概要

私たちの開発組織では、目的別チーム構造のもとでEM（エンジニアリングマネージャー）を独自ロールとして運用していました。
EMは複数チームを束ねる立場として、もともと組織変更や配置計画にも深く関与していましたが、会社制度上の正式な「マネージャー」ではなかったため、評価や人事決定といった権限を十分に持てませんでした。

そのため、EMが責任を果たすには、制度上のマネージャーを兼任する必要があり、兼任による追加業務が負荷となって EMを増やしにくい構造 になっていました。

この問題を解消するために導入したのが、 職能別マトリクス組織 です。
職能軸を明確に持たせることで、EMを会社制度上のマネージャー枠組みに接続し、形式的な兼任を不要にしました。
現在は、四半期ほど運用を経て、 新たにEMを追加任命しやすい体制 が動き始めています。

本セッションでは、

• 制度の外にあったEMロールを、制度の内側へ位置づけ直すまでのプロセス
• その中で整理した権限設計・責任範囲・評価体制の具体例
• 制度変更後の運用で見えてきた変化と、新たに発生した課題

を具体的に共有します。

EMが現場と制度のあいだで、どのように動けば組織を前に進められるのか、今も模索を続けている実践をお話しします。

Learning Outcome

対象：

• 複数チームを見ているEM、または制度設計・組織設計にも関わる立場のマネージャー

得られるもの:

• EMの役割を制度上の位置づけに接続するための現実的ステップを学べる
• EMを拡張可能にする構造設計と運用上の工夫を理解できる
• マトリクス化による権限整理と現場運用のリアルな課題を学べる

概要

「EMって何してるのか、よく分からない」
そんな声をきっかけに、私たちは “EM同士の雑談を垂れ流す社内ラジオ” を始めてみました。

隔週の社内勉強会のあとに15分だけ実施。スケジュールを先に決めて締切駆動にして、事前準備はトークテーマを考えるだけ。録画や集客は既存の勉強会の仕組みに乗せる。など、 運用負荷を極力増やさない設計 にしました。
アンケートや特別な編集もせず、 「続けることを最優先」 に継続しています。

まだ始めて3ヶ月ほどで、明確な効果は見えていません。
それでも、EMが何を考えているのか、どう意思決定しているのかを少しでも伝えられる手段として、価値を感じ始めています。

このセッションでは、 “透明性を仕組みではなく、日々の発信の積み重ねで育てる” という視点のもと、社内ラジオを通じて見えてきた運営の工夫・違和感・気づきを率直に共有します。
「成果が出る前の試行錯誤」を通じて、 EMの透明性をどう増幅していけるか を皆さんと考えたいです。

Learning Outcome

対象：

• チームやメンバーとの情報共有・信頼形成に悩むマネージャー

得られるもの:

• EMが透明性を高めるための“無理なく続ける”仕組み設計を学べる
• 成果が見えない段階でも実践を続けるための考え方を得られる
• 透明性は、仕組みよりも“日々の発信”の積み重ねで育つという視点を持ち帰れる

いわゆるパラシュート人事のような形で既存組織にジョインしたEMが直面する代表的な課題として「コードベースの理解不足」「事業ドメイン理解不足」「既存メンバーとの信頼関係不足」が挙げられます。

私はEM候補として中途入社した自社Webプロダクト開発企業で、上記課題を解消する一環として社内問い合わせ窓口対応を継続してきました。
問い合わせ調査と対応を重ねる中で個人レベルでの上記課題の解消だけでなく、開発組織やプロダクトレベルへEMとしての貢献領域を広げられることが実感としてわかってきました。

これまで累計数百件の問い合わせに対応してきた約2年間の経験から、本セッションでは以下気づきを共有することで、参加者の学びや行動のきっかけにつなげられたらと考えています。

1. チームへと広げる。信頼を築く窓口対応の実践
   • 初動返信を徹底する
   • 緊急度と重要度を判断する軸を磨く
2. プロダクトへと広げる。統計データからの改善プロセス構築
   • 問い合わせの傾向と頻度を把握する
   • 優先度に応じた改修プロセス構築とタスクの見える化
3. 組織へと広げる。顧客志向醸成に向けての展望
   • 社内業務と問い合わせ先に存在するユーザーを理解する
   • EMの隣接領域としてCRE業務を捉える挑戦

