Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

第18回Quesへの登壇

 第18回Ques「スタートアップと品質 ~プロダクトの成長に伴う品質活動~」に私の所属企業から登壇します!

 

ques.connpass.com

 サービスがまだスタートアップだった時代から現在にかけての品質活動の変遷や、今のテスト自動化の取り組みについてお話しする予定で、6年前に書いたこちらのアドベントカレンダー記事の具体的な事例といった内容になるのではないかなと思います。

kokotatata.hatenablog.com

 

 ご興味のある方是非ご参加ください!

今月企画しているDeveloper Productivityやテスト自動化についての勉強会

Developer Productivityやテスト自動化についての勉強会を今月2件開催します。

①freee Tech Night ✖️ 食べログ「何度でも食べたいテスト自動化導入の必勝レシピ」

freee-tech-night.connpass.com

②Test Engineers Meetup #4

test-engineers-meetup.connpass.com

ここ3年ほど外部勉強会にあまり参加できてなかったのですが、今年は色々仕掛けていこうと計画している第一弾です。

Developer Productivityやテスト自動化にご興味のある方、ぜひご参加ください!

 

個人の経歴2021年バージョン

講演・執筆活動

カンファレンス講演等(日本)

カンファレンス講演等(国外)

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

コミュニティ

アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~

はじめに

 こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity(開発生産性)が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。

 私の所属する株式会社カカクコム食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで​最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]!このブログエントリでは、まず ソフトウェア開発におけるDeveloper Productivity Engineeringの歴史 についてお話しした後、食べログでの取り組み についてご紹介します。

Developer Productivity Engineeringの歴史

 古くは"人月の神話"や"銀の弾などない"などの1970年代まで、ソフトウェアのDeveloper Productivity Engineeringについての議論は遡れます[5][6]。人月の神話では

遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。

という、ソフトウェア開発の進捗はプロジェクト参加人数に対してスケールしないというブルックの法則を紹介しており、以前からソフトウェア開発の生産性については大きな課題感があったことが分かります。

 近年では、職場環境がDeveloper Productivity Engineeringに与える影響についての論文 がマイクロソフトから発表されたり、Netflixなどのウェブ企業が積極的に生産性について発信したりと、 ソフトウェア開発業界ではDeveloper Productivity Engineeringが話題 となっています[2][3]。

Developer Productivity Engineeringの源流、アジャイルからDevOpsへ

f:id:kokotatata:20211217101741p:plain

Developer Productivityの歴史

 近年話題のDeveloper Productivityですが、その源流は意外にも日本の製造業にあります[7]。日本の製造業では1970年代、品質と生産性を向上するための様々なプラクティスが提唱、実践されました。その中でも特に、自働化とJust In Time (JIS)による「徹底したムダの排除」を柱とするトヨタ生産方式(TPS)と、統計的な品質分析手法などを柱とするTQM/QCサークルは、日本で製造業の生産性を向上させるだけでなく、海外へとその考え方が輸出されました[8][9]。

 アジャイルラクティスの一つであるスクラムもTPSから影響を受けた手法の一つです[10]。スクラムではプロダクトバックログやスプリントなどを通し、ソフトウェア開発プロジェクトを繰り返し可能なプロセスとして管理します。繰り返しプロセスの中で、スコープを分割し少しずつ開発することで、少しずつ完成される、動くソフトウェアから受け取るフィードバックを元にソフトウェア品質を改善しながら継続的に開発します。また、ふりかえりなどを実施しプロセスの問題点や改善点などのフィードバックを定期的に得ることで、継続的に繰り返しプロセス自体の改善も実施できるようになります。

 継続的デリバリー、DevOpsではアジャイルの繰り返しプロセスに含まれる様々な手作業を自動化することによって、フィードバックをさらに素早く頻繁に獲得できるようにしていきます[10]。例えばパイプラインや受け入れテストを自動化することで、テストを素早く高頻度で実行できるようになり、テストから設計への品質のフィードバックを素早く回せるようになります。また、クラウドやInfrastructure as Code (IaC)などを利用しデプロイを自動化することで、リリースを短縮しエンドユーザーからのフィードバック獲得も素早く実施できるようになります。

 自動化によってDeveloper Productivityを改善できる手作業を分析、特定するためにはバリューストリームマッピングを活用します[11]。チームの垣根を越えて関係者で集まり、開発サイクルの各工程の作業を洗い出し「7つのムダ」の観点で分析することで、自動化によって効率的に削減可能な作業を特定します。

 このように、アジャイルからDevOpsへと発展してきたソフトウェア開発の流れの中には「 繰り返し開発の中でフィードバックループを回すことで品質を継続的に改善する 」という思想があります。この思想を達成するため、スクラムなどのプラクティスによってプロセスを繰り返し可能なものとして管理し、バリューストリームマッピングなどによって非効率な手作業を特定し、それらの手作業をDevOpsの自動化技術によって素早く高頻度でフィードバックを獲得できるように改善していきます。

DevOpsからDeveloper Productivity Engineeringへ

 近年のDeveloper Productivity Engineeringの流れはこのアジャイル・DevOpsのフィードバックによる改善活動を、 リーンやその他の組織改善の手法によってさらに発展させていくもの です[7]。

 "LeanとDevOpsの科学"や同著のレポートである"State of DevOps 2021"では、リーンマネージメントにもとづいた開発組織のパフォーマンス計測について紹介されています[12][13]。これらの著書では、開発組織の重要なパフォーマンスメトリクスとして

  • デプロイ頻度 [フィードバックの素早さ](4回/日)
  • リードタイム [フィードバックの素早さ](1時間以内)
  • リリース失敗率 [フィードバックの信頼性](0%-15%)
  • 復旧時間 [フィードバックの信頼性] (1時間以内)

