紹介文 :
KPTとなぜなぜ分析を各々改良して組み合わせた、「KWS振り返り」
([K]PT+[W]hy なぜなぜ分析+[S]olution 対策）を用いた振り返りの仕組みを確立した。
「KWS振り返り」は3つのフレームワーク（議論、コミュニケーション、横展開）、2つの手法（KPT、なぜなぜ分析）、およびそれらを活用するためのプロセスとテンプレートからなり、プロジェクトの振り返りに有効であった。
本研究は2012年度も継続して研究され以下のテーマで登録され知恵るので、参照していただければ幸いである。「KWS振り返りで得られた知識と知恵を、組織的に活用する仕組みの研究- 同じ失敗を繰り返さないために、先人の知恵と知識を先取りする仕組み -」

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。

紹介文 :
リスク管理から閾値を超えた場合は課題管理にうつり、課題の振りかえりにより、次の開発時に新たなリスクの抽出にしよする。このリスクが閾値を超えた場合は課題管理にうつる。この無限につづく繰り返しを「乙∞（おつむげんだい）モデル」として開発した。課題管理プロセスとリスク管理プロセスを融合した、「乙∞（おつむげんだい）モデル」は、プロセス効果の定量化と合わせて有効性で現場で適用可能であると結論付けられた。

紹介文 :
「一般的な言語 対 ドメイン特化言語」、「上流での実装詳細の捨象の程度」など、記述方式の特化性はソフトウェア開発における難しい問題です。本論文は、フレームワークを用いた開発における形式仕様記述の活用に関し、この問題について様々な観点からの試行と議論を試みています。

紹介文 :
ビジネスのモデリング手法 "G2BizMo" を用いて、重複なく漏れなく要求仕様定義を行う方法について示しています。ビジネスのフローを状態遷移図として表し、そこから状態遷移マトリックスを作成、マトリックスに対してさらに処理を追記していくことで、要求を検討、記述、精査を行うことができるようになります。簡単な例題であっても、間違いなく網羅的に考えることは難しいです。そのことを再確認しながら、現実の業務を根本から見直す要求分析の手法について考えてみませんか。

紹介文 :
レビューの重要性／技法の解説は一般的に普及しているが、レビュー担当者の必要教育／育成に関する書籍・論文は極めて少ない。また、体系的な技術教育としての学習範囲／分類のまとめみならず、品質担当者育成の段階的教育／経験・キャリア別の育成に関する方針書としても、「心構え」といった観点を加えて解説している点が特筆に値する。
企業の品質教育の一助として価値がある。

紹介文 :
フィールドで嫡出されたバグを分析して、嫡出漏れを防止するテストを特定する。また、そのテストケースを生成するテストケース設計技法を採用しているかを分析して、その組織に採用が必要なテスト技法を抽出する。
また、分析途中には、どの段階（テストレベル）でどのようなテスト技法を使えばどのようなバグを嫡出できるかという知識が必要になる。そのため、①テスト観点を仕様ベース、構造ベースで分類した表の作成、②テストレベルとテスト技法の関係、③その技法で嫡出可能なバグ例が報告されている。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法（形式仕様記述）」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。

紹介文 :
企画品質、要求を満たしている、すなわち、不具合がないといった(あたりまえ)品質ではなく、ユーザーにとって魅力的な製品企画を目指した評価方法をユーザエクスペリエンス(UX)手法の一部である「ペルソナ」や「シナリオ」を組み合わせを用い。具体的な事例と共に提案しています。あたりまえ品質から魅力的品質へ、顧客満足度を向上させ次回も後継製品を愛用してもらえる品質を目指す方にお勧めします。

紹介文 :
ソフトウェアのテストについてはソフトウェア工学において研究が進んでいる分野ではあるが、そこにまた新たな視点が加わった。本論文はレビューで早期にエラーを検出する際に3つのレビュー観点を提案するものだ。レビュー品質の向上を目指す方にぜひご一読いただきたい。

紹介文 :
シナリオテストは様々な組織で実践されていると思いますが、方法論は確立していないのが実状です。本論文のように具体的な手順とその実践例が示されているのは、非常に有益です。

紹介文 :
システムが大規模化し、関係組織が多岐にわたる状態になっているにもかかわらず、多くの組織ではシステム全体を知る人材を確保してこなかった。そのため、変更が他部門に影響することを事前に判断できなければ、大きな問題が起きる。特に、「仕様」の状態で変更依頼が届くケースでは、直接関係する部分がイメージしやすいため、他への影響に気付きにくい。この報告書では、仕様レベルで届いた変更依頼から、組織レベルで変更を捉え直す方法を提案している。ただし、変更においても「要求」と「仕様」の階層で捉えることが前提となる。

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