仕様変更の発生ケースと懸念されるトラブルとは?変更に備えて導入したいツールをご紹介

 2021.07.08  株式会社システムインテグレータ

システム開発に携わったことがある方は、仕様変更の発生により負担やストレスを感じた経験があるのではないでしょうか。システムエンジニアやプログラマの方で、仕様変更を歓迎する人はまずいないでしょう。
当記事では、システム開発における仕様変更に備えるために、仕様変更が発生する原因、仕様変更により起こるリスクやトラブル、仕様変更の対処法までを解説します。また、万が一の仕様変更をスムーズに乗り切るためのおすすめツールもご紹介しています。
仕様変更に悩まされている方や、仕様変更にも無理なく対応できるツールをお探しの方は、ぜひ参考にして下さい。

「仕様変更」とは?

システム開発の現場において歓迎されない仕様変更ですが、リスクやトラブルに備えるために、まずは仕様変更がどのような状況を指すのかを知っておきましょう。
仕様変更とは、システム開発のプロジェクトにおいて、一度双方が合意した後で、仕様が変更されることをいいます。法的な観点からは、クライアント側とシステム会社側が債務内容の変更に合意することであると解釈できます。
仕様変更は、途中で完成イメージが変更となるため、進行中の作業が無駄になったり、余計な作業が発生したりと、システム開発会社には大きな負担がかかるといえます。
この仕様変更ですが、新たな要望を求めるなどクライアント側に起因する場合と、業務上のミスなど、システム会社側に起因する場合があります。
続いて、どのようなケースで仕様変更が発生するかを詳しく見ていきましょう。

仕様変更の発生ケース

business documents on office table with smart phone and laptop computer and graph financial with social network diagram and three colleagues discussing data in the background-3

仕様変更のリスクを回避したいのであれば、どのようなケースで変更が発生するかを知っておくことが重要です。実は仕様変更が発生するケースというのは、ある程度パターンが決まっています。
ここでは、仕様変更が発生しやすい代表的なケースについて解説します。典型的なケースをあらかじめ知っておくだけでも大きなリスクヘッジとなるため、ぜひ参考にして下さい。

クライアント側で合意形成できていなかった

システム開発は、クライアントの要望をヒアリングし、その内容をもとに進めます。しかし、クライアント側の担当者から合意を得ていたはずのプロジェクトに対して、別の担当者が違う意見や要望を伝えてきて、仕様変更が発生するケースがあります。
クライアント側で組織内合意ができていない場合に起こるケースで、特にシステム開発の発注に不慣れな場合に発生しやすいといえるでしょう。
また、システム開発を受注したシステム会社側においても、組織内合意ができていないと仕様変更の大きな原因となるため注意が必要です。
このようなリスクを避けるために、システム開発に着手する前には、自社内・クライアント内の組織内合意も含めて、本当に合意が取れているかを必ず確認することが重要です。

開発内容の変更

システム開発では、開発途中でクライアント側のビジネスの状況や戦略が変わり、仕様変更を求めてくるケースがあります。
ビジネスは常に変化するため、このような仕様変更が発生する可能性は避けられませんが、仕様変更の原因としては比較的少なく、もし発生した場合でも原因を作った発注者側が費用を負担することが一般的です。
事前に仕様変更時の対応の方針についてクライアントと合意が取れていれば追加費用や納期調整の話がスムーズに進みますが、クライアントが十分に認識していない場合、こちらに落ち度がなくてもトラブルとなってしまうケースもあります。こうしたケースを避けるには契約書や見積書の条件として記載するだけでなく、クライアント側のプロジェクトオーナーにしっかり説明をし事前に合意をとっておくことが重要です。
しっかり合意が取れていれば追加費用や納期調整においてトラブルになるケースは多くはありませんが、システム会社側としては調整の手間がかかった上に、途中まで作成したシステムのデザインやプログラムが白紙となり、やや後味の悪さが残ります。

ヒューマンエラー

