概要

プロダクトリリースから2年経ち、更なるビジネス成長を果たすため開発にも弾みをつけていきたいというフェーズのチームに開発責任者としてジョインし、その後の2年間を通じて製販一体の『距離の近いチーム』をつくりあげてきた実践知についてお話しします。
プロダクト開発チームは海外拠点におり、一生懸命やってはいるものの『遅れる開発、進まない改善』で国内のビジネスチームは不満を募らせていました。就任当初は物理的にも心理的にもチーム間の距離が遠いように感じられた状態からの出発でした。
本セッションは、このような状況から『製販一体のワンチーム』をつくり上げるために、2年間で実践してきたことの全貌を紹介するEMセッションです。
ビジネス・ディスカバリー・デリバリーが三位一体となっている状態を理想として、どうやって距離を近づけていくか。海外メンバーを全員日本に呼ぶことで物理的に近づける力技から、コミュニケーションパスを設計し直して精神的に距離を近づける小技など、大小様々な施策を実行しました。
どのように言語の壁を越えてダイレクトコミュニケーションの文化をつくったか？ディスカバリーとデリバリーの接続をどのように再構築したか？
『関係性』『プロセス』『採用』『技術』といったトピックを絡めて、組織をアジャイルな開発チームへと再構築した具体的な手法と、それによって何がどれだけ良くなったのかを、生々しい実験記録としてお話しします。

対象

• リモート/ハイブリッド環境下で、チームの一体感欠如に悩むリーダー
• 海外拠点を含むグローバルチームの連携と生産性向上に課題を持つエンジニアリングマネージャー
• ディスカバリーとデリバリーそしてビジネスを繋ぎ、一体にしたいと思っている方

Learning Outcome

• 『距離の近いチーム』の構築法: リモート・ハイブリッド環境下で心理的安全性を醸成し、ダイレクトコミュニケーションを促進する具体的なプラクティス。
• グローバル・製販一体チームの実現: 時差や文化の壁を越え、ワンチームとして機能させるためのプロセスおよびイベント設計。
• ディスカバリーとデリバリーの接続: 開発チームがビジネスの上流から関与し、ディスカバリーチームとともに価値あるプロダクトを届けられるなるための具体的な仕組み。

私が働く STORES は、複数のスタートアップと合併し、それぞれが持っていた歴史あるプロダクトをひとつの体験へ統合する意思決定をしました。
プロダクト統合は技術的に難易度が高く、複雑性や認知負荷は統合が進むほど増大し、理想の体験を実現するための開発が困難になっていきました。この状況で私はEMとしてのプレイスタイルを大きく転換し、「Write Code Every 営業日」を掲げて日常的に開発へ関わることを決めました。

本格的な統合が始まった2023年、私が本番へリリースしたPull Requestは45件でしたが、2024年は223件、2025年は現時点で244件と、ほぼ毎営業日1Pull Requestを実現しています。
この行動変容は事業と組織に具体的な変化をもたらしました。月1000ドル規模のインフラコスト削減の実行、統合に不可欠な重要機能の開発、増え続けていた運用課題の解消など、EMが意思決定しながらコードを書くことで多くのテーマが前に進むようになりました。

また、マネジメントと開発を両立するには課題の粒度を小さくする必要があり、それがトランクベース開発の推進とチーム全体の課題解決力の向上につながりました。さらに自ら手を動かすことで、デプロイフローの課題や開発環境の不備といった現場の痛みをよりリアルな怒りとして感じ、改善が加速しました。
その結果、私が管轄したチームが主に開発するリポジトリのPull Request数は2023年の3096件から2024年には4302件と約1.5倍に増加しました。これらの組織的変化が評価され、私は2025年からシニアマネージャーへ昇格しました。

2025年には統合アカウントのもとで、すべての STORES プロダクトを横断して利用できる「スタンダードプラン」をリリースし、目指していた統合体験をようやく提供できるようになりました。それに伴い、事業の成長も大きく加速しています。

本トークでは、テクノロジーマネジメントが重要になる組織でコードを書くEMへと舵を切った背景、毎営業日1Pull Requestを継続するための実践知、そして自身と組織に起きた変化を共有します。
マネージャーとして働きながらコードを書き続けるというキャリアの可能性について、何かヒントを持ち帰っていただければ幸いです。

