チーム単位で保守性を高める：独自指標と向上にむけた実践

©︎ チーム単位で保守性を高める - 独自指標と向上に向けた実践JaSST Tokyo 2024（2024/03/14） 株式会社10X 平田敏之（tarappo） 1 2024 10X, Inc.

©︎ 自己紹介 平田敏之（tarappo） かんたんな経歴 • DeNA SWET（- 2022/04） • 10X（2022/04 -） 領域 ・「開発生産性の向上」「品質の担保」をミッション 2024 10X, Inc.

©︎ はじめに Abstractより なぜこれが重要課題となったか 弊社の開発チームは、各々の担当領域で保守性を管理可能な水準に高めることを重 要課題の１つとしています。 どういった指標なのか そこで我々は「運営自律性」「機能適合性」「テスト容易性」「システム運用効率 性」といった4つの指標を独自に定義し、これらを最適化することを目指していま す。 実際のチーム事例を一部紹介 本セッションでは、これらの指標を高めるために実施した取り組みとその成果につ いて紹介します。 3 2024 10X, Inc.

©︎ チェーンストアECに特化した EC/DXプラットフォーム お客様アプリ スタッフアプリ 配達スタッフアプリ 4 2024 10X, Inc.

©︎ 1つ1つが むずかしい領域 広いカバー範囲 5 2024 10X, Inc.

©︎ 開発組織の課題 当初の組織体制：パートナー企業単位 この体制は当初効果があった一方、 • 認知コストの増大 • アドホックな対応の積み重ね • コードのオーナシップの希薄化 結果として、 • 開発・運用コストは上昇 6 2024 10X, Inc.

©︎ 開発組織の課題（品管側） 当時の品管側の課題 • パートナー単位でアサインできるほどの人はいない • Stailer全体を把握することは困難（きびしい） 結果として、 • 考慮しきれない箇所が出てくる • • だれも把握していない箇所がある どうしてもテスト全般にかかる工数が大きくなりがち 7 2024 10X, Inc.

©︎ 組織体制の変更と向き合うべき課題 8 2024 10X, Inc.

©︎ 組織体制の変更 コントロール可能な範囲に対して 長期にわたって開発チームをアサインする • 23年4月から開発チーム体制に移行 • 品管メンバーも開発チームに加わる • ただし人数の都合上、一部兼務 参照：https://product.10x.co.jp/entry/2023/04/28/080000 参照：https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=10 9 2024 10X, Inc.

• https://product.10x.co.jp/entry/2023/04/28/080000
• https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=10

©︎ 開発チーム体制（FY23） 品管メンバー 品管メンバー 品管メンバー 品管メンバー（兼） それぞれに品管メンバーが加わる 参照：https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=11 10 2024 10X, Inc.

• https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=11

©︎ 体制変更による期待する変化と見えてきた課題 期待する変化 • 長期目線にたったプロダクト開発ができる • チームごとの継続的な改善サイクルが回る • ドメインに立ち入った開発が加速する より「ドメイン」に立ち入った開発ができるようになった結果 「保守性」の面の課題に直面 11 2024 10X, Inc.

©︎ チームメンバーの工数の行方 開発・運用に「想定以上」に工数がかかっている チームによって異なるがメンバーの「工数」はどこにかかっているのか （単に時間的な意味合いだけでなく、心理的な負担の面も重要） • アラート対応で時間の多くが使われていないか？ • パートナーからの問い合わせ対応で時間の多くが使われいないか？ • 特定機能のテストをするのに時間がかかりすぎていないか？ ここが「どうなっているのか」を「チーム内外」ともに判断できるようにするべき 開発チームだけでなく他メンバーも把握する（できる）ことが次に向けた判断につながる どういった指標をみるべきなのか？ 12 2024 10X, Inc.

©︎ 向き合うべき課題 開発・運用に「想定以上」に工数がかかっている チームが担当する機能を管理しきれていない状況（ともいえる） 管理しきれていると判断するにはどういった指標があるとよいのか？ 世の中にある「指標」をそのまま活用するのは自分たちにとって適切とは限らない 自分たちのプロダクト開発に対して言語化し、指標化し、それをターゲットとする必要性 13 2024 10X, Inc.

©︎ 定義した独自指標 14 2024 10X, Inc.

