はじめに

この記事について

最近読書感想文が多いですが、それだけ良書に出会えていることの証左でもあるので、喜ばしいことです、とくに、自分の現況にとってタイムリーなものは。

「困難と不確実性に強いチームのつくり方」というサブタイトルに惹かれて買ってみました。

最近ひょんなことからエンジニアリングマネジャーっぽい仕事をしていて、チームビルディングを請け負っています。これまで情報システム部の部長とか、インフラチームのリーダーとかはやったことがありますが、それほどチーム作りに長けているわけではないので、これを機に少し学びたい、と思ってたところにこの本と出会えたのは幸甚でした。

ソフトウェア開発の仕事は、まさに困難と不確実性の連続です。
作るものも不安定（なんせ「ソフト」ウェアなので）だし、チームも不安定です（ソフトウェアエンジニアの雇用流動性はおそらく平均よりも高いでしょう）。

本書は、ソフトウェアエンジニアチームに焦点を当てているわけではないですが、内容はまさにぴったりなものになっていると思います。

なお、本記事中の引用は、断り書きがなければすべて本書からのものです。

レジリエンスとは

辞書（Cambridge Learner's Dictionary）によると、以下のような意味です:

resilient: strong enough to get better quickly after damage, illness, shock, etc:

傷ついたとき、病気になったとき、ショックを受けたとき、そのような状態から素早く立ち直ることができる強さ、日本語で一言でいうと、回復力でしょうか。

ビジネスの文脈でレジリエンスといえば、主に失敗や挫折からの回復、ということになります。

「チームレジリエンス」の感想

「早く行きたければ一人で行け。遠くへ行きたければみんなで行け。」

本書の冒頭で引用されているアフリカのことわざです。

この言葉は、私が今年の4月に某社で新卒向けに「チームでソフトウェア開発するときの上流工程」に関する研修をやったとき、資料の最初に掲げたものです。

まれに、ソフトウェア開発の仕事を一人でやることもありますが、たいていの場合はチームで取り組むことになります。それは、「一人で行」くには遠すぎる目的地が設定されていることがほとんどで、ビジネスでサービスを提供するとなると、カバーする範囲が広すぎてとても一人では面倒を見切れないからです。ただし、「みんなで行」ったところで、目的地にたどり着けるかどうかは別問題で、数々の困難と不確実性が待ち構えているため、それらを乗り越えていかねばなりません。

本書は、そうした困難と不確実性に「チームで」どう立ち向かえばいいか、の指南書です。

「困難と不確実性」によってもたらされるチームの危機からどうやって立ち直るかについて、さまざまな研究結果を踏まえて、順序よく論理的に書かれている点が、自分にとっては納得感が高かったです。

はじめに定義を定めているところが良い

まずは、「困難」と「不確実性」の定義から述べています。

困難に関しては以下のように定めています。

本書では「困難」を「個人やチームの存在価値・信念・目標達成を脅かすストレス要因」と定義しておくことにします。

「困難」を「ストレス要因」としているのが面白いですし、より明確な定義になっていると思えます。ある事象に対してストレスを感じるかどうかは人それぞれですが、だれかにとって（とくにチームのメンバーにとって）ストレスになりうる要素であれば、それは立派な困難と断定してしまって良い、ということです。

いっぽう不確実性に関しては、VUCA（Volatility: 変動性、Uncertainty: 不確実性、Complexity: 複雑性、Ambiguity: 曖昧性）をまとめて「どうすればうまくいくのかわからない」ことこそが、ストレス要因（つまり困難）であるとしています。とくに、不確実性は「この先どうなるかわからない」という点で不安を引き起こしますし、その不安と向き合えないと問題を正しく解決できない、と説きます。

自分の意志と感情に向き合えなくなったチームは、互いの関係性をさらに悪化させ、内的な「困難」をさらに増幅させていくのです。これこそが、現代に渦巻く「困難」と「不確実性」の悪循環のメカニズムなのです。

続いて「チームレジリエンス」の定義です。

本書はあくまでチームの話なので、個人のレジリエンスとは少し異なる概念を提示します。

チームレジリエンス＝チームが「困難」から回復したり、成長したりするための能力やプロセス

とくに、個人のレジリエンスが高くても、チームのレジリエンスが高いとは限らない、というのは意外でした。むしろ、チーム単位で見たときに、個人のレジリエンスが悪い方に作用することすらあるとのことなので、考えを改めようと思いました。

自分のこれまでの経験上「強いチーム」はどんなチームだったかを思い起こしてみたときに、本書に書かれていることと一致している特性もいくつかありました。

本書を読む前に、これまで属してきた中で強いと感じたチームの共通項について考えてみました。まず共通しているのはポジティブであること。困難を楽しむ姿勢と常に学びを得ようとする姿勢です。人間だから失敗はするものであると割り切り、失敗しても個人に責を負わせず、失敗から得られた知見をもとに失敗をできるだけ起こさないような仕組みを作っていく、あたりが思い浮かびました。本書を読み終えて、自分の認識が間違ってなかったとわかったのはうれしかったです。

