$30 off During Our Annual Pro Sale. View Details »

startup-mega_venture_em_20230628

kakehashi
June 30, 2023

 startup-mega_venture_em_20230628

kakehashi

June 30, 2023
Tweet

More Decks by kakehashi

Other Decks in Business

Transcript

  1. 環境変化に合わせた
    開発組織とEM期待の変化
    2023/6/28 スタートアップ〜メガベンチャーのEMが語る
    強い開発組織づくりとキャリア戦略
    shinden tomohiro
    ハッシュタグ #kakehashi_dev

    View Slide

  2. 自己紹介
    名前:新田智啓 (Shinden Tomohiro)
       ふりがなが無いと99%読み間違えられます
    経歴:EMっぽいことやり始めて10年近くなりました
       SI系もWeb系も開発を経験
    2001年〜 SIer数社
    ・エンジニア、テックリード、エンジニアチームマネージャなど
    2014年〜 サイバーエージェント
    ・アドテクスタジオ、エンジニア、開発責任者、技術責任者、子会社CTOなど
    2018年〜 メルペイ
    ・バックエンドエンジニアリングマネージャ、テクニカルプログラムマネージャ
    2020年〜 現在 カケハシ
    ・新規プロダクト開発(AI在庫管理チーム) の 開発ディレクター(スクラムマスター)として入社
    ・2022年9月 からはエンジニアリングマネージャーとして活動
    ・働き始めて2年半経ちますが、オフィスへの出社回数は10回以下のフルリモート環境

    View Slide

  3. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  4. 今日話すこと
    ★ カケハシについて ◀◀◀
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  5. 株式会社カケハシ
    創業7年で正社員300人超
    日本の医療体験を、しなやかに。
    ミッション
    患者だけでなく医療従事者を支える
    サステナブルな仕組みを実現する
    バリュー
    累計調達額149億円
    のミッション

    View Slide

  6. 株式会社カケハシ
    薬局向けのサービスを複数展開
    のプロダクト

    View Slide

  7. 株式会社カケハシ のプロダクト開発の特徴
    ● アジャイル開発のスクラム前提
    5〜10人チームで専任のスクラムマスターがいる組織 


    ● ステージ/特徴の異なる5つのプロダクト
    創業プロダクトで大手チェーン導入フェーズから新規事業まで 


    ● 圧倒的な顧客解像度の高さ
    既存顧客とSlackで仕様相談 など非常に顧客に近い環境での開発 


    ● 様々なモダンな技術をフル活用した開発
    AWSフル活用、モダンフレームワーク活用 した開発


    ● フレキシブルな働き方
    フルリモート開発が標準 で、自由と責任をセルフマネジメント

    View Slide

  8. 株式会社カケハシ
    創業7年で正社員300人超
    今回の話はこの辺りの話
    カケハシで

    一番新しいプロダクト 


    View Slide

  9. 今日話すこと
    環境変化に合わせた
    開発組織とEM期待の変化
    ~ カケハシのとある開発チームでの事例 ~

    View Slide

  10. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要 ◀◀◀
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  11. 環境とチーム(開発組織)の関係
    開発の環境は変化するため
    いつも同じマネジメントをするだけでは上手く行かない
    チーム

    環境
    働きやすい環境を
    つくる取り組み
    環境に合わせた
    最適な状態になる

    View Slide

  12. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化 ◀◀◀
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  13. どんな環境変化がある?
    環境変化
    もっと無限にあるけれど今日は3つ
    事業状況
 メンバー数
 開発状況


    View Slide

  14. 環境変化とは?
    環境変化
    事業状況
 メンバー数
 開発状況

    スタートアップの変化スピードは凄く早い
    開発チームに2年間で起こったこと
    5人 → 50人 ゼロ → 技術的負債
    リリース → 大規模導入

    View Slide

  15. 環境変化とは?
    環境変化
    事業状況
 メンバー数
 開発状況

    これをなんとかするのがEMの仕事
    5人 → 50人 ゼロ → 技術的負債
    リリース → 大規模導入

    View Slide

  16. 事業状況の変化
    リリース前 PMF前 PMF後
    開発組織
    EM期待
    開発ボーナスタイム
    開発だけに集中出来る時間
    最小の時間で開発土台作り
    最短でリリースに向かう
    開発と運用のバランス
    運用の差し込みをこなしながら
    素早く開発する必要がある
    中長期に向けた開発
    システム面と組織面の両方で
    成長に向けた仕組み化の強化
    中規模大規模の企業に向けた提供
    ゼロからプロセス構築
    開発のリズムと方向性を作る
    差し込みを計測する
    開発だけではなく、運用に使われる
    時間を計測する仕組みに変える
    真に開発に使える時間を測る
    運用の効率化タイミングを考える
    開発者提案の比重を高める
    事業の長期の成長のため、技術的ボトル
    ネック要件を提案が出来る仕組みと目線
    に変える
    事業
    状況

    メンバ

    ー数

    開発
    状況


    View Slide

  17. 1チーム人数多すぎ
    会議で全員が話すには難しい
    集まって話すので情報は届くが
    十分に拾えない
    メンバー数の変化
    5〜10人弱 10〜15人 20〜+40人
    開発組織
    EM期待
    ※同時に全社の社員は100人 → 300人overへ変化することにも対応 

    理想サイズのスクラム
    話せばチーム全体に情報届く
    深く議論が出来る
    LeSS導入
    複数チーム化による運営変化
    コミュニケーションパスの複雑化
    開発力の不足
    事業スピードに合わせた開発力
    次のスピード開発に向けた
    採用活動をする
    複数チーム設計
    コミュニケーションパスの複雑化の
    デメリットと少人数チームでフォーカ
    スできるメリットを設計
    各チームが安定して開発出来るよう
    なメンバー採用活動をする
    複数チーム安定
    全体のプロセスと個別チームのプロ
    セスを安定させる
    全体最適化と個のチームの主体性
    各チームが更に加速するための軸
    になるメンバー採用活動をする
    事業
    状況

    メンバ

    ー数

    開発
    状況


    View Slide

  18. 開発状況の変化
    何もない コンセプト開発 スケーラブル対応
    開発組織
    EM期待
    試行錯誤の最速機能提供
    ユーザーが求める機能を探す
    不足機能も多数開発
    最短で動くものが必要
    システムが動かなければ
    何も検証が出来ない
    内部品質アップ
    技術土台の修正
    リアーキテクチャ
    非機能な要件の洗い出し
    不足を先送りやコント
    ロールしながら開発
    CI/CDなどは最低限つくるが、プロ
    ダクトリリースの最短を考える
    負債抱えつつ機能開発
    負債をなくしても事業がなくなっては
    意味がない
    まずは価値ある機能を検証する
    事業影響する負債解消
    プロダクト価値の検証が完了した瞬
    間から負債が襲いかかる
    今までのやり方では全く上手く行か
    ない
    今までのやり方が間違いではない
    チームの価値観の転換が必要
    ※事業状況とメンバー状況を大きく受けながら開発方法も変わっていく 

    事業
    状況

    メンバ

    ー数

    開発
    状況


    View Slide

  19. 環境変化に対応してきた
    環境変化
    事業状況
 メンバー数
 開発状況

    不足は多いが、なんとかついていった
    5人 → 50人 ゼロ → 負債
    リリース → 大規模導入

    View Slide

  20. 経験と反省
    結果、当たり前の話でした
    マネージャとしての経験と反省
    採用が大事
 方針が大事
 専門性大事


    View Slide

  21. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力 ◀◀◀
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  22. チーム変化の力が必要
    環境変化と組織変化
    ロバストネス

    (耐久力)

    レジリエンス

    (回復力)

    アジリティ

    (対応力)


    View Slide

  23. プロセスへの変化力
    以前フェーズのプロセスをアンラーンし、全く違う進め方をする
    事業に対応するためにメンバーを採用し変化する
    ロバストネス

    (耐久力)

    レジリエンス

    (回復力)

    アジリティ

    (対応力)

    メンバーが増えることで
    多少仕事が増えても大丈夫
    変化への余力を持つ
    環境変化で合わなくなったものを対応する
    (メンバー増加、事業状況変化への構築力
    )
    プロセスのゼロからの構築
    仕組み化出来ていない変化中にも
    柔軟に対応するチームの多様性と
    個別と全体の認識合わせ

    View Slide

  24. 大きな事業をスピード感を持って作る
    そのためにはメンバーが必要
    まずは沢山のアウトプットが出来る体制をつくる必要がある
    価値にフォーカスするのは一定の量が作れる前提がある
    (変化のために使う工数も必要 )
    事業に対応するためにメンバーを増やす変化
    小さなチームで作れる量 大きなチームで作れる量
    ロバストネス

    (耐久力)

    View Slide

  25. 環境変化のスピードが早いと
    「全体と個」の最適化の変化スピードが必要
    環境変化すると今まで通りのプロセスでは上手く行かない
    変化が多く大きいほど既存プロセスの陳腐化も早い
    急速な環境変化であれば、強力な変化に対応する力が必要
    メンバーが増えたときの組織の変化 レジリエンス

    (回復力)

    小さなチームプロセス
    大きなチームプロセス
    環境の変化が緩やか 環境の変化が急速
    状況にフィットしないプロセス
    状況に合わせたプロセス
    ゆっくり変化
    しても大丈夫
    プロセスの劣化が早く
    素早く変化が必要

    View Slide

  26. チームが大きくなると
    「全体と個」の最適化の距離が遠くなる
    全体と個と最適の目線をあわせる必要がある
    目線を合わせることでアジリティが高まる
    (細かなルールが決まってなくても動ける )
    組織の変化中の対応 アジリティ

    (対応力)

    全体

    最適

    個別

    最適

    全体

    最適

    個別

    最適

    複数チームで運営、数十人体制
    1チームで運営、数人体制

    View Slide

  27. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省 ◀◀◀
    ○ 採用、方針、専門性
    ★ まとめ

    View Slide

  28. 経験と反省
    結果、当たり前の話を再認識
    マネージャとしての経験と反省
    採用が大事
 方針が大事
 専門性大事


    View Slide

  29. 採用が大事
    チームサイズが大きくなると
    1人でマネジメントするのには限界が来る
    1つのチームに1人は
    チームの文化 (変化力)を作るメンバーの採用が必要
    ※時間があれば育成でも OKだが、スタートアップには時間がない、、、
    チーム文化を作るのはマネージャだけではない
    軸になる人が居ると全体が動きやすくなる
    個人が活躍できる強い組織にできる
    採用が
    大事

    方針が
    大事

    専門性
    が大事


    View Slide

  30. 方針が大事
    細かいマネジメントではなく、方向性を示す事が大事
    目線を揃えるためのルールメイクをする
    細かなところはチームに任せることで強い組織になる
    開発方針・設計方針・テスト方針・品質方針・プロセス方針、色々な方針があるが現
    場が一番知っている
    方針を回すためのプロジェクト管理手法、OKR、スクラムなどプロセスを回すツール
    を使った目標達成だけでなく、チームが価値観の理解も進むようにする
    先人が編み出した手法や体系的な知識に助けてもらう
    採用が
    大事

    方針が
    大事

    専門性
    が大事


    View Slide

  31. 専門性が大事
    マネジメントはスペシャルな専門スキルだという実感
    プレイヤーの職能知識に加え、Mgr専門の知識の深さが必要
    マネジメントスキルは片手間で身につける広さや深さではない
    エンジニアリングを活用はできるが + optionスキルではなく、期待されるレベルは環境によって違う
    リーダーシップやマネジメント力は後天的にも身につけられるスキルで学ぶことが大事
    アジャイルではグラデーション的に上位マネジメントが求められる
    カッツモデルやドラッカーモデルはヒエラルキー型を想定しているように感じるが、
    アジャイルなチームでは上位マネジメント的領域の役割や知識が必要になる
    トップマネジメント
    (経営者層)
    ミドルマネジメント
    (管理職層)
    ロワーマネジメント
    (リーダー層)
    テクニカルスキル

    (業務遂行能力)

    ヒューマンスキル

    (対人関係能力)

    コンセプチュアルスキル

    (概念化能力)

    カッツモデル
    採用が
    大事

    方針が
    大事

    専門性
    が大事


    View Slide

  32. 今日話すこと
    ★ カケハシについて
    ★ 環境変化への対応が必要
    ★ 開発チームに起きた環境変化
    ○ 事業状況変化、メンバー数変化、開発状況変化
    ★ 必要だったチームの変化の力
    ○ 耐久力、回復力、対応力
    ★ 経験と反省
    ○ 採用、方針、専門性
    ★ まとめ ◀◀◀

    View Slide

  33. テーマを振り返って
    変化に対応する力を作ること
    個であっても組織であっても同じ
    変化力を考える
    変化のタイミングは大変だが面白い
    ※ホントに大変なんだけど、成長チャンスでもある
    テーマ:強い開発組織づくりとキャリア戦略

    View Slide

  34. テーマを振り返って
    エンジニアリング知識を理解した上で
    真に強い開発組織をつくる
    EMのキャリア戦略として
    試しにマネジメントを深く掘り下げる
    チャレンジをしてみてもいいのでは?
    テーマ:強い開発組織づくりとキャリア戦略

    View Slide

  35. まとめ
    環境が変化するため一辺倒なマネジメントではなく
    状況に合わせてアンラーンしたマネジメントが求められる
    強いチームを作るにはまずは採用・方針・専門性
    マネジメントの専門性は深い
    フォーカスしたチャレンジするのも良いかもしれない

    View Slide

  36. 株式会社カケハシ
    コーポレートサイト
    https://www.kakehashi.life/
    中で働く人
    https://recruit.kakehashi.life/
    Connpass
    https://kakehashi.connpass.com/
    大きな変化と大きなチャレンジがある
    テックブログ
    https://kakehashi-dev.hatenablog.com/
    Kakehashi Handbook
    https://handbook.kakehashi.life/
    ハッシュタグ
    #kakehashi_dev
    技術と組織は繋がっている

    View Slide

  37. カケハシの登壇予定のイベント
    医療スタートアップ開発の裏側
    2023/7/3 (月) 19:00-20:00
    https://henry.connpass.com/event/286755/
    Developers Summit 2023 Summur
    20%ルールに頼らない:
    技術的負債を解消する組織的な取り組み
    https://event.shoeisha.jp/devsumi/20230727

    View Slide

  38. まずは情報交換でカジュアルに話しましょう!
    ● エンジニアリングマネージャのよもやま
    ● エンジニアキャリア 雑談
    ( SI、Web、メガベンチャー、スタートアップ、技術、マネジメント )
    ● 今日のもっと詳しい苦労話・楽しい話

    View Slide

  39. 39

    View Slide