ソフトウェア品質を数字で捉える技術。事業成長を支えるシステム品質の マネジメント

Transcript

1. 2025/07/03　開発生産性カンファレンス2025 ソフトウェア品質を数字で捉える技術。 事業成長を支えるシステム品質の マネジメント Takuya Onda
2. 登壇者情報 
 恩田 拓也
 (おんだ たくや) 
 経歴
 入社
 役割
 ※写真を挿入※ エンジニアリング本部 
 プラットフォーム エンジニアリング部 
 部長
 2023年6月
 新卒でゲームプラットフォーム事業を展開するIT企業に入社後、バッ クエンドエンジニアとしキャリアをスタート。 
 マッチングアプリを制作・運営する企業に転職後はインフラ・SRE領域 を担当。SRE、情シス、セキュリティ部門の技術統括を経て2023年6月 にタイミーに入社。
 現在はプラットフォームエンジニアリング部のエンジニアリングマネー ジャーを務めています。

3. 目次 • タイミーの紹介 • 開発生産性の捉え方 • 開発生産性への取り組み(具体) • まとめ
4. タイミーの紹介
5. Copyright © Timee All Rights Reserved 5 タイミーとは 

6. Copyright © Timee All Rights Reserved 6 タイミーの特徴 

7. Copyright © Timee All Rights Reserved 7 導入実績 

8. タイミーの組織・システム
9. タイミーの開発組織 チームトポロジーでいうところの複数の Stream Aligned Team + Platform Teamで構成 (参考 - 去年の弊社VPoE発表資料：実践チームトポロジー： プラットフォーム性とイネイブリング性の戦略)
10. 10 Engineering Manager 10 タイミーの標準的なストリームアラインドチーム Tribeの内部にバリューストリームによってさらに分割された Squadが内包されている。
11. 11 Engineering Manager 11 タイミーの標準的なストリームアラインドチーム
12. タイミーの開発組織
13. タイミーの生産性への取り組み 考え方編
14. 前置き：プロダクト主導型組織 x 戦略的意図の話 出典：https://engineering.linecorp.com/ja/blog/quality-advocator-shift-left-shift-right
15. 15 戦略的意図と生産性の関係性 プロダクト主導型組織において狭義のプロダクト戦略とは、マーケティングとイノベーションに対し て戦略的意図（顧客ニーズに応える新しいプロダクトやサービスをどう生み出し、どう市場に届ける か）を策定することを指す。この戦略的意図を実現するための具体的なアクションプランがプロダク トイニシアチブと呼ばれます (少なくともタイミー社内においては) 戦略的意図とプロダクトイニシアチブ 
 プロダクトイニシアチブは、戦略的意図を実現するための具体的なアクションプランです。この実行に は、人的資源や物的資源への投資が不可欠です。リソースを最適に運用し、人的・物的資源の投資効率を 高めることがプロダクト戦略の成功を左右します。 資金を投下した人的資源と物的資源に対する投資効率生産性は「運営の仕事」として戦略を支えるリソー ス管理の役割を果たし、プロダクト戦略の実行を下支えする、という関係性。また、最終的には実現付加 価値の生産性という形で売上という形に変換されます プロダクトイニシアチブの実行効率 

16. 16 タイミーの開発生産性への取り組み / 考え方 開発生産性はプロダクトイニシアチブの実行効率に深く関わり、組織の競争力を左右します。プロダ クト開発を効率的に進めることで、限られたリソースで最大の成果を得ることが可能になる プロダクトイニシアチブの実行効率としての開発生産性 
 出典：https://note.com/ka0c0104/n/n578b157b69f5
17. 17 タイミーの開発生産性への取り組み / 考え方 • プロダクト開発組織がプロダクトイニシアチブを爆速でデリバリーできる状態を維持する。 • プロダクトのあたりまえ品質をユーザーへ提供する。 目指す状態 
 • 試行回数を増やす事でPMFを速やかに実現 or 撤退を決められる組織になりたいから • 技術負債解消の遅延コストを最小化させたいから • システム品質と開発生産性は相互作用する関係だと考えるから なぜ目指すのか？ 

18. システムの品質とは何か？ システムの品質とは，システムが様々な利害関係者の明示的ニーズ及び暗 黙のニーズを満足している度合いであり，それによって価値を提供する。 これらの明示的ニーズ及び暗黙のニーズは，製品品質を特性に分類分けす る品質モデルによって表現されている。また、システムの，品質に関係す る測定可能な特徴とそれに伴う品質測定量とを品質特徴と呼ぶ タイミーユーザ目線のあたりまえ品質とは、タイミーのエンドユーザで あるワーカ・クライアント双方の明示的ニーズ及び暗黙のニーズを満足 している状態であり、もしギャップがあるのであれば、それを解消する ことが価値の提供であると考える。 出典：https://kikakurui.com/x2/X25010-2013-01.html
19. 品質特徴一覧 出典：https://kikakurui.com/x2/X25010-2013-01.html
20. 品質の受益者 品質特性毎に、品質の受益者は異なる。 
 • 保守性(モジュール性、再利用性、解析性、修正性、試験性)の恩恵を受けるのは社内開発者であり、 1次利用者は直接恩恵を受けない。 • 機能適合性や使用性、信頼性やセキュリティなどの恩恵を受けるのが1次使用者 (ユーザ) である。
