概要

本セッションでは、組織拡大に伴い生じた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年目の悩み、苦悩のリアル
• 学生や若手メンバーの動機づけを支える観察とコミュニケーションの実践例
• 教育現場から学べる、チームの“自走”を引き出す方法

入社までは空白だった事業のエンジニア1号として入社し3年経過した時点でありがたいことにチームとしてメンバーを増員とともにEMというポジションを頂き1年経過しました。
その中であった苦労した点や今振り返るとみたいな話をしようと考えています。
例えば

• 一人でゴリゴリ開発してて標準化の用意できておらず採用後に教育するのに苦労した
• AIが回答してくれない部分の教育の難しさ
• 同じ方向性を向くためにどのようにしていったか
  対象としては新米EMやこれからEMを目指す方に向けて設定
  弊社はEMが人、開発環境、プロジェクト、プロダクト全てを網羅しておりそれぞれの要素ごとに振り返りと反省、教訓を語るので何かしらを拾ってもらえるかと考えています

トーク概要

マネージャとしての能力は才能でしょうか？
人的リソース管理、技術管理、スケジュール管理などさまざまな管理を一手に引き受けるEMというロールですが、
マネジメントとして人を動かして何かを為すということが本質であると考えています。
これを実践している人を見たときに才能や性格が向いていると思ったことはないでしょうか？

私もキャリアの上でいくつかのロールを経験した背景があるので、
仕事をしていて「GNSNさんの性格だからできてると思います」と言われたことが何度かあります。
私自身1年前までは自分の言動や、意識していることを把握したことはなかったですが、
EMがEMとしてのロールを体現してもらえるように他のEMに自分のノウハウを提供しなければいけないと感じ言語化をすることにしました。

その中でやはりマネジメント能力は才能ではなく、努力や経験で向上させられる技術であると改めて感じました。

ノウハウをただ伝えるだけでは実践に至ることができない方もいらっしゃると思いましたので、
それを実際に実践してもらうために行ったこと、それぞれの理解に繋げるための機会づくりについて
EMとしての生き方、失敗と学びを交えてお話ししたいと思います

アジェンダ

1. マネジメント能力は才能か？
   • 才能ではなく技術である理由
   • 必要なマインドや行動
2. 技術としてのマネジメントの説明
   • 人を動かす時に伝えるべきこと
   • 伝え方において重要視すること
3. マネジメント能力の向上方法と取り組み
   • 情報のキャッチアップについて
   • ディスカッションの時間作り
   • 採用活動はマネージャーとして成長の場

Learning Outcome

対象となる聴衆

EMを作っていきたいと思われる組織構築をミッションとしている方
組織を拡大していくスタートアップの方
マネジメントに挑戦される方
EMというロールに興味がある方

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

人を動かすために必要になるマインドや要素について
急激にチームが増加するときに気をつけることについて
マネジメント能力の教育方法について

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

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

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

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

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

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

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

■概要：

Webエンジニアとして開発経験はあるものの、HRTech SaaSであるカオナビやメルカリの会計システムのPdMとして7年以上PdMをやって、
昨今の開発現場からは遠ざかっていましたが、EMとして軸足をスイッチしたことでPdMとの違いや被っている点、
PdMを経験したEMだからこそチーム改善、エンジニアのエンゲージメント改善で意識した点などを中心に話をしたいと思います。
あくまで当社、当チームの例ではありますが、PdM視点のEM事例を共有出来れば幸いです。

・PdMの役割
・EMの役割
・チームの最初の状況
　・Wevoxの数値
・改善の導入
・チームはその後どうなったか？
　・Wevoxの数値
・改善はつづく
　・更なる改善の着手

■Learning Outcome：

キャリアに悩んでいる人にPdMの次のキャリアとしてEMというキャリアを提示。

ピープルマネジメント、エンジニアのエンゲージメント、仕事へのアトラクトを高めることに課題を感じている人に事例を共有。

■ 概要:
良かれと思って提案した「正論」が、チームに響かない。それどころか、現場を疲弊させているかもしれない…。そんな悩みを抱えるEMはいないでしょうか。
かつての私は、保守性や学習文化の重要性といった「正論」をチームに押し付け、変わらない状況に「どうしてわかってもらえないのか」と無力感を覚えていました。

人気アニメ『タコピーの原罪』で、相手の痛みを理解せずハッピー道具を押し付けるタコピーの姿は、まさに「無知で無邪気な」過去の私自身でした。
問題はチームではなく、彼らの文脈や「痛み」を理解しようとしなかった私自身にあったのです。

本セッションでは、この痛い「失敗」から学んだ、変革アプローチの転換についてお話しします。
理想（Gain）を語るのをやめ、チームの具体的な「痛み（Pain）」から始める対話こそが、変革の第一歩です。

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

• 良かれと思った「正論」や「ベストプラクティス」の導入が、チームに浸透せず悩んでいるEMやリーダー
• チームとのコミュニケーションに「壁」を感じているマネージャー

