top of page

成果物が納品前に変更されバグが発生するもシステムの全体を把握できずに失敗

更新日:2022年5月27日

納品後にクライアント様が仕様変更してバグが発生してしまうことはよくあることです。

ちなみに業務システム部が自社開発を行っている企業様の場合に発生しやすいです。



【失敗例】納期を絶対に超えられないシステム開発の外注


新規の開発プロジェクトが立ち、企画段階から参画することになりました。


納期を変更することが出来ないプロジェクトとの意向はあったのですが、想定外因子などによる遅れも認められないのであれば案件の受注は難しいと伝えたところ、ある程度の納期遅れであれば調整可能とのことでしたので受注する運びとなりました。


開発予算は厳しめだったのですが、増員対応については弊社ビジネスパートナー様に協力していただく段取りを取り付けていたのでフレキシブルに稼働することが出来るところまで体制を組むことができました。


ただ、契約の段階になって見積もりの修正依頼が入り予算が削られてしまったため、基本は自社開発のみということになり上司から自社内リソースの確保の指示がでました。


おおよその予算についてはある程度の合意がなされていたので最終段階で開発資金の見直しになることに不安は覚えていたのですが会社の判断もあるため現場の管理をしっかりすることで遅れが発生しないようにすることを至上命題にして開発がスタートしました。


要件定義が無事にまとまり、基本設計、詳細設計まですべて整えることが出来ました。

ここまでは特に問題もなく順調に進みました。


アジャイル開発進行なので各機能ごとに納品を行いながら進めていたのですが、仕様を実現するにあたり想定よりも時間がかかる開発が出てきたことが重なり開発に遅れが出てきてしまいました。


詳細設計に基づき機能ごとにテスト環境に納品していたのですが納期が遅れる可能性が出てきたことを指摘されてしまいました。


納期が遅れる可能性については見積もり時にすり合わせをして、承諾していただいていたので納期遅れについて説明を行いました。


すると、発注者の担当部署である業務システム部が、納期遅れは許されないので内部設計書に基づき同時進行で開発を進めましょうと提案されました。


責任範疇の取り決めを書面化する前ではリスクがあるので同意できないと拒否をしたのですが、それならば納期を守るための修正案を出してほしいと言われました。


結果、両社打合せにより、同時進行で開発がスタートすることになりました。


構築機能ごとに構築者を切り分け開発がスタートしたのですが、弊社で納品したプログラムが改ざんされていることがわかりました。


理由を問うと先方で作成している仕様が変更になったのでそれに合わせて納品プログラムを修正したとのことでした。


そのような状態が頻繁に発生すると全体把握が出来なくなってしまうため開発を続けることが難しいと説明したところ、当初よりアジャイル開発と伝えているため、仕様変更については承諾済であるとの回答が戻ってきました。


すぐに上司報告したのですが既に修正はかなりの範囲に及んでおり、現時点で構築されている全体像を把握できなくなっていました。


クライアント様に確認をしたところ、先方でも全体像を把握できている方がいらっしゃらず結果として誰も全体を把握できていないことが露見しました。


このまま続けていくとバグだらけになってしまう恐れがあると判断しその旨、報告を上げたところ、開発を続けながら全体を把握してほしいと依頼が入りました。


開発が進行しながら全体を把握することは困難であることから経緯と現状を上司に報告したところ、遅れは出るが一旦、開発を全停止し現状把握することが社内決定となり、クライアント様にもその旨、提案することになりました。


増員対応して納期遅れは最小限にとどめることをお伝えし、新規構築を一旦停止し一から見直しが必要との判断になりました。


弊社事由ではない調査となるため追加見積のご提案を行いましたところ、クライアント様より、遅れが生じた責任の一端は弊社にもあるため追加見積は認められないと指摘を受けてしまいました。


この件についてはすでに両社の上司によるすり合わせ調整になってしまい、結論が出るまでの間、一切の開発が停止してしまいました。


結果、当初の追加予算(弊社が出した見積もり額)ではありませんが追加予算を認めていただくことが出来ました。


同時に開発は弊社だけという言質も取り、修正は全体納品後にしてほしいと依頼を出しました。


なんとか了承いただきましたが納期には間に合わず、修正されたのちに発生したバグについて弊社に修正依頼が入るなどもあり、お付き合い自体をクローズする結果となってしまいました。


