BT

チームのスケールアップによる効果的な組織拡大

作者: Ben Linders , 翻訳者 吉田 英人 投稿日 2016年9月29日 |

原文(投稿日:2016/08/11)へのリンク

組織が急成長している時には,正しい判断が困難になることがある。多くの人を雇い,多くのことを行なう中で,本当に達成したいことが分からなくなるのだ。issuuのエンジニアリング担当副社長であるAlexander Grosse氏がSpark the Change London 2016で,チームのスケールアップによって効果的な組織を構築する方法について講演した。講演の中で氏が取り上げたのは,チーム拡大の5つのドメインと氏が呼ぶもの — 雇用,人の管理,組織,文化,コミュニケーションだ。

Grosse氏がSoundCloudのエンジニアリング担当副社長を務めていた頃,同社は急速に成長し始めていた。1年間で従業員数が3倍になったこともある。このような状況に伴って,頻繁過ぎる会議,重点の欠如や混乱,将来に関する不確実性といった問題が発生した。企業運営を拡大する方法と,企業の成長を支援し,急成長によって生じた問題に対処するためのアプローチが,当時の同社には必要だったのだ。

スケールアップとは単にサイズ的な拡大ではない — 目標はチームのアウトプットを高め,より多くの価値を提供することにある。リーダは製品の開発からチームの開発へと重点を移すべきだ,成長に伴ってアウトプット拡大を実現する上で,チームが経験し成長する方法を探る必要がある,と氏は言う。

スケールアップ計画を用いた積極的アプローチは,組織が急成長する段階では必ずしも有効ではない。拡大するチームには,早期警戒システムを備えた反応型のアプローチも必要だ。例えば,機能提供に必要な時間が長くなっているのであれば,それは警告サインのひとつかも知れない。

人の雇用はすべての基礎である。その失敗モードは不適切な人々の過剰かつ拙速な採用だ,と氏は言う。忘れられがちなのは雇用のプロセスである。数ある雇用プロセスを使って独自の雇用プロセスを定義すればよい,というのが氏の意見だ。そこで必要なのは新人研修への投資である。企業が何を行なっているかを説明し,新たな採用者を同僚に馴染ませなくてはならない。

新人研修は普通,入社当初に簡単に行なわれる — 簡単な紹介の後は,仕事をしながら覚えるという考え方だ。次のステップでは,新人を既存のチーム内でローテーションして,会社内のさまざまな仕事について知ってもらう。しかしこの方法では,チーム数が多くなればすぐに立ち行かなくなる。本当の研修プログラムを用意することが必要だ。

大規模化した組織の人員管理で難しいのは,既存のものを損なわずに管理レイヤを導入することだ,とGrosse氏は指摘する。外部から新たなマネージャを採用することについて氏は,“経験が多いほど,企業に多くのダメージを与える可能性がある”点を警告する。社内で実績のある人を抜擢する方がはるかに望ましく,外部からの採用は注意した方がよい,というのが氏自身の経験による提案だ。それと同時に,社員との1対1の時間を十分に確保することも必要となる。

文化的な観点から見た失敗モードは,スケールアップによって“我々 vs 彼ら”という構図が生じることだ。これはコラボレーションの妨げとなる。氏が提案する解決策は,基本理念(core value)の定義である。何が重要なのかを,全員が確実に理解することだ。

マネジメントは,その基本理念を実践するものでなければならない。例えば基本理念が“不断の進歩”であって,マネジメントチームがレトロスペクティブやポストモーテム(post mortem)を実践していなければ,基本理念を実践しているとは言えない。

組織が成長するにつれて,あまりにも多いEメールや会議のためにコミュニケーションが難しくなるとGrosse氏は指摘する。コミュニケーションニーズの増大が組織に与える影響を考慮する必要がある。適切なチーム編成を行なってコミュニケーションを好転させるだけでなく,“EメールはX営業時間内に確認すること”というようなコミュニケーションポリシーの設定も非常に有効だ。これによってコミュニケーションチャネルを正しく使うと同時に,自分の席に誰かが来て,“5分前にメールを送ったのにまだ返事がない”と言われるような状況を回避することができる。

スケールアップ時の組織に関する失敗モードとして氏があげたのは,コミュニケーションのオーバーヘッドとチームの相互依存によってプロジェクトが行き詰まるような状況だ。コミュニケーションとコーディネーションを低減する方策を見つけ出す必要がある。

InfoQの“ Growing Agile… Not Scaling”という記事では,筆者のAndrea Tomasini,Dhaval Panchal両氏が,組織全体に対するアジャイル原則の適用にはコミュニケーションと作業のコーディネーションの大幅な変更が必要だ,という主張を展開している。

市場へのタイムリな価値提供を実現するためには,業務遂行上のオーバーヘッドだけでなく,業務間の調整や連携による無駄も最小限にすることが必要です。この理由から,大部分のアジャイルチームは,自らをクロスファンクショナルでエンドツーエンドなチームに組織しようとします。同じことを企業レベルでも行なわなくてはなりません。これが既存の組織構造やパワープレイに大きく影響し,調和や同調,意思疎通といった組織のあり方を,これまでよりも集中的で,価値を主体としたアプローチへと根本的に変えていくのです。

Grosse氏は,Daniel Pink氏の著書 “Drive (邦題:モチベーション 3.0)”を引き合いに出しながら,チームを拡大する上で,次のような組織設計の原則を適用すべきだと主張する。

経験則として,バックログ項目の大部分(~95%)を他のチームに依存せずに提供可能なデリバリチーム(Delivery Team)は,完全に自己完結型(self-sufficient)であると言えます。

チームに自らの行動を任せて,彼らの仕事が会社に与える影響を確認しよう,マネジメントに必要なのは彼らに自律性を与えることだ,とGrosse氏は言う。チームの作業時間の少なくとも50%は機能開発や技術的負債の低減など,チーム自身が必要と考える自律的作業のために確保することが必要だ。

Suzie Prince氏は“The Right Way to Scale Agile”の中で,チームが自律性を必要とする理由を次のように述べている。

アジリティを促進するためには,チームは自律的で,作業を自分自身で所有する必要があります。つまり彼ら自身でプロセスを開発し,調査し,適用することが可能でなければなりません。ベストプラクティスを自ら学び,プロセスを継続的に開発することによって,組織に対する最高の貢献が現実のものになるのです。

チームが自己完結していて,ある程度の自律性を備えていれば,企業の成功のためにどのような貢献ができるのか,自分たちの仕事の重点を決定する上で目指すべき目標は何かといったことは,おのずと明らかになっていくはずだ。

急速な成長に直面したチームがスケールアップする上で必要なのは,基本的なことを正しく行なう能力だ,とGrosse氏は主張する。スケールアップの失敗モードを可能な限り早く検出するためには,早期警戒システムを設計して測定を行なう必要がある。何に対処するべきかを,そのシステムが教えてくれるはずだ。後はその問題に打ち込み,根本原因を突き止めて,適切な行動を取ればよい。

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
サイト全般について
バグ
広告
記事
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com and 株式会社豆蔵 InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.
プライバシー
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.