シェアド・リーダーシップへの挑戦

MADOX

この記事を書いたキッカケ

EM Fest や Scrum Fest Sendai 2024 に登壇した際、「シェアド・リーダーシップをどんな風に試しているか具体的に知りたい」というお声をいただいたため、現在進行形で試行錯誤する姿を書きました。

以下の登壇資料を予めご覧いただくと、記事の背景を把握しやすいかと思います。

この記事から得られること

「ソフトウェアエンジニアのチームにシェアド・リーダーシップを適用する際の具体例」を知ることができます。エンジニアリングマネージャーの視点で書いているため、開発組織に携わる方の参考になれば嬉しいです。

リーダーシップ論の変遷

リーダーシップと組織のパフォーマンスに関する研究は、1900年頃から心理学をベースにおこなわれたようです。それらの研究でフォーカスされるテーマは「(先天的な) 特性/性格」から「(後天的な) 行動」へと移り、後に「リーダー中心」から「フォロワー中心」へとパラダイムシフトしていきました。そうした中で生まれたのが「サーバント・リーダーシップ (Servant Leadership)」や「シェアド・リーダーシップ (Shared Leadership, 共有型リーダーシップ)」だそうです。注 1

シェアド・リーダーシップとは

リーダーシップの機能をメンバー全員で共有しあい、組織としてリーダーシップを最大化するスタイルです。

ビジネスの環境が複雑になりサイクルが短くなる傾向がある中で、1人のリーダーへの負荷が高まり、ボトルネック化している現実があります。

そのような課題に応えるべく「歴史的な必然性」を伴って生まれてきたスタイルのため、理論と実践の両面で今後も発展していくものと私は捉えています。

シェアド・リーダーシップの主な特徴は以下の通りです。注 2

  • 各自の強みの領域でリーダーシップを発揮

  • 他メンバーがリードする領域ではフォロワーシップを発揮

  • リーダーとフォロワーが流動的に変化

リーダーとフォロワーが流動的に入れ替わるイメージ

実践前に抱いた疑問

「全員がリーダーシップを発揮する場合、どんな問題が生じるんだろう？」

そんな疑問が湧いてきたため、以下のような仮説を立てて探りながら進めました。

疑問）コミュニケーションパスが複雑化して認知負荷が高まるのでは？
仮説）チームのサイズ、（チーム内の）仮想チームのサイズ、同時進行する案件の数が多すぎると破綻しそうだな。ちょうど良いサイズを探りながら進めよう。「エレガントパズル」の第2章あたりが活かせそう。注 3

疑問）方向性の統一が取れない場合、組織の出力が低下するのでは？
仮説）方向性をファシリテートするためにインセプションデッキが有効そうだな。スクラムマスターの方にワークショップを依頼しよう。

疑問）新規参画者はどんなことにリーダーシップを発揮できるんだろう？
仮説）むしろ新鮮な目で改善点を洗い出す際、リーダーシップを発揮してもらえそうだな。

疑問）責任の所在はどのようになるんだろう？
仮説）各案件の進行をリーダーに任せつつ、EMとして説明責任を果たせるよう、全案件の把握は引き続き必要だな。

組織上の前提

所属する開発組織全体は100人以上のピラミッド構造になっており従来型のリーダーシップで運営されていますが、私の管掌範囲ではシェアド・リーダーシップを採用しました。

「シェアド・リーダーシップのチームを下から支えるマネージャー」として私自身はサーバント・リーダーシップのスタンスをとっており、3つのリーダーシップスタイルを使い分けている状態です。

チーム自体は、チームトポロジーでいうところのストリームアラインドチームにあたります。人数は10名未満で、6〜8件の案件を同時に進めています。注 4

実際どのように試したのか

まずは 1on1 でメンバー1人ひとりにリードしたい案件をヒアリングし、案件ごとにリーダーをアサインしました。

ヒアリングした際の質問は以下の通りです。

  • 3年後のありたい姿 (スキルやポジション)

  • 半年後のありたい姿 (スキルやポジション)

  • 注力したい領域

  • 解決したい課題

  • 取り組みたい案件

リーダーの主な役割は以下の辺りになります。

  • ビジネス部門、PdM、PjM、SRE、QA、他開発チームとの窓口

  • PdMがPRDのたたき台を作成する際の壁打ち役

  • アーキテクチャのたたき台作りと合意形成

  • タスクの分解とアサイン

  • 他チームとの擦り合わせMTGの設定とファシリテーション

  • Daily Stand-Up でのファシリテーション

リーダーとフォロワーの組み合わせは以下のようになっています。

  • 案件Xでは、Aさんがリーダー、BさんとCさんはフォロワー

  • 案件Yでは、Bさんがリーダー、AさんとCさんはフォロワー

  • 案件Zでは、Cさんがリーダー、AさんとBさんはフォロワー

ここでいう「案件」は、「ビジネス起因の取り組み」だけではなく、リアーキテクチャや性能改善等「エンジニアリング起因の取り組み」も含みます。

