最高の開発チームをつくってもらうために考えると良さそうなこと

ZOZOのファッションコーディネートアプリWEARについて - WEARで開発責任者をしています @tsuwatch です。この記事は

シリーズ11の23日目です。WEARの開発責任者として、今年はWEARの開発組織、開発プロセスを刷新するということを実施しました。アジャイル、スクラムをどうやるかというのももちろん大切ですが、今回は具体的な開発プロセスというよりも、ソフトウェア開発においてそもそも最高のチームをつくってもらうために、自分はどういうことが、考え方が前提として知っておくと良いのだろうか、何をすべきなのか、どんなことをチームのみんなに知ってもらって、こういう態度で望んでほしいと伝える必要があるのかについて書きました。深堀りすれば、要素要素各論でやらないといけないこと、考えないといけないこと、ベストプラクティスなどはたくさんありますが、そこは割愛しています

チームとグループの違い

「組織行動のマネジメント」より

グループ

メンバーが各自の責任分野内で業務を遂行するのをお互いに助け合う目的で、主として情報を共有し意思決定を下すために互いに交流する集団である。グループでは、能力と努力の重ね合わせを必要とするような集団作業の必要も機会もない。したがって、その業績は個々のメンバーの貢献の総和にすぎない。全体的な業績水準を投入量の総和よりも高くするようなプラスの相乗効果はない

チーム

協調を通じてプラスの相乗効果（シナジー）を生む。個々人の努力は、個々の投入量の総和よりも高い業績水準をもたらす

難しいことを書いていますが、能力と努力の重ね合わせ、協調することでしか得られない効果を生んで、その結果高い業績水準をもたらそうとしていればチームということでしょう。もちろん単純にグループをチームと呼ぶことにしたからといって、自動的に業績が上がるわけではない

具体的に考えてみると、ベロシティが100の集まりがいたとして、提案者がこれを作りますと言って、作る人がただその通りに作ればグループということになる。このグループの成果を基準として、提案者が提案したものに対して、なぜそれをやるのですか？それならばこれは必要ないのではないですか？こうしたほうが良くないですか？と話したうえで作るのがチームである。そう考えると大抵の組織はちゃんとチームでしょう。その結果、提案者が提案したもの以外のものを作る余裕が生まれるかもしないし、同じ工数でもより成果が大きいものを届けることができれば、相乗効果を生んでいると言っていいと思う

ただ難しいのは、そうすることでベロシティが100を下回り、グループで出た成果とそれほど変わらないことや、高くてもコスパが悪いことがあることである。だからといって、グループのほうがいいというわけではないのは当たり前で、その上で良いチームを作っていくことが求められる。ただ組織によって、例えば人数規模とか、会社をまたぐとかであれば、重ね合わせは小さい（大きいほうが良いだろうが限界はある）だろうし、小さなチームであれば大きいほうが望ましい

現状の組織に対して、役割、責任、裁量の範囲などを適切に設計することが求められる

チームの種類

「組織行動のマネジメント」より

問題解決型チーム

問題の原因調査、解決策の提案、修正活動を行う。しかし、提案した解決策の実行に関する最終決定は、通常マネジメントにゆだねられている

自己管理型チーム

解決策を実行し、その結果に全面的な責任を持つことの可能な真に自律的なチーム。上司が従来負っていた責任を引き継ぐ

機能横断型チーム

それぞれ異なる分野業務分野からある1つのタスクを遂行するために集まっている

スクラム開発となると基本的に機能横断型チームとなる。チームトポロジーでいうと「ストリームアラインドチーム」に相当するだろう。問題解決型チームは「イネーブリングチーム」「プラットフォームチーム」に近くて、「コンプリケイテッド・サブシステムチーム」は「ストリームアラインドチーム」の特定部分が抽出された自己管理型チームなのかもしれない。もうここまで来ると言葉遊びのような気もするが、機能横断型チーム（ストリームアラインドチーム）の価値提供をいかに最大化させるかという観点としては参考になるところもあるのかもしれない

例えば、複数のスクラムチームで1つのプロダクトを開発するのであれば、複数スクラム共通の課題や改善などを支援する問題解決型チームがあると良いとか…

プロダクト開発としては、機能横断型チームでいくとして、発生する問題はたくさんある。多様な能力、経験や考え方、関心を持つメンバーから構成されればされるほど、多様性や複雑さへの対処の仕方を学ぶのに非常に時間がかかるし、信頼やチームワークを確立するのにも時間がかかる。これをいかにやるかということになる

程度の差はあれど、方向性としては、チームが良いという前提の上で、機能横断型チームをいかに機能させるかを考えることが大事だろうか

いいチーム