セッション概要

EM（Engineering Manager）というロールは往々にして幅広い領域をカバーせざるを得ず、どこまで深く関与してどこから移譲するのかの見極めが頻繁に求められるものです。そんなEMが、たとえばIC（Individual Contributor）などの他ロールを兼任する「ハイブリッドロール」を打診・アサインされると、領域のさらなる拡張やコンテキストスイッチングをも強いられるような状況に置かれます。
本セッションは、ハイブリッドロールを遂行するにあたり破綻に追い込まれてしまった当事者として、自身の振る舞いや構造上の問題点について、実体験に基づいて分析します。またその結果から得られた問題の回避策についても触れ、これから別ロール兼務EMに挑もうとしているEM本人のみならず、その周囲の方（とくにアサインを行う上位者）の参考になることを企図したものです。

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

対象者

• 今現在兼務している、または予定や可能性のあるEM本人
• EMに対し兼務アサインを行っている、またはこれから行う可能性のある上位者
• EMになろうという人

得られるもの

• 兼務EMの構造的問題とその回避策
• 期待値のすり合わせに関する実践的コミュニケーション手法
• 管掌チームに対する権限移譲の具体的知識

■概要
育成の属人化に悩むEM、育成に向き合うメンター、そして成長の軸をつくり始める若手──
本セッションは、三者が抱える「1on1がうまく機能しない問題」を乗り越えるための実践談です。

1on1が機能せず、育成が自分の力量に依存してしまう──そんな経験はありませんか？

私は2023年の春、新卒のメンターを初めて任された際にその状況に直面しました。
傾聴が得意でない私では1on1が機能せず、「このままでは続かない」と感じ、育成経験のあるシニアに相談して「シニア＋私＋新卒」での2on1を始めました。

2on1では、私とシニアがメンター役・コーチ役を入れ替えながら対話を進め、フラットな関係性が生まれました。
シニアの問い方や視点を観察することで、傾聴が苦手な私でも育成の型を掴み、弱みと強みを相対化できました。
育成は「一人で抱えるもの」から「共に成長する場」へと変化していったのです。

2on1は当初こそ私の未熟さを補う工夫でしたが、やがて個人依存の育成をチームで支える「仕組みづくりの実験」へと発展しました。
実践を重ねる中で、EM・育成者・成長当事者がそれぞれ異なる課題を抱えていることに気づき、2on1で解決できる手応えを得ました。

・EMの課題
　・育成が特定の人に依存し、負荷が集中していた
　→複数人で育成を担う体制が生まれ、負荷が分散した
・育成者の課題
　・育成が空回りし、成果が届かず、モヤモヤしていた
　→伴走者の存在で弱み・強みが相対化され、成長と自信に繋がった
・成長当事者の課題
　・視点やロールモデルが一人に固定され、成長幅が狭かった
　→複数視点に触れ判断軸が育ち、自分らしい方向性を描けた

本セッションでは、新米メンターからリーダー・EMへと立場を広げつつ、2on1を軸に育成文化を育てたプロセスを紹介します。
属人化しがちな育成をどう仕組みに変え、チーム全体で人を育てる体制へ発展させたのか──その試行錯誤と学びから、「成長し続けるチーム」を作るヒントを共有します。

■対象の聴衆
・育成の属人化に悩むEM
・育成に向き合う新米EM／リーダー／メンター
・成長の軸をつくり始める若手メンバー

■得られるもの
・属人化を抑え、チームで育成を回すためのヒント
・一人で抱え込まない伴走型育成スキルとその始め方
・複数視点を取り入れ判断軸を育てる方法

セッション概要

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

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

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

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

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

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

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

Learning Outcome

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

概要

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

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

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

想定リスナー

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

Learning Outcome

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

概要

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

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

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

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

アジェンダ（予定）

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

Learning Outcome

学習成果

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

対象

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

本セッションでは、EMからVPoEを経てCTOへと役割を広げていったキャリアパスを歩んできた実体験を通じて、
各役割における視点の違いを理解し、自らの意識や行動を変えながら成長してきたプロセスを共有します。

