高品質と高スピードを支える品質のシフトレフトのアプローチ

高品質と高スピードを支える品質のシフトレフトのアプローチ日本科学技術連盟ソフトウェア品質管理研究会特別講義 2026/11/13 井芹洋輝

自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアとさまざまな立場でさまざまなプロダクトの品質保証や品質管理業務に従事 • テストや品質マネジメントについて執筆・講演・研究・技術指導複数 • 現在は車メーカーで車載開発のQA/テストテックリード、QMアーキテクトを担当 •
JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫主な著作 • 「ソフトウェア品質保証ガイド」「ソフトウェアテスト徹底指南書」「実践ソフトウェアエンジニアリング第9版」（共訳）「シフトレフトテストを支える現代的なテスト設計」「システムテスト自動化標準ガイド」（共著）など 2

この講演について ⚫概要 • 品質のシフトレフトについて解説します ⚫アウトライン 1. 開発の総合力を支える重要性 2. シフトレフト 3.
シフトレフトを支える施策 3

アウトライン：3.シフトレフトを支える施策 ⚫品質マネジメントの適時性の向上ウォーキングスケルトン • 早期の品質フィードバックテストピラミッド • 反復型プロセス開発者テスト強化 •
CI/CDの整備静的テスト強化 • 体系的テスト • 品質の積み上げ • 工程品質の積み上げ • コンポーネント品質の積み上げ • ソフトウェアエンジニアリングの適正化 AI駆動開発高凝集・疎結合アーキテクチャバルクヘッドパターンサービス志向アーキテクチャ副作用の局所化プロダクトリスクの分離ドメインプリミティブ設計 ⚫開発容易性の作りこみ • 保守性・運用性の作りこみ • アーキテクチャの整備 • 開発基盤の整備テスト容易性の作りこみコンテキストに合わせたQMS CI/CDデプロイメントパイプライン ⚫あるべき品質への方向付け • ビジネス・ユーザ・開発・運用のすり合わせ • 開発と運用のフィードバックサイクルの形成 • プロアクティブアプローチ 4

開発の総合力を支える重要性 5

あるべきプロダクト品質の実現のためには ⚫ただ品質を追求するだけでなく、開発チームの総合力の向上が重要 • 品質の実現力 • 開発のスピード • 開発の持続性 • 開発のレジリエンス
• コスト競争力 ⚫近年はソフトウェアプロダクトのサービス化で開発チームの総合力がサービスの品質に直結する関係性が強まっている • チームのスピードやレジリエンスが直接プロダクト品質に 6

ビジネスパフォーマンスは開発チームの開発総合力に連動ビジネスパフォーマンスエリート高い中間低い変更リードタイム 1日未満 1日～1週間
1週間～1か月 1か月～デプロイ頻度いつでも 5% 1週間に1回～ 1か月に1回 10% 1か月に1回～変更失敗率 1日1回～ 1週間に1回 20% 障害復旧時間 1時間未満 1日未満 1日未満 1週間から1か月 40% DORA Accelerate State of DevOps 2024 現代的なソフトウェア開発の成功のためには品質実現に加えて、開発のスピード、レジリエンス、持続性の総合力強化が必要 7

品質と開発のスピード、レジリエンス、持続性は共立関係 ⚫開発チームのスピードが速いと →品質向上 • リソース効率改善。品質作りこみの余裕を確保 • 開発とユーザのフィードバックループを迅速化 • 顧客満足のための試行錯誤を迅速化 ⚫開発チームのレジリエンスが高いと
→品質向上 • プロダクトの障害・不満点を早期解消 • リスク許容度が高まりよりチャレンジできる ⚫開発チームの持続性が高いと →品質向上 • ユーザへの継続的なプロダクト価値の向上実現 • プロダクトの改善機会を確保 ⚫逆に総合力に劣ると、品質に注力しても品質が低下する状態に 8

品質マネジメントのアプローチにも品質、スピード、レジリエンス、持続性を共立させるチームの総合力強化が求められる 9

総合力を高める品質マネジメントのアプローチ ⚫品質マネジメントのアプローチには、品質、スピード、レジリエンス、持続性をトレードオフにするもの、トレードオン（共立）にするものがある ⚫トレードオフ（何かを上げれば他が下がる）のアプローチ • 終盤の品質ゲート（例：最終テスト工程）を重厚化 • テストの責務を独立性の高いテスト組織へ集中 →有限な開発リソース下では、総崩れして、品質に注力しているのに品質を下げる事態に
⚫現代的な品質マネジメントは、トレードオフの悪影響を緩和し、可能ならばトレードオン（共立）に転換させるものでなければならない 10

シフトレフト 11

品質、スピード、レジリエンス、開発持続性を共立させる品質マネジメントのアプローチ ⚫今回紹介するアプローチ：品質のシフトレフト ⚫品質活動を早期から実施し： • 品質問題を予防・早期対策する • 品質の確保・保証を早期から行う 12

