モダン・ソフトウェア品質保証-レガシー/アジャイル/生成AIでの戦略の立て方 [単行本]

モダン・ソフトウェア品質保証-レガシー/アジャイル/生成AIでの戦略の立て方 の 商品概要

• 目次

  第1章　ソフトウェア品質保証はなぜ複雑化したか
  1.1　「品質」の定義が変わった：三層モデルで理解する
  　コラム：市場構造の変化が品質保証を変えた
  1.2　クラウドが複雑化させたもの：環境が「固定」ではなくなった
  1.3　アジャイル／DevOps が複雑化させたもの：出荷はイベントではなく「連続」になった
  1.4　生成AIが複雑化させたもの：実装の速度が上がるほど、検証がボトルネックになる
  1.5　失敗のモードが変わった：欠陥中心から「運用事故＋意思決定事故」へ
  1.6　なぜ「二重ループ」と「個別最適化」が必要か
  　コラム：ソフトウェア・ファクトリー型品質保証の強みは、どこまで今も有効か
  　コラム：Tom DeMarco氏の「いいえ、いいえ、そしていいえ」は何を意味するのか
  
  第2章　モダン品質保証の二つの原理：二重ループと個別最適化
  2.1　品質とは「意思決定の品質」である
  2.2　原理1：二重ループ（観測→意思決定→学習）
  2.3　原理2：個別最適化（リリース頻度×影響度×システム特性）
  2.4　二つの原理を組み合わせて使う
  2.5　導入の最小構成：まず「出荷判定」を形にする
  2.6　本章のまとめ
  　コラム：本書の枠組みと既存の品質標準はどう対応するのか
  　コラム：DORAの指標はどこまで信用できるのか
  　補足：モダン品質保証の全体フロー（簡略版）
  
  第3章　出荷判定の意思決定モデル
  3.1　出荷判定の再定義：二値ではなく「制御と責任」で考える
  3.2　Must/May/Watch：出荷判定を三つに分けて考える
  3.3　残っている問題をどう扱うかを決める三つの見方
  　コラム：数字で見ることと、中身を見て考えること
  3.4　エラーバジェット：価値向上と安定性の切り替えのルールを決める
  3.5　テストは「出荷判定の根拠」である
  3.6　本章のまとめ
  　コラム：サプライチェーンでは、部品そのものより「つなぎ方」が重要になる
  　コラム：SBOMはなぜセキュリティだけの話ではないのか
  3.7　モダン品質保証の全体フロー（実務で回す流れ）
  
  第4章　単発リリース型の具体的方策
  4.1　前提：単発リリースでは、どんな品質が求められるのか
  4.2　Delivery Loop：単発リリースでは「ゲートを順に通す」形で回る
  4.3　Learning Loop：単発リリースでも、学習は次に残せる
  4.4　Evidence Lake：単発リリース向けに「判断の根拠を整理して残す」
  4.5　観測指標：単発リリースでは何を見て出荷を決めるのか
  4.6　出荷判定：GO/NO-GOを「会議」ではなく「方式」で行う
  4.7　例外承認：現実を見える形で受け止める
  4.8　本章のまとめ
  　コラム：モダン品質保証の原理はレガシー案件にも使えるのか
  
  第5章　頻発リリース型の具体的方策
  5.1　前提：ここでいう「速さ」とは何か
  5.2　単発リリース型との差分マップ：同じ原理がどう形を変えるか
  5.3　アジャイルは一種類ではない
  5.4　スクラム開発をモダン品質保証にどう取り込むか
  　コラム：大規模アジャイルの品質保証
  5.5　Delivery Loop：露出制御として連続的に回す
  5.6　Learning Loop：障害からも、価値検証からも学ぶ
  5.7　出荷判定：GO/NO-GOではなく「露出制御」で考える
  5.8　エラーバジェットの運用：攻めるか守るかを実際にどう切り替えるか
  5.9　本章のまとめ
  　コラム：アジャイルの成否は、文化や業種ではなく「契約と責任分界の設計」で決まる
  　補足：アジャイル向けアネックス条項チェックリスト
  
  第6章　生成AIの品質保証の考え方
  6.1　生成AIを使うと、品質問題はどう変わるか
  　コラム：ハルシネーションは本当に消えるのか
  　コラム：なぜここでDDD（ドメイン駆動設計）なのか
  6.2　棲み分けの設計原則：DDDで、人が最後まで責任を持つ領域を固定する
  6.3　DDDの三分類を、レビューの優先順位に変える
  6.4　ガードレール：プロンプト単体ではなく、方式として品質条件を組み込む
  　コラム：RAGや社内知識活用があれば、品質保証は不要になるのか
  　コラム：比較ミニ実験
  6.5　ゲート審査とEvidence Lakeへの統合：AI出力を「再現可能な意思決定」に変える
  6.6　二つのLLMをどうコード品質チェックに生かすか
  6.7　最終手段としての人手レビュー：なぜ不可欠で、どこに集中すべきか
  　コラム：生成AIが進化すると、プログラマーは不要になるのか
  6.8　本章のまとめ：生成AIの品質保証は四つを組み合わせて成立する
  6.9　展望：AIエージェントによる開発では、人間レビューはどう再設計されるのか
  
  巻末付録A　モダン品質保証の段階的導入ステップ
  A.1　導入の基本原則
  A.2　段階的導入ステップ
  A.3　導入順序を誤ると起きやすい失敗
  A.4　簡易セルフチェック
  A.5　最初の3か月の導入ロードマップ（30/60/90日の目安）
  
  巻末付録B　実務テンプレート集
  このテンプレート集の使い方
  テンプレートID一覧表
  第1部　誰が判断し、誰が責任を持つかを決める
  第2部　何を基準に出荷を判断するかを決める
  第3部　頻繁リリースを安全に回す
  第4部　生成AIの品質保証を支える
  
  巻末付録C　制度化すべき標準チェックリスト
  
  巻末付録D　用語集
  D.1　SRE・DevOps・品質保証の基本用語
  D.2　テスト・品質保証の技術用語
  D.3　アーキテクチャ・設計用語（DDD関連）
  D.4　生成AI関連用語
  D.5　実務運用・リリース制御用語
  D.6　レジリエンス・分散システム用語
  D.7　生成AI運用品質用語
  
  巻末付録E　開発スタイル別の実践ポイント
  E.1　レガシーB2B請負型
  E.2　B2B反復改善型
  E.3　B2C/SaaS高頻度領域型
  E.4　高信頼・規制領域型
  E.5　生成AI内蔵システム型
  E.6　移行期組織型
  
  おわりに
  
  参考文献

