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

CNDS2024
https://event.cloudnativedays.jp/cnds2024/

Transcript

1. #CNDS2024 CloudNative Days Summer 2024 定量データと定性評価を用いた技術戦略の 組織的実践 Takeshi Kondo (@chaspy) CloudNative Days Summer 2024
2. #CNDS2024 CloudNative Days Summer 2024 Takeshi Kondo (@chaspy) Director of Engineering StudySapuri K12 at Recruit Co., Ltd. 観葉植物 クラフトビール が好き 昨日は前夜祭ありがとうございました！ chaspy chaspy_ https://chaspy.me
3. #CNDS2024 CloudNative Days Summer 2024 スタディサプリプロダクトについて 国内小中高と 海外を担当しています
4. #CNDS2024 CloudNative Days Summer 2024 スタディサプリプロダクトについて 国内小中高と 海外を担当しています スタディサプリ小1講座 リニューアルしました ( スタサプ 小1）
5. #CNDS2024 CloudNative Days Summer 2024 Cloud Native…?
6. #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
7. #CNDS2024 CloudNative Days Summer 2024 Cloud Native とは特定技術を使うことではない ➔ Cloud がもたらす恩恵を最大限活かすことが重要 ◆ オーナーシップに基づいて権限委譲する ◆ それを支えるセルフサービスとガードレール ◆ 依頼(*) による待ち時間を回避し、リードタイムを短縮 ◆ 高速に試行錯誤を繰り返せる * デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
8. #CNDS2024 CloudNative Days Summer 2024 Cloud Native によって開発者が自己完結する世界を目指す ➔ SRE チームのミッション ◆ “自己完結チームがプロダクトを素早く安全に届け続けるためのプラットフ ォームと文化を作る” ➔ 自己完結: 自分たちで必要なものを自分たちで用意できること ➔ 開発、QA、デプロイ、監視、全て一貫して開発者が行う ◆ 開発者が Kubernetes yaml も Terraform HCL も書くし、Datadog の Dashboard 見て Monitor の設定をする。E2E テストのシナリオも書く。 任意のタイミングでデプロイする
9. #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
10. #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
11. #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 データをマスキングした上で、本番同等のデータで開発が行われる
12. #CNDS2024 CloudNative Days Summer 2024 ”技術戦略”と”組織”の話をします！
13. #CNDS2024 CloudNative Days Summer 2024 本日お伝えしたいこと ➔ ①技術課題(技術的負債)をどのように評価するのか ◆ 定量 / 定性両面で収集・評価する事例を紹介 ➔ ② ①をどのように組織的に（個人に依存しない形で、継続性を持って） 実現するのか ◆ 技術戦略グループという兼務組織のアプローチを紹介 ➔ ③計画をどのようにビジネス・プロダクトと連携するのか ◆ Engineering Roadmap を通じて事業計画と整合性をとる試みを紹介
14. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap ①技術課題(技術的負債)をどの ように評価するのか ② ①をどのように組 織的に（個人に依存 しない形で、継続性 を持って）実現する のか ③計画をどのよ うにビジネス・ プロダクトと連 携するのか
15. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap
16. #CNDS2024 CloudNative Days Summer 2024 技術戦略とは何か ➔ 技術を何に投資し、何に投資しないかを決めること ◆ “技術投資”は様々 • 開発部の正社員/パートナーの人員をどう配置するのか、増やすのか 減らすのか、開発案件として何を取り組むのか（技術的負債解消を含 む）、クラウド/SaaSの利用方針など
17. #CNDS2024 CloudNative Days Summer 2024 技術戦略とは何か ➔ どのように技術投資を決めるか ◆ 基本的にはビジネス方針にアラインさせる ◆ そもそも開発とビジネスはどのような関係でしょうか
18. #CNDS2024 CloudNative Days Summer 2024 PdM EM パワー パワー P/ L B/ S いろんな要素が開発 生産性に影響する 作ったソースコードや ドキュメントは”資産“に なる 作った資産で利益を産む 開発生産性 開発とビジネスの関係 開発者 プロセス 文化 ツール
19. #CNDS2024 CloudNative Days Summer 2024 PdM EM パワー パワー P/ L B/ S 開発生産性 開発とビジネスの関係 開発者 プロセス 文化 ツール 開発組織の責任 範囲 PdM と協働する
20. #CNDS2024 CloudNative Days Summer 2024 PdM EM パワー パワー P/ L B/ S いろんな要素が開発 生産性に影響する 作ったソースコードや ドキュメントは”資産“に なる 作った資産で利益を産む 開発生産性 開発とビジネスの関係 開発者 プロセス 文化 ツール
21. #CNDS2024 CloudNative Days Summer 2024 資産と負債 ➔ 技術的負債という言葉をご存知でしょうか ◆ ソフトウェア資産と技術的負債はどういう関係でしょうか ◆ 技術的負債はビジネスにどういう影響を与えるのか
22. #CNDS2024 CloudNative Days Summer 2024 パワー パワー P/ L B/ S 開発生産性 開発者 作ったソースコードや ドキュメントは”資産“に なる 資産と負債
23. #CNDS2024 CloudNative Days Summer 2024 パワー P/ L B/ S 開発生産性 開発者 技術的負債のややこしポイント① パワー 利益を産む ”資産性”の側面 生産性を阻害する ”負債性”の側面 いわゆる技術的負債 マイナスの パワー 作ったシステムは資産性と負債性の両方を持つ
24. #CNDS2024 CloudNative Days Summer 2024 パワー P/ L B/ S 開発生産性 開発者 技術的負債のややこしポイント② パワー マイナスの パワー 資産性と負債性はお金で評価できない 同じものさしで会話できないので、開発外と 共通認識を作るのが非常に難しい だから今”開発生産性”がその代替として HOT である理解
25. #CNDS2024 CloudNative Days Summer 2024 P/ L B/ S 開発生産性 開発者 技術的負債のややこしポイント③ パワー マイナスの パワー ビジネス・プロダクト・組織・外部環境で評価値が変動する 過去の意思決定も状況が変わると再 評価しないといけない パワー
26. #CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしポイントまとめ ➔ ①作ったシステムは資産性と負債性の両方を持つ ➔ ②資産性と負債性はお金で評価できない ➔ ③ビジネス・プロダクト・組織・外部環境で評価値 が変動する
27. #CNDS2024 CloudNative Days Summer 2024 技術的負債がビジネスに与える影響 ➔ ①作ったシステムは資産性と負債性の両方を持つ ◆ 負債性（技術的負債）割合が大きいと、開発生産性が低下する ◆ 資産性の部分はあるので、ビジネス価値は産み続けるかもしれない ◆ しかし、修正コストが極大になると、いつか事実上の EOL となる ➔ だから技術的負債をコントロール下におくことが重要 ◆ 技術戦略上も技術的負債をどのように返済していくかが重要
28. #CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしさにどう向き合うか ➔ ①作ったシステムは資産性と負債性の両方を持つ ➔ ②資産性と負債性はお金で評価できない ◆ 開発生産性観点で負債性を評価する必要がある(Part2,3) ➔ ③ビジネス・プロダクト・組織・外部環境で評価値が変動する ◆ 組織として継続的に評価・計画・解決を行う必要がある(Part4) ◆ ビジネス・プロダクトの状況を合わせる必要がある(Part5)
29. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap ①技術課題(技術的負債)をどの ように評価するのか ② ①をどのように組 織的に（個人に依存 しない形で、継続性 を持って）実現する のか ③計画をどのよ うにビジネス・ プロダクトと連 携するのか
30. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap
31. #CNDS2024 CloudNative Days Summer 2024 技術的負債の定量評価 ➔ 技術的負債度合い = 開発生産性の阻害度合い ➔ 生産性を定量評価するとしても、絶対値に意味はない ➔ 点ではなく線で捉え、変化を見る
32. #CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリース
33. #CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリース
34. #CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 非推奨な関数、書き方etc が存在する場合、生産性を 阻害する ◆ 書く時にどちらにすればいいか迷うし、読む時は複数の読 み方を知っていなければならない ◆ 非推奨というからには書かない方がいい理由がある ➔ フロントエンドでは enzyme, class component の 数を計測
35. #CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 内製の code scanner を開発 ◆ Ruby 製, plugin 形式で scanner(parser) を書けば任意の コードの計測ができる ◆ GitHub Actions で定期実行し、Datadog へ送信
36. #CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 Datadog Dashboard で表示 React の Class Component の数をサービス単位で表示 enzyme というライブラリの利用箇所 減っていることが可視化できる！
37. #CNDS2024 CloudNative Days Summer 2024 事例1: 非推奨な書かれ方をしているコードの計測 ➔ 最初は ABC metrics などの包括的なコードメトリク スを試したが、アクショナブルではなかった ◆ 何かしらの兆候を示しているのは間違いないが... ➔ より身近で、具体的なメトリクスを利用することで アクショナブルになり、改善が進んだ ◆ 開発者が自己完結的に metrics を追加し、改善できている
38. #CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリース
39. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ CI が遅いと掛け算で生産性への影響する ◆ 1つのジョブが1分遅いと、push の数、PR の数、開発者の 数と組織全体のリードタイムが雪だるま式で効いてくる ➔ “CIが遅い”という課題を分解して考える ◆ テスト（そのもの） / ワークフロー: Developer が Owner ◆ GitHub Actions self-hosted runner: SRE が Owner
40. #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 の場所 を工夫することで改善可能
41. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Test / Workflow ◆ ワークフロー、ジョブやステップ単位で分析可能にする ◆ Developer が自己完結で改善できるようにする ◆ junit xml 形式のテスト結果を Datadog Dashboard に集約
42. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする テストワークフローの成功率 （直近7日間、30日間、90日間 ） ワークフローの所要時間 テストの所要時間 最近失敗したテストケースの名前 PowerPack で workflow 指定し て誰でも作れるようになっている
43. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする
44. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Github Self-Hosted Runner の SLO を定義 ◆ GitHub Actions が問題なく使えている時間の割合 > 99% ◆ Self-hosted runners の OOM 発生率 < 1% ◆ 45秒以内に開始されるジョブの割合 > 60%
45. #CNDS2024 CloudNative Days Summer 2024 事例2: CI の結果を分析可能にする ➔ Github Self-Hosted Runner の SLO / monitor を 設定することで、ジョブの実行遅延に気づけるよう になった ◆ 素早く異常に気づき、開発者から声が上がる前に対処
46. #CNDS2024 CloudNative Days Summer 2024 補足: 組織やシステムの定量評価 ➔ 技術戦略策定のための Fact 収集術 - スタディサプリ Product Team Blog もご覧ください! 以下を計測しました ➔ いずれもシステムの変化を知る手掛かりになっています ➔ システムの構成要素について ◆ プログラミング言語比率 ◆ マイクロサービスごとのプログラ ミング言語と LOC ◆ EOL を迎えたソフトウェア数 ➔ システムのパフォーマンスについて ◆ リソース効率性 ➔ 開発組織について ◆ プログラミング言語・領域別技術習熟度 ◆ マイクロサービス別開発活発度
47. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap
48. #CNDS2024 CloudNative Days Summer 2024 開発体験を分解する ➔ 開発のバリューストリームから考える ◆ コードリーディング、ローカルでのコーディング、テスト ◆ Pull Request 作成、CI ◆ デプロイ、リリース これらは典型的な開発フローだが、 実際はもっと複雑
49. #CNDS2024 CloudNative Days Summer 2024 定量と定性の合わせ技で開発体験のペインを収集する ➔ 定量での計測はホワイトボックステスト的アプローチ ◆ 開発フローがわかってる前提 ◆ すでに対象が明らかになっているものを計測する ➔ 定性での調査はブラックボックステスト的アプローチ ◆ 開発フローがわからない前提 ◆ 個別のペイン・多様なユースケースを発見できる
50. #CNDS2024 CloudNative Days Summer 2024 定性意見を収集する事例紹介 ➔ ① Slack reacji で表明 ➔ ② フィードバックフォームの設置 ➔ ③ ユーザーインタビュー
51. #CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ “技術的負債投げ込み” reaction で気軽に投げ込み ◆ 課題だな、と思う message に reaction するだけ ◆ 技術課題を管理するグループ(後述)でトリアージされる
52. #CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ 気軽に投げられる代わりにペインは何か深掘りする ◆ 頻度は？毎日？週に一度？年に一度？ ◆ 強度は？めちゃくちゃ大変？大したことない？ ◆ 頻度 強度で評価する, 他の課題と相対評価する
53. #CNDS2024 CloudNative Days Summer 2024 事例① Slack reacji で表明 ➔ 技術課題のうち、開発チームにアサインが必要なも のは来期の開発計画に入れる ◆ もちろんすぐ解決できるものはしてしまって良い ◆ 開発計画の中には納期制約があるものもあるため、技術的 負債解消案件も合わせて計画する
54. #CNDS2024 CloudNative Days Summer 2024 事例②フィードバックフォーム ➔ google form のリンクを適切な場所に仕込む ◆ 週次リリース担当のリリース体験 ◆ Danger での警告が役に立ったか
55. #CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 一部サービス群は QA を経て週に1度リリースされる ◆ QA 環境のデプロイや、QA での不具合のハンドリング、本番 へのデプロイなど典型的なタスクを輪番で回している
56. #CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 質問はシンプルに3つ ◆ 今回の Weekly Release はいかがでしたか？ (5段階) ◆ 今回の Weekly Release でうまくいったことを教えてください ◆ 今回の Weekly Release で困ったことを教えてください
57. #CNDS2024 CloudNative Days Summer 2024 事例②-1 週次リリース担当のリリース体験 ➔ 月に一度確認し、改善に繋げている release CI を 分析して改善 フィードバック を受けて通知を 改善
58. #CNDS2024 CloudNative Days Summer 2024 事例②-2 Danger での警告が役に立ったか ➔ 非推奨な書き方や、注意すべき点は Danger で警告 ◆ しかし、役に立たない場合、割れ窓化する ◆ 有益なフィードバックになるようにトリガーの調整など、 改善をしていく必要がある
59. #CNDS2024 CloudNative Days Summer 2024 事例②-2 Danger での警告が役に立ったか ➔ 月に一度確認し、改善に繋げている 対象ファイルが 不適当 Danger 警告ごと に ID をつけ、 google form の pre-filled link を 使う 警告文章がわか りづらい
60. #CNDS2024 CloudNative Days Summer 2024 事例②フィードバックフォーム - まとめ ➔ いずれもシンプルで単純な施策だが効果は大きい ➔ 答えてもらうために、適切な動線と項目設計が重要 ◆ ペインを感じた瞬間に書けるように動線を仕込む ◆ 質問項目はせいぜい3つぐらいにした方が良い
61. #CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ 開発者にインタビューを行う ◆ コストは最も高いが、リターンも大きい手法 ◆ 定量データでは得られないフィードバックが得られる
62. #CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ 目的と期待値調整 -> インタビュー -> 振り返りの流れで行う ➔ インタビュー項目 ◆ 最近(1,2か月くらい)どんなサービスを触っていますか ◆ 新しい変更を入れる時にどんな流れでやっていますですか ◆ よかったと思うことはなんですか ◆ ペインを感じたことはなんですか（頻度と強さも含めて）
63. #CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ 目的と期待値調整 -> インタビュー -> 振り返りの流れで行う ➔ インタビュー項目 ◆ 最近(1,2か月くらい)どんなサービスを触っていますか ◆ 新しい変更を入れる時にどんな流れでやっていますですか ◆ よかったと思うことはなんですか ◆ ペインを感じたことはなんですか（頻度と強さも含めて） コンテキストの把握 人・チームによって扱うサービス・特性が異なるため ローカル開発から PR マージ、リリースまで 広く確認 ペインだけでなくポジ ティブなフィードバッ クも得る
64. #CNDS2024 CloudNative Days Summer 2024 事例③ ユーザーインタビュー ➔ まだ2回目実施し終えたばかりだが、メリットを感じている ➔ 毎回気づきが多い ◆ アプリケーション開発だけじゃなくて Terraform 難しいよね、とか ◆ 外部サービス連携しているサービスは開発環境のデータの取り扱いに課題 があるよね、とか ◆ やっぱり CI 遅いと辛いよね、とか
65. #CNDS2024 CloudNative Days Summer 2024 余談: ユーザーインタビューは LLM で捗る ➔ 文字起こし & 対談形式にまとめ & 課題抽出 ◆ GCS に mp4 をアップロードすると whisper に API で文字 起こしさせたが保存される仕組みを作った ◆ 起こした文字の編集を gpt-4o に指示する（めっちゃ便利） ◆ AI 活用については別の場所でアウトプット予定です
66. #CNDS2024 CloudNative Days Summer 2024 余談: ユーザーインタビューは LLM で捗る おまけ
67. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap
68. #CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしさにどう向き合うか ➔ 作ったシステムは資産性と負債性の両方を持つ ➔ 資産性と負債性はお金で評価できない ◆ 開発生産性観点で負債性を評価する必要がある(Part2,3) ➔ ビジネス・プロダクト・組織・外部環境で評価値が変動する ◆ 組織として継続的に評価・計画・解決を行う必要がある(Part4) ◆ ビジネス・プロダクトの状況を合わせる必要がある(Part5)
69. #CNDS2024 CloudNative Days Summer 2024 組織で行うメリット ➔ 集団であることから、個人のモチベーションや欠員 によるアウトプットの低下をカバーできる ➔ 仕組みを作ることで継続性と再現性を持てる
70. #CNDS2024 CloudNative Days Summer 2024 スタディサプリにおける技術戦略の歴史 ➔ 2020年当時、1人のリードアーキテクトが意思決定 責任を持っていた ◆ 範囲が広すぎた結果、問題の発見や計画が進みづらかった ◆ その経験より、ワーキンググループ(WG)を発足し、ボトム アップアプローチをとった
71. #CNDS2024 CloudNative Days Summer 2024 スタディサプリ技術戦略グループ ◆ 全員兼務、週に一度のミーティングベースで活動 ◆ 横断課題管理 WG • Part3 で紹介した投げ込まれた技術課題のトリアージの他、どこにも 属さない技術議論のファシリテーションを行う ◆ フロントエンド WG • フロントエンド領域に特化した技術課題の発見・評価・解決 ◆ DevOps WG • Part 2 & 3 で紹介した定量・定性での技術課題の診断を担当 * スタディサプリ小中高の技術戦略について - スタディサプリ Product Team Blog
72. #CNDS2024 CloudNative Days Summer 2024 組織で実践して3年経過した ➔ 3年継続できたのは組織として行ったからこそ ◆ 実際にサイクルが回り、技術的負債解消が進んでいる ➔ 横断的な技術課題の発見・評価・計画・解決はエンジニアとし てもチャレンジングな機会 ◆ キャリアを提供できる場にもなっている ➔ 組織間のコミュニケーションの場にもなっている ◆ ベストプラクティス・共通の課題を共有し、効率的に解決が行える
73. #CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの利点 ➔ Cloud Native の利点を生かした、オーナーシップと セルフサービスに基づく開発と相性がいい ◆ 技術課題の解決も自己完結で行う ◆ 自分たちで行うからこそ、自分ごととして取り組める
74. #CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの弱点 ➔ 全員兼務なので、解決のスピードは基本的に出ない ➔ 次の1年で実行できる課題しか計画できない ◆ 投げ込まれて評価した課題を“来年”の計画に接続するため ◆ 大きすぎる技術的負債・影響の大きい技術的意思決定につ いても Engineering Roadmap として中長期計画を立てる ことで推進する(Part5へ)
75. #CNDS2024 CloudNative Days Summer 2024 Agenda | 01 02 03 04 05 前提: 技術戦略とは何か 定量データの収集と評価 定性意見の収集と評価 組織的実践とは Engineering Roadmap
76. #CNDS2024 CloudNative Days Summer 2024 技術的負債のややこしさにどう向き合うか ➔ 作ったシステムは資産性と負債性の両方を持つ ➔ 資産性と負債性はお金で評価できない ◆ 開発生産性観点で負債性を評価する必要がある(Part2,3) ➔ ビジネス・プロダクト・組織・外部環境で評価値が変動する ◆ 組織として継続的に評価・計画・解決を行う必要がある(Part4) ◆ ビジネス・プロダクトの状況を合わせる必要がある(Part5)
77. #CNDS2024 CloudNative Days Summer 2024 開発計画はどのように立てられているか ➔ 年に2回、中長期の事業計画を立てる ◆ それに合わせてプロダクト開発案件も計画する ◆ この時、 で投げ込まれた技術課題のうち、重要度が高 いものも開発案件として計画している • 一定の割合を技術的負債解消に投資している
78. #CNDS2024 CloudNative Days Summer 2024 ボトムアップアプローチの弱点をどう補うか ➔ 1年で解消できない、影響の大きい技術的課題が進ま ない構造にあった ◆ 中長期で計画を立てる ◆ Engineering Roadmap(*) の作成にチャレンジ • 技術的負債解消だけでなく、Platform もターゲット • これまで明らかにした様々な定量・定性のデータを根拠に計画する * メルカリEngineering Roadmapの作成とその必要性 | メルカリエンジニアリング
79. #CNDS2024 CloudNative Days Summer 2024 Engineering Roadmap ➔ 技術的負債解消（大規模） ◆ テーマを選定し、プロジェクト的に進める ➔ Platform ◆ Platform ごとに KPI ツリーを作成 ◆ 案件がどの KPI に効くのかを仮説を立てる
80. #CNDS2024 CloudNative Days Summer 2024 Engineering Roadmap ➔ 事業責任者, PdM と合意することで、事業・プロダ クトの方向とあっているか確認する ◆ 技術的負債のややこしポイント③: “ビジネス・プロダクト ・組織・外部環境で評価値が変動する” のため
81. #CNDS2024 CloudNative Days Summer 2024 まとめ ➔ ①技術課題(技術的負債)をどのように評価するのか ◆ 定量 / 定性両面で収集・評価する事例を紹介しました ➔ ② ①をどのように組織的に（個人に依存しない形で、継続性を持って） 実現するのか ◆ 技術戦略グループという兼務組織のアプローチを紹介しました ➔ ③計画をどのようにビジネス・プロダクトと連携するのか ◆ Engineering Roadmap を通じて連携する挑戦を紹介しました
82. #CNDS2024 CloudNative Days Summer 2024 まとめ ➔ スタディサプリ小中高では Cloud Native の恩恵を最大限に活 かし、オーナーシップとセルフサービスで開発者が自己完結に 開発を高速に行える世界を目指しています ◆ 技術課題の発見・評価・計画も自己完結でできることを目指しています ◆ そのために、発見・評価・計画を組織的に行うとともに、評価のための定 量・定性評価手法を多く獲得しています ◆ カバーできない大きい意思決定については中長期で解いていく体制も整え ています
83. #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