◾️Summary
本トークでは、私がグローバルチームをリードするうえで大切にしてきた視点と、そのプロセスを取りまとめ、
「グローバルを前提としたチームをどのように導き、組織としてのアウトプットをどのように高めていったのか」というテーマを中心にお話しします。
扱うのは特定の理論ではなく、チームの思考や対話の流れが整い、理解と協働が累積していくような“組織の下層構造”をどのように形づくるかという視点です。
リードとしてその流れを支え、チームで育てていったかを共有したいと思っています。

◾️Why
<なぜこのトークを行いたいと思ったか>
グローバルチームを率いるというと、特別な経験や高度なスキルが必要だと捉えられがちです。
しかし私自身、留学や英語圏で在住する経験が特にないですが、グローバルチームのリードを担っています。
実際にチームと向き合う中で強く感じたのは、チームが力を発揮する鍵は、“語学力”や“海外での過ごし方”よりも、組織としての理解と関係性の土台を整えていくことにあるという点でした。
土台が整っていけば、多様なメンバーは自然と協働し、チームとしての動きが育っていきます。これは特定の経歴や能力に依存するものではなく、誰にとっても再現可能な導き方だと感じています。
だからこそ、留学経験がなくても、英語が得意でない方、社会に出てから興味を持ち始めた人でも、グローバルな環境を率いることは十分に可能であるということを伝えたいと思いました。
多様なメンバーと向き合いながらチームを導く人、これからその一歩を踏み出そうとする方に向けて、私が実際に行ってきたリードの視点を共有したいと考えています。

◾️Learning Outcome
<このプロポーザルを聴いてほしい方>
・海外経験があってもなくても、グローバルや多文化チームを率いたい人
・言語・文化の違いでチームの足並みが揃わず困っているEM / リード
・“自走するチーム”の作り方を抽象原則として学びたい人

<得られるもの>
・「経験の差」ではなく「構造」でチームは変わるという視点
・非同期 × 多拠点でも機能するコミュニケーション
・チームが自ら学び、挑戦し、成長し続けるための“越境デザイン”の考え方
・個人の行動をチーム文化へ広げるための、定着・巻き込みのアプローチ

概要

多くの組織では、EM の役割が People Management に偏りがちです。
メンバーの育成や開発者体験の改善に力を注ぐ一方で、PdM が担う事業価値の実現とは衝突してしまう。
結果として「チームとしてどこを目指すのか」が分断される──そんな状況を、私も何度も見てきました。

それに対し私自身は、EM として Tech Lead に PdM 相当の Product Management を託し、共に伴走した経験や、
TPM（Technical Product Manager）として EM と協働した経験から、
4軸（Product / Project / People / Technical）を一貫してマネジメントする重要性を体感してきました。

現在は、家族アルバム「みてね」の CRE グループで、EM としてこの4軸を横断的にマネジメントしています。
4軸を“同じ物差し”で設計・運用することで、チーム目標と個人評価、事業成果と組織成長を自然にそろえ、各マネジメント領域が衝突せず、チーム全員が同じ景色を見られるようになりました。

本トークでは、この実践から得た以下のポイントを具体的にお話しします。

• 各軸の階層構造（Product を上位に据えた価値主導設計）
• People / Project / Technical の3領域を事業価値に接続する考え方
• 半期から週次までをつなぐ一貫したチーム運用リズム

「People だけを見る EM」から脱し、“4軸統合EM”としてチームと事業の両方をマネジメントする実践知を共有します。

Learning Outcome（聴講者が得られること）

対象

EM、PdM、TPM、VPoE / CTO

得られるもの

• People だけでなく Product / Project / Technical を含めたマネジメント設計
• 4軸を階層的に捉えた一貫性あるチーム運営モデル
• OKR を活用した目標と評価のつながり
• 技術的負債返済・人材育成・事業インパクトを両立させる運用リズム
• チームが事業価値を自ら定義し、成長を実感できる仕組み化のヒント

サイボウズの開発組織は長らく「職能軸 × プロダクト軸」のマトリクス型体制を採用していました。ソフトウェアエンジニア、QA、デザイン、プロダクトマネージャーなどの専門職能ごとに組織が構成しており、各部門のマネージャーは職能組織の運営や人材育成を中心に責任を持ちます。この構造は社員の専門性を伸ばしやすい一方で、部門マネージャーの製品開発への関与は部分的になりやすいという側面を抱えていました。

その結果、開発現場では次第に構造的な課題が表面化しました。

• エンジニアチームによる成果物に対する責任主体が曖昧になる
• 不確実性の高い物事を進めるうえで、マネージャーとしての権限が製品開発に十分発揮されない
• 技術的な意思決定を含め、判断がプロダクトマネージャーに集中する

