システム開発の要件定義で、認識のズレはどこから生まれるのか。この記事では「削除ボタンを1つ追加してほしい」というごく小さな要望を例に、その裏に隠れている7つの論点（対象・確認・方式・復元・権限・記録・影響）を具体的に分解します。物理削除と論理削除の違い、復元期間の決め方、発注側とコンサル側それぞれの「聞き方・答え方」まで、実際の要件定義の進め方をそのまま書きました。開発を発注する立場の方も、要件をまとめる立場の方も、明日の打ち合わせでそのまま使える内容です。
「削除ボタンを1つ、お願いします」から始まる
打ち合わせの終わりに、お客様がこう言ったとします。
聞いた側は「はい、わかりました」と答え、議事録には「顧客一覧に削除ボタンを追加」と1行だけ書かれる。ここまでは、どこの現場でも起きている光景です。
問題は、この1行を受け取った開発側が、そのまま作れないことにあります。作れないというより、正確には「作り方が何通りもあって、どれで作るか決まっていない」のです。
図にすると、こうなります。ボタンは1つでも、決めなければならないことが7つあります。1つずつ見ていきましょう。
論点1：何を、どの単位で消すのか
最初に決まっていないのは、意外にも「何を消すのか」です。
顧客一覧の1行を消す。ここまでは共通認識でしょう。ところが、その顧客に紐づいている契約情報、過去の商談メモ、添付した見積書はどうなるのか。一緒に消えるのか、残るのか。残る場合、親である顧客がいないデータとして扱うのか。
「1件ずつ消す」のか「チェックを付けてまとめて消す」のかも、ここで決めます。一括削除は便利ですが、誤操作の被害も一括になります。
論点2：押した瞬間に消えるのか（確認ダイアログ）
削除ボタンを押した瞬間にデータが消える設計と、「本当に削除しますか？」という確認を1回挟む設計。どちらも正解です。
ただし、選び方には基準があります。
その操作を、その人は1日に何回やるのか。1日に何十回も消す作業なら、毎回の確認は邪魔になります。逆に、月に数回しか押さないボタンなら、確認があっても誰も困りません。
そして、間違えたときの被害の大きさ。取り返しがつかない操作ほど、確認の価値は上がります。逆に論点4で「あとから戻せる」設計にするなら、確認ダイアログは省いてもいい、という判断も成り立ちます。論点同士が互いに影響し合うのが、要件定義の面倒なところであり、面白いところでもあります。
論点3：物理削除か、論理削除か
ここが、発注側と開発側の認識が最もズレやすい場所です。
発注側が見ているのは画面です。ボタンを押したら行が消える。それが「削除」です。
開発側が考えているのは、データの振る舞いです。「消える」とは、データベースから本当に消すことなのか（物理削除）、それとも「削除済み」という印を付けて画面から隠すだけなのか（論理削除）。
この2つは、見た目は同じでも中身がまったく違います。
物理削除は、実装がいちばん簡単で、データも本当になくなります。裏を返せば、「あの顧客、去年消しちゃったけど、取引履歴だけ見たい」と言われたとき、もう見られません。
論理削除は、データが残るので、あとから参照も復元もできます。監査で「いつ・誰が・何を消したか」を問われるような業務では、こちらが前提になることが多いです。一方で、画面上のすべての検索や集計で「削除済みのものは除く」という処理が必要になるため、実装の手間は増えます。抜け漏れがあると「消したはずの顧客が集計に出てくる」というバグにつながります。
ゴミ箱方式は、その中間です。一定期間はゴミ箱に置いて利用者自身が戻せるようにし、期限が来たら本当に消す。メールやファイル管理ツールで馴染みのある形ですが、期限の管理と自動削除の仕組みが要るので、実装コストは3つの中でいちばん大きくなります。
どれが正しいかは、データの性質で決まります。下書きメモなら物理削除で十分ですし、取引記録なら論理削除が安全です。法令や社内規程で保管期間が定められているデータなら、そもそも「利用者が消せる」こと自体を見直す必要があります。
論点4：復元できるか、誰が、いつまで
「間違えて消したら、戻せますか？」
この質問は、要件定義の段階で必ず聞くべきものです。開発が終わってから聞かれても、物理削除で作ってしまったあとでは答えは「戻せません」になります。
戻せる設計にする場合、次の3つを決めます。
- 誰が戻せるか：消した本人か、管理者だけか
- いつまで戻せるか：7日か、30日か、無期限か
- 期限を過ぎたらどうなるか：完全に消えるのか、管理者だけは見られるのか
冒頭の例で「1週間は元に戻せるようにする」と決めたなら、それはゴミ箱方式を選び、復元期間を7日に設定し、期限後は物理削除する、という3つの決定をまとめて下したことになります。この分解ができていれば、見積もりも設計もブレません。
論点5：誰が消せるのか（権限）
削除ボタンは、全員に見えていいものでしょうか。
自分が登録したデータだけ消せる。管理者はすべて消せる。新人アカウントには削除ボタン自体を表示しない。パターンはいくつもあります。
権限の話は、あとから追加しようとすると影響範囲が広くなりがちです。最初のヒアリングで「このボタン、誰が押しますか？」と一言聞いておくだけで、後工程がかなり楽になります。
論点6：削除の記録を残すか（操作履歴・監査ログ）
「誰が、いつ、何を消したか」を記録に残すかどうか。
普段は誰も見ない記録ですが、「消えているはずのないデータが消えている」というトラブルが起きたとき、この記録があるかないかで原因究明にかかる時間は大きく変わります。
社内の複数人が使うシステムなら、残しておく方が安心です。個人用の小さなツールなら、なくても困らないでしょう。ここも、システムの使われ方で決まります。
論点7：消したら、ほかに何が変わるか（影響範囲）
最後に、いちばん見落とされやすい論点です。
顧客を1件消したとき、その顧客の売上は月次レポートから消えるのか。過去の実績として残るのか。連携している別のシステム（会計ソフトや営業支援ツールなど）にも削除を反映するのか。担当者に通知は飛ぶのか。
「消したら数字が変わった」「連携先には残っていて食い違った」というトラブルは、ボタンそのものではなく、この影響範囲を決めていなかったことが原因で起きます。
なぜ、こんなにズレるのか
ここまで読んで、「削除ボタン1つでここまで考えるのか」と感じた方もいるかもしれません。
ズレの原因はシンプルです。発注側は「画面」で考え、開発側は「データの振る舞い」で考えているからです。どちらが正しいという話ではなく、同じ「削除」という言葉で、別のものを見ている。要件定義とは、この2つの視点を1枚の紙の上でつなぐ作業だと、私たちは考えています。
ヒアリングの型：「〜したら、どうなりますか？」
では、コンサルや開発側は、どう聞けばいいのか。
7つの論点を順番に質問していくのは、正確ですが息が詰まります。実際の打ち合わせでは、時間の流れに沿った3つの質問で十分です。
「押した直後」「消えたあと」「間違えたとき」。この3つのタイミングで「どうなっていてほしいですか？」と聞くと、お客様は自分の業務をイメージしながら答えられます。専門用語を使わなくても、7つの論点は自然と埋まっていきます。
たとえば「間違えたとき、どうなっていてほしいですか？」と聞いて、「1週間くらいは戻せると安心」と返ってきたら、それはそのまま論点3と論点4の答えです。
発注側ができること、コンサル側ができること
発注する側の方へ。 「削除ボタンを付けてほしい」と伝えるとき、あわせて一言だけ添えてみてください。「間違えて消したら戻せるようにしてほしい」でも、「消したらもう二度と見なくていいデータです」でも構いません。その一言で、開発側の設計はまったく違うものになります。細かい仕様を知っている必要はありません。「自分の業務でどう使うか」を話してもらえれば、あとは要件をまとめる側の仕事です。
要件をまとめる側の方へ。 「削除ボタン追加」と1行で書いた瞬間に、7つの決定を暗黙のうちに自分が引き受けたことになります。決めきれないなら、聞く。聞けないなら、「今回はこう解釈して作ります」と書き残す。見積もりの前に、この1行がどの方式を指しているのかを明文化しておくと、あとで「思っていたものと違う」と言われる確率はかなり下がります。
書き下すと、こうなる
最後に、7つの論点をヒアリングしたあとの要件を書き下した例を載せておきます。冒頭の「削除ボタンを1つ」が、要件定義書ではこのくらいの分量になります。
【機能】顧客一覧からの顧客削除
対象 ：顧客1件ずつ。紐づく商談メモ・添付ファイルも同時に削除対象とする。
過去の受注実績は削除せず、「削除済み顧客」として集計に残す。
確認 ：削除ボタン押下時に確認ダイアログを表示する。
方式 ：論理削除（削除フラグ＋削除日時を記録）。一覧・検索・集計から除外する。
復元 ：削除から7日間は「ゴミ箱」画面から本人または管理者が復元できる。
8日目以降は夜間バッチで物理削除する。
権限 ：削除は「担当者」ロール以上。「閲覧者」ロールにはボタンを表示しない。
記録 ：削除・復元の操作を操作ログに記録する（操作者・日時・対象ID）。
影響 ：会計システムへの連携は行わない（顧客マスタは会計側で別管理）。
削除時の通知は行わない。
ボタンは1つ。決めることは7つ。この分解ができるかどうかが、開発が「思っていたものと違う」で終わるか、「思っていた通りに動く」で終わるかの分かれ目になります。
要件定義でお困りの方へ
株式会社Four Youでは、AI・システム開発の要件定義から、発注側に立った伴走支援を行っています。「何をどう伝えればいいかわからない」「見積もりが出てきたけれど、妥当か判断できない」といった段階からでもご相談いただけます。
今回のような「小さな要望の分解」を、実際の案件でお手伝いしています。要件定義の進め方でお悩みがあれば、お気軽にお声がけください。
#要件定義 #システム開発 #DX #AI導入 #発注 #ITコンサル #論理削除 #FourYou
