トーク

概要

株式会社プレックスのエンジニア組織は2021年8月に私が1人目のフルタイムのエンジニアとして入社した時からスタートしました。
そこから3年が経った現在では、フルタイムのエンジニアが16名、業務委託・アルバイトのエンジニアが6名と合計20名を超える規模へと成長しました。
本セッションではプレックスのエンジニア組織の成長の変遷を、事業やプロダクトといった周辺状況も踏まえつつ、採用と組織デザインの観点からご紹介します。

Learning Outcome

対象聴者

• シード期〜シリーズAのスタートアップで働かれている方
• エンジニア組織を成長させていきたいと思っているCTOやEM
• 採用に課題感を持つ採用担当者

得られるもの

• 実際に事業、プロダクト、組織が成長する中で表出化した課題とその対応の事例
• 採用や組織デザインについての具体的な事例
• リソースがない状況下からエンジニア組織を拡大していった戦略
• 組織デザインにおける考え方

概要

私が所属するREADYFOR株式会社では4年以上前からフルリモートを導入しており、
開発組織内だけでも沖縄から東北まで様々な地域からエンジニア・PdMがリモートで働いています。
普通に働いていると交流や会話の時間自体が限られてしまう環境の中、

• 生産性を上げながら円滑に（なるべく楽しく）開発を進めたい！
• PdMなど非エンジニアとエンジニアとの間でも活発にコミュニケーションが生まれるようにしたい！
• でもお金はあまりかけたくない！

そのために私たちが行なってきた取り組みをなるべく具体的に紹介します。

目次

• 背景
• ええ感じに盛り上げるとは
• 取り組み集
  • 一斉1on1
  • ゆる飲み
  • 自動勉強会
  • もくもく会
  • MTGの再設計
  • 半年に一回のオフサイトイベント
  • 属人性LT
• 今後考えている取り組み

Learning Outcome

対象の方々

• リモートのエンジニアが属する組織のマネージャー
• 組織内の空気作りに関心のあるマネージャー

得られるもの

• リモートエンジニアを巻き込んだ施策の考え方
• 会議体や組織施策の設計観点とそれを盛り込んだ具体例

概要

私達エンジニアリングマネージャーとして仕事をしていくなかで、日々様々なことに悩み迷うことが多いと思います。
エンジニアリングマネージャーとしての仕事を分解し、何を考え、何に悩むのか、そしてそれらに対してどのようなに気持ちの持ちようでいたら良いのか、私自身が6年ほどエンジニアリングマネージャーとしての経験から学んだことをお伝えします。
(トークテーマ: Philosophy - EMとしての生き方 -)

Learning Outcome

• 現在エンジニアリングマネージャーをしていて経験が浅く、気持ちの面で悩みがある方
• これからエンジニアリングマネージャーを目指したい方

上記の方をメインの対象として、主にメンタル面でのフォローできることを目指します。
また、エンジニアリングマネージャーの育成に関しても、ヒントとなるものが得られることも目指します。

アジェンダ

• エンジニアリングマネージャーの仕事のテーマ別分解（エンジニアリング、ピープルマネジメント、組織マネジメント、プロダクトマネジメント、プロジェクトマネジメント）
• エンジニアリングに関するポイント
  • 幅広く関心を持つこと
  • 部分的なロールモデル（マネージャーとスタッフエンジニア）
  • リーダーシップとマネジメントの違い、委譲(サーバントリーダーシップ)
• ピープルマネジメントに関するポイント
  • 人となりを知る。知ってもらう。
  • メンバーとの関係性
• 組織マネジメントに関するポイント
  • 組織設計、コミュニケーション設計(チームトポロジー)
  • 非合理的物事との戦い(Disagree and Commit)
• プロダクトマネジメントに関するポイント
• プロジェクトマネジメントに関するポイント
  • コミュニケーションのハブとなる

概要

エンジニアリングマネージャーとして成果を上げている方の中には、異動や転職で新しいチームにEMとして参加する機会がある方も多いのではないでしょうか。しかし、一つの開発チームでSWEからEMへとキャリアを積んだあと、別チームにEMとして異動するというのは大きなチャレンジです