品質のシフトレフトによる総合力強化 ⚫早期の品質確保・品質問題対応・リスクコントロールで： • スピードやリソース効率、コスト競争力を向上 • 早期の保守性確保・仕組みづくりでレジリエンス・開発持続性向上後工程に行くほど欠陥修正コストが悪化『Integrating Software Assurance
into the Software Development Life Cycle (SDLC)』、Journal of Information Systems Technology and Planning, Volume 3、 2010 13

シフトレフトの留意点：シフトレフトはテストの前倒しではない ⚫テストで問題を見つけて修正するアプローチは、手戻りロスが発生 ⚫最も効果的なシフトレフトは、問題の予防や早期コントロール ⚫シフトレフトは、単なるテストの前倒しではない開発ライフサイクル全体でのエンジニアリングの適正化がシフトレフト • 「検査員というのは、生産性をおとす余分な人間である」石川馨、『日本的品質管理:
TQCとは何か』 14

シフトレフトの留意点：「品質の要所を適時に押さえる」のがシフトレフト ⚫品質の問題やリスクは、見つけるべきポイント、対応すべきポイントがある。適時にそのポイントに対応するのが重要 ⚫ただ早ければ良いわけではない品質課題の例見つけるべきポイント並行処理での競合状態に・設計段階で、並行処理設計が妥当起因する異常動作
か確認・コードレビューで、適切な保護処理が実装されているかを評価機密情報の暗号化漏れ対処すべきポイント・設計段階で並行処理設計を適正化・実装のルール整備や静的テストで保護処理を適正化・セキュリティ要件が織り込まれてい・要件定義・設計の段階でセキュリティるか、それが設計に落とし込まれて要件の定義と実現を方針付けいるかレビュー・ペネトレーションテスト・セキュリティ監査で、機密情報を入手できるか評価 15

シフトレフトの留意点：正しい方向にシフトしなけれならない ⚫シフトレフトは、正しい方向にシフトしてこそ効果が出る誤った方向へのシフトは、リソース浪費や、開発生産性悪化につながる • 過剰なリスクコントロールや使われない保守性の実装はリソースを浪費させる • シーケンシャルプロセスでの上流の完璧な品質確保は、開発のスピードやレジリエンス、コスト効率を損ない、開発リソースを使い果たす形で、品質を損なう ⚫シフトレフトでは、適切なあるべき姿を明確化して、バックキャストで施策
を推進する必要がある 16

シフトレフトを実現する施策 17

シフトレフトを支える施策 ⚫品質マネジメントの適時性の向上ウォーキングスケルトン • 早期の品質フィードバックテストピラミッド • 反復型プロセス開発者テスト強化 •

早期の品質フィードバック ⚫シフトレフト推進では、有効な品質フィードバックをなるべく早期に行うのが有効 ⚫早期フィードバックで品質の問題・リスクの早期識別・早期対応につながる 20

早期の品質フィードバック：反復型プロセス ⚫反復型開発プロセスは早期の品質フィードバック確保に有効品質評価工程が最終盤でなく、早期から反復して実施されるシーケンシャル型反復型 21

早期の品質フィードバック：反復型プロセスただ反復すればよいわけではない ⚫有効・妥当な品質評価を早期から行うことでシフトレフトに貢献 • 反復ごとにテスト可能なリリースを確保し、有効な品質フィードバックを確保 • 避けるべきアンチパターン： • リリーススプリント肥大化、全体統合後回しのインクリメンタル開発、アジャイル形骸化（例：ゾンビスクラム）
⚫反復型プロセスで「早期からの有効・妥当な品質評価」を支える施策 • 早期からのユーザ視座のフィードバックの確保 • ユーザ・代理ユーザのテスト確保、顧客満足のテスト観点注力 • 早期からのシステム視座のフィードバック確保 • 包括的な品質評価を実施 • 反復内にテストを収めるためのテスト効率化 • 自動テスト比率向上、探索的テスト能力向上、CI/CD整備、リスクベースドテスト 22

早期の品質フィードバック：反復型プロセス：ウォーキングスケルトンの実現 ⚫反復型プロセスで、有効な品質フィードバックを早期から得るためには、粒度の大きなテストレベル（システムテストやE2Eテスト）を早期から作りかけ状態でも実施できるようにする必要がある ⚫そのためにはアーキテクチャでウォーキングスケルトン（作りかけでもシステムを実行可能にする仕組み）をサポートするのが重要 • 依存関係の最適化/疎結合の推進/アーキテクチャ界面の標準化 •
仮想化/テスト環境・テストツールのサポート/テストダブル開発 • テスト容易性の確保 23

