さようなら！の前提条件？
「デスマーチよ！さようなら！」という本を読了致しましたです。通常であれば書評（のレベルに達してない自己満足な読書感想文）はてきとーににっきにでも書き捨てておいて、時の経過と共にフェードアウト、ということが多いのですが、書き出したら思いの他長くなって「あ、これはネタになるな」と急遽こっちに保存、という訳で。
で、まずは率直な感想。よぉ書いたなと思います。まがいなりにもアジャイル万歳／ウォーターフォール死ね的なポジション（どんなポジションだ）に属する身としては幾分受け付け難いかな、と読んでる間は思ったのですが、実際よくもまぁこれだけの多岐に渡る内容をまとめきったなと。それでいて示されてる対応策も決して非現実的ではありませんし。
対応策として（というか事実上の主題）スペックパターン開発というのを掲げてます。詳細は本ならびにWeb参照頂くといいのですが、基本的には、
- どしょっぱにモックアップ作ってしまう
- 議事録を最重要ドキュメントに据える
- 仕様書＋ソース（＝スペックパターン）を常に１対１のセットとして捉える
- スペックパータン単位で作成していく
このあたりが特徴、という感じですかね。RUPよりは重いけどウォーターフォールよりは軽い。乱暴に言えばこんな感じかと。
で、自分的にはTOC的な変化とでも言いましょうか、全部を一気に変えるのではなく、ボトルネック改善的なアプローチ、現状からのちょっとした変化を狙う、というのを感じましたです。例えば仕様書の流れとか人員配置の考え方がそれまでと大きく異なるとは思いませんでしたし（無論注意点はありますが）。逆を言えばそこに大きなメスを入れることなく導入することで、理解を求めやすくなる・・・ととることもできる訳で。一部ではアジャイルを名乗ることが犯罪者同然の弾圧を受けている現実を考えればこれは素直にうらやましい（笑）。
相変わらずプロジェクトは炎上を続けている、しかしながらアジャイルなんぞはもっての他、そんな組織文化を相手にする場合、このやり方でのアプローチはかなり有効なんでないかな？とか思ったりしますです。逆にXP万歳な人やRUP万歳な人でもこれは「方法論のひとつ」として押さえておく、というのは悪くないと思うぞ。少なくとも糞のよな「ウォーターフォールもどき」に戻させないための手段は多ければ多い程良いですから。
さて。これだけ誉めておけば後で怒られても言い訳はできるな。んじゃ、逆にちょいと気になった点を書かせてもらうね、と。
まずいっこ気になったのは「戻りの扱い」という点。まぁいわゆる仕様変更とか要求変更ですな。
スペックパターンの場合、
- モックアップを要求検討に使うことでズレをなくす。極力「仕様変更ゼロ」を目指す
- もし変更が発生した場合でも、スペックパターン単位で対応することで、影響範囲を食い止める
というアプローチで対応してると受け止めましたが。
果たしてそれで十分なのかな、というのが正直な感想。要求に対する信用度、という点では私はとことん悲観的に見ていますし。
顧客も、もちろん開発側も、モックアップ見ても、「本当にこれが欲しいか」なんてわかりっこないような気がするんですな。もっと言うなら何ヶ月かけて完成されたシステムを見ても、尚要求なんかわからないというのが現実のよーな気がする。
その上でも場合によっては泣く泣く変更せざるを得ないパターンってのはでてきますから。その場合の負荷は、結局実作業者が被ることになる。その被害状況によっては結局は徹夜休出の生活破壊に元通りです。その場合どうするの？的な突っ込みがもう少し欲しかったかなというのがひとつ。
でまぁ↑これはいいです。いっそのことXPの如く週40時間労働突っ込むとかもできますんで。私的には↓の方が深刻かなと。
スペックパターン開発の場合、本の中でも明記されていますが、プロジェクトマネージャーに対しては尋常じゃない作業負荷と責任が振りかかってきます。
ですので、本当に「能力のある人」がその重責を背負う必要があると。これ、いわゆる「受験勉強的」な頭の良さだけじゃ全然対応できませんからね。交渉スキル、決断力、頭の回転・・・あらゆる局面で本当の意味での頭の良い人、ってのが求められると。
で、できる人いるんならいいんです。できるんなら。いないにしても1000万だろうが2000万だろうが出せるだけの金出して確保できればそれでいいんですが（その働きに対して報酬は与えるべきですわな当然。その点では著者に完全同意）。
問題は金出そうが人探そうが、そうゆう人が見つからない場合ですよね。どないすりゃええねん、となってしまいそうな気がすっごくするんです。
この辺の疑問に関しては昨今のPMPやPMBOKに対しても同様の匂い、というか危機感を感じているんですけど。昨今のPM重視傾向もあって人自体は増えてるけど、それが「できるPM」の増加に繋がるとは限らない、現時点でできる人は既に方々から首根っこ捕まれて身動きできない、挙句の果てには業務過多がPM側にも襲いかかることで、できる人から使い潰されていく（これが一番深刻）。そんな悪循環の中でかろうじてPM稼業ってのが成り立ってるような気がしてるんですな。
そんな中で人探すにせよ育てるにせよ、リスク引き受けてやってくれるのか？という疑問は拭えないんですよねぇ。いや、仮に引き受けてくれる人がいたとしても（金積めば来る人は来るでしょうし）、それでじゃあプロジェクトが進められるかってのはそれこそやってみないとわからない。ここにすごく怖さを感じます。
そうなると結局はデマルコ言うところの「スター問題」に行き着いちゃうんですよねぇ。才能への依存というか。スター社員は組織内にいることでとてつもない力になる一方、離脱した際には再起不能なダメージを与える諸刃の剣。しかも最近ではスターから先に破壊されていく傾向がありますし。そんな中、敢えてスターを求めることが吉とでるのか凶とでるのか・・・。うーん難しい問題だ。このあたりの不安要素を組織やプロジェクトの力によって受容できるかどうかがカギを握ってるような気がしますなぁ・・・。
ま、長々と書いてしまいましたが。
なお改めて念押ししておきますが、私著者さんにケンカ売るつもりは毛頭ございませんので。むしろ逆で「こうゆうやり方もあるんだよ」という意味でアジャイル派だろーがウォーターフォール派だろーが、そんなこたぁ関係無く押さえておいて損は無いと思いますので。使いこなせる武器はひとつでも多い方がいい、てのが私の持論でもありますんで（笑）。銀の弾丸なんて存在しませぬ。
つーわけでみんな読みやがれということで。相変わらず無理矢理な〆だがいつものことだ気にするな。
あ、最後にこれ引用しておこう。
特に「ｘステップあたりｙ件のバグを発見しなければならない」という考え方は捨てましょう。プログラマのモチベーションをおとしめるだけで、生産的な数字にはなりえません。開発環境や言語が変わってしまってはなおさらです。繰り返したところで、バグが減らずにプログラマが減っていくだけです。
（p.243より）ぐぅの音も出ない位そのとーりだぁ。