|
「達人プログラマー システム開発の職人から名匠への道」
The Pragmatic Programmer
Andrew Hunt and David Thomas
ピアソン・エデュケーション(2000)
評価：★★★★
実際の開発経験に基づく、実践的な開発手法。役に立ちそうなアイディアがたくさん詰まっている。あなたの開発手法が先端の開発チームからどのくらい遅れているかのベンチマークにもなり、開発者に強く勧める。DRY、直交性、リファクタリング・・・すぐにでも使いたいものがたくさんある。あなたが読めば、また違った発見が必ずある。
「XP エクストリームプログラミング 入門」
Kent Beck
ピアソン・エデュケーション(2000)
評価：★★☆
Amazon.comでソフト関係の本を何冊か買ったことがあるのだが（本棚でも紹介した、McConnell、Black、DeMarcoやWiegers）、その私に対する現在第一のお勧めに、この本があがっていた。Amazon.comでの評価は４つ★である（5点満点）。書店で翻訳を見つけたので早速買った。
私なら、この本で述べられている手法を、究極のプログラミングと言う勇気はない。著者も言うように個々の手法は、昔から言われていることである。著者がこの方法で成功したのは、プロジェクト規模が小さかったことと、コンペティタがいなかったからではないか。所々、共感できる部分もあるが、かなり読みにくい本である。ペアを組んで作業する方法や、テスト可能にするためにコードをシンプルにする等、参考にできそうなところもある。レビューやインスペクションについて、ほとんど述べていないところが面白い。
「コードコンプリート」
STEVE McCONNELL(1993)
アスキー出版局(1994)
評価：★★★★
この９００ページを超える大著は、例のMicrosoft
Pressの一冊である。ソフトウエアのインプリ工程を中心とし、関連する品質保証、検査、プロ意識の話題を含んでいる。「マイクロソフトシークレット」の著者らは、マイクロソフトの人間はソフトウエア工学を勉強していないといっているが、本書の著者は勉強家である。巻末には300冊を超える参考文献がある。
「ライティング ソリッドコード」
－バグのないプログラミングを目指して－
WRITING SOLID CODE
STEVE MAGUIRE(1993)
アスキー出版局(1995)
評価：★★★★
MAGUIREによる実践的コーディング、テストのテクニック。
「ソフトウエア技術レビュー・ハンドブック」（1977,1979,1982）
Ｄ．Ｐ．フリードマン/Ｇ．Ｍ．ワインバーグ
ＴＢＳ出版会（1987）岡田正志監訳
評価：★★★★☆
古い本ですが、レビューに関する古典です。Ｑ＆Ａ形式のソフトウエア・プロダクトのレビューに関するアドバイス。レビューの目的に関し、実にはっきりとした、そしてすっきりとした見解を持っている。ありとあらゆる、起こるであろう問題を想定していて、その回答が非常に論理的である。読んでいて、「そうだ、そのとうりだ！」と言いたくなる。我々がこのようなノウハウを独自に蓄積するには、楽観的にみても数年はかかるであろう。しかし１９７７年に出版された本書が我々にとって非常に参考になるということは、２０年遅れているのだろうか？後半、具体的なレビューのための判断基準がでてくるが、本書のノウハウの基礎となっているのがＣＯＢＯＬで書かれたファイル・アクセス・システムらしいので、我々のレビューにそのまま適用できないのが残念。だが、それは怠慢というものであろう。我々は対象に合った基準を作成するべきである。（そして、もちろん基準はレビューされるべき。）
わけもわからず、レビューに参加させられて不満を持っている人（この忙しい時に、なんだ！）に読んでもらいたい。内容は、そう易しくはないのだが、Ｑ＆Ａ形式で短くまとめられ、とても読み易い。
「アンチパターン」W.J.Brown,R.C.Malveau,H.W.McCormick &
T.J.Mowbray
ソフトバンク(1999)
評価：★★★
ワースト・プラックティスをまとめたもの。「ソフトウエア開発のアンチパターン」「ソフトウエアのアーキテクチャのアンチパターン」「プロジェクト管理のアンチパターン」に分類されている。もともとオブジェクト指向開発のためにまとめられたものだが、本質は、そうでない開発にも十分通用する。他のワースト・プラックティス物と違うところは、症状だけでなく、原因の分析、例外、解決法などを併記している点であろう。耳の痛い話が多いが、序文に次の言葉がある。「あなたは、真実に堂々と直面できるタイプだろうか？一般的にいって、他人に真実を理解させることは非常に難しい。真実の指摘は往々にして、余計なでしゃばりとみなされたり、他人への無理解や思いやりのなさと思われたりする。世の中がまるくおさまるためには真実を語ってはならない、ともいわれる。真実は、一部の人々を不愉快にする。」原書の副題は”Refactoring
Software,Architectures and Projects in
Crisis”で、いわば危機的な状況にある、ソフトウエア、アーキテクチャ、プロジェクトを再編（本訳書では再構想と訳している）するというものである。
「え～、全部テストするんですか！」
山村吉信
三元社(1999)
評価：★★☆
ＩＢＭの山村氏のソフトウエアのテストと統計的手法を応用する場合の理論的な背景を具体例を使ってわかりやすく解説している。題名から画期的なテスト手法を期待したりすると肩透かしをくう。著者はホワイトボックステスト、ブラックボックステストのいずれも問題があることを示し、統計的なテスト管理手法を提案する。Ｎ本の母体からｍ本を取り出してテストし、ｋ本にバグがあった等とやるのだが、前提となる仮定が現実的ではないように私には思える。しかし、では大量のテストをどうするのかと言われれば、私は明確な答えを持ち合わせていないのだが。
「ソフトウエア・テストの技法」
The Art of Software Testing /Glenford J. Myers(1979)
近代科学社(1980)
評価：★★★★
テスト技法に関する古典。なぜもっと早く読まなかったのかと後悔している。テストにかかわるすべての人に薦めたい。理論面に偏ることなく、心理学的、経済学的な考察も貴重である。数学の証明のように、論理を追うのに少々疲れるところもあるが、結論だけにでも目を通す価値は十分ある。
"MANAGING THE TESTING PROCESS"
Rex Black
Microsoft Press(1999)
評価：★★★☆
マイクロソフトでは開発者１人につきテスト担当者が１人いるそうだが、そのマイクロソフトプレスからのソフト、ハードのテストに関する実践書。理論を解説した本ではなく、コンサルタントとしての著者の経験から導かれた方法論、経験談である。当然と思われることもたくさん書いてあるのだが、時々、「これは使えそうだ」というアイディアがきらりと光るところがある。扱っている範囲は、
・テスト計画（２章）
・テストシステムのアーキテクチャ：項目とカバレージ（３章）
・バグ追跡データベース(４章）
・テスト項目管理：テスト状況追跡スプレッドシート（５章）
・危機的場面での変化する状況の管理（６章）
・実験室を確保し管理する(７章）
・人を集め、テストチームを管理する(８章）
・テスト管理者の組織内でのチャレンジ（組織間の政治問題）(９章）
・テストプロジェクトを分散する（１０章）
「パーソナルソフトウエア プロセス技法」
Watts S. Humphrey
共立出版株式会社(1999)
A Discipline for Software Engineering(1995)
評価：★★★
CMMモデルで有名なSEIのハンフリーの著作である。CMMがプロジェクトや企業のソフトウエア開発プロセスの改善モデルであるのに対し、PSP(Personal
Software Processである。Paint Shop
Proではない)は「大規模ソフトウエア開発に必要な個人レベルのソフトウエア工学スキルを身につける」ことを目的とする。また3つ目の柱として（私は詳しくないが）TSP(Team
Software Process)と呼ばれる、チームに対するガイドがある。
PSPは簡単に言えば、個人が自分のソフトウエア開発において、様々な記録をつけ、測定を行い、それを統計的手法により分析して、プロセス改善に繋げる枠組みを提供している。
ハンフリーのアプローチは抽象的なレベルでは理解できる。過去の経験から将来を予測可能でコントロール可能にしようというのである。が、7章まで読んで、様々な疑問がうかんでくる。まだ全てを読んだわけではないので、勘違いがあったらお許し願いたい。
(1)個人の限られた計測データを統計的に処理して意味があるのだろうか？計測値は作成するソフトウエアの種別や領域と個人の経験との関係に密接に依存するのではないか？ちなみに現在までの演習問題で得られた私のデータは意味のある相関関係がないという結果に終わっている。
(2)ハンフリーは測定結果を使ってプロセスを変えないかぎり、改善はないとしている。ここで言われているプロセスを変えるとは、具体的にどういうことを意味するのだろう？PSP0からPSP1、２，３に至る進化のことをいっているのだろうか？各PSPのプロセス自体はウォーターフォールを前提としてかなり具体的に定義されたプロセスのように見受けられるが、そこまで決められると後はどういう改善が残されているのであろうか？
(3)ソフトウエア開発において、規模や工数を見積もることが最も重要な要素なのであろうか？例えば企業が開発者に対してPSPを適用させようとした場合、これは高度にモチベートされた向上心のある開発者が前提になっている。つまりPSP適用の前に、開発者のモチベーションを向上させるというPSPよりはるかに難しい課題に直面することになる。また高度にモチベートされた集団ならPSPを導入するまでもなく、良い仕事をするだろうと私には思われる。
(4)ハンフリーはソフトウエア開発をかなり単純化して考えているように思える。例えばターゲットとなる領域の知識(ネットワークやDCOM等)を持っているかいないかは決定的である。PSPに従わなくても開発はできるが、ターゲット領域の知識なくしては開発できない場合もある。経験から蓄積されるのは、数値だけではないことを見落としていないか？また蓄積される経験からの情報としては数値でないものほうが重要度と次の開発に対する影響度は大きいと思うのだが。
(5)統計的な手法が有効なのは、多数の開発者からデータを集めたときだと思うが、その場合に、データの使い方によっては、開発者が正確なデータを提出しなくなる可能性がある。（日立で起こった例のように）一方、純粋に個人でのデータ使用に統計的手法を適用することには疑問がある。
(6)PSPが「大規模ソフトウエア開発」における「個人のプロセスの改善」というのは矛盾しているように見えます。大規模ソフトウエア開発において、個々人が別々のプロセスを選択することは可能なのだろうか？
(7)ストップウォッチ片手にソフトウエアを開発するのは（本当である。私は演習問題を解くためにストップウォッチを買った。）、とても煩わしく、従って、今のところ他の人には薦めるわけにはいかない。
結論として、PSPで使われている統計的手法は、大規模なソフトウエア開発で、開発規模、工数を予測するのに役立つ可能性があるが、個人レベルでは疑わしい。PSPを適用することで開発手法に枠をはめたり、モチベーション等、もっと重要なソフトウエア開発の他の側面が指の間からすり抜けてしまう危険性がある。
否定的なことばかり書いたが、参考になる点も多い。私には特に、開発規模、工数を見積もるPROBE法が参考になった。技術者というものは、常に「銀の弾丸」を捜し求めている。特に人間的な要素が全くない手法には心を引かれる。うまくいきそうに思えるからである。だが最も重要で影響度が大きいのは、その人間的な要素である。外部にソフトウエアを発注するときに、CMM3で凡庸な管理者のいる組織より、CMM1でも優秀な管理者のいる組織（そういうものがあるとすれば）を選びたいと思うのは私だけであろうか。
「ソフトウエア インスペクション」
Tom Gilb, Dorothy Graham (1993)
共立出版(1999)
評価：★★★★☆
レビューが効果をあげていないと悩んでいる人にはアイディアの宝庫である。もっともGilbは、レビュー、ウォークスルーとインスペクションに明確に一線を画している。インスペクションは、次の手順に厳密に従う。①計画、②キックオフ、③チェック（個々人の）、④ロギング（ミーティング）、⑤ブレーンストーミング、⑥編集、⑦フォーローアップ。
読み進むほどに、我々が行っているレビューとインスペクションの乖離に驚かされ、これはとても実現できないという絶望感に襲われる。開発工数の１５％をインスペクションに割くべきという主張や、インスペクション速度は重要で、1時間につきドキュメント１ページが標準ということにもショックを受ける。だがGilb自身が述べているように、カスタマイズあるいは役立ちそうなところを取り入れればよいのである。絶対に外せないところは効果の定量的な確認とインスペクションプロセス（或いはパラメータ）の改善である。本書には、導入に関するアドバイス、一般的な失敗しやすい場合、6つの企業のケーススタディ、メトリクス・書式のサンプルと、至れり尽せりである。私の抜粋では全体を把握しにくいが、リーダー、管理者に読んで欲しい1冊である。翻訳の質がよく、非常に読みやすかったことを付け加えておく。
|
