はじめに
先日、Qiita主催のイベント「Qiita Night～エンジニア×非エンジニアのコミュニケーション～」に参加しました。
そこで紹介されていた方法が、意外と自分が普段気をつけていることと似ていたので、
もしかしたら自分の事例も参考になるかも？ と思いこの記事を書きました。
想定読者
非エンジニア寄りの立場で、エンジニア・非エンジニア間コミュニケーションの橋渡しに困っている人
※私自身は業務では非エンジニア・非システム部署の立場（経理・営業支援）で、他の人よりはちょっとだけパソコンが分かるレベルです。
そのため、部署内（営業）からのシステムへの要望を取りまとめ、システム部署の担当者とやりとりすることが多いです。
メリット・デメリット
メリット
- システムへの要望が通りやすくなる（感謝される）
- 自部署内で頼りにされる
- 分からないまま放置されて手遅れになる前に相談してもらえる
- システム部署とお互い相談がしやすくなる
※普段からシステム要望を上げている関係で、システムに新しい機能を追加する際は、現場からの意見代表としてモニターで呼んでもらえるようになりました。
デメリット
- とりあえずIT系のサポートは全部あいつに投げておけば良い（システム部署とも交渉してくれる）という立場になる可能性あり
- 基本的に追加の手当は出ない
ですが、その分、通常業務だけでは培えない知識はついたかなと思います。
（調べたりするのも好きなので）
※全国の情シス・サポート部門の方々、私とは比べ物にならないほどの労力を割かれているかと思います。いつもお疲れ様です…。
気をつけていること
対 非エンジニア・エンジニア、シチュエーション別で対応方法が異なるため、分けて記述します。
特に、二つのシチュエーションで使っています。
- システムエラーの問い合わせ
- システムへの要望取りまとめ
また、一番重要なことは 「それぞれが相手へのリスペクトを持つ」 ことだと思います。
「とにかく急ぎで対応してください」といった 相手の状況を全く考慮していない言葉は避ける ようにしています。
ただ、個人的には丁寧に問い合わせをした方が、優先的に対応してもらえている実感があります。
対非エンジニア
エラーの英語メッセージが出ても怖くないことを伝える
プログラミングの勉強をしているとエラーメッセージを読むことは普通のことですが、
あまりシステムに慣れていない方にとっては一大事です。
システムが、エラーの原因や、「操作している人にしてほしいこと」を教えていてくれるんですよと伝えると安心してくれます。
冷静になってから話してもらうことで、状況の聞き取りがしやすくなります。
難しい用語は使わない
弊社は「ブラウザって何？」レベルの方も多いので、ふとした説明の時に出る「ウインドウ」や「タブ」、「ホームボタン」などのワードでも混乱させてしまいます。
説明の時は、「画面の右上」や「星のマーク」など、パッと見て分かるワードで伝えます。
私も全然知らない業界の用語をいきなり言われてもチンプンカンプンなので、相手の理解度に沿った用語選びが重要です。
画像など視覚的な表現を添える
チャットやメールなどで伝えたり、マニュアルを作る際は、スクリーンショットにメモを書き込んだものを渡すことが多いです。
一度誰かと一緒に操作して成功していても、いざ一人でやろうとすると難しいので、実際の操作を丁寧に追えるようにすると、再問い合わせがグッと減ります。
解決策だけではなく、今後の調べ方も伝える
その場限りの対応だけをしても、似たエラーが発生した時の対応力は身につきません。
余裕があれば、エラーメッセージの読み方や、対応策の検索の仕方を教えています。
魚を与えるのではなく、魚の釣り方を教えるイメージです。
数年かけて根気強く伝えたところ、私の上司の場合は、簡単なエラーは自分で対処できるようになりました。
対エンジニア
発生までの経緯・前回の問い合わせ履歴を添付する
エラーの場合は、できれば時系列に沿って、経緯を箇条書きで伝えます。
サービスのアップデートの問題なのかシステム更新が原因なのかなど、すぐ判断してもらえます。
また、再発したエラーでこちらで対処できないものについても、前回の問い合わせ状況・システム部署からの回答も添えて伝えます。
システム部署には全国の支店から問い合わせが来ているので、１から履歴を探す手間を省くためです。
要望の場合も、同様のことを記載します。
できればどこがボトルネックになっているのか、社内システムや部署のどれが絡んでくるのかも添えると、短期的な改修になるのか長期的な改修になるのかを判断しやすくなるようです。
画像など視覚的な表現を添える
対非エンジニアにも同じ項目がありますが、こちらは画面で説明した方が簡単というのが大きな理由です。
公式ドキュメントを参照・該当箇所を添付する
エラーの場合は、公式ヘルプやフォーラムを参照し、似た事例がないかを探します。
それでも解決できず問い合わせする場合は、とにかく自分がどこまで調べたかを明記します。
まとめるのに時間がかかりすぎることもあるので、緊急かそうでないかで調査のやめ時を判断します。
理想としては、簡単に問題の切り分けができると話が早いです（機器側の問題なのか、管理者権限が必要なのか等）。プロではないので断定ではなく、こうではないか……という主旨で記載します。
要望の場合は、現場からの意見を取りまとめた後、参照できれば公式が出している説明資料を読みます。
簡単なカスタマイズが必要なのか大規模な改修になってしまうのかの判断材料にします。
あくまでも下調べなので、実際の開発に貢献できているかは分からないですが、どういったイメージで要望を出しているのかを分かりやすくするのが主目的です。
弊社ではSalesforceを使用しているので、Salesforceが出している学習サイト「Trailhead」で空き時間に勉強しています。
開発側の操作を知ることができるのでとても助かります…！
※2023年12月現在では、まだMOUNTAINEERランクです。精進します。
まとめ
草の根的な活動ではありますが、コミュニケーションコストを減らすことで、お互いに良いフィードバックができる環境を整えられたらいいなと思います。