得られるもの:

• なぜ「正論」が「押し付け（タコピー問題）」になってしまうのか、その構造的な理由
• チームの「痛み」に寄り添い、対話を通じて内発的な変革を促す「Pain-Drivenアプローチ」への転換のヒント
• 自身の「無邪気さ」を客観視し、チームとの関係性を見直す内省のきっかけ

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

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

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

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

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

このセッションでは

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

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

想定リスナー

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

今の僕の開発チームでは、ビジネス上の顧客と直接話すセールスチームと開発チームの距離が心理的に離れていて、セールスメンバーと開発メンバーの直接のやり取りが少ない状態でした。そのため、顧客 => セールスメンバー => PM => 開発メンバーと、顧客の声は伝言ゲームで伝わってきており、開発チームに伝わってくる時には「How=サービスに欲しい機能」のみになって、「Why=顧客が本当に困っていること・やりたいこと」が分からないという状況でした。

このままだと顧客への理解を深められず、開発チームが顧客のためにより良いものを作りたいと思っても自律的に工夫できないと感じていました。これは非常に大きな課題です。

そこで開発チームが顧客をより理解できるように、僕は一歩ずつ施策を進めていきました。たとえば

• セールス側のチームの人と毎週会話して顧客の情報を引き出し、開発チームのデイリーで共有する
• 社内の懇親会では、セールス側の話したことのないメンバーに積極的に話してみる
• まずは自分で顧客への提案資料や議事録、録画を見てみる
• 毎週のミーティングで、セールスチームから実施した案件情報を共有してもらう
• 展示会などへの出展があったら自分もブース対応を行い、実際の顧客と話す
• 開発チームで議事録や提案書を読んで気づきの付箋を貼る会を実施し、顧客の情報をキャッチアップする機会を用意する

今回のトークでは、開発チームが顧客の理解を深められない課題に対して、どのような工夫をしながら解決を試みたか、具体的な経験を共有します。

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

• 対象の聴衆
  • ビジネス側の声が遠く、顧客像が曖昧になっている課題を感じている方
• 得られるもの
  • 少しでも顧客の声を聞くために具体的に何をやると良いか
  • 顧客理解に対して、開発チーム全体を巻き込むにはどうすれば良いか

メンバーからマネージャーにロールチェンジすることにはさまざまな変化が伴いますが、一番大きな変化は「人前で話す機会が増えること」ではないでしょうか。
権限が広がればそれだけ責任も重くなりますし、チーム内外へ説明を求められる機会も必然的に増えていきます。そしてメンバーに過不足なく情報を伝え、向かう先を同じくするためには、適切な粒度で「あなた自身が何を考えて、どのように行動するのか」を伝えることが必要不可欠。
しかしこの「伝える＝発信する」スキルは、わりに難易度が高く、慣れと習熟が必要です。

そこでみなさんにおすすめしたいのが、「気軽な社外への発信」を通じて習熟のサイクルを回すこと。私も普段の仕事における試行錯誤を振り返り、まとめ、社内外に小さく発信するサイクルを回すことで、少しずつ習熟していきました。
というわけで、このトークでは、事業とエンジニアリングのマネジメントについて探求を重ねるひとりのEMが、社内の発信活動（日々のコミュニケーション・ドキュメンテーション、プレゼン）と社外の発信活動（ブログや登壇から、書籍の執筆に至るまで）をどのように相互に影響させ合ってきたかを、実例をたっぷり交えながらお話しします。皆さんにとっての踏み出しやすい「発信の最初の一歩」を見つける機会となれば幸いです。

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

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

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

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

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

背景

あなたの組織では、個人目標（OKR）が「強制的に課せられたルール」になっていませんか？私たちのチームも、古い資料が実態に合わず、新卒への説明コストが肥大化していました。個人目標設定が形骸化している状態は、EMの説明責任コストを増やし、メンバーの視座を下げて成長を停滞させます。

内容

本セッションでは、組織横断的な定例会議を活用し、個人目標を「従業員を評価するツール」ではなく「非連続な成長を促すコミュニケーションの触媒」へと再定義したプロセスを共有します。キャリアラダーを再整備し、「このグレードでは何が求められ、ステップアップにどう目標を使うか」を明確にしました。「一つ上の職務を満たす」を組織としてアピールする視点を目標設定に組み込み、メンバーが自発的に高い目標を立てる基盤を構築。議論を経て統一された資料を展開することで、EM自身の業務コスト（解釈や個別説明）を組織資産に変え、効率化を実現しました。

Learning Outcome

対象聴衆

1. EM/ チームリーダー:
   • 個人目標に関する同じ説明を何度も繰り返すマネジメントコストに悩んでいる方。
   • 目標設定面談を、単なる進捗確認ではなく、メンバーの非連続な成長を促す本質的なキャリアディスカッションに変えたい方。
