スタートアップでバックエンドエンジニアとして、シニア1人＋インターン2人の3人チームで長期インターンをしていました。やり取りは基本的にフルリモート・非同期。そこで一番大きかった学びは、技術そのものではなく「コミュニケーションの設計」でした。
最初の自分は「相手にコストを押し付けていた」
振り返ると、初期の自分の報告や質問は、相手に余計なコストを払わせる形になっていました。
たとえば、設計判断についての議論があるときに、論点の要約だけをDiscordに先に送ってしまう。すると、Githubのプルリクエストとの参照関係が切れてしまい、「この要約はどのやりとりを踏まえたものなのか？」を相手が自分で探しに行く必要が出てきます。結果的に、確認の手間を増やしてしまっていました。
質問の仕方も同じでした。「どうすればいいですか？」に近い丸投げで、前提整理も選択肢の比較もせず、考える仕事ごと相手に渡してしまっていたのです。
協働のスピードは「情報の質」で決まる
シニアエンジニアからの指摘と議論を重ねる中で、次のように考えるようになりました。
- チームメンバーとのコミュニケーションで起きる損失は、大きく分けて2種類
- 違う理解が伝わって手戻りが発生する「ずれ」
- 相手の処理待ちで進捗が止まる「滞留」
そして、この2つへの打ち手はどちらも同じ形をしていると気づきました。
「受け手がそのまま処理できる形で渡す」こと。
情報を探す・解釈する・材料を集めるという仕事は、本来、文脈を一番よく知っている送り手側が先に済ませておくべきものです。受け手は、それを読んですぐに意思決定や実装に入れる状態が理想です。
実務で使った3つのコミュニケーションの型
この考え方を実務で使えるように、具体的に次の3つの型に落としました。
- 報告：結論 → 証拠 → 提案の順に組む
- まず結論を一行で書く
- 次に、ログ・PR・Issueなどの検証可能なリンク付きの証拠を添える
- 最後に、「自分は次にどうするつもりか」という提案を書く
- 質問：丸投げせず、Yes/Noで返せる形にする
- 自分なりの仮説と、その根拠をセットで書く
- そのうえで自分としての推奨案を出し、「A案で進めてもよいでしょうか？」のようにYes/Noで答えられる形にする
- コードの議論：文脈が完結する場所に紐づける
- 議論の文脈から切れた場所に書かず、該当するコード行やPRのスレッド上にコメントを置く
- 読む人がそのスレッドだけ読めば、背景と意図が完結する状態を目指す
この3つを意識するだけで、コミュニケーションに起因する「ずれ」と「滞留」がかなり減り、チームとしての開発サイクルも明らかに速くなりました。
相手のため、ではなく「自分の速度」のための技術
この学びが自分にとって腹落ちしたのは、「相手のために丁寧にする」ではなく、「自分の速度を上げるための技術」だと理解できたからです。
- 相手の返信が遅れると、それはそのまま自分の待ち時間になる
- 相手が誤読すると、それは自分の手戻りとして返ってくる
だからこそ、情報をそのまま処理できる形で渡すことは、最終的には自分の生産性を守る行為だと感じました。
コードとコミュニケーションに共通していた「境界の設計」
インターンを終えたあと、この考え方は自分がコードでやっていたこととよく似ていると気づきました。
- 曖昧な入力は早めに弾く（バリデーション）
- 必要な情報が欠けていたら、黙って進めずに明示的なエラーで返す
- 関数やAPIのインターフェースをはっきりさせ、呼び出し側が迷わないようにする
相手が人間でもプログラムでも、「境界の設計」が仕事の質を決める。
スタートアップでの長期インターンで、一番血肉になったのは、この「情報の渡し方」と「インターフェース設計」の感覚でした。
