Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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/

CARTA Engineering

February 18, 2022
Tweet

More Decks by CARTA Engineering

Other Decks in Technology

Transcript

  1. 3 CARTA HOLDINGS は 2019年1月 VOYAGE GROUP と CCI が経営統合して誕生しました

    多くの事業・サービスを運営しています(下記は一部を抜粋)
  2. 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年
  3. 8 事業C 技術的負 債 事業B 制御不能 な 技術的負 債 事業A

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

    制御不能 な 技術的負 債 事業A 制御不能な 技術的負債 攻めの開発力
  5. 18 事業部A 本部B 子会社C 原因1:組織構造 • 事業部/本部/子会社の責任者は技術に詳し いわけではない • 責任者はシステムの内部構造が見えないの

    で、見えやすい実績を高く評価してしまう 原因2:技術の多様化 • 技術マネージャは全ての技術においてメン バーより詳しいわけではない • フロントエンド(Web/iOS/Android)、バックエ ンド、データベース(RDB/KVS)、インフラ (AWS/GCP/オンプレ)、データ分析、セキュリ ティなど多岐にわたる 会社 事業責任者・ 技術マネージャ エンジニア 技術力 評価 課題が生まれた原因 これまでの10年 技術力 評価 技術力 評価
  6. 20 グレード制度 (等級制度) • 職種ごとにグレードが定義されている • 半年に1度の評価タイミングで昇降格が決まる 評価制度 • 全職種共通

    ◦ 半年に1度 ◦ 事業貢献、能力、CREED Competency Feedback の3軸を総合評価 • エンジニア職 ◦ 能力評価の仕組みとして技術力評価会がある ◦ 技術力評価会の評価結果はグレードの昇格に大きく影響する ◦ 2011年から継続 VOYAGE GROUPの人事制度(抜粋) これまでの10年
  7. 21 事業貢献評価 部署A 部署B 部署C 能力評価 能 力 評 価

    能 力 評 価 能力 評価 鈴木 佐藤 村岡 山田 技術力評価会とは これまでの10年 全社のエンジニアが部署を またいで相互に能力評価を する仕組み 事業貢献と能力の評価を分 け、より納得感のある評価が できるようになった。
  8. 22 評価者は2人 • 社外評価者がいるときは 3人 事前準備 • 被評価者は評価会の 1週間前に資料を提出 当日

    • 1時間30分 • 被評価者がプレゼン (約30分) • 評価者との質疑応答 (約60分) 後日 • 評価者は評価結果を作成 • 評価者2人、評価委員、CTOの4人でフィード バック内容をすり合わせ • 被評価者に評価者からフィードバック 技術力評価会とは これまでの10年
  9. 23 技術力評価会の全体の流れ 技術力評価会とは これまでの10年 全体準備、 ガイダンス 全体 フィードバック 評価会 実施

    評価結果 すり合わせ 被評価者への フィードバック 全体 ふりかえり 事前 準備
  10. 24 全体準備、 ガイダンス 全体 フィードバック 評価会 実施 評価結果 すり合わせ 被評価者への

    フィードバック 全体 ふりかえり 事前 準備 日々の事業活動をBUILDとすると 技術力評価会はMEASUREとLEARNにあたる 技術力評価会とは これまでの10年 https://marmelab.com/blog/2016/02/12/build-measure-learn.html
  11. 28 2011年の評価軸 • 事業・サービスの理解度 • プロジェクトごとの要件・制約の理解度 • 変更容易性 • 可用性

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

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

    • 性能 • セキュリティ • テスト容易性 質とスピードを両立させるために、内部品質に投資する 評価軸からみる文化 これまでの10年
  14. 31 2013年の評価軸 実現力 • スコープ定義 • システム構築・運用 • プロジェクトマネジメント 改善力

    • システム的な改善 • ビジネス的な改善 2011年の評価軸 • 事業・サービスの理解度 • プロジェクトごとの要件・制約 の理解度 • 変更容易性 • 可用性 • 性能 • セキュリティ • テスト容易性 2014年の評価軸 実現力 • 何が課題で何が必要と考えたか。 • 構築・運用したシステムは妥当か。 • プロジェクトの進め方は妥当か。 改善力 • システム的な改善は妥当か。 • ビジネス的な改善への貢献は妥当か。 うまくいっていたとしても、更なる高みを目指し、変えていく 評価軸からみる文化 これまでの10年
  15. 35 全体準備、 ガイダンス 全体 フィードバック 評価会 実施 評価結果 すり合わせ 被評価者への

    フィードバック 事前 準備 全体 ふりかえり 「全体ふりかえり」から見る文化 これまでの10年 全体ふりかえりはLEARNの1つにあたる https://marmelab.com/blog/2016/02/12/build-measure-learn.html
  16. 43 大方針 • 急激な変化にも適応できるチームであり続ける • 事業をエンジニアリングする 大切にしたいこと • 本質を見きわめ、柔軟に考える •

    小さく挑戦し続け、早く失敗する • 仲間と相互にフィードバックしあい、継続的に成長する 価値観を言語化 これまでの10年
  17. 44 その時点で当たり前のことをちゃんとやる。 2016年4月時点での例 • 適切なバージョン管理 • 設計レビュー・コードレビュー • 必要十分なテスト •

    1ステップビルド • 1ステップデプロイ • 誰でもロールバック可能 • 常に最適なツールを模索 • ポータビリティの高いアプリケーション • ディスポーザブルな環境 • キャパシティプランニング・事前検証 • サービスレベルに応じた監視・運用体制 • セキュリティリスク対策 • プライバシーバイデザイン など 価値観を言語化 これまでの10年
  18. 45 VOYAGE GROUPにおける価値あるエンジニアとは 全ての関係者 にとって価値あ るサービスを継 続的に提供で きる。 チームの成果 を最大化

    できる。 職種を問わず 多様なクルー からリスペクト される。 仮説が1つし か浮かばない のは 危険信号。 事業課題を理 解し、仮説を 立てる。 価値観を言語化 これまでの10年
  19. 46 VOYAGE GROUPにおける価値あるエンジニアとは 全ての関係者にとって価値あるサービスを継続的に提供できる。 • 顧客・ピープル・サービス・事業を理解する。 • 制約条件の中で本質を見極める。 • サービスやシステムに対して、新たな課題を見つけ、改善策を提示できる。

    • 改善策に対して、システムを安定運用させながら反映させることができる。 • 既知および未知の問題に対して、チームが素早く検知できるようにシステムを設計、構築で きる。 • 発生した問題に対して、チームの誰もが速やかに安定していた状態に戻せるようにシステム を設計、構築できる。 • 発生した問題に対して、迅速に適切に対応できる。 価値観を言語化 これまでの10年
  20. 47 VOYAGE GROUPにおける価値あるエンジニアとは チームの成果を最大化できる。 • 仲間と事を成す。 • やるべきことに対して、顧客満足と収益のバランスを取りながら適切な優先順位を付けるこ とができる。 •

    「リリース→フィードバック→改善→リリース→・・・」のようなサイクルに対して全体最適化で きる。 職種を問わず、多様なクルーからリスペクトされる。 価値観を言語化 これまでの10年
  21. 52 CTOとしての10年 これまでの10年 文化という土台が固まった 文化 明文化された文化 言語化 事業C 技術的負 債

    事業B 制御不能 な 技術的負 債 事業A 制御不能な 技術的負債 攻めの開発力
  22. 54 事業C 技術的負 債 事業B 制御不能 な 技術的負 債 事業A

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

    制御不能な 技術的負債 攻めの開発力 事業F めの開発力 制御可能な 技術的負債 事業E 制御可能な 技術的負債 事業D 攻めの開発力 制御可能な 技術的負債 事業C 制御可能な 技術的負債 事業B 制御可能な 技術的負債 事業A 攻めの開発力 制御可能な 技術的負債 CTOとしての10年間の結論 これまでの10年 攻めに使える開発力を増やす
  24. 58 VOYAGE GROUPの歴史 サイバーエージェントと 資本業務提携、連結子会社へ 2001年 ▪ 売上高 サイバーエージェントか らMBO

    2012年 東証マザーズ へ上場 2014年 東証一部へ 市場変更 2015年 CCIと経営統合 CARTA HOLDINGSヘ 2019年 探索期 基幹事業に集中 事業部制, 多角化推進 選択と集中 M&A, 多角化 経営統合 ネットバブル 崩壊 ライブドア ショック リーマン ショック 東日本 大震災 コロナ ショック アクシブドットコム設立 1999年 ECナビに社名変更 2005年 VOYAGE GROUP に社名変更 2011年 攻めに使える開発力を増やす これまでの10年
  25. 59 プロダクト 運営年数 概要 大きな出来事 fluct SSP 11年 最大級の国産SSP、海外との 接続も多い

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

    事業が急拡大し負荷対策、オンプレからフルクラウ ドへ Zucks AdNetwork 10年 最初からフルクラウドの広告 プラットフォーム フルサイクル開発の試行錯誤、 CTO交代 ECナビ 17年 2004年から続く老舗Web サービス 計画的な技術的負債の返済、技術スタックの移行 神ゲー攻略 7年 ゲーム攻略メディア 後発の参入から業界トップグループへの急成長、 SSGからSSRへの段階的リプレイス サポーターズ 10年 就活支援サービス 新卒採用における「毎年ユーザーが入れ替わる」 特性を活かしたリプレイス デジコ 9年 デジタルギフト サービスのリブランディング 長く運営していくと 技術的負債との付き合い方が 重要になる プロダクトのリスト(一部) これまでの10年
  27. 64 ここからの数スライドは Developers Summit 2021 「エンジニアリングで負債を 返済するための勘所 ― 事業特性にあわせ たリファクタリング/リアーキテクティング

    /リ プレイス」での発表資料からの抜粋やエッ センスをまとめたものです。 詳細は https://speakerdeck.com/carta_engineeri ng/ripureisu を参照ください。 これまでの10年攻めに使える開発力を増やす これまでの10年 技術的負債の返済
  28. 69 • スキーマをみればどんな データが入っているのか分 かる • スキーマを前提とした単体 テストも書ける 旧広告配信設定 新広告配信設定

    リアーキテクティング • ProtocolBuffersでスキー マを定義 • 一部の新しいデータの ProtocolBuffers版を提供 • 徐々に移行していく 技術的負債の返済 これまでの10年 SSP:広告配信システム全 体のうち広告が掲載される メディア側で利用される仕 組み リアーキテクティング • 広告配信の設定情報をファ イル1つ(1GB)で管理 • 配信サーバのソースコード を読んでもデータの中身が 分かりづらい
  29. 70 葬り & リアーキテクティング 技術的負債の返済 これまでの10年 広告枠 119 A B

    B 手動 自動 掲載管理 42 広告本体 3 広告枠 119➞43 A B B 掲載管理 119➞43 広告本体 3➞2 会員数730万人突破のポイ ントサイト 葬 り • 重複を葬り or 集約 • インターフェース層を設けて、機能間依存 性を管理 広告枠と掲載管理と広告本体と、重 複機能が多数ある リファクタリング リファクタリング リアーキテクティング
  30. 72 Developers Summit 2021 「エンジニアリン グで負債を返済するための勘所 ― 事業特 性にあわせたリファクタリング /リアーキテ

    クティング/リプレイス」での発表資料から の抜粋およびエッセンスはここまでです。 詳細は https://speakerdeck.com/carta_engineeri ng/ripureisu を参照ください。 これまでの10年攻めに使える開発力を増やす これまでの10年 技術的負債の返済
  31. 73 三つのアプローチを実践した結果 技術的負債を返済する力がつき うまく付き合えるようになった 技術的負債の返済 これまでの10年 三つのアプローチとその実践 • リファクタリング ◦

    ボトムアップにコードを綺麗にしていく • リアーキテクティング ◦ 大きなシステムをサブシステムに分 解し、サブシステム単位で置き換えて いく • リプレイス/リライト ◦ ゼロから書き直す
  32. 78 オンプレメイン(2010年) 事業部A 子会社B 子会社C システム本部 Dev Dev Ops Sec

    インフラエンジニア(Ops) • データセンター契約 • 機器調達/セットアップ • OS、ミドルウェアセットアップ、管理 • DBMS管理 • 監視システム構築、運用 • 機器故障対応 • サービスアラート1次受け 組織構造と役割 これまでの10年 Corp Corp Ops 開発者(Dev) • 企画・要件の確認、すり合わせ • 設計 • 開発 • テスト • デプロイ • 不具合調査、対応 Dev Dev Dev Dev
  33. 81 事例 - ECナビ オンプレミスのデータベースを Amazon RDS for Oracle に移行

    https://aws.amazon.com/jp/solutions/case-studies/voyage-group/ クラウド活用 これまでの10年
  34. 88 オンプレメイン(2010年)(再掲) 事業部A 子会社B 子会社C システム本部 Dev Dev Ops Sec

    インフラエンジニア(Ops) • データセンター契約 • 機器調達/セットアップ • OS、ミドルウェアセットアップ、管理 • DBMS管理 • 監視システム構築、運用 • 機器故障対応 • サービスアラート1次受け 組織構造と役割 これまでの10年 Corp Corp Ops 開発者(Dev) • 企画・要件の確認、すり合わせ • 設計 • 開発 • テスト • デプロイ • 不具合調査、対応 Dev Dev Dev Dev
  35. 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
  36. 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
  37. 96 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 フルサイクル開発者とは これまでの10年 • チームの成果を最大化できる ◦ 仲間と事なす ◦ やるべきことに対して、顧客満足と収益の

    バランスを取り入れながら適切な優先順 位を付けることができる ◦ 「リリース→フィードバック→改善→リリー ス→・・・」のようなサイクルに対して全体最 適化できる ▪ 参考:Full Cycle Developers at NetflixーOperate What You Build 価値観を言語化した資料にもす ぐに取り入れた
  38. 98 • フルスタックは引き出しの多さ • フルサイクルは開発のライフサイクルを回す • なんでもはできない、できることしかできない • Full Cycle

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

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

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

    制御不能な 技術的負債 攻めの開発力 文化という土台が固まり、攻めに使える開発力が増えた 事業F めの開発力 制御可能な 技術的負債 事業E 制御可能な 技術的負債 事業D 攻めの開発力 制御可能な 技術的負債 事業C 制御可能な 技術的負債 事業B 制御可能な 技術的負債 事業A 攻めの開発力 制御可能な 技術的負債 文化 明文化された文化 CTOとしての10年間の結論 これまでの10年 返済 増加 言語化
  42. 110 鈴木 健太 a.k.a. すずけん Twitter: @suzu_v 経歴 2012年〜 VOYAGE

    GROUP 新卒入社 2019年〜 VOYAGE GROUP/fluct CTO 2022年〜 CARTA HD CTO 得意 • バックエンド • データエンジニアリング • ウェブ広告関連 どうぞよろしくお願いいたします! 自己紹介 新CTO (2022-) これからの10年
  43. 112 悩んだ 10年実績のある小賀さんから 引き継ぐことの重さ 次のCTOは、すずけんが いいと思ってる なんかめっちゃ仕 事ふえそう 果たして しっかり職務をこ

    なせるのか? 経営統合を経たあ とのCTOいろいろ大 変そう もっと プロダクトづくりに 専念したい fluctを 伸ばしたい コード 書きたい 自分がそもそも なぜここで働いているのか? みんなで作ってきた文化を大切にしたい。 これからも育てていきたい。 なので引き受けることにした。 CTOを打診されたときに考えたこと これからの10年 自分はCARTAの「自ら考え、自ら作る」 文化が好きだ。
  44. 113 重ねてきた信頼 • 入社してから10年間、技術一筋 • エンジニア陣と数え切れないほどしてきた対話 が、そもそも自分は何を武器に使える? これからの10年 とにかく事業を伸ばす「攻め」をやってきた。 fluct

    攻めの開発力 制御可能な 技術的負債 これまでfluctで事業を作ってきた経験 • エンジニアとして、CTOとして、事業とプロダクトを作って きた
  45. 119 再掲 負債を返済し、制御可能にし、攻めに使える開発力が増えた 事業C 技術的負 債 事業B 制御不能 な 技術的負

    債 事業A 制御不能な 技術的負債 攻めの開発力 事業F めの開発力 制御可能な 技術的負債 事業E 制御可能な 技術的負債 事業D 攻めの開発力 制御可能な 技術的負債 事業C 制御可能な 技術的負債 事業B 制御可能な 技術的負債 事業A 攻めの開発力 制御可能な 技術的負債 文化 明文化された文化 返済 増加
  46. 121 文化は積み上げ。信頼を重ね、共感し、仲間を増やすことで深まる。 開発文化を支えてきたもの これからの10年 • 「共有された暗黙の仮定」 (※『企業文化』E.H. シャイン より)である。 •

    形成されるために経験の共有と蓄積が必要。これからより一層深まっていく。 文化は表層的なものではなく、深くにあるものだと理解すること 考えへの共感を広げること • 自ら考え、チームを第一に、スピーディーに動き、失敗を称賛し、改善を続けるチームでありつづけるた めに • これらの価値観が技術力評価会、普段の各チームでの開発、雑談、勉強会等を通じ、新たなメンバーに も定着していく。 • チームメンバーも、社内のメンバーも。謙虚に接し、相手の考えを尊重し、信じること。 • 価値観が広がり、伸び伸びと各人の才能が最大限発揮できるように。 お互いに個々を信じること
  47. 127 CARTAの各社で事業をつくっている 頼もしいCTO・リードエンジニア陣と一緒に、新しいチームをつくった Tech Boardとは これからの10年 子会社 CTO 子会社 CTO

    CTO 子会社 CTO アドバイ ザリ Tech Board 各事業子会社のCTO、リードエンジニアを招聘 (小賀さんにもアドバイザリに) メンバー 「CTOの頭の中」を言語化し、議論し、方針をつくる • 今後エンジニア組織はこうなっていくべきだ • 時流をもとにした採用・広報・評価戦略 • 着想の共有 役割
  48. 128 CTOの意思決定に関する信頼性を高める • 「裏でなにかが勝手に決まったな?」を極力減らす • メンバーを信じているからこそオープンにする 「自ら考える」を可能にするために情報は公開 議論をただオープンにするだけではなく、受け取りやすくする • 結果をサマリーにして受け取りやすく

    • 「ここを見れば大丈夫なんだ」と安心してもらう • 今後の方向性を決める過程も含めてみてもらう Tech Board、採用関連、広報関連をはじめ、個人情報を除き議論内 容 はすべて社内に公開 ポリシー: プライベートよりパブリック これからの10年
  49. 132 文化という土台が固まり、攻めに使える開発力が増えた CTOとしての10年間の結論 これまでの10年 事業C 技術的負 債 事業B 制御不能 な

    技術的負 債 事業A 制御不能な 技術的負債 攻めの開発力 事業F めの開発力 制御可能な 技術的負債 事業E 制御可能な 技術的負債 事業D 攻めの開発力 制御可能な 技術的負債 事業C 制御可能な 技術的負債 事業B 制御可能な 技術的負債 事業A 攻めの開発力 制御可能な 技術的負債 文化 明文化された文化 返済 増加 言語化