それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。
そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。
初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。
なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機能を持たせ、どのように配備（デプロイ）するかについても考えなければならない。しかし、そこまで含めると記事が長くなり過ぎる。そのため、それらは次回の記事にまわすことにした。
1. 安定
「安定」したチームは、プロジェクトチームのような一時的に編成されるチームとは真逆のコンセプトに基づくチームだ。いくつものプロジェクトに渡って存続し続ける。チームの顔ぶれも頻繁に変わるようなことがなく、概ね固定のメンバー編成であることが保証されている。つまり、存続期間が長く、かつ、メンバーがほぼ固定されるというのが「安定」と称する理由だ。
チームが安定することで、チームワークが安定する。プロジェクトチームと違い、プロジェクトのたびにチームビルディングをいちから始める必要がないからだ。タックマンモデルで言うところの「機能期（Performing）」を維持することも可能である。
ジェフ・サザーランド（Jeff Sutherland）の著書『スクラム』に、次のような一文がある。
チームが一つにまとまりシンクロし始めると、魔法にかかったようになる。チームがいる部屋に一歩入ればそれを感じる。チームが仕事に取り掛かると見えてくる。スムーズに流れるような動き。チームが一つになることで、個々の集まりを超えた境地に到達した状態だ。
これこそまさに、機能期のチームだ。私も過去に、このようなチームを体験したことがある。
プロダクト開発はチームプレーだ。機能期にあるチームは、まるでスポーツチームであるかのように、それぞれに受け持つポジションがある。互いに連携し、状況に応じてフォーメーションを変えながら、プロダクト開発ゲームを進める。長く一緒に働いているから、チーム内でのそれぞれの役割（チームロール）が自然と形成され、それが上手く噛み合って機能するのである。互いのパーソナリティだけでなく、ハードスキルやソフトスキルも理解し合っているのだ。
その効果のひとつとして、ソフトウェアの内部品質の劣化を抑制しやすくなる点が挙げられる。チームワークによって、コードレビューやペアプロをはじめとするチームでの協働が機能するからだ。もし、保守性を悪化させてしまったら、そこに変更を加えようとする未来の誰かが苦労する。そのコストが開発時間を長引かせ、市場投入までの時間に悪影響を及ぼす。安定したチームならば、チームワークによってこういった問題を軽減することも可能なのだ。
さらに、安定したチームは、計測したベロシティの信頼性も高い。繰り返されるプロジェクトやイテレーションを通して、チーム編成がほぼ一貫しているからだ。ベロシティの信頼性が高まるということは、プロジェクトの予測可能性も高いということだ。
チームとしてのパフォーマンスを高めること。プロジェクトの予測可能性を高めること。チームを安定させる狙いはまさにこれである。
■関連記事
- 組織設計の失敗ケース「共有リソースプール」
- チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する
- "Products not Projects"で比較される2つのモデルが開発チームを特徴づける
- ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう
2. アトミック
チームの「アトミック」性とは、組織内でチームを「個」として扱うことを意味する。仕事の割り当て対象が、個人ではなく、チームであるということだ。チームとして仕事を引き受け、チームとしてアウトプットする。チーム内の関係性はフラットだ。チームが引き受けた仕事を、チーム内で「誰が何を、いつ、どのように行うか」はチーム自身で決める。そこに対してチーム外から口出しすることを禁ずる。
従来のソフトウェアプロジェクトにおける開発業務は、プロジェクトマネージャー（PM）によるオーケストレーション型で進められる。誰が何を、いつ、どのように行うか、それを計画し、実行を指示し、進捗を管理するのはPMである。極端に言えば「すべてはPMが考え、その通りにチームが動く」ということだ。プロジェクト成否の大部分は、PMの手腕にかかっている。それが、オーケストレーション型のプロジェクトマネジメントである。
オーケストレーション型では、チームの自律性が育ちにくい。PMの指示に従い、割り当てられたタスクに集中し、期限内に要求通りのアプトプットを出すことができれば、メンバーとしての責任が果たせる。だから、メンバーはそれぞれ、担当タスク以外のことに注意が向きづらくなってしまう。
アトミック性を持つチームは、チームが引き受けた仕事をどうやって進めるかについて、チーム内で話し合う。そうして分解されたアイテムを誰がやるかは、チーム内の自薦や他薦で決める。チームリーダーであっても、あれこれ指示してはいけない。ここでのリーダーの役割は、メンバーらによるチーム運営をサポートすることだ。
こうすることで、メンバーそれぞれが、ミッションを念頭にチーム思考で動けるようになることを期待している。自分のタスクだけに専念するようなことはしないということだ。
たとえば、チームのカンバンボードにコードレビュータスクが溜まっているとしよう。こんな時、チーム思考があれば、誰かがやることを期待して放置したりしない。仕掛中の担当タスクが終わった人が、別の担当タスクを始める前に、溜まったコードレビュータスクに取り掛かるだろう。このように、チームやプロジェクトを俯瞰して「誰が何を、いつ、どのように行うか」を自分たちで適切に意思決定できるようになることを期待しているのだ。いわゆる「自己管理型」である。
人手が足りない他チームの応援をする場合も、アトミックに対応する。従来のやり方ならば、応援を要請しているチームXに対し、チームYがメンバーを貸し出す方法をとる。チームYから貸し出されたメンバーは、一時的にチームXのメンバーになるのだ。だがアトミックなやり方は違う。自チームから人を貸し出したりはしない。チームXの仕事の一部を、チームYが責任を持って引き受けるのだ。これが、チームの「安定」にもつながる。
この「アトミックチーム（Atomic Teams）」というコンセプトが、私の組織設計の中核になっている。
■関連記事
3. 非兼務
非兼務、つまりは1人のメンバーが複数のチームに所属しないということだ。所属できるチームの数は、原則として、1人あたり1つだけに限定する。
兼務はチームの独立性の阻害要因となることが問題なのだ。チーム間で人を共有するということは、チーム間で競合が発生するということだ。その競合を解消するためには、チーム間での調整が必要になる。チーム単独で計画づくりができない。これが、チームの独立性を阻害するということだ。
たとえば、Aさんが、チームXのメンバーとして3日間かかる仕事を受け持ち、兼務するチームYでも3日間の仕事を受け持っていたとしよう。このどちらを優先すべきか。優先することになった仕事は3日後に完了する。だが、もう一方の仕事は4日めから着手することになるため、完了するのは6日後だ。両方同時に進めたら、ともに6日後以降に完了することになるだろう。いずれにしても、少なくともどちらか一方は、完了日が遅くなる。これをチーム間で話し合うのだ。
仮に、チームXの仕事を優先することになったとする。この仕事の完了が遅延したらどうなるだろう。もちろん、チームYの仕事の着手が遅延し、完了も遅延する。Aさんを接点として、チーム間にクリティカルチェーン（クリティカルパス）が形成されたからだ。チーム間の結合度が高い状態だとも言えるだろう。
問題はこれだけではない。兼務によって、Aさんは、チームXのミーティングにも、チームYのミーティングにも参加しなければならなくなる。両チームがスクラム開発を採用しているとしたら、Aさんは、そのどちらのスクラムイベントにも参加することになる。各チーム内外での細かなやり取りも含め、Aのコミュニケーションコストが倍になっている。つまり、開発時間がそれだけ削られるのだ。
この例では、各チームのスクラムイベントも、実施時間を調整することになる点も見落とせない。どちらのチームも朝10時からデイリースクラムをやろうとすると、Aさんはどちらか一方にしか参加できなくなる。チームXは10時から、チームYは10時15分から、といったように調整するしかない。うんざりだ。そもそもAさんにとっても、朝から2つのデイリースクラムに参加するなんて……
チームにとってもメンバーにとっても、非兼務である方がストレスも少なく、パフォーマンスも発揮しやすいということだ。
■関連記事
4. 少人数
チームが少人数であるべき理由はいくつもある。主たるものは次の5つだ。
1つめの理由は、一人ひとりに主体性や責任感が生まれやすい点。大人数だとどうしても、一部の少数の人だけが頭を働かせ、残りの人達はそれに従うだけでどこか他人事になってしまいがちだ。人数が少なければ少ないほど、チーム全体で主体的に行動せざるを得なくなる。もちろん、チームメンバー全員がフラットな関係性であることが前提だ。そうして自己管理型のチームに近づいていく。
自己管理型チームは、そうでないチームよりも、優れたプロダクトを生み出せる。私はそう考えている。ただ言われたことを実行するのではなく、ミッションを念頭に自分たちで意思決定し、行動することになるからだ。
2つめは、コミュニケーションコストが小さくなること。ミッションを共有する1つのチームとして行動するためには、メンバー間の相互コミュニケーションが欠かせない。一方で、コミュニケーションはコストとしての側面も持つ。チーム内での密なコミュニケーションを実現しつつも、そのコストを最小化するためには、少人数であることが適している。人数が少ないほど、コミュニケーションパスの数が減るからだ。
3つめは、バッチサイズが小さくなる点。バッチサイズとは、1度の開発におけるスコープの大きさだ。チームが小さければ、スコープも小さくせざるを得ない。大きなスコープに対応しようとすると、市場投入までの時間が長くなり過ぎるからだ。アジャイル開発を採用して、イテレーションを短くすることで、さらにバッチサイズは小さくできる。
バッチサイズが小さければ、早く安全に失敗できる。たとえば、プロダクトに対するアイデアを6か月かけて開発し、リリースしたとしよう。その結果、それがビジネスにとってもユーザーにとっても価値を生まなかったらどうなるだろう。6か月の労力が無駄になってしまう。しかし、小さなアイデアを2週間かけて開発してリリースしたなら、失敗してもダメージは小さい。その失敗から学んだことを、次のイテレーションでまた試せば良い。小さいバッチサイズならば、こういったフィードバックサイクルをまわせるのだ。
4つめは、チームの敏捷性が高まる点。変化への適応能力に優れているということだ。これは、上述の3つの理由によって実現されるものだとも言える。
最後の5つめは、マネジメントコストが小さくなることだ。人数が多ければ多いほど、メンバーマネジメントに関するリーダーやマネージャーの負担が大きくなる。その負担が大きければ、マネジメントが行き届かなくなり、チームを崩壊させることにもなりかねない。私が観察してきた限りでは、チームの規模が8名~10名以上になるあたりから、問題が生じやすくなるように感じている。
以上が、少人数チームが優れていると考える主な理由である。
組織をスケールさせるにも、チームの人数を増やすのではなく、このような少人数チームを増やすという考え方が基本だ。チームメンバーを増やすことで組織をスケールさせるアプローチは取りたくない。
私は昔、20名以上のメンバーを抱えるチームを引き継いだことがある。この多人数チームは、正式なチームとしては1つであるが、実態はもっと複雑であった。
まず、数名からなる保守チームというものが内部に構成されていた。この多人数チームで開発したソフトウェアシステムの保守業務のみを担当するチームだ。そして見事に失敗ケース「保守・運用の分離」を踏み抜いていた。彼らは、品質の悪いソフトウェアのおもりにうんざりしながら毎日の業務をこなしていたのだ。当然、保守チームに割り当てられたメンバーのモチベーションは落ちていた。
残りのメンバーはと言うと、開発業務向けの「共有リソースプール」として管理されていた。この多人数チームは常に複数のプロジェクトを抱えていた。その規模も、大小さまざまだ。共有リソースプール化は、この状況に柔軟に対応するための体制だろう。プロジェクトが新しく立ち上がるたびに、そこから数名がプロジェクトにアサインされていた。もちろん、人数面、あるいは能力面で不足するプロジェクトも出てくる。そうなると、プロジェクトの掛け持ちも横行する。
この多人数チームのマネージャーの権限も大きかった。チームメンバーは、マネージャーのコマンド&コントロールで動き、自主性は失われてしまっていた。
このように、多人数チームの実態は、安定もせず、アトミックでもなく、少人数でも非兼務でもないチームだったのだ。人数の多いチームをマネージャーがなんとか機能させようとする中で、このような形になったのだろう。多人数チームを引き継いで私が最初におこなったことが、チームの分割だったことは言うまでもない。
■関連記事
- 組織設計の失敗ケース「共有リソースプール」
- 組織設計の失敗ケース「保守・運用の分離」
- 組織設計の失敗ケース「無力な他己管理型チーム」
- ビジネスインパクトのない新機能に費やす時間とコストを低減する
- バッチサイズ削減はソフトウェアデリバリに何をもたらすか
5. 流動性
チームを安定させなければならないと言っても、若干の流動性は必要だ。時々はメンバーを入れ替えなければならない。チームの顔ぶれを何年ものあいだ固定し続けると、十中八九、ひどい属人化に陥るからだ。
チームにおける属人化の症状は、様々な形であらわれる。例えば、本番稼働で障害が発生した際、緊急対応しているのがいつも同じメンバーであるとか。彼が対応すれば早く解決するから、他の人は遠慮してしまうのだ。そうするうちに、当人と他のメンバーの間の緊急対応に対するスキル差はどんどん広がっていく。
他にも、特定の領域のコードの理解容易性の低下という形であらわれることもある。その領域の変更はいつも同じ人が担当するから、当人だけがコードを理解すれば良く、理解容易性を高める動機がないのだ。そうしてコメントもなく、適切なドキュメントもないコードができあがる。複雑化してしまうこともあるだろう。こうして他のメンバーは、この領域に含まれるコードに手出しができなくなる。
属人化は、メンバーそれぞれに得意分野ができはじめることから生じる。同じチームで長く仕事を続けていると、みんな、いずれかの分野が得意になっていく。得意になれば、その分野の仕事は人から頼られるようになるし、自ら引き受けるようになる。得意な人がやった方が短期間で仕事が完了するし、アウトプットの品質も高くなるから当然だ。だが、それが長く続くと属人化されてしまう。
属人化はチームにパフォーマンスをもたらす代償として、バス係数を悪化させてしまう。属人化した業務を担うメンバーが、チームの単一障害点になると言った方が分かりやすいだろうか。そのメンバーが何らかの理由でその業務を遂行できなくなった時に何が起こるかを考えると明らかだろう。当人が不在になると、属人化した業務が滞ってしまうのだ。
チームに若干の流動性を持たせることで、属人化の進行を緩和できる。チームに新メンバーを受け入れることになれば、オンボーディングが必要になる。そのためには、仕事のやり方が可視化され、言語化されていなければならない。また、既存のメンバーが抜けることになったなら、引き継ぎも必要となる。こういったイベントを半年や、長くても1年に1回程度の頻度で発生させれば、冗長化が進むことが期待できる。
もちろん、流動性を持たせることだけが、属人化に対する唯一の軽減手段ではない。しかし、組織設計としてそういった仕組みを入れておくことも必要だと考えている。
以前は、属人化を許容するスタンスを私はとっていた。個々の得意分野を活かして、存分に能力を発揮して欲しいからだ。冗長化によって組織としての能力を平均化するより、彼らの能力を活かして組織の強みにしようというわけだ。もし、彼らが退職したとしても、その時に対応すれば良いと考えていたし、実際にいつも何とかなった。
しかし困ったことに、これでは人が育たないのだ。得意分野がある人が、毎回その分野の仕事を担うため、それが結果的に他の人の学習機会を奪うことになるからだ。それに、チーム内に属人化した業務を抱えているからといって、当人をずっとチームに固定し続けると、その人の新しいチャレンジの機会を奪うことにもなる。どちらの立場にたっても、人が育たない環境を生み出してしまっているのだ。
そもそもこれでは、「チーム」という単位にこだわって組織づくりを進めているはずの私自身が、パフォーマンス面で個人にばかり目を向けていることになる。これでは一貫性もない。ジェフ・サザーランド（Jeff Sutherland）も書籍『スクラム』で、メンバー個人の力量より、チームの力に目を向けるべきだと述べている。個人のパフォーマンスの違いより、チームのパフォーマンスの違いの方が大きいからだ。
そういうわけで、属人化を許容したパフォーマンスの獲得より、チームパフォーマンスの向上に力を入れたいのである。これは、メンバー個々の得意分野を活かして、存分に能力を発揮することを否定しているわけではない。そうした高い能力を活かしてもらいつつも、他のメンバーにもその能力を継承（スキルトランスファー）し、人を育てられる体制を作りたいのだ。
思ったより長い節になってしまったが、チームの流動性には、もう1つ狙いがある。それは、チームに刺激を与えようという意図だ。
チームを長く安定させると、文化や価値観が固定化されてしまう。そうしてコンフォートゾーンに入り込んでしまう。しかし、外部環境も内部環境も常に変動している。新しいことを学び、チャレンジしなければ、優れたプロダクトをユーザーに提供することなどできない。それに、長くコンフォートゾーンに浸かり続けると、仕事に飽きもくる。
新メンバーがチームに入ることで、その停滞した空気に刺激が加わる。新しい文化や価値観が流入するのだ。そうすれば、チームは再びラーニングゾーンに入り、変化に適応することが可能になるだろう。
■関連記事
6. イテレーティブ
イテレーティブなプロセスは、ソフトウェアプロダクト開発における意思決定を経験主義に基づかせるためには欠かせない。「少人数」の節でも触れたが、これは、早く安全に失敗し、そこから学ぶためのフレームワークなのだ。
我々が身を置くのは、常に不確実性が高く、予測可能性が低い領域だ。時間をかけて深く分析すれば正解が導き出せるなんて、とんだ思い込みであると知るべきだ。そうして進めた結果、あとから「間違っていた」と気づくことが何と多いことか。
それを端的に表す数字が、「アイデアの3分の2は価値がない、あるいは逆に価値を損なわせる」という、マイクロソフトの調査結果だろう。どれだけ自信を持ってリリースした機能であっても、ユーザーから良い反応が得られないことの方が多い。プロダクト開発に携わっていれば、これは誰もが経験することだ。
こういった失敗は、なにもプロダクトや機能といったレベルでのみ生じるわけではない。アーキテクチャや内部設計でも起こり得る。
たとえば、素晴らしい出来栄えだと思ったアーキテクチャや内部設計が、ほとんど役に立たなかった経験は誰にでもあるだろう。むしろ、可能性を予測して作り込みすぎたために、使いもしない内部機能が設計を複雑にしてしまったようなケースだ。
ソフトウェアプロダクト開発は、クネビンフレームワーク（Cynefin framework）で言うところの「複雑（Complex）」な状況を扱う領域なのだ。この領域では、時間をかけて状況を分析してみても、そこから正解を導き出すことが難しい。探索することでようやく状況を把握し、正解らしきものを見つけられるのだ。それに合わせて軌道修正すれば良い。これが、スクラムガイドでも3本柱のうちの2つとして挙げられている、経験主義による「検査」と「適応」だ。
スクラムをはじめとするイテレーティブな開発プロセスモデルを採用しているならイメージしやすいだろう。スプリントの成果をスプリントレビューで検査し、そこでのフィードバックを次回以降のスプリントとして適応させることができる。実際にリリースしてユーザーに使ってもらえば、もっと正確なフィードバックが得られるだろう。
スプリントのたびに得られる経験は、プロダクトに関してのみではない。プロジェクトを通じてチーム活動に関する知見も得られる。そうしてスプリントごとの振り返りで、チームの成長について議論できる。これも、経験主義による検査と適応だ。
アーキテクティングや設計も、はじめから大きく作り込みすぎると、大きく失敗しやすい。いわゆる「BDUF（Big Design Up Front）」だ。ある程度はBDUFも必要だと感じるが、「ENUF（ENough design Up Front）」で必要最小限な設計にとどめつつ、開発のたびに少しずつ進化させたい。テスト駆動開発は、コードレベルでそれを実現する。小さなフィードバックサイクルの中で、少しずつ内部品質を高めながら実装を進めるフレームワークだからだ。
「イテレーティブ」であることは、チームとプロダクトに、正しい進化と成長をもたらすということだ。
とは言え、組織設計の中で定義できることは、ソフトウェア開発プロセスモデルをイテレーティブにすることぐらいだ。それより内側のフィードバックサイクルについては、チームに任せるしかない。
■関連記事
つづく
次回の記事では、これらの原則を満たすチームにどのような機能（業務機能）を持たせるべきかを考える。また、それらを組織内にどのように配備するかについても検討する。
