コミュニケーションに臨む態度

はじめに

こんにちは。Circuit Xで主にサーバーサイドの開発を担当している高田です。

エンジニアとして会社組織で働き、何かしら業務上の成果物を生み出す上で様々なコミュニケーションが必要になります。
今回は、「エンジニアとしてのアウトプット」を大きくする上で、私がコミュニケーション上意識している事を書いてみます。

補足

「エンジニアとしてのアウトプット」とは、「作成したプログラム、コード」によって評価されるのが妥当であり、
（付随して各種ドキュメントの整備等）
評価軸として 「品質 × 速度 × 再現性 」の三要素で成果物を測るのが妥当です。

品質とは：
不具合が少ない、実行速度が速い、可読性が高い、長期的な運用に耐えうる

速度とは：
機能のリリースまでの時間が短い、レビューに要する時間が短い

再現性とは：
・上記二点における、外的要因（ツール、チームからのサポート…）への依存度が低い

この前提に基づいて、私がコミュニケーション上意識している点を書きます。

早い段階でカジュアルに頼る

フクロウラボが提供する「Circuit X」は巨大な広告システムであり、複数のコンポーネントが連携して単一のサービスを提供しています。
開発組織の状況としてはコンポーネント単位でのチーム編成を行っておらず、全バックエンドメンバーが必要に応じて各コンポーネントにコミットするような組織編成です。

ある機能を実現する際に行う改修範囲は多岐に渡り、実装時に既存の仕様や関連するコンポーネントが不明な場合もあります。
ドメイン知識や技術的知識が他のメンバーと比べて不足しているような状況下では、タスクの初期段階からチームメイトをカジュアル（≠ 粗雑）に頼るべきで、その方がリリース速度、品質の面で良い結果を生みます。
知識量を増やし、自走できる時期を早めるという点でも先輩の知恵を借りる事は有効です。

また、単純なコーディング、実装という文脈においても、コードレビューの段階で初めて他者に晒すより、もっと前段で「できるエンジニア」を頼る方が、全体として組織資産を増やす事に寄与します。

技術的な理解が深いエンジニア、ドメインへの理解が深いエンジニアに早く、小さく、細かく頼る事で全体の作業工程を圧縮し、プログラムの品質もより向上させる事ができます。

コミュニケーションコストを低減するために

知恵を借りる事は有効ですが、コミュニケーションには参加者の時間や体力、精神力というコストが発生します。

消耗を避け、より良いコミュニケーションを行うために、私は以下のような態度でコミュニケーションに望んでいます。

1. 期待値を明確にする

2. ドキュメントに思考を整理する

3. 情報伝達の適切な最小単位を模索する

期待値を明確にする

コミュニケーションが終わった時にどのような成果を期待しているのか明確に共有する事で、議論をスムーズに進行します。

私が受け手だった場合、先の見えない議論や展開は心理的負担が大きいです。
コミュニケーションのロードマップと参加者の現在地を都度理解する事で、「いま我々はどこに向かうために何をしているのか」を明確にします。

ドキュメントに思考を整理する

事実として確定している情報とそこから生まれた自身の所感を整理し、積み上げる事が重要です。
コンテキストの複雑性が増すと、何が分かっていて何が分からないのか、何が事実で何が主観なのかが曖昧になってくる場合もあります。

そのような場合の対策として、私は思考の多くをドキュメントに整理・構造化しています。
自分自身の思考を整理した上でコミュニケーションを取る事で、相手と自分の見ている景色、認知に差分が発生する事態を予防する事が可能です。

情報伝達の適切な最小単位を模索する

コミュニケーション速度の向上は、成果物を生み出す速度の向上に寄与します。
コミュニケーションの速度を上げるためには、一回あたりのやり取りに含まれるペイロードのサイズを圧縮する事が重要です。

構造化されている情報だとしても、情報過多は受け手の認知負荷が高いからです。
また、テキスト、口頭を問わず構造化されていない膨大な情報は受け手に対して大きな認知負荷を強いる事になります。

情報量を圧縮しつつ、一セッションの中で以下が欠損するタイミングを発生させない事を心がけています。

・コンテキスト（前提条件、背景）
・相互の視点（見る対象と見る位置）、視座、視野の調整
・コミュニケーションのゴール、期待値

さいごに

コミュニケーションの質、量を上げる事が成果物の価値向上にも繋がります。
参考にしていただける部分があれば幸いです。