0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初プロジェクトリーダーの経験から学んだ「コミュニケーション力」の正体

0
Last updated at Posted at 2026-03-12

はじめに

昨年、開発メンバーとして参加していたプロジェクトのリーダーを引き継ぎました。
当時の私は「人前で話すことには自信があるし、真面目にコツコツやればリーダーとしてもうまくやれるはず」と、自分の「コミュニケーション力」に周りからの評価も含めて自信を持っていました。

しかし、実際にプロジェクトの矢面に立ってみると、ただ「言葉をハキハキ交わせる」だけではどうにもならない壁にぶつかりました。相手とうまくいかない悔しさや、自分の力不足に涙を流して疲弊した経験でしたが、振り返ることができるようになりました。

本記事では、私が引き継ぎ案件で直面したリアルな課題と、そこから得た「プロジェクトリーダーとして立ち回るための知見」をまとめます。これからリーダーを任される方の参考になれば幸いです。

1. 「コミュ力=話せる」ではない。責任を背負う対話とは

学生時代や友人と話す場面では、「そうですよね!」と元気よく返事をしていればスムーズに進むことが多くありました。
しかし会社員として責任をもつと、自分の発言が「予算」「工数」「会社の責任」に直結します。安易な回答ができず、コミュニケーションのテンポが悪くなることに歯痒さを感じました。

ここでのコミュニケーション力とは、「その場を和ませること」ではなく、影響範囲を想像し、適切に回答もしくは持ち帰ることでした。

  • 「ご要望は理解しました。工数とシステムへの影響範囲を確認して、明日までに回答します」
  • 「その機能を追加する場合、スケジュールの調整が必要になる可能性がありますが、優先順位をご相談できますか?」
    このように、安請け合いせずに条件をすり合わせる交渉力こそが、必要なスキルだと痛感しました。

2. テキストコミュニケーションの罠

クライアントとのメールのやり取りが非常に困難でした。

  • 返信が3往復ほどすると引用だらけになり、今何について話しているのか迷子になる。
  • 相手のメールに「疑問点」「認識合わせ」「ただの確認事項」が混在している。
  • なぜその質問をしているのか(何を不安がっているのか)という「背景」が見えない。

関係性が悪化していた時期は、メールの返信自体をもらえないこともあり、後回しにされている感覚に苦しみました。

これを「反面教師」として、自分からのテキスト発信では以下のルールを徹底すべきだと学びました。

  1. 1メール・1トピックを心がけ、相手にしてもらいたいことと自分の気持ちを混在させない。
  2. 「質問」「相談」「確認(Yes/Noで答えられるもの)」を明確にする。
  3. 相手の意図が読めない時は、メールで粘らずにWebミーティングや電話で背景を聞き出す。

「なぜこの質問が来たのか?」という相手の不安の根源を先に潰さないと、何往復してもゴールに辿り着かないことを学びました。

3. 「聞いていた話と違う」を防ぐ

途中引き継ぎの最大の罠は、「契約・要件定義の段階で合意していない(あるいは曖昧な)部分が多すぎる」ことでした。
さらに、体制変更で営業も開発もプロジェクト開始当初のメンバーがおらず、誰に聞いても正解がわかりません。テスト環境を使うと聞いていたのに、当日に別ベンダーから「本番環境を使いますよ」と聞かされた時は震えました。

先輩のフォローを受けつつ、1年前の資料とメールを漁り、一言一句を確認する毎日に疲弊しました。

引き継ぎの際、「過去の経緯をキャッチアップする」だけでは不十分です。
「現時点での合意事項と未決定事項の棚卸し」を、クライアントとやり直す(ミニキックオフを行う)必要があります。

  • スケジュール、環境(テスト/本番)、スコープ(どこまでやるか)を改めて確認し、「現体制での認識合わせ」としてクライアントに合意をとる。
    これを怠ると、後から「言った・言わない」の地雷を踏み続けることになります。

4. 曖昧な指示から実装漏れを防ぐ

クライアントとの仕様確認で、こんなやり取りがありました。

私「Aは不要ということは、BとCを実装すればよくて、Dは不要という認識で合っていますか?」
クライアント「Aは不要なので。」

これ以上深掘りできず実装を進めた結果、実はDの実装も必要であり、不備として扱われてしまいました。

相手が自分の質問に対して的確な回答(A, B, C, Dのそれぞれの要否)を返してくれないことは多々あります。相手もシステム的な影響範囲を理解しきれていない場合があるからです。
このような場合の対策は以下の通りです。

  • クローズドな確認リストを作成する
    テキストの箇条書きなどで、
    ・A:実装しない
    ・B:実装する
    ・C:実装する
    ・D:実装する(←ここを明記して Yes/No を迫る)
    と整理してボールを投げ直す。
  • 相手が「Aは不要なので」としか言わない場合、「つまり、A以外のB・C・Dはすべて実装するという前提で進めますがよろしいですね?」と最終確認の釘を刺す。

自分がもっと詰めるべきところを詰めなかったことを痛感した出来事でした。

おわりに

プロジェクトが終わった今、「リーダーはしばらくやりたくない、向いていないかもしれない」というのが正直な感想です。

ただ、「コミュニケーション力が高い」=「人と仲良くなれる」ことではなく、「曖昧さを排除し、プロジェクトを安全に前に進めるための合意形成力」であることに気づけたのは、この悔しい経験があったからこそだと思っています。

この失敗談とそこから得た教訓が、これから新米リーダーとなる方のお役に立てば嬉しいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?