対象の聴衆

• 専任CRE組織がない環境で自社プロダクトを開発するEM
• 中途入社・異動でEMポジションに就いた方
• プレイング要素を委譲する中で、新たな選択肢を模索するEM

Learning Outcome

• 社内問い合わせ窓口対応からチーム内外との信頼関係を構築する具体的手法
• 問い合わせ調査を介して、プロダクトの安定運用に貢献する方法
• 問い合わせ対応の構造化を通して、顧客志向を組織へ広げるためのヒント

概要

メンバーとコミュニケーションをするたびに「バランスが大事」「上が言っているから」と曖昧なことを言っていませんか。
また，相手の発言を "自分の感覚や感情で" 否定したりしていませんか。

「言語化」は開発組織で合理的な意思決定をする上で最も重要です。私たちは普段，ロジックを積み上げてプロダクトを作っています。
しかし，マネージャーというロールを担った途端にロジックがうまく形成できないといった悩みを持っている方も多いのではないでしょうか。

マネージャーを長期間担っている方でも，曖昧な表現であったり，それこそ感情的なコミュニケーションの取り方になってしまっている方も見受けられます。

マネジメントは色が出やすいロールでもありますが，一貫して言えるのは，マネジメントの役割はスループットの最大化だと私は考えています。
スループットを最大化するためには，会社・事業の仕組みを理解し，言語化してメンバーに伝えていく必要があります。

本セッションでは，開発組織において合理的な意思決定をするための考え方から言語化まで解説します。

Learning Outcome

対象の聴衆

• エンジニアリングマネージャー，VPoE，CTOなどマネジメント職を担っている方
• 言語化に悩みを持たれている方

得られるもの

• 明日から実践で使える合理的な意思決定の方法
• 対メンバーに対して納得度合いを上げるコミュニケーション・言語化の方法

概要

一言でEMといっても、そのあり方や求められることは組織によって大きく異なります。
私は2025年1月からSREチームのEMを務めています。
SREチームは直接的なプロダクト開発から距離があり、チーム内に中長期の開発方針を決めるPdM（プロダクトマネージャー）が存在しません。

PdMがいないチームでは、「何を優先すべきか」「自分たちは何のために存在しているのか」を自分たちで定義する必要があります。
こうしたチームはSREに限らず、QA・データ基盤・Platform Engineering・セキュリティ・MLなど、プロダクトを支える領域に広く存在します。

私たちのチームもまさにその状況でした。日々の改善や運用タスクをこなしながら、「意味がないわけではないが、事業にどう貢献できているのか実感できない」という課題を抱えていました。

こうしたチームでは、EM自身が“プロダクトマネジメント的な役割”を担う必要があると気づきました。
チームのMissionを再定義し、業務をカテゴリごとに整理し、バックログを事業価値の視点で見直す、などの試行錯誤を通じて、少しずつ「自分たちの仕事の意味」をチーム全員で再定義していきました。

本セッションでは、PdM不在のチームのEMが事業価値と向き合うために行った具体的な工夫と、その中での失敗・気づきをお話しさせていただきます。

Learning Outcomes（聴衆が得られること）

• PdM不在のチームが自律的に事業価値とつながるアプローチの実例を知る
• プロダクトマネジメントの思考をチーム内に育てた実例
• 事業貢献、広くいうと「自分たちの仕事の意味」を再発見するまでのリアルなプロセスと苦労を知ることで、自分のチームでの変化のヒントを得られる

概要

スクラムマスター（SM）/アジャイルコーチ（AC）からエンジニアリングマネージャー（EM）へのキャリアパスは、まだ少数派だと感じます。
本セッションでは、登壇者がSM/ACからEMへとキャリアを移行した実体験をお話しします。
企業の急成長期において、SMとして一つのチームにコミットするだけでは事業全体に大きな影響を与えられないと感じ、より大きな影響力を持って事業に貢献するためEMになることを決意しました。
EMとしての1年間の経験を通じて、EMには「確固たる定義がない」という現実でした。SM時代に培ったサーバントリーダーシップが、必ずしもEMとして全ての状況で最適解とは限らないこと 、そしてチームの状況に応じて事業価値や顧客価値に貢献するために不足している部分を補う「何でもやる」姿勢の必要性を痛感しました。
本セッションでは、従来のプロセス改善といった得意分野が活かせない状況下で、事業価値や顧客価値に貢献するための別の「武器」を持つ必要性を感じた経緯や、チームの状況に応じて自らが適応し、足りない部分を補う「チームにとって必要なこと、事業にとって必要なことは何でもやる」という、より広範囲な「何でもやる」姿勢こそが、真のエンジニアリングマネージャーに求められる立ち振る舞いであると結論付けます。

