エンジニアのホスピタリティについて考える

この記事はGMOペパボ Advent Calendar 2018の20日目の記事です。 qiita.com Qiita で初めてアドベントカレンダーを見てから、3年位？ついに自分も書く側に回ってみたいなぁと思い書いてみることにします。
年が締めくくられていくこのワクワク感とても好きです。いや、やっぱもう2018年のこり10日とか嘘

自分が「書く」時に気を付けていること

さて今回の表題に関して。
わたしはWebのエンジニアなのですがここでの「書く」というのはコードライティングのことではなく、普段仕事ないしプライベートで書く文章のことをさしています。

というのもここ数年ずっと感じているのが、書く力を伸ばす　のを怠ってはいけないなぁということで、
社会人歴＝エンジニア歴が長くなるにつれて仕事で関わる人が最初は同じエンジニア同士しかいなかったのが、他の職種の人も巻き込んでいかなければいけないことが多くなっていきました。
それはデザイナーだったり、マネージメントをする人だったり、営業やディレクター、エンドユーザの声を直に聞くカスタマーサポートの人だったり。
今は事業会社ですが前は受託開発を主にやる会社だったので上で書いた職種の人でも、相手は同じ会社だったり、請負元の事業会社だったり、同じ事業会社から請け負っている会社だったり様々でした。

色んな立場の人と働く中で、基本的にはオンラインのコミュニケーションで完結するこの業界で
エンジニアとしての技術はもちろん、 「文章を書いて人に伝える力」 も磨き続けなければならないとつくづく実感しています。
文章だけじゃなく対面でのコミュニケーションも然りなのですが。
前置きが長くなりましたが、そんなオンラインでのコミュニケーションで自分が「書く」「伝える」時に意識していること（スタンス）をまとめました。

基本的には

• 読んだ人にどう動いてほしいかを見据える
• 読む人がどう想像するか、どんな情報が欲しいのかを考える

に帰結すると思っています。

知りたいことを訊きたいとき

• なるべく簡潔に、結論を先に
• なぜそれを知りたいのか
  • 自分が掴んでいる内容は？
  • 背景・状況を詳しく
  • いつまでに知りたいのか
• どのくらいの粒度の回答を求めているのか

「知りたいことを訊く」時って、何らかの課題を解決したいからという理由がほとんどだと思います。
例えば SQLを使って検索しても返ってくる結果が0件になる という困りごとに対して、その解決方法を人に聞きたいとき。
この事象を伝えられただけで、その人が解決方法をサッと導き出すのは難しいです。
「何をやってそうなったのか」という背景が分からないと聞かれた側も下手に助言をすることができなくなります。

この事象を深掘りすると、例えばこういうことだったとします。

困っていること：
　・検索結果が0件
やりたいこと：
　・12月の人気ランキングに掲載されているブランドの販売する商品のうち、単価が安い順に10件取得したい。
 　取得したい項目は商品名、商品単価、販売しているブランド名、購入者数、販売開始日時。
期日：
　・明日
やったこと・今わかっていること：
　・このようなクエリで試している（以下SQL）
　・取得するのにA、B、C、DのテーブルをJOINしている
　・必要な情報はAテーブルとBテーブルに含まれている

自分が具体的に何をしたのか、やりたいことは何なのかということが、多少相手に伝わる内容になりました。
これによって伝えられた相手は、得たい情報を取得するのに参照するテーブルは果たしてそれで正しいのかとか、JOINは内部結合でいいのか外部結合にすればいいのかとか、
「やりたい（解決したい）こと」に対して
何を助言すべきか？実現する手段は他にあるか？をその課題に寄り添って考えられるようになると思います。

これは極端すぎる例ですが、ついこういう時って詳細をすっ飛ばして「これってXXをやればいいんですかね！？」っていきなり聞きたくなってしまいます。
なるべくつとめて「答えるのに相手が欲しい情報は何だろう？」を整理するようにしています...

判断を仰ぎたいとき

• 実際に起こっていること、これから起こりうることはどんなことか
  • 事実と考察は違う
    • それが調査した結果の事実なのか、事象に対しての自分の推測なのかは人にわかるように伝えなければならない
• いくつか案を提示したならば
  • 採択にあたってのそれぞれのメリデメ
    • 発生する工数
    • 保守性
    • 影響範囲だったり
• どのくらいの粒度の回答を求めているのか
  • Yes/Noでいいのか、その理由も欲しいのか

例えば障害発生時とか、
その障害の大きさ・程度の差は有れどある程度決められているフローに沿って対応を進めることがどの現場でも多いと思うのですが、
事実と考察 って割と混同してしまうことが多いです。
挙げていることが「調査した結果の事実なのか」、あるいは「事象に対しての自分の推測なのか」は人にわかるように伝えなければ、決める側も適切な判断が下せなくなってしまいます。

また、これこれこういう状況です、と詳細に伝えても、果たしてその相手には何を決めて欲しいのか？その人から誰か他の人にも判断を仰ぐ必要のあることなんだろうか？と、伝えられた人が何をすればいいか分からない、 着地点が分からなくなるような伝え方 になってしまうのも良くないです。
こういう報告時にきちんと精査した内容を書いておくのは

