多様性を力に変える!チームを「自走」させる7つのステップ ~ その5 失敗の奨励 ~

目次

この記事について

これはチームや組織が最高のパフォーマンスを発揮するために欠かすことができない7つのステップのうちの五つ目「失敗の奨励」です。

「またか…」が生まれる組織で、人は挑戦しない

私が立て直しのために異動した部署は、リリースの失敗や不具合が続いていました。リリース直後に不具合を検知して切り戻し(リバート)をすることもしばしばで、リリースが失敗に終わると「またか…」という雰囲気になり、それが繰り返されることでリリースがすっかり憂鬱になっていました。

品質の安定性の低さは社内でも有名で、問題が起こると「またか。。」という空気が流れ、社内で自己紹介した際に所属を明かすと「大変ですね」と同情されることもありました。

そして当時の私はどうしていたか。メンバーが生産性や品質改善に向けたツールの導入やアーキテクチャーの変更などを提案してきても「またどうせ失敗する」と取り合わないどころか、彼らがやろうとすることを否定的な目線で細かくチェックし、揚げ足を取るようなフィードバックをすることもありました。

今なら分かります。私は、失敗を減らそうとして、挑戦の芽を摘んでいたのです。

失敗が責められる環境では、人は自己防衛のために、言われたことだけをやり、確実な指示を待つようになります。その2でお話しした心理的安全性の「挑戦」の因子が失われた状態です。そしてもう一つ厄介なのは、失敗が隠れるようになることです。隠れた失敗は、誰も学べないまま、あとでもっと大きくなって出てきます。

「失敗の奨励」は、失敗を歓迎することではない

誤解のないように書いておきますが、「失敗の奨励」は、何でもかんでも失敗していいという話ではありません。同じ失敗を何度も繰り返すことを許容する話でもありません。

奨励するのは、失敗そのものではなく、「学びを伴う挑戦」です。

区別のために、失敗を3つに分けて考えると整理しやすくなります。

  • 防げた失敗(不注意・手順の逸脱):仕組みで防ぐべきものです。責めるのではなく、チェックリストや自動化など、プロセスの側を直します。
  • 避けられない失敗(複雑さゆえのトラブル):複雑なシステムでは一定の確率で起きます。早く気づいて早く戻せるかが勝負です。
  • 知的な失敗(やってみないと分からなかったこと):これが奨励すべき失敗です。新しい技術、新しいやり方、前例のない課題。ここでの失敗は、組織が得た情報そのものです。

リーダーが本当に注意すべきなのは、「知的な失敗」を「防げた失敗」と同じ顔で扱ってしまうことです。これをやると、チームは前例のあることしかやらなくなります。安全に見えて、実はいちばん危ない状態です。

失敗から学べるチームにするために

ここでは、私が実際にやってきたことを一例として紹介します。

リーダーが先に失敗を共有する

いちばん効いたのは、これでした。

私は、常に謙虚な姿勢で知ったかぶりをせず、わからないことは教えてもらい、失敗も進んで共有するようにしていきました。こうすることで、わからないことは聞いてもいいんだ、失敗することは怖くないんだ、ということを少しずつわかってもらうようにしました。

順番が大事です。メンバーに「失敗を共有してください」とお願いしても、まず動きません。リーダーが自分の失敗を先に開示して、それでも何も悪いことが起きないことを、チームが目で見て確認する必要があります。その1でお話しした自己開示は、ここでも土台になります。

犯人ではなく、原因を探す

トラブルが起きたときの最初の一言を、「誰がやったの?」ではなく「何が起きたの?」にしてください。この一言の違いだけで、その後に集まってくる情報の量が変わります。

障害の振り返りでは、人の注意力に原因を求めない(ブレームレスな)進め方が有効です。人は誰でも間違えます。同じ状況に置かれたら他の誰かも同じ間違いをしたはずだ、という前提に立てるかどうか。立てるなら、直すべきはプロセスや仕組みだという結論に自然にたどり着きます。

振り返りを定期的な仕組みにする

私たちはスプリントレトロスペクティブで定期的な振り返りを実施し、日頃の感謝を伝え合い、うまくいったこと、いかなかったこと、次の改善アクションを積極的に共有し合うようにしていました。

失敗から学ぶことを「気持ち」に頼ると、忙しいときから順に消えていきます。だから、カレンダーに乗る仕組みにしてしまうのが確実です。振り返りは、うまくいかなかったことを話す場である前に、感謝を伝え合う場でもあるという設計にしておくと、続きます。

そして、振り返りで出た改善アクションが実際に実行されることが何より重要です。出しても何も変わらない振り返りが数回続くと、チームは本音を出さなくなります。

失敗のコストを下げる

心理的な話だけでは、挑戦は増えません。失敗しても被害が小さくて済むなら、人は自然に挑戦するようになるからです。

小さく出す(1回のリリースの変更量を小さくする)、すぐ戻せるようにする(切り戻しの手順を整えておく)、自動テストで早く気づく。こうした技術的な備えは、実はいちばん直接的な「失敗の奨励」です。挑戦を増やしたいなら、精神論の前に、まず戻せるようにしてください。

「またどうせ失敗する」と言われた側の景色

あのとき、私に提案を取り合ってもらえなかったメンバーは、どんな気持ちだっただろうかと今でも思います。

にもかかわらず、彼らはあのカオスな状況でも明るく前向きに、スケジュールや品質を確保しようと休日出勤も辞さずに力を尽くしてくれていました。今の私があるのは、あの時に諦めずにいてくれた彼らのおかげです。

だからこそお伝えしたいのは、メンバーの提案に対する最初の反応を変えるだけでも、チームは変わり始めるということです。私は、自分の想定外の提案やアイデアがメンバーから出た場合も、まずは受け入れる姿勢を徹底するようにしました。まず「いいね」と受け入れて、わからないことや不安に思っていることはその後で質問する。優れたアイディアは、その中から生まれることが多かったように思います。

挑戦を歓迎する空気は、大きな制度からではなく、リーダーの最初の一言から作られます。

次回は「適切な権限委譲と尊重」です。挑戦できる空気ができたら、次はいよいよ、任せることになります。私がいちばん下手だったところです。


連載「多様性を力に変える!チームを『自走』させる7つのステップ」


7つのステップを、あなたのチームで試してみませんか?

YourRESでは、連載で紹介した7つのステップを、あなたのチームに合わせて一緒に進めるリーダー向けコーチングを提供しています。まずは無料の体験セッション(45分・オンライン)で、あなたの組織の現状をスキャンしてみませんか?

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

こんな方と伴走しています

エンジニアのリーダー・マネージャーの方

プレイヤーからマネージャーへの切り替えや、チームづくりに悩んでいる方へ。

税理士事務所の所長さま

事務所の運営や、スタッフとの関わり方を見つめ直したい方へ。

乗り越えたい壁がある方

仕事のこと、これからのこと。まずは話してみたい方へ。

この記事を書いた人

現役のエンジニアリングマネージャー(開発チームのマネージャー)として働きながら、プロコーチとして活動しています。「エンジニアリング(論理)」と「対話(共感)」の二刀流で、チームの不具合にも、心の不具合にも向き合います。
人一倍しくじり、そのたびに立ち上がってきた経験が、いま同じ場所で迷っている人の役に立つと思っています。

コメント

コメントする

CAPTCHA


目次