本棚登録 : 
感想 : 
仕様はソースコードに書いてある。
ただそこにはその仕様が生まれた要求や背景・理由が書かれていない。また全体像を俯瞰するあらすじやガイドがなければ、膨大なソースコードを時間をかけて1つ1つ読み解いて 仕様を理解し、その背景を推測していく必要がある。
このため、仕様が競合していること、要求が競合していることに気づかずに大量のバグが生み出される。影響範囲を理解しきれないまま一か八かの修正を入れ、二次障害が発生し注意不足/工数不足のせいにする。五月雨式に発生する要求変更、仕様変更を適切にまとめ、時期を見極めて現場に落とせないマネジメントの欠如、体系的にとらえずその場しのぎの修正でやっつけるエンジニアが混乱に拍車をかける。
そんな状況を打開するための手段の一つが、要求仕様書の本質を理解し、その記述テクニックを磨くことだと確信できる。もちろん本書だけで完璧な要求仕様書の記述ができるようになる訳ではなく、演繹法、帰納法、MECE や 7±2 などのドキュメント作成テクニックを磨きながら記述内容の粒度などをそのプロジェクトの特性や要員にあわせて見直していく必要がある。こうした積み重ねにより要求から仕様項目数、ソースコードステップ数を見積り、計画の精度を向上させたり、要求-理由-仕様を分析するようにリスク-要員-軽減策を検討することで、リスク管理などにも応用できるようになるだろう。また改善の効果をより適切に評価するため、改善により削減できた時間を推測し、実際の投入時間と比較することも忘れてはならない。
仕様書のボリュームが大きく書ききれないなら、それをどう覚えきり、制御しきるのか。すべてを同じ粒度で書き出す必要はない。制御するため、コードを読み返さなくても掌握するため、一つ一つ体系的に書き出していこう。
筆者自身の開発経験、コンサルティング経験から思わずうなる事例が多数紹介されていて参考になるが、テーマが拡散して繰り返し冗長に語られている部分や、ありふれた事例で回りくどい説明となっている点、結論が読み取りづらい箇所も少なからずみられるのが少々残念。
0
- 感想投稿日 : 2012年11月28日
- 読了日 : 2012年11月23日
- 本棚登録日 : 2012年11月28日
みんなの感想をみる
