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

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

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

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

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

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

株式会社カケハシ のプロダクト開発の特徴 ● アジャイル開発のスクラム前提 5〜10人チームで専任のスクラムマスターがいる組織 
 
 ● ステージ/特徴の異なる5つのプロダクト 創業プロダクトで大手チェーン導入フェーズから新規事業まで 
 
 ● 圧倒的な顧客解像度の高さ 既存顧客とSlackで仕様相談 など非常に顧客に近い環境での開発 
 
 ● 様々なモダンな技術をフル活用した開発 AWSフル活用、モダンフレームワーク活用 した開発
 
 ● フレキシブルな働き方 フルリモート開発が標準 で、自由と責任をセルフマネジメント

株式会社カケハシ 創業7年で正社員300人超 今回の話はこの辺りの話 カケハシで
 一番新しいプロダクト 


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

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

環境とチーム(開発組織)の関係 開発の環境は変化するため いつも同じマネジメントをするだけでは上手く行かない チーム
 環境 働きやすい環境を つくる取り組み 環境に合わせた 最適な状態になる

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

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


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

環境変化とは？ 環境変化 事業状況
 メンバー数
 開発状況
 これをなんとかするのがEMの仕事 5人 → 50人 ゼロ → 技術的負債 リリース → 大規模導入

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


１チーム人数多すぎ 会議で全員が話すには難しい 集まって話すので情報は届くが 十分に拾えない メンバー数の変化 5〜10人弱 10〜15人 20〜+40人 開発組織 EM期待 ※同時に全社の社員は100人 → 300人overへ変化することにも対応 
 理想サイズのスクラム 話せばチーム全体に情報届く 深く議論が出来る LeSS導入 複数チーム化による運営変化 コミュニケーションパスの複雑化 開発力の不足 事業スピードに合わせた開発力 次のスピード開発に向けた 採用活動をする 複数チーム設計 コミュニケーションパスの複雑化の デメリットと少人数チームでフォーカ スできるメリットを設計 各チームが安定して開発出来るよう なメンバー採用活動をする 複数チーム安定 全体のプロセスと個別チームのプロ セスを安定させる 全体最適化と個のチームの主体性 各チームが更に加速するための軸 になるメンバー採用活動をする 事業 状況
 メンバ
 ー数
 開発 状況


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


環境変化に対応してきた 環境変化 事業状況
 メンバー数
 開発状況
 不足は多いが、なんとかついていった 5人 → 50人 ゼロ → 負債 リリース → 大規模導入

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


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

チーム変化の力が必要 環境変化と組織変化 ロバストネス
 (耐久力)
 レジリエンス
 (回復力)
 アジリティ
 (対応力)


プロセスへの変化力 以前フェーズのプロセスをアンラーンし、全く違う進め方をする 事業に対応するためにメンバーを採用し変化する ロバストネス
 (耐久力)
 レジリエンス
 (回復力)
 アジリティ
 (対応力)
 メンバーが増えることで 多少仕事が増えても大丈夫 変化への余力を持つ 環境変化で合わなくなったものを対応する (メンバー増加、事業状況変化への構築力 ) プロセスのゼロからの構築 仕組み化出来ていない変化中にも 柔軟に対応するチームの多様性と 個別と全体の認識合わせ

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

環境変化のスピードが早いと 「全体と個」の最適化の変化スピードが必要 環境変化すると今まで通りのプロセスでは上手く行かない 変化が多く大きいほど既存プロセスの陳腐化も早い 急速な環境変化であれば、強力な変化に対応する力が必要 メンバーが増えたときの組織の変化 レジリエンス
 (回復力)
 小さなチームプロセス 大きなチームプロセス 環境の変化が緩やか 環境の変化が急速 状況にフィットしないプロセス 状況に合わせたプロセス ゆっくり変化 しても大丈夫 プロセスの劣化が早く 素早く変化が必要

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

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

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


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


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


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


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

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

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

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

株式会社カケハシ コーポレートサイト 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 技術と組織は繋がっている

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

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

39