要件定義を一人で頑張りすぎない
要件定義は、システム開発の中でもっとも地味で、もっとも厄介な工程です。特殊な技術がなくても議論には参加できるぶん、発注者が本気を出せば時間を圧縮できそうに見える——その油断が、思わぬ事故を招くことがあります。
要件定義は「運用」と「システム」の両輪で考える作業
要件定義は、業務がどう回るかという運用的な側面と、それをどうシステムに落とし込むかというシステム的な側面を、両方から検討する必要がある作業です。どちらか一方だけを見て決めると、必ずどこかにひずみが生まれます。
特に厄介なのは、すでに運用が始まっているシステムに機能を追加・変更する場合です。新しく作る機能だけを考えていればよいわけではなく、既存の他機能への影響や、これまで積み上げてきた運用上の取り決めとの整合性まで考慮しなければなりません。ここを見落とすと、新機能自体は動いても、周辺で不整合が発生します。
「これなら自分たちでできる」という思い込み
要件定義は、特殊な技術が必要な開発やテストの工程とは違い、業務を知っている人間が頑張れば時間を短縮できそうに感じられます。実際、業務知識という点では発注者側の担当者のほうが詳しいことも多く、この感覚はあながち間違いではありません。
ただし、要件定義に必要なのは業務知識だけではありません。その要件がシステムのどこに影響し、既存のデータやロジックとどう整合するかという視点は、業務側の知識だけでは埋まらない部分です。
「要件定義はほぼ終わらせています」
保守の定例ミーティングで、発注者側の担当者が資料を手に切り出しました。
「こういう機能を追加してほしいです。要件定義はほぼ終わらせています」
要件定義の時間を短縮しようと、担当者は業務時間を使って一人で要件を作り込んでいました。開発担当者が資料を一通り確認したところ、運用フローとの矛盾や、既存機能への影響、例外的なケースの考慮漏れなど、いくつもの問題が見つかりました。
指摘は、ことごとく押し戻された
開発担当者が見つけた問題点を一つずつ指摘しても、返ってくるのは次のような言葉ばかりでした。
- 「運用的にそういうことは発生しないので大丈夫です」
- 「現場にも確認しているので大丈夫です」
- 「完璧に作り込んでいるので、このままで実装してください」
担当者の強気な姿勢に押される形で、開発チームはその内容に沿って開発フェーズへと進むことになりました。
リリース後に押し寄せた問い合わせ
リリース後、多くの問い合わせが殺到しました。
- 「こういう使い方はどうやったらできますか？」
- 「ここの値を更新しても、ここの値が更新されないのですが」
- 「これまであった〇〇処理をすると、想定外の動きをします」
開発担当者が指摘していた問題点の多くが、そのまま現場のつまずきとして表面化した形でした。結局、その機能は徐々に使われなくなり、そこで生まれた不整合の修正に多くの工数を費やすことになりました。
教訓：要件定義は「一人で完成させるもの」ではない
このケースの問題は、担当者が業務時間を使って要件定義に取り組んだこと自体ではありません。「業務知識があれば要件定義は一人で完成できる」という前提のまま、開発側からの指摘を検討の材料ではなく「差し戻し」として扱ってしまったことです。
要件定義は、業務側の知識とシステム側の知見をすり合わせて初めて完成する作業です。発注者が事前に検討を進めておくこと自体は望ましい姿勢ですが、それは「叩き台」として持ち込み、開発側の指摘を踏まえて磨き上げるためのものであって、「完成品」として押し通すためのものではありません。
「運用的に発生しない」「現場にも確認済み」という言葉も、それ自体が悪いわけではありません。ただし、開発担当者からの指摘に対する説明としてそれを使う場合は、なぜ発生しないと言えるのか、どの範囲で確認したのかを具体的に示す必要があります。根拠のない「大丈夫です」は、リリース後に一番高くつく判断になります。