Updates

新着情報

B'zine

B’zine – 2025年11月号（Webinar開催～生成AIでFMEAを作成してみたら～など）を発行しました

北海道・東北地方では積雪注意のニュースも聞かれますが、温暖化の影響なのでしょうか、関東では街路樹の銀杏がまだ紅葉せずに青々と茂っているところもあります。秋の行楽シーズンも終盤となり、連日のように熊出没情報が出ていますので、十分注意して紅葉狩りをお楽しみください。 B'zine 11月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/3M2FBkmaZB0     B’zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2025年11月号） B’zine 11月号をお届けします。北海道・東北地方では積雪注意のニュースも聞かれますが、温暖化の影響なのでしょうか、関東では街路樹の銀杏がまだ紅葉せずに青々と茂っているところもあります。秋の行楽シーズンも終盤となり、連日のように熊出没情報が出ていますので、十分注意して紅葉狩りをお楽しみください。 【今月のトピックス】 イベント：第６回 ビジネスガレージオープンWebinar開催（11/26） イベント：Webinar EARSを活用した要求の書き方（2026年1月開催予定） コラム：Automotive SPICEの前に考える“要求の肥大化”対策 ～ 要求仕様を明確にする3つのポイント ～ コラム：生成AIはシステム開発・ソフトウェア開発をどう変えるのか？ コラム：車載システム開発における品質保証の進化 － 伴走型QAと現場で作り込む品質 【イベント】 2025年11月26日 Webinar～生成AIでFMEAを作成してみたら～のご案内ChatGPTを活用することで、FMEAの作成期間とリソースを劇的に削減した事例をご紹介します日時：2025/11/26(水) 16:00 – 16:50お申込みはこちらから→ https://www.bgarage.co.jp/news/1496/ 2026年1月 Webinar（予定）：EARSを活用した要求の書き方構文形式を利用することで、書き手と読み手の解釈不一致を防止する要求の文書化手法と事例をご紹介します。 【コラム】  Automotive SPICEの前に考える“要求の肥大化”対策 ～要求仕様を明確にする3つのポイント～「最初は小さな追加だったのに、気づけば手がつけられないほど要求が膨らんでいた。」皆様の現場ではこのような事象に遭遇したことはないでしょうか？いわゆる「要求の肥大化」です。今ではアジャイル開発の普及やツールによるトレース管理などが進み、昔に比べると要求の肥大化そのものは抑制傾向にあります。しかしながら、年々技術の高度化・統合化が急速に進むにつれ、リリース直前にもかかわらず五月雨式に要求が発生するケースは少なくありません。当初の想定を超えた要求が増え続けると、スケジュールは遅れ、品質は落ち、チームの士気も下がります。「うちでは起きていない」と思っていませんか？実は、どんな現場にも“要求の肥大化”の芽は潜んでいるのです。詳細はこちら→https://www.bgarage.co.jp/news/1504/ 生成AIはシステム開発・ソフトウェア開発をどう変えるのか？ 近年、生成AI（Generative AI）は私たちの私生活だけなく、仕事の局面においても利用されるケースが多くなってきました。生成AIは、従来のルールベースや機械学習と異なり、コードだけでなく、人が普段使用する自然言語や画像などを生成する能力をもっています。一方開発現場は、仕様書作成や、コードレビュー、テスト設計、教育資料作成など「知的集約型作業」が多く、生成AIの活用余地が大きい印象があります。今回は、生成AIをどのように開発プロセスに導入していくと良いのかを考察してみました。唯一の答えではなく、あくまでひとつの見解として読んでいただけると幸いです。詳細はこちら→https://www.bgarage.co.jp/news/1524/ 車載システム開発における品質保証の進化 － 伴走型QAと現場で作り込む品質近年、車載システム開発でもアジャイル開発（スクラムなど）の採用が進んでいます。しかし、品質保証（QA）は従来型の方法論に留まり、スプリント外で行われる監査やゲートレビューに偏っているケースが少なくありません。この方法論では、品質リスクが早期に共有されず、リリース直前に重大な問題が発覚することもあります。QAが「最後に合否判定を下す役割」として認識され、開発チームとの距離感が生まれてしまうのです。従来型QAは、品質計画を立て、ゲートレビューや監査で品質基準を満たしているかを確認する役割を担います。これは品質保証の枠組みを維持するために不可欠です。一方、アジャイル開発では短いサイクルで価値を届けることが求められます。その中で、開発と同じリズムで品質を作り込む仕組みが必要です。そこで登場するのが 伴走型QA＝Quality Engineering（QE） です。詳細はこちら→https://www.bgarage.co.jp/news/1522/

