紹介文 :
約２年前、我々の本部において品質悪化が原因で複数の大型プロジェクトの採算が不芳化し利益確保や人材育成に悪影響があった。不芳化の直接原因は①見積ミス、②設計考慮漏れ、③単体品質不良に大別されたが真因は見積、計画レビューの未実施･不備、問題の検出遅れである事が判明した。そこで不芳案件の撲滅を目的とした本部PMOを発足させ、本部PMOが開発プロジェクトの設計、テストの各工程において定量的な進捗/品質の把握を行い、問題の早期検知、エスカレーションおよび問題の早期解決を図るべくプロジェクトレビュー、プロジェクトモニタリングを部門横断で実施した。
プロジェクトレビューではリスクとその回避策、役割分担の明確さ、当社の存在意義・価値の確認を必ず経営層を含めてチェックする、プロジェクトモニタリングでは推測や勘で指摘を行わず、定量データを元に進捗/品質の問題点をあぶりだし、是正が必要な場合はPM自ら早く行動を起こせる様に指摘を行う等の工夫を施した。
これらの取組みにより組織の意思を提案やプロジェクト計画に反映しプロジェクト実行時には進捗/品質共に工程の異常値検知とその分析を行い、プロジェクト実行に問題がないかヒアリングする事でPMに気づきを与えた。この結果、実施から2年目の昨年度は不芳化案件がゼロとなり本部の生産性が向上した。
本報告はソフトウェア開発プロジェクトにおける進捗/品質の定量把握効果を紹介する。

紹介文 :
本発表では，2015年度より実施した弊社の品質保証部門における妥当性確認の改善実績について紹介する。
弊社では開発部門と独立した組織として品質保証部があり，開発プロセスとして，開発部門の検証完了後，品質保証部による妥当性確認を実施している。しかし，検証や妥当性確認のテストを実施して出荷したにもかかわらず，市場への不具合の流出が発生していた。
市場へ流出した不具合について開発工程の作り込み・妥当性確認工程の流出の両面から原因を分析した結果，開発工程の作り込み品質を改善することに加え，妥当性確認工程の改善が必要と判断し，特に妥当性確認工程を「設計の妥当性確認」から「製品の妥当性確認」に改め，テストの網羅性を高める変革を行った。
具体的には，検証工程では，従来どおり仕様書ベースの機能を中心としたブラックボックステストを実施し，妥当性確認工程では，製品のライフサイクルに沿った顧客の運用条件を抽出して，装置操作手順や外部事象のイベントや互換性などユーザ観点のテストシナリオをベースとしたシナリオテストへ変更した。
このテスト技法変更による2015年度の活動の結果，不具合流出防止に一定の効果を得られたので，実プロジェクトへ適用した際の実施内容および工夫について報告する。

紹介文 :
ソフトウェア開発においてその品質（出来栄え）を計る手法としてテストの密度や発見したバグの密度を用いて、過去の実績の標準偏差を用いて上下限範囲内に収まっているかどうかを目安にする定量的品質評価を実施することも多い。この手法は多くの品質データからアラームを効率的に発見する上では一定の効果を発揮している。しかしながら、テストなどの密度が充分であっても，テスト対象が一部に偏っていたり、既存類似機能を流用しているのでテスト密度は低くても問題ないといった説明を過信したりすること等によりテスト不足を開発中に発見できず、終盤のユーザー目線のテストでバグが大量に発見され、リリースまでの限られた時間で大量の追加テストを余儀なくされるケースも少なくない。
大規模で高信頼性が求められるあるＩＴの開発保守部署は、ある大規模機能追加の終盤に前工程をすり抜けたバグが多数発見される事態に陥り、テストの充分性（網羅性）を設計情報から再検証し、テスト不足を洗い出して追加テストを実施してリリースに漕ぎ着けた。この経験から、テストやバグの密度は品質評価のひとつの目安に過ぎないことを教訓とし、テスト計画時のテスト充分性検証を入念に行うよう改善した。その後の開発案件においては、同様の事態は発生していない。

紹介文 :
従来より、開発規模、工数、レビューやテストで検出された欠陥数などのメトリクスをタイムリーに収集することで、プロジェクトを可視化することは一般的に行われている。しかし、可視化された報告からプロジェクトの失敗の兆候を予見するには、組織やプロジェクトに適した基準値や判断方法が必要となる。また、これらのメトリクスを複合して、１つの見解を導くのも困難であった。
本研究では、ベイズ統計を応用し、複数のメトリクスを逐次的に取り入れることで、プロジェクトの失敗リスクを算出するモデルの構築事例について述べる。構築したモデルからは、プロジェクト失敗の兆候を未然に予見し、是正アクションに結びつける効果が期待できる。
本発表では、モデル構築に際し盛り込んだ独自の工夫点や、メトリクスを活用した新たなアプローチについて報告する。

