概要

企業の成長に伴う組織変更により、2024年11月から新チームの立ち上げとエンジニアリングマネージャー（EM）としてチームマネジメントを担当することになってから、気づけば1年が経ちました。

0からチームをつくる中で、「最速で成果につなげるには何から着手すべきか」「メンバーが楽しく働ける環境をどう整えるか」など、プロセス設計・文化づくり・ピープルマネジメントを同時に進めながら、プレイングマネージャーとして開発にも関わり続けてきました。

その中で今回はプロセス設計にフォーカスした内容をお話します。
チームの立ち上げ期において開発プロセスの重要ポイントはなにか？
チームの成長とプロダクト増加に伴う開発プロセスをどう設計することで開発速度を保って来たのか？
本セッションでは、チームの各フェーズにおける開発プロセス設計における試行錯誤をしてきた成功と失敗を具体例と共に紹介します。

これから新チームを立ち上げるEMや、プロセス改善に悩むリーダーが明日から使える知見を提供します。

Learning Outcome

対象者

• EM1〜2年目、またはこれからEMになる方
• 新チーム立ち上げを予定している方
• 開発プロセス設計に悩みのある方

得られるもの

• 新チーム立ち上げ期（0→1）で“最初に整えるべきプロセス”が分かる
• プロセス導入の失敗例から「やってはいけないこと」が分かる
• プロダクト増加や体制変化に応じたプロセスの見直し方

「組織内で勉強会を開いても、実務に結びつかない」

このようなことを感じたことがある人は多いのではありませんか？
この課題に対して私はアジャイルコーチという立場でエンジニアリングマネージャー（EM）と協力し、“共に学ぶ”勉強会を実施してきました。
勉強会の回数を重ねていくうちに、成功させるポイントは3つあることに気がつきました。

1.EMが時間を割いて参加すること
　今回、一番伝えたいポイントになります。
　EMが時間を割いて一緒に学ぶ姿勢を見せること自体が、参加者にとって強いメッセージとなります。
　学ぶことの語源が「まねぶ」（真似る）であるように、マネージャーの行動や振る舞いは周囲に良い影響として伝染していくものです。

2.対面で行うこと
　参加者同士の対話と相互作用が生まれ、認識が揃いやすくなります。
　また、リモートの勉強会で集中力を維持するにはかなりのパワーが必要なため、対面の方が効果的です。

3.長い時間をかけること
　学習とは単なる知識の獲得に留まらず、参加者間の「認識の統一」を目指すものです。
　この認識の統一は一度や二度で達成されるものではなく、継続的な時間の共有を通じて初めて、共通の言語や前提が構築されます。

とはいえ、EMは日々忙しく、勉強会への参加は簡単ではないと思います。
しかし、EMが先陣を切って共に学ぶ姿勢を見せることで、参加者に「これは大事な取り組みなんだ」と理解してもらうことができ、参加者への説明や説得の時間を削減することができます。大事なのは「勉強してね」じゃなくて「一緒に勉強しようね」なのです。
結果として、システム部門と業務部門の相互理解が深まり、意思疎通の無駄が削減されることで、リリース頻度やリードタイムにも改善が生まれました。

本セッションでは、「EMが学ぶ姿勢を見せることが、なぜ組織変容の触媒になるのか」という因果と、再現可能な勉強会の設計方法をお伝えします。

ーーー
Learning Outcome
ーーー
　対象聴衆：
　　· 開催の前後で変化が見られる勉強会を開催したいと思っている人
　　· 組織の壁を超えて共通理解を作りたいと思っている人

　得られるもの：
　　· EMがともに学ぶ姿勢が組織変容の触媒となる手段を理解する
　　· 成果に結びつく勉強会の設計について学ぶ

チームリーダーからマネージャーになって1ヶ月。それは、理想と現実のギャップに直面し、手探りで進む苦い経験の連続でした。

