環境変化に合わせた開発組織とEM期待の変化

環境変化に合わせた開発組織と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、メガベンチャー、スタートアップ、技術、マネジメント ) •
今日のもっと詳しい苦労話・楽しい話

環境変化に合わせた開発組織とEM期待の変化

環境変化に合わせた開発組織とEM期待の変化

shinden

More Decks by shinden

Other Decks in Technology

Featured

Transcript