top of page

発注者の担当者が上流工程と開発フェイズで変わってしまって失敗したケース

更新日:2022年5月27日

これも非常によくある事例です。発注者で要件取りまとめの部署と実際の開発に携わる部署が異なっており結果として開発会社から追加見積に発展してしまったケースです。

今回はシステム開発会社側の目線となります。



【失敗例】追加要件ばかりになってしまった


発注者からシステム開発の依頼が入り、企画段階からプロジェクトに参加することになりました。


企画、要件のとりまとめから基本設計書にいたるまではある部署の担当者さん4人と詰めていました。こちら側はPM1人、エンジニア3人態勢です。


要件定義に時間はかかりましたがなんとか各種ドキュメントのとりまとめまで進み、見積もりも発注者から承諾いただき設計に基づく構築がスタートしました。


構築フェイズになるとそれまでの部署ではなく業務システム部が担当となりこれまでの担当者さんから別の担当者さんへ変わりました。


開発が進むと新しい担当者さんから追加要件が出始めました。

アジャイル開発なのである程度の追加要件は想定しておりましたが、追加要件の数が増えてきており当初の仕様からおよそかけ離れてしまいました。


上流工程を一緒にやってきた担当者さんが途中で会議に参加されたのですが、追加機能はどれも対応範囲内であるとの見解でしたが実際には追加要件のいくつかは調査が必要であったり、機能の拡充を図ると全体的な設計の見直しにまで波及するような内容もありました。


そこで追加見積のお話をし、リリース日の修正を依頼したのですが、契約はすでに締結されているのでこれ以上の追加予算は支払えない、との一点張りになってしまいました。


上司報告を行いましたところ、各種設計書からおよそかけ離れてしまっているため追加費用が出なければ当初の予定通りの仕様で構築するしかないと言われてしまい大問題になってしまいました。



【失敗の理由】仕様の取りまとめとコミュニケーション


アジャイル開発においてはある程度の追加要件をあらかじめ見込んで開発をスタートします。


ただしそれは何でもかんでも気づいたものを追加するということではありません。

今回のケースで問題になるのは以下。


・発注者の上流工程担当者の開発知見があまりなかった

・担当部署の交代に対して情報の共有が出来ていなかった


発注者に企画から入るときに一番気にしなければならないのは、その担当者さんがエンジニアスキルを持っていない場合、追加要件としてできる範囲をしっかりと理解していただくことです。


極端な話になりますが以下を例題にしてみます。


【企画】申込フォームを作ってほしい

【要件】個人情報の入力項目とカレンダー機能を実装し問い合わせはメールで担当者宛てに届く


非常に雑ですが、上流工程で決められた要件がこのようになります。


いざ開発がスタートすると以下のような追加要件が出てきました。


1.カレンダー機能はGoogleカレンダーと連携してほしい

2.問い合わせ内容は顧客管理システムのDBにも格納してほしい

3.問い合わせ内に決済システムをつなぎこんでほしい

4.問い合わせ内容の選択によってその後の入力項目を変更したい


分かりやすく書いているためかなりおおざっぱになっていますがイメージをしてみてください。


発注者、上流工程を作った部署の追加要件に関する考え


【1】アカウント詳細を出せばGoogleアカウントとの連携は大した問題ではないだろう。


【2】既存システムに連携させるためDBに情報を格納するだけだからDBの設定書を出せば大丈夫だろう。個人情報の取得情報はすべて既存システムのテーブルに対応しているので新たにテーブルを新設する必要が無いので楽な作業のはずだ。


【3】既存で使っている決済システムをAPIでつなぐだけのはずだから工数はかからないはず。


【4】申込内容をプルダウンで選択した後に入力項目を変えても要件で取り決めた項目に変更はないのでそれほど重たい追加ではないはず。



開発会社の追加要件に関する考え


【1】カレンダー機能についての取り決めにGoogleカレンダーとの連携は入っていなかったはず。

