エラスティックリーダーシップ――自己組織化チームの育て方

最近出版された本ではありませんが、じっくり読む機会があったので簡単に所感をまとめてみます。購入したのは約1年前でした。それから積ん読していて、読み始めてからも時間のあるときに少しずつ読み進めて1ヶ月ぐらいかかりました。

www.oreilly.co.jp

買っておくといつか読む可能性がある。

読まないよりは少しでも読んだほうがよい。

一通り読めてよかった。

。。。

そんな所感は誰も期待してないでしょうから、少し振り返りながら私にとって関心のある内容をまとめてみます。私はリーダーや管理職に就いたことがないので本当の意味では、本書のリーダーの難しさや悩み、葛藤などは理解できていないと思います。

一方でメンバーの立場でリーダーを補佐してきたことや、いくつかの企業やチームでそれぞれのリーダーに接してきたこと、自分にとって働きやすかったリーダーなど、やはり、本書を読んで共感できるところは多々あります。

そして、自分がリーダーとして振る舞うことが求められるとき、やはり、本書は人それぞれのリーダー観を獲得するヒントにもなるでしょう。

チームの自己組織化

本書でのキーワードの1つに「自己組織化」があります。聞いたことがあるような単語ですが、そもそも自己組織化とはどういう意味だろう?と思ったときに私は答えられませんでした。

パターン形成の仕組みを理解するために、物理学、化学、生物学、情報科学などに広く用いられる概念。無秩序状態の系において、外部からの制御なしに秩序状態が自律的に形成されることをいう。ここで「外部からの制御なしに」とは、外部から細かく手を加えてパターンを作成するような作用がないということを意味する。

自己組織化とは - コトバンク

いくつか説明の記事を読んで、コトバンクの説明が私にはわかりやすかったです。科学の分野にまたがって用いられる概念であるという。系をシステム、秩序をパターンやルールのように読み替えるとエンジニアリングの概念とも合致しそうな雰囲気はします。

それではチームの自己組織化とはどういう意味でしょうか。ちょうどその記事がありました。

www.infoq.com

この記事によると、アジャイルソフトウェア開発宣言 (Agile Manufesto) の一節に次の文言が出てきます。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

アジャイル宣言の背後にある原則

記事内では、単なる個人の集まりとしての共同作業グループと、その宣言で意図された自己組織化チームとの違いを、様々な特徴、モデル、要素などから説明しています。私がざっと読んだだけでは理解できそうにありません。私の中ではまだ言語化できていないので、ここではチームの自己組織化とは尊いものだとしておきましょう。そのぐらいの安易で、なんら初学者の理解を助けない表現で留めておきます。そして、チームの自己組織化は、簡単には成らず、成ったとしても永遠に続くものではなく、メンバーが相互に作用して目的を果たしていく形態のようです。

リーダーシップのスタイルとチームのフェーズ

チームには異なるリーダーシップを必要とするフェーズ/状態がある。本書では次の3つの関係を図解で表しています。

  • 指揮官が必要なとき: サバイバルフェーズ
  • コーチが必要なとき: 学習フェーズ
  • ファシリテーターが必要なとき: 自己組織化フェーズ

図では「モード」と記載されているが「フェーズ」とも呼ぶと説明されている箇所があるのでモードとフェーズは同じ意味で捉えてよさそうです。

f:id:t2y-1979:20210727145652p:plain
3つのチームのフェーズ

サバイバルフェーズ

本書では、チームに学習する時間が十分にない状態を「サバイバル」と定義している。リーダーはメンバーが学ぶ時間をとれるよう、サバイバルモードから抜け出すための戦略を練る必要がある。そういった状態では指揮統制型のリーダーシップが有効である。

学習フェーズ

十分なゆとり時間があり、その時間を使って学習や検証を行っているなら「学習」フェーズにいると言える。このフェーズにおけるリーダーは、メンバーに対して自分たちの問題を自力で解決できるように教え、挑戦させ、自己組織化チームへと育てることが目標となる。そのため、コーチ型のリーダーが必要になる。

自己組織化フェーズ

リーダー/メンバーともに何の心配もなく、携帯電話やパソコンの電源を切り、数日間仕事を放置できる状態であれば、自己組織化フェーズと言える。このフェーズにおけるリーダーは、ファシリテーターとなってその状態を維持すること、そして現状を処理するチームの能力に注意を払うことが目標となる。

フェーズ間の移動

チームの状態によってはリーダーシップが異なること、チームに発生するイベント、例えば、新人がチームに入ってくる、目標の期限を変更するといったイベントが発生したときにフェーズが移動することもありえると説明されている。

f:id:t2y-1979:20210727151023p:plain
チームのモードを検出する

スタイルやフェーズに関する所感

リーダーシップのスタイルとフェーズにも「自己組織化」というキーワードが出てきます。他のフェーズと比べ、リーダーは自由時間をもち、メンバーは自分たちで意思決定を行い、チーム自身で問題解決できるという、尊い状態であることが伺えます。

本書では、それぞれのフェーズについて章を設けてより詳細に説明されています。その中で私が印象に残った5章の学習することを学ぶについて取り上げてみます。

学習することを学ぶ

学習モードとは、チームがゆとり時間を持ち、それを新しいスキルの集中的訓練にあてている状態と定義できる。