Learning Outcome

対象の聴衆

• これからエンジニアリングマネージャー（EM）を目指そうとしている方
  • スクラムマスターやアジャイルコーチからEMへのキャリアチェンジを検討している方
• エンジニアなど、他のロールからEMへのキャリアチェンジを検討している方
• 現役のEMで、自身の役割や立ち振る舞いについて他の事例を知りたい方

その人たちが得られるもの

• SM/ACからEMという、まだ一般的ではないキャリアパスの実例
• EMの役割に「確固たる定義がない」中で、事業やチームの状況に応じてどう価値貢献していくかの視点
• サーバントリーダーシップがEMの現場でどのように機能し、またどのような限界があったかという実例
• EMとして事業価値に貢献するため、自身の得意分野（プロセスマネジメントなど）以外で「何でもやる」必要性に直面した際の具体的な行動例

「概要」

「EMポジションでの転職が初めて」— 私が身構えていたのは、「お手並み拝見」という見えない壁でした。
しかし、その不安は杞憂に終わります。
なぜか？ 分析して見えたのは、単なる運ではなく、新任の私と「受け入れ側」の行動が噛み合った「協奏」でした。
私（新任EM）が意識したことは 「リスペクト」と「アクセル調整」です。
まず、転職者が陥りがちな「前の職場との違いを、今の職場の課題としてしまう」ことを避けるため、徹底的に「過去の意思決定へのリスペクト」に注力し、信頼の土台を築きました。
同時に、自身の理想とのGAPに対しては「踏みすぎか？もっと踏むべきか？」と、自らアクセルの踏み具合をチューニング。周囲にフィードバックを求め、最適な速度を探り続けました。
受入れ側が意識していた（であろう）ことは絶妙な「期待値調整」と「戦略的チャレンジマネジメント」です。
「期待はしているが焦らなくて良い」と伝えつつ、"期待していない"と誤解される難易度の低すぎるタスクも、"パニックになる"緊急度の高すぎるタスクも避ける。
私を信頼し、「重要だが緊急ではない」絶妙なアサインメントを任せることで、早期に「アウトプット」を出す機会を創出してくれました。
本セッションは、この体験を再現性ある仕組みとして棚卸ししたものです。「自分が受け入れる側になった時に活かしたい」、このオンボーディングの協奏モデルを20分に凝縮してお話しします。

「Learning Outcome」

対象の聴衆

• （特に重要） 新しいEMをチームに受け入れ、その立ち上がりを支援したいマネージャーやメンバー
• EMポジションで初めて転職し、どう価値発揮すべきか悩んでいる方
• エンジニアからEMへのキャリアチェンジを目指す方

  その人たちが得られるもの

• 新任EMが「お手並み拝見」の壁を越えるために、「受入れ側」が仕掛けるべき「絶妙な期待値調整」と、"簡単すぎず・緊急すぎない"「戦略的チャレンジマネジメント」の手法
• 新任EMが信頼を獲得するために、「本人が」実践すべき「過去へのリスペクト」と「フィードバックを活用したアクセル調整」という具体的な行動
• 新任EMと受入れ側の「すれ違い」を防ぎ、「協奏」を生み出すための、最初の90日間のオンボーディング設計図

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

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

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

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

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

Learning Outcome

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

概要

複数ドメインの並行開発が進む中で、チームの認識齟齬とリリース効率の低下に直面しました。 EMとして、私は「Project / People / Technical」を横断しながら、チームの理解と実装をつなぐ構造の再設計に取り組みました。

当時のチームは、各人が別タスクを進める“リソース効率”型の進め方に陥り、さらに新規ドメインのキャッチアップとリリースが並走していました。 認識ズレや手戻りが増え、チーム全体の学習速度とアジリティが低下していました。 この混乱を抑えるため、PdM・QA・実装担当・レビュアー全員で行うタスク分解セッションを導入。 FigJam上で受け入れ条件・要件・実装方針・テスト観点を整理し、1つのPBIを全員で分解して理解を揃えました。

