彼女と旅行の計画を立てて、いざ出発したら、その途中で、海に行きたいと言っていたのが山に変わり、レンタカーで行くつもりが電車もいいね、旅館よりホテルの気分かなと言い出し、なんとか現地に着いて部屋食を待っていたら、山奥の蕎麦屋へ行きたいと言い出す、ころころと変わる希望を適えるために臨機応変に計画変更を模索するさまと、仕様変更の対応は似ています。
一般的にはあまり馴染はないかもしれませんが、システム開発に関わる人は知っていて当然の仕様変更という言葉。開発のマネジメントは軽々しく、クライアントは慎重にこの言葉を使っていて、その間に立つプロジェクトマネージャーは、この対応に頭を悩ませます。
仕様変更は、一度決めたことを途中で変えることであり、そのための交渉や対応方法の検討、計画の見直しに見積りなどやることも多く、プロジェクトを進めながら対応するプロジェクトマネージャーはとても大変です。

かんたんイラスト（記事を読む時間のない人へ）

仕様変更とは

ウォーターフォール型で進めるシステム開発プロジェクトの場合、設計完了を持って仕様を確定し、開発以降の工程は、決めた仕様に基づき算出した費用で進めていきます。つまり、開発以降に、決めた仕様に変更を入れたい場合は、別途お金を頂きますよ、ということになり、この決めた仕様を途中で変えることを仕様変更と言います。
実際のプロジェクトにおいては、仕様を確定したからといって、その後一切の変更が入らずにシステムリリースまでこぎつけることは稀で、「画面の動きを変えたい」「こんな機能を追加して欲しい」など変更がはいることは珍しくありません。
まさに、今(2021年6月時点）話題の野村とIBMの訴訟問題の争点もこの仕様変更になってます。

「変更管理プロセスを定義してあるから大丈夫」ではない

システム開発プロジェクトでは、一度決めた仕様を自由勝手に変更することを防止するために必ず変更管理プロセスを定義します。この変更管理プロセスは、仕様変更が発生した際に、この対応に費用がいくら必要で、費用対効果はあるか、開発スケジュールへの影響はないかなどクライアントと協議して実施するかを判定、合意して進めるルールを決めたものです。
変更管理プロセスを決めてさえいれば安心で、追加費用を請求できれば良いと思っている開発側のマネジメントがいますが、そうとは言えません。
このプロセスに則って進めていったとしても、現場レベルではとても面倒なことが３つあります。

　・瑕疵か要望かの戦い
　・工夫と価格交渉
　・検討コストの回収

変更管理プロセスでは、対応方法の検討や実施するかの判定が簡単に書かれていますが、実態としては、プロジェクトを止めることなく、この検討に時間を割かなければならないため、プロジェクトマネージャーは現場のやりくりに非常に頭を悩ますことになります。しかも仕様変更は、プロジェクト後半の工程で発生するため、ただでさえ負荷が高い中での対応を求められることが多いのです。

頭の痛い問題①「瑕疵か要望かの戦い」

瑕疵は、開発側のミスに起因するため無償での対応が求められますが、仕様変更となる要望は費用が発生します。時には、追加費用を払いたくないクライアントとの間で「これは瑕疵だろ」「いえ、これは仕様変更です」という戦いが勃発し、瑕疵か要望かを判定するために、まるで裁判のような協議が行われます。
この戦いに決着を付けるために、開発側は、設計書から該当する記載を見つけ出し、当時の検討資料や議事録を引っ張り出して、証拠集めに奔走して話し合いに挑みます。
それでも、この記載ではわかりにくいとか、明確に言及されていないとか、解釈の違いを言ってくるクライアントもいますし、酷い時には、こんなことは言わなくても常識的に分かる事だとか、これくらい理解している事は前提として発注している、と言われたこともあります。この揉め事自体も面倒で厄介ですが、プロジェクトマネージャーにとっては、この戦いにプロジェクトメンバーの稼働が割かれることが頭の痛い問題なのです。
エビデンス集めなど要望と証明するための準備作業には、仕様を決めた当時を知るメンバーへの確認が必要で、メンバーが既にプロジェクトを離れている場合には、証人として協議の場に来てもらうこともあります。メンバーが残っている場合でも、プロジェクトの予定作業が入っている中で、この準備作業をお願いすることになり、働き方改革が言われる中で難しい残業対応や作業の入れ替えなどプロジェクトを遅延させないための調整にプロジェクトマネージャーは奔走するのです。
このような戦いをしないように厳密に仕様を定め、クライアントと合意しておくことは言わずもがなです。

頭の痛い問題②「工夫と価格交渉」

協議の結果、仕様変更との判決が下されると、この対応にかかる追加費用がいくらで、当初の納期を変えずに対応できるか等の検討が必要となります。システム開発プロジェクトは、クライアントの予算と納期を目標に進めているため、予算に余裕がない場合には、追加予算の申請が必要となります。かなり上役まで稟議を上げるとなると、クライアントも必死になるため価格交渉が発生したり、もっと簡単に対応する方法や納期に収まるスケジュールの工夫を求めてきたりします。対応方法やスケジュールの工夫には、とても頭を使った慎重で精緻な検討が必要となります。そのうえ、見積りを提示するためには開発マネジメントの承認も必要となるため、時間もかかります。
にもかかわらず、クライアントは、上期の予算に入れたいとか今のテスト工程内に合流したいなど我儘な要求とともにスピード感のある対応を求めてきます。
当然プロジェクトを止めることなく、計画タスクを遅らせることなくこの検討と価格交渉をスピード感をもって実施する必要があるため、プロジェクトマネージャーには、とても高度なやりくりが求められるのです。
仕様変更が次々に発生すると、もはや遅滞なく進めることは困難となるため、導入計画自体の見直しが必要になりますが、開発側としては簡単に言い出せない、クライアント側も受け入れられないというのが現実で、問題が長引き、炎上ひいては訴訟ということに繋がってしまいます。
仕様変更の頻発が予想されるプロジェクトでは、最初から請負契約としないことは言わずもがなです。

頭の痛い問題③「検討コストの回収」

なんとかクライアントとの価格交渉を終え、納期を変えずに対応する計画で合意したとします。にもかかわらず、変更管理プロセスに則って実施するかの判定を行った結果、費用対効果の観点から実施しないとなってしまうことがあります。この場合、検討や見積り、価格交渉などにかかった費用は開発側の持ち出しになってしまうことが多いのです。
検討費用はただと思われているのか、営業費用と見なされているのか、端から費用がかかる発想をもっていないクライアントもいます。
開発側のマネジメントからすると、実施するなら追加費用を請求でき、実施しないならコストが発生しないのでロスはないと思っているかもしれませんが、検討コストは既に発生しているのです。このコストを回収できなければ、この検討作業に要した稼働分は持ち出しの赤字となり、プロジェクトの収支を圧迫します。
変更管理プロセスの中で、検討コストの取り扱いも定義してあれば良いですが、そこまで定義していることは稀ではないでしょうか。

検討コストを回収する方法

仕様変更を実施するかの判定は、費用対効果にもよるため、検討しても実施しないことはよく有ります。影響調査、実施計画、見積り、価格交渉など対応前に費やした稼働分のコストを持ち出しとしないために、検討コストを回収する方法を３つ紹介します。

１．リスク費として予め盛り込んでおく
それなりの規模のシステム開発プロジェクトでは、工程毎に契約を締結することが一般的です。設計が完了した時点で、次の工程である開発以降の見積りを提示しますが、この開発以降の見積りに仕様変更を想定した検討コストをリスク費として盛り込んでおく方法が一つ目です。仕様変更が発生した際の検討コストは、このリスク費を切り崩していくことで、いちいち回収に困らずに済みます。このリスク費をクライアントに正直に伝えるか、あくまで開発費用の一部として提示するかは、開発ベンダーによって対応は分かれるところではありますが、クライアントと仕様変更の発生予想について認識が合っていれば、正直に伝えておく方が良いと思います。例えば、業務部門がユーザーでシステム部門が推進責任を持っている場合には、システム部門としてもリスクヘッジになるため利害は一致します。

２．実施することになった件名にまとめて計上する
実施することになった件名に未実施分の検討コストも含めて請求させてもらう方法が二つ目です。一定数以上の仕様変更がある場合は、それぞれの件名の検討コストの実費をクライアントにも見える形で管理します。一つ一つの件名で見ると小さな額かもしれませんが、ちりも積もればそれなりの額になり、それなりの金額を見せることで、営業費用ではまかり通らない現実を訴えることもできます。そのうえで、実施することになった件名に、実施されなかった件名の検討コストを含めて費用を請求させてもらうように相談しましょう。

３．検討コストを見積りに含めて提示する
最後の手段として、仕様変更が認められた件名だけでも、その検討コストを回収する方法です。仕様変更の対応費用に検討コストを合算して見積りを提示します。実施しない分は、持ち出しとなってしまいますが、最低限は回収できます。

仕様変更が頻発するプロジェクトとは

仕様変更が発生する確率が高いプロジェクトは、始まる前からわかります。このようなプロジェクトを行う場合には、請負契約ではなく準委任契約とするべきです。請負とせざるを得ない場合には、変更管理プロセスに検討コストの取り扱いも明示するなど、事前に打てる対策を取っておくことは必須です。

・業務部門がユーザーでシステム部門がバイヤー
実際にシステムを利用するのは業務部門ですが、プロジェクトの推進責任を持つのはシステム部門といった構図のプロジェクトがあります。システム部門の担当者が、業務部門に代わって、あるいは業務部門の方にも伝わるようにコミュニケーションしながらシステム開発を進めていく形です。
この構図で仕様を握るのがシステム部門となる場合、業務部門のニーズを十分に把握できていないために仕様が甘くなりがちで、プロジェクト後半になって業務部門のニーズと齟齬が発覚し、仕様変更が頻発することがあります。

・業務変化が激しいシステム
オンラインショッピングサイトやビジネスプラットフォームなど業務ニーズの変化が激しいシステムの場合、仕様として決めたことは絶対ではありません。例えば、オンラインショッピングサイトの開発では、仕様を確定したタイミングでは単品売りだけであったものが、その後、セット商品や定期購入の商材を扱うことになったり、途中でポイントやキャッシュバックの仕組みを盛り込むになったりします。競争が激しいビジネスを支えるシステムの場合は、仕様変更は当たり前と思っておいた方が良いです。

・システム刷新
既存システムを新たに作り変える刷新プロジェクトの場合、現行システムで実現していることを完全ではないとしてもある程度再現することが求められます。再現するためには現行システムの仕様を十分に理解して、新たに作るシステムの仕様として落とし込むことが必要ですが、2025年の崖でも言われているように、長く使われてきたシステムはブラックボックス化しているため、設計の段階で現行システムの仕様を完全に洗い出すことが困難です。そのため、テストを実施する中で、現行システムとの仕様の違いや漏れが発覚して、それを仕様変更として扱うことになります。

野村とIBMの訴訟問題は、パッケージに業務を合わせる形で現行システム刷新を行うプロジェクトのようですが、実態は、一部のユーザーが現行要件へ固執して仕様変更が頻発したことを、情シスもIBMもコントロールできなくなってしまったことが原因のように思えます。これはまさに、「業務部門がユーザーでシステム部門がバイヤー」と「システム刷新」がセットになった仕様変更が頻発するプロジェクトの典型です。起こるべくして起きた問題のように感じますが、逆に言うと事前にこのリスクを考慮した計画が立てられなかったのか、想定以上の状況だったとすると、情シスの立場が、ユーザーの味方なのかIBM側だったのか中立なのか、その２点は気になるところではあります。

戦わずして勝つ

昨今は、下請法やコンプライアンスが重視されて、クライアントが高圧的にパワーを見せつけることもなくなってきましたが、小さな戦いはいまだに多く見られます。
冷静に考えると、泥仕合のような戦いは、どっちも労力も精神力も必要となるうえに、勝っても負けても気分は良くないため、一番良いのは戦わないことです。そのためには事前にきっちりと定義し合意しておくことは当然ですが、出来ることは他にもあります。

・クライアントと信頼関係を築いておく
「瑕疵か要望かの戦い」をしないで済むような関係を築いておくことは大切です。信頼関係の中で円満に解決できることがベストです。

・軽微なものは戦わずあえて負ける
対応に少しの工数しかかからない件名であれば、「瑕疵か要望かの戦い」をしているよりも、とっとと対応してしまった方がローコストです。勝手に対応するのではなく、これは軽微だから要望かもしれないけど無償で対応しますよ、と軽く貸しを作りつつ、クライアントの許可を得て対応することは良策です。

・微妙なものは折半
当時のメンバーがもういない場合には、「瑕疵か要望かの戦い」の決着をつけづらいです。そのような場合には、戦うことをせずに、とっとと折半での対応を提案するのも内容と規模によっては有りです。先の見えない戦いほど辛いものはありません。

・助言ができるPMOを組織する
ただでさえ忙しいプロジェクトマネージャーなので、あらかじめ情報を整理しておけるようにPMOを組織しておくと良いかもしれません。また、軽微な仕様変更であれば即対応できるような柔軟な開発チームを持っておきたいところです。開発チームを常時スタンバイさせておくことが難しい場合は、ITコミュニケーターを常駐させておきオフショア開発をすぐに稼働させれる体制にしておくのもよいでしょう。

まとめ

仕様変更は、プロジェクトを進めながらの対応を求められるため、プロジェクトマネージャーはやりくりが大変です。また、事前の検討や見積りを行ったとしても、実施しない判断が下された場合には、検討コストを回収できない恐れもあり、ちりも積もればそれなりの額になって、プロジェクトの収支を悪化させます。逆に言えば、進捗遅延を起こすことなく、収支を悪化させることもなく仕様変更の対応と捌きをすることは、プロジェクトマネージャーの腕の見せ所でもあります。

仕様変更を我儘と置き換えると、我儘に付き合うことが必ずしも良いことではなく、いちいち喧嘩するのも大変なので時にはグレーな方が良い場合もあります。それ以上に、そもそも我儘が起きないような事前対策と起きることの想定をしておくことの方が大事だと思います。
そのために、クライアントと信頼関係を築いておくことも大切ですし、マネジメントにも仕様変更のやりくりの大変さを理解してもらい、できるだけ支援を得られる状況を作っておくことも重要になってきます。
プロジェクトが始まる前に、仕様変更が多く発生することを見抜いて、準委任契約とする方がよいことも、当たり前の話です。いまだに大企業では購買部門によって準委任契約が認められないことが多いのも現実ですが。

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！