「問い合わせに件名を追加してください。必須でお願いします」と依頼されると、入力欄を作れば始められそうに見えます。ところが、下書きでも必須なのか、誰が変更できるのか、すでにあるデータはどうするのかが、実装中に気になってくることがあります。
着手前の仕様確認では、目的・対象者・入力・表示・権限・異常時を具体的な操作に置き換えてみます。全部を一人で決める必要はありません。分かっていることと未決事項を分け、決める人と着手への影響を残すことが、確認の第一歩です。
以下は架空の問い合わせ管理の例です。件名は必須・1〜100文字、状態は「下書き・受付済み・対応中・完了」、利用者は投稿者と担当者とします。数字や状態名は説明用の仕様であり、そのままほかの業務に適用するものではありません。
「必須です」を、利用者の操作へ置き換える
最初に確認したいのは、件名を追加する目的です。「一覧で内容を見分けたい」のであれば、入力画面だけでなく一覧の表示も関係します。担当者が振り分けに使うのか、投稿者が自分の問い合わせを探すのかによって、必要な表示や変更権限も変わります。
次に、操作を一つずつ文章にします。「投稿者が新しく問い合わせを作る」「下書きを保存する」「受付済みにする」「担当者が件名を修正する」と置いてみると、同じ件名でも条件が分かれることが見えてきます。
たとえば「件名は必須」という合意があっても、いつ検証するかはまだ曖昧かもしれません。全保存時に適用するのか、受付時に適用するのかは、作る人が推測して埋めずに確認します。矛盾が見つかったことは、誰かの失敗を証明する材料ではなく、実装前に決める項目が見えた状態です。
六つの観点で、抜けを探す
まずは次の表を、依頼と見比べてください。欄をすべて質問にするのではなく、資料で決まっていることには根拠を付け、判断できない部分を取り出します。
| 観点 | 確認する問い | 問い合わせでの例 |
|---|---|---|
| 目的・対象者 | 誰が何に困っているか | 担当者が一覧で内容を区別したい |
| 入力 | 何を、いつ、どこまで受け付けるか | 件名の必須判定は全保存時か受付時か |
| 表示 | どこで何を見せるか | 一覧と詳細の両方に件名を出すか |
| 権限 | 誰が、どの状態で操作できるか | 受付済みの件名を投稿者が変更できるか |
| 異常時 | 失敗したら何を残し、何を知らせるか | 保存失敗時に入力内容を残すか |
| 既存への影響 | 今あるデータや入口をどう扱うか | 件名のない過去データをどう表示するか |
「1〜100文字」にも確認する余地があります。前後の空白を取り除くのか、空白だけの入力を認めるのか、何を一文字として数えるのかを、利用者に見える条件と実装の両方でそろえます。文字数の数え方をコードの都合だけで決めると、画面の案内と保存条件が食い違うことがあります。
空欄と空白の区別をJavaの処理に落とす段階では、null・空文字・空白の違いが参考になります。ただし、判定方法が分かることと、業務で何を許可するかが決まることは別です。
必須・任意の食い違いは、確認票にする
画面案では件名が任意、依頼文では必須になっていたとします。「どちらが正しいですか」だけでも質問はできますが、対象と影響を添えると判断しやすくなります。
| 項目 | 記入例 |
|---|---|
| 分かっていること | 件名を追加し、一覧から内容を見分ける目的は合意済み |
| 食い違っている根拠 | 画面案の項目説明は任意、依頼文は必須 |
| 未決事項 | 必須にする操作と、下書き保存時の扱い |
| 決める人 | 仕様の承認を担当する人。名前・役割を確認して記入 |
| 着手への影響 | 入力欄の配置は検討できるが、保存条件とテストの確定は待つ |
| 決定後の記録 | 採用した条件、更新する資料、決定日を残す |
「決める人」の欄に、まだ確認していない担当者を勝手に入れないことも大切です。相談先が分からなければ、リーダーに「この仕様は誰が判断しますか」と聞くところから始めます。
相談文にすると、次のようになります。
件名の必須条件を確認したいです。画面案は任意、依頼文は必須になっています。 下書き保存時を含むすべての保存で必須にする理解でよいでしょうか。受付時だけ必須にする場合は、状態に応じて条件を分ける必要があります。 保存条件の実装とテストを確定する前に判断が必要です。仕様の承認担当者と、確認できる時点を教えてください。
「必須でよいですか」という誘導だけにせず、どの操作に適用するかまで揃えると、答えを受け取った後の解釈が少なくなります。
決まらない項目があっても、進める範囲を相談する
未決事項が一つあると、全部止めるか、全部仮置きで進めるかの二択になりがちです。実際には、決定に依存しない作業を切り出せる場合があります。
件名の表示位置や既存処理の調査は進められても、必須判定のタイミングは決定後にする、といった分け方です。このときは、仮の前提を共有し、どの決定が変わるとやり直しになるかを伝えます。独断で既成事実を作るために仮実装を進めるのではなく、確認待ちの間に進めてよい範囲を合意します。
返答が「普通でよい」「使いやすくして」など、まだ操作に変換できない場合は、二つの画面例や具体的な入力例で確かめます。抽象的な言葉を繰り返すより、「この入力では保存を止める理解でよいですか」と尋ねる方が、判断する対象がはっきりします。
回答をもらったら、資料とテストへ戻す
口頭で「下書きでも必須」と決まったなら、確認票だけでなく、任意と書かれた画面案の更新担当も決めます。古い資料が残ると、別の人が再び同じ疑問を持つためです。
そのうえで、「件名が空なら保存されない」「1文字と100文字は受け付ける」など、合意した条件を確認できる形に置き換えます。権限や状態による違いが決まっていれば、それも確認対象に含めます。実装上の責務を考えるときは、ControllerとServiceの入力チェックの役割へ進めます。
仕様の食い違いは見つけたが文章が長くなってしまう場合は、確認メールの整理例も参考になります。ここでの確認票は、正しい敬語を選ぶためのものではなく、何を決めれば実装に進めるかを共有するためのものです。
合意の作り方を広く学ぶなら
『はじめよう！ 要件定義』は、要望を整理し、作ってほしい人と作る人の合意へつなぐ考え方を深めたい人向けの選書候補です。出版社の紹介・目次では、目的の確認やUI・機能・データを考える内容が確認できます。この記事の確認票から、もう少し広い要件の整理へ進みたい場合に合います。出版社の案内
これは読後の体験談ではなく、掲載内容に基づく紹介です。特定の会社の承認手順や、現在の実装仕様をそのまま決める本としては使わず、自分の案件の資料と照らし合わせてください。
書籍を探す場合は、ブログのリーダー候補の本棚（Amazon・広告を含みます）から確認できます。本を購入しなくても、この記事の表で確認は始められます。まず依頼文を一つ選び、「決まっていること」と「誰かに決めてもらうこと」を分けてみてください。