特に痛感したのは「事前準備」の不足です。リーダーとしてチームをリードすることはできていたものの、メンバー個々のキャリア観やモチベーションを深く理解していなかったこと。そして何より、チームが向かうべき「方針」と「OKR」の策定が遅れてしまったこと。日々の問題対処に追われ、中長期的な視点を持つ余裕を失いかけていました。

本セッションでは、新人マネージャーが陥りがちな「つまずき」と、そこから学んだことについてお話しします。なぜもっと早くチーム方針を決めなかったのか？ マネージャーになる前に日々考えておくべきだった「心構え」と「準備」は何か。生々しい失敗談とともにお届けします。
何か1つでも皆様の参考になれば幸いです。

【Learning Outcome】
対象聴衆:
・これからマネージャーを目指している方
・新任EM（着任～半年程度）の方
・チームマネジメントのリアルな失敗談に興味がある方

得られるもの:
・新人マネージャーが直面する「リアルな内容」（方針決定の遅れ、期待値調整、OKRやメンバーMBO設定の難しさ）を知ることができます。
・マネージャーになる前から「心構え」として何を意識し、「事前準備」として何をしておくべきかのヒントを得られます。
・メンバーのモチベーションやキャリア観といった「個」の理解の重要性を学べます。
・「チーム方針」を早期に固めることが、いかに重要かを理解できます。

セッション概要

本セッションでは立場の強いステークホルダー、調整余地のないリリース日があり、急造の開発チームにて膨大かつ不確定な要求という困難な状況下でのプロジェクトを乗り越えたエピソードをベースにお話しします。

急造チームで大規模開発を短期間で終えるためのマネジメントと、アジャイルなチーミング、そしてその中で品質要求も妥協しないためには、2つの視点からアプローチをすることが大切です。

観点1 : アジャイルやスクラムだけでは補えないプロジェクトマネジメント(PM)性

アジャイルやスクラムの知識は有用ですが、従来のPMやフェーズゲートの考え方も相互補完的に重要です。
アジャイルは不確実性への対応や継続的改善に強い一方、PMは「全体像の把握と戦略」「大規模プロジェクトの調整」「予算とリソース管理」で効果を発揮します。
今回のような大規模で制約が多い場合に、PMの視点は有効でした。

観点2 : プロジェクトマネジメントだけでは乗り越えられない壁

しかし、教科書通りのPMだけではクリアできません。全ての要素が確実なプロジェクトは稀で、多くは「リリース日は決まっているが、要求は未定」というケースです。
不確実性があるプロジェクトでは、チームによる答えの探索が求められ、アジャイルが活きてきます。短いサイクルでの開発と頻繁なフィードバックで手戻りを減らすことができましたが、それにはチームの主体的な活動が不可欠でした。
PMのガイドとも言われるPMBOKでは、題6版から第7班へ更新される中でアジャイルさについても重要視されるようになっています。
それぐらい近年の開発ではアジャイルという要素は大切になってきます。

開発へ向き合うマネージャーは「絶対に失敗のできない開発」に向き合うシーンかいつかくると思います。
そんなマネージャーに向けて、私の体験と学びをお伝えし、みなさんのプロジェクトを成功に近づけられると幸いです。

Learning Outcome

• プロジェクトマネジメントとアジャイルのハイブリット型アプローチについて実践例を通じて知ることができる
• デッドラインがある大規模開発における重要な観点を理解する
  このセッションを通じて、デッドラインがある大規模開発に向き合っている人・チームへ実践的なプロジェクト進行アプローチを提供します

概要

私の考えるエンジニアリングマネージャー (EM) の重要な役割は、チームのポテンシャルを引き出し、ポジティブな変化のきっかけを作ることです。
しかし、制度や仕組みを導入するだけでは、チームの「熱」は生まれません。スプリントを回すための会議が形骸化したり、知識共有が一部のメンバーに偏ったりしていないでしょうか。

本セッションでは、EMの視点から、チームの主体性や学習意欲という「熱」を引き出すために実践した、具体的な「仕掛け」を共有します。

