組織行動とリーダーシップ Day5|ディズニー・アニメーションのチーミング──失敗を「予期していなかった結果」と呼ぶチームの作り方

組織行動とリーダーシップ Day5|ディズニー・アニメーションのチーミング──失敗を「予期していなかった結果」と呼ぶチームの作り方

本記事は「MBAで学んだ組織行動とリーダーシップ」シリーズのDay5です。

この記事でわかること

  • ディズニー・アニメーションのシステム部で、ガイベルがチームの形と運営をどう変えたか
  • エドモンドソンの失敗の分類と心理的安全が、なぜ「ぬるさ」と別物なのか
  • 秩序系と非秩序系(クネビン・フレームワーク)で、マネジメントのやり方を切り替える考え方
  • ITサービスの運用チームに当てはめたときに確かめる問い
  • 受講後の振り返り課題で「チーミング」について書いたこと

1. 13連敗のスタジオで、エンジニアの部署から変わり始めた

Day5のテーマは「VUCA環境下で、メンバーが自らイノベーションを生み出すチームをどう作り、どう移行させるか」でした。

カリフォルニア州バーバンクにあるロイ・E・ディズニー・アニメーション・ビルの外観。魔法使いの帽子の形をした塔がある
写真:ウォルト・ディズニー・アニメーション・スタジオの社屋(バーバンク)。撮影 The Walt Disney Company/CC BY 2.0(Wikimedia Commons)

ケースはディズニー・アニメーションです。アニメーション制作は、手描きから「手描き+CG」、そしてフルCGへと、わずか10年ほどで移りました。ディズニーはフルCGへの移行で約10年遅れ、2013年の『アナと雪の女王』まで、ピクサーに13連敗していたと講義では紹介されました。

フルCGの映画は、科学者・エンジニア・アーティストが部門を越えて協働しないと作れません。ケースの舞台は、映画を作るアーティストではなく、その裏でエンジニアを束ねる「システム部」です。2010年にシステム部のディレクターに登用されたジョナサン・ガイベルが、マネージャーのロン・ジョンソンと一緒に、チームの形と運営を変えていきました。

このケースの特徴は、ガイベルが変革の理想像を最初に描かなかったことです。変更は一度に1つだけにして、結果を観察し、学んで次を試す。失敗については「単に予期していなかった結果だ」と言い続けました。この記事では、その進め方を支える理論と、IT運用の現場に当てはめたときに何を確かめるかを整理します。


2. ガイベルが変えた4つのことと、それを支える理論

システム部で何が変わったか

2010年以前のシステム部は約50人で、15〜20人ずつのユニットに分かれていました。マネージャーは上階のオフィスからプロジェクトを管理し、最終的な技術判断もマネージャーが下していました。マネージャーは自分のユニットの成果で評価されたため、人や予算を他のユニットに渡したがりませんでした。

ガイベルの改革は次の4点です。

観点以前新しい方法狙い
組織構造マネージャー主導の固定チーム。異動はほぼないチームリーダー主導の流動的な小規模チーム(6人以下)。異動が多い環境やニーズに合わせて改廃しやすくする。小さくして会話を増やす
役割分担マネージャーがPJ管理・リソース確保・人事評価。メンバーは指示されたタスクを単一スキルで執行マネージャーは新技術への投資と人材育成。チームリーダーが分野のビジョンとPJ管理。メンバーはプライマリー+セカンダリーで複数スキルを使うマネージャーが長期の視点に集中する。メンバーが古い技術に固執しなくなる
部内コミュニケーション別々のオフィス、正式な会議近くに座り、ホワイトボードですぐ議論。主要イベントは廊下のマスターカレンダーに付箋で貼る席の距離を縮め、会話の頻度を上げる。タスクを見えるようにする
部門間コミュニケーション希薄映画制作の「デイリー」(遠慮のないメモを共有し、扱いは作業のオーナーに任せる)、顧客の席へ出向く「ソーシャルエンジニアリング活動」率直なフィードバックで早く直す。顔が見える関係で期待値を合わせる
ディズニー・アニメーションのシステム部の組織図の比較。左は2010年以前、上階のマネージャーの下に15〜20人のユニットが3つ並ぶ。右は2010年以降、6人のマネジメントチームの下に2〜6人の小さなチームが5つあり、チームリーダーとプライマリーメンバーに加えて、セカンダリーとして他チームに参加する線が引かれている
図1:システム部のチーム構造の変化

