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

VOYAGE GROUPは事業会社として1999年から22年間さまざまな事業・サービスを生み出し、成長させてきました。2022年からはVOYAGE GROUPはCARTA HOLDINGSとして新たな挑戦を始めます。
このセッションでは、2010年から10年間CTOを勤めた小賀が2010年代のエンジニア組織と文化をふりかえり、2022年からCTOを務める鈴木が2020年以降の未来を語ります。

Developers Summit 2022
https://event.shoeisha.jp/devsumi/20220217/session/3692/

Transcript

1. Developers Summit 2022
   2022年からCTO交代！
   新旧CTOが語るこれまでの10年と
   これからのエンジニア組織と文化
   2022年2月18日 18-A-16
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

6. 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年
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. 10
    文化 明文化された文化
    CTOとしての10年間の結論
    これまでの10年
    文化が根付く
    事業C
    技術的負
    債
    事業B
    制御不能
    な
    技術的負
    債
    事業A
    制御不能な
    技術的負債
    攻めの開発力
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

41. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

89. 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
    

    View Slide

90. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

     View Slide

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

     View Slide

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

     View Slide

103. まとめ
     これまでの10年
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

110. 110
     鈴木 健太 a.k.a. すずけん
     Twitter: @suzu_v
     経歴
     2012年〜 VOYAGE GROUP 新卒入社
     2019年〜 VOYAGE GROUP/fluct CTO
     2022年〜 CARTA HD CTO
     得意
     ● バックエンド
     ● データエンジニアリング
     ● ウェブ広告関連
     どうぞよろしくお願いいたします！
     自己紹介 新CTO (2022-)
     これからの10年
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

119. 119 再掲
     負債を返済し、制御可能にし、攻めに使える開発力が増えた
     事業C
     技術的負
     債
     事業B
     制御不能
     な
     技術的負
     債
     事業A
     制御不能な
     技術的負債
     攻めの開発力
     事業F
     めの開発力
     制御可能な
     技術的負債
     事業E
     制御可能な
     技術的負債
     事業D
     攻めの開発力
     制御可能な
     技術的負債
     事業C
     制御可能な
     技術的負債
     事業B
     制御可能な
     技術的負債
     事業A
     攻めの開発力
     制御可能な
     技術的負債
     文化 明文化された文化
     返済
     増加
     

     View Slide

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

     View Slide

121. 121
     文化は積み上げ。信頼を重ね、共感し、仲間を増やすことで深まる。
     開発文化を支えてきたもの
     これからの10年
     ● 「共有された暗黙の仮定」
     （※『企業文化』E.H. シャイン より）である。
     ● 形成されるために経験の共有と蓄積が必要。これからより一層深まっていく。
     文化は表層的なものではなく、深くにあるものだと理解すること
     考えへの共感を広げること
     ● 自ら考え、チームを第一に、スピーディーに動き、失敗を称賛し、改善を続けるチームでありつづけるた
     めに
     ● これらの価値観が技術力評価会、普段の各チームでの開発、雑談、勉強会等を通じ、新たなメンバーに
     も定着していく。
     ● チームメンバーも、社内のメンバーも。謙虚に接し、相手の考えを尊重し、信じること。
     ● 価値観が広がり、伸び伸びと各人の才能が最大限発揮できるように。
     お互いに個々を信じること
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

137. 私たちは「進化」を生み出す。
     変わろうとするすべての組織に。
     知ってもらえずにいる商品たちに。
     力を眠らせたままのあらゆる産業に。
     よくする、だけでは足りない。
     次のステージへのジャンプを起こす。
     つながりえなかったものをつなぎ、
     停滞していたものを動かす。
     そんな進化を、あらゆる場所につくっていく。
     そのためには、「多様な力」が必要だ。
     違う才能がぶつかりあい、
     自分だけでは想像もできなかった方法に
     辿りつく必要がある。
     だから私たちは、意志を持って、様々な人間が共存す
     る。
     挑もうとする人と進化を起こすために。
     私たちは進化推進業、
     CARTA HOLDINGSです。
     

     View Slide

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

     View Slide

139. View Slide