【IT現場の生態系】チームのムードを決める「ネガティブな一言」

現場を支配する「たった一言の呪文」

　最先端の論理の世界であるはずのITの現場。
　目に見えない複雑なロジックを扱うからこそ、そこで働く人間の感情という非論理的なバグに対して、彼らの心は思っている以上に無防備なのかもしれません。

　深夜2時、静まり返ったオフィスに響くキーボードの打鍵音。バグの原因がどうしても特定できないとき、IT技術者たちが恐れるものは何でしょうか。サーバーのクラッシュでしょうか。それとも、翌朝の進捗報告会議でしょうか。
　もしかしたらそれは、隣の席の先輩がふと漏らす、あの冷え切った一言かもしれません。

　優秀なエンジニアを集め、最新のクラウド環境を整えたその場所が、たった一人の人間が放つ数文字の言葉で、機能不全に陥ることがあるのです。

「ネガティブの一言」という名の構文エラー

　ITの現場におけるネガティブな言葉は、単なる愚痴や悪口の枠に収まりません。それはまるで、プログラムの実行を強制終了させる構文エラーのような破壊力を持っているのです。

　たとえば、システムにトラブルが発生した瞬間のこと。
　原因を突き止めて修正しなければいけない局面で、
　　「普通、テストで気づくよね？」
という結果論による犯人探しが始まると、現場の空気は一瞬で凍りつきます。
　言った本人は正論を吐いているつもりなのでしょう。けれども、その言葉はすり抜けが発生した構造的な課題への視点を遮り、只々担当者を萎縮させるだけなのです。

　あるいは、ビジネス側の担当者から無邪気に放たれる
　　「仕様をちょっと変えるだけだから、すぐできるよね？」
という一言も根深いものがあります。
　エンジニアの感覚からすれば、それは
　　「ちょっと心臓の血管を一本つなぎ替えるだけだから、すぐ終わるよね？」
と言われているようなものです。裏側にあるアーキテクチャや影響調査のコストへの敬意が欠けた言葉は、現場のモチベーションを静かに、確実に削りとっていきます。

チームのムードという名のインフラ

　私たちはよく、プロジェクトの成否を技術力や予算の規模で語りがちです。しかし、実際に現場を動かしているのは、チームのムードという名の目に見えないインフラなのです。

　チーム全体の士気が高いと、高可用性のインフラのように安定した状態を保つことができます。
　心理的な帯域が広いために、悪いニュースほど早く共有される。バグが見つかっても、「すぐに見つかってよかった、みんなで直そう」というパッチが即座に当たり、致命傷に至りません。

　一方で、常に誰かが誰かを責めているような最悪のムードの現場では、誰もが自己防衛に走り始めます。
　ミスを指摘されるのが怖いために、仕様のグレーゾーンや小さな違和感をギリギリまで隠蔽するようになります。報告のレスポンスは遅れ、情報の風通しは悪くなり、最終的には本番環境が炎上するまで問題が表面化しません。

　ムードというのは決して単なる精神論ではなく、システムのパフォーマンスそのものを左右する非機能要件なのです。

生態系を脅かす最強のウイルス言葉

　怒号が飛び交う現場も辛いものですが、本当にチームの息の根を止める「一番ネガティブな一言」は、実はもっと静かな形をして現場に現れます。
　それは、諦めの溜息とともに吐き出される、
　　「どうせ上が決めた仕様だしね」
という一言です。

　怒りや不満を口にしている間は、まだ現状を良くしたいというエネルギーの残り火があります。しかし、「どうせ」という響きがリーダーやベテランの口から漏れた瞬間、チームの思考ロジックは完全にシャットダウンしてしまいます。

　この言葉が恐ろしいのは、課題を解決するプロフェッショナルだったはずのメンバーを、ただ仕様書通りにキーボードを叩く作業員へと変貌させてしまう点にあります。
　主体性が失われたチームで作られたシステムが、ユーザーに愛されるはずもありません。インフルエンザのような強い伝染力を持って、周囲のやる気を次々とゾンビ化させていく。
　この生態系で最悪のウイルスと言えます。

荒む現場で生き残るための、デバッグ方法

　では、そんなネガティブな言葉のウイルスが蔓延する環境で、技術者たちはどうやって身を守ればいいのでしょうか。
　心が擦り切れる前に試してほしい、いくつかの生存戦略があります。