当初は不確実性を最速で減らすための対応でしたが、振り返るとこれは、チームが課題を認識し、理解し、判断できる構造をつくる試行でもありました。
PdMは実装難易度を肌感で掴み、エンジニアはWHYを踏まえた実装を行い、QAは仕様不足に気づけるようになりました。 短期的にはスプリントが安定し、レビューや再実装に伴う手戻りが減少しました。
一方で知識や判断軸の非対称性は依然として残り、「どこまで同期し、どこから任せるのか」という構造設計の境界に今も模索が続いています。

本セッションでは、リソース効率の罠を超え、チーム状態に合わせてフロー効率と学習構造を再設計する実践を紹介します。
以下のブログに記載した実践の振り返りを踏まえ、そこからさらに見えてきた課題と仮説を共有します。
https://tech.up-sider.com/entry/20251003_card-division

Learning Outcome

対象：

• 複数ドメイン・複数案件を同時に抱える EM / PdM / Tech Lead
• スプリント内で認識ズレ・手戻り・リリース遅延に悩むチームを率いる方

得られること：

• 複雑なドメインでも、チーム全体で理解と判断を同期させる構造設計の具体的アプローチを学べる。
• タスク分解や意思決定の可視化を通じて、理解と速度を両立させるファシリテーション設計の実例を得られる。
• EMがチームを“動かす”のではなく、“自ら動き出す構造”を設計するための思考の枠組みを持ち帰れる。

デジタル庁は設立から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 の成長を支援する材料を得られる

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

▼概要
2025年3月、私は上場スタートアップ株式会社Rebaseに初の外部ディレクターとして参画しました。前任者は共同創業者で元CTO。技術力が高く組織から信頼される10歳年下のリーダーです。30名で上場を成し遂げ、入社時には45名に成長した組織。この継承に臨むにあたり、私は3つのミッションを定義しました。
・創業取締役元CTOからのスムーズな引き継ぎを実現すること
・外部ディレクター初事例として会社に成功体験をもたらすこと
・自部門だけでなく全社視点で価値を創造すること
エンジニア出身でEM・VPoE、事業責任者、プロダクトマネジメントなど約20年のキャリアを持っていますが、外部参画の壁は高かったです。

第1階層：組織の歴史を最大限尊重する（最初の3ヶ月）
最初の3ヶ月は変革を起こさないと決め、社員の80%と1on1を実施。前任者との週次1on1も提案し、「まず理解する」ことで課題の質を高めることを重視しました。
第2階層：見えない課題を発見し先手を打つ（4〜6ヶ月）
事業責任者経験を活かし、事業計画から未来の課題を予測。PMやCXチームとの連携を少しずつ深め、水面下で自部門メンバーのキャリアなどもヒアリング。未来の体制変更に向け準備を進めました。
第3階層：信頼を基盤に変革を実行する（7〜12ヶ月）
下期開始時には、エンジニアリング部門12名の大幅な体制変更を実施。幸いにもメンバーからの大きな抵抗はなく、「なぜこの変更が必要か」を理解してもらえたように感じます。

このトークでは、外部参画の最初の1年で私が直面した課題、試行錯誤、失敗と小さな前進を率直にお話しします。

▼対象の聴衆
・外部から参画したが組織に溶け込めず苦戦しているエンジニアリングマネージャー
・組織変更や体制変更に抵抗を感じ、実行できずにいるリーダー
・上場後の成長ステージで組織課題に直面しているリーダー

▼その人たちが得られるもの
・「ヒトに興味を持つ」ことから始まる信頼構築の実践手法 - 社員の80%と1on1を実施した具体的アプローチと傾聴
・外部参画者が最初の1年で成果を出すための取り組み - 信頼ゼロから体制変更実施までの具体的ロードマップ
・エンジニア×事業責任者×PMの3視点を統合した連携術 - 技術・事業・プロダクトを繋ぐ具体的な取り組み

現職に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が持続的に機能するための実践知

本セッションでは、生成AI機能を開発するチームとタブレットアプリを開発するチームで直面した課題について、我々が試行錯誤したアプローチや学びについて紹介します。

生成AI機能開発チーム

