2022年からCTO交代！新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化 / Engineers-in-CARTA-2022-Summer

by CARTA Engineering

Slide 1

Slide 1 text

Engineers in CARTA 2022年からCTO交代！新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化 2022年8月4日

Slide 2

Slide 2 text

これまでの10年 AGENDA ex-CTO 小賀昌法これからの10年新CTO 鈴木健太新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化

Slide 3

Slide 3 text

3 CARTA HOLDINGS は 2019年1月 VOYAGE GROUP と CCI が経営統合して誕生しました多くの事業・サービスを運営しています（下記は一部を抜粋）

Slide 4

Slide 4 text

4 このセッションでは VOYAGE GROUP でのこれまでの10年 CARTA HOLDINGS でのこれからの10年についてお話しますこれからの10年これまでの10年

Slide 5

Slide 5 text

ex-CTO 小賀昌法これまでの10年

Slide 6

Slide 6 text

6 自己紹介 ex-CTO (2010-2021) 小賀昌法 Twitter: @makoga 経歴 2010年7月〜2021年12月 VOYAGE GROUP CTO 2020年1月〜2021年12月 CARTA HOLDINGS CTO 2022年1月〜 CARTA Tech Boardアドバイザリ好きなこと ● 経営や組織をエンジニアリングする ● 成長する環境づくりこれまでの10年

Slide 7

Slide 7 text

7 まずは結論から CTOとしての10年間これまでの10年

Slide 8

Slide 8 text

8 文化という土台が固まり、攻めに使える開発力が増えた CTOとしての10年間の結論これまでの10年事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 暗黙の文化明文化された文化攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力 10年

Slide 9

Slide 9 text

文化が根付くこれまでの10年

Slide 10

Slide 10 text

10 CTOとしての10年間の結論これまでの10年文化が根付く暗黙の文化明文化された文化言語化

Slide 11

Slide 11 text

11 “人間の生活様式の全体。人類がみずからの手で築き上げてきた有形・無形の成果の総体。それぞれの民族・地域・社会に固有の文化があり、学習によって伝習されるとともに、相互の交流によって発展してきた。” https://kotobank.jp/word/%E6%96%87%E5%8C%96-128305 「文化」とはこれまでの10年

Slide 12

Slide 12 text

12 事業をエンジニアリングする急激な変化に適応できるチーム本質を見極め、柔軟に考える小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする根付いた文化とはこれまでの10年

Slide 13

Slide 13 text

13 事業をエンジニアリングする急激な変化に適応できるチーム本質を見極め、柔軟に考える小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトするどこから始めたのか？根付いた文化とはこれまでの10年

Slide 14

Slide 14 text

14 みなさんに質問です！質問これまでの10年

Slide 15

Slide 15 text

15 2010年 CTO就任時に感じていた課題 ● 短期的なスピードを重視しすぎている ● エンジニアの能力評価に対する納得感が低い ● 採用・育成・評価の価値観が統一されていない 2010年 CTO就任時に感じていた課題これまでの10年

Slide 16

Slide 16 text

16 ● 短期的なスピードを重視しすぎている ● エンジニアの能力評価に対する納得感が低い ● 採用・育成・評価の価値観が統一されていない同じような課題、見たことありませんか？ 2010年 CTO就任時に感じていた課題これまでの10年

Slide 17

Slide 17 text

17 ● 短期的なスピードを重視しすぎている ● エンジニアの能力評価に対する納得感が低い ● 採用・育成・評価の価値観が統一されていないなぜこうなってしまうのか？ 2010年 CTO就任時に感じていた課題これまでの10年

Slide 18

Slide 18 text

18 事業部A 本部B 子会社C 原因１：組織構造 ● 事業部/本部/子会社の責任者は技術に詳しいわけではない ● 責任者はシステムの内部構造が見えないので、見えやすい実績を高く評価してしまう原因２：技術の多様化 ● 技術マネージャは全ての技術においてメンバーより詳しいわけではない ● フロントエンド(Web/iOS/Android)、バックエンド、データベース(RDB/KVS)、インフラ (AWS/GCP/オンプレ)、データ分析、セキュリティなど多岐にわたる会社事業責任者・技術マネージャエンジニア技術力評価課題が生まれた原因これまでの10年技術力評価技術力評価

Slide 19

Slide 19 text

19 チームを越えた能力評価制度『技術力評価会』が始まった課題に対する解決策の1つとしてこれまでの10年

Slide 20

Slide 20 text

20 グレード制度 (等級制度) ● 職種ごとにグレードが定義されている ● 半年に1度の評価タイミングで昇降格が決まる評価制度 ● 全職種共通 ○ 半年に1度 ○ 事業貢献、能力、CREED Competency Feedback の3軸を総合評価 ● エンジニア職 ○ 能力評価の仕組みとして技術力評価会がある ○ 技術力評価会の評価結果はグレードの昇格に大きく影響する ○ 2011年から継続 VOYAGE GROUPの人事制度(抜粋) これまでの10年

Slide 21

Slide 21 text

21 事業貢献評価部署A 部署B 部署C 能力評価能力評価能力評価能力評価鈴木佐藤村岡山田技術力評価会とはこれまでの10年全社のエンジニアが部署をまたいで相互に能力評価をする仕組み事業貢献と能力の評価を分け、より納得感のある評価ができるようになった。

Slide 22

Slide 22 text

