[2008 年 9 月号]

［技術書籍紹介］

「新・ソフトウェア開発の神話 - 成功するプロジェクトチームの科学と文化」 ジョー・マラスコ 著 藤井 拓 訳 翔泳社 3,780円（税込み） ISBN4-7981-1042-6

	目次
	著者紹介
	本書のアピールポイント
	内容紹介

目次

第 1 部 一般的な管理

第 2 部 ソフトウェアが違うところ

第 3 部 プロジェクト管理の視点

第 4 部 人的要素

第 5 部 水平に考える

第 6 部 進んだトピック

ページのトップへ戻る

著者の紹介

本書の著者ジョー・マラスコさんは、90年代初頭に Rational Software 社の主力製品だった Apex という Ada の統合開発環境を独自ハードウェアからUNIXに移行させるという社運を賭けたプロジェクトの責任者だった人間である。マラスコさんは、このプロジェクトを反復的な開発アプローチの実践により成功へと導いたのである。その成功が無ければ、Rational Software社は大きな収入源を失い、後年に統一モデリング言語 (UML: Unified Modeling Language) を取りまとめたり、ラショナル統一プロセス (RUP: Rational Unified Process) などを製品化したりするなどの取り組みは不可能だったかもしれないのである。このエピソードで、マラスコさんの本分がプロジェクトを成功させることであり、方法論者や研究者ではないことを少し理解して頂けるのではないかと思う。

本書のアピールポイント

本書は、そのようなマラスコさんがプロジェクト管理者やソフトウェア開発組織の責任者として悩んだ以下のようなことを、解決するための手段や理論を書き記したものである。

• 遅れているプロジェクトに要員を追加した場合の影響はどうなるか
• 開発者と管理者の双方にとって働き甲斐がある組織や風土をどのようにしたら作れるか
• プロジェクト内外で対処しなければならない政治をどのように考えるべきか
• プロジェクトはどのように失敗し、失敗しかけているプロジェクトはどのようにしたら救えるのか
• プロジェクト管理者として自分はどのように成長し、新しい技術と向き合うべきか
• 品質、コスト、納期等は互いにどのように影響を及ぼしあうか
• 以上述べたような悩みを解決する手段と理論をどのようにしたら得ることができるか

　プロジェクト管理の世界でこのような悩みに対峙することが多いが、これらの悩みに真正面から向き合うことはあまりなく、ひたすら「精緻に管理する」ことや「根性でどうにかする」ことも多い。言い換えると、失敗しそうなプロジェクトだと感じていても、「精緻に管理する」ことや「根性でどうにかする」ことでプロジェクトを進めてしまうのである。それは、おそらく感覚的には「無茶」だとか「不合理」だとか思うプロジェクトでも、その「無茶さ」加減や「不合理さ」をうまく上司や開発依頼者に説明できないことも大きな原因になっているのではないかと思う。本書は、そのような「無茶」や「不合理さ」をプロジェクト管理者が把握し、その上司や開発依頼者に説明するのに役立つと期待できる。より積極的には、プロジェクトの成功と失敗を隔てる根本的に要因を理解し、技術者とともにやりがいのある、「3Kではない」開発組織を築くために本書は大きなヒントになるのではないかと思う。

内容紹介

第 1 部 一般的な管理

　ここでは、この本の成り立ち、マラスコさんが受けたエンジニア教育を説明し、次いでソフトウェアに特化しない一般的なマネージャーが直面する問題やそれを克服するために身につけるべきことを説明している。

• 第 1 章 序章への扉
• 本書の一連のエッセイは、ソフトウェア開発に一般的な問題に対するマラスコ氏の解答をまとめたものである。自分自身の体験や考えから、どのようにしてそれらの解答を導き出したのかを説明している。
• 第 2 章 計算の原点
• コンピュータの黎明期だった60年代に米国では理系の大学を志望する人間が多く、そこで育成された多数のエンジニアが今日のシリコンバレー繁栄の土台を築いた。その当時、なぜそんなに理系の志望者が多く、その人たちがエンジニアとしてどのような教育を受けたかを説明する。
• 第 3 章 登山する
• 登山とソフトウェア開発のプロジェクト管理には多くの類似点がある。その類似点を説明し、それらに共通する成功、失敗パターンを述べる。
• 第 4 章 管理する
• チームを成功に導く力を持つマネージャーになるための10ヶの秘訣を説明する。

第 2 部 ソフトウェアが違うところ

　一般的な管理では扱われないソフトウェアに特有の事柄にマネージャーとしてどのように対応し、ソフトウェア以外の分野の人（たとえば経営陣）にどのように説明すればよいかという点を説明する。

• 第 5 章 もっとも大切なこと
• 反復的な開発アプローチの技術的な利点とビジネス上の利点を経営者や管理職に分かりやすい形で説明する。
• 第 6 章 モデリング
• UMLのような共通のモデリング言語がなぜ役立つのかを分析も設計も知らない聴衆にどのように説明すればよいのか。
• 第 7 章 コーディング
• • 次々と登場する新しいプログラミング言語をマネージャーといえども知らぬ存ぜぬで通してよいのか？
• 第 8 章 ドアの外に送り出す
• お客様に納品するソフトウェアは、開発チームの各自が作ったものを統合するためのビルドプロセスにより作り上げることができる。このビルドプロセスを作り上げる上で、政治、プロセス、ツールの3つの障害に直面する。

