注目キーワード

システム開発中の望まない仕様変更・追加は何故発生する?無くすための仕事術

皆さん初めまして、SE(システムエンジニア歴)17年目の秋野と申します。

 

システム開発中に発生する望まない仕様変更・追加は開発者にとってはいつも頭を悩ませる課題です。

 

私も駆け出しの頃は随分頭を痛めましたし、多くの失敗もしてきました。

 

今回は、システム開発中に何故望まない仕様変更や追加が発生するのか?と、それらを無くすための仕事術についてお話したいと思います。

開発者が望まない仕様変更・追加

身を持って分かっている方も多いと思いますが、仕様変更・追加は開発する会社にとっては報酬が発生する立派な案件となる筈ですが、中には望まないものも存在します。

 

それは

・費用が貰えない

・スケジュールがタイトになる。

・戻り作業で作った成果物が無駄になる。

です。

費用が貰えない

開発中に仕様変更・追加と思われる機能要求が顧客から上がってきたが、明確に仕様を決めていなかった為、「ここまでやって当たり前」「やって貰える前提の見積だと思っていた」などと押し切られ、結局あれやこれやと機能追加をさせられるケースです。

 

開発側はガンダムを開発するつもりだったのに気づいたら初期費用でフルアーマーガンダムを作らされた。なんてことも。

 

そもそも、顧客が仕様変更や機能追加をお願いしたという意識すら無いのかもしれません。

スケジュールがタイトになる

次に挙げられるのが仕様変更や機能追加が発生したにも関わらず、リリース日をずらせない事です。

 

数社が絡んで開発している場合やクライアントのエンドユーザーにリリースを発表している場合などは特にリスケが難しくなります。

 

戻り作業で作った成果物が無駄になる。

最後に、戻り作業で作った成果物が無駄になることです。

 

プログラマーが一生懸命作ったプログラムが使えなくなったり、設計書などドキュメント類にも修正が及びます。

 

開発工程が先に進むにつれ戻り作業の工数は増加し、テスト段階で欠陥が見つかった場合は設計、メイクをやり直す必要があります。

 

ではなぜこのような仕様変更が発生するのでしょうか?

望まない仕様変更・追加は何故発生する?

細かい理由は色々あると思いますが、私はこの問いに一言で答えると「曖昧さ」が原因と答えます。

 

それは

・要件定義の曖昧さ

・ゴール・目標の曖昧さ

・顧客運用理解の曖昧さ

・仕様の曖昧さ

・見積の曖昧さ

・アウトプット・インプットの曖昧さ

etc・・・

 

挙げるとキリがありませんが、殆どの場合、これらの曖昧さから開発中の仕様変更・仕様追加が生まれています。

 

顧客の運用を理解せず作ったシステムは、仕様は踏襲しているものの気が利かない使い勝手の悪いシステムになり、ああして欲しいこうして欲しいという要望が次々に出てくるでしょう。

 

アウトプット・インプットを明確にせず開発を行った場合は、データレイアウトや画面、帳票の追加修正が多くなるはずです。

 

そして、仕様の曖昧さは顧客にとって都合の良い解釈を与えかねません。

 

これらは、人や立場によって見えているゴールや持っている知識が違うため、一つの仕様理解を取っても認識のズレが生じるのです。

 

望まない仕様変更・追加を無くすためには

それではこれらの望まない仕様変更・追加を無くすためにはどうすれば良いのでしょうか?

 

一つの例を挙げて説明したいと思います。

 

とある物流会社から現場で使う検品システムの開発を受けたとします。

 

窓口はその会社の情報システム部門を通して要件定義や仕様決定を行っていました。

 

開発側は窓口となった情報システム部を全面的に信用し、開発を進めていきます。

 

しかし、実際使用する現場へシステムを見せると「使い物にならない」「使いにくい」「機能が足りない」「見づらい」「ここをああして欲しい、こうして欲しい」・・。

 

現場からの不満や要望が止まりません。

 

なぜこのような事が発生するのでしょうか?

 

それは、システムに関わるステークスフォルダーの目指すゴールや目的、目線がバラバラだからです。

 

この場合、顧客の情報システム部門と現場の情報共有が足りないと言ってしまえばそれまでですが、開発者側もこれから作るシステムに関わる人たちは誰なのか、誰が使うもので目的や数字的な目標は何かをハッキリさせる必要があります。

 

例のように現場が使うシステムであれば尚更、現場の責任者を交えて開発を進めて行くことが重要です。

 

システムに関わるステークホルダーに対しての情報共有や打ち合わせで決定した事項への合意は絶対に怠ってはいけません。

 

私の場合、メールをする際には必ずシステムに関わるステークフォルダー全てをCCに加えるようにしています。

 

最低でも自分の上司、自社の営業担当、開発メンバー、顧客担当者、顧客担当者の上司、現場責任者はメールのCCに加えるようにしましょう。

 

重要なメールを送る際は自社の人間に内容の確認をして貰ってから送ると間違いがありませんし、自社内での認識は常に合わせておくことが大切です。

 

そして、決定事項や打ち合わせの議事録はエビデンスとして残し、都度クライアントの承認を得るようにします。

 

こうする事でステークホルダー間の情報、認識の「曖昧さ」が無くなり、言った言わないの押し問答は解消されます。

 

決定事項に対してその場その場で承認を取るので、クライアントも仕様変更や追加に対して自覚を持つようになり、新たに変更、追加が発生したとしても費用やスケジュールの確保がしやすくなるのです。

 

お互いに緊張感を持ち、当事者意識を高める事は非常に大事なことなのです。

まとめ

望まない仕様変更・追加が発生する原因として、

  • 要件定義の曖昧さ
  • ゴール・目標の曖昧さ
  • 顧客運用理解の曖昧さ
  • 仕様の曖昧さ
  • 見積の曖昧さ
  • アウトプット・インプットの曖昧さ

を挙げさせて頂きました。

 

そして、これらの「曖昧さ」を無くしていく為に、

  • システムに関わるステークホルダーを洗い出す
  • 「誰が」システムを使うのかを意識する
  • ゴールを明確にし共有する
  • メールを送る際は自分の上司、自社の営業担当、開発メンバー、顧客担当者、顧客担当者の上司、現場責任者を必ずCCに加える
  • 議事録や決定事項、仕様については都度、クライアントからの承認を得る

を是非意識してみてください。

打ち合わせをするエンジニア
最新情報をチェックしよう!