早期の品質フィードバック：反復型プロセス：ウォーキングスケルトンの実現疎結合・高凝集アーキテクチャで分離実行をサポートするアプリケーションフレームワークアプリウォーキングスケルトン実現アプリ
アプリテストダブルフレームワーク OS/基本サービス OS/基本サービスハードウェア制御部 HAL ハードウェアテスト阻害要因や未実装部分は分離し、置換の仕組み（DIなど）を設け、テストダブルに置換ハードウェア制御部ハードウェアモジューラーアーキテクチャ指向を取り入れフィーチャ単位でも分離・置換実行可能にする組込みシステムでのウォーキングスケルトンの例テスト容易性に優れた技術スタックを選定する例）エミュレータ対応等アーキテクチャレベルで接合部を設け、環境仮想化などテスト技術を導入可能にする 24

早期の品質フィードバック：CI/CDの整備 ⚫CI/CDデプロイメントパイプラインは品質フィードバック迅速化の常識的な基盤 ⚫シフトレフト効果増大のため「デプロイメントパイプライン中心志向」が重要 • デプロイメントパイプラインを前提とした開発プロセスを構築する • 開発活動を可能な限り自動化・仮想化し、デプロイメントパイプラインに組み込む • 変更からデプロイまでの品質活動をデプロイメントパイプラインで一気通貫に行う ⚫「デプロイメントパイプライン中心志向」実現を支える施策
• プロダクト、プラットフォーム、環境をCI/CD前提にする • コード化。環境ならIaC対応 • 仮想化対応 • 自動化/自動テスト容易性・自動デプロイ容易性の作りこみ • 開発活動を自動処理に移管する • 開発プロセス設計を工夫する • 活動はなるべく自動化可能な工程に移動させる • 例）品質評価は手動テストではなく、なるべくユニットテストや自動統合テストで対応 25

早期の品質フィードバック：体系的テスト ⚫体系的テスト • 開発ライフサイクル全体のテストを体系的に運用し、全体最適を目指す • 全体構造はテストアーキテクチャとも呼称される ⚫シフトレフトを促進する体系的テストの方針 • シフトレフトを促進するテストの責務を大きくする •
シフトレフトを促進するテスト： • 自動化され、CI/CDに統合可能 • 早期から実施可能 • （できれば）ユーザ価値に近い評価が可能 • シフトレフトを阻害するテストの責務を小さくする • 例）自動テストの拡充に応じて手動テストを縮小する 26

早期の品質フィードバック：体系的テスト：テストピラミッド ⚫ユニットテストや統合テストのサイズ比重を重くする • 実施タイミングが早く、実行も速いため、品質フィードバックのシフトレフトに貢献 ⚫留意点：最適なモデルは開発のコンテキスト依存 • 静的解析に比重を置いたテストトロフィーや、統合テストを主軸にする運用もしばしば有効。AI駆動開発では逆三角形型が推奨される場合も UIテスト
統合テストユニットテスト Mike Cohn、「Succeeding with Agile: Software Development Using Scrum」速い・早い 27

早期の品質フィードバック：体系的テスト：開発者テストの強化 ⚫開発者テスト：開発者による開発のためのテスト • 例）TDD、ユニットテストを活用したリファクタリング、継続的テスト • 実装初期から早期に実行される • CI/CDに組み込むことで、チーム資産として継続運用できる ⚫テストの責務をなるべく開発者テストで果たすことでシフトレフト促進
⚫開発者テストを強化するアプローチ：組織文化醸成が必要 • ソフトウェアチーミング（モブプログラミング）による知見や習慣の共有 • テスト駆動開発、AI駆動開発といった良いプラクティスの定着 • CI/CDによる継続的な下支え • バグ流出を分析して改善サイクルを回し、テストの有効性を担保する Gerard Meszaros、「xUnit Test Patterns: Refactoring Test Code」 28

早期の品質フィードバック：体系的テスト：静的テストの強化 ⚫静的テストは早期から実行可能 • 動くソフトウェアがなくても実施可能/顕在化していない欠陥を直接見つけられる • 品質についてのさまざまな学びが早期から得られる ⚫静的テストの有効性の強化はシフトレフトにつながる • 技術・環境強化
• 各種静的解析ツールやAI活用、CI/CDやPRと連携 • 静的テスト容易性確保 • 静的解析ツール対応、ツールやAIに合わせたドキュメント・構成管理の整備 • 観点の改善 • スリーアミーゴスレビュー、Wモデル、パースペクティブベースドレビュー • コミュニケーション効果・シナジー効果の引き出し • ソフトウェアチーミング（モブプログラミング） 29

早期の品質フィードバック：体系的テスト：静的テストの強化：開発工程レビューへのテストの視座の注入 ⚫仕様作成・設計段階にテストの視座を注入するとシフトレフトに貢献 • 仕様・設計バグの予防・早期検出。リスクの早期識別・コントロール • テスト容易性要件の反映 ⚫テストの視座の注入手段 • テスト分析・設計活動を早期から着手する
• Wモデル、受け入れテスト駆動開発、ふるまい駆動開発 • テストについての観点を強化する • テスト活動のシナリオを使ったパースペクティブベースドレビュー 30

