開発の最終段階になって修正要求があることの悲劇

顧客と十分に打ち合わせをし、合意を得たと思って開発したはずのシステムなのに最終段階になって「これは頼んだものとは違う」と言われます。

これこそエンジニアにとっての悪夢です。

もちろん顧客にとっても災難でしょう。
こんなことが起こるのには、それなりの原因があります。

エンジニアが経験する最悪の事態は納品時点で、

「我が社が依頼したシステムと違うから、修正してくれ。
　修正するまでは検収（支払い）はできない」

と言われることです。

このような事態に陥ると、プロジェクトチームだけでなく開発側の企業全社にまで悪影響が及びます。

終わったと思ったのに終われない

システムの開発が終了し、納品直前の試験を開始している段階で「修正してくれ」と言われたらどんなことになると思いますか。

さまぎまなレベルでの修正が考えられますが、いずれにせよ問題となる部分を設計からやり直さなければなりません。それで済めばまだ良い方で、それまでの全ての開発作業が無駄になってしまうことさえあります。

完成を目前にして設計から考え直すとなると、設計者やプログラマーを含む開発者、テスト技術者をもう一度手配し、新しくプロジェクトを開始することさえ必要となることもあります。しかも、こんなことをしていたら当然納期には間に合わなくなってしまいます。

また、それがちょっとした変更だったとしても、修正部分に加えて関連部分も再度設計し直し、開発し、検証する作業が発生してしまいます。

さらに開発側の事業として見た場合、たとえば今月末に納品で翌月検収の予定だったから、もう既に次の開発案件を受注してしまっていて、要員計画まで立てていることだってあります。

開発側にとっても、企業活動なわけですから「社員」を遊ばせておいて余裕を作ってる…と言うわけではありません。常に空きがでないよう、先を見越した営業活動などが為されていることでしょう。

にもかかわらず、請求もできない追加作業が発生し、検収もあげられず、延々と要員が解放されなかったどうなると思いますか？

既に次のプロジェクトとして契約を結んでしまっていた場合、その契約内容によっては、契約解除ができなかったり、損害賠償請求をされてしまったり…ということもあり得ます。もちろん開始時期の延伸交渉などもするでしょうけど、発注側にも発注側のビジネスというものがあり「いつでもいい」と言うわけにはいきません。よほどのことが無い限り、揉めるのは必至です。

修正要求には予定外のコストがかかる

ビジネスの世界ではどのような活動にもコストがかかります。

「およそ企業の内部には、プロフィットセンターはない。
　内部にあるのはコストセンターである。技術、販売、生産、経理の
　いずれも、活動があってコストを発生させることは確実である。
　しかし成果に貢献するかはわからない」

ドラッカー名著集⑥『創造する経営者』

というのはそういうことです。

SI事業というのは、経験上ある程度発注側からの「修正要求」を予想しており、その予想範囲で修正分の費用も考慮して見積もっています（「コンティンジェンシー予備費」とか、単純に「バッファ」とか言いますが、それらを積んでいることを発注側に見せることはまずないでしょう）。

ところが想定を超えるような修正が発生してしまうと、プロジェクトそのものが赤字になる恐れが出てきます。

企業は利益を追求するためにビジネスを行っています。
利益を表す公式は単純です。

　利益 = 売上 － コスト（経費）

この原則は、天地がひっくり返っても変わることはありません。

つまり、「修正」による費用負担はそのままコストの増加につながり、利益を圧迫することになります。コストが売上を超える場合には、損失（赤字）になることもあるのです。

ソフトウェア開発やシステムインテグレーションの場合、問題を起こしたプロジェクト…すなわちトラブルプロジェクトが企業全体の利益を損ねることになります。開発企業全体から見れば、まさに「問題プロジェクト」となってしまうわけです。

　「顧客が修正要求を出してきたのだから、
　　修正の費用は顧客に請求すればよいではないか」

という考え方もあるかもしれませんが、しかしそううまくはいきません。顧客だって余分な費用は支払いたくないのですから。

たとえ修正を見込んで、その場合の費用分担を明記した契約をしていたとしでも、「言った、言わない」問題が起こることもあります。