2. VPoE, CTOなどのエンジニアリング組織のリーダー:
   • 組織全体の評価基準とメンバーの視座に統一感がなく、成長を加速させる仕組みを求めている方。
   • 属人化していたOKR運用を、新任EMでもすぐに使える組織資産として確立したい方。

得られるもの

1. 成長を誘発する目標設計：目標設定プロセスに「視座上げ」の要素を組み込み、個人目標をメンバーの自律的な成長を促す触媒に変える具体的な資料と運用法。
2. EMの工数削減：統一された基準で前提認識を揃えることで、個別説明にかかっていた時間を劇的に減らし、面談時間を「目標設定の深掘り」という本質的な議論に充てる方法。
3. 納得感の増幅：メンバーの「自分で目標を立てている」というオーナーシップを強化し、個人目標面談での納得感を高めるロードマップ。

背景：評価プロセスが抱える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つを連動させ、成長と効率化を増幅させる一貫した評価システムの設計フレームワーク。

背景：評価インプットの品質問題

メンバーから「360度評価（他者評価）をどう書けば良いか分からない」というフィードバックを受けたことはありませんか？その結果、「書いたは書いたけど分析がない」「そもそも記述がない」といった品質の問題が発生し、評価インプットが不足していませんか？これは、評価の土台となる情報が不十分であるため、EMの評価判断コストを増やし、組織の評価統一感を欠く原因となります。

内容：ベストプラクティスという触媒

本セッションでは、360度評価の質を向上させるため、評価入力の仕組みそのものに「触媒」を投入した実践を共有します。査定の振り返りから、良い記述と悪い記述のセンシティブな事例を分析し、「成果とインパクト」の視点が欠けているという核心的な課題を特定しました。良い記入例と、それが「なぜ良いのか」という評価者目線の解説をセットにしたベストプラクティス集を組織全体に展開。これにより、360度評価の記述品質と量の増幅を促しました。ベストプラクティス集を参照し、集中して記述に取り組む時間を確保するなど、運用プロセスに組み込み、一過性の情報展開に終わらない仕組みを作りました。

Learning Outcome

対象聴衆

• エンジニアリングマネージャー（EM）/ チームリーダー
• VPoE, CTOなどのエンジニアリング組織のリーダー
• 評価制度の設計・運用に携わる人事・組織開発（HR/OD）担当者

得られるもの

1. 評価インプットの品質向上とコスト削減：定性的な評価の「良い基準」を明確化し、360度評価の記述品質と量の増幅を達成する具体的な資料設計と展開手法。質の高いインプットが揃うことで、EMが評価材料のヒアリングや補完にかける工数を削減する方法。
2. 評価リテラシーの統一感醸成：評価の書き方に関する認識を組織横断で統一し、新卒も含めた全メンバーの評価プロセスへの参加意識とリテラシーを底上げするロードマップ。
3. 内向的なメンバーの貢献の可視化：目立つ貢献だけでなく、「書けない」という課題の裏にある公平性の課題に対処し、多様なメンバーの活動を適切に評価するためのインプットを確保する視点。

概要

組織やプロダクトは、創業期（0→1）、成長期（1→10）、成熟期（10→100）、再構築期といったライフサイクル（フェーズ）を経て進化します。本セッションでは、なぜフェーズが変わるとリーダーシップも変化するのか、具体的にどのように自ら／チームが変化に対応すべきかを掘り下げます。

具体的には以下を扱います

• 各フェーズにおける組織目的・リーダー像・主導スタイルの典型パターン
• フェーズが進む中でリーダー・マネージャーが陥りやすい“思考のズレ”とその回避策
• メンバー／リーダー双方において「今、自分はこのフェーズにいる」と見定め、振る舞いを変えるためのヒント
• リーダーにとってだけでなく、フォロワー・メンバーとして組織の文脈を読み、自分の立ち回りを最適化する視点

このように、“フェーズを起点としたリーダーシップの再定義”を通じて、組織成長の流れを意識したマネジメント／フォロワーシップを紹介します。

Learning Outcome

対象となる聴衆

• エンジニアリングマネージャー、テックリード、プロダクトマネージャーなど、組織／チームの管理・運営に関わる方
• 成長フェーズあるいはスケール段階にある組織に所属し、マネジメントスタイル／チーム運営を見直したい方
• リーダーではないが、チーム文脈を理解してより主体的に動きたいメンバーの方

得られるもの

• 自社／自チームが「今どのフェーズ」にあるかを客観的に判断するためのフレームワーク
• 各フェーズで有効なリーダーシップ／マネジメントのアプローチと、その根拠
• フェーズに合っていない振る舞いを“ズレ”として捉え、改善のヒントが得られる
• メンバー視点で「フェーズを理解し、どう振る舞うか」の考え方を手にすることで、フォロワーシップを強化できる
• 組織の成長段階に応じたチーム運営・マネジメント設計を、自チームに適用するための示唆