早期の品質フィードバック：体系的テスト：静的テストの強化：開発工程レビューへのテストの視座の注入 ⚫例）ユーザーストーリ作成時にテストの視座を注入するユーザストーリをテスト担当交えて共同作成 or 作成直後にテストの視座でレビューするユーザーストーリ：検索履歴の呼び出し「システム利用者として、過去の検索履歴の一覧を表示し、履歴の検索構文を選択して再実行できる。それにより、以前検索し
た内容をすばやく実行できるようにする」テスト視座から問題検出・対応境界値テストを考える。表示履歴数の最小値・最大値を確認し、受け入れ基準に明記するテストに必要な情報を確保する。詳細なUI仕様を確保・補完するリリース判定の観点でチェックする。「検索履歴の削除」「検索履歴のセキュリティ」など、関連するユーザーストーリや仕様の存在を確認し、不足があれば是正する 31

品質の積み上げ ⚫プロセスやアーキテクチャの工夫で、積み上げるように品質を作りこめる ⚫品質の積み上げを実現すると、早期からの品質確保が容易になり、シフトレフトが促進される ⚫品質の積み上げのアプローチ • 工程品質の積み上げ • コンポーネント品質の積み上げ 33

工程品質の積み上げ ⚫各工程ごとに品質の責務を果たす。後工程に品質面で迷惑をかけない • 従来の「品質の積み上げ」「自工程完結」 ⚫各工程の責務を明確化した上で、工程活動の適正化（品質を作りこむ）と、工程内の品質評価の充実を進めて実現工程品質の積み上げでない開発工程品質の積み上げを実施してる開発 34

コンポーネント品質の積み上げ ⚫各コンポーネントの品質確保を積み上げて、全体の品質を担保する • 必須の前提：高凝集・疎結合なコンポーネントでアーキテクチャを構築する • 各コンポーネントごとの品質確保・品質保証を充実させる品質疎結合・高凝集アーキテクチャでシステムを部品分けする時系列
部品の品質確保を積み上げて全体の品質を担保する 35

コンポーネント品質の積み上げ：疎結合・高凝集アーキテクチャ ⚫コンポーネント品質の積み上げは、疎結合・高凝集アーキテクチャが必須の前提となる • 疎結合でないアーキテクチャ • コンポーネントを横断する問題やリスクが悪化する品質が多数のコンポーネントに複雑に依存する →コンポーネントの品質を高めても、プロダクトの品質に直結しにくくなる
• 高凝集でないアーキテクチャ • コンポーネントの品質とシステム視点の品質が乖離するシステム視点の品質が依存するコンポーネントが複雑化する →コンポーネントの品質を高めても、システム視点（ユーザ視点）の品質に貢献しにくくなる 36

コンポーネント品質の積み上げ：疎結合アーキテクチャ：副作用の局所化 ⚫副作用の影響範囲を特定コンポーネントに局所化する • 副作用：意図した直接の出力とは別におこる作用 • グローバルな変数の更新 • 静的な変数の更新 •
共有するリソースやデータの更新 • I/O の実行 • バッファオバーフローといった異常状態の発生 • 処理の遅延 • 上記を発生させる関数の呼び出し ⚫副作用の局所化により、コンポーネントを横断する問題が削減される ⚫個々のコンポーネントの品質の作りこみに注力できるようになり、コンポーネント品質の積み上げが容易になる 37

コンポーネント品質の積み上げ：疎結合アーキテクチャ：副作用の局所化 ⚫副作用の局所化の推進手段：主に設計の工夫で推進する • 変数やリソースなどの状態のスコープを小さくする • 静的な状態を少なくする • 横断的に共有される状態、静的な状態は、操作処理や、ガードといった防御的設計をまとめたオブジェクトとしてカプセル化する。状態更新についての防御的設計を
複数に散在させない • 妥当な範囲で、参照透過性や不変性を確保する。例えば純粋関数（入力だけで出力を決め、外部に他の影響を発生させない関数）や、不変オブジェクト（初期化以外で状態を更新しない）として処理を実装する • バッファオーバーフローといった異常状態については、開発言語機能、型システム、コーディングルール、静的解析といった多重の手段で解消を目指す • 不確実性を適正化する。例えば非同期処理でsleepによるタイミング調整を避けるなど 38

コンポーネント品質の積み上げ：疎結合アーキテクチャ：バルクヘッドパターン ⚫実行環境のキャパシティやリソースを分割し、コンポーネントやサービスを疎結合にする。特定のコンポーネントに問題が発生しても、他のコンポーネントへの悪影響を遮断する • 船舶のバルクヘッド（隔壁。浸水しても他への浸水の伝播をブロックする）に由来 ⚫バルクヘッドの実装例 • 物理サーバの分離。リージョンごとにサーバを分割する等
• コンテナの分離 • プロセッサコアの分離。プロセスごとにコアをバインドする • 実行プロセスやスレッドの分離 ⚫バルクヘッドパターンを導入すると、悪影響が局所化される。コンポーネントの品質確保が、システムの品質確保につながりやすくなる Michael Nygard、『Release It! Second Edition: Design and Deploy Production-Ready Software』 39