昨年、私は別グループ会社のプロダクトチームにEMとして異動しました。コードベースも知らなければメンバーもほとんど接点がないという、これまでとは異なる文化やプロダクトに飛び込む大きなチャレンジでした。新しい環境で、どのようにアクションをとりリーダーシップを発揮しながらチームと信頼関係を築くか、試行錯誤の連続でした。

本セッションでは、EMが新しいチームに異動した際の戦略と具体的なアクションプランについて私の経験を踏まえてお話しします。

このセッションを通して、新しい環境でいち早く順応し、チームをリードしていくためのヒントを掴んでいただければ幸いです。

Learning Outcome

対象者:

• これから異動や転職を控えているEM
• 新しい環境で課題を感じているEM
• 将来の異動に備えて準備したい方

得られること:

• 異動後にスムーズに成果を出すためのアクションプラン
• 新しいチームとの信頼関係を迅速に築く方法
• 効果的なリーダーシップを発揮するタイミングとアプローチ

概要

EMとはどういう存在で、どのような役割を持ち、どのような影響を会社に及ぼすことができるのでしょうか？

EMが組織や事業に与えるインパクトはみなさん気になるテーマの一つだと思います。一方で、既にEMがいる組織ではEMを前提としてチーム組成やマネジメントが行われているため、純粋にEMの存在だけを切り取って会社への影響を測ることは簡単ではないでしょう。このトークでは、ゼロからEMを立ち上げたからこそ見えた、EMが生み出す組織と事業へのインパクトについてお話をします。

私が所属するスマートバンクでは創業から5年が経ち、組織も大きくなって創業者の目が行き届かない所が出るなどの50人の壁を感じるようになりました。例えば開発チーム内で抱えている課題の解像度が創業者たちとズレたり、会社内で起こる様々な課題の責任の所在が不明確になことで課題解決のスピード感を失なっていました。この背景には、権限委譲を進めたい経営陣に対して、その過渡期においてうまく責任と権限が整理しきれていない組織マネジメントの課題がありました。

そのため去年からマトリクス組織とEM制度を取り入れることで問題解決を図ってきました。特にEM制度においては、これまでCTOが抱えていたピープルマネジメントを権限委譲したり、2~3人のチームの育成に責任を持つことで自律的に成長し課題解決ができる開発組織を目指しました。その過程で実践したEMの役割定義やEMを育成していくための仕組みづくり、EMがチームで取り組んだ実践例を紹介しながら、どのように組織が変わっていったのかお話しする予定です。

創業以来の最もシンプルでフラットな組織構造を改革して、事業の加速に取り組んだEMのチャレンジ結果に興味はありませんか？

Learning Outcome

対象聴者

• EMの役割に悩んでる人やうまく価値を発揮できずに悩んでいる人に一つの解を提示する
• 組織デザインや組織のマネジメント手法について学びを得たい人に実践例を提示する

得られる学び

• スタートアップが直面する30人の壁、50人の壁の具体例
• 組織におけるマネジメントの重要性とEMが果たせる役割
• 会社に初めて生まれたEMという役割を定義し定着させるための仕組み
• EMが生み出す組織と事業へのインパクト

概要

ICとして運用エンジニア、SREをやっていた前職時代、EMから「マネジメントキャリアパス」を読む薦められたことがありましたが、興味をもって読むことができませんでした。

そんな私は今、さくらインターネットでチームをつくり、EMとして仲間と学び、多くのエンジニアと共にガバメントクラウド認定という大規模開発に立ち向かっています。
2025年度末までにデジタル庁から出されている300件超の技術要件を満たすため開発を進めており、2024年10月時点で大きな遅延は発生はしていません。
本トークではどのようなきっかけでICからEMとなり、EMとして開発チームととも変化し、開発を行って来ているのか紹介します。

・さくらインターネットでもう一度SREチームをつくるきっかけ
・SREチームの取り組みの中で感じた組織課題
・大規模開発への挑戦と、私と開発チームの変化と成長、あるいは変わらないこと

Learning Outcome

【対象者】
・大規模プロジェクトに挑戦し、組織作りに悩むエンジニア、エンジニアリングマネージャ

