デッドラインを読了

トム・デマルコの『デッドライン ソフト開発を成功に導く101の法則』を読了した。この本では、ソフトウェア開発プロジェクトを成功させるための教訓や考え方が小説形式で書かれている。大いに学ぶところがあり、非常に面白い本だった。

私の上司も過去にこの本を読んだことがあるそうで、「デマルコは読んでおいて損はない」と言っていた。また「言えば貸してやったのに」とも言われた。身近に持っている人がいるとは知らなかったので、今回は自分で購入してしまった。しかし、十分元はとれる良書なので問題ない。

- デッドラインを読んだ理由

私はソフトウェア開発プロジェクトの運営や管理の知識に乏しい。雑誌の特集やコラム、情報処理技術者試験のテキスト、そしてウェブサイト程度でしか学んだことがない。ちなみに誌名を挙げておくと、日経コンピュータ、日経システム構築、ソフトウェアデザインなどだ。文献はほとんどと言っていいほど読んでいない。せいぜい XP (Xtream Programing) 関連の書籍を流し読みした程度だ。

今まではそれでも何とかなっていたが、最近はコードや SQL を書く仕事よりも、設計やチームの運営レベルの仕事が増えてきている。そういった仕事を担当する上で、知識や方法論・考え方の基礎が自分にないことは問題だと感じ、学習が必要だと考えていた。研修や勉強会に参加して学ぶのもよいが、まずは本を読むところから始めようと思い、この『デッドライン』を購入した。

- デッドラインで面白かった7つの点

本書は全編にわたって学ぶべきところが多い。その中でも私がとくに面白いと感じたのは以下7つの部分だ。

・正しい管理の4つの本質
・プロジェクトの数量化の必要性。すべての製品のサイズを測定せよ。
・プレッシャーをかけても思考は速くならない。管理者がプレッシャーを使うことが多いのは、他に何をすべきかわからないから。
・曖昧な仕様書ができる理由は、利害関係者間の対立が解決されていないから。
・設計をしていない開発チームと、なぜ設計をしないのかについての考察。
・部下を尊敬すること、気遣うこと、守ることが、プロジェクトにとっていかに大切か。
・良い目標は実現が難しいところに設定される。良いスケジュールは達成される可能性が高い期日で設定される。

いずれも自分の身の回りの問題として考えることができるテーマだ。とくに、曖昧な仕様書ができる理由と設計をしない理由についての考察は、ここ最近興味を持っているテーマでもあり、何回か読み返した。読んだ結果、設計は一般に考えられているよりも非常に範囲の広い作業であること、上流での設計の善し悪しが、プロジェクトに大きな影響を与えることを痛感した。

- 設計が重要

たとえば、業務の担当を決めるということは一見すると管理者の仕事である。しかし、管理という視点だけで担当を決めてしまうと、開発するシステムの質に大きな影響を及ぼしてしまう。

通常、担当者の決定はシステムの構成や機能の切り分けの後におこなわれることが多い。しかし、これは重大な間違いを含む。なぜなら、担当者を決めるためにまずシステムを切り分けてしまっているからだ。つまり、ここが非常に重要な設計の上流工程だったのだ。これに気づかずに安易に担当を決めたり、担当範囲を曖昧にしたままプロジェクトを開始すると、そのプロジェクトの成果物の品質は格段に落ちる。管理は設計の上流工程であるということを認識した上で、プロジェクトを進めることが必要なのだ。

考えてみれば、今まで設計について学ぶことは少なかった。多少学んだことはあるにしても、実装寄りの部分が多く、プロジェクトを進めるという観点からのものではなかった。デッドラインを読んだおかげで、自分に何が欠けていて、今後どんなことを学んでいくべきかがわかった。

- 一度技術から離れて本を読んでみることにした

今までは純粋な技術書を読むことが多かったが、これからしばらくの間、プロジェクト全体を円滑に進めるにはどうすればよいかという観点から、何冊か本を読んでみるつもりだ。