紹介文 :
約２年前、我々の本部において品質悪化が原因で複数の大型プロジェクトの採算が不芳化し利益確保や人材育成に悪影響があった。不芳化の直接原因は①見積ミス、②設計考慮漏れ、③単体品質不良に大別されたが真因は見積、計画レビューの未実施･不備、問題の検出遅れである事が判明した。そこで不芳案件の撲滅を目的とした本部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(プロセスフローダイアグラム)を利用して、必要なタスクと成果物を整理する試みを行いました。
試みを実施してみて得られた効果と今後に向けての課題を、社内外で実施したワークショップの結果と合わせて発表いたします。

紹介文 :
本論文は、効率よく欠陥を検出できる上級テストエンジニアのテストスキルを、経験の浅い初級テストエンジニアに移転するためのテスト実施トレーニング手法を研究したものです。
具体的には、過去の欠陥情報から上級テストエンジニアのノウハウを抽出し、それをSOHT表にまとめてトレーニングすることで初級テストエンジニアのスキルを向上します。

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

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