各役割では、異なる視点とアプローチが求められました。
EMではPeople/Project/Product/Techのマネジメントをフル活用して、チームの成果をいかに最大化することにフォーカスしました。
VPoEではエンジニアリング組織全体の戦略と実行を担い、開発組織視点での人・組織の仕組みづくりや人の配置の最適化により、短期的な成果の最大化をはかりました。
CTOでは技術戦略とビジネス戦略の接続を担い、経営リソースをフルに活用した意思決定を行い、短期〜中長期的な組織的な成果の最大化をはかっています。

役割の変化に応じて、求められる知識やスキルの領域も広がっていくことを実感してきました。
特定領域における深い専門性はコスト効率の高い意思決定を可能にする強力な武器である一方で、
対応領域の広さは経営に近づけば近づくほど重要になってきます。
特に、組織開発・ファイナンス・アカウンティングといった経営の知識を身につけることは、より戦略的な意思決定が可能になる糧となりました。
この広さと深さのバランスをどう取るかは、マネジメントキャリアパスを歩む上で重要な課題だと理解しました。

役割の広がりの過程には、避けて通れない葛藤や悩みも伴いました。
エンジニアとして良しとされているスペシャリスト思考のキャリア観から外れているという感覚に、悩まされる日々。
専門外のスキルが要求されるようになってくることによる無能感、コストに見合わない人材になっていく不安感なども、マネジメントキャリア特有の悩みでした。
自分が一人で抱えることの限界を迎えたときに誰かに業務を渡すことの、その球の重さへの申し訳なさは現在でも良く起こる葛藤です。

本セッションでは、これらの困難や葛藤を乗り越えるために、どのように視点や意識や行動を変えて成長してきたかを、マネジメントキャリアパスの実体験を通じて共有します。

Learning Outcome

• EM/VPoE/CTOの視点の違いと必要とされるスキルセット
• マネジメントキャリアパスを歩んでいく際の心構えとスタンス、考え・行動の変え方

デジタル庁は設立から5年目を迎えました。
中央省庁にありながら官民融合のチームとして、デジタル政策を推進し、数々のサービスや仕組みを生み出してきました。

私もその一員としてデジタル庁の立ち上げから携わり、これまでの専門性に固執せずにさまざまな領域の担務に関わりながらデジタル庁のエンジニアとしてのあるべき姿を模索してきました。
私が現在ユニット長を務めるエンジニアユニットには、民間から参画したソフトウェアエンジニアが所属しており、デザイナー、プロダクトマネージャーたちと調達では実現できないスピードと専門性で社会的インパクトのある課題に挑戦しています。

このトークでは、行政組織という特殊な環境で立ち上げからエンジニアが活躍できるようになるまでを振り返り、内製開発への取り掛かりと実践を紹介します。
「iPhoneのマイナンバーカード」や「マイナンバーカード対面確認アプリ」などの内製開発の事例における振る舞いや開発におけるアプローチも紹介しながら4年間の試行錯誤を共有します。

組織の成長とともにこの4年間で私自身の振る舞いや態度がどのように変わっていったのかも見どころのひとつです。
民間組織のEMと呼ばれるポジションとの違いから、行政組織におけるEMの役割を定義してみたいと思います。

Learning Outcomes

対象： 特に行政・公共領域に興味がある現在EM/VPoE、TL、エンジニア、デザイナー、プロダクトマネージャーの方、その他将来EMと呼ばれるロールになってみたい全ての方々
• 新しい行政組織における内製開発の最初の一歩
• 官民融合組織における民間専門人材の振る舞いから、専門領域の違う方々との協業の仕方
• 既存の調達中心の開発にどのように内製開発を両立させていくか進め方やアプローチ
• エンジニア上がりのEMがマネジメントを進めるうえでのコツ
• 行政と民間組織のEM目線での違いと振る舞い方

EMConf JP 2025 で『マネージャー全員でマネジメントポリシーを作った』話をさせていただいた際は、EM 同志での経験知と探究テーマの共有を試みました。

ところが協賛案内資料で前回参加者の「職種」分布をみると、もちろん EM が最多でしたが、その半数以上も「エンジニア」の方々が参加されていたと分かりました！そしてそれ以外の様々な役割で開発組織に関わっている方々も大勢！！
つまり、前回の EMConf JP に集まった 1/3 以上が、『自分は今 EM じゃないけど EM 向けの話を聞きに来た』方々だったのです（そんな志の高い皆さんを “Next EM” と呼んでみます）。

