トーク

概要

SREチームのチームリーダーとしてプレイングマネージャーを務めて約2年、チームの成長と組織への影響力に自己効力感を持ち始めた頃に、複数チームのグループマネージャーとして4チーム20名程度のラインを見ることになりました。
チームリーダーが1stラインのEMなら、複数チームを見る2ndラインのManager of Managerは一般的にシニアEMという役割になるかと思います。

当初は「チーム成果に責任は持つので現場でエンジニアリングをやっていたい」「自分が手を動かす時間が減るのは嫌だ」と思って避けていました。
自身の専門性でチームをリードするプレイングマネージャーと異なり、全く専門性の異なるメンバーの目標設定やキャリアについて対話を行い、事業と接続してチーム成果を最大化する仕事は、広い意味でエンジニアリングであり自分が考えていたよりも面白く好きになれる仕事でした。

このトークでは、かつての私のように自身の専門性を手放してフルタイムEMに挑戦することに及び腰な方に、N=1の体験談を参考にしてもらえればと思います。

Learning Outcome

• プレイングマネージャーとシニアEMの仕事の違い（時間の使い方、視点/視野/視座、メンバーとの接し方、自身に求められる能力）の具体例を知る
• 自身が積み上げてきたプレイヤーとしての専門性に自信がある人ほどフルタイムEMへの転向が不安な問題に対して、N=1の体験談を知り勇気を持てる（かもしれない）

概要

「最近、仕事で何をしているの？」と聞かれたとき、技術広報や採用、開発者体験向上などやるべきものがありつつも、その他の細かいタスクもたくさんあり忙しさに追われて「いろいろと…」としか答えられない瞬間がありませんか？特に、経験豊富なエンジニアリングマネージャー（EM）ほど、広範なタスクと役割を持ち、何でも屋的な立場で多くの依頼に応えているため、全体像が見えにくくなりがちです。

本セッションでは、限られたリソースの中で無数にあるタスクをどう管理し、どのように優先順位をつけるかに焦点を当てます。EMとして、組織やチームからの期待に応えつつも、単なる雑用担当に陥らないようにするためのアプローチを共有します。重要なのは、頼られる存在でありながらも「目的を解決するためのフルスタック雑用？！」であることです。

各タスクに取り組む前に、その目的を明確に理解することが必要です。依頼された仕事をただこなすのではなく、「何のためにこのタスクがあるのか」を常に意識することで、自分がやるべきか、やるべきでないかの判断がしやすくなります。そうしたフィルタを持つことで、EM自身が真に注力すべきタスクが浮かび上がり、適切にリソースを集中させることが可能になります。

また、EMとして判断力や嗅覚を磨くことも大切です。過去の経験や実績を通じて、状況に応じた適切な対応や意思決定ができるようになります。私はこれまで、メガベンチャーからスタートアップ、そしてNPO法人や一般社団法人まで、役割も現場のエンジニアからマネージャーやCTOまで幅広く経験してきました。それぞれの組織やフェーズでの学びが、今のマネジメントに活きていると感じています。

本セッションでは、タスクの目的を無意識に捉えつつ、何でも屋として信頼されるEMを目指す方法について具体的にお話しします。そして、必要とあれば自ら組織や仕組みを改善し、大義を持ってタスクに取り組む姿勢を醸成することの重要性をお伝えします。

Learning Outcome

• なぜEMは「忙しい」状態に陥りやすいのか
• EMが本来やるべきタスクを見極めるための基準
• タスクの「目的」を明確にすることの重要性
• EMとしての判断力や嗅覚を鍛える方法

概要

2024年7月から Mobile Team の Engineering Manager を担当することになりました。
それまでは Backend 開発経験を持つ、開発組織のトップが EM を兼任しておりました。
一方で、チームは Mobile 特有の課題を多く抱えていました。
その課題を解決し、チームを再構築するために取り組んだ3つのことを紹介いたします。

具体的には、以下の内容を想定しています。

• 課題の認識と解消
  • 課題の収集・分析・優先度を整理し、一覧で可視化することで、やるべきことが明確になった
  • 上記を元に PM とコミュニケーションを行い、課題解消に向けて前に進める状態になった
• メンバーサポート
  • 日々の 1on1 から課題の吸い上げを行い、潜在的に潜んでいる課題の認知と解消
  • メンバーや組織の成長に向き合えるようになり、長い目線での組織成長を考えるようになった