私たちはより事業インパクトの大きな活動を増やすために、これらの課題を組織的に解決する試みを始めました。組織構造とマネージャーの役割を見直し、チームとその成果物に責任を持つエンジニアリングマネージャー（EM）を任命しました。 エンジニアチームは自分たちの成果物にオーナーシップを持ち、EMはチームの成果最大化に責任を持ちます。

これまでのマネージャーはピープルマネジメントだけではなく、プロセスマネジメント、技術マネジメント、プロダクトマネジメントなどの役割を担い、チームの事業貢献を大きくしました。エンジニアチームは事業インパクトの大きな取り組みに挑戦できる機会が増え、魅力的な機能アップデートが増えました。

本セッションでは、サイボウズがどのようにしてEMという役割を組織に根付かせ、その変化が組織にもたらした成果について、実践とストーリーを交えて紹介します。

Learning Outcome

対象となる聴衆

• エンジニアリングマネージャー（EM）や開発組織のマネージャー
• 開発組織の組織づくりに携わっている人

得られるもの

• EM体制を立ち上げ、根付かせるプロセスのユースケース
• サイボウズのEMの役割

概要

技術統括責任者に就任し、技術戦略の立案が求められたとき、エンジニアとして持っていた事業理解の浅さを痛感しました。
プロダクト開発などで理解できていると思っていた事業の解像度では、経営上の技術戦略を立案するに際して経営層を説得できる戦略は描けません。
この理解度の乖離を埋めるため、以下7つのアプローチで事業理解を深化させました：

1. 創業経営者への事業変遷ヒアリング：入社前から現在までの会社の歴史と意思決定の積み重ねを理解
2. 事業部長との関係構築：定期的なコミュニケーションを通じて各事業の目指す方向性を把握
3. 財務状況の自己学習：事業別P/L、5ヵ年計画から事業の現状と見通しを読み解く
4. 収益モデルの因数分解：各事業のビジネスモデルから、技術やプロダクトが貢献できる箇所を特定
5. 外部環境調査：競合・市場動向の把握
6. 顧客との直接接触：商談同席、顧客アポによるリアルな課題理解
7. リーンキャンバス作成：特に顧客視点でのキャンバス作成により解像度を劇的に向上

また、この過程で得た学びをエンジニア組織全体に展開し、個人の学習を組織の資産に変える取り組みも実施しました。
表面的な理解から経営視点での事業把握へと昇華させることで、事業理解に基づいた技術戦略立案ができる土台を構築しました。

想定リスナー

• 事業戦略と技術戦略の接続に課題を感じているEM
• 技術統括責任者として経営層との対話に悩んでいる人
• 事業理解を深めて技術判断の質を向上させたいエンジニアリングマネージャー

Learning Outcome

• 事業理解の実践手法：各アプローチの具体的な実施方法、得られる情報、注意点など
• 技術戦略立案プロセス：事業理解を技術戦略に昇華させる思考プロセスと、経営層への説明責任を果たすフレームワーク
• 組織展開の手法：個人の学習を組織の資産に変える取り組みなど、エンジニア全体の事業理解度向上の方法論
• EMの視点転換：エンジニア視点から経営視点への思考の転換点と、その後の判断基準の変化の実体験
• 失敗談と教訓：試行錯誤の過程で得た気づきと、もっとうまくできたであろう改善点の共有

概要

本セッションでは、「どうすれば自分がいなくても組織が回るようになるのか」というある意味ものぐさな考え方が、組織を拡大して成長させるためにどのように有効に作用してきたのか、6年間の経験に基づいてご紹介いたします。

私は2019年に4名の内製化チームを立ち上げ、そこから商材化やさまざまな活動を経て現在はおよそ20名の内製組織（仮設）の代表を担っています。立ち上げ当初はやらなければいけないことが多く、私はプロダクトオーナーでありスクラムマスターでもあり、エンジニアでもありました。当然のようにその状態のままスケールできるはずもなく、人が増えても困難な働き方が続きました。

そこで私は負担を減らすために、自分のやってきたことを委譲できるようにメンバーを育成することにしました。それを繰り返していくうちに自分の時間が少しずつ生まれてきました。

興味深いことに、その時間によって私が発見したことは、さらなる組織の課題であり次にすべき新たなことでした。スペースが生まれることで今まで見えていなかった問題が見えるようになったということです。当然その課題解決に勤しむことになり、また忙しくなります。

この後は想像に難くないかもしれません。同じことの繰り返しです。現状の負担を減らすために今やっていることを委譲できるようにしてきました。その結果余裕＝スペースが生まれます。つまりそれによってまた更なる課題が見えてきます。

単純に考えると、自分がいなくても組織が回るようになったとき、次はその時間をつかって組織を成長させます。そうするとまた自分がいないと回らなくなります。これが繰り返されることによって組織が成長します。この考え方の嬉しいことは、このサイクルにおいて動作の主体が自分である限り、内発的動機に従って意欲的に働ける側面があることです。