みなさんご存知Googleのre:Workだが、一番大事なことは、崇高なビジョンやミッションなどではなく、心理的安全性であるとなっている。もちろんビジョン、ミッション、組織の明確な目標、やりがいなども絶対必要。それらはこうやって提供すべきだというプラクティスもたくさんあるし、すべきでしょう。ただ多様な人から構成される組織、多様な感情があり、心理的安全性があれば必要なことはすべてあとからついてくるんだろうなというのが僕の感想

アジャイルソフトウェア開発宣言はこの一文から始まる

プロセスやツールよりも個人と対話を

これもすなわち心理的安全性。プラクティスを実践することは大事だが、もっと大事なのは個人であり、対話であるとされている。忘れがちだが、一人ひとりの個人が大切であり、一人ひとりの個人のために対話し、必要なことを適切に必要なだけすることが大切だということだと思う

もう一つおもしろい話がある

wired.jp

性別と社会的感受性は関連しており、心の知能[自分や他者の感情を知覚する能力。「EQ」はその指数]や「会話のバランス」は、集団課題の成績における最も重要な要素になっているとWoolley氏は述べている。

一方、集団課題の成績には、個人の知能が無関係であるだけでなく、集団の団結度もほとんど影響しないことが明らかになったという。さらにはモチベーションや幸福度も同様で、この結果には多くの労働者が当惑することだろう。

「われわれは直感的に、満足度や団結が成績に関連していると考えているが、こうした直感はあまり当たっていない部分があるようだ。しかしだからといって、幸福や団結が悪いというわけではない」とWoolley氏は述べている。

またこれもすなわち心理的安全性。個人の知能もモチベーションも幸福度も影響がないというのも驚きで、もちろん実験内容に依存するところはあるが、とても示唆に富む。特に「会話のバランス」が良いことで集団の成績が上がるのであれば、どんどんやっていくべきでしょう

これほど大事と言われていても、油断すると軽視しがちな気がする。なぜか？それは仕事っぽくないからだろう。高尚な目標を考えているときや、怖い顔をして何かを指摘することのほうがよっぽど仕事をしている感が出るし、評価もされやすいかもしれない。ただ心理的安全性は最優先事項であることは忘れないようにしなければならない

メラビアンの法則というものがある、表情や視線など見た目や仕草による「視覚情報（Visual）」が人に与える影響度は55%、声の大きさや話すスピードなどの「聴覚情報（Vocal）」は38％、会話そのものの内容である「言語情報（Verbal）」は7%というものである。なんと93%はノンバーバルである。これは多くの人が忘れがちな要素の1つで、特にリモートワーク時代で重要なものである。誰か1人が喋ってるときに、聞いている人の顔が無の表情になっていないだろうか？それはとても辛いことでしょう

最近はそのチームは楽しくたこパ、ないしはBBQができるのだろうか？と考えたりもする。たこ焼きに入れる具の趣味は合うのか？焦げてても笑いあえるのか？つくる人、洗う人、役割分担できてる？準備早そうかな？とか。たこパを楽しめないチームは開発は楽しめるのだろうか。サッカーチームとして勝てるチームだろうか？（相手チームも同じぐらい下手だとして）とか…。

役割、責任など

年老いた組織と説明されているが、チームとして機能させるのであれば上のような姿を目指すべきであることは明らかだろう

偉い人についても話しておきたい。偉い人はどこの組織にもいる。組織としては、チームに可能な限り権限を移譲し、自律的に動けるようにすることが生産性を高めるし、その結果成果を出していくことがマネジメントだろう。そのためにステークホルダーとは適切に関われるような設計にしないといけない。そして、当たり前だがそれを関わる人、経営層やマネージャーなど、全員に説明して、理解してもらう必要がある。説明すれば理解はしてもらえるが、この実行がなかなか気合がいる

それぞれの階層でそれぞれの責務で動くことがマネジメントであると思う。経営層が具体的な機能を作ることを指示することは良くない。それを実行するのが正しいとチームのいちメンバーが理解できるように、必要な情報をチームのリーダーやマネージャーなど必要な人に説明し、組織として目標に組み込み、組織を動かすべきだろう。チームはすべての情報を全員で経営層に説明する必要はない。経営層が関心があることだけを特定のメンバーが説明するのが良いだろう

メンバー構成も重要である。まず第一にメンバー個人の能力、もちろん技術的な専門性は重要だし、シニアとジュニアを組ませるというようなことが大切。だがそれだけではなく、パーソナリティも重要である。外向性、人当たりの良さ、誠実さ、安定した感情といった項目の平均レベルが高いチームは、チームの業績に対するマネージャーの評価が高い傾向にあるという研究結果もある。さらに面白いのは平均値よりもばらつきの大きさのほうが大事だということ。1人でも誠実さがかけている人がいると全体に悪影響を及ぼす可能性が高い。腐ったリンゴは何とやらというやつである