の4つが紹介されています。これらのメトリクスはそれぞれ[]内にある通り、フィードバックの「素早さ」または「信頼性」を表しています。ちなみにそれぞれのメトリクスの横の数字は、DevOps実践者を「エリート」「上級者」「中級者」「初級者」の4つにカテゴライズした際の、「エリート」の平均値であり、「初級者」に比べて数倍良い数字になっているとのことです。みなさまのチームはどのカテゴリに属していますでしょうか?

 ちなみに2021年のYahoo! JapanさんのAdvent Calendarでも同様の枠組みを用いたDeveloper Productivityの分析が紹介されています[14]。ブログ内では言及されてませんが、分析結果を見る限り(Yahoo!さんのコンテキストでは)下記のDevOpsのプラクティスがDeveloper Productivityと相関が高そうですね。

  • デプロイの共通化および自動化
  • 単体テストの自動化
  • テストのCI/CDへの統合
  • システムの結合関係および変更に伴う影響範囲の明確化

 Gradle社はこういったソフトウェア開発プロセスの改善活動を"Developer Productivity Engineering"として定義し、白書にまとめています[15]。こちらの白書ではDeveloper Productivity Engineeringは以下のように定義されています。

Developer Productivity Engineering is a discipline of using data to improve the developer experience and essential software development processes to ensure a high degree of automation, fast feedback cycles, and reliable feedback.
日本語訳:Developer Productivity Engineeringとは開発者体験とソフトウェア開発プロセスを改善するためにデータを使用する手法です。高度な自動化、素早いフィードバックと信頼できるフィードバックを作り上げます。

つまり、Developer ProductivityとはDevOpsの高度な自動化と、 リーンやその他の組織改善のためのデータ分析 が融合した手法です。繰り返しプロセスのデータ(メトリクス)を取得することで、フィードバックの素早さと信頼性を可視化し、ボトルネックを見つけて継続的に改善していきます。DevOpsでは、ウォーターフォールアジャイルよりも繰り返しの開発プロセスの期間が短くなります。そのため、プロセスのデータも小刻みかつ頻繁に取得できるようになるため、様々なデータ分析手法が適用しやすくなるのが嬉しいところです。

 この白書の中では、改善すべき「素早いけれども信頼できない」フィードバックの例として「自動テストのFlaky Test (毎回成功、失敗と異なる結果を返すテスト)」が紹介されています。手作業のテストを自動化することによって、テストからフィードバックを獲得するまでの期間を短縮できますが、一方でテストが毎回異なる結果を返すFlaky testが増えるとテスト結果が信用できなくなり、開発現場に余計なノイズを生んでしまいます。すべてのFlakyテストを撲滅することは難しいかもしれませんが、自動テストのFlaky率を計測しながらコントロールすることで信頼できないフィードバックを軽減することができます。

食べログのDeveloper Productivityの取り組み

 ここまでソフトウェア開発でのDeveloper Productivityについての変遷についてご紹介してきました。ここからは食べログのDeveloper Productivityチームについてご紹介します。食べログでもエンジニアの開発生産性の課題に取り組むDeveloper Productivityチームが2021年に爆誕しました!まずはこのチームのミッションをご紹介します。

Developer Productivityチームのミッション

f:id:kokotatata:20211217102123p:plain

食べログのDeveloper Productivityチームのミッション

 食べログのDeveloper Productivityチームのミッションは「 開発サイクルのフィードバックを素早く、リッチにすることで​最高の開発・テスト体験を実現する 」です。
 エンドユーザーの要望をソフトウェアとして開発し価値に変換する開発サイクルの中には、実装やテスト、リリースなどの工程が含まれます。これらの工程では至るところでプロダクトの動作確認や検証が行われており、「デバッグ」「結合テスト」「再発防止策」などが絶え間なく開発チームにフィードバックされています。これらのフィードバックをより「素早く」「リッチ」にしていくことで最高の開発・テスト体験を食べログの中で実現していくことを目指しています。

 「最高の開発体験」に対しては「 開発者の影響分析・デバッグにかかる労力を最小化する 」を中・長期目標とし、開発環境や開発ツールなどをモダン化していく計画です。また、「最高のテスト体験」に対しては、「 コード修正後すぐにテストからフィードバックを得られるようにテスト体験を向上する 」を中・長期目標として、テスト自動実行基盤やテストデータ基盤などの構築を行っていきます。

バリューストリームマッピングやりました

 これらの中・長期目標を立てるにあたっては、Developer Productivityチームと開発チームメンバーが一緒になって2ヶ月に渡る課題分析をバリューストリームマッピングにもとづいてワイワイと実施しました。15年以上のサービス開発の歴史を持つ食べログでは、"これだけ歴史があればあちこちにガタが来ている"状態であり、その課題はアーキテクチャや組織文化、開発サイクルと多岐に渡っています[16]。今回の課題分析では、その中でも開発サイクルの課題にフォーカスし、素早くリッチなフィードバック獲得の妨げとなっているボトルネックについて分析しました。

f:id:kokotatata:20211217102614p:plain

