Slide 1

Slide 1 text

生産性の高い 開発組織を作るための テスト文化の育て方 2023/10/11 古家 大

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

(C)PharmaX Inc. 2023 All Rights Reserve 4 ジョイン時のYOJO事業の状況 ● YOJOのリリースは約4年前の2019年6月 ● 当然フロントエンドにテストはなく、 コードをみても、ユースケースがわからない。 そして仕様書もない。 ● 専任のフロントエンドエンジニアがいない中で、 リリース速度を優先して作られたプロダクト (CRMとLINE側のLIFFをNext.js/TypeScriptで開発) → よし、テスト文化を育てよう

Slide 5

Slide 5 text

(C)PharmaX Inc. 2023 All Rights Reserve 5 何のためにテスト文化を育てるのか? ● 持続的にビジネスを成長させるため ● 少ない人数で高い利益率・アジリティを確保し、 競争力を高めるには生産性向上が必要 ● テスト文化は生産性向上に寄与する有効な手段 (詳しくは後述)

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

(C)PharmaX Inc. 2023 All Rights Reserve 7 なぜFour Keysを改善するのか? ● 組織のソフトウェアデリバリのケイパビリティ(Four Keys) は組織に競争上の優位性をもたらす ● 実践している組織とそうではない組織には数十〜数百倍のパ フォーマンスの差がある ● パフォーマンスを向上させるには「テスト容易性」 と「デプロイ容易性」が重要

Slide 8

Slide 8 text

(C)PharmaX Inc. 2023 All Rights Reserve 8 テスト容易性を高める方針 ● テストの大半を統合テスト環境を必要とせずに実施できる状態(コードカバ レッジは75〜90%が理想) ● 自動テストの割合にはいくつかの分類方法がある (テストピラミッド/テスティングトロフィー/テストサイズ) ● 結論、弊社ではフロントエンドはテスティングトロフィーを採用

Slide 9

Slide 9 text

(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 リクエストを含む ページ全体のテストをインテグレーション テストと定義(統合環境は不要)

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

(C)PharmaX Inc. 2023 All Rights Reserve 11 インテグレーションテストの例 ● APIやルーターなど外部依存はMock化 ● renderingとユーザーアクションによる 変更が予期した挙動をしているかテスト ● ドメインロジックはバックエンドで見る (バックエンド側のカバレッジは67.12%) ● 分割したコンポーネントを結合した時の ページ単位の挙動を担保

Slide 12

Slide 12 text

(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/経営陣と信頼関係を築く ② リファクタリング工数を組み込む ⑤ データを元に改善する習慣を作る

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

(C)PharmaX Inc. 2023 All Rights Reserve 17 テスト文化の育て方⑤ データを元に改善する習慣を作る ● まずはテストカバレッジやデプロイ頻度 といったすぐに取得できるデータを週 次のスプリントレトロスペクティブで必ず見る (基盤を用意してから、ではいつまでも始まらない) ● 見る習慣ができたら、どの指標をいつまでにどれくらい改善するかを明確 に目標設定する (目標にすることでチームで取り組む意識ができる)

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

(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側はこれから

Slide 20

Slide 20 text

(C)PharmaX Inc. 2023 All Rights Reserve 20 弊社のAfter(2023年10月時点) ● リファクタリング工数なし → プロダクトロードマップ組み込みを合意 ● 重要なアーキテクチャ特性の議論を進行中

Slide 21

Slide 21 text

(C)PharmaX Inc. 2023 All Rights Reserve 21 弊社のAfter(2023年10月時点) ● eslintの運用がされていない → 運用開始 + warning修正中 ● 仕様書も0 → 全機能の仕様書追加完了!QAシナリオ整備中 (E2Eテストを書き始める土台が出来始めた)

Slide 22

Slide 22 text

(C)PharmaX Inc. 2023 All Rights Reserve 22 まとめ ● 持続的にビジネスを成長させるために開発生産性 (Four Keys)の向上は不可欠 ● Four Keysの向上にはテスト容易性が重要 ● テスト容易性を高めるためテスティングトロフィーを採用 ● テスト文化を作るには信頼を獲得し、工数を確保する所から ● 背中を見せる人を明確に確保することが重要 ● まずは取得しやすいデータから見る癖をつけて、目標に落とし込む

Slide 23

Slide 23 text

(C)PharmaX Inc. 2023 All Rights Reserve 23 まとめ 当たり前のことを、 当たり前にやる ※ これが難しい。鋼の意志を持とう

Slide 24

Slide 24 text

(C)PharmaX Inc. 2023 All Rights Reserve 24 参考にした本

Slide 25

Slide 25 text

(C)PharmaX Inc. 2023 All Rights Reserve 25 ご清聴ありがとうございました エンジニア募集中! https://herp.careers/v1/yojo