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

生産性の高い開発組織を作るためのテスト文化の育て方

 生産性の高い開発組織を作るためのテスト文化の育て方

テストコードが0の状態から、開発生産性の高い組織を実現していくために土台となるテスト文化を育てていくための方法を実体験ベースでお伝えします。

More Decks by PharmaX(旧YOJO Technologies)開発チーム

Transcript

  1. (C)PharmaX Inc. 2023 All Rights Reserve 2 YOJO事業 薬局DX事業 女性の健康に寄り添うかかりつけ医療ブランド

    「YOJO」を運営。いつでもどこでも医療者へ相談で き、体調に合わせて最適な医療にアクセスできるよう な体験を目指す YOJO事業で得られた知見をもとに、新規/既存薬局事 業者がオンライン薬局を立ち上げるためのソフトウェア ・オペレーションパッケージPharmaX OSを提供 PharmaXが取り組む2つの事業
  2. (C)PharmaX Inc. 2023 All Rights Reserve 3 自己紹介 古家 大(フルヤ

    マサル) YOJO事業のエンジニアリーダー エンジニアは4名、自分は他事業から今年の7月にジョイン プレイングマネージャーとしてコード書きつつ、 組織体制を強化するために必要なことはなんでもやる人
  3. (C)PharmaX Inc. 2023 All Rights Reserve 4 ジョイン時のYOJO事業の状況 • YOJOのリリースは約4年前の2019年6月

    • 当然フロントエンドにテストはなく、 コードをみても、ユースケースがわからない。 そして仕様書もない。 • 専任のフロントエンドエンジニアがいない中で、 リリース速度を優先して作られたプロダクト (CRMとLINE側のLIFFをNext.js/TypeScriptで開発) → よし、テスト文化を育てよう
  4. (C)PharmaX Inc. 2023 All Rights Reserve 5 何のためにテスト文化を育てるのか? • 持続的にビジネスを成長させるため

    • 少ない人数で高い利益率・アジリティを確保し、 競争力を高めるには生産性向上が必要 • テスト文化は生産性向上に寄与する有効な手段 (詳しくは後述)
  5. (C)PharmaX Inc. 2023 All Rights Reserve 6 PharmaXの開発における生産性指標 Four Keys

    • デプロイ頻度(d/d/d): 本番環境へのリリース頻度 • 変更のリードタイム:初回commitから本番反映までの時間 • 変更障害率:本番環境で障害が発生する原因となったデプ ロイの数 / 試行したデプロイ数 • 平均修復時間(MTTR): 障害が発生した場合に復旧までに かかった平均時間
  6. (C)PharmaX Inc. 2023 All Rights Reserve 7 なぜFour Keysを改善するのか? •

    組織のソフトウェアデリバリのケイパビリティ(Four Keys) は組織に競争上の優位性をもたらす • 実践している組織とそうではない組織には数十〜数百倍のパ フォーマンスの差がある • パフォーマンスを向上させるには「テスト容易性」 と「デプロイ容易性」が重要
  7. (C)PharmaX Inc. 2023 All Rights Reserve 8 テスト容易性を高める方針 • テストの大半を統合テスト環境を必要とせずに実施できる状態(コードカバ

    レッジは75〜90%が理想) • 自動テストの割合にはいくつかの分類方法がある (テストピラミッド/テスティングトロフィー/テストサイズ) • 結論、弊社ではフロントエンドはテスティングトロフィーを採用
  8. (C)PharmaX Inc. 2023 All Rights Reserve 9 テスティングトロフィー https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications https://twitter.com/kentcdodds/status/960723172591992832

    • React Testing Libraryの作者、Kent C. Dodds氏が提唱したコンセプト • 信頼性と速度のトレードオフが一番 取れているインテグレーションテストを 一番厚く書くべきという考え方 • モック化された HTTP リクエストを含む ページ全体のテストをインテグレーション テストと定義(統合環境は不要)
  9. (C)PharmaX Inc. 2023 All Rights Reserve 10 なぜテスティングトロフィーを採用したか? • フロントエンドはシンプルに保ちたい

    (複雑なドメインは極力バックエンドへ) • Reactコンポーネント単体のテスト書く旨味が少ない。複雑なドメイン処理 が少ないので単体テストの量がそこまで多く必要ない • 主要機能のユースケースをインテグレーションテストでカバーすれば、仕 様書の代わりになるし、デグレへの保護・リファクタリング耐性・フィード バックの速さのバランスが良い
  10. (C)PharmaX Inc. 2023 All Rights Reserve 11 インテグレーションテストの例 • APIやルーターなど外部依存はMock化

    • renderingとユーザーアクションによる 変更が予期した挙動をしているかテスト • ドメインロジックはバックエンドで見る (バックエンド側のカバレッジは67.12%) • 分割したコンポーネントを結合した時の ページ単位の挙動を担保
  11. (C)PharmaX Inc. 2023 All Rights Reserve 12 どうテスト文化を育てていくか? https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications https://twitter.com/kentcdodds/status/960723172591992832

    ④ StaticとIntegration Testに投資する ③ 背中を見せる人のリソースを確保する ① PdM/経営陣と信頼関係を築く ② リファクタリング工数を組み込む ⑤ データを元に改善する習慣を作る
  12. (C)PharmaX Inc. 2023 All Rights Reserve 13 テスト文化の育て方① PdM/経営陣と信頼関係を築く •

    工数を勝ち取れなければ、文化作りは不可能 • 1on1やtimesなどで普段から考えていること・やろうとして いることをこまめに伝えておく • 普段からビジネスと誠実に向き合い、PdM/経営陣からの 期待に応えられるように最善を尽くす
  13. (C)PharmaX Inc. 2023 All Rights Reserve 14 テスト文化の育て方② リファクタリング工数を組み込む •

    機能追加時にリファクタリングの工数をセットでとる • リファクタリング時に必ずインテグレーションテストをセットで書いているか コードレビューで確認する • 20%ルールの時間でモブプロ等でテストの書き方を学べるようにする
  14. (C)PharmaX Inc. 2023 All Rights Reserve 15 テスト文化の育て方③ 背中を見せる人のリソースを確保 •

    文化を作るには率先して背中を見せる人が不可欠 • 真似してもらうためのサンプル、土台が必要 • 背中を見せる人(例: テクニカルリード)を明確に役割として置く • テクニカルリードがリファクタリングやテストを書いたり、 学習する工数を確保できるようにサポートする
  15. (C)PharmaX Inc. 2023 All Rights Reserve 16 テスト文化の育て方④ StaticとIntegration Testに投資

    • まずは基盤となるlintを整備 & 運用し、テストを書く以前の コードへのストレスを解消する (自分の修正範囲の警告は放置しない) • テスト0の状態からはまずはインテグレーションテストを増や すことに集中する • E2Eテストはlintが整い、インテグレーションテストを書く文 化が軌道に乗ってから着手する (開発外でやることが多く集中できなくなるため)
  16. (C)PharmaX Inc. 2023 All Rights Reserve 17 テスト文化の育て方⑤ データを元に改善する習慣を作る •

    まずはテストカバレッジやデプロイ頻度 といったすぐに取得できるデータを週 次のスプリントレトロスペクティブで必ず見る (基盤を用意してから、ではいつまでも始まらない) • 見る習慣ができたら、どの指標をいつまでにどれくらい改善するかを明確 に目標設定する (目標にすることでチームで取り組む意識ができる)
  17. (C)PharmaX Inc. 2023 All Rights Reserve 18 弊社のBefore(2023年7月時点) • 開発生産性の計測無し、週1リリースでd/d/dは0.05

    • フロントエンドのテストコードは0、テストを書く習慣がない • フロントエンドでリファクタリングする習慣もなく工数もない • eslintも導入されていたが、運用されていない • 仕様書も0、仕様の全体を把握しているのが古参メンバー1人
  18. (C)PharmaX Inc. 2023 All Rights Reserve 19 弊社のAfter(2023年10月時点) • 開発生産性の計測を開始!

    • リリースを週1→週4に変更し、d/d/dを0.05→0.2の4倍に改善! ※ バックエンドも含む • フロントエンドのテストカバレッジ(c0)が0→52%に! ※ CRM側のみ、LIFF側はこれから
  19. (C)PharmaX Inc. 2023 All Rights Reserve 20 弊社のAfter(2023年10月時点) • リファクタリング工数なし

    → プロダクトロードマップ組み込みを合意 • 重要なアーキテクチャ特性の議論を進行中
  20. (C)PharmaX Inc. 2023 All Rights Reserve 21 弊社のAfter(2023年10月時点) • eslintの運用がされていない

    → 運用開始 + warning修正中 • 仕様書も0 → 全機能の仕様書追加完了!QAシナリオ整備中 (E2Eテストを書き始める土台が出来始めた)
  21. (C)PharmaX Inc. 2023 All Rights Reserve 22 まとめ • 持続的にビジネスを成長させるために開発生産性

    (Four Keys)の向上は不可欠 • Four Keysの向上にはテスト容易性が重要 • テスト容易性を高めるためテスティングトロフィーを採用 • テスト文化を作るには信頼を獲得し、工数を確保する所から • 背中を見せる人を明確に確保することが重要 • まずは取得しやすいデータから見る癖をつけて、目標に落とし込む