コンポーネント品質の積み上げ：疎結合アーキテクチャ：サービス志向アーキテクチャ ⚫バルクヘッドパターンを採用しやすいアーキテクチャ ⚫ビジネスに紐づいたサービスごとに構造的にコンポーネントを分離 • コンテナや実行プロセスを分離 • デプロイを分離 ⚫サービスごとに独立して品質を作りこむことで、プロダクト全体の品質に貢献できるようにする
40

コンポーネント品質の積み上げ：疎結合アーキテクチャ：プロダクトリスクの分離 ⚫リスクレベルの高いプロダクトリスクを、特定のコンポーネントに局所化 • リスクレベルの高い責務を特定のコンポーネントに割り当てる • プロダクトリスクの発生要因を特定のコンポーネントに閉じ込める。構造的に分離したり、防御的設計を充実させる ⚫特定のコンポーネントの作りこみで、システムのリスクコントロールに貢献特定のコンポーネントの作りこみで、
品質リスクのコントロールができるようになる 41

コンポーネント品質の積み上げ：疎結合アーキテクチャ：プロダクトリスクの分離：ソフトウェア安全性クラスの分離 ⚫医療機器ソフトウェア開発のアプローチ • ソフトウェアを疎結合のソフトウェアアイテムに分離し、ソフトウェアアイテムごとにソフトウェア安全性クラスを評価する • ソフトウェア安全性クラスに応じて、ソフトウェアアイテムのプロセスや品質基準を別々に使い分ける
ソフトウェアクラスC ソフトウェアクラスC Cクラスのアイテムに厳しい品質基準を適用して、全体の安全性を担保するソフトウェアクラスC ソフトウェアクラスB ソフトウェアクラスA Aクラスのアイテムには軽快な品質基準を適用して、開発スピードを確保する JIS T 2304：2017 日本工業規格、『医療機器ソフトウェアソフトウェアライフサイクルプロセス』 42

コンポーネント品質の積み上げ：高凝集アーキテクチャ：システム品質の凝集度を高める ⚫システム品質について凝集度を高め、コンポーネント品質の積み上げでシステム品質が高まるようにする ⚫ビジネス視座について凝集度を高め、コンポーネント品質の積み上げでビジネスの競争力が高まるようにする UI サービスサービスサービス
例）マイクロサービスアーキテクチャビジネスの視座でサービスを組み、独立して開発・デプロイ可能にする 43

コンポーネント品質の積み上げ：高凝集アーキテクチャ：システム品質の凝集度を高める：ドメインプリミティブ設計 ⚫プリミティブ型（intなど）を使用せず、ドメインに合わせた型を用意・使用する。ドメインの型にはバリデーションを組み込み、オブジェクトに問題がない状態を実現する • 品質の実現もドメインに合わせた型に集約する • 型やオブジェクトの作りこみで、システム視点の品質を積み上げられるようになるドメインに合わせた型
セキュリティの責務セキュリティの責務セキュリティの責務ドメインに合わせたオブジェクトに集約セキュリティ担保の仕組みセキュリティの責務コンポーネント品質の積み上げでセキュリティ確保しにくい Dan Bergh Johnsson, Daniel Deogun、「セキュア・バイ・デザイン安全なソフトウェア設計」 44

コンポーネント品質の積み上げ：高凝集アーキテクチャ：システム品質の凝集度を高める：ドメインプリミティブ設計 class User { ドメインプリミティブでない設計 private: const std:: string
name_; const int age_; public: User(const std:: string& name , int age) : name_(name), age_(age) {} ドメイン固有の型を定義する std:: string getName () const { return name_; } 不変オブジェクトにし、入力バリデーションを実装して品質担保 int getAge () const { return age_; } 名前はこの型のみで宣言することで、名前についての品質担保を ... さまざまなメソッド... UserNameクラスに集約する }; ドメインプリミティブ設計 class UserName { private: const std:: string value_; static std:: string validate(const std:: string& val) { if (val.length () < 1 || val.length () > 20) { throw std:: invalid_argument ("name must be between 1 and 20 characters "); } return val; } public: explicit UserName(const std:: string& val) : value_(validate(val)) {} std:: string value () const { return value_; } 45 };

ソフトウェアエンジニアリングの適正化 ⚫シフトレフトはテスト工程やレビュー工程の強化・前倒しに限定されない。最初から問題を作りこまないのが重要 • 設計工程の場合： • 第一に優先すべきは、優れた設計者の確保、前提となるアーキテクチャや要件定義の改善、設計アプローチの洗練、設計制約の緩和、ガードレールの整備。また構成管理システムやAI活用など直接サポートする仕組みの整備 •
次点でレビューやテストの強化 ⚫シフトレフトは、ソフトウェア開発ライフサイクル全体のソフトウェアエンジニアリングの適正化 ⚫品質マネジメントとしては、適正なソフトウェアエンジニアリングを持続するための仕組み整備に注力する 47