本論ではより具体的なエピソードを踏まえて詳細にお話しいたします。

Learning Outcome

• 忙しくて辛い、という状況からの意欲的な抜け出し方
• マネジメントという業務を別視点から捉え直すきっかけ
• 楽をしようという考え方は楽になるのではなく意欲的になれるということ

📍概要
成長期、過渡期の組織において、EMが採用、技術広報といった専門領域外の業務まで幅広く兼任する状況はよくある話なのではないかと考えます。（あるあるー！）

私自身、ものづくりを主務とするチームのEMをしながら、バックオフィス、社内イベント運営、採用、広報といったEngineering Office機能を持つチームのマネージャーを現在進行系で担っています。向き合う業務も所属メンバーのバックグラウンドも様々である中で、この経験からこそ得られた知見や生存戦略があります。
担う業務の幅からEMは「なんでも屋さん」と表現されることもありますが、そこから得た経験をEMとしてのキャリアを異なる領域、もしくは次のステージに進める「武器」となるのではないかという切り口で紹介したいです。
例えば、業務幅が広く属人化していたEngineering Office機能に対し、「ものづくりにおけるプロセスとゴール設定の明確化」の型を持ち込みました。具体的には、明確なゴールや判断軸の設置、透明性を高める取り組み、実験的なペアワークなどを行うことで、個人のプロフェッショナル性への依存を減らし、チームとしての価値を最大化する取り組みを行っています。

上記のような事例から得た気づきや失敗を交えながら、以下のようなテーマに沿ってお話します。

• これまでの経験とは異なる分野、専門領域外であるチームにEMがマネージャーとして入り込んでいくにあたってのマインドセットや振る舞い
• これまでのEMの経験から何を「武器≒マネジメントの型」とし抽象化、再利用をすることができたか
• その型がもたらした効果/効能

🍕聞いていただいた方へのテイクアウェイ
組織拡大、状況の変化量が大きい過渡期のEMに起きうるリアルな事象を指し、EMの経験を生かした普遍的なマネジメントスキルとして言語化し、再現性を持って立ち向かえる気付き、知見をお持ち帰りいただきたいです。

🎯想定聴衆
・EM/VPoE/CTO: 成長期組織において、採用、広報、組織運営といった専門領域外の業務を兼任しており、業務の幅をキャリアの資産として体系化したいリーダー層
・技術広報およびEngineering Office担当: エンジニアリング組織内のバックオフィス業務や広報を担当しており、EM視点のプロセス改善や他社の事例を知りたい方

インフラエンジニア、DevOps エンジニア、SRE、そしてプラットフォームエンジニア──企業によって呼び方は違えど、会社としてその役割を担うチームやエンジニアが存在しています。サイボウズにも、製品開発が利用する開発環境や、お客様に提供する本番環境の基盤を支えるチームがあります。私たちはその開発、運用、保守、そして信頼性向上に力を注いできました。

開発組織全体に目を配ると、以前から気付いていた課題がありました。複雑な開発フロー、属人化した作業、長いビルド時間など。これらは“なんとなく困っている”状態として常に存在していました。問題を認識しながらも、プラットフォーム側で体系的に解決する文化が十分に根付いていなかったのです。そこで私たちは、プラットフォームを「利用する側」への価値提供を意識することで、組織全体の開発生産性が向上すると考えました。

2025年に、チーム内外でその考え方を共有できるように、自分たちの部署を「プラットフォームエンジニアリング」と名を改めました。では「プラットフォームエンジニアリング」の役割は一体何なのでしょうか。それは事業フェーズ、組織規模、アーキテクチャによって様々な形があると考えています。サイボウズでも、自分たちとしてのプラットフォームエンジニアリングを言語化し、自分たちの状況にあった方法で問題解決してきました。またプラットフォームエンジニアリングの文化形成や開発組織のパフォーマンス向上に取り組んできました。

本セッションでは、EMとしてプラットフォームエンジニアリングの役割を定義し、どのような活動や仕組みを通じて文化を形作ってきたのか。そのプロセスと、そこで得られた気づきや学びをお話しします。

Learning Outcome

対象となる聴衆

• プラットフォームエンジニア、SRE、インフラエンジニア
• EM・テックリード・基盤チームのリーダー

得られるもの

• 開発組織で発生していた課題とその解決方法
• プラットフォームエンジニアリング文化を形成するためのサイボウズの取り組み

概要

「自律自走型組織」は理想ですが、単に自由を与えるだけの「甘い自走」は、責任の不明確さや意思決定の停滞といった構造的な問題を引き起こし、最終的にチームの生産性を低下させ、事業の足を引っ張ります。
私自身、この「甘い自走」の失敗により、組織の士気と成果が著しく悪化する危機を経験しました。
その経験から得た最大の教訓は、「自律とは自由ではなく、EMが設計する明確な枠組みと責任がセットで存在して初めて成立する」という真実です。