上述の組織内合意や開発内容の変更に問題が無かったとしても、システム会社側の仕様書や設計書に、抜け漏れや間違いなどのヒューマンエラーがあると、仕様変更が発生してしまいます。
仕様書・設計書に落とし込むプロセスまで問題なく進めていても、些細なミスや油断で大きなリスクにつながるという、最も避けたいケースです。
しかし、仕様変更の原因としては比較的多く見られるケースであり、単純にシステム会社側のヒューマンエラーである場合は、当然仕様変更に伴うコストの請求が難しくなります。
ヒューマンエラーによる仕様変更を避けるためには、二重三重のチェックを行ってから開発に着手するなど、入念なリスクヘッジを行なうことが得策です。

開発を進める中で明らかになる

システム開発は非常に複雑難解な業務特性を持つため、仕様書・設計書を入念に作り込んで確認を行なっても、実際に開発を進めてみなければ気づかないことや分からないこともあります。
そのため、開発を進める過程でやむを得ず仕様変更を行わなければならない事実が明らかになるケースもあります。例えば、技術的問題により仕様変更を行わなければ機能実装が難しいケースなどです。
このような原因による仕様変更を完全に無くすことは困難であるため、あらかじめやむを得ない仕様変更発生時についてクライアントと取り決めを行っておくことや、要件定義・設計の段階でリスクを矮小化する工夫を行なうことが重要です。

新規CTA
新規CTA

仕様変更の発生で懸念されること

Stressed businesswoman sitting at her desk in the office

ここでは、システム開発のプロジェクトで仕様変更が発生した際に懸念されることを解説します。具体的に、どのようなことが起こり得るかを把握しておきましょう。

開発メンバーの負担増加

仕様変更により予定していなかった作業が追加されることで、システム開発に携わるメンバーの負担が増えます。
疲労やストレスも増すため、社内の雰囲気が悪化することもあるでしょう。

スケジュールの調整

仕様変更がスケジュールに割り込むことで、スケジュールの変更や調整を余儀なくされます。場合によっては、メンバーに過剰な残業や休日出勤も発生します。
仕様変更に着手するにあたっては、クライアントとの折衝や合意を得る労力も必要となります。

対応できないケースもある

仕様変更といっても、内容はさまざまです。軽微な仕様変更であればいいですが、あまりに大胆な仕様変更や技術的に不可能な仕様変更など、仕様変更の範囲では対応できないケースもあります。
イチから開発をやり直さなければならないケースだと、対応するにしても断るにしても大きな問題へと発生する場合もあるでしょう。

クライアントとの関係悪化

仕様変更でクライアント側とシステム会社側の見解や認識が食い違うと、トラブルに発生する場合があります。

特に、仕様変更に伴う追加コストは双方が揉める火種となりやすく、支払いを巡って法的紛争に発展する場合もあります。
このように、仕様変更が発生するとさまざまなリスクやトラブルが懸念されます。特に、追加コストに関しては問題となりやすいため、次章でトラブルの詳細や対処法について詳しく見ていきます。

仕様変更で発生する「追加コスト」のトラブル

ご説明した通り、仕様変更が発生するとシステム会社は、予定していない修正作業や追加作業を行わなければなりません。加えて問題となるのが、仕様変更に伴う「追加コスト」です。
システム会社はシステムエンジニアやプログラマに対して人件費を支払って開発を行っているため、自社に非が無い仕様変更であれば、追加コストを受け取らないと損失となります。
また、仕様変更に人的リソースを消費して、その間他の業務にリソースを回せないという問題もあります。

トラブルの要因

仕様変更の追加コストがトラブルを招くのは、クライアント側・システム会社側どちらがコストを負担するかという点で揉めるためです。
なぜこのように揉めてしまうかというと、以下2つのケースが挙げられます。

仕様変更に値するのか

追加コストでトラブルに発展する1つ目のケースは、追加で発生した作業が「仕様変更であるか否か」という点です。
本来の仕様に含まれている範囲内の作業であり、仕様変更で無いのであれば、追加コストは発生しません。反対に、本来の仕様の範囲外であり、後から要求された作業であれば仕様変更となり追加コストが発生します。
しかし、事はそう単純ではなく、専門知識を持たないクライアント側と専門知識を持つシステム会社側では認識や見解が異なるため、齟齬が発生してしまうのがトラブルの原因です。
このようなトラブルを避けるためには、受注・契約の時点で本来の仕様と仕様変更に該当する追加の作業を明確化して、双方が合意しておくことが重要となります。