開発サイクルの課題分析の3つのステップ

 開発サイクルのボトルネックの分析のステップは以下の3つです。

  • ①業界や他社のトレンドの共有
  • ②現状の課題の分析
  • 食べログ理想の開発サイクルを描く

 ①業界や他社のトレンドの共有では、他社での技術的負債に対する取り組みやマイクロサービス化などの最新技術についてそれぞれワクワクするトピックを持ち寄って共有しました。課題分析、、、となると自分たちの反省点を挙げる辛い作業になってしまうことも多々あると思いますが、食べログのDeveloper Productivityチームが目指しているのは「最高の開発・テスト体験」であり、そこに必要なのは「ワクワク感」です。ですので、まず、自分たちが 「ワクワクできる」開発サイクルってどんなのだろう? ということについて、他社の事例を参考にしつつ、みんなで共通のイメージを持つようにしました。

 ②現状の課題の分析はこの課題分析のメインの議論であり、バリューストリームマッピングを使用しています。まずオンラインホワイトボードに開発サイクルの絵を書き、みんなでペタペタと課題を付箋で貼っていきました。次に各工程の課題について原因と解決へのアプローチを深掘りしました。

 下記は結合テスト工程での深堀りディスカッションの付箋たちです。「テストデータ準備が大変」「手動テストの実行に時間がかかる」といった課題に対して「手順が煩雑」「種データがわからない」「テストがコードとして管理されてない」「テストがパイプラインに統合されてない」などの付箋が原因として出てきました。 これらの付箋を元に検討したところ、データの準備やテスト実行などのテストに必要なアクションをコード化 していくことで、これらの課題を解決し「コード修正後すぐにテストからフィードバックを得られるようにテスト体験を向上する」を実現できそうなことがわかりました。

f:id:kokotatata:20211217102737p:plain

結合テスト工程の分析結果

 ③食べログ理想の開発サイクルでは、すべての課題が解決された後の理想的な食べログの開発サイクルについてみんなで絵を描きました。②のステップでは各工程内部の課題の解決にフォーカスしましたが、こちらの③のステップでは開発サイクル全体をどういう風に変えていきたいかを話し合いました。開発サイクル全体で見たときに、サイクルの前半でチーム内外のコミュニケーションを密に行うようにし、サイクルの後半で各工程の自動化できる作業を集めて自動で実行するようにすることで、コミュニケーションと作業の効率化の両方を狙っていくことにしました。

 この課題分析を開発チームと一緒に実施できたのは非常に貴重な経験でした。別々のチームとして活動していただけでは気づけない、例えばテストの場合はテスト実行自体だけではなくデータの投入などの準備もめっちゃ大変など、現場のリアルな話が聞けました。開発チームのメンバーも、進行中のプロジェクトなどで忙しい中での参加だったのですが、全部の分析が終わった後で、「開発チームのリアルな声を元にDeveloper Productivityチームの活動方針を決めてもらえて嬉しい」と言ってもらえたのが嬉しかったです。

「最高のテスト体験」に向けた取り組み

 Developer Productivityチームでは、「最高の開発・テスト体験」を実現するための取り組みを始めています。特に「最高のテスト体験」を実現するために「テストに必要なアクションのコード化」をしていく取り組みについては、

のチームメンバーのアドベントカレンダーの記事の中で紹介していますので是非そちらもご覧になってください[17][18]。

 "カバレッジ10%のテスト自動化で7割以上のテスト工数を削減できる!?〜ゆもつよメソッドを使った要求分析〜"は、今後食べログで自動化していくテストのテスト観点について、「ゆもつよメソッド」を使って分析した取り組みです。ゆもつよメソッドを使って「機能やテスト条件」と「過去のテスト実行情報や障害情報」を組み合わせて整理していくことで、 10%の観点の自動化で74%のテスト工数を削減できる ことが分かりました。

カバレッジ10%のテスト自動化で7割以上のテスト工数を削減できる!?〜ゆもつよメソッドを使った要求分析〜 - Qiita
https://qiita.com

 また、"フィードバックループを高速に回すためのテスト自動化アーキテクチャを設計した話"では、「素早く信頼性の高いフィードバック」を自動テストによって実現するためのアーキテクチャ設計をご紹介しています。(もちろんチームによって重要となるアーキテクチャの品質特性は様々ですが)食べログでは 「追跡性」「再現性」「スケーラビリティ」が重要そう ということが分かったため、これらの品質を作り込むためのアーキテクチャを設計しました。

フィードバックループを高速に回すためのテスト自動化アーキテクチャを設計した話 - Qiita
https://qiita.com

 実はこれらの取り組みは一つの形で実を結び、 この12月18日に「10%のテスト自動化」を達成 することができました!食べログのDeveloper Productivityチームは今年の10月に発足したばかりであり、まだまだ小さい成果ですが、食べログのDeveloper Productivityを大きく改善していくための確かな一歩を踏み出すことができました。

おわりに

 このアドベントカレンダー記事では、近年話題となっているDeveloper Productivityについての業界の歴史と、食べログでの取り組みについてご紹介しました。日本の製造業での生産性と品質の改善手法が、アジャイル・DevOps開発として世界に普及し、Developer Productivity Engineeringとして発展し、2021年食べログでも本格的に取り入れてソフトウェア開発の生産性改善に取り組むことになりました。

 食べログのDeveloper Productivityチームでは、開発サイクルのデバッグ結合テストなどのフィードバックをより素早くリッチにしていくため、開発環境や開発ツールのモダン化やテスト基盤の構築などに取り組んでいます。フィードバックを素早くリッチにしていくことで、食べログの開発プロジェクトで最高の開発体験、テスト体験を得られるようにします。

 食べログでは現在、一緒にお仕事をしてくれるSETエンジニアを募集しています。これからもりもり自動化に取り組んで参りますので、ご応募お待ちしております:relaxed: 正式なご応募以外にも、転職活動前の情報収集やランチを交えた情報交換なども大歓迎です。その場合はご応募いただくときに、フリーテキスト記入欄に「カジュアル面談希望」とご記載ください!

