なぜ、エンジニアは木から落ちたがる？

職場

» 2011/05/23

　随分昔のことではありますが、「人間とは、木から落ちたがる猿だ」というようなことを聞いたことがあります。

　普通の猿は木から落ちることはありませんが、人間は木に登れない猿だと……。

　思考実験として、ここに、人が真っすぐに歩けるくらいの十分な幅をもった平均台があるとしましょう。

　平均台自体の高さは大して高くありません。その平均台に人を乗せます。そしてその人に、平均台の端から端まで歩いて渡るように指示します。

　最初、その人はまっすぐに歩けますが、一瞬でも下を見てしまったら、その人はもう

　「平均台から落ちなければならない」

という暗示にかかる、という説でした。

　人は、下を見なければそのまままっすぐに歩けるらしいのですが、下を見た（つまり落ちられる状況であると認識した）途端に、運命があらかじめ決められていたかのごとく”落ちて”しまうらしいのです。

　「俺はここから落ちなければならない」という強迫観念に駆られるのだとか……。

　この説の真偽は定かではないです。だいたいが昔の記憶のことですから、うろ覚えも甚だしい。

　しかし、ある種の蜂に餌にされるある種の蜘蛛は「餌になることが決まっている」かのように行動すると聞いたことがあります。

　遺伝子レベルの約束であるかのようにです。マーフィーの法則というものもありましたね。何やら不可避な原理が隠れているような気持ちにもなります。

　おっと、話がそれてしまいましたが、ここで話をしたいことは猿でも蜘蛛のことでもなく、我々エンジニアのことです。

　私の周りでは、いくつものソフトウェア開発プロジェクトが進行しています。そのどれを取ってみても、Q（品質）、C（コスト）、D（納期）のどれか、あるいは全部に問題を抱えているのです。
これは何故でしょうか？

　単に計画倒れのプロジェクトばかりだったという“落ち”ではつまらないですね。少し思考遊びになりますが、こんなこともあるのかな、と考えました。

　今ここに、納期がひっ迫し、品質に問題があるプロジェクトがあります。このプロジェクトのプロジェクトマネージャ（PM）の取る行動とは、いったいどのようなものになるのでしょうか。

　プロジェクトが破綻していれば破綻しているほど、プロジェクトを「納期通り」に「当初の要求機能のまま」に「コストも超過せず」に完結させることは十中八九無理でしょう。

　しかし、何がしかの策を取らないと、そもそもPMとして存在する意味がなくなる……とばかりに、事後策を弄します。

　一番手っ取り早い対応は「人員を増やす」という対応ですよね。

　私だって、何度も何度も自分のプロジェクトのお世話をしてもらいましたし、他のプロジェクトのお世話もしました。このご時世（って言っても、相当以前から）、納期を遅らせて良いなんていう物分りの良いプロジェクトはありません。

　「死んでもいいから、モノ作れ」

って、上司に何度も真顔で言われたこともありますし……。それはそれは厳しい現実が待っているものです。

　ですので、瀕死のプロジェクトには決まっていつも助っ人が増員されます。“増員できればまだマシ”っておっしゃる方もいるかもしれませんが、人間も生き物ですから、同じ人間を何日（何カ月、何年）も酷使する訳にもいきません。そんなことをすれば、確実に生産性は落ちるし、揚げ句の果てにはどっかに逃げられてしまいます。

　という訳で、最後はやっぱり社内社外を問わず、誰かが増員されます（私の関与したプロジェクトでは、まず間違いなく増員されました）。

　でも、ここで増員されるメンバーっていうのは、対象製品に対してまったくの門外漢だったりしますから、増員した事自体が余計にプロジェクトの負荷になることもあります。

　文句を言っても、そんな人しか残っていないのですから「仕方がない」って訳で実行されます。

　で、どうなるかっていうと、結果は、「やっぱり遅れる」んです。

　だけど、それ以外の対応方法を知らないので、とにかく増員したメンバーで、なんとか乗り切ります（負荷を分散したおかげで、死にそうになる人の数が5人のところから3人になったというくらいの効果はあるのでしょうが）。

　こんなことを何年もやってくると、みんな考えることは同じ。

　「増員って……果たして効果があったのか？」

　増員しなかった場合の納期遅れや品質劣化を挽回するために増員したはずなんですが……。こんな疑問がふつふつと湧いてきます。

　ところで（唐突に）、皆さんは「ブルックスの法則」というものをご存じでしょうか？

　ソフトウェア開発に長年従事している人だったら「ブルックスの法則」を知っているか、少なくとも聞いたことはあるでしょう。

　「ブルックスの法則」で最も有名なものは、「遅れているソフトウェアプロジェクトへの要員追加は、さらに（プロジェクトを）遅らせるだけだ」というものです。

　これは1975年に出版された書籍 “The Mythical Man-Month” （日本語版の書名は『人月の神話』）に登場した文言とのこと（出典：Wikipadia）。

　上記の法則以外に、いくつか収録されているようですが、これが私の一番印象に残っている名ゼリフです。

　出典の日付を見ると、なんと！今から36年も前に出版された本だったのですね。その法則が今でも通用するなんて、ソフトウェア開発はあまり進歩していないのではないか？と疑ってしまいます。

　この法則が意味するところは、皆、なんとなくは理解はしていると思います。では、なぜ「理解しているはず」の悪魔のサイクル（デスマーチって言い換えてもいいです）に突入してしまうのでしょうか。それも、いとも簡単に……。

　理性では計りしれない、何か、もっと奥底の何か（本能？）が、正常な理性の営みを邪魔しているのではないか？ そんな妄想に囚われたのです。

　それが冒頭にお話をした「落ちなければならない」という説です。

　懸命なる皆さんの中にも、

　「増員しても、とても納期通りに成果物が完成しないと分かっているのに、やっぱり大幅に増員してしまった」

なんてことはありませんか？

　そんな時は、悲しい気分になりませんか？まさに「死者の行進」「デスマーチ」です。

　上司も（きっと）分かっています。でも、増員せざるをえないのです。“増員する以外に良い案なんてない”と言って、本能がささやくから。

　部下も（きっと）分かっています。増員しないと上司が許してくれないし、説得するのも面倒だし。って本能がささやくのです。

　増員しても望む結果が得られないことが分かっているのに、安易な策にすがって（落ちて）しまう。その方が、他の策を取るよりもずっと楽だからでしょうか。

　下（納期遅延、品質劣化）が見えてしまってからでは、やっぱり人は不条理な解決策を取り続けるものなのでしょうか？上に登って行くよりも、流れ落ちてしまった方が楽だから？……

　猿や蜘蛛にならないためにも、まともな開発をしたいと切に願うこの頃。

　“大脳新皮質をちゃんと使いましょう”って、別の本能もささやきます。

　最後に一言。上を向いて歩こう……（昔の歌にありましたね）♪（時々、石につまずく危険性はありますけど）