【得られること】
・難易度の高いプロジェクトへの挑戦や、開発チーム作り悩む皆様のヒントに少しでもなればと思います

概要

マシンに向き合うエンジニアリングとヒトに向き合うエンジニアリングマネジメントについて、その違いをエンジニアとしてのキャリアをベースに話します。
具体的には、マシンとヒトのコミュニケーションはマシン側の絶対的な正となる期待値が用意されているが、ヒトとヒトのコミュニケーションは相対的な期待値から落とし所を見つけ出す必要があり、そのような状況における対応方法を紹介します。
対応方法の内容は、自分の期待値、相手の期待値、事実(結果)の 3 要素から互いの期待値のズレを伝え合い、そのズレに対する解釈を相互に理解し、理想的な結果に近づけていくフィードバックコミュニケーションです。

Learning Outcome

メインターゲット: エンジニアをバックグラウンドに持つエンジニアリングマネジャー
サブターゲット: エンジニアリングマネジャーを目指すエンジニア
ターゲットが得られるもの: 漠然としたマネジメントの難しさや擬かしさの言語化／明日から実践できるフィードバックノウハウ

概要

本セッションのタイトルに惹かれたということはピープルマネジメントが好きなEMでしょう。
そんな方に聞いていただきたいセッションになります。

私は前職でスクラムマスターからエンジニアリングマネージャー、VPoEとしてキャリアを積んできました。
そして、2024年10月より株式会社ログラスでアジャイルコーチとして新たなキャリアを歩み始めました。

VPoEからアジャイルコーチへの転身、地続きでないように見えるキャリアのように見えます。
しかし、私にはこの歩みは自然な歩みでした。
EMの重要な仕事として1on1があります。私はここでコーチングに興味を持ちました。
個人の支援だけではチームの力を最大化することは難しいと感じた私はチームの力を最大化するためにシステムコーチング®︎を学びました。
VPoEとなった私はプロダクトを価値を顧客に届けるためには、開発組織の力だけではなく、ビジネスサイドも含めた企業全体がアジャイルな組織であることが重要であると理解しました。
私にとって、アジャイルコーチは私にとってはごく自然な流れだったのです。

なぜそんなキャリアを歩むことになったのか、それは「好き」や「興味」といった内発的動機づけにありました。

本セッションでは以下のお話をします。
・ 私のキャリアの変遷
・ キャリアの変遷にあった学びやスキルなど、私を構成する要素
・ 好きこそものの上手なれ、EMだからこそ「EMたるもの」を追求するのではなく、「あなた」を追求していく

Learning Outcome

・ 次なるキャリアに悩むEMの方がご自身の歩みを省みて、明日からの活力を得る

概要

2024年8月28日に EM Fest で「プロダクト志向なエンジニア組織作り」を発表した後、以下のご質問を多数いただきました。
「シェアド・リーダーシップを試してみたいけど、実際どのようにおこなっているんですか？」

本セッションでは、このご質問に対する回答を具体的にお伝えします。

シェアド・リーダーシップ (Shared Leadership) とは、「全員が強みを活かし、リーダーシップを発揮するスタイル」です。
ソフトウェア開発現場での事例が見当たらなかったため、書籍や論文を読み漁り試行錯誤を繰り返しました。

7ヶ月半にわたるトライ＆エラーの結果、私たちのチームでは「部門横断案件を牽引するリーダー」が複数人誕生しました。
そして、リーダー経験者が未経験者を支援することで「新リーダー育成のサイクル」が回り始めています。

私自身も「EM」から「EM of EMs」へと役割が移り、視野・視座が変化しました。
「成熟度の異なる複数のチームに導入した場合、再現性はあるのか。」
「経験者がチームを越境して支援した場合、新たな化学反応を起こせるのか。」

当日は最新の挑戦結果をお届けします。

Outline

• 背景
  • タクシーアプリ『GO』の開発現場
  • 一人のリーダーが牽引することの限界
• シェアド・リーダーシップとは
  • リーダーシップ論の変遷
  • 全員が強みを発揮し、組織のリーダーシップを最大化
  • 互いの強みで補完しあう関係へ