今回は、この「甘い自走」を捨て、自律型組織を再構築するために組織に導入した独自のマネジメントポリシーをお話しします。
様々な試行錯誤の上での取り組みがもたらした、市場投入速度の向上や開発コスト削減といった具体的な事業成果、そして現場での実践方法を、痛みを伴う失敗例を交えてお話しします。

アジェンダ

1. 「甘い自走」が招いた失敗
   1. 自律型組織における課題と失敗事例（現状確認と課題の分析）
2. 自律型組織の再定義
   1. 自律型組織の課題解決に向けた新たな枠組み（新しい方針や枠組みの共有）
3. 自律型組織を実現する戦略
   1. 成功に導くための具体的アプローチ（具体的な実行計画）
4. 成果
   1. 目指す成果と期待される未来像（期待される成果の明確化と共有）

Learning Outcome

対象の聴衆

• 自律型組織を構築したい、しているエンジニアリングマネージャー（EM）。
• 組織構築に課題を感じているリーダー層。
• チームや組織への関与を強めて事業貢献に繋げたいと考えているプロジェクトマネージャー。

聴衆が得られるもの

• 自律型組織の本質を理解する
  • 「自律」とは単なる自由ではなく、組織の仕組みと責任設計であること
• 独自の戦略的プロトコル
  • 自律を駆動させるための実践的なマネジメントポリシー
• 事業価値への接続
  • 変革が開発リードタイムの短縮や技術的負債解消、開発生産性向上といった具体的な事業成果

概要

ドキュメントは単なる情報共有ツールではなく、組織全体の生産性や競争力を支える「資産」です。
でも多くの組織ではドキュメントが軽視され、まともな管理がされないまま散在し更新されることもなく陳腐化し、日の目を浴びることなくいずれ闇に葬られます。
その結果、プロジェクトの遅延や技術的負債の温床となり、最終的には組織全体足枷となった挙句に士気や成果に悪影響を及ぼします。
EMとしての経験を通じて、私は何度もそのような問題に直面してきました。
その中で、ドキュメントを「組織の最重要資産」として再定義し、とにかく全てを文字に書き起こし（かっこよく言えば運用ルールを構築することで）、プロジェクトの円滑な管理進行や新規参画メンバーのオンボーディング期間短縮、4Keysなど開発生産性指標の向上といった結果に繋げてきました。
今回は、ドキュメントを活用できていない組織が抱えるリスクを明確にし、ドキュメントを中心とした組織運営がどのように技術的負債を解消しつつ組織の生産性を高め、事業貢献できるかを実践的なアプローチや失敗例を交えてお話ししようと思います。

アジェンダ

1. 「書かない組織」のリスクと課題（現状把握）
2. ドキュメントの再定義：単なる記録から「最重要資産」へ（価値の共有）
3. 戦略的ドキュメント・ポリシーの設計と実践（計画と実践）
4. ドキュメントがもたらす具体的な事業成果（成果の共有）
5. AI時代におけるドキュメント運用の未来（未来の展望）

Learning Outcome

対象の聴衆

• 課題（属人化、遅延、情報共有不足）を組織戦略として解消したいEM
• プロジェクトの根本課題を解決して事業貢献に繋げたいプロジェクトマネージャー
• チームや組織の生産性を向上させるための実践的な方法を模索しているリーダー

聴衆が得られるもの

• ドキュメントの価値を再認識する視点
• 独自のドキュメント・ポリシー設計
• 事業価値への接続

■概要
本セッションでは、EMとスクラムマスターが連携して貢献を高めていくために、実際に考え、取り組んだことをご紹介します。

私たちはより良いプロダクト開発組織を目指し、過去5年以上にわたって、大きな組織の変化を進めてきました。
具体的には、プロダクトやメンバーの増加とともに、EMやチームリーダー不在のフラットな組織から、組織を階層化し、EMやリーダーのロールを定義・配置する形へ移行しました。

すると、以前からチームで活動していたスクラムマスターの立ち位置が変化してきました。従来、スクラムマスターは、チームの自己管理、チームビルディング、メンバーのモチベーションといったテーマに主体的に取り組んできました。これらのテーマが、EMロールの責務にも含まれる形で期待されるようになりました。つまり、EMとスクラムマスターの役割が重なってきたのです。そうすると、メンバーによっては「EMがいれば、スクラムマスターは不要なのでは？」と感じる人も出てきました。

しかし、本当にそうなのでしょうか。

私たちは、EMとスクラムマスターは競合して席を取り合うのではなく、協力して手を取り合うことで、一緒に開発組織をより良くしていける役割だと考えています。実際に、EM/リーダーとスクラムマスターとで密に連携することで、価値提供のボトルネックの検知と対応、チームメンバーのスキルアップといった課題に、より効果的に取り組むことができています。

