最初に確認したいこと
その一覧画面は、
本当に「更新する」ことが本来の業務要件なのでしょうか。
それとも、新しい出来事をすぐ知ることが業務要件なのでしょうか。
ここを分けずに設計を始めると、業務要件がいつの間にか「更新ボタン」や「定期更新」という形に置き換わってしまいます。
よくある進み方と、本来確認したい進み方
すぐ方式へ進む例
要求が構造検討されない
お客様：新しい受注をすぐ知りたい
IT：では更新ボタンを付けます
IT：または定期的に一覧を再取得します
これでも画面は作れます。動くものにもなります。 ただし、「なぜその構造なのか」が検討されていない場合、業務要求とのズレが残ります。
要件から確認する例
まず業務要求を分解する
お客様：新しい受注をすぐ知りたい
IT：受注はどのくらいの頻度で発生しますか？
IT：確認したいのは1分未満ですか？数分以内ですか？
IT：更新型と通知型を比較して説明します
こちらは、先に実装方式を決めていません。 必要な即時性、頻度、運用、制約を確認した上で、構造を選ぼうとしています。
更新ボタンが悪いわけではない
更新ボタンや定期更新が悪いわけではありません。 業務頻度、利用人数、通信量、運用コスト、既存システムとの接続条件によっては、更新型を選ぶ方が妥当な場合もあります。
問題なのは、更新型を選ぶことではなく、
更新型にした理由を説明できないことです。
「通知型も検討した。しかし、この制約があるため今回は更新型にした」。 そこまで説明できるなら、それは設計判断です。
要件定義で確認すべきこと
業務側へ確認すること
- 新しい情報はどの頻度で発生するのか
- 何秒・何分以内に知る必要があるのか
- 遅れた場合に業務影響はあるのか
- 誰が、どの画面で、何を把握したいのか
設計側で説明すること
- 更新型と通知型の違い
- それぞれのメリットと制約
- 今回の業務で採用する理由
- 残るリスクと運用上の注意点
要件定義では、「画面をどう作るか」より前に、何をどのタイミングで把握したいのかを確認する必要があります。
「更新したい」は、要件ではなく手段かもしれない
新しい受注をすぐ把握したい
更新型にするのか、通知型にするのか、業務条件から比較する
採用した構造に合わせて、画面・処理・運用を具体化する
「一覧を更新する」は、すでに手段を含んだ表現です。 要件定義では、その前にある本当に実現したい業務状態を確認する必要があります。
簡単なデモ
例えば、更新ボタンや定期更新に頼らない構造も考えられます。 以下は、その考え方を体験するための簡単なデモです。
重要なのは、どう実装しているかではありません。
「問い合わせ続ける」以外の構造も検討対象にできるという点です。
この辺りは、AI丸投げでは難しい
AIは、仕様から実装することは非常に得意です。 一覧画面、登録画面、検索処理、更新処理などは、短時間で形にできます。
ただし、本当に必要なのは更新なのか、通知なのか、どの程度の即時性が必要なのかを整理する部分は、まだ人間側の重要な役割です。
要件整理をしないままAIへ依頼すると、よくある構造がそのまま再生産されます。 だからこそ、AI時代には「要件から構造を考える力」がより重要になります。
最後に
更新ボタンを置く前に、
その“更新”は本当に要件なのか。
そこから考えることが、要件定義の入口だと思います。
更新型が正しい場合もあります。通知型が合う場合もあります。 大切なのは、どちらを選ぶかではなく、なぜその構造を採用したのかを説明できることです。