• 実践前の疑問と仮説
• 部門横断案件のリーダーの育成
  • 自己発揮のためのセキュアベース
  • 意思決定基準のファシリテーション
  • 一人ひとりの多面的な強み
  • 仮リーダー体験の日常化
  • 多様なステークホルダーとの関係作り
  • 部門横断案件のリーダーの誕生
• 複数チームへの適用
  • リーダー経験者による言語化
  • 経験者による未経験者への支援
  • チーム間のスイッチング
• EMの役割
  • 3つのリーダーシップの使い分け
  • トップダウンとボトムアップの架け橋
  • 2階層上の視野・視座の獲得

Learning Outcome

• 全員の強みを最大化するプラクティスの獲得
• 部門横断案件を牽引するリーダーの育成フローの把握

概要

現在、私が所属する「Ubie株式会社」は、ホラクラシー組織を採用しています。
ホラクラシー組織には肩書きがなく、全員が役割（ロール）に基づいて活動しており、一般的にマネージャーと呼ばれる人がいません。
しかし、組織の規模が一定以上になると、組織をうまく運営していく上で、マネジメントの仕組み自体は必要となってきます。

本セッションでは、ホラクラシー組織における基本的な仕事の流れを説明します。
そして、ホラクラシー組織において、どのようなマネジメントの仕組みを実現しているのか、一般的な組織とのメリット・デメリットを示しながら解説します。
また、評価についても報酬に紐づかない形となっているため、その内容もお伝えします。

Learning Outcome

• ホラクラシー組織とはどういうものか
• ホラクラシー組織におけるマネジメントの工夫
• 一般的な組織と比較した場合のマネジメントのメリット・デメリット
• 報酬に紐づかない評価の仕組み

概要

現在私は「テックリード」という肩書でプロダクト開発に関わっています。ここでいう「テックリード」とは、テクノロジーに関するリーダーとして、技術的な意思決定や方向性の舵取り、チームメンバーの技術力向上支援など、多岐にわたる役割を担うポジションです。
言い換えると、プロジェクトマネジメントとテクノロジーマネジメントを司っているロールであり、両者のバランスを取りながら日々のアジャイル開発を進めることを求められています。

近年、アジャイル開発の現場では、変化への対応力、自律性、そして高い生産性を持つ「クロスファンクショナルチーム」の構築が重要視されているかと思われます。

そこで本セッションでは、アジャイル開発におけるクロスファンクショナルチームの構築と、それに必要なチームケイパビリティの獲得戦略について、ケーススタディを交えながら解説します。

Learning Outcome

• チームケイパビリティ向上のためのアイディア
• 従来の役割分担を超えたチーム作りを実現するための方法

概要

マネジメントにおいて、具体的な目標とは別に、やや抽象的に定義された「期待値」を使っているチームや組織は一定数あるかと思います。このトークでは、「期待値」とはどのようなものであり、どう使うとうまくいくのか、またうまく行かないのかなどを、登壇者の経験とその他公開されている情報などをベースにお話します。

良い期待値を設計するには、マネージャーとして組織の上位の戦略（事業戦略、技術戦略、組織戦略）を理解して自分のチームやメンバーへの期待値に落とし込むことが必要です。しかし、これだけでは一方的な期待値であり、期待値の設計・設定が完了したとは言えません。メンバーの現在地や特徴をよく加味して調整した上で、その内容をメンバー自身が100%腹落ちするまできちんと伝える必要があります。期待値が100%腹落ちしているメンバーは、場面場面における期待される行動を自分で解釈して自分の判断によって行動を選択し、成果を生み出すことができるようになります。これが良い期待値設定の理想状態です。
このような状態に向けて考えるべきポイントなどをお話します。

Learning Outcome

対象聴衆

• 期待値または目標を設定する役割を持つマネージャーの方
• 期待値や目標とうまく付き合えるようになりたいメンバーの方

得られること

• 効果的な期待値を設定するためのポイント
  • 良い期待値と悪い期待値の違い
  • 個人ごとに異なる期待値の効果
  • 期待値を実際に成果に変えるために必要なこと

概要

エンジニアリングマネージャーには組織貢献のために様々な観点での活動が求められます。その中でもエンジニアがマネージャーになったときに特に困難を感じる取り組みとしてピープルマネジメントが考えられます。これは、多くの人がピープルマネジメントについて初めて明確に職責を負うタイミングがマネージャーへのロールチェンジだからです。

