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

紹介文 :
本発表では開発プロジェクトマネジメントに対する改善提案として、富士通のプロダクト開発部門における第三者検証活動を通して判明して来た一課題から考察し提案するものである。
筆者の所属する組織では富士通で製品を開発する事業部門から独立した第三者の立場として、製品開発のプロセスおよびマネジメントに着目した第三者検証活動（以降、開発プロジェクト審査）を2004年から実施し、富士通のソフトウェア製品の品質向上に貢献してきた。
近年の開発プロジェクト審査の指摘傾向としてプロジェクトマネジメントの問題が散見されてきた。これらの問題指摘について分析を進めた結果、原因の一つに開発計画策定時の品質施策立案に問題があるのではないかと考察した。この検証としてその後の開発プロジェクト審査で品質施策の運用状況を確認したところプロジェクトマネージャーの独自判断によるものが多いと分かった。
各プロジェクトがプロセスを整備する際に部門のQMSに準じているが、品質施策の粒度に関しては定義されていない。そのため今後の開発プロジェクト審査の中で、開発計画段階で品質施策の内容の妥当性を確認し、プロジェクトマネジメントの問題を是正していく。この活動を進めることでプロジェクトマネージャーが円滑にマネジメントできるよう支援し、プロジェクトマネジメントに貢献していく。

紹介文 :
　業務システムの開発においては、関心事の異なるステークホルダーに対して、業務システムの機能や画面といった、仕様に関する情報をさまざまな視点や抽象度で表現し、議論や妥当性確認を促す必要がある。そのような場面において、例えば、技術者と技術者ではない読み手とのコミュニケーションのために、仕様書が用いられる。仕様書は、通常、技術者が作成・維持し、仕様に関する情報をある形式で表現し集約したものである。しかし、技術者ではない読み手には不適切な形式で仕様が表現されることや、読み手のさまざまな視点に合わせた異なる形式の仕様表現との間に不整合が生じるといった課題がある。そこで本研究では、仕様に関する一通りの情報を集約しつつ、読み手のさまざまな視点に合わせた形式の仕様表現を生成するための、仕様書の作成・維持の支援手法を提案する。具体的には、形式手法のひとつであるVDM (Vienna Development Method)によって厳密な仕様表現(形式仕様記述)を作成し、その記述から、機械処理により状態遷移図やシーケンス図といったさまざまな形式の仕様表現を生成する。本提案手法により作成・維持される仕様書は、異なる形式の仕様表現との間の不整合を防ぎつつ、現場担当者や技術者といったさまざまな読み手に適した形式の仕様表現を含むという特徴を持つ。

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

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

紹介文 :
　我々の所属部門は,エンタープライズ型システムインテグレーションを得意としお客さまに対しシステムの開発や保守をサービスとして提供している。
　過去保守プロジェクトでお客さま業務の把握不足が原因の障害が多発したことがあった。
　そこで、我々の所属部門はお客さま業務の全体像や現況の理解を保守業務担当者に促す目的で「保守業務確認会」を開始した。
　このたびの「保守業務確認会」は、保守業務サービス品質底上げを行うことを目的に実施し、ドキュメント不備等に対して改善指導を行った。
　保守業務担当者が所属するチームの改善のＰＤＣＡサイクルと所属部門の組織としてのＰＤＣＡサイクルを見直し、「保守業務確認会」のＰＤＣＡサイクルでの位置付けを明確にしたうえで「保守業務確認会」を実施した。
　所属部門の組織特性に合った保守業務サービス品質の定義、「保守業務確認会」の事前処理と事後処理の手順整理,対面評価シートによる可視化といった実施上の工夫をした。
　ＰＤＣＡサイクルの明確化と実施上の工夫により保守業務担当者自身が改善すべき課題と所属部門として改善すべき課題が確実に解決できるようになった。
　本発表は、保守業務サービス品質の向上を課題とする組織にとって参考となる取り組みの事例紹介といえる。

紹介文 :
要件定義段階で顧客・ユーザとの認識の齟齬を減らすには、UX手法が効果的ですが、
開発現場で導入するにはまだまだ敷居が高い状況です。しかし、従来のやり方や設計書の
書式を大きく変えなくても、要件定義時に5W1Hを考慮するというちょっとした工夫を
加えるだけで、要件の齟齬や漏れを減らす効果があります。
またスマートスピーカーを題材にした検証結果も掲載されており、実践の参考になります。

紹介文 :
基本設計書を初めとする上流工程のドキュメントでは、しばしばテストなどの後工程で必要な情報が抜けたり、曖昧な記述により情報が伝わらなかったりします。本論文では、テストケースの自動生成を見据えることで後工程に必要な情報を漏れにくくする設計書の作成アプローチを提案しています。