顧客との関係上、修正によって発生する費用を顧客から全額支払ってもらうことができるわけではありません。それをするためには明確な変更管理（変更依頼管理）が行われていなければ、時として負け戦となってしまうことも珍しくないのです。

結局、開発側の予算持ち出しで費用負担を覚悟しなければならないことが多くなります。

労力の面だけでなく、費用の面から見ても、時間の面から見ても、修正要求が発生することはそこに関わるエンジニア、すなわち開発側の会社にとって、

　大いなる悲劇

になるのは間違いないでしょう。

完成の遅れがもたらす問題

修正要求に対応することは、そのシステムの開発プロジェクト単体にとってもプロジ‘ェクト単位の利益が減少するという問題があります。

さらに、修正が発生し、検収が遅れることによる問題は単にプロジェクトレベルだけで終るものではありません。

企業運営というレベルにとっても、さまざまな問題を引き起こします。

検収が遅れることによる入金の遅れ

企業にとって、資金運用は非常に重要です。
いわば経営者自身の仕事２つのうちの１つに支障をきたすということだからです。

企業のトップマネジメントが関わる経常管理の役割の中でも、

　「いつ入金があり、いつ出金があるか」

という資金繰りは、最も主要なミッションのひとつです。

ところでシステム開発を見た場合、費用の支払いというのはいつになるのでしょう。ー般的な製品の売買から考えると「納品時」と思いがちですが、システム開発では「納品」は文字どおり物品を納めるだけのことを指します。

顧客の「検収」が終わるまでは最終の支払いは行われないのが一般的です。

納品の直前に修正要求が出たにしろ、検収時点で問題点を指摘されたり修正の要望が出たにしろ、いずれにしても支払いは後ろへずれこんでいきます。

これは、企業の資金繰りにとっては大きな痛手です。

納期が遅れることによる契約違反

システム開発には完成したものを納品する日、すなわち「納期」があります。この納期は、契約書に書かかれた守るべき重要な義務のひとつです。

ところが、作業のやり直しが先生すると、予定通りにシステムが完成しないことも十分ありえます。こうなると納期には間に合いません。

顧客の側からすれば、頼んだものとは違うものを作って、その修正のために納期が守れなくなるなどというのは契約違反とも考えることができ、結果として損害賠償を詰求したいと考えることだってあるでしよう。

たとえ顧客の修正要求によって引き起こされた納期遅れであっても、とにかく納期が遅れるというのは、開発側にとっても、発注側にとっても一大事なのです。

予定していた他の開発プロジェクトにおける機会損失

企業は、適正に人を配置して仕事を進め、利益を得るように努めています。

営業に何人、経理に何人という配置もそうですし、システム開発のプロジェクトで、どのプロジェクトに何人、そのうちの何人を2ヶ月後から別のプロジェクトに移動させる…というような流動的な配置も、人的資源をフル活用するためのものです。

そしてプロジェクトが予定どおりに進んでさえいれば、開発者の配置も予定どおりにうまくいくわけです。１つのプロジェク卜から次のプロジェクトへと無駄なく人を動かしていくことで、たくさんの仕事をこなせるわけです。

ところが、ひとつでも予定どおりに終了しないプロジェクトがあると、歯車がすっかり狂ってしまいます。

開発者の配置がうまくいかなければ、別のプロジェクトにも悪い影響が出てしまいます。次のプロジェクトを開始できないことだってあるかもしれません。このように、ひとつのプロジェクトでスケジュールが遅れると、他のプロジェクトにも支障が出てきます。

当然できるはずだったプロジェクトがつぶれるなどの機会損失もでてくるのです。

トラブルであれ修正要求であれ、計画通りに進められないプロジェクトというのは

・純粋に利益が低下する
・請求がずれ、資金繰りに影響をおよぼす
・要員計画に影響を及ぼし、機会損失を作る
・機会損失によって、売上が下がる
・顧客満足度低下により、リピート率に影響が出る
・現場の要員に疲弊・不満が出る
・現場の要員の離脱、離職が発生する可能性が高まる
・人的リソースの減少により受注機会や受注数に影響が出る

 などといった悪循環が発生することになりかねません。良いことは何一つないのです。こうした問題の解決は、純粋な技術力の修得だけではどうすることもできません。