PDCAサイクルとOODAループ、新しいプロジェクトを進めるにあたってのその本質とは

昨今、PDCAサイクルに代わる目標達成のための手法として「OODAループ」が注目されています。

PDCAサイクルはビジネスパーソンにとっては常識ですが、その手法に従っているはずの多くのプロジェクトで、進捗管理や品質確保に悩みを抱えていることは今も昔も変わりません。

そのような悩みを打開することの期待感から流行の兆しを見せるOODAループですが、プロジェクトをうまく進めるために大切なのは、それぞれを適切なタイミングで正しく運用することではないでしょうか。

今回は、新しいプロジェクトを進めるにあたっての、その本質について説明します。

OODAループとは？

OODAループとは、さまざまなものごとに対する意思決定や行動を決めるときに利用できる考え方。

Observe（観察）→Orient（状況に対する適応・判断）→Decide（意思決定）→Act（行動）の4ステップの頭文字をとって、OODAループと呼ばれています。

(1) Observe（観察）

はじめに客観的な情報を収集します。このステップでは担当者の考えなどは極力排除し、変化する情勢の生の情報を獲得することに努め、またステークホルダーによる意思決定の材料となるよう記録を残します。

歴史ドラマなどで、次のようなシーンを見たことはありませんか？　作戦会議をしている戦国武将たちのもとへ「○○軍が××に進行中！」と伝達が入り、その場に広げられた地図に○○軍に見立てた駒を置く、というシーンです。

判断をする前に情勢を整理し、共有するステップがObserve（観察）になります。

(2) Orient（状況に対する適応・判断）

Observe（観察）によって得た生の情報から、分析やこれまでの経験を通して、現在の情勢を整理します。

上記の戦国武将の例を続けると、このステップでは伝達された情報を元に、自軍が優勢なのか劣勢なのかといった判断や、敵軍がどのような意図をもって動いているか仮説を立てます。

(3) Decide（意思決定）

Orient（状況に対する適応・判断）によって得た情勢の仮説に基づき、論理的な意思決定を行います。言い換えると、具体的にどのような行動を取るべきかといった方針の策定と、複数の案がある場合にはその選択です。

(4) Act（行動）

Decide（意思決定）によって決定された方針に従って実行、もしくは仮説が正しいかどうかの検証を行います。

OODAループでは4つの「ループ」が最重要

OODAループは、Observe（観察）から始まって、最終的にはObserve（観察）のフェーズに戻ってきます。

Observeで客観的な情報を収集し、Orientで現在の状況を具体的に分析する。そして、Decideで明確に意思決定を行い、その結果をActで検証する。そして得られた結果を元に、新たな情報を収集する（Observe）へと進む。

このようにOODAループでは、4つのフェーズをループすることが最も重要なのです。短いスパンで4つのフェーズをループすることで、思考を最速でブラシュアップするのがOODAループの真意です。

OODAループとPDCAサイクルの違い

PDCAサイクルは、生産・品質管理などの継続的な改善方法として作られたものであるのに対して、OODAループは軍事行動に関するところから、アメリカ空軍のジョン・ボイド氏によって提唱されたものです。

OODAループは、刻一刻と変化する情勢の中で迅速性と柔軟性を備えた意思決定プロセスと評価されており、VUCA時代にマッチした考え方として注目されています。

ちなみに、PDCAサイクルは、Plan（計画）→ Do（行動）→ Check（評価）→ Act（改善）の 4段階を繰り返すことによって、業務を継続的に改善する考え方・方法です。

>>OODAループ×タスク管理ツールで生産性向上を図ろう。タスク管理ツール「TeamHack」とは？

OODAループがPDCAサイクルより優れている点

PDCAサイクルではPlan（計画）が特に重視されますが、この特徴のために「想定外のことに弱い」とされています。計画ありきといえば、どうしてもネガティブな印象を与えます。不確実で変化の早い時代に計画ありきとは何事かと、拒否反応を示す人もいるのではないでしょうか。

実際、システム開発ではPlan（計画）に多くの時間を割くことになりますし、計画といえばボリュームたっぷりのWBS（ガントチャートで引かれたスケジュールのことを、日本ではなぜかWBSと呼ぶ）をイメージする人も多いでしょう。もしくは過剰なマイクロマネジメントを上司からPlan（計画）と称して受けた人もいるかと思います。

PDCAサイクルが生まれたのは、必要最低限な計画さえできていなかったという反省がもとになっていると聞きます。想定外のことが起こりにくい生産工場などにおいて生産計画を行い、継続してサイクルを回すことで品質を向上させるといった手法は、一定の効果があったものと考えられます。

他方で、たとえば新しいWebサービスを生み出そうとしている場面で、綿密な計画よりもサービスを迅速に立ち上げて検証することを優先すべきとの主張には、私も賛成です。

たとえ話：新しいWebサービスの立ち上げ

OODAループとPDCAサイクルを具体的に理解するために、一つのたとえ話で考えてみたいと思います。

世の中にまだない、新しいWebサービスの開発を進めているとします。
その会社はベンチャーで、従業員は社長を含めて５人程度です。事業計画を立て、資金調達をしてきた社長と、Webサービスを作るためにデザイナーとエンジニアがいます。

