エンジニアとCSをはじめとする非エンジニアの間では、情報共有でのすれ違いが起きやすいです。

自分も情報共有した際に「知りたいことはそこじゃないんだけど…」という雰囲気の返答が返ってくることが度々あります。
仕様の内容は正確に書いたつもりでも、ズレが生じてしまっています。

本記事では、このすれ違いがなぜ起きるのかを整理し、自分が意識していることをまとめます。

自分が考えるすれ違いの正体

エンジニアが仕様を書くとき、自然と「システムが何を・どう変えるか」という視点で構成します。

一方、CSが知りたいのは主に２つです。

顧客への影響：この変更でユーザーに何が起きるか
自分たちの行動変化：対応フローや説明内容を変える必要があるか

同じドキュメントを読んでいても、エンジニアは「仕様を伝えた」と思い、CSは「自分ごとにできなかった」状態になります。
情報量の問題ではなく、求めている情報がかみ合っていないことが原因と考えています。

なぜ気づけないのか

理由は主に２つあると考えています。

「正確に書く」ことに意識が集中してしまう

エンジニアにとって仕様書は、実装の根拠や変更内容を正確に記録するものです。正確さを追求するあまり、「この情報で読み手は何ができるようになるか」という視点が後回しになりやすいです。

非エンジニアの観点を意識できていない

相手がどういう観点で情報を受け取るかを、自分自身もあまり意識できていませんでした。（いまだにその視点が抜けてしまうこともあります）
相手の業務が見えていないと、何が必要な情報かをイメージするのが難しいと感じています。

意識していること：エンジニアの言葉を翻訳する

個人的に大事だと実感しているのは、エンジニアの言葉を翻訳してから話を進めることです。

書き始める前に想定読者を決め、その人の言葉で書き直すように心がけています。
例えばCSが読むなら、CSの関心軸で必要な情報が何かを先に考えてから構成します。この考え方はテクニカルライティングの原則とも重なります。Technical Writing One でも読み手ファーストの文章構成が体系的に解説されており、参考になりました。

ネイティブアプリエンジニアであれば日常的に使う言葉でも、CSには馴染みがないことがあります。
たとえばこういったズレが起きやすいです。

エンジニアの表現	CSが本当に知りたいこと
「セッションの有効期限を変更した」	ログアウトに関するお客様への案内は変わるか
「強制アップデートのロジックを追加した」	古いバージョンのお客様への対応フローを変える必要があるか
「ローカルストレージの保存形式を変更した」	アップデート後にデータが引き継がれるか

粒度のズレも起きやすいです。「ユーザー一覧画面のパフォーマンスを改善した」と書いても、CSが知りたいのは「問い合わせが来たらどう答えるか」です。技術的に正確な表現が、読み手の行動に結びつかないことがあります。

この翻訳を意識するようにしてから、認識齟齬による確認のラリーが減った体感があります。

個人の意識に依存するだけでは限界があるので、CSの関心軸をドキュメントのテンプレート項目として定型化することも検討しています。

まとめ

すれ違いの多くは、伝える側の悪意や説明不足ではなく、読み手の関心軸を想像できていないことから来ます。

書き始める前に「この情報で読み手は何を判断・行動するのか」を問う習慣が、一番シンプルな改善だと今は考えています。