チームの「ギスギス」を技術で解決する。エンジニアのための『反応しない練習』活用術

ITエンジニアの現場では、技術的な課題よりも「人間関係」や「急な仕様変更」への対応で疲弊してしまうことが少なくありません。本記事では、ベストセラー『反応しない練習』の考え方をIT現場に適用し、チームの心理的負荷を減らして開発をスムーズに進めるための具体的なメソッドを紹介します。この記事を読むことで、感情的な対立を避け、本来の「ものづくり」に集中できる環境を整えるヒントが得られます。

1. チームを停滞させる「3つのムダな反応」

チームがうまく回らなくなる原因の多くは、起きた「事実」に対して過剰に反応してしまうことにあります。現場でよくある3つのパターンを整理します。

① コードレビューを「人格否定」と捉えてしまう

• ダメなパターン： 指摘を受けた際に「自分はダメなエンジニアだ」と落ち込んだり、ムキになって反論したりする。
• 変えるための視点： 相手は「あなた」ではなく「プログラム」の改善点を話しているだけです。自分と成果物を切り離し、「そういう書き方もあるのか」という事実だけを受け取ります。

② 急な要望を「敵の攻撃」と捉えてしまう

• ダメなパターン： 営業や上司からの仕様変更に対し、「現場を分かっていない！」とイライラをぶつける。
• 変えるための視点： 相手を「嫌なやつ」と見るのをやめます。相手も「プロジェクトを良くしたい」という目的は同じです。感情で返さず、「今の期限ならA案、1週間伸ばせるならB案」と数字や選択肢で返答します。

③ 周囲の目を気にして「停滞」してしまう

• ダメなパターン： 「初歩的な質問をしたら笑われるかも」と不安になり、相談や発信をためらう。
• 変えるための視点： 批判への不安はすべて頭の中の「妄想」です。「やってみて、何か言われたらその時に考える」というスタンスで、まずは行動という事実を作ります。

2. 「イライラするチーム」から「サクサク進むチーム」へ

「反応しない」ことをチームの合言葉にすると、組織の空気感は次のように変化します。

3. 明日から現場で実践できる2つの共通ルール

難しい理屈は抜きにして、まずは以下の2つをチームの運用に取り入れてみてください。

① 「それは事実？ それとも妄想？」と確認し合う

議論がヒートアップしそうな時、一度このフィルターを通します。

• 具体例： 急な変更にメンバーが「現場をバカにしている！」と怒っている場合。
• アクション： 「『バカにされた』という感情は一旦置いておきましょう。『今の人数と期間ではこの機能の実装は厳しい』という事実を整理して、期間を延ばすか機能を削るか相談しませんか？」と提案します。

② 感情と状況を「箱分け」する

嫌なことがあった時、我慢するのではなく頭の中でラベルを貼って整理します。

• 具体例： レビューで「センスがない」と心ないコメントを書かれた場合。
• アクション： 頭の中に「感情の箱（傷ついた、ムカつく）」と「事実の箱（相手は別の書き方を推奨している）」の2つを用意します。感情を否定せず認めた上で、「具体的にどの部分をどう変えるのが理想ですか？」と事実の箱にある情報だけを引き出します。

結びに：心に余裕があるチームが、一番強い

仕事がサクサク進む良いチームとは、決して「全員が超人的なスキルを持っているチーム」ではありません。ムダな感情のぶつけ合いをせず、目の前の課題に淡々と取り組めるチームです。

『反応しない練習』をチームのルールにすることで、余計なストレスを減らし、私たちが本来やりたかった「面白いものづくり」に集中できる環境を作っていきましょう。