• 採用
  • 採用を進める上で、自組織に必要な人材要件・人物像の詳細化
  • 構造化面接のフォーマットを作成し、採用基準を明確化

上記の取り組みを通じて、少しずつではありますが、課題を解消しながら組織を前に進めています。
同じ境遇の方がいましたら、少しでも力になれたら幸いです。

Learning Outcome

対象の聴衆

• EMを目指している人
• これからEMになる人/EMになったばかりの人/EMを引き継いだ人
• EMになり、何をしたらよいか悩んでいる人

得られるもの

• EM となり、何をどのように取り組んでいったか等の進めたの事例
• EM として、チームの課題をどのように解消していくかの取り組み事例
• 採用で構造化面接を取り入れた事例

概要

エンジニアリングマネージャーにとって採用は重要な仕事の一つですが、その難易度は年々高まっています。
頑張って時間を取ってスカウトを送っても返信率は雀の涙。エージェントに頼ってみても知名度のある会社が優先され、推薦が中々来ない……。
絶望的な採用難に直面した結果、近年では多くの企業でエンジニアからの認知を獲得するための活動の価値が見直されています。

それがTechPRや技術広報と呼ばれる活動です。

これらの活動は認知を獲得し、採用活動における企業の優位性を高めるだけではなく
活動の中でメンバーの登壇などが促進され、個々人の成長にも寄与する素晴らしい施策です。

しかし、いざ、会社としてゼロから取り組むにもEMとして忙しすぎて活動する余力がない……。
なんとかして技術広報活動をスタートさせたいが、それぞれの施策に求められるリソースが大きくて辛い……。
そんなEMの方も多いのではないでしょうか？

本セッションは大規模技術広報コミュニティの主宰でもある技術広報専任のプロが
忙しいEMでも明日から始められる技術広報時短レシピを伝授します！

お品書き：
・他社の活動に囚われずに捨てるものを決める話
・時短の友は実は友達である話
・コンテンツは味がしなくなるまで噛み続けようという話

Learning Outcome

【対象オーディエンス】
・資金調達や事業拡大などがあり、開発組織の拡大を見据えている企業のEM
・まだまだ小中規模の組織で技術広報にも取り組みたいが手が回っていないEM

【得られるもの】
・忙しくても始められる技術広報戦術
・エンジアリングマネージャーが技術広報活動の中で自分が持つべき役割

概要

私の今までの経験ですが、優秀な人を採用するのはめちゃくちゃ難しい。
難しすぎて採用における永遠の命題＝「優秀かつ会社の社風に合う人を採用する」こと。になっている。
それをクリアして優秀な人を採用しても、組織に入った瞬間にハイパフォーマンスで仕事ができるわけではない。これも難しい。
みなさんもそんなことないですか？コストを掛けて採用したのに「あれ、思ったよりこの人仕事出来ないかな？」と思ったこと。
例えば、合コンで気が合いそうだなと思った人なのに、初デートで「思ってたのと違う」となるような。
そんな経験ないでしょうか。

思い当たるフシがあるのであれば、話は早い。問題は判明しているので、あとは解決に向かうだけです。
今回は、採用した中途入社のパフォーマンスをいち早く引き上げて、組織に浸透してもらうお話です。大丈夫です。出来ます。

現場マネージャーの皆様はそんな初デート＝オンボーディングにもう少し目を向けてみてください。
「早く戦力になりたい新入社員」と「早く立ち上がって欲しい組織リーダー」両方の観点からオンボーディングに必要なことのお話をしていきます。

弘法も筆は選ぶし、エンジニアは開発環境を選ぶ。もちろん中途入社本人の努力・マインド次第ですが、出迎える側はそれを最大限高める手伝いをしないといけません。
そしてもっとも効果的なのは、中途入社社員の最初の仕事として「オンボーディングの設計」をしてもらうことです。
鉄は熱いうちに叩け、オンボーディングを考えるのはオンボーディングのうちに。

新しく会社に参加してくれた有望な社員を、有能な社員に。
有望→有能へ持って行くのに大事な「オンボーディングの設計の仕方」をお話します。

Learning Outcome