ならば、これだけ多くの “Next EM” が集う機会を生かすことができないか？
→“Next EM”な皆さんの関心事を知る場にしたい
→“Next EM”な皆さん同志がお互いを認識し合い、繫がれる場にしたい

さらに、“現役EM” を含む “先輩EM” の皆さんもこの場に集まってくださるならば・・
→“Next EM”な皆さんに“先輩EM”からヒントを贈れる場にしたい
→“Next EM”な皆さんそれぞれの関心事に寄り添えるメンター的な“先輩EM”と出逢える場になると最高じゃないか？

・・などとイメージが膨らんじゃいました。
そのような場を、いろいろな角度から問いかけをさせていただいたり、燃料になる情報を示させていただいたりして実現したいと思います。
そして参加者の皆さんにも能動的に場づくりに加わっていただける、創発的なワークショップやタウンミーティングのような場づくりを試みたいと思います。

Learning Outcome：

for “Next EM”
・エンジニアリングマネジメントに関心のある仲間の存在を知れる
・エンジニアリングマネジメントについて他者の関心事を知れる
・EM を目指す/担うにあたってのヒントを得られる
（→次に探究するテーマが見つかって新しい扉が開くようだと最高です）

for “先輩EM”
・“Next EM” が考えていることを知れる
・自身のエンジニアリングマネジメントを客観的に見直す気付きを得られる
・（マネージャーのなり手が少ない組織も多いなか）未来の EM の成長を支援する材料を得られる

※他社の仲間と共同登壇を検討しています

現職に1人目のEMとして入社してから2年が経ちました。
当時、エンジニアは10名ほどで、CTOと私の2人でEMの役割を分担していました。
しかし、エンジニアが20名を超え私のレポートラインが15名ほどになった頃から、
採用・育成・組織運営のすべてが中途半端になり、私自身がボトルネックとなってしまいました。

そこで2人目EMの採用を検討し始めたものの、いくつもの壁に直面しました。
たとえば次のような論点です。

• 「内部登用にするか、外部採用にするか」
• 「候補者が少ない中、どんな期待値で募集すべきか」
• 「経営陣にどう必要性を説明すべきか」

加えて、私自身が1人目EMとして多岐にわたる業務を担っていたため、
どの業務を2人目EMに委譲し、どのように責任を分担すべきかという点にも大きく悩みました。

本セッションでは、
「1人目EMしかいない組織が、どうやって次のEMを迎え入れ、活躍できる体制を作るか」
をテーマに、実際に私が経験した検討・採用・業務設計・立ち上げまでの具体的なプロセスをお話しします。

アジェンダ（予定）

• 1人目EMとして取り組んできたことと、見えてきた限界
• 2人目EM採用の検討（内部登用／TL兼務／外部採用）
• 経営とのすり合わせと期待値の明確化
• 2人目EM候補者への魅力づけと採用プロセス設計
• 入社後の業務分担・権限移譲の進め方
• 2人目EMの参画による変化と学び

想定リスナー

• 組織拡大に伴い、2人目以降のEM採用を検討しているCTO/VPoE/EM
• 小規模プロダクト組織でEMとして入社・活躍を目指す方
• 小規模プロダクト組織に属しており、将来的にEMを目指しているエンジニア

得られる学び

• 2人目EMを採用する際に直面する典型的な課題と、その乗り越え方
• EM人数の少ない組織における期待値設定とオンボーディング設計の実践例
• マネジメントを特定個人に依存させず、権限を分散・委譲するための実践的アプローチ

概要

本セッションでは、組織拡大に伴い生じたQA課題に対し、QA組織が体制と運営を見直し、変化を進めた実践を紹介します。

開発やプロダクトの組織が成長に合わせて仕組みを変える一方、QA組織は従来のやり方を続け、変化に追いつけていませんでした。

当初、QAEは開発チームに入り、QAの実践をリードする立場として活動していました。
しかしチームが増えるにつれ、横断的なイネイブリング活動を強化し、レビューや壁打ちなどの支援を通じての関わり方も進めました。
一見うまく機能しているように見えましたが、少しずつQA組織としておこなえていることの幅が狭くなっていきました。

