こつつみ

コツコツ積み上げる

「人月の神話」を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:Jr. ブルックス,フレデリック・P
  • 書籍名:人月の神話[新装版]―狼人間を撃つ銀の弾はない
  • 出版社:アジソンウェスレイパブリッシャーズジャパン
  • 発売日:2002/11/15
  • 頁 数:321ページ

本の目次

以下は本書の目次です。

  • 第1章 タール沼
  • 第2章 人月の神話
  • 第3章 外科手術チーム
  • 第4章 貴族政治、民主政治、そしてシステムデザイン
  • 第5章 セカンドシステム症候群
  • 第6章 命令を伝える
  • 第7章 バベルの塔は、なぜ失敗に終わったのか
  • 第8章 予告宣言する
  • 第9章 五ポンド袋に詰め込んだ十ポンド
  • 第10章 文書の前提
  • 第11章 一つは捨て石にするつもりで
  • 第12章 切れ味のいい道具
  • 第13章 全体と部分
  • 第14章 破局を生み出すこと
  • 第15章 もう一つの顔
  • 第16章 銀の弾などない ーー本質と偶有
  • 第17章 「銀の弾などない」再発射
  • 第18章 「人月の神話」の命題 ーー真か偽か
  • 第19章 「人月の神話」から二十年を経て

概要

1975年に書かれた本だが、今でも読まれているバイブル的な本。

正直、下の記事によく纏められている(長いけど..)

www.gixo.jp

なので概要と自分の思ったことをさらっと書いていく

第1章 タール沼

個人で作られたものが、企業で作られた奴より何倍も早く完成したという話があるが、実際に企業のプログラミングシステム製品にするには約9倍の労力がかかる。 これを忘れて見積もると大変なことになる。

タール沼については、プログラムを作ることは喜びもあるが、沼のような苦しみもあるぞということだと解釈した。

第2章 人月の神話

「人」と「月」は交換できない。人が増えるほど、コミュニケーションの労力をもたらし一人当たりの進捗は遅くなる。

著者の目安では、全体の半分がテストに充てられる。現在は、CI/CDやテスト駆動開発などでてきてマシにはなったものの、概ね当たっていると思う。

第3章 外科手術チーム

非常に優秀なプログラマは、経験二年目の人の何十倍の生産性をもつ。 外科手術チームのように、1人の優秀な執刀医(プログラマ)を支えるようにしてプロジェクトを進めるのが良いという話。

これは古い話なので参考にしなくても良いかなと感じた。(別の書籍の方で勉強しよう!アジャイルなど...)

第4章 貴族政治、民主政治、そしてシステムデザイン

コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点と主張している。

これは綿密にドメイン設計をすることが重要ということと解釈した。1975年でもドメインに焦点が当てられており、やるべきことはドメイン駆動設計だなと感じた。

第5章 セカンドシステム症候群

セカンドシステム症候群とは、MVPの後、二度目の開発(セカンドシステム)のデザインしすぎてしまう傾向がある。

MVP(Minimum Viable Produc)という名前は出していないが、MVP出した次のフェーズで開発しすぎてしまう問題を指摘している。 提案された改善点を率先して受け入れるためにも、変更容易性が大事とも書かれている。これにより自分の目指すべきは、やはり設計だなとも感じた。

第6章 命令を伝える

この章は設計書の話が主だった。内容が難しく、古さを感じるので参考にしなくてよさそう。

第7章 バベルの塔は、なぜ失敗に終わったのか

バベルの塔の失敗した原因は、コミュニケーションとそれから生まれる組織がなかったため。 チームは可能な限り多くの方法で互いにコミュニケーションを図るべきだ。つまり、非公式の会話や技術的な概要報告を行う定期的なプロジェクトミーティング、共用の正式なプロジェクト手引書などを通してだと主張している。

この本の時代はウォータフォールでの開発ではあるが、頻繁にコミュニケーションをとることはアジャイルじゃなくても必要なんだと再認識した。(当たり前だが、できていないので...)

この章で組織についての話は面白かった。 組織の目的は、必要になるコミュニケーションと調整作業の量を減らすことだ(中略)。 コミュニケーションを不要にする手段は、作業の分割と機能の専門化である。

自分は大企業にいて入社した時からもちろん組織・チームに分かれていた。 この分かれている目的を特に意識していなかったが、必要になるコミュニケーションを減らすことと考えると色々と組織構造に変だと思う部分があったり、無駄にコミュニケーションを増やしているケースなども見受けられたりする。 なので、これから先いかに他部署とのコミュニケーションを減らしてプロジェクトを進めていけるかなどの指針となりそうだ。

第8章 予告宣言する

