会議室に10人のエンジニアがいます。

PM「このスケジュールで問題ないですよね？」

（全員の心の声：いや、絶対無理だろ）

エンジニアA「…大丈夫だと思います」
エンジニアB「（Aが大丈夫って言ったし）問題ないです」
エンジニアC〜J「（みんな大丈夫って言ってるし）異議ありません」

── 3ヶ月後、プロジェクトは見事に炎上しました。

全員が「無理だ」と思っていたのに、誰一人そう言えなかった。

こんにちは、株式会社イデアルアーキテクツです。

今日は、この「沈黙の共犯関係」を生む原因──心理的安全性について掘り下げてみます。

🔬 Googleが出した「最強チーム」の答え

Googleが2012年から実施した社内調査「プロジェクト・アリストテレス」をご存知でしょうか。

180以上のチームを分析し、「生産性の高いチームの共通点は何か」を徹底的に調べたプロジェクトです。

調査の結果、チームの成果を最も左右する要因は「誰がチームにいるか」ではなく「チームがどう協力しているか」でした。

そして、最も重要な要素として挙げられたのが 心理的安全性 です。

Googleが特定した5つの要素

- 心理的安全性 ── ミスをしても非難されないと信じられる（最重要）
- 相互信頼 ── メンバーが期待通りに仕事をすると信頼できる
- 構造と明確さ ── 役割・計画・目標が明確である
- 仕事の意味 ── 業務が個人的に意味があると感じられる
- インパクト ── 自分の仕事が影響を与えていると実感できる

注目すべきは、心理的安全性が他の4つの土台になっていることです。安心して発言できない環境では、信頼も構造も意味も成り立ちません。

🤔 「心理的安全性」って、要はぬるま湯のこと？

ここでよくある誤解を解いておきます。

心理的安全性 ≠ 仲良しクラブ

「何を言っても許される」「対立がない」「緊張感がない」──これは心理的安全性ではありません。

心理的安全性の本質は、建設的な意見の対立を恐れない状態です。

「このコード、設計的にまずいんじゃないですか？」
「この仕様、ユーザーの視点が抜けてませんか？」
「正直、スケジュール的に無理です」

こういった率直なフィードバックが自然にできる状態。それが心理的安全性です。

心理的安全性が低いチームで起きること

- バグに気づいても「余計なことを言って嫌われたくない」と黙る
- 仕様に疑問があっても「空気を読んで」従う
- 障害の原因を知っていても「犯人扱いされたくない」と報告しない
- 新しい技術を提案したくても「生意気だと思われそう」でやめる

結果として、問題が水面下で肥大化し、ある日突然プロジェクトが炎上する。

エンジニアなら一度は経験したことがあるのではないでしょうか。

🍳 心理的安全性がゼロの料理教室（想像してください）

ちょっと極端な例え話をさせてください。

心理的安全性がゼロの料理教室があったとします。

生徒「先生、鍋から火が出てるんですが…」
先生「今は質問の時間じゃありません」
生徒「いや、でも本当に燃えて──」
先生「手順通りにやってください」

（教室、全焼）

報告書：「生徒の技量不足が原因」

…笑えますよね。でも、これと同じことがIT現場で毎日起きています。

「本番環境のログ、なんかおかしいんですけど…」
「今は機能開発に集中して。あと、それ、チケット切った？」

火が出てるのに手順を聞くな、って話です。

このバカバカしさに気づけるかどうかが、チームの命運を分けます。

⚡ SESエンジニアが特に感じる「言いにくさ」

ここからが僕たちにとって大事な話です。

SESエンジニアは常駐先で働くという特性上、心理的安全性が確保されにくい構造にあります。

よくあるシーン

「客先のコードに問題があるけど、指摘しにくい」
→ 外部の人間が内部のやり方に口を出すのは勇気がいる

「プロジェクトの進め方に疑問があるけど、立場的に言えない」
→ お客様のチームに合わせるのが暗黙のルール

「新しい現場で、質問すること自体がハードル」
→ 何を聞いていいのか、誰に聞けばいいのかがわからない

「所属元にも常駐先にも本音を言えない」
→ 二重の組織関係で、どちらにも遠慮してしまう

これ、SESエンジニアの「あるある」ですよね。

🛠️ 心理的安全性をつくる5つの実践

では、エンジニアのチームで心理的安全性を高めるにはどうすればいいのか。

すぐに実践できることを5つ挙げます。

1. 「わからない」を歓迎する

技術の世界では「知らない＝恥」という空気になりがちです。

でも、「わからない」と言えることこそがチームの強さです。

リーダーが率先して「この技術、正直よくわかっていないんだけど、誰か詳しい人いる？」と言えるチームは強い。知ったかぶりで進んで後で詰むより、100倍マシです。

2. 失敗を「学習」として共有する

障害報告を「誰が悪いか」ではなく「何が起きて、何を学んだか」にフォーカスする。

いわゆるブレームレス・ポストモーテム（非難なき振り返り）です。

GoogleやNetflixなどの企業で標準的に行われている手法で、「障害は個人の責任ではなくシステムの問題」として捉えます。これだけで、チームの報告速度が劇的に上がります。

3. 1on1を「評価面談」にしない

1on1ミーティングが上司による「進捗確認」になっていませんか？

心理的安全性を高める1on1は、メンバーの話を聞く時間です。

「最近、困っていることはある？」
「仕事で楽しいと思えていることは？」
「キャリアについて考えていることはある？」

こういう問いかけを、評価とは切り離した場でやることが大切です。

4. 「反対意見」を制度化する

重要な意思決定の場で、あえて反対意見を言う役割を設ける方法があります。

「デビルズ・アドボケイト（悪魔の代弁者）」と呼ばれる手法で、誰かが必ず「本当にそれでいいのか？」と問い返す。

反対意見が個人の意見ではなく役割になるので、発言のハードルが下がります。

5. 小さな成功体験を積む

「意見を言ったら受け入れてもらえた」
「質問したら丁寧に答えてもらえた」

こうした小さな成功体験の積み重ねが、心理的安全性の土台になります。

いきなり大きな文化改革は不要です。明日の朝会で「何か気になっていることはありますか？」と一言聞くだけでも変わります。

💡 イデアルアーキテクツが大切にしていること

僕たちは、SES企業だからこそ心理的安全性を意識しています。

常駐先で一人で頑張っているエンジニアが、孤独にならない仕組みが必要です。

具体的には、こんなことを心がけています。

- 定期的な1on1 ── 評価ではなく「何でも話せる場」として設計
- 案件の選択肢を提示 ── 合わない現場に無理に居続けなくていい
- 技術的な相談チャンネル ── 常駐先で聞きにくいことを社内で聞ける
- 「やってみたい」を応援する文化 ── 新しい技術に挑戦したい気持ちを歓迎する
- 失敗を責めない ── 「次どうするか」だけを一緒に考える

エンジニアが安心して技術に集中できる環境。それこそが、本当の意味でのエンジニアファーストだと考えています。

まずは話を聞きに来ませんか？

「今の現場、ちょっと息苦しいかも…」
「もっと自由に意見が言える環境で働きたい」
「SESでも心理的安全性って本当にあるの？」

そう感じている方、ぜひカジュアルにお話ししましょう。

堅苦しい面接ではなく、コーヒーを飲みながら本音で話せる場を用意しています。

💡 今日の理想をカタチにする一言

> 「"失敗しても大丈夫"と言ってくれる人がいるだけで、人は信じられないほど強くなれる」

#エンジニア採用 #心理的安全性 #チームビルディング #エンジニアの働き方 #SES #エンジニアファースト #Google #プロジェクトアリストテレス