VOYAGE GROUPは事業会社として1999年から22年間さまざまな事業・サービスを生み出し、成長させてきました。2022年からはVOYAGE GROUPはCARTA HOLDINGSとして新たな挑戦を始めます。 このセッションでは、2010年から10年間CTOを勤めた小賀が2010年代のエンジニア組織と文化をふりかえり、2022年からCTOを務める鈴木が2020年以降の未来を語ります。
Engineers in CARTA2022年からCTO交代！新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化2022年8月4日
View Slide
これまでの10年AGENDAex-CTO 小賀 昌法これからの10年新CTO 鈴木健太新旧CTOが語るこれまでの10年とこれからのエンジニア組織と文化
3CARTA HOLDINGS は 2019年1月VOYAGE GROUP と CCI が経営統合して誕生しました多くの事業・サービスを運営しています（下記は一部を抜粋）
4このセッションでは VOYAGE GROUP での これまでの10年CARTA HOLDINGS での これからの10年 についてお話しますこれからの10年これまでの10年
ex-CTO 小賀 昌法これまでの10年
6 自己紹介 ex-CTO (2010-2021)小賀 昌法Twitter: @makoga経歴2010年7月〜2021年12月 VOYAGE GROUP CTO2020年1月〜2021年12月 CARTA HOLDINGS CTO2022年1月〜 CARTA Tech Boardアドバイザリ好きなこと● 経営や組織をエンジニアリングする● 成長する環境づくりこれまでの10年
7まずは結論からCTOとしての10年間これまでの10年
8文化という土台が固まり、攻めに使える開発力が増えたCTOとしての10年間の結論これまでの10年事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G暗黙の文化 明文化された文化攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力10年
文化が根付くこれまでの10年
10 CTOとしての10年間の結論これまでの10年文化が根付く暗黙の文化 明文化された文化言語化
11“人間の生活様式の全体。人類がみずからの手で築き上げてきた有形・無形の成果の総体。それぞれの民族・地域・社会に固有の文化があり、学習によって伝習されるとともに、相互の交流によって発展してきた。”https://kotobank.jp/word/%E6%96%87%E5%8C%96-128305「文化」とはこれまでの10年
12事業をエンジニアリングする 急激な変化に適応できるチーム本質を見極め、柔軟に考える 小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする根付いた文化とはこれまでの10年
13事業をエンジニアリングする 急激な変化に適応できるチーム本質を見極め、柔軟に考える 小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトするどこから始めたのか？根付いた文化とはこれまでの10年
14みなさんに質問です！質問これまでの10年
152010年 CTO就任時に感じていた課題● 短期的なスピードを重視しすぎている● エンジニアの能力評価に対する納得感が低い● 採用・育成・評価の価値観が統一されていない2010年 CTO就任時に感じていた課題これまでの10年
16● 短期的なスピードを重視しすぎている● エンジニアの能力評価に対する納得感が低い● 採用・育成・評価の価値観が統一されていない同じような課題、見たことありませんか？2010年 CTO就任時に感じていた課題これまでの10年
17● 短期的なスピードを重視しすぎている● エンジニアの能力評価に対する納得感が低い● 採用・育成・評価の価値観が統一されていないなぜこうなってしまうのか？2010年 CTO就任時に感じていた課題これまでの10年
18事業部A 本部B 子会社C原因１：組織構造● 事業部/本部/子会社の責任者は技術に詳しいわけではない● 責任者はシステムの内部構造が見えないので、見えやすい実績を高く評価してしまう原因２：技術の多様化● 技術マネージャは全ての技術においてメンバーより詳しいわけではない● フロントエンド(Web/iOS/Android)、バックエンド、データベース(RDB/KVS)、インフラ(AWS/GCP/オンプレ)、データ分析、セキュリティなど多岐にわたる会社事業責任者・技術マネージャエンジニア技術力評価課題が生まれた原因これまでの10年技術力評価技術力評価
19チームを越えた能力評価制度『技術力評価会』が始まった課題に対する解決策の1つとしてこれまでの10年
20グレード制度 (等級制度)● 職種ごとにグレードが定義されている● 半年に1度の評価タイミングで昇降格が決まる評価制度● 全職種共通○ 半年に1度○ 事業貢献、能力、CREED Competency Feedback の3軸を総合評価● エンジニア職○ 能力評価の仕組みとして技術力評価会がある○ 技術力評価会の評価結果はグレードの昇格に大きく影響する○ 2011年から継続VOYAGE GROUPの人事制度(抜粋)これまでの10年
21事業貢献評価部署A部署B 部署C能力評価 能力評価能力評価能力評価鈴木佐藤村岡山田技術力評価会とはこれまでの10年全社のエンジニアが部署をまたいで相互に能力評価をする仕組み事業貢献と能力の評価を分け、より納得感のある評価ができるようになった。
22評価者は2人● 社外評価者がいるときは 3人事前準備● 被評価者は評価会の 1週間前に資料を提出当日● 1時間30分● 被評価者がプレゼン (約30分)● 評価者との質疑応答 (約60分)後日● 評価者は評価結果を作成● 評価者2人、評価委員、CTOの4人でフィードバック内容をすり合わせ● 被評価者に評価者からフィードバック技術力評価会とはこれまでの10年
23技術力評価会の全体の流れ技術力評価会とはこれまでの10年全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備
24全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備日々の事業活動をBUILDとすると技術力評価会はMEASUREとLEARNにあたる技術力評価会とはこれまでの10年https://marmelab.com/blog/2016/02/12/build-measure-learn.html
25半年で2人、2年で8人から多角的なフィードバックをもらう1回目技術力評価会とはこれまでの10年2回目 3回目 4回目1年目 2年目
26『技術力評価会』はどのような影響があったのか技術力評価会と文化これまでの10年
27 評価軸からみる文化これまでの10年
282011年の評価軸● 事業・サービスの理解度● プロジェクトごとの要件・制約の理解度● 変更容易性● 可用性● 性能● セキュリティ● テスト容易性評価軸からみる文化これまでの10年
292011年の評価軸● 事業・サービスの理解度● プロジェクトごとの要件・制約の理解度● 変更容易性● 可用性● 性能● セキュリティ● テスト容易性言われたものをただ作るのではなく、エンジニアが事業・サービス、要件・制約を理解し、改善案の提案も含めて一緒に作っていくその後「事業をエンジニアリングする」という言葉が見つかる評価軸からみる文化これまでの10年
302011年の評価軸● 事業・サービスの理解度● プロジェクトごとの要件・制約の理解度● 変更容易性● 可用性● 性能● セキュリティ● テスト容易性質とスピードを両立させるために、内部品質に投資する評価軸からみる文化これまでの10年
312013年の評価軸実現力● スコープ定義● システム構築・運用● プロジェクトマネジメント改善力● システム的な改善● ビジネス的な改善2011年の評価軸● 事業・サービスの理解度● プロジェクトごとの要件・制約の理解度● 変更容易性● 可用性● 性能● セキュリティ● テスト容易性2014年の評価軸実現力● 何が課題で何が必要と考えたか。● 構築・運用したシステムは妥当か。● プロジェクトの進め方は妥当か。改善力● システム的な改善は妥当か。● ビジネス的な改善への貢献は妥当か。うまくいっていたとしても、更なる高みを目指し、変えていく評価軸からみる文化これまでの10年
32 「全体ふりかえり」から見る文化これまでの10年全体ふりかえり5, 6人ごとのチームに別れ、今回の技術力評価会についてKeep, Problemを出し、最後にチームごとの重要なトピックを発表する会。ここで出たトピックは、次回の技術力評価会の改善の元ネタとなる。
33技術力評価会の全体の流れ（再掲）技術力評価会とはこれまでの10年全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック全体ふりかえり事前準備
34 「全体ふりかえり」から見る文化これまでの10年全体ふりかえり全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり
35全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり「全体ふりかえり」から見る文化これまでの10年全体ふりかえりはLEARNの1つにあたるhttps://marmelab.com/blog/2016/02/12/build-measure-learn.html
362015年11月に実施した「全体ふりかえり」で実際に出た意見 抜粋その1「全体ふりかえり」から見る文化これまでの10年
372015年11月に実施した「全体ふりかえり」で実際に出た意見 抜粋その1「全体ふりかえり」から見る文化これまでの10年
382015年11月に実施した「全体ふりかえり」で実際に出た意見 抜粋その2「全体ふりかえり」から見る文化これまでの10年
392015年11月に実施した「全体ふりかえり」で実際に出た意見 抜粋その2「全体ふりかえり」から見る文化これまでの10年
40 「全体ふりかえり」から見る文化これまでの10年主体性を持って発言し、ともに学び、制度自体もみんなで改善していく全体準備、ガイダンス全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体ふりかえり
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
42全体ふりかえり技術力評価会を10年運営していくなかで価値観を言語化し、全体ガイダンスで繰り返し伝えていった価値観を言語化これまでの10年全体フィードバック評価会実施評価結果すり合わせ被評価者へのフィードバック事前準備全体準備、ガイダンス
43大方針● 急激な変化にも適応できるチームであり続ける● 事業をエンジニアリングする大切にしたいこと● 本質を見きわめ、柔軟に考える● 小さく挑戦し続け、早く失敗する● 仲間と相互にフィードバックしあい、継続的に成長する価値観を言語化これまでの10年
44その時点で当たり前のことをちゃんとやる。2016年4月時点での例● 適切なバージョン管理● 設計レビュー・コードレビュー● 必要十分なテスト● 1ステップビルド● 1ステップデプロイ● 誰でもロールバック可能● 常に最適なツールを模索● ポータビリティの高いアプリケーション● ディスポーザブルな環境● キャパシティプランニング・事前検証● サービスレベルに応じた監視・運用体制● セキュリティリスク対策● プライバシーバイデザインなど価値観を言語化これまでの10年
45VOYAGE GROUPにおける価値あるエンジニアとは全ての関係者にとって価値あるサービスを継続的に提供できる。チームの成果を最大化できる。職種を問わず多様なクルーからリスペクトされる。仮説が1つしか浮かばないのは危険信号。事業課題を理解し、仮説を立てる。価値観を言語化これまでの10年
46VOYAGE GROUPにおける価値あるエンジニアとは全ての関係者にとって価値あるサービスを継続的に提供できる。● 顧客・ピープル・サービス・事業を理解する。● 制約条件の中で本質を見極める。● サービスやシステムに対して、新たな課題を見つけ、改善策を提示できる。● 改善策に対して、システムを安定運用させながら反映させることができる。● 既知および未知の問題に対して、チームが素早く検知できるようにシステムを設計、構築できる。● 発生した問題に対して、チームの誰もが速やかに安定していた状態に戻せるようにシステムを設計、構築できる。● 発生した問題に対して、迅速に適切に対応できる。価値観を言語化これまでの10年
47VOYAGE GROUPにおける価値あるエンジニアとはチームの成果を最大化できる。● 仲間と事を成す。● やるべきことに対して、顧客満足と収益のバランスを取りながら適切な優先順位を付けることができる。● 「リリース→フィードバック→改善→リリース→・・・」のようなサイクルに対して全体最適化できる。職種を問わず、多様なクルーからリスペクトされる。価値観を言語化これまでの10年
48VOYAGE GROUPにおける価値あるエンジニアとは事業課題を理解し、仮説を立てる。管理画面を使っている人から「検索機能が欲しい」と言われたら、どんな行動をしますか？どんな機能が必要かヒアリングすると考えた人はちょっと気が早いかもしれません。まずは「いま何に困っているのか」「もし検索機能があったとして、検索結果をどのように使いたいのか」を理解するのが重要と思います。もしかすると、使い方によっては既存機能でもいいかもしれませんし、デフォルトのソート順を変えるほうがいいかもしれません。なにか機能が欲しいと言われた時は、課題を理解し、それを解決する仮説を立てましょう。価値観を言語化これまでの10年
49VOYAGE GROUPにおける価値あるエンジニアとは仮説が1つしか浮かばないのは危険信号。課題を理解しました。あなたは良い解決策を思いつきました。これは最高のアイデアなのですぐ実装するぞ！と考えた人はちょっと気が早いかもしれません。まず解決策が思いついても、それはまだ仮説です。本当に効果的かはまだ分かりません。そして仮説が1つしかないときは過去の経験や現状によるバイアスが掛かっているかもしれません。同じような課題を持っている人がいないかググってみたり、他のチームの人に聞いてみましょう。価値観を言語化これまでの10年
50このようにみんなの声を取り入れながら改善のサイクルを10年まわし文化が根付くこれまでの10年
51これらが根付いていき事業をエンジニアリングする 急激な変化に適応できるチーム本質を見極め、柔軟に考える 小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする文化が根付くこれまでの10年
52 CTOとしての10年これまでの10年文化という土台が固まった事業A事業B 事業C 事業D暗黙の文化 明文化された文化制御不能な技術的負債攻めの開発力言語化
攻めに使える開発力を増やすこれまでの10年
54文化という土台が固まり、攻めに使える開発力が増えたCTOとしての10年間の結論これまでの10年事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G暗黙の文化 明文化された文化攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力10年
55 CTOとしての10年間の結論これまでの10年攻めに使える開発力を増やす事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済
56影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年● 技術的負債を返済する力● 開発者がオーナーシップを持てる環境● フルサイクル開発者
57影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年● 技術的負債を返済する力● 開発者がオーナーシップを持てる環境● フルサイクル開発者
58VOYAGE GROUPの歴史サイバーエージェントと資本業務提携、連結子会社へ2001年■ 売上高サイバーエージェントからMBO2012年東証マザーズへ上場2014年東証一部へ市場変更2015年 CCIと経営統合CARTA HOLDINGSヘ2019年探索期 基幹事業に集中 事業部制, 多角化推進 選択と集中 M&A, 多角化 経営統合ネットバブル崩壊ライブドアショックリーマンショック東日本大震災コロナショックアクシブドットコム設立1999年ECナビに社名変更2005年VOYAGE GROUPに社名変更2011年攻めに使える開発力を増やすこれまでの10年
59プロダクト 運営年数 概要 大きな出来事fluct SSP 11年 最大級の国産SSP、海外との接続も多い事業が急拡大し負荷対策、オンプレからフルクラウドへZucks AdNetwork 10年 最初からフルクラウドの広告プラットフォームフルサイクル開発の試行錯誤、CTO交代ECナビ 17年 2004年から続く老舗Webサービス計画的な技術的負債の返済、技術スタックの移行神ゲー攻略 7年 ゲーム攻略メディア後発の参入から業界トップグループへの急成長、SSGからSSRへの段階的リプレイスサポーターズ 10年 就活支援サービス新卒採用における「毎年ユーザーが入れ替わる」特性を活かしたリプレイスデジコ 9年 デジタルギフト サービスのリブランディング攻めに使える開発力を増やすこれまでの10年プロダクトの一部
60みなさんに質問です！質問これまでの10年
6110年以上継続しているサービスを運営したことありますか？質問これまでの10年
6210年以上継続しているサービスを運営したことありますか？技術的負債が溜まりすぎたことありませんか？質問これまでの10年
63プロダクト 運営年数 概要 大きな出来事fluct SSP 11年 最大級の国産SSP、海外との接続も多い事業が急拡大し負荷対策、オンプレからフルクラウドへZucks AdNetwork 10年 最初からフルクラウドの広告プラットフォームフルサイクル開発の試行錯誤、CTO交代ECナビ 17年 2004年から続く老舗Webサービス計画的な技術的負債の返済、技術スタックの移行神ゲー攻略 7年 ゲーム攻略メディア後発の参入から業界トップグループへの急成長、SSGからSSRへの段階的リプレイスサポーターズ 10年 就活支援サービス新卒採用における「毎年ユーザーが入れ替わる」特性を活かしたリプレイスデジコ 9年 デジタルギフト サービスのリブランディング長く運営していくと技術的負債との付き合い方が重要になるプロダクトのリスト（一部）これまでの10年
64ここからの数スライドは DevelopersSummit 2021 「エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング/リアーキテクティング /リプレイス」での発表資料からの抜粋やエッセンスをまとめたものです。詳細はhttps://speakerdeck.com/carta_engineering/ripureisu を参照ください。これまでの10年攻めに使える開発力を増やすこれまでの10年技術的負債の返済
65 技術的負債の返済これまでの10年技術的負債とは
66技術的負債を返済するための3つのアプローチhttps://speakerdeck.com/carta_engineering/ripureisu?slide=5技術的負債の返済これまでの10年
67三つの実践例技術的負債の返済これまでの10年
68リファクタリング● コードを綺麗にするためだけのチケットは作らない● 機能追加などで既存のコードに手を入れるときに、必要に応じてサブタスクとしてリファクタリングを行う「リファクタリングは日常的に行う」技術的負債の返済これまでの10年既存コード調査チケットアサイン機能追加実装リファクタリング実施リファクタリング必要？全社の共通認識
69● スキーマをみればどんなデータが入っているのか分かる● スキーマを前提とした単体テストも書ける旧広告配信設定 新広告配信設定リアーキテクティング● ProtocolBuffersでスキーマを定義● 一部の新しいデータのProtocolBuffers版を提供● 徐々に移行していく技術的負債の返済これまでの10年SSP：広告配信システム全体のうち広告が掲載されるメディア側で利用される仕組みリアーキテクティング● 広告配信の設定情報をファイル1つ（1GB）で管理● 配信サーバのソースコードを読んでもデータの中身が分かりづらい
70葬り & リアーキテクティング技術的負債の返済これまでの10年広告枠119ABB手動自動掲載管理42広告本体3広告枠119➞43ABB掲載管理119➞43広告本体3➞2会員数730万人突破のポイントサイト葬り● 重複を葬り or 集約● インターフェース層を設けて、機能間依存性を管理広告枠と掲載管理と広告本体と、重複機能が多数あるリファクタリングリファクタリングリアーキテクティング
71 技術的負債の返済これまでの10年卒業年によって違うシステムを提供することで影響範囲を限定した就活生と企業のマッチングを創出するサービスリプレイス
72Developers Summit 2021 「エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング /リアーキテクティング/リプレイス」での発表資料からの抜粋およびエッセンスはここまでです。詳細はhttps://speakerdeck.com/carta_engineering/ripureisu を参照ください。これまでの10年攻めに使える開発力を増やすこれまでの10年技術的負債の返済
73三つのアプローチを実践した結果技術的負債を返済する力がつきうまく付き合えるようになった技術的負債の返済これまでの10年三つのアプローチとその実践● リファクタリング○ ボトムアップにコードを綺麗にしていく● リアーキテクティング○ 大きなシステムをサブシステムに分解し、サブシステム単位で置き換えていく● リプレイス/リライト○ ゼロから書き直す
74● 技術的負債を返済する力● 開発者がオーナーシップを持てる環境● フルサイクル開発者影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年
75オーナーシップを持てるとは？オーナーシップを持てる環境これまでの10年
76● 権限が及ばないところに、興味持たんよね● 改善するぞってなっても、権限の範囲内までしかできない● そこの権限構造がお願いしないとできないとかなってると、それをお願いすることのコストが勝ってしまって誰も改善しなくなる● やろうと思えば出来るっていう土壌作ったのは偉大だなって思っているオーナーシップを持てるとは？これまでの10年社内でこのプレゼンの事前練習したときに出てきた言葉（原文ママ）
77オーナーシップを持てる環境づくりインフラの事例オーナーシップを持てる環境これまでの10年
78オンプレメイン（2010年）事業部A 子会社B 子会社Cシステム本部DevDevOpsSecインフラエンジニア(Ops)● データセンター契約● 機器調達/セットアップ● OS、ミドルウェアセットアップ、管理● DBMS管理● 監視システム構築、運用● 機器故障対応● サービスアラート1次受け組織構造と役割これまでの10年CorpCorp Ops開発者(Dev)● 企画・要件の確認、すり合わせ● 設計● 開発● テスト● デプロイ● 不具合調査、対応DevDevDevDev
79● オンプレミスの構成だと、ネットワーク機器などは複数サービスで共有していたため、DevがOpsに相談して、Opsが決めていた● 事業部や子会社からみて急ぎの作業があっても、DevがOpsに依頼し、Opsが作業していた● 障害発生時はOpsが一時切り分けし、必要に応じてDevに連絡していたオンプレメインのとき、どうだったか？これまでの10年開発者(Dev)がインフラのオーナーシップを持てなかった
80AWS 東京リージョンができた（2011年3月）https://aws.amazon.com/jp/about-aws/whats-new/2011/03/02/announcing-asia-pacific-tokyo-region/この頃から新規サービスは基本的にクラウドを選択するようになっていったクラウド襲来これまでの10年
81事例 - ECナビオンプレミスのデータベースを Amazon RDS for Oracle に移行https://aws.amazon.com/jp/solutions/case-studies/voyage-group/クラウド活用これまでの10年
82https://techblog.cartaholdings.co.jp/entry/2017/02/20/140412クラウド活用これまでの10年事例 - ECナビインフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築
83https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premisesクラウド活用これまでの10年事例 - fluct
84https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=7事例 - fluctクラウド活用これまでの10年
85https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=37事例 - fluctクラウド活用これまでの10年
86https://speakerdeck.com/nishigori/fluct-migrate-aws-from-on-premises?slide=15事例 - fluctクラウド活用これまでの10年開発本部とSRE本部の体制だったが、SRE本部を発展的解消し、開発本部に統合した
87さまざまな事業部・子会社でクラウド活用した結果クラウド活用これまでの10年
88オンプレメイン（2010年）（再掲）事業部A 子会社B 子会社Cシステム本部DevDevOpsSecインフラエンジニア(Ops)● データセンター契約● 機器調達/セットアップ● OS、ミドルウェアセットアップ、管理● DBMS管理● 監視システム構築、運用● 機器故障対応● サービスアラート1次受け組織構造と役割これまでの10年CorpCorp Ops開発者(Dev)● 企画・要件の確認、すり合わせ● 設計● 開発● テスト● デプロイ● 不具合調査、対応DevDevDevDev
89クラウドメイン（2021年）事業部A 子会社B 子会社Cシステム本部Dev&OpsOpsSecインフラエンジニア(Ops)● エンジニアがいない部署のサポート組織構造と役割これまでの10年CorpCorp Ops開発者(Dev&Ops)● 企画・要件の確認、すり合わせ● 設計● 開発● テスト● デプロイ● 運用● 監視● 不具合調査、対応Dev&OpsDev&OpsDev&OpsDev&OpsDev&Ops
90開発者(Dev)がインフラのオーナーシップを持てる環境になったオンプレメインからクラウドメインにこれまでの10年事業部A 子会社B 子会社Cシステム本部DevDevOpsSecCorpCorp OpsDevDevDevDev事業部A 子会社B 子会社Cシステム本部Dev&OpsOpsSecCorpCorp OpsDev&OpsDev&OpsDev&OpsDev&OpsDev&Ops
91影響が大きい3つのこと攻めに使える開発力を増やすこれまでの10年● 技術的負債を返済する力● 開発者がオーナーシップを持てる環境● フルサイクル開発者
92https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249フルサイクル開発者とはこれまでの10年
93https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325“ソフトウェアライフサイクルの目的はtime to valueの最適化、つまり効果的にアイディアを実際のプロダクトやサービスに変換することだ。ソフトウェアサービスを開発し運用することは一連の責任から構成される。”フルサイクル開発者とはこれまでの10年
94https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325“驚くべき開発ツールを持ち、設計、開発、テスト、デプロイ、運用、サポートといったフルソフトウェアライフサイクルへの責任を持つ開発チームだ。”フルサイクル開発者とはこれまでの10年
95https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249フルサイクル開発者とはこれまでの10年これを読んで「VOYAGE GROUPの価値観と、めっちゃ近い！」と思った
96https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249フルサイクル開発者とはこれまでの10年● チームの成果を最大化できる○ 仲間と事なす○ やるべきことに対して、顧客満足と収益のバランスを取り入れながら適切な優先順位を付けることができる○ 「リリース→フィードバック→改善→リリース→・・・」のようなサイクルに対して全体最適化できる■ 参考：Full Cycle Developers atNetflixーOperate What YouBuild価値観を言語化した資料にもすぐに取り入れた
97https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249フルサイクル開発者とはこれまでの10年社内から有志が集まりNetflixから許可をもらい翻訳したものをBlogに掲載
98● フルスタックは引き出しの多さ● フルサイクルは開発のライフサイクルを回す● なんでもはできない、できることしかできない● Full Cycle Developer● 価値を届けることに責任を持つ● 誰かを待って開発することはしない● イニシアチブを持ってやっていく● 何を世の中に届けるか● 不得手な部分は得意な人とツーリングする● 一緒にやろう● 価値を届けるのに必要なことをやっていくhttps://techblog.cartaholdings.co.jp/entry/engineers-in-zucks● 役割を分けない● 何のために作るのか● 顧客が本当に必要だったもの● 納得するまでコミュニケーションをとる● 裁量がある● 仕事を前に進める力● 実現したいことにフォーカスする● 自分で開発したものを運用する● 本当にやりたいことはなにか● フルサイクルはマインドセットVOYAGE/Zucksにおけるフルサイクル開発者とはこれまでの10年
99● フルスタックは引き出しの多さ● フルサイクルは開発のライフサイクルを回す● なんでもはできない、できることしかできない● Full Cycle Developer● 価値を届けることに責任を持つ● 誰かを待って開発することはしない● イニシアチブを持ってやっていく● 何を世の中に届けるか● 不得手な部分は得意な人とツーリングする● 一緒にやろう● 価値を届けるのに必要なことをやっていく● 役割を分けない● 何のために作るのか● 顧客が本当に必要だったもの● 納得するまでコミュニケーションをとる● 裁量がある● 仕事を前に進める力● 実現したいことにフォーカスする● 自分で開発したものを運用する● 本当にやりたいことはなにか● フルサイクルはマインドセットhttps://techblog.cartaholdings.co.jp/entry/engineers-in-zucksVOYAGE/Zucksにおけるフルサイクル開発者とはこれまでの10年
100役割を分けず、権限を持つことでフルサイクル開発者が増えているフルサイクル開発者これまでの10年
101 攻めに使える開発力を増やすこれまでの10年結果として...✔ 技術的負債を返済する力✔ 開発者がオーナーシップを 持てる環境✔ フルサイクル開発者
102 CTOとしての10年間の結論これまでの10年攻めに使える開発力を増やす事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済
まとめこれまでの10年
104 技術力評価会を軸に文化が根付いた事業をエンジニアリングする 急激な変化に適応できるチーム本質を見極め、柔軟に考える 小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする
105 時代に合わせて試行錯誤し、下記ケイパビリティを獲得した✔ 技術的負債を返済する力✔ 開発者がオーナーシップを 持てる環境✔ フルサイクル開発者
106文化という土台が固まり、攻めに使える開発力が増えたCTOとしての10年間の結論これまでの10年事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力増加返済暗黙の文化 明文化された文化言語化
すずけんへのメッセージこれからの10年これまでの10年
108新CTOへのメッセージ「文化の土台」と「攻めの開発力」があります。これらが無くなることを考えると怖いと思うけどそれを恐れず大きな意思決定をたくさんしてください。CTOの仕事は1人で解決できることはほぼありません。困ったら周囲の人を頼ってください。すずけん ならいい感じにできると信じてるよ！これからの10年これまでの10年
これからの10年新CTO 鈴木 健太
110鈴木 健太 すずけん経歴2012年〜 VOYAGE GROUP 新卒入社fluct（子会社）でIC -> EM -> IC -> EM2019年〜 fluct 取締役CTO2022年〜 CARTA HD 執行役員CTOどうぞよろしくお願いいたします！自己紹介 新CTO (2022-)これからの10年ポッドキャスト「 https://ajito.fm 」Twitter: @suzu_v
111ここからのセクションは10年かけて会社のエンジニアリング文化を作り上げてきた初代CTOからある日、と、言われたという想定でご覧ください。ある日のことこれからの10年来年からCTOよろしくね
112悩んだ10年実績のある小賀さんから引き継ぐことの重さ次のCTOは、すずけんがいいと思ってるなんかめっちゃ仕事ふえそう果たしてしっかり職務をこなせるのか？経営統合を経たあとのCTOいろいろ大変そうもっとプロダクトづくりに専念したいfluctを伸ばしたいコード書きたい自分がそもそもなぜここで働いているのか？みんなで作ってきた文化を大切にしたい。これからも育てていきたい。 なので引き受けることにした。CTOを打診されたときに考えたことこれからの10年自分はCARTAの「自ら考え、自ら作る」文化が好きだ。
113重ねてきた信頼● 入社してから10年間、技術一筋● エンジニア陣と数え切れないほどしてきた対話が、そもそも自分は何を武器に使える？これからの10年とにかく事業を伸ばす「攻め」をやってきた。これまでfluctで事業を作ってきた経験● エンジニアとして、CTOとして、事業とプロダクトを作ってきた攻めの開発力制御可能な技術的負債fluct
114そもそもCTOは必要か？・・と、CTOを引き継ぐにあたって最初に考えたCTOは必要かこれからの10年
115● すでに技術力評価会も浸透しており、評価制度も定着し、開発文化もできている。● 各々の事業で実現したいことはすでに回っている。● 各事業部が自律して意思決定しており、技術者として事業をリードするCTO・エンジニアもいる。CTOは必要かこれからの10年それ以上にやれることがあるのだろうか？そもそもCARTA HOLDINGSにおけるCTOは必要なのか？
116みなさんが経営者だとして、CTOに何を求めますか？質問ですこれからの10年
117前提として: 会社がCTOに求めることとはCTOは必要かこれからの10年①技術者として経営の意思決定に携わるCTOの意思決定レベルを上げ続ける必要がある。②エンジニアリングの力を強化組織成長を持続可能にする必要がある。シンプルにいえば、 価値を最大化するには、
118 CTOは必要かこれからの10年エンジニア組織の文化形成を引き続き支援しつつ、CTOの意思決定を継続的に改善するメカニズムをデザインしようと考えた● すでに技術力評価会も浸透しており、評価制度も定着し、開発文化もできている。● 各々の事業で実現したいことはすでに回っている。● 各事業部が自律して意思決定しており、技術者として事業をリードするCTO・エンジニアもいる。それ以上にやれることがあるのだろうか？そもそもCARTA HOLDINGSにおけるCTOは必要なのか？
CTOの仕組み化を考えるあらゆる場所にフィードバックのメカニズムを導入するこれからの10年
120施策実行結果確認振り返る計画するCTOの意思決定レベルをあげるにはこれからの10年CTO
121施策実行結果確認振り返る計画するCTOの意思決定レベルをあげるにはこれからの10年子会社CTO子会社CTOCTO 子会社CTOアドバイザリTech Board
122CARTAの各社で事業をつくっている頼もしいCTO・リードエンジニア陣と一緒に、新しいチームをつくったTech Boardとはこれからの10年子会社CTO子会社CTOCTO 子会社CTOアドバイザリTech Board 各事業子会社のCTO、リードエンジニアを招聘（小賀さんにもアドバイザリに）メンバー「CTOの頭の中」を言語化し、議論し、方針をつくる● 今後エンジニア組織はこうなっていくべきだ● 時流をもとにした採用・広報・評価戦略● 着想の共有役割
123 Tech Boardをつくってどうだったかこれからの10年● 他の部署とのやりとりが「CTOに相談しよう」ではなく「Tech Boardに相談しよう」になった。○ トラック係数の向上● 各事業部内での「観察」がやりやすくなった。○ 1500人規模の組織だとむしろ「何が起きているか」を吸い上げることで得られる情報が多い。○ 徹底的に考え抜くには情報・ヒアリング・実態把握が必須。よかったポイント現状ホールディングスの経営会議に参加している技術担当執行役員は自分だけ。自分が新しい領域を拓きながら意思をもって周りを巻き込んでいく。
124 CTOとして年明けから取り組んだこと● 経営メンバーとしてワンチームになるためにひたすら話す● 各事業・各本部の中の人と話をする（弱い紐帯を強く。吸い上げの土壌づくり）● 組織ビジョン・方針をつくる（CARTA Tech Visionの策定）● 採用のリブート（エンジニア採用コンセプトの策定）● CARTA体制として初めての技術力評価会実施○ CCIエンジニア陣も含めた評価会の開催● ホールディングスとしての来年以降の戦略策定○ そもそも経営としてどういうルートで何を目指していくかひたすら人と話し、課題を聞き、議論し、決定を重ねた（小賀さんの言う通り）自分ひとりで完結する問題はほとんどないこれからの10年
125 新たにCARTA Tech Visionを策定これからの10年https://techblog.cartaholdings.co.jp/entry/carta-tech-visionCARTAではエンジニアリングに携わるメンバーが170人程度います。来年、あるいはその次の年にもどんどん新しい人も入ってきます。そのときに「CARTAのエンジニア組織はどこに向かうのか？」「どうなっていきたいのか？」という問いに答えなければならない。何より、自分自身が「こうしていきたい」というものを言語化したいとずっと思っていました。面接の場で、外の場で、そして何より大事なエンジニアのメンバーと話すときに、「こういうエンジニア組織にしていきたい」ということにちゃんと答えたい。そう思っていました。“
126 CARTA Tech Vision
127信頼されなければコトは進まない。CTOの意思決定に関する信頼性を高める。● 「裏でなにかが勝手に決まったな？」を極力減らす● メンバーを信じているからこそオープンにする「自ら考える」を可能にするために情報は公開議論をただオープンにするだけではなく、受け取りやすくする● 結果をサマリーにして受け取りやすく● 「ここを見れば大丈夫なんだ」と安心してもらう● 今後の方向性を決める過程も含めてみてもらうTech Board、採用関連、広報関連をはじめ、個人情報を除き議論内容はすべて社内に公開ポリシー: プライベートよりパブリックこれからの10年
128 なぜ「信頼性」が大事か？これからの10年小賀さんの時代から、「信頼すること」で文化は始まった。僕自身も小賀さんに信じてもらい、挑戦させてもらった。信頼が挑戦を産み、文化を育てる。文化は信頼を育て、挑戦を産み、また文化を育てていく。「共に信頼し、共に創る」文化信頼挑戦
129 CTOを引き継ぐとはこれからの10年CTO引き継ぎは大変、まだ始まったばかり引き継ぐと小賀さんのすごさがわかった10年やるのは本当にすごい文化を作ってきてくれて、ありがとうございました！🙇
これからの10年これまでの10年まとめ
131文化という土台が固まり、攻めに使える開発力が増えたCTOとしての10年間の結論これまでの10年事業A事業B 事業C 事業D事業A事業B 事業C 事業D 事業H 事業I事業E 事業F事業G攻めの開発力制御可能な技術的負債制御不能な技術的負債攻めの開発力暗黙の文化 明文化された文化増加返済言語化
132事業をエンジニアリングする 急激な変化に適応できるチーム本質を見極め、柔軟に考える 小さく挑戦し続け、早く失敗する仲間と相互にフィードバックしあい、継続的に成長するその時点で当たり前のことをちゃんとやるチームの成果を最大化する職種を問わず、リスペクトする文化これまでの10年技術力評価会を軸に文化が根付いた
133時代に合わせて試行錯誤し、下記ケイパビリティを獲得した✔ 技術的負債を返済する力✔ 開発者がオーナーシップを 持てる環境✔ フルサイクル開発者開発力これまでの10年
134CTOの意思決定レベルをあげていく施策実行結果確認振り返る計画するCTOの仕組み化これからの10年子会社CTO子会社CTOCTO 子会社CTOアドバイザリTech Board
135 なぜ「信頼性」が大事か？これからの10年小賀さんの時代から、「信頼すること」で文化は始まった。僕自身も小賀さんに信じてもらい、挑戦させてもらった。信頼が挑戦を産み、文化を育てる。文化は信頼を育て、挑戦を産み、また文化を育てていく。「共に信頼し、共に創る」文化信頼挑戦
136CARTA HOLDINGSのエンジニア組織として、高い実現力をもとに、世の中により多くの進化を共に起こせるよう、取り組んでいきますこれまでの10年 と これからの10年 のまとめ小賀さんが10年かけて、文化をもとに開発力を強化してきましたそのバトンを すずけん が受け取り、この文化が持続するよう、体制をつくりました
人の想いで、人と未来の可能性を、拓いていく。
carta_engineering
kaznishi
sbtechnight
ikuyamada
taketakekaho
sakaitakeshi
sosuiiii
ytsuzaki
sparty
asazutaiga
iwashi86
teckl
ddemaree
sonatard
myddelton
productmarketing
geoffreycrofte
nonsquared
chriscoyier
jakevdp
danielanewman
keithpitt
paulrobertlloyd
skipperchong