概要

エンジニアの生産性やモチベーションを低下させる一要素として「割り込みタスク」があります。
割り込みタスクはできる限り避けたいものですが、全く発生しない組織はないでしょう。

エンジニア組織やエンジニアをマネジメントする上で避けては通れないこの問題に対して、
"あなたがメンバーから「割り込みタスクが多くて困ってます」と相談された"
というシチュエーションを仮定して、どのように問題解決するかを話します。

このテーマについて、過去にエンジニア・デザイナーのマネージャーとしてブログ記事を書き、400ブクマをいただきました。
https://naopr.hatenablog.com/entry/2024/08/18/094343

このセッションでは、ブログで紹介した「個人」「チーム」に加えて「組織」観点から解決を試みるアプローチを紹介するほか、
エンジニアに特化したより具体的な対策についても話します。

Learning Outcome

• メンバーから抽象的な相談をされた際にヒアリングを通じて課題を明確化し解決するアプローチ
• エンジニアが受ける割り込みタスク多すぎ問題を解決するための実践的な方法
  • エンジニア個人の問題として解決する方法
  • エンジニアが所属するチームの問題として解決する方法
  • エンジニア組織として解決する方法
  • プロダクト組織全体で解決する方法
  • プロダクト組織以外も巻き込んで解決する方法

概要

転職が一般的になりつつある今の時代ですが、「1つのサービスに長年携わることでこそ、システム設計における深い学びが得られる」という意見も増えています。私は飲食予約サービス「Retty」に関わって6年、その間にEMおよびVPoEとして大小さまざまな課題と向き合い、改善を重ねてきました。

本講演では、以下の具体的な事例を通して、各局面でどのような判断や実装を行い、何を学んだか、そして今どのようにその経験を振り返っているかを共有します。

• スクラムと大規模スクラム（LeSS）の導入：アジャイルを拡張して適用する中での成功と失敗
• マイクロサービスアーキテクチャへの移行：モノリシックからの脱却と、その後のシステムの柔軟性向上
• ライブラリやフレームワークの選定プロセス：技術選択の重要性とチームへの影響
• 内製システムのマネージドサービスへの置き換え：効率化とスケーラビリティを実現するための決断

この6年間で積み上げた知見をもとに、長期的な視点でのシステム改善や技術選定、チームマネジメントに関する実践的な学びを紹介します。

Learning Outcome

継続的な改善に関心があるEMや技術リーダー・意思決定者が下記の内容を学ぶことができます。

• 同一サービスへの長期関与で学んだシステム設計と改善の学び
• 技術選定やサービス移行を通じた効率化と成長戦略
• 持続的改善のためのチームマネジメントと意思決定のヒント

概要

Engineering Management に関するグローバルなサーベイである 2024 State of Engineering Management Report 、国内外論文、国内外カンファレンスの概要とトレンドを知れるセッションになります。

Engineering Managementを実践する時のエントリーポイントおよび自分のアウトプット場所の目安にもなります。Engineering Managementの基本用語を知っている前提になるかとおもいますが、全て参照先を明記するようなスライドになりますので、多くの方に見ていただきやすいセッションになるかと思います。

Learning Outcome

• Engineering Managementの国内外のイベントで発表してみようと思える
• 社内の改善に対して客観的に観察できるようになる

参考スライド

• プロダクトマネジメントのグローバルトレンド #pmconf2023

Outline

• 2024 State of Engineering Management Reportの紹介
  • 世界的なトレンド
  • 各トレンドに関連する論文
• Engineering Manager Conference Japan2025のセッションとの比較
• 海外Engineering Managementカンファレンスのセッションとの比較
• Engineering Manager Conference Japan2025と海外カンファレンスの相違

概要

某動画配信サービスの某相撲ドラマを見た時に組織のあり方として非常に理想的だなとビビッときました。
組織が一丸となって成長している姿は、相撲に限らず全ての組織に通ずるものがあり、私もあんな組織づくりをしてみたいものだなぁと思いました。

