Redmineに2要素認証のパッチが提供されている

Redmineに二要素認証のパッチが提供されているのでメモ。
次期バージョン4.0で設定されているので、じきに実装されるのでは、と推測する。

Patch #1237: Add support for one time passwords or two-factor authentication - Redmine

@g_maedaさんがレビューしてコメントされている。

（翻訳開始）
パッチを共有してくださったFelixとPlanioに感謝します。
2FAはアカウントを安全に保つのに役立ち、最新のクラウドベースのアプリケーションでは必須の機能なので、これは非常に優れた拡張機能だと思います。
多くのユーザーがこの機能を歓迎する必要があります。
私はパッチを試しました。 それは非常にうまく動作します。
（翻訳終了）

２要素認証方式は、ネットバンキングでも身近だ。
たぶん、スマホでセキュアなクラウドサービスを使っているならば、この認証方式が普通だろう。

実は知られていない、2段階認証アプリの落とし穴について | 仮想通貨のあるとこ

Redmineに２要素認証が追加されるメリットとしては、Redmineをよりセキュアに使いたい利用シーンで役立つだろう。
たとえば、社外へ公開しているRedmineでは、認証操作が甘いと、Redmineの情報が漏れてしまうリスクがある。
そのリスクを軽減するために、二要素認証をユーザに課すことは考えられる。

また、RedmineをSaaSで提供しているクラウド事業者にとっては、２要素認証の機能は非常に重要な機能要件になるだろう。
アプリそのものがよりセキュアに作られている、という証拠にもなるからだ。

パッチ後の管理画面を見ると、オプション機能で全ユーザに対し２要素認証の設定を各ユーザアカウント画面で有効・無効にできること、バックアップ用のQRコードを作成する機能があるようだ。
２要素認証では、スマホのようなクライアント機器が水没したりして無くなると、非常に困るので、バックアップ用QRコードは助かる。（それが漏れるとリスクありだが）

こういうセキュリティ強化につながる機能がどんどん実装されることで、Redmineがよりエンタープライズな業務やユースケースでも利用範囲が広がれば、Redmineの信頼性も増すだろう。
今後も注目していく。

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない

ネットでフラフラしていたら、偶然良い記事を見つけたのでリンクしておく。
特に主張は無し。
ラフなメモ。

【参考１】Embedded Software Manufactory: ISO 26262との向き合い方 (21) 安全について理解を深める

【1-1】「開発プロセスを管理することでしか、ソフトウェアの品質は管理できない」という文言にしびれた。
ああ、そうなのか。
自分がRedmineにハマっている理由は、たぶん、Redmineを通じて開発プロセスをモニタリングすることで、ソフトウェアプロダクトの品質・コスト・納期を調整しようと暗黙的に行っていたから、と思う。

でも、プロセスアプローチの発想は、アジャイル開発とは異なる。
アジャイル開発は、プロセス重視ではない。
では、その部分はどう解釈するべきか？

（引用開始）
しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。（『ソフトウェア品質論の歴史的推移』を参照されたし）
（引用終了）

【1-2】IT業界では、新しい技術や設計思想は、熱意を持った人がエバンジェリストとして普及させる必要がある、という経験則があるのだろう。
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」の最初にも「エバンジェリスト」があったなあ、と気づく。

（引用開始）
そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。
（中略）
Microsoft の社員の肩書きで Evangelist（エバンジェリスト：伝道者）というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。
宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。（洗脳者のような胡散臭い感じもするが・・・）
（引用終了）

【参考２】Embedded Software Manufactory: ソフトウェア品質論の歴史的推移

（引用開始）
「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
（中略）
この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
「民主主義的原理に基づく品質論」
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
（引用終了）

製造業の品質管理技法は、いわゆる古典的な統計的品質管理が発端らしい。
つまり、量産品のバラツキを統計的手法によって原因分析して解決し、不良率を減らす。
日本が得意。

一方、プラグマティズム的品質論は、「良いプロセスが実践されているからこそ、良い品質が生み出される」と考える」。
この発想を元に、プロセスを国際規格として定めて、トップダウン・アプローチで形式知として実現したものが、ISOなどの各種規格。
今の日本は、このやり方がグローバル・スタンダードになったために、すごく苦労している。

さらに、「民主主義的原理に基づく品質論」はマーケティング３．０または、アジャイル開発を連想させる。

しかし、日本の品質管理でも、製品ライフサイクルによって、狩野モデルにある「魅力的品質」から「一元的品質」「当たり前品質」へ品質が変化する、ということも既に指摘されていた。
この辺りの整合性はどう取るのか？

