はじめに
エンジニアは「技術力」だけあれば良いわけではありません。プロジェクトが炎上する原因の多くは、技術的な問題ではなくヒューマンエラーです。
そこで今回は、「現場で求められる積極的なコミュニケーション」について整理しました。
チーム開発でよく課題になる観点を、自分なりに具体例と対策とともにまとめます。
なぜ積極的なコミュニケーションが必要か？
- 忙しくなると「返事を後回しにする」「確認せず進める」事態が起こりがち。
- 人によっては数日や１週間（！）の無視も。結果、チームの信頼は崩れる。
- コードレビューやタスク遅延よりも、無視・放置がプロジェクト効率を大きく下げる。
大事なのは「完璧な対応」ではなく、忙しい中でも無視を防ぐ仕組みを持つこと。
つまり、改善する意思と行動が見られるかどうかが、現場では重視されます。
ヒューマンエラーを防ぐ7つの仕組み化
- 認識の齟齬を防ぐ(実装前の確認)
- 報連相を怠らない(進捗報告・タイムボックス)
- ルールを確認する(チェックリスト)
- 伝わりにくい質問をしない(結論ファースト)
- 全体を見る(他メンバーの状況把握)
- 相手の状況に配慮する(緊急度明示・労い)
- 情報共有を仕組み化する(ドキュメント化・通知)
以下で具体的に整理します。
1. 認識の齟齬を防ぐ——「こうだろう」を排除する
何が問題か
「たぶんこういう仕様だろう」と思い込んで実装を進め、レビューで「そうじゃない」と指摘される。このパターンは時間と工数の無駄を生みます。
対策例
実装前に、仕様の解釈をSlackで確認する
例:
【確認】会員登録APIについて
・メールアドレスの重複チェックは、登録時のみ実施でOKですか?
・既存会員が同じメールで再登録しようとした場合は、エラーを返す認識です
・パスワードのバリデーションは、8文字以上+英数字混在で進めます
認識に齟齬があればご指摘ください🙏
ポイント:
- 自分の解釈を明文化する
- Yes/Noで答えやすい形にする
- 曖昧な部分は実装前に潰す
この確認を習慣化してから、手戻りが明らかに減りました。
2. 報連相を怠らない——進捗とアラートを出す
何が問題か
「進んでます」とだけ言って、実は詰まっている。これが一番チームに迷惑をかけます。
対策例(1): 毎朝の進捗報告をテンプレ化
【進捗】10/4(金)
■昨日やったこと
・会員登録API実装(80%完了)
・単体テスト作成
■今日やること
・会員登録APIの残り実装
・結合テスト準備
■懸念・相談
・パスワードのハッシュ化部分で、ライブラリの選定に迷っています
→午前中に調査して、方針を相談させてください
毎朝同じフォーマットで書くだけなので、負担になりません。「懸念・相談」の項目があることで、アラートを出しやすくなります。
対策例(2): タイムボックスを設定する
「分からないことは30分調べて解決しなければ質問する」とルール化しています。
- タイマーをセット
- 30分経過時点で進展がなければ、調べた内容をまとめて質問
- 「自力で解決したい」という気持ちはグッと抑える
これにより、1時間も2時間も一人で悩む状況を回避できます。
3. ルールを確認する——「知らなかった」をなくす
何が問題か
コーディング規約を読まずに実装し、レビューで大量の修正指摘を受ける。全体スケジュールを把握せず、自分のタスクだけを見て動いている。
対策例
プロジェクト参画時のチェックリストを作成
- README.mdを読む
- コーディング規約を読む(リンター設定も確認)
- ブランチ運用ルールを確認
- リリースフローを確認
- 全体スケジュールをカレンダーに入れる
- テスト方針・環境を確認
これをNotion等に保存しておき、新しいプロジェクトに入るたびに実行します。特に「全体スケジュール」は、自分のタスクとの関係性を理解するために必須です。
4. 伝わりにくい質問をしない——結論ファーストで書く
何が問題か
「会員登録の処理が分かりません」だけ送られても、何が分からないのか読み取れません。
対策例
質問は以下のフォーマットで書きます。項目を埋めるだけなので時短できます。
【質問】会員登録API: メール送信のタイミングについて
■結論(聞きたいこと)
メール送信は、DBへの登録成功後に行うべきですか?
■背景・状況
・現在、会員登録APIを実装中です
・メール送信に失敗した場合の挙動が仕様書に明記されておらず、判断に迷っています
■自分の理解・試したこと
・他のAPIを見ると、DB登録後にメール送信しているように見えます
・ただし、メール送信失敗時にロールバックすべきかが不明です
■確認したドキュメント
・API仕様書(p.12)
・既存コード(UserController.php)
お手すきの際に、ご教示いただけますと幸いです🙏
これを書くことで、相手は「背景を理解する時間」を節約でき、即答しやすくなります。また、書く過程で自己解決することもあります。
5. 全体を見る——自分のタスクだけに閉じない
何が問題か
自分のタスクだけに集中し、他のメンバーが困っていることに気づかない。結果として、チーム全体の効率が落ちます。
対策例
朝会・夕会で他メンバーの状況をメモする
- Aさん: ○○機能で詰まっている → 自分が過去に同じ箇所を実装済みなら声をかける
- Bさん: テスト環境の構築中 → 同じ環境を使う予定なので、完了したら教えてもらう
「困っている人がいたら助ける」を意識的に行うために、他人の状況を把握する習慣をつけています。
6. 相手の状況に配慮する——忙しい人への質問の仕方
何が問題か
「教えてください!」と矢継ぎ早に質問するのは、相手が忙しいときには負担です。
対策例
質問の緊急度を明示し、相手を労う
お疲れ様です。お忙しいところ恐縮ですが、質問させてください。
【緊急度: 低(今日中でOK)】
○○の実装方針について、お手すきの際にご相談させてください。
午後イチに別タスクを進めつつ、お返事をお待ちしています🙏
また、以下も意識しています:
- 他に質問できる人(過去の担当者、別のシニアメンバー)がいないか確認
- ドキュメントやコードを自分でもう一度読む
- 「今すぐ聞くべきか」を自問する
7. 情報共有を仕組み化する——「自分だけが知っている」をなくす
何が問題か
自分が詰まった箇所を解決しても、共有しないと他のメンバーが同じところで詰まります。
対策例(1): 詰まった箇所はScrapbox等に残す
例:
## [解決] 会員登録API: メール送信でタイムアウトが発生
### 症状
- 本番環境でメール送信時に30秒でタイムアウト
- ローカルでは再現せず
### 原因
- 本番のSMTPサーバーが、接続数制限に引っかかっていた
- 同時に大量のリクエストが来ると発生
### 解決策
- キュー処理に変更(Laravel Queueを使用)
- 参考: https://...
### 所要時間: 2時間
これをチームの共有ドキュメントに残すことで、「検索すれば分かる」状態を作ります。
対策例(2): 共通処理を作ったらSlackで通知
【共有】メール送信の共通処理を作成しました
■内容
・sendMail()関数を作成(app/Services/MailService.php)
・キュー処理に対応済み
・使い方はREADMEに記載
今後メール送信が必要な機能では、こちらをご利用ください👍
「自分が作ったから自分しか知らない」を防ぎます。
おわりに
この記事では、「忙しい中でも無視を防ぐ仕組み化」7つの仕組み化を紹介しました。
- 認識の齟齬を防ぐ(実装前の確認)
- 報連相を怠らない(進捗報告・タイムボックス)
- ルールを確認する(チェックリスト)
- 伝わりにくい質問をしない(結論ファースト)
- 全体を見る(他メンバーの状況把握)
- 相手の状況に配慮する(緊急度明示・労い)
- 情報共有を仕組み化する(ドキュメント化・通知)
完璧にできているわけではありませんが、「忙しくても破綻しない仕組み」を作ることで、少しずつヒューマンエラーを減らせています。
今後も改善を続けていきます。何か改善案があれば、コメントで教えていただけると嬉しいです!