■プロジェクトマネジメントの応用 ３（ソフトウェア開発編）
◆システム仕様を決定する
①要件定義書（顧客要求仕様書）があるか？
システム仕様の決定の基になるのは，要件定義書（顧客要求仕様書）である。したがって，このドキュメントがあることが前提である。顧客要求仕様書としての正式な発行云々ではな く，それに相当するドキュメントが明確になっているか，である。
システム仕様での代用もあるが，システム仕様はあくまでも開発側が作りたい仕様であって，顧客要求を反映しているか否かが判らない。ステークホルダーのレビューに依ることも可能ではあるが，要求仕様として求められている部分と異なる点もあり，その点は明らかにしておかねばならな い。
また，要件定義書をシステム仕様で代用すると，顧客仕様の問題とシステム仕様の問題が交錯することが起こる。システム仕様を作成するのは開発者なので，顧客仕様の問題になると（開発者の責任では無くなるので）責任が暖味になり，誰も判断ができず，問題点だけが先送りされ，プロジェクトが停滞することが発生する。そうならないように，顧客仕様の問題は商品企画で，システム仕様の問題は開発側で速やかに判断すべきである。
②要件定義書の暖味な部分が多く，システム仕様が定まらないことはないか？
要件定義書（顧客要求仕様書）に暖味な部分が残っていると，システム仕様が決まらないことになるので，暖味な部分は明確にさせることが必要である。やむを得ず計画時点で定まらない部分は，その箇所を明確にしてデッドラインを設けて，その時点までに明確にさせるようにしなければならな い。
要件定義書で上述したように，事情により暖味なもの，決まらないものなど，その部分を明らかにして，メリハリある判断ができるようにしておくことが重要である。プロジェクトの最初の段階でのトラブルは，この要件定義書の曖昧さからくるシステム仕様がなかなか決まらず，当初の計画からズルズル延び，この期間で時間を費やしてしまうことであり，プロセスがきっちりできていない組織ほど，こうした事態で混乱することが多い。
システム仕様が決まらないことは，その後の工程に入れない，或いは仮に後工程に入ったとしても後戻りのリスクが発生する。しかし，プロジェクト全体では入口であり，ここが滞ってしまうと全体日程への影響が大きい。つまり，自工程の遅れだけで済まず，後工程に多くの人が待ち構えていることを念頭に日程厳守することが重要である。
また，プロジェクトメンバー全員が寄って集って，船頭ばかり増えてなかなか前に進まない状況に陥らないようにしなければならない。
③要件定義書を的確にシステム仕様書に落とし込めているか？
要件定義書（顧客要求仕様書）から，的確にシステム仕様書として，実現可能なシステムを考慮したものに仕上げる必要がある。
顧客要求仕様に対して，そのままシステム仕様に落とし込む部分は良いが，代用特性で作り込んだり，一部修正を加える部分など，システム仕様として反映すると共に，顧客要求仕様の変更を伴う部分は，明確にして要件定義書（顧客要求仕様書）にフィードバックさせ承認 をもらっておくことが必要である。
④システム仕様としての必要事項が網羅されているか？
システム構成として，インターフェース関連（ハード，ソフト，モジュール間）が明確になっていること。
ユーザーインターフェースも十分考慮されていること。
各モジュールの役割・機能が明確にされていること。（重複・漏れがなきこと）
⑤仕様書の内容が一定水準レベルにあるか？
システム仕様の出来映えは，プロジェクトとしてのQCDを大きく左右する要因である。したがって，ここでの出来映えを確固たるものにするためにも，一定以上のシステムを全貌できるスキルを持った人が当たらねばならない。
特に，複雑なシステムや技術難易度の高いものは，漏れや抜けが無いようにすることが必須であり，このレビューには経験ある人が責任を持って当たることが重要である。 複雑なシステムで複数のモジュールが組み合わさるシステムでは，システム側から仕様を押し付けるだけでなく，各モジュールの責任者ともインターフェース部分を十分詰めておくことが最低限必要であり，モジュール間の齟齬が無いようにするのはシステム側で責任を持たねばならない。
[Reported by H.Nishimura 2011.04.18]
Copyright (C)2011 Hitoshi Nishimura
