Updates

新着情報

WhitePaper

Organization SPICE 概説資料を公開しました

先日、Organization SPICE が intacsから公開されたことをお知らせしましたが、その概説書を作成いたしましたので公開いたします。 コンテンツに含まれるもの： 成熟度レベルについて 組織成熟度の評価方法 アセスメントモデルとプロセスの選択 プロセスインスタンスの選択 Organization SPICEプロセス群 PIM.1（プロセス確立） RIN.2（スキル開発） QNT.1（定量的能力管理） QNT.2（プロセス革新） Organization SPICE PAM の説明だけでは、理解しにくい下記事項については、今後コラムでご紹介予定ですので、是非こちらもご参照ください。 プロセスインスタンスと、その選択方法について 高成熟度（成熟度レベル4、５）の考え方  

コラム

システム／ソフトウェア開発に品質保証活動は必要なのか？

はじめにAutomotive SPICEのSUP.1やCMMIのPPQAでは、システム開発／ソフトウェア開発の品質保証活動に対する要求事項をまとめています。しかしながら、そもそもなぜシステム開発／ソフトウェア開発に品質保証活動が必要なのかを考えたことがありますか？今回は、SUP.1やPPQAの元となっている規格や書籍を参考に、「品質保証活動の必要性」について考えていきます。  品質保証の規格MIL規格（Military Standard）最初に品質保証が規格として体系化されたのは、MIL-STD-109で、1960年代後半に初版が制定されました。この中で「品質保証（Quality Assurance）」を以下のように定義しています。A planned and systematics pattern of all actions necessary to provide adequate confidence that management and technical planning and controls are adequate to: Established correct technical requirements for design and manufacturing. Create products and services that confirm to the established technical requirements.管理および技術計画と制御が次の事項に適切であるという十分な確信を与えるために必要なすべてのアクションの計画的かつ体系的なパターン。 設計および製造に関する正しい技術要件を確立する。 確立された技術要件に準拠する製品およびサービスを作成する。つまり「適切に正しい技術要件を定義して、適切にそれに準じた製品やサービスを作っている確信を得るための活動」が品質保証であるとしています。さらにその技術要件の重要な要素である品質要件についても以下のように定義しています。The technical requirements relating to the quality of the product (supply or service) and contract clauses prescribing quality standards, inspection, and other quality controls incumbent on the contractor, to assure that the product or service confirms to the contractual requirements.製品 (供給またはサービス) の品質に関する技術要件、および契約者に課せられた品質基準、検査、およびその他の品質管理を規定する契約条項で、製品またはサービスが契約要件に準拠していることを保証する。契約者（≒供給者）が、要件通りのモノを作ったことを保証するための契約事項（≒約束事）を品質要件と定めています。言い換えると、要件通りにモノを作ったことを対外的に保証する行為が品質保証活動だと言えるでしょう。ISO規格（国際標準規格）品質に関する国際標準は、皆さんもご存知のISO 9000シリーズです。1980年代に制定されましたが、その中のISO 9003が、特に「最終検査および試験における品質保証モデル」に焦点を当てた規格です。ISO 9003は、製品の最終検査と試験を通じて品質を保証するためのガイドラインを提供していました。ISO 9003は、長期間にわたって製造、設計、その他の使用方法が確立されている製品に対して、最終検査のみで品質を保証するための規格でしたが、2000年の改訂により、ISO 9001に統合され、より柔軟で包括的な品質マネジメントシステムの規格となりました。IEEE規格（電気・電子工学分野における国際標準規格）電気・電子工学分野における国際的な標準を策定するための組織であるIEEE（Institute of Electrical and Electronics Engineers）も、前述のMIL-STDをベースに1970年代後半に品質保証の国際標準を制定しました。IEEE Std 730IEEE Standard for Software Quality Assurance Processesがその規格であり、今もなお改版を続けています。この中で、Automotive SPICEやCMMI以上に詳細説明があるので、この規格を参考に必要性を整理していきます。この国際標準では、SQAプロセスの目的と以下のように定義しています。 「ソフトウェア開発プロジェクトが SQA プロセスを使用して、ソフトウェア製品が確立された要件に準拠していることを正当に証明するための根拠となる証拠を作成および収集できるようにすること」 やはり、品質保証を要件通りにモノを作ったことを対外的に保証する行為と位置付けています。  QAが準拠保証しなくてはならない要件とは Automotive SPICEのSUP.1でも定義されているように、成果物とプロセスの品質保証をする必要があるため、QAが遵守保証しなくてはならない要件は、プロダクト要件とプロセス要件になります。IEEE std 730では、契約事項である利害関係者要件から導出されたプロダクト要件とプロセス要件に対し、図にあるような適合関係の推移性に基づいて、1つ前の情報と比較し適合していることを確認することで、プロジェクト全体を通じて、「要件通りにモノを作ったことを保証する」こととしています。 契約事項と導出されたプロセス要件の適合を確認する プロセス要件と導出された計画やプロセス、標準や手順の適合を確認する 計画やプロセス、標準や手順と実際の活動結果の適合を確認するこのように、1つ前の情報との適合を確認することが、品質保証活動の基本的な考え方となります。  プロジェクト内のレビューやチェックだけでは品質保証は十分なのか？契約事項に基づいた「要件通りにモノを作ったことを対外的に保証する」必要性は、開発に携わった人であれば理解できることかと思います。それでは、その対外的な保証はプロジェクト内の活動だけで十分であると考えることはできないのでしょうか？先のコラムAutomotive SPICE SUP.1 本当に品質は良くなるの？でも引用した「プロセス成熟度の改善」（Watts S. Humphrey著日本語訳：日科技連出版社発行）には、客観的な品質保証の必要性を以下のように説明しています。監査者に対し客観的になることは、誰にとっても難しい。一般に、我々はかなり注意深く仕事をやっており、そうでないように言われると不愉快に感ずる。しかし、「外側から」のレビューを行うのは、釣り合いのとれた見方が必要だからである。たとえば、あなたがこれからパラシュートを包み終えて跳ぼうとしているとする。有能な検査者があなたの1つ1つの動作を監視して本当に正しく行ったということを保証してくれるならば、あなたの幸せになれる勝算は大きくなる。品質が決定的に重要な場合は、なんらかの独立したチェックが必要である。それはその人たちが信頼できないからではなくて、その人たちが人間だからである。ソフトウェアにおける問題は、チェックが必要かどうかではなく、誰がどうやるかである。小規後な組織では、しばしば管理者自身が作業を直接に監視できるので、SQAの活動は必要がない。部下の数が多くなるにつれて管理者は他の業務に巻き込まれ、次第に日常の技術的作業ができなくなってしまう。このような時には、管理者は次の事項の1つを行うことが必要である。 余分な負荷をうまく扱うなんらかの方法を見つけ、部下の仕事をより密接に監視できるようにする。 監視する人を雇う。 部下同士が互いに監視するように動機づける。技術的、経済的、そしてモラル上の観点から、最後の選択が一般には最も望ましい。残念ながら、歴史的にもソフトウェアの組織が数十人を越えてくると、この「ニ人一組方式」は崩壊してしまう。このような場合には、SQAによって解決しなければならないのである。 規模が膨らみ、複雑なシステム／ソフトウェア開発を行っているからこそ、管理者に代わって、「要件通りにモノを作ったことを対外的に保証する」客観的な視点が必要になるのです。当然ながら、管理者のサポートが、効果的な品質保証活動を行う大前提となります。  さいごに いかがだったでしょうか。今回は、改めて品質保証活動の必要性について考察してみました。皆さんの効果的な品質保証活動を行う動機付けになれば幸いです。 内山哲三 

