プロダクト組織の考え方
「ソフトウェアを作る組織は、自身の組織構造そっくりのデザインを世に出してしまう呪縛に囚われる。」
―メルヴィン・コンウェイ（コンピューター科学者）―
これは、ソフトウェア組織に属したことのある人なら一度は聞いたことがあるかもしれない、「コンウェイの法則」だ。より平たく言うと「Shipping the org chart」とも言われ、自社の組織図に沿ってプロダクトを構成し、それをそのまま顧客に押しつけてしまう習性のことを言う。
実は、私が属していたAmazon Adsもその良い例だ。「広告プロダクト」の欄を見て頂くと分かるように、広告主から見たら一体何故こんなに沢山のプロダクトがあり、これらをどう使い分けたらよいのかさっぱり分からない。
数年前から、「これおかしいよね」と理解しながらも、個々のプロダクト（＝チーム）が驚異的なスピードで成長できていたため、社員は概ね目をつぶっていた。しかし、徐々に各プロダクトの成長領域がかち合い、これをクリアせずには前に進めない状態になり、去年から図の左にある広告主の「目標」に基づいたプロダクトへの再構成を進めている。度重なる再編に伴う労力や、疲弊・離脱する社員の姿を見ると、これは大きなツケだったなと改めて感じさせられる。
組織設計は、企業幹部にとって避けられないテーマ。事業が進化する中、結果を出し続けるためには時には大きな変更を決断しなくてはならないが、考えなくてはならない要素が山ほどある。今回は、ソフトウェア組織の設計の仕方について考えてみたい。
バランスすべき3つの要素
結果を出す組織構成を決める際に考える要素は、主に3つある。
責任範囲：機能性、顧客体験、品質、性能、技術的負債における各チームの責任範囲。社員は、「自分は意味のあるスコープを任されている」と感じる時、士気を保つことができる。責任範囲が狭すぎると、事業への貢献が実感できず、「組織の歯車にすぎない」と感じてしまう。また、一般的にはスコープが広い方が士気が上がるが、チームの規模やスキルでは期待を満たせない程広いと、これもまた逆効果。
自律性：チームに解決すべき課題を与える際、彼らが最適だと考える方法で課題を解決できるよう、十分な裁量を与えることが大事だ。チームは解決策を決める前にアイデアの検証や比較を行うことを期待され、経営層は最も顧客に近い彼らを信頼して任せるのが理想的。また、どんな組織構成にしてもチーム間で何等かの依存関係は発生するが、良い組織構成とはそれを最小限に抑えるものであるべきだ。
整合性：各チームの活動が事業戦略とどれ程上手く結びついているかのこと。大きくは、ソフトウェア構造（アーキテクチャ）との整合性と、ビジネスとの整合性の2つ軸がある。
ソフトウェア構造は、プロダクトのビジョンに基づいて作られるのが理想的。そうであれば、その構造に沿ったチーム構成にすると、各チームが意味のある範囲を担当し、重要な決断を下すことができる。しかし、技術的負債があると、チームとソフトウェア構造が一致しないこともあり、複雑な依存関係をクリアしなくてはならなくなる。
ビジネスとの整合性とは、主に顧客の種類に合わせた組織構造のことを指す。ユーザー像、商材カテゴリー、チャネル、地域など様々な分類の仕方がある中で、どのように分解するのが最も会社の戦略と合致するのかを考えなくてはならない。
プラットフォームチームと顧客体験チーム
上記3要素を考慮すると、先ず推奨されるのが、プラットフォームと顧客体験へのチーム分類だ。
プラットフォームチームは、複数の顧客体験チームが必要とする共通のサービスを提供できるため、機能の重複を防ぎ、リソースを最大活用できる。例えば、広告プロダクトであれば、大企業向け、中堅中小企業向けなど異なるプロダクトがあっても、その全てのプロダクトが共通の機能を必要とする（コンソール、キャンペーン保管、オークション運営、効果測定、決済、等）。これらの各機能を担当するプラットフォームチームが存在することで、顧客体験チームは毎度それを作らなくても彼らと連携すればプロダクトを作れるようになる。
顧客体験チームは、アプリやUIを始めとした顧客体験に責任を持つ。彼らの顧客は、プロダクトを直接購入する顧客や、B2Bであれば顧客の従業員であるかもしれないし、時には社内の従業員（例：店舗スタッフ）かもしれない。プラットフォームと同様、顧客体験チームは単一のチームが担当することもあれば、複数のチームに分割される場合もある。原則としては、各チームにできる限り一貫した顧客体験を担当させることで、士気に繋がる責任範囲と自律性を持たせることができる。
顧客体験チームは、事業軸と機能軸のどちらで構成すべき？
次に、顧客体験チームをどう束ねるべきかが大きな課題となる。業界を見渡すと、大きくは①事業軸、②機能軸、③ハイブリッドの3種類が見受けられる。
事業軸モデル：プロダクト及びエンジニアチームは、自律的な事業ユニットに編成される。各ユニットは、事業の成果に紐づくプロダクトを期待する事業部長によって率いられる。
用途：このモデルは、主に会社の最終目標が売上である、あるいはそれに近い時にうまく機能する。例えば、多くの決済・商取引企業（Coinbase、Amazonなど）は、取引量が主要指標となるので、これが直接的にビジネスの売上高を牽引する。各プロダクトがその損益に直接影響を及ぼせるので、これらを各事業部長の管轄に置くと整合が取り易い。
責任範囲：事業部の売上・利益。専任の人員（PM・UX・エンジニア等）の権限を持つ。
メリット：明確な目標と責任範囲、スピード・機動性
デメリット：顧客の包括的な体験や、プロダクト間での相乗効果を重視しづらい。個別最適になりがち
チーム・人材育成への影響：自立性・独立性のあるチームが構成でき、方向転換や資源再配分を機敏に行える。チームのマネージャーや部下無しリーダーは、複数の分野に渡りビジネス責任を負うことで、事業のリーダーとして成長していく
機能軸モデル：エンジニア・PM・デザインがそれぞれ機能別組織に集約され、各機能のリーダー達が事業の成果に繋がるプロダクト指標に共同で責任を負う。
用途：包括的な顧客体験を追求することが、長期的にプロダクトの成長に寄与する時に使われる。例えば、MetaやGoogle Searchは、売上は間接的に広告収入として得ているが、自社にとって外してはならない「北極星」目標はユーザーのエンゲージメント（例：いいね、RT、滞在時間等）だ。この場合は、機能軸でより良いプロダクト作りに集中することが長期的な会社の成長に繋がる。
責任範囲：売上や利益より上流の、プロダクト体験の結果に責任を負う。チーム内の機能専門の人員の権限を持つ。
メリット：顧客の包括的な体験を重視しやすい。また、相乗効果が期待できる新たな体験に踏み込みやすい。
デメリット：複数の機能間で戦略や資源配賦の合意が必要
チーム・人材育成への影響：無駄を省いた組織で全社的な連携を強化し、重複する努力を最小限に抑えることができる。チームのマネージャーや部下無しリーダーは、自身の専門領域を磨くことで、機能のリーダーとして成長していく。
ハイブリッドモデル：その名の通り、事業軸と機能軸の良いとこどりを目指すモデル。聞こえは良いが、機能⇔事業軸の舵取りが求められる。
用途：プロダクト体験と事業のオペレーションの両輪が事業の売上と利益に不可欠な時に用いる。例えば、料理・食品宅配サービスのDoorDashでは、事業部長（GM）がPM・UX・エンジニア部門と連携し、必要なプロダクト体験を作りつつ、日々のオペレーションや販促を推進している。
チーム・人材育成への影響：「良いとこどり」を実現するための、経験豊富かつ強い意思決定プロセスを持つチームを組成する必要がある。社員は、事業軸又は機能軸のどちらの方向への成長も目指すことができる。
目指す組織構成の検討ステップ
以上のように、組織設計は、あらゆる要素を考えなくてはならないため、複雑な取り組みだ。どれ程綿密に考え抜いても、思い通りに機能する保証はなく、試行錯誤が必要となるかもしれない。但し、大きくは以下の3つのステップを踏むことで、最適解に辿り着きやすくなる。
フェーズ1：データ収集と取り組みの範囲の設定
組織を分析し、何のために組織の再設計が必要かを特定する。例えば、事業戦略、重要成功要因、現状の課題を特定し、何が機能し、何が機能していないのかを判断する
今回の組織改編の範囲内で変更可能なこと・そうでないことや、協力が必要な関係者、時間の制約を明確にする
フェーズ2：最適な組織構成の分析と意思決定
事業戦略を推進するための、組織設計基準を作成する
3〜5つの組織設計案を作成し、上記基準に照らして評価する
各案の影響を評価する。例えば、コストとリスク、外部関係者への影響、予期せぬ結果、等
フェーズ3：変更の計画と実施
選択された組織設計の詳細を確定する（現状からの変更点に注目）
関係者とコミュニケーションを取りながら、変更を推進する
新しい組織の有効性を、何を・どのように・いつ測定するか計画する
組織変更時のチェックリスト
ステップ2でどの組織に設計するかを決める際は、大きな決断となるので、以下のようなチェックリストを活用すると良いだろう。
顧客と社内関係者は我々から必要なものを得られるか？
組織設計の基準を考慮し、トレードオフを検討したか？
事業戦略の実現にどう寄与するか？
この組織構造は資源配分と意思決定をどのように効果的に導くか？
事業プロセスとメカニズムは、情報や業務の流れ、顧客のためのイノベーション推進力をどう改善/最適化するか？
人事関連の方針、慣行、システムは組織のミッションと文化を従業員の モチベーション、行動、能力とどのように整合させるか？
変更実施の真のコストとそれに伴うリスクを考慮したか？
実施の一時的なコストはどの程度か？運用コストはどう変化するか? 増加、減少、あるいはほぼ同じか？
プロセスと技術システムの再構築または修正に何が必要か？
現従業員の再訓練や配置転換、新人材の採用・雇用・訓練、新拠点への 拡大、リモート及びバーチャル勤務環境への対応に何が必要か？
この組織設計変更の隠れたコストは何か？
この組織設計に伴うリスクは何か? それらをどう軽減するか？
組織の一部だけでなく、組織全体の有効性を考慮したか？
この組織設計の範囲外の他の組織への影響を考慮したか？
この組織設計変更の意図しない結果の可能性を考慮したか？
以上、組織設計を考える上での参考になれば嬉しい。体験された実例などあれば是非ご共有頂きたい。
