![見出し画像](https://assets.st-note.com/production/uploads/images/46065317/rectangle_large_type_2_143cbb7f2ef6eb227ee0a31cc9f013f7.png?width=1200)
私がOODAループをあまり勧めない理由
2019年頃からOODAループというのを見聞きすることが増えました。いい考えだとは思うのですが、システム開発のコンテキストにおいては私はあまり勧める気になれないです。その話を書きます。
よく見かけるPDCAとの対比
OODAがでてくるときにPDCAと対比されるのを何度か見かけました。Plan - Do - Check - Act をフィードバックループとして捉えていくものです。ふるくはデミング博士であったり、日本の品質系のコミュニティ(学会)が関わっていたり、経営学や組織論ででてきたりと、いろんなところから使われるようになった概念かとおもいます。
PDCAは私の理解では予測をして、実験して、差分や発見を見直して、次のアクションにつなげていって、計画に反映していくというやりかたです。Wikipediaによると、CheckはStudyのほうがよかったよねっていう主張もあったということで、まぁ自分はそもそもStudy的な観念でとらえていたので、どっちでもいいかなという気持ちです。で、これを聞くとScrumに似ている感じがします。
OODAを説明するときに、既存の概念とどう違うのかを説明するために、「みなさんご存知のPDCAがありますよね。ですが、PDCAでは計画偏重になってしまうこともしばしばあります。そこで最近ではOODAという概念が着目されています。」のような表現のされかたです。こういった対比においては、PDCAは重いプロセスなので、OODAのようなもっと現場でのリアクティブで軽量な概念を取り入れるほうがいいという言われかたをしています。(そういうことが伝えたかったわけではない人達すみません。僕にはそう聞こえたという話です。)
OODAの説明
で、そこでOODAループはObserve - Orient - Decide - Act をフィードバックループとして捉えていくものです。軍隊でつくりあげられた概念と言われています。
OODAループはまず観察するところからはいることや、それぞれのステップは柔軟につながっているプロセスになっています。こういった非線形なプロセスがシステム開発の現場では重要であるという話をされていることがおおいかとおもいます。
どのステップからも最初のObserveにいくことですぐに次の判断にうつれるようにしていることは、最適解がわからなかったり、常に変わっていく状況では有効にはたらくでしょう。
このように常に情報が流通していくこともたしかにアジャイルであったり、Scrumの透明性をたかめる1つの概念として捉えることができそうです。
さて、OODA発祥の軍隊では
この記事が気に入ったらチップで応援してみませんか?