Software Engineer in Test(SET)【食べログ】 | 株式会社カカクコム
https://hrmos.co

参考文献

 

個人の経歴2020年バージョン

講演・執筆活動

カンファレンス講演等(日本)

カンファレンス講演等(国外)

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

コミュニティ

アジャイルとDevOpsの品質保証と信頼性

 このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。

 (品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。)

---

概要

 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル全体を見 通した素早いテストや,開発から運用まで含めた一連のプロセスの中での継続的なテストとフィードバッ クの獲得も求められる.また,本番稼働中のシステムの障害についてもレジリエンスの枠組みでフィード バックを獲得し継続的に学習する.本稿では,ウォーターフォールとの比較を含むこれらのアジャイル/DevOps の品質保証と信頼性の考え方について事例も交えながら紹介する.
 

1.はじめに

 ソフトウェア開発の国際競争力強化のため,アジャイルやDevOpsなどのソフトウェア開発手法を導入するチームが増えている1).顧客のフィードバックにもとづいて機能開発を反復するアジャイル開発や,クラウドや自動化などによりソフトウェア開発プロセス全体の生産性を改善するDevOpsを導入することで,グローバルでのビジネス環境の変化に素早く対応可能なソフトウェア開発が実現できることが知られている2) 3).

 アジャイル/DevOpsを導入するチームが増えている一方で,アジャイル/DevOps導入について品質面での懸念を抱えているチームも多い.アジャイル/DevOpsには品質保証に関する手法が一見すると少ないため,アジャイル/DevOpsは品質を軽視しているとの誤解が少なくない.また今まで慣れ親しんだウォーターフォールと考え方が異なるため,ウォーターフォールで培った品質保証や信頼性の知見をそのままアジャイル/DevOpsに適用することは難しい場合もある. アジャイル/DevOpsを効果的に導入するためには,その特徴にもとづいて実施していくことが重要である.

 アジャイル/DevOps開発の特徴は,分割されたスコープに対し短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返すことである.そのためQAテストとしての品質保証の役割は依然重要であるが,収集可能なメトリクスの特徴は異なる. また開発サイクル全体を見通し素早くテストを実施する必要があるため,自動テストやプロセスの品質を適切に設計し自動化していくことが重要となる.さらにテストの実施時期を前倒し/後ろ倒しすることで,開発から運用までの一連のプロセスの中で継続的にテストを実施しフィードバックを獲得する. またアジャイル/DevOpsの信頼性では,レジリエンスエンジニアリングと共通する考え方が多い.

 本稿では,アジャイルからDevOpsへの発展の流れを述べた後,その特徴について特にウォーターフォールとのプロセス面での違いを述べる.次にアジャイル/DevOpsにおける品質保証と信頼性の特徴として,①QAテストとメトリクス,②素早いテストと開発サイクル,③継続的なフィードバックと④レジリエンスの4つを挙げ,それぞれの特徴について事例を交えながら解説する.

2.アジャイルとDevOpsの発展と特徴

2.1 アジャイル/DevOpsの発展

 アジャイル開発は,90年代後半に出てきたスクラム,XP(Extreme Programming),などの手法の提唱者たちにより,2001年にアジャイル宣言が書かれて生まれた2).日本においては2000年代後半より普及し始め,日次ミーティング,ふりかえりなどのスクラムの手法や,単体テスト自動化,継続的インテグレーション(CI)などのXPの手法の適用率が高い1).

 アジャイル開発はその後,XPのCIなどの手法がクラウドなどの運用面の自動化技術と融合し対象領域を運用へと広げていく中で,継続的デリバリーそしてDevOpsへと発展していった3).その過程で,トヨタ生産方式(TPS)を源流とするリーン開発の影響も受けており,開発から運用までのプロセスを自動化によって改善することがDevOpsの1つの主目的となっている.ソフトウェア開発のプロセスでは,開発,品質保証,運用が別のチームによって分業されることが多かったが,これらの組織をまたいだプロセス改善のため特に大企業が積極的に導入している4).

 

f:id:kokotatata:20200212155143j:plain

図1 アジャイルからDevOpsへの流れ

 2.2 アジャイル/DevOps開発の特徴

 アジャイル開発の特徴は,要求(スコープ)を分割し,少しずつ素早い開発を繰り返し実施していくことである2).ウォーターフォールではソフトウェア開発工程を分析,設計,実装,テストの順に開発する.そのため,プロジェクトが終了するまで動くソフトウェアが完成しない.一方アジャイルでは要求を分割し,2週間から3ヶ月程度の短い開発サイクルを繰り返しながら徐々に開発していく.そのため,動くソフトウェアを徐々に積み上げていくことができる.開発期間を通し,動くソフトウェアに対する顧客のフィードバックをもとにした改善活動が可能になる2).

f:id:kokotatata:20200212155419j:plain

図2 繰り返し開発としてのアジャイル/DevOps

 DevOpsでは品質保証や運用も対象にして,アジャイルよりもさらに短い開発サイクルを繰り返す4) 5).これはDevOpsがトヨタ生産方式(TPS)を源流とするリーン開発の影響を受けていることも理由の一つとして考えられる.「10+ deploys per day」の言葉に代表されるように,一日に何度も品質保証や運用作業を実施する.短い開発サイクルの中で,単体テストや受け入れテストのテスト結果や,運用作業やリリースの結果を小刻みにチームにフィードバックすることで,アジャイルの改善活動をより効果的にする.