21. 21 開発生産性とシステム品質の関係 • 内部品質への向き合い ◦ モジュール性,再利用性,解析性,修正性,試験性 • 信頼性エンジニアリングのプラクティスの整備 ◦ CICD / 高品質なテスト基盤 / リリースエンジニアリング / o11y / IaC /etc • システムコストが下がれば投資余力を生み出せる ◦ キャパシティプランニング上の財務的余力 / ツールやシステム、人への投資 • バグ / 脆弱性の早期発見は修正コストを下げる ◦ いわゆるShift Leftなメソドロジー システム品質を上げる取り組みはデリバリーを加速させる 

22. 22 開発生産性/システム品質を数字で見る事の意味 • パフォーマンス指標 = 4KeysやSRE PracticeにおけるSLIなど。 • 重要な課題の仮説立てと検証、改善の活動を続ける仕組みと文化が大事。数字は結果指標 • 数値化されたソフトウェア品質/開発生産性をエンジニア個人やチームの業績評価指標に用いない パフォーマンス指標と正の相関のあるケイパ/プラクティスに目を向ける 
 参考：https://dora.dev/research (DORA’s Research Program)
23. 23 プロダクト/組織が大きくなると何が起こるか • 事業拡大>投資拡大 / 様々なステークホルダーニーズ / プロダクトと組織の安定運用へのニーズ • 会社/プロダクトが必要とする専門性の深度に応じた専門性カットのチームが立ち上がる。 専門性による組織細分化と分業化 
 • 安定運用が期待されるOps(QAやSecurityなども含) と納期コミットが期待されるDevの構図が典型例 • リリースのフェーズゲート化 (リリース前判定会議/特定組織によるレビュー必須化) • 意思決定のデリゲーションレベル低下 (エライ人同士で優先度決めてくれないと動けない) • 説明コストの増加 (技術負債？なんで今対応するの？) チーム間で注力するパフォーマンス指標が直交し始める = サイロ化の始まり 

24. 24 パフォーマンス指標の直交に抗う • 発生自体はある程度やむを得ない。それを正しく認識する事と、それが負債となりうるならば いつ解消するか、解消するまでの期間のリスクとその増大はどの程度か、という認知が大事。 • ソフトウェア品質への向き合い方を社内分業でない形で取り組む事 / 開発生産性とトレードオフと しない事を目的としたプラットフォームエンジニアリング サイロ化は組織間がそれぞれ重視するパフォーマンス指標の直交で起きる 

25. 25 タイミーのプラットフォームエンジニアリングチーム 開発生産性も含めたソフトウェア品質全体をプロダクト開発にまつわる組 織全体の関心事と扱えるよう組織的な目標設計および意志決定力学に積極 的に介入する。 その上で、生産性とソフトウェア品質のアカウンタビリティを発揮しつ つ、これらを改善する / Stream Aligned Teamが自律的に改善する武器を 提供する。
26. 26 [余談] アウトカムなのか / アウトプットなのか 4keysが良好である事は、期待付加価値や実現付加価値の生産性を保証しない。その上で、仕事量の生産性 は期待付加価値をより多く試行し顧客に価値を届けるため / その試行回数を増やすための土台となる。また ビルドトラップに陥らないために戦略的意図やプロダクトイニシアチブが存在する 4Keysが教えてくれること / 教えてくれないこと 

27. タイミーの生産性への取り組み 具体例編
28. 28 タイミーの生産性への取り組み - 具体例編 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ 観察 / 課題仮説 / 改善のフレームワーク / フィードバックループ 

29. 29 タイミーの生産性への取り組み - 具体例編 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ 観察 / 課題仮説 / 改善のフレームワーク / フィードバックループ 

30. ソフトウェア品質のフィードバックループを回す
31. 31 ソフトウェア品質のフィードバックループを回す • チームが担当するユーザジャーニーの体験悪化アラート / トリアージ / Runbook整備 • ポストモーテムとNext Actionの策定、対策状況のトラッキング • テスト設計や品質保証活動を組織内分業せずチームで行う。 開発者自身がデリバリしたソフトウェアのシステム品質の 
 フィードバックを受ける 
 • コードベースとユーザジャーニー体験アラートのマッピング • 検証を複数チームが並列(待ちや相互依存が発生しない) で精度高く (本番同様のEnd to End 試験が実施できる / 非機能要件まで含めた試験が可能など)実施できる環境を提供するなど。 • 銀の弾丸はないし、愚直な改善を回す。 フィードバックをラクに / 早く受け取る 

32. 32 タイミーの生産性への取り組み - 具体例編 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ 観察 / 課題仮説 / 改善のフレームワーク / フィードバックループ 

