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

紹介文 :
プロセス改善を進めるにあたって発生する様々な課題について各社の対応事例を分析しガイド(事例集)としてまとめたもの。プロセス改善の難しさの一つとして、対応する組織やプロジェクトの状況が経験した改善と同じ状態ということがほとんど存在しない場合が多い。このため、多くの解の中から適切な事例を参考に対応することが多く、手持ちの解を充実させるためにも有益な研究となっている。

紹介文 :
組織標準プロセスをプロジェクトに適用する際には、プロジェクトの特性を考慮した最適化／効率化であるテーラリングが重要ですが、これを正しく行わないと、かえってプロジェクトの失敗を起こしかねません。そこで、ここでは、テーラリングのパターンを整理し、それぞれの影響度やリスクを明確にし、テーラリングを行う上でのポイントをまとめるとともに、これをベースに各組織でテーラリングガイドラインを作成する方法を提案しています。プロセスの有効な活用にとって非常に有用です。

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

紹介文 :
品質レベルの兆候をいち早く察知し事前に手を打つことは、品質確保の究極の活動である。
本テーマは、「健康診断」にて活用される「問診票」の考え方をプロジェクトの予兆察知に活用し、ソフトウェア品質確保に適用した事例である。
「問診票」をチェックリストとして活用しているが、人の行動や思いにフォーカスした質問も含んだ形態であり、質問内容の抽出の過程に興味を引く論文である。

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

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

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

紹介文 :
品質保証部門の目線でなく、開発現場での目線にてデータ活用の”見える化”・”うれしさ”を解り易く紹介している。
更に、現場での”うれしい”メトリクスを多面的に考察し、実践事例を基に最適データ活用を提示している。

紹介文 :
本研究は、新たな開発スタイルにも柔軟に対応可能な、組織資産管理システムの一手段を提案している。
「組織標準プロセスの構造とテーラリングの概念」にて、部品化した組織標準プロセス（静的プロセス）を、時系列を考慮したライフサイクル（動的プロセス）に合わせて、プロジェクト特性に最適なプロセスを選択するテーラリング指針の概念を提供する。

紹介文 :
継続的プロセス改善を浸透させる仕組み作りを検討中の組織は、本IDEALモデルの導入手引書（良い事例、悪い事例）の活用により、効率・効果的に改善プロセスを実装可能となる。

紹介文 :
本研究は多くの組織で聞かれる現場とプロセス改善支援部門(SPI/SQA等)の間でのギャップをどのように埋めていくかをテーマとしている。
その解決手法として、現場の思い込みを解きほぐしていくことが重要と考え、なぜなぜ分析やTOCfE等をベースとした新しい手法(GMS法)を提案している。
これにより、現場と支援部門双方が共通の目標を持つことができWin-Winの関係を築くことが可能となる。

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

紹介文 :
プロジェクトにおける標準プロセスの定着度を、実態に合う形でより正確に評価するメトリクスを提案しています。具体的には、プロセスが定着していることを、仕組みが機能し、ルールが守られ、継続的な改善が行われていることととらえ、それぞれの観点から評価するメトリクスを用意しています。また、測定を正確に行うための各種チェックリストを用意している点も、この方法の有効なポイントです。

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

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

紹介文 :
プロジェクトの失敗リスクを予兆となるシグナルを事前に察知し対策をする「みえる化モデル」を提案しています。たとえば、リスク管理表の分析結果や、進捗管理データ、残業時間の推移、未解決課題数などを定量的に判断し、失敗する前に対策を打つ取り組みに役立つ内容です。成功プロジェクトを増やす開発プロセスを検討したい方にお勧めします。

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

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

紹介文 :
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。