3.品質保証と信頼性の特徴

 ここまでみてきたように,アジャイル/DevOps開発には

  • 分割されたスコープ
  • 短い開発サイクルの繰り返し
  • フィードバックループにもとづいた改善活動

の3つの特徴がある.

 これら3つの特徴は品質保証や信頼性にも影響するため,アジャイル/DevOpsでは品質保証や信頼性においてもウォーターフォールとは異なる考え方が必要になる.もちろん品質保証自体はアジャイル/DevOpsでも重要であり,ソフトウェア品質の評価メトリクスやテスト自動化の技法などではウォーターフォールと共通で活用できる手法も多い.一方で,特に短い開発サイクルでフィードバックを繰り返すプロセス面での違いは顕著であり,アジャイル/DevOpsでは大きく考え方が変わっている.

 アジャイル/DevOpsでの品質保証と信頼性についてウォーターフォールとの比較を

  • ①QAテストとメトリクス
  • ②素早いテストと開発サイクル
  • ③継続的なフィードバック
  • ④レジリエンス

の4つの特徴から紹介する.

f:id:kokotatata:20200212155654j:plain

図3 アジャイル/DevOps開発における品質保証,信頼性面での4つの特徴

特徴①: QAテストとメトリクス

 アジャイル/DevOpsでも,ウォーターフォールと同様にQAテストとしての品質保証の役割は依然必要となる5).短い開発サイクルを繰り返すアジャイル開発では製品出荷の頻度が多くなるため,品質保証チームがQAテストの結果にもとづきしっかりとした出荷判定をしないと,不具合の市場流出のリスクが高まる.

 ただしアジャイル/DevOpsでは現場の課題の見える化をメトリクス活用の主目的としていたり,収集可能なメトリクスの特徴がウォーターフォールと異なっていたりするため,メトリクスの取り扱いには注意が必要である5) 6).

 

特徴②: 素早いテストと開発サイクル

 アジャイル/DevOpsは短い開発サイクルを繰り返すため,品質保証も短期間,高頻度での実施が求められる.そのため品質保証の生産性の改善活動がアジャイル/DevOpsの重要な要素の一つとなる4).自動化を通し,テスト実行やテストレポートなどのテスト工程をソフトウェア化することで,品質保証が素早く実行可能になる.

 また,さらに短い開発サイクルのDevOpsでは,実装工程と運用工程をつなぐ品質保証はボトルネックになりやすい7).アジャイル/DevOps開発では,品質保証工程が詰まるとバグ修正や運用作業で待ち時間が発生し,開発工程全体に影響を及ぼしてしまう.実装工程や運用工程を含めた品質保証工程のソフトウェア化による生産性の改善が必要となる.

 

特徴③:継続的なフィードバック

 アジャイル/DevOpsにおける品質保証活動では,チームに対する継続的なフィードバックを重視している8).顧客のフィードバックと同様に,テストや本番稼働中のシステムからのフィードバックにもとづいた改善活動を,プロジェクト期間中継続して実施する.

 継続的なフィードバックは品質保証活動を前倒しする「シフト・レフトテスト」と,後ろ倒しする「シフト・ライトテスト」に分類することができる9). 「シフト・レフトテスト」では品質保証活動の一部を開発の初期から開始しバグの情報などを適宜フィードバックする.また「シフト・ライトテスト」には本番稼働中のシステムで新旧異なるバージョンのソフトウェアをユーザーに実際に使用してもらい比較する「ABテスト」などの手法が含まれる.

 

特徴④: レジリエンス

  アジャイル/DevOpsの信頼性では,レジリエンスエンジニアリングと共通する考え方が多く,監視や対応,学習のためのフィードバックを重要視する傾向がある.シフト・ライトテストに含まれる「カオスエンジニアリング」や「カナリアリリース」は本番稼働中のシステムからシステム障害について継続的にフィードバックすることで,システム障害について組織的に継続的な学習することや,迅速な検知と対応の枠組みを提供する9).

 

 次章からはこれら4点の特徴についてそれぞれ詳細な解説と事例の紹介をする.

4.QAテストとメトリクス

4.1 QAテストとしてのアジャイル品質保証

 アジャイル/DevOpsにおいてもQAテストとしての品質保証の役割は依然重要となる.アジャイル/DevOpsでは短い開発サイクルを反復するため製品出荷の頻度がウォーターフォールに比べ多い. 品質保証チームがQAテストとしての役割を確実に果たさないと,不具合が市場に流出するリスクが高まってしまう.アジャイル開発向けの品質保証の枠組みとして,スクラムに受け入れテストと品質テストを組み込む「QA to AQ」というパターンが提案されている10).

 アジャイル開発の導入では生産性の向上が期待される一方,品質が低下するという懸念もあるが,アジャイル開発でも十分な品質保証を実施していることを示している事例もある.

 NECの事例では,スクラム,XPとウォーターフォール向けの品質管理技法である品質会計を組み合わせることで,出荷後バグを発生させないことを達成している11).この取り組みでは,スクラムのスプリントレビューでのスプリント完了基準に基づく完了評価とスプリント中の品質管理技術者による品質確認を中心とした軽い仕組みによって,開発工数も1/2程度に改善している.

 筆者のチームでは,アジャイルプロジェクトでシステムテストを全面的に自動化する際に,ウォーターフォールで培われた品質評価のメトリクスであるテスト密度,バグ密度によって評価した12) 13).IPAの提供する業界標準と比較することで,ウォーターフォールで実施されている品質保証と同程度のテストを自動化できていることを確認した.6章で詳述するが,この事例ではバグ修正にかかる日数を5日から2日へと60%削減している.

f:id:kokotatata:20200417185724p:plain

