仕様確認のチェックリスト｜実装前に聞くべきことと質問例

「問い合わせに件名を追加してください。必須でお願いします」。入力欄を作れば始められそうでも、下書きの扱いや変更できる人、過去データへの影響が気になることがあります。

以下は架空の問い合わせ管理の例です。件名は必須・1〜100文字、状態は「下書き・受付済み・対応中・完了」、利用者は投稿者と担当者とします。数字や状態名は説明用の仕様で、そのままほかの業務に適用するものではありません。

「必須です」を、具体的な操作にする

まず、件名を追加する目的を確かめます。「一覧で内容を見分けたい」なら、入力画面だけでなく一覧表示も関係します。担当者の振り分け用か、投稿者が自分の問い合わせを探すためかで、表示や変更権限も変わります。

次に「投稿者が新しく作る」「下書きを保存する」「受付済みにする」「担当者が件名を直す」と、操作を一つずつ文章にします。

「必須」の合意だけでは、いつ検証するかまでは決まりません。全保存時なのか、受付時だけなのかを確認します。食い違いは誰かを責める材料ではなく、実装前に決める項目が見つかった状態です。

六つの観点で、仕様の抜けを探す

次の観点を依頼と見比べます。すべてを質問にせず、資料で決まっていることには根拠を付け、判断できない部分を取り出してください。

• 目的・対象者：誰が何に困っているか。例：担当者が一覧で内容を区別したい。
• 入力：何を、いつ、どこまで受け付けるか。例：必須判定は全保存時か受付時か。
• 表示：どこで何を見せるか。例：一覧と詳細の両方に件名を出すか。
• 権限：誰が、どの状態で操作できるか。例：受付済みの件名を投稿者が変更できるか。
• 異常時：失敗時に何を残し、何を知らせるか。例：保存失敗時に入力内容を残すか。
• 既存への影響：今あるデータや入口をどう扱うか。例：件名のない過去データをどう表示するか。

「1〜100文字」も、前後の空白を取り除くか、空白だけを認めるか、何を一文字と数えるかを確認します。コードの都合だけで決めず、画面の案内と保存条件をそろえます。

Javaでの判定はnull・空文字・空白の違いが参考になります。ただし、判定方法を知ることと、業務で何を許可するかを決めることは別です。

必須・任意の食い違いを確認票にする

画面案では任意、依頼文では必須だったとします。「どちらが正しいですか」に、対象と影響を添えると判断しやすくなります。

決める人を勝手に割り当てず、相談先が不明ならリーダーに「この仕様は誰が判断しますか」と聞くところから始めます。

「必須でよいですか」と誘導するだけでなく、どの操作に適用するかまで確認すると、回答後の解釈が少なくなります。

確認待ちの間に進める範囲を相談する

未決事項があっても、全部止めるか、全部仮置きで進めるかの二択ではありません。表示位置の検討や既存処理の調査は進め、必須判定のタイミングは決定を待つ、と分けられる場合があります。

その際は、仮の前提と、どの決定が変わるとやり直しになるかを共有します。仮実装を既成事実にせず、進めてよい範囲を合意します。

「普通でよい」「使いやすくして」など、操作に変換できない返答には、二つの画面例や具体的な入力例を使います。「この入力では保存を止める理解でよいですか」と、判断する対象を確かめます。

回答を資料とテストへ戻す

「下書きでも必須」と決まったなら、確認票を更新し、任意と書かれた画面案を直す担当も決めます。古い資料を残すと、別の人が同じ疑問を持つためです。

「空なら保存されない」「1文字と100文字は受け付ける」など、合意した条件を確認できる形にします。権限や状態による違いも含めます。実装上の責務はControllerとServiceの入力チェックの役割を参照できます。

相談が長文になる場合は確認メールの整理例も参考になります。目的は敬語を選ぶことより、何を決めれば実装に進めるかを共有することです。

合意の作り方を広く学ぶための本

まず依頼文を一つ選び、「決まっていること」と「誰かに決めてもらうこと」を分けてみてください。