22 評価者は2人 ● 社外評価者がいるときは 3人事前準備 ● 被評価者は評価会の 1週間前に資料を提出当日 ● 1時間30分 ● 被評価者がプレゼン (約30分) ● 評価者との質疑応答 (約60分) 後日 ● 評価者は評価結果を作成 ● 評価者2人、評価委員、CTOの4人でフィードバック内容をすり合わせ ● 被評価者に評価者からフィードバック技術力評価会とはこれまでの10年

Slide 23

Slide 23 text

23 技術力評価会の全体の流れ技術力評価会とはこれまでの10年全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備

Slide 24

Slide 24 text

24 全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備日々の事業活動をBUILDとすると技術力評価会はMEASUREとLEARNにあたる技術力評価会とはこれまでの10年 https://marmelab.com/blog/2016/02/12/build-measure-learn.html

Slide 25

Slide 25 text

25 半年で2人、2年で8人から多角的なフィードバックをもらう 1回目技術力評価会とはこれまでの10年 2回目 3回目 4回目 1年目 2年目

Slide 26

Slide 26 text

26 『技術力評価会』はどのような影響があったのか技術力評価会と文化これまでの10年

Slide 27

Slide 27 text

27 評価軸からみる文化これまでの10年

Slide 28

Slide 28 text

28 2011年の評価軸 ● 事業・サービスの理解度 ● プロジェクトごとの要件・制約の理解度 ● 変更容易性 ● 可用性 ● 性能 ● セキュリティ ● テスト容易性評価軸からみる文化これまでの10年

Slide 29

Slide 29 text

29 2011年の評価軸 ● 事業・サービスの理解度 ● プロジェクトごとの要件・制約の理解度 ● 変更容易性 ● 可用性 ● 性能 ● セキュリティ ● テスト容易性言われたものをただ作るのではなく、エンジニアが事業・サービス、要件・制約を理解し、改善案の提案も含めて一緒に作っていくその後「事業をエンジニアリングする」という言葉が見つかる評価軸からみる文化これまでの10年

Slide 30

Slide 30 text

30 2011年の評価軸 ● 事業・サービスの理解度 ● プロジェクトごとの要件・制約の理解度 ● 変更容易性 ● 可用性 ● 性能 ● セキュリティ ● テスト容易性質とスピードを両立させるために、内部品質に投資する評価軸からみる文化これまでの10年

Slide 31

Slide 31 text

31 2013年の評価軸実現力 ● スコープ定義 ● システム構築・運用 ● プロジェクトマネジメント改善力 ● システム的な改善 ● ビジネス的な改善 2011年の評価軸 ● 事業・サービスの理解度 ● プロジェクトごとの要件・制約の理解度 ● 変更容易性 ● 可用性 ● 性能 ● セキュリティ ● テスト容易性 2014年の評価軸実現力 ● 何が課題で何が必要と考えたか。 ● 構築・運用したシステムは妥当か。 ● プロジェクトの進め方は妥当か。改善力 ● システム的な改善は妥当か。 ● ビジネス的な改善への貢献は妥当か。うまくいっていたとしても、更なる高みを目指し、変えていく評価軸からみる文化これまでの10年

Slide 32

Slide 32 text

32 「全体ふりかえり」から見る文化これまでの10年全体ふりかえり 5, 6人ごとのチームに別れ、今回の技術力評価会についてKeep, Problemを出し、最後にチームごとの重要なトピックを発表する会。ここで出たトピックは、次回の技術力評価会の改善の元ネタとなる。

Slide 33

Slide 33 text

33 技術力評価会の全体の流れ（再掲）技術力評価会とはこれまでの10年全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備

Slide 34

Slide 34 text

34 「全体ふりかえり」から見る文化これまでの10年全体ふりかえり全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり

Slide 35

Slide 35 text

35 全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり「全体ふりかえり」から見る文化これまでの10年全体ふりかえりはLEARNの1つにあたる https://marmelab.com/blog/2016/02/12/build-measure-learn.html

Slide 36

Slide 36 text

36 2015年11月に実施した「全体ふりかえり」で実際に出た意見　抜粋その1 「全体ふりかえり」から見る文化これまでの10年

Slide 37

Slide 37 text

37 2015年11月に実施した「全体ふりかえり」で実際に出た意見　抜粋その1 「全体ふりかえり」から見る文化これまでの10年

Slide 38

Slide 38 text

38 2015年11月に実施した「全体ふりかえり」で実際に出た意見　抜粋その2 「全体ふりかえり」から見る文化これまでの10年

Slide 39

Slide 39 text

39 2015年11月に実施した「全体ふりかえり」で実際に出た意見　抜粋その2 「全体ふりかえり」から見る文化これまでの10年

Slide 40

Slide 40 text

40 「全体ふりかえり」から見る文化これまでの10年主体性を持って発言し、ともに学び、制度自体もみんなで改善していく全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり

Slide 41

Slide 41 text

41 価値観を言語化これまでの10年 https://scrapbox.io/nishio/%E8%A8%80%E8%AA%9E%E5%8C%96%E3%82%92%E4%BF%83%E3%81%99%E6%96%B9%E6%B3%95

Slide 42

Slide 42 text

42 全体ふりかえり技術力評価会を10年運営していくなかで価値観を言語化し、全体ガイダンスで繰り返し伝えていった価値観を言語化これまでの10年全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体準備、ガイダンス