コラム

車載システム開発における品質保証の進化──伴走型QAと現場で作り込む品質

車載システム開発におけるアジャイル普及と品質保証の現状近年、車載システム開発でもアジャイル開発（スクラムなど）の採用が進んでいます。しかし、品質保証（QA）は従来型の方法論に留まり、スプリント外で行われる監査やゲートレビューに偏っているケースが少なくありません。この方法論では、品質リスクが早期に共有されず、リリース直前に重大な問題が発覚することもあります。QAが「最後に合否判定を下す役割」として認識され、開発チームとの距離感が生まれてしまうのです。 品質保証の役割とアジャイル開発への適応従来型QAは、品質計画を立て、ゲートレビューや監査で品質基準を満たしているかを確認する役割を担います。これは品質保証の枠組みを維持するために不可欠です。一方、アジャイル開発では短いサイクルで価値を届けることが求められます。その中で、開発と同じリズムで品質を作り込む仕組みが必要です。そこで登場するのが 伴走型QA＝Quality Engineering（QE） です。QEは、品質保証担当が担う場合もあれば、開発チーム内に専任を置く場合もあります。いずれの場合も、品質を「後から判定する」ではなく「一緒に作り込む」ことを目指します。QEはスプリントの長さに依存せず、例えば2週間のスプリントでも、計画・レビュー・分析をスプリント内で回すことが可能です。一部の事例では、イテレーション内の最終スプリントを品質保証活動に充てる方法もありますが、QEは全スプリントで品質を作り込む点が特徴です。 車載システム開発の現場で報告されている事例：QE導入による品質保証強化車載システム開発の現場では、QEを導入することで、従来型QAの仕組みがより効果的に機能した事例が報告されています。例えば、ある車載ソフトウェア開発チームの取り組みとして、次のような事例があります： スプリント計画時に品質リスクを洗い出し、優先度を設定し、チーム全体で共有→ リスクを早期に共有することで、対応漏れや後工程での不具合発生を防止 Doneの定義を明確化し、品質基準をチームで共有→ 品質基準の認識ズレが減り、レビュー指摘や手戻りが大幅に減少 スプリントごとに品質指標を振り返り、改善策を次スプリントに反映→ 継続的な改善により、品質課題を早期に解消報告によると、リリース前の重大不具合は半年で約50％削減され、品質リスクが早期に共有されることで手戻り工数も大幅に減少したとされています。この報告は、QAの枠組みとQEの現場適応が組み合わさることで品質保証が進化する可能性を示しています。 QAとQEの役割分担 QA（Quality Assurance）品質計画、ゲートレビュー、監査 → 品質保証の枠組みを維持 QE（Quality Engineering）スプリント内で品質リスク管理、Done定義、品質指標改善 → 品質を現場で作り込む両者は競合するものではなく、補完関係にある「両輪」です。 QEの具体的な関わり方 Doneの定義やチェックポイントの整理「何をもって完了とするか」を明確化し、品質基準をチームで共有 品質リスクの見える化と共有スプリント計画時にリスクを洗い出し、優先度を設定 技術レビューへの参加設計レビューやコードレビューに参加し、品質観点で議論をサポート レビュー指摘の分析スプリント内で発生したレビュー指摘（不具合や改善点）を記録・分析し、品質改善に活用 テスト結果の分析スプリント内で検出された不具合を分類・傾向分析し、次スプリントの品質戦略に反映 リリース判断のための品質情報提供「どこに懸念が残っているか」を可視化し、リリース可否判断に必要な情報を提供 スプリントの振り返りで品質状況を確認し、改善策を次に活かす不具合件数やレビュー結果などを確認し、改善策を次スプリントに反映まとめ品質保証は、もはや「最後に判定する役割」だけではありません。QAが品質保証の枠組みを維持し、QEが現場で品質を作り込む──この両輪で、品質保証はアジャイル時代に適応します。当社では、こうした取り組みを実現するために、品質リスクの見える化やスプリント内レビューの仕組みづくり、品質指標の設計といった仕組みづくりの お手伝い に加え、実際のQE活動における現場サポート（レビュー参加、品質データ分析、改善提案など）も ご支援できます。「QEをどう立ち上げ、QAと連携させるべきか？」とお悩みの方は、ぜひご相談ください。品質保証を進化させる第一歩は、開発とQA/QEが同じゴールを見て走ることです。（安部宏典）

