iOSエンジニアの 藤井 です。デザインパートナー事業を担う Design Division に所属しています。この記事はGoodpatch Advent Calendar 2021の二日目の記事になります。
最近はSwiftUIを使うことも多く、それについて書くのもいいなと思ったのですが、今年しかない新卒一年目という身分をフル活用するのも今しかない！と思い、今回は「エンジニアのコミュニケーション術」について書いていこうと思います。
昨今、デジタルネイティブという言葉もある通り、中高生の年代から圧倒的な技術力を持っている人がいるのも珍しく無くなってきました。今ではネットを見れば、大抵の情報が転がっているので独学である程度のレベルまで行くことも難しくありません。 では、そんな中で学生と会社に所属するプロのエンジニアを分けるものは何か？となった時に、挙げられるのはおそらく「コミュニケーション」に関するスキルなのではないか、と個人的にこの一年間を通して働く中で感じることが多かったです。 もちろん、俗に言う「コミュ力」を指している訳ではありません。それはむしろそこらのエンジニアより、エンジニアリングに関係ないそこらの大学生の方が高いことも多いでしょう。そうではなく、チームや組織の中で、どう自分の技術力を最大限発揮するか、そのためにどのようにコミュニケーションをするか、というところを話していければと思います。なかなかこういったテーマが語られることは少ないと思うので、ぜひこれから社会人になる学生の方や、インターンとしてさらに活躍していきたい方などの役に立てれば幸いです。
なお、これは自分がOJTとして入った最初の案件で先輩から受けたFBをメインに作った社内ナレッジの再編となります。そのため、若干僕個人の弱みがベースになった記事になっており、またチームビルディングが上手くいっていなかったり企業文化によってそのまま活用できない内容などもあるかもしれませんが、各セクションの冒頭に対象者を書いていくのでぜひ共感する悩みを持っているところから読んでいただくと役立てやすいのかなと思います。
各シチュエーションでのコミュニケーション術
エンジニア主導のミーティングデザイン
対象者
- デザイナーに情報共有をするミーティングを設定し、念入りに準備をして望んでみたが、どれだけ詳しく説明してもあまり響かなかったという経験のある人
- チームの仲間にエンジニアリング観点でわかってほしいことがあり、それをどう説明するのかで悩んでいる人
結論
その情報が、その人にどのような意味を持つかを考え、受け取った人がその後どうすれば良いかまでをしっかり共有できるようにしましょう。
どういうこと？
チームで働く、ということは多くのミーティングが伴ってきます。エンジニアはその職務の性質上、あまり自分からミーティングを主催することは少ないと思うのですが、そんな中このようなシチュエーションはないでしょうか？
- iOSのアップデートで大きなデザインアップデートがあった。うまく対応するためにデザイナーに情報共有したい。
- 実装をしていく中で、工数的にかなり厳しい仕様が出てきた。折衷案を模索するために、その難しさをチームに正確に共有したい。
挙げたのはあくまで一例ですが、このようにエンジニアが主催するミーティングというのは、エンジニア特有の知見の共有といったシチュエーションが多いのではないかなと思います。そこでなるべくわかりやすく、その情報を整理するというのは、ある意味技術記事やカンファレンスに出るのと似ているので得意な人も多いのかなと想像しています。しかし異なる職能がいる場合、それだけでは足りません。いくらわかりやすく説明したところで、それはただ噛み砕かれた知識を受け取っただけで具体的な行動に繋がらないのです。そこで、意識としてその情報に基づいて、聞き手が何をすればいいのかまでを具体的に伝えられるようにしましょう。もしそれを考える中で相手にしてほしいことがなければ、それは実質あまり意味のないミーティングとなってしまいます。伝え方としては例えば、そのアップデートによってデザインファイルを変更してほしいという依頼の形に持っていったり、選択肢を示してあげるなどもそれにあたります。 だからこそ、事前にそこまで考えてミーティングをデザインしていくことが大事になってくるのです。
仕事上のチャット
対象者
リモートワークで相手の時間や状況が見えない時、
- テキストチャットでやってほしいことを投げたが、なかなか見てもらえず、返信を待っている間に期限が迫ってきてしまったことがある人
- 的外れな返信が返ってきて、ちゃんと読んでほしいなとイライラしてしまったことがある人
結論
以下の3点を意識しましょう
- 質問・相談・共有のいずれの投稿なのかを明確にする
- いつまでに、の部分を明確にする
- 事実を明確にする
どういうことか？
Slackなどのテキストチャットを活用している仕事現場、特にコロナ下の二年間でリモートワークが増えてきた現場においては、一日にかなりの量のテキストチャットが飛び交っているのではないでしょうか。そんな中、漫然と書かれたチャットは往々にして斜め読みされ、そして大抵誤解されたまま終わります。結果やはり口頭じゃないと伝わらないと、必要以上にミーティングが開かれ、作業時間が減っていく、そんな流れができてしまっている人も少なくないのではないでしょうか？
この対策についても基本的には前節のミーティングのデザインと本質の部分は同じです。つまり、そのチャットの中で、伝える相手にどうなって欲しいのか、どう行動して欲しいのかがしっかり明確になるようにしなくてはならないのです。 結論の一つ目のポイントである、「質問・相談・共有のいずれの投稿なのかを明確にする」というところで言うと、まずその投稿がどういった性質なのかが明確になっていないと、読んだ人は答えなければいけないのか、それとも確認するだけでいいのかがわかりません。二つ目のポイントの「いつまでに」がはっきりしていない投稿は、忙しい人にとっては次第と忘却されていく存在となってしまいます。また最後のポイントの「事実を明確にする」ということに関しては、対象になるもの、確認した時間、検証に必要な情報などを明確にするということで、これがなければたとえこれまでのポイントが読み取れていたとしても、その人なりにやってみたら全然違う結果になってしまった、なんていうことが起きてしまうかもしれません。 受け取り手のためのデザインともとれますが、これらは全て一発で相手に正確に伝える、余計なコミュニケーションを増やさないための方策でもあるのです。
調査報告を書く時
対象者
- QAエンジニアからすぐにはわからないバグが上がってきて、その調査を行った結果をまとめたい人
- 技術的に難しい仕様を調査したので、その結果を正確に判断に使えるように整えたい人
結論
- 調査中のメモと清書を分けられるようにしましょう
- セクション分けを意識しましょう
- 箇条書きで一文が簡潔になるようにしましょう
どういうことか？
エンジニアの調査作業というのは、大抵の場合試行錯誤の繰り返しになると思います。そうなった場合、どうしても調査をメモする場所と最終的にまとめたい場所が似たところにあると、調査メモの延長線上のように調査報告がなってしまう人もいるのではないでしょうか。そこでまず意識したいのがメモと清書分けることです。当たり前といえば当たり前ですが、時間がないと疎かになってしまいがち。そんな時にはツールごと切り替えると意識できていいと思います。 またセクション分けや箇条書きによって、形式から情報を整理していくというのもわかりやすい文章にするコツです。個人的にはこの時に、「結論→前提→調査の具体」という順番にするのが、読んでほしい順に並べられて良いかなと思っています。
GitHub上やコード中のコメント
対象者
- レビュー側の負担が大きく、なかなかレビューが回りにくい
- コメントの付け方などで迷ってしまう
結論
- 動作確認をテストケースを書く意識で、チェックリストを使ってまとめましょう
- コメントはその場所だけでわかることを書きましょう、また解釈の分かれる表現はしないようにしましょう
どういうことか？
ここに関しては比較的多く語られている部分だと思いますが、まず結論一つ目の動作確認の書き方について。ある程度のルールによってPRの粒度などが決まってきた次の段階に来るのが、いかにレビューしやすくするかだと思います。その点でポイントとなってきたのが、いかに変更に対する動作確認で二度手間を起こさないかというところでした。そこで学んだのが「テストケースを書く意識」の部分で、どれだけ普段テストを書く習慣がなかったとしても、いいPRを作るために勉強するというのは一つの観点だなと感じました。 またもう一つの結論のコメントの書き方に関するところですが、これも自分が指摘されたところベースの話でわかりやすいコメントを書くのはもちろんのこと、別ファイルなどの情報を使わずに解釈できることだけを書くというのも大事な観点でした。これはその後メンテナンスされていく中で、コメントが古くなっていることを検知しにくくなるためです。このように未来の人に残る文章では、未来の人に対することも考え文章をデザインすることが必要になってきます。
プロジェクトでの用語について
対象者
- テキストでコミュニケーションを取ろうとした時、いつも改めてどの画面のことか、どの機能のことかといったような確認作業が発生してしまいがちな人
- FigmaやSketchなどのデザインファイルであったり、実際の実装したもののようなビジュアルがないとコミュニケーションがなかなか進まず、リモートワークが大変だなぁと感じている人
結論
急がば回れ、多少大変でもプロジェクトでのユビキタス言語を定義するようにしましょう （なおここでのユビキタス言語とは、PM・UXデザイナー・UIデザイナー・エンジニアのような実際の作業者のチーム内で共通認識をとるためのものを指し、業界用語のようなプロダクトの性質に応じて生まれる特殊な用語に関しては切り離して考えることとします。）
参考：ユビキタス言語について
❶ ユビキタス言語 1つ目の取り組みは「ユビキタス言語」の構築です。ユビキタス言語はEric Evansが提唱したドメイン駆動設計の要素の一つで、 ユーザーが使う言葉とプログラムの中の言葉を一致させるための用語です。 私が携わったワンキャリアクラウドの開発ではこの手法をUIデザイン・UIコンポーネントに応用して実践していました。
Goodpatchのエンジニアが持つデザインの観点とは？ Goodpatch Engineer Meetup Vol.6より
どういうことか？
これは特に巨大なプロジェクトで起きがちなことですが、画面や機能など呼ぶ名前が決まっていないとどんどんとコミュニケーションが難しくなってしまうことがあります。何より、テキストのログの検索性が非常に下がってしまう恐れもあるため、メンテナンスは少し大変ではありますが、ある画面をなんと呼ぶのか、ある機能をなんと呼ぶのかは整理しておけるといいなと感じました。これは最初からいい名前になっている必要はなく、あくまでチームの中で共通認識が取れる固有の名前であればなんでも良いのかなと思っています。
プロジェクトの把握
対象者
- 質問が思い付かず「大丈夫そうです」と返したが、後から大丈夫じゃなかったことに気づいた人
- 自分の作業は完璧でスケジュールも余裕があったのに、最終的に遅れてしまうということが起こってしまったことがある人
結論
- まずは何を知っていなければならないかという観点の質問もできるように意識しましょう
- 自分の作業の後に、どのようなプロセスが必要なのかをしっかりと理解できるようにしましょう
どういうことか？
ちょっと二つの話はシチュエーションは違いますが、根っこは同じ話です。特にプロジェクトに後から入った場合、往々にしてその人はまず何を知らなくて、自分がどのような立ち位置にいるのかをわかっていないことがあると思います。そこでそれを明確にするというのが、自分がスムーズにプロジェクトに入っていく中で大事だなと思いました。なぜならそのような状態の人は、そもそも自分の中の尺度で全てを判断してしまうため、プロジェクトのプロセスや、特有の知識とズレがあったときに気付かぬまま進めてしまうことがありうるからです。特に二個目に関しては決定プロセスが一番見えにくいのですが、それに関してはデリゲーションポーカーというのが一つ解決策としてあるというのを学びました。デリゲーションポーカーとはプロジェクトの中で、誰がどういうところまで責任を持っているかというのを明らかにするワークで、責任の範囲を可視化することで自分がどこまで決定していいのか、逆にどういう点は自分一人で決定してはいけないのかということを明確に把握することができるようになります。プロジェクト全体を巻き込むソリューションなので、個人で活かすのは難しい部分もあるかもしれませんが、このように権限を正確に把握するというのはどんなチーム形態でも大事なのかもしれません。
まとめ
以上、様々なシチュエーションでのコミュニケーション術を整理して紹介させていただきました。（調査報告のセクションで学んだことを活かしています） これはあくまで解決方法の一例でしかなく、もっとこうすると上手くいった、であったり、自分にとってはうまくいかなかった、みたいなこともあるかもしれませんが、少しでも役に立てていただけたなら嬉しいです。
具体的なところを役立ててほしいというのはもちろんのこと、この根底にある全てを解決できる魔法の言葉が「コミュニケーションをデザインしましょう」というところなのかなと現時点では考えています。もちろん常にそれを続けていくというのは大変ですし、疲弊してしまって本末転倒な事態を引き起こすことがあるかもしれません。ですがそこまでいかなくても、想像を働かせる意識を持っておくことが大事なのかなと思います。そしてその助けとして、技術だけでなくこういったところの学びも広まっていけるといいのかなと思いました。
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味のある方は、ぜひ一度カジュアルにお話ししましょう！
- 新卒採用エンジニア 22卒 / 23卒
- 中途採用iOSデベロッパー