本書を読んで私がもっとも関心をもったことの1つに学習には「谷」があると説明されていたことでした。

進捗には2つのタイプがある。

  • 学習の進みが遅く安定している高原。
  • 学習が大きく飛躍している峰。

f:id:t2y-1979:20210727152609p:plain
学習の変化と谷

さらに引用します。

私が思うに、学習の真の力というのは、次の単純な事実を悟ることだ。谷は最終的には終わって、あなたは新しい知識と共に飛躍する ことになる。このことを知ってい れば、不可能だと思うことだって、やり始めることができる。

そして、自分が谷に直面している可能性があるのは次のような状況にあると言う。

  • 面目や尊厳、お金や友人を失う可能性があるために、一歩を踏み出すのに勇気がいる。
  • 違和感を感じている。
  • 自分を変えるかもしれないこと、あるいは、自分の世界や仕事、関わる人々への理解の仕方を変えそうなことがある(が、これを事前に知るのは難しい)。
  • 新しいスキルを獲得しなくてはならない。

真の学習は谷によってもたらされる。谷底は不快で、時折イライラさせられる。メンバーが楽しくなさそうなら、彼らをうまく安全地帯の外に出せている良い兆候かもしれない。メンバーから抵抗を感じたなら、それはあなたがうまくチームを操縦できている証拠だ。

余談ですが、先日、寺田さんの podcast に出演した際にも本書の学習の谷について少し話しました。

podcast.terapyon.net

私はずっとバックエンドの開発に携わってきて、最近フロントエンドの開発に携わりました。その過程で自分の培ってきた経験や知識と明らかに考え方の異なる設計やアプローチに対して、大きな違和感を受けつつ、それを言語化できない自分自身のもどかしさに葛藤や逡巡を覚えました。

決して自身の経験や知識を正しいと主張して新たな開発スタイルを否定する気持ちはありませんでした。しかし、設計とはトレードオフを強いることもあるため、この設計ではこういうケースに対応できないとか、拡張するときにこういったデメリットがあるといった、大小あれども自分の価値観との違いをうまく言語化できずにもがいていました。

手伝い始めた当初はアンラーニングも大事だろうと考え、盲目的に同僚の意見や設計を受け入れながら開発を進めました。同僚はあまり設計やアーキテクチャ言語化せず、意図も説明しなかったので、違和感があっても指摘するのが面倒になって放置するといったときもありました。

そのときの楽しくない気持ち、自身の行動に自信がもてない気持ち、そういった感情の振れ幅とモチベーション管理をうまくできなくて自己嫌悪に陥ったときもありました。思い起こせば、これまでも新しいことに挑戦するときは同じような、うまくいかなくて挫折感を味わうというのは何度も経験していました。しかし、それを「学習の谷」という概念では捉えていませんでした。本書で谷という概念を知ることで少し救われたように私は感じました。

真の学習というのは、以前より生産性が落ちたり、違和感を感じて不快なものであると考えることにより、いくらか新しい挑戦への不安を軽減する術になるように私は思います。

第7章「メンバーを成長させる」にもリーダーがメンバーを指導するとき、メンバーにとって真の成長機会であるかを見分ける項目として、学習の谷にあることを確認するときの項目と同様に次をあげている。

  • 恐怖があること
  • 初期の不快感や不満があること

影響パターン

メンバーの主要な振る舞いを変えるように影響を与えたい場合の6つの影響力について次の説明があります。当初、この影響力のマトリクスの説明を読んだときはあまり内容を理解できていませんでした。

本書の後半は、様々なリーダーが1章ずつエッセイを綴っています。そのエッセイに対して著者が分析してコメントを書いています。そのコメントを読んでいると、このエッセイは影響パターンのこれとそれを示唆しているといった説明が度々でてきます。

より具体的な事例を影響パターンに分類することで私の理解が深まった気がします。

f:id:t2y-1979:20210727161500p:plain
影響力のマトリクス

現場リーダーのための 6 つの原則 平鍋 健児

過去に平鍋さんの記事をいくつも読んで私は大きな影響を受けています。その中で「名前づけ」の節がおもしろかったので紹介します。

気づきによって得た知識に名前をつけましょう

問題を解決する方法には、「ブレークダウンによる方法」(Divide and Conquer)と、もう一つ、「名前づけによる方法」(Name and Conquer)があります。

プログラミングで最も難しいことの1つに、やはり名前づけがよく言われます。私は初期の開発時にしょっちゅう名前を変えます。

名前を知ったことで人間の認知に影響が出たエピソードとして「ヨシュアツリーの原則」も紹介されています。

www.atmarkit.co.jp

まとめ

読者の経験や立場によって本書の興味や関心をもつ箇所は変わるでしょう。また時間が経って、自分の状態の変化によっても本書から受け取る内容は変わるかもしれません。

さて、冒頭でチームの自己組織化とはなんぞや?という問いに、私は尊いという言葉で表現していました。本書を読むと、自己組織化とはこういった内容かなと、自分なりの解釈や理解が、読む前よりは進むように思います。そして、その解釈や理解に絶対というものもないように私は考えています。

私にとっての、チームの自己組織化というのは、チームが自律的に課題を解決していくための責任と権限をもち、それが開発文化として十分に根付いており、リーダーもメンバーもその役割を担う上での価値観が共有されている状態であると考えます。