「働き方改革で残業は減らす、しかし開発日程は維持する。つまり、人を増やして乗り切るってことだ。」
マネージャからそう言われ、開発途中から何人もの人がつぎ込まれたプロジェクトがありました。工数不足で検討が進んでいないブロックに追加された人員が割り当てられていきましたが、日程の遅延を巻き返すことはできませんでした。
そればかりか、複数人で担当していた部品では、境界で大きな問題を抱えていることが、出図(金型製造スタートのこと、これの後は大幅変更ができない)になって健在化するなど、爆弾を抱える始末になりました。
何でこんなことが起きたのか。そんなときに頭に浮かんだのが本著「人月の神話」です。フレデリック・ブルックス著のソフトウェアプロジェクト管理の古典です。(初版はなんと1975年！僕より年上だ)
人月とは
工数の単位です。１人の人間が１ヵ月にこなすことが出来る工数を表します。ソフトウェア開発の現場では、仕事量の大きさを測るのに、この人月を使っているそうです。*1
人月の何が神話なのか
本著では人月の考え方は間違った危険な神話とされています。
何故かというと、人と月とが交換できるという前提で成り立つ単位であるからです。12人月の仕事があるとして、1人だと1年かかる仕事も、12人いれば1ヶ月で終わるわけですが…これは本当でしょうか。
このような見積もりが成り立つのは、仕事の内容が作業者間のコミュニケーションを必要としない場合だけです。仕事が複雑性をはらむ場合は教育・訓練に作業配分の再考、何より担当者間の相互コミュニケーションが必要になってくるわけで、このコスト(工数)は人数の増加とともに増えていきます。
人員を増やしていくと、人員追加による業務短縮効果を前述の工数増加が超えてゆき、最終的に人を追加しただけスケジュールが遅延する悪循環が生じる…と述べてあります。
「遅れているソフトウェアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけである」これはブルックスの法則として提唱されている内容です。
本著で語られているソフトウェア構築は、まさに複雑性をもった仕事です。そして、複雑性を持った仕事はソフトウェア構築以外にも多数あり、それらの業務についてはブルックスの法則は適用できるのではないでしょうか。
「人月の神話」章以外の重要な知見
ブルックスの法則以外にも、「なるほど」と思わせる内容がありました。コンセプトの完全性のお話です。
本著ではシステムのデザインは1人、もしくは少数かつ同意見のグループによってなされるべきとの提言がありました。システムの機能は多ければ多いほど優れているわけではなく、どれだけ目指した姿がボケずにいられるかが大切ってことです。いろんな人がいろんな意見を言って全部取り込んでいくと、何をしたいか良く分からないものが出来ますからね。(この点、自分も多分に経験があります)
コンセプトの完全性を守るために
少数精鋭のチームを組む、アーキテクチャ(企画・仕様設計)とインプリメント(内部開発)を分ける、システムデザイン(目指すべき姿)を明確に全体共有する。
複数の章からエッセンスを抜き出すと、こんなところですかね。
自分に使える知見としてまとめると
コンセプトに余計な意見を混ぜず、必要なコミュニケーションを最小としたうえで、常に相互コミュニケーションを行いながら開発を進めていく…これが本著を元に構築した理想の姿と言えるでしょう。
翻って、冒頭の自分の状況を振り返ってみると…
コンセプトの完全性は、完全に失敗です。部品や検討ブロックの分割方法については、逐次担当者間で調整を行っていました。思想が違う、複数の人間で決めていたため、境界部分への認識があってなかったのですね。
コミュニケーション量も、失敗しています。部品ごとに取りまとめ役が明示されておらず、複数人が互いに複数のメンバー全員とコミュニケーションをとっており、多大なコミュニケーションコストがかかっていました。まとめ役を決め、他のメンバーはまとめ役との情報共有に勤める(基本的に1対1のコミュニケーションで済む)ようにしておけば、取りこぼしも少なかったかもしれません。
相互コミュニケーションも、こなしきれてなかったですね。メカ設計はCADで形状を見れば、他の人の検討状況が見えるものではありますが、全体アセンブリとして表示されているのは各自の検討データの一部のみです。*2そんなわけで、後になって「え？そういう風にケーブル引き回すの？」といったどんでん返しが発生するなど、余計な手戻りが生じました。
まとめると、人月の神話で言われていたダメなパターンをやらかしていた、と言えます。
大昔に書かれていた内容が今も通用すると驚くべきか、人(自分も含め)の進歩の無さを嘆くべきか…
まとめ
人月の法則、ソフトウェアプロジェクトの内容を元に書かれている本ではありますが、複雑性をもつプロジェクトなら、ソフトに限らず有効な知見が書かれています。
上記に紹介した内容以外にも、読み応えのある話に溢れています。「銀の弾などない」関連の話が、そうです。(新装版にしか入ってないのでご注意を)
この本について1つ難点を上げるとするなら、それは読みにくさでしょう。章ごとに主題が切り替わりますし、回りくどい表現も多い。そして当時のソフトウェア開発の現場を知らなければピンとこない内容が多分に含まれます。途中、僕も読み進めるのがキツかったです。
最初から通して読むと辛いので、まずは18章『「人月の神話」の命題ー真か偽か？』から始めることをお勧めします。何故かというと、この章はほぼ全体の要約だからです。冒頭にこれを持ってきてほしかった。。。
しかし、内容としては良かったです。ソフトウェアプロジェクトを超えてメカ設計にも言える内容ですし、メカ設計を超えて製品開発プロセスに適用できる内容です。コンセプトの完全性とか、今の時代の製品開発には欠かせない思想だと思います。
こんな記事も書いています。