コーディングの部分だけから見積もり、それからそれぞれ2章で出ていた比率を適用し、全体の作業を見積もるということは決してしないと誓う必要がある。 コーディングはせいぜい6分の1に過ぎないから

  • 投下工数の半分くらいは、プログラミングやデバッグ”以外”の作業に費やされる(書類作成や打ち合わせなど)
  • 他者とのコミュニケーションが発生しないとしても、プログラムの規模に応じて、必要工数は累乗で増加する
  • 相互作用(≒コミュニケーションの必要性)があると、プログラマの生産性は簡単に1/7くらいまで落ちてしまう

上記のような話があった。実際に体感とあっているので、工数を見積もる際には多めにバッファを用意しておく必要があると感じた。

第9章 五ポンド袋に詰め込んだ十ポンド

タイトルの意味は、金額にだけ気を取られるのではなく、それが「何をしてくれるものなのか」ということも併せて考えなくてはならない。つまり、それまでかけたお金と引き換えに、使い勝手やパフォーマンスがどれだけ得られるかということであり、このお金は他のアプリケーションに使ったほうが、もっと有効であったのではないだろうかということである。

自分たちで作らないで、他所から買うという選択もあるぞ!ということを言っている。 「トレードオフ」を理解し、何をどの程度優先するかという”考え方”が重要。そして、それに則った”意思決定(をするという姿勢)”が大切。もちろん、世の中には様々な選択肢があり、さらに厄介なことに、似たようなシチュエーションであっても、実際には、都度都度、微細な条件が変化している。そんな中で「どのように考え、どのように意思決定するか」ということが、物事を正しい方向に進ませるためには欠かせない。

第10章 文書の前提

文書を書く意味について語っている。

以下は、第15回:メモリが安くなったからといって「無限」だとは思わない方が良い|本気で読み解く”人月の神話”(第9章「5ポンド袋に詰め込んだ10ポンド」) - GiXo Ltd. の引用。

大抵の場合、その経験則に従って行動すれば物事はうまくいきます。ただ、その経験則も「きちんとデータで検証されるべき」であったり、「最新情報に更新されるべき」であったりすると思うのです。 勘と経験が悪いのではありません。勘と経験を最新化しないことが問題なのです。そしてそれは、現場を離れて管理職・経営者となった後には「データを用いて最新化するしか選択肢がない」のです。本章で論じられた3つのシチュエーションには含まれていませんが、「経営」というシチュエーションにおける「文書」には経営分析レポート・事業分析レポートなどが含まれていてしかるべきだ、ということになるでしょうね。

文書化により、自分の思考(また、他のメンバーの知識)をアップデートすることが目的。記憶なんて、ほとんど忘れてしまうからね...

第11章 一つは捨て石にするつもりで

この章は、19章(20年後)で、間違っていたと言っているので、参考にしなくて良い。

第12章 切れ味のいい道具

プロジェクトの共通ツールを作ることは良いことだ。プログラマ個人用のツールは、各個が違うツールを使うことによりコミュニケーションの妨げになるので、汎用的なツールは共同で開発・メンテナンスするのが効率的。

後半は、古い話で参考にならなそうだった。チームのツール(botや自動生成など)を作るのは、やっていきたい。

第13章 全体と部分

多くのバグはサブシステム間のデータの受け渡しに関するもの。製品のコンセプト(サブシステム間のインタフェースや受け渡されるデータ構造の設計指針をシステムとして統一する)をはっきりさせることにより、サブシステム間のデータの受け渡しに関するバグを減らすことができる。あとは、デバッグのためにダミーを作るなどの話をしている。

古い話も多かったが、今でも話の内容は間違っていないと感じる。上の話があるので、マイクロサービスやAWS Lambdaなどのサーバレスアプリケーションが流行っているのだと理解した。

第14章 破局を生み出すこと

  • プロジェクトは突発的な不運が起こって遅れているわけではない、一日ごとに徐々に遅れている
  • マイルストーンは具体的かつ明確で測定可能なイベントとして定義しなければならない。そして、進捗をごまかしてはならない
  • スケジュールは直前になるまで変更されないのがほとんどである
  • ハッスルプレイ(求められている以上に速く走ったり、機敏に動いたり、一生懸命になるといったもの=一日の遅れにもやっきになる)は、プログラミングチームにも必要不可欠だ。
  • クリティカルパススケジューリングが、どの遅延がどのくらい問題なのか理解するのに役立つ

もちろん遅延は起こるものです。しかし、それは「まあいいや」ではなく、「起こるべからざることが起こっている」という認識で、周囲に共有され、必要に応じ、然るべき対策が講じられるべきなのです。 というわけで、大事なのは「遅延を隠さない」ということです。

上の話は肝に銘じたい。「風通しの良い組織」を作ることが、情報隠匿を排除し、結果的に、致命的な遅延を防ぐことに繋がるのだろう。

第15章 もう一つの顔

プログラムには、機械に対する命令の羅列という顔の他に、人間が理解するためのドキュメントとしての顔がある。

