1
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?

目次

  1. はじめに
  2. 体験談:メンバーとしての現場での課題
  3. 課題から学んだこと
  4. 私がプロジェクトリーダーとして実施したこと
  5. プロジェクトは伝言ゲームである
  6. まとめ

1. はじめに

1.1 プロジェクトにおけるコミュニケーションの重要性

プロジェクトが円滑に進むかどうかは、「情報が正しく伝わるか」 に大きく左右されます。
特に、開発プロジェクトでは以下のような状況が発生しがちです。

  • 要件や仕様が曖昧なまま進行し、後から大きな手戻りが発生する
  • 口頭やチャットベースの情報伝達が多く、正式なドキュメントが残らない
  • 有識者と一般メンバーの知識差が埋まらず、属人化が進む
  • 「言った」「言わない」の認識ズレがトラブルを引き起こす

こうした問題は、多くのプロジェクトで起こり得ます。そして、プロジェクトの情報伝達は「伝言ゲーム」に似ている ことがよくあります。
情報が正しく伝わらなければ、どれほど優秀なエンジニアが揃っていても、プロジェクトの品質や生産性が低下してしまいます。

本記事では、私が実際に経験した 「プロジェクトにおける情報伝達の課題」 について共有し、
そこから学んだことや、リーダーとして実施した改善策を紹介します。


1.2 なぜメンタルヘルスやストレスマネジメントが必要なのか

プロジェクトの進行において、コミュニケーションがうまくいかないと、単に作業が非効率になるだけでなく、関わる人のストレス にも直結します。

私自身、過去に以下のような経験をしました。

  • 有識者の機嫌に左右され、質問がしづらい → 必要な情報を得られず、不安を抱えながら作業
  • 十分な引き継ぎ資料がなく、何が正しいのかわからない → 属人化した知識に振り回され、長時間労働
  • 職場の陰口文化が蔓延し、心理的安全性が低い → 周囲の雰囲気にストレスを感じ、パフォーマンスが低下

このような状況が続くと、エンジニアのモチベーションや生産性の低下、場合によってはメンタル不調につながることもあります。

現代のエンジニアに求められるのは、技術スキルだけではありません。
健全なコミュニケーション環境を作ること や、ストレスマネジメントを意識すること も、長期的に良い仕事をする上で重要です。

本記事では、私自身が経験した 「ストレスの要因になった職場環境」 を紹介し、それをどう乗り越えたかを説明します。
また、リーダーとして環境を改善するために実践したことも共有するので、
同じような課題を感じている方にとって、少しでも参考になれば幸いです。

2. 体験談:メンバーとしての現場での課題

2.1 不十分な共有資料と引き継ぎの難しさ

この課題に直面したのは、入社して間もない頃のことでした。あるプロジェクトで画面操作を伴う性能試験を引き継ぐことになりましたが、前任者からの引き継ぎ資料はほとんど存在せず、重要なノウハウが文書化されていない状態でした。

入社直後ということもあり、プロジェクト全体の流れや業務の詳細を十分に把握できていない中での作業は特に困難でした。それでも、自分なりにできる限りの対策を講じました

  • 有識者に積極的に質問を重ねる
  • 自分で手順書を作成しながら作業の抜け漏れを防ぐ

しかし、非有識者の視点では前任者が持っていた暗黙知や細かなノウハウを完全に引き出すことは難しく、結果としていくつかの重要なポイントが抜け落ちてしまいました。

その結果、大幅なスケジュール遅延が発生し、最終的には残業や休日出勤が続くことになりました。この状況は決して個人の努力だけで解決できるものではなく、プロジェクト全体での知識共有の仕組みが整備されていなかったことが大きな要因だったと感じています。

💡 補足

  • このような状況は多くの現場で発生し得る課題であり、属人化を防ぐためのドキュメント整備やナレッジ共有の仕組みが求められる。
  • 「〇〇さんしか知らない」といった知識の属人化は、業務継続性を損なうリスクにもなる。