コラム

生成AIはシステム開発・ソフトウェア開発をどう変えるのか？

生成AIの台頭と開発現場への普及近年、生成AI（Generative AI）は私たちの私生活だけなく、仕事の局面においても利用されるケースが多くなってきました。生成AIは、従来のルールベースや機械学習と異なり、コードだけでなく、人が普段使用する自然言語や画像などを生成する能力をもっています。 メモ： ルールベース：人が設定した事前のルールに基づいて動作し、特定のタスクについて高い精度と一貫性を持つ反面、柔軟性には欠ける。 機械学習：大量のデータから自己学習し、パターンを見つけ出す能力を持つが、結果の根拠がわかりにくく、学習の偏りが性能に影響する。一方開発現場は、仕様書作成や、コードレビュー、テスト設計、教育資料作成など「知的集約型作業」が多く、生成AIの活用余地が大きい印象があります。 メモ： 知的集約型作業：技術・知識・情報・判断力が価値の中心で、労働の量だけでなく、知識の質が成果を決める。生産性を高めるには、知識の蓄積と再利用、設計の品質を高めることが重要となる。 労働集約型作業：主に人の手作業や現場の働き手の数に依存する生産・サービスで、生産性を高めるには、人数を増やすか、作業を標準化して手間を減らすかが鍵となる。今回は、生成AIをどのように開発プロセスに導入していくと良いのかを考察してみました。唯一の答えではなく、あくまでひとつの見解として読んでいただけると幸いです。 生成AIの活用ケース皆さんご存知のように、生成AIはプロンプトを入力することで、「それなり」の出力を返してくれるので、開発プロセスの様々な場面で利用できる可能性があります。要求定義と仕様書作成の支援アイデア ユーザストーリーやユースケースの作成：プロンプトから指定した形式のストーリーやケースを作成する 曖昧性の検出：自然言語仕様に潜む曖昧表現（例：「これまでと同様に処理する」）を指摘し、改善案を提示する 翻訳支援：日英併記仕様書の生成、用語統一を支援する 国際標準の適用：要求工学との整合性を意識し、構文化された要件記述を促進する。設計・実装作業の支援アイデア 短いコードの断片生成：設計書から関数の雛形を生成する 設計書の記述補完：クラス図やシーケンス図の説明文を自動で生成する スクリプト自動化：JIRAやConfluenceの操作をScriptRunnerで自動化するために、そのスクリプトを提案する 面倒な作業のたたき台作成：FMEAなど多くの工数が必要なる作業のたたき台を生成する（「生成AIを活用した設計ドキュメント作成プロセス効率化支援」を参照）テスト・品質保証への応用アイデア テストケース生成：仕様書から境界値・異常系を含むテストケースを生成する 不具合報告書の作成：不具合内容を自然言語で要約し、指定したカテゴリに分類する テスト結果の報告書作成：テスト結果を要約し、報告書を自然言語で自動生成する レビューや監査のコメント生成：プロジェクト成果物のレビューや監査のコメントを提案する教育・ナレッジマネジメントへの利用アイデア 教育資料の作成：ISOやIEEEなどの一般知識を図解付きで説明する資料を作成する FAQ・用語集の作成：社内固有の用語を定義と使用例を自動生成する 多言語展開：既存の日本語教材を、技術用語や文脈を考慮して英語教材へ翻訳する（「AIの力でリアルを超える！多言語対応の次世代動画制作を始めました」を参照） 導入における留意点と課題一見すると、人間にとって都合の良いように、何でもやってくれそうですが、生成AIはまだ、発展途上であり日々進化しているため、現時点では利用する際には、いくつか留意点があると考えています。出力の信頼性皆さんご存知のように、生成AIは虚偽または誤解を招くような情報を、あたかも事実にように提示するハレーション（ハルシネーション）を起こします。また、生成AIは、事前に学習した膨大なデータから「次に来る言葉」を確率モデルから予測して出力しているため、毎回同じ出力が出るわけではありません。よってルールベースにように、精度が高く一貫性のある出力を生成するわけではありませんから、生成結果はあくまで「提案」と捉え、人間によるレビュー・検証が不可欠になります。プロンプト設計力「プロンプトエンジニアリング」という言葉があるように、適切な指示を与える技術やスキルが、生成AIの出力の品質を左右します。プロンプトエンジニアリングに関する書籍やサイトが多くあることからも、その重要性を一目瞭然です。また、開発現場の当たり前が生成AIにとっての当たり前でない可能性もあります。プロンプトやコンテキストなどの入力を与える際には、それが一般的な情報なのか、組織や製品に固有な情報なのかを整理し、質の良い出力を得る様々な工夫が必要であると考えます。セキュリティ・著作権社内情報や第三者の知的財産を扱う際には注意が必要です。生成AIが出力する際、クラウド上で処理される可能性が高いため、情報漏洩リスクがあります。生成AIの学習範囲を限定したり、社内ポリシーで入力可能な情報の範囲を明示したり、入力検証・フィルタリングの仕組みを導入して、利用制限を設ける必要があります。生成AIが学習したデータに著作権がある場合、その影響を受けた出力が著作権侵害と判断される可能性がありますが、個々の出力結果に対して警告してくれるわけではありません。AIが生成したコードや文章をそのまま使う場合、著作権の所在が不明確なことがあるので注意が必要です。 今の生成AIはあくまで「良き相棒」前述の留意点や課題を考えると、特定の開発工程や開発作業を、マルっと人に代わって生成AIにやってもらう（自動化してもらう）には時期尚早ではないか。というのが筆者の見解です。「設計のアイデアを他の人からもらいたい」「誰かちょっと分析を手伝ってほしい」といった、開発者個人のサポート役として生成AIを活用するのが、現時点での適切なやり方ではないかと考えています。1990年代後半から2000年代初頭に流行った「ペアプログラミング」のように、開発者に代わるモノではなく、開発者の良き相棒になってくれれば、個人の生産性や作業の質は向上し、開発者の集合体である組織の開発プロセスの生産性と質の向上にもつながるのではないでしょうか。生成AIに関して、いま組織が標準化すべきは、生成AIによる自動化を狙ったプロセスではなく、開発者個人に向けた「生成AIの利用ガイドライン」なのかもしれません。 内山哲三