紹介文 :
ソフトウェアの品質を高めるためには、不具合の再発防止と未然防止が重要である。その手段として、ＦＭＥＡやＦＴＡ、ＨＡＺＯＰなどのリスク分析手法が知られているが、ソフトウェア開発では効果的に実施できず、普及しているとは言えない。
その理由は、ソフトウェアでリスク分析を行う際に、不具合（ＦＭＥＡでは故障モードと呼ばれる）の発想が難しいからである。よって、リスク分析を効果的に行うためには、発想を促すキーワード（観点）が重要と考えた。観点の例としては、ＨＡＺＯＰにおけるガイドワードがあるが、パラメータに着目した汎用的なものとなっている。ＦＭＥＡなど他のリスク分析手法にいたっては、ソフトウェア開発に有効な観点は知られていない。
そこで東芝では、組込みソフトウェア開発一般向けの「観点リスト」を用意し、それを発想の際に用いることでソフトウェアにおけるＦＭＥＡの実施効果が高まることを確認してきた。
しかし、組込みソフトウェア開発一般向けの観点リストでは、製品の特性に応じた不具合の発想が難しい。そこで、より効率的・効果的にリスク分析を行うことを目的に、製品分野に特化した観点リストを用意する方法（手順）を開発した。
本論文では、製品分野に特化した観点リストを開発するための方法（手順）を述べる。そして、実製品開発でのエンジニアによるアンケートと、実際に計測した不具合の発現密度から、その実施効果を述べる。

紹介文 :
派生開発では、同じソースコードを何度も変更することにより、ソースコードが劣化していく。劣化が進行すると、手戻りやデグレードなどの温床となり、開発の遅れが引き起こされる。このような問題への対策の一つにリファクタリングが挙げられる。
開発者を対象にリファクタリングについてのアンケート調査をおこなった結果、リファクタリングを実施するためのプロセスが存在しないことが多く、実施の判断やプロセスの内容が担当者任せになっていることがわかった。また担当者任せのリファクタリングによって、担当者のスキル不足や機能変更ついでのリファクタリングなどに起因する不具合が発生していることもわかった。このような担当者任せのリファクタリングを防止するため、派生開発のプロセスとして知られるXDDP（eXtreme Derivative Development Process）をリファクタリングに用い、リファクタリング専用の変更プロセスR-XDDP（Refactoring-XDDP）を考案した。
R-XDDPでは「構造の変更」のみをおこない、機能の追加変更、削除といった「機能の変更」はおこなわない。リファクタリング対象の構造の特徴を抽出したリファクタリングパターンを要求として扱い、構造のBefore/Afterを表現した変更3点セットを作成し、レビューを実施する。変更3点セットには具体的な変更内容や担当者のスキルが表現されるため、レビューによってリファクタリングの保留や担当者変更などの判断が可能になり、担当者任せのリファクタリングを防ぐ効果が期待できる。

紹介文 :
ソフトウェアを含む設計・開発の多くの現場は、一つの開発だけではなく、複数の開発を抱えていたり、突発な不具合に対応したり、会議などのさまざまな業務を切替えながら仕事をする「マルチタスク」となっている。このマルチタスクは、タスク切替えにオーバーヘッドがあるため、シングルタスクで順番に実行するよりも時間がかかる。よって、遅延の要因となり、コスト増大にもつながる。また、一般に人間の思考はシングルタスクであるため、マルチタスクでは生産性が40%低下するとも、IQが15ポイント低下するともいわれる。さらに、タスク切替えで集中力が削がれるため、ケアレスミスなどで作業品質が低下し、工数圧迫のプレッシャーなどが加わり、成果物や製品の品質を低下させる。また、過度なマルチタスクは精神疾患を生み出すともいわれている。
本報告では、このマルチタスクの低減に注目した改善手法として、タスクボードを用いたTOC (Theory of Constraints)に基づく標準的業務改善プログラムを提案する。本手法では、開発チーム内の推進者がTOCの有識者の支援のもと、標準化されたフォーマットに則り、自チームの改善を検討する。結果、チーム内で助言を得やすくなったなどの定性的効果だけではなく、残業時間30%減や納期遵守率27%増などの効果も得ており、現在まで日立グループにて1,000人が関わる規模に拡大している。

