THECLUTURE CODE 最強のチームを作る方法を読んで、エンジニア以前に人間であることを再認識した
今年は1か月に1回ブログを書くと宣言して、既に2月が終わりそうで焦ってます。笑
少し前に続きチームビルディングが自分の中でも課題だったので、タイトルに挙げたこちらの本を読んでみました。
個人的に抱いている課題感を解消するために、何をしていけば良いのか、という視点で参考になる話が多かったのでまとめてみたいと思います。
個人的に抱いていた課題感
目指しの共有ができておらず、議論が活性化しにくい
今期、社内では新しい全社データ基盤を構築するために、大掛かりな引っ越し作業を予定しています。
その上で、まずは引っ越し作業を完遂するために何をするのか？
どういうスケジュールで何をやっていけば良いのか？
等を僕の方で洗い出してみました。
今振り返ってみると、タスクの洗い出しは、チームで議論しながらできれば良かったと思ってます。
しかしながら、チームとして目指しやゴールの共有がふんわりしていました。
(そもそも論、僕自身がそういった内容を共有する、という意識が甘かった)
そのため、一旦タスクとか洗い出して目指しを共有すれば良いかなー、と軽く考えていました。
先週の金曜日に目指しを共有したのですが、順番が逆だったかも、と反省してます。
漠然とした理想像
お互いが目標に向かって、課題を出しあって議論したり、メンバー間で方向を決められる状態を作ること、が漠然とした理想像です。
今の僕はポジションとしてそういう立場にいる訳ではないですが、リーダーという立場を意識せずに仕事をしたいなと思っています。
そのためには、チームメンバーが互いに自走して、考えて、議論して、、という状態を作ることが必要です。
(こうやって書くと受動的な働き方をする人ばかりなのか？という話も出てくると思いますが、現在のチームはむしろ積極的に動いてくれる人の方が多く、頼りになる方が多いです。)
誤解を恐れずに書くと、Howの話は活発に議論するが、As is to beの話はメンバー間ではあまりしない、という感じです。
そもそも論、僕自身メンバーだった際はそうだったなと思い返していて、リーダー的な立場になった途端、こういうことが気になりだしています。。
本の中で良かったところを2点まとめてみます
圧倒的な具体例の多さ
良いチーム、ダメなチーム、ダメだったチームが改善されていくプロセス、世の中の実験を通して読者の予想を裏切ると同時に、なぜこれが上手くいったのか？を言語化してくれる質が圧倒的に高い本だと思います。
印象的なものが多すぎたのですが、そのうち一部を抜粋してみます。
イントロ部分で紹介されていた、スパゲッティとマシュマロを繋げて高い塔を作る実験です。(結構有名な話らしいので、知っている方も多いかもしれない)
ビジネススクール、弁護士、CEOチーム、幼稚園児のグループといった、様々なチームの人が集まった。
この中で優勝したのはどこか？というイントロから始まります。
こういった書き方をすると、結果が予想できてしまうかもしれませんが、優勝したのは幼稚園児チームでした！
なぜ幼稚園児チームが優勝したのか？
他のチームだと、リーダーは誰だ？とかアイディアを批判しても大丈夫か？という「ステータス・マネジメント」の状態になり、余計なことを考えていて非効率です。
幼稚園児チームは、「チーム内の立ち位置」などを気にせず、対等に目の前の課題解決に没頭している。
そのため、リスクを取って挑戦し、失敗から学び、効率的な解決策を見つけられた、という話です。
もちろん、実際の業務は幼稚園児に解決できるような問題ではないだろう、と思われる方もいらっしゃると思います。
ただ、上手くいっているチームは根本的には上記と同じスキルを使っていることが本書では解説されています。
特別なスキルは基本的には必要ない
この本で何度も言及されているのが、強いチームを作るために何か特別な能力は必要ない、という話です。
若干補足すると僕自身はエンジニアなので、課題を解決する際に技術力が足りない、という問題は起こりえると思っています。
その上でエンジニアとしての技術力と、チームとしての力は別物、という前提で話をしていきます。
(むしろチーム開発を行っていく過程で、チームビルディングが重要だと思っているから、この本を読んでいます。)
スキルは大きく3つに分けられる
安全な環境づくり
他のチームビルディング本でも出てきましたが、心理的安全の話がここでも出てきていました。
弱さを見せる
これも心理的安全を生み出し、信頼関係を気付くのに大切な要素として挙げられています。
共通の目標を持つ
物語が共通の価値観や目標を生む仕組み
意思決定のヒューリスティクス
共通の目標を持つ、という部分で具体例として挙げられている粘菌の話をしたいと思います。(僕がもともと理系で生物学が大好きだったのもあります。笑)
粘菌は単細胞生物の集合体ですが、子孫を増やす際は面白い活動を行います。
1. アメーバたちが1つの有機体として活動を始め、中央に集まってくる
2. 一部のアメーバが、上に向かって移動し植物の茎のようなものを形成する
3. 他のアメーバが茎を上り、頂上に着くと胞子に変わる
4. 風に乗って飛んでいき、子孫を増やす
この背景に指示を出す役割の細胞がいると考えられていましたが、実際はそのような細胞は存在しません。
ここで出てくるのがヒューリスティクスです。(かならずしも合理的な根拠がある訳ではないが、多くの人が経験的に有効だと信じている知識)
ヒトは複雑な有機体なので意思決定のプロセスも複雑だと考えがちですが、実際にはシンプルな経験則から判断しています。
そこでチームとしての目標を共有し、大切な態度を言葉で共有しあうことで、多少ルールベースで行動ができるようになる、という手法が紹介されていました。
そんなに機械的にルールで網羅できるのか？という考えもあると思います。
もちろん、キャッチフレーズを暗唱することは目的ではありません。
挑戦や失敗を通して反省し、その学習を通して生まれた「ルール」だからこそ、重みが生まれてきます。
またこれは、習熟が必要な分野においては意味があることも記載されていました。
同じ仕事を高い質を保って繰り返すものは、理想の姿がはっきりしているため、標語化しやすいです。
では、創造的な仕事ではどうするのか？という視点では、チームの自主性を認める、というか書き方に留まっていたのが残念でした。
ただ、これはルール化しにくい、という点では仕方ないのかもしれません。
じゃあどうやったら自主的な活動がし易いか？という視点で、相手の心理を想像しながら仕事をして行ければと思います。
挙げられていたものでは、以下のようなものですね。
・チーム構成や力関係に注意を払うこと
・失敗を恐れない環境を作り、FBを与える
・自主的な行動・挑戦を盛大に祝う
長々と書きましたが、本当に何か特別なスキルが必要か？と言われるとそうではないものばかりです。
終わりに
この本を読んでいると、エンジニアとか社会人とか、そもそもそれ以前に僕たちは人間なんだ、ということを改めて感じさせてくれた本だな、と感じました。
エンジニアとして技術力をつけたい、良いプロダクトを届けたい...
そのためには○○をやらなきゃ、△△も進めないと.. みたいな気持ちになりがちで、歳を重ねるごとにドライになっていく自分がいることを感じさせました。
日々、内省はしていますがコミュニケーションに悩む機会がこれ以上に増えそうです。。笑
心理的安全や弱さを見せる、の部分で触れられているのは圧倒的にコミュニケーションに関してなので。
コロナで在宅ワークが一般的になった今、会議では画面オフになることが多くなりました。(女性はもちろん、化粧が面倒、というのもあると思います。)
その流れに違わず、チーム内も基本画面オフで会議をすることがほとんどです。
この本を読んでから、とりあえず僕は顔を出すことにしてます。
喋る側は画面が真っ暗だと結構不安になるものですが、少なくともメンバーが話している際に僕の顔が見て多少安心感を覚えてもらえば良いかな、という感じです。
別にこれを強要することは難しいと思いますし、変えるつもりもありません。
問題意識を抱いて、変わっていくプロセスを大切にして行ければと思いますし、そもそも論自分が話しすぎることが問題かもなので..
今までの自分からすると、全然やってこなかったことがほとんどなので、意識的に行動を変えていければと思います。
チームビルディングの仮説検証を行って、上手くいったこと、行かなかったことがあれば、機会を見つけてブログに投稿したいですね。
