物事は1日にして成らず。遅延は1日で起こらず。
18章（まとめ）から始まり、16章→17章→19章→エピローグ/訳者あとがき→1章→2章・・・という順序で読み進めてきた本連載もいよいよ大詰めです。今回は、プロジェクトの遅延に対抗するための手法を説く「第14章：破局を生み出すこと」を読み解きます。（そして、次回の15章で読み解き完了です。）
連載記事一覧は、コチラの最下段から
スケジュール無くして、スケジュール遵守は無い
極めて当然のことですが、「スケジュール」が無ければ遅延することはありません。しかしながら、これまた当然ながら、「スケジュール」が無ければスケジュールが順守されることもありません。
別に、システムを作ることには限らず、大抵の仕事は、1日にして成りません。システム開発の場合には、開発規模が大きくなったり、恒久的に安定的に動くことを目指したりするのであれば「徹夜すれば何とかなる」という考え方は捨てないといけません。システム開発は”積み上げ”ていく作業です。また、一般的なビジネス上のタスクも、殆どは”積み上げ”ることが求められます。
ですので、何はさておき、まずはスケジュールを引きましょう。
余談ですが、例外的に、戦略コンサルティングはちゃぶ台返しが効きます。考えることが仕事であり、考えた結果が成果物だからです。もちろん、それまでに収集したデータや調査結果は最大限に活用しますが「昨日までと180度違う結論」だとしても、それが絶対的に正しいという確信があれば（あるいは、昨日までが絶対的に誤っているという確信があれば）、深夜12時に、翌朝に向けて真逆の方角へ走り出すことも可能です。で、あるが故に、世の中の戦略コンサルティングファーム出身者の中には、世の中の多くの物事に、この性質を適用してしまうという致命的なミスを犯す人もいます。僕自身、自戒を込めて、非常に注意せねばならないポイントだなと思いますね。
確固たるマイルストーンを置こう
さて、スケジュールが引けたとすると、次に行うべきは「マイルストーン」の設定です。
ここで間違ってはいけないのは、”解釈の余地のあるマイルストーン”は、役に立たないどころか、かえって悪い影響を与えるということです。
マイルストーンを鋭利な刃のようにあいまいなところをなくすことは、上司が確かめられるようにすることより重要だ。人は、マイルストーンが自分も欺けないくらい鋭利だと思えば、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司はしばしば報告を提出した本人とは異なる意味に解釈してしまう。
マイルストーンが明確でなければ、進捗報告は曖昧なものとなり、遅れているのか遅れていないのかが誰にもわからなくなるわけですね。そして、それは即ち「遅れている」ということを意味するのです。ええ。残念ですが、管理されないスケジュールは、常に遅れ続けるのです。
遅れは悪だと認識せよ
マイルストーンが明確に定義されたら、今度は「認識」を変えましょう。遅れてよい物事はありません。遅延＝悪だと強く心に刻み込みましょう。
人は、プロジェクトのスケジュールが破滅的に遅れていると聞くと、たいへんな災難が続けざまに起こったに違いないと想像する。しかしたいていの場合、そういう破滅的状況は竜巻のような突発的なものではなく、白アリのようにじわじわ忍び寄ってくるものが原因である。スケジュールは、情け容赦なくではなく、ごくわずかずつ遅れてきたのだ。
これまでみてきたように、1日の遅れにも躍起にならなければならない。この程度の遅延こそが、まさしく破局の要素なのだから。
「どうせ他も遅れているから」とか「自分たちだけ納期に間に合わせても仕方がない」という思想そのものが積み重なった結果、プロジェクト全体を壊滅的な遅延に追い込みます。言い訳をしてはいけません。遅延は悪です。
そして、隠すな！
もちろん遅延は起こるものです。しかし、それは「まあいいや」ではなく、「起こるべからざることが起こっている」という認識で、周囲に共有され、必要に応じ、然るべき対策が講じられるべきなのです。
というわけで、大事なのは「遅延を隠さない」ということです。
現場リーダーが、自分のチームの遅延を上司に報告することを厭う理由として、ブルックス氏は以下の2つの理由を上げます。
- 自分自身で解決できる可能性があり、それこそが自分自身の仕事の本分のはずだ、という自負
- 問題を報告したら、権限を奪われ、今のままでも上手くいくはずの他のことまで台無しにされてしまうのではないか、という危惧
まさに、この2つの理由で、多くの遅延が（ブルックス氏の表現でいえば）じゅうたんの下に隠されていることでしょう。そして、その遅延は、じゅうたんの下でどんどん大きくなり、気づいた時には取り返しがつかなくなるのです。
この課題解決のための手段として、ブルックス氏は「上司が、現場リーダーの話を落ち着いて聞き、パニックに陥ることもなければ、頭越しに権限を発動したりしないこと」および「マイルストーンと、それに対する進捗状況を相互に共有できる仕組みで運用すること」を上げています。
これは、本当に重要なことです。もし、上司が「遅延しているなんて台詞は聴きたくない（もしくは、そんな報告を自分の上司にしたくない）」という反応をすると、遅延は隠されてしまいます。「遅延しているという報告ではなく、どうやったら間に合うかを報告しろ」という指示も適切ではありません。もちろん、対応策は現場から提示されて然るべきですが、どう頑張っても間に合わないという状況もあります。そういう場合には、それを前提として、どういう対策を練るべきか・どういう対処をすべきkを”プロジェクト全体”として考えることも必要になります。それこそが「上司」の役目です。
こうした全体のプロセスは、上司がミーティングや評価・検討会あるいは大きな会議を、状況検討のためか問題対策のために開くのかはっきりと区別し、それに応じて自分自身をコントロールすることによって促進される。人は、状況検討ミーティングの結果、問題が自分だけの手におえないと考えたら、問題対策ミーティングを招集するはずだ。
ありきたりな台詞で恐縮ですが「風通しの良い組織」をつくることが、情報隠匿を排除し、結果的に、致命的な遅延を防ぐことに繋がるわけです。（もちろん、どうしたって遅れるときは遅れるわけですが、プロジェクト全体でのリソース再配分などの対応策を”早期に”打つことが大事なのです。プロジェクト後半に人員を追加することが逆効果だということは、もう、皆さん、重々ご理解されていますものね。）
次回は、この読み解きの最終章である「15章：もう1つの顔」です。
連載記事一覧は、コチラの最下段から