第 3 部 プロジェクト管理の視点

　ソフトウェア開発のプロジェクトを管理する際に直面するQCD(品質、コスト、納期)のトレードオフ、反復期間の設定などの基本的な事柄から出発し、日程の見積もりの人毎のばらつきや開発途上にプロジェクトに作用する力などについて論じている。

• 第 9 章 トレードオフ
• プロジェクトのQCD(品質、コスト、納期)の間にはトレードオフがあるという話は良く知られている。このQCDの3角形をマラスコ氏はさらに拡張し、プロジェクトの成功を左右する複数の因子の間にどのようなトレードオフがあるのかについて簡単な幾何学的なモデルで説明する。
• 第 10 章 見積もりをする
• この章のタイトルから精度の高い費用や労力の見積もりを行う方法が説明されているのではないかと期待するかもしれない。実際には、開発期間に応じて反復の回数や期間をどのように考えたらよいかということが論じられている。
• 第 11 章 スケジューリング
• プロジェクトマネージャーの中には、安全を見て日程を立案する人もいれば、最初から無謀な日程を立案する人もいる。この観察結果からどのようなことが導き出されるのか。
• 第 12 章 リズム
• 順調に開発が進んでいるプロジェクトには一定のリズムがある。そのリズムを支配するものは何かという点についてマラスコ流の考えを披露する。

第 4 部 人的要素

　開発組織であっても人間の集団であるがゆえに、プロジェクトや開発組織を率いる上で政治、交渉、約束など人間の間の相互作用を理解するということが大事である。

• 第 13 章 政治
• エンジニアは政治的なことを毛嫌いするが、よく考えると政治的なことにも「良いこと」、「無害なこと」、「悪いこと」の 3 種類がある。「悪い政治」こそは、マラスコ氏の理想とする信頼に基づく組織を壊す危険なものなのである。
• 第 14 章 交渉する
• エンジニアがマネージャーの依頼を気軽に引き受けないことも多い。それは、そもそもエンジニアとの話し方をマネージャーが理解していないからなのだ。
• 第 15 章 約束する
• ソフトウェア開発において、約束された期日にソフトウェアができていないことが良くある。その一因は、「約束する」ということの意味についてソフトウェア開発に係る人たちの認識が他の分野の人たちの認識とずれているからだ。
• 第 16 章 処遇
• 開発者の能力や職務の難しさと処遇の関係についてマラスコ氏の考えを披露する。エンジニアがより能力を発揮するためには、処遇を改善する以外の手段はないのだろうか。

第 5 部 水平に考える

　ソフトウェア開発のプロジェクト管理とは直接関わらない様々なテーマに関するマラスコ氏の意見や考察を紹介する。

• 第 17 章 歴史の教訓
• 進水して港を出るまもなく沈没した戦艦バーサ号を取り上げ、そのような大失敗がどのようにして生じたかを解説する。
• 第 18 章 悪いアナロジー
• ニュートンの運動方程式やアインシュタインの特殊相対性理論などの物理法則を日常会話でどのように間違って引用しているかをマラスコ氏が斬る。
• 第 19 章 リフレッシュ問題
• 携帯電話のようなモバイル機器のソフトウェアをアップデートするためのマラスコ流の妙案を説明する。
• 第 20 章 それほどランダムでない数
• 難破して無人島に着の身着のままでたどり着いたあなたは、救出されるまでどのように時間を過ごすか。マラスコ氏の化身であるロスコーとその友人のマンデーは、無人島でベースボールカードゲームを楽しもうとした。さて如何に。

第 6 部 進んだトピック

　１つのプロジェクトのプロジェクト管理から離れて、開発組織全体を強力にする（弱体化させない）ために注意すべきことをなんだろうかということについてのマラスコ氏の考えを説明する。

• 第 21 章 危機
• いけすで泳ぐ魚が売り物の料理屋で、魚が次々と死に始め、客がどんどん離れていった。その危機を火消しはどのように解決するのか。
• 第 22 章 成長
• 遅れているプロジェクトに要員を追加したら、プロジェクトがさらに遅れるという有名なブルックスの法則[1]を表現する簡単な数式モデルをマラスコ氏が提示する。マラスコ氏のモデルは、プロジェクトのみならずソフトウェア開発会社の成長を考える参考にもなる。
• 第 23 章 文化
• 文化には、強い文化と弱い文化がある。信頼に基づく組織が成り立つためには強い文化が必要だが、そのような強い文化をどのようにしたら作り上げることができるか。
• 第 24 章 すべてをまとめる
• エンジニアの成長を考えるうえで、3 つの段階を考えることができる。それらの段階の特徴はどのようなものであり、どのようにしたら次の段階に移れるのか。

参考文献

• [1] フレデリック・P・ブルックス.Jr, 人月の神話―狼人間を撃つ銀の弾はない（新装版）, ピアソンエデュケーション, 2002

ページのトップへ戻る

© 2008 OGIS-RI Co., Ltd.

HOME TOP