紹介文 :
ソフトウェアのリリース時は、品質保証部門により出荷判定の審査を行い、ユーザーが使用する上で支障が無いことが承認された上で実施されることが多い。リリース後の不具合件数を予め予測出来れば、リリース判定時に有力な指標となる。また、予測のために重回帰モデルを構築し、説明変数として開発工程における各メトリクスからレビュー、テストの十分性評価の要素を含めることで、開発工程の改善につなげる事が出来る。リリース後の不具合件数はゼロを多く含む右に歪んだ分布になる傾向がある。
右に歪んだ分布に重回帰モデルを適用する場合は不具合件数のモデルとして知られるポワソン分布を仮定して、一般化線形モデルを適用する方法である。だが、リリース後の不具合件数の分布はポワソン分布の想定よりもゼロの件数が多すぎるため適さない。
ゼロが多く含まれる理由として、異常検知時の処理や使用頻度が低いなどで通常操作ではあまり動作しない機能があり、実際には不具合があっても報告されないため過大にゼロが報告されていると考えられる。ゼロが分布から期待される以上に多く含まれる結果、ポアソン分布の性質である"平均 = 分散"にならないため精度の高いモデルを構築することが難しかった。
本研究では、ソフトウェアリリース後の不具合件数はポアソン回帰モデルに従う不具合が無い完全状態(ゼロ状態)と不完全状態(不具合が潜在的に存在する)の2つの状態があると仮定して、どちらの状態を取るかをロジスティック回帰モデルに従うとするゼロ過剰ポアソン回帰モデルを用いて重回帰モデルを構築した。
実際の開発工程で使用したメトリクスを適用して実験を行った結果、ゼロを多く含む右に歪んだ分布に対してはゼロ過剰ポアソン回帰モデルを適用することで高精度の予測モデルが構築出来ることを確認出来た。

紹介文 :
これまでのソフトウェア製品の使い勝手評価では、過去の経験に基づくチェックリストを標準化し実践してきたが、以下の問題があった。お客様にとって使いやすい製品とならず、お客様満足度の低下につながっていた。
・お客様製品利用の実態が日々変動する中で、新たな製品特性に対する使い勝手の観点をカバーしきれず、製品利用現場の実態を捉えた評価が困難になり、使いにくさの問題を見逃す
・検出した使いにくさの問題を、製品設計者・開発者に対して納得性の高い定量的な裏付けをもって示せない。　結果、問題改善の重要度を設計・開発者に適切に伝えられず、対処が見送られる
本報告では、前述の問題を解決することを目的として、ユーザビリティ評価手法であるNEM法（Novice Expert ratio Method）を応用・拡張した「インタラクションデザイン評価手法」を開発し、実践した結果を報告する。また、「インタラクションデザイン評価手法」が昨今のトレンドである仮想化技術やクラウド、マウスやキーボードを用いないスマートデバイス等、新たな製品利用実態においても有効であることの可能性、および今後の研究の方向性についても報告したい。

紹介文 :
本発表では、TPI NEXTよるテストプロセス成熟度評価の導入における取組み、および導入時の問題解決のために作成したガイドについて報告する。
我々の所属する品質保証(QA)部門における業務は、QA部門の基準で定められたテストプロセスに従い、様々な問題点に対しそのプロセスを適宜変更・改善しながら進めている。その変更・改善において、テストプロセス改善のためのモデルの導入は行わず、各QAチームの裁量により進めてきた。しかしながら、そのような進め方において自チームのテストプロセスの改善の度合いを客観的・多面的に把握できておらず、系統だって改善を推進できていないことが課題であると考えた。
そこで本取組みでは、テストプロセス改善モデルとしてTPI NEXTを採用し、モデルに基づくテストプロセス改善の導入を始めた。まず、TPI NEXTによるテストプロセス成熟度の評価を導入するにあたり、QA部門での適用性を確認した。次に、いくつかのQAチームを対象に成熟度評価を試行し、導入に関するいくつかの問題点を明らかにした。そして、これらの問題点を解決するために、TPI NEXTによるテストプロセス成熟度評価を支援するためのガイドを作成し、そのガイドの有効性を検証した。