私たちはアジャイル開発を採用していますが、当初はスプリントが効果的に回らず、まず会議の目的を明確化する必要がありました。 さらに、チームの自走を促すため「アウトプット文化の醸成」を重視しました。活発な知識共有が、個人/組織の成長やナレッジシェアに不可欠だと考えていたからです。

本編では、これらの施策に関する具体的な実践例と学びを共有します。

• 会議体の設計
  • 会議の質を高めるため、その目的を「振り返り（過去）」「計画（直近の未来）」「プロダクトビジョン（さらに先の未来）」のように明確に分離しました。議論の質を高めるためにEMとして行った工夫を共有します。
• アウトプット文化の醸成
  • 社内LTや社内ブログといった取り組みを始めた経緯や、個人の学びをチームの成長へつなげる文化をどう育んだか。その具体的な働きかけと仕組みづくりを紹介します。
• コミュニケーション設計
  • 週1のランチ会を活用し、心理的安全性を育むとともに、自然な「振り返り」や「ナレッジシェア」が生まれる「場づくり」の工夫を紹介します。

これらの仕掛けが、いかにしてチームの文化を変えるきっかけとなったのか。EMとして何を意図し、実践してきたのか、その軌跡をお話しします。

Learning Outcome

対象の聴衆

• 「自走するチーム」や「アウトプット文化」を育てたいEM・リーダー
• 会議体の形骸化や、チームのコミュニケーションに課題を感じている方
• チームの「熱量」を高める具体的な施策を探している方

得られるもの

• チームの対話の質を高める会議体設計のヒント
• 社内LTやランチ会などを「文化」として育てるためのEMの働きかけ
• チームの自走と成長を促す、コミュニケーション設計のアイデア

概要

背景

採用が進んで開発組織が50人以上に膨れあがってくると組織・チーム運営に様々な課題が発生します。とりわけモノリシックなシングルプロダクト組織だと、その傾向はより顕著にみられます。
まずはアプリケーション側からモノリシックアーキテクチャからモジュラーモノリスに移行していきましたが、組織は長らくそれらを十分に扱える体制ではありませんでした。

課題

AI Agentの台頭で開発能力は上がっているのに、その開発能力をチームがうまく扱えていませんでした。
また、チームがプロジェクトに依存していたせいで、プロジェクトの流動性が高い分、コードベースの保守やチームのナレッジ形成が容易ではありませんでした。

対策

上記の課題を解決すべく以下のような対策を設計、推進しています。

• チームトポロジーの見直し
  • Spotify modelを基礎にマトリクス型の組織とします
• ロールの見直し
  • チームのリードと技術領域のリード、ギルドマスターを追加します
• モジュールオーナー制
  • コードベースのモジュラーモノリス化に伴いのオーナーチームの概念を設け、管轄外モジュールを変更する場合はオーナーチームのレビューを促します
• チームサイズのバリデーション
  • AI Agentによってエンジニアのケイパビリティが増えるのでチームサイズにバリデーションを設けます
• スキルの可視化
  • AI Agentによって技術領域の越境が促進されるので、他技術領域での開発能力を可視化します

Learning Outcome

本セッションでは上記の背景から対策までを詳細に説明し、硬直してアジリティが低くなった組織を復活させるような処方箋を提供します。
また、この設計がフィットしない組織でも、組織設計の議論の土台になれば幸いです。

対象者

• EM/VPoE
• 開発組織の採用責任者/CHRO

得られるもの

• 組織の設計力
  • トポロジー設計
  • チーム設計
• リアーキテクトの推進体制
  • 運営体制
  • スケジュール

私は2025年夏にEMをやめました。
このセッションではその背景を整理し、やめたことによるメリットとデメリットを共有します。

EMとして3年ほどチームやプロダクトに対して尽力してきましたが、うまくいかないことも多く悩みを抱えていました。
そこでチームや組織と相談し、EMをやめて別チームのテックリードとして新たな一歩を踏み出すことにしました。

