AIでアプリ開発は速くなった。でも要件定義と設計はむしろ重要になった

AIに「在庫管理アプリを作って」と頼むと、商品一覧や入出庫の画面ができるかもしれません。画面が動けば、仕事が前に進んだように感じます。

しかし、現場が困っていたのが「紙に書いた数量を、事務所でExcelへ打ち直す手間」だったらどうでしょう。新しいアプリへの入力が追加されただけなら、作業はかえって増えます。

実装を速められる場面が増えるほど、何を解決するために作るのかを確かめる意味が大きくなります。この記事では、倉庫の記録業務を例に、課題の整理、AIへの指示、設計、検証までを順に考えます。例はすべて説明用の仮定で、特定企業の導入実績ではありません。

1. 作りたいものを、変えたい業務に言い換える

想定するのは、倉庫で商品と数量を紙に記録し、作業後にExcelへ転記している業務です。担当者から「スマートフォンで入力できるようにしたい」という要望が出ています。

ここですぐ画面を作り始めると、現在の帳票をそのままスマートフォンへ移しがちです。まず、記録がどのように使われているかを追います。

• 誰が、いつ、商品と数量を記録しているか。
• なぜ現場でExcelに入力せず、紙を使っているか。
• 転記した情報を、誰が何のために使うか。
• 入力を間違えたとき、誰がどう訂正しているか。
• 紙にだけ残しているメモや、口頭で補っている情報はないか。

例えば、紙を使う理由が「作業場所では通信が不安定だから」なら、オンライン接続が必須の入力画面では困りごとが残ります。紙が確認者への引き継ぎも兼ねているなら、入力機能だけでは置き換えられません。

この確認を経て、目的を「アプリを導入する」から「現場で一度記録した情報を、打ち直さずに事務所で確認できるようにする」へ言い換えます。こうすると、何を試せばよいかが具体的になります。

なお、既存ツールの入力方法やデータ連携を変えるだけで済む場合もあります。新しいアプリ、既存ツールの設定変更、作業手順の見直しを、同じ目的に対する選択肢として比べます。

2. 最初の試作で答えを出す問いを一つ決める

目的が決まったら、最初に何を確かめるかを絞ります。この例なら「現場で商品と数量を記録すれば、作業負担を増やさずに転記を省けるか」です。

試す範囲は、一つの作業と少数の商品に限定できます。全拠点の在庫集計、発注機能、管理者向けの詳細な分析画面まで、同時に作る必要はありません。

今回用意するもの	その理由
商品と数量を記録する画面	現場で入力を続けられるか試すため
保存した記録を確認する画面	記録漏れや入力間違いに気づくため
記録を訂正する方法	間違いが起きたときの実務を確かめるため
事務所で記録を受け取る方法	転記を省けるか確かめるため

「事務所で受け取る方法」は、最初から大きな連携システムである必要はありません。試作ならファイルの出力で確かめる選択肢もあります。ただし、その出力作業に手間がかかるなら、効果の評価に含めます。

また、通信切断が実際に起きる業務なら、切断時の記録を試せない試作品では、重要な問いに答えられません。機能を減らすときは、検証したい条件まで削っていないか確認します。

3. AIには、機能に加えて条件と未決事項を渡す

「在庫管理アプリを作って」だけでは、AIが不足している前提を補う必要があります。補われた前提が現場と合うかどうかは、画面を見ただけでは分かりません。

最初の依頼を、次のように具体化できます。

目的：倉庫で紙に記録した商品と数量を、事務所でExcelへ転記する作業を減らしたい。

利用場面：作業者が商品を扱った直後に、スマートフォンで記録する。通信が切れる場所がある。

今回の範囲：商品と数量の記録、保存結果の確認、入力の訂正、事務所への受け渡し。集計や発注機能は含めない。

未決事項：商品を一覧から選ぶか、バーコードで読むか。複数端末で同じ記録を訂正することがあるか。

最初の依頼：まだ実装せず、確認が必要な点と、試作で確かめられる点を分けて整理してほしい。判断に使った前提も示してほしい。

この依頼の狙いは、最初から完璧な仕様を書くことではありません。分かっていることと、AIに推測で埋めてほしくないことを区別することです。

AIから質問が返ってきても、すべてを会議で決める必要はありません。例えば商品選択の方法は、二つの簡単な画面を作って利用者に触ってもらう方が判断しやすい場合があります。一方、誰が訂正できるかは、業務の責任分担を確認して決める必要があります。

依頼に使う記録は、説明に必要な項目だけに絞ります。試作段階では架空の商品名や数量を使い、実データを使う場合は社内の取り扱いルールと利用環境を確認します。

