この記事は はてなエンジニア Advent Calendar 2024 12/39の記事 2025/1/8の記事です。
昨日は id:kk__777 さんの IntelliJ IDEA の progress bar を 犬にする pluginでした。
こんなかわいいプログレスバーなら何時まででも待てそうですね！
本当は年末年始でなんかやろうと思っていたけど、思った以上にゆっくりしてしまって書くことがないので、去年を振り返ってコミュニケーションが不十分なことが原因でミスに繋がったことがあったことを思い出し、どういうコミュニケーションが必要なのかを書きます。
関わるプロジェクトはに参加しているメンバーはエンジニアだけではなく、自分と異なる職種の人と一緒に1つのプロジェクトを進めている。
職種が違えば視点も違うので、同じ物事を見ていても自分とは異なる見方をしていて齟齬が生まれてしまうことがある。
それはエンジニア同士でも、サーバサイドエンジニアとアプリエンジニアでも言えることで、同じGraphQLのスキーマを見ていても、前提条件が異なると期待した動作にならないことがある。
例えば、「マンガが購入可能かどうかを示すフィールドが真だったので購入リクエストを送ったところ、ポイント不足でエラーになってしまった」というケース。 購入可能という状態の認識に齟齬が生まれていて「必要なポイント数を所持している」という条件を含めるかどうかがすり合わせできていなかったことで起こる問題だ。
ジョハリの窓
自分はこういうすれ違いが起きないようにするため、普段から ジョハリの窓 に置き換えて考えることがある。ジョハリの窓は自己分析で用いられるものだが、対象をプロジェクトやシステムにすることで認識を合わせるためにも応用できるツールだと思っている。
プロジェクトで考えると、
開放の窓: 全員が知っている情報
秘密の窓: 自分だけが知っていて、他の人は知らない情報
盲点の窓: 他の人は知っているが、自分が知らない情報
未知の窓: 誰も知らない情報
と考えることができる。
コミュニケーションによって適切な情報共有ができると、矢印のように解放の窓を広げていくことができる。
しかし、ここで気をつけなければいけないのは自分から伝えるだけでは不十分ということだ。一方的な伝達だけだと秘密の窓から開放の窓を広げる下向きの矢印はできるが、盲点の窓から開放の窓を広げる右向きの矢印の効果は得られない。
どんなアクションができるか？
どんな情報のすり合わせが必要か分かったところで、それを適切に伝えたり、受け取ったりできないと意味がない。 普段自分がどんなことに気をつけているかというと、世間的にも良く言われていることをやっているだけで何か特殊な方法を用いているわけではない。
- 具体例を織り交ぜて会話する
- こういう状態でリクエストを送るとこういうレスポンスが返るというような例があった方が相手の理解度が高まる。実装する際のテストケースにもなるので一石二鳥!!
- 聞いたことを自分の言葉で言い換えて確認する
- 聞いた内容にちょっとでも不安があるときは、こういうことですか？と聞き返す。自分の言葉で説明できるくらいになっていればその情報は開放の窓になったと十分言えるはずだ。
- ちゃんと聞いてなかったのかと怒られることを心配するひともイルかもしれないが、正しく理解しようとする姿勢が相手にも伝わることはむしろポジティブに捉えられることも多い。
- 話した内容を文章に残しておく
- 伝えるという面では会話の方が有利だが、時間が経つにつれて記憶は曖昧になって、一度開放の窓にあった内容が秘密の窓や盲点の窓になってしまうこともある。あとから見返せるようにテキストで残しておこう
まとめ
チームで進めて行く以上はコミュニケーションは必要不可欠なことだし、それが原因ですれ違いが起きると戻り工数も発生して勿体ないことになってしまう。 コミュニケーションにちょっと気をつけるだけで大きなリスクを回避できることも多いので話す側としても聞く側としても当事者意識を持って取り組みましょう。