　まずは、受け取った言葉を自分の心の本番環境に直撃させないことです。
　脳内に「サンドボックス」と呼ばれる隔離空間をイメージしてみてください。誰かから鋭い言葉を投げつけられたら、
　　「おっと、バグを含んだパケットを受信したな」
と捉えて、その隔離空間に入れて客観的にデバッグするのです。
　　「なぜこの人は今、こんなに焦っているんだろう」
と観察する視点を持つだけで、受けるダメージは劇的に減ります。

　次に、会話の主語を人からシステムへと転換する技術も有効です。
　　「なんでこんな設計にしたの？」
と責められたら、
　　「私の能力が足りなくて」
と返すのではなく、
　　「現行の仕様では、ここがボトルネックになっています」
と、主語をモノに変換して打ち返します。
　感情の殴り合いの土俵に上がらない賢さが、時には必要なのです。

　そして何より大切なのは、自分の心の電源を定時で物理的に落とすこと。
　他人の不機嫌という、コントロール不可能な外部APIのレスポンスを待ち続けて夜更かしをする必要はありません。

おわりに

　ITの現場を動かしているのは冷徹なソースコードですが、それを紡ぎ出しているのはどこまでも生身の人間です。

　もし、あなたの職場で誰かの一言によってネガティブな冷たい風が吹いたとしても、あなたが一緒になってゾンビになる必要はありません。
　フッと一息ついて、脳内のバリアを起動させましょう。

　そして心の中で、静かにこう呟いてみるのです。

　　「私のモチベーションは、あなたの言葉くらいではダウンしませんよ」

と。

【徒然メモ】「ネガティブな一言」と「ムード」

1. 「ネガティブな一言」とは

　ITの現場におけるネガティブな一言は、単なる悪口や愚痴にとどまりません。「技術への敬意の欠如」「不確実性への恐怖」「心理的安全性の破壊」など、IT特有の文脈から発生するものがチームを蝕みます。

　(1)心理的安全性を破壊する「否定・詰問」
　　技術的な課題が発生した際、原因究明ではなく「犯人探し」や「能力否定」に向かう言葉です。

　・「なんでこんな設計／実装にしたの？」
　　→意図を聞くのではなく、責め立てるニュアンス

　・「これ、常識（基本）だよね？」
　　→相手の知識不足をなじり、質問しづらくさせる

　・「普通、テストで気付くでしょ」
　　→すり抜けが発生した構造的バグの背景を無視した責任転嫁

　(2)現場のモチベーションを削ぐ「軽視・無関心」
　　ビジネス側（非エンジニア）やマネジメント層から放たれがちな、技術的な労力や複雑さを無視した言葉です。

　・「仕様ちょっと変えるだけだから、すぐできるよね？」
　　→裏側のアーキテクチャや影響調査のコストを無視

　・「これ、AIとかでパパッとできないの？」
　　→魔法のように技術を捉え、現場の泥臭いチューニングを軽視

　・「動けば何でもいいよ」
　　→コードの美しさ、リファクタリング、技術負債への理解ゼロ

　(3)チームの歩みを止める「諦め・他責」
　　不確実性の高いプロジェクトにおいて、課題解決の意欲を放棄させる言葉です。

　・「どうせ上が決めた仕様だしね」
　　→当事者意識の放棄、やらされ感の蔓延

　・「あっちのチーム（またはベンダー）が動かないから無理」
　　→セクショナリズムを助長する壁作り

　・「前もそれやって失敗したから無駄だよ」
　　→過去の文脈をアップデートしない挑戦への冷水

2. 「チームのムードを決める」とは

　「ムードを決める」とは、特定の振る舞いや環境要因が、チーム全体の「発言のしやすさ」「トラブル発生時の初動」「品質へのこだわり」を決定づける空気感（カルチャー）を形成していくプロセスを指します。

　(1)トラブル対応のスピードを決める「バッドニュース・ファースト」の有無
　　バッドニュース（バグ、進捗遅れ、仕様のバッティング）が起きた時のリーダーや周囲の「反応」が、その後のチームの透明性を決めます。

　・「隠蔽か、即共有か」
　　悪い報告をしたメンバーが「責められる（ネガティブなムード）」か、「助けられる（ポジティブなムード）」かで、トラブルの早期発見率が劇的に変わります。

　・「失敗の資産化」
　　トラブルを「あいつのミス」にするか、「システムの仕組みの穴」として全員でカイゼンに向かうかの空気感。