紹介文 :
　製造装置の組み込みソフトウェアの開発は、装置の初期開発から保守にいたるまで開発期間が長く、その間に機能追加、機能改修を随時行う必要がある。特に新規装置では改良が頻繁に行われ、ソフトウェアは定期的にリリースされる。この定期的なリリース毎に、開発チームでは開発から実機組み込みまでフェーズを分けてテストを行っている。
　リリース前のテストでは、目的の異なる２つのテストを行っている。作った機能が仕様通りに動くことを確認する仕様ベースのテストと欠陥検出を主眼としたテストの２つである。仕様ベースのテストを主とし、欠陥検出のテストで仕様ベースのテストを補完するようにしている。
　これらのテスト活動を行っているが、リリース後(装置組み込み後)に欠陥が検出されることがある。欠陥を検出しきれていない問題にはいくつかあるが、その中でも欠陥検出のテストがアドホックなテストとなっている点に着目し、このアドホックな欠陥検出のテストを探索的テストとするべく取り組んだ内容を報告する。

紹介文 :
ソフトウェア開発は規模が大きくなり、一つのプロダクト構築に向けて複数名が作業を行うことは当たり前になっている。複数名で同一の設計文書をつくる場合、テストベースにもなる設計文書にばらつきが発生してしまうことが多い。また、開発期間の短縮、必要な情報を提供する締め切りの厳格さによって、テストベースにおいて情報の散逸や、必要な情報が存在しない、という状況が発生する。
これらのテストベースにおける問題がテスト設計を困難にする。テスト設計の困難さがテストケース抜けを発生させ、最終的に不具合へとつながってしまう。市場での不具合は大きな損害をもたらすリスクとなる。
本論文では、テストベースとなる設計文書にばらつき、必要情報の散逸、情報が存在しない状況を想定し、テストケース抜けを防止する「テスト詳細設計プロセスの手順」を提案する。テストベースの各問題に対応したテストケース設計手順を定義し、テンプレートを活用して設計を行うことでテストケースの抜けを防止する。
また、提案する方法を用いてテストケースを実際に作成し、従来的なテスト設計方法と比較を行った。結果として得られたテストケース抜け防止の効果についても報告する。
なお、記載した問題は設計側での解決が理想的だが、本論文ではまずテスト側で対処を行った上で、検出した問題発生状況を活用して設計側の改善を行う想定で提案を行う。

紹介文 :
多くの企業では、ソフトウェア開発の過程で欠陥が混入しないように予防策を講じている。しかし、欠陥は人間の誤りにより発生するため混入をなくすことは容易ではない。そのため、市場に欠陥が流出しているのが実情である。
そこで我々は、欠陥は混入するという前提の上で、以下の問題の解決を目標とした。

・同じような欠陥を取り逃さない。
・後工程に欠陥を流出させない。

この問題を解決するために、欠陥混入のメカニズムに着目し、欠陥検出時に得られる情報を用いて他の潜在欠陥を検出する手法の確立を目指した。
本研究ではまず、「Aという欠陥が発生すれば、Bという欠陥も発生するという性質」を欠陥の共起性として定義する。
そして欠陥混入のメカニズムを表現する手法である「欠陥モデリング」と、要素の関連を解析するのに適した「グラフ理論」を用いて、欠陥には共起性があることを示す。
そのうえで、欠陥の共起性と推定アルゴリズムを用いて潜在欠陥の推定を行う「共起欠陥推定アプローチ」を提案する。
「共起欠陥推定アプローチ」の有用性を検証した結果、欠陥混入の要因と欠陥の関連の強さを考慮することで、より潜在している可能性の高い欠陥を推定できることを確認した。
本発表では、欠陥の共起性と共起欠陥推定アプローチによる推定手法について、具体例を交えて紹介する。

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

紹介文 :
新しい安全解析手法「STAMP/STPA」にセキュリティ適用をし、
「アシュアランスケース」で分析の妥当性確認をした初めての研究事例です。
脅威にはSTRIDE分析、影響評価基準にはASILを用いました。
保証の全体像を定めた上で、セーフティとセキュリティ双方のリスク抽出、評価、対策まで作り込みました。
「自動運転」での事例はお役立ち間違いなしです！