2.2 有識者の気分に左右される職場環境

製造工程から参画した際、有識者に質問することが難しい場面が多々ありました。その理由は、有識者の気分に波があり、機嫌を損ねることを避けたかったからです。
このため、最低限のことだけを確認し、細かな仕様や不明点については自分の予測に頼ることが多くなりました。

短期的にはこのアプローチで作業を進められましたが、後の工程で予想通りバグが発生しました。
中には**「このままだと不具合が出るかもしれない」と予感しつつも、環境的に確認が難しく、そのまま進めざるを得なかった部分もありました**。

この経験を通じて、オープンなコミュニケーション環境が整っていないと、個々の努力だけではプロジェクト全体の品質向上に限界があることを実感しました。

💡 補足

  • 開発現場では、質問がしやすい環境がプロジェクトの成功に直結することが多い。
  • 心理的安全性が確保されていないと、メンバーは消極的になり、リスクを事前に防ぐ機会を失うことになる。

2.3 職場の陰口文化による精神的負担

私が直接悪口の対象になることはありませんでしたが、常駐先の正社員同士が、その場にいないメンバーや協力会社の陰口を頻繁に言う環境に身を置いていました。

こうした職場の雰囲気は、心理的な安全性を損ない、「自分も陰で何か言われているのではないか」という不安を常に抱かせました。この状況では、メンバー間の信頼関係を築くことが難しくなり、結果としてモチベーションの低下や業務効率の悪化につながりました。

この経験を通じて、健全なコミュニケーション文化の重要性を強く認識するようになりました。

💡 補足

  • 陰口が蔓延する職場では、心理的安全性が損なわれる
  • 人間関係の悪化は、エンジニアの離職率を高める大きな要因の一つ
  • オープンなフィードバック文化を作ることで、陰口ではなく建設的な議論が生まれる

まとめ

これらの経験を通じて、プロジェクトにおける情報共有の重要性や、職場環境が個々のメンタルに及ぼす影響の大きさを痛感しました。

また、個人の努力だけでは解決が難しい問題も多く 「どうすればより良い職場環境を作れるか」 を考えるきっかけにもなりました。

この課題を踏まえ、次の章ではプロジェクトリーダーとして私が実践したことについて紹介します。

3. 課題から学んだこと

私がこれまで経験した 「情報共有が不十分な環境」や「コミュニケーションに課題のある職場」 では、
個人の努力だけでは解決できない問題が多くありました。

そこで、これらの経験から 「情報共有の重要性」「心理的安全性が生産性に与える影響」 を学びました。


3.1 個人の努力だけでは解決できない壁

情報が正しく伝わらない環境では、どれだけ個人が努力しても限界がある ことを痛感しました。
以下のような状況が続くと、プロジェクトの進行に大きな影響を及ぼします。

  • 属人化した知識に依存する → 特定の有識者が不在になると業務が止まる
  • 質問しづらい環境 → 問題を事前に防げず、後工程で手戻りが増える
  • 情報が正式なドキュメントに残らない → 新しいメンバーがキャッチアップしづらい

これらの問題は、個人だけでなく 「チーム全体の文化や仕組み」による影響 が大きいと感じました。

💡 対策として学んだこと

  • 「聞かなくてもわかる」仕組みを作る(ドキュメント整備、ナレッジ共有)
  • 「質問しやすい文化」を醸成する(心理的安全性の確保)
  • 「属人化を防ぐための情報共有」を意識する(チームで知識を持つ)

3.2 知識共有と心理的安全性の重要性

プロジェクトを円滑に進めるには、単に技術力があるだけでは不十分 であり、
「知識の共有」「心理的安全性」 の2つが不可欠だと実感しました。

  1. 知識共有ができていないと、情報格差が生じる

    • 仕様やルールを知っている人と、知らない人の間で生産性の差が広がる
    • 「わかる人にしかわからないコード」「属人化した手順書」が増える
    • チームの誰かが抜けると、プロジェクトが回らなくなる
  2. 心理的安全性がないと、コミュニケーションが機能しない

    • 「質問すると怒られそう」 という雰囲気があると、問題が隠れる
    • ミスを報告しづらくなり、後工程で手戻りが増える
    • メンバー間の信頼が低下し、モチベーションの低下につながる