　(2)技術的な挑戦と品質を左右する「フィードバックの質」
　　コードレビューやペアプログラミング、定例会議でのコミュニケーションのトーンが、プロダクトの品質を決めます。

　・「レビューが人格否定に見える空気」
　　指摘が攻撃的に捉えられるムードだと、メンバーは萎縮し、必要最小限のコードしか書かなくなります（技術負債の温床）。

　・「互いをリスペクトする空気」
　　「より良くするための提案」として受け入れられるムードがあれば、技術的な議論が活発化し、チーム全体のスキルが底上げされます。

　(3)職種間の壁を崩す「共通言語・ブリッジ」の意識
　　ビジネス職（営業・企画・PM）と技術職（エンジニア・デザイナー）の間に流れる空気をどうコントロールするかです。

　・「分断（敵対）ムード」
　　「営業は無茶ばかり言う」「開発は腰が重い」という相互不信のムードは、仕様の擦り合わせを破綻させます。

　・「ワンチームのムード」
　　お互いの専門性をリスペクトし、「顧客に価値を届ける」という共通のゴールに向けてリソースを最適化しようとする空気。

【関連記事】

☆IT現場の生態系

☆プロマネの生きる道

☆プロジェクトマネジメントの小径

書籍の紹介

・ピープルウエア　第3版
・トム デマルコ；ティモシー リスター (著)
　松原 友夫；山浦 恒央；長尾 高弘 (翻訳)  形式: Kindle版
・出版社 ‏ : ‎ 日経BP　 2013/12/24
・開発プロジェクトで技術よりも何よりも大事なもの――それは「人」。一人一人の人格の尊重、頭を使う人間にふさわしいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織づくり、という6つの視点から「人」を中心としたプロジェクト開発の大切をユーモラスに語っている。
　1987年の初版発行以来、多くのソフトウエア・エンジニアの共感を呼んだ名著の改訂第3版。第3版では、時代の変化に対応し、以下の章が追加された。「リーダーシップについて話そう」、「他者とうまくやっていく」、「幼年期の終わり」、「リスクとダンスを」、「会議、ひとりごと、対話」、「E(悪い)メール」。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・プロジェクトマネジメント知識体系ガイド
　（PMBOKガイド）第7版 Kindle版
　＋プロジェクトマネジメント標準: PMI日本支部 監訳
　プロジェクトマネジメント協会（PMI） (著)
　一般社団法人 PMI日本支部 (2023/1/6)
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解即戦力　PMBOK第7版の知識と手法がこれ1冊でしっかりわかる教科書 Kindle版
　前⽥ 和哉 (著)
　 技術評論社 (2024/9/20)
　プロジェクトマネジメントの世界標準として知られるPMBOK Guide 第7版の解説書です。「プロジェクトの基本」「価値実現システム」「12の原理・原則」などプロジェクトマネジメントの基礎となる知識のほか、PMBOK第7版のメインテーマともいえる「8つのパフォーマンス領域」について、要点をくわしく解説します。プロジェクトマネジメントの勉強のほか、PMP試験対策の第一歩としてもおすすめできる1冊です。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・図解入門よくわかる 最新PMBOK第6版の基本 Kindle版
　鈴木安而 (著)
　‎ 秀和システム (2018/3/23)
　PMBOKガイドは、米国プロジェクトマネジメント協会により、日本語を含め世界11ヶ国語に翻訳・出版されています。翻訳されても、専門用語が多い、カタカナ用語が多いなどの理由からなかなか理解が困難です。本書は、『PIMBOKガイド第6版』の翻訳・監訳チーム・リーダーでもある著者が、本来の意味をなるべくかみ砕いて解説します。イメージしやすいよう図版を豊富に使っているので、初心者からベテランまでわかりやすくなっています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

・プロジェクトマネジメントの基本がこれ1冊でしっかり身につく本 Kindle版
　前田和哉【著】
　技術評論社（2022/06）
　本書は、プロジェクトマネジメントについて基本から学ぶことのできる入門書です。プロジェクトマネジメントの基礎知識について解説した後、プロジェクトを「立ち上げ」「計画」「実行」「監視・コントロール」「完了」という5つの段階に分け、各段階において実施すべきこと、注意すべきポイントについて丁寧に解説しています。
（ ※ 書籍の解説等は原則としてリンク先（Amazon）における解説をベースに記載しています。詳細内容はリンク先を参照願います。）

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-