プロジェクトマネジメント雑記（6）小さな開発プロジェクトの要件定義成果物

開発の前段階として、顧客へのヒヤリングを行い要件の整理を始めることが多いと思います。
このフェーズでは、システムの要件定義書が成果物になると思います。
その後、基本（外部）仕様書を作成し、詳細（内部）仕様書へと、
開発工程に即した資料成果物を作成していくと思います。

これまで、このフェーズは、システムの要件定義書を作成してお客様への説明を行ってました。
が、最近は、最初の工程では、システム提案概要書の作成をメイン成果物とする機会が増えています。
その場合、要件定義書は、外部仕様書の一部とドッキングさせて作成します。
そして、提案概要書の作成時補足資料として活用します。

提案概要書は、顧客への説明用にパワーポイントで作成します。
場合によっては、ビジネスに関する提案や業務改善に関する提案なども盛り込みます。
案件の性格や規模などによって臨機応変な構成としています。

このような体裁になるパターンとして、
・小規模な開発プロジェクトである
・顧客の潜在ニーズがはっきりと見えている（この場合は提案内容も含めて仕様化します）
・開発チームと阿吽の呼吸ができている
といった条件が当てはまる場合です。
このような場合は、開発の仕様書類はできるだけ端折ります。

詳細設計や、それより後ろの工程でも、
内部仕様書は、一部の複雑な部分とか重要な部分のみ
テスト仕様書は作成せずに、仕様書類をテスト仕様書替わりに活用する
どうしても足りない部分だけテスト仕様を作成
あたりですが、これでも資料類としては十分に作成している方だと思っています。

小規模開発の場合、時間もリソースも余裕が無い場合が多いです。
また、顧客の距離が比較的近い場合が多いです。
顧客とのやりとりを中心とした回し方（エビデンス）を重視し、
仕様書類は必要最小限度で意思疎通を図る。