スティーブ・マグワイヤ『デバッギング ザ デベロップメントプロセス』アスキー出版、1995年12月

■読むきっかけ

  • 以前、開発担当だったときにたまたま本書を店頭で手にとり、興味深く、同意しながら読んだ覚えがあること
  • 現在、改めて委託によるシステム開発を担当することになり、システム開発の要点をおさらいしておきたいこと

■内容【個人的評価:★★★★−】

  • 開発チームにおいて、基本的な誤りが繰り返されるという現象に気づいた。一方で、プロジェクトリーダーは、コーディングばかりに時間を費やし、肝心な仕事であるプロジェクト管理をしていないことがわかった。リーダーは「指導者」としての教育を受けていない、指導者になってから学ぼうとするのは少し遅い。
  • しかし、基本的なテクニックと戦略をマスターすれば、長時間働かなくても高品質でバグのないソフトウェアをスケジュールどおり出荷することは可能である。

○第1章「基本原則の設置」

  • むかしから、試練と過ちを積み重ねることで人は権威と呼ばれるような浅く広い知識を身に付けてきた。しかし、これを積極的な学習を通じて劇的な速度で身に付けることは可能である。
  • 「製品の向上に結びつかない活動は無駄」という認識を持ってほしい。そんな活動の代表として「会議への参加」や「報告書の作成」などがある。逆にプロジェクトリーダーはそうした障害を取り除くよう努めるべきである。
  • リーダーはつねに最終的に到達すべきポイントは何かということを念頭におくべきである。また、具体的で明確な目標を掲げることが有効である。

○第2章「体系的なアプローチ」

  • バグの修正は根本的な問題である。バグの修正は決して後回しにしてはいけない。
  • 電話などで作業が中断されることは望ましくない。電子メールを積極的に活用した方がよい。ただし電子メールを確認するのは、1日に2〜3回程度にするべきである。
  • 問題が生じたときに、その過ち/経験から、なぜそうしたことが起きたのか問い直す習慣を付けてほしい。
  • 一般的にプログラマから忌み嫌われている「goto」文であるが使い方によっては、分かりやすさにつながることがある。一般に信じられているからなどの理由で、旧来のやり方にとらわれてしまうのは賢明ではない。

○第3章「戦略の重要性」

  • 毎日の始まりの10〜15分に「あと数カ月プロジェクトを軌道に乗せておく手助けとして自分に今日できることは何か」を問い直してほしい。的外れな問題でなく本当に必要な問題に対処すべきである。
  • バグを摘出するためにもっとも有効な手法は、デバッガにブレークポイントを設けてどこでデータがこわれたのか確認することであり、ソースコードを追いかけて探すのは怠惰かつ無能な行為である。
  • 守れないとわかっている期日を約束してはいけない。また、上司からの熟慮を欠いた提案を請け負ってはいけない。
  • 技術的な挑戦とか楽しいなどというだけで機能をインプリメントしてはいけない。

○第4章「解放による熱気」

  • よく考えてみると本当に必要なのかどうか疑わしい作業が求められていることがある。たとえば「ポットローストの切れ端の謎」のように、続けておこなってきている作業でもよく考えてみるとすでに必要のない作業であることもある。

○第5章「狂気のスケジュール作成」

  • スケジュールは本当に妥当なものかよく検討される必要がある。逆に、それほど根拠のない最終期限を守るために製品をだめにしてしまってはいけない。
  • 大きなプロジェクトを運営するために有効な手法として、サブプロジェクトへの分割と2カ月毎のスケジュール作成ということがある。つまり大きなプロジェクトを2年かかるものとすると、2カ月単位のサブプロジェクトで2カ月おきに製品を出荷していたということになる。

○第6章「安定した、絶え間ない向上」

  • プログラマの能力向上は非常に重要、プロジェクトの新しい分野に挑戦させることが必要だ。また、熟練者についても伸び悩んでいれば新しい学びの場を与えるために表に出してやる必要がある。
  • チームのどのメンバーも少なくとも2カ月に1回は重要な技術を学んでいることを確認する必要がある。良い本にめぐり合えば、誰かが数十年かかって到達したことに数日で到達できるのだ。
  • 重要な態度として、改良が必要な部分はすぐに正しく改めるということがある。

○第7章「すべては心構えから」

  • バグのないコードを書くのは大変だという認識を持つことが重要である。
  • また、「どうせ無理」という姿勢が改革を妨げるのを許してはならない。また、ユーザーはそれほど品質を気にしていないという認識をプログラマに持たせてはいけない。
  • 標準に満たない機能を出荷してはいけない。あるべき姿にインプリメントされるまで出荷を見合わさないといけない。プログラマは、エンドユーザーの感覚に敏感でなくてはいけない。

○第8章「沈没していく感覚」

  • プロジェクトが遅れているときは何かが間違っている。これを過重労働で埋めようとしてはいけない。何が原因なのか良く見きわめること。逆に長時間労働は品質を確実に低下させる。
  • 必死に働くな、必死に頭を働かせよ。
  • リーダーは、自分をチームメンバーの上司ではなく、メンバーの一人と見るべきである。

■読後感
アメリカという国の強さ、英知を見せつけられる本であると思う。どこに典型的な問題があるのか、何が解決の秘訣なのか経験に基づいて説明している。
ただし書いてあることを額面通り行うということでなく、自分のおかれた組織や仕事の流れをふまえてもっとも効果的な手法を頭を使って考えるということだろう。