6人という上限は、実験から出てきた数字です。ガイベルは週1回のリーダー会議を任意参加にし、毎週参加人数が変わるようにしました。すると、6人から7人に増えたところで議論の質が大きく下がり、人が黙ってしまうことに何度も気づいた。そこからチームは2〜6人で組む、という形になりました。

講義では、この転換を「効率性の追求」から「可能性の最大化」へ、と整理していました。標準化して比較・管理すると、人は競争に向かう。強みを発揮させて弱みを補い合わせると、創発が生まれる、という対比です。

秩序系から非秩序系へ

この変化の背景にあるのが、秩序系と非秩序系の区別です。

秩序系非秩序系
進め方KPIとPDCA試行錯誤と探索
組織のたとえ機械のような組織生き物のようなチーム
動機づけ金銭的なインセンティブ内発的な動機

クネビン・フレームワークでは、自明・煩雑な領域が秩序系、複雑・混沌な領域が非秩序系にあたります。複雑な領域では「探索→感知→対処」、混沌の領域では「行動→感知→対処」の順で動きます。反脆弱性の3段階(規則で縛る=脆弱、原則で運用する=頑健、美徳を通じて学習し更新する=反脆弱)も同じ線上にあります。

失敗の分類と心理的安全

ガイベルの「失敗とは予期していなかった結果だ」という言葉を理論で裏づけるのが、エドモンドソンの失敗の分類です。逸脱・不注意・能力不足による失敗は非難に値します。一方、仮説検証や探査のための実験で起きた失敗は称賛に値する。その間に、プロセスの不備・困難な仕事・複雑さ・不確実性による失敗が並びます。

もう1つが心理的安全です。罰せられたり評価を下げられたりしないと感じられる雰囲気のことで、だからこそ厳しいフィードバックや難しい話し合いができる状態を指します。講義では、これはぬるさではないと整理されていました。Googleのre:Workでも、チームの効果性を左右する因子として、①心理的安全性 ②相互信頼 ③構造と明確さ ④仕事の意味 ⑤インパクト が挙げられています。


3. IT運用のチームに当てはめると

ここからは、ITサービスの運用チームや、顧客企業に常駐するチームを率いる立場に当てはめて考えます。ケースのシステム部は、アーティストを社内の顧客として支える部署で、顧客の要望と技術のあいだに立つ点が運用や常駐の現場と近い構図です。

失敗をどの位置に置いているか

障害の振り返りに失敗の分類を重ねると、次のようになります。

エドモンドソンの失敗の分類を、左の非難に値する(逸脱・不注意・能力不足)から右の称賛に値する(仮説検証・探査実験)まで横一列に並べた図。その下に、IT運用の場面に当てはめた例として、手順を飛ばした作業、手順書の不備による誤操作や複合障害、新しい監視設定の試行で出た想定外の検知を置き、それぞれ再発防止、仕組みの見直し、共有して称えるという向き合い方を対応させている
図2:失敗の分類をIT運用の場面に当てはめる

決められた手順を飛ばした作業と、新しい監視設定を試した結果の想定外の検知とでは、失敗の性質がまったく違います。後者を前者と同じ「原因と再発防止策」の様式で扱えば、チームは「新しいことを試さないのが正解」と学んでしまう。振り返りの場では、まずこの失敗は分類のどこに置かれるものかを決めることになります。

エドモンドソンが示した、チームが失敗から学ぶアプローチも、そのまま点検項目になります。

  1. 失敗を恐れない(「失敗はある」を前提にする)
  2. 失敗に気づく(報告してきた人を歓迎する)
  3. 失敗を分析する(複数の分野の目で、体系立てて)
  4. 意図して試みる(学ぶための知的な失敗をデザインする)