Slide 43

Slide 43 text

43 大方針 ● 急激な変化にも適応できるチームであり続ける ● 事業をエンジニアリングする大切にしたいこと ● 本質を見きわめ、柔軟に考える ● 小さく挑戦し続け、早く失敗する ● 仲間と相互にフィードバックしあい、継続的に成長する価値観を言語化これまでの10年

Slide 44

Slide 44 text

44 その時点で当たり前のことをちゃんとやる。 2016年4月時点での例 ● 適切なバージョン管理 ● 設計レビュー・コードレビュー ● 必要十分なテスト ● 1ステップビルド ● 1ステップデプロイ ● 誰でもロールバック可能 ● 常に最適なツールを模索 ● ポータビリティの高いアプリケーション ● ディスポーザブルな環境 ● キャパシティプランニング・事前検証 ● サービスレベルに応じた監視・運用体制 ● セキュリティリスク対策 ● プライバシーバイデザインなど価値観を言語化これまでの10年

Slide 45

Slide 45 text

45 VOYAGE GROUPにおける価値あるエンジニアとは全ての関係者にとって価値あるサービスを継続的に提供できる。チームの成果を最大化できる。職種を問わず多様なクルーからリスペクトされる。仮説が1つしか浮かばないのは危険信号。事業課題を理解し、仮説を立てる。価値観を言語化これまでの10年

Slide 46

Slide 46 text

46 VOYAGE GROUPにおける価値あるエンジニアとは全ての関係者にとって価値あるサービスを継続的に提供できる。 ● 顧客・ピープル・サービス・事業を理解する。 ● 制約条件の中で本質を見極める。 ● サービスやシステムに対して、新たな課題を見つけ、改善策を提示できる。 ● 改善策に対して、システムを安定運用させながら反映させることができる。 ● 既知および未知の問題に対して、チームが素早く検知できるようにシステムを設計、構築できる。 ● 発生した問題に対して、チームの誰もが速やかに安定していた状態に戻せるようにシステムを設計、構築できる。 ● 発生した問題に対して、迅速に適切に対応できる。価値観を言語化これまでの10年

Slide 47

Slide 47 text

47 VOYAGE GROUPにおける価値あるエンジニアとはチームの成果を最大化できる。 ● 仲間と事を成す。 ● やるべきことに対して、顧客満足と収益のバランスを取りながら適切な優先順位を付けることができる。 ● 「リリース→フィードバック→改善→リリース→・・・」のようなサイクルに対して全体最適化できる。職種を問わず、多様なクルーからリスペクトされる。価値観を言語化これまでの10年

Slide 48

Slide 48 text

48 VOYAGE GROUPにおける価値あるエンジニアとは事業課題を理解し、仮説を立てる。管理画面を使っている人から「検索機能が欲しい」と言われたら、どんな行動をしますか？どんな機能が必要かヒアリングすると考えた人はちょっと気が早いかもしれません。まずは「いま何に困っているのか」「もし検索機能があったとして、検索結果をどのように使いたいのか」を理解するのが重要と思います。もしかすると、使い方によっては既存機能でもいいかもしれませんし、デフォルトのソート順を変えるほうがいいかもしれません。なにか機能が欲しいと言われた時は、課題を理解し、それを解決する仮説を立てましょう。価値観を言語化これまでの10年

Slide 49

Slide 49 text

49 VOYAGE GROUPにおける価値あるエンジニアとは仮説が1つしか浮かばないのは危険信号。課題を理解しました。あなたは良い解決策を思いつきました。これは最高のアイデアなのですぐ実装するぞ！と考えた人はちょっと気が早いかもしれません。まず解決策が思いついても、それはまだ仮説です。本当に効果的かはまだ分かりません。そして仮説が1つしかないときは過去の経験や現状によるバイアスが掛かっているかもしれません。同じような課題を持っている人がいないかググってみたり、他のチームの人に聞いてみましょう。価値観を言語化これまでの10年

Slide 50

Slide 50 text

50 このようにみんなの声を取り入れながら改善のサイクルを10年まわし文化が根付くこれまでの10年

Slide 51

Slide 51 text

51 これらが根付いていき事業をエンジニアリングする急激な変化に適応できるチーム本質を見極め、柔軟に考える小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする文化が根付くこれまでの10年

Slide 52

Slide 52 text

52 CTOとしての10年これまでの10年文化という土台が固まった事業A 事業B 事業C 事業D 暗黙の文化明文化された文化制御不能な技術的負債攻めの開発力言語化

Slide 53

Slide 53 text

攻めに使える開発力を増やすこれまでの10年

Slide 54

Slide 54 text

54 文化という土台が固まり、攻めに使える開発力が増えた CTOとしての10年間の結論これまでの10年事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 暗黙の文化明文化された文化攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力 10年

Slide 55

Slide 55 text

55 CTOとしての10年間の結論これまでの10年攻めに使える開発力を増やす事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済

Slide 56

Slide 56 text

56 影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年 ● 技術的負債を返済する力 ● 開発者がオーナーシップを持てる環境 ● フルサイクル開発者

Slide 57

Slide 57 text

57 影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年 ● 技術的負債を返済する力 ● 開発者がオーナーシップを持てる環境 ● フルサイクル開発者

Slide 58

Slide 58 text

