はじめに
開発生産性カンファレンス2024に2日間参加して、お話を聞いてきました。
様々なお話を伺う中で、重複するワードが多く見受けられました。
そこで、私が特に重要だと感じ、実際に業務で活用できそうな内容をご紹介したいと思います。
参加したセッション
１日目
- テスラ、Redwood Materialsにみるビジネスグロースに貢献するエンジニア組織とは（Fireside Chat）
- APIライフサイクル管理の進化と生成AIの活用へ
- 高品質と高スピードを両立させるソフトウェアテストアプローチ
- 開発とQAのタッグで実現するこれからの開発生産性向上
- 価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦
- 価値創造と開発生産性
- タクシーアプリ『GO』におけるプラットフォームエンジニアリングの実践
2日目
- Mastering Developer Experience: A Roadmap to Success
- インプロセスQAとテスト自動化の両輪で進める食べログの開発生産性と品質改善の3年間
- LeanとDevOpsのためにE2Eテストができること
- 経営視点から捉えた開発生産性
- Metrics-informed development; theory and practice
- スクラム開発導入による他組織を巻き込んだ開発生産性向上の取り組み
- アーキテクチャレベルで考える開発生産性
- 爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み
- 開発生産性の観点から考える自動テスト
開発生産性の全体像？
開発生産性カンファレンスでは、「テスト自動化」、「Four Keys」、そして「開発者の満足度」など、さまざまなトピックが議論されました。
これらの観点を一つの図として表現するものを探していたところ、私としてはDora Core Modelが最も適していると感じましたので、ご紹介させていただきます。
Dora Core Modelは、DevOpsに関する研究を行う「Dora」というプロジェクトによって作成されており、Google Cloudが運営しています。
以下の図では、「Capabilities（機能）」が「Performance（パフォーマンス）」に影響を与え、最終的には「Outcomes（成果）」に結びつくことを示しています。（この部分には自信がありませんが…）
この図を通して、「開発生産性」と一口に言っても、さまざまな取り組みが存在し、それぞれ異なる指標で測定される必要があり、その結果として多様な成果が得られることをお伝えしたかったです。
その他にも開発生産性を測る指標として、SPACEフレームワークも度々話に上がっていました。
そもそも開発生産性とは？（価値創造と開発生産性）
皆さんは以下のどちらだと思いますか？
- チームが所定の期間内で作れるモノの量（つまり物的生産性）
- チームが所定の期間内で生み出せる価値の量（つまり付加価値生産性）
結論から言うと、決まった定義はない様です。
また、LeanとDevOpsの科学の著者Nicole Forsgren氏によると、それの定義を決めるのはあなた自身だと仰っていました。
そのため、開発生産性という定義を決めるのは、その指標を扱うチーム or 「開発生産性」を改善しようとする人 になります。
開発生産性を高める上で重要なこと①： 開発者自身がビジョンを理解する
テストやデプロイを自動化する前に、開発者自身がビジョンを理解しておくことが大切です。
開発者が一丸となって良いプロダクトを提供するためには、開発者自身がビジョンを理解しておく必要があります。
「なぜその機能が必要か？どういうニーズから生まれたか？」を説明できることが重要です。
仕様が決まって開発側に渡ってきたとき、時には企画から言われたことをそのまま作らないことも大切だと感じました。
スクラム開発を行っているチームは、スプリントレビューでスプリントゴールを共有し、「どの様な理由からこのスプリントゴールを設定しているか」に関して、開発者の満足度を高める上でも、共有した方が良いかと思いました。
元テスラCEOの方も、何よりも重要なのはビジョンを理解し、それに情熱を傾けることだと仰っていました。また、本当に熱意を持てることが大切だとも強調していました。
極端な例ですが、世界にインパクトを与える製品を生み出していると実感できれば、それが一番良いことだと思います。
（テスラがEVを世界に広める！！ と思いながら開発していた様に）
開発生産性を高める上で重要なこと②： テスト自動化
テスト自動化は、カンファレンスで最も盛り上がったトピックだったと思います。
その意義は、信頼性を保ちつつソフトウェアを変更できるようにすることにあります。
自動化対象のテストは以下の通りです。
- API
- ユニットテスト
- インテグレーションテスト
- フロントエンド
- E2Eテスト
- UIテスト
UI テスト（E2Eテスト）
AutifyやMagicPodなどのツールを利用すると、ノーコードでUIのテストを行う事ができます。
MagicPod
Autify
テスト自動化の注意点に関しても上げておきます。
-
テスト作成者が複数いると、人によってテスト観点が異なる
- 例えば、URLのリンクが正しいか確認する人がいたり、Paddingなどを多めに確認する人がいたりするなど
-
テストケースが肥大化する
- 闇雲にテストケースを書くと、さまざまなテストケースが増え（UIテスト導入時に特に起こりがち）、自動テストが重くなります。
-
自動テストが重くなり、実行時間が長くなる
1と2の解決策としては、どのような観点でテストケースを書くべきかについてのガイドラインを作成し、テスト品質が担保できるようにすることが重要です。
また、3の解決策として、テストの実行を日時・週次・案件単位で分けることが挙げられます。
- 日時: 最低限のテスト
-
週次: 挙動を確認するテスト
- 例: 登録が成功するかどうか
Unit Testテストとインテグレーションテスト、E2Eテスト
定義
それぞれのテストの定義は以下のものとします。
- Unit Test
- 単体と呼ばれる少量のコードを検証する
- 実行時間が短い
- 隔離された状態で実行される
上記、Unit Testの３つの性質を一つでも損なっているテストのことをインテグレーションテストと呼びます。
- インテグレーションテスト
- データベースにアクセスするなど、プロセス外依存するテスト
- 複数のパッケージに跨ったテスト
全てのプロセス外依存を含んだテストのことをE2Eテストと呼びます。
(参考文献：Vladimir Khorikov （2022）． 単体テストの考え方/使い方 株式会社マイナビ出版)
Flaky Test（不安定なテスト）
プロダクションコードを修正していないのに、テストの実行結果が変化する不安定なテストのことをFlaky Test（フレーキーテスト）と呼びます。
インテグレーションテストやE2Eテストといったプロセス外依存のテストは、Flaky(不安定)なテストになりやすいです。
Flaky Testが多いと以下のデメリットがあります。
- テストの信用度が減少する
- 「またテスト失敗した。再実行するか。。」や「いつも失敗するから失敗しているけどマージしよう」となりがち
- 実行時間が長い
- 失敗原因を調査する必要があり、余計な工数が掛かってしまう
そのため、 インテグレーションテストやE2Eテストに過剰投資するのは避け、実行時間が短く、安定性が高いユニットテストをできる限り促進することが大切 です。
Technology Radarでも、インテグレーションテストやE2Eテストの導入は「Hold」（業界で受け入れられているが良い経験がない、成熟していない、業界で使用しないことを望んでいる）に分類されています。
(画像出典：Technology Radar)
Unit Test
上で以下の様に定義したと思います。
Unit Test
・ 単体と呼ばれる少量のコードを検証する
・ 実行時間が短い
・ 隔離された状態で実行される
そこで、以下の場合はUnit Testだと思いますか？
- DBにアクセスするのはユニットテスト？
- ファイルにアクセスするのはユニットテスト？
- 現在時刻を取得するのはユニットテスト？
- 依存先のモジュールに本物を使うのはユニットテスト？
A：明確な定義はなし
そこで、Googleのソフトウェアエンジニアリングで示されている、Test Size（Small Medium Large）で考えてみようかと思います。
(画像出典： Google Testing Blog)
Flaky Test（不安定なテスト）を防止するためには、実行時間が短く、スピードが速い、そして小さなテストを拡充していくことが大切です。
詳しくは、素晴らしい記事を執筆されているTwadaさんの記事をご確認ください！
開発体制：QAとエンジニアの協力
QAチームだけでE2Eテストの自動化を行うのは、しばしば難しいことが多いです。
-
CI（継続的インテグレーション）に接続できない
- CIに接続することで、リリース前に不具合などを検知することができます
-
開発生産性の向上に活かせないと、自動化のメリットが減少する
- テストの自動化が開発プロセスに役立たない場合、そのメリットは減少します
-
テスト側で頑張るよりも、プロダクトのテスタビリティを向上させる方が経済的であることが多い
(参考文献：LeanとDevOpsのためにE2Eテストができること)
QAと開発側が協力し、テストを自動化するためにCIに接続し、テストしにくい箇所についてはプロダクト側を修正できる環境を整えることが重要です。最終的には、これが開発生産性の向上に繋がります。
とはいえ、最初からこのフェーズに移行するのは難しいかもしれません。そのため、最初はQAチームがテストの自動化を推進し、後から部分的にエンジニアも関与できるような文化を採用している会社もあります。
開発生産性を高める上で重要なこと③： スクラム
開発生産性向上のために、多くの組織が「スクラム開発」を採用しています。スクラム開発では、1スプリント内で作成したインクリメントをリリース可能な状態にすることが求められます。スクラムガイドでは具体的に定義されていませんが、そのためにはテスト自動化が必須条件となります。上記に挙げたE2Eテストやインテグレーションテストがこれに該当します。
しかし、実際にはテスト自動化をいきなり進めるのは難しいことも多いです。そこで、以下のように開発チーム内でテストを行い、最低限の品質を担保している会社もあります。
このような開発フローは取り入れるハードルが低く、スプリント内でリリース可能なものを完成させる第一歩となるかと思いました。
(画像出典：スクラム開発導入による 他組織を巻き込んだ開発生産性向上の取り込み)
開発生産性を高める上で重要なこと④： バリューストリームマップの作成（VSM）
バリューストリームマップ (VSM) とは、製品の製造やサービス提供に関連するステップを図示して分析するフローチャートです。
バリューストリームマッピングはリーン生産方式から生まれました。
これを活用することで、リーン手法の主目的である過剰生産、不良品、無駄な人や製品の移動などのコントロールを可視化し、開発生産性の向上を助けることができます。
(参考文献：Lucidchart, バリューストリームマップの作り方)
効果としては、以下の点が挙げられます。
- プロセスの全体像を把握することができる
- ボトルネックを把握し、組織の改善を図ることができる
まずはプロダクトオーナーと会話し、壁や問題点を見つけて、最終的には組織の改善に繋げれば良いんじゃないかと思いました。
最後に
開発生産性カンファレンス2024 はとても有意義な会で、来年も参加してみたいと思えるカンファレンスでした。
開発生産性に関して学べたことに加え、有名な著者の方々とお会いできたり、ブースで他社のプロダクトについて知ることができたりと、思いがけない学びもありました。
私なりに特に学びになったことを並べてみましたが、皆さんの業務に少しでも役立てば幸いです。
ここまでお読みいただきありがとうございました。