チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。
機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。
開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこにあると考えています。言い換えれば、組織を構成する個々のチームが可能な限り単独で業務を遂行できるよう、チームの独立性を高める設計を組織構造に組み込むということです。これが、本記事のテーマです。
少人数チームによる緊密なコミュニケーション
チームは少人数が良いと言います。まずはその理由を考えてみます。
自社プロダクトを複数名で開発する人たちは、互いにコミュニケーションを取りながら仕事を進めます。自分1人だけならコミュニケーションは必要ありませんが、2人以上が関わるなら欠かせません。
その理由の1つは、そこで生じる各々のタスクの多くが互いに従属関係を持つことです。先行するタスクが完了しなければ、後続のタスクが始められないという関係です。従属関係にある先行タスクと後続タスクのそれぞれを別々の人が担う時、そこにコミュニケーションが発生します。例えば、コードレビューというタスクを実施するには、先行タスクであるコード実装によって書かれたコードが必要です。これが、従属関係です。そして、コード実装を終わらせた担当者が、その状態を関係者に対して明らかにしなければ、その成果物が別の担当者によってコードレビューされることはありません。
もう1つ、コミュニケーションは、そこに集まる人々が、同じ方向を向いて力を合わせるためにも必要です。プロダクトの開発やプロダクトマネジメントには、開発者にデザイナー、テスター、アーキテクト、プロダクトマネージャー、テクニカルライター、マーケター、営業、カスタマーサポートなど、同じ役割、異なる役割の人たちが集まります。それぞれが目指す先が揃っていなければ、力を合わせることができません。そんな状態で優れたプロダクトを生み出すことは困難でしょう。だから、目的を明確にし、それによって協働意思を高めます。コミュニケーションは、その手段としても用いられます。
このように、緊密なコミュニケーションというものは、優れたパフォーマンスや品質をプロダクト開発にもたらすためには欠くことのできない存在です。
しかし、そこには制約が存在します。1人の人が、双方向で定常的にコミュニケーションするネットワークの大きさには限界があるからです。その人数が数名程度なら狙い通りの効果が期待できるでしょう。互いに信頼関係を築き、日々のコミュニケーションを通して、高いパフォーマンスと品質を実現できるはず。では、数十名程度の規模ならどうでしょうか。あるいは、数百名なら。人数規模が大きくなるほど、各人が何をやっているかを互いに日々把握し続けることが難しくなります。
例えば、メンバー全員が毎日同じ時間に集まって開かれるデイリースタンドアップ（朝会）。メンバーが数名程度のスタートアップ企業や、それに類するチームであれば、短時間で互いの進捗や、抱える課題を共有し合うことができます。それが、事業の拡大に伴い、人数規模が数十名、数百名に増えたらどうなるでしょうか。全員参加によるスタンドアップでのコミュニケーションは、もはや無謀であることは明らかです。順番に情報共有し、全員が発言し終わるのを待つだけで大きな時間を取られます。そこで聞いた話をすべておぼえることもできません。これではもはや、スタンドアップでのコミュニケーションはコストでしかありません。
このように、双方向コミュニケーションを取るべき対象が増えるほど、そのコストが上がって仕事の効率が落ち、やがて破綻を迎えることになります。この状況はしばしば、コミュニケーションパスの多さによって説明されます。2人だけならパスはたった1本ですが、3人になると3本、4人なら6本です。さらに、5人なら10本、6人なら15本というように、パスの数は、人数に対して指数関数的に増えます。このモデルは、コミュニケーションコストを厳密に説明するものではありませんが、人数が増えるほどコミュニケーションコストが高くなることを直感的に理解することができます。
チームメンバーをあまりにも増やし過ぎると、増員によって得た生産力よりも、コミュニケーションコストによって削られる生産力の方が大きくなるということです。たとえば1人あたりの生産力を10だとした場合、2人だと20、3人だと30、4人だと40というように、線形にのびていきます。しかし、コミュニケーションコストは2人だと1、3人だと3、4人だと6というように超線形でのびていきます。こうしていずれは、コミュニケーションコストがチームの生産力を食い尽くしてしまうのです。
コミュニケーションコストがあまりに高くなり過ぎると、個々のメンバーは、チーム全体の状況を把握することを諦め、自分が担当するタスクだけに注意を向けるようになります。この状態で、互いの情報やタスクを淀みなく繋いでいくことは困難でしょう。
チームは少人数が良いとされるのは、こういった背景があったのです。チームの最適な人数としてよく耳にする数は、5名から9名でしょうか。2020年版のスクラムガイドによれば、チームは10名以下が良いとされます。ピザ2枚を分け合える人数が良いとも言われます。ダンバー数を参考にするのも良いかもしれません。フルリモートで活動するチームであれば、オフィスで活動するチームより人数を少なくする方が良いのではないかという実感もあります。リモートの方がコミュニケーション効率が悪い印象があるからです。
こうして少人数チームとなることで、チーム内でのコミュニケーションは、網羅的で密な状態を維持できるようになります。
構造化
少人数であることが優れたパフォーマンスや品質をもたらすと言っても、単純に増員を抑えてしまうと、プロダクト開発のキャパシティがスケールしません。それがビジネス規模拡大の足かせとなっては、元も子もありません。やはり、必要に応じた増員は可能にしておきたいところです。もちろん、労働集約型のビジネスモデルであるべきだと言っているわけではなく、組織内の人員数をビジネス規模拡大の制約にしたくはないということです。
ここで必要な考え方は、チーム内の人数を増やすことではなくチームの数を増やすこと、そして、チーム間での協働をデザインすることです。このような複数チームの相互作用で価値を生み出す集団は、1つの小さなチームという存在から、いくつものチームで構成される構造化された組織に変わります。
一見すると、チームを増やすことで組織内の人員数も増え、結局はコミュニケーションパスが指数関数的に増えてしまうに感じてしまいますが、そうではありません。構造化は、突き詰めると、チーム境界を越えるコミュニケーションパスがなるべく少なく済むよう設計されることになるからです。チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションの必要性を最小限に抑えるということです。その理由を以降の節で見ていきます。
スパゲッティ組織問題
複数のチームで組織を構成しても、チームを横断しながら仕事を進めるフローが、組織内でスパゲッティのようにこんがらがっているなら大問題です。
ソフトウェアプロダクト開発業務における個々の開発は、ユーザーや市場の観察からアイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程では、様々な人によって様々なタスクが実行されていきます。先の例でも挙げた、コード実装やコードレビューも、そういったタスクの1つです。
企画チームXのAさんが、ある機能追加のために、ソフトウェアエンジニアを必要としていたとしましょう。開発チームYのリーダーに相談したところ、Bさん、Cさんの2名をアサインできることになりましたが、これでは期待する期限内に機能追加を完了させられないことは明らかでした。そこで、Aさんはさらに、開発チームZのリーダーに相談し、Dさん、Eさんの2名を追加で獲得しました。
これは、Aさんをプロジェクトマネージャー（PM）とした小規模な「プロジェクト」だと言えるでしょう。企画チームXと開発チームY、開発チームZの3チームのメンバーが関わるプロジェクト体制で、機能追加を進めるのです。
このように、誰かがフローを開始しようとするたびに、こういった小規模プロジェクトを進める体制がアドホックに組織内で編成されるようなら、様々な問題が発生します。
まず、小規模なプロジェクトごとにその遂行体制が乱立していくと、そこに参加することになるメンバーは、プロジェクトを掛け持ちする可能性が高くなるという点です。
プロジェクトにアサインされたメンバーは、コミュニケーションコストによる負荷に苦しみます。プロジェクトを掛け持ちする数に比例して、参加するミーティングも多くなり、コミュニケーションコストがかさむからです。所属する開発チームのデイリースタンドアップだけでなく、掛け持ちするそれぞれのプロジェクトのデイリースタンドアップにも参加することになるかもしれません。それに加え、定期的なもの、不定期のもの、随時的のものなど、プロジェクト内でのコミュニケーションは様々に存在するので、そのコストはなおさらかさみます。
開発チームリーダーは、メンバーそれぞれが、いつからいつまでどのプロジェクトにアサインされているか、人的リソースを管理することに追われます。「チーム」というのは名ばかりで、チームとしての活動実態はなく、ただプロジェクトに人を貸し出すだけの存在（リソースプール）に成り果てています。もし、メンバーらの評価者がチームリーダーであるなら、自身が関わらないチーム外のプロジェクトで活躍するメンバーらを正しく評価することに苦労するでしょう。
そして、このようなプロジェクト体制は、プロジェクトを立ち上げるPMが個人で保有するコミュニケーションネットワークに依存し、それを駆使したものになりやすいように感じます。プロジェクトへの参加メンバーの指名は、PMがお気に入りの相手や、組織内で特に優秀とされる人に集中しがちです。そういった人たちは、他のPMからも人気があるので、スケジュールに空きありません。そういった時は、スケジュールに空きのある人をメンバー追加することになるでしょう。いずれにしても、バランスの悪い体制になりやすいのではないでしょうか。
こうして、組織内には、並走するいくつものプロジェクトそれぞれが描くフローが、まるでスパゲッティのように絡まり合い、繋がり合って存在することになります。効率的な業務とは程遠く、とても煩雑であり、組織内での仕事の透明性を極端に悪くします。これが、業務改善を阻害する要因にもなります。
カプセル化と実行責任/説明責任
組織内部がスパゲッティ化する大きな要因は、組織を構成する「チーム」という単位が、組織コンポーネントとして機能していないことにあります。実態として組織を動かしているのは、乱立する小さなプロジェクトです。それは、機能追加や機能改善といった粒度のアイデアを実現しようとする度にチーム横断で体制が組まれ、そのリリースとともに解散します。そこで一時的に発生するフローが、プロジェクト間で干渉し合い、絡まり合います。
チーム横断のプロジェクト体制自体が悪いわけではありません。新規プロダクトのローンチに向けた体制は、社内から精鋭を集めてプロジェクト化する形が向いているでしょう。リニューアルプロジェクトなんかもそう。何よりこれらのタイプのプロジェクトは、乱発するものではありません。
乱発というほどではない数のプロジェクトが並走するだけなら、既存プロダクトへの機能追加や機能改善を個別にプロジェクト体制で進めても問題ないかと言うと、それもおすすめできません。プロジェクトメンバーが毎回のように異なると、プロダクトの設計に一貫性が失われやすくなるからです。
それでは、プロジェクト単位で体制を構築するのではなく、チーム単位でプロジェクトを遂行するようにしたらどうなるでしょうか。
スパゲッティ組織では、企画チームXのAさんが担当する機能追加プロジェクトに対して、複数の開発チームから人をアサインしていました。これがプロジェクト単位の体制です。これをチーム単位に変えると、1つの開発チームが、チームとして単体でプロジェクトを遂行する方式になります。プロジェクトと言っても、その規模は、単体の機能追加や機能改善といった比較的に小さなものが多いでしょう。同一のプロダクトに対する機能追加や機能改善であれば、リリース日を1点に決めて、チームのキャパシティ的に対応可能な範囲で、複数の機能追加や機能改善をまとめて進めることになります。
チーム単位での開発体制に移行すると、開発プロセスの実行責任は、個別のプロジェクトではなく開発チームに移ります。開発タスクへの分解や、誰がそれらのタスクを担当するかもすべて、チーム内で決定します。それぞれのタスクの進捗状況の把握や遅延時の対応、成果物の品質もチームで責任を持つことになります。
これは、開発プロセスのカプセル化です。企画チームXのAさんはもはや、担当する機能追加や機能改善の開発プロセスをPMとしてマネジメントする必要がなくなったのです。どのようにタスク分解が行われ、誰がタスクを担当するかについて、Aさんが強い関心を持たなくても開発プロセスは進みます。
その結果、Aさんと開発チームのコミュニケーションコストは下がります。もちろん、Aさんと開発チームメンバーとのコミュニケーションが完全に無くなるわけではありません。企画チームのAさんに対し、開発チームメンバーからは仕様の確認や調整が頻繁に入ってくるでしょう。こういったコミュニケーションは必須のものです。無理に削減すべきものではありません。
開発チームにとっても、カプセル化によって開発プロセスがチーム内に閉じることで、プロセス内での仕事の進め方を柔軟に調整できるようになるという恩恵があります。遅延が発生しているフローやタスクをチーム全体でフォローするといったことも可能になるからです。
開発チームは、プロセスの実行責任を持つと同時に、説明責任を果たす義務も生じます。以前は、Aさんがフローを動かしていたので、Aさん自身が全体の状況を把握できる状況にありました。しかし今や、開発プロセスは開発チーム内でカプセル化され、その実行責任はAさんにはありません。つまり、Aさんを含め開発チーム外からは、開発チーム内でのフローの進捗状況が見えづらくなったのです。そのため、開発チームは、自チームが実行する開発プロセスを流れるフローの状況をAさんや関係者らに対して可視化し、説明する責任が生じるのです。
チーム単位で開発プロセスをまわせる組織では、開発チームにアジャイル開発フレームワークを導入しやすくなります。開発チームYがスクラムを採用していたなら、以前は小規模プロジェクトとして扱っていた機能追加や機能改善といった単位を、プロダクトバックログにアイテム（PBI）として追加するようになっているはずです。チームは、スプリント内で扱うPBIを、自分たちのベロシティを基準に複数選択し、スプリントをまわすのです。「スクラムチーム」としてはまだまだ十分ではありませんが、小規模プロジェクトの乱立による、組織内でのフローのスパゲッティ化は抑えられるようになるはずです。
なお、チーム単位での開発体制は、組織設計によってはフローをサイロ化させてしまいます。この問題については、後の節『機能横断型（クロスファンクショナル）』で検討することにします。
学習する組織と改善サイクル
プロダクト開発に関連する活動の主体を、このようにチーム単位とすることで、業務改善をまわすことも可能になります。
その理由の1つは、組織全体でスパゲッティのように絡まり合っていたプロセスが整理され、チームごとに責務が明らかになったことです。実行責任のあるプロセスもチーム内で可視化されたので、チームとしてそのプロセスやフローの改善に取り組むことが可能になりました。
もう1つの理由は、プロセスがカプセル化されたことです。もし、チーム内での改善によってプロセスに加えられた変更が、他チームの業務に影響を及ぼすようなら、その変更の適用のために他チームとの調整を要します。これでは改善のために支払うコストや時間が大きくなってしまいます。しかし、プロセスのカプセル化により、プロセス内部の設計が他チームに影響を及ぼすことが少なくなったのです。
改善とは、知識と経験の積み重ねによる学びによって得られるものです。組織内での活動の単位を常に「チーム」として設計していくと、学びを得るのは個人だけではなく、チームもその器とすることが可能になります。スクラムを導入した開発チームであれば、スプリントごとに実施するレトロスペクティブ（振り返り）がまさにそのための改善の場となるでしょう。スプリントを通してチームが獲得した知識や経験を活用し、プロダクトや開発方法をより良くするアイデアを話し合えるからです。こうして、目標の不確実性と方法の不確実性を継続的に低減していきます。
チームの固定化と非属人化
チームが「学習する器」として機能するためには、その存続期間が短命であってはならないということです。チームが解散すれば、そこに蓄積された知識や経験が失われるからです。もちろん、チームが解散しても、個人としての知識や経験は残りますが、それらを次のチームでそのまま知識・経験とできるわけではありません。新しいチームでは、チームビルディングを新たにいちから始め、それぞれが持ち寄った知識や経験と、新たに獲得する知識や経験を統合しながら、時間をかけてまた成長していくことになるからです。
それでは、固定のメンバーでずっとチームを存続させることが正解かと言うと、そうとも言い切れません。チームの成長が停滞しやすくなるからです。同じメンバーで長いあいだ一緒に働き続けると、内状を客観視できなくなります。習慣化された現状のやり方が当たり前になってしまうので、そこに問題があっても気づきにくくなる。コンフォートゾーンに入ってしまい、チームとしての成長が止まるのです。
属人化も生じやすくなります。チームに新しいメンバーを迎えることがほとんどないため、オンボーディングの機会がほとんどないこともその一因です。各自の仕事のやり方を可視化する必要性がないので、それが個人に閉じてしまいやすいのです。そうするうちに、「この類の仕事は◯◯さんが速い」とか「この分野なら△△さんが詳しい」といった理由で仕事を分担するようになります。やがて、「この類の仕事は◯◯さんしかできない」「この分野は△△さんしか知らない」というように、属人化が完成します。
属人化はチームにパフォーマンスをもたらす側面もありますが、リスクを伴います。属人化した仕事を受け持つメンバーがチームから抜けると、チームが責務とする業務機能の一部が遂行不可能になるからです。属人化はまた、チーム内での業務負荷が偏る原因にもなってしまいます。
チームは長く存続させるべきですが、メンバーは少しずつ入れ替えていくのが良いでしょう。チームに新しい視点と文化を注入するチャンスになるからです。また、チーム内での仕事のやり方や蓄積した知識を可視化し、引き継ぎやすい状況や冗長化を促すきっかけにもなります。こうして、チームに刺激を与え、常にラーニングゾーンに置き続けるのです。
業務機能の凝集
それぞれのチームにとって、自分たちが実行責任を負うプロセスとは、業務上の機能を具象化したものです。それは、組織の事業活動を構成する要素であり、チームごとに責務として分掌されたものです。業務機能の抽出と配置は、構造化における組織設計そのものと言えます。
ソフトウェア設計がそうであるように、組織設計も完璧にはなり得ません。様々なトレードオフを伴います。また、設計者の能力に大きく影響を受けるうえ、そもそもはじめから正解が分かるはずもないので、試行錯誤を繰り返すことになります。それは、ソフトウェアがリファクタリングやリアーキテクティングを繰り返すようなものです。放置したら、少しずつ設計が腐敗していく点も、ソフトウェア設計と似ていると言えるでしょう。
この観点で、チームが責務とする業務機能を眺めてみると、問題が見つかることがあります。あるチームが責務とする業務機能の一部が、別のチームに組み込まれてしまっているようなケースです。プロセスの途中でフローが別チームに移るため、チーム単独での業務機能の遂行が不可能となっているのです。ここに、チーム境界を越えるコミュニケーションパスが構築されることは言うまでもないでしょう。
次の図は、開発チームが責務とするソフトウェア開発という業務機能を実行するための開発プロセスを表したものです。設計・実装タスクを終えたコードが、アーキテクティングチームでレビューされるフローになっています。これは、コードレビューとは名ばかりの承認フローです。おそらく過去に、開発チームのコードの品質が悪すぎて問題になり、シニアエンジニア以上で構成されるアーキテクティングチームがレビューする形になったのでしょう（アーキテクティングチームが存在することの良し悪しは、ここでは議論しません）。
このような組織設計は、問題の解決策として十分理解できますが、そのために、チーム境界を越えるコミュニケーションパスが必要となる点がデメリットです。おそらくアーキテクティングチームには、コードレビュー依頼がひっきりなしに届いているはずです。その数もさることながら、アーキテクティングチームのメンバーにとって、他チームが書いたコードを理解すること自体がレビューの難易度を高めます。どんな目的で書かれたコードであるかを知らないからです。それを知るためには、開発チームに説明してもらうしかありません。このコミュニケーションコストも相当なものになるでしょう。
だったら、アーキテクティングチームを解体して、開発チームにアーキテクトを所属させれば良いと思うかもしれません。しかし、組織内に複数の開発チームが存在する場合、すべてのチームにアーキテクトを配置できるほど人材は豊富ではないでしょう。だからと言って、1人のアーキテクトが複数のチームを掛け持ちすると、後の節で述べる兼務問題が生じます。各チームに1人のアーキテクトを配置できたとしても、チーム内のすべてのコードレビューを1人で担うのは荷が重く、ボトルネックになりかねません。
組織設計にはいつも、このような現実問題が立ちはだかります。その中で、品質とスピードが上手くバランスする解決策を探求し続けるしかありません。本ケースの解決策としては、ペアプログラミングの導入を選択したことにしましょう。コードレビューを開発チームの責務に戻し、設計・実装タスクとコードレビュータスクを2人1組のペアで進めることで、品質とスピードのバランスを取ろうという試みです。これで、ソフトウェア開発という業務機能が、開発チーム内で閉じたプロセスになりました。
ここでの例のように、チームに欠けていた責務の一部を他チームから移管して統合することで、業務機能の凝集度が高まり、他チームとの結合点を減らしたり、結合度合いを弱める効果が得られます。すなわち、チーム境界を越えたコミュニケーションパスを減らせるのです。逆に、自チームの業務機能との関連性の薄いコードレビューを手放したアーキテクティングチームも、チームの業務機能の凝集度が高まったと言えます。
業務機能の凝集度を高める効果としてはもう1つ、業務改善のコストを下げることが挙げられます。業務機能がチーム内で閉じるので、業務改善によるプロセスなどの変更が、他チームに影響することが減り、その調整コストを下げてくれるのです。
先のケースで言えば、機能追加・改善に伴うドキュメントのメンテナンスを開発プロセスに乗せることになったとします。ドキュメントが整備されないことが、開発チーム内で課題だったのです。そのため、設計・実装タスクの中で、その内容に応じたドキュメントの追記・変更を行うことにしました。コードレビューでは、コードと共に、ドキュメントもレビューします。
さて、コードレビューをアーキテクティングチームで実施していたならば、この業務改善を受け入れてもらえるでしょうか。「ドキュメントまではレビューできない」と断られてしまうかもしれません。これでは、コードはアーキテクティングチームでレビューし、ドキュメントは開発チームでレビューすることになりそうです。このようなプロセスで、コードとドキュメントの整合性が取れるのでしょうか。
凝集後のプロセスであれば、こういったことは生じ難くなるでしょう。
担当領域の分割とオーナーシップ
1つのプロダクトを扱う組織が、内部に2つの開発チームを持つ場合、その組織設計は2通り考えられます。そのどちらを選択するかで、チーム境界を越えるパスの数が大きく異なります。
1つめの組織設計では、それぞれの開発チームの責務を、技術的な専門分野を軸に分担します。フロントエンド開発とバックエンド開発で分担させるようなケースがこれにあたります。粒度の細かい機能別組織とも言えそうです。もし、組織が扱うプロダクトが2つであったとしても、それぞれのチームは両方のプロダクトを担当するようなケースもよく見ます。このような設計は、チームの専門性をより高められる点がメリットでしょう。
技術的専門性でチームを編成する組織の欠点は、チームの独立性が落ちることにあります。フロントエンド開発とバックエンド開発でチームが分割されていると、1件の機能追加を進めるにしても、両チームが協調して開発を進めなければ機能が完成しません。その調整や合意によるコミュニケーションに時間を取られる上に、両チームの状況を加味して引きのばされたスケジュールによって、リードタイムが悪化します。
それでは、フロントエンド開発とバックエンド開発の両方の責務を持つ開発チームを2つ編成するならどうでしょうか。これなら、1つの開発チームだけで、機能追加を完了させられそうです。
しかし、1つのプロダクトに対し、2つの開発チームが並行して開発を進めると、互いの開発が干渉し合うこともありえます。そうなると、またしても調整と合意にコストを支払うことになります。
干渉し合うことをなるべく避けるなら、プロダクトが扱う領域をいくつかに分け、そのオーナーたる開発チームを決めておく方法が考えられます。扱うプロダクトがEコマースであるなら、購買者向けの領域と、販売者向けの領域で分けるといったことが考えられます。干渉し合うことを完全に回避することはできませんが、その頻度や程度は軽減することができます。
技術面ではなく、プロダクトの側面から見た領域でチームの責務を分担すると、チームは自分たちが何を作っているのかをよりユーザー視点で理解するようになります。そして、担当領域にオーナーシップを持つようになります。それが、プロダクトの品質として反映されていくことが期待できるのではないでしょうか。
機能横断型（クロスファンクショナル）
スクラムガイドによれば、スクラムチームは機能横断型です。プロダクトに関するアイデアを形にして価値に変えるまでのフローを、チーム単独でカバーできる範囲が広いということです。その範囲が広いほど、他チームに頼ることなくプロダクト開発を独立して進められる可能性が高まるため、効率よくフローを進められます。
逆に、分業化/サイロ化が進んだ組織では、フロー効率が落ちるだけでなく、目的意識が低下しやすいのではないでしょうか。特に、フローの中でもより後ろに位置するプロセスを担うチームほど、目的意識の低下は顕著になるように感じます。企画チーム、開発チーム、運用チームの3つに分業し、この順序でフローが進んでいくのなら、開発チームの目的意識は低くなり、運用チームはさらに低くなるということです。
その理由は、より後続のプロセスを担うチームほど、ユーザーや顧客から遠ざかるからだと考えています。プロダクト開発のフローは、ユーザーや市場の観察からアイデアを生み出すところから始まります。このプロセスに関わったチームは当然ながら、アイデアの背景や目的を熟知しています。その情報や知識が、フローが進み、チーム境界を越えてプロセスを渡り歩くほど薄れていくのです。
開発チームはただ、企画チームに依頼されたものを開発しているだけになります。それが、どんなユーザーの、どんな課題を解決するものなのか、十分な情報を持ち合わせていません。この状況に不満を抱く開発者もいるでしょうが、フローを通して次から次へと押し寄せる開発依頼に日々追われるばかりです。そのためか、計画どおり、要求どおりに作り上げることが、開発チームのゴールになってしまいます。もはや、それがユーザーに十分な価値を提供できるか否かは興味の対象外です。
運用チームは、開発チームから渡された新バージョンのソフトウェアを安全にリリースすることだけが関心事になります。システムの安定のためには、リリースの頻度を減らして欲しいとさえ考えているかもしれません。自分たちが運用を担当する様々なコンポーネントが、それぞれどんな役割を担っているかも詳しく知らないということだってありえるでしょう。
それでは、企画チームが責務を持つプロダクト企画関連の一部の業務機能と、運用チームの責務であるシステム運用関連の一部の業務機能を、開発チームの責務に追加したらどうなるでしょうか。開発チームを機能横断型に変えるわけです。
まず、このケースで企画チームの業務機能から開発チームが得たのは、明確なプロダクトオーナーです。
スクラム開発を導入していた開発チームは、これまでも企画チームのリーダーをプロダクトオーナーと見立てていましたが、実際にはこの仮想プロダクトオーナーと開発チームが直接会話する機会は多くありませんでした。企画チームの活動は、開発チームのスクラムとは関係なく、企画チーム内のプロセスやサイクルでまわっていたからです。両者の接点は、先行プロセスを受け持つ企画チームに所属するメンバーそれぞれから、後続プロセスを受け持つ開発チームに対して見積りが依頼されるところから始まっていました。見積り依頼を受けた開発チームは、それをプロダクトバックログに登録します。PBIに付けられる優先順位は、企画メンバーが企画チーム内で決定したリリース日によって決まりました。
企画チームのAさんが専任のプロダクトオーナーになったことで、この状況は変わります。Aさんは、企画チームに籍を置きつつも、プロダクトオーナーとして開発チームと同じサイクルで活動するようになったのです。また、企画チームに所属するデザイナーがひとり、開発チームに専属でつくことになりました。開発チームはこれで、形として、よりスクラムチームっぽくなったわけです。
プロダクト全体の方向性の検討や、大きなアイデアの創出は、変わらず企画チームが担っていましたが、それはプロダクトオーナーであるAさんと話し合われた上で、プロダクトバックログに追加されるようになりました。そのようにして追加されたアイテムは、比較的に粒度が大きいので、スクラムチーム内でリファインメントが行われます。チーム内から声のあがった改善案なども、プロダクトバックログに追加されるようになりました。
次に開発チームは、自らが開発したソフトウェアのリリースと運用を担うようになりました。インフラの運用やプラットフォームの提供は、引き続き運用チームが担います。開発チームは、そこで用意された環境にアプリケーションをデプロイし、システムの稼働状況をモニタリングし、アラート対応を担当するようになったのです。
このようにして、開発チームを拡張した機能横断型のチームは、プロダクトに関するアイデアを形にして価値に変えるまでのフローを、チーム単独でカバーできる範囲が広がります。そこで必要とされる業務機能とスキルは、すべてチームが所有しています。チーム内を網羅的に結ぶコミュニケーションパスによって、互いのタスクは淀みなく繋がるようになりました。
マルチスキル化
機能横断型のチームは、責務とする業務機能が多岐にわたります。前節のケースのように、開発チームの責務はソフトウェア開発だけでなく、システムのデプロイや運用もチーム単独でこなし、企画に関連する一部の業務機能も担います。
ソフトウェア開発のスキルだけでは、これらの業務機能を遂行することが不可能であるため、スキルを獲得する必要性がチームに生じます。
必要とされるスキルのすべてを保有していればならないと言っても、それはあくまでも「チームとして」です。個人が多くのスキルを身につけている「マルチスキル」であることに越したことはありませんが、必ずしもそれが求められているわけではありません。先のケースでは、マルチスキルではなく、企画チームのメンバーが開発チームに加わることでスキルを獲得しています。
とは言え、チームがフローをどこまで広くカバーできるかは、少人数という制約の中で、チームがどれだけ機能横断型になれるかにかかっています。
各人が、自身の専門分野だけを担当するシングルスキルであろうとするチームでは、チーム編成が困難になります。7人が最適なチームメンバー数だとする場合、ソフトウェア開発スキルを持つメンバーが5人いると、他のスキルを有するメンバーが入れる枠は2つしかありません。2つで足りないからといって、ソフトウェア開発スキルの枠を減らすと、今度はソフトウェア開発業務のパフォーマンスやキャパシティが低下するかもしれません。
それぞれが専門分野のシングルスキルに固執しすぎると、自身の専門分野のタスクがない間、その人は何もやることが無くなってしまいます。手持ち無沙汰になったらきっと、優先順位の低いタスクをやり始めてしまうでしょう。あるいは、手持ちのタスクの品質を必要以上に高めることに時間を費やすかもしれません。それではチームとして高いパフォーマンスが出せません。
専門分野以外のタスクであっても、チーム内で優先順位の高いタスクであれば、自ら積極的に関わっていくようなメンバーが揃ったチームでありたいところです。それを続けていくことで、1人1人がマルチスキルに近づいていきます。
ただしこれはトレードオフ的な側面もあります。十分なスキルを持たないメンバーが専門外のタスクを担当することで、アウトプットの品質が低くなる可能性があるからです。チームに十分なスキルが揃えられないならば、機能横断型チームとしての範囲を無理に広げすぎる必要はないでしょう。
兼務問題
他チームとの兼務者がチーム内にいると、そのメンバーが、チームの独立性を阻害する要因になり得ます。兼務者のスケジュールを介して、チーム間での調整が生じやすいからです。
2つのチームを兼務する人に対し、それぞれのチームが共に、10日かかる仕事を任せたいとします。この時、兼務者のスケジューリングには2通りが考えられます。ひとつは、一方のチームの仕事を10日かけて終わらせた後に、もう一方の仕事を10日かけて終わらせる方法。この場合、後にまわされたチームの仕事は、20日後に終了することになります。これは、期待するより10日遅い終了を意味するかもしれません。もうひとつの方法は、両チームの仕事をマルチタスクで進めること。この場合、両方の仕事が20日目以降に終わることになります。
これが、チームの独立性を阻害するということです。いずれの方法でも、少なくともどちらか一方の仕事は10日後に終わらせることが期待できず、この問題を両チームで話し合わなければならないからです。チーム内の仕事のスケジュールをチーム単独で決めることができないのです。
また、兼務者にとっても、コミュニケーションコストが高くなるという負荷が生じます。ミーティングというものは大抵、チームやプロジェクト単位で定期的に開かれます。そのため、兼務するチーム数に比例して、参加するミーティングが増えてしまいます。その分だけ、実務時間が削られるということです。
このような理由から、できるかぎり兼務を避けることが、組織のパフォーマンスに有利に働くと考えられます。
しかし、兼務が組織のパフォーマンスを阻害しないケースもあります。先の機能横断型チームの例として、プロダクトオーナーであるAさんが、企画チームとスクラムチームを兼務したケースがそれにあたります。
Aさんは、企画チームとスクラムチームを兼務していますが、それはあくまでもスクラムチームのプロダクトオーナーとしての役割を果たしやすくするためです。1つの役割の遂行のために、複数のチームに籍を置いているに過ぎません。これであれば、チーム間でのスケジュールの衝突は発生しません。参加するミーティングの数は増える可能性がありますが、それもプロダクトオーナーの役割としての参加である側面が強いでしょう。
Aさんの企画チーム所属は、評価ラインを考慮した結果であるとも考えられます。企画職であるAさんの評価者は、同じ企画職である企画チームリーダーが担うという考え方です。
また、企画チームは、企画職のコミュニティ的な側面も持ち合わせています。同じ企画職であるAさんは、企画チームに所属することで、企画職としての知識やスキルをより効率よく高める機会を多く得ることができます。
チーム・組織設計の重要性
単一の少人数チームだけでは収まりきらない規模のプロダクトを扱う組織をどう設計するか。その良し悪しが、組織のパフォーマンスに大きく影響します。優れた設計であるほど、組織のコミュニケーション量は、多すぎず、少なすぎず、最適にバランスします。また、それぞれのチームは担当領域において深いドメイン知識を獲得するだけでなく、強いオーナーシップを持つに至ります。スクラムで重視されるような自己管理や自己組織化は、これらを基礎として育まれていくのではないでしょうか。
そして、組織とコミュニケーションを語る上ではやはり、コンウェイの法則を忘れるわけにはいきません。
（広義での）システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すという制約を受ける。
組織設計は、ソフトウェアプロダクトの内部品質にも強い影響を及ぼすということです。
したがって、チーム・組織の設計は、プロダクト設計と同様、あるいはそれ以上に、重視すべき対象なのだと言えるのではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？