• 今のオンボーディング資料がどれだけいい内容だとしても、それをジャッジするのは既存社員ではなく新入社員だということの意識
• 最初にどう立ち上げるかで、その人のパフォーマンスはびっくりするほど変わってくるし、帰属意識すらも変化するということ
• 鉄は熱いうちに打つほうが良いけど、実際現場は冷えてから叩いていることが多い。それをやめて熱いうちに打つべき使命感

タイトルは結構当たり前なことかもしれないですが、いま一度それがなぜ大事なのかの認識をみなさんに持っていただきたいです！

概要

「若手の育成」
若手エンジニアを対象に実施している、「事業成長×自己成長」を軸としたキャリア支援の取り組みについてお話しします。
意志ある目標設定を促すため、マネージャーとの対話を通して深掘りができるキャリア支援シートを作成しました。
・メンバー自身の持つ特性や強みのタネを見つける自己分析
・会社が求めるエンジニア像のインプット
・事業の向かいたい先
まで、このシートを用いて、1年後、2年後の未来を想像して目標に落とし込むという取り組みです。
当日の発表では具体的なシートについて一部紹介をしながら、現場の若手エンジニアのキャリアに対するモチベーションの変化や、解像度がどう変わっていったのかの
数値的振り返りについても可能な限りシェアしたいと思います。

「トップラインを伸ばす育成」
中堅以上のプレイヤーを対象に実施している、「事業成長リードを狙う領域特化の育成プログラム」の取り組みについてお話しします。
組織が強めていきたい領域のプロフェッショナルを育成していくための取り組みとして、領域特化育成制度を立ち上げました。
・抜擢メンバーに領域特化の目標、ミッションをセットする
・該当領域の成長支援のメンターと並走してミッションを遂行
・最終的には事業成長をリードする事例を作り出すことを目指した視点で本人がロードマップを描く
という流れで、中堅以上のプレイヤーへのミッションセットと成果追求の考え方をお話しします。
ミッションセット〜育成まで実際に取り組む中での試行錯誤のリアルを伝えられたらと思います。

Learning Outcome

「若手の育成」
若手プレイヤーの立ち上げに関わるEMの方に特に聞いていただきたい内容になります。
・スキル成長についてマネージャーと本人で共通認識を持つこと
・そこから強みや伸び代ポイントを明確にしてキャリアに繋げる会話
・本人の自己成長のモチベーションを引き出しつつ、事業成果と掛け合わせる環境づくり
この辺りを参考にしていただけるかと思います。

「トップラインを伸ばす育成」
若手の育成のその後について、中堅以上への求め方という角度で育成の参考にしていただきたいです。
・事業✖️技術の視点でメンバーの強みを伸ばすとは
・取り組む中でうまくいったこと、いかなかったこと
この辺りを参考にしていただけるかと思います。

概要

あなたのチームでは、開発プロセスの中で作業の重複やお見合いが発生することはありませんか？

プロジェクトの進捗を妨げる要因の一つに、PM（プロダクトマネージャー/プロジェクトマネージャー）、EM（エンジニアリングマネージャー）、TL（テックリード）、Eng （エンジニア）の役割が曖昧で、無駄なコミュニケーションやボールが落ちたままの状態になることが挙げられます。

弊社 PIVOT では、「誰が何をいつ行うべきか」が不明確であるが故に、開発プロセスが停滞することがありました。本セッションでは、RACIマトリックスを活用して役割と責任を明確化し、開発プロセスと成果物を整理したことでスループットが向上した具体的な取り組みを紹介します。

また、現在の課題はサービス品質の維持と向上。現在取り組んでいる QA プロセスの改善や今後の展望についてもお話しします。

Learning Outcome

• 役割の曖昧さと重複やボールが落ちたままの状態を解消する具体的な方法
  • PM、EM、TL（テックリード）、Eng の役割を具体的に定義し、重複や曖昧さを解消した実践的な方法
  • 開発プロセスにおける「お見合い」や「人任せ」の状況を改善し、スループットが向上した具体的な手法
• チームメンバー間の信頼と自主性を高める方法
  • メンバーが自分の役割に自信を持ち、「ここは任せとけ！」という主体的な意識を醸成するアプローチとチーム作り
• 継続的なプロセス改善と新たな課題への取り組み方
  • チーム全体でプロセス改善に取り組み、変化に柔軟に対応できる文化の育て方
  • 新たに発生する課題やQAプロセスの改善に対して、どのようにアプローチし解決していくかの方法を紹介

