エンジニアが多くなりすぎると
ソフトウエア開発が難航する理由
『人が増えても速くならない ～変化を抱擁せよ～』倉貫 義人 著、技術評論社、1540円（税込）
早速、書籍のタイトルにもなっている「人が増えても（ソフトウエア開発が）速くならない」理由について、本書の内容をもとに解説していこう。
ソフトウエア開発に明るくない発注者や経営者に限って、「ものづくり」の発想のもと、人手が増えれば同時にたくさんの作業が可能になると思いがちだ。それゆえ、開発チームから「納期までにもう少し時間がほしい」「作業が遅れている」などと聞かされれば、「じゃあ、エンジニアを増やそうか」という発想になる。
これは、エンジニアという職種に誤解があるからだろう。
本書によると、エンジニアは「発注内容に沿って単純に手を動かすだけの人」ではない。発注者や社内上層部の「○○に役立つソフトウエアが欲しい」という、時として曖昧な指示を聞き、それを実現するために適切なプログラムを「設計」する。この「上流工程」も担えるのがエンジニアなのだ。
著者の倉貫氏は、エンジニアの仕事を住宅建設に例えて説明している。家を新築するとき、いろいろな職種の人が関わるが、その中でエンジニアに当たるのは「設計士」なのだという。決して「大工」ではない。
住宅建設では多くの場合、大工が増えれば、より短期間で家を完成させられる。その理由は至ってシンプル。現場で手を動かす人が増えると、これまで手が回らなかった部屋やフロアの工事を同時に進められるからだ。
やるべき作業もだいたいは決まっていて、設計士の指示に従って作業すればいい。途中で人手が加わっても、作業の分担は容易だ。
しかし、設計士の場合はそうはいかない。決まった作業をこなすのではなく、自分で仕事を作り出さなければならないからだ。例えば設計士が5人いても、設計方針などの意見が合わず、工程が前に進まなくなってしまう恐れがある。エンジニアも同じなのだ。
人を増やすとしたら、エンジニアが作成した設計書・定義書に従ってコードを書く「専門のプログラマー」になるが、今度はエンジニアからの指示が一苦労になる。人が増えればそれだけミスの可能性も多くなるだろう（ここは大工も同じかもしれないが）。
人海戦術での効率化が難しいのであれば、どうすればいいのか。倉貫氏によれば、そのポイントは「情報共有」と「心理的安全性」だ。
