Upgrade to Pro — share decks privately, control downloads, hide ads and more …

職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team ...

Avatar for MADOX MADOX
March 07, 2025

職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position

Scrum Fest Fukuoka 2025

Avatar for MADOX

MADOX

March 07, 2025
Tweet

More Decks by MADOX

Other Decks in Technology

Transcript

  1. © GO Inc. 2 プロフィール写真 自己紹介 GO株式会社 バックオフィス基盤開発部 部長 菅原

    円 (すがはら まどか) 2023年 2月 入社以来、主に決済基盤の開発に従事 2024年 4月 決済基盤のエンジニアリングマネージャーに就任 2024年12月 バックオフィス基盤開発部の部長に就任 MADOX @madoxten まどっくす
  2. © GO Inc. ※   は当社の登録商標です。 11 2022年9月 1000万ダウンロード突破! 2024年10月 2500万ダウンロード突破!

    2021年11月 法人向けタクシー配車管理 『GO BUSINESS』リリース 2021年10月 500万ダウンロード突破! 2020年4月 Mobility Technologies誕生! 2023年4月 「GO株式会社」に商号変更 『GO』四半期別タクシー実車数 『GO』累積ダウンロード数 2020年9月 『GO』アプリ 全国11エリアでスタート ダウンロード数 (25年2月) 2700万 利用可能エリア 46都道府県 ネットワーク事業者数 1100社以上 年間実車数 (22年6月-23年5月) 6000万回 No1※ タクシーアプリとして成長中 ※Sensor Tower by data.ai調べ - タクシー配車関連アプリにおける、日本国内ダウンロード数( App Store/Google Play合算値) - 調査期間: 2020年10月1日~2024年12月31日 2024年9月 2000万ダウンロード突破! ー 実車数とダウンロード数推移 ー 『GO』アプリの事業成長
  3. © GO Inc. 12 『GO』アプリの開発 タクシー会社向け 管理画面 乗務員向けアプリ 後部座席アプリ 乗務員向け

    ポータル画面 乗客向けアプリ 決済系サーバ群 支払請求系サーバ群 社内向け 管理画面 ジオ・AI系サーバ群 配車系サーバ群 法人向け 分析系 「タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践」 https://speakerdeck.com/mot_techtalk/takusiapuri-go-niokerupuratutohuomuenziniaringunoshi-jian
  4. © GO Inc. 13 『GO』アプリの開発 タクシー会社向け 管理画面 乗務員向けアプリ 後部座席アプリ 乗務員向け

    ポータル画面 乗客向けアプリ 決済系サーバ群 支払請求系サーバ群 社内向け 管理画面 ジオ・AI系サーバ群 配車系サーバ群 法人向け 分析系 • 10以上の開発チーム • 100人以上の開発者 • 100以上のマイクロサービス 「タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践」 https://speakerdeck.com/mot_techtalk/takusiapuri-go-niokerupuratutohuomuenziniaringunoshi-jian
  5. © GO Inc. 15 『GO』アプリの開発組織の構造 『GO』アプリ AIドライブ レコーダー GX (CO2削減)

    人材 地図データ サービス 複数の事業部門 x 横断部門のマトリクス構造
  6. © GO Inc. 『GO』アプリ AIドライブ レコーダー GX (CO2削減) 人材 地図データ

    サービス 16 『GO』アプリの開発組織の構造 複数の事業部門 x 横断部門のマトリクス構造 開発本部 (エンジニア) プロダクトマネジメント本部 (PdM, PjM, QA, デザイン, 分析/BI) IoT本部 (エンジニア) 事業部専属 (エンジニア) 事業部専属 (エンジニア) 事業部専属 (エンジニア)
  7. © GO Inc. 17 『GO』アプリの開発組織の構造 『GO』アプリ AIドライブ レコーダー GX (CO2削減)

    人材 地図データ サービス 複数の事業部門 x 横断部門のマトリクス構造 開発本部 (エンジニア) プロダクトマネジメント本部 (PdM, PjM, QA, デザイン, 分析/BI) IoT本部 (エンジニア) 事業部専属 (エンジニア) 事業部専属 (エンジニア) 事業部専属 (エンジニア)
  8. © GO Inc. 21 1チーム体制 (6人) 入社当時 リーダー • 全員がエンジニア

    (スクラムマスターがエンジニアを兼務) • 3〜4件のプロジェクトが並走 • リーダーはキープレイヤーとして活躍 自分 Aさん
  9. © GO Inc. 22 1チーム体制 (13人) 人数が倍以上に増える • 扱う領域、プロダクト、仕事量が増加 (7件ほどのプロジェクトが並走)

    • ミーティングの時間が増加 (開発に充てられる時間が減少) • 「Aさんしかわからない」が増え、属人化 • リーダーの最終レビュー待ちが増えスタック リーダー 自分 Aさん
  10. © GO Inc. 25 サブチーム体制 (13人) 3つのサブチームに分ける リーダー サブ サブ

    サブ • リーダーへの負担を減らすためにサブリー ダーを置きサブチーム体制へ • そしてサブチームごとにミーティングも分割 自分 Aさん
  11. © GO Inc. 26 サブチーム体制 (13人) 情報の壁ができ、サイロ化してしまう リーダー サブ サブ

    サブ • サブチーム間でやっていることが見えにくく なり、別の連携ミーティングが必要に • リーダーはすべてを把握するため全サブチー ムのミーティングに参加 • 属人化は変わらない状況 • リーダーの最終レビュー待ちは引き続きス タック 自分 Aさん
  12. © GO Inc. 27 ☆:エース ◎:得意 ◯:一人前 △:助けがあればできる − :

    できない ↑ : 今後習得したい ↓ :できるけどやりたくない スキルマップ(星取表)でみると依存が一目瞭然 知見の属人化 単一障害点 「スキルマップ作成のすすめ」 https://www.ryuzee.com/contents/blog/7065 Aさんしかわからない (汗) 技術スタックやドメイン知識など一人ひとりのスキルを見える化、チームの強みや弱みを発見
  13. © GO Inc. 29 変化 ここで自分がマネージャーに任命され、リーダーから引き継ぐことに サブ サブ • 引き継ぎではリーダーと日々

    数時間 話し合 い改善の糸口を模索 • そしてリーダーがチームを卒業し 皆でその役割を埋めていくことに 引き継ぎ マネージャー サブ リーダー 卒業 自分 Aさん
  14. © GO Inc. 33 サブチーム体制 (10人以下) 情報の壁を撤廃 • インターンの方たちの卒業もあり、人数が 10人以下へ

    • これを逆にチャンスと捉え、全員でのミー ティングに戻すことに • ミーティングの長さは隔週で見直し、段階的 に削減 (週次MTGは2時間半かかっていたものを1時 間以内へ) マネージャー リーダー リーダー 自分
  15. © GO Inc. 35 サブチーム体制 (10人以下) 弱い領域の解像度アップ • ここでドメイン知識学習会を開始 •

    スキルマップ上の弱い領域から着手 (属人化が強い領域、詳しい人が少ない領域) • 「初心者が整理して発表し、有識者が補足す る」というスタイルで実施 • 初心者ならではの気づきが生まれたり、皆が 質問しやすい雰囲気を醸成 • チーム内の共通理解が増加 マネージャー リーダー リーダー 自分
  16. © GO Inc. 36 サブチーム体制 (10人以下) レビューを各サブチーム内で完結 • 一人のリーダーが最終レビューしボトルネッ ク化していた問題の解決策

    • サブチーム内の2名以上 or その領域に 詳しい人のレビュー&テスト完了でOKに変更 • アーキテクチャのレビューはSREチームへの 相談やレビューを必須化 • サブチーム間ですり合わせ必要な場合は 個別にモブレビューを実施 マネージャー リーダー リーダー 自分
  17. © GO Inc. 38 サブチーム体制 (10人以下) マネージャー(自分)の「ボトルネックになります」宣言 • 期の変わり目で期末評価や目標設定が重なり 自分はミーティングに追われる日々

    • 想定通りマネージャーの自分がボトルネック に • マネジメント業務に注力するため、案件の切 れ目でプレイヤーから離れることを決断 • この状況を見越して、事前に声がけしていた Bさんへの移譲をスタート マネージャー リーダー リーダー 自分 Bさん
  18. © GO Inc. 39 サブチーム体制 (10人以下) 新リーダーへの抜擢 • 他チームとのバーチャルチームでファシリ テーションしたり、開発や運用に高い当事者

    意識をもっていたり、飲み会の幹事を率先し て引き受けてくれたりしていたBさん • 「Bさんならできそうだ」と考え、1on1 で 移譲をすり合わせ • そしてBさんが初めてリーダー役へ挑戦する ことに • 不確実性の高い大きめの案件のため、不安も 大きかったはず • 期の変わり目でバトンタッチ マネージャー リーダー リーダー リーダー 自分 Bさん
  19. © GO Inc. 40 新しくリーダーになる方に伝えたこと 「影響の輪」にフォーカスしよう! 関心の輪 自分がコントロールできること 自分がコントロールできないこと 相手の態度や言動

    自分の態度や言動 他社の 仕様変更 傘 天気 景気 過去の失敗 現在 地震 防災 津波 火山 周囲への関わり方 未来の懸念 親族 影響の輪 加齢 食事 (他社や他部署など) 外的要因に気持ちが 振り回されすぎないよう 「影響の輪」に焦点を当てよう スティーブン・R.コヴィー (2013) 『完訳 7つの習慣 人格主義の回復』 https://www.amazon.co.jp/dp/4863940246
  20. © GO Inc. 41 I (私) We (私たち = 自チーム)

    We (私たち = 周辺チーム) 「影響の輪」にフォーカスしながら、主語を I から We に変えていこう! 新しくリーダーになる方に伝えたこと
  21. © GO Inc. 43 新しいリーダーにどんなステップで移譲していくか 1. 指示する :マネージャーが意思決定をおこない、指示をする 2. 売り込む

    :マネージャーが意思決定したことについてチームを納得させる (説得する) 3. 相談する :マネージャーが決定する前に、チームからの意見を得る 4. 同意する :マネージャーがチームと一緒に決定を下す (対等) 5. アドバイスする :チームに決定権を渡しつつ、アドバイスや意見で影響を及ぼす 6. 問い合わせる :チームの決定後に問い合わせる 7. 移譲する :特に影響を及ぼさず、チームに全て任せる (自分はほぼ一切かかわらない) 権限移譲の7つのレベル 最初は密に話してアドバイス(レベル5)しながら、方向性を擦りあわせて 2〜3ヶ月後には事後に確認する(レベル6)へ移行していこう - “Delegation Poker & Delegation Board” https://management30.com/practice/delegation-poker/ - 「Delegation Pokerで権限移譲について学ぶ」https://www.ryuzee.com/contents/blog/3669
  22. © GO Inc. How を明らかにする Why を明らかにする 49 われわれは なぜここに

    いるのか エレベータ ピッチ パッケージ デザイン やること やらないこと リスト 技術的な 解決策 トレードオフ スライダー 期間を 見極める なにが どれだけ 必要か 「ご近所さん」を探せ 夜も眠れない問題 ✔ ✔ ✔ 目指す方向を明確にしよう インセプションデッキ ✔
  23. © GO Inc. 52 サブチーム体制 (10人以下) 新リーダーの活躍 • 新リーダーBさんが担当した案件は 早い時期で参画したこともあり

    チームの対応範囲を前倒しで完了 • 「まだ余力があるので他のチームの領域も引 き受けます!」となり、チームを越境し新た な領域も開発 • 抜擢された当時の不安がウソのように頼もし く成長 マネージャー リーダー リーダー リーダー Bさん 自分
  24. © GO Inc. 53 リーダーの大まかな役割 プロジェクト ピープル プロダクト テック PdMがPRDのドラフトを

    作成する際の壁打ち役 アーキテクチャやデータ構造の たたき台作りと合意形成 SREレビューの実施 リーダー タスクの切り出しやアサイン クリティカルパスを踏まえた進捗確認 担当案件の開発の推進役 リーダー リーダー • チーム外との窓口役 (事業部門、PdM/PjM/QA/SRE、他開発チーム) • チーム内外のミーティングのファシリテーション
  25. © GO Inc. 55 新リーダーが模索しながら言語化した役割 • 状態:1人先行して参画 • 目標:できる限りメンバーがすぐ手を動かせる状態まで準備 •

    行動: ◦ PdMがPRDのドラフトを作成する際の壁打ち役 ◦ アーキテクチャ、データ構造の設計 ◦ 事前にメンバーに要件のインプット ◦ 必要に応じてチーム内で壁打ち プロジェクト「黎明期」 ※実際に本人がまとめた内容をほぼそのまま記載しています。
  26. © GO Inc. 56 • 状態:リーダーとメンバーの間で要件や設計の理解に差がある状態 • 目標:迅速にキャッチアップし実装に入ってもらうこと • 行動:

    ◦ チーム外との窓口(メンバーの時間確保のため) ◦ メンバーへの仕様や設計の共有を改めて実施 ◦ メンバーからの質問・相談に第一優先で応答 ◦ 仕様確認のミーティングを頻繁に開催 ◦ 成果物のレビューは認識の齟齬を防ぐため同期的に実施 プロジェクト「初期〜中期」 新リーダーが模索しながら言語化した役割 ※実際に本人がまとめた内容をほぼそのまま記載しています。
  27. © GO Inc. 57 • 状態:リーダーとメンバーの間の仕様理解はほぼそろった状態 • 目標:QA開始時期など、開発工程のクリティカルパスに間に合わせること • 行動:

    ◦ チーム外とのやりとりは該当箇所の開発担当メンバーが対応 ◦ 共通認識ができているため成果物のレビューは非同期で実施 プロジェクト「中期〜後期」 新リーダーが模索しながら言語化した役割 ※実際に本人がまとめた内容をほぼそのまま記載しています。
  28. © GO Inc. 59 案件ベース体制 (10名以下) より柔軟な案件ベースの体制へ • サブチームに案件がアサインされる形から 案件に応じてユニットが結成される体制へ

    (この図では表しきれないけど案件に対して より有機的に人が離散集合する形になる) マネージャー リーダー リーダー リーダー Bさん 自分
  29. © GO Inc. 60 案件ベース体制 (10名以下) さらなる新リーダーの誕生 • 新リーダーBさんの案件と並行して Cさんが新たな案件のリーダーに

    • 0->1の立ち上げをやりたいという内発的動 機を Cさんとの1on1で把握 • 新規機能の追加や既存機能の改修ではなく、 新規プロダクトの立ち上げプロジェクトに挑 戦することに • このプロジェクトも順調に進み、実は今週無 事リリース済 • さらにDさんが別の新規プロダクト立ち上げ のリーダー役へ マネージャー リーダー リーダー リーダー Bさん 自分 Cさん リーダー 経験者
  30. © GO Inc. 65 出会い 『リーダーシップ・シフト: 全員活躍チームをつくるシェアド・リーダーシップ 』 • 一人ひとりの強みの領域でリーダーシップを発揮する

    • 他のメンバーがリードする領域でフォロワーシップを発揮する • リーダーとフォロワーが流動的に入れ替わる • 組織として「リーダーシップの総和」を最大化する - 堀尾 志保, 中原 淳 (2024) 『リーダーシップ・シフト 全員活躍チームをつくるシェアド・リーダーシップ』 https://www.amazon.co.jp/dp/4800592100
  31. © GO Inc. 68 出会い 『指導力革命: リーダーシップからフォロワーシップへ 』 • 絶版になった名著

    (稀に図書館に眠っている、今なら Amazon で 5万4000円〜) • 模範的なフォロワーの条件は 「独自のクリティカルシンキング」と「積極的な関与」の両方を兼ね 備えていること • これらの度合いに応じて、フォロワーを5タイプに分類している 孤立型、消極的型、順応型、実務型、模範型 - ロバート・ケリー (1993) 『指導力革命: リーダーシップからフォロワーシップへ』 (牧野 昇 訳), プレジデント社. https://www.amazon.co.jp//dp/4833415097
  32. © GO Inc. 69 模範的フォロワーの特徴 積極的な 関与 消極的な 関与 独自のクリティカル・シンキング

    依存的・無批判な考え方 模範的 フォロワー 孤立型 フォロワー 順応型 フォロワー 消極的 フォロワー 実務型 フォロワー 20 40 20 40 0 60 0 60 • 組織のミッションや目標に沿った付加価値の大きな仕事 に注力する • その実現のためにリーダーにNOと言える • クリティカルパス(プロジェクトを進める上でスケ ジュールに影響がでる作業経路) を分析・特定する能力 に長けている • 守備範囲以上の仕事をこなす • 専門の知識・技術に磨きをかけている • 新しいアイデアに挑戦する • 仲間やリーダーをサポートする • 組織的ネットワークを作る • 自分が生んだ価値を整理し言語化して残す (利益向上、コスト削減、品質向上 etc) 『指導力革命: リーダーシップからフォロワーシップへ』P.99 の図を元に作成 出会い - ロバート・ケリー (1993) 『指導力革命: リーダーシップからフォロワーシップへ』 (牧野 昇 訳), プレジデント社. https://www.amazon.co.jp//dp/4833415097
  33. © GO Inc. 81 異なる状況のチームをマネジメントする立場に 決済・会計・管理画面 事業者向け管理画面 支払請求基盤 決済基盤 リーダーとフォロワーが

    案件ごとに入れ替わる形 複数のチームを越境した開発組織作り 一人のリーダーによる マイクロマネジメントの状態 サブチーム体制による サイロ化が進んだ状態 自分 自分
  34. © GO Inc. 82 色んな方にヒアリングして得た声 決済・会計・管理画面 事業者向け管理画面 支払請求基盤 決済基盤 複数のチームを越境した開発組織作り

    自分 自分 隣のチームとの連携部分に携 わったので、もっと隣のドメ イン領域を深めたい 会計について 学んできたので その領域を深めたい 同じチームでの在籍が長く なってきたので、隣のプロダ クトの開発に直接関わりたい
  35. © GO Inc. 83 複数のチームを越境した開発組織作り 『ダイナミックリチーミング 第2版: 5つのパターンによる効果的なチーム編成 』 •

    RSGT2024 基調講演のスピーカー Heidi Helfand さんの著書 • チームの構造を変更する際に見られる基本的な5つのパターンを紹介 • 翻訳レビューに参加 • 2025年3月26日 発売予定 • 詳細はぜひ購入して把握してください! - Heidi Helfand(2025) 『ダイナミックリチーミング 第2版: 5つのパターンによる効果的なチーム編成』 (永瀬 美穂, 吉羽 龍太郎, 原田 騎郎, 細澤 あゆみ 訳) https://www.oreilly.co.jp/books/9784814401079/
  36. © GO Inc. 84 互いの良い部分の融合 (現在進行中) 決済・会計・管理画面 事業者向け管理画面 支払請求基盤 決済基盤

    チームメンバーの ニーズやウォンツとも マッチしている 複数のチームを越境した開発組織作り 自分 自分 ダイナミックリチーミングの スイッチングのパターンを 適用し、互いのチームで 1名ずつの交換をしていこう
  37. © GO Inc. 85 複数のチームを越境した開発組織作り 1. 指示する :マネージャーが意思決定をおこない、指示をする 2. 売り込む

    :マネージャーが意思決定したことについてチームを納得させる (説得する) 3. 相談する :マネージャーが決定する前に、チームからの意見を得る 4. 同意する :マネージャーがチームと一緒に決定を下す (対等) 5. アドバイスする :チームに決定権を渡しつつ、アドバイスや意見で影響を及ぼす 6. 問い合わせる :チームの決定後に問い合わせる 7. 移譲する :特に影響を及ぼさず、チームに全て任せる (自分はほぼ一切かかわらない) 権限移譲の7つのレベル 失敗体験 →当事者本人には 決定権を渡しつつアドバイスし  マネージャーやリーダー陣には事前に相談してスムーズに進んだが... - “Delegation Poker & Delegation Board” https://management30.com/practice/delegation-poker/ - 「Delegation Pokerで権限移譲について学ぶ」https://www.ryuzee.com/contents/blog/3669
  38. © GO Inc. 86 複数のチームを越境した開発組織作り 1. 指示する :マネージャーが意思決定をおこない、指示をする 2. 売り込む

    :マネージャーが意思決定したことについてチームを納得させる (説得する) 3. 相談する :マネージャーが決定する前に、チームからの意見を得る 4. 同意する :マネージャーがチームと一緒に決定を下す (対等) 5. アドバイスする :チームに決定権を渡しつつ、アドバイスや意見で影響を及ぼす 6. 問い合わせる :チームの決定後に問い合わせる 7. 移譲する :特に影響を及ぼさず、チームに全て任せる (自分はほぼ一切かかわらない) 権限移譲の7つのレベル 失敗体験 →一部の方への共有が後手にまわり、決定事項として伝える形に。  ハレーションが大きかったため、書籍にある通りメンバーの方たち全員の気持ちを踏まえた進め方の大切さを痛感。 - “Delegation Poker & Delegation Board” https://management30.com/practice/delegation-poker/ - 「Delegation Pokerで権限移譲について学ぶ」https://www.ryuzee.com/contents/blog/3669
  39. © GO Inc. 88 今後の仮説や展望 決済・会計・管理画面 事業者向け管理画面 支払請求基盤 決済基盤 複数のチームを越境した開発組織作り

    自分 Agile Framework FAST が やりたいことと近いのではないか、 という仮説があるが ここはまだわからない状況 すでにこの2つのチーム間で 越境して一気通貫で開発する 動きが出始めている 開発環境などの統一化を進め 技術スタックやドメインが 近しい領域で 流動的に移動しやすい形へ - bonotake さん Emi さん主催の「人類にはまだ早い」フレームワークFASTを体験しよう!」に運営として参加し会場提供させていただきました https://setagagile.connpass.com/event/341601/
  40. © GO Inc. 90 今後の仮説や展望 ソフトウェア開発統括部 『GO』アプリ 『GO』アプリのバックエンド Web 決済・会計・管理画面

    複数のチームを越境した開発組織作り 自分たち 事業のコアドメインのため 複雑度が高いプロダクトを抱えている ホットスポットになりやすく リリースに影響が出やすい
  41. © GO Inc. 91 今後の仮説や展望 ソフトウェア開発統括部 『GO』アプリ 『GO』アプリのバックエンド Web 決済・会計・管理画面

    複数のチームを越境した開発組織作り ドメイン領域や技術スタックが近い チーム間で越境する動きは すでに出始めている これをより柔軟におこなっていきたい
  42. © GO Inc. • 水戸 祐介 (2024) 「タクシーアプリ 『GO』 におけるプラットフォームエンジニアリングの実践」

    https://speakerdeck.com/mot_techtalk/takusiapuri-go-niokerupuratutohuomuenziniaringunoshi-jian • 吉羽 龍太郎 (2016) 『スキルマップ作成のすすめ』 Ryuzee.com https://www.ryuzee.com/contents/blog/7065 • スティーブン・R.コヴィー (2013) 『完訳 7つの習慣 人格主義の回復』 https://www.amazon.co.jp/dp/4863940246 • “Delegation Poker & Delegation Board” Management 3.0 website https://management30.com/practice/delegation-poker/ • 吉羽 龍太郎 (2011) 『Delegation Pokerで権限移譲について学ぶ』 Ryuzee.com https://management30.com/practice/delegation-poker/ • 堀尾 志保, 中原 淳 (2024) 『リーダーシップ・シフト 全員活躍チームをつくるシェアド・リーダーシップ』 日本 能率協会マネジメントセンター. https://www.amazon.co.jp/dp/4800592100 • ロバート・ケリー (1993) 『指導力革命: リーダーシップからフォロワーシップへ』 (牧野 昇 訳), プレジデント社. https://www.amazon.co.jp//dp/4833415097 • Heidi Helfand(2025) 『ダイナミックリチーミング 第2版: 5つのパターンによる効果的なチーム編成』 (永瀬 美 穂, 吉羽 龍太郎, 原田 騎郎, 細澤 あゆみ 訳), オライリー・ジャパン. https://www.oreilly.co.jp/books/9784814401079/ 117 参考