半世紀を超えて繰り返されるソフトウェア開発のミスとは
PMが1冊だけソフトウェア開発の本を読むならこれだ、と言われる本がある。なんと半世紀前、1975年に初版が刊行された、「人月の神話」という本だ。著者のフレデリック・ブルックスは、「IBMのSystem/360の父」として知られ、同社の超大型開発チームを率いた後、ノースキャロライナ大学でコンピューターサイエンス学科を立ち上げた人物。「人月の神話」で彼は、IBM在籍時に遭遇した問題点を分析し、ソフトウェア開発にまつわる難しさについて持論を展開している。レビューを見ると分かる通り、今でも「必読書」と言われるほど、ソフトウェア開発に関わるメンバーが犯しがちな間違いとその対策を鋭く捉えている。だが、いかんせん表現が古く、読むのに骨が折れるので、今日はその中から私が共感した6つのポイントを紹介したい。
① 遅延しているプロジェクトに人を追加すると、さらに遅れる
これは「人月の神話」の有名な主張の1つで、「ブルックスの法則」とも呼ばれる。経営陣は遅延に直面すると、それを取り戻すために人を投入しようとしがちだが、それは逆効果。このステージで新メンバーを加えると、そのメンバ―の教育、作業の再分割（とそれに伴う混乱）、および追加のコミュニケーション、という3つの観点で以前より時間がかかるようになる。著者は、「工数を『人月』という考え方で見積もること自体に誤りがある。コストは人月で測れても、成果はそうではない」と言う。また、デバッグ（検査→修正）のように、そもそも分割できないタスクもある。「妊婦に9人のスタッフをあげても、1カ月で赤ちゃんができないのと一緒だ」と指摘する。
② 「遅延」しているのは、そもそも見積もりが間違っているから？
著者の経験則では、ソフトウェア開発は目安として以下の時間配分を要する。
計画：1/3
コーディング：1/6
単体テスト：1/4
統合テスト：1/4
特に、テスト（含むデバッグ）に50％もの時間を要するのは、意外に感じる方もいるかもしれない。新米の頃の私は、テストにかかる工数を最短で見積もり、リリース日が近づくにつれ、度重なる遅延で周囲への説明に追われていた。デバッグとは、理由が分からないエラーが発生するから起きるもので、その究明には時間を要する。一方、遅延が続くと、顧客やチームの士気にも大きく影響を及ぼす。これを回避するには、予めテスト工数を十分に見積もることが不可欠だ。
③ 明確なマイルストン、クリティカルパス、及び状況共有が肝
ニュースでは大規模プロジェクトが1年以上遅れる例を耳にするが、一体どうやってそんなに遅れるのか？
1日ずつである、と著者は言う。日々の遅れは、大災害よりも認識が難しく、防ぐのが難しく、取り戻すのも難しい。厳格なスケジュールを守るためには、以下3つが必要不可欠だ：
最初のステップは、具体的で、「鋭利な刀のように」明確に定義されたマイルストンだ。エンジニア自身が自分を欺くことができないほど明確なマイルストンを担当することで、進捗を正確に共有することができる。また、ややぎこちないのだが、進捗がクリアでない時、プロジェクト責任者がエンジニアと細かく確認するのも重要だ。
次に大事なのは、クリティカルパス（プロジェクト完了のために今必要な作業工程）だ。端的に言うと、誰かの工程が遅れている時に、「他の皆があなたを待っているんですよ」と言えるか否かで、進捗が全然違う。これがないと、逆に、「どうせ他の部分も遅れているから」という言い訳ができてしまい、遅延が蔓延してしまう。
最後に、関係者への定期的な状況共有（例：隔週）が肝だ。プロジェクト責任者がメール等で幹部も含めて状況共有し、各タスクの状況まで明確にすることで、遅れているチームは優先順位を見直したり、他チームの協力を仰いだり、といったやり取りを促すことができる。
慢性的なスケジュールの遅延は士気を殺すため、こうした仕組みを通じて遅延を最小限に抑えることが肝だ。言うは易しだが。
④ ソフトウェアデザインに民主主義はいらない
ソフトウェア設計の良し悪しは、いかに必要な機能を揃えつつ、それを極力シンプルに実現できるか、という2軸で決まる。これを「概念的統合性」と呼ぶ。概念的統合性を実現するには、設計は1人又は合意した最少人数のグループで行わなくてはならない、と著者は言う。様々なパーツの依頼が必要な大規模プロジェクトでも、先ずこの全体設計を最少人数で行うことで、その後の構築・テスト・統合をスムーズに進めることができる。
⑤ プログラムの保守コストは、開発コストの40%以上
意思決定の際は開発コストに意識が向きがちだが、リリース後の欠陥の修復、機能の追加、使用環境の変更への適応など、様々な保守活動に掛かるコストを忘れてはいけない。また、欠陥を修正すると、別の欠陥を導入する相当な（20〜50%）確率があるため、以前実行されたテストケースを全てやり直す必要がある。ソフトウェアの寿命にわたるバグの月間発生数は、以下のような曲線を辿ると捉えておくと良い。リリース後に欠陥を修復し続けると一定の期間収束するものの、その後様々な変更を加えるうちにまたバグが指数関数的に増え、いずれは修復不可能な状態に陥りゼロから作り直す必要が出てくる。
⑥ 変化に強い組織には、管理職と技術職の互換性が必要
変化は世の常であり、ソフトウェア作りも例外ではない。その時々で顧客・会社が必要とするものや投下できる予算が異なり、その変化に対応できる柔軟な組織作りは、柔軟なシステム作りより何倍も難しい。著者は、社員が管理職と技術職の間を容易に行き来できる組織体制が重要だと説く。
私もAmazonで勤める中、いかにこれが稀なことでないかに驚いた。組織の合併に伴いエンジニアディレクターが技術職に転換したり、また逆に部下無しサイエンティストが大組織を率いるようになったりと、組織の過程に応じてリーダー達が新たな役割を担うことで、その時々のチャレンジを乗り越えていった。
この互換性を持たせるためには、待遇や階層だけでなく、オフィス、サポートスタッフ等、あらゆる面で技術職の処遇を、管理職のそれと同等以上にすることが肝だ、と著者は強調する。一般的には管理職の方が「偉い」と見られがちなため、組織変更を行う際は、昇進でも左遷でもなく、役割変更だとはっきりさせることも重要になる。