合意がないまま変更が実装される

追加コストでトラブルに発展する2つ目は、仕様変更発生後に、作業内容やコストについての明確な合意が無いまま作業が進められてしまったケースです。
具体的には、クライアント側は仕様変更に追加コストが発生することを認識しておらず、システム会社側は追加コストが支払われることを前提に作業を進めてしまったケースなどが考えられます。
クライアント側が「追加コストが発生するなら仕様変更は不要」「勝手に進めて請求してきた」と主張する可能性があるため、システム会社側は追加コストの回収が困難になります。
従って、仕様変更に着手する前には、「追加コストの有無」「コストが発生しても着手するか」「作業内容と金額」などについて、双方が明確に合意したうえで進めることが重要です。

仕様変更の最大のリスクは、追加コスト支払いに関するトラブルならびに回収できなかった際の利益損失です。不要な仕様変更の発生を未然に防ぐことが最も重要ですが、やむを得ず発生してしまう場合もあります。
万が一の仕様変更発生時にスムーズに対応するためには、CADツールの導入がおすすめです。次章でツールの性能や活用方法についてご紹介しているため、ぜひご参考下さい。

仕様変更に備えて導入したい「システム開発設計用のCADツール」

Brainstorm against business interface with graphs and data

Word・Excelといった汎用ツールで仕様書・設計書を作成・管理していると、仕様変更の影響範囲の調査・特定もすべて手作業で行わなければならず、非常に煩雑で時間がかかります。また、正確な影響範囲を把握することも困難です。
しかし、システム設計用のCADツールを導入・活用すれば、仕様書・設計書等のドキュメントを合理的・効率的に作成・管理することが可能であるためおすすめです。仕様変更に伴う作業にも柔軟な対応が可能で、作業負担・作業時間も大幅に軽減できます。
次章では、弊社が提供するCADツール「SI Object Browser Designer」の機能・特徴をご紹介します。

仕様変更時でも安心!「SI Object Browser Designer」

弊社のCADツール「SI Object Browser Designer」は、仕様書・設計書・詳細設計書・各図面の作成・管理を効率化・合理化するツールです。
汎用ツールに比べて作成効率は格段に向上するだけでなく、システム開発に必要なドキュメントをまとめて整理して管理することができます。属人化や不整合が発生するリスクを低減できることも当ツールの特徴です。
欲しい情報をすぐに参照できるため、システム設計工程だけでなく、メンテナンス・カスタマイズ・テスト・運用といった全工程の生産性向上に大きなメリットがあります。
仕様変更発生時においても、汎用ツールより遥かに効率的に対処できるでしょう。

仕様変更の影響範囲を検索!「クロスリファレンス」

「SI Object Browser Designer」であれば、仕様書・設計書が合理的・効率的に管理されているだけでなく、クロスリファレンスという機能を用いて、仕様変更の影響範囲をスムーズに調査・特定することができます。
クロスリファレンスとは、システムの機能間の相関関係を調べる機能のことで、画面やロジックといった機能単位での影響範囲を詳細かつ効率的に調べることが可能です。また、調査結果をもとにエビデンスを作成することも容易に行うことができます。
仕様変更はほとんどの場合において、システム会社にとってネガティブな仕事となるため、少しでも工数や負荷を減らすことがポイントです。「正確に」「素早く」「効率的に」仕様変更の影響範囲を把握したい方は、ぜひ「SI Object Browser Designer」をご検討下さい。

まとめ

システム開発の仕様変更ならびにそれに伴うトラブルは、会社にも開発に携わるメンバーにも大きな負担となるため、極力回避したい問題です。業務プロセスを見直すことで仕様変更が発生するリスクは低減できますが、ゼロにすることは難しいのが実状です。
そのため、万が一の仕様変更発生時にスムーズに対応できる備えを行っておくことも重要となります。システム開発用のCADツールを導入すれば、開発プロセスを明確に管理できて、仕様変更の影響範囲も調べることができます。


RECENT POST「コラム」の最新記事


この記事が気に入ったらいいねしよう!