ロールチェンジと同時にメンバーの評価や給与に関する権限が与えられます。メンバーが成果を出し、その過程で学びを得ることで能力の獲得 / 発揮 / 洗練をしていただければ一定の評価をつけることは可能でしょう。では、それを実現するためにマネージャーとして日々の業務の中でどのようにフィードバック（以下FB）をしていけばよいのでしょうか。いざ実践したいと思っても、以下のような疑問や不安を抱える方もいるのではないでしょうか？

• これまで良質なFBを貰ったことがなく、何をどのように伝えればよいのかよくわからない
• 期末のタイミングでしかFBをもらったことがなく、どのように期中に継続してFBすればよいのかわからない
• 我流でFBをしてよいのだろうか

エンジニアの皆さん、定型的な運用作業であれば経験が浅い人でも実行できるような手順書があったらいいなと思いませんか？本セッションでは、FBのプロセスを手順書として整理することで、事業を加速させるマネジメントの強力なツールの1つとしてFBを実践できるようになることを目指します。また、ご自身の現場に合わせて手順書をカスタマイズできるように各手順についてなぜそれが必要なのかのリファレンスを示し、根本的なアイデアの理解の支援に努めます。加えて、セッションの後半では提案する手順で実施したFBの成功事例、失敗事例の振り返りを共有します。

Learning Outcome

対象聴衆

• ピープルマネジメントの責務を負っているエンジニアリングマネージャー
• 育成に責任または関心のあるエンジニア
• フィードバックに関心のある全ての方

得られること

• 定型化されたフィードバックの手順
• 人の学習過程に関する研究事例

話さないこと

• 具体的に何をフィードバックすればよいのか

概要

「エンジニアマネージャー」と言われるロールになって、はや数年が経過しました。
マネジメントスタイル・手法は関係するメンバーに対して、アジャストする必要があるので十人十色といっても過言ではありません。

マネジメントの1つの要素として、「メンバーのキャリアパス構築」があると思います。
エンジニアマネージャーはそれに対して伴走していきますが、どうしても自身のキャリアパスについて、考える時間をなかなか取ることができず、悩むことも多いのではないでしょうか。私も以下のことで悩んでいました。
・複数チームを率いていることで一点突破できるなにかがない
・実務では技術から離れてしまって、キャッチアップがやりにくい
・今の延長線で数年後も成長していないのではないか

それらの悩みに対して、こういう取り組みをしてキャリアパスを描ければよいのではないか？を考えましたので、それを共有します。

■取り組みの一例
・視点を切り替えて、キャリアの広さ・深さを出す / キャリアの希少性を突き詰める
・100点のキャリアパスは青写真なので盲信せずに適宜見直す
・技術は総論を確実に捉え、各論はメンバーからも学びを得る

エンジニアマネージャーを担っている方の「次の一手」についても言及し、エンジニアマネージャーをこれから目指す方へはエールを送る話をします。

後者については以下のドラフト資料を拡充して発表します。
https://speakerdeck.com/yutakawasaki0911/duo-yang-narorujing-yan-gadao-itaenziniakiyarianonabigesiyon

Learning Outcome

■エンジニアマネージャー向け
・キャリア形成での悩みやあるある
・特に「器用貧乏」になりがちな方の悩みに対するアプローチ
・特に「広く浅く」な経験をお持ちの方のキャリパスに対する考察

■エンジニアマネージャーを目指そうとしている方向け
・キャリアパス実現の課題とそれに対するアプローチ
・エンジニアマネージャーを目指すメリットと勘所
・実例をふまえた道しるべ

概要

副業が一般化し、スタートアップを中心に多くの企業で、受け入れてきました。
個人にフォーカスすると、新しい技術や知見の獲得、次のキャリアの選択肢が増える、収入が増えるなどを通じて市場価値を高めることに成功し、転職市場でも優秀な人材が増えている良い兆しが見られます。
一方で受け入れる企業側は外部の優秀な人材の時間や知見を獲得するメリットがある反面、非同期を前提とした一体感の欠如、本体側の目まぐるしい方針転換による作業の手戻りなどデメリットも目立ってきました。

