度重なる仕様変更とうまく付き合うにはどうすればいい?

度重なる仕様変更とうまく付き合うにはどうすればいい?

ELIO TRUONG

現在、仕様変更に柔軟に対応するためにアジャイル開発を導入している企業が多いのは確かですが、まだウォーターフォールモデルで開発を実施している企業も少なくありません。前の工程が終わってから、次の工程に進めるのが特徴であるウォーターフォールモデルは仕様変更が多いと、手戻りが発生したり、当初予定していた予算を上回る課題は誰もがわかるでしょう。では、仕様変更が発生した時、うまく対応するには何をすればよいでしょうか。この記事では、仕様変更とうまく付き合っていくために必要な工夫について説明したいと思います。

目次

  1. 仕様変更とは
  2. 後から出てくる変更はどう対応すべきか
  3. まとめ

Change_Request

1.仕様変更とは

発注者はシステム開発に必要な情報と必要な機能の詳細をまんべんなく伝えてもらえるわけではありません。開発を進めるにあたって、発注者が予測したない開発者やQAなどからの質問に対して検討した結果仕様が変わったり、社内会議の検討で要望が変わったりすることは多くあります。
つまり、仕様変更とは決まった仕様を修正するということです。決まった仕様をもとにしてシステムを開発している途中で、追加や変更が加わると、当初予定していたスケジュール、工数などに影響を与えてしまうおそれがあります。
しかし、仕様変更の中でも、悪い仕様変更と良い仕様変更があります。
悪い仕様変更とは明らかに手戻りが発生し、追加工数の発生やスケジュールの再検討につながるものです。逆に、良い仕様変更は変更によって、実装がしやすくなるために決定されたものです。

試験作成システムの開発を例にします。
当初は一度試験を受けた受験者がある場合、その試験を編集することができない仕様でした。しかし、何等かの理由で、設計まで終わった段階で、実装まで進めている途中で、試験の編集を許可する仕様に変わってしまいます。この変更によって、設計したものを変えないといけないし、どこまでスケジュールや期日に影響が出そうか検討が必要になってきます。これは明らかに悪い仕様変更の一つの例です。

CR-3

  1. 後から出てくる変更はどう対応すべきか

では、途中から変更してほしいといわれたら、どう対応すべきでしょうか。
「すみません、ちょっとできないです」をきっぱりと断りますか。
それとも、受け入れる声で「何とかします」と答えますか。
プロジェクトの状況を見て、慎重に回答しないといけないと思いますが、ビジネスの世界では、「ノー」をいうと次の受注のチャンスを失ってしまう可能性があるでしょう。開発が後回しにするかもしれませんが、仕様変更を受け入れる前提で進めるのがほとんどの場合です。

CR-2

いずれにしても、納期はもちろん、工数の増加になるため、慎重に管理することが求められます。仕様変更が要求されたら、まず課題管理表を更新することが一般的ですが、変更管理表もセットで更新しないと後のトラッキングが難しくなります。
それでは、変更管理表にどのようなことを記載すればよろしいでしょうか?これは会社ごとの雛形にもよりますが、以下の項目を書くのが一般的かと思います。
①機能:ここで追加・変更となった機能名を記載
②画面:どの画面で機能追加・機能変更かを記載
③変更の詳細:期待される変更後の機能の詳細を記載
④変更の経緯:なぜ変更となったか、その理由を記載
⑤資料:顧客からもらったファイルか、やりとりのメール、リンクを記載
⑥変更発生日:顧客から変更を要求された日付を記載
⑦種類:固定で仕様変更
⑧優先度:顧客と協議の上、「最優先」、「高」、「中」、「低」を記載
⑨状態:未着手、対応中、完了、保留などを記載
⑩工数:追加費用を記載

  1. まとめ

この変更管理表を作ることによって、発注者側と受注者側の認識を統一させることができ、万一問題があったときに証拠として提示することができるので、工夫して完了しておくとよいです。また、仕様変更には悪いケースと良いケースもあるので、どれほど実装中のものに影響を与えそうか把握した上で、前提条件を付けて顧客と調整するようにしましょう。