後出しユースケース

「まぁ、いいか」は、開発終盤に大きな爆弾として戻ってくる。

ユースケースは地味に重要

要件定義において、ユースケースは欠かせない要素のひとつです。「誰が、どのような場面で、このシステムをどう使うか」を整理したもので、これが変わると、システムの内部的な作りや見積もりが大きく変わることもあります。

しかし、実際の現場ではこんな会話が生まれやすいです。

「このユースケースも一応あるんだけど、ちょっとレアケースだし、まぁ言わなくてもいいか」

「普通に使えるだろうから、わざわざ伝えなくても大丈夫だろう」

細かいことを全部伝えるのは面倒ですし、「これくらいは当然できるだろう」という期待もあります。その気持ちはよくわかります。

開発が終盤に差し掛かり、受け入れテストが始まりました。担当者がひと通り操作を試していると、ふと気になりました。

「あ、そういえば、こういう使い方ってどうやってやるんですか？」

ベンダーの担当者の反応が、少しだけ固まりました。

「……その使い方は、現行のシステムでは対応していません」

「え？」

「追加開発が必要になります」

しかも、その機能を実装するには内部の作りを大きく変える必要がありました。単純な追加ではなく、すでに完成している部分に影響が出てくる規模の変更でした。

後からユースケースが出てくること自体、珍しくはありません。ただ、出てくるタイミングが遅いほど、コストとスケジュールへの影響が大きくなります。要件定義の段階で発覚するのと、受け入れテストで発覚するのでは、対応コストがまるで違います。

「おまけ」のつもりで軽く添えたユースケースが、システムの設計を根底から変える可能性もあります。

「これくらいは当然できるだろう」は、確認してから言いましょう。 思い当たる使い方はすべて、できるだけ早い段階でベンダーに伝えるのが、結果的に一番安上がりで、一番トラブルが少ない方法です。