ブックレビュー：適応型ソフトウェア開発

書名：適応型ソフトウェア開発 変化とスピードに挑むプロジェクトマネジメント
著者：ジム・ハイスミス
訳者：山岸耕二/中山幹之/原 幹/越智典子
発行所：翔泳社
ISBN：ISBN4-7981-0219-9

アジャイル開発手法「ASD」に関する本なのですが、
ここ半年で読んだ中で、もっとも刺激的な本でした。
最初手に取った時は数あるアジャイル開発手法関連の本のうちの
一つくらいにしか考えていなかったのですが、読んでみると他のものとはかなり趣が異なることが分かりました。

アジャイル開発手法に共通する特徴として、ソフトウェアを構築するためのワークフローの詳細はあえて定義せずに、開発チームに決めさせるということがあります。ここがアジャイル開発で一番批判されやすいポイントです。定義していないということが単なる「いい加減さ」と解釈されやすいのです。
本書では、どうして詳細なワークフローを定義すべきでないのかも含めて、ASDの基本的な考え方を複雑適応系理論をベースに、ソフトウェア開発を筆者の趣味である登山に例えたりしながら、丁寧に説いています。非常に説得力のある議論で、これに正面から反論するのは難しいのではないかと思います。
実際はXPやスクラムなどアジャイル開発方法論の多くはASDと同様に複雑適応系理論にその基礎を置いていますが、それらの解説書は開発手法の実践に重きをおいており、そこまで理論的な基礎をしっかりと解説はしていません。本書をよむと、その述べられていない基礎をも理解することができるので、他のアジャイル開発方法論への理解も深まります。

具体的な内容も紹介したいのですが、長くなってしまいそうなので
今後何回かに分けて紹介したいと思います。

これはおすすめです!

ブックレビュー：チェンジ・ザ・ルール!

書名：チェンジ・ザ・ルール! なぜ、出せるはずの利益が出ないのか
著者：エリヤフ・ゴールドラット
訳：三木本 亮
ダイヤモンド社 ISBN4-478-42044-0 1,600円

「ザ・ゴール」「ザ・ゴール2」の続編です。内容は引続きTOC(Theory of Constraints)に関するものですが、今回は焦点をコンピュータシステムにあてています。ERPを開発しているあるソフトウェア開発企業が、他社の追随を許さない絶対的な競争優位を築くまでを描いたお話しです。
話の結論としては、単にコンピュータシステムを導入するだけでは、企業にとって大した利益にはならず、コンピューターのパワーが何を可能にするのかを認識して業務のルール自体を変えなければならない、ということです。

単に顧客のリクエストにて答えているだけでは顧客もソフト開発企業も幸せにならない。顧客のリクエストというのは大抵既存のルールにシステムを対応させようとするもので、かつその既存のルールはコンピュータ導入以前の物理的な限界に縛られたものである。そのようなルールに対応しても徒にシステムが複雑化するだけで、コンピュータのパワーをフルに活かすことは出来ない。単に顧客のリクエストに答えるだけでなく、業務コンサルのような部分まで踏み込まないと、本当にWin-Winの関係にはなれない。

という主旨のことが小説仕立てで描かれています。特に、ここでいう「既存のルール」というのは、主にTOC以前の部分最適化の努力のことを指しており、コンピュータ導入によって、従来の限界を越えてTOCを加速させることが出来るということがいいたいのだと思います。

小説としてはちょっと話がうまく行きすぎで、正直どうかと思うのですが、上述の話の主旨には考えさせられるものがあります。
TOC云々の話とは離れてしまうのですが、既存のルールに縛られるとコンピュータのパワーを活かしきれないというのは共感できます。僕も、もしかしてコンピュータより人間の方が頭が硬いのではと思うことがよくあります。コンピュータは人間とちがって、今までの習慣とかに縛られることがありません。だから、テクノロジーの進化に応じて黙々と仕事をこなすことができます。それに対して人間は一度身に付いた習慣をなかなか変えたがらないものです。

テクノロジーの進化の方が人間の習慣の変化より速い例を自分の身に引き付けて考えると、例えば、
ソースコードと同じ詳細レベルのプログラム設計書を意地になって書きたがることなどがあげられます。