紹介文 :
プロジェクトの振り返り”活動結果を、他のプロジェクトでも活用し、反映させ展開することは、実際には難しいという問題がある。
　本テーマは、この問題に焦点を当て、展開すべき振り返り結果の改善策(TRY)の納得感を高めるため、振り返り分析プロセスについて、観点シートで網羅的な成功点/問題点(KEEP/PROBLEM)を抽出し、QCD観点から他への展開の重要度が高い問題点を選定して、それを分析シートで真因分析するよう、手を加えることから始め、担当者だけでなく管理者や改善支援担当も含めた展開のための振り返りも行って、改善策の反映プロセスでの情報伝達・実践状況の実行支援の仕組みまでを一貫させて結合しようとする、組織改善に欠かせないプロセス基盤構築の研究である。

紹介文 :
既存システムの改修を行う派生開発では、開発側も顧客側も機能要件に意識が集中しがちなために性能要求が要求仕様書に明記されず、応答時間や処理速度の劣化を招くことがある。このような性能劣化は開発終盤や納品後に判明することが多く、そのため修正に大きなコストがかかる。
そこで我々は、機能の追加・変更に伴う性能劣化について顧客と交渉が容易な要件定義フェーズで把握することが重要ととらえ、システムの改修が時間効率性に与える影響を処理時間に換算して検出するための方法「EMOT (Estimation Method Of Time behavior degradation)」を考案した。
本論文では、本手法により時間効率性の劣化を機能の追加・変更要求から検出することができ、要件定義フェーズで性能劣化の対策を講じることで時間効率性の劣化防止に寄与できることを示す。

紹介文 :
過去のレビュー指摘を分類・活用しようとすると、これまでは必ずと言っていいほど、管理者視点で行われてきた。
本論文では管理者視点と共存する形で、作成者視点の分類・活用方法が提案されている。
実験で付与されたタグは大きく６つに分類され、「機能系」「対応方法系」「品質特性系」だけでなく、「注意喚起系」「表現方法系」「影響度系」といった作成者ならでは視点があり、具体的なキーワードでタグが付与されている。
作成者にとってレビュー指摘を検索・活用しやすくなると共に、作成者自身が自由にタグを付与できるため、品質向上活動への能動的な関与の促進が期待できる。
レビュー指摘を組織的に蓄積・横展開し、作成時の品質向上に活用したいと考えている組織の方は、一読されることをお勧めする。

紹介文 :
製品知識や開発情報・技術のノウハウは特定の担当者によって異なるが、偏りが進み過ぎると、伝達すべき情報や技術が継承されず，製品を改造・流用する際に製品仕様や設計、実装時の検討漏れや誤りなどの原因となって問題を引き起こす場合が多い。
　本テーマは、この“いわゆる属人化状態”の分析に焦点を当て、プロジェクトチーム内の担当者同士による技術面での個人依存度の主観的な相互評価の値と、レビュー実施時の各担当者別の発言時間という客観的な測定値とを組み合わせ、担当者を「職人領域」，「属人領域」，「教育領域」，「点検領域」，「適正領域」の五つに分類し、チーム内の担当者の相対的な属人化の進行の不均衡さ（チームバランス）を可視化することによって、
管理者が各領域のバランス状態を確認し、必要な育成リソースに対する過不足を把握して、
問題発生前の事前対応計画作成に役立てられるよう、属人化状態の測定・可視化を通して改善する仕組みを構築しようとする研究である。

紹介文 :
要求獲得におけるゴール指向要求分析の活用は有効であるものの分析に時間がかかってしまうことや個人の知識や経験に依存してしまうような課題があり、その解決のため、誰でも簡単に活用できる手法として「ゴール指向Lite」を考案した、という内容の論文です。
従来手法の実用化を目指し、属人性排除の為の適度なガイドや効果を損なわない適度なシンプル化が秀逸であり、論文の構成や文章も大変分かり易く、定量的な分析や効果の確認が行われており大変面白い内容です。

紹介文 :
ソフトウェアテストの現場ではコスト制約と納期に迫られるなか、良さそうと分かっていながらテスト分析・設計を行うことができない現状がある。そこで、本研究では、そのような短納期でかつ小規模な開発プロジェクトに対して、テスト分析・設計の有効性の検証を行った。
その結果、小規模・短納期プロジェクトのテストにおいても、テスト分析・設計を行う効果を確信することができている。
これは、当然の結果ではあるが、多くの組織で未だテスト分析・設計の導入をためらっている現状において、背中を後押しする有用な論文である。

紹介文 :
派生開発において、変更要求を実現した結果、当初の”設計制約”が変わることがあります。このような、本来の変更に付随して発生する”前提条件の変更”は見つけにくいものです。本研究では、これを”欠陥混入メカニズムの知識”を活用して把握しようというものです。