【参考３】Embedded Software Manufactory: 機能安全の意味がわかった(IEC61508とISO26262の最新情報）

最近よく聞く「機能安全」とは、安全装置が保証する安全に関する機能、という思想があるわけか。
そうならば、すごく理解しやすい。
最近は、IPAも組込安全規格に関して、盛んに研究しているしね。

（引用開始）
機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。
（中略）
機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全（=機能安全）と考えると非常にすっきりする。
そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。
（引用終了）

【参考４】Embedded Software Manufactory: ISO 26262との向き合い方 (6) 機能安全のマネジメント2

【4-1】現代のソフトウェア開発では、ITS、SCM、CIツールの３つが使われるのは当たり前。
その効果は、変更管理や構成管理がツールで制御できるようになったこと。
今後の課題は、要件管理である、という主張。

（引用開始）
変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。
（中略）
構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。（構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。）
（引用終了）

【4-2】日本発祥の開発プロセスであるXDDPは、特に派生開発で有効。
その理由は、日本人に合うボトムアップ・アプローチによる変更管理をコントロールできるから。

（引用開始）
日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識： Awareness: Worrying about Quality の力ではないかと思っている。（これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。）
（引用終了）

【4-3】安全が確保されている証拠、機能安全の規格を満たしている証拠として、トレーサビリティマトリクスがある。
そのトレーサビリティマトリクスを作成・維持するために、要件管理ツールの存在意義がある、という主張。

（引用開始）
その状態を回避し、ユーザーの期待（安全は当たり前に確保されているはず）に答えるには、安全に対する要求と、その実現方法、実現の結果（証拠）を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。
要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。
（引用終了）

【参考５】Embedded Software Manufactory: ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

著者がISO 26262 にこだわっている理由を経験談を元に書かれている。
「「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態」だったから、米国での製品販売が止められた。
著者は、当初、理由が分からなかった。
きちんとやっているのに、なぜ差し止められるのか。

しかし、後に著者は理解する。
「個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。」
つまり、世界標準のやり方でないと通用しない世界がある。
その背後には、プロセスアプローチ、プラグマティズム的品質論の考え方がある。

統計学の考え方に関する感想

統計学を勉強してみて、気づいたこと、考えたことをメモ。
ラフなメモ書き。
以下は、自分が理解したいために、僕が理解した内容をラフスケッチで書き残す。
但し、自分はまだ統計初心者なので、間違っていたら後で直す。

【1】統計学という学問が最近、すごく重要になっているのはすぐに同意するのに、実際に理解しようとすると訳が分からなくなる。
IOT、AI、ビッグデータみたいなバズワードもあれば、心理学、経済学、疫学、国勢調査のように古くからの数多くの専門分野でも統計学の知識が語られていて、何が本質なのか分かりにくい。

【1-1】それぞれの学問では、統計学をやりたいのではなく、それぞれの学問で解決したい問題があり、その解決に統計学の手法を利用しているだけ。
だから、ベイズ統計の話は経済学で多かったり、因子分析の話は心理学やで多い、など、使われる統計手法も異なるみたい。
よって、初心者が勉強しようとすると、数多くの手法が紹介された情報を読んでしまって、逆に混乱してしまいがち。

【2】では、統計学の基本的な思想とは一体何なのか？

なお、以下の考えは、「経済数学の直観的方法 確率・統計編」に大きく影響を受けている。

【2-1】物理における古典力学の基本的思想に対応するものが、統計学では正規分布に相当する

統計学の計算方法を理解してくると、微積分や古典力学とは発想が大きく異なることに気づく。
考え方が全く違う、と思った方がいいと思う。

古典力学の発想は、自然現象はビリヤードみたいなもの。
粒子が衝突してどう飛ぶのか、微小な現象から全体の運動系を微分方程式を使って探し出す。

一方、「経済数学の直感的方法～確率統計編」を読んで理解した限り、確率・統計学の基本思想は、確率論ではなく誤差論にある。
統計学の発想では、真の誤差（ボラティリティ）は正規分布で表現されるので、正規分布の形さえ確定すれば、現象の確率を見極められる、というストーリー。

【2-2】統計学の発想では、自然現象における物事のバラツキは、トレンドとボラティリティの2種類がある。

トレンドは、ある傾向で偏りが発生するもの。
ボラティリティは、人の意思で制御できず、偶然の産物で発生するもの。

そして、トレンドに相当する部分は、人の知恵や改善によって解決できるが、ボラティリティの部分は人は制御できず、神様のサイコロに任せるしか無い、と考える。

このボラティリティの部分は、大数の法則によって、正規分布に近似される。
そこで、正規分布の形を把握できれば、自然現象の不確定な動きを予知できるようになる。

たとえば、トレンドとボラティリティという考え方は、製造業における大量生産の製品の統計的品質管理、あるいは、ファイナンスにおけるデリバティブ商品のリスクとリターンの考え方へ適用できる。

但し、全ての誤差の分布が正規分布に集約される、というわけではない。
誤差が非線形に発散する場合、色んな分布が提唱されているみたい。

【2-2-1】実際、製造業の品質管理では、量産した製品の品質のばらつきに対し、系統誤差(トレンド)と偶然誤差(ボラティリティ)に明確に分けるために、フィッシャーの３原則を適用する。
つまり、局所管理や無作為化の原則によって系統誤差を調整し、繰り返しの原則によって偶然誤差を調整する。

あるいは、品質管理において、バラツキの種類には、異常原因によるバラツキ(トレンド)と偶然原因によるバラツキ(ボラティリティ)と考える。

異常原因によるバラツキは、製造工程で何らかの不備があり発生した、と考えて、根本原因を追求し、是正処置を取って、バラツキをなくす。
偶然原因によるバラツキは、原因を調べても意味がないもの。
たとえば、正しい作業手順を作って、その作業手順にいくら従っても発生してしまうバラツキ。
つまり、トレンドは統計的品質管理の技法を使って原因を除去するが、ボラティリティは対処しようがない。

【2-2-2】また、ファイナンスでは、ボラティリティが大きいほど、リスクは大きいがリターンも大きくなる。
そこで、たとえば、猛暑でリターンの大きい証券と冷夏でリターンの大きい証券を組合せて、リスクを減らして確実にリターンを得るように考慮する。
つまり、相関関数が－１になるように組合せる。

すると、証券を上手く組合せると、無リスク資産の概念が出てきて、これが最終的にはデリバティブのオプション価格として提供されるようになる。
その煙のようなオプション価格は、ブラック・ショールズ・モデルによって原理的に計算されるわけだ。

「経済数学の直感的方法～確率統計編」では、微分方程式を発展させた確率微分方程式の背景には、トレンドとボラティリティを分離する、という思想があるという。
その思想を具体化したものが、伊藤の補題。
この伊藤の補題があったからこそ、ブラック・ショールズの公式が証明できた、というストーリーらしい。

【2-3】正規分布の形は、平均値と標準偏差の2つで決まる。

平均値は、正規分布の頂点。
標準偏差は、正規分布の頂点と変曲点の間の距離。
つまり、標準偏差が大きいほど、正規分布はなだらかな形になり、バラツキが大きい性質が導かれる。

物事の不確定な現象の動きを把握するために、正規分布を使う。
ある母集団の母平均と母分散が判明していれば、あるサンプルが正規分布のどこに位置するのかを、計算することで、そのサンプルが発生する確率を導ける。

この確率の計算が特殊。
確率は、正規分布の面積から求まる。
つまり、Z＝（ｘ－μ）/σでZ値を求めて、Z値から正規分布の面積を求めると、その面積が確率に相当する。
だから、昔は、正規分布の面積を簡単に計算できなかったので、正規分布表なる紙がいつも準備されていたわけだ。

【2-4】2つのサンプルの違いなどを把握するために、t検定、F検定、χ二乗検定などの推定を行う。
これらの検定処理で使うt分布、F分布、χ二乗分布は、正規分布の発想と同じ。

サンプルの測定値から、t値、F値、χ二乗値を計算して、各分布の面積を求めることで確率が出る。
その確率が５％未満ならば、帰無仮説が棄却されて、有意となる。
この有意という発想も、最初は理解しにくい。

僕の理解では、主張したい仮説を対立仮説、その逆を帰無仮説として提示する。
すると、帰無仮説が発生する確率が５％未満ならば、その帰無仮説が発生する事象は相当稀である。
ほとんど発生しないと言っていい。
そこで、背理法を拡張した確率的背理法によって、帰無仮説が発生する事象はほとんど起こらない、ゆえに、対立仮説は確率的にほぼ正しい、と導く。
この辺りは、用語も使い方も数学的にも厳密に証明されているみたい。

この検定処理を使って、２つの社会的集団に対して、補助金の政策効果、会社の人事施策の効果、マーケティングにおける販促の効果などを測定する、といった使い方を行うわけだ。
そして、そういう手法を行うための統計学的理論は揃っているので、後は、Webシステムとクラウド環境を使えば、いくらでもデータ収集できるし、いくらでもデータ分析できる、という流れなのだろう。

【2-5】相関関係があっても因果関係があるとは限らない

相関関数はわりと簡単に計算できる。
しかし、その解釈がすごく難しい。

2つの事象に対し、相関関数が大きければ、たしかに関係が深い、と分かるが、だからと言って、因果関係があるとは言い切れない。
ニセの相関関係、隠れた因子など、色んな観点で考慮しなくてはいけない。

「相関係数」ってなんですか？ -意味と利点と欠点をわかりやすく- - Data Science by R and Python

つまり、相関関数の一つの値に、多様な現象の因果関係の意味がたくさん込められているから、解釈が難しいのだ。
一方、相関関数はデータさえ収集できれば、現代ならすぐに計算できる。
だから、解釈が難しくても、使われているのではないか。

【2-6】最近のWebやIOTでは、どんな傾向があるのか？

結論は、最近は、WebやIOTのおかげで、ランダム化比較試験を実施しやすくなった点だろう。
そのおかげで、いくらでも、多様な人間の集団に対して、色んな仮説を検証しやすくなった事があるのだろう。

Webとクラウドの環境さえあれば、ユーザにスマホやセンサー機器にデータを入力してもらい、いくらでも個人情報とその履歴を統計学の知識を用いて、仮説を検証すればいい。
この辺の考えは、下記にラフに書いた。

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

すると、ランダム化比較試験がやりやすい環境とは何だろうか、という問題意識につながる。
個人情報保護法が厳しいほど、こういう実験がやりにくい。
そこで、オープンデータのような流れもある。

また、ユーザ数が多いほど、データを集めやすい。
おそらく、中国のように１０億人以上のユーザがスマホを使って、決済やビジネスを行ってくれれば、そこに蓄積されるデータ量は、他の国よりも莫大だろう。
データという資源が多い国ほど、データ分析も有利、という考えが正しいならば、今後はそういう流れになるのではないか。

【2-6-1】しかし、現代はランダム化比較試験の環境を整えやすくなったと言っても、その前提条件を満たすように構築するのはそれなりに人もシステムも費用もかかる。

人の集団を介入群と非介入群の2つに分けようとしても、既にバイアスがかかっていると、本当に検証したい仮説をいくら立てても無意味になる。
むしろ、世の中の経済データ、マーケティングデータは、バイアスがかかって手垢の付いたデータばかりなので、そのデータをそのまま統計処理することはできない場合が多い。

統計処理できるパターンは、「自然実験」「回帰不連続設計法」「集計分析」「パネル・データ分析」など、限られた手法になる。
この辺りの問題点は、「データ分析の力 因果関係に迫る思考法」が詳しい。

【2-6-2】しかし、ランダム化比較試験を行うための環境を構築するための前提条件は、統計学の理論で既にある程度知られているようだ。

たとえば、フィッシャーの3原則がそうだろう。
あるいは、ランダム化比較試験の環境を作るために、層別サンプリング、集落サンプリング、系統サンプリングなどのサンプリング手法を使い分ければいい。

たとえば、製造業の品質管理の技法では、層別サンプリングがよく使われるみたい。
技法として、ヒストグラムやパレート図を頻繁に使うからだろう。

一方、心理学、教育学、経済学などでは、集落サンプリングがよく使われるように思える。
なぜなら、全ての人間の集団をテストできないので、母集団からランダムにあるクラスタ（集落）を選んで、その集落全員を試験対象にする方法を使うことで、母集団と同質でありながら狭い範囲の集団をテストすることで代用したいからだ。

今はExcelでも簡単に乱数を生成できるので、集落サンプリングがやりやすくなったこともあるのではないか。

AstahのRedmine連携プラグインが公開されました

AstahのRedmine連携プラグインが公開されました。
とても使いやすいので気に入っている。
ラフなメモ書き。

【参考】
Redmine連携プラグイン | Astah

ChangeVision/astah-redmine-plugin: Associating Redmine tickets to a diagram

【1】astahを使いながら、モデリングという作業に、変更管理や構成管理の概念が反映されていない点にずっと違和感があった。
その問題意識は下記に書いた。

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

描いたモデルは、一度書いたらそれで終わりということはない。
頻繁な仕様変更、洗練された設計思想へ反映などの作業で、モデルはどんどん変化する。

また、モデリング作業を行っていくと、数多くのモデル間の整合性を考慮していくうちに、モデルが変化する。
さらに、モデルの粒度を考えながら、モデルをリファクタリングすることもあるだろう。

つまり、モデル間の粒度やトレーサビリティを考慮すると、モデルの変更履歴をどこかで保持したくなる。

しかし、astahにせよ、EnterpriseArchitectやRationalRoseにせよ、モデルのファイルはバイナリのため、Gitで履歴管理してもあまり有り難みがない。
また、モデルの変更箇所をノートや吹き出しで追加していくうちに、モデルが醜くなってしまう。

【2】では、上記の問題点はどうやって解決できるか？

根本的な解決方法ではないが、モデルの変更履歴はRedmineチケットへ外出しすることで、モデルの変更管理や構成管理の問題点はある程度解決できるはず、と僕は考えている。

つまり、モデルの変更履歴のように、モデルのある時点のスナップショットとなる履歴情報は、Redmineチケットで管理すべき、と考える。
そうすれば、モデルは常に最新の仕様を反映した状態で保持すれば良い。
モデルが色んな事情で変更された経緯は、Redmineチケットの内容で確認すればいい。

たとえば、Excel設計書に必ず付属する変更履歴シート、昔のJavaのJavaDocにあった@historyのようなソース変更履歴コメントは、そもそもRedmineで一括管理すべき情報だから。

【3】上記のRedmine連携プラグインでは、下記の機能を持つ。

1)astahのモデル（実際はUMLダイアグラム等）の単位で、Redmineチケットを登録・参照できる
　仕組みとしては、RedmineのREST APIを使う。

