机上で100項目チェックするより、本物に近い1件を流したら設計の継ぎ目が見えた。

システムを作ったら、当然テストをする。

入力できるか。
保存できるか。
検索できるか。
カレンダーに表示されるか。

一つずつ確認していけば、「正常に動いている」という判断になる。

ところが今日、MVPを実際に使ってみて、改めて感じたことがあった。

机上で100項目チェックするより、本物に近い1件を流した方が、設計の継ぎ目が見えることがある。

たった1件の入力だった

今日、開発中の面談記録システムに、実際の利用を想定して1件入力してみた。

音声や文章からAIが内容を整理し、記録として保存する仕組みだ。

入力そのものは正常。
AIの整理も正常。
Googleシートにも保存されている。

ところが、月間カレンダーを見ると、その記録がない。

「あれ？」

前月の記録はちゃんと表示されている。

保存に失敗したのかと思って確認すると、データはある。APIからも正常に返ってきている。

問題は、もっと小さなところにあった。

「不明」が正しかったから起きた

その記録では、会話の中で面談日を明確に言っていなかった。

だからAIは勝手に日付を推測せず、

面談日：不明

と処理した。

これは正しい。

システムにも、面談日が分からなければ「入力を受け付けた日」を使う仕組みを用意していた。

ところが実際のプログラムでは、

「面談日が空欄なら受付日を使う」

という処理になっていた。

空欄なら大丈夫。

しかし、

「不明」は空欄ではない。

プログラムは「不明」という文字を面談日として採用しようとする。当然、日付には変換できない。

その結果、データは存在しているのにカレンダーから消えていた。

1件の不具合から、別の画面にもつながった

最初はカレンダーだけの小さなバグだと思った。

ところが同じ考え方でコードを調べていくと、別の顧客向けMVPにも似た処理が残っていた。

さらにカレンダーだけではない。

月別の一覧、担当者別の集計、検索結果の日付や並び順。

同じ「主となる日付が使えなければ受付日に戻る」という処理が、いろいろな場所に存在していた。

たった1件のテストから、複数のシステムにまたがる共通の弱点が見つかったことになる。

テスト項目では見えにくい「継ぎ目」

もちろん、チェックリストによるテストは必要だ。

ただ、チェックリストはどうしても、

「正しい日付を入力する」
「保存される」
「カレンダーに表示される」

という、きれいな条件になりやすい。

実際の現場はそんなにきれいではない。

日付を言わない。
名前が分からない。
途中で話が変わる。
必要な情報が抜けている。

そしてAIを使ったシステムでは、AIが無理に補完せず「不明」と返すことも重要になる。

今回の問題は、個々の機能ではなく、AIの出力と従来のプログラム処理との継ぎ目にあった。

ここは机上の機能テストだけでは見落としやすい。

MVPは「完成してから使う」のではない

MVPというと、「最低限の機能で早く作る」という部分に目が行きがちだ。

でも、本当の価値はその先にあると思う。

早く作るから、早く本物を流せる。

そして本物を流すと、設計者が想定していなかった使われ方が出てくる。

今回も、大量のテストデータを投入したわけではない。

本番に近い形で、たった1件入力しただけだった。

それだけで、

「データは保存されているのに、なぜ見えない？」

という違和感が生まれた。

その違和感を追いかけた結果、共通する設計上の穴までたどり着いた。

本物に近い1件を、できるだけ早く流す

システム開発では、バグをゼロにしてから現場に出したくなる。

でもMVPでは、別の考え方もできる。

小さく作る。
壊れてはいけない部分を確認する。
そして、できるだけ早く本物に近い1件を流す。

そこで出てきた違和感を拾って、また直す。

今日の経験で、この繰り返しの意味がよく分かった。

机上で100項目チェックすることも大切だ。

でも時には、

本物に近い1件を流したら、設計の継ぎ目が見えた。

そんな1件の方が、100個の「正常」より多くのことを教えてくれる。