• その事柄についての今後発生するやり取りの手間が減る
• 説得力を増す

というメリットもありますね。大事。

相手がどれだけ自分が伝える内容について理解しているか?

個人的に気をつけているのは対エンジニアでも、そうでなくとも「なるべく低いレイヤーから」「誰にでもわかりやすく」伝えるということです。
例えば極端な例で言うと

この Hoge クラスの fuga メソッドのここ、XX機能の処理を重くしてるので修正したい。

みたいなことを開発を統括するディレクターなどに伝える時。
ある機能の具体的な仕様の話をされても、それがどういう条件で発生するのか、人から見えるところであればどこで動いているのかとか、それを知ってるエンジニアならこれだけをプルリクエストの説明に記載しても「なるほど」で終了する話だけど、それを詳しく知らない人にとっては親切な内容とは言えません。

この画面からこう遷移して表示するこの画面で、XXを入れて検索した時のみ結果が表示されるのにすごく時間がかかってしまっている。
それはXXX呼んでさらにYYYという処理をしてるのが原因なので、これらをZZZをすることで速くなるのでそうするように修正したい。

ちょっと細かすぎ＆実装的なところに寄った話になってますが、落とし込んで説明する、といったことです。

以外と自分達が普段話してる内容って、外から聞いてもごく一部の人にしか内容がわからないことって多いのです。
また

• エンジニアが有してる技術的な見解だとか知識ってある程度共通のものだろうとか
• 機能の仕様であればある程度開発を見てる統括者なら認識してるだろうとか
• そのプロジェクト歴が長い人でも知ってるだろうとか

いうとそんなことは全然ないのです。
全てを知ってる人っていないんですよね。

また上2つで書いた内容は細か目ですが、あくまで「相手がどういう立場の人か、それに合わせて内容を用意する」というのも大事です。
なにかを報告するにしても、報告する人に対しての適切な内容、伝えるべきところはどこまでだろう？を意識します。

ちょっと語り

わたしは、基本的には相手と自分の認識（知識）してるレベルに差がある、という前提で伝える内容を考えます。
自分より相手がその内容に詳しいであろう場合でも、その逆で自分の方が詳しいかもしれないという場合でも同様です。

「相手はこの内容でわかるだろう」という思い込みで「具体的な話だけして認識のズレを生んでしまう」というのはすごく怖いです。

だってお互い安心し合いながら話したい。お互い同じ認識をした上で小気味なギャグとかボケとか挟んで会話終了したい。
まあこれは会話していて極力雲行きを怪しくさせたくない・・・という自分の予防線を張る性格がそうさせているのかもしれないですが。

これって正直、結構しんどいし難しいんですけど、あらためてどういう問題起こってるのかな？を俯瞰してみることもできます。
また色んな人に協力を仰ぐのにも、「誰にでもわかる内容で事象を伝える」 って大事なのです。
協働するって、多少の不便を伴っても、結果的により良い方向に早く導くためには労を惜しんじゃいけないなぁと。

エンジニアの人々はコードを書くときって色んなことを考えて書きます。
書くときの視点は色々あります。よりDRYに、よりステップ数は少なく、よりその言語っぽく書く。etc,...
「自分のコード書く時の流儀」って誰でもあると思いますが、やっぱりわかりやすさを重視するのは大事で

• どう関数をつくろうか？
• I/Oはどうしようか？
• 負荷は？速度は？
• 正常系以外はどうハンドリングしてやるか？
• ログはどう出力しておこうか？

とかとか色々ありますが、コードという資産って自分ではない使う誰かのために書いてますよね。
普段自分が書くコードと同じように、自分以外の誰かのために文章を書くその視点ってすごく大事だと思うのです。

おわりに

…なんだかんだと抑圧された堅苦しい内容になっている気がする。

（ビジネスでも使われる）文章の書き方に関しては、やれPREP法で書けだの、こうこうこういう形式に沿って書けだの、どういう場でも文章を扱う以上ルールにうるさく言われますよね。
作業手順書ひとつ、お客さんとやりとりするバックログひとつ、レビューしてもらって書き方を正されたりしていると「自分の意思で書いた内容なんかもはや残ってないのでは・・・」と思うことが沢山ありました。

が、自分の意思をちゃんと持つということは大事なことであり、その自分の意思が相手に伝えられるようにことばというツールを駆使してやろう！！という気持ちでやってて、何とかやってられていると思います。

「仕事をしていて楽しいと思う瞬間」、人それぞれと思いますがわたしは「関わるメンバーとちゃんと意思疎通ができて」その上でプロダクトを推進できるのが楽しいです。
意思疎通ってあたりまえじゃん、と思うのですが、仕事以外の生活で関わらないであろう人とかトラブルに遭遇して、でも言葉やコミュニケーションで何とか渡っていけるのってすごく尊いことだなぁと改めて思うのです。

わたしは今年の4月にGMOペパボに入社しましたが、我が社の人は職種を問わず「表現力」を磨いている人が多いのが好きです。
ここで書いた内容だけには留まりませんが、ちょっと今回の内容には自分もずっとそう有りたい、という思いを含めました。