ITエンジニア的な情報に浸っていると、「読書会」なるワードを見かける機会があります。他にも「もくもく会」とか、「勉強会」とか、ありますよね。どんな感じなんだろうなぁと興味を持ちつつも、参加の機会はありませんでした。自分に実務経験が無いのもあり、専門的な内容の読書会への参加がはばかられた部分もあります。

ある記事をはてなブックマーク経由で閲覧した時、『人月の神話』読書会、なるものを見つけました。そこから、CONNPASS経由で参加させていただきました。『人月の神話』の存在は知っており、興味があったので、丁度良かったです。人月の神話が技術書の中の分類としては、エッセイ的なもの（特定の言語やそのフレームワークを取り上げた本とは異なる）でしたので、参加もしやすかったです。
※本イベントを見つけた段階で、CONNPASSで参加者を募集している期限は過ぎていましたが、イベントページの問い合わせ欄から参加したい旨を連絡すると、承諾していただくことができました。感謝感謝。
※イベント当日までは参加登録できるだろうと勝手にたかをくくっていました。以後は募集期間をしっかり確認したいです。

『人月の神話』については、ご存知の方も多いと思います。そう、バベルの塔が表紙の難しそうな本です。 shinwa

読書会を概観しつつ、『人月の神話』について章毎に気になった内容をまとめていきたいと思います。

読書会について

※n=1の内容です。当たり前ですが、これが平均値や普通というわけではありません。

  • 参加者数：15名程
  • 時間：4時間程
  • 参加者層：年代性別色々（男性多め）。ITエンジニア的仕事をしている方々が集まった（私を除いて）。
  • 形式：1人ずつ、1ページを音読する。1人が音読中は、他の人はそれを聞く。気になる点があれば都度、共有・議論する。
    ※議論・共有は、読み進めている途中でも読み終わった後でも可。読み終わった後の方が多かったかな。
  • コミュニケーション方法：ZOOM、ビデオカメラの使用は必須では無いが半分くらいの人が共有、自分が話す時や議論する時以外はミュート設定にしている人も多かった
  • 進み具合：64ページ、1～6章

読書会に参加しての所感

  • 人月の神話を既読の人が半分程いたのですが、少し意外でした。読んだこと無い人が主に参加するのかなぁとなんとなく思っていたので。ただ、既読の人がいるからこの内容は飛ばすといったことはありませんでしたので、特段問題無かったと思います。既に読んだ人でも、あまり理解できなかった（理解を深めたい）人、随分前に読んだので内容を復習したい人等、色んな人がおりました。まあ、有名な作品ですし、既読の人が多いのもよくよく考えれば納得です。前の版を読んだけど、新装版は読んだことないという方もいました。
  • 原著は1974年に書かれており、その新装版が1995年に出版され、その英訳が日本で出版されたのが2014年です。この2014年に出版されている本が今回の読書会の対象となっています。文章のほとんどは約50年前に書かれた内容であり、一部の新しい箇所でも約30年前という状態です。「プログラム事務係」「電話の記録を残す仕組み」等、聞き慣れない文や単語も多くありました。そういった、現代と認識の差異が箇所について、ベテランの方が自身の経験や知識で内容を補填してくれるのは、嬉しい誤算でした（プログラムテスト実施方法の違い等）。
  • 主催者の方が仕切ってくれたのも良かったと思います。前述の通り、読書会の経験はありませんが、グループワークの経験は何度かあります。その経験からも、誰か、グループを取りまとめてくれるファシリテーター役がグループワークには必須のように思います（少なくとも気の知れた仲同士で無い場合）。議論が長引いたり、脱線しそうになった時はうまくコントロールして貰えました。ありがたいです。
  • 読書会の後、自由にコミュニケーションを取れる時間が1時間程ありました。残った人は半分くらいだったと思います。詳しい人が残ってくれている場合は、質問のチャンスですね。私も聞いてみたいことがありましたが、お知り合い同士？なのかな、会話の応酬がややハイスピードでしたので、切り出せずに終わってしまいました。私自身、素人として参加している以上は、その他の方の迷惑にならないように努めようと思っていたので、その辺からも難しさがありました。また機会があれば勇気を出していきたいですね。

人月の神話、いくつか気になった点まとめ

最初に当日読み終わった章のタイトルと画像の内容をまとめておきます。

    1章「タールの沼」タール沼の壁画  
    2章「人月の神話」ニューオーリンズのレストラン「アントワーヌ」のメニュー  
    3章「外科手術チーム」手術の様子  
    4章「貴族政治、民主政治、そしてシステムデザイン」ノートルダム大聖堂  
    5章「セカンドシステム症候群」航空交通用の回転する家  
    6章「命令を伝える」7つのトランペット
  1. 2人のプログラマがガレージで作ったプログラムが、大規模開発チームが最大限の努力で作り上げたそれを凌ぐ。それなら、常に小規模で開発するのが正解とならないのはなぜか。
  2. 人と時間が交換可能になる（人を導入すればその分時間が短縮される）のは、その作業に意思疎通を取らなくても分担ができる場合だけである（とても単調な作業など）。
  3. システム開発は上記に該当しないので、人と時間は交換不可能である。それどころか、人数が増えるほど、コミュニケーションのコストが増え、人を増やすほど必要な時間が伸びる減少が起こる。
  4. スケジュールが遅れている時、要員を追加する。追加人員には訓練のコストがかかる。訓練するのは開発チームの人であり、その人の開発の手を一時的に止めることになる。また、追加された人自身も、当然すぐに実作業に取りかかれるわけではない。ブルックスの法則が有名。
  5. 少数精鋭チームでの開発はコストパフォーマンスが高い。
  6. しかし、少数精鋭チームが非常に大きなシステム開発（5000人年）をする場合、時間がかかりすぎる（10年）。つまり、現実的ではない（冒頭の疑問に対する答え？）。
  7. システムデザインにおいてコンセプトの完全性が最も重要。
  8. 簡単かつ直截的（ちょくせつてき）なシステムが最高だ。片方だけでは駄目。 ※直截的の意味がわかりにくいですが、「迷いの無い」くらいに思っています。簡単と被る部分もありそうですが。

以上となります。 次回以降も、日程が合えば参加したいなと思います。