EMとスクラムマスター2人それぞれの目線から、取り組みと得られた成果について、ご紹介します。

■Learning Outcome
スクラムマスターがいる、または置こうとしているエンジニアリング組織のEM：
・スクラムマスターをどのように頼り、連携すると良いか
・スクラムマスターの貢献をどのようにマネジメント・支援すると良いか

スクラムマスター：
・EMがいる組織で、スクラムマスターとしてどのように動くとバリューを出せるか
・EMとうまく連携していく方法

「自分は知り合いが少ないから、リファラル採用はできないな……」
そう思っていませんか？

あるいは、あなた自身は積極的にリファラル採用をしているのに、他のエンジニアが全く動かない。
そんな状況に悩んでいませんか？

私は2年前、メガベンチャーからスタートアップに転職し、初めてエンジニア採用の現場責任者を務めました。
人的・金銭的リソース、そして会社の知名度の面で大手企業に敵わない状況の中、
「この環境で成果を出せる採用手法は何か？」を考え抜いた結果、リファラル採用に行き着きました。

本セッションでは、それまで積極的にリファラル採用をやってこなかった私が、
毎月3件ペースで候補者にお会いし、そのうち約半数に選考に進んでもらえるようになった具体的な「はじめの一歩」をお伝えします。
さらに、自身の行動だけでなく組織全体にリファラル採用を文化として根づかせるために行った取り組みについて、
成功・失敗の両面から具体的にお話しします。

アジェンダ（予定）

• 自身がリファラル採用を行うためにやったこと
  • 「受動」から「能動」への意識の切り替え
  • SNSやブログでの情報発信
  • 声をかけたい候補者リストの作成
  • 継続的な会食の実施
• 組織全体にリファラル採用を広げるためにやったこと
  • リファラル会食制度の言語化とアップデート
  • 各メンバーの候補者リスト化支援
  • オンボーディングへの組み込み
  • 継続的な社内発信
  • カジュアル面談の実施マニュアル整備と引き継ぎ
• リファラル採用を行った効果と学び
  • リファラル会食数・応募数・採用数の変化
  • 入社に至らなかった候補者のファン化

想定リスナー

• リファラル採用を「やった方がいい」と思いつつ、まだ踏み出せていないEM・採用担当
• 組織としてリファラル採用を推進したいが、どこから始めるべきか悩んでいるEM・採用担当

得られる学び

• 明日から自分でもリファラル採用を始められる、具体的なアクションとマインドセット
• 組織全体にリファラル採用を根づかせるための、制度設計・コミュニケーション・巻き込み方の実践知

◼︎概要
AIは開発を劇的に効率化し、エンジニアを解放すると期待されました。
しかし、開発現場の現実はどうでしょう？

AIがもたらす「超高速な開発」という要求は、既存の開発手法やマネジメント構造と衝突し、大きな混乱を生みました。単純作業が減った代わりに、人間には大量の意思決定や認知負荷の増大といった「AI疲れ」が蔓延しています。 開発を楽にするはずが、なぜ私たちはこれほど疲弊しているのでしょうか。

本セッションは、この「AI疲れ」の発生源を理解し、 AIとの適切なチーミングを模索した私たちのリアルな失敗と葛藤を共有する物語です。
私たちは、AIが期待された成果を生まず組織が疲弊した過程を詳細に分析し、その経験から一つの結論に辿り着きました。それは、組織の成長フェーズに合わせてAIへの権限委譲レベルをカスタムすることです。

セッションでは、初期の混乱期から成熟期に至るまでのフェーズごとの具体的な戦術を事例とともにお伝えします。AIに振り回されずにその真価を引き出し、自律的に成長できる開発組織を築くための実践的な戦略を提供します。

◼︎Learning Outcome
・ AI疲れを乗り越えた先に、組織にどのような戦略的変化が必要だったかを理解できる
・ 組織の成長フェーズに応じたマネジメントポリシー設計指針と権限委譲レベルを戦略的に策定できる
・ AIを単なるツールとしてではなく、チームの一員として位置づけるための基本的な心構えと原則を理解できる

◼︎Target Audience
・ AI疲れしている方
・ 開発手法に振り回されてしまっている悩みのある方
・ エンジニアリングマネージャーやスクラムマスターをされている方

概要

組織は突然壊れるように見えますが、実際には静かなズレが積み重なり、外部環境の変化や内部の負荷によって一気に表面化します。私はこれまでに2度の組織崩壊を経験しました。1度目はメンバーとして、25名の会社が翌月16名へ縮小する現場に立ち会い、期待役割の曖昧さや採用基準の揺れが組織を不安定にするプロセスを体感しました。

2度目は開発部門の責任者として、より大規模な構造的揺らぎに直面します。外部環境による事業の見直し、急成長期特有の役割・権限設計の不整合、そして組織が大きくなるにつれて起こりやすい認識ギャップの増幅が集積し、結果として約60名の組織が30名規模へ縮小する変化を経験しました。これは特定の誰かの問題ではなく、成長企業で広く起こり得る構造的課題です。

