紹介文 :
増加する派生開発の案件に対応するために、既存の協力会社では間に合わず、新たに外部の協力会社を頼む必要が生じることがある。しかしながら新たに参加する協力会社の技術者には、今回の開発製品やシステムに対するベースの知識が不足していたり、ソースコードの設計の隠れた情報を「読み取るスキル」が不足していたりするため、変更への対応ミスが生じやすい。短い開発期間の中で、このギャップをどのように埋めるかという問題は、多くの現場に共通する問題と思われる。
従来から変更に関連する情報を提供していたが、渡した資料の範囲が広すぎたりしてうまく活用されなかった。その解決方法として、機能と資料とのマトリクスの中で関係情報の所在を示すと同時に、関連する情報を小さな短冊（Chips）にして、目的の箇所に辿りやすくなるように工夫した。マトリクスのマスター情報に対して、今回の変更に関係する箇所がわかるように更新して渡すことで、時間の無駄も省いた。

紹介文 :
我々の組織では、給湯器等の製品を設計・性能評価を実施する製品開発部門と、仕様化から結合テストまでを実施する制御ソフトウェア開発部門があり、「製品発売」を判定するためのシステムテストを実施するのは、前者の製品開発部門である。
製品として品質を確保した上で、発売するためには、システムテストが重要になるが、各々の部門が専業化しているため、どうしてもシステムテストとしての取り組みが弱くなっていた。（システムテストを専門的に考える部門がおらず、効果的なシステムテストに取り組めていなかった。）
そのため、従来は、網羅的にテストケースを設定し、それぞれの重要度は決めているものの、効果的なシステムテストの進め方になっておらず、外部流出につながるケースがあった。
今後、我々の製品にも高機能化の要求が強まる中で、従来どおりのやり方では品質を確保できなくなる可能性も否定できない。そこで、効果的に品質を確保するために、システムテストの部分にもっと注力していく必要が出てきた。
本発表では、システムテストを起点として、派生開発における問題の兆候を掴むための基準作り等、定量的なソフトウェアの品質マネジメント実現のために、工夫した内容とその結果について述べる。

紹介文 :
社外活動（ここでは、業務以外の社外の勉強会やシンポジウム、学習を指しています）をおこなうときに、以下のような困ることはありませんか？
・社外活動をうまく現場に展開できない
・同僚に、社外の勉強会やシンポジウムに参加してもらえない
・社外活動に参加したいと思っているが、時間や場所、お金、家庭の事情で参加できない
・参加したい社外活動がない
・地方の事業所の同僚にも積極的に社外活動に参加して欲しいが、地方開催されておらず機会に恵まれない
地方都市で社外活動に参加するには、求めている活動が限られていました。そこで場所を問わず、すでに開催されている社外活動に参加しました。自らも社外の勉強会やシンポジウムを運営し、発表するようになりました。社外活動に参加するうちに、テストや品質に関する社外活動に率先して参加する開発部門の技術者が増えないことが課題となりました。本発表では、各活動の工夫点やフィードバックが現場で適用した事例、社外活動に参加する前後の変化について発表します。

紹介文 :
ソフトウェア開発ではビジネス要求に迅速かつ柔軟に対応するために、アジャイル開発の適用が増加している。アジャイル開発では動作する成果物を素早く届けることを重視しており、そのための様々なプラクティスが存在する。これらのプラクティスの適用時には、プロジェクトの条件に合わせて適用方法を工夫することで、より高い効果を得ることができる。

ペアワークはアジャイル開発のプラクティスの1つであり、2人で会話をしながら調査や設計、製造、テストを実施する。ペアワークを適用することで開発者が個別に作業するよりも作業中の見落としが少なくなるとともに、情報共有や信頼関係の構築にも効果があり、結果として成果物の品質向上につながることが知られている。これらの効果を得るために、ＮＥＣではアジャイル開発プロジェクトにおいてペアワークの適用を強く推奨している。

