Upgrade to Pro — share decks privately, control downloads, hide ads and more …

成果の最大化と向き合うEM思考

shkomine
December 15, 2023

 成果の最大化と向き合うEM思考

2023/12/15開催のEMゆるミートアップで話した内容です。

linkや当日お話した部分、誤解を生みそうな部分に関していくつか補足を書いておきます。

- p5~p11 補足: EMは会社や事業、チームの状況によって、求められることが違うので、弊社のプロダクトや自分の立場についてお話しています。それを踏まえて資料を御覧ください。

- p13 link: HIGH OUTPUT MANAGEMENT

- p17 link: LayerX羅針盤

- p19 link: 相互理解の重要性と、促進するためのワークショップのご紹介 #LayerXテックアドカレ

-p23 補足: 委譲度は、図解真ん中の「同意する」がちょうど合議で決めるラインで、それより左はMgrが意思決定している状態で、右がメンバーに委譲して意思決定している状態です。徐々に右に進み、委譲度が大きくなるように意識しています。メンバー委譲できるものが増えれば増えるほど、チーム全体でいろんなことができて成果が最大化されるので、委譲度を増やすことはとても大事だと考えています。
-p23 link: 権限委譲で自己組織化を促す!デリゲーションポーカー×実践的ワークショップのススメ

- p26 補足: 1.5年はスタートアップでPMF後のプロダクトを担当している自分の立場で短期と長期のバランスを考えた時の目線感です。ご所属の組織の状況によってそのバランスは適宜調整してください。

- p28 補足: OODAループはPDCAサイクルと比べて、Observeから始めるということにより主眼が置かれている手法なので、OODAループを選んでいます。

-p30, p31 link: 開発チームのマネージャーとして意識しているチームのCapability

- p36 link: LayerX 採用情報, shkomine OpenDoor

最後に、弊社ではLayerX Casual NightというLayerXのプロダクトメンバーと美味しいお酒やご飯を囲みながら、プロダクトやチーム、技術の話をゆる〜く行うイベントを定期的に行っています。
もう一歩踏み込んだお話もできるかもしれません。よかったらぜひご参加ください!

shkomine

December 15, 2023
Tweet

More Decks by shkomine

Other Decks in Technology