私なりに上記の組織の状態を分析し言語化したものが下記になります。

• 個人それぞれがなりたい姿が明確になっている
• オーナーシップを持って組織を引っ張る存在がいる
• オーナーシップを発揮するのは特定の一人ではなく、状況によって様々な人が発揮する
• オーナーシップのみだけでなく、その周りのフォロワーシップが発揮されている
• それらを発揮するための心理的安全がある

これは、ドラマだから特別だとは全く思いません。
「なりたい姿」、「オーナーシップ」、「フォロワーシップ」、「心理的安全」をキーワードとして、
私の考える理想的な組織づくりである「個人のなりたい姿をチームで支える」を
どのように工夫し奮闘しているかをお話ししたいと考えています。

特に「オーナーシップ」、「フォロワーシップ」、「心理的安全」は人により様々解釈が異なると思いますので、
それぞれをより細分化し、どのような取り組みをしているかをお話ししていきたいです。

Learning Outcome

• 理想の組織像を検討中の方の一助となれば幸いです。
  • 理想の組織像は様々な形があり、こちらは飽くまでも1例としてお聞きいただければと思います。
• 「オーナーシップ」、「フォロワーシップ」、「心理的安全」を細分化しますので、それらにご興味のある方に聞いていただきたいです。
• マネジメント領域の中でも、ピープルマネジメントの色が強いのでそちらにご興味のある方に聞いていただきたいです。

概要

フリー株式会社で EM をしている sentokun と申します。このセッションでは、フリーが行っているメンバー成長・キャリアパスに対するアプローチの実例を元に、「現場」と「組織」それぞれから生まれた活動が合わさり、新たな価値を産み出した話をします。