本発表では、ペアワークを適用して効果的に成果を上げるために、スプリント終了時のふりかえりを通してペアワークの適用ルールを最適化した事例を紹介する。さらに、最適化により得られた適用ルールの他プロジェクトへの適用可能性についても述べる。

紹介文 :
ソフトウェア開発において発生する欠陥の情報が、プロジェクト内で欠陥管理票として蓄積されている。しかし、蓄積された欠陥情報は、果たして有効に活用されていると言えるだろうか。多くの場合、欠陥が発生した当該プロジェクトの中で欠陥修正のために使用されて終わりとなり、同じ社内であっても、背景の異なる別のプロジェクトの品質向上にまで活用される機会は非常に少ないのではないだろうか。
では、欠陥情報を背景の異なる別のプロジェクトで活用するにはどうしたらよいか。
過去の研究において、欠陥発生のメカニズムを図式化・伝達するための「欠陥モデル」が提案されている。しかし、このモデルによって欠陥情報が実際に移転できるか、その効果まで踏み込んだ研究は行われていなかった。また、昨年度の当シンポジウムでは、プロジェクトと欠陥の属性情報である「欠陥特性」が発表されている。本研究では、この「欠陥モデル」と「欠陥特性」を組み合わせた新しいアプローチで欠陥を移転する方法を考案した。この欠陥移転法を使い、複数企業のプロジェクトに欠陥情報を移転し、品質向上に活用できるかを“リスク候補抽出”作業を用いて検証した。その結果、「欠陥モデル」だけを使ったケースよりも品質向上に効果があることが確認できた。
本発表では、この欠陥移転法の概要とその新規性、及び検証過程と分析・考察結果について具体的に解説する。

紹介文 :
JAXAでは、開発プロジェクトとは異なる第三者の技術者でソフトウェアの評価を行う独立検証及び妥当性確認の活動（以下、IV&V活動という）を行っている。IV&V活動は、開発プロジェクトが作成した設計書やソースコード等のソフトウェア開発成果物に対し、将来不具合となるようなリスクの有無を開発作業と並行して評価していく活動である。そのため、IV&V活動に従事する技術者は、ドメイン知識、ソフトウェア設計や検証技術の知識に加えて、ソフトウェアの不具合要因となるようなリスクを抽出する能力が求められている。
リスクを抽出する能力は、一定の業務経験に加えて技術者の思考特性による得手不得手が大きく影響するため、リスクを抽出する能力の度合いを計測することで、よりIV&V活動に向いた技術者を配置できる。
従来、技術者の能力を短時間で計測する方法は、「概念や手法をどの程度知っているか」等の選択式又は論述式による筆記試験で計測していたが、「リスクを分析する能力」のように人の思考過程に依存する能力は計測することが困難であった。一方、提案する本手法では、技術者の思考過程をGSN（Goal Structuring Notation）形式で可視化することで、技術者の思考過程に依存する能力を数値化し能力の度合いを計測できるか試みた結果を報告する。

紹介文 :
　我々はカーナビゲーションにおける携帯電話と連携するテレマ機能を開発している。テレマ機能は、スマートフォンを用いたサービスの拡充に伴い、規模の増加と複雑化が進む一方、開発期間は年々短くなっている。現実の開発においては、機能の設計、実装が遅れるとテスト期間が圧迫されるため、テスターを増員することでテスト期間の短縮を図っている。
　しかし、テスターの増員により、計画時以上のテスト項目が実施されるようになると、テスト方法やテストサイトの制約など様々な問題によりテストの生産性が低下する。特に増員したテスターにテスト未経験の割合が大きい場合には、テストの進捗を妨げる問題の特定と解消をテストマネージャに依頼することができないためテストの遅れはより顕著になる。
　我々はこの問題を解決するテスト管理プロセスを設計した。このプロセスでは、テスト未経験でも記入できるテスト実施を妨げる要因を分類した「阻害要因ラベル」を定義し、それを付与したテスト結果をテスターから定期的に収集する。さらに、阻害要因ラベル付きテスト結果を蓄積して分析することで、多数のテスト実施を妨げる要因を推測し特定することにより優先的に解消する。
　本発表では、設計したテスト管理プロセスについて説明し、この管理プロセスを実際のプロジェクトに適用した結果を報告する。適用したプロジェクトではテスト生産性を大幅に改善し、計画通りにテストを完了した。

