多くの大企業にとって、経営幹部の重要な目標は効率性と有効性を高めることだ。多くの市場で売上高の成長が見込みにくいなか、株主へのリターンを増やす重要な方法は、最終利益を伸ばすこと、つまり生産性を高めることだ。そのためには、次のようなプロセスを改善する必要がある。運営すると、次のようなプロセスを改善する必要がある。変革する。
残念ながら、変革を目的とするプロジェクトチームの生産性を高めるのは難しい場合があり、新技術が関わると特にそうだ。どの企業も、予算が当初の2倍、期間も2倍かかった末に納品されたプロジェクトや、目標を達成できないまま最終的に打ち切られたプロジェクトを経験している。こうした大規模プログラムが失敗する理由はさまざまだが、根本原因の一つとして考えられるのは、プログラムが自らの重みに耐えきれず崩壊することだ。プロジェクトの有効性を高める方法の一つは、取り組むチームの規模を小さくすることだ。つまり、プロジェクトチームを小規模にする時期かもしれない。
小規模チームは動きが速く、より頻繁に改善を重ね、企業により多くの革新をもたらす。少人数のチームが驚くべき成果を上げた例は数え切れない。FacebookがWhatsAppを190億ドルで買収したとき、同社のエンジニア32人は、4億5,000万人が利用するプラットフォームを築いていた。史上最も有名なホットハッチの一つであるフォルクスワーゲン・ゴルフGTIは、8人のチームによって生み出された。大手テクノロジー企業の多くは、10人未満のチームで最初の成功製品を開発した。
ジェフ・ベゾスは、Amazonの創業初期に有名な「2枚のピザルール」を導入した。2枚のピザで食事を賄えないチームは大きすぎる、というのが彼の方針だった。概念としては、小規模チームのほうが効果的になり得る理由は理解しやすい。コミュニケーションが容易で、意思決定もより速く行えるからだ。
では実際に、大規模組織の管理職はこの手法をどう活用できるだろうか。
大きな問題を小さな問題に分ける
時間とともに拡大しがちな大規模組織の進行中プログラムで、2枚のピザで食事を賄える規模のチームをつくるのは特に難しい。大規模な変革施策の範囲を追っていくと、プロジェクトの終わりには、プログラムの目標が当初合意した内容とほとんど似ても似つかないものになっていることがよくある。プログラムとそれを支えるチームが大きくなるほど、この拡大効果は大幅に増幅される。新しいチームメンバーはプログラムに盛り込むべき新たな目標を持ち込む（もちろん、何かが取り除かれることはない）。
プログラムが自然に肥大化するのを抑える方法の一つは、当初からプロジェクトを、小規模チームで解決できる個別の問題に分解することだ。リーダーシップが焦点を定めれば、大規模で複雑な問題も、個別の達成可能な課題に分けられ、小規模チームが容易に取り組み、期待を上回る成果を出せる。
組織そのものを縮小せずに小規模化するもう一つの方法は、事業能力を、重点を絞った組織単位に分けることだ。それぞれに明確な使命を与え、会社に提供するサービスの範囲を定め、内容を明確にして理解しやすくする。そのうえで責任者を置き、仕事を成し遂げる責任と権限を与え、何を達成できるかを見てみよう。
チームに不可欠なメンバーをつくらない
多くの大規模組織では、一つの問題だけに専念できる人はほとんどいない。解決すべき問題とそのチームが増えるにつれて、重要な人材は複数の競合するタスクに分散し、時間は管理しにくい細切れの単位に分けられる。チームの重要なメンバーが、同時にほかの6チームにも所属していると、重要なマイルストーンの達成に必ず影響が出る。その人の予定を押さえるだけでも難しくなる。
変革やトランスフォーメーションのプロジェクトでは、「不可欠な」人材に頼らないよう、積極的にマネジメントすることが重要だ。重要な意思決定を一人に集中させると、チームに単一障害点が生まれる。その結果、プロジェクトやイノベーションの進行が遅くなり、リスクも高まる。小規模チームなら、リスク管理の一環として、より容易に相互訓練を進められる。
一段階で意思決定できるようにする
大規模チームは、ほとんどの意思決定に複数の段階が必要になることで知られる。予定を調整するだけでも時間がかかり、全員が会議室に集まっても（実際には電話会議になることのほうが多いが）、参加者の何人かには状況を説明する必要がある。必要な資料を読んでいない人もいれば、都合がつかなかった重要な意思決定者の代理として送られてきた人もいる（その代理人は上司に相談しなければ重要な決定を下せない）。誰もがこうした会議に出たことがあるだろう。意思決定に至ることはめったになく、たいていは追加の会議につながる。小規模チームなら、こうした問題をはるかに容易に回避できる。意思決定に必要な参加者は少なく、参加者は通常、問題の詳細をよく把握しているため、貢献する前に状況を把握するための会議を開く必要もない。
チームをつくる際は、まず、各メンバーが単独で決められること、チームとして決められること、上位職の判断を仰ぐ必要があることを見極める時間を取ろう。そのうえで、チームに権限と説明責任を持たせる明確な指針を定め、できる限り多くの意思決定をチームに委ねることを徹底しよう。
信頼を築く
チームにとって、信頼ほど大きな力を持つものはない。信頼は進捗を加速させ、品質を高め、実行リスクを減らす。しかし、信頼は自動的に生まれるものではなく、意識して築く必要があることも多い。小規模チームなら、管理職は一人ひとりと過ごす時間を増やし、それぞれの強み、弱み、キャリア目標を知ることができる。チーム本来の強みを生かすようにタスクを組み立てれば、メンバーは自分の能力を示せるようになり、それが信頼につながる。メンバーは、共に問題に取り組み解決するなかで、継続的な交流を通じても信頼を築く。
仕事の外でチームイベントを成功させることも有効だ。ボウリング場やペイントボール場、バスケットボールコートで、あるいはおいしい食事を楽しむだけでも、信頼が築かれることがある。
情報共有をより形式張らないものにする
プレゼンテーションは、複雑な考えを伝えるうえで非常に優れた手段だ。同時に、チームにとっては膨大な時間を費やす作業でもある。チームを小規模にして焦点を絞れば、プレゼンテーションが担う定型的なコミュニケーションの必要性を減らし、なくすこともできる。
小規模で焦点の定まったチームなら、何時間もかけて作成する正式なプレゼンテーションやスライド資料を、問題と解決策をその場で図示するホワイトボードセッションに容易に置き換えられる。チームが同じ場所にいない場合も、Slack、Microsoft Teams、Symphonyなど多くのコラボレーションツールを使って、実物のホワイトボードを代替し、ブレインストーミングをオンラインに移せる。効果は同じで、解決策をより早く導き、チーム内の認識をより一致させられる。
可視性（と説明責任）を高める
大規模チームでは、責任を逃れるのは比較的簡単だ。電話会議に参加しても発言せずに済む。成果物を複数人で担当するため、重い作業をほかの人に任せやすい。準備が必要な重要会議のときに、忙しいふりをすることもできる。メンバーの一部が何をしているのか、誰もよく知らないチームで働いた経験は誰にでもあるだろう。
小規模チームでは、責任を逃れるのはほぼ不可能だ。貢献がなければすぐに気づかれる。前進に貢献しないメンバーは、価値を生み出していないことを示す直接的な証拠があるため、より容易にチームから外せる。
不要な同期型会議を減らす
電話会議を完全になくすことは明らかにできないが、Slackなどのコラボレーションプラットフォーム、インスタントメッセージ、デスクトップでのビデオ会議が広く普及したことで、チームは電話会議に伴うあらゆる固有の課題に縛られず、さまざまな方法でコミュニケーションできる。
小規模チームは、デジタルと対面の複数のチャネルを通じて頻繁に連絡を取り合うため、電話会議を避けられる。大規模チームは交流がはるかに少なく、そのため定期的に集まって目標を再確認し、情報が効果的に共有されているか確かめる必要がある。それでも、電話会議は認識を一致させる手段として比較的効果が低い。
プロジェクトの進捗管理に注力しすぎない
プロジェクトマネジャーは、物事を追跡することに力を注ぐ。タスクの一覧を作り、その進捗を追う。依存関係を特定し、遅れの度合いを把握する。有能なプロジェクトマネジャーは、大規模なプロジェクトチームの潤滑油となり、納期に影響が及びそうなときに摩擦を和らげられる。一方、能力の低いプロジェクトマネジャーは、チームに進捗状況を尋ねて回り、集めた報告をまとめたプレゼンテーションを作ることに日々を費やす。
SlackやJiraなどのツールが広く普及したことで、プラットフォームが追跡を自動化するため、進捗を集約する役割を担う人は急速に不要になりつつある。小規模チームではこの傾向がさらに顕著だ。チーム内のコミュニケーションの密度が高く、どのタスクが遅れているか、軌道に戻すには何をすべきかを全員が把握している。
プロダクトマネジャーは重要だが、プロジェクトマネジャーの有用性は、特にチームが小規模で焦点の定まったものになるにつれて、問い直すべきだ。
ほかのチームとより円滑に協働する
小規模チームが取り組める単位にプログラムを分解すると、互いに依存するチーム間の連携が重要になる。チーム間の摩擦が、依存関係の見落としやスケジュールの遅れにつながることがよくある。
チーム間で「契約」を作成し、それぞれの使命を明確にし、連携方法を詳述し、何をいつ相手に提供してもらえるのかを特定することが重要だ。依存関係を明確かつ簡潔に管理することに注力すれば、透明性が高まり、各チームが割り当てられた具体的な目標の達成に専念できる。
自らの運命を自分で決められる、小規模で権限を与えられた事業チームは、自分たちが担当する領域をより良くするためにテクノロジーをどう活用するかを、より速く見いだすようになる。とりわけ、支援するテクノロジーチームをより直接的に監督できるようにすれば、その効果は大きい。
これを実現するには、テクノロジー提供能力のどの側面を集中化し、どの側面を分散化して、顧客や同僚のために実行するチームに近づけるかを企業が見極める必要がある。革新的なテクノロジーの利用を評価し承認するプロセスも改善が必要だ。大規模組織では、ここが摩擦の原因となることが多い。
機械学習が重要なビジネスツールとして台頭したことは、テクノロジーチームが高度な分析機能を少人数のビジネスユーザーからなるチームに提供しようとしている例だ。実現は容易ではないが、実行チームを支えるテクノロジー提供能力を適切に整えれば、イノベーションが増え、ビジネス目標の達成も加速する。
テクノロジーのモジュール化と柔軟性が進み、組織がアジャイルな提供手法を採用するにつれ、ここで述べた考え方はより一般的になっていくだろう。実行リスクを減らし、イノベーションのペースを上げ、より早く成果を出したいなら、大きなプロジェクトを複数の小規模プロジェクトに分け、チームに取り組ませよう。
