OODA(ウーダ)ループをより早く回すための使い方

スポンサーリンク
ニュース、日記、その他

三回にわたってOODA(ウーダ)ループの話をしてきました。

一部のお客さんには「ブログにまとめたので読んでね!」で終わりです(笑

PDCAとOODAは組み合わせて使う!使い分けとセットでの使い方
最近、OODA(ウーダ)ループというのが出てきました。元々は軍隊で使われており、日本には2017年ごろから「PDCAは古い、OODAが良い!」みたいな話が出てきましたが…「OODA」って知ってる?PDCAの...
OODA(ウーダ)ループのメリット・デメリットと、PDCAと組み合わせの話
昨今話題のOODA(ウーダ)ループのメリット・デメリットの話です。PDCAと比較をされますが、組み合わせることでOODAループのデメリットが補われます。また、他人や他社のOODAループを止める方法についてもまとめております。

最後の記事は他より短め、OODA(ウーダ)ループの高速化についてです。

半自動化って言い方の方が正しいかもしれません。

PDCAや他のフレームワークより環境適応能力が高く、

なおかつスピードが魅力であるOODA(ウーダ)ループを

より高速で回しましょうという話です。

OODA(ウーダ)ループが話題になりそんなに経ってないのに…

って思うかもしれませんが、以前から説明しているように

「幼稚園人でもやってること」ですからね、人生の中に

高速化のコツなんていっぱい転がっています。

そのうちの4つをご紹介しておきます。

スポンサーリンク

1.すべて工程に時間・期間設定をする

まずはすべての工程で期間・時間を定めること。

OODA(ウーダ)ループに限らず当たり前の事なんですが、

「スピード重視」であることを前提とした期間設定が必要です。

特に「情報収集」は集め始めたらきりがありませんし、

前回お話ししたように「状況が変わる」とOODAは最初からです。

例えばですが、すべての工程をダラダラやっていると、

途中で状況が変化して、実際の行動に移せないということにもなりかねません。

ですから、全ての工程で時間をかけすぎないことが重要であり、

例えばDecide(意思決定)の後にAct(行動)するのであれば、

間をあけずにさっさと行動に移すことが重要です。

その上で「状況判断が間違ってた」とかわかったなら、

それを生かして次のOODA(ウーダ)ループへと向かいましょう。

2.情報収集方法・場所・内容を決める

お次は情報収集方法や場所、内容を決めるという事。

状況判断のために情報収集をするわけですが、

「関連する情報を集める」となればキリがなかったりします。

例えばですが、2年後に発売の軽自動車に関して情報収集をします。

「売れる軽自動車の企画を作る」ってことで、売れてる車や

将来の自動車に関する情報を集めたとしましょう。

最近は「ぶつからない車」が重要であるという記事があり、

ユーザーアンケートでも「プリクラッシュセーフティ」が重要と出た。

更にアンケートでは「ハイブリッド」への注目度が高いのもわかり、

ニーズで見ると「自動運転」を望んでいることがわかる。

一方で日本の人口は減る一方で、やがては1億人を切ってしまう…

しかも少子高齢化が進むのに、毎年免許の返納率は上がってる…

他にも「自動車」はぜいたく品になり、車だけがライバルではないとか、

あれこれ情報を集め出すとキリがありませんよね?

確かに自動運転は期待されてますが、まだ実用化されていません。

ハイブリッドやディーゼルも人気ですが、軽自動車はまだまだ、

あくまで高価格帯の車がメインの技術であります。

日本の少子高齢化は確かに進んでますし、人口が1憶以下にもなりますが…

そもそも「2年後発売の自動車」にその情報が必要でしょうか?

モデルサイクルが6-8年としたら、せいぜい10年先を読む程度。

人口が減って、1億人以下になるのは2050年(約30年後)以降だし…

要するに「いらない情報は捨てる」ってことがスピード化につながります。

注意したいのは「必要な情報」まで捨てないことです。

例えばここで「軽自動車の企画だから、コンパクトカーのアンケートは無駄」とか、

でも、コンパクトカーは予算的に軽自動車のライバルになりますよね。

同様に「普通車に自動ブレーキ全車搭載?うちは軽自動車!」ってのも違います。

これらはわかりやすい例ですが、自分のOODA(ウーダ)ループにて、

必要な情報まで「不要」と捨てないようにしたいものです。

これは何度か回すうちに「とるべき情報」がわかるでしょうし、

どこで収集するのが良いかもはっきりすると思われます。

3.意思決定をあらかじめ設定

意外と重要かつ時間がかかるのがDecide(判断)です。

集まった情報が分析された状態で渡され、さてどうするか?

ここで「情報が漏れてないかな?」と気にして情報を探せば、

正直新たな情報は見つかるでしょう。

それを見て「ああ、だめだ。情報収集不足だ!」といえば、

再びOODA(ウーダ)ループのやり直しになります。

スピードを重視すれば、必ず正確性が下がります。

ただ、収集可能な情報は限られますし状況は刻一刻と変化する中で、

「完璧な情報収集」と「ミスのない判断」はほぼ不可能です。

どちらかといえば「状況の変化に対応できる計画」だったり、

「状況が変化したら、更に変化して対応する」が重要とも言えます。

ですから、意思決定を早くすることは大切ですから、

その意思決定をある程度ルールで設定しておくことが重要です。

例えばですが、所定のシミュレーションをした上で、

5年以内に投資回収が可能なら実行する、とか。

市場でシェア20%以上が見込めるなら挑む、とか。

アンケート調査で50%以上が求めるなら開発する、とか。

もちろんもっと細かくてもOKですが、ルールを変えないこと。

5,000人以上を対象としたアンケートA、B、Cを見て、

50%以上が求めているので「開発GO」と判断しようとしたのに、

「今回、いつもよりAの賛成が少なくない?」と言い出し、

それで「じゃあ、もう少し調べてみる?」という事をしていたら、

それだけスピードは遅くなるので、決めたルールを守るのが重要です。

もしそれで結果が伴わなかったのであれば、

そもそものデータ収集方法か、判断の基準が間違っているので変更が必要です。

5,000人でなく1万人を対象にするとか、

A,B,Cのアンケートに加え、DとEも対象にするとか、

各アンケートの平均50%以上賛成はもちろん、

各アンケートでそれぞれ50%以上の賛成を獲得するとか、

いずれかのアンケートで40%以上の反対があればやめるとか。

これはある程度経験や実績が必要ですが、

ルール化することで明らかに判断が早くなります。

また、別で説明しますが「社員の動き」にも影響しますので、

判断はある程度一定化することが重要です。

4.2-3個のOODAループを平行して行う

これもPDCAや他のフレームワークにも言えますが、

複数を並行して回す事も重要であったりします。

例えば広告戦略でネットを活用するとします。

Google検索連動広告がいいと聞いたので実行しつつ、

途中で「最近はGoogleよりYahooらしい」と聞こえてきたら、

Googleは当初のまま進めつつ、予算の調整などによりYahooを併用。

更に「Facebook広告もいいらしい」と聞こえたら追加をしたり。

想定した結果が得られなければ単一でOODAループを回しつつ、

全体を見て「ダメな広告」から切り捨てていけばいいわけですし、

「ゼロかヒャクか」でなく「ダメな広告は次の月で予算減らす」でもOK。

OODAループの利点は「状況に合わせて高速で実行できること」ですから、

その利点を最大限に伸ばす意味でも「平行」が重要です。

なお、並行できないケースもあるので、その場合は他のコツを利用しましょう。

マニュアル・システム・機械化も有効

OODA(ウーダ)ループの高速化に関して、

マニュアル作成やシステム化、機械化も有効です。

例えば情報収集のマニュアル化を進めるとします。

Aサイトの〇〇という統計データを利用、

Googleアナリティクスの過去3か月間の動向を活用、

Bシステムから注文・問い合わせデータを抽出、

全てをCプログラムで処理し、データ収集完了。

「会社WEBのアクセスデータを利用」より

「GoogleAnalyticsのPV、UUを活用(セッションは不要)」としたほうが

「どこのどのデータ?」と迷うことはありませんし、

アナリティクスなど膨大な情報からも的確に抽出ができます。

システムがあるならワンクリックで必要な情報がまとまって出力されたり、

管理画面で分かりやすいグラフ化されているというのもあるでしょう。

昨今話題のRPAやAIを活用してもいいかもしれません。

マニュアル、システムが固まりすぎると人は考えなくなる

一方で注意したいのは、がちがちのマニュアルを作ったり、

全てをシステム任せにしてしまうことです。

例えばトレッキングコースを進むと考えてください。

マニュアルは簡単かつルールがしっかりしており

  1. 山は昇る。下らないこと。
  2. 分かれ道はすべて右へ行くこと。
  3. 登山道以外は使わない。

とルール化したとしましょう。

例えば登山道で「小高い丘を越えて」というのがあると

「上った後に少し下る」という行為があり、このルールでは止まります。

また、道が二つに分かれて右側の道が見るからに崖でも右に進みます。

登山道限定ですから、渡し船があっても使えません。

これは極端な例ですが、仕事ではよくあるんじゃないでしょうか?

所定のフォーマットを渡されるも、フォーマットに当てはまらないデータがあったり、

対応マニュアルがあるが、そこにないケースが発生したり。

で、相談すると「マニュアル見ろよ!」って言われてマニュアルにない旨を伝えると

今度は「少しは考えろよ!」って言われる。でも、上司が望んだ結果でないと

「なんで勝手なことしたんだよ!マニュアル通りやれよ」と。

人だからこんな理不尽なこといいますが、システムはそうもいきません。

あくまでエラーを吐き出し止まってしまって終了です。

人間もマニュアル通りにしてわからないから聞くと「考えろ」と言われ、

考えて実行すると「勝手にやるな」って言ってたら最後は思考停止します。

マニュアルが間違っていても「マニュアル通りにしました」となりかねませんし、

OODAで言うならデータ収集や分析、判断を間違えまくるわけです。

では、ルールを緩くしたらどうでしょうか?

緩い設定だと、判断が増えて結局遅くなる

では、次にマニュアルをゆるーくしてみたとします。

リンゴを剥く時を考えてください。

マニュアルでは以下のようになっています。

  1. リンゴを洗います。
  2. 皮を剥きます。
  3. リンゴを八等分します
  4. お皿に盛りつけます。

なんとなーく想像できますが、初めてリンゴを剥く人には難しいかもしれません。

皮の剥き方がわからない人もいるかもしれませんし、

「八等分」ってどうやるの?って感じもします。

更に「種や芯」を取ることを伝えてないので、もしかしたら残ってるかも!?

これも皆が知ってる「リンゴの皮むき」だからわかりますが、

いざ、見たことも聞いたこともない仕事や、一度教えてもらった程度の事だと

どうしても抜け漏れが発生するので問題です。

また、システムだと「洗う」の段階で洗剤を使わないとも限りません。

人間で言うなら「洗うっていうのは水道水ですか?飲料水ですか?」とか、

「皮はつなげて剥いた方がいいですか?途切れてもいいですか?」とか、

更に「先にカットしてから剥いてもいいですか?」なんて話になります。

今回は「普通に剥く」ですが「ウサギカット」にするなら

耳の長さや角度、皮を残す割合も決めなくてはならないかもしれません。

それを「その時々の判断」にしていてはやはり判断が遅れます。

結果を重視したルールを設定し、定期的に見直す

じゃあ、どうしたらいいの!!!

ってなりそうですが、まずは求めているものを共有しましょう。

先ほどのGoogleAnalyticsなら

「直近3カ月のPVとUUから、ユーザーのニーズをつかみたい」と伝えます。

そうすると過去3年間のデータは持ってきませんし、ほかの余計な情報も収集しません。

一方で「滞在時間は『読み込んでいる時間』なんで使えませんか?」とか

「シーズン商品なので、去年のデータも使いませんか?」と提案があるかもしれません。

間違ってもここで「黙れ、3カ月だけ持ってこい!」と言わないように…(笑

また、OODAループを回しているうえで予定した結果、望む効果が得られないなら、

チームと「こういう結果が欲しかったんだよね…」と共有した上で、

情報収集や分析、判断の部分を見直すことが重要です。

OODA(ウーダ)ループを回して、チェックして、改善案を出す…

前の記事でも書いたようにOODA(ウーダ)ループにPDCAサイクルのCAを追加した

OODA+CAという形になるわけですね。

フレームワークは所詮道具です。

ハサミと一緒で使う人や使い方次第で、得られる結果も大きく異なります。

重要なのは「OODAが絶対」とか「PDCA最強」とか思わずに、

使ってみて身に着けて、その上で「自分なりの使い方」をしてみることだと思います。

そこには「PDCAを使う」「OODAを完璧にする」ではなく、

「ビジネスで望む結果を手に入れる」という目標設定が重要です。

是非、OODA(ウーダ)ループも自分なりの使い方をしてみてください。

最後になりますが、皆さんカレーが食べたくなりますように。

Pixabayにあったカレーの画像。今夜はカレーにします。

コメント

タイトルとURLをコピーしました