58 VOYAGE GROUPの歴史サイバーエージェントと資本業務提携、連結子会社へ 2001年 ■ 売上高サイバーエージェントからMBO 2012年東証マザーズへ上場 2014年東証一部へ市場変更 2015年 CCIと経営統合 CARTA HOLDINGSヘ 2019年探索期基幹事業に集中事業部制, 多角化推進選択と集中 M&A, 多角化経営統合ネットバブル崩壊ライブドアショックリーマンショック東日本大震災コロナショックアクシブドットコム設立 1999年 ECナビに社名変更 2005年 VOYAGE GROUP に社名変更 2011年攻めに使える開発力を増やすこれまでの10年

Slide 59

Slide 59 text

59 プロダクト運営年数概要大きな出来事 ﬂuct SSP 11年最大級の国産SSP、海外との接続も多い事業が急拡大し負荷対策、オンプレからフルクラウドへ Zucks AdNetwork 10年最初からフルクラウドの広告プラットフォームフルサイクル開発の試行錯誤、 CTO交代 ECナビ 17年 2004年から続く老舗Web サービス計画的な技術的負債の返済、技術スタックの移行神ゲー攻略 7年ゲーム攻略メディア後発の参入から業界トップグループへの急成長、 SSGからSSRへの段階的リプレイスサポーターズ 10年就活支援サービス新卒採用における「毎年ユーザーが入れ替わる」特性を活かしたリプレイスデジコ 9年デジタルギフトサービスのリブランディング攻めに使える開発力を増やすこれまでの10年プロダクトの一部

Slide 60

Slide 60 text

60 みなさんに質問です！質問これまでの10年

Slide 61

Slide 61 text

61 10年以上継続しているサービスを運営したことありますか？質問これまでの10年

Slide 62

Slide 62 text

62 10年以上継続しているサービスを運営したことありますか？技術的負債が溜まりすぎたことありませんか？質問これまでの10年

Slide 63

Slide 63 text

63 プロダクト運営年数概要大きな出来事 ﬂuct SSP 11年最大級の国産SSP、海外との接続も多い事業が急拡大し負荷対策、オンプレからフルクラウドへ Zucks AdNetwork 10年最初からフルクラウドの広告プラットフォームフルサイクル開発の試行錯誤、 CTO交代 ECナビ 17年 2004年から続く老舗Web サービス計画的な技術的負債の返済、技術スタックの移行神ゲー攻略 7年ゲーム攻略メディア後発の参入から業界トップグループへの急成長、 SSGからSSRへの段階的リプレイスサポーターズ 10年就活支援サービス新卒採用における「毎年ユーザーが入れ替わる」特性を活かしたリプレイスデジコ 9年デジタルギフトサービスのリブランディング長く運営していくと技術的負債との付き合い方が重要になるプロダクトのリスト（一部）これまでの10年

Slide 64

Slide 64 text

64 ここからの数スライドは Developers Summit 2021 「エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング/リアーキテクティング /リプレイス」での発表資料からの抜粋やエッセンスをまとめたものです。詳細は https://speakerdeck.com/carta_engineeri ng/ripureisu を参照ください。これまでの10年攻めに使える開発力を増やすこれまでの10年技術的負債の返済

Slide 65

Slide 65 text

65 技術的負債の返済これまでの10年技術的負債とは

Slide 66

Slide 66 text

66 技術的負債を返済するための3つのアプローチ https://speakerdeck.com/carta_engineering/ripureisu?slide=5 技術的負債の返済これまでの10年

Slide 67

Slide 67 text

67 三つの実践例技術的負債の返済これまでの10年

Slide 68

Slide 68 text

68 リファクタリング ● コードを綺麗にするためだけのチケットは作らない ● 機能追加などで既存のコードに手を入れるときに、必要に応じてサブタスクとしてリファクタリングを行う「リファクタリングは日常的に行う」技術的負債の返済これまでの10年既存コード調査チケットアサイン機能追加実装リファクタリング実施リファクタリング必要？全社の共通認識

Slide 69

Slide 69 text

69 ● スキーマをみればどんなデータが入っているのか分かる ● スキーマを前提とした単体テストも書ける旧広告配信設定新広告配信設定リアーキテクティング ● ProtocolBuffersでスキーマを定義 ● 一部の新しいデータの ProtocolBuffers版を提供 ● 徐々に移行していく技術的負債の返済これまでの10年 SSP：広告配信システム全体のうち広告が掲載されるメディア側で利用される仕組みリアーキテクティング ● 広告配信の設定情報をファイル1つ（1GB）で管理 ● 配信サーバのソースコードを読んでもデータの中身が分かりづらい

Slide 70

Slide 70 text

70 葬り & リアーキテクティング技術的負債の返済これまでの10年広告枠 119 A B B 手動自動掲載管理 42 広告本体 3 広告枠 119➞43 A B B 掲載管理 119➞43 広告本体 3➞2 会員数730万人突破のポイントサイト葬り ● 重複を葬り or 集約 ● インターフェース層を設けて、機能間依存性を管理広告枠と掲載管理と広告本体と、重複機能が多数あるリファクタリングリファクタリングリアーキテクティング

Slide 71

Slide 71 text

71 技術的負債の返済これまでの10年卒業年によって違うシステムを提供することで影響範囲を限定した就活生と企業のマッチングを創出するサービスリプレイス

Slide 72

Slide 72 text