4つ目の例として、イーライリリーの「失敗パーティー」が紹介されました。運用の現場では、2つ目の「報告してきた人を歓迎しているか」が最初に確かめる点だと考えます。障害の第一報を上げた人が、その後の報告書作成まで背負い込む運用になっていないか、という問いです。

指標が行動をゆがめていないか

ケースには、IT運用に近い場面がもう1つ出てきます。技術サポートのチームを、処理したチケットの数で評価していたところ、メンバーは手間のかからないチケットばかりを取り、複雑な問題を避けるようになった、というものです。ガイベルは「私たちはデータや指標ではなく、人との関係によって動いている」と述べています。

運用チームの評価に処理件数やSLA達成率を使っている場面に当てはめると、その指標が、難しい案件を後回しにする理由になっていないかが論点になります。

顧客にどこまで問題を見せるか

顧客とのあいだに立つ立場にもっとも近いのは、メールの宛先をめぐる場面です。システム部のあるメンバーは、顧客と情報を共有しすぎていると考え、顧客用と内部用の2つのメーリングリストを作るべきだと提案しました。ガイベルたちは議論したうえで、結局オープンなコミュニケーションを選びました。

エンジニアの1人は「バグの発覚やその対応に3週間かかるとして、それを顧客に恐れず正直に話すことが、顧客との信頼構築につながる」と話しています。同時に「解決策がないと言ってばかりはいられない。約束を実行する必要がある」とも付け加えていました。

顧客向けの報告を整えてから出す運用に当てはめると、整える過程で、顧客が知っておくべき遅れやリスクを削っていないかを確かめる問いになります。

6人の上限と、セカンダリーという役割

常駐チームが大きくなると、定例会議の参加者も増えます。ケースの「7人目で議論の質が落ちる」という観察を当てはめると、会議の人数とチームの単位が議論の質に影響していないかを確かめることになります。

プライマリーとセカンダリーの仕組みも参考になります。全員が1つのチームに主な責任を持ちながら、別のチームにも補助として参加できる。ケースでは、データベースのスキルを持つWindowsの管理者などが、その力を部署全体で使えるようになりました。「2人の上司の板挟み」を避けるため、主な責任はプライマリーチームにあると明確にしていた点も押さえておきたいところです。


4. 振り返り課題に書いた「チーミング」

受講後のDay6振り返りアサインメントで、私はDay5の内容について次のように書いていました。

また、「チーミング」という概念は自身にとって重要だった。ここでは、失敗を実験の一部と捉え、素早く学び、次へ進むことが強調されていた。

続けて、心理的安全性を担保したうえでまずトライしてみること、結果が悪くても失敗ではなく試した結果だと理解し、改善して次に向かうこと、そしてこのアプローチが組織の革新と成長に欠かせないと感じたことを書いています。

同じ課題の「学びの整理」には、もう1つDay5に関わる記述があります。

さらに、素晴らしい組織は、元々素晴らしいのではなく、自社で改善に努めた結果素晴らしい組織になっていることがわかった。

ここで挙げた例の1つが、ディズニー・アニメーションでした。システム部も、最初から理想の形があったわけではなく、一度に1つずつ変えながら今の形にたどり着いています。

左にDay6振り返りアサインメントの記述、右にケースの場面を並べて矢印で結んだ図。失敗を実験の一部と捉える記述は「失敗とは予期していなかった結果だ」という言葉と早期報告の奨励に、心理的安全性のもとでトライする記述は「いいアイデアだね、やってみよう」という反応と作業場の移動に、透明性とオープンな姿勢の記述はマスターカレンダーと顧客へのオープンなコミュニケーションに対応する。4行目は実務の気付きとして職場の社員の「顧客への遠慮」を、エンジニアの「バグ対応に3週間かかると正直に話すことが信頼につながる」という発言と対応させている
図3:振り返り課題の記述とケースの場面の対応

振り返り課題の「実務における気付き」の欄には、自分の職場の社員の特性を書き出したことを記しています。社員のプロファイルを検討するなかで、経営層との距離感、顧客への遠慮、英語への憧れといった特徴を見つけ、それを踏まえてコミュニケーションを変えた、という内容です。