©︎ 指標の定義 Focusすべきもの プロダクトの機能と実装を整理し、 開発チームが十分に管理可能な状態まで保守性を高める われわれにとって「管理可能な状態とは？」「保守性が高い」とは？ そのためにはどういったものを見るべき、追うべきなのか？ CTO主導で進めEM（私含む）と話した上で定義したのは次の４つの独自指標 • （１）運営自律性 • （２）機能適合性 • （３）テスト容易性 • （４）システム運用効率性 15 2024 10X, Inc.

©︎ （１）運用自律性 定義：ネットスーパー運営が小売事業者で完結する機能が揃っている 測るうえでの指標 • 開発チームへの質問・調査依頼数 • 開発チームへの作業依頼数 • • 10X側が作業しないと完結しないものがある パートナー固有のハードコードの分岐数 これらの指標がわるいとどうなるのか？ • お互いにとって「コスト」がかかり続けてしまう 16 2024 10X, Inc.

©︎ （２）機能適合性 定義：プロダクトの機能群が提供価値に適した形になっている 測るうえでの指標 • 事業価値に繋がらない・繋がりづらい機能の数 • 類似または重複している機能の数 • プロダクト化できていない仕組みの数 • 追加開発なしで横展開できない機能の数 これらの指標がわるいとどうなるのか？ • 機能に対する運用・提供コストが高くなる 17 2024 10X, Inc.

©︎ （３）テスト容易性 定義：プロダクトに対する変更を検証するコストが低い ※ 品管メンバーにとってという意味でなくチーム全体にとっての話 測るうえでの指標 • ドキュメントが不十分な機能の数 • 仕様書、コードドキュメントなど • テスト設計が不十分な機能の数 • 自動テストが不十分な機能の数 これらの指標がわるいとどうなるのか？ • テスト全般にかかる工数が多くなる 18 2024 10X, Inc.

©︎ （４）システム運用効率性 定義：プロダクトが正常な状態を維持するコストが低い 測るうえでの指標 • 開発チームで合意した監視が存在しない機能の数 • アラートの発生回数 • アラート対応にかかっている時間 • 障害の発生回数 • 障害対応にかかっている時間 これらの指標がわるいとどうなるのか？ • 対応コストが大幅に増えてしまうだけでなく関係者への影響が大きい 19 2024 10X, Inc.

©︎ 指標についてのかんたんなまとめ 「提供機能についての話」 • 事業価値につながる機能を提供できている • 小売事業者側が機能を理解して使えている 「問題の発見コスト・対応コストの話」 • リリース前後に「問題」を見つけられる • 「問題」を見つけられるコストが低い • 「問題」を対応するコストが低い 20 2024 10X, Inc.

©︎ まさに「すべてにおいてテスト」に通じる話 出典：Agile Testing Condensed Japanese Edition（翻訳前の元画像はContinuous Testing in DevOps… ） 21 2024 10X, Inc.

• https://leanpub.com/agiletesting-condensed-japanese-edition
• https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/

©︎ 指標の改善に向けた動き 22 2024 10X, Inc.

©︎ 開発チーム体制（FY23） チームによって扱っているドメインは異なる 品管メンバー 品管メンバー 品管メンバー 品管メンバー（兼） 参照：https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=11 23 2024 10X, Inc.

• https://speakerdeck.com/10xinc/10x-purodakutobu-men-shao-jie-zi-liao?slide=11

©︎ チームごとに指標と向き合う チームによって扱っているドメインは異なるがゆえにチームごとの特性がある 「チーム特性」は重要なポイント 必ずしも全ての指標において画一的に良くするべきという話ではない チーム単位でなにをよくしていくか（どこから登っていくべきか）を検討し推進 • どこがチームとして課題となっているか • どこを重点的に強化するべきか また指標はそれぞれ独立しているわけではなく他の指標と関連していることも多い 24 2024 10X, Inc.

©︎ チームごとに指標と向き合う - ２チームの事例 • なににフォーカスをしているか・したか • どういった変化がおきたか Case2 Case1 25 2024 10X, Inc.

©︎ Case1 Case1 26 2024 10X, Inc.

©︎ Case1 お届けチームの例 前提：パートナーのスタッフが利用する機能が多い 複数の人がさわったり、状態が複雑になりやすい機能がある 27 2024 10X, Inc.

©︎ Case1 • お届けチームの例 指標定義時点での一番の課題 • システム運用効率性 「システム運用効率性」の中で次が課題 • 監視が存在しない機能の数 • 障害対応にかかっている時間 • 状態の複雑さゆえに調査に時間がかかりやすい 28 2024 10X, Inc.