2)astahのモデルとRedmineプロジェクトは1対1に対応付けられ、Redmineチケット一覧が表示される。
　astahで表示されたRedmineチケット一覧では、ステータスや優先度などのチケット項目でソートできる。

3)astahの全モデルのRedmineチケット一覧も表示できる。

4)但し、astahにはRedmineチケットの基本的情報を表示するだけであり、詳細な情報はRedmine上で編集する運用になる。
　Redmine上で編集した情報をastahへ同期する場合、「Sync」ボタンを押せばよい。

【3-1】Redmine連携プラグインによって、astahモデルから、モデルの変更履歴の吹き出しの情報は全てRedmineチケットへ外出しされる。
Redmineに蓄積されたモデル変更のチケット情報は、Redmineの優れたチケット集計機能でいくらでも分析できる。

たとえば、モデルのレビュー記録チケットから、レビューの効果やモデルの品質を計測してもいい。
また、モデルのアーキテクチャや要望が未決定のため保留となっている箇所は、課題チケットに外出して、未解決リストとして扱ってもいい。
あるいは、Redmineチケットはタスクと見なせるから、将来のモデル修正のToDoリストとして使ってもいい。

すなわち、astahのモデルに付属するRedmineチケットのビューは、「モデルの変更履歴」だけでなく「モデル修正のToDoリスト」だったり、「モデルの未解決の課題リスト」として扱うこともできる。

