1. HOME
  2. テックブログ
  3. PDCAが通用しない局面に。環境変化に強いOODAループの紹介と実践

PDCAが通用しない局面に。環境変化に強いOODAループの紹介と実践

プロダクト開発本部という所属部署なのですが、なぜか開発以外にも色々やっている斉藤です。

そろそろ早い企業は新卒の方々の配属が始まったのではないでしょうか。
配属が決まると配属先の専門性が高い研修などが今後増えていくということで、テックブログという名ではありますが、ちょっとした考え方やコトの進め方の話を今回書いてみます。

PDCAサイクルの雑感

先日PDCAサイクルの話が出たブログ投稿がありました。

PDCAというキーワードは良く聞きますし色々な書籍も出ています。
プロダクト開発本部で取得しているISO/IEC 27001(情報セキュリティマネジメントシステム)の認証などもその考え方が取り込こまれていて、社内で触れることもあり、先日の投稿記事自体はPDCAサイクルに合致しやすい内容でPDCAサイクルが回れば少なからず成長(?)が見込める形の話とも思っています。

ただPDCAサイクルを回すことが悪いというわけでもないのですが、良く言われる欠点のうちの1つに「計画に従う前提」ということがあると思っています。

この「計画に従う前提」というコトは、計画を立てるためスタートまでに時間がかかったり、結果が出るまでの時間に加え、チェックする時間が必要になってしまいます。若干のロスが発生するだけであれば良いのですが、計画があまりに粉飾な状態になっていると、実行もさることながら、どこからチェックして良いのか判らなくなる場合もあります。

私の経験則として、PDCAサイクルは「実行結果から最初の計画が良い状態で推移したか・その計画が厳しかったか/簡単過ぎたかをチェックすること」で、次のアクションにつなげる…のではなく【アジャストするもの】と考えることで、PDCAが崩壊しづらく且つ継続できることが多いと思っています。

つまり、チェック+アジャストのタイミングだけは無理の無い計画を立て、チェック+アジャストを数回実行して習慣づけるということだけは死守すると、うまく回っていくと思います。

PDCAの最大の欠点

その上でPDCAの最大の欠点と思っているのは、計画倒れもしくは計画の甘さの結果から、「DとAだけになってしまう」とか「(内部監査とかがあるから)DとCだけになってしまう」ことだと考えています。

だからといって「その場で計画を立て直せば良い」とか「無計画に」言い出してしまうと、悪いスパイラルのPDCAになります。また、それだけなら良いのですが、最終的に結果だけ追い求めて振り返りもしない様になり「それでOK」という話からPDCAが崩壊していくことを度々目の当たりにしています。

なので「チェック+アジャストを数回実行して習慣づける」という経験則が生まれたということだと考えています。

別の考え方・進め方(本題)

前置きが長すぎるかもしれません…が続けます。ようやく本題なので…。

PDCAが回らないとか回せないとかはオペレーションの課題と言えるのでソコはPDCAを回し…という本末転倒になる以前に、PDCAの考え方が通用しない局面があります。

それは何らかのトラブルを含めた緊急事態の時です。特に悪いほうの緊急事態の時にPDCAを回している時点でどんどん悪い影響が広がっていく…ということは普通にあります。

前述のISO/IEC 27001の考え方は、そういう場合を想定した「情報セキュリティインシデント管理」や「事業継続マネジメント」を考えて対応しなさい…という話があり、これは予防措置に近く、環境の変化があると現実離れしかねませんし再計画しないといけなくなります。

が、世の中には環境変化に強い考え方があり、それが「OODAループ」と呼ばれるものです。今回はこれを紹介したいと思います。

OODAループとは

OODAループとは、観察する(observe)・確認する/方向づける(orient)・決定する(decide)・行動する(act)のプロセスの頭文字を取った意思決定の理論です。

元々はアメリカ空軍のジョン・ボイド大佐が提唱した、軍事行動の作戦や戦術における意思決定を対象とした理論でした。PDCAほど、その名前は広がっていない感じがありますが、ビジネスなどの分野にも導入されてきています。

見た目行動する部分までのプロセスが長いようですが、実際のところ元々の理論上、「緊急事態」や「想定外」が起きた後については非常に高速で強力なアクションが実行できます。

軍事行動の中ではそのような動きをしないと、敗北に直結するという、非常に生々しい意思決定の理論だとは思います。

具体的な例

さて、ここからは技術の話も盛り込まれていきます。

会社がWebサービスで収益を上げる事業形態の中、サーバ上でのトラブルやプログラムのバグは切りたくても絶対に切り離せませんし、周りのWebサービスの技術革新に触れた時に大幅なサービス内容の変更に迫られる場合があります。

特にこのような場合にはOODAループの圧倒的なスピード感が生かされると思っています。

一番簡単な緊急な環境の変化の例として、「サービス継続に影響を及ぼす異常な状況が発生」があげられます。その際のOODAループの手順はシンプルに・汎用的に書くとこのようになります。

OODAループの手順

①状況をチェックする・原因を探る
②一時的または恒久的な対応方法を検討する
③対応方法を決める
④対応する

ファブリカコミュニケーションズでは、実際のシチュエーションとしてはこのような形が、日々起こっていて緊急度や重要度に応じて実践されています。

バグ報告の例

①不具合発生の状況の報告を受け、運用担当・インフラ担当が現象・状況の把握をします。この時、時間がかかる場合は調査・把握できたところから随時状況を報告します。
②現象・状況に応じて、プログラムを直す・データを修正するなどの対応方法を探り、また作業時間を概算で見積ります。
③対応方法で「現在の最適解」と思われるものを決定します。この決定も緊急度や重要度に応じて、現場で即座に決定し次のステップに移る場合もあれば、決定後経営層の承認を得た上で次のステップに移る場合もあります。
④決定した方法で実行します。
⑤対応後の状況に問題がないか、改めて運用担当・インフラ担当が現象・状況の把握をします。(①に戻った格好です)
問題がなければ・復旧したなどがあればここで終わりですが、ダメな場合はまた対応方法を探ります(②を改めて実践することになり、ループが再開されることになります)

このような状況で当然うまくいかないこともありますが、それはプロセス上の問題点を追求し対策をすることで、状況把握に変化を起こすよう努力しています。

まとめ

PDCA以外にもこのようなプロセスの進め方があるという紹介をしてみました。

どちらかでなくてはいけないということはありませんし、PDCAの中にOODAを取り込むということは多々あるので、やはり適材適所ということであり、どちらも対応できるのが一番良いのだろうなぁ…と思いつつ、日々を過ごしています。

プロセスのきっかけとなる「観察をする」ということは様々な情報収集が前提となるので、サービスのアクセス状況だったり、基盤となる技術情報だったりの情報収集・把握もまた重要なものですが、なかなかうまくいきません。

この部分の課題を解決する方法は、さてどちらのプロセスを…という「鶏が先か卵が先か」的な悩みがまだまだ残っている…ということで、一旦この投稿を締めさせていただきます。

興味が出てきた方は巷に発売されている本を購入するのが良いかとは思います。

オススメの本はこちら。



この記事を書いた人

齋藤 直彦
プロダクト開発本部 IT管理統括部長兼CISO
齋藤 直彦

おすすめの記事