紹介文 :
一般的な開発プロジェクトではテスト工程終了時の工程移行判定にて品質判断しているため、品質問題が起きた場合はスケジュール遅延のリスクが発生しやすい。当社では本リスク対策を行っている。
当社の品質保証部門では最終成果物であるソフトウェアの品質要求を品質特性で定義しており、品質特性を品質指標として活用している。テストレベル毎に品質副特性ベースで定義された品質要求を達成することを念頭にテストレベル毎にクオリティゲートとなるクライテリアを定義している。
この品質保証プロセスを活用し、品質問題が起因したスケジュール遅延リスクの対策として、テストレベル毎にクオリティゲートとなる当社独自の「受入テスト」という仕組みを構築し、予定しているテストが手戻りなくスケジュール通りにテスト可能な品質が備わっていることをシミュレーションしている。
当社独自の受入テストは、網羅性のある品質特性で定義された品質要求が確保されていることを念頭に対応するテストタイプからテストケースを抽出しているため、テストレベル毎の受入テストをパスすることにより、品質確保の状況が分かりやすくなる。
本論文では、テストレベル開始前条件に品質判断する手法として当社独自の受入テスト技法を紹介し、本技法の効果であるプロダクトリスクの回避や品質の見える化実現に向けたプロセスの解説とともに説明する。

紹介文 :
当社のソフトウェアパッケージ製品の開発プロジェクトでは、最終成果物であるソフトウェアの品質要求を品質特性にて定義し、開発部門とともにその品質要求を満たすことを目標に製品開発を行っている。品質保証部門では定義された品質特性毎の品質が確保されているかを確認するため、各テストタイプを品質特性毎に分類し、それらテストタイプの実施により各品質特性の品質が確保されているか確認している。これらの検証計画は詳細にマスタープランに記載されるとともに、各テストレベルでは受入テストによる品質ゲートを設けている。このような開発プロセスと非同期の品質評価プロセスを2011年より導入している。
昨年９月の一般社団法人コンピュータソフトウェア協会のPSQ認証の取得を機に、SQuaREやISO/IEC/IEEE 29119のテストプロセスなどの最新規格への対応、利用時の品質、利用者文書であるマニュアルの品質要求への品質特性の導入、第三者への品質情報の提供を踏まえた検証結果報告書の作成等の検討を行い、JIS X 25051:2016に対応した新たな品質保証プロセスを構築した。
本論文では、当社が構築した最新の品質保証プロセスの概要や導入教育の方針を解説するとともに、導入プロジェクトでの適用例を踏まえた本プロセスの効果および今後の課題を述べる。

紹介文 :
当社では利用時の品質の評価を実現するため、利用者用文書を活用した取り組みを行っている。SQIPシンポジウム2016で発表した内容であるマニュアルベーステストを行う時期や検証実施条件を考慮し、マニュアルベーステストで修正した内容が効果的かどうか検討した。なお、今回はマニュアルベーステスト技法を用いた評価の実施が可能かどうかの判断基準としてマニュアルユーザーテストを活用し、その結果からマニュアルベーステスト実施時の検証観点の考慮を行うこととする。
また、過去の評価結果に対し、当社サポート部門への問い合わせ分析による技法の効果測定を行った結果、問い合わせ数が減少しこれまでの施策が効果的だと考えられた。そこで、既存のマニュアル制作プロセスにマニュアルの品質保証を目的としたマニュアルベーステストとユーザーテストを組み込んだプロセスを構築し、適用することとした。「マニュアル評価ガイドライン」の評価観点と利用者文書の品質要求の品質特性とを紐付けしマニュアルの評価工程別に担保すべき品質の明確化し、プロセス改善を進めた。
今回は、当社が適用しているマニュアル制作プロセスの流れとマニュアル制作の一部を修正し、マニュアルベーステストとユーザーテストを適用し評価した結果を報告する。また、マニュアル制作プロセスでマニュアルの評価を行うことが、利用時の品質の向上に繋がることを定量的に示し、利用時の品質評価のためのマニュアルベーステスト技法の改良について解説する。

紹介文 :
製品の販売数増加に伴って、テクニカルサポートに対する問合せ数に大幅な増加傾向があり、製品に関する何らかの「品質」が低下していると考えられ、対策が急務となっていた。
そこでわれわれは「テクニカルサポート部門」という立場から、ISO/IEC 25010を参照し「品質」のモデル化と定義を行いテクニカルサポートへの問合せを分析
して、品質低下の根元要因分析とフィードバック先を特定することとした。結果としては、ユーザは製品自体（ソフトウェア品質）ではなく、製品の「運用など
を含む利用状況」（システム品質）に問題を感じていることがわかった。
さらに調査を進めると、根元問題としてシステム移行に関するマニュアルが存在していないことが分かった。ソフトウェア自体に関する文書品質には問題ないと
考えていたが、運用部分を考慮した「システムとマニュアルの一貫性」が低いために問合せが多く発生していることが分析できた。

開発部門の考慮の中心は「ソフトウェア品質」に偏ることが多くなり、「利用時品質」や「システム品質」への考慮が不足して品質要求の漏れが生じる。そこで、
「テクニカルサポート問合せ分析」を行う事によって利用者側の観点及び製品運用の観点を付与することができ、利用者を考慮した品質要求分析を行うことができると考える。本発表は、テクニカルサポート部門の活用によりシステム品質向上に効果が得られた事例の報告である。

紹介文 :
ソフトウェアパッケージ製品を一定期間契約するサブスクリプションモデルおよび月額ベースで契約するクラウドサービスモデル等のリカーリングビジネスを支えるためには製品およびサービスの品質を高めるだけではなく、顧客からの技術的な問い合わせに関するプロアクティブなフィードバックプロセスの構築が必要不可欠である。
当社では第三者への品質情報の提供を意識し、品質特性を活用した品質保証プロセスの構築と適用を進め、予定品質での製品リリースを進めてきた。しかし、リカーリングビジネスを支えるために必要なサポート部門の顧客からの問い合わせ結果を社内の体制面および問い合わせ分析のタイミングなどの問題から効率よく開発部門にフィードバックすることはそれほど想定できていなかった。顧客問い合わせの定期的分析を製造部門にフィードバックしても次期開発プロジェクト対応では顧客要望の反映に一年以上かかり、リカーリングビジネスにおいては損失につながる可能性がある。
顧客要望や指摘を迅速にパッチリリースや次期メンテナンスリリースに反映させる仕組みを検討し、品質保証プロセスと技術的な問い合わせの発生原因分析との連携が必須であるとため、品質保証プロセスとの連携が可能な問い合わせ分析のフィードバックプロセスの構築を進めた。この既存の品質保証プロセスとの連携および迅速な顧客要望へのフィードバックへの対応方法の紹介およびその効果について解説する。