【3-2】そういう複数の観点でRedmineチケットを管理できれば、astahのモデルの作業管理が大変やりやすくなるだろう、と思う。
なぜなら、モデルは一夜で完成するものではなく、数多くの顧客要望を五月雨式に反映したり、他要件を考慮しながら洗練させていく作業のために、たくさんのToDoや課題が発生するからだ。
それらのTODOや課題を漏れなく管理していくことは、とても重要だから。

【3-3】そこで、astahのモデルのRedmineチケット一覧画面で、各項目をソートできる機能が有効に役立つ。
たとえば、ステータスでソートして、未着手・作業中のチケットを一覧の上部に表示するようにすれば、TODOリストのように扱える。
あるいは、優先度でソートして、優先度の高いチケットを画面上部に表示すれば、直近で最優先のタスクを判別できるようになる。
さらに、トラッカーでソートして、障害や課題チケットのみに注目してもいい。

実際にRedmine連携プラグインを使っていくと分かるが、モデルの変更作業の情報をチケットに起票していくと、じきに10件、50件とチケットが増えていく。
そして、完了チケットと作業中チケットがたくさん混じってしまい、管理しにくくなる。

だから、変更履歴として見たい時は、ステータスの降順でソートする一方、TODOリストとして見たい時はステータスの昇順でソートするし、課題リストとして見たい時は、トラッカーでソートしたくなるだろう。

【3-4】さらに、Redmineチケットの情報をもっと詳しく書きたいなら、astahではなく、Redmineチケットに書き込めばよいだろう。
そうすれば、Redmineの優れたチケット集計機能や全文検索機能で、欲しい情報をいくらでも集計したり検索できるようになる。
また、Wikiとリンクさせて情報を集約させることもできるだろうし、モデルのTODOリストとなるチケットを元に、Redmine上で進捗管理してもいい。

すなわち、astahではモデルそのものの要件や仕様を描くことに注力し、課題やTODOはRedmineで管理するように、区別して管理すればいい。
つまり、モデルの作業そのものの進捗管理、課題管理はRedmineで代用できるし、その方がRedmineの優れた機能を利用できるメリットがある。

但し、モデルそのものの履歴管理、つまりモデルの構成管理はRedmine単体だけでは実現できない。
モデルがどのように変化したのか、実際に見たい、という要望は、上記のプラグインでも実現されないので注意。

【3-5】astahユーザがRedmineを使っているならば、Redmine連携プラグインはたぶん使いやすいと思う。

似たようなastahのプラグインとして、TODOプラグインなどがあったけれど、TODO一覧がastahモデル単位に表示されないので、TODOが溢れると探しにくくなる弱点があった。
また、TODOをソートできない弱点もあり、TODOが多くなるとイマイチな面があった。
でも、Redmine連携プラグインで、それらの弱点は全て解決される。

【4】僕は、astahのようなモデリングツールとRedmineやTestLinkなどの開発支援ツールと外部連携することは、とても発展の余地があると考えている。
なぜなら、astahのモデルと外部の開発支援ツールが連携することで、数多くの情報を相互に参照しやすくなり、色んな使い道が出てくるからだ。

実際、Redmine連携プラグインによって、astahのモデルの変更履歴がRedmineチケットに蓄積されるだけでなく、モデリング作業の進捗管理やモデルの課題管理を行えるようになる。
また、TestLinkとastahがもし連携できれば、テストケースと要求図を相互リンクできて、要件カバレッジを出力できたり、トレーサビリティマトリクスを出力する、という機能も実現できるかもしれない。

よって、モデリング作業を開発プロセスの一部に取り込んでしまい、昨今の優れたプロセス支援ツールの機能を流用して相乗効果を得る、ということもできるのではないか。

