Test Automation

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

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

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章で詳述するチームへのフィードバックであり改善活動を促進する.

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