今回はOODA（ウーダ）について！
PDCAは行動サイクルの手法として、よく使われているので、すでにご存じの方が多いと思います。
最近は、PDCAに近い言葉で「OODAループ」なんていう言葉も、ちょいちょい出てくるようになったのですが、皆様は聞いた事ありますでしょうか？
私思うんですけど、またメディアに影響されて「今はOODAだ！」なんて人、増えそうな気がするんです・・。
こういう言葉でマウントとってくる上司も、もしかしたら現れるかもしれません。
なので、ご存じない方は、こんな事態に備え、この機会に覚えておきましょう！
OODAとは？
ざっくり言うと、OODAは、変化する状況や情報を察知し、自分の考え方や行動を変化に合わせて、成果や行動を導きだすという方法。
現場がすばやく作戦を立てて動くためであったり、変化の多い時代に対応する手段として知られています。
前に別な記事で「今はVUCAの時代で、変化が速くて昔に比べてビジネスが難しい」
なんて事を書かせていただきましたが、OODAは、このVUCA時代の対策になるとも言われています。
※この話ともつながりますので、よろしければこちらも読んでみて下さい！
PDCAとどう違うの？
では、同じ行動サイクルでも、PDCAとはどう違うんでしょうか？
行動サイクルを回すという意味では、同じですが、実は似て非なるモノで、そもそも目的が違うのです。
例えばPDCAはこんな感じ
PDCAのパターンをざっくりと解説すると。
PDCAはまず計画（Plan）して実施(Do）します。そして実行した結果を評価（Check）します。
そして、評価（Check）した結果をもとに、どう改善（Action）するべきかを考え、この情報をもとにまた計画（Plan）をする。
より良くしていくためには、改善が必要だし、いつまでも同じ方法は通用しないので、PDCAというサイクルを繰り返すんです。
それに対して、OODAはどんな感じなのでしょう？
OODAはこんな感じです
OODAの頭文字をとると。
Observe（観察）→ Orient（状況判断、方向づけ）→ Decide（意思決定）→ Act（行動）
承認フェーズを無くし、現場の判断だけでこれを素早く繰り返すという方法です。
次は、例を書きつつ、OODAのフェーズを１つずつお話します。
Observe（観察）
OODAは観察から入るのが基本で、まずは外部の情報を集めるところから始めます。
ポイントは、現在起きている些細な情報や市場動向など素早くチェックしたり、とにかく「生の情報」をたくさん集める事。
OODAは、PDCAのように「計画」から始めるのではなく、調査から始めるのが特徴です。
（例）
お問い合わせを集計した結果、こんなお問い合わせがかなり多かった。
「〇〇の機能を使ってみたけどできません。どうやってやればいいですか？」
Orient（状況判断、方向づけ）
Observe（観察）で集めた情報を、自分の知見と組み合わせ、仮説を立てます。
集めた情報から、今どんな事が起きていて、どんな事が考えられるかを、全力で考え分析しています。
（例）
お問い合わせの多い操作を実際にやってみた
誤解をしやすい操作手順になっていたり、UIが解りずらかった。
お問い合わせが多いのはこれが原因であり、ユーザーにストレスを与えている？（仮説）
Decide（意思決定）
次はOrient（状況判断）で定義した仮説から、どんな作業をすれば解決できるかを具体化してタスクにしていきます。
ただ出来るようにするのではなく、別な場所に問題がでないか？などの影響や、どんな手段があるかを、現場で議論する事が必要です。
（例）
議論した結果、UIを改善し、さらに操作画面に説明書きを入れるのが一番良い方法に思えた。
Act（行動）
Decide（意思決定）で決まった、内容を実際行動に移します。ポイントは鮮度が落ちないようスピード感をもって対応する事です。
大事なのは、1ループ毎の教訓は生かしつつ、OODAをずっと繰り返す事！
（例）
１か月以内にUIを〇〇のように改善し、操作画面に説明書きを追加。
実装後、Observe（観察）に戻り、このお問い合わせが減るか観察を続ける。
OODAから生まれるメリット
ちなみにOODAを実施する事で、私はこんなメリットが生まれると思います。
- 現場の判断で臨機応変に対応できる
- チームの問題解決能力が向上する
- 意思決定と行動が速くなる
- チームでの成果が出やすい
意思決定の速さこそが、変化が多い今の時代（VUCAの時代）で生き抜くための攻略法かもしれません。
現場の判断で動けるようにする事で、１人１人が自律的に動けるようになり、自信にもつながるので、メンバーも成長します。
何よりも、自分の判断で自由にできる事で、仕事が楽しくなりモチベーションがあがれば、成果が出やすくなります。
逆にOODAの難しそうなとこ
私は逆にこんな状態だと、破綻しちゃうんじゃないかな？って思います。
- 指示待ちの人が多いチーム
- 全組織が実施したらバラバラになりそう
- PCDAに比べて「改善」という点が弱い
1つ目の懸念点
この方法は、常に現場が工夫する事で初めて成り立つので、誰も自分の判断で動かない・・みたいな思考停止が起きると破綻します。
誰かに言われてやるのではなく、より責任感・専門性をもって臨む必要があるので、向いてない人も当然いると思います。
２つ目の懸念点
OODAをもし、営業と技術が別々にやった場合、目線の違いからバラバラになるリスクがある気がします。
現場に任せるとは言え、骨子や共通認識は、ズレないようにする工夫が必要なのではないでしょうか。
３つ目の懸念点
PDCAは、Do（実行）の後に「Change（評価）」と「Action（改善）」を必ずしますが、OODAは仮説→意思決定後、すぐに実行します。
従って、PDCAに比べてOODAは、チェックがかなり甘くなるので、品質管理をしたいならPDCAサイクルの方が有効です。
こうやって考えてみると、OODAはメンバーの能力に依存する要素が多いのかもしれませんね。
最後に
ここ最近、VUCAとかアジャイル開発とかスクラムの記事を書いてて、思った事があります。
※ここ最近の記事も良かったら！
この話に共通して言える事は、チーム１人１人が、高い専門性を発揮し、自分の判断でスピード感をもって進めなければならない時代になっているかもしれない・・という事。
少なくとも私のいるIT業界は、上に怒られながら、言われた事だけを忠実に頑張る人よりも、自分の判断で試行錯誤を重ね、自由にやれてる人の方が成果を出せている気がします。
もしかしたら、上に立つ人は現場を支援し、働きやすい環境を作り、トラブルが起きたときはメンバーを守る・・みたいな支援の役割に少しづつ変わってきてるかもしれませんね。
ちなみに、noteで「よっしーTECH」の下書き版公開中です！ こちらもよろしくお願いします！