あるいは、astahで設計したモデルに関する情報を超高速開発ツールに取り込んで、即座に開発していく、というモデル駆動開発も実現できるかもしれない。

この辺りの構想も今後まとめる。

【追記】下記の要望があがっていた。
上記のRedmine連携プラグインは、astahモデルから、変更履歴や課題一覧、ToDoリストをRedmineへ外出ししているに過ぎない。
最終的には、モデル自身の構成管理、つまりモデルの変更履歴を保持する仕組みが必要になるだろう。
つまり、モデルのライフサイクルを管理する枠組みが必要になるのではないか。

岡本卓也さんのツイート: "Redmineチケットからastahダイアグラム方向への参照（クリックで図に飛ぶ）が出来ると素晴らしいのですが、そうなるとastahファイル自体がシングルトンで共有できてて欲しい。 と言うようなことを開発者の人とも話してました。… "

岡本卓也さんのツイート: "確かに現状では難しいですよね。ただ、モデリングの目的（の１つ）がコミュニケーションだとすると、モデルを共有して検討を積み上げる機能が欲しいなと。 astah Shareが健在なら、、ってよく思います。… "

アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。
内容がとても奥深い。

僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。
以下、ロジカルでないラフなメモ書き。

【参考】
@yusuke_arclampさんのまとめ記事が公開されました。

アジャイルにおける事前合意について - arclamp

【1】エンタープライズアジャイル勉強会　2017年12月セミナー開催のお知らせ

アジャイルを機能させる外枠について - arclamp

(引用開始)
アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。
チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@papanda）にお願いしました。市谷さんの講演は「アシ?ャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。
ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました（参照：大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp）

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。
(引用終了)

つまり、見積りできないモノ、ステークホルダーとの調整をアジャイルチームに持ち込まない。

アジャイル開発を支えるアーキテクチャ設計とは from Yusuke SUZUKI

isopさんのツイート: "kent beckや平鍋さんが偉大なアーキテクトだから、という文脈は激しく同意したい"

isopさんのツイート: "@hiranabe 先日のエンタープライズアジャイル勉強会での @yusuke_arclamp さんのQAセッションで開発サイクルを回すことでアーキテクチャは自然と生まれてくるのか？という質問に対する回答でした"

鈴木雄介/Yusuke SUZUKIさんのツイート: "どちらかというと「平鍋さんやkent beckがアジャイルを語るとき、アーキテクチャの重要性が本人達にとって自明すぎるがゆえに語られないのは問題だ」というクレームめいた言い方をしまして... https://t.co/P6Ou6WRkpl"

【2】上記に関する感想をツイート。

akipiiさんのツイート: "名言。ストンと落ちた。RT @yusuke_arclamp: エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM https://t.co/qFNXcROiek"

昌。さんのツイート: "@akipii @yusuke_arclamp 先日のアジャイル勉強会でもその辺り激しく主張されてましたね"

akipiiさんのツイート: "@aj15_aj15 @yusuke_arclamp 立場によっては、当たり前だろ、という意見と、開発を最大に効率化する観点では、この方法しかないので、この方法を洗練化すべきだ、という意見があると思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@akipii @aj15_aj15 特にエンタープライズ業界でアジャイルをスタートする方は強めに意識してもらいたいな、と思います。僕の知る現場で苦労しているのは、この2つということが多いので。"

門屋　浩文さんのツイート: "@yusuke_arclamp @akipii @aj15_aj15 なるほど。エンタープライズアジャイルにはまだ踏み込んでいませんが、納得です。ただ、それができるPOやSMはウォーターフォールでもうまくいく気がします。早く成果物を作る・使うって効果を優先ってことで手法を選択、ですかね"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 いえいえ、もっと深い意味があります。DOAモデラーとの議論では、アジャイル開発では要件定義やアーキテクチャ設計は誰が担当するのか？と言う議論がありました。アジャイル開発の文脈では、開発チームは要件定義やアーキテクチャ設計を担当せず、POに委ねることで解決しようとしてます。多分。"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 よって、DOAモデラーの観点では、そうならば 速く開発できるのは当たり前でしょ、と。でも要件定義やデータモデリングを他人の手に委ねて良いのかと。僕は、アジャイル開発のような特化したやり方は有りと思うし、そういう仕組みがあるから中小SIが市場に食い込めるので日本では人気あると理解し… https://t.co/QO72yG0fhm"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@MadoWindahead @akipii @aj15_aj15 アジャイルでは「要件定義レベルでモデルやアーキテクチャを固くすることに意味がない」とも言えます。なぜなら変化するから。つまり、作りはじめるまでに、いつ、どこまで、誰が固く表現するのか？というのが論点かと。"

【3】スクラムとの関わりについて。

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルで「エンジニアにとって面倒なことをチームに持ち込まない」というのを「効率化のために調整は減らすべき」と考えるか「エンジニアの甘え、仕事の醍醐味は調整だ」とするかで分かれそう。もちろん、両面ある。僕としては「両者を混ぜて曖昧にするな」というだけ。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スクラムマスターってエンジニアの世話役とかおもりみたいな面もあり「そんなの甘え」と思う人もいるだろが、そういう人がいないとエンジニアが機能しないのも事実なんだよね。ウォーターフォールでいう「バッファ」を実体化したのがスクラムマスターともいえるのかな？"

鈴木雄介/Yusuke SUZUKIさんのツイート: "ともかく日本でまともな開発現場、エンジニアがやり甲斐があって、つらくならない開発現場を増やしたい。でも、なんでもできるエンジニアは限られているから組織やチームとしてできる体制を作らないといけない。だから、マネジメントが必要になる。アジャイルは良いツール。"

みぞやんさんのツイート: "@yusuke_arclamp WFでいう（人数によりますが）サブシステムごとのチームリーダーがスクラムマスターを担えるといいのかなと思いました"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@mizoyan432 最新のスクラムガイドでも「スクラムマスターはサーバントなリーダーである」と記載があるので、ある意味ではその通りです。ただしコミュニケーションパスを抑えるようなリーダーではないべきですね。"