💡 対策として学んだこと

  • ドキュメントの整備を徹底し、情報共有の仕組みを作る
  • 「何を言っても大丈夫」な環境を作ることで、チームのパフォーマンスを向上させる
  • 質問しやすい文化を作ることが、長期的にプロジェクトの安定につながる

まとめ

これらの経験を通じて、
「情報共有の仕組みがないと、プロジェクトの品質が低下する」
「心理的安全性がないと、メンバーのパフォーマンスが発揮されない」
という2つの大きな学びを得ました。

この後の章では、私がプロジェクトリーダーとして実際にどのように改善を試みたか を紹介します。

4. 私がプロジェクトリーダーとして実施したこと

これまでの経験を踏まえ、プロジェクトリーダーとして 「情報共有の仕組みづくり」「心理的安全性の向上」 を意識し、以下の改善策を実施しました。


4.1 オープンなコミュニケーション環境の構築

私がメンバーとして経験した 「質問しづらい環境」「陰口が飛び交う職場文化」 を改善するため、
誰もが安心して情報を共有できる環境づくり を意識しました。

情報伝達のルールを明確にする

  • 「情報共有は○○(例: ドキュメント、メール、チャット)で行う」と明示し、伝達ミスを防ぐ
  • 誰に何を伝えるべきかを役割ごとに整理し、必要な情報が適切に流れるようにした

陰口を防ぐための行動指針

  • チーム内の不満を「陰で言う」のではなく、「どう改善できるか」にフォーカス
  • フィードバックは必ず 本人に直接伝える(建設的な内容であれば対面 or テキストで)
  • 「誰もが安心して発言できる場を作る」 ことをチームのルールとして共有

4.2 引き継ぎ資料の標準化と共有意識の醸成

「引き継ぎ資料がないと、業務が属人化し、後任者が苦労する」 という課題を解決するため、
業務の標準化と情報共有の仕組みづくり に注力しました。

業務の標準化を進める

  • 「自分しか知らない業務」 を明確化し、ドキュメント化を促す
  • 記録が残りやすい形式(例: Google Docs、Confluenceなど)を活用

引き継ぎ時のポイントを整理

  • 重要な手順やノウハウを「業務フロー」として簡潔にまとめる
  • 口頭で伝える場合でも 「何を伝えたか」 をテキストで補足する習慣を作る

💡 ポイント

  • 「文書が整備されていない」と嘆くだけでは変わらない → 仕組みとして標準化する
  • メンバーの負担にならないよう、簡潔なフォーマットを用意する

4.3 メンバー間の信頼関係を築く工夫

リーダーとして、「メンバーを信用しすぎず、かといって疑いすぎない」 というバランスを意識しました。
信頼関係を築くために、以下の工夫を行いました。

「任せるべきところ」と「チェックすべきところ」を明確に分ける

  • すべてを管理しすぎると、メンバーの主体性がなくなる → 裁量を与えるべき業務は明確に任せる
  • 逆に、品質に直結する部分は 適切なタイミングでレビューを実施 し、問題を早期に発見

メンバーの顔色は伺わず、公平な関係を築く

  • 「機嫌を取るためのコミュニケーション」は避け、業務上の事実ベースでやり取りを行う
  • ただし、メンバーの悩みや不安には適切に対応し、心理的安全性を確保

💡 ポイント

  • 信頼関係を築くには、「放置しすぎない」「干渉しすぎない」 のバランスが重要
  • 「厳しいフィードバックも、信頼があるからこそ成立する」 という考え方を持つ

4.4 テキストと対面の使い分け

チームのコミュニケーションが円滑になるように、「テキスト」と「対面」の使い分け にも気を配りました。

