森崎 修司 名古屋大学 大学院情報学研究科 バグ分類に合わせた品質評価 エビデンスにもとづくシフトレフトとシフトライトテスティング 

森崎 修司 - 自己紹介 • 名古屋大学 大学院情報学研究科／ティアフォー技術顧問 • 小学5年生からプログラミングを始める • 2001年 奈良先端科学技術大学院大学 情報科学研究科 博士後期課程修了 • エンジニアとして: ソフトウェア開発（2001～） • 研究者として: 実証的ソフトウェア工学の研究（2005～） – 55社と機密保持契約ベースの共同研究 – 11名の社会人博士の学位取得、審査に従事 – 元エンジニアだからこそ設定できるテーマを目指している。 2 

アジェンダ • バグ分類と品質評価 – 検出方法とタイミング: 未然防止、レビュー、テスト、リリース後 – バグの分類 • 過去のバグの共通点から • ユーザ価値を損なうようなバグから • 事例 – プログラミングで注意が必要な部分をモデル図から特定 （ソニーグローバルマニュファクチャリング&オペレーションズとの共同研究） – 可読性向上の度合いからリファクタリングの優先順位決め （エンジニアコミュニティの方々57名、和田卓人氏との共同研究） – 自動車の自動運転ソフトウェア開発におけるV&V戦略 （ティアフォーとの共同研究、同社技術顧問） 3 

ひとことで言えば… 4 問題を防ぐ方法、バグや問題 を見つける方法 バグ分類（欠陥タイプ） 品質評価（検出方法） 起こりそうなバグ・問題 

ひとことで言えば… 5 起こりそうなバグ・問題 問題を防ぐ方法、バグや問題 を見つける方法 バグ分類 品質評価 （検出方法） 

バグ分類と品質評価方法の例: 境界値分析 • 仕様に沿ってプログラムを書くときに、条件分岐の境界値を間違って実装しやす いので、その境界値をテストするとバグをみつけやすい（経験則）。 例） – 仕様の例 「18歳未満であれば未成年、18歳以上であれば成年」 – 条件分岐の例「if (age < 18) { print(“未成年”)}else{print(“成年”);} 」 – 境界値の例「17, 18, 19」 6 プログラムを書く時点 （バグの混入） テスト （バグの検出） コードレビュー （バグの検出） コードレビューで検出する場合 テストで検出する場合 検出工数をはじめ合理的 な品質評価方法を選ぶ 品質評価（未然防止、検出の方法） 

もう一度… 7 仕様とプログラムで条件分岐が一致しない ペアプログラミング （未然防止） バグ分類 品質評価 条件分岐の境界となるような 値をテストする（検出） 条件分岐の境界となる部分を コードレビューで確認する（検出） 適切な方法を1つ以上選ぶ 起こりそうなバグ・問題 問題を防ぐ方法、バグや問題 を見つける方法 バグ分類 品質評価 

バグ分類と品質評価方法の例: 境界値分析 • 仕様に沿ってプログラムを書くときに、条件分岐の境界値を間違って実装しやす いので、その境界値をテストするとバグをみつけやすい（経験則）。 例） – 仕様の例 「18歳未満であれば未成年、18歳以上であれば成年」 – 条件分岐の例「if (age < 18) { print(“未成年”)}else{print(“成年”);} 」 – 境界値の例「17, 18, 19」 8 プログラムを書く時点 （バグの混入） テスト （バグの検出） コードレビュー （バグの検出） コードレビューで検出する場合 テストで検出する場合 ②検出の手間や影響の大きさ等か ら合理的な検出方法を選ぶ ①ミスがなければ、 境界値テストの 効果は下がる プログラムを書く時点で未然防止 リリース後 （問題／バグの検出） 使い始めてから変更する場合 

バグ分類と品質評価方法 • 多くの場合、テストやレビューで包括的に検出する。 • 特に注意が必要な場合には、バグ分類を意識することが多い。 9 仕様どおりにプログラムの条件分岐が書けていない バグ分類 ペアプログラミング （未然防止） バグの未然防止や検出方法 （品質評価方法） ユニット テスト コード レビュー システムテスト 自動生成 （未然防止） 合理的な方法を選択、併用 A/Bテスト／ カナリアリリース リリース後の フィードバック シフトレフト シフトライト 成年のときの処理 未成年／成年の チェック 未成年のときの処理 シフトレフト テストアーリー チェック単体のテスト チェックとその後の処理を含めたテスト 

