(出典：Wikipediaより)
「PDCA知ってる？」、「PDCAやったことある？」ってよく聞かれると思うけど「OODA知ってる？」って聞かれる事はあまりないんじゃないかな〜と思います。
が、手段としてOODAループってとても有効だから知らない人はぜひ、この記事読んでOODAループを知ってらいたい。
OODAとは？
以下の４つのプロセスをループし、意思決定して動く事です。
・観察（Observe）
・状況判断（Orient）
・意思決定（Decide）
・実行（Act）
観察（Observe）
状況の観察で改善する事、したい事を観察します。
観察とは見て観察するだけでなく、データを収集する事も含まれます。
できれば事前バイアスがかからないよう生のデータを収集することが大切です。
状況判断（Orient）
観察結果、収集したデータから仮説を立てます。
仮説を立てるのが難しい場合もありますが、無理矢理でもいいので仮説を立ててください。
意思決定（Decide）
立てた仮説を元に、どのように実行していくか検討します。
収集したデータ、仮説からいくつか実行方法を考え、一番効果的なものを選択するのが良いでしょう。
実行（Act）
意思決定（Decide）で導き出した一番効果的と思われる方法を実行します。
PDCAとの違い
大きな違いは、やる事が分かっているか分かってないかです。
PDCAはやることが分かっているのでPlan（計画）を立てることができますがOODAの場合は、やる事が分かってないので観察（Observe）、状況判断（Orient）のやる事を導き出すプロセスがあります。
そもそもPDCAとOODAはどちらが良いかというのもなく、それぞれ使われるケースが異なるのです。
「方向性の決まってるソフトウェアプロダクト」や、「会社の知名度を上げるため広告を打つ」など明確な方向性が決まってる場合は、PDCAを選択し
「顧客満足度を上げたい」や、「ソフトウェアの品質を上げたい」などのゴールはあるが明確な方向性が決まってない場合は、OODAを選択します。
このようにPDCAとOODAは使われるケースが全然違うんです。
だからPDCAとOODAを比較する事はなく、それぞれにマッチするケースでPDCAかOODAを選択すれば良いのです。
OODAループを使った例
実際に私が関わったプロジェクトを例にします。
【ゴール】
開発効率を上げたい
【観察（Observe）】
どこに開発のボトルネックがあるか観察しました。
観察内容としては月あたりの
・開発チケット数
・予定通りに終わったチケット数
・予定通りに終わらなかったチケット数
・リリースしたがバグになった件数
を観察する事とし、チケットの件数はRedmineから、予定通りに終わらない、バグになった件数は日々のやり取りメールから集計しました。
【状況判断（Orient）】
集計したデータを元に以下の判断をしました。
・開発チケット数が開発メンバーに対して多いか少ないかは判断が難しい
・予定通りに終わらないチケットがそこそこある印象
・２週間に１回リリースしてるが５、６件リリースして１件のバグが発生する確率が２回に１回くらいある。（ちょっと多いかな）
・開発プロセスを確認したら、製造者とテスト担当者が同じでソースコードレビューも忙しさを理由に簡単にすませてる事があった。
【意思決定（Decide）】
状況を見た結果、開発メンバーに対して現在の開発ペースが速いか遅いかは判断が難しく、バグを減らして、バグに対応する時間を開発に使うのがいいんじゃないかという判断になりました。
バグを減らすために考えたことは
「テスト、レビューをしっかりして開発プロセス正す事」
テスト、レビューをしっかりすると今までよりも時間はかかるがバグが無くなれば結果的に時間を節約できると考えました。
そこで、正しく開発できるプロセスを考え、そのプロセスを開発リーダーにレビューしてもらい実行できるレベルまでプロセスを作り上げた。
【Act（実行）】
あとは、正しい開発プロセスを適用して開発してもらった。
このような施策はすぐに効果が出るわけではなく長い目で見なければいけない。
しかも、ここで終わりではなく、プロセスを適用した結果を観察し次のOODAループでどんどん改善していく事が重要です。
OODAループがチカラを発揮するケース
「開発効率を上げたい」、「品質を上げたい」などゴールはあるが計画（Plan）が無い場合に大きなチカラを発揮します。
計画（Plan）が無いのに無理やりPDCAを適用すれば間違った計画・行動になってしまい効果が出るまで時間がかかってしまいます。
なので計画がない場合は、OODAを適用し何回もループさせて素早くゴールにたどり着きましょう！！
コメント