コラム

Automotive SPICEの前に考える“要求の肥大化”対策　～要求仕様を明確にする3つのポイント～

「最初は小さな追加だったのに、気づけば手がつけられないほど要求が膨らんでいた。」皆様の現場ではこのような事象に遭遇したことはないでしょうか？いわゆる「要求の肥大化」です。今ではアジャイル開発の普及やツールによるトレース管理などが進み、昔に比べると要求の肥大化そのものは抑制傾向にあります。しかしながら、年々技術の高度化・統合化が急速に進むにつれ、リリース直前にもかかわらず五月雨式に要求が発生するケースは少なくありません。当初の想定を超えた要求が増え続けると、スケジュールは遅れ、品質は落ち、チームの士気も下がります。「うちでは起きていない」と思っていませんか？実は、どんな現場にも“要求の肥大化”の芽は潜んでいるのです。そう考えると、要求の肥大化はもはや一部の大規模開発だけの問題ではないのです。Automotive SPICEでは要求管理が開発プロセスの基盤として定義されていますが、実際にはAutomotive SPICEの適用だけでは“要求の肥大化”を完全に防ぎきれないケースが多く見られます。そこで、要求の肥大化はどういった原因で起こるのか、考えてみたいと思います。 ■ 要求の肥大化が起きる主な原因 ステークホルダーが多い今は１製品のことだけ考えれば良いものづくりは影を潜め、ヒト・モノと繋がるスケールの大きな製品づくりが主流です。それによって、プロジェクトのスコープが拡がり、ステークホルダーも増えていきます。そうすると、ステークホルダー毎に多種多様な要求が発生していきます。すべての要求を取り込もうとした結果、特にコスト、納期を超過してしまいます。 要求が曖昧なまま進む要求仕様書自体の曖昧さも要求肥大化の原因になります。具体的には、要求仕様書に「〜など」「〜関連」「〜のように」のような“便利な曖昧語”が書かれていることがあります。この“便利な曖昧語”が、「こういう要求も含むよね？」といった要求の肥大化に繋がることがよく見受けられます。 要求追加を断り切れない顧客からの要求に対して、「大切な顧客に言われたら断れない」「少し無理をすれば何とかなるだろう」といった安易な受容が、次々と要求を呼び込んでしまう要因になり得ます。次第に要求を断りづらい雰囲気が生まれ、最終的には未対応の要求事項がいくつも残存したまま納期を迎えてしまうことは珍しくありません。 ■ 要求の肥大化を防ぐための『処方箋』要求の肥大化が起きる原因は現場の努力不足ではありません。以下のような「仕組みとルール」でコントロールすることができます。 スコープを明確にするプロジェクト計画立案の段階で、「今回はここまでしかやらない」と範囲を明確化し、ステークホルダー間で合意を取っておきます。その際には、要求を採用するかどうかを「コスト」「納期」「品質」などの観点から定量的に検証する基準を設けることが重要です。例えば、要求ごとに「コスト増加率」「スケジュール影響度」「顧客価値への貢献度」を簡易的に見積もるフレームを持ち、これらをトレードオフ評価してスコープを決定します。また、スコープ外要求が出た場合は、判断ルールに沿って扱う柔軟性も兼ね備えておくことが必要です。 曖昧な要求表現を排除する仕様書や設計書、議事録に至るまで、定義や条件が具体化されていることを複数人の目で確認し、誰が見ても同じ理解になるよう整理しなおす機会を持つことが必要です。「“～など”や“～のように”が記載されていないか」といった定義の明確さを確認するチェックリストを用意する仕組みも有効です。 要求受け入れの判断を仕組み化するプロジェクトが厳守すべき方針に基づき、CCB（変更制御委員会）などの場で要求の受け入れ可否を判断する仕組みを取り入れます。その場合、「誰が」「どういう基準で」変更の受け入れを判断するかを明文化しておくことが重要です。では、具体的にどのような基準で判断すればよいのでしょうか。以下に一例を紹介します。あるプロジェクトでは開発期間を3カ月単位のリリースサイクルと定義し、要求の出し方・締切・変更ルールを明確にして運用していました。 各リリースは3カ月単位とし、期間の延長や早期リリースは行わない 1リリースの中で数回のフェーズに区切って開発をする 第1フェーズ（スタート～2週間）までに要求を確定する 第3フェーズ（5週目～8週目）までは要求変更を許容する それ以降の要求追加・変更は次リリースに持ち越しこのように、あらかじめ「いつ・どの範囲まで変更を受け入れるか」をルール化しておくことで、品質とスケジュールの両立が可能になっていきます。 ■ Automotive SPICEに固執しすぎない、現場に効く支援を要求肥大化の防止は、単にAutomotive SPICEの要求管理プロセスを満たすだけでは実現しません。重要なのは、「現場が運用できる形で仕組みを落とし込む」ことです。弊社は要求定義を含む開発経験豊富なコンサルタントが在籍しており、現場目線で支援しています。また、コンサルティングの中で、設計文書に潜む曖昧表現の抑制に向けたプライベート教育も行っています。私たちはAutomotive SPICEの規格に固執しすぎず、組織文化やチームの成熟度に合わせた“浸透しやすい最適解”を提案し続けています。ぜひ、現場に合った仕組みづくりについてご相談ください。 弊社YouTubeチャンネルにてソフトウェア要件分析のポイントを解説しております。こちらもご覧ください。【ソフトウェア要件分析プロセス②】Automotive SPICE 活動のポイント お問い合わせはこちら（弊社コンサルタントがご相談を承ります）https://www.bgarage.co.jp/contact/ （長澤克仁）

