要件から小さなアプリへ｜ダミーデータで試し、人が確かめる

「こんな道具があれば助かる」を、小さなアプリへ変えるには、最初に何を決めればよいのでしょうか。前回は金川歯科医院の開発記録と確認課題を紹介しました。第6回は、入出力を決め、ダミーデータで試し、人が確かめるまでの流れを、具体例で考えます。

以下の「備品補充依頼アプリ」は説明用の架空の設計例です。実装・試験・実運用の報告ではなく、入力値も架空です。患者情報は使っていません。

1．困りごとを、一つの入出力にする

たとえば「備品が足りないと口頭で伝えたが、何箱必要だったか分からなくなる」という困りごとを想定します。最初の目標は、担当者が確認できる補充依頼を一件残すこと。品目コード「SUP-001」、数量「2」、単位「箱」を入力し、「確認待ちの依頼」として一覧に表示するところまでに絞ります。

ここで、入力する人、確認する人、何をもって完了とするかも決めます。「依頼を保存した」と「業者への発注が完了した」は別の状態です。この例では外部発注を機能に含めず、保存後も担当者が内容を確認する設計にします。画面のボタン名や完了メッセージも、その範囲に合わせます。

「入力できる画面を作って」だけでは、空欄や間違った数量をどう扱うかが残ります。この試作では、品目コードと単位を選択必須、数量を1以上の整数と決める、という具合に条件を具体化します。実際の上限や単位は、業務に合わせて別途決める項目です。

ブラウザー側の入力チェックは、その場で修正を促す助けになります。ただし、サーバーへ送る実装では、受け取る側でも検証が必要です。画面のチェックだけで保存データの正しさを保証できるわけではありません（MDN：フォーム検証）。

小さなアプリを確かめる流れ
入出力と停止条件を決める
↓
架空データで最小の機能を作る
↓
期待した結果と実際の結果を比べる
↓
担当者が確認し、修正後にもう一度試す

試す前に合格条件と操作手順を書いておくと、開発する人と使う人が同じ結果を確認しやすくなります。これはMDNのテスト方針でも示される考え方です。下表は今回の架空例に対する期待結果の案であり、試験済みの記録ではありません。

重複防止や中断時の扱いは、ボタンを置けば自動で備わる機能ではありません。試験用の環境で実装を確かめ、満たせない条件は未解決として残します。試験のために本番の通信や業務データを操作する必要はありません。

フォームの情報を受信した後、画面へ表示するか、データベースへ保存するかは実装によります（MDN：フォームデータの送信）。「保存しました」という表示だけで、想定した場所に記録が残ったとは言い切れません。

この例では、試験用の保存先を開き直し、品目・数量・単位・件数を照合する手順を提案します。画面だけの試作なら「保存機能は未実装」と明示します。担当者は、操作した端末やブラウザー、試した版、期待結果と実際の違いを残し、修正後には該当する場面を再確認します。

試作が動くことと、医院で継続して使えることは別の段階です。実運用へ進む前には、使える人の範囲、保存先、記録の復元、困ったときの連絡先も決めます。今回の例による時間短縮や売上への効果は未検証です。次回は、この流れを支える「ブラウザ・サーバー・ログイン」の基本を整理します。

いずれも2026年10月19日に本文を確認。図と表は、資料の考え方を架空の業務へ当てはめた本記事の設計案です。本記事はAIの作成支援を利用しています。公開後に運営者が確認し、必要に応じて追記・修正します。