ソフトウェアエンジニアリングの適正化： AI駆動開発 ⚫ソフトウェアエンジニアリングの適正化を進めシフトレフトに貢献する ⚫品質マネジメントとしては多方面の仕組み作りで持続可能な組織活動にする • 情報管理の整備 • コードベース・ドキュメントの整備、Everything as Code、構成管理の整備
• 鮮度・必要十分性・一貫性の確保 • 機密情報のシークレット管理 • ハーネスエンジニアリングの推進 • ルール、スキル、外部情報の整備、ループの形成 • アーキテクチャの工夫 • 関心の分離/分割統治によるコンテキスト境界/作業スコープの明確化 • 品質評価の自動化 • スキャンツールや自動テスト、モニタリングを通したAI成果物の監視 • 技術スタックの工夫 • リスクの低いAIサービスの選択、ハルシネーションの発生の低い技術スタックの選択 • 開発インフラの整備松本淳太郎、サカモト、金剛洙、「プロフェッショナルAI駆動開発 • 開発コンテナ整備によるリスクコントロールの整備確率論から決定論へ AIの揺らぎを制御する開発フレームワーク」仕組みでエンジニアリングを適正化し、シフトレフトを促進する 48

開発容易性の作りこみ ⚫プロダクトの保守性・運用性を作りこむと、以降のプロダクトの開発・運用のスピードやコスト、レジリエンスを改善できる ⚫備えとして間接的にシフトレフトに貢献できる保守性についての特性（ISO/IEC 25010）品質特性内容運用性についての特性品質特性
内容再利用性再利用のしやすさ監視性モニタリングのしやすさ解析性問題の解析・特定のしやすさ柔軟性スケーラビリティや置換の容易さ修正性変更や修正のしやすさ互換性相互運用性や環境との競合性試験性（テスト容易性）テストのしやすさデプロイ容易性デプロイのしやすさ・容易性モジュール性結合性の低さ・凝集性の高さ運用リスク管理性運用に関わるリスクのコントロールしやすさ 50

開発容易性の作りこみ：シフトレフトにとって妥当な開発容易性の確保が必要 ⚫過剰・無駄な保守性・運用性の実装は、コストやリソースを悪化させ、シフトレフトを阻害する • 例） • 負債化したフィーチャトグル。アーキテクチャを複雑化させる。効果的なポイントに実装しないと費用対効果がマイナスに •
過剰なレイヤドアーキテクチャ。オーバーヘッドなどで性能効率性が悪化 • Mock Hell：Mock開発や接合部確保のコストが過剰にかかるほか、テストしているのがプロダクトかMockか混乱する ⚫シフトレフトに必要な保守性・運用性の要件を見極め、必要十分な確保を行う必要がある 51

開発容易性の作りこみ：保守性・運用性を確保すべきポイントポイント内容常識的に確保すべき最低限のリテラシー・常識として確保例）クローンコードを避ける、命名は適切にする、複雑な構造を避け可読性を確保する計画上
確保すべき計画される保守・運用活動に対する備え例）プラットフォーム切り替えを計画しているならば、プラットフォーム依存部を抽象化するリスクに対し識別されたリスクに対する備えて確保すべき例）脆弱性リスクが高い場合、ゼロトラストアーキテクチャを志向する確保方針常識として確保する計画に従って確保する費用対効果に基づいて確保するリスク分析・リスクマネジメントに従って確保する上記に当てはまらないものはシフトレフトを阻害するリファクタリングを実施すべきかの判断基準にもなる 52

開発容易性の作りこみ：テスト容易性の作りこみ ⚫適切なテスト容易性の確保で： • テストの早期実行が可能になる • 後のテストの作成・実行・保守が容易になる ⚫シフトレフトに貢献 • 例）テスト自動化容易性を確保すれば、早期からリグレッションテストの継続実行が
可能になり、後の追加変更の品質確保をサポートできる ⚫テスト容易性実現手段 • 開発工程へのテスト視座の注入 • アーキテクチャレベルからテスト容易性を組み込む • Wモデル、受け入れ駆動テスト開発、スリーアミーゴスレビュー • テスト容易性についての改善サイクルを早期から回す • 反復型プロセス 53

保守性・運用性の作りこみ：テスト容易性の作りこみ品質特性内容具体例観測容易性テスト対象の観測のしやすさエラーログの充実度制御容易性テスト対象の操作のしやすさ
APIの充実度セットアップ容易性テストのセットアップのやりやすさコンストラクタの単純さ実行容易性実行の容易さテスト実行のブロック要因の少なさ分解容易性テスト対象の分割・置換の容易さ接合部の充実度網羅容易性テストでの網羅のしやすさデッドコードの少なさ安定性テスト対象の安定性・バグの少なさ変更頻度の少なさ環境構築容易性テスト環境の構築のしやすさ環境の冪等性問題検出性バグの特定のしやすさ解析ログの充実度対象によってより具体的な品質特性がある。例）自動化：仮想化容易性、並列化容易性、CI/CD統合容易性 54

