異なる分野の人とのコミュニケーションで気をつけていること 3選

これはフェンリルデザインとテクノロジー Advent Calendar 2021 13日目の記事です。

はじめに

こんにちは。インフラエンジニアの木村奈美です。

フェンリルで毎年実施されているアドベントカレンダー、その執筆者は圧倒的にデザイナーが多いです。とはいえ、デザインの知識がなくても興味深く読めるものが多く、毎年読む側として楽しみにしていました。

今回、自分も書く側としてチャレンジするにあたり、技術ブログとして逸脱しない範囲で、分野を問わず広く読んでもらえる記事にしたいと考えました。

そこで、「異なる分野の人とのコミュニケーション」をテーマとして、ふだん私が気をつけていることを書きます。

フェンリルにはいろいろな職種の人がいます。デザイナー、営業、事務…など。また、エンジニアであっても、アプリエンジニア、Webエンジニア…というように、専門分野の異なるエンジニアもいます。ここでいう「異なる分野の人」というのは、非エンジニアだけではなく、専門分野の異なるエンジニアや、知識の少ない新人エンジニアも含みます。

なお、例としてうまくいかなかったシチュエーションを掲載していますが、これらは全て実例を元にした作り話であり、当事者は存在しません。

気をつけていること3選

その1 相手と足並みを揃えながら会話をする

当たり前のことですが、自分たちが常識として使っている言葉であっても、分野が異なれば伝わりません。これぐらいなら一般的な言葉だし通じるだろう、と思っても、自分の思う「一般的」が相手のそれとは異なる可能性があります。少しでも用語っぽいなと思ったら「〇〇って聞いたことありますか？」と確認しながら話を進めるようにしています。

以前、新人エンジニアにインフラのトラブルシューティングを手伝ってもらう機会がありました。そこで「データベースのレプリケーションが切れてないか確認してください」とお願いすると、「レプリケーションとは何ですか？」という質問が返ってきました。

知らない人向けに簡単に説明すると、レプリケーションとは、1台のデータベースサーバーを元として2台目以降のデータベースサーバーに継続的にデータをコピーすることです。バックアップなどを目的として、本番環境でよく取り入れられます。

新人エンジニアは、新卒研修や個人開発でデータベースに触れることはあるかもしれませんが、それらの場面では基本的に1台で事足ります。 2台目以降を用意する機会は、インフラの実務経験がなければそうそうないでしょう。そのため、レプリケーションを知らなくても当然です。トラブルシューティングを手伝ってもらう前に、前提知識を学習する時間を与えることが必要でした。

自分の常識で話を進めずに、相手と足並みを揃えながら話をしなければ伝わらないと気付かされました。

その2 エンジニアにしか伝わらない表現を避ける

異なる分野の人にも読まれる文章を書くときは、エンジニアにしか伝わらない表現を避けるようにしています。

例えば、エンジニアの間でよく使われる表現として、複数のパターンを意味する (apple|orange|grape)_juice という書き方があります。この例ならば、 apple_juice 、 orange_juice 、 grape_juice の3パターンあるという意味です。

この表現を使って、「(apple|orange|grape)_juice のいずれかの名前で作ってください」と伝えたら、相手に意図が伝わらず、 (apple|orange|grape)_juice という文字列がそのまま使われてしまったことがありました。

伝え方の改善策としては、例を添えるのが手っ取り早く分かりやすいかと思います。

 (apple|orange|grape)_juice のいずれかの名前で作ってください。
例: apple_juice

パターンが少なければ網羅してしまうのも手でしょう。

XXX_juice のような名前で作ってください。XXXには以下のいずれかを入れてください。

- apple
- orange
- grape

この例のような表現は、慣れた側にとっては短い文字数で済んで便利なので、つい使いがちです。伝わる相手であれば問題ないのですが、異なる分野の人が読む場では、ひと手間かけるようにしています。

その3 具体性を上げる

私は今年度から社内GitLabサーバーのメンテナンスチームに参画しています。メンテナンスチームの業務として、4半期に1〜2回、日程を決めてメンテナンスを実施します。

メンテナンス作業中に利用者がGitLabにアクセスすると、意図せぬ問題が発生する可能性があります。一番良いのは、メンテナンス中は利用者にアクセスさせない仕組みがあることですが、社内サーバーという限定的なサーバーのため、残念ながらそこまでは作り込んでいません。そのため、事前に「○月○日にメンテナンスするので、アクセスしないでください」と利用者に告知する必要があります。

告知の対象は社内のエンジニアですが、全員が作業内容を理解しているとは限りません。どうしたらより伝わりやすくなるだろうと考え、以前から使われていた告知文に、少し手を加えました。その一部を引用します。