そこで「ボトムアップ」と「トップダウン」の両輪を活かすことができるQA組織にする必要があると考えました。

まず、QA組織のメンバーがより自律的に動けるように「成果を出せる環境作り」「成果が評価される仕組みづくり」「成果を知ってもらう仕組みづくり」を整えるために、次のようなことを進めていきました。

• 進む方向性の提示として目指す姿の共有
• 進む方向の後押しをするためのスキルの現状把握とスキルアップ支援
• 評価の軸の明確化と方向性がよりわかる等級制度の見直し

さらに、QA組織が他組織と動けるようにマネジメント層との連携強化や、そのための品質保証部から本部への拡大など、より横断的に動けるような組織へと整備をしていきました。

この両輪によって、QA組織が他組織と連携しながらQA面でリードできる基盤が整いつつあります。
結果として「QAEをどこにアサインするか」ではなく「どんなスキルが必要か」という視点でQA体制を検討できるようになり、組織全体で考える第一歩が進み出しています。

組織の変化に合わせてQA組織が適切にコミットメントできるようにするための実践と、その過程で得た知見を共有します。

Learning Outcome

対象：QAに関わるメンバー、EM、プロダクトマネージャー、開発チームのメンバーやEMなど

得られること

• 組織の成長に合わせてQAの役割や体制を再設計するための視点
• QA組織が他組織と連携しやすい仕組みを整えるアプローチ
• メンバーが自律的に動けるようにする制度・支援設計の具体例
• 変化を続ける組織でQAが持続的に機能するための実践知

現在私は、UPSIDERの「支払い.com」事業部で、事業とプロダクト開発・運用の両面に関わりながら、CTO/EMとして活動しています。
マネジメントを担う立場でありながら実際に手を動かす“ハンズオンCTO”として過ごしたこの1年は、「マネジメントの原点とは何か」を改めて考える期間でした。

以前は10年間、取締役CTOとして組織・人・事業のマネジメントに注力していました。
経営判断や採用・評価に時間を割く一方で、現場感覚が薄れ、“自分がバリューを出せていないのでは”という違和感を抱えていました。

再び現場に戻ったことで、マネジメントの視点は大きく変化しました。
少人数でも高速に動くチーム体制、プロダクトマネジメント・技術・経営の橋渡し、そして「手を動かすこと」が意思決定やチームの信頼に与える影響を実感しています。

本セッションでは、

• 経営と現場を行き来して見つけた“マネジメントの原点”
• 少人数・高速開発を支える組織構造と意思決定の工夫
• 現場に関わることがチーム関係性を変えた実例

これらの実体験と学びを通して、マネジメントの役割を改めて問い直します。

スピーカー略歴

エムスリー、Nubee Tokyoを経て2015年ユニファに参画。取締役CTOとしてチームを率い複数プロダクトを立ち上げ。2025年4月よりUPSIDER「支払い.com」事業部CTO。

Learning Outcome（対象の聴衆と得られるもの）

• 対象の聴衆：
  • CTO/VPoE/EMとして、組織拡大期・変革期にある技術部門を率いている方
  • 少人数体制・スタートアップフェーズにおいて、マネジメント/開発/運用を兼務している方
  • 現場から離れたマネジメント経験者で、再び開発・プロダクトに関わる意義を探している方
• 得られるもの：
  1. 経営マネジメントに専念していたCTOが再び現場に戻った際に直面した“ギャップ”とそれを乗り越えるステップのリアルな知見
  2. 手を動かしながらマネジメントを行うことで生まれた「チームの信頼」「技術/開発速度」「意思決定の質」の変化と、その実践から得た仕組み
  3. ハンズオンと組織視点の間を行き来できるマネジメント体制の設計ヒント（特に少人数・高速開発を前提とした体制）

■ 概要

エンジニアリングマネージャー（EM）としての最初の一年。
「組織をよくしたい」「メンバーを支えたい」という想いとは裏腹に、日々の課題の多さと自分の不得意さに何度もぶつかりました。
テクノロジーマネジメント、ピープルマネジメント、プロジェクトマネジメント、プロダクトマネジメント……EMの仕事は本当に広く、「全部はできない」という絶望からスタートした一年でもあります。

