なぜ、アジャイルに仮説検証を含めるのか
書籍「正しいものを正しくつくる」で、仮説検証型アジャイル開発について言語化し、整理している。
なぜ、仮説検証を強調し、アジャイル開発と連動したスタイルを提案するに至ったのか。あらためて、整理をしてみる。観点として「解くべき問題の設定」と「解決手段の構築」の2つを用いる。
さっそく、結論はこのとおり。
解くべき問題が分かっているか？ 解決手段は決められるのか？の回答に基づき、方法を選択する。解くべき問題は分かっているし、解決手段も考えたらあらかじめ決められる場合は「ウォーターフォール」を選ぶ。
あくまで問題も解決手段も事前に決められるならば、という前提。決められるならば、その通りにやったほうが最短距離でゴールにたどり着けるだろうという判断になる。くどいようだが、決められるならばね。
次の型は、問題設定はプロダクトオーナー（PO）が行い、構築するべき対象は優先判断に基づき順序付けるというもの。いわゆる「アジャイル開発」だが、今回の例示では前提として「POは解くべき問題を分かっている」を置いている。
ゆえに、「プロダクトバックログ（PBL）を積み上げるのはPOの役割」というメンタリティの上に立っている。「正しいものを正しくつくる」を書いたときは、この手の開発をよく見た。このメンタリティに至っている場合、POと開発の間には役割上の "境界" があり、たいてい分断している。
PBLという名の機能一覧が整っていれば、開発を行う（さもなくば、開発が始まることはない）。結局、機能一覧という「記述」の投げ合いになるので認識の不一致も頻出する。実は、メンタリティがⅠ型から変わっていないため、ろくに検査適応が行われず、スプリントレビューは進捗会議でしかない。
実際のところ、POは解くべき問題を分かっているのか？ 暗黙的にブラックボックスとしている「左側の世界」に光をあてて、解像度を上げなければ全体として望むような状態にはならないのではないか。POと開発の間に境界を設けず、両者がチームとして協力して、問題設定と解決手段の構築にあたる世界に向かいたい。「仮説検証型アジャイル開発」は、その思いから端を発している。
この考えの源流には、昔なつかし「リーン・スタートアップ」がある。10年以上も前に平鍋さんが紹介したエリック・リースのスライドがあり、時々ここに立ち返っている（今回のnoteもそう）。
リーン・スタートアップから10数年。そもそも、仮説検証とアジャイルが分け隔てられることなく、"アジャイル" に仮説検証が包含される世界は実は近いと感じている。DXや組織変革の文脈で語る "アジャイル" には、仮説検証による探索と適応を自ずと含めていることが多い（現代組織の多くは探索適応欠乏症にある）。
アジャイルとは、探索することだ。Ⅰ型やⅡ型を経て、今ここにいるものとしては、そう言い放つこと自体に隔世の感がある。もちろん、ポジティブに捉えている。きっと、探索と適応が「これからの仕事の方法」として当たり前になる。
この記事が気に入ったらサポートをしてみませんか？