コラム

Automotive SPICE GP 徹底解説 その３ ～ そもそも能力レベル２とは？

これまで２回にわたって Automotive SPICE の GP（General Practice）について解説しましたが、今回は「能力レベル２って、どういう状態なの？」というテーマでお届けいたします。 本題に入る前に、「プロセス」って何でしょうか？と聞かれても、皆さん明確には答えにくいのではないでしょうか？最近流行りの生成AI君に尋ねてみると：  プロセスとは、物事がある結果に達するまでの道筋や手順、方法を意味します 類義語には、「過程」、「経過」、「手順」、「工程」などがあります と答えてくれました。そもそもカタカナで書いてあることから「プロセス」は日本語由来のものではなく、類義語ででてくるように人によってそれぞれの解釈で日本語に当てはめているものと思います。アセスメントのインタビューで、「私達にはプロセスはありません」という発言を聞くことがありますが、この言い回しは正しくありません。アセスメントの場では、発言者は「プロセス」＝「手順を文書化したもの」と勘違いしてしまっているのです。何らかの成果物が生成されている限り、そこに至った過程、経過や手順は存在するはずです。 次のような２つのグループがある場合、あなたならどちらのグループに仕事を依頼したいですか？グループA 計画書を作成して、作業状況を計画に照らしてチェックしている あらかじめ作成すべき作業成果物を決めて、ドキュメントを管理している 作成したドキュメントは、必ずレビューを実施して誤りを訂正しているグループB 計画書はなく、グループ員にヒアリングしないと状況はわからない 作業成果物は担当者の申告ベースで、何があるか、何処にあるかはわからない レビューは実施せず、担当者の力量に任せている これだけでは、どちらのグループが良い成果物を納入する可能性があるか判断できませんが、グループBの方は、よっぽど優秀なメンバーが揃っていないと任せるのは怖い感じがしませんか？この２つのグループの違い、つまり仕事の仕方の違いがプロセス能力の違いなのです。アセスメントでは、プロジェクトにおける仕事の仕方および作成された成果物の十分性を判断して、プロセス能力を判定しています。 ではプロセス能力レベル２とは、どんな状態なのでしょうか？次の２つがポイントとなります 作業が計画的に実施できているか？ 作業成果物が管理され、成果物の品質がチェックされているか？つまり、この２つの仕組みができていれば、プロジェクトに携わる人が変わったとしても、繰り返し一定レベルの成果が期待できるということなのです。このようなプロセスの状態になっているプロジェクトを「能力レベル２」と呼ぶというのが、アセスメントの評価基準になります。 アセッサーによっては重箱の隅をつつくように細かいことを指摘する人がいますが、極めて基本的なことだと思いませんか？Automotive SPICEでは、PA（Process Attribute）とGP（General Practice）を能力レベル２の判定基準として定めています。事例も含めて表にまとめてみました。それほど高い壁ではないと思いますので解釈の参考にしてください。     また、GPとプロセスには上図に示すような密接な関係があります。GPを十分に実現するためには、対応するプロセスで定義されるBP（Base Practice）の内容を実施しておく必要があると読み替えてください。 文書だけでは、わかりにくい領域だと思います。弊社ではAutomotive SPICEに関する無料相談会（ミニコンサル）も実施していますので、お気軽にご相談ください。日吉昭彦

