人事評価制度は組織や個人の成長に大きな影響を与えるものであり、ピープルマネジメントを担当するマネージャーにとっては真っ向から向き合うべき重要な制度になります。一方で、現場に合わない制度や複雑な制度、メンバーへのフィードバックや周辺組織とのキャリブレーションなど悩みも絶えません。
私はEMとして、これまでに以下のような会社規模や組織の歴史が異なる2社で人事評価制度の設計(改定)・導入・運用に関わる経験を積む機会がありました。
2社に共通することはチームでプロダクト開発を行い、組織として成果の最大化と成長を目指していることです。一方で制度変更の方向性は対照的で1社目では制度への足し算を行い、2社目では引き算を行っています。
本セッションでは上記経験を振り返り、以下のような内容について話すことで、人事評価制度の在り方や運用に悩む方々に未来へのきっかけを提供できればと考えています。
株式会社プレックスのエンジニア組織は2021年8月に私が1人目のフルタイムのエンジニアとして入社した時からスタートしました。
そこから3年が経った現在では、フルタイムのエンジニアが16名、業務委託・アルバイトのエンジニアが6名と合計20名を超える規模へと成長しました。
本セッションではプレックスのエンジニア組織の成長の変遷を、事業やプロダクトといった周辺状況も踏まえつつ、採用と組織デザインの観点からご紹介します。
エンジニアリングマネージャーとして成果を上げている方の中には、異動や転職で新しいチームにEMとして参加する機会がある方も多いのではないでしょうか。しかし、一つの開発チームでSWEからEMへとキャリアを積んだあと、別チームにEMとして異動するというのは大きなチャレンジです
昨年、私は別グループ会社のプロダクトチームにEMとして異動しました。コードベースも知らなければメンバーもほとんど接点がないという、これまでとは異なる文化やプロダクトに飛び込む大きなチャレンジでした。新しい環境で、どのようにアクションをとりリーダーシップを発揮しながらチームと信頼関係を築くか、試行錯誤の連続でした。
本セッションでは、EMが新しいチームに異動した際の戦略と具体的なアクションプランについて私の経験を踏まえてお話しします。
このセッションを通して、新しい環境でいち早く順応し、チームをリードしていくためのヒントを掴んでいただければ幸いです。
対象者:
得られること:
ICとして運用エンジニア、SREをやっていた前職時代、EMから「マネジメントキャリアパス」を読む薦められたことがありましたが、興味をもって読むことができませんでした。
そんな私は今、さくらインターネットでチームをつくり、EMとして仲間と学び、多くのエンジニアと共にガバメントクラウド認定という大規模開発に立ち向かっています。
2025年度末までにデジタル庁から出されている300件超の技術要件を満たすため開発を進めており、2024年10月時点で大きな遅延は発生はしていません。
本トークではどのようなきっかけでICからEMとなり、EMとして開発チームととも変化し、開発を行って来ているのか紹介します。
・さくらインターネットでもう一度SREチームをつくるきっかけ
・SREチームの取り組みの中で感じた組織課題
・大規模開発への挑戦と、私と開発チームの変化と成長、あるいは変わらないこと
【対象者】 ・大規模プロジェクトに挑戦し、組織作りに悩むエンジニア、エンジニアリングマネージャ
【得られること】
・難易度の高いプロジェクトへの挑戦や、開発チーム作り悩む皆様のヒントに少しでもなればと思います
マシンに向き合うエンジニアリングとヒトに向き合うエンジニアリングマネジメントについて、その違いをエンジニアとしてのキャリアをベースに話します。
具体的には、マシンとヒトのコミュニケーションはマシン側の絶対的な正となる期待値が用意されているが、ヒトとヒトのコミュニケーションは相対的な期待値から落とし所を見つけ出す必要があり、そのような状況における対応方法を紹介します。
対応方法の内容は、自分の期待値、相手の期待値、事実(結果)の 3 要素から互いの期待値のズレを伝え合い、そのズレに対する解釈を相互に理解し、理想的な結果に近づけていくフィードバックコミュニケーションです。
メインターゲット: エンジニアをバックグラウンドに持つエンジニアリングマネジャー
サブターゲット: エンジニアリングマネジャーを目指すエンジニア
ターゲットが得られるもの: 漠然としたマネジメントの難しさや擬かしさの言語化/明日から実践できるフィードバックノウハウ
現在私は「テックリード」という肩書でプロダクト開発に関わっています。ここでいう「テックリード」とは、テクノロジーに関するリーダーとして、技術的な意思決定や方向性の舵取り、チームメンバーの技術力向上支援など、多岐にわたる役割を担うポジションです。
言い換えると、プロジェクトマネジメントとテクノロジーマネジメントを司っているロールであり、両者のバランスを取りながら日々のアジャイル開発を進めることを求められています。
近年、アジャイル開発の現場では、変化への対応力、自律性、そして高い生産性を持つ「クロスファンクショナルチーム」の構築が重要視されているかと思われます。
そこで本セッションでは、アジャイル開発におけるクロスファンクショナルチームの構築と、それに必要なチームケイパビリティの獲得戦略について、ケーススタディを交えながら解説します。
マネジメントにおいて、具体的な目標とは別に、やや抽象的に定義された「期待値」を使っているチームや組織は一定数あるかと思います。このトークでは、「期待値」とはどのようなものであり、どう使うとうまくいくのか、またうまく行かないのかなどを、登壇者の経験とその他公開されている情報などをベースにお話します。
良い期待値を設計するには、マネージャーとして組織の上位の戦略(事業戦略、技術戦略、組織戦略)を理解して自分のチームやメンバーへの期待値に落とし込むことが必要です。しかし、これだけでは一方的な期待値であり、期待値の設計・設定が完了したとは言えません。メンバーの現在地や特徴をよく加味して調整した上で、その内容をメンバー自身が100%腹落ちするまできちんと伝える必要があります。期待値が100%腹落ちしているメンバーは、場面場面における期待される行動を自分で解釈して自分の判断によって行動を選択し、成果を生み出すことができるようになります。これが良い期待値設定の理想状態です。
このような状態に向けて考えるべきポイントなどをお話します。
対象聴衆
得られること
「エンジニアマネージャー」と言われるロールになって、はや数年が経過しました。
マネジメントスタイル・手法は関係するメンバーに対して、アジャストする必要があるので十人十色といっても過言ではありません。
マネジメントの1つの要素として、「メンバーのキャリアパス構築」があると思います。
エンジニアマネージャーはそれに対して伴走していきますが、どうしても自身のキャリアパスについて、考える時間をなかなか取ることができず、悩むことも多いのではないでしょうか。私も以下のことで悩んでいました。
・複数チームを率いていることで一点突破できるなにかがない
・実務では技術から離れてしまって、キャッチアップがやりにくい
・今の延長線で数年後も成長していないのではないか
それらの悩みに対して、こういう取り組みをしてキャリアパスを描ければよいのではないか?を考えましたので、それを共有します。
■取り組みの一例
・視点を切り替えて、キャリアの広さ・深さを出す / キャリアの希少性を突き詰める
・100点のキャリアパスは青写真なので盲信せずに適宜見直す
・技術は総論を確実に捉え、各論はメンバーからも学びを得る
エンジニアマネージャーを担っている方の「次の一手」についても言及し、エンジニアマネージャーをこれから目指す方へはエールを送る話をします。
後者については以下のドラフト資料を拡充して発表します。
https://speakerdeck.com/yutakawasaki0911/duo-yang-narorujing-yan-gadao-itaenziniakiyarianonabigesiyon
■エンジニアマネージャー向け
・キャリア形成での悩みやあるある
・特に「器用貧乏」になりがちな方の悩みに対するアプローチ
・特に「広く浅く」な経験をお持ちの方のキャリパスに対する考察
■エンジニアマネージャーを目指そうとしている方向け
・キャリアパス実現の課題とそれに対するアプローチ
・エンジニアマネージャーを目指すメリットと勘所
・実例をふまえた道しるべ
副業が一般化し、スタートアップを中心に多くの企業で、受け入れてきました。
個人にフォーカスすると、新しい技術や知見の獲得、次のキャリアの選択肢が増える、収入が増えるなどを通じて市場価値を高めることに成功し、転職市場でも優秀な人材が増えている良い兆しが見られます。
一方で受け入れる企業側は外部の優秀な人材の時間や知見を獲得するメリットがある反面、非同期を前提とした一体感の欠如、本体側の目まぐるしい方針転換による作業の手戻りなどデメリットも目立ってきました。
私もスタートアップCTOとして事業やプロダクトに資するため副業エンジニアとのコラボレーションする中で、うまくいったこと、つまづいたことがあります。
これらの知見をシェアすることで、企業側の受け入れ体制がより整う(増幅)->エンジニアの多様な働き方が促進される(増幅)->そのような事例(触媒)が広がる、のようなポジティブな循環を作るきっかけにしたいと思います。
▼対象聴衆
▼得られること
▼話さないこと
1人目のエンジニアとして現職にジョインし、5年間で全社員7名から60名強、エンジニアは20名の組織に成長しました。
また、入社以前から開発・運用されていたプロダクトのリニューアルを平行して実施し、現在は新プロダクトが旧プロダクトの全機能をプラスアルファの価値を加えた形でカバーするところまで拡充しました。
プロダクト、組織の成長とともに自分のロールがどのように変遷したかを技術・組織両面からふり返り、そのときどきでどのような課題があり、それらにどのような背景でどう対応してきたか、将来構想についてもお話したいと思います。
私はこの2年間で、「プレイングマネージャー」「スクラムマスター」「複数チームのEM」としての役割を担う中で、成長支援について考えてきました。タックマンモデルに示されるように、機能するチームを作るには多くの時間と努力が必要であり、特に次の2つの難しさがあると考えます。
1.自分自身の成長ですら簡単ではない中で、他人やチーム全体をより良い方向へ導くことの難しさ。
2.チームは放置すればエントロピーの影響を受け、環境変化によって機能する状態から遠ざかる。
私はこの状況に対して、チームの状態をよく観察し、小さな成功を積み重ねることで、持続的な成長を目指すアプローチを意識したことをお伝えします。
2024年にはじめて 「エンジニアリングマネージャー」 になりました。
右も左もわからない中でチームがうまく回るようにと、
いくつかの 「ルール」 を作ったり、 「アクション」 を起こしました。
例えば
これらの試作は一般的には良い効果を生むとされていますが 「実際やったらどうなのか?」 が気になり導入しました。 発表時には導入から 約半年 経ちますので、その結果を皆さんに共有します。
※他にもこんな施策を試してもらいたいというものがあれば、X(@riddle_tec) にご連絡いただければチームと相談して試してみます
対象聴衆:
得られること:
どれだけエンジニアを採用しようと、どれだけ評価制度を整備しようと、事業が伸びなければ意味がありません。
エンジニアリングマネジメントの4領域の1つであるテクノロジーマネジメントは、その事業成長を技術面から支える重要な領域です。
技術戦略というものは、事業やプロダクトの戦略に基づき、それらの実現を支える形で策定する必要があります。
私がCTOを務めるSODAでは、月間600万人以上が利用するスニーカー・トレカフリマアプリ「スニダン」の開発・運営を行なっています。
そんなスニダンはUS/APACを中心にグローバル展開を進めていますが、技術組織として様々な課題に直面しています。
などなど、様々な課題によって最速でグローバル展開が出来ていないと感じています。
様々な課題があり、すべての課題をすぐに解決することは出来ないため、ときにはプロに頼りながら戦略的に技術と向き合っていく必要があります。
SODAでは、AWSの方々にも多大なサポートをいただきながらイベントストーミングを実施したり、その結果を用いてシステムをモジュラモノリスの形にリアーキテクチャしていくプロジェクトなどを進めています。
そして、それらの取り組みすべてにおいて、学びと実践のイテレーションをどれだけ早く回せるかが重要だと考えています。
本セッションでは、そのようなSODAでの取り組みをご紹介し、技術戦略と日々向き合う皆さんの参考になることが1つでもお話しできればと思っています。
合同会社DMM.comのデータ基盤開発部の新任マネージャーの高橋と申します。
本セッションでは、我々が実際に実施したデータ組織の再編の事例を通じて、組織変革と改善の具体的な過程とその成果をご紹介します。
2024年2月に入社後、約130日間に渡って組織を観察し、導き出した解決策をもとに、2チーム体制への変革を行いました。
1.現状把握の重要性:
組織の現状や問題点を正確に把握するための具体的な方法を学べます。
2.効果的な変革計画の立案:
変革に向けて新たなチームのビジョンやゴール策定、役割・体制、ロードマップづくりなど、自組織でも変革計画の具体を学ぶことができます。
3.チーム間のコミュニケーション改善:
組織再編を通じて得られたコミュニケーション改善の施策を紹介します。
4.プロジェクト進行のスピードアップ:
プロジェクトの進行をいかにスピードアップさせるか、優先順位の設定やリソース管理の実践例について学ぶことができます。
ニフティでエンジニアリングマネージャーをしている芦川と申します。
本セッションでは、ニフティ株式会社でエンジニア文化の活性化を目的に取り組んだ「インナーソース」の導入事例や会社としてコミュニティ参加をした経験を、中間管理職という目線から、導入へのきっかけ、社内での展開の仕方、工数管理や評価の仕方、その結果得られる組織文化の変化について具体例を交えてお話したいと思います。
そもそもインナーソースに限ったことではないですが、社内の全エンジニアの文化に何か影響を与えたいような活動を加速させたいとき、中間管理職のもつ現場へのコミット権限、全社に視野を広げることのできる勘所、現場で使われている技術への理解など、ミドル層がもつ特権が功を奏す、ということを強く伝えたいという想いがります。
インナーソースは、オープンソースの手法を社内の開発に取り入れるアプローチであり、エンジニア同士のコラボレーションを促進します。エンジニア自身のモチベーション向上や教育・成長に寄与しつつ、組織から見た場合は車輪の再発明の抑制、サイロの破壊など開発リソースの適正化にも寄与します。
Engineering Management Triangleに当てはめると、下記にインパクトがあるとも言えます。
People Development 教育、OJTなどに活用 / Quality Assurance 要求(PR)を柔軟にうけつけられる / Resource Management 車輪の再発明防止、リードタイム削減 / Team Development チームを超えた組織活性化 / DevRel オープンなエンジニア文化のアピール
対象聴衆:
得られるもの:
※下記のスライドURLは1年ほどの前の関連するスライドになり、今回の発表用のものではありません。
CTO室に相談室を新設し、そこで全社の色々なプロダクトチームが価値を届け続け自走できるように右腕として色々なチームをサポートしています。
その中で見えてきたことは技術力の課題だけではなく組織の課題だったりと幅広いことがわかりました。
右腕のようなロールがどのようにエンジニア、チームの成長を支えることができるのか、また、右腕が能力を発揮するためには何が必要と感じているかをお話します。