定量データと定性評価を用いた技術戦略の組織的実践 / Systematic implementation of technology strategies using quantitative data and qualitative evaluation

by Takeshi Kondo

Slide 1

Slide 1 text

#CNDS2024 CloudNative Days Summer 2024 定量データと定性評価を用いた技術戦略の組織的実践 Takeshi Kondo (@chaspy) CloudNative Days Summer 2024

Slide 2

Slide 2 text

#CNDS2024 CloudNative Days Summer 2024 Takeshi Kondo (@chaspy) Director of Engineering StudySapuri K12 at Recruit Co., Ltd. 観葉植物クラフトビールが好き昨日は前夜祭ありがとうございました！ chaspy chaspy_ https://chaspy.me

Slide 3

Slide 3 text

#CNDS2024 CloudNative Days Summer 2024 スタディサプリプロダクトについて国内小中高と海外を担当しています

Slide 4

Slide 4 text

#CNDS2024 CloudNative Days Summer 2024 スタディサプリプロダクトについて国内小中高と海外を担当していますスタディサプリ小1講座リニューアルしました ( スタサプ小1）

Slide 5

Slide 5 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native…?

Slide 6

Slide 6 text

#CNDS2024 CloudNative Days Summer 2024 スタディサプリは Cloud Native 対応組織です ➔ Infra: AWS & EKS / GCP (Pub/Sub, BigQuery) ➔ CI: GitHub Actions & Self-Hosted runner (*) ➔ CD: ArgoCD & 内製の deploy-action ➔ Job: Argo Workflows * GitHub Actions Self-hosted Runner の導入と安定運用に向けた軌跡 - スタディサプリ Product Team Blog

Slide 7

Slide 7 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native とは特定技術を使うことではない ➔ Cloud がもたらす恩恵を最大限活かすことが重要 ◆ オーナーシップに基づいて権限委譲する ◆ それを支えるセルフサービスとガードレール ◆ 依頼(*) による待ち時間を回避し、リードタイムを短縮 ◆ 高速に試行錯誤を繰り返せる * デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog

Slide 8

Slide 8 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native によって開発者が自己完結する世界を目指す ➔ SRE チームのミッション ◆ “自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフォームと文化を作る” ➔ 自己完結: 自分たちで必要なものを自分たちで用意できること ➔ 開発、QA、デプロイ、監視、全て一貫して開発者が行う ◆ 開発者が Kubernetes yaml も Terraform HCL も書くし、Datadog の Dashboard 見て Monitor の設定をする。E2E テストのシナリオも書く。任意のタイミングでデプロイする

Slide 9

Slide 9 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native だからできる”あたりまえ” ➔ Self-Service, On-Demand, Isolated & Scalable ◆ Kubernetes 上 namespace にある個別開発環境(qall-k8s*1) ◆ Pull Request ごとの Preview 環境 ◆ 独立した負荷試験環境 (*2) ◆ 本番データベースを開発環境へ日次でリストア (*3) *1 スタディサプリのWebアプリケーションはこうやって開発されている - スタディサプリ Product Team Blog *2 GitHub Actions Self-hosted Runner と Gatling による負荷試験 - スタディサプリ Product Team Blog *3 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog

Slide 10

Slide 10 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native だからできる”あたりまえ” ➔ Self-Service, On-Demand, Isolated & Scalable ◆ Kubernetes 上 namespace にある個別開発環境(qall-k8s*1) ◆ Pull Request ごとの Preview 環境 ◆ 独立した負荷試験環境 (*2) ◆ 本番データベースを開発環境へ日次でリストア (*3) local の vim や vscode から接続し、開発やテストができる。ブラウザ経由でアクセスもできる。 PR 作成し、deploy ラベルをつけると変更を反映した環境がデプロイされる。ブラウザ経由でアクセスもできる。 *1 スタディサプリのWebアプリケーションはこうやって開発されている - スタディサプリ Product Team Blog *2 GitHub Actions Self-hosted Runner と Gatling による負荷試験 - スタディサプリ Product Team Blog *3 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog

Slide 11

Slide 11 text