Transcript

  1. © 2023 LayerX Inc. 3 本日のテーマ 「EM(Engineering Manager) とは何なのか」 -

    プロダクトのフェーズ(ライフサイクル): 導入期, 成長期, 成熟期, 衰退期 - チームのフェーズ(タックマンモデル): 形成期, 混乱期, 統一期, 機能期, 散会期 - チーム内外の状況 - toB or toC - and more... A. 会社やチームの状況によって、求められることは違う Read Me => 今日は、私にとっての 「EMとは?」 を身の丈に合わせて話します
  2. 目次 Agenda 前提. 自己紹介 & プロダクトと組織の紹介 0. 私にとっての 「EMとは?」 1.

    チームの基盤を整える 2. 日々の業務を遂行する 3. 変化を捉え改善する
  3. © 2023 LayerX Inc. 5 バクラク申請・経費精算 Engineering Manager @sh_komine LayerX

    • 2021/08/16 入社 => TechLead => Engineering Manager • プレイングマネージャー • 担当プロダクトのメンバー 2名 =>8名に拡大 (実質2チーム) • ベストマネージャー賞で社内表彰 経歴・スキル • 社歴: Yahoo! JAPAN => Candee => 友人と共同創業 => LayerX • スキル: Go, Typescript, Nuxt.js, AWS, Android, ベトナム駐在, iOS, Elixir, GCP, etc… 書いた記事 • 【GraphQL × Go】gqlgenの基本構成とオーバーフェッチを防ぐmodel resolverの実装 • 2年弱で5つのプロダクトが立ち上がる中での組織の変化と現場が向き合うハードシングス • 開発チームのマネージャーとして意識しているチームのCapability 自己紹介
  4. © 2023 LayerX Inc. 8 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行

    * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能 バクラクシリーズラインナップ
  5. © 2023 LayerX Inc. 9 「バクラク」 の特徴 会計システム インターネット バンキング

    (EBシステム) 法人カード 支払管理 経費精算 管理 請求書 支払管理 ワークフローツールの統一 経理ツールの統一 会計システム・ EBシステム連携 一 気 通 貫 で 連 携 経理業務を一元管理し、債権・債務に関連する業務を一気通貫でなめらかに連携。経理業務の工数を大幅削減。 出張申請 取引先申請 押印申請 契約申請 購買申請 法人カード 利用申請 請求書支払申請 経費精算申請 請求書 発行管理 保管場所の統一 領収書 保管 受領請求書 保管 発行帳票 保管 国税関係書類 保管
  6. © 2023 LayerX Inc. 10 2年半で6つのプロダクトと各連携をリリース * 2023年10月時点 2021/01 バクラク請求書

    2021/04 バクラク申請 2021/11 バクラク電子帳簿保存 2022/04 バクラク経費精算 2022/07 バクラクビジネスカード 2023/07 バクラク請求書発行
  7. © 2023 LayerX Inc. 11 プロダクト組織の体制 (2023.12) バクラク 申請・経費 精算

    QA ML/AI-OCR Design バクラク 請求書 バクラク 電子帳簿 保存 Enabling&Platform バクラク カード Data • 各プロダクトチームを横断チームがサポートする体制 • 各プロダクトにPdM、EngineeringManagerをアサイン、 各プロダクトの意思決定はプロダクト内で完結 • 各チームは2〜8人程度の少人数でチームを構成 プロダクト チーム 横断チーム プロダクト部 計50名 Engineering Office バクラク 発行 バクラク 共通管理
  8. © 2023 LayerX Inc. 13 画像を入れてね マネージャーのアウトプット = あなたのチームのアウトプット +

    あなたが影響を与えた他のチームのアウトプット アンドリュー・S・グローブ HIGH OUTPUT MANAGEMENT 0. 私にとっての 「EMとは?」 私にとっての 「EMとは?」 お客様に面したプロダクトチームのEM の目線で言い換えると、 自分のプロダクト+その隣接するプロダクトの成果を最大化し続ける ことがEMのお仕事。 個人的に一番しっくり来たマネージャーの定義
  9. 目次 Agenda 前提. 自己紹介 & プロダクトと組織の紹介 0. 私にとっての 「EMとは?」 1.

    チームの基盤を整える 2. 日々の業務を遂行する 3. 変化を捉え改善する
  10. © 2023 LayerX Inc. 17 共通の価値観の共有 - ミッション・ビジョン・バリュー - 会社でカバーされていればOK.

    プロダクトやエンジニアから見て遠ければ、別途作って補足 - チームにとっての 「良い行動」 まで言語化する - ex. Trustful Feedback、 使われないものを作らない (弊社 羅針盤より)    デモ駆動、 コードレビュー文化、 テスト駆動、 eslintによるレビューの自動化 迷わない目標を定める - チームメンバーの優先順位がブレない、ワクワクして、没頭できるもの - ex. 期ごとのOKR, KPT, 戦略 - メンバーの腹落ち感を作ることが重要で難しい => 意見やFactを汲み上げつつ、最後はマネージャーが決める or マネージャーが質疑応答で説明責任を果たすなどの工夫が必要 チームの方向性を定める 1. チームの基盤を整える チームの目指す方向 目標 共通の価値観
  11. © 2023 LayerX Inc. 18 透明性 (= 情報やヒトへのアクセシビリティ) - 基本的な情報は極力オープンに

    - アクセス性が下がって来たら、ポータルなど情報の起点を再整理する - 「誰が何を知っているか、どこを見たら何がわかるか」 をわかる状態にする 業務知識 (= 顧客・ドメイン理解、システム理解、市場理解) - プロダクトづくりに必要な知識は、極力ドキュメントにまとめる。 (ex. ドメインモデル図、 システム構成図) - 知らないことは当たり前と捉え、手厚く教える 議論を積み上げられる土台を作る 1. チームの基盤を整える 透明性 業務知識
  12. © 2023 LayerX Inc. 19 透明性 (= 情報やヒトへのアクセシビリティ) - 基本的な情報は極力オープンに

    - アクセス性が下がって来たら、ポータルなど情報の起点を再整理する - 「誰が何を知っているか、どこを見たら何がわかるか」 をわかる状態にする 業務知識 (= 顧客・ドメイン理解、システム理解、市場理解) - プロダクトづくりに必要な知識は、極力ドキュメントにまとめる。 (ex. ドメインモデル図、 システム構成図) - 知らないことは当たり前と捉え、手厚く教える 相互理解 (思ったことを言える関係性) - 互いのことがわからないと、相手がどう受け取られるかが怖くて、自分の思っていることを本音で言えない => 相互理解を深めるような施策が重要 - ex. 1on1でのMgrからの自己開示、 チームでの相互理解のワークショップ - 互いに弱みを見せれるくらいの関係になって初めて、思ったことが言える (詳しくはblog) 議論を積み上げられる土台を作る 1. チームの基盤を整える 相互理解 透明性 業務知識
  13. © 2023 LayerX Inc. 20 目標や土台を作ってメンバーのベクトルを揃えつつ、 議論積み上げられる基盤が整った 多様性のあるメンバーが同じ方向を向いて議論を積み上げることが高い成果を生む チームの方向性を揃え、議論を積み上げる 1.

    チームの基盤を整える チームのベクトル メンバーのベクトル チームのベクトル メンバーのベクトル マネジメント 共通の価値観 相互理解 目標 透明性 業務知識
  14. © 2023 LayerX Inc. 22 タスクに対してはオーナーを必ず決め、周りはサポートする オーナーのケイパビリティより、 一回り大きいケイパビリティのタスクをアサインすることが多い ケイパビリティが多少足りなくても、周りのサポートにより、オーナーのメンバーが成長する ※ケイパビリティの乖離が大きいと、負荷が大き過ぎて、遂行も学習もできない時もあるので注意が必要

    タスクのアサインと遂行 2. 日々の業務を遂行する タスク遂行に必要なケイパビリティ メンバーの持つ ケイパビリティ はそれぞれ タスクのアウトカムは 顧客理解 x 技術力 x UX・情報設計力 x プロジェクトマネジメント力 で決まる タスクの遂行に必要なケイパビリティをメンバーのケイパビリティの重ね合わせが満たせるようにアサインする オーナー サポート
  15. © 2023 LayerX Inc. 23 - タスクの遂行時、 Why What How

    すべてをメンバーに委譲 - 特にWhyはPdMやEMが考えることもあるが、担当のメンバーがオーナーシップをもつ - タスク以外にも、個別の技術、品質、会議体の運営など、特定の要素ごとにオーナーシップを任せる事は できる。 自分から剥がしてどんどん任せる - ex. フロントエンドのTechLead、 品質大臣、 スクラムマスター - 任せることは意思決定をするということ。 人は意思決定で成長する。 委譲度は常に意識する - 質も大事なので、委譲度はメンバーの状態を見て変化させる。 委譲しても、EMは説明責任を果たす必要がある - ex. デリゲーションポーカー - ティーチングとコーチングの割合もこの委譲度に合わせて変化する 委譲はできる限りする 2. 日々の業務を遂行する 指示する 売り込む 相談する 同意する アドバイス する 問い合わ せる 移譲する
  16. © 2023 LayerX Inc. 24 基本的に、 マネージャーが手を動かすことで以下のような利点がある - メンバーに「やって見せる」 ことができる

    - 現場レベルの解像度があがり、 戦略が宙に浮いたものにならない - 非常事態においては、「最悪自分がカバーする. 」 ということができる - TechLeadなどを他人に任せても、そのメンバーと違う観点でFBを返せる => なので、弊社ではチームの構成メンバーを少数に抑えて、プレイングマネージャーを中心にしている とはいえ、チームの状態が悪く、 メンバーが力を発揮できていない、成長できていない時に自分が手を動かして いるのは悪手。 チームの成果が最大化を考え、マネジメントを優先する マネジメントによるチームの成果 > 個人の成果 ※ 逆に少人数チームなど、 自分の成果 > マネジメントの成果 の時もある。 その時には柔軟に比重を変える マネージャーはプレイングであるべきか? 2. 日々の業務を遂行する
  17. © 2023 LayerX Inc. 25 様々なトレードオフの意思決定 日々の意思決定には様々なトレードオフがあり、いつも僕らを悩ませる、、、。 - 質 ⇔

    スピード - 技術的負債の解消 ⇔ フィーチャータスク - 短期的な成果 ⇔ メンバーの成長 - チーム内 ⇔ 組織全体 2. 日々の業務を遂行する
  18. © 2023 LayerX Inc. 26 様々なトレードオフの意思決定 日々の意思決定には様々なトレードオフがあり、いつも僕らを悩ませる、、、。 - 質 ⇔

    スピード - 技術的負債の解消 ⇔ フィーチャータスク - 短期的な成果 ⇔ メンバーの成長 - チーム内 ⇔ 組織全体 => 1.5年後の全体の成果が最大化されるように意思決定をしている - 1.5年後 = 短期での成果を求めつつ、中長期の成長も考えるということ - 四半期とか1年の場合: 短期の成果に偏重。 技術的負債や、成長するアサインが後回しに - 2年以上の場合: 「長期で見たら必要」 と必要のないものまで作りがち - 今の変化の多い状況だと、 「この投資は1.5年後に回収できてるかな?」 と考えると、 妥当性ある結論に至ることが多い 2. 日々の業務を遂行する
  19. © 2023 LayerX Inc. 28 状況の変化を捉え改善する 3. 状況の変化を捉え改善する チーム内の変化、組織の変化、市場の変化、 etc...

    日々、チームを取り巻く状況は変化する。 変化の大きい環境ではその変化をいち早く捉えて、手を打ち続けることが重要 => OODA(ウーダ)ループを回す - Observe: 情報を集め、観察することによって現状を認識する - Orient: 観察結果から、状況判断する - Decide: 具体的な方針・施策を意思決定する - Act: 意思決定したことを実行に移す => OODAの中では何より、Observe = 情報収集 が一番重要 正確な情報がなければ、何もアクションは取れない。 逆に、課題が見えたら優先順位をつけて対処できる。
  20. © 2023 LayerX Inc. 29 定期的に状況の変化をキャッチできる仕組みをつくる • 日々の変化をキャッチできる仕組みを作り、情報収集 => 振り返りのリズムを作ることが重要

    仕組み化で、意識しなくても自然と改善できる状態が理想 ◦ ex. 1on1、 朝会、 スプリントごとのKPT、 Bizからの要望収集会、 Dev Manager定例    月次のインシデント・エラーの集計、 期ごとの振り返り、 etc… 個別でも振り返る • 中規模以上のプロジェクトやインシデントなど、大きいものは個別に振り返る ◦ ex. プロジェクトの振り返りやインシデントのポストモーテム 生の情報を取りに行く • Face to faceだから取れる情報があるので、チーム外にも繋がりを作っておき、生の所感を集める ◦ ex. Bizとの飲み会を企画、 同世代で飲む、 サークル活動、 なんでもいい 状況の変化を捉えるタイミング 3. 状況の変化を捉え改善する
  21. © 2023 LayerX Inc. 31 4象限のマネジメントは機能しているか? 3. 状況の変化を捉え改善する ピープル マネジメント

    メンバーは一人一人がモチベーション高く働けているか、成長できているか、 チームは目標に向かい 多様性を持ちながらも一丸となって取り組める状態になっているか 人と組織のマネジメント。 EMが必ずマネジメントする。 テクノロジー マネジメント 数年後の事業の状態を見据え、適切な技術選定やアーキテクチャが選べているかどうか、 技術の耐用年数や品質、開発速度などのバランスが取れているか のマネジメント。 テックリードやシニアなエンジニアに委譲してもよい。 プロダクト マネジメント 顧客の持つ課題を見つけ、「何をつくるのか」、「なぜ作るのか」を管理するマネジメント。 プロダクトの初期フェーズにおいて一番不確実性が高い領域。 PdMに委譲しても良いが、自分でも必ず考える。 プロジェクト マネジメント 何かの課題に対して、期限・スコープ・品質・コストといったバランスを決めて、関係者と調整し物事を進 め達成まで導くためのマネジメント。 プロジェクトの数ごとに必要なので、チームに対し1:Nで発生しうる。 役割に関係なく、プロジェクトごとにオーナーが回せていればいい。 メンバーに委譲してもいいが、チームとしてバランス良く機能していることは重要。 (詳細はblog)
  22. © 2023 LayerX Inc. 32 チームメンバーの特性はバランスが取れているか? 特に真面目なチームで不在になりがちなのが、ムードメイカー チームにムードメイカーが不在な時、自分から失敗談を話したり、 雑談の話を振ったりを意識的にしている 3.

    状況の変化を捉え改善する 顧客やチームの課題を、技術力やドメイン の知識といった専門性を深掘りして解決 する人 ソルバー チームの雰囲気をポジティブに持ってい ける人。ユーモアのあることを言ったり、 ポジティブな言葉が多い人 ムードメーカー 落ちているボールを拾ってくれたり、 困っている人がいると助けたり、 周囲のことがよく見えている人 気が利く人 全員の当たり前水準を上げる体現者、 ハ イパフォーマーで、行動でチームの目線を 上げることができる人 目線を上げる人 連携しないと解決できない問題を、人と 人を繋げたり、両方の仕事をやったりし て、解決まで持って行ける人 ジェネラリスト チームメンバーのバランスは重要。 一人二役でもいいので、以下の特性が揃っているチームは安定する 足りないところは、人を育てたり、EM自身がカバーできると良い。 (詳細はblog)
  23. © 2023 LayerX Inc. 33 組織全体で俯瞰して見れているか? EMは自チームの事だけでも大変なので、意識をしないと、自チームだけの部分最適に陥いる 自チームのみの部分最適に陥ってないか? 組織全体で俯瞰して見れているか? いくつかの問いで、自チームの外にも目を向け、全体最適を考える

    - 自分のチームのロードマップより、事業全体から見た時の注力領域はないか? - 全体の採用活動はうまく行っているか? 見る人がいるか? - 各チームのEMはうまくやれているか? 自分から分けられるナレッジやTipsはないか? - 斜めの1on1を必要としているメンバーが他のチームにいないか? - 組織内に足りない機能、チームはないか? - etc... 3. 状況の変化を捉え改善する 全体の最大化 自チーム 隣のチー ム 隣のチー ム
  24. © 2023 LayerX Inc. 35 自分のプロダクト+その隣接するプロダクトの成果を最大化し続ける ために、日頃考えていることを、以下の3ステップでご紹介しました。 1. チームの基盤を整える 2.

    日々の業務を遂行する 3. 状況の変化を捉え改善する 今回の内容は、 「もし、EM未経験者がEMになったときに、自分がメンターをするなら何を伝えるか?」 と考えたものをまとめた内容になります。 EMが向き合う課題は多岐に渡り難しいですが、 一歩ずつ、 諦めずに進んでいきましょう!! まとめ まとめ
  25. © 2023 LayerX Inc. 36 バクラクのEMはプロダクトごとに裁量を持って働いており、 EMにとって、「成果の最大化」 と向き合って働けるいい環境です!! - 毎週開催しているDevManager定例での事例共有やディスカッションが学びになる

    - CTO経験のあるEMやVPoEにカジュアルに相談できる - どんどんプロダクトが生まれるので、まだまだEMは必要 - Whole Productで価値を届けようとしているので、プロダクト間連携など、まだまだ課題も多い - Engineering Career Ladderを策定中 OpenDoorからカジュアル面談が申し込めます。ぜひ気軽にお話しましょう!! LayerXでは絶賛採用中です! まとめ @sh_komine OpenDoor https://jobs.layerx.co.jp/869a2596b6a04bdf83 28249c1005bc40 採用情報 https://jobs.layerx.co.jp/