【失敗の理由】同工程内で複数の開発チームがあるのは危険


発注者と受注者の間でどれだけ詳細なドキュメントを作成しても、予想した通りに稼働しないのがシステム開発の難しいところです。


構築で複数の会社が同時進行するのであれば最初から同時進行を想定した作業工程を組まなければなりません。


途中から開発チームが増えるというのは危険です。


システム開発会社が増員をするという場合と今回のケースは全く事情が異なります。


失敗になってしまった一番の問題点は、結合テストを行う前に構築内容を変更してしまったことです。


仕様が変わってしまったことからの修正であることは理解はできても容認はできません。

その時点でドキュメントと異なる作業が発生しているからです。


まれに、アジャイル開発だからそれもあり得る、といった指摘があるのですがアジャイル開発は根幹は変更せず、機能内で完結する範囲での機能追加や仕様修正です。


多機能の範囲にまで及ぶ修正や追加であれば基本設計から全て変更しなければなりません。


また、失敗例で考えなければならないのはスケジュールと契約です。


納期が厳しい案件を受託する場合、単体テストや結合テストの期間を短く設定することがあります。バグが出ないことを前提としたような工程を引きがちですがバグが出ない開発などあり得ません。


デバッグは別のバグの発生要因になってしまうこともザラにあります。


システム開発の失敗リスクで大きな要因になり得るのがスケジュールを読み違えることです。


致命的になることもあります。


間違えやすいのですが、各工程のスケジュールを開発前に作ってもあまり意味が無いのです。


1つの工程が完了しなければ次の工程のスケジュールを出すことはできません。

最初に引いたスケジュール通りに開発が進むなどということはありません。


最初に取り決めた納品日はシステム開発の全体を把握するための暫定と認識しないとスケジュールに関する失敗は消えません。


構築フェイズなどは特に予想外な問題が発生しやすく工期が延びてしまう原因となります。


トラブル無く構築が終わりことは、ほとんどありません。


納品日絶対からの逆算をしなければならないのであれば発生しうるトラブルを洗い出し、契約時に取り決めをしっかりと書面化しておかなければなりません。


費用の問題でいうと、想定外因子に関して人材の増量に関する追加見積について承諾を得ていなければ失敗まで一直線となってしまいます。


時間を短くするためには物理的な書き手を多くするしか方法がないからです。

ただし、いたずらに人員を増加しても全体を把握できているマネージャーがいなければ意味がありません。


今回のケースでは納期が遅れる可能性を開発会社が説明しており発注者もそれを承諾していますが、実際のところ両者の間で納期遅れに関する時間に差異があることが問題を大きくした要因ではないでしょうか。


動き出してしまってからのトラブルは失敗だけではなくその後の関係値も崩れてしまいます。


納期が厳しい案件を扱わなければならない時は細心の注意をはらって取り決めをまとめなければなりません。


ちなみに弊社では

開発で問題になる原因の1つは納品が遅れることです。


システム開発において納品が遅れることは恥ずかしいことではありますが、想定外因子を事前に知ることはできない以上、自社のスタンスを変更したスケジュールを組むことは避けるようにしています。


工数を多めに計算するのではなく、これまでに行ってきた開発実績から各工程にかかるであろう時間を想定都合で変更するのは避けるべきです。


無理な工程を組めば結果的に失敗開発になってしまう恐れが増すだけです。


弊社でも過去にクライアント様と弊社での同時開発という提案を持ち掛けられたケースがありましたが、基本的にはお断りさせていただいております。


どれほど詳細な内部設計を作ってもなぜか、単体で開発するよりも開発進行が遅れる傾向があるからです。


規模が巨大で複数社が一気に開発に携わるケースというのは確かに存在しますが弊社はそのような巨大案件を得意としておりません。


得意ではないことをすれば必ず歪が生じます。


歪が生じれば納期が遅れる原因となります。追加予算のご提案にもなりかねません。


お金の問題だけではなく、発注者にもご迷惑が掛かってしまうと考えるからです。


従いまして弊社が得意ではないと思われる場合、その理由をお伝えして、案件の受注をお断りさせていただくこともございます。


出来ること/出来ないことをしっかりと説明することが真摯なサービスであると信じています。


bottom of page