紹介文 :
システム開発において品質目標値を見直す場合、適切な判断であれば、進行しているプロジェクトの改善にはとても有効である。問題はその適切な判断を行うために何を基準とするか？である。
今回はコード分析では定評のあるCKメトリクスを採用し、その判断基準に使用できるかを試みた。
CKは6種のメトリクスからなる、クラスに対する設計と複雑度を評価する尺度である。
採用した理由としては、設計成果であるコードの情報から判断基準を作成すれば、その時点での品質状況を推測でき、かつ開発途中の目標の変更を実施できるのではないかと考えたからである。
本発表では、実際の開発プロジェクトにこのCKメトリクスをどのように適用し、今回の目的である品質目標値を変更する基準作成がどの程度まで実施できたのか、この一連の取組みについて紹介する。

紹介文 :
我々の組織では、再発防止すべきと判断された不具合を特別なインシデント管理システムで管理し、再発防止策と共に記録している。
しかし、「どのようなテストを行えばその不具合を早期に発見できたのか？」については十分検討されているとは言えない状況であ
る。特に、システムテストなどの上位のテストレベルで発見すべき不具合であるほどその傾向が強いことが経験的にわかっている。た
だし、定量的には定かではない。そこで、現状の調査・分析を行うことにより不足しているテスト技術を特定し、それを補うための活
動を始めた。
まず、インシデント管理システムに記録されている不具合情報から、それらの不具合を発見するためにどのようなテスト分析/設計技
術が必要であったのかを分析した。次に、その分析結果を基に、幾つかの開発現場におけるシステムテストレベルのテスト分析/設計
プロセスを調査し、プロセス上の問題点を特定した。更に、それらの調査結果から判明した不足しているテスト技術を補うテスト分析
/設計手法を確立した。最後に、この手法をアンケートと実際の製品への適用により評価した。
提案手法の主な特徴は、テストタイプごとに思考過程を定めていること、不具合が起こりやすい条件「不具合誘発条件」を導出するこ
と、基本的なテスト設計技法の使用を促進することである。
本報告では、提案手法に至る一連の活動、提案手法およびその評価結果について述べる。

紹介文 :
ソフトウェア開発工程における検出バグの真の根本原因追究とその根本原因に基づいた類似調査/再発防止策定までの一連の作業を標準化しているプロジェクトは多くはない。この一連の作業を標準化していないプロジェクトでは、同様なバグが類似調査で刈り取れずに流出し出荷品質の低下を招いたり、同様なバグを再発防止できずに以降の開発において再発させたりしている。
プロジェクトXにおいても同様でこの一連の作業を標準化しておらず、出荷後のバグ対応に追われていた。そのため、品質を改善すべく品質向上の取り組みとして各工程で検出されるバグの真の根本原因追究から根本原因に基づいた類似調査/再発防止策定までの作業を標準化し、更に開発プロセスを改善するためのPDCA改善サイクルも標準化し実施するように品質分析・評価プロセスを改善した。
その結果、①各工程におけるバグ混入が減少 ②類似調査により同様なバグが検出可能 ③再発防止によりフィードバック課題が明らかになった ④出荷後の発生バグが減少するといった効果を得られた。
本報告では、ソフトウェア開発における品質分析・評価プロセスの改善とその効果について事例紹介をする。同様の課題に悩んでいる開発者やプロジェクト管理者の方の参考となれば幸いである。

紹介文 :
アドバンテストではソフト開発の工期と品質を両立するため、トヨタ開発方式*1をカスタマイズ*2しソフト開発現場で利用している。

*1) 次の文献にて著者が名付けた開発方式であり、「欠陥」だけでなく開発工程で生じる「待ち」や「遅れ」の状態もムダとし、改善対象としている。
”トヨタ製品開発システム”James M.Morgan、Jeffrey K.Liker著

*2) カスタマイズし利用している内容は、次の４つの要素である。
・開発の流れの確立：マイルストーンによる同期化と平準化（SQiP2013にて発表）
・専門家チーム：継続改善を探究する技術者集団（SQiP2014にて発表）
・セットベース開発：多角的な視点から設計の最適解を導出（今回新たに発表）
・知識の再利用：必要な時に必要な知識を引き出す（今回新たに発表）

今回は、カスタマイズ内容を包括的に利用した結果を報告する。課題ばらしの質の確保や改善で使用した方法と指標を再利用することで、改善の継続性を確保する活動を行った。また、課題ばらしの結果を形式化し再利用することで、新規性が高い開発の際に、後から分かる課題を低減する活動を行った。この活動に際し、トヨタＡ３ストーリー*3を新たに導入した。