テキストを使う場面

  • 結論が明確で、後で参照する必要がある情報(仕様変更、決定事項の記録など)
  • メンバーが時間のあるときに確認できる内容

対面やオンラインミーティングを使う場面

  • 感情的な要素を含むフィードバック(誤解を防ぐため)
  • 意見を交わしながら進める議論(ブレスト、方向性決めなど)

💡 ポイント

  • 「すべてテキストで済ませる」のではなく、状況に応じて使い分けることが重要
  • 相手の温度感が伝わる場面では、できるだけ対面 or オンラインでの対話を優先

まとめ

リーダーとして実施したことは、私自身が過去に苦労したことを踏まえての改善策 でした。

  • 情報共有を仕組み化し、属人化を防ぐ
  • 質問しやすい環境を作り、心理的安全性を向上させる
  • メンバーの信頼関係を適切に築き、責任を分散させる
  • テキストと対面のコミュニケーションを使い分ける

こうした取り組みを通じて、
「プロジェクトは伝言ゲームである」 という考え方を強く意識するようになりました。

次の章では、「プロジェクトにおける伝言ゲームの影響と、それをどう防ぐか」について詳しく解説します。

5. プロジェクトは伝言ゲームである

プロジェクトがスムーズに進むかどうかは、「情報が正しく伝わるか」 に大きく左右されます。
実際に業務を経験して感じたのは、プロジェクトの情報伝達は伝言ゲームに似ている ということです。

例えば、以下のようなケースが発生します。

  • 仕様が途中で変わったが、正しく伝わっていなかった
  • 「Aさんには伝わっていたが、Bさんには伝わっていなかった」
  • 情報の伝達ミスにより、開発が手戻りになった
  • 「上の人から聞いた話と、実際の要件が違っていた」

情報が人を介するごとに変化し、最終的には最初に伝えた内容とは異なる形で認識されてしまう ことがよくあります。
こうした「伝言ゲーム」の問題が発生すると、プロジェクトの品質や進行に大きな影響を及ぼす ため、
情報共有の方法やチームの文化を整えることが重要になります。


5.1 伝言ゲームがプロジェクトに与える影響

伝言ゲームによる情報伝達ミスが発生すると、以下のような問題が起こります。

1. 仕様のズレによる手戻りが増える

  • 「言った」「言わない」の食い違いで、手戻り作業が発生する
  • 仕様変更がチーム全体に正しく共有されず、古い情報で開発が進む
  • 結果として スケジュールが遅延し、余計な工数が増加

2. チーム内の認識のズレが生じる

  • 「リーダーはAだと言っていたが、現場のメンバーはBだと理解していた」
  • 会話の中で曖昧な表現が使われ、解釈の違いが発生する
  • 個々の認識がバラバラになり、連携ミスが増える

3. メンバーの心理的ストレスが増す

  • 「聞いていないのに、なぜできていないと言われるのか?」
  • 情報を持っている人と持っていない人の間にストレスが生まれる
  • 「正しい情報がどこにあるのか分からない」状態が続き、混乱が発生

5.2 伝言ゲームを防ぐための工夫

伝言ゲームの影響を最小限に抑えるためには、情報の伝え方を工夫し、仕組みとして整備すること が重要です。

1. 情報の伝達ルールを統一する

  • 仕様変更や決定事項は 「口頭ではなく、必ず記録に残す」 ルールを徹底
  • 情報共有の場を統一し、「誰がどこを見れば正しい情報がわかるのか」を明確にする
    • 例: 「正式な決定事項は全てConfluenceに記載」
    • 例: 「仕様変更はSlackの#仕様変更チャンネルで必ず共有し、スタンプで構わないので反応してもらう」

2. コミュニケーションのギャップを減らす

  • 重要な情報は 複数の手段(テキスト+対面)で共有 する
    • 対面で話した内容も、必ずテキストで記録する(後から見返せる形にする)
  • メンバーごとの認識をすり合わせるため、「言葉だけでなく、可能な限り図やフローで示す」
    • 例: 仕様の変更点をテキストだけでなく、簡単な図やスクショで説明する