本セッションでは、そんな“できない”からのスタートをどのように受け入れ、学びに変えていったかを赤裸々にお話します。
苦手領域をどうカバーしたのか、どんな学習方法を試したのか、支えになった本や仲間との関わりを通じて、
「全部できなくてもチームは良くできる」という実感を得るまでのプロセスをお話しします。

EM1年目のリアルを通して、「苦手を認めることから始まる成長」「自分らしいマネジメントスタイルの見つけ方」「学び続ける仕組みづくり」など、
明日からの行動に活かせる具体的なヒントを持ち帰っていただける内容を目指します。

EMとしてキャリアを歩み始めた方、あるいはこれから挑戦したい方に向けて、
完璧でなくても前に進める“成長の一歩”を一緒に考えていきましょう。

■ Learning Outcome

・「EMの仕事の幅広さ」に圧倒されたときの向き合い方が分かる
・自分の不得意領域をカバーするための実践的なアプローチ（人に頼る・仕組みで補う・学習で伸ばす）のヒントを得られる
・EMとしての学びを加速させるための学習法・読書法・情報収集のコツを知る
・「全部はできない」と割り切りつつ、チームとして成果を出すための考え方を学べる
・他のEMのリアルな失敗談や成長過程を通して、自分の挑戦を前向きに捉えられるようになる

「マネジメントはマネージャーの仕事」そう考えて、すべての判断や調整をEMに依存する組織になっていないでしょうか？
EMがボトルネックとなり、現場のスピード感が失われ、メンバーのオーナーシップが育たない…そんな課題を感じている方も多いはずです。

本セッションでは、自分たちのチームで実践している「みんなでマネジメント」の取り組みについてうまくいっていること、うまくいっていないことを共有します。

「みんなでマネジメント」なぜチーム全体でマネジメントをやるべきなのか？
「冗長性」「即時性」「多様性」「将来性」「自律性」という5つの観点からその意義を解説します。

もちろん、「メンバーの負担が増えるのでは？」「意思決定が苦手な人もいる」といった懸念もあるでしょう。
しかし、コードの多くをAIが書くようになりつつある未来において、エンジニアが小さな意思決定を積み重ね、自ら手を挙げる経験こそが、プロダクトとチーム、そして個人のキャリアを強くすると考えます。

このトークでは、EMが集中すべき「マネジメントがスケールする仕組みづくり・空気づくり」に大事さを共有し、
OKR運用やAI推進プロジェクトといった実例を交えながら、いかにメンバーの自律性が育まれていったかを、EMそしてテックリードそれぞれの視点から対話形式でお伝えします。

■ Target Audience
・マネジメント業務に疲弊し、ボトルネックになっていると感じるEM
・チームの自律性やオーナーシップをどう高めるか悩んでいるテックリード、シニアエンジニア
・将来的にマネジメントキャリアも視野に入れているエンジニア

■ Learning Outcome
・マネジメントを「ロール」ではなく「機能」として捉え直す視点
・みんなでマネジメントすることの良さを知る
・メンバーの自律性を促す仕組みづくりのヒント

■ 概要:
「システム改修に半年かかります」「影響調査に1ヶ月ください」
前職でEMだった私は、あらゆる技術的負債が受肉したような保守コストの高いスパゲティと、品質を顧みる余裕すらない組織構造の壁に直面していました。
内部品質の重要性を説き、新しい開発プロセスの試行を提案しても、日々の運用に疲弊するメンバには響かず、構造的な組織課題を前にEMとして無力感を味わいました。

「事業会社のシステム保守開発を楽にしたい」
その強い課題意識から私はあえてEM職を離れ、モダナイゼーションの現場に飛び込みました。
そこで得たのは、アーキテクトとしての実践知（システムと組織の構造的関連性や、モデリングによる共通理解の形成）と、専門職大学院での学びによって得られた経営戦略的な視座（情報社会学や管理会計 ）でした。
技術的な「構造化思考」と、組織や経営を多角的に分析する「視座」。これらを武器に、私は再びEM（グループ長）として、まさに前職の課題そのものであった「基幹システムの保守開発部門」のモダナイゼーションに取り組んでいます。

本セッションでは、一度EMを挫折した私が、アーキテクトとして得た学びをいかに増幅させ、それを触媒としてレガシーな組織とシステムの変革に活かそうとしているのか。その現在進行形の実践と葛藤を共有します。