©︎ Case1 • 不足している監視の追加 • Feature Flagの導入 お届けチームの例 など 「結果」 • 右図のとおり大幅に減少 減少 29 2024 10X, Inc.

• お届けチームの例 具体的な内容の例については発表資料をチェック 「テストの完了をゴールにしない！ 仮説検証を繰り返し、開発・QA・ユーザーが交 流しながら開発することで見えてくる理想の姿 」 参照：https://speakerdeck.com/10xinc/shift-left-and-shift-right ～ 30 ～ ©︎ Case1 2024 10X, Inc.

• https://speakerdeck.com/10xinc/shift-left-and-shift-right

©︎ Case1 • お届けチームの例（発表資料から抜粋） 独自指標の向上につながる「シフトライト」の事例 参照：https://speakerdeck.com/10xinc/shift-left-and-shift-right 31 2024 10X, Inc.

• https://speakerdeck.com/10xinc/shift-left-and-shift-right

©︎ Case2 Case2 32 2024 10X, Inc.

©︎ Case2 • お会計チームの例 前提：扱っているものから「特に」守りを強くするべきチーム 33 2024 10X, Inc.

©︎ Case2 • お会計チームの例 指標定義時点での一番の課題 • システム運用効率性 「システム運用効率性」の中で次が課題 • アラート発生回数 • アラート対応にかかっている時間 • 外部連携が多いチーム アラートが多く、その対応に時間がかかり心理的負担も多い状況 34 2024 10X, Inc.

©︎ Case2 お会計チームの例 改善機能を都度リリースした結果 「アラートの発生回数」 • 23年10月 → 24年2月（1/4程度） 「結果」 • • アラートの対応工数はダウン 減少 心理的負担も軽減 35 2024 10X, Inc.

©︎ Case2 お会計チームの例（テスト容易性の話） テスト容易性の指標 • ドキュメントが不十分な機能の数 • テスト設計が不十分な機能の数 • 自動テストが不十分な機能の数 お会計チームのテストプロセス 以前はすべての案件で本プロセスを適用 テスト容易性の向上 参照：https://product.10x.co.jp/entry/okaikei̲qa 36 2024 10X, Inc.

• https://product.10x.co.jp/entry/okaikei_qa

©︎ Case2 • ドキュメントが不十分な機能の数 • • • ドキュメントの記載は基本的に必須 コードドキュメントはPR時に品管メンバーからFB テスト設計が不十分な機能の数 • • • お会計チームの例（テスト容易性の話） 仕様書 x プロダクトコードからテスト設計 今までおこなってきたものが積み上がっている 自動テストが不十分な機能の数 • • テスト設計時点でどこで守るか（自動、手動）を設計 テストコードの不足点は品管メンバーからFB 現状のプロセスを続けた結果 テスト容易性はそこまで「課題」とはなっていない → 「チームにとって」変更を検証するコストは高くない 37 2024 10X, Inc.

©︎ Case2 お会計チームの例（機能適合性の向上） 「改善前」 • 特定機能がパートナー単位で実装が分岐 • • パートナー追加時、要望対応時のコストが大きい パートナー単位で分かれているため検証コストも大きい 「改善」 • 共通化・抽象化して振る舞いは変えずに内部実装を改善 「改善後」 • 追加時・要望対応時の実装工数、検証工数大幅減 • 両方足しても１日以内程度（以前の1/4以下） 38 テスト容易性にもつながる 2024 10X, Inc.

©︎ 独自指標の導入によってわかったこと と次に向けて 39 2024 10X, Inc.

©︎ 独自指標導入によって分かったこと チームとして「ことに向き合えるようにする」ことは重要 そのためにも今回の独自指標の定義と活用は意義があった 一方、チームによって進み方の差がでてきた • 数値が改善できるサイクルがまわるようになっているチームがある • 改善サイクルがまわしづらい構造になっているチームがある チームがわるいとかではなく「取り組むのが難しいモチモノを扱っている」「改善に向 けてやるべきことが多い」など モチモノの整理やアプローチの仕方の検討などを通して次へつなげる 40 2024 10X, Inc.

©︎ 次にむけて 指標の定義、可視化によって「チーム内外」の人が現状を（ある程度）分かる • 現時点でという前提の元 • • コミットを強化するべきチームがより「明確」になった • 品質に対して自律性が高いチームもある • → 品管としてのコミットを弱めても平気といえる 「より各チームの成果を最大化」するためにチームアサインを実施 • 品管メンバーの関わり方のグラデーションが「より」可能に 組織として成果の最大化へ向けて 41 2024 10X, Inc.