72 Developers Summit 2021 「エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング /リアーキテクティング/リプレイス」での発表資料からの抜粋およびエッセンスはここまでです。詳細は https://speakerdeck.com/carta_engineeri ng/ripureisu を参照ください。これまでの10年攻めに使える開発力を増やすこれまでの10年技術的負債の返済

Slide 73

Slide 73 text

73 三つのアプローチを実践した結果技術的負債を返済する力がつきうまく付き合えるようになった技術的負債の返済これまでの10年三つのアプローチとその実践 ● リファクタリング ○ ボトムアップにコードを綺麗にしていく ● リアーキテクティング ○ 大きなシステムをサブシステムに分解し、サブシステム単位で置き換えていく ● リプレイス/リライト ○ ゼロから書き直す

Slide 74

Slide 74 text

74 ● 技術的負債を返済する力 ● 開発者がオーナーシップを持てる環境 ● フルサイクル開発者影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年

Slide 75

Slide 75 text

75 オーナーシップを持てるとは？オーナーシップを持てる環境これまでの10年

Slide 76

Slide 76 text

76 ● 権限が及ばないところに、興味持たんよね ● 改善するぞってなっても、権限の範囲内までしかできない ● そこの権限構造がお願いしないとできないとかなってると、それをお願いすることのコストが勝ってしまって誰も改善しなくなる ● やろうと思えば出来るっていう土壌作ったのは偉大だなって思っているオーナーシップを持てるとは？これまでの10年社内でこのプレゼンの事前練習したときに出てきた言葉（原文ママ）

Slide 77

Slide 77 text

77 オーナーシップを持てる環境づくりインフラの事例オーナーシップを持てる環境これまでの10年

Slide 78

Slide 78 text

78 オンプレメイン（2010年）事業部A 子会社B 子会社C システム本部 Dev Dev Ops Sec インフラエンジニア(Ops) ● データセンター契約 ● 機器調達/セットアップ ● OS、ミドルウェアセットアップ、管理 ● DBMS管理 ● 監視システム構築、運用 ● 機器故障対応 ● サービスアラート1次受け組織構造と役割これまでの10年 Corp Corp Ops 開発者(Dev) ● 企画・要件の確認、すり合わせ ● 設計 ● 開発 ● テスト ● デプロイ ● 不具合調査、対応 Dev Dev Dev Dev

Slide 79

Slide 79 text

79 ● オンプレミスの構成だと、ネットワーク機器などは複数サービスで共有していたため、DevがOpsに相談して、Opsが決めていた ● 事業部や子会社からみて急ぎの作業があっても、DevがOpsに依頼し、 Opsが作業していた ● 障害発生時はOpsが一時切り分けし、必要に応じてDevに連絡していたオンプレメインのとき、どうだったか？これまでの10年開発者(Dev)がインフラのオーナーシップを持てなかった

Slide 80

Slide 80 text

80 AWS 東京リージョンができた（2011年3月） https://aws.amazon.com/jp/about-aws/whats-new/2011/03/02/announcing-asia-pacific-tokyo-region/ この頃から新規サービスは基本的にクラウドを選択するようになっていったクラウド襲来これまでの10年

Slide 81

Slide 81 text

81 事例 - ECナビオンプレミスのデータベースを Amazon RDS for Oracle に移行 https://aws.amazon.com/jp/solutions/case-studies/voyage-group/ クラウド活用これまでの10年

Slide 82

Slide 82 text

82 https://techblog.cartaholdings.co.jp/entry/2017/02/20/140412 クラウド活用これまでの10年事例 - ECナビインフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築

Slide 83

Slide 83 text

83 https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises クラウド活用これまでの10年事例 - ﬂuct

Slide 84

Slide 84 text

84 https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=7 事例 - ﬂuct クラウド活用これまでの10年

Slide 85

Slide 85 text

85 https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=37 事例 - ﬂuct クラウド活用これまでの10年

Slide 86

Slide 86 text

86 https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=15 事例 - ﬂuct クラウド活用これまでの10年開発本部とSRE本部の体制だったが、 SRE本部を発展的解消し、開発本部に統合した

Slide 87

Slide 87 text

87 さまざまな事業部・子会社でクラウド活用した結果クラウド活用これまでの10年

Slide 88

Slide 88 text

88 オンプレメイン（2010年）（再掲）事業部A 子会社B 子会社C システム本部 Dev Dev Ops Sec インフラエンジニア(Ops) ● データセンター契約 ● 機器調達/セットアップ ● OS、ミドルウェアセットアップ、管理 ● DBMS管理 ● 監視システム構築、運用 ● 機器故障対応 ● サービスアラート1次受け組織構造と役割これまでの10年 Corp Corp Ops 開発者(Dev) ● 企画・要件の確認、すり合わせ ● 設計 ● 開発 ● テスト ● デプロイ ● 不具合調査、対応 Dev Dev Dev Dev

Slide 89

Slide 89 text

89 クラウドメイン（2021年）事業部A 子会社B 子会社C システム本部 Dev & Ops Ops Sec インフラエンジニア(Ops) ● エンジニアがいない部署のサポート組織構造と役割これまでの10年 Corp Corp Ops 開発者(Dev&Ops) ● 企画・要件の確認、すり合わせ ● 設計 ● 開発 ● テスト ● デプロイ ● 運用 ● 監視 ● 不具合調査、対応 Dev & Ops Dev & Ops Dev & Ops Dev & Ops Dev & Ops

