Edited at

OODA(ウーダ)でPDCA脱却して、より柔軟に身軽な組織を作る

More than 1 year has passed since last update.


そもそもの前談

「PDCAを回す」という表現を耳にするのがちょっと飽きてしまい、今風なやり方でもっといい仕事の回し方がないかなと探してみて見つけた、OODAの紹介です。

英文の記事を訳して解説したものではなくて、私の個人的な考えなどもモリモリですので、ご了承ください。


OODAって?

OODAは、PDCAと同じく、4つの単語が表す行動を繰り返し行う、という仕事などの実行術です。

開発したのは、John Boyd(ジョーン・ボイド)という方で、元々はアメリカ軍で素早く計画と決断をしながら、常に変わる状況に対して適切な判断を行い行動するためにできたものです。

PDCAとの違いはまずそこにあります。PDCAは、計画実行のプロセスに重点置くのに対して、OODAは、決定・決断のプロセスに重点を置きます。OODAのすべての4ステップを最も早く正しく実行したものまたはチームが「優勝する」という訓練で用いられることがあるぐらいなので、「素早く」の部分も重要です。

OODAの概念自体について、ボイドさんはほとんど執筆しておらず、メモ程度しかないため、彼の名も、あんまり知られていないらしいです。当初のOODAは複雑な解説が必要で、若干とっつきにくい概念だったらしく、それをCliff Notesという方がやっと少しシンプルに解説・説明をしてくれたみたいです。OODAの概念の根拠にあるのは、人間が自然と日常において繰り返しやっている変化への適応を、極端な緊張やストレスが伴う戦場でもできるようにする、という意図があるようです。戦場に限らず、ビジネスや開発現場において、緊急事態などがあります。

そのような状況に置かれた場合でも、同じく「素早く決断ができる」には、役立っています。

個人的には、これは、アジャイル開発の現場においても、使えるのではないかと思って、いろんな記事を読んでいます。

アジャイル開発は変化に強いはずですが、そこに従来のPDCAが現れると「計画の実行」が重要になり、途中での「変化」に現場が惑わされてしまいます。

これをOODAの採用によって、改善できないかと考えています。

不確定要素の多い状況でも正しく決断をして、素早く身軽に動ける開発チームは、きっと最強のチームになるのではないかと、想像しています。


略の意味 → OODAの4フェーズ解説

OODA つまり、 Observe, Orient, Decide, Act です。

Observe: 観察をする

Orient: 適応させる

Decide: 決める

Act: 行動をする


Observe: 観察をする

外部情報、今起きている状況の変化などの情報をとにかく把握し、なるべく視野に入れることです。

開発の現場なら・・・今やっているプロジェクトに関わるニュース、部署内外の様々な「事情」(先方の状況の変化など)、もっと大きくいうと例えば業界の動きや突発的な出来事。

それらによって、今やっているプロジェクトが、どう影響を受ける可能性があるか?を考えることが重要です。

外部の要因をここまで広く捉えようとすると、自然と「閉ざされた」チームから「外に向いて開かれたチーム」になっていくことにもつながります。


Orient: 適応させる

ここが、かなり重要な部分です。そして一番難しい部分かもしれません。「常に変化する環境や状況に適応する」というのは、至難の技です。

「今の状況を観察し適応する」を繰り返すことで、常に「現状」へ適応した状態を維持することができ、その訓練を経て、「適応」が徐々に楽になると言われています。

正直、自分も初めて読んだ時、何だ?と思った例がありますが、これはボイドさんがOrientの部分を解説するときに使っていたと言われている例でもあり、何回か読むと、なるほど!と思えるようになるのは、ある意味このステップの真意を捉えている気もするので、紹介したいです。

以下の文章を読んで、最終的に、何を想像できたか、何が見えたかを考える、という練習です。

元の英文:

“Imagine that you are on a ski slope with other skiers… that you are in Florida riding in an outboard motorboat, maybe even towing water-skiers. 

Imagine that you are riding a bicycle on a nice spring day.
Imagine that you are a parent taking your son to a department store and that you notice he is fascinated by the toy tractors or tanks with rubber caterpillar treads.

Now imagine that you pull the skis off but you are still on the ski slope.
Imagine also that you remove the outboard motor from the motorboat, and you are no longer in Florida.
And from the bicycle you remove the handle-bar and discard the rest of the bike.