再建の転換点となったのは、制度の刷新よりもコミュニケーションの再設計でした。1on1・定例・意思決定プロセスの透明化、違和感を安全に共有できる場づくりなど、対話の質と量を変える取り組みが組織の再生を後押ししました。また混乱期には「頭では理解しているのに心がついてこない」瞬間が訪れます。その時に私を支えたのは、正解探しより本音で対話し続ける姿勢でした。

本トークでは、崩壊の予兆、構造的要因、再生プロセス、そして混乱期の心の扱い方まで、普遍的に応用できる組織を立て直す技術を共有します。

アウトライン

静かに進行する組織崩壊
メンバーとして体験した初期崩壊（25名→16名）
責任者として直面した大規模な揺らぎ（60名→30名）
再生の鍵──コミュニケーションの再設計
混乱期のリーダーシップと心の扱い方
再生後の“強い組織”が持つ特徴

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

ターゲット

スタートアップ／成長企業の経営者・VPoE・EM
組織が縮小フェーズに入り不安がある責任者
混乱期で心が揺れているマネージャー

このトークから得られる学び

成長企業で起こりがちな役割・権限設計の落とし穴
規模拡大と認識ギャップが引き起こす構造課題
リーダーの心が揺れる時のメンタルマネジメント
崩壊後の再生プロセスと、強い組織に共通する特徴

概要
EM就任から半年、正社員ゼロ・業務委託のみのチームで、私は多くの「教科書通りにいかない」課題に直面しました。
例えば：
・1on1の頻度や深さをどう設計するか
・評価制度やキャリアパスが使えない中でのモチベーション管理
・「チーム」としてのエンゲージメントをどう作るか
・限られた稼働時間の中での信頼関係構築

正社員前提のマネジメント手法が通用せず、失敗も多くありましたが、半年間の試行錯誤を通じて、いくつかの手応えと学びを得ました。
本トークでは、以下のような実践と学びを共有します。
・業務委託メンバーとの関係構築で意識したこと
・契約の枠内でできるコミュニケーション設計
・うまくいった施策、うまくいかなかった施策
・この経験から学んだ「雇用形態を超えるマネジメント」の考え方

完成された成功事例ではなく、現在進行形の試行錯誤を共有することで、同じような状況にいる方や、これからEMになる方の参考になれば幸いです。

Learning Outcome
【対象聴衆】
・業務委託やフリーランスを含むチームをマネジメントする方
・リモート/分散型チームのマネージャー
・これからEMになる方、EM1-2年目の方

【得られるもの】
・業務委託チームのマネジメントで直面する課題と対処の実例
・限られた関係性の中でのコミュニケーション設計のヒント
・試行錯誤から見えてきた「雇用形態を超える」マネジメントの考え方
・「完璧じゃなくても、できることから始める」EM実践例

概要

AI が設計や提案まで担う時代に、エンジニアに求められる力は「正確さ」ではなく「曖昧さの中で意味を構築する力」へと変化しています。

私は当初、スキルマップを拡張し育成を試みましたが、知識を積み上げても成長が止まる瞬間を何度も見ました。
丁寧に説明しても理解されない、文脈が抜けて誤った行動になる──そんな経験から、育成は“スキルの付与”ではなく“思考の構造そのもの”を扱うべきだと気づきました。
試行錯誤の末に辿り着いたのが「理解」「模倣」「認知耐性」の3軸モデルです。

これは性格やスキルではなく、人がどのように理解し、再現し、曖昧さに耐えながら考えるかという“認知の使い方”を捉えるフレームです。
特に一見エンジニアリングと無関係に見える「認知耐性」が、AI時代における判断力と創造性の核にあると分かりました。

本セッションでは、育成がうまくいかなかった理由、3軸の発見、チームで行った分類・観察・トレーニングの実践を共有し、AI時代に必要な「考える力」をどう育てるかを解説します。

アジェンダ（予定）

1. AI時代に育成を語る理由
2. 伝わらなかった経験と最初の違和感
3. スキキルマップ育成の限界
4. 3軸モデルの紹介（理解／模倣／認知耐性）
5. 実践と変化
6. 結論と問い

Learning Outcome

学習成果

・スキルでは説明できない「思考の違い」を3軸で捉える視点が得られる
・3軸モデルを用いた育成・支援・対話デザインのヒントを持ち帰れる
・AI時代に必要な「曖昧さを扱う力」「意味を構築する力」の育て方を理解できる

対象

・育成やコミュニケーションの難しさを感じているエンジニアリングマネージャー／リーダー
・スキル中心の育成に限界を感じている方
・AIと共に“学習する組織”をつくりたいリーダー

