EMConf JP 2026参加レポート

2026年3月4日に、ブロンズスポンサーとして協賛した「EMConf JP 2026」にUPSIDERメンバーで参加しました。

2026.emconf.jp

今年のテーマは「増幅」と「触媒」。EMが組織のアウトプットをいかに加速させ、変化を促す存在になれるか。多角的な視点からEMの本質に迫るセッションが目白押しでした。

UPSIDERからはEMのMitsuiがCfPで登壇し、メンバーもそれぞれの視点で学びを持ち帰りました。

tech.up-sider.com

本記事では、各メンバーによるセッションレポートをお届けします！

1.「事業目線」の正体を解き明かす

セッション名：「事業目線」の正体〜3つのフェーズのCTO経験から見えてきた、EMが持つべき視点
登壇者：sotarok 氏

Report by 支払い.com事業部・CTO Akanuma

「もっと事業目線を持って」──自分自身も言われたことがあるし、周りに対しても言ってしまうフレーズです。本セッションでは、3社でCTOを経験されたsotarokさんが、この曖昧な「事業目線」の正体を3つのレベルで整理してくれました。

まずLv.1は「数字を知る」。自組織に関わるトラフィックや売上といった数字を把握し、事業構造の中で自部門がどこに作用しているかを理解すること。「いつも大体これぐらい」という肌感がなければ異常に気づけないという指摘は、数字を意識しているつもりでもパッと出てこないことのある自分には耳が痛い話でした。

Lv.2は「お客さまと隣接組織を知る」。CS研修でエンジニアが問い合わせ対応を経験すると、プロダクト改善で解決できる課題に気づけるというエピソードが印象的でした。実際、他チームがエンジニアの工数を遠慮をしてオペレーションで頑張ってくれているけれど、相談してもらえたら簡単に解決できるケースは自分たちのチームでも多いと感じています。

Lv.3は「戦略に反映する」。『HIGH OUTPUT MANAGEMENT』の「マネージャーのアウトプット＝自組織＋影響力が及ぶ隣接組織のアウトプット」という定義が引用されていました。組織図上の管掌範囲ではなく「自分が影響を及ぼせる組織」までを自分のマネジメント範囲と捉える視点は、今後意識していきたいポイントです。

今のチームは少人数ゆえに隣接組織との連携はある程度できていますが、組織規模が大きくなっても同じことを継続できるかはこれからの挑戦です。事業目線を個人の意識に留めず、チーム全体に仕組みとして組み込んでいくことの重要性を改めて感じたセッションでした。

2.規模拡大に伴う「意思決定」の脱皮

セッション名：特定領域から複数領域へそのとき何を求められるのか〜縦と横 2つの影響力・統合性を目指す大規模な開発組織での実践
登壇者：freee株式会社友澤慶人氏 Report by カード事業部EM Shunsuke

約150人規模の開発本部を率いる友澤さんによる、「縦の影響力（深さ）」と「横の影響力（広さ）」という2軸で整理されたマネジメント論です。現在10名規模のチームを見ている私にとっても、リーダーとしての「あり方」を再定義する貴重な機会となりました。

私は現在、マネジャーとして自分がボトルネックになる場面に直面しています。セッションで語られた「詳細把握の限界」という壁は、今の私に強く刺さりました。すべてを同じ解像度で把握しようとすれば、意思決定は必ず自分のところで滞ってしまうからです。

友澤さんはこれに対し、解像度を上げるべき場所を見極め、メンバーを信頼して「意思決定」と「環境整備」に専念するという割り切りを示されていました。「完璧でないといけない」という呪縛からの解放が組織の可能性を広げるという逆説は、勇気がいりますが、リーダーとしての脱皮には不可欠だと感じています。

組織横断の標準化についても考えさせられました。プロダクトが「統合型」を目指す以上、組織が疎結合なままでは実現できない価値があります。この「統合型のジレンマ」は、規模を問わずEMが向き合うべき構造的な課題です。調整を個人の頑張りに頼るのではなく、いかに仕組みとして機能させていくか。管掌範囲を広げていく上での大きなヒントになると感じました。

AI活用で組織のあり方が激変する今、リーダーが全情報の解像度を追い続けるのはもはや物理的に不可能になります。不完全さを受け入れ、任せるべきを任せる。組織のポテンシャルを最大化するための準備を、今の規模から着実に進めていきたいと思えたセッションでした。

3. 良い提案の裏側にある「4つの理解」と、場数を踏むための「覚悟」

セッション名：マネージャー版「提案のレベル」を上げる
登壇者：こにふぁー氏 Kyash 執行役員VP of Engineering
Report by カード事業部 Anti-Fraud Tech Team Ryutaro

過去に書いたブログがベースの内容の発表とのことで、何かを提案していく中のレベル分けとレベルを上げていくためにどういったことを意識するべきかを知れる発表でした。

提案にはいくつかレベルが分かれていて、そもそもレベルを上げた提案が難しい理由が説明されており、色んな軸の広がりによる変化が影響するというのは自分にはすごく納得のいく理由でした。