この「顧客への遠慮」を、ケースの場面に置き換えて考えてみます。システム部のエンジニアは、バグの対応に3週間かかることを顧客に正直に話すことが信頼につながると言っていました。遠慮が先に立つと、悪い知らせほど伝えるのが遅れます。ガイベルたちが顧客用と内部用のメーリングリストを分けなかったのは、遠慮によって情報が削られる経路を、仕組みの側でふさいだとも考えられます。課題ではこの2つを別々の欄に書いていましたが、並べて読み返すと、同じ問題を別の角度から見ていたことになります。

振り返り課題の「学びを深めるための方向性」では、ディズニーとHCLの事例から、チームビルディングとエンゲージメントの強化を挙げていました。チーム内のコミュニケーションを強化し、メンバーの意見を尊重する文化を育てていく、という方向です。また、自分の活動だけでなく、他の現場のリーダーたちに共有してともに取り組むことで、組織の変化を速められるという気付きも書いています。ガイベルが自分の部署で始めたチーミングを、マネジメントチームにも同じ構成で導入していったことと、方向は同じだと考えています。


5. 学びと示唆 ── チームを移行させるときに確かめること

移行には実験と、リーダーによる心理的安全の提供が要る

講義のまとめは3点でした。

  1. VUCA下では、俊敏にイノベーションし続ける必要がある
  2. 存在目的が明確で改廃しやすい組織、新しい技術を取り入れやすい役割分担、率直に話せる場づくりが要る
  3. 移行には実験が欠かせない。失敗を学習に変える仕組みと、リーダーによる心理的安全の提供が要る
ガイベルの変革の進め方を、現状の問題を分析・議論する、変更は一度に1つ、影響を観察し測定する、学んで次の理論を立てる、結果を全員で共有する、という5段のループで示した図。右側に、このループで決まったこととして、リーダー会議の人数を変えて6人以下のチームに決めたこと、役割の混乱からリーダー・プライマリー・セカンダリーを定義したこと、席を近づけて正式な会議の多くが不要になったこと、8人用スペースの壁を外したが全チームに合うかは未確定であることを並べている
図4:一度に1つ変える実験ループ

3点目について、ガイベルは心理的安全を言葉だけで確保したのではありません。自分たちの専用部屋をやめ、作業場をシステム部の中心に移して、いつでも話しかけられる位置にいました。全作業が見えるマスターカレンダーはメンバー自身に更新させ、服装・レイアウト・プロジェクト管理の方法・会議の構造もメンバーに決めさせています。

講義で紹介された、心理的安全を高めるリーダーの行動は次の7つです。

リーダーの行動ケースで近い場面(本稿での対応づけ)
親しみやすい作業場を部の中心に移した
知識の限界を認める顧客にとって何が最善かは、その分野の技術リーダーが一番よく分かるとして、運用の決定を任せた
自分もよく間違うと示す肩書きをなくす判断について「最悪の決定の1つになる可能性もある」と口にした
参加を促す新しいアイデアに「いいアイデアだね、やってみよう」と返した
失敗は学習の機会だと強調する「失敗とは単に予期していなかった結果だ」
具体的な言葉を使う2ページの「リーダーに期待すること」で役割を書き出した
境界を設け、責任を負わせる主な責任はプライマリーチームにあると明確にした

実行フレームと学習フレームの対比も、この表と重なります。学習フレームのリーダーは、メンバーを脇役や部下ではなく「困難を乗り越えるための重要なパートナー」と見て、自分自身もメンバーに依存していると認めます。ケースの見出しの1つが、リーダーが「脇役」に徹する、でした。

自律は与えただけでは根づかない

一方で、ケースは移行の難しさも隠していません。ガイベルが服装やレイアウトを自分で決めるよう指示しても、机を動かすのに許可を求めに来るエンジニアがいました。ガイベルは「君はどう思う?君のチームにとってベストなのは何?」と返しています。従業員の平均在職期間が15〜40年で、トップダウンの文化が染みついていたためです。