このセッションではEMをやめて改めて感じたEMであったことの良さや、やめたことへの後悔を含めてお話します。
決して「EMはやめた方が良い」という論調ではなく、ニュートラルに自分の感想と得た知見を共有する時間にします。

話すこと

• なぜEMになったか
• なぜEMをやめたか
• やめてから何をしたか
• 自分の性格とEMとのかみ合わせについての考察、一般化
• EMをやめた後悔

Learning Outcome

このセッションの対象の聴衆は次の通りです

• 自分がEMをやり続けることに疑念を持っている人
• 気づいたらEMに「なってしまった」人
• 任せることが苦手な人

またこのセッションでは次のようなことが得られます。

• EMをやめる意思決定に必要な覚悟が何であるか
• EMをやめたらどうなるかの経験談

気づけば、学生の頃からずっと「人の背中を押す」ということを続けてきました。
社会人になり、CTOとして組織づくりや評価・制度設計に向き合うようになっても、その根っこは変わっていません。

誰かが一歩を踏み出す瞬間には、必ず “押す・待つ・預ける” という3つの関わり方があります。
それは『人を動かす』で語られるように、相手の中にある熱や欲求を“反応させる”行為です。

本セッションでは、関係性と信頼の中から人が動き出す瞬間をどうつくってきたのか。
そして、制度や仕組みといったツールを使って、その後押しをどのように強化してきたのか。
背中を押し続けてきた一人のマネジメント実践者として、その実践と思考を共有します。

Learning Outcome
・“背中を押す”という行為を、評価・制度を含めて構造的に理解できる
・「押す・待つ・預ける」の3つの関わり方が、人の挑戦を支える理由がわかる
・評価・制度・言葉・関係性を一つの線として捉える、EMの視点を学べる
・組織の中で“人が動き始める瞬間”をどうつくるかの実践ヒントを得られる

概要

EMになった当初、過去の経験からマネージャーという役割に対してネガティブなイメージを持つ一方で、
良いプロダクトには技術環境だけでなく組織についても考える必要があることも理解していました。
ならば、自分が楽しめるマネジメントの捉え方を獲得すれば良い。

「全員探究・全員ファシリテーター」という組織文化を持つMIMIGURIでは、
日々の組織開発や、半期ごとのリフレクションレポートと相互フィードバックを通じて、
自分のこだわりやとらわれについて深く内省する機会があります。
その中で私は、ルール設計者の視点や、より広いシステムをつくる視点を獲得し、
EMという役割が自身のこだわりや好奇心と接続して見えるようになりました。

チームのマネジメントでは、ルールデザインを通じてメンバーが力を発揮しやすい環境をつくる。
プロダクトのマネジメントでは、「誰かのhowは誰かのwhyかもしれない」という視点を持つ。
共通のWhyを掲げるだけでは機能的な関係性を強化してしまう。
ビジネス価値・ユーザー価値・個人の意味づけを両立させることで、
個々が持つWhyをプロダクトに活かすことを目指す。

このトークでは、モヤモヤを感じつつ知識を取り入れて実践する中で、
深いリフレクションを通じて自分が楽しめるマネジメント観を獲得するまでの
実践を、リフレクションやルールデザインといった
具体的な仕組みとともに共有します。

Learning Outcome

対象の聴衆

• EMという役割に葛藤や違和感を感じている方
• リフレクションや組織開発の実践に関心がある方
• マネージャーという役割にネガティブなイメージを持っているエンジニア

得られるもの

• 外部知識と深いリフレクションを組み合わせて、自分なりのマネジメント観を獲得するプロセスの実例
• 機能的な関係性を超えて、個々が持つWhyをプロダクトに活かす仕組みづくりのヒント
• ルールデザインを通じたチーム環境づくりの考え方

