紹介文 :
サービス品質(含：顧客満足（CS)、および従業員満足（ES)）に関する研究論文。特にCSとCD（Customer Delight）について考察し、さらにはCDに関するプロセスについて言及している点がテーマとして特筆に値する。主たる顧客満足において「感動」の重要性を考察している。
特にマーケティングの父：フィリップ・コトラーの顧客満足度の４段階、およびカール・アルブレヒトのホッケースティック・ロイヤリティを引用しながらサービス品質に必要な「感動」を解説している点がユニークである。

紹介文 :
プロジェクトで問題を解決したので、原因や注意点などをまとめて書いた。社内規定通りにやったし、これで障害処理は完了したとする人が大半だ。
本当に完了したのだろうか。次にこの情報が必要になる時、書かれた注意点が読まれる保障はないし、書かれていることさえ分からないかもしれない。
書いただけでは問題は解決しない。人の行動様式を踏まえて対策をとるべきだ。

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

紹介文 :
上級レビューアの欠陥検出テクニックの１つ『欠陥情報をパターン化して蓄積した「欠陥パターン」とレビュー対象を照合して、欠陥混入箇所と欠陥内容を推測することで、素早く且つ高い精度で欠陥を検出する方法』を、初級・中級レビューアも活用できるように、欠陥パターンに一般的に知られている欠陥検出テクニックを紐づけたレビュー手法『DPDT法』を考案している。
また、手法の提案に留まらず、実践で活用できるようにするために、反復練習型トレーニング教材「チョコ・トレ」も開発されている。
この学習教材はレビューアだけでなく、仕様書作成者にとっても非常に有用なものとなっている。

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

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

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

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

紹介文 :
教育の効果は、育ちたいと思っている人の「学びたい」、「知りたい」、「出来るようになりたい」と言う欲求(WANTS)の有無で大きく変わる。
この論文では、プロジェクト・マネジャとして成長したい、或いは、プロジェクト・マネジャになりたい人々に欲求を植えつけるにはどうしたら良いかを解いた。

紹介文 :
現場の開発者がUX手法の本来の目的をしっかりと理解し、かつ手法の効果があがるように展開するためには、UX手法の有識者によるサジェストが有効であると提案している。UX手法の組織導入・展開を行う場合に有益な示唆を与えてくれる内容である。検証実験で使用したサンプルも付録に掲載されているので参考になる。

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

紹介文 :
ソフトウェア開発において、有識者によるレビューは非常に重要である。しかし、ドメイン知識の豊富な有識者の数は限られており、有識者にかかる負担は大きい。有識者の負担を減らす為には、レビューアへの教育が必要である。我々はレビューアが早期にドメイン知識を習得し、より質の高いレビューができるようにするトレーニング手法について研究してきた。
我々は2014年度SQiP研究会にて仕様書に意図的にエラーを埋め込み、それをレビューする手法（EIDeR-Training 法：Error Injected Document Review -Training 法）を提案した。ドメインに特化した欠陥を仕様書に埋め込み、教材とすることで、失敗の疑似体験を可能とした方法である。EIDeR-Training 法の教材の作成は20分程度で可能であり有識者への負担は比較的少ない。実験から一定の効果は見られたものの効果にばらつきがあった。
本報告では効果にばらつきがみられる原因について考察し、EIDeR-Training法の改良を行った。実験の結果、シナリオレビューの手法を取り入れレビューアのレベルに合わせた教材を使ったEIDeR-Training法により、若手レビューアの不具合検出率は３３％～３００％向上した。
本報告では、提案手法とその実験の結果、考察について述べる。

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

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

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

紹介文 :
研究会の研究員へのアンケート実施を通して、研究活動に対するニーズと満足度を把握する取り組みになっています。「満足度」をどのように評価すればよいか、考え方と手順が参考になります。

紹介文 :
レビューで重大な指摘をしても、修正されなければ意味がない。
本論文では、レビュー指摘を作成者に抵抗感なく伝えるための手法を提案している。
プロジェクトや作成者の状況などを配慮せず指摘を伝えてしまうと、作成者は抵抗感を抱き、指摘を素直に聞こうとはしない。
特に第三者レビューを実施している人は、悩まれているところだと思うので、一読頂きたい内容となっている。

紹介文 :
HTMLで作成されたモック（サンプル）画面を使って、コメントを追加する方式で、画面仕様書、テスト仕様書を生成する自動ツール開発とその効果が報告されている。ツールによる仕様書生成手順は次のとおり。
①モックにある種のタグと定められた構文に従って記述されたコメント追記することにより画面仕様書のHTMLファイルを生成する。②ツールの画面仕様書生成機能にこのHTMLを入力して、画面仕様書のCSVファイルを生成する。③CSVファイルをツールのテスト仕様書生成機能にインプットしてテスト仕様書のXLSファイルを生成する。

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

紹介文 :
　システムをリリースした後にくるクレームの「言葉」をどのように改修要件に落とし込むかについての研究です。「ぼやき」のような曖昧な言葉を、システム的にどのように解釈すれば良いのかを考察しています。一人でもチームでも運用できるチェックシート形式の問診票で改修の必要度を探ります。ユーザから直接フィードバックを得られる立場の方に、特にお勧めします。