ジョンソンも、小さな自律チームを最初に作ったとき「ただ14の新しいサイロを作っただけなのではないか」と懸念していました。肩書きをなくすかどうかについても、ガイベルは「非常に大きな成功かもしれないが、最悪の決定の1つになる可能性もある」と迷いを口にしています。

ここから受け取ったのは、移行の途中にいるリーダーが、自分の判断が正しいか分からないと認めたまま進めてよい、ということです。講義で触れたキーガンの「弱さを見せあえる組織」では、取り繕わず本来の自分で来られること、互いの弱点を知って克服を支援すること、率直なフィードバックの文化が挙げられ、「トップダウンではなく、トップから共感する」という言葉が紹介されました。

U理論の会話の4つのモード(ダウンローディング→討論→内省的対話→プレゼンシング)も扱われ、「安心安全な場」とは好き勝手に言える場ではなく、内側から湧く言葉を出せる場だという中土井僚さんの言葉が引かれました。成功循環モデル(関係性の質→思考の質→行動の質→結果の質)とあわせると、ガイベルが席の配置や会議の人数から手をつけたのは、関係性の質から入ったと整理できます。


6. まとめ

  • ディズニー・アニメーションのシステム部では、15〜20人の固定ユニットを2〜6人の流動的なチームに組み替え、マネージャーは新技術への投資と人材育成、チームリーダーは分野のビジョンを担う形に変えた
  • 変え方は「一度に1つ変え、観察し、学んで次を試す」という実験の繰り返しだった。6人という上限も実験から出てきた
  • 失敗には非難に値するものと称賛に値するものがあり、心理的安全は厳しい話し合いをするための前提であって、ぬるさではない
  • IT運用に当てはめると、振り返りでの失敗の位置づけ、指標が難しい案件を避けさせていないか、顧客に見せる情報を遠慮で削っていないか、が確かめる問いになる
  • 自律は指示しただけでは根づかない。リーダーが迷いを認めながら、場所・言葉・仕組みの3つで心理的安全を提供し続けることが、移行の条件になる

振り返り課題に「チーミング」は自身にとって重要だったと書いた理由は、読み返すと、失敗の扱い方とコミュニケーションの透明性という2つにありました。次回のDay6では、同じイノベーションの問いを、HCLテクノロジーズのCEOの立場から、組織全体の変革として考えます。


よくある質問(FAQ)

Q1. 心理的安全性が高いチームは、ぬるいチームになりませんか?
心理的安全は、罰せられたり評価を下げられたりしないと感じられる状態です。だからこそ厳しいフィードバックや難しい話し合いができます。何を言っても許される、問題を指摘しないという状態とは違う、というのが講義での整理でした。

Q2. 失敗の分類では、どの失敗が称賛に値するのですか?
エドモンドソンの分類では、仮説検証や探査のための実験で起きた失敗が称賛に値します。逸脱・不注意・能力不足による失敗は非難に値し、その間にプロセスの不備・困難な仕事・複雑さ・不確実性による失敗が入ります。

Q3. チームを6人以下にするのはなぜですか?
ディズニー・アニメーションのシステム部では、任意参加のリーダー会議で参加人数を変えてみたところ、6人から7人に増えると議論の質が大きく下がり、人が黙ってしまうことが繰り返し観察されました。そこからチームを2〜6人で組む形にしています。

Q4. プライマリーとセカンダリーの役割分担は、マトリックス組織と何が違いますか?
全員が1つのプライマリーチームに主な責任を持ち、セカンダリーとしての参加は補助と決めている点です。チームリーダーも、セカンダリーメンバーがプライマリーチームに割く時間を奪わないようにしていました。2人の上司の板挟みになる問題を避けるための設計です。

Q5. クネビン・フレームワークの秩序系と非秩序系は、どう使い分けますか?
自明・煩雑な領域(秩序系)は、分析すれば答えにたどり着けるので、KPIとPDCAで計画どおり進めます。複雑・混沌な領域(非秩序系)は事前に答えが分からないため、複雑なら探索→感知→対処、混沌なら行動→感知→対処の順で、試しながら進めます。


参考書籍


本記事はアフィリエイト広告(PR)を含みます。