「対処」が突出しているチームの場合、困難を繰り返し解決した経験によって「どんな困難が起きても対処できる」「困難が起きてから考えれば良い」といったように、困難に対する自信が醸成されていきます。

大きな問題も必ず解決可能な部分に分解でき、それらを一つずつ解決していけばいずれ大きな問題にも対処できる、過去にそうした成功体験があれば、問題が異なってもプロセスは似たようなものになるはずなので、自信を持って立ち向かえます。

チームレジリエンスの高め方

以下の3つの章で、具体的なチームレジリエンスの高め方について述べています。 - 第3章レジリエントなチームは課題を定めて対処する - 第4章レジリエントなチームは困難から学ぶ - 第5章レジリエントなチームは被害を最小化する

内容が盛り沢山なので、Kindle でマーカーを引いた箇所をすべてここに引用することはできないんですが、いくつか気に留めておきたいと思った事柄を要約して列挙しておきます。

迷ったときに立ち戻れるビジョンが必要
お互いに助け合える仕組みと雰囲気が必要
メンバーを観察し、ストレスレベルを把握しておく
困難から目を背けない姿勢
困難の中にもポジティブ要素を見つけ出す姿勢
振り返りを通して、より良い選択肢がなかったかどうか検討する
振り返りにおいて、前提を疑う習慣を身につける
チーム内の小さな困難の兆候を見逃さない
チームの”持病”を把握しておく
形式知による業務の型化が必要

これらをチーム単位でやらなければならないので、パッと見では、なかなかに大変そうだなぁという感想がまっさきに出てきますが、実際の運用を想像してみると、マネジャーが入念にやるべき部分と、ガイドさえ引けばあとはメンバーが勝手にやってくれそうな部分と両方あるなっていう気もしてくるので、なんとかなりそうとも思います。

私は近年は主にスタートアップで働くことが多いので、わりと変化に強い柔軟な同僚が多い印象がありますが、同時に若い人も多いため、若さゆえの自信の過剰または不足が目に付くこともあります。

これまで一緒に働いてきた人たちはどちらかというととそんなにメンタルが強いタイプは少ない印象で、どちらかというとナイーブな感じの人が多かったですが、ソフトウェアエンジニアの特性として、そういう面はあるのかもしれません。

自分自身を振り返っても、ちょうどいい塩梅の自信具合を手に入れたのは40歳過ぎたあたりでしたし、かといっていまだに自信が揺らぐこともあったりするので、なかなか適度な自信を維持するのは難しいと思いますが、困難から目を背けず、一つずつ着実に解決していくために必要なものという気もするので、自信を持ててなさそうだなって感じたメンバーがいたら、少し過剰なくらいがちょうどいいですよと、アドバイスしたいと思います。

おわりに

冒頭にも書きましたが、「困難と不確実性」はまさにソフトウェア開発の仕事では日常的に付き合っていかなければならないもので、それゆえに困難からの回復力はなくてはならないものと感じています。

また、個人のレジリエンスとチームのレジリエンスは異なるもので、仮にひとりひとりは脆弱であっても、チームで結束して事に当たれば乗り越えられる可能性がある、というのを知れたという点だけでも、豆腐メンタルの私にとっては勇気をもらえた本になりました。

そのためには、いかに共通の目的を持ち、それを実現するためにいかに協力し合えるか、というのが重要だと思います。

いままさにチームビルディングに着手したばかりのタイミングではありますが、この本を座右の書としつつ、困難に遭遇したときには「遠くに行きたければみんなで行け」の精神を忘れずに、何度でも立ち上がる起き上がりこぼしとなれるよう精進していきたい所存です。

2024-07-17 17:10 追記ここから >>>>

もう一つ大事なのは、課題を課題と認識してまず向き合うことで、避け癖のついてるチームは、これを受け入れちゃうっていう問題があって、けっこうこれが難題と感じます。どうせどうにもならないとか、自分にできることはないって思っちゃうと前に進めなくなってしまいます。成功体験がない（少ない）と不安が勝ってしまう部分はあると思うので、軽く背中を押して、うまくいくように、成功体験を積めるように、必要最低限のサポートができるようにしていきたいです。

必要最低限のサポートというのは、対話を通して、どうすればできそうって思えるか、どの部分ならやれそうかっていうのを一つ一つ丁寧に引き出すていどに留める、ということです。

いま自分は業務委託でマネジャーをやっているので、いずれは社員のだれかにバトンタッチするか、あるいは、こうしたピープルマネジメントを自分たちで自律的にやれるようになってもらうかどちらかの状態に持っていきたいと思っているので。

<<<< 追記ここまで