生成AIを活用した新機能開発プロジェクトが発足し、社内でメンバーを集めて生成AIチームを立ち上げました。

チームとして活動を進める中で、いくつか課題がありました:

1. 社内に生成AIを専門とするエンジニアが不在で、一からキャッチアップする必要があった
   最初はkintoneをデータソースとしたRAGの機能を提供するために、自分が主導してPoCを作ったり設計をしてチームに展開しました。
   それと並行してLLMに関する知識のキャッチアップをチーム皆で進めつつ、機能開発を進めていきました。

2. 属人化していて、自分含む特定のメンバーが抜けると業務が回らなくなるリスクがあった
   OJT方式で併走することで、後任を育成するところを進めました。
   こうしたことで移譲が上手くいったのもあり、組織化して堅牢な体制を作ることができました。

モバイルチーム

kintoneと連携できるタブレットアプリ開発のプロジェクトが発足しました。

モバイルチームの課題として、
開発速度が遅い→Webチームの方が価値提供が早い→機能開発の経験が積めない→開発速度が遅い...の負のスパイラルに陥っていて、周囲からも信頼が得られていない状況が続いていました。
チームとしても、利用できるAPIが整備されていないことや、UI/UXデザイナーが不在なことが要因で遅くなっていると他責なマインドになっていました。

開発速度が遅くなっている要因を特定するため、メンバーへのヒアリングや実際の開発現場の観察を通じて情報収集を行いました。
その結果、メンバー間のスキル差とAPI整備の不足という2つの課題が浮かび上がったため、まずはこれらの改善に着手しました。
特にモバイル開発において、APIが十分に整備されていないという問題がありました。そこで、共通インターフェースの設計方針やチーム内のコミュニケーション方法を決定し、開発環境を整えていきました。
こうした施策を実施した結果、徐々にメンバーの意識が他責から自責へと変わっていく変化が見られました。

現在私は、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. ハンズオンと組織視点の間を行き来できるマネジメント体制の設計ヒント（特に少人数・高速開発を前提とした体制）

■ 概要
本セッションでは、「会議名」や「アンケートの問い方」の改善事例を通して、言葉がもたらす変化と、言葉をデザインするという考え方を紹介します。

言葉ひとつで、人の感じ方や行動は大きく変わります。
上司から来る「ご相談」というスケジュール、Slackでの「ちょっといいですか？」──その一言を見ただけで、なんとなく身構えてしまうことはありませんか？

この“言葉がつくる空気”は、個人のやり取りだけでなく、組織の中にもあります。会議やイベントの名前、アンケートの質問文など、そこで使われる言葉が、場の雰囲気や関係性を無意識のうちに形づくっています。

そうした組織の中の言葉を見直す中で、「全体定例」や「休憩時間」の名前を変えたらどうなるのかを試してみました。たったそれだけのことでも、形式的な報告の場だった定例が、対話が生まれる場へと少しずつ変わっていったのです。

プログラミングで変数名にこだわるのと同じように、会議体という“プログラム”の名前や設計を見直すことで、チーム文化や心理的安全性は大きく変わります。

これらの事例を通じて、“言葉をデザインする”という考え方をどのように組織づくりへ応用できるのか。ポジティブな要素を増やし、前向きな対話を生むための小さな工夫とヒントを紹介します。

■ アウトライン
・言葉がつくる印象と空気──「ご相談」が与える心理的影響
・全体定例の名前を変えた理由
・アンケートの問い方を変える
・言葉をデザインするという考え方
・言葉を変えると文化が変わる

■ このトークから得られる学び
・言葉の選び方が人の心理や行動に与える影響を理解できる
・質問やアンケートの設計によって、チームの心理的安全性を高める方法を学べる
・言葉をデザインすることが、組織づくりの重要な手段であると気づける

■ ターゲット
・チーム運営や組織文化づくりに関心のあるエンジニア、マネージャー
・勉強会・定例会・社内イベントを企画・運営している方
・言葉やコミュニケーションの力でチームをより良くしたいと考える方

■ 予備知識
・特別な前提知識は不要
・チームビルディングなどの経験があると理解が深まる
・自分のチームや会議の「名前」「伝え方」「聞き方」を見直してみたい方におすすめ

■ 概要

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

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

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

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

■ Learning Outcome

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

◻︎概要

