Throughの新作コンテンツを読みました。
で、雑感
対応策として（というか事実上の主題）スペックパターン開発というのを掲げてます。詳細は本ならびにWeb参照頂くといいのですが、基本的には、
* どしょっぱにモックアップ作ってしまう
* 議事録を最重要ドキュメントに据える
* 仕様書＋ソース（＝スペックパターン）を常に１対１のセットとして捉える
* スペックパターン単位で作成していくこのあたりが特徴、という感じですかね。RUPよりは重いけどウォーターフォールよりは軽い。乱暴に言えばこんな感じかと。
で、自分的にはTOC的な変化とでも言いましょうか、全部を一気に変えるのではなく、ボトルネック改善的なアプローチ、現状からのちょっとした変化を狙う、というのを感じましたです。例えば仕様書の流れとか人員配置の考え方がそれまでと大きく異なるとは思いませんでしたし（無論注意点はありますが）。逆を言えばそこに大きなメスを入れることなく導入することで、理解を求めやすくなる・・・ととることもできる訳で。一部ではアジャイルを名乗ることが犯罪者同然の弾圧を受けている現実を考えればこれは素直にうらやましい（笑）。
スペックパターンについては、前にNextEngineerの最終号で読んだのですがかなり良いと思いました。
Agileバンジャイのはずのボクですが、スペックパターンのドキュメント至上主義も理解できます。
ただスペックパターンは
実際に、一部上場企業や官庁での、画面や帳票を中心とした業務システム開発プロジェクトを成功させてきた考え方と実際の行動を著した業務システム開発プロセス「スペックパターン開発(R)プロセス」を公開します。従来の開発プロセスにはなかった、業務分析、要求定義、仕様策定までの工程を特に重視したものとなっており、 全て日本国内で実際に行った行動です。* 顧客にもプログラマにも伝わる「質の高い仕様書（設計書）の量産」を行うことができる。
* 全体的な生産性が圧倒的に向上する（５倍以上−顧客からの評価）。
* 顧客とのコミュニケーション、プログラマとのコミュニケーションがしっかり出来る。
* 顧客とのコラボレーションをスムーズに行うことができ、顧客満足につながる。
* 結果、トラブルのないシステム開発を行うことができている（弊社業務実績参照）。等の効果、実績があります。