Engineer Life Book Review（3）
開発現場で悩むエンジニアにおくる6冊
2002/12/20
阿出川真広（ゼロソフト）
開発現場や開発プロジェクトには、さまざまな問題が横たわっている。開発リーダーやプロジェクトリーダー、さらにプロジェクトマネージャたちは、それらを解決するために、多くの時間を取られているだろう。もちろん、現場の開発者にとってもこの問題は人ごとではない。
そこで、こうした開発現場や開発プロジェクトにかかわる問題の解決のヒントとなるような書籍を6冊を紹介しよう。この書籍選びと執筆は、現役エンジニアにお願いした。「最前線で必要なスキルとキャリアを知る」の第9回に登場していただいた阿出川真広氏だ。
|
| 開発管理のヒントとなる古典 |
 |
人月の神話 新装版
狼人間を撃つ銀の弾はない フレデリック・P・ブルックス,Jr著、滝沢徹、牧野祐子、富沢昇訳 ピアソン・エデュケーション 2002年11月 ISBN4-89471-665-8 2900円（税別） |
古典ともいえる『人月の神話』を読むことで、現在の各種の開発プロセスやプロジェクト管理の源流を読み取ることができる。XPやAgile、それにRUPやCMMにも、新しい見方を与えてくれるだろう。
1995年に原著の刊行20周年を記念して増訂版として発売された本書は、3つのパート（時代）に分かれている。1つ目は、当初『人月の神話』として出版された部分。2つ目が改定時に追加された『銀の弾などない――本質と遇有』（1986年の論文）の部分。そして3つ目は、初版発行後の仮定や推論の誤り、訂正のほか、新しい技術との関係などを見直し、説明不足を補った部分だ。
こうした増補を重ねてきたのだが、私には1つだけ不満がある。それは、初版時に収録されていたエピローグのある部分「〜自分自身の誤りやすさ、また能力の限界をも認識できるという天性の人間的素質が必要である」という文がなくなっていることだ。誤りさすさと能力の限界、それを正しく認識することから始めることが大切だと思う。
本書からは、さまざまな言葉、キーワードを興味深く読むことができると思う。例えば、「遅れているソフトウェアプロジェクトへの要員追加はさらに（プロジェクトを）遅らせるだけだ」という「ブルックスの法則」や、「技術においても管理手法においても、それだけで十年間に生産性や信頼性と安易性での飛躍的な改善を1つでも約束できるような開発は1つとしてない」といった言葉は、エンジニアに重くのしかかるに違いないと思う。
| ソフトウェア開発の生産性向上はやる気にある |
 |
ピープルウエア 第2版
ヤル気こそプロジェクト成功の鍵 トム・デマルコ、ティモシー・リスター著、松原友夫、山浦恒央訳 日経BP社 2001年11月 ISBN4-8222-8110-8 2200円（税別） |
「思考は速くならない」とは、トム・デマルコの著書『デッドライン』（後述）にある言葉だ。これは、プレッシャーと生産性との関係における記述だが、開発全般に当てはまることではないだろうか。思考を減速することは簡単にできるほか、それ以外にも多くのブレーキに技術者は囲まれている。本書は、個人・開発チームを取り囲むブレーキの存在と外し方を教えてくれるものだ。
ソフトウェア開発の生産性は、コンピュータ性能の飛躍的な向上と言語／ツール／手法により着実に改善されている。しかし、生産性の格差は増大し続けている。人間のやる気がその差を左右するカギとなっている。開発環境を取り囲むブレーキは作業を減速させ、やる気を削いでいく。慣習となっている減速装置を取り除くのは困難だし、認知することすらも難しい場合もある。技術者も管理者もそれぞれの立場で認知するしかない。
発刊10周年を記念した第2版では、「変化」に関する項目が追加され、これはこれで非常に興味深い。「古い状況」と「新しい状況」の間には、「混乱」と「実践と統合」のステージが含まれるという。エンジニアにとっては、よく聞く話ではないだろうか？ 例えば、新システム導入時や変更時の教育やサポートが、いかに困難かを知らないマネージャはいないだろう。開発現場への新ツールや手法の導入時も同様だろう。
| ソフトウェアの品質管理について |
 |
ソフトウェア文化を創る
1 ワインバーグのシステム思考法 G.M.ワインバーグ著、大野徇郎監訳 共立出版 1994年8月 ISBN4-320-02706-X 3200円（税別） |
本書は『ワインバーグシステム』シリーズ全4巻（『洞察法』『行動法』『変革法』）の第1巻に当たる。
この本の原題は、『Quality Software Management, Vol.1. System Thinking』であり、ソフトウェアの品質管理が主題となっている。品質管理には「理解・観察・行動」の3つの能力が必要だと定義し、本書では、「複雑な状況を理解する能力」が書かれている。
システムは相互作用によって働く。システム開発自体も1つのシステムであり、1つのパラメータの変化はシステム全体に影響を与える。その影響は安易な期待を裏切り非線形となり戻ってくる。このように本書では、相互作用の体系やその考察手段を提示し、複雑な状況を理解するのを手助けしてくれる。
本書の特徴の1つとして、ハンフリー（Humphrey）の“プロセス成熟度”を基に、組織の中での人の扱われ方として6つのモデルを定義している点が挙げられるだろう（無意識・可変・慣習・かじとり・予知・適合）。同じ問題であっても、どこの段階にあるかによって認識と反応が違ってくると主張する。
最後の4章に当たる「欠陥パターン」は、ソフトウェアの障害を定義するうえでの欠かせない考察となっている。ここだけでも一読をお勧めする。
| プロジェクトが混乱する元凶は何かを考える |
 |
