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

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

紹介文 :
本報告は、筆者組織のSQA監査の取り組みに関する報告です。SQA監査に対する要求などを、ISO/IEC25000(SQuaREシリーズ)やISO/IEC9126で述べられている品質特性や、機能要求・非機能要求をベースにして取り組んでおり、また効果的なSQA監査活動や担当者のスキルアップに効果があったことが報告されている。簡潔にまとめられており、SQA監査活動にしている方々にとってはよい参考事例になると思います。

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

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

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

紹介文 :
ソフトウェアテストの自動化ツールは、導入の要望は高いものの、効果や導入の準備などさまざまなことを考えるとなかなか踏み切れない方も
多いのではないでしょうか。
この論文は、テスト自動化への「取り組みやすさ」を考えて、段階的に導入を進める方法を提案しています。

紹介文 :
チームが自立的に動いてくれない。どうすれば自立的に動いてくれるかという古くて新しい問題に立ち向かった。
まずは、チームの能力のよってたつ構造を明らかにした。チームの能力は、4つの属性から成り立っている。環境属性、リーダ属性、メンバ属性、組織属性である。各々の属性は説明変数に分解される。これらの変数には、変えられる変数と変えられない変数、さらにその中間的な変数がある。
リーダは、チームの状況に応じて、どの説明変数を変化させれば良いかを考え、組織を変えたり、メンバーを変えたり、教育したり働きかける。こうすることで、メンバの自主性・主体性が発揮され、チームを活性化できる。

紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人（熟練者）」に依存することが多いが、この研究では、共通仕様に関する変更情報を１箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。

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

紹介文 :
エンジン制御器（コントローラ）開発においてモデルベース開発（MBD）を導入することにより開発期間の短縮は実現できましたが開発プロセス後半の開発効率の低下は改善できなかったことからMBDの開発プロセスを見直しを行い、ソフトウェア構造と制御対象（プラント）に着目し、シミュレーションを用いるテスト駆動開発を取り入れたプロセス改善方法について提案しています。発表内容はエンジン制御に特化していますが、他の制御機器にも適用できる開発プロセスだと思います。

紹介文 :
レビューの適切な実施時期と適切な観点は悩ましい問題です。やり方によっては指摘内容が全く無駄になることも少なくありません。本発表はレビューの実施時期と観点を適切に変えましょう、といういわばあたりまえを地道にやっています。特にレビュー観点の4象限（粒度と誤り度合い）から導かれる、レビュー観点の実例が見所です。「誤り」軸で「誤りでない」ものは欠陥とは言えないのでは？という話はともかく、気軽に読めてすぐ実効に移せる実用性の高い内容になっています。

紹介文 :
効率的かつ効果的なテストを行うためには、テストアーキテクチャの設計が重要なポイントです。
そこで、発想を整理するマインドマップを使ってテスト観点を抽出し、その観点の整理方法とともに、テストプロセスを提案したのが、この論文です。
提案する手法は、実際にソフトウェアテスト技術振興協会（ASTER）の「テスト設計コンテスト」に出場して効果を検証したものです。

紹介文 :
単体テストで見逃す欠陥数に最も相関が高いのが規模であるという、非常に単純かつ強烈なメッセージを投げかけています。データ分析の進め方という意味では非常に参考になる論文です。サイクロマティック数やネスト深さなどいかにも関係ありそうな数値はあまり効いていないことがわかるのもよい点です。ただ惜しむらくは、肝心の規模等すべて相対値なので、読んですぐ使えるタイプの論文ではありません。また対象としているソフトウェア規模も比較的小さく、実験的性格の強い論文であることを念頭に置いて読む必要があるでしょう。

紹介文 :
システムを開発して納品する間際にお客様から「これでは使えない」と言われたことはありませんか？
本論文では、プロジェクトがこのような状況に陥る可能性がないかを「診断」するためのツールと、診断で判明した問題を解決するためのUXデザイン手法がすぐわかる「処方箋」を提案しています。
２つのツールは組み合わせて使用するだけでなく、それぞれ単独で使っても効果が見込めます。
これからUXデザインを学んで実践しようとする方も、実施検討のために活用していただけます。

紹介文 :
開発プロジェクトの中でも特に難しい要件定義の見積もりとコントロールに果敢に挑んだ例として目を引きます。特にCCPMとは何かを知りたい方、実際にCCPMを回してみたい方にはおすすめです。今回は要件定義に絞って書かれていますが、見積もりのしやすい作業と難しい作業に分けて別々の管理手法をとるという本論文の考え方は、新技術・新規分野への参入など、工数が読みにくい局面のコントロールに威力を発揮するでしょう。

紹介文 :
非クリティカルシステムの短期開発に取り組むときに、参考になる研究です。QAチームと、開発者、ユーザー、ツールの関わり方についても提案されており、QA担当者だけでなく、開発者やマネージャーにも有用です。
後半には事例紹介もありますので、実際の開発チームやQAチームの動きや効果の詳細を知りたい方にも役立つ内容となっています。

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

紹介文 :
プロジェクトにおけるリスクマネジメントの成否は、プロジェクトマネージャ等など取り纏め者の経験やスキル等に依存するところが大きい。これに対応するため、筆者らは、過去事例や一般事例等を集めた「経験値リスクDB」を作成し、自分たちのプロジェクトの特性から「経験値リスクDB」よりリスクを抽出することで、リスクの見える化および関係者間でのリスクを共有することで、トラブルプロジェクトの削減効果があったことが報告されている。リスクマネジメントに悩んでいるプロジェクトマネージャなどには参考になる事例だと思います。

紹介文 :
保守プロジェクトの改善の着手や進め方について悩んでいる方、改善のための指標項目の事例を知りたい人に、特に参考になる内容です。
筆者らの施策で設定した目的や指標項目、PDCAサイクルを利用した活動内容にも触れられており、読者自身の現場で使っている指標や活動内容と照らし合わせながら読むことができます。