エンジニアをいくら増やしても「納期遅れ」を回避できないのはなぜ？：ソフトウェア開発にまつわる10個の神話【第1回】

さまざまな“神話”が存在するソフトウェア開発業界。人員の増加とテストの扱い方における、生産性の向上に関する神話の真実を解き明かす。

[Cameron McKenzie，TechTarget]

　ソフトウェア開発業界には、誤解に基づく“神話”があふれている。それらを否定するのは難しいことではない。にもかかわらず企業の経営層や産業教育に携わる教育者、そしてソフトウェア開発チーム自体にさえも、神話は根強く残っている。ソフトウェア開発業界に関する、よく知られた神話を紹介する。

神話1「開発の遅延はエンジニアを増やせば解消する」

併せて読みたいお薦め記事

エンジニアのためのノウハウ

• 40歳を過ぎたエンジニアが面接で“年齢”を効果的にアピールする方法
• “年収1000万円エンジニア”になれる初心者が「最初にすること」はこれだ

　「ソフトウェア開発プロジェクトに人員を加えると、生産性が瞬く間に向上する」――。これはソフトウェア開発によくある神話だ。

　新しいエンジニアがチームに加わると、最初はたいてい1人当たりの生産性が低下する。新人をプロジェクトに順応させるために、他のエンジニアが開発に集中する時間が奪われてしまうからだ。さらに新人が一人前になるには時間が掛かる。

　ソフトウェア開発では、大規模なチームよりも小規模なチームの方が、生産性や適力、敏しょう性を保ちやすい傾向にある。「スクラム」提唱者であるケン・シュウェーバー氏とジェフ・サザーランド氏による、スクラムのガイドライン「Scrum Guide」は、チームのメンバーを10人以内にすることを推奨する。スクラムは、メンバーに役割やタスクを割り振り、メンバー同士の連携を取りながらプロジェクトを進めるソフトウェア開発手法だ。

　「遅れているソフトウェア開発プロジェクトに人員を加えても、プロジェクトがさらに遅れるだけにしかならない」という「ブルックスの法則」がある。ソフトウェア開発チームの人員が増えるほど、それに応じた見返りが得にくくなる。

神話2「TDDは時間の無駄だ」

　ソースコードを書く前に、前もってテストコード（テスト用プログラムのソースコード）を書くべし――。こうした考えに沿ったソフトウェア開発手法が「テスト駆動型動開発」（TDD：Test Driven Development）だ。

　よくあるソフトウェア神話に「TDDは時間の無駄だ」がある。これは事実ではない。

　エンジニアはソフトウェアのソースコードを書く前に、そのソフトウェアがどのように動作するのかを考える必要がある。外部ソフトウェアとの連携方法も考慮しなければならない。TDDはテストコードにより、これらの動作を網羅的に検証することを求める。

　TDDを採用するかどうかにかかわらず、最終的にはテストコードを書く必要がある。そのことを考えれば、ソースコードが完成してからテストコードを書くよりも、ソースコードがどう動くのかを考えながらテストコードを書く方が、時間の節約になると考えられる。

---

　次回は、3つ目と4つ目の神話を紹介する。

TechTarget発　エンジニア虎の巻

米国TechTargetの豊富な記事の中から、開発のノウハウや技術知識など、ITエンジニアの問題解決に役立つ情報を厳選してお届けします。