# 第5章 生産性を高めるチームビルディング――「サーバントリーダーシップ」とは何か（後半・part2から続く） ※第5章の前半は `part2-ch05-team-building.md`。このノートは part3 に収録された後半（自己組織チームとマネージャーのあり方）を扱う。 ## 中心主張 優れたマネージャーの役割は指示や管理ではなく「サポート」と「アンブロック(障害物の除去)」であり、チームが自律的に動く「自己組織チーム」こそが高い生産性を生む。この体制は上司と部下の上下関係ではなく、失敗に寛容でフラットな「仲間」関係の文化の上に成り立つ。 ## 論の展開 - 著者の上司ダミアンは、初対面のミーティングで「初対面の私を信じて一切を任せてくれた」。以後もチームや個人のゴール・ミッションの共有はしっかり行うが、具体的な仕事の進め方には「あれしろ、これしろ」と細かく指示することは一切ない。 - ボスの役割は「サポートすること」に尽きる。毎週30分のOne on Oneミーティングでは、悩み事や相談があれば話すが、自主的に動く各メンバーを、具体的にマネージャがゴールやミッションを共有しながらサポートする姿勢が徹底されている。 - マネージャーは納期を急かさない。予定通りリリースできず1週間〜2カ月ずれ込むことも頻繁に起こるが、マネージャーの主な仕事は技術的な実装管理ではなく「アンブロック」――開発者(IC)がどこかで詰まっている状況を解消することだと定義される。 - 一度仕事を渡した以上、マネージャーはプログラマを信頼するしかない。ブレインストーミングでは誰のアイデアも頭ごなしに否定せず、意見が対立しても議論を通じて最適なアイデアを選ぶ姿勢が根底にある。この背景には「自分が一番大切で、自分の幸せを第一に考える」というアメリカの職場文化があり、「辛さに耐えろ」という日本的な忍耐美徳とは対照的である。 - 自己組織チームの導入には注意が必要で、「スクラムを導入しても本気で自己組織チームにしていない」現場が多い。コマンド&コントロール型のマネジメントのままスクラムの形だけ真似ても機能しない。AmazonやMicrosoftでは「two pizza team」のような少人数(10人程度)のチームに分割し、それぞれが小さな裁量権を持つことで機能させている。 - 自己組織チーム導入には、組織の層ごとに異なるアプローチが要る。トップ層にはリードタイム短縮などの効果を示し社の方針として承諾を得る。ミドル層には現場マネージャーの不安を汲み取り、管理負担が減ってビジョン・戦略に注力できるメリットを理解してもらう。チームメンバーには「指示待ち」体質からの脱却が最優先課題で、決定はあくまで本人にさせる「ファシリテーター」役を置く。 - チーム内の上下関係をなくすことも鍵となる。日本の職場にありがちな「社員vsステークホルダー」という対立構図ではなく、アメリカのチームでは全員が同じ責任を負う「仲間」としてフラットに機能する。困ったら自分から助けを求める「プル型」の文化があり、命令口調で仕事を依頼する人はいない。 - 失敗に寛容な職場がチャレンジ精神を生む。マイクロソフトには「Demo or Die」の文化があり、新機能デモで失敗しても「問題ないよ」「よくあることだよ」と励まされる。失敗を恐れず挑戦するからこそイノベーションが生まれるという発想が根底にある。 - 「Be Lazy(より少ない工数で多くのバリューを出すことに集中する)」という考え方が推奨され、休暇も強く尊重される。休暇中は仕事から完全に切り離し、「あー休暇だったらしゃーない」で許容される文化がある一方、日本では休暇中でも仕事を完全に切り離せない・頑張っている感を演出する傾向が対比的に描かれる。 - チームにパワーを持たせることの価値も語られる。「開発者」「運用者」という分業体制ではなく、現場の技術者自身が判断して問題解決に当たれる体制のほうがパフォーマンスが高い。人間はできない人を管理するより、できる人を成長させるほうが効率がよいという考え方に基づく。 ## 実践指針 - マネージャーは部下の仕事の進め方に細かく口出しせず、ゴール・ミッションの共有とOne on Oneでのサポートに徹せよ。 - One on Oneでは、部下から悩み事や相談があれば聞くが、こちらから「共有したいこと」を一方的に持ち込むのではなく、あくまでメンバー各自の個性を発揮させる手助けに徹せよ。 - チームや個人が困っているときは、進捗管理ではなく「何が障害(ブロッカー)になっているか」を探して取り除くことに時間を使え。 - 一度仕事を任せたら、途中経過を逐一チェックせず結果が出るまで信頼して待て。最初のアサインがベストでなかったとしても、途中で口出しするより最後まで任せきる方を選べ。 - 新人であっても「まだできない人」として扱うのではなく、最初から「できるもの」として大人扱いし、必要なときだけ周囲が助ける前提でチームを設計せよ。 - スクラムなど自己組織チームの手法を導入する際は、コマンド&コントロール型のマネジメント習慣を本気で手放さない限り機能しないと心得よ。「チームの体制だけ変えて、上位のマネジメントは変えない」という中途半端な導入を避けよ。 - 組織にチーム制度を導入するときは、トップ・ミドル・現場メンバーそれぞれに異なる不安があることを踏まえ、層ごとに異なる説明・支援を用意せよ。特にミドル層は評価に紐づく数字を持っているぶん抵抗が強くなりやすいので、管理負担が減り本質的な仕事(ビジョン・戦略・改善)に注力できるというメリットを丁寧に伝えよ。 - チームメンバーには「質問することの大切さ」を繰り返し伝え、「Ask For Help」を言い出しやすい空気をつくれ。ただしアドバイスは求められたときだけ行い、決定は本人にさせよ。 - 部下に仕事を依頼するときは命令口調ではなく「お願いモード」を基本にし、困ったときに自分から助けを求められる「プル型」の空気をつくれ。 - 失敗したメンバーを責めるのではなく「よくあることだよ」と受け止め、次のチャレンジを促す態度をとれ。 - 「何をやるか」より「何をやらないか」を先に決め、少ない工数で高いインパクトを出すことに集中せよ(Be Lazy)。 - 休暇中のメンバーには極力連絡せず、休暇から仕事を完全に切り離せる文化をチームでつくれ。 - 自分の意見が誰かと対立しても、それは単に「意見が違う」だけの話であり、相手の人格やマネージャーとの関係性を損なうものではないと割り切れ。 ## 根拠となる研究・事例 - 著者の上司ダミアンのマネジメントスタイル: 初対面のSkypeミーティングから著者に一切の仕事を任せ、「私の力じゃないよ。君がdecodeや他のイベントですごいインパクトを出したからだ」と本人の実績を理由に信頼を示した。以後も細かい指示をせずゴール・ミッション共有のみでサポートに徹した。→示唆: 信頼をベースにしたマネジメントが、メンバーの自律性とパフォーマンスを引き出す。 - 新人とシニアの扱いの違い: アメリカの職場では新人であっても最初から「できるもの」として大人扱いされ、周囲の助けを借りつつきちんとやれる安心感がある一方、日本では新人は「できないもの」として扱われがちだと対比される。→示唆: 「できない前提」で管理するより「できる前提」で任せるほうが、本人の成長と自立を早める。 - マイクロソフトの納期運用: 世界規模のクラウドプロダクト(Build発表分)の開発でも予定が1週間〜2カ月ずれ込むことが頻繁に起こり、マネージャーは急かさず「不確実性を受け入れる」ことを基本方針にしている。戦略(ストラテジー)とカスタマフィードバックに基づいたバックログをもとに「今期やるべきこと」を柔軟に組み替える運用がされている。→示唆: 過度な納期プレッシャーより、開発者が実力を発揮できる環境の方が結果的に成果を生む。 - マネージャーの「アンブロック」業務の具体像: 技術的に困っているメンバーを助けたり、ステークホルダーへの説明を代行したり、他部署の協力を要請したり、デッドラインの調整を手伝ったりする「サポーター」役に徹する。中長期的なキャリアアップの相談にも乗る。→示唆: マネージャーの価値は技術指示力ではなく、開発者が本来の仕事に集中できるよう周囲の障害を除去する調整力にある。 - 「自分が一番大切」という価値観の対比: アメリカでは「技術者たるもの、どんな批判も甘んじて受け入れ、まさに七難八苦を与えたまえ!」というような日本の戦国武将的な忍耐美徳は存在せず、自分の意見が誰かと対立しても「自分はこう思う」「意見が違う」という事実がある以上のものとして扱われない。→示唆: 自己犠牲を伴う忍耐ではなく、自分の幸せを起点にする発想の方が、長期的な生産性と心身の健全さを保ちやすい。 - 自己組織チームの導入実態を扱った英文記事: 「スクラムがアジアでは機能しない」と題された記事で、「欧米では組織全体にスクラムを導入しているが、アジアではソフトウェアチームの導入に留まっている」と指摘されていた。→示唆: 自己組織チームは一部門だけの制度変更ではなく、組織全体のマネジメントスタイル変革とセットでなければ機能しない。 - Amazon・Microsoftの「two pizza team」的な少人数チーム編成: 2枚のピザで足りる人数(10人程度)を上限にチームを分割し、世界最大級のグローバルシステムでも実際にはマックス25人ぐらいのチームの集合体として運用されている。→示唆: 自己組織チームは規模の大小によらず、小さな裁量権を持つ単位に分解することで機能する。 - 図17「自己組織チーム導入にあたってのコツ」の三層構造: トップ層にはリードタイム短縮など定量的な効果を示して社の方針としての承諾を得る。ミドル層は変革のミッションごとに数字(KPI)を背負っているぶん一番抵抗が強く出る層であり、管理負担が減ってビジョン・戦略・改善に注力できるというメリットを丁寧に伝える必要がある。チームメンバー層は新しい技術やプロジェクトへの前向きさがある一方、指示待ち体質からの脱却が最優先課題で、「決定」は本人にさせる「ファシリテーター」役を置く。→示唆: 自己組織チーム導入の最大の壁はメンバーではなく、評価責任を負うミドルマネジメント層の不安にある。 - 「Ask For Help」の文化: メンバーには「質問しやすくするのはよいが、それはあくまで彼らが求めたときだけ」というスタンスでアドバイスをし、「気軽に質問してみよう!」というメッセージを繰り返し伝えることで、自然とメンバーからの質問が増えていったという著者の実体験が語られる。→示唆: 指示待ち文化からの脱却には、上司が我慢して「求められるまで待つ」姿勢が不可欠。 - マイクロソフトの「Demo or Die」文化: 新機能デモで失敗しても「問題ないよ」「よくあることだよ」と励まされ、失敗が気にされない空気がある。→示唆: 失敗への寛容さが心理的安全性を生み、結果としてチャレンジ精神とイノベーションを促進する。 - COLUMN「アメリカのキャリアアップ文化」: アメリカ企業ではレイオフの可能性があるが再就職しやすい文化があり、ジョブレベル制度によりキャリアは「自分次第」。給料ランクは社内で上がりにくいため転職で昇給するのが一般的で、IC(Individual Contributor)という管理職ではない専門職の道もあり、マネージャーより給料が高いプログラマも多い。→示唆: キャリアの選択肢が多いことが、個人の主体的な意思決定と幸福を優先する文化を支えている。 ## キーワード - **アンブロック(unblock)**: マネージャーの主要な役割の一つ。開発者(IC)が業務上詰まっている障害物を取り除くこと。技術的な指示ではなく、ステークホルダーへの説明や他部署との調整などが中心。 - **自己組織チーム**: メンバー自身が意思決定・自主規律を行うチーム体制。コマンド&コントロール型のマネジメントの対極にある考え方で、スクラムなどのアジャイル手法の前提となる。 - **Be Lazy**: より少ない工数(仕事量)で、より多くのバリュー(インパクト)を生み出すことに集中する考え方。「頑張って多くこなす」ことよりも「やらないことを決める」ことを重視する。 - **プル型/お願いモード**: 上司が部下に細かく指示する「押し付け型」ではなく、困ったら本人が自分から助けを求める(プル型)、依頼するときは丁寧に頼む(お願いモード)という、フラットな職場文化のあり方。 - **IC(Individual Contributor)**: 管理職(マネージャー)ではない、専門職としてのキャリアパス。アメリカでは技術者がマネージャーにならずに高い給料・評価を得られる仕組みとして重視される。 - **two pizza team**: Amazon発祥とされる、2枚のピザで足りる程度(おおむね10人以下)の少人数チーム編成の考え方。大規模組織でも自己組織チームを機能させるための基本単位として紹介される。 - **サーバントリーダーシップ**: 部下に指示・命令する従来型のリーダーシップとは逆に、リーダーがメンバーに奉仕し支援することでチームの成果を引き出す考え方。自己組織チームへの移行に伴い、マネージャーはこの役割へのシフトを求められる。 - **Demo or Die**: マイクロソフトに根付く、新機能や試作をとにかくデモという形でアウトプットし、たとえ失敗しても許容される文化。失敗を恐れず挑戦することを促す価値観の象徴として紹介される。