■ Learning Outcome（対象の聴衆 / 得られるもの）:
対象の聴衆:

• レガシーシステムや保守開発チームのマネジメントに課題を感じているEM
• 組織構造の壁により、技術的改善が進まないと感じているリーダー
• 専門職とマネジメントのキャリアパスに悩むシニアエンジニア

得られるもの:

• 「構造化思考」をEM業務（特に組織変革）に活かす具体的なヒント
• チームやステークホルダーとの共通理解を形成する実践的アプローチ
• 「EM → 専門職 → EM」というキャリアの往復から得られる学びと、それを次の挑戦に繋げる視点
• エンジニアリングの隣接領域への越境学習がEMとしての「引き出し」を増やす実例

多くの組織は小さな体制でスタートします。1人だったり1チームだったり。立ち上げ初期はそのシンプルな構造で十分回るかもしれません。そして事業の成長とともに人は増え、チームも増え、責任や役割の分担が複雑になるにつれて、今の構造ではうまく回らないと感じる瞬間が訪れます。

• メンバーが増えてコミュニケーションコストがあがった
• チームやメンバーごとに目指すものがばらばらになり、思ったように進められない
• CTO/VPといった役割の人が全体を見きれなくなってしまう

これらの課題に向き合っていく中で、「組織の階層を増やす」という選択肢を検討するケースが多いと思います。

人が増えているのだから、それをさらにチームに分けて、管理できるようにミドルマネジメントを置く。一見合理的に見えるこの選択ですが、実際にやろうとすると多くの課題に直面することになります。

私達の組織も、3〜4年ほど前はシンプルな構成でした。VPoEのもとにユニットと呼ばれるチームがいくつかぶら下がるような2階層の体制。しかし開発チームが拡大していく中で、徐々に意思決定やマネジメントが追いつかなくなり、徐々にミドルマネジメントの概念を追加していき、今では4階層構造へと移行しました。

このセッションでは

• なぜ階層を増やす必要が生じたのか。なぜ2階層から4階層まで増やしたのか
• どのような流れで構造を変化させていったのか
• 具体的に直面した課題と、それに対する向き合い方
  • マネージャー不足と育成
  • ミドルマネジメント層で生まれた役割や期待値に対する認識のズレ
  • 権限移譲の難しさ
• やってよかったこと、難しかったこと、今振り返っての学び
• 今後の展望

といった形で、具体的な経験を共有していきます。

想定リスナー

• 組織拡大フェーズのリーダー、マネージャー
• 将来的な構造変更に備えたいCTO / VPoE
• ミドルマネジメント層の育成に課題を抱える方

EMの重要な役割の１つとして、「エンジニアの採用」が挙げられます。
私はe-dashというスタートアップに1人目のエンジニアとして入社し、採用活動に強くコミットしてきました。
決して知名度の高い企業ではありませんでしたが、採用活動におけるアトラクトがうまく働き、2年をかけて20名以上のエンジニアの採用に至りました。

エンジニア、特に一定の経験値・スキルをもった”優秀なエンジニア”の採用はどの企業でも苦戦しているかと思います。
知名度の低いスタートアップがどのように優秀なエンジニアを採用できたのか、という点について、私の体験談を踏まえてお話しします。

Agenda
・エンジニア組織拡大の軌跡
・採用チャネル・採用プロセスに関して
・エンジニア採用のTips
　　・候補者を如何に”アトラクト”すべきか
　　・”技術力の高い”エンジニアの見抜き方
　　・結局優秀な人を惹きつけるのは”xxxx”
・エンジニア採用アンチパターン（採用における失敗談）

Intended Audience
・エンジニアの採用・組織づくりに携わるすべての方
・スタートアップやベンチャーで働いている方
・チーム拡大や採用に関わり始めたテックリード、シニアエンジニア

Expected Takeaway
・知名度のないスタートアップでも、優秀なエンジニアを採用するために実践できる、具体的で再現性の高いアトラクト手法と採用戦略
・面接で見落としがちな”技術力の高い”エンジニアを正確に見抜くための手法と、避けなければならない採用アンチパターン
・小規模組織において”優秀な人”を継続的に惹きつける、技術と組織文化に根ざした本質的な採用力の磨き方

概要