33. 33 ボトルネックに目を向ける • 開発生産性 x SDLC | バリューストリーム切り口でのボトルネック • 信頼性 x ソフトウェアアーキテクチャ上のボトルネック ボトルネックとは、業務プロセス全体の中で最も処理速度が遅く、全体の効率 を低下させてる原因 

34. 34 開発生産性 x SDLC上のボトルネックに着目する • ビジネス要件の把握コスト / 業務要件 | 制約事項の把握コスト • コードベース把握のコスト / 影響箇所把握のコスト • レビューのコスト / レビューアサインのコスト • 手動テストのコスト/ テストデータ用意のコスト / テストスコープ決定のコスト • リリースのコスト / 異常検知とロールバック判断のコスト • 定量 / 定性からボトルネックを突き止める。 コーディング工程の前後に目を向ける 

35. 35 バリューストリーム上のムダと苦痛に着目する • 部分的に完成した仕事 / 余分な処理 / 余分な機能 • タスク切り替え / 待機 / 動作 / 不良 / 非標準的な作業や手作業 / 超人的な作業 • 「常にxxチームに作業依頼が必要」といった状態は、パフォーマンス指標の直交が原因で生まれた可 能性があるので特に注意が必要 顧客価値を送り届ける間に必要(とされている) プロセスがボトルネックを生ん でいないか？ 
 Toil切り口 - プロダクションサービスを動作させることに関係する作業でボトル ネックはないか？ 
 “Toilとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行わ れ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比 例するといった傾向を持つもの” 

36. 36 信頼性 x ソフトウェアアーキテクチャ上のボトルネック • 新規登録/ログイン/求人検索/マッチング/出退勤/振込/etc • 求人出稿/勤怠管理/報酬確定/帳票ダウンロード/請求/etc • タイミーのワーカ/クライアント双方のクリティカルユーザジャーニーに基づいたモニタリングと目 標信頼性/パフォーマンスの設定 > 技術ボトルネックの特定と対応を繰り返す。 ユーザジャーニー軸 
 • ユーザジャーニー上重要な処理がSPOFな実行基盤となっていないか？ • システムの可用性をクラウドコストとトレードオフにできる(お金で買える) 構成になっているか？ • カスケード障害の発生がありえる箇所は？ • 将来的にはSRE Agentの活用なども視野に(ソフトウェア信頼性におけるボトルネック特定と対策立 案、実装からリリースまでを人がコストかけずに行う手段という位置づけ) アーキテクチャ / データフロー軸 

37. 37 [余談] AIエージェント / LLMツールのインパクト • 極端な例だが、要件定義やコードレビュー、リリース作業が渋滞したら意味ないよねという事 • First Commit > PR作成の前後での活用拡大に時間投資できているかが重要になるという考え • タイミーでは現在コーディング業務での利用を中心に、 Flaky Testの解消サポート、テストケース作 成の自動化 / 簡素化、PRの自動サマリー作成とレビューなどでも利用中。 開発工程全体のボトルネックに目を向けなければ開発生産性/品質へのイン パクトは限定的になる 
 • AIを中心に添えたDevelopment Lifecycleを再考する転換期 開発工程の頭からのAI適用を考える必要性 

38. 38 タイミーの生産性への取り組み - 具体例編 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ 観察 / 課題仮説 / 改善のフレームワーク / フィードバックループ 

39. 39 観測から始め仮説を持つ • 定量情報だけではなく、定性情報(開発者意見) も課題仮説材料の一次情報として扱う • 活動を形骸化させない。目的意識を持ち活動を組織に根付かせる。 ソフトウェア品質の定性・定量一次情報を収集し続ける 

40. 40 タイミーの生産性への取り組み - 具体例編 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ 観察 / 課題仮説 / 改善のフレームワーク / フィードバックループ 

41. 41 巨人の肩に乗る - Capability / Best Practice • Dora Core Model • Security Framework • FinOps Framework 改善の道筋立ての指針として活用する 

42. 42 まとめ • プロダクト開発組織がプロダクトイニシアチブを爆速でデリバリーできる状態を維持する。 • プロダクトのあたりまえ品質をユーザーへ提供する。 タイミーの開発組織が目指すところ 
 • ソフトウェア品質のフィードバックループを回す • ボトルネックに目を向ける • 一次情報の観測から課題仮説を作る • 獲得すべきケイパビリティ / 実践すべきプラクティスのフレームワークを持つ どう目指すのか 
 

43. 43 (Ad) タイミーでは様々な職種で積極採用中です！ • エントランスブック : ◦ Timee Product Org Entrance Book • プロダクト社員やカルチャー紹介 : ◦ Product note • エンジニア向け成長支援制度 : ◦ TDE10 • エンジニア技術ブログ : ◦ Timee Product Team Blog • オンラインイベントのアーカイブ : ◦ Youtube アーカイブス • 募集中の職種一覧 : ◦ 採用情報
44. 検索 タイミー ご清聴ありがとうございました