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

紹介文 :
トップレビューアの頭の中がのぞけたら・・・本論文の研修者たちは挑戦した。トップレビューアの思考プロセス、それがHDR法だ。もしこの方法で優秀なレビューアが育つなら試してみない手はない。悩みを抱えるPMや品質管理部門の方はぜひご一読をお勧めする。

紹介文 :
通常、XDDPの変更プロセスでは「3点セット」を必須としている。これは派生開発で混乱している組織にあっては、この3点セットの成果物を作りながら作業を進めることで秩序を確保するのが狙い。しかしながら、ビジネス系においては「SLCP」などでそれなりの成果物が作られプロセスの秩序も維持されていることがある。また、短納期の要求などもあって、「3点セット」を作成することに抵抗がある。そのような中で、変更を含む要求仕様に関するトラブルに的を絞って取り組むことにしたケース。得意なケースなので、なぜこの「部分適用」の方法が可能なのか、本報告書から読み取って欲しい。

紹介文 :
本研究は継続的にレビューする手法ContinuousReviwについて記すものである。レビュー品質の向上を目指すうえで、「短時間、レビューアのばらつき」の問題は大きい。CR法はプロセスを持つレビュー法であるが、参加者自身がレビューの目的とルールを定め、振り返りを行い、新たなレビュー観点やルールの変更を検討する。特にレビュー期間が限られているプロジェクトの品質担当者にご一読いただきたい。

紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。

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

紹介文 :
曖昧な表現によってソフトウェアに欠陥が作り込まれており、これらをレビューで見付けるにも限界がある。そこで社外の過去の研究成果をベースに曖昧な表現を機械的に検索できるチェックツールを開発し、レビュープロセスに組込んだ活動発表です。 レビュー前の仕様書に適用し、問題点が抽出出来ており、効果もあることが確認されています。

紹介文 :
現場での課題の分析結果から、レビュープロセスを改善しています。具体的な手順や帳票も提案されており、すぐに現場で活用することが可能です。また、レビューの真の目的は「ソフトウェア品質に対する不安を除去すること」との認識から、不安ヒアリングシートという帳票が開発されており、ユニークな発想で興味深いです。

紹介文 :
「開発の上流文書の質が良くないと下流のテストがタイヘンになる、だったらテストエンジニアが上流から関わってはどうか」というところから出発した報告です。テストエンジニアの視点は設計者や開発者とは異なることを利用し、テストで発見されるべきバグを要求仕様書の段階で見つける試みです。 設計・開発とテスト担当者が別のチームであるプロジェクトなどには、有効な考え方です。

紹介文 :
ドキュメントに敢えて記載されることがない暗黙的な情報（ステルス情報）を、レビューの場に引き出し活用することで、認識齟齬や漏れに起因する重大な欠陥を検出するレビュー手法『SBR法（ステルス・ベースドレビュー手法）』を考案している。 ステルス情報を、所有者（ユーザ、プロジェクト、作成者）と、種類（状況、知識、経験）で掛け合わせたマトリクスで整理したり、レビュー対象のプロジェクト特性によってパターン化したり、具体的な引き出し方法についても工夫されている。

紹介文 :
レビュー効率と効果向上に関する新技法の提案論文。欠陥検出率の向上と、コスト効果を改善する方法として、メトリクス測定＋仮説立案を利用に言及している。 品質系、特にレビュー技法に対するメトリクス利用の論文は一般に少ないこと、また当該論文にて言及している「間接メトリクス」に関してはプロセスメトリクス・プロダクトメトリクスのいずれでもない新たなメトリクス分野として注目に値する。

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

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

紹介文 :
エキスパートレビューアを育成するためのトレーニング手法として、特に伝え方や教育が難しいドメイン知識に着目し、経験の浅いプロジェクトメンバーに実務において失敗させずにドメイン知識を習得してもらう手法として、EIDeR-Training法（Error Injected Document Review - Training 法）を提案している。短時間での教材作成や、個人学習なのに疑似的失敗体験ができる仕掛けなど工夫がされている。

紹介文 :
研究対象を、プロジェクトの上流段階でのプロトタイプの作成 とペルソナ・シナリオに基づく検証(ウォークスルー)の二つに絞ったUCD(人間中心設計)手法の現場への適応研究。評価軸となるペルソナや、テストケースであるプロトタイプに求められる品質問題も垣間見えて興味深い。使い易さを設計/検証するには、どれだけの準備が必要なのかを疑似体験できる。尚、UCDは基本的にはUXD(ユーザ体験デザイン)と同義と思って頂いて差し支えない。

紹介文 :
皆さんはレビューをする際にビジネスリスクを考慮してレビューをされているだろうか。我々エンジニアは顧客視点と常々意識をしているがお客様が抱えるリスクとレビュー観点が常に一致しているとは限らない。この研究ではビジネスリスクのリスクツリーを作ることにより上流段階での重大欠陥を効率的に行う提案を行っている。

紹介文 :
開発済みのシステム(Webサイト)に対して、要件定義/開発/評価の三つのフェーズに置いて、どのようにUCD(人間中心設計)の手法が活用できたかを考察しています。UXD(ユーザ体験デザイン)という言葉が広まる前に広まった用語ではありますが、内容的にはほぼ同じです。ペルソナシナリオ手法やプロトタイピング手法をUMLと比較検討したりし、特に付録の実際の検討シートの内容は多くの読者がUCD/UXDを疑似体験できるものとなっています。

紹介文 :
上流工程でのレビューが品質に良い影響を与えることは知られているものの、効果的なレビューを行うことでは簡単ではありません。 本発表では、レビューの方式を工夫することで、所要時間を維持したまま、重大欠陥の検出や知識の移転の度合いを高める方法を示しています。他のレビュー技法との比較も、わかりやすく説明されています。

紹介文 :
ピアレビューを通じたOJTによるスキル向上に関する報告である。多くの組織で、仕事のやり方（プロセス）が決められていると思う。しかし、形式的にプロセスに従うことが目的になってしまい、プロセスの意図や目的等を考えずに実行されてしまうこともあると思う。本報告では、ピアレビューを通してプロセスの本質や目的を満たしたことを、自分で判断させることによりスキルアップに効果があったことが報告されている。OJTの実施者には参考になる内容だと考える。

紹介文 :
実在する交通費精算システムに対して、ストーリーボード、カードソーティング、ペーパープロトタイピングという代表的な3つのプロトタイピング手法を用いてUI改善を実践し、各種法の長所短所/適応場面などを考察しています。「手書き画面→写真→試作」が可能なタブレットPCを見れば多少古めかしさは否めませんが、ユーザ視点として押さえるべき原点的な事が書かれています。読む時代と、その時可能な技術とを鑑みて読むと学ぶべき事は多いと思います。