設計書ではユーザーIDが必須になっている。しかし前回のレビューでは任意と決まったはず。このまま実装すると、外部連携側と条件が合わないかもしれない。
確認メールを書こうとして、経緯を全部説明したら長文になった。この記事は、そんな仕様の食い違いを、設計担当や顧客へ確認するエンジニア向けです。
相手に答えてほしい問いを一文目に置く。
その後へ、食い違っている根拠、実装への影響、判断が必要な時点を付けます。短くする対象は挨拶の重複であり、判断材料ではありません。
「確認をお願いします」だけでは、回答が決まらない
次の文は、事情を説明していますが、相手に何を返してほしいかが最後まで見えません。
先日いただいた設計書について確認したくご連絡しました。3章のユーザーIDが必須となっているようですが、前回レビューでは任意になったと認識しております。必須の場合は外部連携チームへの連絡が必要となりますので、ご確認をお願いいたします。
冒頭を「ユーザーIDは必須・任意のどちらで実装しますか」に変えるだけで、問いが見えます。相手は、その判断のために後続の説明を読めます。
また、実際の資料に「必須」と書いてあるなら「必須となっているようですが」とぼかす必要はありません。資料の記載と、自分の記憶の確かさは分けて書きます。
そのまま組み替えられるメール例
以下は書き方を示す架空の文面です。資料名、版、回答希望時点は実際のものへ置き換えてください。
件名：【仕様確認】ユーザーIDの必須・任意について
ユーザー登録APIのユーザーIDは、必須・任意のどちらで実装するか確認をお願いします。
確認した設計書v1.3の3章では「必須」です。一方、前回レビューでは「任意」と聞いた認識ですが、決定記録はまだ確認できていません。最新の決定と、その記録を教えてください。
必須にする場合、ユーザーIDを送っていない外部連携側の変更調整が必要です。明日の実装着手前に条件を確定したいため、本日中の回答が可能か確認させてください。
決定後は、設計書と連携仕様の更新担当もそろえたいです。
「設計書が間違っている」と先に決めていません。一方で「どちらでもよいので確認してください」ともしていません。最新の決定を確認し、それに合わせて実装と資料をそろえるという依頼です。
根拠は、種類ごとに確かさを分ける
仕様確認では、記憶を事実として書くことも、事実を必要以上に弱めることも避けます。
| 手元にある根拠 | 書き方 |
|---|---|
| 設計書の記載を実際に確認した | 「設計書v1.3の3章では必須です」 |
| 議事録に任意という決定がある | 「レビュー議事録の決定事項には任意とあります」 |
| 会議で聞いた記憶だけがある | 「任意と聞いた認識ですが、決定記録は未確認です」 |
資料が二つとも確認できているなら、両方の該当箇所へリンクを付けます。「こちらを見てください」と大きなフォルダだけ送るより、相手が矛盾箇所へたどり着きやすくなります。
回答期限は、急かす言葉ではなく判断の用途と組にする
「至急お願いします」だけでは、いつまでなら間に合うか分かりません。何の作業や判断に使うかを添えます。
明日の実装着手前に条件を確定したいです。本日中の回答が難しい場合は、回答可能な時点を教えてください。その間、該当条件に依存しない部分を先に進めます。
回答が来ないからといって「返信がなければ任意で進めます」と一方的に決めないこと。未合意の仕様を、相手の沈黙で承認されたことにしないためです。待ちで予定に影響するなら、その影響をリーダーへ戻します。
チャットでは、問いを一つに絞る
相手が同じ資料を開いているなら、背景は短くできます。
登録APIのユーザーIDは必須・任意のどちらでしょうか。設計書v1.3は必須、レビューでは任意と認識しています。必須なら連携側の変更が必要です。明日の着手前に決めたいので、最新の決定を確認できますか。
無関係な質問を続けて詰め込まず、複数あるなら番号を付けます。「承知しました」という返事が、どの問いへの回答なのか分からなくなるのを防げます。
回答が曖昧なら、実装条件へ戻して確認する
返事が「前回の方針で大丈夫です」だけだった場合、そのまま実装へ進むと認識が分かれる可能性があります。
登録APIのユーザーIDは任意とし、未送信でも受け付ける条件で進める理解で合っていますか。
対象と動作まで言い換えます。さらに、設計書を誰が直すかを確認してください。チャットだけが正しく、設計書が古いままだと、次の担当者が同じ場所で止まります。
送る前には、メールの一文目だけを読んでみてください。その一文で相手が何を答えるか分かるか。 分からなければ、敬語の修正より先に問いを書き直すのが近道です。