汎用的なカレンダーを実装させるつもりがこの追加要件によりGoogleカレンダーの仕様を確認する作業が発生する。調査の時間が必要だ。


【2】当初は構築するフォームの構築のみだったはず。DBに格納するためにはDB設計書など必要情報を取得して構成を確認し、どのように格納すればよいかを設計する必要がある。


【3】これも調査が必要な事案。構築する申込フォーム内だけで完結しないので仕様自体の見直しが必要


【4】選択した内容から入力項目を変更するとなると当初の設計では対応できない。再設計をする必要が出てくる。


実際にこのような追加要件事例はありませんが、極端にわかりやすく書くとこんな感じです。


問合せフォームを作成することに変更はありません。また、カレンダー機能や個人情報の入力項目についても要件定義から変更はありません。


しかし、実際には全く別の問合せフォームになってしまっています。


問題点はどこにあったのでしょうか?


社内の情報共有が充分ではない


申込フォームを作ることはどちらの部署も理解しています。しかし、その完成イメージが合っていません。


合っていなくても大変な作業にならないだろうからなんとかなるでしょう、というのが問題の本質です。


部署間で共有がしっかりとできていないということも問題ですが、1つの案件で担当部署が変更となるのであれば上流工程の段階でも業務システム部から会議に参加しなければなりません。


これだけの追加要件が構築中にいきなり発生するとは考えづらいです。発注者で部署間の情報共有が出来ていないことが考えられます。


最初から部署が変わることがわかっているならば、開発会社側から依頼を出すことも必要だったといえます。

知らなかった場合は交通事故です。


ただ一度、経験すれば次からは確認できることでもあります。

防御策としてはプロジェクトのメンバー構成図などを作成して確認を取るなどが挙げられます。


大きな会社の場合、こういったことはあり得ますから事前に危機管理レーダーを張り巡らせることでこの問題を回避することが出来ます。


追加費用の発生概念を説明する


システム開発で追加費用が発生することはままあり得ます。

アジャイル開発に限らず、仕様が変更になること自体を完全に取り除くことはできません。


追加要件の内容によっては追加見積になることは事前に説明しておかなければなりません。

発注者は追加要件について「費用内でできる」をベースに考えています。


開発会社側は追加要件について「仕様の変更内容によっては追加見積」をベースに考えています。


工数が開発会社の許容している範囲を超える場合、追加費用になりますのでエンジニアスキルが無い方が担当者であるならば特にこの説明は重要になります。


これらはスタートする前に確認しなければなりません。これが一番重要です。


スタートしてから説明をすると発注者はあまり良い気分にはなりません。

事前に追加費用についての説明をしておくことでこうした印象を取り除くことが出来ます。


どうしても理解していただけない場合は設計がどのように変わってしまうのかを図と表にするなどして目で見てわかるようにすることも忘れてはいけません。


ちなみに弊社では


追加要件についてはトラブルに直結するため、常に気を配っています。


これまでの開発経験をまとめておくことはもちろんのことですが担当者が複数人になる場合は役割を明確化するためプロジェクトの役割図など開発がスタートする前にプロジェクトの全体像をいろんな角度で可視化するようにしています。


また、できるだけ追加費用を発生させないことを信条としているため追加要件がどうしても追加見積になってしまう場合は、なぜ、追加見積になるのか?をしっかりとご理解していただくまで説明をするようにしています。


工期がいたずらに延びるよりもいったん取り決めた仕様から逸脱するような追加要件が出る場合はフェイズ2など改めて案件を立ち上げるなどの提案を行います。


実際に構築がスタートすると、あれも、これもお願いしよう、せっかくだから一度にやっつけてしまおう、というのは失敗開発ではよくあるからです。


発注者にいた経験からこの気持ちはよくわかります。ただ、


基本的に確定した仕様はいじらない。


これは失敗しない開発をする上で金言だと思っています。





bottom of page