コーチングは、答えを与えるものではなく、その人の中にある“願い”や“感情”を探究し、言語化していく時間です。
AIが多くの問いに即座に答えを出せるようになった今も、「自分は何を望み、なぜそう感じるのか」という内面の理解は、自分で設計するしかありません。
人が自律的に行動するためには、外からの指示ではなく、自分の内側から湧き上がる動機（内発的動機づけ）が不可欠です。
コーチングは、その内発的な動機を明らかにし、感情・思考・行動をつなぐ構造を整理する対話の手法です。
本セッションでは、ライフコーチングの観点から、日常のモヤモヤやイライラといった感情をデータとして扱い、自分の行動を再設計するプロセスを紹介します。

コーチングを特別なスキルではなく、“思考と感情の関係性を構造的に理解し、内発的に行動するための設計アプローチ”として捉え直すきっかけになれば嬉しいです。

◻︎Outline / Structure of the Talk（予定）

1. 導入：テーマと目的の共有　
2. コーチングの基本構造
3. 人が変化する旅のモデル　
4. コーチングの実践と伴走の意味
5. まとめ：日常への応用と一歩のヒント

◻︎Prerequisites for Attendees

・ 自分やチームの感情・思考・行動の関係を振り返る意欲がある方
・ コーチングや内省の経験がなくても問題ありません

◻︎Learning Outcome（対象の聴衆 / 得られるもの）

対象の聴衆:

・ エンジニアリングマネージャー、リーダー、PdMなど、チームの自律的成長を支援する立場の方
・ 「内発的動機づけ」や「自律的行動」に関心があり、実践へのヒントを探している方
・ コーチングを、日常の対話や思考整理の手法として取り入れたい方

得られるもの:

・ 感情・思考・行動の関係を振り返り、内側にある動機を見つめ直すきっかけ
・ 無意識の構造（願い→感情→思考→行動）への理解を深める視点
・ コーチングを“内省を支える設計的な対話”として捉えるためのヒント
・ モヤモヤや違和感を、成長や変化のサインとして扱う小さな気づき

私は某企業でエンジニアをしてる傍ら、副業として弓削商船高専で教員を務めています。
今年度は学生たちと全国高専プログラミングコンテスト（プロコン）に挑戦しました。

プロコンは半年という短い期間で、アイデア発想から実装、ユーザテストまでを進めるプロジェクトです。

参加した学生は合計12名。経験も知識もまちまちで、評価制度・意思決定フローも未整備。
教員として学生エンジニアと関わる中で意識したのは、「どうすれば学生が最後までやりきれるか」という点でした。

プロジェクト初期は、開発スケジュール策定・実行を学生に任せました。
その上で、私は全体方針を示し、進め方や優先度を一緒に整理しながら進行を支援しました。
報告の場では成果だけでなく、進まない理由や迷いも共有してもらうようにし、失敗を責めずに次の行動へつなげる会話を心がけました。

プロジェクト中盤 ~ 終盤の開発現場では不具合で進まない開発の不満・ストレスを報告する子、何も話さない子など多様なパターンの学生がいました。
進捗が滞るときはあえて時間を置いたり、短時間の面談で方向を整理したりと、学生が自分の意思で動けるような関わり方を試しました。
結果として、学生たちは期限ぎりぎりまで試行錯誤を重ね、最終発表を自信を持ってやり遂げました。

この経験から、「マネジメントとは指示を出すことだけでなく、チームが自分たちで動ける環境を整えること」だと実感しました。

このセッションでは、教育現場・コンテスト・半年で開発~評価までやり切る必要ありという特殊な条件下で行ったチーム運営を題材に、メンバーにやりきってもらうための環境設計・動機づけの方法について紹介します。
学校教育に限らず、インターンや若手育成など“教えながら進める”場面に役立つ考え方を共有します。

■ Target Audience

• 若手エンジニアの育成やインターン指導を担当しているエンジニアリングマネージャー・リーダー
• チームメンバーの自走を促したいマネージャー
• 学生向けエンジニアリング教育・育成の現場に興味のある方

■ Learning Outcome

• マネージャー1年目の悩み、苦悩のリアル
• 学生や若手メンバーの動機づけを支える観察とコミュニケーションの実践例
• 教育現場から学べる、チームの“自走”を引き出す方法