4. 先に決めることと、試してから決めることを分ける

設計を重視すると聞くと、開発前にすべての細部を確定するイメージがあるかもしれません。しかし、使ってみないと分からないこともあります。

判断の手がかりは、変更したときの影響です。過去の記録、ほかのシステム、権限、日々の作業手順に影響するものは、早い段階で検討します。

先に確認したいこと	試作で調整しやすいこと
何を一つの作業記録として扱うか	画面内の項目の並び順
記録・訂正を誰に許可するか	ボタンの文言や案内文
保存前に通信が切れたらどう扱うか	一覧の表示件数や絞り込み方
訂正前の情報を残す必要があるか	利用者が理解しやすい説明の位置

例えば、保存ボタンを押した直後に通信が切れた場合、利用者は「保存できなかった」と考えてもう一度押すかもしれません。画面上の表示だけでなく、同じ作業が二重に記録されないための扱いも考える必要があります。

ここで決めたいのは、特定の技術を採用することより、「どの状態なら記録済みと表示するか」「再送しても同じ記録として扱えるか」という振る舞いです。技術的な実現方法は、その条件に合わせて検討できます。

将来の拠点数や全機能を予想して大きな仕組みを作る必要はありません。今の検証に必要な条件と、後から直すと影響が大きい箇所を押さえることで、試作を小さく保てます。

5. 「動いた」と「役に立った」を別々に確かめる

試作品ができたら、まず意図したとおりに動くかを確認します。正常に入力できる場面だけでなく、現場で起こり得る間違いや中断も試します。

試す場面	確認する結果
数量を空欄にして保存する	意図しない記録が残らず、必要な入力が分かる
保存中に通信を切る	保存状態が分かり、記録を失わずに再開できる
同じ記録を再送する	二重計上されない
数量を訂正する	訂正結果が反映され、必要な履歴を確認できる
アプリを閉じて開き直す	保存済み・未送信の状態を確認できる

これらは、この例で採用したい動作の候補です。実際の期待結果は、業務上の必要性と実装範囲に合わせて決めます。テストを始めてから都合のよい結果を成功とみなさないよう、事前に書いておきます。

次に、業務の困りごとが改善したかを確かめます。転記時間だけでなく、現場入力にかかる時間、訂正や記録漏れへの対応も含めて比べます。

事務所での転記が減っても、現場で入力待ちが増えていたら、負担を別の人へ移しただけかもしれません。同じ種類の作業で、処理件数や担当者の慣れも記録して比較します。操作に慣れていない初日と、慣れた後の結果は分けて見ると、改善点を整理しやすくなります。

6. 試作ができても、判断できない状態に注意する

次のような状態では、画面が完成していても検証は終わっていません。

• 作った人しか操作していない：実際の利用者が迷わず使えるかは未確認。
• 通信が安定した場所でしか試していない：現場の切断条件に対応できるかは未確認。
• 「便利そう」という感想だけがある：入力や転記の負担が減ったかは未確認。
• 変更前の作業を記録していない：改善したかを比較する材料が足りない。
• うまくいかなかった場合の判断がない：修正を続けるか、別の方法を試すかが決まらない。

結果が悪くても、すぐに機能を増やす必要はありません。入力項目が多すぎたのか、端末を持つこと自体が作業に合わないのか、受け渡し方法に問題があるのかを切り分けます。原因によっては、画面の改善より運用や道具を変える方が適切です。

最初の検証を決めるためのメモ

検討を始めるときは、次の項目を一枚にまとめてみてください。大きな仕様書にする前に、関係者の認識が揃っているかを確かめられます。

項目	この例での記入内容
困っていること	紙からExcelへの転記と、その際の数量の入力ミス
確かめたい問い	現場で一度記録すれば、作業負担を増やさず転記を省けるか
試す範囲	一つの作業、少数の商品、記録から事務所への受け渡しまで
今回は作らないもの	全拠点の集計、発注機能、詳細な分析画面
まだ分からないこと	商品選択の方法、訂正する人、端末を使えるタイミング
比べるもの	現場入力と転記の合計時間、訂正件数、未記録件数
次の判断	負担が減れば対象拡大を検討。減らなければ原因を調べ、修正・別案・中止を選ぶ

「負担が減った」と判断する条件は、開始前に利用者と決めておきます。例えば、時間が短くなっても記録漏れが増えるなら受け入れられない、といった条件です。判断する担当者と振り返る日も、このメモに添えておくと試作を放置せずに済みます。

まずは、今の業務から一つだけ困りごとを選び、上の表を埋めてみてください。未記入の欄があれば、それが次に現場で確認すること、あるいは試作で答えを出す問いになります。