開発容易性の作りこみ：テスト容易性の作りこみ：Humble Objectパターン ⚫自動テストの障害を局所化し、実行容易性・分解容易性を改善するテスト困難なプロダクトコード Vladimir Khorikov 、『単体テストの考え方/使い方』 Humble Object導入
55

開発容易性の作りこみ：アーキテクチャの整備 ⚫アーキテクチャは保守性・運用性を持続的に支え、シフトレフトをサポート • 抽象度高く全体の仕組みを工夫できる • 例）サービスアーキテクチャを導入しサービスごとにデプロイを分離すると、コンポーネント品質の積み上げや、デプロイの迅速化が促進される • 例）仮想環境対応など早期テストが可能な技術スタック選定を行うと、テストの
フィードバック確保を前倒しできる ⚫ユーザやビジネスの展望に基づいて必要な保守性・運用性を見定め、それを支えるアーキテクチャを構築するのが、シフトレフトにとって重要 57

開発容易性の作りこみ：アーキテクチャの整備：プロダクトライフサイクルを予期した界面設計この界面を設計したいハードウェアバリエーションの増大や、通信仕様の改訂が予期されるプロダクト 58

開発容易性の作りこみ：アーキテクチャの整備：プロダクトライフサイクルを予期した界面設計（ダメな例）アプリーケーションが通信ドライバに直接依存する界面設計方針を取ると… ハードウェアバリエーションの増大や、通信仕様の改訂が予期されるプロダクト ×ハードウェアバリエーション追加や通信仕様改訂が入るたびにアプリケーションに大きな変更が発生。シフトレフトに逆行 59

開発容易性の作りこみ：アーキテクチャの整備：プロダクトライフサイクルを予期した界面設計（良い例）依存性逆転の原則遵守でハードウェアがアプリケーションに依存する設計で統一すると… ハードウェアバリエーションの増大や、通信仕様の改訂が予期されるプロダクト〇ハードウェアバリエーション追加や通信仕様改訂に際しても変更が局所化され、品質リスク軽減 →シフトレフト貢献
60

開発容易性の作りこみ：開発基盤の整備 ⚫開発基盤は開発容易性を大きく左右するまた開発基盤を含めた仕組み（マネジメントシステム）は、シフトレフトの施策の持続性を支える ⚫開発の総合力の向上には、シフトレフトを支える開発基盤の整備が重要 62

開発基盤の整備：コンテキストに合わせたQMS ⚫シフトレフトを促進する活動は、品質マネジメントシステム（QMS）として仕組み化してこそ持続可能になる • 品質についての方針、MVV、計画 • プロセス • 体制、リソース
• インフラやサポートシステム ⚫QMSは開発のコンテキストに合わせたものを構築するのが重要 • 立ち上げ初期のＰＳＦやＰＭＦの時期は軽量な仕組みで • 医療機器など法規制の強い開発では、法規に基づいた厳格な仕組みで • ＱＭＳのネガティブイメージは、コンテキスト無視の鈍重な仕組み強制で発生 63

開発基盤の整備：コンテキストに合わせたQMS：シフトレフトに合わせたQMS シフトレフトを阻害するQMS シフトレフトを促進するQMS 品質管理・プロセスとして詳細な作業手順を指定する・マイクロマネジメント的に、作業手順からの逸脱を許さない・ガードレール（型システムなどの制約、PRと静
的テストの組み合わせ、アーキテクチャ検査、開発コンテナ）を整備し、スピード重視の開発を許容しつつ品質確保・仕組みでゴールデンパス（ベストプラクティス）に誘導品質評価・後工程に品質ゲートを設ける・品質に問題がある場合は開発をブロックし工程を差し戻す・品質の積み上げで早期から品質を担保する運用・人が目視・手動で監査・運用開発インフラ、開発プラットフォームとして実装。ツールやサービスでサポートを自動化する適切なQMSで、適切なシフトレフトを持続的活動として定着できるようになる 64

開発基盤の整備： CI/CDデプロイメントパイプライン ⚫デプロイメントパイプラインは現代的なソフトウェア開発の骨格シフトレフトにおいて必須・常識のインフラ • 自動化による変更からデプロイまでのリードタイム短縮 • 迅速なデプロイの実現 • 例）ローリングアップデート、カナリアデプロイメント
• 早期テストの早期実行 ⚫デプロイメントパイプライン中心志向での開発プロセス構築が重要 • なるべく多くの開発活動を自動化し、デプロイメントパイプラインに統合するのがシフトレフトに有効 Jez Humble、David Farley、『継続的デリバリー』 65

