トーク

概要

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

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

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

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

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

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

Learning Outcome

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

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

概要　

従業員数約1000人/売上高100億円程度だった頃に入社した企業が、グループ連結で従業員数約1.4万人/売上高1100億円を超えるまでに成長。
領域もソフトウェアテストと品質保証だけだったところから、開発、ERP、セキュリティへと広げてきました。

このセッションでは、その激動の渦中に7年間いた自分が、VPoEになるまでの歴史とこれから挑戦したいことについて語ります。
段階的に多くのエンジニアを配下に抱えるにつれて、エンジニアのキャリアを支援する方法を考え、エンジニアが輝ける制度の設計をするようになりました。

現在、私の企業ではこれらが実現しています。
・スキル/成果重視の絶対評価制度
・年間昇給率平均11％ 　
・年間2000人の採用と退職率6%
・職級の細分化と定義の整備
・キャリアマップ
・フェロー制度
・検定/研修/勉強会/イベント
これらの詳細とその効果を共有します。

そして次に挑戦しようと思っていることは、活躍するエンジニアに提供する新しいポジションの設定です。「スタッフエンジニア」などを参考に、考えられるポジションをアメリカの事例などを元に洗い出し、まだ構想段階の内容を紹介することで、参加者とのディスカッションへ繋げられれば幸いです。

Learning Outcome

• スキルと成果に応じたエンジニアの評価制度とその効果
• エンジニアのロールやポジションの設計
• メンバーのキャリアを明るくするために制度設計から考えるVPoEの目線
• 事業会社にはない、SIerのジレンマ

参考

『エンジニアのキャリアパス。管理者以外の選択肢をつくる意義』
https://recruit.shiftinc.jp/career/library/id1295/
『トップエンジニアが輝ける制度の導入と障壁（エンジニア組織の未来 vol.1） 』
https://recruit.shiftinc.jp/career/library/id1343/
https://www.youtube.com/watch?v=m6oPRUwON_Q

概要

株式会社ExaMDは2024年に設立された医療ドメインに特化したエクサウィザーズのグループ会社です。私は新会社の技術開発部の部長として組織立ち上げを担いました。
新会社の組織立ち上げにおいてはやらなければならないことがたくさんあります。部長として部のメンバーが同じ方向を向き、事業を進めていくために必要と考える対応を行ってきました。
本セッションでは新会社の組織立ち上げにあたって、どのようなことを行なったか、その結果どうなったか、今後どうしていこうと考えているか、をお話しします。

どのようなことを行なったか
・組織のMission, Vision, Value策定
・メンバーとのコミュニケーション機会創出
・現状の整理と主要技術の決定
・ソフトウェアエンジニアの役割の明確化
・etc

今後どうしていこうと考えているか
・会社・部署を超えた交流機会の形成
・組織としての品質水準の策定
・etc

Learning Outcome

対象聴講者
・新組織立ち上げ時の動き方に興味がある方
・スタートアップの立ち上げに携わられている方
・いきなり部長を任されて困っている方

得られるもの
・組織立ち上げ期における動き方の事例

概要

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

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

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

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

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

Learning Outcome

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

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

概要

私が所属するオープンロジは昨年、創業10周年を迎えた物流テック企業です。ビジネスは順調に成長し、現在は社員数が約200名の規模に拡大しました。私が入社してからの3年間で、エンジニア組織は2倍の規模に成長しましたが、多様なバックグラウンドを持つエンジニアが集まり、特に多くが最近入社したメンバーで構成されています。

エンジニア組織には多様な信念を持つメンバーが集まっており、オープンロジのエンジニア組織のカルチャーとは何なのかが共通認識化できていないことで、組織内の意思決定のスピードが遅くなってしまったり、採用時の候補者への印象が不明瞭になってしまっています。

私は3年前にオープンロジのVPoEに就任し、エンジニア組織のカルチャーを醸成するプロジェクトを立ち上げました。その中で得た理論と実践の知見を、お話ししたいと思います。

企業全体のカルチャーやバリューについては、多くの書籍や記事が存在しますが、エンジニア組織に特化したバリューやカルチャーに関する情報はあまり見かけません。
この登壇が、今後CTOやVPoE、EMがエンジニア組織のカルチャーに向き合う際の道しるべとなることを願っています。

Learning Outcome

本セッションではCTO・VPoE・EMがエンジニア組織のカルチャーの課題について取り組むための理論と実践的アプローチを提供します。具体的には下記が得られます。

・エンジニア組織のカルチャーについて体系的な理解
・カルチャー醸成に向けた具体的な取り組み
・エンジニア組織のバリュー策定の進め方と注意点
・全社のバリュー、事業・プロダクトとエンジニア組織のカルチャーとの関係性
・創業10年を経た企業での実体験から得た教訓

概要

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

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

Learning Outcome

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

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

概要

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

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

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

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

Learning Outcome

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

概要

エンジニアリングマネージャー(EM)の役割は多岐にわたり、プレイヤーとしてのエンジニアからEMへ役割を変えることは大きな挑戦を伴います。キャリアが連続的なものではないが故に、そしてEMとしての理想的な姿を体現することの難しさから、EMへの役割転換に対して積極的なエンジニアの数は決して多くはありません。一方で、優秀なEMを採用することの困難さはemconf参加者のみなさんならば説明は不要かと思います。

私が所属するestieでは、EMという役割に興味をもったエンジニアに対して、EMへの成長の機会を提供する制度として「Potential EM」という役割を定義し、約2年前に運用を開始しました。この制度は、マネジメント経験のあるメンターEMと壁打ちをすることを通して、チームメンバーの能力を最大限に引き出す能力を獲得することを促します。自身にEMとしての適性があるかどうか、やってみる前に判断するのではなく、EMとしてチャレンジする過程を経て、続けるかどうかを意思決定してもらいたいという意図が込められています。結果として、約2年間で5名がPotential EMを経て正式にEMとなり、今も活躍をしています。

このように組織や事業の成長に大きな貢献があったPotential EM制度ですが、実は最近になって私たちはこの制度の廃止を決定しました。

本セッションでは、2年ほどPotential EMという制度を試行錯誤しながら運用する中で感じたメリット・デメリットや、最終的に廃止という意思決定をした背景、どのような組織であれば適用をオススメできるかなどを共有します。

Learning Outcome

組織拡大にあたってEMの仲間を増やすという選択肢を検討しているみなさんへ、実践的なアプローチのひとつをお伝えします。また、試行錯誤のプロセスを共有することを通して、いくつかのエッセンスを持ち帰っていただきたいと思います。

概要

急成長スタートアップにおいて、エンジニアリングマネージャー（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

概要

大小さまざまな企業で1万人のマネージャーとコーチングで伴走してきた実例から、あるあるなマネジメント課題の乗り越え方について話します
・マネージャーが任せられず忙しすぎる
・1on1が難しい。業務の話になってしまう
・急なマネージャー登用で自信が持てない
etc...

それらの実例と、私がCTOとしてそれらの課題にどう向き合っているのかをお伝えします

「管理職支援」をサービス提供しているmentoだからこそできる、リアルの話をしたいと思っています。

Learning Outcome

・マネージャーが忙しい問題への対処方法について学べる
・1on1のやり方や相互理解の方法が学べる
・急な登用で自信がない状態からどのようにチームをエンパワーしていくことができるかを学べる

概要

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

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

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

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

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