「特定のドメイン知識や技術領域の強み」を元に案件のリーダーを決めるケースが多いですが、「本人の案件への関心度や意欲」も重要なファクターとなっています。

案件は3〜4名のグループで動くことが多いです。必要に応じてチーム全体に情報を同期すべく「案件共有会」を実施しています。これによって前提がそろい、直接携わっていない案件のレビューがある程度スムーズになります。

新規案件が多い時期は、一時的に認知負荷が高くなるという課題も抱えています。

1人で開発できる規模の案件では、孤立や属人化を防ぐため他案件のメンバーとペアを組み、リーダーとフォロワーの関係を形成すると良さそうです。
（これはスクラムマスター @moriyasu0410 さんの発案で、今後試していく予定です。）

現時点の仮説

2024年9月時点の私たちが考える最適解は以下の通りです。

  • 開発組織全体 (100名以上) では、ピラミッド型の構造と従来型のリーダーシップを維持

  • 1チームは できる限り 6〜8名を維持 (会議で全員が発話でき、1~2名の入退場を吸収でき、オンコールの当番を負担なく回せること)

  • 1チームが同時に携わる案件の最大数はチームの人数未満

  • 1チーム内で案件ベースの仮想チームを2〜4名で形成し、シェアド・リーダーシップを発動

  • 仮想チームは案件のサイクルで有機的に結成・解散

  • 特定のドメイン知識や技術領域の強み、案件への関心や意欲でリーダーをアサイン

  • チーム全体に情報を同期するため案件共有会を開催

  • 1人でできる案件の場合も他案件のメンバーとペアを作り孤立化・属人化を防止

現時点のリーダー育成フロー

1. チームのセキュアベース化

  • 自己開示できる仕組みと場づくり

    • ニコニコカレンダー

    • Good & New

    • シャッフル1on1

    • 分報

  • 互いの期待値の擦り合わせ

    • ドラッガー風エクササイズ

  • 感謝を伝え合う文化の醸成

    • ふりかえりのフォーマット

2. チームの意思決定基準の明確化

  • チームの存在意義や方針

    • インセプションデッキ

3. 仮リーダー体験の日常化

  • 場の準備やリードをする側の経験

    • ファシリテーションの輪番化

    • イベントの取りまとめ役

    • オンボーディングのメンター

4. 部門を越境したステークホルダーとの関係強化

  • 気軽に相談できる関係性づくり

    • シャッフル1on1 (Biz、PdM、PjM、QA、SRE、対向先チームのエンジニア etc)

5. 部門を横断した案件リーダー経験の増加

  • サポート体制

    • 類似案件のリーダー経験者がフォロワーとして新リーダーを後援

エンジニアリングマネージャーとしてのあり方

スタンス

書籍「リーダーシップ・シフト」の中で、全員がフラットに話せる状態を作り出すために、マネージャーが以下のようなスタンスでメンバーと目線合わせをすることを重要視しています。注 5

  • 自分の長所、短所、得意、不得意を知り、正しい自己認識を持つこと

  • アイデアやアドバイス、フィードバックを受け入れること

  • メンバーの強みに注目すること

  • メンバーから学ぶことにオープンであること

  • メンバーの貢献を評価・強調すること

メンバー1人ひとりの長所を最大化するために、特に私が重視しているのは以下の2点です。

  • メンバーの強みに注目すること

  • メンバーの貢献を評価・強調すること

役割

方向性のファシリテート

  • 個人のパフォーマンスを最大化できるよう、モチベーションの源泉をヒアリング

  • チームの成果を最大化できるよう、方向性を統一する取り組みを継続的に開催

情報の流通

  • チーム外へ輸出

    • 説明責任を果たせるよう全案件の進捗と要点を把握し共有

    • 全仮想チームの6ヶ月先までのリソース状況を見える化し共有

    • メンバーの貢献を共有

  • チーム内への輸入

    • 「経営者視点の情報」を共有

    • 「他チームの現状や取り組み」を共有

次のステップ

今後、以下の取り組みと言語化を進めていく予定です。

終わりに

最後までお読みいただき、ありがとうございました。

現在、シェアド・リーダーシップにトライしていますが、あらゆる場面やあらゆる組織でフィットするスタイルとは考えていません。

震災等の緊急時には、強力な個人によるトップダウンのリーダーシップが適切な場合もあるでしょう。また、海外の論文ではシェアド・リーダーシップのマイナス面も研究されています。

プラスとマイナスを踏まえ、実践を通じてブラッシュアップした上で、登壇の形で発表していく予定です。

RSGT 2025 でプロポーザルが採択された場合は、最新の実践結果を発表しますので、ご興味のある方は以下のリンク先でログイン後に Like を押していただけると嬉しいです！
➡ 全員が活躍するチーム作り 〜シェアド・リーダーシップへの挑戦〜

建設的なご意見 もお待ちしています！

それではまた！！

参考

いいなと思ったら応援しよう！