紹介文 :
熟練担当者が暗黙の了解として扱うためドキュメントに記載されない仕様や設計の理由に関する情報（「マイスター情報」）を引き出し、形式知として残す方法を提案しています。

紹介文 :
短納期開発現場で、成果物の形態を変えたり新しい手法を導入したりするには、時間に対する不安や効果に対する不安を排除する必要があります。本研究は、XDDPを短納期開発現場に導入する際の不安を払しょくするための施策を提案しています。

紹介文 :
ISO9001（2000年版）の認証を取得してる企業がCMM(SW-CMM)の取得を目指すためのガイド。
ISO9001認証後にプロセス改善を行う際にCMMIを参考にする場合にも有効。
ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。

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

紹介文 :
本研究は、二つのモデルを組織に導入するための、一手段を提供している。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　興味深い内容としては、ソフトウェアプロセス改善モデルCMMとISO9001を融合させる研究過程の活動内容より、ソフトウェアプロセス改善モデルの構造・構成要素を深く理解することが可能となる。

紹介文 :
アジャイルソフトウェア開発の一手法であるエクストリーム・プログラミング (XP) を導入する際の課題について、ＳＬＣＰ、ＰＭＢＯＫ、ＩＳＯ９００１、ＣＭＭとを比較し、特に品質の側面での懸念を抽出した報告です。アジャイル開発における品質確保の方法については、現在でも変わらず課題であり、この報告を自組織のソフトウェア開発に当てはめ、どのように品質を確保するかを考える際に役立てることができます。

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

紹介文 :
試験フェーズ（ISO/IEC 15288の検証プロセス、妥当性確認プロセス）を中心に、プロセスとメトリクスの相関をモデル化しています。
作成したプロセスとメトリクスの相関図は、プロセスとメトリクスの関連を示すだけでなく、フィードバックの関係も示しているため、同図を用いて、プロセス改善の方法の検討及び導出に利用できるものとなっています。

紹介文 :
EVMSをこれから導入する、あるいは導入したがどうやって運用したらいいか迷っているプロジェクトマネジャ向けの論文です。

EMVSを運用するとき、誰もが「こういうときは、どうすればいいのだろう」と悩む事例に、FAQの形式で解を提示しています。
EMVSで使う帳票の例も記載されており、実用的な論文になっています。

紹介文 :
本研究は、品質保証メンバーが客観的役割を基本としつつ、品質保証活動より得られた知見を活かして、開発プロジェクトに積極的に寄り添ってQCD 問題解決を促進する活動の提案である。
調査分析から、開発プロジェクトが品質保証メンバーに期待する支援範囲を抽出し実践した、大変有用性の高い研究である。

紹介文 :
ECサイトのベストプラクティスと言えるAmazonサイトの成功要因をユーザビリティの観点から探っています。書籍ECサイトに対するガイドラインによるチェックにより外から見た静的な評価を行ったり、利用者のタスク分析により動的な評価も行うことで多面的にAmazonサイトを分析しています。ちなみに、『Amazon Hacks』と言う書籍の翻訳も研究活動と並行して行うことで、サイトが意図していることや内部の作りについても深く研究を行っています。

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

紹介文 :
ソフトウェアテストにおけるテスト技法については、効果は理解されているものの展開が難しく、人によるばらつきや抜け漏れのためにテスト品質が
確保できずにお困りの方も多いのではないでしょうか。
とはいえ、本や机上で学んだだけでは、適用が難しいのも事実です。
この論文では、テスト技法を現場に適用したときの問題を想定し、解決策を提案しました。

紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。
XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。
そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。

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

紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。

紹介文 :
品質の向上とは、究極的には顧客満足度の向上であり、そのためには、組織全体を、顧客に対する新しい価値を創造し、積極的に提案する顧客価値経営に到達させることが必要である。本論文は、「日本経営品質賞」のフレームワークをベースに、顧客価値経営到達への道筋を、具体的改善項目の実施度合により示しており、アセスメントと改善の繰り返しにより組織レベルを向上させることができる点が、有益かつ実践的である。

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

紹介文 :
ソフトウェア開発プロジェクトを円滑に進めるためには、コミュニケーション（情報伝達）は重要な要素である。プロジェクト内で「コミュニケーションに関する問題」が発生すると、プロジェクトは開発現場の諸問題に気づかずに適切に対処しないまま進行しがちとなり、メンバの士気低下やプロジェクト全体の雰囲気が悪化する。これは、さらに潜在する課題の増加を招くので、プロジェクトにとって大きなリスクとなり得る。
そこで本研究では、プロジェクトリーダ、チームリーダ、チームメンバ間のコミュニケーション問題，士気／雰囲気の問題を察知するための質問を「コミュニケーション問診票」として作成し提案し、試行している。そして、「コミュニケーション問診票」を適用して“問題点を検知”し、「コミュニケーション問題箇所特定図」にて“問題点を特定”し、PMOやSQAなどのプロジェクトの第三者の専門部門にて作成された「処方箋」提案をもとに、プロジェクトリーダ、チームリーダ、チームメンバが各範囲で“問題に対処”する流れを体系化した。コミュニケーションの問題は可視化が困難であるが、プロジェクト全体を俯瞰した図を活用し、見える化を図った興味深いテーマである。

紹介文 :
AI/IoT時代の新しい安全分析手法として注目されているSTAMP/STPA (Systems Theoretic Accident Model and Processes / System Theoretic Process Analysis)は、セーフティとセキュリティのリスクを同時分析が可能であることを本分科会では昨年度、初めて提言しました。今年度はSTAMPを用いた場合と用いない場合に分けて、自動運転の利用シーンを具体化した事例による実験を実施し、STAMPによるセーフティセキュリティ分析の有効性を確認しました。
論文とともに具体的な分析の一連の証跡、分析手順、実験の質問事項や結果、用語集など、利用価値の高い付録も収録しています。ぜひご活用ください。