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

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

紹介文 :
本論文は、論文作成時最新のプロセスモデルであったCMMI-SE/SW v1.02について、調査とその試行結果をまとめたものであるが、アセスメントに必要な工数や、モデルの意義や懸念などがまとめられており、現時点においても、CMMIに基づくプロセス改善を行う際には、十分参考になるものである。

紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。

紹介文 :
UCD手法をアジャイル開発に取り入れて実施することで、ユーザビリティの高い製品を効果的に開発することができる方法を提案しています。短納期で使いやすいものを作ろうとする場合に参考になります。

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

紹介文 :
XDDPは、派生開発に特化した開発プロセスであり、要求仕様からソースコードの変更までの範囲を扱う。一般に、プロセスは個人の習慣や組織の慣習になっているため、XDDPの導入の際にそれまでの慣習が障壁になる。本報告書は、「XDDPの導入障壁」を最初に扱ったもので、障壁の種類や背景について整理されており、さらにいくつかの障壁について克服のヒントを提示している。 ここから、XDDPに取り組む際にはどのような障壁が生じるか、またその克服方法を考えるヒントが得られるだろう。

紹介文 :
データベース（以降、DB)を共有し合う業務システムでは、他システムのDBの変更が自システムへ与える影響を正確に把握し対処する必要がある。過去の不具合事例を分析したところ、データ項目間の関係性の変化やデータバランスの変化を発生させる類の変更は、不具合の可能性を見過ごしやすいことがわかった。そこで、DB変更時の必須チェック項目と、関連システムのTMを組み込んだシートを作成し、これを介して「変更要求」「理由（背景）」「想定される影響」を伝達するしくみを考案した。

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

紹介文 :
アジャイルプラクティスを教育の場としながらも品質を確保する取り組みの事例紹介です。課題設定とアプローチ、その実施結果が明瞭にわかりやすく表現されているでとても参考になります。

紹介文 :
ASILモデルの安全性レベルをベースにして危険要素を監視する構成モデルの検出レベルと独立性の評価を行いシステムの分割要件をまとめた研究論文である。

紹介文 :
現状アジャイル開発でウォータフォールと同じような品質保証活動を行うと、過大な工数がかかるか、品質保証活動が開発の終盤になってしまう。 この課題を解決するために、品質保証部門のみによる監査ではなく、開発現場自身がセルフチェックを行うことで相乗効果を狙うアプローチを「QAAD42」(Quality Assurance in Agile Development by 42)と命名し検証を実施し、その効果を確認した。

紹介文 :
ソフトウェアを修正した場合の影響範囲をいかにして把握し、考慮漏れを防止するのかが提案されています。影響範囲が発生するメカニズムの考察や影響確認の手法も参考になります。

紹介文 :
プロトタイプを用いることでお客様の真の要求を掴み、サービス品質を高めることで、CS(Customer Satisfaction)を超えるCD(Customer Delight)：顧客歓喜を実現するプロセスが提案されています。業績向上、従業員満足度向上につながるサイクルも提示され、経営者にとっても魅力的な研究内容になっています。

紹介文 :
既存システムに対して変更や機能追加を行う際、変更箇所や変更による影響範囲を特定するために既存システムのソースコードを調査する。この調査方法が人によって様々で、調査結果もレビューに耐えられるものではなかった。そこで、調査の目的を3種に分類し、標準調査プロセスと調査プロセスガイドラインを作成・検証した。

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

紹介文 :
開発規模の増大、開発期間の短縮、仕様変更への柔軟な対応を目的に、チケット駆動型開発を取り入れた事例です。新たな開発プロセスを導入した際に、プロセスの理解度向上を図る取り組みも併せて紹介されています。

紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。 そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。 この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。 逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。

紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。 そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。

紹介文 :
　エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。