HARADA Kiroさんのツイート: "@yusuke_arclamp 有効なら「甘え」でなにか悪いことでも？くらいのノリですかねえ。バッファよりは、もうちょい能動的で、バッファ減らす要因に働きかけに行く感じ。"

【4】アジャイル開発とWF型開発における、プロセスの違い、体制の違い、

鈴木雄介/Yusuke SUZUKIさんのツイート: "企画の決める仕様がゆるい、基幹システム連携がもめる、運用部門に提出するドキュメント作成が大変、といったことはWFからアジャイルになっても変わらない。むしろ、課題として明示化される。作業に落とし込めない調整事を開発チームに持ち込ませないのが大事。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンタープライズ開発だと、WFでもアジャイルでもやるべきことはきちんとやる、のです。ただ、作業にならないものはスプリントに持ち込めなくなるからPOやSMが頑張って作業になるように調整を行うことになる。その代わりチームは機能の実現に全力を尽くす。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スプリント計画で「開発チームが見積もれないものはスプリントバックログにいれない」というのが大事です。それがグダグダになるとうまく回らなくなる。そもそもプロダクトバックログに調整中のものは持ち込まないべき。その手前に解決しておかないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルに比べてWFの方がゲートやプロセスが厳密なんて聞きますが、間違いです。アジャイルはスプリントごとのゲートやプロセスは大変に厳密です。ただWFはゲートの数が少ないので一回でやるべきことが多くなるだけで。"

上記のツイートは、本当に同意。
大規模WF型開発でも、優秀なプロジェクトマネージャは故意にフェーズ分けして段階リリースを踏む、という手段を取る場合が多い。
最後の1回だけの本番リリースは危険すぎる。

鈴木雄介/Yusuke SUZUKIさんのツイート: "WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていた頃が僕にもありましたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM"

そういう文脈で、アジャイル開発では、スクラムマスターやプロダクトオーナーが防波堤になる。
組織パターンにおける防火壁、ファイアウォール。

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラで調整が面倒なのは仕様合意、システム連携、インフラ調整、運用引継。インフラ調整はクラウド化で軽減、システム連携や運用引継はプロセス関係なく事前ネゴ。仕様合意はアジャイルの締切駆動や定期調整に変更。つまり、アジャイルで変化を強く求められるのはビジネス側"

鈴木雄介/Yusuke SUZUKIさんのツイート: "みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。"

【5】@yusuke_arclampさんと@sugimoto_keiさんのやり取りを読んだ後で振り返ると、おそらく、アジャイル開発には要件定義工程はあるのか、という問題の本質を突いているのではないか、と直感した。

杉本啓さんのツイート: "鈴木さんのエントリで一番気になったのは「見積もれないことをチームに持ち込まない」という点です。興味深い要求は、ふつう最初見積もれないですからね。これは「なすり合い」「平行線」とは違うと思うのです。私は鈴木さんの心情を批判しているのではなく書かれた主張を批判している点ご理解下さい。 https://t.co/XE9KG0za2U"

吉田 収さんのツイート: "@yusuke_arclamp @sugimoto_kei いわゆる「ビジネスアナリスト」の領域はチーム外とした方がよいということになるでしょうか。"

杉本啓さんのツイート: "@omuysd @yusuke_arclamp お尋ねの点は、どう仕切りたいかという意思の問題に依るところが大きいように思います。私としては、業務側との関係が宜しければ、業務要件の定義・分析もチームで担当する方が好みですが、それは設計/開発だけチームで受けるのとは少し異なるビジネスかと思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@omuysd @sugimoto_kei フェーズによると思います。初期は完全に外でも良くて、作るものが見えて来たらやり取りを開始し、画面への落とし込みはチームに任せていくという雰囲気でしょうかね。杉本さんが言われるようにチームのスキルや関係性で寄り方は変わるでしょうが。"

@yusuke_arclampさんも違和感を感じられているのかな、と感じた。

akipiiさんのツイート: "DOAモデラーとの議論を読んでたら、そんな感じがする。RT @yusuke_arclamp: なんか自分の主張がRUP的にフェーズによってチームスキルの濃淡を付けろという話になっている気がしてきて微妙な気分。うーむ https://t.co/Vweh4rkrnO"

【6】DOAモデラーからの意見。
モデリングするという行為の立場から言えば、まさに正論。

年忘れLT宴会＜第60回IT勉強宴会＞ | ＩＴ勉強宴会blog

ソフトウェア開発と業務システム開発（杉本さん）

(引用開始)
アジャイルとウォーターフォール

・「ソフトウェア開発」に関するアプローチの違いだけではない。
・スコープ(視野に収めている範囲)が違うよね。
・ソフトウェア開発 vs. 業務システム開発
・超高速開発は、スコープの点ではWFと同じ。
・ソフトウェア開発を仕事としているエンジニアに超高速開発を訴えるとき、注意しないとスコープを誤解される。
・超高速開発は、業務システム開発の面を強調した方がよい。超高速開発というとソフト開発が早くできるというメッセージだけ。
(引用終了)

個人的には、関西IT勉強会で、DOAとアジャイル開発におけるモデリングや要件定義の違いについて、@yusuke_arclampさんと@sugimoto_keiさんの対談を聞いてみたい、と思う。

【7】個人的な感想を以下、書いておく。
ラフなメモなので、論理がズレているかもしれない。

【7-1】超高速開発ツールが何故プログラマに嫌われるのか

超高速開発ツールを使うと、DB設計や実装モデルを作れば、プログラミングレスで即座に業務システムを作れる。
つまり、超高速開発はモデル駆動開発の方向性に似ている。

しかし、プログラマの観点では、超高速開発ツールは正直面白くない。

プログラマなら、誰もが自分のプログラムが一番と思っている。
でも、自分が書いた優れたプログラムを見てくれ、という場面をアピールできない。
Githubで互いに書いたプログラムをフォークして、プルリクエストを送る、といったソーシャルコーディングが実現されない。

また、モデルという絵や、モデルを表現するための別のプログラムであるDSL（ドメイン特化言語）を別途覚える手間がかかる。
そんなものを覚える暇があるなら、RubyやPythonをガリガリ書きたいし、そちらの方がはるかに意味があるでしょ、と。

