完璧な段取りなんてあるわけない。100%の時間効率なんてゼロ、プロバビリティだ。
ただし、これは情報系ITの世界の話です。

世界で500万ユーザが使うソフトウェアのプロダクトマネージャーをやっていたことがある。開発陣は日本、台湾、中国、アメリカに及んだ。開発チームだけでも200名を超えていた。
この品物、年に一回新製品を出すきまりになっていた。だから、製品発表会には多くのジャーナリストを集める。デモもやる。リリースのタイミングでアメリカのPC雑誌のレビューワーに製品を試してもらう。そうして売ってゆく。こういうサイクルを毎年回してきた。

ところが、開発スケジュールは毎年必ず遅れる。もちろんこっちはサバを読んでいる。それでも、発表会に間に合わせるために何かを諦めなければならなくなる。例えば、いくつかの機能を諦める。トレードオフを繰り返す。おまけに、PCマガジンのレビューワーにわたすビルドは必ず何かが起きる。あらゆる予防パターンを考えた。それでもトラブルは起きる。最後は開発者を貼り付けてすぐ治せる体制を作った。PCマガジンの評価は売上に大きく影響するからだ。

さて、どうして学習し、改善できないのか?PDCAはちゃんと回しているのか?
はい、やってます。

理由はいくつかあると思う。まず、人間はエラーが組み込まれてしまっている生き物だからだ。プロジェクトを遅らせる要因を行動経済学や認知学からさらってみる。ざっと見ただけでもこんなにある。
「自信過剰バイアス」、「計画の錯誤」、「確証バイアス」、「内集団バイアス」、「社会的手抜き」、「コンコルド効果」、「気質効果」、「テンション・リダクション効果」、「希望にすがる」、「集愚効果」、などなど・・・

更に、こういうバイアスやら悪い意味でのヒューリスティックスが数百名の関係者で発生するのだ。まったく、「大男、総身に知恵が回りかね」だ。

一方、世の中には数千名で動かすプロジェクトを成功させる人たちもいる。原子力発電所、ロケット、など失敗が許されない世界で働いている。ただ、私見だが、彼らはスケジュールについての優先順位は高くない。失敗は多くの人命がかかっている。だからプライオリティは明確なのだ。

一方、商業ソフトウェアやサービスはちょっと違う。バグっても最悪パッチをリリースすれば良い。ときにはスケジュールを守ることが最重要事項になることすらある。

そう、どうしても問題は起きる。優先順位はスケジュールや使い勝手に置かれる場合もある。
そこで、ソフトウェアの世界では開発手法そのものが変わってきた。アジャイルやら、スクラムやら、PDCAのAもアクションでなくアジャストと解釈される。スピードをもって変化に対応すること、そして、ゴールへの優先順位もタコのように柔軟に変わるのだ。

つまり、段取りすら変えることがリスクに対する答えになってきているのだ。QA(テスト)もどんどん自動化する。そうすると時間効率性も一体何をもって測ればよいか、チェックする視点が変わってくる。
このような世界では、どうやら日本式製造方式、決まったやり方を熟成させてゆくやり方は不利だ。型にこだわるあまり、時間をかけすぎてしまう。その間に新しい土俵ができてしまう。いや、もはやそこはオクタゴンのリングだ。そして戦いのルールも変わっている。その時、自分が周回遅れであることに気がつく。時すでに遅し、だ。

こういう世界では、自分たちが遅れていること、これに気がつく方法を心得ていることが生き抜く秘訣だろう。そして目覚まし(ウェイクアップコール)がなったら、知恵を集め、柔軟に、すばやく対応する。それを何度も何度も回転させる。そして自分がどこに転がっていっているのか、それを片目で睨みつけておく、そんな矢文ラミのような態度が、ますます加速するイノベーションの世界でのリスク管理のような気がする。
どうだろうか?