PDCAとOODAの概要

PDCAは皆さんご存知だと思いますが、

• Plan - 計画
• Do - 実行
• Check - チェック
• Action - 改善

この４つの頭文字からとられた行動で、
PDCAサイクルと呼ばれ、このサイクルを回してどんどん良くしていくことです。

OODAは聞いたことがあるでしょうか？

• Observe - 監視
• Orient - 情勢判断
• Decide - 意思決定
• Act - 行動

この４つの頭文字から取られたもので
OODAループと呼ばれ実行される活動のことです。

戦争の戦略の中から生まれ、司令軍と前線の小隊のやりとりをPDCAでやっていては計画を立てている間に小隊がやられてしまう。命令が下されるまで身動きが取れないということからスピードを重視し、最大限のスピードで能動的に動く活動を定義したものです。

PDCAとOODAの使い方

OODAの本の煽りなどには、「これからはPDCAではなくOODAだ！」みたいに書いているものがありますが、実はそんなことはないと考えています。

使い分けが重要だと考えています。
PDCAは計画と改善に重点が置かれていると思います。
初めてやる作業や活動のときには、よく見て実行しても場当たり的な行動になりがちです。
それは判断するための十分な知識が不足しているからだと考えられます。

そこで必要なのは計画であり、計画する際には十分な情報収集を行い、どのように行動するべきかの実行計画を練ります。
どんなに素早く行動しても、次に活かせない行動はコストが高いです。
最初の段階では情報収集を十分にして、行動コストを抑えることに重点を置きます。

行動した結果、当然新しい知識を得るので、次の行動の情報として最大限また情報収集を行い計画をします。
正しく計画が行えていれば、しばらくすると、この計画と改善の観点がチームの全員に行き渡ります。

その知識を持って、各人が状況に応じて判断し、決断し、行動して行けるようになるのです。
そして行動した結果の情報は今までのPDCAサイクルで得た、改善活動がOODAに組み込まれていき、チーム全体が改善活動を自然のサイクルとして活動できるようになることが理想形だと考えています。

アジャイルに活かす

アジャイルも沢山のサイクルがあります。

• スプリント計画 - スプリント - スプリントレビュー - レトロスペクティブ
• 毎日の開発サイクルでの デイリースクラム(朝会、夕会)
• チームが自由に振り返るKPT
• など

最初はしっかりと計画して、実行し、レビューを行い、振り返ります。
始めたばかりのときはぎこちなく、うまくいかない所をレビューでなんども改善しながら進めるでしょう。
しかし、チームがそのサイクルに慣れて、ごく自然に出来るようになったら、次のステップです。各人に作業するタイミングの判断を渡せるものがあるでしょう。
なれてきたチームであればスプリントのプランニングポーカーなどはGithubのestimateを各人が設定し、朝会、夕会で確認をお願いし、chatworkやslackなどのチャットツールで解決出来るようになるかもしれません。
どういう観点で、どういうものが何ポイントになるかはすでにチームの中でイメージ出来ています。細かなズレのみをチャットツールで解決することで、全員の大きな時間を使っていたものが半分にできるかもしれません。

スプリントレビューのデモなども、最初は毎回対面でやるべきです。
疑問点、どんな観点でアプリケーションを見るべきか、クライアントはどんな疑問を持っているか、それらはクライアントも開発チームも双方に対して無知だからです。
しかし、マネージャやクライアントが慣れてきたならば、オンラインでデプロイして、更新項目と動作フローのみwikiやqiita:teamで共有し、動かした結果のフィードバックもチャットでもらって打ち合わせる。と言う事が出来るかもしれません。

もちろん、これらの切替のタイミングは非常に気をつける必要がありますし、開発の関係のススメ方やメンバの能力によっては、適さない手法かもしれません。

ただ、常にPDCAをするのではなく、すでに仕組みに慣れた段階で、各人を信じ、OODAを実行出来る仕組みに切り替えることで開発スピードを上げ、また違うことを改善するための時間を使えるようになるでしょう。

チーム活動を進化させること。これこそアジャイルの真髄では無いでしょうか。

終わりに

ぜひPDCAとOODAを使いこなし、アジャイル開発に活かしてみてください。