生産性を爆上げするAmazonの「ピザ2枚ルール」は多くの開発現場で形骸化している

Amazonが事業を拡大していくことができたのは、ジェフ・ベゾスCEOが設定した「社内のすべてのチームは2枚のピザを食べるのにピッタリな人数でなければいけない」というルールにあるといわれています。このピザ2枚ルールはソフトウェア開発の現場でしばしば用いられるようになりましたが、少人数チームであるにも関わらず大企業の開発者の多くが「生産性が上がらない」と不満を漏らしているとのこと。ピザ2枚ルールを単純に利用するだけでは意味がないと、開発者であるKislay Vermaさんが指摘しています。

Independence,autonomy,too many small teams | Kislay Verma
https://kislayverma.com/organizations/independence-autonomy-and-too-many-small-teams/

ピザ2枚ルールの根本的なアイデアは「ピザ2枚を分け合える程度の規模のチームが余分な時間を省略でき、最も効率的である」というものです。多くの人が関わる大規模なチームは会議を行ったり計画を立てたりして全体で意思疎通を図る必要性がありますが、能力と決定権を持つ小さなチームであれば、このようなコミュニケーションにかける時間が最小限になり、迅速に動くことができます。

本質的にピザ2枚ルールの重要な点は「ミッション」と「自律性」にあります。この2つがそろっているチームがたくさんあると、それぞれのチームが課題に対してエンドツーエンドで取り組むことが可能です。これこそが「迅速性」を生み出します。

しかし、大企業の場合、チーム1つ1つは小規模であっても、上記のような特徴を持たず、「ピザ2枚ルール」が形骸化しているとのこと。

ピザ2枚ルールが形骸化した理由は、組織作りのどこかの時点で「コミュニケーションを減らす」という視点が失われたことにあると、Vermaさんは考えています。「コミュニケーションを減らす」という観点からいうと、1つの問題解決に携わるチームは1つであるべきですが、この視点が欠けると「1つの問題解決に3つのチームをあてる」という判断になることがあります。

たとえば、1つのチームが全責任を負って課題を解決する場合、チームの目標はビジネスの目標に結び付けられたものになります。しかし課題解決において「データ取り込みチーム」「データ処理チーム」「データ公開チーム」が存在してしまうと、それぞれのチームの目標は、全体のビジネス目標ではなく「タスクを完遂すること」になってしまいます。そしてそれぞれのチームが歯車の1つになることで、報告することが増え、チームの自律性や生産性、モチベーションは失われます。これが大企業の抱える盲点です。

アイデアを練る時にコラボレーションを行うことはさまざまな視点から考えるという点で基本的によいことだとされますが、一方で「アイデアが固まり、実行するフェーズ」でコラボレーションを行うことは非常に高コストとのこと。実行段階でのコラボレーションはチームや個人が自らの仕事に集中できなくし、他人と足並みをそろえることに気を遣わせるようになります。

アムダールの法則では「複数のプロセッサを計算に使った時、プロセッサを追加しても性能が向上しなくなる上限が存在する」とされています。これを開発の現場に当てはめると、課題に並列して取り掛かるチームを追加しても、指数関数的にコミュニケーションが増加し、作業を並列できなくなり、効率性が上がらなくなる上限が存在すると考えられ、ある時点から「人員を追加すると状況が改善するではなく悪化する」ということが発生する可能性すらあり得ます。実際に「1人の開発者が9カ月かかる仕事は、9人の開発者が1カ月でできるわけではない」という言葉はマネージメントの現場ではよく聞かれる、とVermaさん。

上記を踏まえた上で、組織の中でコラボレーションを設定する際には制約条件の理論に基づいて「ボトルネックを広げ、『構想から顧客への提供』までワークフローを広げること」が重要になるとのこと。制約条件の理論とは「どんなシステムも少数の要素からパフォーマンスが制限されている」という仮定から、「制約(ボトルネック)」に焦点を当てて問題解決を行う手法をいいます。ボトルネックを広げた上で、チームによるエンドツーエンドの仕事が必要だというわけです。

ピザ2枚ルールは小規模の会社であれば実行が容易なのですが、規模が大きくなればなるほど難しくなるとVermaさんは語ります。構想から顧客への提供までの作業が分割されていると、それぞれのチームはコミュニケーションとフィードバックを求められ、作業としては独立していても、最終的に商品を顧客に届けるまでの仕事は自律的にはなりえません。そして自律的に仕事ができなければ、永遠にコミュニケーションの要求の中で開発者は束縛されることになってしまうと、Vermaさんは指摘しました。