概要

急成長スタートアップにおいて、エンジニアリングマネージャー（EM）からTech Recruiterへとキャリアをシフトすることで、組織にどのような価値をもたらすのか？
このトークでは、EMとしての経験を活かし、エンジニア候補者の視点に立った採用プロセスの設計や、チームにフィットする人材の見極め方について実践的な事例とともに紹介します。また、エンジニアリングチームが事業へ集中する時間を確保しながら、採用を成功させ続けるためのメリハリの付け方とトレードオフについても触れます。採用に多くの時間を割かざるを得ないEMの方々にとって、採用業務と他の責務のバランスを取るためのヒントになると幸いです。

Learning Outcome

• EMからTech Recruiterに転向することで得られる独自の視点と強みを理解する
• エンジニアリングチームが事業へ集中する時間を確保しつつ、採用を成功させ続けるためのメリハリの付け方とトレードオフを学ぶ
• 採用に多くのリソースが割かれる状況で、採用業務と他の責務をチーム全体でバランスよく管理するための実践的なヒントを得る

概要

エンジニアとEMは異なる道と思われがちですが、EMの経験は意外にもエンジニアとしての視野を大きく広げてくれます。
本セッションでは、スタートアップのエンジニアがEMになって半年で経験した、インフラコスト削減、採用面接の効率化、メンバーの退職対応といった具体的な取り組みを通じて得た学びを共有します。
マネージャーの意思決定の背景を理解し、チームメイトを技術面と文化面から評価し、組織が重視する指標を把握する。さらに、評価者としての1on1を通じて効果的なフィードバックの方法を学ぶ。これらの経験は、実はエンジニアとして働く上でも大きな価値を持つことが分かってきました。
EMの視点を得ることで、組織やチームをより深く理解し、エンジニアとしてもより効果的に活動できるようになる。そんな可能性が広がる瞬間を、具体的な事例とともにお伝えします。

Learning Outcome

• EMの視点を知ることで、エンジニアとしての活躍の幅を広げるヒントを得る
• EMとして直面する課題と、それを乗り越えるためのアプローチを学ぶ
• チームの一員として、より効果的に活動するための視点を理解する

対象：

• キャリアの次のステップを模索しているエンジニア
• チームや組織の課題に関心のある方
• これから誰かにEMを任せてみよう、という方

概要

エンジニアリング組織のトップとして外部から新任のCTOを迎える際、Engineering ManagerやVPoEとしてその移行をサポートすることは非常に重要です。このトークでは、CTOのオンボーディングプロセスをどのように設計し、組織のスムーズな移行を支援するかについて、外部採用の視点から具体的な事例とともに紹介します。特に、周囲が「お手並み拝見」となりがちな雰囲気の中で、建設的なチームワークを促進する工夫や、新任CTOへの過度なサポートを避けつつ、自主性を尊重しながらも適切な支援を提供するバランスの取り方について触れます。また、オンボーディングにより得られる組織全体の成長や信頼関係の構築についても考察します。

Learning Outcome

• 外部から採用されたCTOを迎え入れるための効果的なオンボーディングプロセスの設計方法を学ぶ
• 新しいCTOとのコミュニケーションと信頼関係の築き方を理解する
• 周囲の「お手並み拝見」ムードを建設的なものへと導く方法や、サポートと自主性の尊重のバランスについて知る

概要

タイトルの「お手並み拝見をしない」はよく言われるフレーズだと思います。

新しいメンバーをチームが受け入れるにあたって、まずは力試しだとばかりに不十分なサポートで難しい仕事をやらせてみるやり方・周囲のそういう姿勢は百害あって一利なしである、壁際で腕組みして「どれどれ」とするのはいけないのだと。

新しくチームに参画する人が、「チームから受け入れられていない、このチームでは必要な支援が受けられない、仕事の成功ではなくストレス耐性を要求されている、減点方式で評価されそうだ」と思ってしまうのは、ふつう、その人のパフォーマンスによい影響を与えません。オンボーディングにおけるそれはアンチパターンだという認識は世に広まっていると思います。