図4: 開発サイクルをまたぐ時系列メトリクス12)

4.2 アジャイル品質保証のメトリクス

 アジャイル開発では,コードカバレッジ(ソースコードに対するテストの網羅率)や欠陥数などウォーターフォールと共通のメトリクスがある一方,独自のメトリクスも提案されている.ストーリーポイント,ベロシティなどはアジャイル独自のメトリクスである5).

 アジャイル開発でのメトリクス活用の主な目的は,プロジェクト管理ではなく現場の課題の見える化と改善活動の促進である6).例えばバグメトリクスを時系列で見える化することでプロジェクトの後半で多くのバグが検出されていることに気づき,テストの網羅率の向上などの改善活動に繋げることができる.また品質ダッシュボードはコード品質を見える化することでチームがコード品質を保つことをサポートする5).これらのメトリクスによる見える化は,6章で詳述するチームへのフィードバックであり改善活動を促進する.

 アジャイル開発では短い開発サイクルを繰り返すため1回の開発サイクルの中では対象となるデータ量が少なく,メトリクスのバラツキが大きくなる.そのためチームをまたぐような標準適合度合いの評価などでは統計的な分析手法が使いにくい5).

 その一方で,アジャイル開発では開発サイクルを繰り返すため,時系列のメトリクスを開発サイクルにまたがって測定することが可能になる7) 12).そのためチーム内の開発サイクルをまたいだ変化についての統計的な分析がアジャイル開発では得意である.

 アジャイル開発では,ウォーターフォールで培われた品質保証の技術をそのまま適用できない場合もある.ウォーターフォールの出荷判定で利用される信頼度成長曲線は,品質保証期間中にソースコード変更がないことを前提として収束する特徴を持つが,アジャイル/DevOps開発ではソースコード変更と品質保証が並行して実施されるため収束しない12).

 

f:id:kokotatata:20200417185824p:plain

図5: アジャイル開発での統計的データ分析12)

5.素早いテストと開発サイクル

5.1テストのソフトウェア化による素早いテスト

 アジャイル開発では短い開発サイクルを繰り返すため,品質保証も短期間,高頻度で実施することが求められる.自動化などを活用し,テスト要求分析からテストレポートまでの一連のテスト工程を素早く実施する.

 テスト自動化はテストの実行時間を短縮するための一般的に知られた手法である.アジャイル開発では単体テストから受け入れテストまで異なるテストレベルのテストを自動化する.ただし,アジャイル/DevOps開発では繰り返し自動テストを保守したり実行したりするため,ソフトウェアとしての自動テストのアーキテクチャ設計も重要となる14).

 自動テストの実装は手動テストに比べより多くの時間やコストがかかることが指摘されている6).特にテスト自動化を始めたばかりの組織や,繰り返し開発における自動テストコードの保守ではより多くの時間がかかる.そのため,振る舞い駆動開発やデータ駆動テストやなどの手法を用いてテストの習得性や保守性を適切に設計することが重要である14).

 また,毎回異なるテスト結果をもたらすFlakyテストは,テスト実行のたびにテスト結果を人間が確認する手作業を生じさせるためテストの生産性に悪影響を及ぼす14) 15).並行して実行するテストの相互干渉を防ぐためのテストシナリオやテストデータの独立性,テスト環境起因の問題を解決するためのテスト環境の信頼性,テスト結果調査のためのエラー追跡性などの自動テストの品質をソフトウェアとして作り込むことでFlakyテストによるテスト実行の効率悪化のリスクを軽減することができる.

 近年では,単純な定型作業であるテスト実行だけでなく,今まで人間が行なっていたテスト設計やテスト結果の確認などの知的活動が必要な作業のソフトウェア化も,機械学習やAIを活用することによって進められている15) 16).

 

5.2 DevOpsでの開発サイクル全体のソフトウェア化

 アジャイルよりさらに短い開発サイクルを繰り返すDevOpsでは,品質保証工程の改善はより大きな意味を持つ.特にDevOpsの場合,品質保証はDev(開発)とOps(運用)をつなぐ位置に存在するため,品質保証単独ではなく開発プロセス全体を見通したプロセスの改善とソフトウェア化が重要となる.

 DevOpsではプロセスの分析手法として,リーン生産方式の技法の一つであるバリューストリームマッピングが知られている17).バリューストリームマッピングはTPSで使われていた手法をもとにしており,開発や品質保証などのステークホルダー全員でプロセスを可視化し,プロセスに潜むムダを見つけ出す.特にチーム間でのタスクの受け渡しや承認が必要な部分に手作業や手待ちのムダが存在することが知られている4) 17).

 また,筆者のチームでは,開発,品質保証とDevOpsチームにまたがるプロセスのムダをQC七つ道具により分析し,ソースコード変更後から出荷までの一連の手作業とテストを自動化することで解決した7).この事例ではテスト環境への不具合流出が原因で,品質保証チームの生産性だけでなく実装やバグ修正などの開発チームの生産性まで下がっていた.特性要因図,散布図などのQC七つ道具を利用し根本原因を特定し,出荷やテストなどの手作業を自動化した.その結果,障害件数を66%,バグ修正日数を80%削減した.DevOpsでの自動化は,手動で実施していたプロセスのソフトウェア化に他ならない.プロセスに求められる品質をソフトウェアの品質特性として設計,実装することで開発サイクル全体の生産性を改善する.

 バリューストリームマッピングとQC七つ道具はどちらも日本の製造業に源流があるプロセス改善の手法である17) 18).DevOpsの場合,ウォーターフォールと比べむしろこれらの手法との相性は良い7).1つ目の理由は,DevOpsによってソフトウェア開発は製造業と同じように定型的な工程を何度も繰り返すようになったことである.品質保証の実施頻度が少ないウォーターフォールに比べプロセス全体の最適化のインセンティブは高い.また,前述の通りDevOpsではプロセスのメトリクスが開発サイクルをまたいで測定できるため,時系列では分析対象のデータが多くなり統計的なプロセス分析手法を適用しやすい.

 