業務委託メンバーとの協業において、こんな不安や課題を感じていませんか？
「会社間の文化・責任者の違いで、コミュニケーションが分断されがち…」
「契約形態による制約で、詳細な指示や関与が難しく、チーム連携や情報共有に支障が出がち…」

本セッションでは、楽天カードにおける実体験に基づき、業務委託メンバーを巻き込んだスクラムで直面する具体的な課題を深掘りします。そして、それらを乗り越え、一体感のあるスクラムチームを築く実践的なアプローチをご紹介します。

楽天カードでは以下の具体的なチームビルディング施策を実施しました。
「なりたいチーム」のビジョン共有:
　全員でディスカッションを行い、「どんなチームになりたいか」という共通の目標意識を醸成。
価値観の相互理解促進:
　バリューズカードを用いたワークショップを通じて、お互いの仕事観や大切にしている価値観を深く理解し、心理的安全性を高める。
チームの個性と一体感の醸成:
　チーム名を自分たちで決定することで、チームへの帰属意識と一体感を醸成。
偶発的なコミュニケーションの創出:
　毎日座席をくじ引きで決定する「シャッフル座席」を導入し、ランダムなメンバーとの交流機会を意図的に創出。
非公式な交流の場の提供:
　定期的なチームでのランチや飲み会により、仕事以外の親睦を深め、信頼関係を構築。

これらの多角的な取り組みの結果、チームには以下のようなポジティブな変化が生まれました。
「対等な関係」の構築: 契約形態や所属会社の違いを超え、チームの目標達成に向けた対等な関係が築けました。
スクラムの新たな可能性の発見: スクラムが持つ「自律的な開発」を促す特性は、むしろ業務委託メンバーを含む多様なチーム構成において、その真価を発揮しやすいという新たな気づきを得ました。

本セッションでご紹介するような「偽装請負リスクへの適切な向き合い方」という前提知識と、「意図的なチームビルディング」を組み合わせることで、それらの壁を乗り越え一体感のある、自律的なスクラムチームを築くことができます。

Learning Outcome
対象聴衆
チームビルディングや組織文化の醸成に携わる方
スクラム導入を検討している方

得られるもの
契約形態の壁を越えた一体感のあるチーム構築方法

概要

背景

レガシー改善（クラウド移行、リアーキテクチャ）を実施する上で、スクラムからよりソフトウェア開発に特化したXPに開発手法を変更、定着しつつあった矢先に、AIの進化が急加速して瞬く間に普及しました。
業界的にもAI活用が急務になっており、自社でも生産性の向上のため、XPとAIの共存ではなく共創が必要になりました。

※ スクラムからXPへの移行背景
2024年初めに、レガシー改善（クラウド移行、リアーキテクチャ）をメインで動く組織を編成。
システム改善は事業的な不確実性が少ないため、スクラムよりソフトウェア開発に特化したXPに移行した。

内容

本セッションでは、XPを実施している開発チームにどうやってAIを普及・定着させ、目標として掲げている開発生産性2.5倍の実現に向けて動いたかをみなさんに共有します。
XPの有名なプラクティスであるペアプロやTDDにおいて、AIの恩恵を受けやすい部分と受けにくい部分に対して、それぞれにどう向き合って、どう改善していったか、
やめる or 続けるの意思決定をしていったのか、を赤裸々に紹介していきます。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

対象の聴衆

• 既存の開発スタンスを、AI活用でさらに最適化したいと悩んでいる人
• 組織のAI向き合いについて悩んでいる方
  • 導入検証
  • 文化定着
• AIが組織に与える影響について知見や事例の情報がほしい人

得られるもの（持ち帰ってほしいもの）

• アジャイル（XP） x AIで生産性を向上させるヒント
• AIの普及などの組織の変化点にどう対応していったかという知見や学び
• 組織へのAI導入で困ったことやつまづいた失敗事例

異なるバックグラウンドを持つメンバーが集まるチームを、どうすれば一つの方向に進ませられるのか。
本セッションでは、“仕組みづくり”と“対話の設計”によって、チームが自走し始めるまでのプロセスを、EMとしての意思決定を軸に紹介します。

最初の一歩は、「まずは型を守る」こと。一定のリズムでミーティングを重ね、チームの状態を定点観測しました。
その結果、課題が可視化され、メンバー自身が改善を提案するように変化します。
やがて“ルールを守る”段階から、“自分たちで仕組みを育てる”段階へと進化。

このセッションでは、成長実感を持てるチームを育てるためのアプローチ──定例の運用、アンケートの活用、文化を継続させる工夫──を共有します。
テクニックではなく、マネージャーとして「どう関わるか」に焦点を当てたリアルな実践知をお届けします。

●アウトライン（発表の流れ）

① 文化の異なる組織がひとつになる──混沌のスタートライン
異なる価値観・ルールを持つメンバーが合流し、開発の足並みが揃わない混沌を前に「秩序づくり」が必要だと判断した状況。