紹介文 :
近年, ソフトウェア開発のスピード向上とコスト削減の有力な方法の一つとして,オープンソース・ソフトウェア(OSS)の利用が注目を集めている.しかしながら, OSSを利用した製品やサービスを開発しても,結果的に, QCD(コスト(Cost)や品質(Quality),開発スピード(Delivery))の向上につながらない事例も少なくない. 本投稿は, 「OSSを活用したエンタープライズソフトウェア開発における課題調査」を実施, その内容を踏まえ, OSSを効果的に利活用するためのメトリクスを抽出、OSS の利活用を組織的に取り組むことの重要性を示すものである. 本研究では, OSS利活用においては, OSSの「目利き力」,「設計力」,「品質保証力」が重要であること示し, 国内におけるエンタープライズ向けの高い信頼性が要求されるソフトウェア開発を担う組織を対象にアンケートを実施, GQM (Goal Question Metrics) 手法を用いて, OSS利活用のためのメトリクスを抽出, ソフトウェア開発の品質やスピードを向上させることを狙う. 本調査により, 例えば, 新しいOSS へチャンレンジしているチームは, 積極的にコミュニティに参加, OSS専任者をおいてより成熟度の低い（新しい） OSS 活用にチャレンジすることで開発のスピードをあげようとしている傾向があることが判った. 本論文では, アンケート結果からOSS利活用するためのメトリクス（OSSの「目利き力」,「設計力」,「品質保証力」）を抽出, 適用状況, 及び, 考察を述べる.

紹介文 :
みなさんこんな経験をしたことはないでしょうか。
・テスト開始直前になって、必要なテストデータや実行環境の手配ができていなかった
・後工程で利用されることを意識していない、利用するには不十分な情報のドキュメントばかりだった
このような状況が発生すると多くの場合、手戻り作業が発生してしまいスケジュールの遅延や、成果物の品質の低下を招く原因となってしまいます。どのようにすれば、この状況を予防することができるのでしょうか。
今回、必要な作業、成果物の抜け漏れや、利用目的が不明確な成果物を防ぐ方法の１つとして、テスト計画時に清水吉男氏が考案されたPFD(プロセスフローダイアグラム)を利用して、必要なタスクと成果物を整理する試みを行いました。
試みを実施してみて得られた効果と今後に向けての課題を、社内外で実施したワークショップの結果と合わせて発表いたします。

紹介文 :
日本の情報システム開発プロジェクトは約70%が失敗であると言われており、成功率の向上が求められている。成功率向上のために、プロジェクトの主体的な活動のみならず、プロジェクトが所属する組織の支援によってプロジェクトのみでは十分に対応できないリスクの影響を軽減する必要がある。本研究は、情報システム開発プロジェクトのリスクの評価を通して最終的な成否の予測を行うことで、組織が優先して支援すべきプロジェクトの特定に寄与すことを目的とする。
先行研究において、特定のITベンダのプロジェクトからデータを収集し、ロジスティック回帰分析を適用して成否の予測モデルを構築したところ、73.9%のプロジェクトの成否を予測できるモデルが得られた。本研究では、属性毎に分類したデータを活用することで、予測能力のさらなる向上を目指した。属性毎に分類したデータにベイズ識別器を適用して成否の予測モデルを構築したところ、業務パッケージを利用しないプロジェクトのデータでは、予測能力85.4%と良好なモデルが得られた。これらの結果を活用することで、本研究の目的である、組織が優先して支援すべきプロジェクトの特定に寄与できると考える。

紹介文 :
当社のソフトウェアパッケージ製品の開発プロジェクトでは、最終成果物であるソフトウェアの品質要求を品質特性にて定義し、開発部門とともにその品質要求を満たすことを目標に製品開発を行っている。品質保証部門では定義された品質特性毎の品質が確保されているかを確認するため、各テストタイプを品質特性毎に分類し、それらテストタイプの実施により各品質特性の品質が確保されているか確認している。これらの検証計画は詳細にマスタープランに記載されるとともに、各テストレベルでは受入テストによる品質ゲートを設けている。このような開発プロセスと非同期の品質評価プロセスを2011年より導入している。
昨年９月の一般社団法人コンピュータソフトウェア協会のPSQ認証の取得を機に、SQuaREやISO/IEC/IEEE 29119のテストプロセスなどの最新規格への対応、利用時の品質、利用者文書であるマニュアルの品質要求への品質特性の導入、第三者への品質情報の提供を踏まえた検証結果報告書の作成等の検討を行い、JIS X 25051:2016に対応した新たな品質保証プロセスを構築した。
本論文では、当社が構築した最新の品質保証プロセスの概要や導入教育の方針を解説するとともに、導入プロジェクトでの適用例を踏まえた本プロセスの効果および今後の課題を述べる。

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

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

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

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

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

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

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

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