f:id:kokotatata:20200417185948p:plain

図6 開発サイクル全体の生産性改善事例7)

6.継続的なフィードバック

  アジャイル/DevOpsでは,開発サイクルを通し小刻みなフィードバックを獲得するための手法が数多く提供されている9).これらの手法はテストの観点から継続的テストと呼ばれており,開発の早期の段階からフィードバックを獲得するための「シフト・レフトテスト」と,本番稼働中のシステムからもフィードバックを獲得するための「シフト・ライトテスト」によって構成される.

f:id:kokotatata:20200417190035p:plain

図7シフト・レフトとシフト・ライトテスト9)

 6.1 シフト・レフトテスト

 テスト活動を前倒しする「シフト・レフトテスト」では,品質保証活動の一部を開発の初期から開始することで,プロダクトの改善やバグ修正に必要なフィードバックを開発の早い段階から獲得する8).そのためフィードバック獲得の仕組みを適切に設計することの重要性が指摘されている8) 19).

 三菱電機の事例では,プロジェクトの初期からフィードバックを獲得したいGUI部分の開発にアジャイル開発を適用している19).フィードバック獲得について「誰から?」「どんな?」「どうやって?」を事前に設計することで,インターフェースの矛盾やユーザビリティ,システム仕様の不整合についてのフィードバックを早期に獲得することに成功している.

 「シフト・レフトテスト」の中の継続的インテグレーション(CI),継続的デリバリー(CD)などの手法は,既存機能を壊すバグであるリグレッションバグを早期に発見,フィードバックするための仕組みである.自動化したテストを日次などのペースで継続的に実行することで, リグレッションバグに関する小刻みなフィードバックを実現する.そのため,開発者はリグレッションバグやバグ修正の結果をソースコード変更直後に知ることができる.

 筆者のチームではシステムテストを自動化する継続的システムテストを導入した12) 13).継続的システムテストでは自動化したシステムテストを毎日継続して実行しテスト結果をフィードバックする.そのため4章の図4で示すように,システムレベルのリグレッションバグを開発期間中も継続して発見することができる.実装を終えソースコード変更をレポジトリに追加した翌日に混入されたバグのフィードバックを得られるため,特にバグ修正の期間を改善することができる.筆者の事例ではバグ修正にかかる日数を5日から2日に改善した.

 

6.2 シフト・ライトテスト

 テスト活動を後ろ倒しする「シフト・ライトテスト」では,リリース以降の本番稼働中のシステムからもフィードバックを獲得する9).レジリエンスと関係の深い「カナリアリリース」と「カオスエンジニアリング」は次章で詳述するため,ここでは「ABテスト」と「モニタリング」を紹介する.

 「ABテスト」では,本番環境の実ユーザーに2つのバージョンのアプリケーションを使用してもらい,クリックや商品の購入といったユーザーの実際の行動につながったかを示す顧客転換率(CVR)などを比較する.ユーザーインターフェースのユーザービリティやゲームの甘美性など主観的な評価が大きな割合を占める分野で特に利用されている.

 「モニタリング」では,本番環境から得られたメトリクスをフィードバックとして機能やシステム拡張計画を改善する.開発した機能はリリース後,要求分析の際の事前の想定とは異なる使われ方がされることがある.想定と実際の使われ方のギャップから,次に開発したり改善したりする機能を分析する.システム拡張計画も想定とのギャップが出やすいため,リソース使用率などから適宜改善する.

7. レジリエンス

 アジャイル/DevOpsでは,信頼性の中でも特にレジリエンスを重要視する.レジリエンスでは,「予測」「監視」「対応」「学習」の4つの基本能力からなる枠組みで,障害などの事象から学ぶ組織を設計する20).短い開発サイクルの中でのフィードバックを重要視するアジャイル/DevOpsでは,特に障害についての継続的な学びを実践するシフト・ライトテストの中にレジリエンスの考え方と共通するものがある.

 

7.1 カオスエンジニアリング

 カオスエンジニアリングでは,障害を引き起こすようなテストを本番環境で意図的に実施する9).長期間障害が発生しないと,そのこと自体は喜ばしいが,障害に対する能力を組織が忘れる弊害が生じる.そうすると,いざ障害が起きた時に検知したり復旧したりといった迅速な対応ができなくなってしまう.本番環境で意図的に障害を引き起こすようなテストを継続的に実施することで,障害の検知方法や復旧方法について定期的にフィードバックを獲得,学習することができる. 

 DevOpsではシステムアーキテクチャを,すべての機能が単一のシステムとして設計されるモノリシックなものから,小さい多数のシステムへ移行するマイクロサービス化が進められている21). モノリシックなシステムの場合,障害影響範囲はシステム全体におよびやすいが,マイクロサービスでは障害の影響範囲をシステムの一部に限定することが可能になる.こういったシステムの耐障害許容性をカオスエンジニアリングはテストする.もし問題が見つかった場合は設計にフィードバックし改善する.

 