② “型”が生む秩序──スクラム導入で整う共通リズム
共通言語と対話の機会を作るために“型”としてスクラムを導入し、異文化の融合とコミュニケーション活性を実現した判断。

③ 自律を生む目標設定──組織課題を個の挑戦に翻訳する
組織課題を分解し、メンバー個人の目標に紐づけることで、各自が主体的に課題解決へ動き始める仕組みを整えたプロセス。

④ 定点観測で状態をつかむ──アンケートと対話の循環
アンケートで心理状態と課題を可視化し、EM主導の対話を通じて改善サイクルを回し続け、文化が更新される状態をつくった継続運用。

⑤ 文化をつなぐオンボーディング──回り続ける組織へのアップデート
価値観・型・改善のリズムをオンボーディングとして仕組化し、新メンバーが文化の担い手となる“続く組織”を実現した最終段階。

概要

私たちは、プロダクト開発をより一貫した形で進めたいという課題から「全員がプロダクトエンジニアとして動ける状態をつくる」という方針を掲げました。
技術領域ではなく、価値に向き合う単位で動けるチームを目指した形です。

ただし、役割をそろえるだけではチームは変わりません。
肩書きや担当範囲を動かしても、日々の流れや連携の仕組みがそのままなら行動はほとんど変化しません。

私たちは、人ではなく構造を変える必要があると判断しました。
コードの設計を見直すように、チームの境界や依存関係を整理し、情報の流れを整えました。
意思決定の範囲を明確にし、プロダクト単位で完結できる形へ移行しています。
フロントエンドとバックエンドの分断をなくし、企画と開発が同じループで動ける土台も用意しました。
小さな改善を続けられる構造へ組み替えた形です。

取り組みを進める中で、マネジメントの役割も変わりました。
「どう動かすか」を決めるのではなく、「どういう構造なら自然に動けるか」を設計する側へと比重が移っていきました。

このセッションでは、全員プロダクトエンジニア化を支えた構造設計の実践と、そこから得た視点を共有します。

Learning Outcome

対象:

• エンジニアリングマネージャーとして、組織の成果を技術と結びつけたい方
• チームの動きが事業の動きと噛み合っていないと感じている方
• 「マネジメント＝人の管理」から抜け出し、構造的にチームを設計したい方

得られること:

• マネジメントを構造設計として捉え直し、事業と技術のつながりを強化するためのヒント
• 役割変更で組織が動かない理由を理解し、構造的な課題を見抜く視点
• チームの境界や依存関係を整理し、自律的に動ける環境をつくるための方法

トーク概要

マトリクス組織では、サーバーサイドのEMとして横断的な技術課題や基盤整備を担っていても、メンバーは日々の事業部プロジェクトを中心に動いています。
1on1を通して事業部側の状況は把握できているし、メンバーとの関係も良好で、みんな前向きに仕事をしている。
それでも、サーバーサイドとして取り組みたい改善や、横断的に解くべき技術課題が思うように進まない──そんな状況が静かに積み重なっていく。

事業部の優先度も正しいし、現場のプロジェクトが重たいのも理解している。
ただ同時に、サーバーサイドとして未来を守るために取り組むべき課題は明確に存在している。
両方の“正しさ”の間で、どのように改善を進めていけば良いのか。そこにマトリクスならではの難しさがある。

このトークでは、

• メンバーは動いているのに、サーバーサイドの横断課題だけが後回しになる構造
• 事業部中心の動きの中で、技術的な改善が進みにくい背景
• EMとして軸をどう持ち、どうすればサーバーサイドの基盤整備を前に進められるのか
  といった点について、実際の現場で起きている状況をベースにお話しします。

マトリクス組織では、縦の動き（事業部）と横の動き（サーバーサイド）が必ず揺れます。
その“揺れ”をどのように扱い、改善を継続できる体制をどう設計するか。
その考え方と実践を共有します。

対象となる聴衆

• メンバーが事業部プロジェクトに多くの時間を使う環境で、サーバーサイドの改善が進まず悩んでいるEM
• 日々の1on1で状況を把握できているのに、横断課題へのアクションにつなげづらいと感じている方
• プロダクト側のスピードと、サーバーサイドとしての中長期的改善のバランスに悩むマネージャー
• マトリクス組織で“縦と横”の動きがぶつかる構造に関心があるエンジニアリングリーダー

このトークから得られる学び

• サーバーサイドの横断課題が進みにくくなる、マトリクス構造ならではの理由を理解できる
• メンバーの負荷を増やさずに横断的な改善を進めるためのアプローチ
• 事業部の動きを尊重しながら、サーバーサイドとして必要な改善をどう組み込むか
• EM自身が判断軸を整え、改善を継続的に前に進めるための具体的な視点
• マトリクス構造を前提にサーバーサイドの基盤を育て続けるための考え方