#CNDS2024 CloudNative Days Summer 2024 Cloud Native だからできる”あたりまえ” ➔ Self-Service, On-Demand, Isolated & Scalable ◆ Kubernetes 上 namespace にある個別開発環境(qall-k8s*1) ◆ Pull Request ごとの Preview 環境 ◆ 独立した負荷試験環境 (*2) ◆ 本番データベースを開発環境へ日次でリストア (*3) テストシナリオがあるレポジトリで PR を作成するとテストクライアントが立ち上がり、前述の PR 環境に対してテストを実行し、レポートも PR に貼り付けられる個人情報など Sensitive データをマスキングした上で、本番同等のデータで開発が行われる

Slide 12

Slide 12 text

#CNDS2024 CloudNative Days Summer 2024 ”技術戦略”と”組織”の話をします！

Slide 13

Slide 13 text

#CNDS2024 CloudNative Days Summer 2024 本日お伝えしたいこと ➔ ①技術課題(技術的負債)をどのように評価するのか ◆ 定量 / 定性両面で収集・評価する事例を紹介 ➔ ② ①をどのように組織的に（個人に依存しない形で、継続性を持って）実現するのか ◆ 技術戦略グループという兼務組織のアプローチを紹介 ➔ ③計画をどのようにビジネス・プロダクトと連携するのか ◆ Engineering Roadmap を通じて事業計画と整合性をとる試みを紹介

Slide 14

Slide 14 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap ①技術課題(技術的負債)をどのように評価するのか ② ①をどのように組織的に（個人に依存しない形で、継続性を持って）実現するのか ③計画をどのようにビジネス・プロダクトと連携するのか

Slide 15

Slide 15 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap

Slide 16

Slide 16 text

#CNDS2024 CloudNative Days Summer 2024 技術戦略とは何か ➔ 技術を何に投資し、何に投資しないかを決めること ◆ “技術投資”は様々 ● 開発部の正社員/パートナーの人員をどう配置するのか、増やすのか減らすのか、開発案件として何を取り組むのか（技術的負債解消を含む）、クラウド/SaaSの利用方針など

Slide 17

Slide 17 text

#CNDS2024 CloudNative Days Summer 2024 技術戦略とは何か ➔ どのように技術投資を決めるか ◆ 基本的にはビジネス方針にアラインさせる ◆ そもそも開発とビジネスはどのような関係でしょうか

Slide 18

Slide 18 text

#CNDS2024 CloudNative Days Summer 2024 PdM EM パワーパワー P/ L B/ S いろんな要素が開発生産性に影響する作ったソースコードやドキュメントは”資産“になる作った資産で利益を産む開発生産性開発とビジネスの関係開発者プロセス文化ツール

Slide 19

Slide 19 text

#CNDS2024 CloudNative Days Summer 2024 PdM EM パワーパワー P/ L B/ S 開発生産性開発とビジネスの関係開発者プロセス文化ツール開発組織の責任範囲 PdM と協働する

Slide 20

Slide 20 text

Slide 21

Slide 21 text

#CNDS2024 CloudNative Days Summer 2024 資産と負債 ➔ 技術的負債という言葉をご存知でしょうか ◆ ソフトウェア資産と技術的負債はどういう関係でしょうか ◆ 技術的負債はビジネスにどういう影響を与えるのか

Slide 22

Slide 22 text

#CNDS2024 CloudNative Days Summer 2024 パワーパワー P/ L B/ S 開発生産性開発者作ったソースコードやドキュメントは”資産“になる資産と負債

Slide 23

Slide 23 text

#CNDS2024 CloudNative Days Summer 2024 パワー P/ L B/ S 開発生産性開発者技術的負債のややこしポイント① パワー利益を産む ”資産性”の側面生産性を阻害する ”負債性”の側面いわゆる技術的負債マイナスのパワー作ったシステムは資産性と負債性の両方を持つ

Slide 24

Slide 24 text

#CNDS2024 CloudNative Days Summer 2024 パワー P/ L B/ S 開発生産性開発者技術的負債のややこしポイント② パワーマイナスのパワー資産性と負債性はお金で評価できない同じものさしで会話できないので、開発外と共通認識を作るのが非常に難しいだから今”開発生産性”がその代替として HOT である理解

Slide 25

Slide 25 text

#CNDS2024 CloudNative Days Summer 2024 P/ L B/ S 開発生産性開発者技術的負債のややこしポイント③ パワーマイナスのパワービジネス・プロダクト・組織・外部環境で評価値が変動する過去の意思決定も状況が変わると再評価しないといけないパワー

Slide 26

Slide 26 text

#CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしポイントまとめ ➔ ①作ったシステムは資産性と負債性の両方を持つ ➔ ②資産性と負債性はお金で評価できない ➔ ③ビジネス・プロダクト・組織・外部環境で評価値が変動する

Slide 27

Slide 27 text

#CNDS2024 CloudNative Days Summer 2024 技術的負債がビジネスに与える影響 ➔ ①作ったシステムは資産性と負債性の両方を持つ ◆ 負債性（技術的負債）割合が大きいと、開発生産性が低下する ◆ 資産性の部分はあるので、ビジネス価値は産み続けるかもしれない ◆ しかし、修正コストが極大になると、いつか事実上の EOL となる ➔ だから技術的負債をコントロール下におくことが重要 ◆ 技術戦略上も技術的負債をどのように返済していくかが重要

Slide 28

Slide 28 text

#CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしさにどう向き合うか ➔ ①作ったシステムは資産性と負債性の両方を持つ ➔ ②資産性と負債性はお金で評価できない ◆ 開発生産性観点で負債性を評価する必要がある(Part2,3) ➔ ③ビジネス・プロダクト・組織・外部環境で評価値が変動する ◆ 組織として継続的に評価・計画・解決を行う必要がある(Part4) ◆ ビジネス・プロダクトの状況を合わせる必要がある(Part5)

Slide 29

Slide 29 text

Slide 30

Slide 30 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap

Slide 31

Slide 31 text

#CNDS2024 CloudNative Days Summer 2024 技術的負債の定量評価 ➔ 技術的負債度合い = 開発生産性の阻害度合い ➔ 生産性を定量評価するとしても、絶対値に意味はない ➔ 点ではなく線で捉え、変化を見る

Slide 32

Slide 32 text

#CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリース

Slide 33

Slide 33 text

Slide 34

Slide 34 text

#CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 非推奨な関数、書き方etc が存在する場合、生産性を阻害する ◆ 書く時にどちらにすればいいか迷うし、読む時は複数の読み方を知っていなければならない ◆ 非推奨というからには書かない方がいい理由がある ➔ フロントエンドでは enzyme, class component の数を計測

Slide 35

Slide 35 text

#CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 内製の code scanner を開発 ◆ Ruby 製, plugin 形式で scanner(parser) を書けば任意のコードの計測ができる ◆ GitHub Actions で定期実行し、Datadog へ送信

Slide 36

Slide 36 text

#CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 Datadog Dashboard で表示 React の Class Component の数をサービス単位で表示 enzyme というライブラリの利用箇所減っていることが可視化できる！

Slide 37

Slide 37 text

#CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 最初は ABC metrics などの包括的なコードメトリクスを試したが、アクショナブルではなかった ◆ 何かしらの兆候を示しているのは間違いないが... ➔ より身近で、具体的なメトリクスを利用することでアクショナブルになり、改善が進んだ ◆ 開発者が自己完結的に metrics を追加し、改善できている

Slide 38

Slide 38 text

Slide 39

Slide 39 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ CI が遅いと掛け算で生産性への影響する ◆ 1つのジョブが1分遅いと、push の数、PR の数、開発者の数と組織全体のリードタイムが雪だるま式で効いてくる ➔ “CIが遅い”という課題を分解して考える ◆ テスト（そのもの） / ワークフロー: Developer が Owner ◆ GitHub Actions self-hosted runner: SRE が Owner

Slide 40

Slide 40 text

#CNDS2024 CloudNative Days Summer 2024 ➔ “CIが遅い”という課題を分解して考える事例2: CI の結果を分析可能にする GitHub Actions self-hosted runner EKS GitHub Actions (Workflow) Build, Test SRE が Owner 開発者が Owner Build は必要なライブラリをインストールしたイメージを使ったり、apt repository の場所を工夫することで改善可能

Slide 41

Slide 41 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Test / Workflow ◆ ワークフロー、ジョブやステップ単位で分析可能にする ◆ Developer が自己完結で改善できるようにする ◆ junit xml 形式のテスト結果を Datadog Dashboard に集約

Slide 42

Slide 42 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にするテストワークフローの成功率（直近7日間、30日間、90日間）ワークフローの所要時間テストの所要時間最近失敗したテストケースの名前 PowerPack で workflow 指定して誰でも作れるようになっている

Slide 43

Slide 43 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする

Slide 44

