何が難しいのか どう解決しようとしているか NTTデータ 富士通 NEC （イデソンの見解も含む） 日本IBM 野村総研 日立製作所 • 開発期間が短い • 品質の根拠となる要求そのものが変化 • 今まで使ってきたメトリクスを使った 評価が難しい（テスト密度、バグ密度） • 受け入れ基準を活用して要求を満たしていることを示そう • 正しいプロセスで開発すれば正しいプロダクトができるだろう(プロセス品質、リソース品質を強化しよう) • 観点カバレッジとDDP（Defect Detection Percentage：欠陥検出率）モニタリングの手法を組み合わせるこ とでプロセスの適切さを判断する • 短期間で開発する必要がある • 順次開発のためデグレードリスクが高い • 相対的ポイントを使うと、過去の案件と の比較や基準値としての横展開が困難 • 短期間なので、初めから品質を作り込む工夫が必要（自動計測、自動判定の仕組み含む） • バグの計測対象は，当該ストーリーの開発スプリントの完了判定以降に摘出されたバグと定義する • Doneの定義を活用し、プロセス品質とプロダクト品質の両面で品質を確保する • 過去の案件と比較可能なメトリクスの収集（Done判定後のバグ、工数、テスト項目数） • 要求変更の数が多くなると、決められた 期間とコストの中で要望を管理する必要 • 明確な指針を提供し、事業と開発双方の 調整手腕を持つPOの存在が欠かせない • 従来の品質管理のプラクティスを適用で きるかどうか検証が必要 • 従来の欠陥摘出前倒し率は工程分割され たウォーターフォールにしか適用不可 • プロセスや技術が多様で統計的品質管理 が難しい(比較データ/代理特性適切さ） • 指標値が規定範囲に収まっているかどう かで品質の良し悪しを直接判断できない • 比較データは、プロセスや技術が似ている自チームの直近Sprintのデータを活用し、代用特性はチケットライ フサイクル（リードタイム、着手待ち時間、発券時期）を利用することでプロセスの在り様の観測が可能 • 多様性の高いアジャイル開発は、指標も、プロセスも、人それぞれ、チームそれぞれであることが自然 • 町⽥欣史, NTTデータ, アジャイル開発での品質保証 〜成功の鍵〜,(2020) https://www.nttdata.com/jp/ja/trends/data-insight/2020/102201/ • 町⽥欣史, NTTデータ, バグ密度・テスト密度に依存しない品質保証への挑戦, (2024) https://www.nttdata.com/jp/ja/trends/data-insight/2021/0204/ • 誉⽥ 直美, イデソン, 品質重視のアジャイル開発 〜ウォーターフォールモデル開発との比較から〜, (2021) https://www.veriserve.co.jp/asset/approach/column/agile/agile04.html • 誉⽥ 直美, NEC, アジャイルと品質会計, (2016) https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=167780&file_id=1&file_no=1 • 坂⽥ 晶紀, 富士通, アジャイル開発の品質管理技法, (2020) https://www.fujitsu.com/jp/services/agile/featurestories/about-agile-02.html • 短期で新しいテストが積み上がっていく スクラムでは不具合曲線の適用は困難 • 頻繁にプログラムを追加/修正するので、 保守困難かつデグレードが発生しやすい • 過去の類似プロジェクトを参考に、欠陥発見目標数を品質目標値とし、実際に発生した欠陥数と比較する • 設計フェーズから、ドキュメント・レビュー時の欠陥発見数を品質目標値として品質を見える化 • チーム内で議論して、入手しやすく、欠陥数と比例関係にある項目を品質目標として設定 • イテレーション期間は短いので、スプリント・レトロスペクティブで発生欠陥を分類/分析して議論 表は参考文献の記載内容を一部要約して記載 • トヨタ生産方式の「自工程完結」のように、工程内で品質を管理し、不良品を出さないようにする考え方を ソフトウェア開発に持ち込めるようにする • 開発工程を小規模なチームで管理できる単位まで小さくすることで 「自工程完結」の品質管理の考え方をソ フトウェア開発に持ち込める • 1SprintでE2Eテストまでやり切る、自動化する、QAも設計初期段階から参画し、使用検討とテストを実施 • 前倒しの基準を工程からバク票作成日に変更、対象をE2Eテストのバグに絞って、前倒し率を利用可能にし た • アジャイル開発では開発期間が短く、リリースごとの特徴のような要因によりメトリクス値の変動を無視で きないため、リリース毎の特徴を踏まえてメトリクスや基準値を調整 • 坂上 義之, 日本アイ・ビー・エム, 3分で読める｜アジャイル開発における品質見える化, (2023) https://www.ibm.com/blogs/smarter-business/business/quality-visualization-in-agile-development-01/ • 物部 康介, 浦⽥ 壮一郎, NRI,アジャイル開発の本質をひもとく―日本企業への導入に何が必要か―, (2017) https://www.nri.com/jp/journal/2017/1025 • 松⽥ 元輝, 日立製作所, アジャイルプラクティスを導入した開発における品質メトリクスの提案, (2018) https://www.juse.jp/sqip/library/shousai/download/index.cgi/A4-2.pdf?id=410 • 足立 直ほか, 日立製作所,アジャイル開発における品質管理の取り組みと評価 , (2009) https://www.jstage.jst.go.jp/article/spm/2009.Autumn/0/2009.Autumn_86/_article/-char/ja/
koborik
maltzj
lauravandoore
zakiyama
sachag
lara
marktimemedia
dougneiner
soudai
eileencodes
malarkey
skipperchong
orderedlist