• 事業活動とエンジニアリングは年々強く関連するようになってきており、エンジニアリングの目的はプロダクトやサービスの開発を通じて事業目標の達成に寄与すること
• 事業目標の達成は経営の目標でもある。経営がやりたいことをどのように理解するか、それをエンジニアリング課題に如何に接続するかがエンジニアリング戦略の根幹となる
• が、実際にP/Lなどの経営指標を見ても、そこからエンジニアリング活動にどのように結びつけるのがいいかイメージするのが難しいEMは多いと思われる（自分もそう）
• そこで本セッションでは、経営の基本は財務・会計であることを念頭に、財務会計 → 事業戦略 → プロダクト戦略/技術戦略の流れを理解し、実際の活動に落とし込むにはどうすればいいか、そのフレームを提案する
• また、実際に社内の経営数値を集めてどのように可視化し、技術戦略を考える際に活用しているかの実践知を提供する

想定リスナー

• 事業や経営の近くで戦略を描く必要があるEM/技術統括
• 事業戦略を理解しながらマネジメントをすることに興味がある人

Learning Outcome

• 財務会計の基本的な考え方を念頭におき、技術戦略の考え方との接続方法を考える枠組みを提供する
  • 特にP/L、C/Fのパターンから経営状況の概況を読み解き、そこからエンジニアリング戦略を考える糸口を見つける
• 実際に経営に携わるようになってから、どのように経営・会計を理解し、エンジニアリング戦略に結びつけていったのかの流れを提供する
  • 獲得できる数値情報だけでなく、事業責任者との対話、商談同行などを行い、経営と事業の解像度を上げ、会計情報とマッピングしていった流れについて追体験
  • 半年かけて理解した内容と、その時の経営・事業課題を踏まえて、どのようなエンジニアリング戦略を描いたかを提供する
• 「将来の事業成長」につながるイノベーションと、「今の経営状態」を示す財務会計とをつなげる方法について考える
  • イノベーション経営のためのシーズ投資は、現在の経営成果の将来費用から支払われる
  • どのようなお金の流れが起きるのかをイメージし、イノベーション戦略に結びつけることを考える

話さないこと

• 詳細な財務会計の知識

背景：評価プロセスが抱える3つの断絶とEMコストの肥大化

あなたの組織では、評価制度が形骸化し、メンバーの納得感を損ねていませんか？（例：個人目標（OKR）資料と実態の乖離、360度評価の記述不足、査定時の「びっくり」）。特に、古い個人目標資料が残ることでEMが矛盾した指導を強いられ、説明責任コストが肥大化しているということはありませんか？当組織では、この断絶が深刻な問題となっていました。

内容：評価システムを「成長の触媒」に変える連動施策

組織横断的なEM定例会議を起点に、この断絶を解消する一貫した評価システムを設計した実践を共有します。具体的には、①個人目標（OKR）をキャリア連動型のコミュニケーション触媒として再定義、②360度評価の品質を増幅させるベストプラクティス集を展開、③査定前のギャップを解消するフィードフォワード面談を連動。評価プロセス全体を「成長の触媒」に変え、EMコスト削減と納得感増幅を実現しました。

Learning Outcome

対象聴衆

• Engineering Manager (EM) / チームリーダー: メンバーの成長と評価に悩む方、マネジメント工数を削減したい方。
• VPoE, CTOなどのエンジニアリング組織のリーダー: 組織全体の評価基準の統一と、評価プロセスの仕組み化を検討している方。
• 評価制度の設計・運用に携わる人事・組織開発（HR/OD）担当者: EMと連携し、評価の納得感を高めるプロセス設計の事例を知りたい方。

得られるもの

1. マネジメントのレバレッジ向上：統一された評価基準を組織資産として言語化し、定常的な個別説明コストを削減する方法。浮いた時間を一歩踏み込んだキャリア議論に集中させる運用術。
2. 納得感の確実な醸成：査定時の「びっくり」をなくし、評価におけるアピール格差を是正し、自己評価が低いメンバーの貢献を正しく可視化する評価支援プロセスとロードマップ。
3. 組織変革のシステム設計論：個人目標（OKR）、360度評価、フィードフォワード面談の3つを連動させ、成長と効率化を増幅させる一貫した評価システムの設計フレームワーク。