EMConf JP 2025 で『マネージャー全員でマネジメントポリシーを作った』話をさせていただいた約ひと月前、組織マネジメント界に新しいパタンランゲージ的な共通言語を生み出しそうな本が出版されました。奇しくも今回基調講演をされる安斎勇樹さんが記した『冒険する組織のつくりかた』です。

当時は「人にやさしい組織マネージメント勉強会」の本読み会で『マネージング・フォー・ハピネス』を読み終えた直後、次に読む本を選ぶタイミングでした。
そこで、届いたばかりの『冒険する組織のつくりかた』を候補に出したところ、他にも同じ本を挙げた方がいるなどして支持が集まり、2月からみなさんと読み始めることができました。そして、このプロポーザルを書いている11月前半もまだ途中です。この調子だと読了は12月に至りそうです。

この1回に読む量の平均は30ページ未満というゆっくりペースの読書会で何が起こってきたのか？どうして1年近くも続いているのか？参加し続ける魅力や価値はどこにあるのか？などをふりかえって探究します。

どうやら、この場で起こっている現象は「増幅」、書籍だけでなく参加者も「触媒」と言えそうです。

Target Audience
・組織変革や行動変容といったチェンジ・マネジメントを担っている方
・社内｜外で読書会などの勉強会を行いたい人｜行っている方
・『冒険する組織のつくりかた』を触媒に生まれた学びに興味がある方

Learning Outcome
・対話や気付きを増幅する場づくりのヒントを得られる
・AI時代の（人間ならではの）本の読み方について考える材料を得られる
・参加者のコンテキスト共有レベルに合わせたコンテンツ選定の事例を知ることができる
・『冒険する組織のつくりかた』から出てきた気付きや学びの一端を知ることができる

※読書会（勉強会）の場づくりにフォーカスした内容を予定しており、書籍『冒険する組織のつくりかた』の内容を紹介するセッションではありません（具体的な気付きや学びの紹介とコンテンツ選定の観点で一部は触れると思います）
※参加者仲間か運営の方との共同登壇を画策しています

私たちの組織では、プロダクトで価値を創出することをキーワードに、エンジニアは全員がプロダクトエンジニアとして動ける状態を目指し、またDevRelやデザイナーやPMも、全員がプロダクトグループの構成メンバーとして、プロダクトが描く価値を中心とした組織づくりをしています。ビジネスサイドのメンバーが提供するカスタマーへの体験も含めて、広義のプロダクトとして定義し、BizDevが密に連携した状態を目指しています。

ところで、開発組織の目標設計って難しくないですか？タスクを終えたらOK？主要KPIを追ってもらう？各社さまざまですよね。
私たちの開発組織では伸ばすべき方向性についての共通認識を持つことを大切にしています。
その中心にあるのがNorth Star Metricです。
North Star Metricのために、今すべきことを決めていくという意思決定の構造を持ちます。
そこで、私たちの組織ではNorth Star Metricをどのように定義したのか、またそれに沿ってどのようにひとりひとりがワークし、組織としてより大きな価値を生み出そうとしているのか、これまでの取り組みとこれからのチャレンジについてご紹介します。

Target

・ 組織の目標設計に悩むマネージャー
・ NorthStarMetricって聞いたことあるけどナニソレナニソレと興味がある方
・ BizほどメジャラブルなKPIを持ちにくいことに悩む方
・ プロダクトエンジニアという考え方が好きな方

Learning Outcome

・ 組織が同じ方向を向いてプロダクトを磨き上げるためのNorthStarMetricの存在価値
・良いNorthStarMetricの定め方
・BizDev交流の育て方

概要

多くの組織では、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としての経験を通じて、私は何度もそのような問題に直面してきました。
その中で、ドキュメントを「組織の最重要資産」として再定義し、とにかく全てを文字に書き起こし（かっこよく言えば運用ルールを構築することで）、プロジェクトの円滑な管理進行や新規参画メンバーのオンボーディング期間短縮、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・採用担当

得られる学び

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