すると、超高速開発ツールは製造業のSE向けがマーケットなんだろうな、と思う。
つまり、プログラミングしないけどシステムを開発したい人達、すなわち発注者、特に日本では製造業のSEがターゲットになるだろう。

彼らはプログラミングは下流工程とみなし、外部へ発注するのが普通と考えているからだ。
外部に発注する工程が超高速開発ツールで代替されて、発注費用がなくなるのが理想だろうから。

akipiiさんのツイート: "同感。良い物なのに肝心のターゲット、つまり発注側のSEに届いてない気がする。RT @sugimoto_kei: 翻って超高速開発ツールを見るに、ターゲットがバクっとし過ぎのような気がする。もちょっとターゲットを定めた方がよいのでは？"

また、超高速開発ツールは多分最終的にはDSL基盤を目指しているんだろうな、と思う。
つまり、超高速開発ツールはプログラミングしない代わりに、モデルを描くために特化したスクリプト言語が必要になり、それがDSL（ドメイン特化言語）になるわけだ。

たとえば、UMLでもOCLみたいなDSLが提唱された時もあった。
DSLの優れた事例は、ExcelのVBAという意見もあったな。

そのDSLの最大の特徴は、プログラマでなくても、ユーザが分かるようなプログラミング言語であり、ユーザが簡単に書けることだろう。
システム化したい業務を一番良く知っているユーザ自身が、モデルをDSLで書いてしまえば、後は超高速開発ツールが即座にシステムを作れる、というストーリー。

そういうストーリーでは、プログラマの出番はないし、業務システムの発注者であるユーザ自身が超高速開発ツールを使いこなせるようにならなければならない。
超高速開発ツールはおそらく、そういう方向へビジネスモデルとして進化するのではないか。

【7-2】アジャイル開発における発注者と開発チームでの設計上の役割分担の誤解

上記のように、アジャイルチームには、外部との調整や要件定義に関わる作業は担当させない。
要件定義やそこから定まるプロダクトバックログはプロダクトオーナーが担当するし、スクラムマスターがスクラムチームの守護神として守る。
つまり、アジャイルチームの外側に、要件定義やモデリングの作業が追いやられているように見える。

モデラーの立場から言えば、そういう分業体制なら、速く開発できるのは当たり前だろう、と。
既に、作るべき機能リストがあり、チームはそれを淡々とこなせばいいのだから、と。

おそらくこの部分で、アジャイル開発とDOAモデラーとの間で、認識の相違が生まれるのだろうと思う。

【7-3】アジャイル開発が何故日本では中小SI企業に人気があるのか

では、なぜ、アジャイル開発が日本でも注目されているのか？
アジャイル開発が注目される理由の中に、日本特有の事情があるのか？

理由として、日本の中小SI企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という@sakaba37さんの意見があって、すごく納得した。

実際、日本のIT業界では、受託開発は請負契約の多段階の下請構造になっている場合がほとんど。
すると、その構造のままでは、中小SI企業自身がIT案件を主導するビジネスはやりにくい。

しかし、アジャイル開発を採用すると、ユーザ企業とシステム企画や要件を直接ヒヤリングしながら、スピーディにシステム開発して納品するビジネスモデルを実現できる。
つまり、今までは、元請けSIの大企業が担当していたシステム企画や要件定義フェーズを、下請けの立場に甘んじていた中小SI企業が直接担当して、ユーザ企業と直接契約できるようになるメリットがある。

特に、Webシステム開発のように、技術力に特化しているならば、要件定義さえ上手くまとめれば、ユーザ企業と直接やり取りしながら、小刻みにリリースしながらシステムを納品していくことができる。
一方、発注者であるユーザ企業も、早い段階でシステムの受入れで確認できるし、途中で細かな改善要望も織り交ぜられるので、双方にメリットが共有できれば、受け入れやすい契約になる。

また、ドメイン駆動設計のような設計手法、ユーザストーリーマッピング等の要件定義手法、リーンキャンパスやリーンスタートアップなどのシステム企画の手法も色々編み出されているので、従来のアジャイル開発の盲点であったフェーズもカバーできるようになってきている。

すなわち、日本におけるアジャイル開発の文脈では、アジャイル開発は、中小SI企業が多段階の下請構造から脱却するためのビジネスモデルとして捉えられる、のではないか。

【7-4】DDD（ドメイン駆動設計）がアジャイル開発におけるモデリング技術の補完的役割を担っている

では、アジャイル開発では要件定義やモデリングは不要なのか？
開発チームの外側で要件定義やモデリングを行うとしても、プロダクトオーナーはアジャイル開発の文脈でどのような要件定義手法やモデリング手法を持つべきなのか？

2018年初頭の日本では、ドメイン駆動設計がアジャイル開発における唯一のモデリング手法として認知されている、という回答になるのではないか。

現場で役立つシステム設計の原則を読んだ | mizoguche.info

Takuto Wadaさんのツイート: "(トッパン|ピアソン)ショック、単に絶版、様々な要因でOOA/OODの書籍がほぼ死滅し、訳書が出るタイミングが遅かったDDD本だけがオーパーツのような存在になった結果、日本ではDDD ≒ OOA/OODになってしまったという奇妙な状況の背景の話をした #teppeis_sushi"

@t_wadaさんの指摘の通り、2000年代はオブジェクト指向分析の観点で色んなモデリング手法が提唱されていたが、それらの本を出版していた出版元が書籍発行を辞めてしまったため、最も遅く出版されたドメイン駆動設計本だけが生き残り、その本しかアジャイル開発者は参考できない、という現状があるからではないか。

つまり、ドメイン駆動設計が日本で注目されている理由の一つは、そういう日本特有の事情があるのではないか。

【7-5】超高速開発ツールには、DOA基盤のツール以外にも、SalesforceやKintone、Ruby on Railsも含まれる

そういう超高速開発ツールはDOA基盤のツールだけでなく、著名なパッケージ製品では、SalesforceやKintoneも含まれるだろう。
たとえば、DOAの発想でデータモデルさえきちんと設計すれば、Salesforceで簡単に実装できる。
また、要件定義できちんと要件さえ確定していれば、KintoneでAPIを駆使して、簡単な業務システムを作り込める。