kotsutsumi.hatenablog.com

上の書籍では、コードを文書化するという話があった。あんまり納得はできなかったが、アリなのかもな。という気になってきた。

第16章 銀の弾などない ーー本質と偶有

ソフトウェア開発における「むずかしさ」は、本質的なものと偶有的なものに分けられる、とブルックス氏は述べる。

  • 本質的なむずかしさとは、ソフトウェア開発に固有のものです。
    • 複雑性(ややこしい)
      • ソフトウェアの大きさに従って、非線形に複雑性が増加する
      • これにより、問題が多発する
    • 同調性(他と合わせる必要がある)
      • 他のインターフェースに従うことにより、複雑性は増加する
    • 可変性(常に変化することが求められる)
      • 絶えず変化し続けるもの。その変化がソフトウェアに変更を強制する。
    • 不可視性(リアルなものとして捉えられない
      • ソフトウェアは目には見えない。
  • 偶有的なむずかしさとは、事象としては実際に難しいものの、別にソフトウェア開発だから難しいってわけではない、というような事象です。 これは、ソフトウェア開発の歴史の中で、少しずつ解決されてきました。(もちろん、この”偶有的むずかしさ”さえも、まだ完全に解決していないが故に「銀の弾がない」という結論に至っているわけですが)
  • その解決の歴史として3つ述べられている
    • 高水準言語(機械語からの脱却による”概念”の世界でのプログラミングの実現)
    • タイムシェアリング(リアルタイム処理による”思考を妨げない”)
    • 統一されたプログラミング環境(統合ライブラリ等によって”概念構造体”としてプログラムを捉えることができるようになった)

現在は偶有的な難しさはどんどん解決されてきているので、本質的難しさに目を向けるべき。これは、ドメイン駆動設計やアジャイルの考え方が効いてくるのでは?と思った。

第17章 「銀の弾などない」再発射

第3回:反論に対する反論|本気で読み解く"人月の神話"(第17章:前半) - GiXo Ltd.

第4回:再利用って口で言うほど簡単じゃないんだよね|本気で読み解く"人月の神話"(第17章:後半) - GiXo Ltd.

この記事に書いてあることがほとんど書きたかったこと。その中でも良いところをピックアップする。

「インプリじゃなくて、設計段階・構想段階なんだよ、難しいのは」ってことです。「何を作るのか」が一番難しい、と。

偶有的(副次的)な問題が数多く解決されてきた今、本質的な問題に取り組むべきだ

  • 複雑性(ややこしい)
  • 同調性(他と合わせる必要がある)
  • 可変性(常に変化することが求められる)
  • 不可視性(リアルなものとして捉えられない

これはドメイン駆動設計でいうモデリングのこと。設計力をつける必要があると感じた。

第18章 「人月の神話」の命題 ーー真か偽か

ここは各章のまとめが書かれている。初めて読む人は、この章から読むことで大体の話を掴むことができるので、最初に読むのが良いだろう。

第19章 「人月の神話」から二十年を経て

  • 正しかったのは、以下がが挙げられます。

    • コンセプトの完全性が成功の鍵であること
    • その、コンセプトをしっかりと構築するために、アーキテクトを任命し、アーキテクチャとインプリメンテーションを分離すること
    • セカンドシステム症候群、すなわち、「後継システムの開発」には、大きなリスクがあること
    • そして、もっとも重要な命題である「人月の神話」は、やはり神話であったこと
      • 新たな要員を追加すると、キャッチアップに数週間の時間を要することから、「要員を追加しても、納期短縮にはつながらない」と述べます。もちろん、「遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない」という話は持ち出すものの、そのためには「プロジェクトの初期段階で要員を追加するべき」と述べています。
  • 一方、自己反省として、正しくなかったこととして挙げられるのは、以下です

    • 一つは捨石にする、という発想(前提としていたウォーターフォール型開発そのものに限界があったため)
      • 少しずつ加えていく改良(漸増的構築)が良い
    • 情報公開・共有こそ是である、という考え方(カプセル化は非常に有効だと分かったため)
      • パッケージソフトは、すでにテストされており、詳細なドキュメントが添付された上に、完全に「情報隠匿」もなされています。再利用性という意味で「完璧」です。「つくらなくていいものは、つくらない」「すでにあるものは、そのままつかう」という基本思想に基づけば、パッケージソフトこそ、生産性向上の鍵です。

最後に

ドメイン駆動設計のようにドメインの複雑さをいかに分かりやすくするかが肝になってくると感じた。

つまり、設計の重要性をより一層感じることができ、ドメイン駆動設計の有用性がわかった。

今後やっていくべきは、ソフトウェア問題の本質(複雑性、不可視性、同調性、可変性)に取り組むこと。ドメイン駆動設計が解決できると思うので、実際に手を動かしてみる。