現場では、「エンジニア波瀾万丈伝」というキャリア共有イベントを通じ、メンバーがなりたい姿を考える支援を行っていました (https://developers.freee.co.jp/entry/eng-haranbanjo) 。
一方、組織課題の専任チームは、多様化しはじめた開発者への期待値を明らかにするため「役割とそのラダーの明文化」に取り組んでいました(https://speakerdeck.com/freee/vpoe-talks-about-the-real-story-of-building-freees-development-organization?slide=26) 。
それらの活動が絡み合い、社内でのキャリアパスの具体的イメージ形成という相乗効果を産み出しました。

セッション内では、これらの活動内容と相乗効果を産んだ経緯を解説し、そこから得た学びを紹介します。

アウトライン

1. 現場から発生した活動「エンジニア波瀾万丈伝」
   • 活動内容
   • きっかけ
   • 広がり
2. 組織から発生した活動「役割とそのラダーの明文化」
   • 組織課題
   • 解決のアプローチ
   • 役割の明文化とその狙い
3. 相乗効果
   • 活動を進めて見えてきた価値
   • 更なる進化
4. 学びとまとめ
   • 効果に繋がった要因を紹介

Learning Outcome

• 現場と組織課題から発生した活動のコラボレーション例が知れる
  • 結果、以下の方が学びを得られる
  • 自チームが行っている改善の取り組みを組織に広げたい方
  • 他チームが行っている改善の取り組みとコラボレーションしたい方
  • 活動を広げるのっておもろいよね！という方
• 実例内容を通して、メンバー成長・キャリアパスに対するアプローチを知れる
  • 結果、以下の方が学びを得られる
  • メンバー成長・キャリアパスについて悩んでいる方

概要

本セッションでは、急速にスケールするチームが直面する多様な課題を解決し、持続可能な開発体制と高いモチベーションを維持するために、Less (Large-Scale Scrum) を応用した「機能別のチーム編成」と、それに合わせた「エンジニアのロール分担」について詳しく解説します。

チームや組織がスケールする過程では、オーナーシップの欠如、協力体制の崩壊、個人プロジェクト化、プラットフォーム間の断絶といった複雑に絡み合った問題が顕在化します。これらの課題を解消するため、メンバーとの対話を通じて各エンジニアの適性を見極め、「機能開発」と「技術課題の改善」に特化したチームを再編成します。また、リーダーシップを発揮できる開発者には、プロダクトリード（PL）、テックリード（TL）、および個別貢献者（IC）など、明確なロールを背負ってもらうことで、プロダクト開発と技術課題の検証に集中できる環境を整えます。

このアプローチにより、チームのスケールを契機に、パフォーマンスの最適化・加速、モチベーションの向上、そしてチームの一体感を徐々に取り戻すことができました。

本セッションでは、具体的な施策とその効果について実際の事例を交えながら紹介し、参加者が自身のチームに応用できる実践的な知見を共有します。

Learning Outcome

• 中規模チームにおける、持続可能な開発環境の構築:
  • 機能別チームとロール分担を導入し、開発効率を最大化しつつ、メンバーが疲弊せずに持続的に成果を上げていく具体的な事例を共有します。
• チーム間コラボレーションの設計見直しによる生産性の向上:
  • 具体的ないくつかのプロセス改善を通じて、チーム間のコミュニケーションコストを最適化し、機能横断などで生産性を向上させる具体策をお話しします。
• 開発者の役割と評価基準の最適化:
  • 対話を通じ、適正に合わせた役割設定と評価方法を明確にし、成長を支援するアプローチをお話します。

対象

• チームのスケーリングに伴う課題解決、メンバーのモチベーション向上に取り組むリーダー層

概要

エンジニアリングマネージャー（EM）は、チームの成長と成功を導くために、技術的な知識だけでなく、ピープルマネジメント、プロジェクトマネジメント、チームビルディングなど、多岐にわたるスキルが求められます。

しかし、これらのスキルは実務経験の積み重ねに依存しがちで、その向上には時間がかかり、即効性に欠けるという課題があります。

この課題に対して、私たちは社内でEM向けの勉強会を立ち上げ、スキル向上を図る新たな取り組みを始めました。

本セッションでは、勉強会の始め方、進め方、工夫、無理なく継続する方法を詳しく紹介します。
この勉強会の特徴は、単なる座学ではなく、自分たちの経験を共有し合うことで、マネジャーが自分自身の経験の意味を理解する手助けをおこなうスタイルを採用しています。
具体的には、目標設定の悩みやメンバー評価の難しさ、プロジェクトマネジメントでの成功例や失敗談を持ち寄り、「みんなはどう感じたか？」「今の組織ではどうしたら良いか？」と互いに意見を交換します。これにより、各自が自分の経験を客観的に捉え、新たな視点や解決策を見出すことができました。

また、勉強会で得られた知見や成果を社内の他部門へどのように還元したかについてもお話しします。

Learning Outcome

対象の聴衆：

• EMとしてスキル向上に課題を感じている方
• EM育成のための具体的な施策を探している方

得られるもの：

• 実務経験以外でEMスキルを向上させる具体的な方法
• 無理なく継続できる社内勉強会の設計・運用ノウハウ
• EM育成の取り組みを組織全体に還元する方法

概要

これまで私は様々なEMのイベントに参加してきましたが、そこで参加者の方と立ち話をしていると
「1on1のやり方に困っている」
「1on1で話す話題がない」
「1on1は1ヶ月に1度しかできていないが良くないと思っている」
など1on1に関する悩みが多くあることに気づきました。

また、私自身もかつてマネジメントラインのメンバーとの1on1の際に
「今日話したい内容はありますか？」
とよく聞いていたのですが、ほぼ毎回のように
「今日は...特にないですね...」
という回答で困っていた経験があります。

このような状態から私なりに改善を重ね現在では上記のような悩みがなくなり、毎週30分の1on1を話題に困ることなく実施できています。

その結果、私の1on1のやり方が社内でも取り上げられ、他のマネージャー陣の参考にもなるようになりました。

このセッションでは私が具体的に行なっている1on1に関して、
・1on1の目的
・1on1に向けた準備
・効果的な1on1のやり方
・1on1で扱うべき話題
など"今日から使える"をコンセプトに話していきます。

Learning Outcome

聴衆の皆さんは、この講演を通じて以下のようなことを学ぶことができます。
・トークテーマに困らない効果的な1on1のやり方
・"Growth - 組織形成と成長 -"のための1on1のやり方
・メンバーによって1on1はカスタマイズしていく必要があるということ
・傾聴だけではなく、マネージャーも自身も話す必要があるということ
・1on1で話すべき話題の具体的な例

概要

チーム内に各分野のスペシャリストを抱え、業務を進めるうえで
・スペシャリストの業務内容を把握できない
・スペシャリストが思ったような成果物を作成できない
・スペシャリストが周囲の技術レベルを引き上げられない
などの壁にぶつかることがあるかもしれません。

単純にスペシャリストとしてのスキルが不足している、
または、活躍できる土壌が組織の中で整っていないなどの可能性もありますが、
総じてエンジニアリングマネージャが貢献できる領域といえそうです。

今回、viviONが定義するスペシャリスト像とともに、
マネジメントとの役割分担や、活躍しやすい環境の構築について、
スペシャリストの成熟度に合わせたアプローチの中で
効果があった事例を紹介させてもらえればと思います。

Learning Outcome

新しくスペシャリストの職位を設定したい、採用を進めたい、
または、スペシャリストの働き方に違和感を抱えるエンジニアリングマネージャの方を対象に、
スペシャリストとの関わり方の一例を知ることで
アウトプットの最大化に役立てていただければと思います。

概要

プロジェクトで設定されている納期を果たせずに、お客様とも社内のステークホルダーとも関係性が良くない。ステークホルダー、ビジネスパートナーを含めて心理的安全性が確保できない。その結果、チームに大きな負荷がかかり、労働時間も長くなりメンバーの健康も損ね、生産性も落ちてしまう。そのようなビハインド状態の開発チームを立て直すために、エンジニアマネージャーとして何をしたら良いでしょうか？

登壇者である私は、リリースが半年延期し、ステークホルダーからの横槍も多く入り、労働時間も超過することが多くなって疲弊し切ったチームに途中からマネージャとしてジョインし、そのチームを立て直した経験があります。

本登壇では、私がエンジニアマネージャーとしてステークホルダーから権限を移譲してもらい、短期でチームと一致団結してリリースをやりきることで信頼を得て、その後チームでの生産性を改善し、最後にはエンジニアマネージャーが居なくてもまわるチームを作った事例をご紹介します。

Learning Outcome

• ビハインド状態を把握し、マネージャとしての取り組みを検討するためのヒント
• 理想的なマネジメントが難しい時に取る段階的なアプローチのヒント
• チームがステークホルダーから信頼を得るための活動
• 見守るだけではどうにもならない状態でのマネージャの振る舞いに対するヒント

概要

多くのテック企業において、プロダクト開発の生産性を底上げするべく、社内開発基盤を支えるプラットフォームチームを組成することがあります。
この社内プラットフォームは黎明期を乗り越えて、社内の開発者という顧客を獲得して盤石になった時、場合によっては方向性に迷うことがあると思います。
安定顧客が存在することによる慢心の発生、プロダクト開発チームとの距離による情報流通量の低下、守りに走りすぎて開発組織のボトルネックになるなどです。

医療系スタートアップ Ubie のデータプラットフォームは 2024 年の夏頃、まさにこの手合いの課題に直面していました。
技術的には理にかなっているものの、利用者にとって取り掛かりにくく生産性が低下してしまう。しかしデータ分析をする上で使うことが必須で避けられない。利用者がその状態に耐えて利用し続けてしまうと、それが組織を取り巻く変えられない制約として根づいてしまう。
この状況を打破すべく、 Ubie データプラットフォームチームでは社内ユーザのヒアリングや課題の収集、今までに無かったリスクテイク可能にする機構の導入など様々な施策を回すことで、利用時に必要な作業の一部リードタイムを 1/8 に短縮、ヘビーユーザからのポジティブな反応を獲得するに至りました。

本セッションではこの Ubie データプラットフォームチームで行った生産性改善プロジェクトのマネジメントと、より一般化した社内プラットフォームのマネジメントの考え方について紹介します。

Learning Outcome

• 社内プラットフォームチームが黎明期を超えた先で陥る可能性がある課題と解決策の一例の把握
• 社内プラットフォームチームのマネジメントの困難と緩和策の一例の理解

概要

ミドルステージのスタートアップが、どのようにグローバルチームを構築して組織拡大にトライしていったかと、段階的に発生する課題とアプローチを紹介します。
進出国の選定の考え方、日本との採用方法違い、リモートワーク体制、コミュニケーション設計、文化の醸成などを具体的な事例を用いて紹介します。

Learning Outcome

• グローバルチーム構築の具体的なステップを理解
• 各段階で必要なリソースと準備を把握

概要

事業会社(自社プロダクト企業)で1年間「プロジェクトG」の開発リードとして走った実体験から抽出した、エンジニアリングマネジメントの哲学を共有します。

急造チーム・タイトスケジュール・仕様ふわふわ というある種お約束の属性で始まった「プロジェクトG」。
EM(Engineering Manager)という名前を与えられていたわけでもなければ、自分でそれを意識していたわけでもありませんでしたが、
振り返ってみれば、私が取り組んだことは一種の「エンジニアリングマネジメント」だった と言えるだろうと感じています。
良かったこと・悪かったこと・今後挑戦したいことなどを交えながら、ご参加の皆様と共にEMのミッションやバリューに目を向けていく２０分です。

Learning Outcome

• 対象の聴衆
  →EMを目指す者
  →EMとなったが、どうバリューを発揮すべきか、迷いを抱える者

• その人たちが得られるもの
  既知でないケースで得られた観点からの哲学を「触媒」とし、
  EMが持つミッションや解き放つべきバリューへの気づきを手にすることで
  事業(プロダクト)や組織の成長へのコミットを「増幅」させる道筋を得る

概要

事業会社のストリームアラインドチームでEMに従事されているみなさま、こんなこと言われたことありませんか？
『そんなに時間がかかるの？』（あれもこれも全部最優先て言うから、、）
『これバグですよね？いつ直ります？』（それあなたが言った仕様です、、）

事業会社のIT部門では、事業価値向上を至上命題としてチームとテクノロジを磨きます。
EMはプロダクト・チーム・テクノロジのすべての成長に責任を負います。まさに完璧超人。
でも現実ではすべてを完璧にこなせる人など(ほとんど)いません。心ない言葉を投げつけられてしまう場面もあるでしょう。

でも大丈夫。そんなもんです。みんな通ってきた道ですよ。
ポイントを押さえて力を入れるところさえ掴めたら、後は勝手に回っていきます。たぶん。

ポイントは2つだけ。
１つは、事業と技術を繋ぐインターフェースとして機能すること。
事業理解を深め、それを継続的に発展可能な形でアプリケーションに具現化する過程をリードすること。
もう１つは、その過程で得た知見を組織の資産として紡ぎ、持続的な成長を実現する機能です。

このトークでは、事業理解を深めるための実践的アプローチや、チーム成長のステージに応じた具体的な施策を、実例を交えてご紹介します。
明日からの実践に活かせる示唆と共に、長期的な視座に立ったエンジニアリングマネジメントの可能性を提示します。

Learning Outcome

下記のような課題感を持つEMに対して :

• 事業部門との効果的なコミュニケーション方法

  • 要件の本質的な理解をどう深めるか
  • 優先順位の調整をどう行うか

• チームの技術力と業務理解の向上

  • 個々のメンバーの成長をどう支援するか
  • チームとしての総合力をどう高めるか

• 持続可能な開発体制の構築

  • 短期的な成果と長期的な成長のバランス
  • チームの自律性の確立

本セッションでは、以下の3つの視点から具体的な示唆を提供します :

1. 事業理解を深める実践的アプローチと、価値増幅のための具体的な施策（ソフトスキルとDDD）
2. 成長ステージに応じた適切なアプローチと、具体的な成功事例と失敗からの学び（モデリングの実践例）
3. 実践のためのフレームワーク（すぐに実践可能なアクションアイテム）

概要

シリーズAのスタートアップである現職に2024/03に入社し、2024/06ごろからPdMとEMを実質的に兼任してきました。
組織への投資を十分にできない組織状況の中で、組織マネジメントを進めるために

Learning Outcome

対象の聴衆

• EMとPdMを兼任している方
• 組織への投資を十分にできないが、プロダクト組織を形成していきたい方
• 事業の成長速度が早い中での組織開発と事業開発のバランスに困っている方

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

• PdMとEMの役割を兼任する時の頭の切り替え方
• 十分にEMとしての工数を割けない中での割り切り方

概要

直近、組織的な課題を解決するためにイネイブリングチームを組成し、そのチームが自走するまでを手掛けました。
本トークではその際に行った施策やアプローチについてお話します。

私自身はテックリードの役割を担うプログラマですが、技術的な革新を行うために組織に手を入れる施策をする必要がありました。
そのひとつがイネイブリングチームの組成です。

しかしながら、テックリード業務がある関係上、マネジメントに集中することはできません。
そこで試みたのは「いかにチームを自走させ、手離れするか」です。

行った施策はさまざまです。
たとえばグループからチームに進化するために必要なコミュニケーション基盤づくり。
技術的知見の相互共有の仕組みづくり。
相互サポートの雰囲気つくり。
それらを具体的にどのような予測から実施し、いかに浸透させたかについてお話いたします。

なお、私自身はマネジメントするのもされるのも嫌いな典型的なさきがけタイプのプログラマです。
組織の先頭をひた走るようなプログラマが何を好み、何を嫌うのか、それを自ら知っているからこそできるノウハウについてお話しいたします。

Learning Outcome

• チームが目指す姿とその背景にある理論
• 学び合いを促すコミュニケーションルール
• 主体性を発揮させるための状況作り
• メンバーのアラートを察知するためテクニック

概要

EngineeringManager（以下、EM）とTechRecruiterがどのように協力し、理想的な協力体制を作ることで、事業の最大の差別化要因となるプロダクト組織を構築できるかについて、現役TechRecruiterの視点でお話します。

これまでの成功体験に基づく紹介ではなく、「理想とする協力体制」をテーマに据え、これまで多くのEMと協業した経験から、モメンタムを産むEMとTech Recruiterの協業体制、採用にまつわる課題をどのように捉え、どのような体制が望ましいかを提案します。

採用とエンジニアリングの双方がシナジーを生むことで、さらなるプロダクト組織のスケールを加速する協力体制を考察します。

このセッションのターゲット

・プロダクト組織の拡大（採用）に責務を持っているEM
・これからプロダクト職種の採用にアクセルを踏みたいと考えているEM
・プロダクト職種の採用担当をこれから採用したいと考えているEM
・プロダクト職種の採用担当がいるものの、協業が上手くいっていないEM

なぜこのセッションを話そうと思ったか？

20名規模のスタートアップ、老舗IT企業、2000名規模のメガベンチャーでのリクルーティングの経験を経て、EMのプロダクト組織構築における役割の重要、またTechRecruiter視点から採用起点に組織を瞬く間にスケールさせ、事業の貢献力を高めていくEMの方を見てきました。

マインド面や、実際の協業体制を踏まえ、環境変化の早い業界においてますます重要となり、昨今明確に事業の差別化要因となっているプロダクト職種の採用において、整理しお話ししたいと考えています。

Learning Outcome

1. 採用とマネジメントの協力関係がもたらすプロダクト組織の成長理解
   採用担当とエンジニアリングマネージャーがどう協力し、組織の強化につなげられるかを理解できる。

2. 採用活動と組織文化の関連性とその重要性の認識
   採用が組織の成長とカルチャー形成にどのように貢献するかを学び、具体的なアプローチに活かせる。

3. 採用担当目線の理想的な体制づくりの方向性
   理想の採用体制やエンジニア組織との連携モデルを把握し、自組織での体制強化に向けたヒントを得られる。

（※ 二重投稿になってしまったので削除したいです。）

概要

新卒エンジニアとしてキャリアをスタートした際、多くの人が「マネジメント」に対して抱く恐怖心や抵抗感を抱いたことがあると思います。（全く恐怖がなかったという人を僕は尊敬してます）
これは「マネジメント」というテーマは意味が広く・重要度もあり・ 難易度も高いがゆえに発生するプレッシャーから来てるのだと考えてます。

僕自身もその一人であり、「マネジメント」を避けてきました。
しかし、転職をきっかけに EMをしている人、テックリード + EMっぽいことをしてる人などの動きを見て、
改めて「マネジメント」ってなんだろ？そんなに恐怖を抱くべきテーマなのだろうか？と冷静に見つめ直すことができました。
そして、恐怖心や抵抗の感情の背景にあった原因を深掘りし理解することでEMを目指す決心ができました。

このセッションでは、新卒エンジニアが「マネジメント」に対して抱く悩みや恐怖心、そこに至るまでのフローを具体的に共有し、それを克服するためのステップや考え方を提案します。

Learning Outcome

対象の聴衆： これからEMを目指す人、EM の教育やキャリア支援に携わる人
話したいテーマは以下です。

• 「マネジメント」というテーマへの恐怖心がどのように形成されるかについての具体的なエピソード。
  • 歴代リーダー・EMからフォローをもらっていたのに、フォローを活用できなかった愚かなエンジニアのエピソード。
• 今だからこそわかる、感情とどう向き合うべきだったかの考察。
• 今のEMの人が、これからのエンジニアやEMを志す人に言って欲しいこと。

概要

人事評価制度は組織や個人の成長に大きな影響を与えるものであり、ピープルマネジメントを担当するマネージャーにとっては真っ向から向き合うべき重要な制度になります。一方で、現場に合わない制度や複雑な制度、メンバーへのフィードバックや周辺組織とのキャリブレーションなど悩みも絶えません。
私はEMとして、これまでに以下のような会社規模や組織の歴史が異なる2社で人事評価制度の設計(改定)・導入・運用に関わる経験を積む機会がありました。

• 1社目： プライム上場企業のグループ事業会社内に創設されて間もない内製開発組織
  • 1社目ではエンジニア向けの目標管理と評価制度を新規に策定しました
• 2社目： 10年来のWebサービスを運営するベンチャー企業のプロダクト開発組織
  • 2社目では複雑化していたプロダクト開発組織の人事評価制度を全社の人事評価制度と接続できるようにスリム化させました

2社に共通することはチームでプロダクト開発を行い、組織として成果の最大化と成長を目指していることです。一方で制度変更の方向性は対照的で1社目では制度への足し算を行い、2社目では引き算を行っています。

本セッションでは上記経験を振り返り、以下のような内容について話すことで、人事評価制度の在り方や運用に悩む方々に未来へのきっかけを提供できればと考えています。

• 各組織で人事評価制度の Before/After
• 期待した効果　〜誰のための／何のための制度なのか〜
• 導入までの工夫　〜関係各位との付き合い方〜
• 運用時の工夫と反省　〜結局は運用〜
• 今後取り組みたいこと

Learning Outcome

• 人事評価制度の在り方と運用を考えるヒント
• 影響範囲の大きな制度を変える際の導入ノウハウ