10．設計書の提示・確認、仕様変更への対応

まとめた設計書を顧客・ユーザに提示し、必要であれば説明する。

これ以降、基本的にこの設計書の内容に準じて、開発作業を進める。

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業	事前情報、他
・設計書の作成（メニュー体系図の作成、画面設計、機能設計など）	・設計書の内容を把握していること（以下、仕様変更の対応として）・ヒアリングで得た情報・一般的な／最新の業界・技術情報・対象システムの業務知識・技術知識（マシン、ソフト、プログラム言語）

ある程度内容が固まった後や、ドキュメントとしての設計書がまとまった後で、仕様変更を依頼されることがある。

とりあえず、変更内容とその理由を聞く。
変更に応じるかどうかの判断材料や、応じる場合の条件などを検討する。
- 作業の難易度、量（範囲）、かかる期間（時期）、変更による他への影響範囲、担当要員の有無、全体コンセプトとの整合性、そもそもの必要性、．．．
- 追加予算の依頼、製造期間延長の依頼、要員増加の検討、次期開発案件としての提案、．．．
変更に応じるかどうかを決める。必要に応じて、製造スケジュールや担当分担などを調整する。

仕様変更を放っておくと、ドキュメントと実態の整合性が取れなくなるので、必ずドキュメントも修正する。

一度ドキュメントを正式納品してしまっている場合は、それを直接変更することはせず、別紙として変更内容を記載する。
直接変更する場合は、必ず「変更履歴」を残す。「いつ、どんな理由で、どこの何がどう変わったか」

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他	この後の作業
・設計書	・設計書の確認、顧客の了解・開発環境準備、構築・製造

もとの仕様や作業範囲があいまいだと、「当然これも含まれていると思っていた」といって追加・変更を求められる。
それが明確になっていることが、仕様変更によるトラブルを防ぐ第１条件。

仕様検討・調整段階での議事録・メール・メモなどは、必ず残しておく。  
確定後の変更依頼などに関するものも同様。

言ったことを忘れてしまったり、以前は「A」と言ったが今度は「B」と言い出した、などと話が二転三転することもある。振り回されてころころ変更するのは手間が大きい。
やり取りの議事録・メール・メモなどが残っていれば、「あの時Cさんがこう言った」という証拠になる。

すべてを「ダメ」と言っていたら、信頼関係にも影響が出る。  
作業工数への影響が少ない小さなものは、（無条件で）引き受けることもある。

results matching ""