具体的に提案レベルを上げるためには「理解」と「覚悟」が必要とのことで、まず4つのポイント（組織図・目標・会議体・予算）を理解することが大事とのことで、これらはキーノートの「冒険する組織の作り方」でも同様の内容が重要だとして発表されていたポイントでした。こにふぁーさん自身が失敗したなと感じた事例を元に振り返るともっとこうするべきだったという内容もあり、とてもわかりやすい内容でした。

覚悟についても始めから上手くいくことは少なく、レベルを使い分けながら場数をこなしていくことも必要ということで、一定の覚悟は持ちながらも最初からうまくやろうとしなくて良いというアドバイスがとても印象に残っています。

自分も提案に関してはあまりレベルの高いものを出せていないと感じながらもモヤモヤしていたことがあったので、今回のセッションを通して長い目で成長が必要なんだと気持ちを楽にしてくれた発表でした。

4. ROIの先へ。キャッシュフローから逆算する「今、本当にやるべきこと」

セッション名：経営と会計とエンジニアリング
登壇者：前田和樹氏 Report by 支払い.com事業部 EM Okahashi

興味深かったのは、キャッシュフローから企業（事業）の財務状態を読み解くこと、そして技術戦略の判断軸としてもその財務状態を反映すべき、という視点でした。

個人的に過去を振り返ると、日常の仕事の中でも「コスパ / ROIは良さそうだけれど、今やるべきことではないかもしれない」と判断する場面はこれまでもあったように思います。ただ、その判断の根拠については、自分では「コストパフォーマンスやROIを見て判断しているのだろう」となんとなく理解していた程度でした。

今回のセッションを通して、単に施策単位のROIを見るだけではなく、キャッシュフローをベースに事業全体の状態を踏まえて「今それをやるべきフェーズなのか」を判断する必要がある、という整理が自分の中でできた気がします。

これまで「コスパは良さそうだけれど今ではない」と感じていた感覚が、キャッシュフローや事業フェーズという言葉で言語化されたことで、個人的にはとても腹落ちしました。ROIは施策の良し悪しを判断するうえで重要な指標ではありますが、それだけを見ていると「正しいが、今ではない」という判断を外してしまうこともあるのだと思います。

また、財務状態が厳しい場合でも、投資を完全に止めるべきではないという点も印象に残りました。短期的なキャッシュ確保だけを優先すると、将来の成長の芽まで止めてしまい、結果として事業が先細りになってしまいます。状況に応じて投資規模を調整しつつも、一定の投資は維持する。そのバランス感覚が重要なのだと感じました。

技術的には正しい提案であっても、事業の状態と噛み合っていなければ「正論だけれど少し的外れ」なものになってしまうことがあります。EMとしても、キャッシュフローを含めた事業の状態をできるだけ正しく理解したうえで、戦略や提案を考えていくことが大切なのだと改めて感じたセッションでした。

5.仕組みで「スーパーマン」を卒業する

セッション名：スーパーマンに頼らない"分権型組織"で作る強い開発チーム
登壇者：株式会社スマートバンク三谷昌平氏
Report by カード事業部 QAエンジニア Mizuki

EMconf2026で拝聴した三谷さんのセッションは、組織が拡大する中で「昔は防げていたはずの不具合」やお見合い状態をどう打破するかという、QAエンジニアとしても非常に身につまされるテーマでした。

特に印象的だったのは、委員会を半年サイクルで更新し、メンバーの「興味・好奇心」をエンジンにするという設計です。QAの現場では、テスト自動化や不具合の深掘りといった活動が、どうしても「余裕がある時にやるべきこと」というシャドーワークになりがちです。しかし、これを公認の委員会活動とし、さらに「やりたい人」がオーナーとなって裁量を持つことで、当事者意識が自然と芽生える仕組みは、品質向上を「自分たちのミッション」として捉え直す上で非常に強力なアプローチだと感じました。

また、危機感を可視化する「やばいよやばいよメトリクス」や、運用を資産化する「RUNbook」の徹底も、QAが理想とする「シフトレフト」の体現そのものだと思います。不具合が起きてから対応するのではなく、メトリクスが警告を出した時点でチームが自律的に動き、過去の知見がRUNbookとして誰でも引き出せる状態にある。こうした「仕組みで品質を守る」姿勢は、個人の能力に依存しない「強い開発チーム」の土台になると強く共感しました。

さらに、自然言語でクエリを叩ける「データ分析Agent」の活用には、大きな可能性を感じました。QAフェーズでの調査やテストデータの準備において、SQLのスキル差がボトルネックになる場面は少なくありません。エージェントを通じて「誰でも・即座に」データへアクセスできる環境は、現場の判断スピードが上がるだけでなく、チーム全体の『ちょっと調べたい』という気持ちを後押ししてくれる、本当に心強い仕組みだなと感じました。

今回のセッションを通して、特定のスーパーマンに頼り切るのではなく、仕組みと最新技術、そして「遊び心」を掛け合わせることで、組織の課題解決がいかにクリエイティブになれるかを学べました。このエッセンスを活かし、私もQAの立場から、より自律的で品質に強いチーム作りを加速させていきたいです。