バグ分類と品質評価方法 • 多くの場合、テストやレビューで包括的に検出する。 • 特に注意が必要な場合には、バグ分類を意識することが多い。 10 バグの未然防止や検出方法 （品質評価方法） アクセス集中時に不安定になる プロトタイプによる 評価（未然防止） コード レビュー ストレス テスト 集中度合いの見積り （未然防止） 段階的 リリース α／β リリース アーキテクチャ レビュー 合理的な方法を選択、併用 リリース後の フィードバック 仕様どおりにプログラムの条件分岐が書けていない バグ分類 ペアプログラミング （未然防止） ユニット テスト コード レビュー システムテスト 自動生成 （未然防止） A/Bテスト／ カナリアリリース リリース後の フィードバック 

品質評価方法の選択 • 品質評価方法が複数あれば、合理的な方法を選ぶ（必要であれば併用）。 選ぶ基準の例） – 簡単に検出（評価）できるか？ – 低コストで検出（評価）できるか？ – リスク低減／ユーザ価値向上につながるか？ 11 混入 検出方法B 未然防止できなければ混入する コスト 未然防止 検出方法A 合理的な（たとえばコストが小さい）方法で未然防止するか検出する 

まとめ: 品質評価方法の選択 • バグ分類／問題分類を考え、品質評価方法を選ぶことがシフトレフト、シフトライト の検討につながる。 12 検出方法B 評価方法Q 検出方法A 評価方法P 検出方法／評価方法を選ぶことが、シフトレフト／シフトライトを選んでいることになる ↓ 単に「シフトレフト／シフトライト」を考えるのではなく、リスクやコストの合理性から考える リリース 

13 バグ分類を直接選定する方法(D) (D-1)過去のバージョンや類似のシステムでのレビュー指 摘や検出されたバグを参考にする (D-2)システムの構成や要素技術が共通する他のシステ ムのレビュー指摘や検出されたバグを参考にする 保証すべき内容を明らかにし、それ を損なうバグ分類を選ぶ方法(I) (I-1)提供できていない保証内容、提供することを明示して いる保証内容から、それを損なうバグ分類を見つける (I-2)システムが担うビジネスや業務、環境から期待される 価値を見つけて、その提供を損なうバグ分類を見つける バグ分類の設定方法 出典: 森崎 修司: なぜ重大な問題を見逃すのか？ 間違いだらけの設計レビュー 第3版, 日経BP(2023) 

D-1: バグ分類の設定例 – 過去のバグ情報 • 類似のバグ／問題を探して一般化する。 • 一般化した問題を検出すべきバグ分類とし、それを評価する方法を考える。 バグ分類の例） 過去の指摘リストのうち「カード」を含む指摘 14 指摘内容 指摘ID カード決済用ネットワークの通信プロトコルとして想定しているプロトコルの記述が漏れている 012 カード決済用ネットワークの選択基準が記述されていない 028 Webから注文された場合のカード決済用のタイムゾーンが定義されていない 042 カード決済時の分割払のオプションがない 049 16桁以外のカード番号が想定されていない 081 

D-1: バグ分類の設定例 – 過去のバグ情報 • 例） 過去のバグリストのうち「カード」を含む指摘 – 012と028から問題種別「必要なカード決済用ネットワークと通信プロトコルが明らかに なっていない」を設定する。 – 049と081、その他の問題から問題種別「カード決済に必要な情報や条件が揃って いない」を設定する。 15 指摘内容 指摘ID カード決済用ネットワークの通信プロトコルとして想定しているプロトコルの記述が漏れている 012 カード決済用ネットワークの選択基準が記述されていない 028 Webから注文された場合のカード決済用のタイムゾーンが定義されていない 042 カード決済時の分割払のオプションがない 049 16桁以外のカード番号が想定されていない 081 

D-2: バグ分類の設定例 –類似アーキテクチャ • 前日の売上げから翌日の出荷量を決めるシステムがある。 • 東日本統括サーバ、西日本統括サーバで集めた日次の集計結果を集約して データベースに蓄積する。 東日本統括(A) 西日本統括(B) 拠点A1 拠点A2 拠点An ･･･ 拠点B1 拠点B2 拠点Bn ･･･ データベース 16 

D-2: バグ分類の設定例 –類似アーキテクチャ • 東日本統括サブシステムAで集めた日次の集計結果と西日本統括サブシステ ムBで集めた集計結果をデータベースに蓄積する。 東日本統括(A) 西日本統括(B) 拠点A1 拠点A2 拠点An ･･･ 拠点B1 拠点B2 拠点Bn ･･･ データベース 17 