Slide 90

Slide 90 text

90 開発者(Dev)がインフラのオーナーシップを持てる環境になったオンプレメインからクラウドメインにこれまでの10年事業部A 子会社B 子会社C システム本部 Dev Dev Ops Sec Corp Corp Ops Dev Dev Dev Dev 事業部A 子会社B 子会社C システム本部 Dev & Ops Ops Sec Corp Corp Ops Dev & Ops Dev & Ops Dev & Ops Dev & Ops Dev & Ops

Slide 91

Slide 91 text

91 影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年 ● 技術的負債を返済する力 ● 開発者がオーナーシップを持てる環境 ● フルサイクル開発者

Slide 92

Slide 92 text

92 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 フルサイクル開発者とはこれまでの10年

Slide 93

Slide 93 text

93 https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 “ソフトウェアライフサイクルの目的はtime to valueの最適化、つまり効果的にアイディアを実際のプロダクトやサービスに変換することだ。ソフトウェアサービスを開発し運用することは一連の責任から構成される。” フルサイクル開発者とはこれまでの10年

Slide 94

Slide 94 text

94 https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 “驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。” フルサイクル開発者とはこれまでの10年

Slide 95

Slide 95 text

95 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 フルサイクル開発者とはこれまでの10年これを読んで「VOYAGE GROUPの価値観と、めっちゃ近い！」と思った

Slide 96

Slide 96 text

96 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 フルサイクル開発者とはこれまでの10年 ● チームの成果を最大化できる ○ 仲間と事なす ○ やるべきことに対して、顧客満足と収益のバランスを取り入れながら適切な優先順位を付けることができる ○ 「リリース→フィードバック→改善→リリース→・・・」のようなサイクルに対して全体最適化できる ■ 参考：Full Cycle Developers at NetflixーOperate What You Build 価値観を言語化した資料にもすぐに取り入れた

Slide 97

Slide 97 text

97 https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 フルサイクル開発者とはこれまでの10年社内から有志が集まり Netflixから許可をもらい翻訳したものをBlogに掲載

Slide 98

Slide 98 text

98 ● フルスタックは引き出しの多さ ● フルサイクルは開発のライフサイクルを回す ● なんでもはできない、できることしかできない ● Full Cycle Developer ● 価値を届けることに責任を持つ ● 誰かを待って開発することはしない ● イニシアチブを持ってやっていく ● 何を世の中に届けるか ● 不得手な部分は得意な人とツーリングする ● 一緒にやろう ● 価値を届けるのに必要なことをやっていく https://techblog.cartaholdings.co.jp/entry/engineers-in-zucks ● 役割を分けない ● 何のために作るのか ● 顧客が本当に必要だったもの ● 納得するまでコミュニケーションをとる ● 裁量がある ● 仕事を前に進める力 ● 実現したいことにフォーカスする ● 自分で開発したものを運用する ● 本当にやりたいことはなにか ● フルサイクルはマインドセット VOYAGE/Zucksにおけるフルサイクル開発者とはこれまでの10年

Slide 99

Slide 99 text

99 ● フルスタックは引き出しの多さ ● フルサイクルは開発のライフサイクルを回す ● なんでもはできない、できることしかできない ● Full Cycle Developer ● 価値を届けることに責任を持つ ● 誰かを待って開発することはしない ● イニシアチブを持ってやっていく ● 何を世の中に届けるか ● 不得手な部分は得意な人とツーリングする ● 一緒にやろう ● 価値を届けるのに必要なことをやっていく ● 役割を分けない ● 何のために作るのか ● 顧客が本当に必要だったもの ● 納得するまでコミュニケーションをとる ● 裁量がある ● 仕事を前に進める力 ● 実現したいことにフォーカスする ● 自分で開発したものを運用する ● 本当にやりたいことはなにか ● フルサイクルはマインドセット https://techblog.cartaholdings.co.jp/entry/engineers-in-zucks VOYAGE/Zucksにおけるフルサイクル開発者とはこれまでの10年

Slide 100

Slide 100 text

100 役割を分けず、権限を持つことでフルサイクル開発者が増えているフルサイクル開発者これまでの10年

Slide 101

Slide 101 text

101 攻めに使える開発力を増やすこれまでの10年結果として... ✔ 技術的負債を返済する力 ✔ 開発者がオーナーシップを　持てる環境 ✔ フルサイクル開発者

Slide 102

Slide 102 text

102 CTOとしての10年間の結論これまでの10年攻めに使える開発力を増やす事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済

Slide 103

Slide 103 text

まとめこれまでの10年

Slide 104

Slide 104 text

104 技術力評価会を軸に文化が根付いた事業をエンジニアリングする急激な変化に適応できるチーム本質を見極め、柔軟に考える小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする

Slide 105

Slide 105 text

105 時代に合わせて試行錯誤し、下記ケイパビリティを獲得した ✔ 技術的負債を返済する力 ✔ 開発者がオーナーシップを　持てる環境 ✔ フルサイクル開発者

Slide 106

Slide 106 text

106 文化という土台が固まり、攻めに使える開発力が増えた CTOとしての10年間の結論これまでの10年事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済暗黙の文化明文化された文化言語化

Slide 107

Slide 107 text

すずけんへのメッセージこれからの10年これまでの10年

Slide 108

Slide 108 text