しかし実際のところ、同様の有害さを含むお手並み拝見モードのコミュニケーションというのは、新メンバー受け入れ場面でも、またそうでない場面でも容易に発生してしまいます。相手が仕事を達成することよりも、できるかどうか確かめることを優先してしまう。単にそれが形式的に悪いことだと線を引いてしまうことも難しいものですし、振り返って自身の振る舞いにそのようなかたちを見出してしまって「自分、矛盾しているのでは?　自分の中では一貫していても周囲から読み取れないのでは?」と悩むこともあります。

ここでは、経験ベースとはなりますが、「お手並み拝見」について少し掘り下げ、普段から生じているその姿勢の影響について向き合う事例についてお話しします。

Learning Outcome

以下のような方を対象としています。具体は異なっても悩みの形は相似であると思いますので、一緒に悩みましょう。

• たとえばオンボーディング時の「お手並み拝見」モードについて考えている方
• 有益そうなアイディアをチームに取り入れるときに、影響範囲や射程について悩むことが多い方

概要

EMとしての大きな仕事の一つは、メンバーやチームを成長させていくことだと思います。しかし、アジャイルやDevOpsなど社内で新しい取り組みを進める際には、成長の目標となる先達の個人やチームが存在しない、という課題に直面します。

私が新人時代にそれを補ったのは、社外のコミュニティとの繋がりでした。コミュニティに参加・登壇することで、様々な刺激や目標とすべき同志や先輩に出会い、自分なりの成長につなげてきました。そして、そのコミュニティとのつながりのきっかけは、身近な先輩がつなげてくれたものでした。

このリレーをつなぐべく、チームを任されてからは、メンバーに積極的にコミュニティやカンファレンスへの参加を呼びかけてきました。また、自身もカンファレンスへの参加や登壇を積極的にこなし、そこで繋がった人たちとチームとの間で対話会を設けるなど、チームと外部をつなぐ活動も積極的に行ってきました。

そういった地道な活動を1年以上続けた結果、現在では年間で10回以上の登壇機会をチーム内で持つようになり、それがきっかけとなって社内外でのつながりも生まれてきました。

このように、外部登壇を通じてチームの成長を駆動してきた取り組みについてお話しします。

Learning Outcome

1. 外部発信を通じて開発組織の成長を促進させた事例
2. メンバーの外部活動を促すための具体的なアプローチや戦略
3. 社内に先達が少ない場合でも、外部リソースを活用して新しい取り組みを推進する方法
4. 継続的な外部活動が組織文化やチームのモチベーションに与える長期的な効果の事例

概要

エンジニアやリーダーからエンジニアリングマネージャー（以下EM）への役割転換で直面する課題の一つにプログラミングスキルの低下が挙げられます。
プレイングマネージャーとしてコードを書きながらマネジメントを担うという選択肢もありましたが、私は大企業とベンチャー企業の双方でEMを務めた際、ある程度の期間が経った後、コードを書く業務から退くことを周囲に宣言しました。
初めは、プログラミングから離れることで技術的なスキルが衰えるのではないかという恐れや不安を抱いていました。
しかし、その決断を通して、マネージャーとしての役割に専念し、エンジニアリング組織の成長を促進することに注力できるようになったと感じています。

本セッションでは、当時を振り返りながら不安に対してどう向き合ったか、向き合った結果どうなったかを実体験をもとにお話します。
具体的には以下を紹介します。
・不安の正体と深掘り: プログラミングスキルが低下することの不安を様々な観点から分析し、自身の感情や思考整理につなげます
・EMへの登用・周りから求められていることの理解: EMとして求められる役割を理解し、周囲から期待されることを把握し、自身の新たな価値を見出すことを期待します
・不安を和らげるテクニック・理論の紹介: 不安を和らげる実践的な理論やテクニックについて具体的な事例を交えて紹介します。これにより、自分自身の状況に応じた対処法を持つことができます

このセッションを聞いて、コードを書かなくてもエンジニアリングマネージャーとして新たな役割に適応し、不安ではなく自信を増幅して業務に取り組めるような処方箋になれば幸いです。

Learning Outcome

対象聴衆
・EMに興味があるエンジニアの方
・自身の役割や価値を見直したいEMの方
・業務負荷からコードを書く時間が減っているEMの方
得られること
・EMとしての新たな価値の見直しやふりかえりの機会提供
・プログラミングスキル低下やキャリアへの漠然とした不安の解消

概要

初めて挑戦することには失敗はつきもの。でも挑戦し、失敗を乗り越える過程で人は成長できます。それはEMも同じ。