Slide 44 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Github Self-Hosted Runner の SLO を定義 ◆ GitHub Actions が問題なく使えている時間の割合 > 99% ◆ Self-hosted runners の OOM 発生率 < 1% ◆ 45秒以内に開始されるジョブの割合 > 60%

Slide 45

Slide 45 text

#CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Github Self-Hosted Runner の SLO / monitor を設定することで、ジョブの実行遅延に気づけるようになった ◆ 素早く異常に気づき、開発者から声が上がる前に対処

Slide 46

Slide 46 text

#CNDS2024 CloudNative Days Summer 2024 補足: 組織やシステムの定量評価 ➔ 技術戦略策定のための Fact 収集術 - スタディサプリ Product Team Blog もご覧ください! 以下を計測しました ➔ いずれもシステムの変化を知る手掛かりになっています ➔ システムの構成要素について ◆ プログラミング言語比率 ◆ マイクロサービスごとのプログラミング言語と LOC ◆ EOL を迎えたソフトウェア数 ➔ システムのパフォーマンスについて ◆ リソース効率性 ➔ 開発組織について ◆ プログラミング言語・領域別技術習熟度 ◆ マイクロサービス別開発活発度

Slide 47

Slide 47 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap

Slide 48

Slide 48 text

#CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリースこれらは典型的な開発フローだが、実際はもっと複雑

Slide 49

Slide 49 text

#CNDS2024 CloudNative Days Summer 2024 定量と定性の合わせ技で開発体験のペインを収集する ➔ 定量での計測はホワイトボックステスト的アプローチ ◆ 開発フローがわかってる前提 ◆ すでに対象が明らかになっているものを計測する ➔ 定性での調査はブラックボックステスト的アプローチ ◆ 開発フローがわからない前提 ◆ 個別のペイン・多様なユースケースを発見できる

Slide 50

Slide 50 text

#CNDS2024 CloudNative Days Summer 2024 定性意見を収集する事例紹介 ➔ ① Slack reacji で表明 ➔ ② フィードバックフォームの設置 ➔ ③ ユーザーインタビュー

Slide 51

Slide 51 text

#CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ “技術的負債投げ込み” reaction で気軽に投げ込み ◆ 課題だな、と思う message に reaction するだけ ◆ 技術課題を管理するグループ(後述)でトリアージされる

Slide 52

Slide 52 text

#CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ 気軽に投げられる代わりにペインは何か深掘りする ◆ 頻度は？毎日？週に一度？年に一度？ ◆ 強度は？めちゃくちゃ大変？大したことない？ ◆ 頻度強度で評価する, 他の課題と相対評価する

Slide 53

Slide 53 text

#CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ 技術課題のうち、開発チームにアサインが必要なものは来期の開発計画に入れる ◆ もちろんすぐ解決できるものはしてしまって良い ◆ 開発計画の中には納期制約があるものもあるため、技術的負債解消案件も合わせて計画する

Slide 54

Slide 54 text

#CNDS2024 CloudNative Days Summer 2024 事例②フィードバックフォーム ➔ google form のリンクを適切な場所に仕込む ◆ 週次リリース担当のリリース体験 ◆ Danger での警告が役に立ったか

Slide 55

Slide 55 text

#CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 一部サービス群は QA を経て週に1度リリースされる ◆ QA 環境のデプロイや、QA での不具合のハンドリング、本番へのデプロイなど典型的なタスクを輪番で回している

Slide 56

Slide 56 text

#CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 質問はシンプルに3つ ◆ 今回の Weekly Release はいかがでしたか？ (5段階) ◆ 今回の Weekly Release でうまくいったことを教えてください ◆ 今回の Weekly Release で困ったことを教えてください

Slide 57

Slide 57 text

#CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 月に一度確認し、改善に繋げている release CI を分析して改善フィードバックを受けて通知を改善

Slide 58

Slide 58 text

#CNDS2024 CloudNative Days Summer 2024 事例②-2 Danger での警告が役に立ったか ➔ 非推奨な書き方や、注意すべき点は Danger で警告 ◆ しかし、役に立たない場合、割れ窓化する ◆ 有益なフィードバックになるようにトリガーの調整など、改善をしていく必要がある

Slide 59

Slide 59 text