B'zine

B’zine – 2025年10月号（Webinar開催～生成AIでFMEAを作成してみたら～など）を発行しました

10月下旬になり朝晩はめっきり肌寒くなりました。秋の行楽シーズン到来ですが、山奥深い場所や人気のない場所への侵入や単独行動は控え、熊出没注意報にも十分注意して、紅葉狩りをお楽しみください。 B'zine 10月号を発行いたしました。動画版(約3分)も公開していますので、弊社公式YouTubeより是非ご視聴ください。https://youtu.be/DP1UjaROsto     B’zineは、１回/月のペースでの配信しています。ご興味のある方は、ここから登録をお願いいたします。   B'zineビジネスガレージ通信（2025年10月号）  B’zine 10月号をお届けします。10月下旬になり朝晩はめっきり肌寒くなりました。秋の行楽シーズン到来ですが、山奥深い場所や人気のない場所への侵入や単独行動は控え、熊出没注意報にも十分注意して、紅葉狩りをお楽しみください。【今月のトピックス】 イベント：第６回 ビジネスガレージオープンWebinar開催（11/26） コラム：無料相談会（ミニコンサル）11月開催 コラム：使えるプロセス vs 使われないプロセス：決定的な違いと成功事例 コラム：ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～ コラム：「テスト頼み」からの脱却 ─ レビュー文化が品質を変える 【イベント】 2025年11月26日 Webinar～生成AIでFMEAを作成してみたら～のご案内ChatGPTを活用することで、FMEAの作成期間とリソースを劇的に削減した事例をご紹介します日時：2025/11/26(水) 16:00 – 16:50お申込みはこちらから→ https://www.bgarage.co.jp/news/1496/ 無料相談会（ミニコンサル）11月開催のご案内弊社では、皆様のお困りごとに対する相談会を実施しています。Automotive SPICE/プロセス改善/プロジェクト管理など、お気軽にご相談ください。お申込みはこちらから→https://www.bgarage.co.jp/news/1494/ 2026年1月 Webinar（予定）：EARSを活用した要求の書き方構文形式を利用することで、書き手と読み手の解釈不一致を防止する要求の文書化手法と事例をご紹介します。 【コラム】 使えるプロセス vs 使われないプロセス：決定的な違いと成功事例プロセス改善は、こうした属人的な開発から脱却し、誰がやっても一定の品質・納期・コストを再現できる仕組みをつくるための重要な取り組みです。しかし近年、開発の複雑化や規格対応の厳格化により、品質問題や納期遅延のリスクはますます高まっています。その一方で、監査や認証取得を目的に整備された“形だけのプロセス”が現場で使われず、改善が止まってしまうケースが増えているのも事実です。良いプロセスも、現場で使われなければ意味がありません。では、なぜプロセスは使われなくなるのか？どうすれば現場で本当に役立つプロセスになるのか？このコラムでは、私たちの現場支援の経験をもとに、成功のヒントをいくつかご紹介します。詳細はこちら→https://www.bgarage.co.jp/news/1424/ ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～ソフトウェア開発において、テストは品質保証の要です。しかし、テスト活動そのものの成熟度やプロセス品質を体系的に評価・改善する枠組みは、長らく十分に整備されていませんでした。そこで登場したのが Test SPICEです。Test SPICEは、ISO/IEC 330xxシリーズの一部として策定された、ソフトウェアテストに特化したプロセス評価モデルです。従来のSPICE（Software Process Improvement and Capability Determination）モデルをベースに、テスト活動の特性に合わせて設計されています。「検証サービスプロバイダ」 に求められる組織能力を可視化し、プロセス改善による組織能力向上を図ることを目的としていますが、テスト資産の再利用や回帰テストの自動化など、ソフトウェア開発組織のテストプロセスの改善にも有益な内容になっています。詳細はこちら→https://www.bgarage.co.jp/news/1464/ 「テスト頼み」からの脱却 ─ レビュー文化が品質を変える製品開発における品質保証は、テスト工程に偏りがちです。多くの組織では、テストで検出された不具合をもって品質を評価し、設計工程でのレビュー指摘は記録されない、あるいは品質活動の一部として認識されていないことがあります。しかし、品質は本当に“テストだけ”で保証できるのでしょうか？テストは重要な工程ですが、あくまで後工程であり、設計段階での不具合をすべて検出できるわけではありません。特に組込み系開発では、タイミング依存や環境依存の不具合が多く、テストだけでは限界があります。設計段階での不具合を未然に防ぐには、レビューによる“作り込み”が不可欠です。詳細はこちら→https://www.bgarage.co.jp/news/1453/

