はじめに: 「私がやりました」という一言
障害レビューの会議室。決済システムがたった今30分間止まり、数百件の取引が失敗しました。みんなが原因を探しています。そのとき一人のエンジニアが手を挙げて言います。「昨日デプロイした設定変更が原因です。ロールバック手順を抜かしました。」
この一言を口にするには勇気が要ります。そしてその勇気が出せるかどうかは、ほぼ完全に*その部屋の空気*にかかっています。もしその言葉の後に非難と追及が降り注げば、次の障害のとき誰も手を挙げないでしょう。逆に「正直に言ってくれてありがとう。この手順をどう自動化できるか一緒に見ましょう」という反応が出れば、そのチームは毎回より強くなります。
この記事は「ミスを認めよ」という道徳的な勧めではありません。ミスを認めることが*なぜこれほど難しいのか*をまず理解し、それを可能にする条件 — 心理的安全性(psychological safety) — をどうつくるかを具体的に扱います。そして核心的な主張はこれです。心理的安全性は「優しい空気」の問題ではなく、**成果の問題**です。
ミスを認めるのが難しい理由
まず認めるべき事実があります。ミスを隠すのは欠陥ではなく*本能*です。非難を避けようとする心は、進化的に深く刻まれています。群れから排斥されることが生存に致命的だった時代の名残です。
組織の中で、私たちは絶えず印象管理(impression management)をしています。エイミー・エドモンドソンは、人が職場で避けたい四つのイメージを整理しました。
避けたいイメージ だからやらなくなる行動
-------------------- -----------------------------------------
無知に見えること 質問をしない
無能に見えること ミスを認めず助けを求めない
邪魔者に見えること 意見や懸念を言わない
否定的に見えること 批判や異なる見解を言わない
この表が示すのは恐ろしい事実です。*沈黙が常により安全な選択だ*ということです。質問しない、ミスを隠す、懸念を飲み込む — これらは短期的には常に合理的です。問題は、この個人的に合理的な沈黙が集まると、組織全体が学習能力を失うことにあります。
沈黙のコスト
沈黙が積み重なると何が起こるでしょうか?
- 小さな問題が隠されたまま大きな事故になります(覆われたバグ、無視された警告)。
- 同じミスが繰り返されます(誰もミスから学べないので)。
- 良いアイデアが葬られます(言うのが怖くて)。
- 最も正直な人が最も損をします(一人で手を挙げて非難されるので)。
だからミスを認める問題は、個人の勇気の問題ではなく*システムの問題*です。勇気だけに頼る組織は失敗します。正直さが安全な環境をつくる組織が成功します。
Edmondsonの心理的安全性: 四つの要素
ハーバード経営大学院のエイミー・エドモンドソンは、1990年代から「心理的安全性(psychological safety)」の概念を研究してきました。彼女の定義はこうです。
> 「心理的安全性とは、対人関係のリスクを取っても安全だという共有された信念である。」
つまり、質問したりミスを認めたり懸念を言ったりしても*罰せられたり恥をかかされたりしない*という信念です。興味深いことに、グーグルの大規模なチーム研究「プロジェクト・アリストテレス」は、高成果のチームを分ける最も重要な要因がまさに心理的安全性だという結論に至りました。賢い個人の総和よりも安全な空気のほうが重要だったのです。
心理的安全性を成す要素
エドモンドソンの研究と関連する後続研究を総合すると、心理的に安全なチームには次の四つがあります。
1. **包摂と帰属感**: 自分がこのチームに属し、ありのままで受け入れられているという感覚。最も基本的な土台です。
2. **学習への安全**: 質問し、知らないと言い、実験し、ミスをしても大丈夫だという信念。成長が起こる領域です。
3. **貢献への安全**: 自分の意見やアイデアが歓迎され、真剣に扱われるという感覚。
4. **挑戦への安全**: 現状に疑問を投げかけ、より良い方法を提案しても安全だという信念。最も高いレベルです。
誤解を正す: 心理的安全性 ≠ ぬるい空気
ここで最もよくある誤解を指摘しなければなりません。心理的安全性は「みんな仲良く、批判なし、基準は低く」では*ありません*。むしろ正反対です。エドモンドソンは、心理的安全性と成果基準を二つの軸とするマトリクスを示します。
高い成果基準
^
不安ゾーン | 学習ゾーン
(Anxiety) | (Learning)
<----------------+----------------> 高い心理的安全性
無関心ゾーン | 安楽ゾーン
(Apathy) | (Comfort)
|
低い成果基準
- **不安ゾーン**: 基準は高いが安全は低い。人々は恐れに震えながら働きます。ミスを隠し、燃え尽きが来ます。
- **安楽ゾーン**: 安全は高いが基準が低い。快適ですが成長がありません。「ぬるい空気」は実はここです。
- **無関心ゾーン**: どちらも低い。誰も気にしません。
- **学習ゾーン**: 安全も高く基準も高い。**ここで最高の成果と成長が起こります。**
核心は明確です。心理的安全性は高い基準の*代替*ではなく、高い基準を*可能にする条件*です。安全だからこそ、人々は難しい真実を語り、リスクを取り、互いに率直なフィードバックを与えられるのです。
非難なきポストモーテム(Blameless Postmortem)
心理的安全性をシステムとして実装した最良の例が**非難なきポストモーテム**です。グーグルのSRE文化やEtsyなどが定着させたこの慣行は、障害が起きたとき「誰が悪かったか」ではなく「システムがなぜこのミスを許したか」を問います。
核心的前提: 人はミスをする
非難なきポストモーテムの哲学的出発点はシンプルです。**善意で有能な人もミスをする。** したがって一人を非難して解雇しても根本問題は直りません。次の人も同じ罠に落ちるからです。
代わりに問いが変わります。
- 「なぜその人がミスをしたのか」(X)
- 「なぜシステムがそのミスを容易にし、防げなかったのか」(O)
非難するレビュー vs 非難なきレビュー
対話の例で違いを見ましょう。
非難するレビュー:
> 「誰がこのデプロイを承認したんですか? なぜ確認しなかったんですか? 次はもっと気をつけてください。」
こうしたレビューの結果: 人々は防御的になり、本当の原因は隠され、次の障害のとき誰も正直に話しません。
非難なきレビュー:
> 「このデプロイが検証なしで本番に出ましたね。どの段階で検証が省かれたのでしょう? 検証を義務化または自動化するには何が必要でしょうか?」
こうしたレビューの結果: 本当の原因(検証手順の空白)が露わになり、システムが改善され、人々は次も正直に共有します。
良いポストモーテムの構成要素
セクション 内容
-------------- -----------------------------------------
タイムライン 何がいつ起きたか(事実のみ、判断なし)
影響 誰が/何がどれほど影響を受けたか
根本原因 5 Whysなどでシステム的原因まで掘り下げる
うまくいった点 対応で効果があったこと
改善アクション 再発防止のための具体的で責任者がある項目
特に「うまくいった点」のセクションが重要です。障害レビューが自責の場ではなく学習の場であることを空気で示すからです。
リーダーが先に脆弱性を見せる
心理的安全性は上からつくられます。どれほど「正直に言って大丈夫」と言っても、リーダーが自分のミスを決して認めなければ誰も信じません。行動が言葉に勝ります。
リーダーの脆弱性が持つ力
リーダーが「私がこの判断を誤りました」と言う瞬間、二つのことが起こります。
1. **許可の信号**: 「ここではミスを認めても安全だ」というメッセージが全体に広がります。
2. **信頼の逆説**: 直感に反して、脆弱性を見せたリーダーは弱く見えず*より信頼されます*。ブレネー・ブラウンの研究がこの「脆弱性の力」をよく示しています。
リーダーができる具体的な行動
行動 例
-------------------- -----------------------------------------
自分のミスを共有 「先四半期、私の判断ミスで日程が遅れました」
知らないことを認める 「それは私も分かりません。一緒に調べましょう」
質問を歓迎する 「良い質問です。他に聞きたいことはありますか?」
失敗した人を守る 非難の代わりに「大丈夫、一緒に直しましょう」
フィードバックを求める 「私がもっと良くできることは何でしょう?」
特に最後の「フィードバックを求める」が強力です。リーダーが自分についてのフィードバックを心から求めれば、チーム全体にフィードバックが安全だという信号が伝わります。
「分かりません」と「私が間違っていました」の力
心理的安全性が高いチームの共通点の一つは、人々が二つの文を気楽に言うことです。「分かりません」と「私が間違っていました」。
「分かりません」が強い人の表現である理由
多くの人が「分かりません」を無能の告白と見なします。しかし実際は逆です。
- 知らないことを認める人は*学ぶ準備ができています*。
- 知らないことを認める人は*推測で仕事を台無しにしません*。
- 知らないことを認めるシニアは、ジュニアに*「知らなくても大丈夫」という許可*を与えます。
最も危険な人は、知らないのに知っているふりをする人です。その虚勢が誤った決定と隠れたリスクを生みます。
「私が間違っていました」がつくる信頼
自分が間違っていたことを素早く認める人は、逆説的により信頼されます。なぜなら:
- その人が「正しい」と言うとき、その言葉を信じられるからです(間違えば認める人なので)。
- 真実をプライドより優先する人だと示すからです。
- 議論が「誰が勝つか」ではなく「何が正しいか」に向かうからです。
対話の例:
> 同僚A: 「この方式は並行性の問題がありそうです。」
> 同僚B: 「うーん、その部分を見落としていました。正しい指摘です。どう直せばいいでしょう?」
この短いやり取りでBは弱く見えるどころか、プライドよりも良い結果を選ぶ人に見えます。
心理的安全性を測定する
「測定できなければ管理できない」という言葉があります。心理的安全性も漠然とした感覚ではなく、測定可能な対象です。エドモンドソンはチームの心理的安全性を測る設問を提案しました。次の文にチームメンバーがどれほど同意するかで診断できます。
診断項目(同意の程度で回答)
-----------------------------------------
1. このチームでミスをするとしばしば不利益を受ける(逆採点)
2. このチームでは難しい問題を提起できる
3. このチームの人は違うという理由で他人を排斥しない
4. このチームではリスクを取っても安全だ
5. このチームに助けを求めるのは難しい(逆採点)
6. 誰も私の努力をわざと貶めない
7. 私の固有のスキルと才能が価値あるものとして扱われる
1番と5番は逆採点の項目です。点数が低いほど安全です。こうした診断を定期的に(例: 四半期ごとに匿名で)行えば、空気の変化を追跡できます。
行動の信号で読む
設問なしでも日常の行動から心理的安全性を読めます。
- 会議で*誰が*話すか? 少数だけが話すなら危険信号です。
- 「分かりません」「私が間違っていました」がどれほど頻繁に聞こえるか? まったく聞こえないなら、人々が仮面をかぶっています。
- 悪い知らせが*速く*上がってくるか、それとも隠されて爆発するか? 速い報告は安全の証拠です。
- 新入りが最初の一週間でどれほど質問するか? 沈黙する新入りはすでに空気を読んでいます。
段階的に安全を積む: 最初の一歩
心理的安全性は一朝一夕には生まれません。それは小さな行動の蓄積です。リーダーであれチームメンバーであれ、今日始められる最初の一歩があります。
一度の会議から始める
タイミング 具体的な行動
-------------- -----------------------------------------
会議の開始 「今日は反対意見も歓迎します」
誰かが沈黙したら 「OOさんの考えはどうですか?」と直接招く
良い質問に 「それは本当に良い質問ですね」と認める
ミスが出たら 「共有してくれてありがとう」とまず反応
会議の終わり 「今日、私たちが見落としたことはありますか?」
特に「OOさんの考えはどうですか?」のように*静かな人を招く*行動が強力です。話さない人は意見がないのではなく、話すことが安全でないと感じることが多いのです。招きはその扉を開きます。
小さな約束を守ることの力
心理的安全性の土台は信頼であり、信頼は小さな約束を守ることから積み上がります。「明日までに見ます」と言ったら明日までに見ること。この小さな一貫性が「この人は言った通りにやる」という信頼をつくり、その信頼が「この人の前では正直でも安全だ」へと広がります。
失敗から学ぶシステム
心理的安全性は個人の態度だけでは維持されません。失敗から*体系的に*学ぶシステムが必要です。安全を空気に委ねず、構造にするのです。
失敗を学習に変える仕掛け
- **非難なきポストモーテム(前述)**: すべての意味ある障害について定例化します。
- **エラーバジェット(error budget)**: 一定水準の失敗を*許容された予算*として明示します。失敗がゼロであるべきという圧力は、むしろ実験を妨げ失敗を隠させます。
- **失敗共有の集まり**: 「今週私がやらかしたこと」を気軽に分かち合う場。失敗の正常化(normalization)。
- **改善アクションの追跡**: ポストモーテムで出たアクションが実際に実行されるか追跡します。さもないとレビューが形式になります。
失敗の種類を区別する
バランスの取れた視点のために重要な区別があります。エドモンドソンは、すべての失敗を同じように称えてはならないと強調します。失敗には種類があります。
失敗のタイプ 例 対応
-------------- -------------------- -------------------
非難に値する失敗 手順無視、不注意 コーチング、明確な基準
複雑性の失敗 予測できない相互作用 システム改善
知的な失敗 新しい試みの実験 称えて学ぶ
「心理的安全性」が「どんな失敗でも大丈夫」という意味ではないことに注目してください。意図的な怠慢や繰り返される不注意は依然として扱うべきです。ただし*扱う方法*が非難ではなく、コーチングとシステム改善である点が違います。
アンチパターン: 責任転嫁とその親戚たち
最後に、心理的安全性を崩すアンチパターンを見ていきます。これらに気づくだけで半分は防げます。
責任転嫁(Blame Game)
最も破壊的なアンチパターンです。障害が起きると「誰のせい」をまず探す文化。結果は明白です。人々はリスクを隠し、情報を伏せ、自己保護にエネルギーを使います。
その他のよくあるアンチパターン
アンチパターン 症状 解毒剤
-------------- -------------------- -------------------
責任転嫁 「誰のせいだ?」 「システムがなぜ許したか?」
英雄崇拝 一人がすべて抱える 知識の分散、ペアリング
処罰的レビュー レビューが詰問の場 非難なきポストモーテム
完璧主義の圧力 失敗が決して許されない エラーバジェット、知的失敗を称える
表面的な同意 会議では頷き、裏では不満 反対意見を積極的に求める
偽の安全 「大丈夫」だけ繰り返し実践なし 言葉でなく行動で証明する
特に「偽の安全」を警戒すべきです。リーダーが「ここでは正直でいい」と言うだけで、いざ誰かが正直になると不快がったり不利益を与えたりすれば、その隔たりがかえって信頼をより大きく崩します。心理的安全性は宣言ではなく*繰り返された行動の蓄積*によってのみつくられます。
事例ウォークスルー: 一つの障害がチームを強くした過程
前述の原理が実際にどう働くのか、仮想の(しかし非常によくある)障害を追ってみましょう。
**状況**: あるジュニアエンジニアがマイグレーションスクリプトを誤って実行し、本番DBの一部のデータが30分間、誤った値を持つことになりました。
**悪い経路(非難文化)**:
> マネージャー: 「なぜ本番で直接実行したんですか? 誰がそうしろと言いました?」
> ジュニア: (凍りつきながら)「すみません……確認できませんでした。」
結果: ジュニアは萎縮し、本当の原因(本番とステージングを区別しにくいツール設計)は埋もれます。次に似たリスクを見た人も沈黙します。
**良い経路(非難なき文化)**:
> マネージャー: 「まず、素早く共有してくれてありがとう。おかげで30分で捕まえられました。一緒に見ましょう。どうして本番スクリプトがステージングのように見えたのでしょう?」
> ジュニア: 「ターミナルで二つの環境がほぼ同じに見えて、本番だと気づきませんでした。」
> マネージャー: 「良い発見です。では本番ターミナルを赤色で表示するか、本番マイグレーションに確認ステップを入れるのはどうでしょう?」
結果: 非難なきポストモーテムから二つのアクションが出ます — (1) 本番環境の視覚的警告、(2) マイグレーションの確認ゲート。システムが改善され、ジュニアは萎縮するどころか次も素早く報告する人になります。そしてこの話を聞いたチーム全体が「ここでは正直に話すのが安全だ」をもう一度学習します。
同じ障害、まったく異なる結果。違いをつくったのは技術ではなく*最初の反応*でした。
均衡: 安全と責任は衝突しない
心理的安全性を語るとき最もよくある反論は「それでは誰も責任を取らないぬるい組織になるのではないか」というものです。この誤解を正確に解かなければなりません。
心理的安全性と責任(accountability)は対立項ではなく、二つの独立した軸です。
高い責任
^
不安ゾーン | 高成果の学習ゾーン
<----------------+----------------> 高い心理的安全性
無関心ゾーン | 安楽ゾーン
|
低い責任
- 責任だけ高く安全が低いと: 不安ゾーン。人々が恐れてミスを隠します。
- 安全だけ高く責任が低いと: 安楽ゾーン。楽だが結果が出ません。
- 両方とも高いとき: **高成果の学習ゾーン。** 人々が正直にミスを認め*て*、それを直す責任も共に負います。
核心的な洞察はこれです。非難なき文化は「責任のない文化」ではなく「責任の方向が人からシステムへ、そして未来の改善へ向かう文化」です。
責任を問う正しい方法
- 人を罰する責任 (X): 「誰がやった?」 → 隠す
- 改善に向かう責任 (O): 「どう再発を防ぐか? そのアクションは誰がいつまでにやるか?」
後者も明確に誰かに責任を負わせます。ただしその責任が*過去の非難*ではなく*未来の改善*に向かいます。これが本物の責任であり、同時に安全な責任です。
おわりに: 安全が先、成果はその上に
あの障害レビューの会議室に戻ります。手を挙げて「私がやりました」と言ったエンジニア。その一言が出せたのは、その人が特別に勇敢だったからではありません。その部屋が*その言葉を安全にしておいたから*です。
心理的安全性は優しさの問題ではありません。それは成果の土台です。人々が分からないと言えてこそ学び、間違っていると言えてこそ直し、懸念を言えてこそ事故を防ぎます。そしてこのすべては、高い基準と*共に*行くとき最高の成果につながります。
安全と基準は二つのうち一つを選ぶものではありません。安全は基準を可能にする床です。床が固いとき、私たちは初めて高く積み上げられます。
最後に、これはリーダーだけの仕事ではありません。私たち一人ひとりが「大丈夫、一緒に直しましょう」と言うたびに、誰かが手を挙げられる部屋が一回り広くなります。
一文に要約すると
この長い話を一文に縮めるとこうなります。**人々が真実を語ることが安全なとき、組織は初めて学び始める。** 真実には悪い知らせ、知らないことの告白、自分のミス、異なる意見がすべて含まれます。これらの真実が恐れなく流れるとき、小さな問題は大きくなる前に捕まえられ、良いアイデアは葬られず、同じミスは繰り返されません。
心理的安全性はその真実の流れを可能にする通路です。そしてその通路は大げさな制度ではなく、今日あなたが同僚のミスに示す最初の反応からつくられます。
実践チェックリスト
**個人として**
- [ ] 最近「分かりません」と正直に言ったことがあるか?
- [ ] 自分が間違ったとき素早く認めるか?
- [ ] 同僚のミスに非難ではなく「一緒に直そう」で反応するか?
**リーダーとして**
- [ ] 自分のミスをチームの前で認めたことがあるか?
- [ ] 自分についてのフィードバックを心から求めるか?
- [ ] 誰かが懸念を言ったとき歓迎するか、防御的になるか?
**チーム/システムとして**
- [ ] 非難なきポストモーテムを定例化したか?
- [ ] ポストモーテムのアクションが実際に追跡・実行されるか?
- [ ] 失敗の種類(知的失敗 vs 不注意)を区別して扱うか?
- [ ] 高い基準と高い安全を同時に追求するか?(学習ゾーン)
- [ ] 「偽の安全」の罠に陥っていないか?(言葉と行動の一致)
参考資料
- Amy C. Edmondson, "The Fearless Organization: Creating Psychological Safety in the Workplace" — [https://fearlessorganization.com/](https://fearlessorganization.com/)
- Amy C. Edmondson, "Psychological Safety and Learning Behavior in Work Teams"(Administrative Science Quarterly, 1999) — [https://www.hbs.edu/faculty/Pages/profile.aspx?facId=6451](https://www.hbs.edu/faculty/Pages/profile.aspx?facId=6451)
- Google re:Work, "Project Aristotle"(効果的なチームの五つの要素) — [https://rework.withgoogle.com/](https://rework.withgoogle.com/)
- Google SRE, "Postmortem Culture: Learning from Failure" — [https://sre.google/sre-book/postmortem-culture/](https://sre.google/sre-book/postmortem-culture/)
- Brené Brown, "Dare to Lead"(脆弱性とリーダーシップ) — [https://brenebrown.com/](https://brenebrown.com/)
- Etsy, "Blameless PostMortems and a Just Culture" — [https://www.etsy.com/codeascraft/blameless-postmortems/](https://www.etsy.com/codeascraft/blameless-postmortems/)
현재 단락 (1/180)
障害レビューの会議室。決済システムがたった今30分間止まり、数百件の取引が失敗しました。みんなが原因を探しています。そのとき一人のエンジニアが手を挙げて言います。「昨日デプロイした設定変更が原因です。...