現在のテクノロジーの状況を考えれば、ソースコードと同じ詳細レベルの設計書を書く必要性は全くありません。

第一に、同じ情報を２回書くのは基本的に無駄です。
第二に、設計書のほうがソースコードより見やすいということは決してありません。紙の設計書よりIDEの助けを借りてソースを追う方がずっと楽です。
第三に、設計書はテストできません。テストしないで動作するソースコードなどありえないのに、どうして設計書を正しく書けるとおもうのでしょうか?それに対して今はマシンが速いので、ソースコードはすぐにテストすることができます。
第四に、ソースコードの変更と設計書の同期を手動でとるのは、ほとんど不可能です。できたとしても、多大なるコストがかかります。

冷静に考えてみればわかることなのに、それでも気違いじみたプログラム設計書を書かせたがるのは、プログラマーの時間よりCPUの時間の方が高価だったころの習慣からぬけだせないからだと思います。そりゃテストするのにマシンを予約しなければならないような環境では机上デバッグも大事だろうさ。ホントにソースコード全部特大フォントで印刷してプログラム設計書とかゆって渡してやろうかと思うことがあります。

単に習慣の問題に加え、前例の無いことをやって自分が責任をとりたくないとかいう、もうなんといっていいか、バカか、というような悪い意味で極めて日本的な思考回路が状況を悪化させています。こんなことが日本を代表するSIerと呼ばれる企業でも結構まかり通ってしまっているところに日本のソフトウェア産業の限界を見て、いつも暗い気分になってしまうのであります。だからITゼネコンとかいわれるんだよ、全く。

そういう意味で、この本を読ませたい人はたくさんいますね。

ブックレビュー：熊とワルツを

書名：熊とワルツを リスクを愉しむプロジェクト管理
著者：Tom DeMarco & Timothy Lister
訳者：伊豆原弓
発行：日経BP社

FDD関連の本を買おうと思って本屋さんに行って、なぜか衝動買いした本です。平積みになってたので、結構売れてるんじゃないでしょうか。

内容はタイトルから想像出来る通り、ソフトウェア開発プロジェクトにおけるリスク管理についてです。全体として平易な言葉で、理論と実例、たとえ話を降り混ぜながら親しみやすい語り口でリスク管理のいろはを語っており、読みやすい印象をうけました。3日で読み終わりました。ちなみに著者は「ピープルウェア」を書いた人だそうです。

まず、第1章の1ページ目からいきなり登場するリスクのないプロジェクトには手をつけるなとの言葉にはおもわず拍手しそうになりました。特に日本では「リスクをとる」ということができる会社はほとんどないのではないでしょうか?

ソフトウェア開発はなぜいつもこんなにツラいのか?というのはいつもみんなが不思議に思うことですが、本書ではそれは発注者もプロジェクトマネージャもソフトウェアプロジェクトについて回る不確定要素を認識せず、適当な基準で納期を決め、しかもそれを依怙地になって守らせようとするからだ、という話になってます。プロジェクトのリスクを正しく評価し、リスク移行の程度によって納期に幅があることを認めればみんなが幸せになれる、ということです。
この議論にかんしては僕も大いに共感できました。
プロジェクトの納期に幅を認めたくない人達の心配は、開発者に甘えを許すことだと思われますが、無駄な厳しさによって問題が解決するのなら僕は今すぐ、ムチとおもりの付けられる足枷と外から鍵のかけられる部屋を調達しますね。

よく発生するリスク(コア・リスク)については発生する確率のデータをとることで、プロジェクトのリスクをある程度定量的にはかれるようになる、ということもいわれていますが、それを実践できてる会社ってあるんですかね？あったら是非見学に行きたいです。
単なる数の遊びでなく、そのようなデータを現場に活かすのは、ものすごく難しいことのような気がするんですが。。。

インクリメンタルな開発手法は、リスク回避の方法として推奨されています。XPに関してはeXtream Programming Explaindなどの本が推薦図書としてあげられています。著者はXPをリスク回避戦略として高く評価しているようです。

なお、本書で紹介されているRiskologyという無料のツールを使うと、簡単なプロジェクトのリスクのシミュレーションができるそうです。