コラム

Automotive SPICE SUP.1 本当に品質は良くなるの？

今回は、品質保証に関する話題をご提供いたします。プロセス改善モデルには、品質保証というプロセスが定義されています。Automotive SPICE では、SUP.1（品質保証）、CMMI v1.3では、PPQA（プロセスと成果物の品質保証）というプロセスが該当します。（CMMI v2.0/3.0では、品質保証の考え方が多少変わってきていますので、後述いたします） さて、これらのプロセスを実装することで、良い品質の製品をリリースできるでしょうか？ 筆者は、本件については甚だ懐疑的です。というのも、これまで自身の担当するプロジェクトで、単純にAutomotive SPICEのSUP.1プラクティスに記載されている内容を実施してきましたが、効果を感じられませんでした。また、多くの組織やプロジェクトを見ても、状況はあまり変わりません。はじめてSW-CMM（CMMIの前身モデルです）というモデルの導入を検討していたとき、SQA（ソフトウェア品質保証）プロセスとは、「プロジェクトが、決められた方法（約束事）に従って活動していることを評価する」ということだと知り、これで品質が担保できるのかと不思議に思ったものでした。 これらの原因は、品質保証活動＝プロセス監査という考え方になってしまっていることにあると考えています。確かに Automotive SPICE SUP.1の各プラクティスを見ても、監査すれば十分であると読めてしまうところがあると思います。また、プロセスモデルでは「品質管理」というプロセスが別に定義されていることもあり、このような実装になってしまうことも仕方ないかもしれません。 しかしながら、せっかく品質を保証する活動を導入するのであれば、もう少し実際の品質に寄与できる活動にしたいとは思いませんか？重箱の隅をつつくような作業や、不遵守が発見されない監査項目に多くの時間をかけて作業するのは勿体ないですよね。ここからは、こういった現象に気付いた私たちが実践してきた、品質保証活動の刷新についてご紹介いたします。 まずは、本当の意味での品質保証活動について考え直すことから始めました。一番参考になったのは、「プロセス成熟度の改善」（Watts S. Humphrey著日本語訳：日科技連出版社発行）です。この本は、私たちが赤本と呼び、プロセス改善のバイブルとして長年使っているものです。品質保証として評価すべき観点を列挙し、それぞれの開発工程で確認すべき点をまとめました。下記に概略を記載しますので、参考にしてください。 構成管理：計画とその遵守、設計書・ソースコード・テスト仕様、構成監査 レビュー：レビュー計画と運営状況の確認、各工程のレビューへの参加と品質確認 監査：プロセスの遵守性 要求仕様：顧客要求の合意形成、要求のテスト可能性、要求毎の進捗状況 設計：開発進捗、レビュー摘出率、コードメトリクス、トレーサビリティ テスト：テスト計画、不具合発生と解決データのトレース、テスト報告書 ツール：使用ツールの妥当性、ツール使用状況 修正処置：変更依頼の状況、修正手順、各工程の修正の開始から完了までの状況、問題原因の傾向 外注先：外注先の品質保証プロセス、設計標準の確認、品質データの把握 計画：計画の妥当性、計画変更の妥当性、計画に対する進捗状況 出荷：レビュー・テスト指摘解決状況、テスト報告書、出荷審査こうしてみると、かなり実施すべきことがあると思いませんか？ 次に品質保証活動の役割分担について考えました。本来の意味での品質保証活動を実施するにあたり、品質保証活動の役割を次のように細分化しました。 品質システム担当：品質システムの構築・運用 品質分析担当：各プロジェクト品質データの取りまとめ・分析・報告 内部レビュー担当：プロジェクト内部のレビュー実施者（開発者） 外部レビュー担当：プロジェクト外の開発者、品質保証グループによるレビュー実施者 プロセス監査担当：プロジェクトの監査実施者 品質保証活動プロセスの（再）定義品質保証活動の観点と役割から、品質保証グループとして実施すべき活動とプロジェクトの品質保証活動の２つに分けて、品質保証活動のプロセスを定義しました。プロセスの概要は、導入事例（品質保証活動の刷新）を参照してください。  気が付いている人も多いようですが、監査だけでは品質は良くなりません。品質保証に携わる組織としては、プロジェクトの品質データを収集し、そのデータをもとに品質課題を解決する活動が重要です。長年の開発経験からわかることは、重大な不具合はソフトウェア全体が悪いわけではなく、ある特定のコンポーネントの不出来が起因して起こるということです。これらを如何に開発途中で見つけるかが品質保証活動のキーポイントとなるはずです。いつまでも設計が終わらない機能、規模が膨大になっているソフトウェアコンポーネント、コードメトリクスが例外値を示しているソフトウェアユニット、多くの不具合が発生している機能など、これらを調査することで未然に予防できることがあるはずです。 Automotive SPICE SUP.1や、CMMIを取り巻く環境も近年変化が見られるようです。欧州の自動車メーカーからは、プロジェクトの品質データを毎月提出することが求められるようになりました。CMMI v2.0/3.0では、「品質の確保」という属性の中に４つのプラクティス領域（ピアレビュー、プロセス品質保証、要件の開発と管理、検証と妥当性）を設け、従来のPPQAプロセスだけでなく他のプロセスを品質に結び付けています。皆さんも、監査だけの品質保証から、本質的な活動に移行してみませんか？ 日吉昭彦

トップ新着情報

Contact Us

お問い合わせ

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

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