• 出版社からのコメント

  品質保証を「最後に検査する仕事」から「安全に変え続けるためのやり方」へと捉え直す書。巻末にはテンプレート17種などを掲載。

• 内容紹介

  品質保証を「最後に検査する仕事」から「安全に変え続けるためのやり方」へと捉え直す一冊。巻末にはテンプレート17種などを掲載。
  
  アジャイルのための品質保証、AIのための品質保証など、それぞれに作法があると言われるが、現実の組織はそのすべてを同時に抱えている。基幹系の大規模改修と、週次で改善を回すサービスと、AIが書いたコードが、開発組織の中に共存する。各作法を足し合わせても、現実には運用できない。
  
  本書は、対象ごとの作法ではなく、すべてを包含する一つの方式から始める。品質とは、意思決定の品質である。何を根拠に出荷し、何を例外として受け入れ、何を観測しながら止め、そこから何を学ぶか。これを、出荷を成立させるDelivery Loopと改善を積み上げるLearning Loopの二重ループとして設計する。
  
  さらに、同じ方式を同じ強さで適用するのではなく個別最適化する方式として、リリース頻度と影響度、システムの特徴に応じて、Must／May／Watchの重心を配分し直す。守るべきものを厳格に守りながら、学ぶべき領域では速く回す。速さと信頼の両立は、精神論ではなく品質戦略を設計することである。
  
  巻末には記入例つきテンプレート17種を収めた。既存の強みを捨てるのではなく、重心を置き替える考え方で生成AIの時代に対応できる一冊である。

モダン・ソフトウェア品質保証-レガシー/アジャイル/生成AIでの戦略の立て方 の商品スペック