チームをどう組成するべきか？の考察と自組織での実践
今回はどういう基準でグループやチームを組成すべきかについての考察とそれを自組織で実践してみた結果をお伝えしたいと思う。
ジモティーの組織形態
ジモティーでは完全にデバイスによってチームが分かれていた。これは割と普通だと思っていて、実際そういう分け方をしている組織もよく聞くし多いと思う。
初めは僕はiOSチームにいた。人数は4人だった。2週間を1つのスプリントと考えていて、2週間に1回のテストとリリースがあった。テストはチーム全員でとりかかるし、リリース作業はリリースマネージャーが責任を持って行う。リリースマネージャーは輪番制だ。
チーム感があるかないかの肌感でいうと、あった。スプリントの終わりに近づけばリリースマネージャーを起点としてチームメンバーとリリースの対象物についてや、テストの内容、リリーススケジュールなどの連携が行われるからである。各々の開発をブロックせずに滞りなくリリースを終わらせようとする点では共通の目的認識があったように思う。
その後、Webグループに移ったときに感じたのはチーム感のなさだった。
まずWebメンバーの人数は10人を超える。上の図だとWebが9人、インフラが3人となっているが、実際インフラメンバーはWebとの兼務である。インフラ作業は恒常的に発生しているわけではないので2割程度の配分で兼務するといった感じだ。
また、アプリもそうだが、案件に関してはそれぞれディレクターやデザイナーを含めてアサインしメンバー組成している。
Webに関しては、チームのメンバーが何をやっているか？ すら把握しないようなチーム体制になっていた。また、ジモティーでは月次で振り返りを行っていてチーム単位で行ってメンバー同士でFBしあうということをしているのだが、そもそも他メンバーが何をしていたのか分からないので、理解度が低いまま質の低いFBになってしまったり、あるいは質問しまくったり、そもそもFBすることを諦めたりしていた。
こういった状況をみてチームって何だろう？と考えるようになった。
チームとは
アメリカにHarvard Business Review という経営学誌があるのだが、それに連載された「The Discipline of Teams」という投稿がある。
ちなみに、この「The Discipline of Teams」はHarvard Business Reviewの中でも特に評価が高いらしい。
これによるとチームとは
チームとは、共通の目的、達成すべき目標、そのためのアプローチを共有し、連帯責任を果たせる補完的なスキルを備えた少人数の集合体である
「The Discipline of Teams」
と定義されている。
それに対してグループは
個人の集合でその目的は個々の業績水準を底上げすること
とあり、
結果として重要なのは、成果が
・グループの成果は個々のメンバーの総和
・チームの成果は個々のメンバーの総和以上
ということである。
野球を例に例えると、
日ハムの選手が皆「中田翔」であればそのチームは明らかに弱い。
長打力はないが、打率の高いバッターを1〜3番に構えてランナーが複数人いる状態でホームランや長打が発生するから上手く点を稼げるのである。逆に例えばランナーが1塁、2塁の状態で「イチロー」が内野ゴロを転がしても、どんなに「イチロー」の足が早くても別のランナーが3塁で刺されるかもしれない。（その状況であれば「イチロー」ならホームランを狙ってくれるかもしれないが、、）
つまり何が言いたいかというと、足りないところを補完し連携することでシナジーが生まれる。チームの目的はシナジーを出して成果を乗算的に大きくすることにある、ということだ。
この「The Discipline of Teams」に述べられている内容は、個人的にチームの捉え方としては非常にしっくりきた。
チームの詳細設計
チームについての定義とグループとの違いが分かったところでもう少し掘り下げたいと思う。
「The Discipline of Teams」によると、チームには皆が納得できる目的とその達成を測定できる定量的な目標が必要だと述べられている。
例えば、iOSチームでいえば「iOSアプリのプロダクト品質面でのユーザーの不満をなくす」という目的を立てるとすると、「2021年3月までにグロスの平均レビューを4.7にする」といった具合だ。
目標まで決まれば、数値をモニタリングし、課題があれば施策をたて、実行するというようなPDSサイクルが回ってくる。
実際にどう変えたか？
ここまでの知識をもとにしてWebチームをどう変えたか？ つまり実践の部分について述べる。
まず、Webチームが抱える課題を分解して皆に伝えた。なんとなく開発生産性が悪いよね、という認識はあったがどこの部分にどういった課題があるのかの整理ができていなかった。
そして、この課題感に対して下記のざっくりとした解決案を提示した。
・ブリッジングチームを組成し、他部署のやりとり全般やシステム仕様の整理化の役割を担う
・障害対応チームを組成し、障害対応の公平性と対応効率を向上させる
・工数見立てを正確にするために、タスク分解させブリッジングチームのレビューを受けるようにする
・詳細設計のレビューを含めた開発フローを用意し、遵守させることで手戻りを防ぐ。（ブリッジングチームが責任をもつ）
そしてチーム編成の素案まで決めて、中身はチームメンバーと一緒に擦り合わせながら決めた。最終的に決まった障害対応チームの内容を紹介する。（ブリッジングチームも同じような感じである）
◆ 目的
フェアに工数をかけずに障害を対応できるようにする
・ナレッジのログ化による効率化
・チーム化による負荷分散
→ 対応時間のバラツキが少ない、対応総時間が短い ことが重要
◆ 目標（= KPI）
障害対応（障害に関わる作業全て）にかかる総時間と対応時間のばらつきの小ささ
・対応総時間は総稼働時間の5%未満
・対応時間のばらつきの小ささは各メンバーの対応時間の平均偏差が1時間以内
◆ 役割
・障害を対応し、作業のログだけ残す人
・作業ログから精緻に共有知化する人
に分ける。
目的については、障害について対応する人、しない人がはっきり分かれていて、する人が時間を奪われていきフラストレーションが溜まっていく、しない人もする人に対して申し訳ないと思っているみたいな事実があった。なのでチームメンバーでフェアに対応しよう、するように努めようという風に話を固めた。
また効率化については、同じ類の障害を別の人が対応するのに1から調査して対応するみたいなことが発生していたので、対応したら共有知化して効率化を進めよう、とチームで認識を擦り合わせた。
目的が決まれば目標（= KPI）を決めるのは早かった。
これについては数値が妥当かどうかはそこまで重要ではない。やりながらリーダーが調整すればよい。大事なのはモニタリングしてどこにボトルネックがあるのかを分解して解決策を皆で考えてアクションを起こす、といったことだ。
役割についてはシナジーを意識して役割を分担してそれぞれの業務に責任を持たせた。まず、障害対応チームで言えば4,5人のチームメンバー全員が障害に対応してたら明らかに効率が悪い。考察や意見が散発していたら話がまとまらない。
また皆一律で同じことをさせるよりも、役割を分けて専門性を上げることでシナジーを発生させるのが重要である。
ここまで決まればチームは動き出す。障害は担当の人間がメインで対応するようになったし、チーム会でもKPIをもとにどう改善するか？という議論が活発だ。上層部で細部まで決めきらなかったのがポイントだと思っている。
経営陣は、チームの編成とその存在意義、達成すべき課題を明確に示す責任を負う。その一方、チームの目的、具体的な達成目標、チャンスやアプローチについてはチームに任せ、前向きな姿勢を育むための自由度を残しておくべきである。
「The Discipline of Teams」
とはいえ、まだ結論を出すのは早すぎる。様子を見ながらテコ入れして行きたい。
まとめ
チーム作りに関しては
皆が納得できる目的とその達成を測定するための定量的な目標を用意し、メンバー間で足りないところを相互補完しながらうまく連携してシナジーを生み出し圧倒的な成果を出させることが重要。
ジモティーではWebチームにおいてチーム感が感じられず、目標どころか上段の目的すら曖昧だった。
なので、まずは課題を明確にしてメンバーに共有、チームの目的の大枠と編成の素案だけ決めて定量的な目標（= KPI）は皆で決めた。またシナジーを出すために役割分担を決めた。KPIのモニタリングをすることで課題の見える化と改善施策をチームで自主的に出しアクションを取れるようになった。
参考
チームについての考え方をめっちゃ参考にした「The Discipline of Teams」についてはダイヤモンドオンラインのサイトで1章をPDFでまるまる読むことができる。
この内容だけでもかなり参考になった。
この本文中の引用はすべてこちらから行った。
この記事が気に入ったらサポートをしてみませんか？