Finally, you take off the rubber treads from the toy tractor or tanks.
This leaves only the following separate pieces: skis, outboard motor, handlebars and rubber treads.”

日本語訳(若干フリー)

想像してください。他のスキー客が大勢いるゲレンデにいること。フロリダの海でオープンモーターボートに乗っていて、水上スキーの人を引っ張ってるかもしれない。

春のおい天気の日に自転車に乗ってることを想像してください。
子供の親であることを想像してください。息子さんとデパートへ行ってる、子供がゴム製のキャタピラ式のトラクターや戦車のおもちゃに興味があることに気がつく。

また、ゲレンデにいることを想像してください。スキーの板はちょうど外しているところです。
もうフロリダにじゃないよ。同時に、モーターボートからエンジンだけを取り外していることも想像してください。
自転車も、ばらして、ハンドルだけ残して他の部品は捨てています。
おもちゃの戦車やトラクターから、ゴム製のキャタピラーを外しました。
残ってるのは次のバラバラな部品:スキー板、外付けのエンジン、自転車のハンドル、ゴム製のキャタピラー。

最後に、これらを踏まえて、何が想像できるかを考えるという練習です。

答え、わかったかな?

「スノーモビル」です。

「適応する」ことのポイントは、このような、極端・素早く変わる状況の中で、次にできることを想像、想定することです。

自転車 スキー モーターボート キャタピラー

これらは、何になるのか?これらが提供された状態で、なにができるのか?

同じように、「観察する」時に手に入った様々情報を組み合わせて、相対的にみて、次は何をすべきかを考えることが、適応する、ことです。

開発現場では、おそらく無意識に、場合によって半分強制的(状況に強いられてという意味)に行われていることです。

あるプロジェクトの急な方向転換は、企画側が手にした情報よる方向修正であることが多いです。

変化に強い現場(開発チーム)は、そういった情報を企画と同じぐらい早く(別の軸の情報も)仕入れることで、企画が予定変えたから再計画や要件再定義を行うのではなくて、自らの情報収集や周囲観察の結果、計画や要件の見直しが必要と判断し、場合によって企画側にまでそれを持っていくチームだと思います。

もちろん、純粋な「開発チーム」では、なくなりますが、「開発しかできない」チームでも、なくなります。


Decide: 決める

このステップには、ほぼ必ず「仮説」という言葉がついています。

ボイドさんの言葉の通り、このステップでは:

 actors decide among action alternatives generated in the Orientation phase

つまり、Orient(適応)部分で現れた代替案の中から、検証するものを当事者たちが選定するフェーズです。

ボイドさんがDecideの隣に「仮説」という表現をおくことで、決まったことの不確実性を表したかったかもしれません。


Act: 行動をする

こちらも、分かりやすい部分です。

Act、つまり「行動を起こす」のみです。

言葉を変えると、違和感なく最近多くの開発現場で耳にする表現になりますが、Decide部分で選んだ仮説を検証するステップです。

ボイドさんの資料にはActの隣にはTestという言葉が残っているらしいですが、「実行」ではなくて「検証」に重点を置きたかったのでしょう。

OODAは、ただ迅速に決断をするためのフレームワークだけではなく、常に学び、ナレッジを蓄積し、仮説を見つけて試し、また学部サイクルを繰り返すことで、成長して行くことをサポートするフレームワークでもある気がします。


まとめ

OODAが開発現場にもたらす可能性(野望も入った感満載ですが):


  1. 「開発しかできないチーム」ではなく、企画・経営と同じ視座から物事を観察し、自ら作るものを決めることができる、開発以上のことができるチームの創造

  2. 開発現場と企画側が同じ立場からものを語ることで生まれる、属人化のない強い組織の創造

だと思います。

ウーダは、PDCAのように計画から初めて試行錯誤するためのフレームワークではないです。それよりも、育成・教育・構築の道具になるフレームワークだと思います。

常に変わる、正解のない今の世の中での、出遅れることがなく、不確定要素に惑わされない判断力とそのために必要な、観察力、適応力、行動力を磨くためのフレームワークとして非常に有効なものだと思います。


参考資料として読むといい記事