2021/2/12(金)のあじゃてくミニ#3（Agile Tech Mini #3）のカンファレンスで学んだことの備忘録です。
発表を聞いた上でのぼくの理解を記載しています。
登壇者・発表者の意見や主張ではないことご了承ください。
勉強会のトピックス（一部抜粋）
- 仮説検証型アジャイル開発のすすめ
- OODA（ウーダ）サイクルを活用する
- リーダー無き組織のPBL
- PBL教育（プロジェクト推進におけるアジャイルの役割）
仮説検証型アジャイル開発のすすめ
仮説検証型アジャイルとは、 仮説検証を繰り返してMVPの取りうる選択肢の幅を狭めていく、ということのようです。
仮説検証型アジャイル開発の図
※上記図は登壇者スライドの再現です。
- 縦矢印はプロダクトの取りうる幅が表現されています。
（MVP特定以降は幅が狭くなります）
- 図左の赤い3つの円が「仮説検証」
真ん中の縦矢印より右が「アジャイルサイクル」
一番右の縦矢印より右が「MVP価値検証（次のステップへ）」
アジャイルサイクルに入る前に仮説検証フェーズを経ることで、より精度の高いプロダクトが作れる、ということだと理解しました。
この仮説検証型アジャイル開発の利用方法は2つ考えられると思いました。
- MVP特定までを定義する（アジャイルサイクルとは別定義する）
- MVPの揺れを定義する
一つ目は、プロダクトのMVP特定をアジャイルサイクルに含めないで行うということかと理解しました。
登壇者の方は、PDCAではなく別の行動サイクルOODA（ウーダ）を高速で回すと仰っていたので、プロダクトMVP特定までを定義するために「仮説検証型」というスタイルを考えられたのではないかと推測します。
※OODAについては後述します。
スクラムでいうインセプションデッキからMVPの定義までを円滑に進めやすくなるのかなと思いました。
二つ目は、プロダクト事前検証におけるMVP定義を「幅」とすることで、MVP価値検証によってMVPの再定義が求められた場合でも、柔軟に対応できる線引きとするのではないかと考えました。
事前に幅広く検証することで、MVP価値が想定していたものでなかった時も、事前検証の中から二の手、三の手を打って、プロダクトを成長させるということと理解しました。
MVP価値がないと判断した時点で検証をしていては遅い、ということなのだと思います。
OODA（ウーダ）サイクルとは
回すのはPDCAサイクルではなくOODAサイクルが良いと登壇者の方はおっしゃっていました。
OODAは
- Observe（観察）
- Orient（仮説構築）
- Decide（意思決定）
- Action（実行）
というサイクルになっています。
PDCAサイクルと比較すると下記のような感じになります。
| OODAサイクル |
実施内容 |
PDCAサイクル |
実施内容 |
| Observe（観察） |
情報を集める |
Plan（計画） |
何を行うか意思決定を行う |
| Orient（仮説構築） |
仮説を検討する |
Do（実行） |
実行する |
| Decide（意思決定） |
仮説の採用・意思決定 |
Check（評価） |
実行結果の評価を行う |
| Action（実行） |
実行する |
Action（改善） |
評価に基づく改善 |
| Observe（観察） |
実行結果を観察し情報を集める |
Plan（計画） |
改善内容を計画に取り入れる |
| ・・ |
・・ |
・・ |
・・ |
比較してわかるように、OODAとPDCAは回す対象物がそもそも違うと思われます。
定型化が行える業務はPDCAで回した方が早いと思います。
一方、開始時点で定義が不十分で、未知の要素が多分にある場合はOODAで回したほうが試行錯誤を多く、精度高く行えると思います。
（定型化できる業務であっても、業務について深い理解や知識がない場合はOODAを無意識に回していると思います）
OODAの特徴は2つあると思っています。
- 情報収集から開始すること
- 意思決定がサイクルに組み込まれていること。
一つ目は、手持ちの情報が常に不完全であることが指摘されています。
現在わかっていることが次のサイクルでもそのまま通用するとは限らないという指摘だと思います。
MVPにおけるマーケットあるいはターゲットが変異している可能性があること、MVPの価値が顕在化していない、決まっていないから、情報収集を常に行うということだと理解しました。
PDCAと比較すると知識や行動が、次のサイクルでも必ず役に立つという前提になっているのと大きな違いだと思いました。
二つ目は、意思決定にサイクル実施者が関与していることです。
PDCAは実施する内容を決めるのはサイクル実施者ではない場合が多いと思います。
PDCAは何をやるかは決まっていて、どうやるかを工夫する仕組みだと思います。
OODAは何をやるかを考える仕組みだと思います。
そもそも何をやるかが決まっている・決められるプロジェクトの場合、アジャイル・スクラムで行う必要性が薄いのだと思います。
詳細に計画できるのであればウォーターフォールで開発しても十分効果が出るとおもうので。
後半は次の記事で紹介します。
以上です。
qoo10 
