案件日誌⑦：実測で決める

最終回です。この案件で最も効いた判断を書きます。性能を、机上の比較で決めなかったことです。

要件定義の書類には、たいてい「主要画面は3秒以内」と書かれます。そして書いた時点では、誰もそれが守れるか分かっていません。分かるのは、作り終わって本番のデータを入れたあとです。

検証用のサーバを1台建て、外部から確認できるようにして、案件データを1万件入れました。

結果は、こうでした。

一覧の表示に21.6秒。キーワード検索に22.4秒。1件だけ表示する詳細画面ですら11.7秒。そして全11画面が、90秒待っても表示されませんでした。

原因を追うと、はっきりしていました。1件だけ取りたいときも全件を読んでいたのです。しかも全画面に共通で置かれている件数の表示が同じ処理を呼ぶため、どの画面を開いても22秒を踏む構造でした。

ここで重要なのは、この失敗を要件定義の前にできたことです。設計書に「3秒以内」と書いたあとで発覚したら、設計のやり直しになります。

対策は、段階的に入れました。

1件取るときは1件だけ取るようにする。検索に使う項目には索引を張る。同じ問い合わせの結果は使い回す。そして読み取り用のデータベースを分けました。

索引は30本張りました。そのうち8本は、部分一致の検索を速くするための特別なものです。どの項目で検索されるかを全部洗い出して、漏れがないようにしています。

結果はこうなりました。一覧21.6秒→1.9秒。検索22.4秒→2.6秒。詳細11.7秒→0.04秒。全11項目が3秒以内に収まりました。90秒でも表示されなかった画面は、数秒で開くようになりました。

この数字が、要件定義の議論を変えます。「3秒以内でお願いします」に対して「できます」と答えるのではなく、「1万件で測ってこの数字です」と出せるのです。

最後に、うまくいかなかった話を書きます。

読み取り用のデータベースを分けた構成では、書き込んだ内容を読み取り側へ写す仕組みが必要になります。この写す処理が、ある日データを大量に消しました。1万件あったはずの読み取り側が、82件になっていたのです。

書き込み側は無傷でした。つまり実害は復旧可能でしたが、原因を追うと、いくつも重なっていました。写す処理を途中で止めて再開したときに、消す操作だけが適用され、追加する操作が飛ばされる状態が作れてしまう。しかも復旧作業を2人が同時に進めて、互いの作業を壊していました。

対策は、すでに適用した変更を必ず読み飛ばす仕組みを写す処理に入れることでした。これを入れたあと、同じ条件をもう一度踏ませてデータが1件も減らないことを確認しています。

そして分かったことがあります。この穴は、要件定義の前に踏めたから安く済みました。本番で踏んでいたら、業務が止まっています。早い段階で実物を動かす価値は、速さではなく失敗を安いうちに済ませられることにあります。

7回にわたって書いてきたことを、最後に並べます。

受注した初日に、プロトタイプを触れる品質に上げた。初回打合せから自社の説明を削り、相手の成功条件を聞く時間を作った。分かっていないことを37項目数えて表に出した。データの持ち方を本番と同じ構成に寄せ、見せかけの処理を実物に置き換えた。静かに失敗する箇所を洗い出して潰した。守れない約束を資料から削った。そして1万件で実測し、障害まで踏んで直した。

従来の進め方なら、この大半は要件定義のあと、実装工程でやることでした。しかも一度作ってから直すので、手戻りと呼ばれていました。

AI駆動開発の効果は、「同じことが速く終わる」ではありません。実物が先にできることで、上流でやれることが変わるのです。紙で議論していたことを、触って議論できる。想像で見積もっていた性能を、測って答えられる。本番で踏むはずだった失敗を、要件定義の前に踏める。

速くなった話ではなく、順番が入れ替わった話です。そしてこの順番の入れ替えは、実装の効率化よりもプロジェクトの成否に効きます。

この連載はここで一区切りです。要件定義そのものの記録は、また別の形でまとめます。