しくみ製作所代表の車より 今月のつぶやき「チーム作り」

今回は「チーム作りについて」です。 最近、一周回って、このテーマが一番難しいなと感じるようになりました。

私は子供の頃からサッカーをやってきたので、チーム作りは凄く身近にあったのですが、最近色々と制約が多い中でチームアップする機会もあり、改めて大変だなーと感じています。

心理的安全性みたいな話は皆さん耳タコだと思いますので、その辺りの話は割愛して、好き勝手にエッセイ的に書いていこうと思います。

いつもどおり、まずは言葉の定義から考えていきます。

wikipediaで調べてみると、こんな感じに書いています。

定義は色々あるのですが、

が、ポイントかと思います。基本的には、共通の目的があり、それを区切る形で目の前の目標が設置されることが多いと思います。

プロダクト開発作り自体には目的や目標があるPJなので、PJにアサインされたメンバーは結果的に共通の目標を持ったチームになる第一歩を踏み出すことになります。

チームのポイントは、個人の弱いところは打ち消し、強いところを引き出し、チームとして有機的に動き、目標達成の確率を上げることになると思っています。

チームは、置かれた環境や構成人員の条件、各自の成長状況、逆に成長してもらうためのアサインもあり、常に組合せを改善し続ける必要がありますよね。

繊細な組合せの設計をする場合は、個人の弱みや強みを把握し、最適化していく方向で調整する必要があり、1人1人を理解するための密度の濃さが必要になります。結果的に、小さなチームの方がこれらのことはやりやすくなっていき、単位一人あたりの生産性という意味では小さなチームの方が有利になっていくと思います。

これらの補完的なスキルを、チーム全体で明示的に共通認識を作る方法として、役割の概念があります。サッカーでいうポジションに該当し、各自の責任範囲をゆるやかに定めて分担していきます。

ここの範囲がカッチリしすぎると、お互いのFBが減りすぎるので、あくまでも緩やかで少しずつはみ出す方が健全な相互理解やFBが回っていくと思います。

役割については、チーム全体の責任範囲を分割する形で割り当てていきますが、分割方法についても、構成人員の特性を見て切り直す方が、良いなと思う部分が多いです。

アサインだけではなく、アサインする役割自体も要素を因数分解し、その人の特性とピタッと合う役割を再設計することで、極めて高い生産性を産むことができると思っています。

ただ、それは世間で言う一般的な役割とは違う区切り方であることも多いので、特性を見て役割を再構成する必要も求められると思います。各チームレベルで、これらのチューニングは実行されていくべきですし、このような細やかなチューニングを行うことで、強いチームを作っていくことは、チーム作りの醍醐味かもしれないです。

一方で、チームが複数ある場合にチームの平均的なモデルを構成し、そのモデルに合わせて人の方を教育して、はめ込む方法論もあると思います。

もちろん、平均的／理想的なモデルケースを設計し、事業として設計していくことは大切だと思っているのですが、その型自体をチーム外から規格化 = 強制しようと思うと細やかな配慮ができないために、失敗していくケースが多いんじゃないかと思っています。

実際、個人単位で見たときに、認知特性や思考特性があり、向き不向きがあるので、いかにそれを把握して、最適化を行うかはチームにあくまで委譲して、平均的なモデルケースを磨くと良いんじゃないかと思っています。

最近、何が難しいかと感じているかと思うと、チームアップにかかる時間の問題を感じています。

比較的細かく再設計を繰り返すタイプだったので、結構時間がかかってしまうんですよね。

本来時間的ゆとりもあって、コミュニケーションも密に取れると嬉しいんですが、色々な制約で十分にできないことも多く、そうなってくると、いかに効率的にチームアップを行えるか？という話がでてきます。

特に慣習や考え方が違う人達と認識を揃えて、チームアップしていくことを短時間でやろうと思うのがホントに難しく、条件制限下での最適解を作れるほどに、練度が全然上がっていないなと感じます。

逆に言うと、これまで周りの人達にいかに恵まれてきたのかということも最近感じています。

もう一点、難しいなと感じるのは、チームとしてのロバスト性、いわゆるバス係数を上げる行為と、各々が別の勉強をして専門を強化し、チームとしての学習速度をどう取るかのバランスです。それぞのメンバーが補完的なスキル構成で、かつ別のスキルを伸ばしていくチームであれば、全体としては最も学習効率が上がっているのですが、誰か一人欠けたときのダメージが大きいというものですね。

トヨタ生産方式などでは、メンバーに対して多能工化を依頼していて、機械を自働化し、学習する時間をつくり、メンバーのスキルをフルスタック化していく方式を取っています。複数の作業を1人の人ができるようになるので、生産ラインの変更ダンドリに強く、平準化生産型、いわゆるフロー効率を上げる方式に向いていきます。

こういった方法はアジャイルやリーンとなって逆輸入されて、戻ってきているわけなんですが、一方でデザインのような業務まで、エンジニアまでやってくれというのが現実的なのかと言うとムムムと思ってきます。

ちょうど、自分たちは3.5-4.0人を1チームとしようと考えているので、HDDのRAID5構成のように、2人以上に冗長に知識とスキルを蓄積することで、ロバスト性を上げていく設計も面白いかもしれないです。

参考: https://www.guardian-r.com/blog/datarecovery/20190712/3335/

具体的に考えると、スキル構成として、以下のようなスキル構成の4人チームがいれば、1人ダウンしても、他3人で補完できるようになります（机上の空論ではありますが）。

また、相互にFBがしあえると言う点でも価値があるため、因数分解した要素で、組合せとしてマーケット価値が高いものについて、学習してもらうのは、組織にとっても個人にとっても相互に価値が高いかもしれないですね。

とまぁ、人が関わることなので、ここまできちんと動いたりすることはないのですが、モデリング的にもまだまだ色々と考えることがあるテーマだなと感じました。この辺が中々進みにくいのって、一人だとシミュレーションしにくく、具体的な人を巻き込むと時間がかかってしまうからのような気がします。

自分たちの会社では、最近チームの平均サイズを3.5人程度と定めようとしていました。このサイズ感の効用やさらにそのチームを束ねた9人サイズまでの、ライフサイクルなどもシミュレーションしていこうかと思っているところです。開発メンバーにとっては、自分の関わるチームが良い感じかどうかが結構働く上でも重要だと思っています。生産性というだけではなくて、働きやすさ的な意味でも重要なテーマなんじゃないかと思います。

今後、フリーランスの人なんかも増えているので、マーケットとしては急増のチームアップってやっぱり増えて行くとは思うんですよね。いかに効率よくチームアップをしていけるのかは、きっとこれからより重要になっていくんじゃないかと思います。

いずれにせよ人に関わる話なので、モデリングの話はほどほどにして、現場レベルでは落ち着いて相互理解ができる環境を作るのが本質的な解だし、相互理解をするくらいの投資は複利になってすぐ回収できるんだよという心の余裕のあるPJを増やしたいなと思っています。