デスマーチ なぜソフトウエア・プロジェクトは混乱するのか エドワード・ヨードン著、松原友夫、山浦恒央訳 シイエム・シイ 2001年1月 ISBN4-901280-37-6 2200円（税別） |
デスマーチとは、ソフトウェア開発において次の1つ以上が発生したものをいう。それは、プロジェクトのスケジュールが半分以下に圧縮されたもの、エンジニアが必要な人数の半分以下のもの、予算やそのほかの必要資源が半分のもの、開発するソフトウェアの機能や性能などの技術的要求が通常の倍以上のもの。
このように不適当な見積もりや、変更を繰り返す要求や条件、もしくは無邪気なチャレンジによりデスマーチは引き起こされる。そして、ブルックスの法則が適用され、銀の弾（不慣れで現場に適合していないプロセス、手法そしてツール）が混乱をさらに増加させる。
しかしながら現実の世界は、デスマーチとなるプロジェクトが常態となっている（特に開発期間）。その中でプロジェクトは、どのようなプロセスを取り入れていけばよいだろうか。
本書では1つの解答として、「Triage」の導入を挙げている。最優先事項を絞り込んで順番に消化していく。限りある資源を最大限の効果を得られる形で配分するのだ。「すべてを完全に」。この一言が新たな破壊的なデスマーチを作り出している。戦略的にデスマーチを選択する必要があるのなら、一読をお勧めする。
| ユニークな図解でCMMの理解を助ける |
 |
CMMガイドブック――ソフトウェア能力成熟度モデル Keneeth M. Dymond著、高橋高志、前田卓雄、重岡毅訳 日刊工業新聞社 2002年3月 ISBN4-526-04819-4 3900円（税別） |
本書は文字どおりのガイドブックである。ユニークな図解が、難解で膨大なCMMのゴールと活動、およびそれらの関係の理解を助けてくれる。
『ピープルウエア』や『デスマーチ』を紹介した後でCMMを紹介するのは、ある意味勇気が必要だ。『ピープルウエア』は、衰退への道を歩むCMMアプローチを警告し、『デスマーチ』は、付帯作業の増加を指摘している。
しかし、CMMの生みの親といえるハンフリーが、「決まりきった見方が、改善への意欲を失わせ前進への妨げとなる。（中略）活動の実装方法を几帳面に心配しないことである」との言葉を「本書によせて」に記している。ぜひ、この言葉を忘れないでほしい。
本書は、CMMのプロセス改善を実践し、その活動から利益を得るためには適切なガイドブックだと思う。あなたがCMMの推進役となり、全体の方向を見失わないための道標になるだろう。
| XP（エクストリーム）を実践する際の参考に |
 |
XPエクストリーム・プログラミング入門
ソフトウェア開発の究極の手法 ケント・ベック著、長瀬嘉秀監訳、永田渉、飯塚麻理香訳 ピアソン・エデュケーション 2000年12月 ISBN4-89471-275-X 2100円 |
「エクストリーム」の本質は、「可能な限り全ての実践を徹底して相互作用を高める事にある」とされている。しかし、それを完全に実施できる環境は少ないだろう。そうした場合、まずは実施が適用可能なことから取り込み、それをできる限り拡大していけばよいのではないだろうか。
お勧めしたいのは、リファクタリングとそれを支えるテストである。これらには副次的な効果も大きい。テストを先に考えると入出力と内部処理の範囲・境界・特殊ケースを意識することになる。リファクタリングを繰り返すことは、プログラム構造、特にオブジェクト指向を理解するのに有効なはずだ。また、コードが洗練されるに従いステップ数が少なくなることを実感するのも価値があろう。見積もり根拠の1つとされるステップ数は、工数を掛けることで減るのだ。
ペアプログラミングも魅力的だ。レビュー効果やエゴ・ソースの所有意識に変化を与えてくれる。
しかし、これらを実践する場合、問題となるのはコストではないだろうか。「動いているプログラムを変更するコスト」や「テスト用のステップが増えるコスト」、そして「2人掛かりのプログラミングのコスト」。これらは中長期的な視点で考察してほしいものだ。もちろん、教育や技術取得という名目で行うこともできるだろうが……。
定常的な見直し（要求、見積もり、手法やプロセス自体）、変化の容認、コミュニケーション、エゴレス、適切な作業環境、Triage、20-80ルールなど、実際に使っている用語とは異なるかもしれないが、この書籍に掲げられているキーワードは、さまざまな形で現場で話題になることばかりだと思う。ぜひお勧めしたい1冊だ。
書評にある ボタンをクリックすると、オンライン書店で、その書籍を注文することができます。詳しくはクリックして表示されるページをご覧ください。 |
 |
Engineer Life Book Review |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