EMをやる前は、「EMって何をする人なの？」とか「いつも忙しそうだけど何に時間が取られてるの？」といった、自身に経験がないことによる理解不足から「何をフォローすればいいのかわからない」とか「なんとかしてくれるんだろう」と良くも悪くもEMを近づきにくい人として扱ってしまいがちかなと思います。

このセッションでは、そんなことを考えていたチームメンバーの一人だった私が、EMに挑戦して経験した失敗とそこから得た知見、そして今後どういったEMを目指していこうと考えているかをお伝えします。

例えば以下のような取り組みについてお伝えします。

• 他人の意思決定にそのまま従わない
• 重要度・緊急度でタスク分類する
• TODOリストは頭に入れない

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

対象の聴衆：

• いまはチームメンバーで、これからEMに挑戦してみたいと考えている人
• EMがどんなことをするのかわからないので知りたい人

得られるもの：

• EMに求められることと経験することで得られる知見
• EMに挑戦してもいいかなという心持ち

概要

マネジメントの課題はスキルを持って超えられる「技術的課題」だけではなく、各人の自己認識や他者認識、関係性など人の課題=「適応課題」が多くの比重を占めています
メンバー同士やマネージャー自身の適応課題を、深い本音を伝え合う対話によって乗り越える方法について大企業でのコーチング・システムコーチングなどの事例を用いて説明します

Learning Outcome

・適応課題と技術的課題の違いがわかる
・深い対話によってどんな変化がマネージャーやメンバーに起きうるのかがわかる
・システムコーチングの概要についてわかる
・スタートアップでのシステムコーチングの実体験に基づいた学びや大企業でのマネージャーの変貌によるチームの変化の事例について理解できる

※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

概要

どんなマネージャーも、生産的なチームづくりを目指しています
しかし生産性を測る指標の難しさはソフトウエア開発において永遠のテーマです
一方でチームが楽しく没頭して働いている=ウェルビーイングな状態を作ることができれば生産的であることに疑問がある人はいないのではないでしょうか？

このトークでは
・なぜ知らず知らずのうちにお互いがストレスを抱えてしまうのか
・意外と知らないことが多い、他者の「楽しい」「没頭している」瞬間を知ることがなぜ大事か
・生産性を測る指標としての「ウェルビーイングかどうか」がなぜ大事か
・それを相互理解することによってどんなコミュニケーションが生まれるか
を実体験を交えて話します

Learning Outcome

・相互理解によってどうチームの生産性が上がるかがわかります
・相互理解の手法についてスクラムイベントの中に取り組む簡単な方法やシステムコーチングのような深い理解の手法を含め理解することができます

※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

概要

IT業界では長らく開発プロセスに着目したマネージメント手法が中心で、人や目的に着目したマネジメントとしてはほとんど浸透していませんでした
アジャイルの流れでEMが注目されてきていることがとても良い流れではないかと思います
EMを目指したいという方も増えており、ぜひ応援していきたいと思っています

しかし現代的なEMのカバーする範囲は広く、また、環境によるケース・バイ・ケースなことも多く一概にこれができれば良いという方法論に落とし込むことが困難です

そこで少し抽象的なEMとしての考え方に着目したお話ができればと思います
　・目的、目標、手段に切り分けて考えるクセをつける
　・事実と仮説を切り分けて考えるクセをつける
　・チームの仕組みづくりは、自分で考えて行動した結果から学べるようにすること

つまり、ここを押さえておけばきっとEMとして応用が効くと思われるポイントのお話となります
ふわっとしたEMを目指すのではなく、こういう考え方で行動している人を目指しましょう

Learning Outcome

EMとしてどのように成長をしていけばよいか、イメージができるようになる

概要

みなさん、こんにちは！

私からはリリースから4年経ち、利用者も増え、複雑度も高いプロダクトに対し、
プロダクト戦略策定からチーム一丸となって取り組むことを決めたチームの奮闘記を紹介したいと思います。

まずカミナシではプロダクト毎にサービスチームという
PdM/PD/Eng/EMが所属する仮想的な職能横断チームを作り、サービス開発を行っています。
職能横断チームを組成することでプロダクトのオーナーシップを持ち自律的に価値提供を行える仕組みです。