コラム

ソフトウェアテストのプロセス改善を支える国際標準～Test SPICE～

 はじめに ソフトウェア開発において、テストは品質保証の要です。しかし、テスト活動そのものの成熟度やプロセス品質を体系的に評価・改善する枠組みは、長らく十分に整備されていませんでした。そこで登場したのが Test SPICEです。今回はTest SPICEの概要について解説します。  Test SPICEの位置づけ Test SPICEは、ISO/IEC 330xxシリーズの一部として策定された、ソフトウェアテストに特化したプロセス評価モデルです。従来のSPICE（Software Process Improvement and Capability Determination）モデルをベースに、テスト活動の特性に合わせて設計されています。 国際ソフトウェアテスト資格認定委員会（ISTQB）のシラバスに基づき、長年にわたるソフトウェア/システムのテストに関する世界中の有識者の経験を体系的にまとめ、テストプロセスの共通フレームワークを提供しています。 「検証サービスプロバイダ」 に求められる組織能力を可視化し、プロセス改善による組織能力向上を図ることを目的としていますが、テスト資産の再利用や回帰テストの自動化など、ソフトウェア開発組織のテストプロセスの改善にも有益な内容になっています。  構成と特徴 Test SPICEは、以下のようなプロセス群で構成されています： ビジネスライフサイクルプロセスカテゴリー： テスト計画、設計、実行、評価などテスト運用に使用されるプロセスで構成されています。 技術ライフサイクルプロセスカテゴリー： テスト環境管理、テストデータ管理、テストの自動化など、テストを技術的に有効利用するプロセスで構成されています。 テストリソース合意プロセスカテゴリー： テストを実施するための人的・物理的リソースを調達または供給するプロセスで構成されています。検証サービス、テスト資産、テストツールなどテスト実施のために取引されるあらゆるものが含まれます。 アジャイル拡張プロセスカテゴリー： Test SPICEのコアプロセスではありませんが、テストプロセスをアジャイルに実行するためのプロセスが定義されています。各プロセスは、Automotive SPICEと同様に、目的・成果物・ベースプラクティスが定義されており、能力度レベル（Level 0〜5）に基づいて評価されます。  Automotive SPICEとの違い 範囲の違いとしては、Automotive SPICEがシステム・ソフトウェア開発全体を対象とするのに対し、Test SPICEはテスト活動にフォーカスしています。両者を組み合わせることで、より精緻なプロセス改善が可能になります。 また構造的な違いとして、Test SPICEでは、各プロセス群に「包括プロセス（Overarching Process）」と「詳細プロセス（Detailed Process）」が定義されています。Automotive SPICEでは、プロセス群には単にプロセスが定義されていますが、Test SPICEでは、包括プロセスと詳細プロセスが親子関係をもって定義されています。包括プロセスの各BPに対応するように詳細プロセスが定義されており、より詳細な評価指標を定義しています。 Test SPICEを用いたアセスメントを計画する際には、包括プロセスを対象とするのか、詳細プロセスを対象するのかを明確に決定することが求めれています。両者を混在させることは推奨されていません。迅速かつ大まかな分析を行う場合は、包括プロセスとそれらのBPを使用し、より詳細な分析を行う場合は、詳細プロセスとそれらのBPを使用することが期待されています。 各ライフサイクルプロセスカテゴリーで定義されている包括プロセスと詳細プロセスは下図のようになっています。   例えば、技術ライフサイクルプロセスカテゴリーにあるテスト自動化プロセス群（TAU）の包括プロセスと詳細プロセスの関係について見てみましょう。 包括プロセスとして定義されている「TAU テスト自動化プロセス」には、6つのBPが定義されています。6つのBPは、テスト自動化のための要件定義・設計・実装・テストケース実装・自動化実施・使用状況の監視に関するプラクティスになっています。これら6つのBPに対応する形で詳細プロセスが定義されています。各詳細プロセスには、包括プロセスが定義しているBPをより詳細にしたBPが定義されています。 大まかに何をすればよいのか知りたいときは包括プロセスを参照し、具体的に何をすべき把握したいときは詳細プロセス参照すると良いですね。  Test SPICEを覗いてみよう もう少し理解を深めるために、「TAU テスト自動化プロセス」がどんな内容になっているのか見てみましょう。 先に述べたように、包括プロセスである「TAU テスト自動化プロセス」では、テスト自動化のための要件定義・設計・実装・テストケース実装・自動化実施・使用状況の監視に関する6つのBPが定義されています。これら6つのBPに対応する形で詳細プロセスが定義されています。 これを図示すると以下のような作業の流れになります。  TAU.1：テスト自動化のニーズと要件の抽出プロセス 包括プロセスのBP1に対応した詳細プロセスです。 組織におけるテストに対する思想を記述したテスト方針に基づいて、テスト自動化に対する共有理解を得るために要件仕様書とアーキテクチャ設計書を作成します。 また、どのようにテスト自動化を実現していくのかを記述した、テスト戦略と計画書も作成します。 TAU.2：テスト自動化の設計プロセス 包括プロセスのBP2に対応した詳細プロセスです。 テスト自動化の実現手段を明確にするために、TAU.1の成果物をインプットに、テスト自動化の設計書を作成します。 使用するツールもここでリストアップしておきます。 TAU.3：テスト自動化の実装プロセス 包括プロセスのBP3に対応した詳細プロセスです。 テスト自動化の基盤を構築するために、TAU.2で作成した設計書をインプットに、リストアップしたツールを利用して、自動化ソフトや実行に必要な構成ファイル、サンプルスクリプトなどを作成し、動作を確認します。 TAU.4：テストケースの実装プロセス 包括プロセスのBP4に対応した詳細プロセスです。 実際にテスト自動化を実行するために、TAU.3で準備したソリューションを使用して、テストケースをテストスクリプトに変換し、実行に必要なテストデータやテスト手順も作成します。 TAU.5：テスト自動化の実施プロセス 包括プロセスのBP5に対応した詳細プロセスです。 ここで実際にテスト自動化を実行し、テストログやテストレポート、不具合報告を生成していきます。 TAU.6：テスト自動化プロセスの監視プロセス 包括プロセスのBP6に対応した詳細プロセスです。 実際にプロジェクトでテスト自動化の使用状況を確認し、意図した利用ができているか、組織として当初目指していた、コスト削減や製品品質の均一化に対する妥当性を評価します。 「テストの自動化はコストにも品質にも良いのはわかるけど、何からやったらよいの？」「テストは自動化できたけど、かえって手間が増えてしまった気がする」 こんな悩みや困りごとをお持ちの方は、有益なヒントが詰まっているTest SPICEを参照すると良いと思います。 他にも「テスト仕様書だけじゃなくて、テスト環境も上手く再利用したい」方や「そもそも、どんなテストが自分たちの製品に有効なのか改善したい」方など、少しでもテストに関する悩みがある方は参考していただけると良いと思います。  さいごに いかがだったでしょうか。Test SPICEは、Automotive SPICEと同様に、組織的な品質文化の醸成や教育・研修の教材として活用できますが、テストプロセスに特化した可視化や標準化だけでなく、テスト資産の再利用やテスト自動化など具体的な改善にも活用することができます。 興味のある方は一度Test SPICEのPAMを参照してみてください。  内山哲三 

トップ新着情報

Contact Us

お問い合わせ

お客様のニーズに応じて、最適なサービスを展開しております。
まずはお気軽にご相談ください。

お問い合わせフォームはこちら