案件日誌④：プロトタイプを本物に寄せる

デモ用に作ったプロトタイプには、必ず嘘が混ざります。押すと成功のメッセージが出るけれど、実際には何も保存していないボタン。画面の中に直接書き込まれた条件。見た目を合わせるためだけに用意した固定のデータ。

見せるだけなら問題ありません。ただその嘘を残したまま要件定義に入ると、お客様と私たちの認識が静かにずれていきます。

最初にやったのは、データの保存の仕組みを丸ごと入れ替えることでした。こちらが慣れている方式ではなく、お客様が実際に使っている構成に合わせたのです。

作りやすさで選べば、別の方式のほうが早く進みます。それでも寄せたのは、データの持ち方が違うと、後で判明する制約が違ってくるからです。検索の速さ、同時に更新したときの振る舞い、集計に向いているかどうか。これらは方式ごとに癖があり、本番と違う方式で確かめた結果は、本番の保証になりません。

要件定義の段階で作り替えるのは、まだ安い作業です。設計が終わってから作り替えるのは、そうはいきません。

次に、見せかけだけだった機能を順に実物へ置き換えました。

登録・更新・削除を本物の通信にする。アカウントと権限を実際に保存する。ファイルを実際に保存して、実際にダウンロードできるようにする。帳票を実際に出力する。外部サービスへの通知も、実際に飛ばす（相手が繋がっていないときは、その旨が分かるようにしておく）。

そしてログインの仕組みも、本番と同じやり方に作り直しました。デモでは便利なので、画面上で立場を切り替えて見せる作りにしていました。これをやめて、実際にログインした人の権限だけが効くようにしたのです。

この作り直しは地味ですが、効き方が大きいものでした。権限の話は、切り替えて見せている限り絶対に詰まりません。実際にログインして「見えないはずのものが見えている」に出会って、はじめて具体的な議論になります。

業務の承認の流れは、当初こちらの想像で組んでいました。これをお客様の正式な資料に合わせて、全面的に差し替えました。工程の数は88ありました。

88の工程を実際に画面に載せると、想像で組んでいたときには見えなかったことが出てきます。この工程は誰が終わったと判断するのか。飛ばしてよい場合はあるのか。戻れるのか。

これらは、工程を並べただけの一覧を見ていても出てきません。実際に進めてみて、進められなくなった場所で出てきます。

そしてこの期間の後半は、ひたすら画面に直接書き込まれた条件を設定に追い出す作業に充てました。

承認をどう回すか。何を異常とみなして知らせるか。誰に通知するか。どのくらい放置されたら催促するか。見込みの度合いをどう自動で上げ下げするか。古いデータを何日で片付けるか。

これらは全部、最初はプログラムの中に書いてありました。動きます。デモも通ります。けれどお客様が運用の中で数字をひとつ変えたいと思ったとき、私たちを呼ばないと変えられません。

納品したあとに開発会社を呼ばないと何も変えられないシステムは、だんだん現実と合わなくなります。合わなくなった分は、現場が手作業で埋めます。10年後に「使いにくい古いシステム」と呼ばれるものは、たいていこの積み重ねでできています。

だから要件定義の段階で、どこを設定で変えられるようにするかを決めておくことにしました。これは機能の話ではなく、システムの寿命の話です。

ここまでに書いたことを並べてみます。データの持ち方の全面入れ替え。見せかけ機能の実物化。認証と権限の作り直し。88工程の差し替え。設定化の一括棚卸し。

従来なら、これは要件定義のあとの実装工程でやる分量です。しかも一度作ってから作り替えるので、手戻りとして扱われます。

AIを主力に据えると、これが要件定義に入る前に終わります。そして終わっていることの意味は、時間の節約ではありません。要件定義の議論が、実物を前にした議論になるということです。権限の議論は実際に見えてしまった画面を見ながらやる。設定化の議論は、実際に設定画面を触りながらやる。

紙の上で合意した要件は、たいてい後でずれます。触って合意した要件は、ずれません。

次回は、「動いたように見えて何も起きない」を潰していった話です。