プロダクトごとにチームがあることから、プロダクト戦略策定から関わりやすい組織構成ですが、プロダクトが大きくなると顧客数も増え、さらには利用ユーザの業種も増えることから、扱う情報がどんどん多くなり意思決定は複雑化します。カミナシレポートもリリースから4年が経ち顧客数も増え、業種も多種にわたり扱う情報量が非常に多くなっていました。

またサービスチームではiOSアプリをPWAへ移行するという、比較的長期に開発が必要なリリースを進めており、開発に集中する必要もありました。こういった状況もあり、PWA移行後のプロダクト戦略についてはPdMチームに任せっきりになっていました。

本来とは違うこの状況を変えようと、9月末PWAアプリのリリースを機に、
戦略策定から全てにエンジニア含めて関わると決めて、サービスチームを再組成しています。

いざ始めてみると、扱う情報量や意思決定の数が一気に増えるだけでなく、カミナシレポート以外のプロダクトがリリースされたことから、プロダクト間の連携も並行で検討したいタイミングにあり、ステークホルダーも急激に増え、一筋縄ではいかない状況の中奮闘しています。

この荒波を乗り越えるため、多くの失敗と学びから改善を繰り返し進めている様を、カミナシのバリューである「全開オープン」でお話したいと思います。

Learning Outcome

▼想定聴者
プロダクトと開発チームの関わり方に興味がある方

▼得られるもの
プロダクト戦略とチームの関わり方
プロダクト開発とのバランスの取り方
失敗と学び試行錯誤の数々

概要

この一年間、50名規模のエンジニア組織のマネジメントに挑戦し、組織の成長を支えるための戦略を模索してきました。その中で、部門間のサイロ化、文化や価値観の共有不足、期待値のすれ違いといった問題が浮き彫りになり、組織全体の一体感や業務効率に悪影響を及ぼしていることが明らかになりました。

これらの課題を解決するために取り組んだのが、「文章を書くこと」を通じた組織の明文化です。暗黙知に頼りがちな文化や価値観を言語化し、期待値を明確にすることで、メンバー間の認識を揃え、曖昧さを排除していきました。

本セッションでは、これらの取り組みを通じて得た知見を基に、具体的な手法とその効果について、以下のトピックを中心に共有します。

• 体制の再編とコミュニケーションパスの再設計
• 情報共有と浸透のための文章化
• 共に実践するマネジメントプロセスの強化
• 技術戦略と文化醸成への投資

Learning Outcome

• 50名規模のエンジニア組織を運営する上での主要課題とその解決アプローチ
• 組織文化や戦略の浸透を促すための「文章化」の実践方法
• マネージャーが押さえるべきマネジメントプロセスの改善ポイント

このトークは、組織のマネジメントについて新たなインスピレーションを得たい、エンジニアリングマネージャー、リーダー、及びマネジメントに興味のあるエンジニアに適しています。

概要

マネージャーの仕事は意思決定の連続であり、もちろんエンジニアリングマネージャー（EM）も例外ではありません。そして、意思決定のアプローチとしてよく用いられるのが「仮説検証」です。

この方法では、現場の問題に対して解決策の仮説を立て、それを検証して評価することでより良い意思決定を目指します。特に不確実性の高い状況では有効とされ、リーン・スタートアップの根幹を成すメソッドでもあります。

一方で、この手法には落とし穴があります。定性的なアプローチに依存しがちのため、個人やチームのバイアスの影響を受けやすいのです。

本セッションでは仮説検証アプローチの一般的なプロセスに沿って、各ステップで生じがちな認知バイアスとその影響を紹介し、対策について考察していきます。例えば、以下のようなポイントです。

• 仮説の選択：ヒューリスティックによって、特定の選択肢を過大評価してしまう
• 検証方法の検討：確証バイアスによって、仮説を裏付けるデータのみを集めてしまう
• 検証結果の評価と意思決定：メンバーへの伝え方によって特定の判断に誘導してしまう

これらをできるだけ回避して、よりもっともらしいアプローチを行うためにマネージャーが取るべき行動を検討します。また、仮説検証において何を担保すべきなのかを再確認していきます。

Learning Outcome

対象

仮説検証と意思決定が求められるすべての人

得られるもの

仮説検証による意思決定に関する以下の知識とノウハウ

• 主要な認知バイアスの種類と、それを補正する方法
• チームで意思決定をする際、より公平に意見を集めるための質問方法
• 仮説検証プロセスにおいて重要視すべきポイント