紹介文 :
一般にソフトウェア開発において欠陥の検出を上流化することは、下流であるテスト工程での品質を向上して手戻りを減らし、更には市場への流出低減にも効果があることが知られている。しかしその関係が定量的に示されることは稀であるため、具体的な目標設定に結びつかず、継続的な品質改善活動に繋がりにくい。実際、上流メトリクスを収集するのみで活用されていないケースや、メトリクスの収集自体していないケースはよく耳にするところである。
本研究ではレビューおよびテスト工程で検出される欠陥の数に対して、工程間で比をとった前倒し率という指標を用いて、上流のレビュー活動が下流のテスト工程に与える効果をモデル化し、定量評価できるようにする。次にこれを近似変換することで、上流工程終了時に下流工程での欠陥検出数を予測可能なモデルへと発展させる。
本発表では実際のプロジェクトデータを用いた検討の過程を段階的に示し、得られたモデル式とその精度の検証結果について報告する。

紹介文 :
当社の品質保証部門ではJIS X 0129やJIS X 25051規格を参考にした品質評価プロセスが存在する。しかし、利用時の品質要求に対する方針は社内では規定されておらず、各プロジェクトに委ねられていた。当社ではPSQ認証取得を機に利用時の品質への取り組みを開始し、開発プロジェクト期間中に利用時の品質を測定する方法を検討した。
当社では各製品でペルソナを定義し、マニュアル毎の利用者を定義している。そこで、このマニュアル毎の利用者を活用し、過去にマニュアルを仕様書としてソフトウェアを動かしマニュアルの習得性および理解性の評価を行った実績がある。この実績をもとに品質保証部門でのペルソナを参考に利用者の分類を行い、この分類とマニュアルを仕様書として移用することで、開発プロジェクト期間での利用時の品質を評価するマニュアルベーステスト技法を構築した。JIS X 25051を参考に構築された品質保証プロセスを適用した複数の開発プロジェクトにマニュアルベーステスト技法を適用し、利用時の品質の評価を行った。
今回、このマニュアルベーステスト技法のプロセスの解説とともに、マニュアルベーステスト技法の評価結果および分析結果、今回の適用結果から得られた開発プロジェクト期間中での利用時の品質の評価可能な条件および今後の課題について報告を行う。

紹介文 :
派生開発の現場では、機能の追加・変更による振る舞いの変化が、思いもよらないユーザビリティの劣化を招くことがある。そのうえ、ユーザビリティに及ぼす影響への配慮不足により発生する不具合の多くが、開発の終盤やリリース後に発見され、納期遅延やコスト増大といった問題を引き起こしている。さらに、このような不具合は要求仕様書や変更設計書などドキュメントが揃っている現場でも発生する可能性がある。
そこで我々は、機能の追加・変更によって生じた振る舞いの変化を差分として明らかにし、振る舞いの差分からユーザビリティの劣化に気づくことで、設計段階でユーザビリティに関する不具合を防ぐ以下の三つの解決策を考案した。
・「派生開発で劣化し易いユーザビリティの観点」
・「振る舞いBefore/Afterシート」
・「ユーザビリティの劣化を防止するプロセス」
これらの解決策の効果を検証するため、過去の不具合事例や現在進行中のプロジェクトに適用したところ、機能の追加・変更による振る舞いの差分を設計担当者に意識させることができた。また、設計担当者が振る舞いの差分から、その変化がユーザビリティへ影響し劣化していないかを「派生開発で劣化し易いユーザビリティの観点」を用いて熟慮することで、ユーザビリティの劣化への気づきを得られることがわかった。
本報告では、これらの解決策を用いた派生開発でのユーザビリティの劣化を防ぐ方法について詳細を述べる。

