高層ビルが施工中に倒壊したとすれば、大問題になって原因究明されるだろう。謝罪会見が開かれ、関係者の更迭やトップに対する株主代表訴訟が起こるかもしれない。そのようにして、同じことが二度と起こらないように徹底的に検証される。痛みをともなった失敗は貴重な工学的経験として文書化され、未来の技術者たちに受け継がれるだろう。
システム開発ではどうか。「施工中の倒壊」に相当する事態は、プロジェクトがデスマーチ化して、鬱病患者や自殺者を生み出している状況とみなしていいだろう。ところがこの場合、原因究明はされないし謝罪会見もなされないし責任者の処分もされない。結果的に同じような現象が繰り返される。なぜか。受託側にとってデスマーチは失敗とみなされないからだ。
理由はいくつか挙げられるが、次の3点にしぼって説明しよう。(1)デスマーチになっても作業中止に至らないから。(2)受託側も発注側も"本来あるべきだった仕様"を示せないから。(3)デスマーチ案件は完成後に受託側にとっての経営資源となるから。これらを説明したうえで、悲惨なデスマーチを防ぐための方策を示そう。
まずは、「(1)デスマーチになっても作業中止に至らないから」。建築では建築資材が空間を占拠しているため、倒壊すれば作業を中止せざるを得ない。ところが、ソフトウエア開発では物理的な資材を伴わないため、パッチを当てながら作業を継続できてしまう。ゆえに社会的な耳目を惹かない。こうして膨大な無駄と苦役を投入した果てに、システムは曲がりなりにも「完成」してしまう。ゆえに「あわや失敗かと思われたが、なんとか完成した」と認識される。原因としてせいぜい「プロジェク管理の不徹底」くらいは挙げられるだろうが、技術的な問題に関して蒸し返されることはない。
これには「(2)受託側も発注側も"本来あるべきだった仕様"を示せないから」も関係している。最終的に適切な仕様として完成したかどうかは、発注側も受託側もわからない。有り体に言えば「的外れな仕様のシステムが非常識なコストをかけて完成した」といったところなのだが、お互いに「では適切な仕様はどのようなものだったのか」を示せないので、この問題はうやむやにされる。ゆえに明らかな失敗とはみなされない。
発注側としては失敗を認めたくないという事情もある。当初の倍以上の開発コストをかけて、稼働が数年遅れになったとしても、「我が社のシステムは無事刷新された」と表明するだろう。とくに上場企業であれば責任追及が怖いので、システム刷新に失敗したとはなかなか公言できない。それでもあまりにも出来が悪いようであれば訴訟に至るが、互いに痛手が大きいのでその確率は低い。
続いて「(3)デスマーチ案件は完成後に受託側にとっての経営資源となるから」はどうだろう。保守性や可読性の劣悪さはデスマーチ化の一因となるが、それゆえに「他の業者では保守できない神経系」が出来上がる。いったん完成してしまえば受託側にとってそのシステムは「こっちのもの」で、顧客はもう逃げられない。下請けの技術者を送り込んで保守や二次開発のマージンを稼げば、一次開発での持ち出しは遅かれ早かれ回収できる。鬱になって去った技術者の代替はいくらでもいる。ようするに受託側にとってデスマーチは、彼らの大好きな多重下請体制の中で対応できる「想定内の日常」であり、異常で反省されるべき状況とはみなされない。
そういうわけで、デスマーチは観念論やウワサとしてだけ存在することになる。客観的にはどこからどう見ても失敗なのだが、そもそもデスマーチが公式には存在しない。ゆえに繰り返し起こる。手痛い失敗から学ばないのは愚かしいと思われるかもしれないが、彼らがその状況を失敗とみなしていないのだから、そこから学ぶ必要を感じていないだけの話である。
とはいえ、それを何と呼ぼうが「施工中の倒壊」の社会的影響は隠然として甚大なので、発注側としては是が非でも避けたい。少なくとも開発業者の食い物になどされたくないだろうし、現場の技術者も同じ気持ちだろう。もちろん、業者としても悪意をもって意図的にそんな状況を起こすわけではない。しかしこれはいわゆる「不作為の罪」のようなもので、デスマーチのメリットとデメリットを考えると、コストをかけて予防策を張ることの経済合理性が薄いのである。ではいったいどうしたらいいのか。続く記事で説明しよう。