デザイナーとエンジニアの仕事ぶりはどうでしょうか。

• 彼ら／彼女らは社長の語る夢を素早く形にして、動くWebサービスを作り上げる。
• 彼ら／彼女らはシステムを動かしながら社長に説明する。
• 社長は動くものを見て要望を彼ら／彼女らに伝える。
• 彼ら／彼女らはITに疎い社長の要望を正しくくみ取り、Webサービスに反映するだろう。

このような場合、デザイナーとエンジニアをPDCAサイクルで管理することは、おそらく難しいのではないでしょうか。ポイントは、デザイナーとエンジニア自身が「要望の引き出し」を行っているという点です。

「要望の引き出し」に、自分たちが作成した成果物を利用しています。計画された生産物の確認ではなく、創造されたものから要望を引き出しているのです。

しかし私の経験上、要望（システム要件）が揃っていないなかで動けるデザイナーやエンジニアはほとんどいません。

デザイナーやエンジニア自身がITに疎い人間から要望を引き出し、システム要件に落とし込まなければならないうえ、ITに疎い人間に対して専門用語を使わずに説明するスキルも要求されます。説明の際には、システムの挙動の説明ではなく、利用者に対する提供価値を語ることができなければなりません。

さらに、システムは常に動くものである必要があります。ロジックがほぼ書き上がっているが動かないシステムよりも、動かすことができるが中身のロジックがスカスカなほうが、価値あるものだと理解していなければいけません。

「要件がコロコロ変わって困る！」などという言葉を、たとえ話で出てきたデザイナーやエンジニアたちは絶対にいません。何しろ、作られたシステムによって要件が決まると理解しているのですから、コロコロ変わって当然くらいの心持ちでなければ務まりません。

OODAループとPDCAサイクルのハイブリット運用

たとえ話ではPDCAサイクルの適用は難しく、おそらくOODAループを適用することで、機動力のあるプロジェクト推進が可能になると思います。

しかしながらOODAループをWebサービス開発のプロジェクト全体に適用することは、強力なリーダーシップのもとで経験豊富なデザイナーやエンジニアが揃っていなければできないでしょう。

新しいプロジェクトを進めるにあたって、私のオススメは「OODAループとPDCAサイクルのハイブリッド運用」です！

ハイブリッド運用では、OODAループとPDCAサイクルを使い分けていくことになります。適用するか否かの判断は、勝利条件／敗北条件における制約や前提条件に対する取り組みの違いで行いましょう。

OODAループの使いどころ

• 勝利条件：制約や前提条件を変更すること。
• 敗北条件：制約や前提条件を変更するための手立てが無くなること。

PDCAサイクルの使いどころ

• 勝利条件：制約や前提条件のもとで、最高のパフォーマンスを出すこと。
• 敗北条件：制約や前提条件のもとで、一定閾値以下のパフォーマンスになること。

たとえば軍事行動において、戦争が起こっているという前提条件があり、最終的な勝利条件とは戦争が終わることです。また、戦争前にあった制約が変更され、自分たちに有利な状態になることが勝利条件となります。翻って敗北条件とはすなわち、制約や前提条件を変更することができなくなる状態、たとえば戦力の消滅といったことが考えられます。

戦争前にあった制約や戦争が起こっているという事実を変えることを目的とせずに、最高のパフォーマンスを出しても意味がないことは明らかですから、PDCAサイクルよりもOODAループのほうが適しています。

システム開発においては、あるアプリケーションソフトはインストール形式が主流であるという状況のもとでクラウドサービスを主流にするといったプロジェクトや、現金売買が常識という状況のもとでスマートフォンアプリによって売買を完結させる時代にするといったプロジェクトにおける「システム要件の洗い出し」では、OODAループが適しているのではないかと思います。

上記のようなプロジェクトにおいてもWebページのUIデザインやプログラミング実装が必要です。そのような「いったん決定したシステム要件を形にする工程」においては、システム要件という制約や前提条件を変えることではなく、次のシステム要件の洗い出しステップのためのインプットとなる、動く成果物の迅速なデザイン・開発が求められます。制約や前提条件のもとで最高のパフォーマンスを出すには、OODAループよりもPDCAサイクルのほうが適しています。

アジャイル開発では、チームのコミュニケーションを重視したスクラムという手法があります。スクラムでは小さなPDCAサイクルを素早く繰り返すことで、システム開発に推進力をもたせます。スクラムにおいても、Plan（計画）は重要な要素です。スプリント（サイクルの一回転）の振り返りでは、計画に対してどの程度パフォーマンスを発揮できたかを測りますが、振り返りを行うためには納得感のある計画が必要です。

PDCAサイクルによって完成した成果物は、OODAループを回すために最も重要なインプットとなります。

>>チームでの業務コミュニケーションのしやすさに特化したタスク管理ツールとは？

まとめ

私はこれまで、多くのプロジェクトで「OODAループのAct（行動）でPDCAサイクルを回した」ことで、停滞していたプロジェクトに爆発的な推進力を与えることに成功してきました。
もし、プロジェクト推進がうまくいっていないといった課題感があれば、OODAループとPDCAサイクルのハイブリッド運用を試してみてください。