nishida 
Weekly Red Journeyは、隔週発刊のトピックレターです。これまでのレッドジャーニーの発信の中から、特定のテーマに基づいてトピックを集め、紹介します。今回のテーマは「仮説検証型アジャイル開発」です。
仮説検証型アジャイル開発とは何か？
新規事業開発やDX（デジタル・トランスフォーメーション）にともなうプロダクト開発に乗り出そうとするとき、重要なのは新しいプロダクトの価値をはかるための「仮説」です。一方、現場の声に耳を傾けてみると、こんな声が聞こえてきます。
- 主要事業に手がいっぱいで、新規事業の仮説づくりに時間がさけていない
- 上司から一方的に与えられた仮説に取り組んでいるが、根拠がよく理解できないままである
- 基幹システムづくりに自信はあるが、ユーザーとのコミュニケーションのための仮説づくりには自信がない
- アイデアに対する周囲の反応がいいのでとりあえず事業にしようと仮説を立てた
このようなシチュエーションの中で生まれた事業仮説は、
- データの裏付けに欠ける仮説
- 十分な調査・検証を経ていない仮説
- 自身に都合のいいデータばかりで固めた仮説
- 関係システムとの連携が考慮されていない実現可能性の低い仮説
になってしまっている場合が多く、そのまま開発に入ってしまっては致命的な失敗を招くおそれがあります。
新規事業開発やDXにともなうプロダクト開発には唯一の正解はなく、不確実性が必ず伴います。この不確実性の暗闇の中で、私たちが拠りどころとするのが仮説検証でありアジャイル開発という手法です。
では、どのように仮説を立て開発を進めればいいのでしょうか。求められるのは次の2点です。
- 「採⽤の失敗」を抑えながらプロダクト開発をおこなう⼿段
- 小さな失敗をもとに仮説を検証しながら少しずつ進める柔軟な開発
失敗とは「正しくないことの学び」に他なりません。
失敗をなくすことはできませんが、その失敗を学びとして活用することはできますし、また活用できなければプロジェクトの長期的成功は望むことができません。
一方で、失敗時の負荷が高すぎる、リスキーな意思決定はなんとしても防ぎたいところです。
わたしたちレッドジャーニーは、事業づくりの礎となる仮説検証と、これを実際のプロダクト制作に反映する開発手法であるアジャイル開発を組み合わせたものづくりを実践し、これを仮説検証型アジャイル開発と名付け、長年取り組んできました。
▼仮説検証型アジャイル開発について、詳しくは特設ページをご覧ください。
「正しいものを正しくつくる」ために
仮説検証とアジャイル開発、それぞれを得意とする企業は数ありますが、これらを一貫して実施できるチームはそう多くはありません。レッドジャーニー代表の市谷は、「正しいものを正しくつくる」ためには仮説検証と開発体制が密に連携していることが理想的だと考え、この仮説検証型アジャイル開発を考案、提唱してきました。
仮説検証型アジャイル開発の詳細について、市谷が初めて説明したのは2016年のことです。「正しくつくる」ために用いられていたソフトウェア開発の手法であるアジャイル開発だけでは、「正しいものを作ろうとしているのか？」という問いが不在であり、「間違ったものを正しくつくる」ことになりかねないと指摘。誰も正解を持ちえない、圧倒的な不確実性の闇の中で「確からしさ」を探し求めるためには、仮説検証アプローチが必要であると説きました。そうして行き着いたのが、仮説検証アプローチとアジャイル開発を連動させた仮説検証型アジャイル開発です。
正しいものを正しくつくる ～プロダクトをつくるとはどういうことなのか～
仮説検証型アジャイル開発についてより詳しく知りたい方は、ぜひ提唱者である市谷による著書『正しいものを正しくつくる』を手に取ってみてください。「プロダクトづくりにともなう不確実性を、いかに乗り越えるか?」 というアジャイルな探索的プロセスを精緻に言語化しています。問いを立て、仮説を立て、チームととともに越境しながら前進していくための実践の手引きとなっています。
仮説検証型アジャイル開発で組織はどう変わったのか
〜クラウドサイン（弁護士ドットコム株式会社）の事例～
実際に仮説検証型アジャイル開発に取り組む企業の現場から、当事者の声をご紹介します。見渡す限り不確実性だらけの状況下で、急速なプロダクト開発に挑んだクラウドサイン（弁護士ドットコム株式会社）の事例です。レッドジャーニーは仮説検証型アジャイル開発の導入から伴走支援を行いました。
価値が不確実であるということが、まず一つ大きな課題です。「提供するものに本当に価値があるのか？」が分からない状態から始めなくてはならないということが起点となり、仮説検証型アジャイル開発を採用するにあたって、今回ご支援いただいた次第です。
不確実性だらけの状況下で挑む急速なプロダクト開発。仮説検証型アジャイル開発で組織はどう変わったのか ―クラウドサイン（弁護士ドットコム株式会社）（前編） – Red Journey
価値の不確実性ということでは、MVP（Minimum Viable Product。お客様に価値を提供できる最小限のプロダクト）の特定の仕方に非常に苦戦してきました。つまり、ある機能におけるMVPの定義が異なるために組織内での合意形成が得られにくいことが課題になっていました。
原因は、そもそもの目的が明確になっていなかったからだと思います。検討するプロセスにおいて、必要な（不足している）情報はそれぞれ違うんですよね。そこを整えるために仮説検証を学び、各自が必要な情報をインプットすることができるようになったことで、格段に合意が得られやすくなりました。
不確実性だらけの状況下で挑む急速なプロダクト開発。仮説検証型アジャイル開発で組織はどう変わったのか ―クラウドサイン（弁護士ドットコム株式会社）（前編） – Red Journey
僕は、クラウドサインの開発は挑戦だと思っています。体得したメソッドに安住することなく、改良していきたいです。要求定義フェーズのためのメソッドとして仮説検証を導入しましたが、まだまだスピードに関しては改良の余地がありますし、お客様に受け入れられる度合いも未知数です。だからこそ、ここからが本当の挑戦なのかなと。仮説検証のスピードアップをして、スピーディーにお客様に価値を提供していくことに挑戦していきたいです。
不確実性だらけの状況下で挑む急速なプロダクト開発。仮説検証型アジャイル開発で組織はどう変わったのか ―クラウドサイン（弁護士ドットコム株式会社）（後編） – Red Journey
「発明者側」の組織になることを目指します。やはり、新しい契約の形を我々自身で発明し、マーケットに対して発見を提供していくことが大事だと考えます。価値の定義づけや、合意、意思決定の過程が言語化され定義されているかどうか。それらが蓄積された組織になることが必要です。
不確実性だらけの状況下で挑む急速なプロダクト開発。仮説検証型アジャイル開発で組織はどう変わったのか ―クラウドサイン（弁護士ドットコム株式会社）（後編） – Red Journey
▼全文（前編）はこちらをご覧ください。
redjourney.jp▼全文（後編）はこちらをご覧ください。
仮説検証型アジャイル開発の基本を7週間で学ぶ
組織やチームで仮説検証とアジャイル開発を推進するための能力・スキルは、座学で身につくものではなく、経験を伴った学習が必要になります。一方で、プロジェクトを闇雲に進めるだけで習得できるものでもないため、途方に暮れる担当者の方に多く出会ってきました。新規事業開発や新たな価値を作る行為は、探索的であるがゆえに、時には失敗もつきものです。いきなり組織の重要課題を取り扱うことは大変難易度が高くハイリスクです。だからこそ、実践に入る前に、仮説検証のスキルを習得するべきです。
これまでのノウハウから、わたしたちが開発したのは全5回のワークショップを7週間という短い期間で臨むプログラムです。大企業からベンチャーまで幾度となく適用し、アップデートを重ねてきました。必要に応じて個社ごとのカスタマイズを加えることで、より実践的なスキルを習得できます。チームで仮説を立てて考え抜くことで、ポイントベース(事前につくるものを決めた一点突破型の進め方)ではなくセットベース(選択肢を広げて検証結果から絞っていく進め方)での取り組み方も身につきます。
レッドジャーニーへのお問い合わせ
多くの組織にとって、組織活動にアジャイルを適用していくという挑戦はまだこれからと言えます。組織アジャイル、アジャイル開発の適用や課題、お困りごとについて、お問い合わせはこちらからお寄せください。ともに考えていきましょう。