108 新CTOへのメッセージ「文化の土台」と「攻めの開発力」があります。これらが無くなることを考えると怖いと思うけどそれを恐れず大きな意思決定をたくさんしてください。 CTOの仕事は1人で解決できることはほぼありません。困ったら周囲の人を頼ってください。すずけんならいい感じにできると信じてるよ！これからの10年これまでの10年

Slide 109

Slide 109 text

これからの10年新CTO 鈴木健太

Slide 110

Slide 110 text

110 鈴木健太すずけん経歴 2012年〜 VOYAGE GROUP 新卒入社 ﬂuct（子会社）でIC -> EM -> IC -> EM 2019年〜 ﬂuct 取締役CTO 2022年〜 CARTA HD 執行役員CTO どうぞよろしくお願いいたします！自己紹介新CTO (2022-) これからの10年ポッドキャスト「 https://ajito.fm 」 Twitter: @suzu_v

Slide 111

Slide 111 text

111 ここからのセクションは 10年かけて会社のエンジニアリング文化を作り上げてきた初代 CTOからある日、と、言われたという想定でご覧ください。ある日のことこれからの10年来年からCTO よろしくね

Slide 112

Slide 112 text

112 悩んだ 10年実績のある小賀さんから引き継ぐことの重さ次のCTOは、すずけんがいいと思ってるなんかめっちゃ仕事ふえそう果たしてしっかり職務をこなせるのか？経営統合を経たあとのCTOいろいろ大変そうもっとプロダクトづくりに専念したい ﬂuctを伸ばしたいコード書きたい自分がそもそもなぜここで働いているのか？みんなで作ってきた文化を大切にしたい。これからも育てていきたい。なので引き受けることにした。 CTOを打診されたときに考えたことこれからの10年自分はCARTAの「自ら考え、自ら作る」文化が好きだ。

Slide 113

Slide 113 text

113 重ねてきた信頼 ● 入社してから10年間、技術一筋 ● エンジニア陣と数え切れないほどしてきた対話が、そもそも自分は何を武器に使える？これからの10年とにかく事業を伸ばす「攻め」をやってきた。これまでﬂuctで事業を作ってきた経験 ● エンジニアとして、CTOとして、事業とプロダクトを作ってきた攻めの開発力制御可能な技術的負債 ﬂuct

Slide 114

Slide 114 text

114 そもそもCTOは必要か？・・と、CTOを引き継ぐにあたって最初に考えた CTOは必要かこれからの10年

Slide 115

Slide 115 text

115 ● すでに技術力評価会も浸透しており、評価制度も定着し、開発文化もできている。 ● 各々の事業で実現したいことはすでに回っている。 ● 各事業部が自律して意思決定しており、技術者として事業をリードするCTO・エンジニアもいる。 CTOは必要かこれからの10年それ以上にやれることがあるのだろうか？そもそもCARTA HOLDINGSにおけるCTOは必要なのか？

Slide 116

Slide 116 text

116 みなさんが経営者だとして、 CTOに何を求めますか？質問ですこれからの10年

Slide 117

Slide 117 text

117 前提として: 会社がCTOに求めることとは CTOは必要かこれからの10年 ①技術者として経営の意思決定に携わる CTOの意思決定レベルを上げ続ける必要がある。 ②エンジニアリングの力を強化組織成長を持続可能にする必要がある。シンプルにいえば、価値を最大化するには、

Slide 118

Slide 118 text

118 CTOは必要かこれからの10年エンジニア組織の文化形成を引き続き支援しつつ、 CTOの意思決定を継続的に改善するメカニズムをデザインしようと考えた ● すでに技術力評価会も浸透しており、評価制度も定着し、開発文化もできている。 ● 各々の事業で実現したいことはすでに回っている。 ● 各事業部が自律して意思決定しており、技術者として事業をリードする CTO・エンジニアもいる。それ以上にやれることがあるのだろうか？そもそもCARTA HOLDINGSにおけるCTOは必要なのか？

Slide 119

Slide 119 text

CTOの仕組み化を考えるあらゆる場所にフィードバックのメカニズムを導入するこれからの10年

Slide 120

Slide 120 text

120 施策実行結果確認振り返る計画する CTOの意思決定レベルをあげるにはこれからの10年 CTO

Slide 121

Slide 121 text

121 施策実行結果確認振り返る計画する CTOの意思決定レベルをあげるにはこれからの10年子会社 CTO 子会社 CTO CTO 子会社 CTO アドバイザリ Tech Board

Slide 122

Slide 122 text

122 CARTAの各社で事業をつくっている頼もしいCTO・リードエンジニア陣と一緒に、新しいチームをつくった Tech Boardとはこれからの10年子会社 CTO 子会社 CTO CTO 子会社 CTO アドバイザリ Tech Board 各事業子会社のCTO、リードエンジニアを招聘（小賀さんにもアドバイザリに）メンバー「CTOの頭の中」を言語化し、議論し、方針をつくる ● 今後エンジニア組織はこうなっていくべきだ ● 時流をもとにした採用・広報・評価戦略 ● 着想の共有役割

Slide 123

Slide 123 text

123 Tech Boardをつくってどうだったかこれからの10年 ● 他の部署とのやりとりが「CTOに相談しよう」ではなく「Tech Boardに相談しよう」になった。 ○ トラック係数の向上 ● 各事業部内での「観察」がやりやすくなった。 ○ 1500人規模の組織だとむしろ「何が起きているか」を吸い上げることで得られる情報が多い。 ○ 徹底的に考え抜くには情報・ヒアリング・実態把握が必須。よかったポイント現状ホールディングスの経営会議に参加している技術担当執行役員は自分だけ。自分が新しい領域を拓きながら意思をもって周りを巻き込んでいく。