D-2: バグ分類の設定例 –類似アーキテクチャ • 東日本統括サブシステムAで集めた日次の集計結果と西日本統括サブシステ ムBで集めた集計結果をデータベースに蓄積する。 東日本統括(A) 西日本統括(B) 拠点A1 拠点A2 拠点An ･･･ 拠点B1 拠点B2 拠点Bn ･･･ データベース ネットワークの信頼性は？ 集計できなかったら？ パフォーマンスは？ 東日本だけ、西日本だけしか集計できなかったら？ 18 

D-2: バグ分類の設定例 –類似アーキテクチャ • センサーからのデータを系に分けて、集約する場合にも同じようなことが起こる。 A系センサー 統括部 B系センサー 統括部 センサーA1 センサーA2 センサーAn ･･･ センサーB1 センサーB2 センサーBm ･･･ 統合制御 センサーやネットワークの信 頼性は？ A系、B系のセンサーからの情報を処理できる？ A系だけ、B系だけの情報しか来なかったら？ 

20 バグ分類を直接選定する方法(D) (D-1)過去のバージョンや類似のシステムでのレビュー指 摘や検出されたバグを参考にする (D-2)システムの構成や要素技術が共通する他のシステ ムのレビュー指摘や検出されたバグを参考にする バグ分類の設定方法（再掲） 出典: 森崎 修司: なぜ重大な問題を見逃すのか？ 間違いだらけの設計レビュー 第3版, 日経BP(2023) 保証すべき内容を明らかにし、それ を損なうバグ分類を選ぶ方法(I) (I-1)提供できていない保証内容、提供することを明示して いる保証内容から、それを損なうバグ分類を見つける (I-2)システムが担うビジネスや業務、環境から期待される 価値を見つけて、その提供を損なうバグ分類を見つける 

I-2: 保証すべき内容から設定する例 • 対象: 公共交通機関（企業D）の座席予約システム • システムの特徴 – インターネット、企業Dの窓口、旅行代理店の端末といった連携システムから座席を 予約できる。 – 標準的な予約手順があり、詳細な状態遷移の定義やそれに対応した再利用できる テストがある。 – 予約システムは長期にわたって運用する。 • システムの価値 – 予約と対応する座席に過不足がない。 – 短時間で予約でき、乗客が代理店やインターネットから座席の空きを確認しながら予 約できる。 – システム内部の予約の手順が変更されず長期にわたって保守できる。 21 

I-2: 保証すべき内容から設定する例 • システムの価値 – 予約と対応する座席に過不足がない。 → 予約、解約、参照の間で守られるべき条件が守れているかを確認する。 – 短時間で予約でき、乗客が代理店やインターネットから座席の空きを確認しながら予 約できる。 → 性能要求が損なわれる可能性のある部分を抽出しておき、テストで確認する。 – システム内部の予約の手順が変更されず長期にわたって保守できる。 – → 予約手順が実質的にかわっていないかを確認する。対応する設計やコードの変更 が必要ないかを確認する。 22 

当研究グループでの取り組み • プログラミングで注意が必要な部分をモデル図から特定 （ソニーグローバルマニュファクチャリング&オペレーションズとの共同研究） • 自動車の自動運転ソフトウェア開発におけるV&V戦略 （ティアフォーとの共同研究、同社技術顧問） – 確定していない情報が少ない中でも検出できる問題を明らかにする – シミュレーションテストでの継続的インテグレーションのテスト実行順の工夫 • 可読性向上の度合いからリファクタリングの優先順位決め （エンジニアコミュニティの方々57名、和田卓人氏に協力いただく） – デザインパターン導入により条件分岐を減らす – 紛らわしい命名やコメントの修正 23 

事例のスライドは動画（説明つき）でご覧ください 24 

まとめとお知らせ • まとめ – バグ分類とそれに合わせた品質評価の方法を説明した。 – エビデンスにもとづいた品質評価方法の設定事例を紹介した。 • お知らせ 1. 当研究グループとの具体的な連携（有償の受託・共同研究）を募集しています。 – 論文発表を前提に、レビューの改善、効果計測、組織内ガイドライン作成の支援をしてい ます。 – 詳細な統計データや海外動向との比較ができます。 2. ソフトウェア開発に関する情報発信しています。 – https://blogs.itmedia.co.jp/morisaki/ – https://x.com/smorisaki 38