7.2 カナリアリリース

 カナリアリリースは,シフト・ライトテストのもう一つのレジリエンスの仕組みである.新旧2つのバージョンを本番環境で稼働させ,新バージョンに徐々に移行しながら新バージョンに問題がないかどうかフィードバックループを回しリリースする9).

 カナリアリリースでは新バージョンに徐々に移行するため,新バージョンに問題があった場合の影響範囲を限定できる.システム全体を一度にリリースするとユーザー全体に影響を及ぼしてしまうが,小規模なユーザーから徐々に新バージョンをリリースすることでフィードバックを獲得し,問題があった場合の影響範囲をコントロールする.

 カナリアリリースの名前には「リリース」とついているが,本番環境でのテスト手法として捉えることができる.テスト環境では環境の制約が原因で実施が困難なテストを限定的な影響範囲の下,本番環境で実施していると考えられる.そのため一般的なテストと同様に, カナリアリリースの最中に監視する項目をリストアップし,それぞれの監視項目の期待される値を定義する.カナリアリリースの最中は実際の値と期待される値を比較し,パスすればその移行工程を終了し次の移行工程へと進む.

 筆者の組織では,ビジネス上クリティカルなユーザーシナリオの成功率やシステムレスポンスの遅延などを監視項目として定義し,リリース中に監視している.筆者の組織ではカナリアリリースを導入することで,システム全体に影響を及ぼす深刻な障害だけでなく,限定的な障害も削減することができた.カナリアリリースの監視項目の定義と監視を通し本番環境のシステムの振る舞いを学習することで,バグの作り込みそのものを減らすことができる.

 

8. おわりに

 本稿ではアジャイル/DevOpsの品質保証と信頼性について特徴と事例を紹介した.アジャイル/DevOpsでは短い開発サイクルを繰り返し,フィードバックによる改善活動を促進する.そのため,依然QAテストとしての品質保証は重要であるが,それに加えて,開発サイクル全体を見通した素早いテストの実施や,開発サイクルの早期から本番稼働環境までを含めた継続的なフィードバックループの獲得が重要である.アジャイル/DevOpsを通した日本のソフトウェア開発競争力のさらなる向上を期待する.

参考文献

  1.  (独) 情報処理推進機構:アジャイル型開発におけるプラクティス活用事例調査 調査概要報告書(2013. 03)
  2. 平鍋健児:変化を味方につけるアジャイル開発, SEC journal,11,No.3, pp.22-25(2016. 03)
  3. 榊原彰:開発と運用の融合-DevOpsの波-, IBM PROVISION, No.75, pp.26-31 (2012. 10)
  4. 川口恭伸ら:楽天でのエンタープライズアジャイルとDevOps -Dev/Test/Ops 三位一体の自動化-, 情報処理学会デジタルプラクティス, Vol.7, No.3, 243-251(2016. 07)
  5. 誉田直美ら:アジャイル品質保証の動向, SQuBOK Review 2016, Vol.1, pp.1-10 (2016. 09)
  6. 荻野恒太郎:楽天のアジャイル開発とメトリクス事例,SQiP 2016, E2 講演&パネルディスカッション資料(2016. 09) https://www.slideshare.net/kotaroogino/sqip2016 (2020年01月06日現在)
  7. 内藤史郎ら:QC七つ道具を利用したDevOpsプラクティスの導入による開発とテストの生産性改善, SQiP 2019, C1-1(09)
  8. 永田敦:プロダクト部門での品質保証担当の振る舞い アジャイル開発の場合, JaSST `16 Tokyo, C5-1 (2016. 03)
  9. 辰巳敬三:ソフトウェアテストのニューノーマル~テストの新たな常態・常識~, VERISERVE NAVIGATION, Vol.13, pp.06-11 (2018. 03)
  10. Joseph W. Yoder el:QA to AQ -Patterns about transitioning from Quality Assurance to Agile Quality-, Asian PLoP 2014, (2014. 03)
  11. 誉田直美:俊敏さを実現する新しい情報システム開発―エンタープライズアジャイルを中心にー, 情報処理学会デジタルプラクティス, Vol.7, No.3, 218-225(2016. 07)
  12. 荻野恒太郎:継続的システムテストについての理解を深めるための開発とバグのメトリクス分析, SQiP 2014, A1-3, (2014. 09)
  13. 荻野恒太郎:安心なサービスの品質改善を実現するための継続的システムテスト, 15-B-11先進的な設計・検証技術の適用事例報告書2015年度版(2015. 11)
  14. 荻野恒太郎:“素早い”テスト実践法, 日経SYSTEMS, 2017年8月号, 特集2 pp.50-57 (2017. 07 )
  15. John Micco: Advances in Continuous Integration Testing @Google, JaSST `18, A0, http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf(2020年01月06日現在)
  16. Tariq King: AI-Driven Testing a new era of test automation, JaSST `19, A0, http://jasst.jp/symposium/jasst19tokyo/pdf/A1.pdf(2020年01月06日現在)
  17. 牛尾剛:日本のDevOps変革を促進するバリューストリームマッピング, https://gihyo.jp/dev/column/01/devops/2017/value-stream-mapping,(2020年01月06日現在)
  18. 安達賢二ら:日本におけるソフトウェアプロセス改善の歴史的意義と今後の展開, SQuBOK Review 2016, Vol.1, pp.11-24 (2016. 09)
  19. 細谷泰夫:斥候としてのアジャイルプロセス活用の提案, SPI Japan 2012, (2012)
  20. 小松原明哲:個人と組織のレジリエンスを高める, 人間工学, 2013年49巻Supplement号2S1-1, pp.S58-S59, (2013. 06)
  21. レン・バスら:DevOps教科書, 日経BP社 (2016. 06)

個人の経歴2019年バージョン

講演・執筆活動

カンファレンス講演等(日本)

カンファレンス講演等(国外)

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

コミュニティ