また成功するチームは、以下の8つの役割をすべて満たす人材で構成されているとされている

https://www.tmsdi.com/profiles/team-management-profile

優秀なメンバーを集めてもいいチームとはいえない。例えばマネージャーをやってる人だけでチームを組むと優秀そうに見えるが、課題を見つけるばかりで自主的に解決しようとする人がいないかもしれないとかそういうことである

そして重要なのはチームの規模である。スクラム開発でもそうだが、開発以外のあらゆる研究でもチームは小さいほうが良く、10名以下が良いとされている。それは、これまで書いてきたことからもわかるように、多くなればなるほど、コミュニケーションコストが指数関数的に増えていく。能力と努力の重ね合わせ、シナジーを生むことは難しいし、会話のバランスを保つことさえ難しい。全く軽視すべきではない

プロセス

プロセスは非常に大事。もちろんいつもチームを導いてくれるような全員が納得している共通の目的、具体的で測定可能な目標は大事だが、それを生み出しているプロセスの積み上げも大事

自分たちが目標を達成したかどうか大抵の組織はわかるだろうが、いいチームとして成長しているか、積み上げられているか、機能しているか、1+1+1=100に近づいているかというところが評価できているか。それはベロシティで見れるかもしれないし、Four Keysで見れるかもしれないし、SPACEでも見れるかもしれない

ただ、開発プロセスというのは複雑なものでどこがうまくいってるのか、うまくいってないところはどこなのかとても分かりづらい。それを定量化するために、起案〜リリースまでのプロセスを標準化し、それぞれのフェーズを計測可能にして、自分たちのプロセスはうまくいってるのか、改善が続けられてるのかを見ていくことが重要だろうと思う

生産性の話で、コンフリクトの生産性を考えてみる。基本的にコンフリクトが起きることは良いとされている、チームとしてやっていくのであれば説明するまでもなく当たり前である。効果的なチームには適度のコンフリクトが存在している。最高のチームをつくるには、ストーミングの過程が必要である。そうすることで、よりよい意思決定をしていく

コンフリクトというのは、互いに持っている事実と解釈に差分があるのが原因だと思う。みんなの現実は、みんなそれぞれが解釈した世界であり、自分が知っていること、解釈していることは相手は知らないし、解釈も違う。水が入ってるコップの話は有名だろう、水が事実8割入っていたとして、それが多いと思っている人もいれば、少ない2割足りないと思っている人がいるというやつである。これも案外当たり前のことのように思えて、普段忘れ去られている大事なことである。話が通じないときは、お互いにこの情報の非対称性をいかに解消するかが大事で、

構造的に減らす（受容する）
- そもそも組織的に発生させないように、事前に解消
対人的に減らす（受容する）
- すでにある非対称性を日々の密なコミュニケーションで解消

この2軸で考えると良いのではないだろうか。受容すると書いてるのは、誰かが技術的に不可能ですと話したときにそれが本当かを技術を全く知らない人が完全に理解する必要はないですよねということである。優秀なリーダーは、ストーミングを避けようとすることが多い。コンフリクトはパフォーマンスが下がるし、組織間の対立も強くなってしまうからだ。ただ、たくさんコミュニケーションを重ねることでストーミングを乗り越えることは最高のチームをつくるには乗り越えていきたい課題である。「起立、礼、着陸」と先生が言ったとき、生徒は全員無視してはならないし、それもよりも誰かお調子者が1人飛行機ポーズをとったほうがいいし、全員が飛行機ポーズを取ったほうがいいだろうし、もっと言うと全員が違うポーズをとって1回全員で最高のリアクションが何かを話し合って考えたほうが良い *1

また、非生産的なコンフリクトというものももちろん存在する。これはどこから起きるかというとHRTだと考えている。Team Geakの引用だが

謙虚（Humanity）：常に自分を改善していこう
尊敬（Respect) ：一緒に働く人のことを心から思いやろう
信頼（Trust）：自分以外の人は有能。正しいことをする

あらゆる問題はこの欠如から来るとされている。コンフリクトについて考えるときは、これらが欠如していないかを考えることが大事

また、コンフリクトを解消するときにやたらめったに新たにプロセスやルールを構築するべきではない。仕事をした気になってしまうが、柔軟性が失われてしまうこともある。必要なことは対話

話は戻るが、チームが成長しているか、積み上げられているのかということを、これらを総合的に定性的に、定量的に見て、解釈して、何が起きているかわけがわかってることが大事だと思う。この成長が、プロダクトとしての成果に結びついているかも重要である。いかにディスカバリーとデリバリー、正しいものを正しくつくるを考えてプロセスに落とし込み、それが結果、プロセスとしてうまくいってると見れるのか、そうすることでチームが正しい方向に成長していけるはずだと信じている…。