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

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

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

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

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

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

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

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

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

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

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

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