#CNDS2024 CloudNative Days Summer 2024 事例②-2 Danger での警告が役に立ったか ➔ 月に一度確認し、改善に繋げている対象ファイルが不適当 Danger 警告ごとに ID をつけ、 google form の pre-filled link を使う警告文章がわかりづらい

Slide 60

Slide 60 text

#CNDS2024 CloudNative Days Summer 2024 事例②フィードバックフォーム - まとめ ➔ いずれもシンプルで単純な施策だが効果は大きい ➔ 答えてもらうために、適切な動線と項目設計が重要 ◆ ペインを感じた瞬間に書けるように動線を仕込む ◆ 質問項目はせいぜい3つぐらいにした方が良い

Slide 61

Slide 61 text

#CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ 開発者にインタビューを行う ◆ コストは最も高いが、リターンも大きい手法 ◆ 定量データでは得られないフィードバックが得られる

Slide 62

Slide 62 text

Slide 63

Slide 63 text

#CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ 目的と期待値調整 -> インタビュー -> 振り返りの流れで行う ➔ インタビュー項目 ◆ 最近(1,2か月くらい)どんなサービスを触っていますか ◆ 新しい変更を入れる時にどんな流れでやっていますですか ◆ よかったと思うことはなんですか ◆ ペインを感じたことはなんですか（頻度と強さも含めて）コンテキストの把握人・チームによって扱うサービス・特性が異なるためローカル開発から PR マージ、リリースまで広く確認ペインだけでなくポジティブなフィードバックも得る

Slide 64

Slide 64 text

#CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ まだ2回目実施し終えたばかりだが、メリットを感じている ➔ 毎回気づきが多い ◆ アプリケーション開発だけじゃなくて Terraform 難しいよね、とか ◆ 外部サービス連携しているサービスは開発環境のデータの取り扱いに課題があるよね、とか ◆ やっぱり CI 遅いと辛いよね、とか

Slide 65

Slide 65 text

#CNDS2024 CloudNative Days Summer 2024 余談: ユーザーインタビューは LLM で捗る ➔ 文字起こし & 対談形式にまとめ & 課題抽出 ◆ GCS に mp4 をアップロードすると whisper に API で文字起こしさせたが保存される仕組みを作った ◆ 起こした文字の編集を gpt-4o に指示する（めっちゃ便利） ◆ AI 活用については別の場所でアウトプット予定です

Slide 66

Slide 66 text

#CNDS2024 CloudNative Days Summer 2024 余談: ユーザーインタビューは LLM で捗るおまけ

Slide 67

Slide 67 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap

Slide 68

Slide 68 text

#CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしさにどう向き合うか ➔ 作ったシステムは資産性と負債性の両方を持つ ➔ 資産性と負債性はお金で評価できない ◆ 開発生産性観点で負債性を評価する必要がある(Part2,3) ➔ ビジネス・プロダクト・組織・外部環境で評価値が変動する ◆ 組織として継続的に評価・計画・解決を行う必要がある(Part4) ◆ ビジネス・プロダクトの状況を合わせる必要がある(Part5)

Slide 69

Slide 69 text

#CNDS2024 CloudNative Days Summer 2024 組織で行うメリット ➔ 集団であることから、個人のモチベーションや欠員によるアウトプットの低下をカバーできる ➔ 仕組みを作ることで継続性と再現性を持てる

Slide 70

Slide 70 text

#CNDS2024 CloudNative Days Summer 2024 スタディサプリにおける技術戦略の歴史 ➔ 2020年当時、1人のリードアーキテクトが意思決定責任を持っていた ◆ 範囲が広すぎた結果、問題の発見や計画が進みづらかった ◆ その経験より、ワーキンググループ(WG)を発足し、ボトムアップアプローチをとった

Slide 71

Slide 71 text

#CNDS2024 CloudNative Days Summer 2024 スタディサプリ技術戦略グループ ◆ 全員兼務、週に一度のミーティングベースで活動 ◆ 横断課題管理 WG ● Part3 で紹介した投げ込まれた技術課題のトリアージの他、どこにも属さない技術議論のファシリテーションを行う ◆ フロントエンド WG ● フロントエンド領域に特化した技術課題の発見・評価・解決 ◆ DevOps WG ● Part 2 & 3 で紹介した定量・定性での技術課題の診断を担当 * スタディサプリ小中高の技術戦略について - スタディサプリ Product Team Blog

Slide 72

Slide 72 text

