エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定

はじめに

2015年、中国の長沙で57階建ての超高層ビルMini Sky Cityがわずか19日で建設されました。私はここ数年、息子を学校に送る途中で、サンフランシスコの9階建てのビルが3年以上かけて建設されているのを見てきました。Mini Sky Cityの記録は、工場で事前製作したモジュール式の部品を組み立てる工法に大きく依存していたため正当ではないという議論もあります。しかし、サンフランシスコのビルも同様にモジュール式の部品で建設されていることは確かです。なぜ片方は1日3階のペースで建設でき、もう片方は1年で3階なのでしょうか？

Bent FlyvbjergとDan Gardnerの共著『How Big Things Get Done』（邦訳『BIG THINGS』サンマーク出版）は、戦略が複雑な建築プロジェクトの成否にどう影響するかを探った本です。著者らの根本的な発見は、「スピードを上げるには、シミュレーションのような失敗のコストが安い段階で失敗をたくさん重ね、建物がほぼ完成した後のような修正が難しい段階では失敗を減らすべきだ」というものです。私の経験では、この洞察はソフトウェアエンジニアリング戦略にもそのまま当てはまります。

しかし、ソフトウェアエンジニアリングの世界ではさらに根深い問題があります。建築設計図を見たことがない建築家はいないでしょう。しかし、ソフトウェアエンジニアや幹部の大多数は、明文化されたエンジニアリング戦略を見たことがないと言います。エンジニアリング戦略なんて存在しないという考えも広まっています。しかし適切に質問してみると、ほとんどのエンジニアが自社のエンジニアリング戦略を直感的によく理解していることがわかります。たとえその戦略が優れたものでなくても、何なのかは把握しているのです。 ...