SEの仕事は、とにかく不具合を出さないようにする正確さが求められますが、そもそも要件定義レベルで破綻していた場合、どんな凄腕の技術者でもどうすることもできません。家屋の土台にスカスカな素材を使っているようなものです。
今回は筆者が経験した中でも、杜撰な仕様からスタートし破綻してしまった案件のいくつかをご紹介しましょう。

名寄せシステムのキー情報漏れ

とある金融系管理システムで、請求データの名寄せ機能を開発したいという要件がありました。その名の通り複数の請求書を、利用者の住所や名前でひとまとめに管理するというものでしたが、管理する情報が多く、なかなかの大規模案件になりました。
しかし、設計書の作成も佳境に入ったという頃、問題が発覚しました。なんと複数あるフォーマットの請求書の中でも、特に重要な２種に、想定していた情報の記載がなかったのです。
当然、これでは一から設計のやり直しになってしまいます。あらゆる手段でキーとなる情報を紐づけられないか努力したのですが、有効な手段が見つからず、プロジェクト自体が頓挫することになってしまいました。

過剰なデータボリューム案件

要件定義云々の前に、営業チームの暴走によって破綻してしまった案件も存在します。例えば筆者の場合、新人の営業メンバーが下調べもせずパッケージソフトの売り込みに行った結果、想定していたデータボリュームを大きく上回る大口の顧客と契約してきてしまったのです。
当然、想定外のデータボリュームのせいで、どの機能も非常に重くなり、まともに使えるシステムではなくなってしまいました。結果としてDB設計の見直しも含む大幅なチューニングが必要になり、とんでもない赤字案件になってしまったのです。

想定外仕様での生体認証

筆者にとって、悪い意味で特に記憶に残っているのは、生体認証による入退室管理システムです。認証機に指を当て、指紋と静脈を読み込んでアカウント管理をする、というシンプルなもので、一見簡単なプログラムに思われました。
悲劇の発端は、この認証期の使用を、要件定義担当者が誤解していたことでした。
本来のこの認証機の使い方は、「まず画面でIDを入力し、パスワード代わりにこの認証機を使う」、というものだったのですが、要件定義の担当者は、「認証機によってアカウント情報を直接呼び出せる」と思いこんでしまったのです。
何が問題だったかというと、この認証機は低価格を売りにした商品で、何百人という人の生体情報を細かく読み込める精度を持っていないことでした。
結果として、指を当てたときに誤認証が多発することになり、リリース間際にしてプロジェクトを一からやり直すという、異例の事態になってしまったのです。
そもそも誤認識を起こす生体認証機自体も問題です。安物買いの銭失いとは、まさにこのことですね。

要件定義での破綻は、全ての努力を無駄にする

どんなプロジェクトにも共通して言えることですが、SEの仕事は、何ヶ月もかけて精密なシステムを組み上げることです。そのために皆、並々ならぬ労力を支払い働いているわけですが、その土台から崩されてしまえば、全ての努力が無駄になってしまいます。それほど残念なことはありませんし、当然、会社にとっても大打撃になってしまいますよね。
クライアントとの要件定義は密に行い、しっかりした土台づくりを確実に行うようにしましょう。