#CNDS2024 CloudNative Days Summer 2024 組織で実践して3年経過した ➔ 3年継続できたのは組織として行ったからこそ ◆ 実際にサイクルが回り、技術的負債解消が進んでいる ➔ 横断的な技術課題の発見・評価・計画・解決はエンジニアとしてもチャレンジングな機会 ◆ キャリアを提供できる場にもなっている ➔ 組織間のコミュニケーションの場にもなっている ◆ ベストプラクティス・共通の課題を共有し、効率的に解決が行える

Slide 73

Slide 73 text

#CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの利点 ➔ Cloud Native の利点を生かした、オーナーシップとセルフサービスに基づく開発と相性がいい ◆ 技術課題の解決も自己完結で行う ◆ 自分たちで行うからこそ、自分ごととして取り組める

Slide 74

Slide 74 text

#CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの弱点 ➔ 全員兼務なので、解決のスピードは基本的に出ない ➔ 次の1年で実行できる課題しか計画できない ◆ 投げ込まれて評価した課題を“来年”の計画に接続するため ◆ 大きすぎる技術的負債・影響の大きい技術的意思決定についても Engineering Roadmap として中長期計画を立てることで推進する(Part5へ)

Slide 75

Slide 75 text

#CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か定量データの収集と評価定性意見の収集と評価組織的実践とは Engineering Roadmap

Slide 76

Slide 76 text

Slide 77

Slide 77 text

#CNDS2024 CloudNative Days Summer 2024 開発計画はどのように立てられているか ➔ 年に2回、中長期の事業計画を立てる ◆ それに合わせてプロダクト開発案件も計画する ◆ この時、で投げ込まれた技術課題のうち、重要度が高いものも開発案件として計画している ● 一定の割合を技術的負債解消に投資している

Slide 78

Slide 78 text

#CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの弱点をどう補うか ➔ 1年で解消できない、影響の大きい技術的課題が進まない構造にあった ◆ 中長期で計画を立てる ◆ Engineering Roadmap(*) の作成にチャレンジ ● 技術的負債解消だけでなく、Platform もターゲット ● これまで明らかにした様々な定量・定性のデータを根拠に計画する * メルカリEngineering Roadmapの作成とその必要性 | メルカリエンジニアリング

Slide 79

Slide 79 text

#CNDS2024 CloudNative Days Summer 2024 Engineering Roadmap ➔ 技術的負債解消（大規模） ◆ テーマを選定し、プロジェクト的に進める ➔ Platform ◆ Platform ごとに KPI ツリーを作成 ◆ 案件がどの KPI に効くのかを仮説を立てる

Slide 80

Slide 80 text

#CNDS2024 CloudNative Days Summer 2024 Engineering Roadmap ➔ 事業責任者, PdM と合意することで、事業・プロダクトの方向とあっているか確認する ◆ 技術的負債のややこしポイント③: “ビジネス・プロダクト・組織・外部環境で評価値が変動する” のため

Slide 81

Slide 81 text

#CNDS2024 CloudNative Days Summer 2024 まとめ ➔ ①技術課題(技術的負債)をどのように評価するのか ◆ 定量 / 定性両面で収集・評価する事例を紹介しました ➔ ② ①をどのように組織的に（個人に依存しない形で、継続性を持って）実現するのか ◆ 技術戦略グループという兼務組織のアプローチを紹介しました ➔ ③計画をどのようにビジネス・プロダクトと連携するのか ◆ Engineering Roadmap を通じて連携する挑戦を紹介しました

Slide 82

Slide 82 text

#CNDS2024 CloudNative Days Summer 2024 まとめ ➔ スタディサプリ小中高では Cloud Native の恩恵を最大限に活かし、オーナーシップとセルフサービスで開発者が自己完結に開発を高速に行える世界を目指しています ◆ 技術課題の発見・評価・計画も自己完結でできることを目指しています ◆ そのために、発見・評価・計画を組織的に行うとともに、評価のための定量・定性評価手法を多く獲得しています ◆ カバーできない大きい意思決定については中長期で解いていく体制も整えています

Slide 83

Slide 83 text

#CNDS2024 CloudNative Days Summer 2024 Thank you for listening! Takeshi Kondo (@chaspy) Director of Engineering StudySapuri K12 at Recruit Co., Ltd. またどこかで会いましょう良い Cloud Native Days を！ chaspy chaspy_ https://chaspy.me