*3) Ａ３ストーリーとは、問題解決に関する内容を１枚の標準形式にまとめて伝達することを指す。

上記の活動を行った結果、パフォーマンスの向上成果を確認できたので紹介する。

紹介文 :
ユーザーが陥ってしまう操作上での行き詰まりに対して、行為の7段階モデルを元に時系列をさかのぼって分析することで、より本質的な原因を探っています。
この方法を用いることで、ユーザーの心理や行動、認識まで意識することができるため、なぜなぜ分析単独では見つけにくい真因を見つけることができます。

紹介文 :
CMMI(Capability Maturity Model Integration)を活用してプロセス改善に取り組む組織において、成熟度レベル達成と組織のビジネスゴール達成との関連についての関心は高い。組織的なプロセス改善に取り組み、CMMIの成熟度レベルが向上した場合には、それに伴って品質や生産性などの数値が向上することが期待される。実際に、CMMIに基づく改善の効果として、コスト面でのROI改善、見積り精度向上、失敗率の低減など、多くの事例が報告されている。しかしながら、結果としての品質や生産性の良否に影響を及ぼす要因について、開発中の品質や生産性に関するデータ（以降、プロセスデータと呼ぶ）に着眼して分析した研究事例は少ない。
本研究では、ソフトウェア品質の良否に影響を及ぼす要因についてプロセスデータを使用して分析を行った。また、成熟度レベル別に分析することにより、成熟度レベルによってソフトウェア品質の良否に影響を及ぼす要因がどのように変化するかについて考察した。
今回の分析により、成熟度レベルが上がるにつれて出荷後品質が向上することを確認した。また、ソフトウェア品質の良否に影響を及ぼす要因は、成熟度レベル毎に異なる結果となった。これらの分析結果を紹介し、効率的な品質改善に向け、各成熟度レベルで焦点を当てるべき改善のポイントについて述べる。

紹介文 :
近年では、システムテスト自動化を導入するプロジェクトも増加してきた。しかし、効果的に自動化されたテストを作成、運用するにはツールやライブラリを導入するだけでなく、テストプログラム自体の設計と作成、運用プロセスを改善する必要がある。正しく設計されていないテストプログラムでは以下の問題が発生する。

・作成、メンテナンスが困難
・不安定ゆえの低速な実行速度
・分業が難しく、要員の確保が困難

筆者は複数の企業、プロジェクトのテスト自動化支援をする中で、「操作技術」と「シナリオ」のモジュール分割に着目し、プログラム自身の品質向上と、作成、運用する上でのプロセスの改善を実践してきた。本発表では、それらの実践経験から設計のポイントと、分業方法、チーム間での連携を紹介する。

紹介文 :
上級レビューアの欠陥検出テクニックの１つ『欠陥情報をパターン化して蓄積した「欠陥パターン」とレビュー対象を照合して、欠陥混入箇所と欠陥内容を推測することで、素早く且つ高い精度で欠陥を検出する方法』を、初級・中級レビューアも活用できるように、欠陥パターンに一般的に知られている欠陥検出テクニックを紐づけたレビュー手法『DPDT法』を考案している。
また、手法の提案に留まらず、実践で活用できるようにするために、反復練習型トレーニング教材「チョコ・トレ」も開発されている。
この学習教材はレビューアだけでなく、仕様書作成者にとっても非常に有用なものとなっている。

紹介文 :
大規模なソフトウェア開発プロジェクトの現場では、テストにより不具合が数千件摘出されることもある。従来は、不具合の発生傾向や改善が必要な箇所を把握するために、不具合情報へ「重要度」「現象分類」「原因分類」「作り込み工程」「摘出すべき工程」などの定型的な分類情報を付与し、それらの分類情報を機能やプログラムごとに集計することで品質状況の分析を行ってきた。
しかし、ソフトウェア開発プロジェクトで扱う問題は多岐にわたり、問題分析は、予め定義した分類種別を付与した不具合の分析だけではない。問題分析においては、分析する情報が定型的に分類されているとは限らず、また、分類されていたとしても、情報の欠落や属人的な分類判断により、しばしば精度に欠けた情報で分析を行わざるを得ないのが実状である。プロジェクトによって分析の目的／情報／期間はさまざまで、必ずしも上述の方法で品質状況や問題を的確に分析できるとは言えない。
そこで、複雑な情報を可視化する方法として「ネットワーク型データモデル」が研究されていることに着目し、不定形な情報をネットワーク図により可視化することで、分類種別に依存せず、問題点の発生傾向の把握および、改善が必要な箇所を分析できないか試みた。今回、その分析実施例と成果について発表する。

