カケラでもあれば相当楽なんですが。
REでは資料が不足しているのは当然いつものことです。
それをRE時点で全部仕様策定側に問いただしても現場は混乱するだけです。その元凶はなんでしょうか。
大元の要求仕様はしっかりした資料があり、事前検討や調査資料は残っている。Q&Aも多数ある。メールアーカイブもある。
常に欠けているのは実装仕様書です。
要求仕様には"何を作って欲しいか"、"製品としてどう振舞って欲しいか"が書いてあるとすると、事前検討や調査資料は、"ほんとうにそんなことが実現できるのか"、"実現するのに過大なコストがかからないか"の見積り作業のごく一部の結果です。Q&Aは要求仕様に対するレビュー記録でしかありません。
その作業を通して、要求仕様書だけを更新するのが最大の問題点です。作業と同時に、実装仕様書のドラフト版くらいは書かないとだめなのです。
少なくとも要求仕様書を書いて、メールで突っ込まれた要求元はそうイメージしています。
自分の書いた要求仕様書の重箱の隅を多数突かれて、丁寧に再検討して回答した上で仕様書を更新するという困難な作業を繰り返したからです。
にもかかわらず、残るのはA4で2枚の再利用不可能な重箱の隅をつついたというだけというものです。そんなものしか書かない連中に対する不信感がどれほどのものかご想像いただけますでしょうか。
このフェーズは、本来は調査ではなくプレゼンフェーズなのです。提示された貴重な要求仕様書。要求仕様書というのは本来は競合に対してトップシークレットの機密情報なのです。それを開示した上で、実装仕様を見積もらせるフェーズのはずが、なぜかいつも要求仕様書の一貫性や誤字脱字指摘あるいは、"出来ない理由の大合唱"大会となるのです。
# プレゼンは要求仕様書に対して実装仕様書で入札するのですよ！
# 要求仕様書のレビューではありません！
そこを見るだけでその仕事の行く末が見えてきます。
実装仕様書を書くのは設計フェーズなので、要求仕様書がある程度固まるまで着手しないという意味不明なことを言う人がいます。そうやって遅らせることで、製造フェーズの日程圧縮の恐怖に負けてロクな実装仕様書も書かずに見切り発車することになるのです。
実装仕様書に書くべき詳細が未決定であるというのなら、実装仕様書にTODOやTBDあるいは検討中一覧の章を作ってそこに列挙します。「検討中一覧.xls」などというばかげた表を作ることが無駄なのです。そしてその内容が更新されたら実装仕様書の版数を上げて発行すればいいだけです。
最も無駄なのは、本来実装仕様書に書いておけばよい情報、たとえば関数リファレンスや、設定スクリプトの説明、ブートローダの更新手順などを、いちいちMS-WORDの3ページくらいの文書として発行し、しかも版数管理もしないで書きっぱなしで放置することです。後になってから情報が分散していてどうにもならないなどと言い出すのです。
実装仕様書の発行というのは、CVSリポジトリからリリース物を固めてエクスポートするのと本来同じなのです。バージョンを付けて串を通す。それが本来の作業です。リリースされた仕様書をみれば、どの情報とどの情報が同期して変更されたか分かります。別の文書になっていたら、一貫性を持っているかどうかの確認だけで半日仕事です。
注意して欲しいのは、実装仕様書を単一のMS-WORD文書にしろと言っているのではないことです。ある時点で実装に必要な情報をフルセットで固めたものを実装仕様書としてリリースすべきというのが主張の幹です。
モジュールAの関数Bを変えただけだから・・・とか設定ファイルXの設定値Yを変えただけだから・・・などと各担当者が個別にファイルをリリースすることを許してはいけません。
理由は実装つまりソースと実装仕様書の同期が取れなくなってしまうからです。念のため書いておきますが、実装仕様書とソースを同期してリリースすることには賛成できません。実装仕様書で宣言したあと実装をするのですから、実装仕様書が先行します。実装中に実装の都合に合わせて実装仕様書を修正するのは頭のおかしい人がすることです。そんなことが起きないレベルになるまで実装仕様書をブラッシュアップしてから実装作業を開始しなければなりません。
お前は一体ナニサマなんだとおっしゃられるかもしれませんが、まぁ一軍曹あるいは一参謀の目から見た問題点を指摘したまでのことです。
コメント