紹介文 :
当社のパソコン製品には、自社製アプリケーションだけでなく、約50本のISV（独立系ソフトウェアベンダー）製アプリケーションをプリインストールしている。ISVによるQAをパスしてから納品されたアプリケーションは、当社の受入部門による受入テスト、SI部門によるシステムテストを経て、QA部門による出荷監査を受け、重大な不具合がないことが保証され、出荷される。
筆者が所属する受入部門の任務は、受入テストの段階ですべての不具合を検出し、出荷監査では不具合が検出されないようにすることにある。しかし、実際には出荷監査で不具合が検出され、ISVへの緊急修正依頼、マニュアルへの注記、修正モジュールのWeb公開など、予定外の不具合対応に追われることが多い。受入テストでいかにして効率的に多くの不具合を検出できるかが課題である。
この課題に対し、“Exploratory Software Testing”という文献で提唱されている探索的テストを導入することで、受入テストにおける不具合検出効率向上を図った。同文献を参照しながら洗い出したテスト観点に基づく探索的テストを、従来のブラックボックステストと組み合わせることにより、テスト工数あたりの不具合検出数を向上させることができた。
本論文では、探索的テストを導入するにあたって実施した、探索的テストプロセスの定義、テストチームの編成、テスト観点の洗い出し、テスト工数の確保方法、および、実際の製品に適用した効果について報告する。

紹介文 :
ソフトウェア開発の現場では、「障害票」の情報を共有して不具合の再発予防対策を立案する際に、対策が効かず同種の欠陥が混入されて、不具合を再発させてしまうことがある。
多くの欠陥は、混入要因として「個人に依存した要因」と「集団に起因した要因」に分類を行うことができる。しかしながら、不具合発生の瞬間を記載した「障害票」情報を基に分析を行うため、「障害票」に記載されない背景に潜む「集団に起因した要因」を把握することができず、「個人に依存した要因」に着目した再発予防対策を立案するため、対策として不十分であり、同種の不具合を再発させていると、我々は考えた。
本研究では、欠陥混入の背景となる「プロジェクトの体制や環境である周囲の状況」を「環境要因」と定義し、欠陥情報に「環境要因」の情報を付加して蓄積、情報共有することを提案して、その有効性を確認した。
この取り組みにより、欠陥が混入するメカニズムを理解することを促し、視点を拡げた有効な再発予防対策を立案できることが期待できる。組織として「欠陥情報」を価値あるものとするために必要なアプローチを提唱する。

紹介文 :
派生開発時のテストでは、変更の影響範囲を考慮しテスト観点の抜け漏れを抑えるテスト要求分析が重要です。
本論文ではHAYST法の「ラルフチャート」を派生開発の前後で作成し両者を比較することで「変更の影響範囲を考慮したテスト観点を導出する」というテスト分析手法を研究したものです。

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

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

紹介文 :
モチベーションやモラールを扱った著書や研究は多い。この問題は、古くは、ホーソンの実験から始まると考える人も多いだろうが、人類の誕生以来ずっとあるのでは無いだろうか。
　本論文を書き終わった時、研究員の全員が異口同音に「自分はプロジェクトリーダだと思っていたが、この１年研究していかに未熟かを実感した」と言っている。本論文には、現代のプロジェクリーダが見えていない世界が描かれている。
本論文は、そのエッセンスが書かれているので、1年かけた研究者と同じ実感はもてないかもしれないが、プロジェクト管理の世界の広さをかいま見ることが出来るだろう。

紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。
設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。