私もスタートアップCTOとして事業やプロダクトに資するため副業エンジニアとのコラボレーションする中で、うまくいったこと、つまづいたことがあります。
これらの知見をシェアすることで、企業側の受け入れ体制がより整う（増幅）->エンジニアの多様な働き方が促進される（増幅）->そのような事例（触媒）が広がる、のようなポジティブな循環を作るきっかけにしたいと思います。

構成

• セッションの背景
• 私たちの取り組み
  • 見える化とワークデザイン
• 私たちが大事にしていること
• 結果何が起きたか

Learning Outcome

▼対象聴衆

• 雇用形態（正社員・副業・業務委託）の垣根なくマネジメントされている方（エンジニアリングマネージャー）

▼得られること

• 副業や業務委託の方と上手にコラボレーションして、プロダクトや事業に接続するための方法論

▼話さないこと

• オフショア開発
• グローバルにまたいだ組織

概要

1人目のエンジニアとして現職にジョインし、5年間で全社員7名から60名強、エンジニアは20名の組織に成長しました。
また、入社以前から開発・運用されていたプロダクトのリニューアルを平行して実施し、現在は新プロダクトが旧プロダクトの全機能をプラスアルファの価値を加えた形でカバーするところまで拡充しました。

プロダクト、組織の成長とともに自分のロールがどのように変遷したかを技術・組織両面からふり返り、そのときどきでどのような課題があり、それらにどのような背景でどう対応してきたか、将来構想についてもお話したいと思います。

Learning Outcome

• プロダクト・組織戦略の事例として
• エンジニアが今後のキャリアを考える参考として

概要

私はこの2年間で、「プレイングマネージャー」「スクラムマスター」「複数チームのEM」としての役割を担う中で、成長支援について考えてきました。タックマンモデルに示されるように、機能するチームを作るには多くの時間と努力が必要であり、特に次の2つの難しさがあると考えます。

1.自分自身の成長ですら簡単ではない中で、他人やチーム全体をより良い方向へ導くことの難しさ。
2.チームは放置すればエントロピーの影響を受け、環境変化によって機能する状態から遠ざかる。

私はこの状況に対して、チームの状態をよく観察し、小さな成功を積み重ねることで、持続的な成長を目指すアプローチを意識したことをお伝えします。

Learning Outcome

• チームの成長支援の難しさを知ることで、支援の打ち手が増える
• 新しくチームにジョインしたEMの考え・行動の引き出しが増えることで、メンバーからの印象が変わる
• 「小さく」「成功を積み重ねる」ような支援方法を知ることで、チームメンバーが成功体験を得やすくなる

アウトライン

• 序章：チームjoin初日にスクラムマスターに任命された

チームの成長が難しい要因

• 他人やチーム全体をよい状態に導く難しさ
• チームの状況移ろいゆく

他人やチームへの向き合いかた

• 他人へアプローチする難しさ
  • 価値観が異なる、自分の関心ごととして捉えられるか
• チームで話すことの重要性
  • メンバーを理解する、関係性がつくれる
  • 腑に落ちて取り組みやすくなる
• 1つ1つ取り組む
  • ハードルを下げる
  • スコープを狭める
  • 短い期間でも「良くなった」を体感する

チーム状況を見立てる

「形成期」に考え行動したこと  

• 信頼獲得と関係構築
• やってみせ  
• フィードバックからチームの文化を形成

「混乱期」に考え行動したこと  

•  感謝を伝えあう  
• メンバーの衝突に向き合う  
• スコープも期日も達成困難な状況から、チームの意識を統一

「統一期」に考え行動したこと  

• 向き直り  
• プロダクト・ユーザーを知る

概要

2024年にはじめて 「エンジニアリングマネージャー」 になりました。

右も左もわからない中でチームがうまく回るようにと、
いくつかの 「ルール」 を作ったり、 「アクション」 を起こしました。

例えば

• エンジニアリングマネージャーとはなんなのか？を言語して共有する
• 部署独自の評価制度を作る
• 15%ルール (勤務時間の15％は普段と異なる業務をしても良いとする制度)の導入
• 採用のチームごと化（皆で採用活動をやっていこう）
• 定例のファシリテーションはみんなで分担する　などなど

