紹介文 :
レビュープロセスの質をチェックリスト形式で評価することで得点化する方法、および、レビュー指摘の価値を指摘工程と影響範囲でポイント化し、金額換算する方法を提案しています。従来のレビュー速度でレビューの質を捉えたり、単純に指摘件数をレビューのアウトプットとするよりは、より実感できる形でレビューの質と価値を把握できます。数値の精度は十分ではありませんが、簡便な方法で実践できるのが良いです。

紹介文 :
ソフトウェア成果物の品質を測定する際の、①プロセスに着目した評価方法と②プロダクトの品質特性に着目した評価方法の両面について整理し、開発現場で実践的に活用できる分析方法を提案しています。

紹介文 :
改善推進側の立場から、『プロジェクト特性に見合ったレビュープロセスの適用』と『レビュー成熟度に応じたレビュー改善』を客観的な診断に基づき推進する手法を提案している。また、その診断を各プロジェクトが簡単に自己診断できるためのツールも開発しており、プロジェクトが自立的にレビュー改善を推進できるように工夫されている。

紹介文 :
品質確保の重要なポイントであるレビューをより効果的にするため、レビューによる指摘項目の、指摘分類、原因分類を最適化し、本質的な問題のみを対象とし、真の原因に応じた適切な対応が可能になるよう工夫をしています。レビューによる品質の評価を、単に指摘件数だけで評価するのではなく、指摘内容を踏まえてより正確にし、また、的確に品質向上につながる対応が取れるなど、有効な方法です。

紹介文 :
2001年時点での「創造的なシステム開発」の方法（＝情報システムにおける要求分析の方法）について述べている。論点は、情報システム発注者の「欲しいもの」だけでなく、発注者の先にいる利用者の「欲しいはずのもの」までを捕えるというところにある。この考え方は、2013年時点では当たり前になっているが、実現の度合いから言うと難しい問題として残っている。

紹介文 :
2012年SQiP Effective Award受賞。 振り返りは、品質に貢献しないと思われています。そこで、「KPT」と「なぜなぜ分析」を組み合わせたKWS振り返りを作りました。 議論のフレームワーク、コミュニケーションのフレームワーク、振り返り結果の横展開のフレームワークで組織レベルの改善ができ、KWS振り返りでは、本音の議論ができ、真の原因も見つけられ、問題解決への意識が高まり、人材育成につながるなどの効果が見られます。

紹介文 :
プロセスを定着させる重要なポイントとして、継続的な改善がありますが、ここでは、継続的改善を具体的に行う手法／手順を提案しています。原因分析シート、不遵守原因リスト、対策分析シートを用いた方法は、具体的で説得力があり、ここで提案された方法を各所で実践されることをお薦めします。

紹介文 :
開発工程にて用いられるW字モデルを品質保証部門における検査プロセスに適用させ、検査プロセスのプロセス改善に取り組んだ事例を紹介しています。品質保証工程において機能仕様書に記載される機能に対する検査観点をまとめた検査観点表をW字モデルにおける上流工程で作成することにより機能仕様の不備やテスト項目の不足を洗出しバグ摘出数の向上とバグ修正工数の短縮につなげています。

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

紹介文 :
ソフトウェア開発時に、以前の類似システムのときと同じ原因の不具合を混入させないようにする、再発防止は十分に実施できているでしょうか？ 開発現場で再発防止策を定着させることは実際にはなかなか容易ではなく、以前の類似システムと同じような問題が繰り返し発生してしまうケースが少なからずあります。 この論文では、再発防止策の定着に有効な要素が何であるかを特定するため、ソフトウェア開発者が再発防止策を実施するときのモチベーションやヒューマンファクターに着目して調査・分析しています。また、分析結果から、再発防止策の定着に結び付ける展開・伝達手法として、どのようなアプローチを用いるとより有効となるのか(「あつ森法」)を提案しています。

紹介文 :
質問表は、工程の最初の頃から発生します。「発生・回答件数」「滞留・遅延時間」を分析することにより、工程の早い段階で、プロジェクトのリスクを検知することができます。また、既存の質問表を分析するだけなので、負荷なく導入することができます。

紹介文 :
組込システムの利便性等をより良くするために製品のヒューマンマシンインタフェース（HMI）に対するユーザビリティの向上を図るためのHMI設計・評価プロセスを提案しています。システムアーキテクチャ設計プロセスにおいてHMI品質メトリックを設定し定量的に評価することにより開発プロセスにおける設計課題を共有化し手戻りの削減やユーザビリティの向上が図れると共にメトリックを蓄積することでHMI品質に対する総合診断が可能になると想定されています。

紹介文 :
本事例は、プロセス徹底・推進のための弱点プロセスや要強化ポイント のあぶり出しや、品質指標の有効性の検証することを目的に、定量データを統合的分析した結果を示したものです。 データマインニングではなく、８０以上の仮説を立てて分析した点が特徴的です。

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

紹介文 :
レビューという品質向上活動そのものを改善することを目的として、 「レビューの振り返り手法」を提案しています。 「レビュー記録という客観的な事実を活用する」、「作成者とレビューアが個別に振り返る」、 「作成者とレビューアがお互いを振り返る」、「継続すべき項目にも着目する」など、 心理的安全性を高めて参加者全員から前向きな意見が抽出され、有意義で合意と納得の行く振り返りができるように工夫をしています。

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

紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか？ 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。 そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。

紹介文 :
レビューの品質を第三者が評価して必要に応じて対策を促すことを目的とした「レビュー品質の可視化手法」および新しい品質指標「予測重大欠陥レビュー検出率」を提案しています。 第三者が客観的かつ容易に、そして各プロジェクトの特性を踏まえてレビュー品質を評価出来るように工夫した研究です。

紹介文 :
本論文では，多くのソフトウェア開発現場で作成・運用されている「チェックリ スト(チェックシート)」の改善を目指した，「Smile - Process for Checklist Design (S-PCD)」法を提案している。 　チェックリストが，チェックを実施する使用者にとっては分かりにくく，チェッ ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で あったり，項目数が必要以上に多いためである。こうした原因がチェックリストを 作成する手法と体系化にあると分析し，チェックリストを改善するために，チェッ クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。 　S-PCD法により、使用者がチェック作業を効率良く行え，ソフトウェア品質向上 に効果があることを実感し，「Smile」を浮かべて作業できるようになり，開発現 場のモチベーションアップに貢献することが期待される。

紹介文 :
開発中のプロセスメトリクス（レビューやテストの欠陥数や各工程の工数等）を使って、リリース後の不具合発生確率を予測するモデルをロジスティック回帰分析を用いて構築しています。一般的に予測モデルというと予測精度の高さにばかり焦点が当たりがちですが、本研究では予測精度よりもモデルの意味するところが、開発現場のプロセス改善に良い方向づけを与えるかどうかに拘ってモデル構築を行っています。また最初に構築したモデルは開発現場に提示しづらいものでしたが、説明変数の選択や使い方を工夫して、現場にとって納得感のあるモデルを構築することができました。メトリクスを活用して予測モデルを作成する際のエッセンスが詰まった研究となっていますので、是非とも参考にしてください。