紹介文 :
運用しているWebサイトの使用性（ユーザービリティ）を改善するために、簡易リモートUT（ユーザビリティテスト）を使った素早い課題抽出と、Webサイト目的・利用者ニーズに基づく優先順位づけを提案しています。
UXの専門知識を持たないWeb担当者でも実施可能なやり方になっています。

紹介文 :
近年の機能安全要求の高まりに伴い、車載開発では、顧客から要求を受けた場合、車載E&E機能安全規格ISO26262に基づき、三種類の確証方策（確証レビュー、機能安全監査、機能安全アセスメント）の実施を求められる。各確証方策の実施主体は、第三者性のみ規定され、部門は限定されていない。
三種類の確証方策を別々のイベントとして実施する場合、イベントが増えることで、開発プロジェクトの工数負担が多くなる。また、レビューアー・監査員・アセッサーという実施者を分ける場合、人員の確保、育成も必要になる。SQiP2012では、SQA監査をソフトウェアからシステムに拡張し、「機能安全監査」をSQA監査と同時に行う取組みを発表した。これに加えて、必要な確証方策を更に効率的に実施するために、これまで技術部門が担当していた「確証レビュー」を監査に融合させて実施することに取り組んだ。
本発表では、SQA監査・機能安全監査・確証レビューの融合の取組みについて共有する。

紹介文 :
　我々のプロジェクトでは組み込みソフトウェアの大規模化にともない、複数社のパートナーと協働して開発チームを構成している。製品を構成する機能部毎に開発チームを設け、相互に連携しながら開発と品質の作り込みを実施している。
　高い品質を確保するためには、開発チームが一丸となり、組織や会社間の枠を超えて改善活動を継続することが重要である。しかし、パートナーが異なる複数の開発チームの足並みを揃えて活動するためには、多くの壁を乗り越える必要があった。
例えば、活動評価の数値基準となる品質メトリクスにおいては、各パートナーの見識があり容易には統一できなかった。品質データの収集においては、パートナー工程におけるデータをプロジェクト全体で共有することへの抵抗もあった。また、社員とパートナーで一体となった改善活動、技術継承におけるパートナーとの人材育成計画の共有など、これら多様な課題に対して、アイデアを持ち寄り試行錯誤を繰り返しながら、全員で成果を共有することにより、弊社とパートナー間の高い相互信頼を築いてきた。
本発表では、15年にわたり継続してきた改善活動の中で苦労したこと、得られた成果について報告する。

紹介文 :
派生開発の現場では，変更による影響範囲を特定できないことに起因する不具合が後を絶たない．
そこで，現場でどのように変更の影響範囲を特定しているのかをヒアリングしたところ，調査方法や調査結果の残し方が様々であることがわかった．
また，現場で行なわれている調査の仕方と派生開発に特化したアプローチであるXDDP（eXtreme Derivative Development Process）のプロセスを比較した．
その結果，多くの担当者が調査時に処理の順番に沿ってソースコードを読んでいることがわかった．
このコードリーディングの順番(ソースコードの探索ルート)では，調査範囲が狭くなり，本来目的別に分けて行なうべき調査を区別なく行なっているため，影響範囲の特定漏れを引き起こしやすくなるという課題が見えてきた．
この課題を解決するために，調査を事前調査，変更箇所調査，影響調査という3つのステージに分類し，ソースコードの探索ルートを内容に含む「標準調査プロセス」を定義した．
そして，「標準調査プロセス」を現場で有効に活用するために「調査プロセスガイドライン」を作成し，これらを用いて過去の事例をシミュレーションしたところ，変更の影響範囲の特定漏れを減少させることができた．
また，実プロジェクトに適用したところ，「標準調査プロセス」は技術的に難しいことはなく，現場で有効に活用できることがわかった．

紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。
要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。

紹介文 :
研究会で事例を発表し合った。ところが、内容が伝わらない。実際の仕事でも、仕様が誤解されたり、指示が伝わらなかった等、この種の事例にはこと欠かない。そこで、この問題を解こうとした。
　事実を正確に伝え、そこから推論を組み立てるべきなのに、推論が随所に入って議論が混乱してしまう。あるいは、推論同士で根拠の無い議論が空回りしてしまう。まず、事実を正確に伝えることが伝わる第一歩だ。事実が共有できれば、その上にたつ推論の範囲は狭められる。
　元々我々は、話を受ける側の教育ばかり受けてきて、話し手の教育をあまり受けてきていない。一度本論文を読んで、伝わる/えるにはどうすべきか考え直してみると良い。