3. 「確認の文化」を作る

  • 「伝えたつもり」を防ぐため、重要な情報は必ず 相手にリピートさせる
    • 例: 「〇〇さん、この仕様変更について認識合ってますか?」
  • 不明点はその場で確認する 文化を醸成し、曖昧な状態で進めない

💡 ポイント

  • 「伝える」ではなく「伝わったことを確認する」ことが重要
  • 記録を残すことで、言った・言わない問題を防ぐ

まとめ

プロジェクトにおける伝言ゲームの影響は大きく、情報伝達が適切に行われないと、手戻りや混乱が増える ことを経験しました。
そのため、私はリーダーとして以下を意識しました。

  • 「情報の伝達ルールを統一する」
  • 「口頭+テキストを併用し、記録に残す」
  • 「確認の文化を作り、認識のズレを防ぐ」

こうした対策を行うことで、伝言ゲームの影響を減らし、プロジェクトの安定性を向上させることができました。

次の章では、これまでの経験を踏まえた 「まとめ」 を記載します。

6. まとめ

これまでの経験を振り返ると、プロジェクトの課題は 「情報共有」と「心理的安全性」 に大きく依存していると感じました。

🔹 振り返り:私が経験した課題

  • 質問しづらい環境 → 必要な情報が得られず、不安を抱えながら作業
  • 共有資料がなく属人化が進む → 手戻りや引き継ぎ時の混乱が発生
  • 陰口文化によるストレス → メンバー間の信頼が築けず、パフォーマンスが低下
  • 情報が正しく伝わらない → 伝言ゲームが発生し、手戻りや仕様ズレが増加

こうした経験から、個人の努力だけでは解決できない壁があることを実感しました。


🔹 プロジェクトを改善するために実施したこと

私自身がプロジェクトリーダーとして関わる中で、以下の改善策を実践しました。

オープンなコミュニケーション環境の構築

  • 情報共有のルールを明確化し、伝達ミスを減らす
  • フィードバックは「本人に直接伝える」ことを徹底し、陰口文化を排除

情報共有の仕組み化

  • 「ドキュメントの標準化」 を進め、属人化を防ぐ
  • 引き継ぎ時に口頭+テキストを併用 し、情報の抜け漏れを防ぐ

メンバー間の信頼関係の構築

  • 顔色を伺わず、公平に接する ことで、フラットな関係を築く
  • 適切なタイミングでレビューを実施 し、責任の分散と品質の向上を両立

伝言ゲームを防ぐ仕組みづくり

  • 情報の伝達ルールを統一し、「口頭+テキスト」で記録を残す
  • 認識のズレを防ぐため、重要な情報はリピート確認

🔹 プロジェクトは伝言ゲームである

これらの経験を通じて、私は 「プロジェクトは伝言ゲームである」 という考えを強く持つようになりました。

  • 情報は人を介するごとに変化する
  • 「伝えたつもり」「聞いたつもり」で進めると、大きなズレが生じる
  • 伝えたことよりも、「伝わったかどうか」が重要

この課題を乗り越えるためには、「正しい情報を、正しく共有できる仕組みを作る」 ことが必要です。


🔹 最後に

この記事で紹介した内容は、私自身が実際に経験したことをもとにしています。
しかし、これは 「どの現場でも起こり得る課題」 だと感じています。

もし、似たような課題に直面している方がいたら、

  • 「なぜ情報共有がうまくいかないのか?」
  • 「どうすればメンバー間の認識ズレを減らせるか?」

こうした視点を持つことで、少しでも改善のヒントが得られるかもしれません。

本記事が、プロジェクトの円滑な運営や、働きやすい環境づくりの参考になれば幸いです。

あなたの職場では、情報共有の仕組みはどうなっていますか?

1
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
1
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?