Slide 124

Slide 124 text

124 CTOとして年明けから取り組んだこと ● 経営メンバーとしてワンチームになるためにひたすら話す ● 各事業・各本部の中の人と話をする（弱い紐帯を強く。吸い上げの土壌づくり） ● 組織ビジョン・方針をつくる（CARTA Tech Visionの策定） ● 採用のリブート（エンジニア採用コンセプトの策定） ● CARTA体制として初めての技術力評価会実施 ○ CCIエンジニア陣も含めた評価会の開催 ● ホールディングスとしての来年以降の戦略策定 ○ そもそも経営としてどういうルートで何を目指していくかひたすら人と話し、課題を聞き、議論し、決定を重ねた（小賀さんの言う通り）自分ひとりで完結する問題はほとんどないこれからの10年

Slide 125

Slide 125 text

125 新たにCARTA Tech Visionを策定これからの10年 https://techblog.cartaholdings.co.jp/entry/carta-tech-vision CARTAではエンジニアリングに携わるメンバーが170人程度います。来年、あるいはその次の年にもどんどん新しい人も入ってきます。そのときに「CARTAのエンジニア組織はどこに向かうのか？」「どうなっていきたいのか？」という問いに答えなければならない。何より、自分自身が「こうしていきたい」というものを言語化したいとずっと思っていました。面接の場で、外の場で、そして何より大事なエンジニアのメンバーと話すときに、「こういうエンジニア組織にしていきたい」ということにちゃんと答えたい。そう思っていました。 “

Slide 126

Slide 126 text

126 CARTA Tech Vision

Slide 127

Slide 127 text

127 信頼されなければコトは進まない。 CTOの意思決定に関する信頼性を高める。 ● 「裏でなにかが勝手に決まったな？」を極力減らす ● メンバーを信じているからこそオープンにする「自ら考える」を可能にするために情報は公開議論をただオープンにするだけではなく、受け取りやすくする ● 結果をサマリーにして受け取りやすく ● 「ここを見れば大丈夫なんだ」と安心してもらう ● 今後の方向性を決める過程も含めてみてもらう Tech Board、採用関連、広報関連をはじめ、個人情報を除き議論内容はすべて社内に公開ポリシー: プライベートよりパブリックこれからの10年

Slide 128

Slide 128 text

128 なぜ「信頼性」が大事か？これからの10年小賀さんの時代から、「信頼すること」で文化は始まった。僕自身も小賀さんに信じてもらい、挑戦させてもらった。信頼が挑戦を産み、文化を育てる。文化は信頼を育て、挑戦を産み、また文化を育てていく。「共に信頼し、共に創る」文化信頼挑戦

Slide 129

Slide 129 text

129 CTOを引き継ぐとはこれからの10年 CTO引き継ぎは大変、まだ始まったばかり引き継ぐと小賀さんのすごさがわかった 10年やるのは本当にすごい文化を作ってきてくれて、ありがとうございました！ 🙇

Slide 130

Slide 130 text

これからの10年これまでの10年まとめ

Slide 131

Slide 131 text

131 文化という土台が固まり、攻めに使える開発力が増えた CTOとしての10年間の結論これまでの10年事業A 事業B 事業C 事業D 事業A 事業B 事業C 事業D 事業H 事業I 事業E 事業F 事業G 攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力暗黙の文化明文化された文化増加返済言語化

Slide 132

Slide 132 text

132 事業をエンジニアリングする急激な変化に適応できるチーム本質を見極め、柔軟に考える小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする文化これまでの10年技術力評価会を軸に文化が根付いた

Slide 133

Slide 133 text

133 時代に合わせて試行錯誤し、下記ケイパビリティを獲得した ✔ 技術的負債を返済する力 ✔ 開発者がオーナーシップを　持てる環境 ✔ フルサイクル開発者開発力これまでの10年

Slide 134

Slide 134 text

134 CTOの意思決定レベルをあげていく施策実行結果確認振り返る計画する CTOの仕組み化これからの10年子会社 CTO 子会社 CTO CTO 子会社 CTO アドバイザリ Tech Board

Slide 135

Slide 135 text

135 なぜ「信頼性」が大事か？これからの10年小賀さんの時代から、「信頼すること」で文化は始まった。僕自身も小賀さんに信じてもらい、挑戦させてもらった。信頼が挑戦を産み、文化を育てる。文化は信頼を育て、挑戦を産み、また文化を育てていく。「共に信頼し、共に創る」文化信頼挑戦

Slide 136

Slide 136 text

136 CARTA HOLDINGSのエンジニア組織として、高い実現力をもとに、世の中により多くの進化を共に起こせるよう、取り組んでいきますこれまでの10年とこれからの10年のまとめ小賀さんが10年かけて、文化をもとに開発力を強化してきましたそのバトンをすずけんが受け取り、この文化が持続するよう、体制をつくりました

Slide 137

Slide 137 text

人の想いで、人と未来の可能性を、拓いていく。

Slide 138

Slide 138 text

これまでの10年 AGENDA ex-CTO 小賀昌法これからの10年新CTO 鈴木健太新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化