紹介文 :
GUI の試験において、テストケースや自動試験コードの作成・保守には多大な工数が掛かる。
本取り組みではそれらの作成を部分的に自動化することで、GUI自動試験の設計・実装の効率化を狙いとする。

画面のテストケースには、操作対象のボタンや入力欄が異なるだけでほぼ同一の操作・確認を実施するものが多い。このことを利用して、以下の手法を提案する:
(1) 複数画面に適用可能なテスト内容を試験シナリオのパターンとして定義する。
(2) 上記パターンに対応した、自動試験コードの雛形を作成する。
(3) 画面上のオブジェクト名称をパラメータとして (2)の雛形に当てはめると、対応する自動試験コードが自動生成されるようにする。
この手法によってテストケースの設計と自動試験コードの実装が同時かつ効率的に実施可能になり、作業時間を削減できる。

本発表では開発中のアプリケーションに提案手法を適用した結果として、
・仕様分析に基づいて作成された試験項目数と自動生成されたテストケース数の比較
・自動試験コードの自動生成による開発コスト削減効果
という2点を主に述べる。

紹介文 :
近年、自動車業界では安全性への関心が高まっており、機能安全規格ISO26262への準拠等、安全や品質保障への取り組みがますます重要となっている。一方、制御の高機能化によるソフトウェアの大規模化や、開発期間短縮への要求も強まっており、品質と効率の両立が大きな課題となっている。
弊社では、従来より、ISO26262相当のソフトウェアテストプロセスを構築している。主に、テストベンチを用いた結合テスト・システムテストの自動化に取り組んできたが、単体テスト（ホワイトボックステスト）においても自動化の可能性を検証すべく、Auto Test Generator（自動テスト生成ツール）の有効性・課題について評価した。今回は、その評価結果について報告する。

紹介文 :
ソフトウェア開発において、有識者によるレビューは非常に重要である。しかし、ドメイン知識の豊富な有識者の数は限られており、有識者にかかる負担は大きい。有識者の負担を減らす為には、レビューアへの教育が必要である。我々はレビューアが早期にドメイン知識を習得し、より質の高いレビューができるようにするトレーニング手法について研究してきた。
我々は2014年度SQiP研究会にて仕様書に意図的にエラーを埋め込み、それをレビューする手法（EIDeR-Training 法：Error Injected Document Review -Training 法）を提案した。ドメインに特化した欠陥を仕様書に埋め込み、教材とすることで、失敗の疑似体験を可能とした方法である。EIDeR-Training 法の教材の作成は20分程度で可能であり有識者への負担は比較的少ない。実験から一定の効果は見られたものの効果にばらつきがあった。
本報告では効果にばらつきがみられる原因について考察し、EIDeR-Training法の改良を行った。実験の結果、シナリオレビューの手法を取り入れレビューアのレベルに合わせた教材を使ったEIDeR-Training法により、若手レビューアの不具合検出率は３３％～３００％向上した。
本報告では、提案手法とその実験の結果、考察について述べる。

紹介文 :
ドキュメントに敢えて記載されることがない暗黙的な情報（ステルス情報）を、レビューの場に引き出し活用することで、認識齟齬や漏れに起因する重大な欠陥を検出するレビュー手法『SBR法（ステルス・ベースドレビュー手法）』を考案している。
ステルス情報を、所有者（ユーザ、プロジェクト、作成者）と、種類（状況、知識、経験）で掛け合わせたマトリクスで整理したり、レビュー対象のプロジェクト特性によってパターン化したり、具体的な引き出し方法についても工夫されている。

紹介文 :
アジャイル開発手法「スクラム」を用いた開発プロジェクトでは、プロダクトオーナー(PO)から見ると、反復開発するスプリント毎では順調に思えたのが、実は開発状況をうまく把握できていなかったために、品質(Quality) ，コスト(Cost) ，納期(Delivery)の問題が開発プロジェクトの後半に発覚することも少なくありません。
そこで、各スプリントと開発プロジェクト全体の問題を可視化し、POがQCD問題の予兆を察知して対策するきっかけを掴めるような「勘所性」のあるメトリクスを提案しています。プロダクト品質の技術面とプロジェクト管理面から絞り込んだ１７種のメトリクスで、開発プロジェクトのメンバからの有益性、実現可能性の評価についても調査しています。