仮説検証スタイルとアジャイル開発の関連性

勝間和代の本を読みながら、アジャイル開発との関連性についてメモ。
＃ラフなメモ書き。

【元ネタの本】

昨今、外資系コンサルタントやMBAホルダーの思考スタイルであるフレームワーク思考、仮説検証スタイル、ロジカルシンキングなどが流行している。
それらの本を読んでみると、確かに実際の仕事で役立つ。

これらの本で興味深いと思ったのは、限られた情報の中で、精度の高い意思決定をする技術の重要性だ。
つまり、鮮度はいいけれど正確さが多少悪い判断の方が、遅くて正確な判断よりも重要である、と。

この意思決定のスキルは、中間管理職よりも経営者のように上級マネジメント職での基本技術のように思える。
実際、経営者は、動きの激しいマーケットの中で、素早く正しい舵取りを要求されている。

この意思決定の構造は何か？
それが仮説検証スタイルなのだろう。

つまり、限られた情報から、論理的に整合性が取れている仮説を一旦作り、それから行動すべき対策を導き出すことだ。
勝間和代の本では、この構造を「空-雨-傘」フレームワークと呼んでいる。

空は客観的な事実。
雨は人の解釈、主観。
傘は解釈に対する行動、対策。

「空-雨-傘」やロジックツリーなどのフレームワーク思考で、限られた情報から推論して一つの仮説を作る。
仮説があるからこそ自信を持って実行できる。

実行した結果を仮説から導き出される結果と比較して評価する。
それが検証プロセスになる。
その評価によって、仮説を更に修正して強化していく。

いわゆるPDCAサイクルにおけるCheckとAction。

この手法はアジャイル開発に似ている気がする。
アジャイル開発では、イテレーション又はスプリントと言う定期的な期間の中で、実現すべき要件をシステム化していく。

要件であるストーリーは、システムの観点から眺めれば曖昧であり、実装前にいくらきちんと設計しても、システムとして動作しなければ分からない所もある。
また、ストーリー通りに作ったとしても、顧客が受入テストで動かしてみたら、障害があるだけでなく、些細な機能を変更したい、などの改善要望も出てくるだろう。

開発者の戦略としては、与えられた要件から論理的整合性に矛盾なく動作するシステムをまずは作り、早くリリースしていく。
そして、顧客のフィードバックを受けて、仕様変更を受け入れる余力を保持できるように、設計も実装も開発チームの体制もあらかじめ作っておく。

与えられた要件のうち、一部は間違っていたり、あるいは、開発者が要件をきちんと認識できていなかった部分もあるかもしれない。
でも、間違った認識に基づいたとしても、ロジカルに設計して実装できたならば、後から修復は可能だと思う。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」でも、下記の一節がある。

意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても、変わらずしっかりしているはずです。

つまり、意思決定のプロセスが正しく進んでいるならば、限られた情報で誤った方向に進んだとしても、検証プロセスを速める事によって、正しい方向へ軌道修正できる能力がある。

アジャイル開発へ仮説検証プロセスを意識的に取り入れたならば、現場リーダーは自信を持って意思決定できるのではないだろうか？