これらの試作は一般的には良い効果を生むとされていますが 「実際やったらどうなのか？」 が気になり導入しました。 発表時には導入から 約半年 経ちますので、その結果を皆さんに共有します。

※他にもこんな施策を試してもらいたいというものがあれば、X(@riddle_tec) にご連絡いただければチームと相談して試してみます

Learning Outcome

対象聴衆：

• エンジニアリングマネージャーを志す方
• エンジニアリングマネージャーをやることになった方

得られること：

1. 新人エンジニアリングマネージャーの抱えるリアルな問題や、そのアプローチの知見が得られます
2. 様々な試作を実施した結果、「何がうまくいったか」、「どこが課題だったか？」がわかります
3. 「もし、半年前に戻れるとしたらどうするか？」もわかります

概要

テクノロジーマネジメントの重要性

どれだけエンジニアを採用しようと、どれだけ評価制度を整備しようと、事業が伸びなければ意味がありません。
エンジニアリングマネジメントの4領域の1つであるテクノロジーマネジメントは、その事業成長を技術面から支える重要な領域です。
技術戦略というものは、事業やプロダクトの戦略に基づき、それらの実現を支える形で策定する必要があります。

スニダンのグローバル展開と課題

私がCTOを務めるSODAでは、月間600万人以上が利用するスニーカー・トレカフリマアプリ「スニダン」の開発・運営を行なっています。
そんなスニダンはUS/APACを中心にグローバル展開を進めていますが、技術組織として様々な課題に直面しています。

• 日本向けのシステムと海外向けのシステムが分離されていること
• 分離されている中でも連携が必要なデータを無理に連携していること
• それぞれのシステムを開発するチームが別々であること

などなど、様々な課題によって最速でグローバル展開が出来ていないと感じています。

学びと実践のイテレーションを最速に

様々な課題があり、すべての課題をすぐに解決することは出来ないため、ときにはプロに頼りながら戦略的に技術と向き合っていく必要があります。
SODAでは、AWSの方々にも多大なサポートをいただきながらイベントストーミングを実施したり、その結果を用いてシステムをモジュラモノリスの形にリアーキテクチャしていくプロジェクトなどを進めています。
そして、それらの取り組みすべてにおいて、学びと実践のイテレーションをどれだけ早く回せるかが重要だと考えています。
本セッションでは、そのようなSODAでの取り組みをご紹介し、技術戦略と日々向き合う皆さんの参考になることが1つでもお話しできればと思っています。

Learning Outcome

• 事業戦略を実現するための技術戦略とどう向き合うべきか
• 学びと実践のイテレーションを最速にすることの重要性および具体例

概要

「なぜ私の評価は低いのだろう？何が足りないのだろう？」と思ったことはありませんか？
もしくは声を聞いたことはありませんか？

多くの企業では、評価制度の不透明さや主観的な評価によってメンバーの揺らぎや不安につながります。
「なぜ彼が評価され、私は評価されないのか？」「私の得意なスキルを活かせていない」と疑問を抱くエンジニアは少なくないでしょう。

納得感を持ってもらい、モチベーションを高いチームを作るために試行錯誤を繰り返しました。
ジョブ型組織とクラウドベンダーである私たちの会社では、これらの問題を解決する新たな評価制度を構築しました。

新たな評価制度の導入により、メンバーが自己のスキルとキャリアパスを意識し、
自己評価と上長評価の差異を確認でき、モチベーションの向上と納得感の醸成につながった事例を紹介します。

Learning Outcome

今回私たちが、皆さんにお伝えしたい内容は、
得意なことを活かしつつ責任感を持たせる新しいジョブ型（コラボ型）を使った組織開発における評価制度です。

約100個からなる可視化された評価基準を用い、自己評価と上司の評価のギャップを数値化することで、
自己投資の方向性や、メンバーが納得感を持った評価制度の仕組みづくりについてお話ししたいと思います。

我々クラウドベンダーのチャレンジをもとに、エンジニアを抱える組織の皆さんにとって、一つのきっかけになれればと思っています。