慎重に設計してレビューしたはずなのに、ユーザーの変更要望がいつ果てるとも知れずどんどん積み上がる。そんな経験を持つエンジニアは多いのではないでしょうか。良いシステムを作るために、ある程度の変更はやむを得ないかもしれません。しかし度を超すと、プロジェクトは炎上してしまいます。そんな事例を見てみましょう。


「こりゃ、ダメだよ」

 PMの柊聡は、加納次長の言葉に耳を塞ぎたくなった。受け入れテストが始まってからずっと、同じ言葉を繰り返し聞かされている。

「何がダメなんですか?」

「従業員基本情報を検索するときは、漢字氏名で検索できないと。うちは地方の事業所が多くてさ、名字の読みが分からないことが多いんだから」

「外部設計のときに何度も確認して、カナ氏名検索で設計したんですけど」

「外部設計には参画していないから経緯は分からないけど、これじゃダメなのは分かるよ」

 柊は、情報システム部の長田課長の顔を見た。外部設計で、ユーザー側の責任者として仕様を決めてきたのは長田だ。長田課長は、視線を逸らした。

「それから、基本情報を表示するときには、勤務地も出してもらわないと。移動補給金の額は、地域によって違うんだから」

「所属組織で分かるんじゃないですか?」

 長田課長の言葉に、加納次長は首を振った。

「分かるわけないじゃない。例えば営繕一部のサービス区域は、北海道から秋田県まで広がってるんだよ」

 柊は、思わずため息をついた。ほんの1カ月前、基本情報の項目を追加変更したばかりなのだ。

 このところずっと、この調子だった。先月からユーザー受け入れテスト(UAT)を開始して、加納次長をはじめとする業務部のスタッフが検証に参画した。すると、なんと百件以上の変更要望が出てきたのだ。

 いったんUATを打ち切って、要望を整理・対応することになった。そしてようやく変更後のソフトウエアを導入して、今週からテストを再開したのだ。それなのに加納次長は、さっそく数十件の新たな「ダメリスト」を持ち込んできた。

次から次へと変更要求が積み上がりプロジェクトが炎上
[画像のクリックで拡大表示]

 柊は、長田課長に顔を向けた。

「こんなに変更要望があるのでは、スケジュールもコストも守りようがありませんよ」

 長田課長は、苦りきった顔つきだ。

「コストはともかく、スケジュールを動かすのはきついですね。加納さん、このリストの要望は2次リリースに回せませんか?」

 長田とは対照的に、加納次長は涼しい顔だ。

「そう言われてもねぇ」

 一度に言えよ。柊は、そう言いたい気持ちを抑えた。前回追加要望を整理したときに出し切ってもらっていれば、数十件もの追加変更要望は出なかったはずだ。


トラブルの要因

 システムは、設計書やサンプル画面などで事前にチェックするのと、実際に操作してみるのとでは、感覚が違います。リリース時期が近づき、ユーザーが検証し始めてようやくあるべき仕様がはっきりしてくるというのは、ある程度やむを得ないかもしれません。

 要件定義や基本設計に参画する人数は限られていますから、多くのユーザーは、UATやシミュレーションのタイミングになって初めて、新しいシステムに触れることになります。そうすると、開発チームが考えてもいなかった要望が飛び出すことになります。

この先は有料会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら