エンジニアとCSをはじめとする非エンジニアの間では、情報共有でのすれ違いが起きやすいです。
自分も情報共有した際に「知りたいことはそこじゃないんだけど…」という雰囲気の返答が返ってくることが度々あります。
仕様の内容は正確に書いたつもりでも、ズレが生じてしまっています。
本記事では、このすれ違いがなぜ起きるのかを整理し、自分が意識していることをまとめます。
自分が考えるすれ違いの正体
エンジニアが仕様を書くとき、自然と「システムが何を・どう変えるか」という視点で構成します。
一方、CSが知りたいのは主に２つです。
- 顧客への影響：この変更でユーザーに何が起きるか
- 自分たちの行動変化：対応フローや説明内容を変える必要があるか
同じドキュメントを読んでいても、エンジニアは「仕様を伝えた」と思い、CSは「自分ごとにできなかった」状態になります。
情報量の問題ではなく、求めている情報がかみ合っていないことが原因と考えています。
なぜ気づけないのか
理由は主に２つあると考えています。
「正確に書く」ことに意識が集中してしまう
エンジニアにとって仕様書は、実装の根拠や変更内容を正確に記録するものです。正確さを追求するあまり、「この情報で読み手は何ができるようになるか」という視点が後回しになりやすいです。
非エンジニアの観点を意識できていない
相手がどういう観点で情報を受け取るかを、自分自身もあまり意識できていませんでした。（いまだにその視点が抜けてしまうこともあります）
相手の業務が見えていないと、何が必要な情報かをイメージするのが難しいと感じています。
意識していること：エンジニアの言葉を翻訳する
個人的に大事だと実感しているのは、エンジニアの言葉を翻訳してから話を進めることです。
書き始める前に想定読者を決め、その人の言葉で書き直すように心がけています。
例えばCSが読むなら、CSの関心軸で必要な情報が何かを先に考えてから構成します。この考え方はテクニカルライティングの原則とも重なります。Technical Writing One でも読み手ファーストの文章構成が体系的に解説されており、参考になりました。
ネイティブアプリエンジニアであれば日常的に使う言葉でも、CSには馴染みがないことがあります。
たとえばこういったズレが起きやすいです。
| エンジニアの表現 | CSが本当に知りたいこと |
|---|---|
| 「セッションの有効期限を変更した」 | ログアウトに関するお客様への案内は変わるか |
| 「強制アップデートのロジックを追加した」 | 古いバージョンのお客様への対応フローを変える必要があるか |
| 「ローカルストレージの保存形式を変更した」 | アップデート後にデータが引き継がれるか |
粒度のズレも起きやすいです。「ユーザー一覧画面のパフォーマンスを改善した」と書いても、CSが知りたいのは「問い合わせが来たらどう答えるか」です。技術的に正確な表現が、読み手の行動に結びつかないことがあります。
この翻訳を意識するようにしてから、認識齟齬による確認のラリーが減った体感があります。
個人の意識に依存するだけでは限界があるので、CSの関心軸をドキュメントのテンプレート項目として定型化することも検討しています。
まとめ
すれ違いの多くは、伝える側の悪意や説明不足ではなく、読み手の関心軸を想像できていないことから来ます。
書き始める前に「この情報で読み手は何を判断・行動するのか」を問う習慣が、一番シンプルな改善だと今は考えています。