杉本啓さんのツイート: "kintone というのは複数テーブルのジョインも出来ないと聞いて、全然だめじゃないのと思っていたのだが、使ってみるとそうでもないようだ。簡単な台帳を作るにはよく練られている。ターゲットとする用途をうまく選択することがいかに重要かを示す例かもしれない。"

杉本啓さんのツイート: "@akipii はい。私も超高速開発ツールと同じと思っていましたが、おっしゃるように、想定している利用シーンが異なる（kintone の方が絞り込まれている）のではないかと今は考えています。@iteman さんの方が詳しいですが。"

Atsuhiro Kuboさんのツイート: "@sugimoto_kei @akipii 汎用の CMS と WordPress 等のブログシステムとの違いに近いと感じています。超高速開発ツールは「設計する」というアクティビティがあると思いますが、kintone にはそれがない感じでしょうか。"

そういう観点では、Ruby on Railsも超高速開発ツールの一種とみなすこともできるだろう。
業務のデータモデルをActiveRecordで対応付けることができれば、画面は簡単に自動生成できるから。

さらに、画面の細かなUIは、JavaScriptで作りこめばいい。
たとえば、XEADでも、画面UIの作りこみの部分はJavaScriptで実装できるように作られている。

特に、Ruby on RailsはJavaScriptと大変相性が良いので、画面UIをデスクトップアプリのような操作感で実現できる。

よって、最近は、DOA基盤のツールだけでなく、SalesforceやKintoneのように手軽に操作できる有償のパッケージ製品、さらにはRuby on Railsのような強力なフレームワークが普及したことで、超高速開発ツールを適用したいニーズに当てはまるのだろう、と思う。

【7-6】超高速開発ツールが普及したからこそ、匠Methodのような要件定義手法に価値がある

アジャイル開発やプログラマの視点では、超高速開発ツールに否定的になってしまう。
しかし、超高速開発ツールのおかげで、発注者自身がお手軽にシステム開発できる基盤が整った、という側面もある。
つまり、要件定義できちんとシステム要件さえ確定できれば、超高速開発ツールを使えば、即座にシステム化できるのだ。
よって、萩本さんが提唱する匠Methodを要件定義のための手法として扱って、超高速開発ツールのインプットに連携すれば、スムーズにアジャイルに開発できるだろう、と思う。

そんな話を連想できたのは、先月に関西匠塾に行ってきて、匠メソッドの概要を初めて聞いたから。
詳細はまだ理解しきれていないけれど、ビジネスモデル設計やシステム企画から業務の要件定義まで一通り、設計できる、とのこと。

価値を描き、活動に落とし込む手法を学ぼう！ - connpass

では、その後はどうやってシステム開発するのか？
お話を聞くと、たとえば、Salesforceを使って、システム要件を元に素早くシステム開発していく、というストーリーみたい。
つまり、匠メソッドを要件定義のアウトプットを作るフェーズで使って、業務の要件定義書を作り、それをSalesforceやKintoneのインプットとして用いることで、アジャイルに開発できる。

【7-7】kintoneという超高速開発ツールの開発基盤があるからこそ、業務ハックという職業も生まれる

この考え方は、最近、倉貫さんの会社でも提唱されている業務ハックにつながるのではないか、と推測する。

業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

業務ハック勉強会@大阪 ? 働き方改革にも効く！事例で学ぶ業務改善のノウハウ - connpass

つまり、超高速開発ツールのような即座にシステム化できる開発基盤があるからこそ、プログラマの観点では、業務モデリングも実装ツールの一つに組み込んでしまって、アジャイルにシステムを作りながら、業務もシステムも改善してく手法を取っていく、という考え方ではないか。
ユーザから画面UIに関する細かな改善要望があっても、JavaScriptさえ操ることができるなら、画面UIの作りこみにさほど苦労することはないだろうから。

この辺りは聞いてみないと分からないけど。

【8】以上は妄想にすぎない部分もあるけれど、今年も色んな勉強会に行ってみて、上記のアイデアの方向性が合っているのか、確認してみたい。

【追記1】
鈴木雄介/Yusuke SUZUKIさんのツイート: "相変わらずウォーターフォールとアジャイルの話は受けがいいなぁ。最近のエンタープライズ界隈はウォーターフォールからアジャイルへの転向が増えている気がするので、もっと、こういう話はされていいんだろうな。 https://t.co/yR1x9ZUku4"

【追記２】
杉本啓さんのツイート: "読みました。興味深い試みですね。業務の仕組みを作るという志向において超高速開発やDOA界隈と似ていると思います。「業務ハッカー」という呼称は、確かに新味があってプログラマに受けそうですが、顧客サイドからするとどうですかね。現場の人には響くでしょうが、上の方には響きにくいかも。 https://t.co/fbXybQn6vL"

akipiiさんのツイート: "@sugimoto_kei 実現したいものは超高速開発ツールも業務ハッカーも同じ方向性に感じます。但し、モデリングに注力してノンプログラミングにする超高速開発ツールと、プログラミング作業の中に業務設計や運用設計を取り込む業務ハッカーは手法が異なると読み取りました。"

杉本啓さんのツイート: "@akipii まあ、嗜好は違うのだとは思いますが、同じ問題領域を対象にするのであれば、収斂してくるような気がしますね。超高速開発がノンプログラミングというのはセールストークであって実際にはDSLなどでプログラミングするわけだし、業務ハックで使うkintoneもある種のDSL環境ですしね。"

杉本啓さんのツイート: "@akipii 業務ハッカーについては、私は、さほど違和感を感じていません。買う側の意思決定者には響きにくいだろうなと思う程度です。調整をチーム外にという鈴木さんの話については、たぶん問題意識についても不一致があると思います。"

杉本啓さんのツイート: "@akipii とはいえ「超高速開発」よりは「業務ハッカー」の方がセンスありますね。ユーザ視点に立つと、前者では開発が速くなるんだろうなあという印象しか湧きません。後者だと、自分たちの業務に踏み込んで考えてくれるのかも、という期待が持てます。"