あるべき品質への方向付け ⚫シフトレフトは正しい方向にシフトしてこそ効果がある • 顧客満足を実現しビジネスを成功させる品質実現への貢献が重要 ⚫あるべき品質を見極め、その方向に向かうように、早期からのチームの舵取りを行うのが重要 67

あるべき品質への方向付け：ビジネス・ユーザ・開発・運用のすり合わせ ⚫あるべき品質は顧客満足を実現する品質だけではないビジネス・ユーザ・開発・運用のすり合わせの最適解を目指すユーザプロダクト利用についてのニーズ投資対効果組織の持続性・成長性ビジネス
あるべき品質どこまで支えられるか運用容易性開発何をどこまで実現できるか開発容易性運用 68

あるべき品質への方向付け：ビジネス・ユーザ・開発・運用のすり合わせ ⚫共通言語を形成する • 全体に共通するバリューメトリクス（本当に価値のあるメトリクス）でKPI定義 • 全体を横断する言語の確立：ユビキタス言語、DSL、概念モデル、ビジネスモデル ⚫一緒に力を合わせる • 一緒に評価する：スリーアミーゴス、ふるまい駆動開発
• トレードオフの合意形成：アーキテクティング ⚫相互に越境する • 越境する組織設計：FDE、プロダクトオーナー • 異なるドメインの知見取り込み：ユーザテスト ⚫横断するフィードバックサイクルを形成する • 開発と運用を横断するサイクルを回す：仮説検証、DevOps 69

あるべき品質への方向付け：開発と運用のフィードバックサイクル ⚫チャレンジを伴うソフトウェア開発では、開発と運用のフィードバックサイクルを反復することで、あるべき品質が見えてくる ⚫そのためにも運用とシフトライトテストを整備し、運用/ユーザサイドから有効なフィードバックを確保するのが重要 • 現代的なデプロイの実現 • フィーチャフラグ、カナリアリリース、軽快なロールバック
• シフトライトテストの実現 • ユーザ調査・市場調査の充実 • 顧客満足の評価/クレーム調査/継続的なプロダクトモニタリング • 改善要望の収集 70

あるべき品質への方向付け：プロアクティブアプローチの確立 ⚫シフトレフトは未然防止や早期のリスクコントロールが有効。その実現のためにはプロアクティブアプローチ（先読みして先手を打つアプローチ）の精度を高める活動がシフトレフトに求められる ⚫プロアクティブアプローチの推進手段 • 予兆・トレンド分析によるリスクマネジメント • トレンドパターンの監視（例：リソース使用率やキュー滞留数の悪化、サチュレー
ションの監視） • 問題蓄積の監視（例：エラーカウント/エラーバジェットの累積傾向） • 弱点の監視（例：死活監視やレスポンス評価） • プロアクティブテスト（能動的に干渉してその反応を見る） • カオスエンジニアリング • 過去の知見の活用 • 過去の障害やトラブルからの逆引き予測：FTA • サンプリングによる推定（例：探針） 71

あるべき品質への方向付け：プロアクティブアプローチの確立：有効な先行指標を見出す ⚫バリューメトリクス（基本的に遅行指標）に関係する先行指標を見出すことで、先行指標に基づいたプロアクティブアプローチが可能になる • 開発と運用の仮説検証サイクルを回し、プロダクト成功のモデルの解像度を高める • バリューメトリクスの因果関係・モデルを分析し、原因や因果のロジックを見出す • 五ゲン主義で、現地現物現実から原理・原則を見出す
バリューメトリクスアクティブユーザ数、離脱率、クレーム数、成約率、営業利益… 相関・因果先行指標ユーザテスト結果、コード品質、欠陥流出率、テスト密度… 72

あるべき品質への方向付け：プロアクティブアプローチの確立：オブザーバビリティの整備 ⚫プロダクトのオブザーバビリティを作りこむと、シフトライトテストや運用の評価が容易になり、開発と運用のフィードバックサイクルが適正化する →知見が蓄積しプロアクティブアプローチの精度が高まる ⚫オブザーバビリティの整備アプローチ • モニタリング基盤の構築 • APMなどのプロダクト監視ツールの導入
• インフラやネットワーク監視ツールの導入 • ロギングといったプロダクトの監視機能の作りこみ • ビジネス・ユーザ体験の評価手段の確立 • アンケートやNPS（Net Promoter Score）サーベイの手段の確立 • ビジネス指標の定量化 • オブザーバビリティの品質要件・指標の明確化 • 適正なSLAやSLOの明確化 73

まとめ ⚫品質マネジメントの適時性の向上ウォーキングスケルトン • 早期の品質フィードバックテストピラミッド • 反復型プロセス開発者テスト強化 •

高品質と高スピードを支える品質のシフトレフトのアプローチ

高品質と高スピードを支える品質のシフトレフトのアプローチ

Hiroki Iseri

Transcript