紹介文 :
新規ソフトウェア開発プロジェクトにおいて、仕様や設計段階での漏れ／誤りの多発、あるいはコーディングやテストでバグが収束しない等の品質問題を起こすことは、比較的よくあるケースである。
今回の経験事例における対象プロジェクトについても同様の品質問題を抱えたプロジェクトであり、フェーズ１開発完了時点で品質問題が顕在化した状態であり、フェーズ２開発以降において開発品質をどうやって改善／向上させるかが重要課題となっていた。
当プロジェクトの品質改善の為に自身がＰＭＯおよび品質管理の役割で参画し、品質悪化要因について分析した結果、当プロジェクトはオフショアを含む多拠点で編成されたプロジェクト、且つ新規メンバ中心で構成された体制であり、開発プロセスやコミュニケーションの観点などにおいて改善すべき点が多々あることが判明した。特に
　・開発プロセス理解／周知不足で成果物の品質が一定でない
　・仕様／設計における拠点間の認識齟齬の多発
　・仕様／設計／コーディングでのレビュー不足多発
　・テスト項目網羅不足
などの弱点が顕著であった事から、これらの観点に着目した改善施策を立案／実行した。
その結果、当プロジェクトのフェーズ２開発以降において、大幅な品質改善が見られたことから、当経験を事例として発表する。

紹介文 :
Agile開発におけるチームマネージメント方法についてScrumが知られているが、導入に際して効果的に定着出来ていないプロジェクトが散見される。特に導入段階で躓くプロジェクトの多くに幾つかの共通点がある。形骸化されたロール定義による誤った責任分担。Scrumの原則を順守しないイテレーション開発の実施。その結果、プロダクトの品質が確保できず、Agilityが上がらないチーム開発になり、期待した結果を得られない事が多い。
原因は、Scrum自体が抽象度の高い開発プロセスである事がその一つだと考えている。実案件においては開発プロセスを補完するために従来型の開発方法の知見を利用する事になる。Agile開発の本質は、可能な限り早く顧客に価値を提供する事を優先する事だが、しかしながら適応した知見がAgile開発との相性が悪いと、効果が出るまでの障害となる事がある。この問題については、Agileに適した知見を共有する事で問題解決するのではないかと考えた。
本発表では、これからScrumを導入するプロジェクトに適した幾つかのプラクティスを示す。プラクティスを導入した実案件のプロダクトの品質の分析結果およびプロジェクトの課題を共有する。

紹介文 :
STAMP/STPA (Systems Theoretic Accident Model and Processes / System-Theoretic Process Analysis)は、数多くのシステムがつながることにより発生する事故の解析に有用とされており、安全性解析の新しい手法として注目されている。
従来の安全性解析手法（FTA、FMEA）では、事故を引き起こす原因はシステムの故障であるとしている。それに対してSTAMP/STPAでは、システムがシステムの状態を誤認識することにより、 “安全ではないアクション”を実行することが事故の原因であり、それを特定するためにプロセスモデル（システムが認識するシステムの状態）の抽出が必要であるとしている。しかし、プロセスモデルの具体的な抽出方法については提示されておらず、分析者がアドホックに抽出するしかないという課題がある。
この課題に対し、MITのJohn Thomas氏はExtending STPAというコンテキスト（システムの状態）を分解してプロセスモデルを具体化していく手法を発表している。本提案は、この手法の前に、6W3Hを適用してコンテキストを幅広く捉え、プロセスモデルの漏れを予防しようとするものである。

紹介文 :
業務システムの受託開発において、要件定義工程の成果物として業務フロー図が作成される。業務フロー図には、業務全体の流れに沿ってシステム化する範囲と作業概要が記述される。その記述内容に基づき、発注者と開発者とで合意形成が行われ、設計工程やテスト工程の成果物が作成される。
業務フロー図をテスト工程の入力成果物として利用するとき、実務中に実行される業務シナリオがすべて記述されておらず、十分なテストを設計できないことが多い。典型的な業務フロー図では、基本シナリオ（業務目的を達成できる代表的なシナリオ）は記述されるが、代替シナリオ（業務目的を達成できる基本シナリオ以外のシナリオ）/例外シナリオ（業務目的を達成できないシナリオ）の記述が一部に留まっている。
業務フロー図に記述されない代替/例外シナリオを表現するため、状態遷移図/表を利用する方法がある。状態遷移図/表は、複数の業務に紐づく代替/例外シナリオを簡潔に表現できる。
しかし、業務システムの受託開発においては、設計工程でもテスト工程でも状態遷移図/表が作成されず、十分なテストを設計できたか検証するのが困難になるという課題がある。
本論文では、業務フロー図および各業務を詳細化した設計書から状態遷移を抽出し、業務フロー図に記載されていない代替/例外シナリオを補完してテストするためのテスト設計手法およびその適用事例について報告する。

紹介文 :
ソフトウェア開発において、品質と生産性の向上は永遠の課題である。
弊社では、ソフトウェア開発を行っている組織から毎年プロジェクトデータを収集・蓄積し、組織横断的なデータ分析を行い、品質や生産性への影響要因を分析することにより、全社的な品質・生産性の改善活動に結びつけてきている。
今般、2015年度に終了した527件のプロジェクトデータを使用し、出荷後の品質状況、設計・製造工程のレビューにかけた工数、設計・製造工程の工数、テスト工程の工数、各工程の摘出バグ数等から、品質および生産性の関係を分析したところ、設計・製造工程でレビューに時間をかけて、より多くのバグを摘出するほど、出荷後の品質がよく、生産性もよいことがわかった。
本発表では、これらの分析結果を説明し、品質と生産性はトレードオフの関係ではなく、品質・生産性向上を両立させて改善できることを報告する。

紹介文 :
　派生開発では、変更の影響箇所に潜在する欠陥を、回帰テストで見逃さず検出することが必要である。限られた時間で、影響範囲に対するテスト漏れを防止するためには「確実な影響範囲の特定」に加えて「テストの網羅性の確認」と「影響範囲を小さくする設計」が重要である。本発表では「制御の流れとデータ更新・参照の流れから影響箇所を特定可能」という考えから、影響波及パスという概念を定義し、それを利用した手法「影響波及パス分析法」を提案する。本手法を実開発に適用した結果、影響範囲に対するテスト漏れによる欠陥流出の防止に繋がる効果が確認できた。

紹介文 :
Internet of Things（IoT）や人工知能（AI）など、社会にイノベーションを起こす技術の急速な進展に伴い、これらを具現化するソフトウェアの重要性がますます高まっている。特にその品質は、社会基盤やビジネスに大きな影響を与えており、ソフトウェア製品・サービスそのものに対する要求はもちろん、利用時の視点での要求、そして、市場競争力強化への要求など、多面的に捉えられてきている。本稿では、「多面化するソフトウェア品質要求をどのように実現できるか」をテーマに、『ソフトウェア品質要求』を『品質特性』に読み替えることに着眼し、品質確保するアプローチを考案・検証した。本品質確保のアプローチは、『品質特性』を実現するために採用する『品質技術』の選択手法、そして、『品質特性』の達成度を評価できる『メトリクス』の活用手法から構成した。品質特性とその達成度を評価するメトリクスは、国際規格ISO/IEC 25000シリーズ（SQuaRE）をベースに、品質技術は、網羅・体系化が必要となるため、「ソフトウェア品質知識体系ガイド（SQuBOKガイド）」をベースとして研究を行った。最後に「IPA 2015年度ソフトウェア工学分野の先導的研究支援事業（RISE)」（早稲田大学）が調査結果として報告した「異なる品質間の関係を総合的に実証した世界初のベンチマーク（WSQB2017）」との検証も行い、ひとつの実践結果を示すとともに、今後広く展開するための深掘りの観点と考察を発表する。

紹介文 :
一般的な開発プロジェクトではテスト工程終了時の工程移行判定にて品質判断しているため、品質問題が起きた場合はスケジュール遅延のリスクが発生しやすい。当社では本リスク対策を行っている。
当社の品質保証部門では最終成果物であるソフトウェアの品質要求を品質特性で定義しており、品質特性を品質指標として活用している。テストレベル毎に品質副特性ベースで定義された品質要求を達成することを念頭にテストレベル毎にクオリティゲートとなるクライテリアを定義している。
この品質保証プロセスを活用し、品質問題が起因したスケジュール遅延リスクの対策として、テストレベル毎にクオリティゲートとなる当社独自の「受入テスト」という仕組みを構築し、予定しているテストが手戻りなくスケジュール通りにテスト可能な品質が備わっていることをシミュレーションしている。
当社独自の受入テストは、網羅性のある品質特性で定義された品質要求が確保されていることを念頭に対応するテストタイプからテストケースを抽出しているため、テストレベル毎の受入テストをパスすることにより、品質確保の状況が分かりやすくなる。
本論文では、テストレベル開始前条件に品質判断する手法として当社独自の受入テスト技法を紹介し、本技法の効果であるプロダクトリスクの回避や品質の見える化実現に向けたプロセスの解説とともに説明する。

紹介文 :
探索的テストは、バグの摘出効率が優れており、品質向上や生産性向上を目指す多くの組織に注目・活用されている。
しかし、システムの受託開発を行う業者における、探索的テストの採用事例は少ない。
探索的テストは、事前にテストケースを作成しないため、テストの総量や実施範囲が不透明であり、テスト管理が難しいことが原因の1つと考えられる。
そこで、受託開発におけるテスト管理に求められる要件を明確にすべく、JSTQB Foundation Levelシラバス「5. テストのマネジメント」に記載の6つのカテゴリに着目し、これらのカテゴリごとに、探索的テスト導入時の問題点を整理し、改善目標を定義した。
本発表では、テストをセッションと呼ばれる時間の枠で管理する「Session-based Test Management」を活用することで、定義した改善目標を満たしながら、探索的テストを実施する方法を検討し、実際の開発現場で適用した結果を紹介する。

紹介文 :
ウォーターフォール開発プロセスは、上流工程における成果物の完成度をできる限り高めることにより、当該工程以降に検出されたバグの修正による後戻り作業を低減するモデルといえる。そこで、品質管理部門では、上流工程の成果物の完成度の程度を測るための各種メトリクスを定義・運用して、品質上のリスクを見極める判断をしている。
筆者の組織では、プロセスメトリクスの一つであるレビュー工数の基準値を定め、レビュープロセスを確実に実行するように、組織的なプロセス標準を規程し品質管理を運用してきた。その結果、レビュー工数の増加と供に、出荷後のバグ数は減少し、一定の成果が得られたと考えられる。しかし、レビュー工数がある程度確保され、レビュープロセスが安定して実行されるようにプロセスが成熟した組織に対して、レビュー工数を軸にした品質管理だけでは品質リスクの見極めが難しくなってきた。
そこで、レビュー記録に着目し、レビュー記録のテキスト情報から得られるメトリクスについて設計品質に影響を与える要因を分析した。レビュー記録のテキスト情報から抽出したメトリクスには、バグの指摘率、レビュー指摘文の長さ、および、レビュー指摘文の述語の種類別の頻出度などである。
本発表では、これらの分析結果をもとにして、レビューにおける多角的な品質管理方法について提案する。

紹介文 :
近年のソフトウェア開発では流用開発やOSSの活用等、開発者は他者が開発した機能を開発対象に組み込むことが一般化してきている。この開発方法は開発工数の大幅な削減が期待できる。その一方で、他者が開発した機能を取り込むことで、開発対象のソースコードがブラックボックス化・複雑化し、ソースコードの品質劣化による障害の誘発や、障害調査・修正に多くの時間を要する等の問題が発生している。開発者に開発対象のソースコードの品質情報を提供すれば、問題の早期発見や修正時間の短縮化につながると考え、ソースコードの品質状況をメトリクスにより自動測定し、定量的に把握する仕組みの確立、および開発現場への展開を行ってきた。しかし、開発現場からは「メトリクスを見ても対応方法が判らない」等の声があがっており、定量的なメトリクス情報に基づいてソースコードの品質を改善するプロセスが現場に根付かない問題があった。
そこで本稿ではソースコードの品質劣化を表すメトリクスと、その後のソースコードの修正回数や修正日数（品質リスクと呼ぶ）との関係を分析し、これらの間に関連があることを示す。これにより開発者にメトリクスを活用したソースコード品質改善の早期対応への動機づけを行う。あわせて品質リスクへの具体的な対応案を開発現場に提示し、品質劣化を防止することで、追加コストの発生および納期遅延を未然防止することを狙いとする。

紹介文 :
ソフトウェア開発において、開発作業の進捗は評価できるが、プロダクト品質（コードにバグがどれだけ存在するか）はテストが完了するまで分かり難い。そのため、ソフトウェアのバグが計画より多く存在し、バグ修正に掛かる時間と労力が計画より増えること、今後について再計画が必要であるということに気付くには、多くの時間が必要である。特に大規模で短期間のソフトウェア開発は、バグが多いリスク、納期が遅延するリスク、コストが増えるリスクが高いため、早期に品質の悪い部分を検出し改善させるサイクル（よいプロセスに改善する）が重要である。
よいプロセスの習慣化には各工程で活用するセルフチェック（標準的なチェック観点）やレビューを愚直に実施させることが有効である。実施状況を数値化することで作業品質を評価できる。この作業品質の尺度を用いることで、"異常値"(＝作業品質が悪いモジュール)は開発要員の理解不足、手抜き（嘘）を客観的に検出できスキル向上の指導を施すことができる。
私たちは本施策をQM3S”Quality Mind and Skill Scoring System”と呼び、開発作業における作業品質を定量的に評価する手法がソフトウェアの品質確保に有効であることを確かめた。本発表ではQM3Sの特徴説明を行うとともに適用効果の報告を実施する。

紹介文 :
本発表では、弊社の鉄道ソリューション事業のシステム開発部門における改善活動について報告する。
改善したいことは「プロセスに対する納得不足」→「プロセス不遵守の増加」→「市場不具合の増加」のサイクル。この負のサイクルの歯止めとして、まずはプロセスに対する現場の納得感を高めることに取り組んだ。新人からベテランまで、プロセスの目的・必要性に納得してもらえるよう、ＷＨＹに重点を置いた新たなプロセストレーニングを実施した。トレーニング対象は、エンジニアリング領域のプロセス。
過去のトレーニングでは手薄だったプロセスの目的や意義「何のために必要なのか」「何が嬉しいのか」といった話や、プロセスに関する社内外の取り組み、やりがいを感じてもらうための話を新たに取り入れ強化した。
プロセス自体の説明も、ＷＨＡＴ・ＨＯＷが中心だった過去トレーニング内容を、ＷＨＹ・ＷＨＡＴ・ＨＯＷの説明へ再構築した。またベテランが新鮮味を感じるよう、標準プロセスだけでなく、現場ノウハウも紹介するよう工夫した。
トレーニングの有効性はアンケートで評価した。過去トレーニングと比べ、全評価項目が上昇。また任意記入の感想・要望も改善がみられた。感想・要望の前向きなコメント内容や、テキストマイニング結果からも、プロセスへの納得や関心に効果があったと評価できるため、トレーニングの工夫やトレーニング内容について紹介する。

紹介文 :
　システムのディペンダビリティを説明しステークホルダ間の合意形成を行うことを目的として、D-Caseという手法が提唱されている。発表者らは2013年度にD-Caseを用いて曖昧な要求仕様を明確化することに成功し、その後も現場への適用拡大に取り組んできた。しかし、D-Caseの使いどころや論証方法が難しいという点から導入が進んでいない。
　対策として「D-Case適用ガイドライン」を策定し、プロジェクトへの適用手順を明確にした。その際、いきなりD-Caseを書き始めるのではなく、D-Case作成前のチーム議論によってプロジェクトの目的、リスク、チャレンジしたい内容をチームで共有することに重点を置いた。また、ソフトウェア開発によくある具体的なパターン（D-Case適用パターンと呼ぶ）をガイドライン中に掲載し、初めてD-Caseを作成する人の指針となるようにした。さらにD-Case適用ワークショップを開催し、開発プロジェクトごとに少人数のグループにわかれた議論を行いD-Caseを作り上げた。現在は、作成したD-Caseから導出されたタスクの実行と効果の確認を行っている。
　本発表では、D-Case適用ガイドラインの内容と適用の結果を報告する。

紹介文 :
レビュー会議において、時間通りに終わらない、軽微欠陥の検出に終始するなどの問題が発生し、参加者は効率よくレビューが行われていないと感じている。我々はこの問題が解決されない原因は以下の二つにあると考えた。
・レビュー会議の目的が曖昧になっている
・レビュー会議の実態を参加者が正確には把握していない
この二つの原因により、参加者はレビュー会議に不要な活動があり、効率よくレビューが行われていないと感じているのである。
そこで我々は、レビュー会議の目的が曖昧になっており、レビュー会議の実態を参加者が正確には把握していないことに起因する問題を解決する手法として、TMBRI(Time Measure Based Review Improvement)法を考えた。TMBRI法の特徴は下記の三つである。
(1) レビュー会議の参加者全員で、各々が持つレビュー会議の目的を共有する
(2) 発言内容毎の時間、発言者を可視化し、参加者全員で振り返る
(3) 振り返りにより、レビュー会議の主体的な改善を促す
TMBRI法の効果を検証するため、実際のレビュー会議に対して試行したところ、レビュー会議の目的が曖昧になっていることを参加者が認識することができ、レビュー会議の改善策を導出できることがわかった。
本報告では、TMBRI法を用いたレビュー会議の可視化により目的の曖昧さを明確にする手法について詳細を述べる。

紹介文 :
我々は、ウォーターフォールによる組込みシステム開発において「プロジェクト後半での不具合の顕在化による日程遅延とコスト増加」という問題を長らく抱えていた。当初はドキュメント作成やそのレビューの厳格化による解決を試みたが、投資に値する結果が得られることはなかった。その後、アジャイル導入による問題解決を試みたが、プロセスやプラクティスの真の目的を理解しないまま実践した為、その効果を得ることはできず問題解決には至らなかった。今回は、この反省に基づきプロセスの導入方法から根本的に見直した。既成のプロセスをそのまま導入するのではなく、現行プロセスの問題点を明確にした上でその問題を解決するために必要なプラクティスを選別し、さらにそのプラクティスをチームおよび開発対象の特性に合わせ最適化させながらプロセスを再構築した。例えばアジャイルプラクティスの中でもイテレーション開発／テスト自動化は技術面において非常に効果的であるが、ハードウェア開発との整合が必要な組み込みシステム開発においてはそのままでは導入が難しい。しかし、それらを組み込みシステム開発に最適化する工夫を施すことにより、実践が可能となりその効果を得ることができるようになった。
本試みの結果として、ハード結合工数の半減、システムテストのバグ件数の2/3削減および余裕をもった日程維持を実現することができ、長年の問題を解決することができた。

紹介文 :
SI事業において、システム構築や稼動維持の作業はSEの手によって支えられており、手作業であるがゆえにヒューマンエラーに起因する事故が発生している。事故は全く新しい要因によって発生しているとは考えづらく、事故の正しい原因分析に基づく再発防止策の立案を積み重ねることで大部分の事故は未然に防げると考えられる。従来の事故分析では「個人・部署間で検討方法・品質が不統一」「分析工数が足りず、分析品質が低い」「対策対象が人に集中しがちになる」などの問題がみられる。
このような問題を解決するために、本報告では医療分野の分析手法を基に開発したSE事故分析手法を提案する。本手法は、原因分析から再発防止策の立案まで一貫した事故分析プロセスである。本手法には、分析工数低減のための原因絞込み手順追加と、再発防止策の発想支援の枠組み追加という工夫を加えている。
実際のSE事故に対して提案手法を適用し評価したところ、「発想が広がって再発防止策案の質が向上する」、「チームで議論しながら分析に取り組むことができ分析実施後の満足度が従来よりも高まる」などのメリットが確認できた。
現在、一つの事業部門においては、月次会議での報告に本手法が採用されている。またある部署では、本手法で導出した再発防止策により適用後約3年間の問題事象を、（従来頻度では10件程発生していたところを）0件に押さえることができている。

紹介文 :
通常、ソフトウェアテストにおいては、テスト要因を分析し、その要因を組み合わせてテスト項目を作成し実行する。作業効率化のため、実行と結果確認を自動化しても、テスト項目作成は人手であり、実施可能な組み合わせ数に限界があった。そこで我々は、要因をランダムに組み合わせ大量のテスト項目を自動生成し、生成されたテストの実行および回答との結果比較まで自動化する手法により組み合わせのバリエーションを拡張したテストを実施し、多くの障害を検出した。
しかし、活用の実績から2つの問題があることが明らかになっている。1つは、テスト項目を、ランダムに要因を組み合わせ生成した順に実行するため、品質リスクに応じた順番でテストできず、早期の品質確保ができないことである。もう1つは、結果比較でNGとなるテスト項目を大量に検出した場合、それらが同一原因によるものかの確認は人手であり、工数がかかることである。
本報告では、これらの問題を解決するため、障害に関係する重要な要因を含むテスト項目を優先的に実施する手法と、検出した障害を、そのテスト項目の要因に着目して同一原因かどうか自動で分類し、原因の究明を効率化する手法を提案し、実際のテスト作業においてこの手法を適用した効果について報告する。

紹介文 :
ソフトウェア開発では、大規模かつ短納期という非常に厳しい状況が続いており、さらに、顧客満足度を高めるため、要求変更への柔軟な対応と品質の確保が望まれている。著者らは、このような状況に対応できるソフトウェア開発手法としてWatts Humphrey氏の提唱するパーソナルソフトウェアプロセス（PSP）とチームソフトウェアプロセス（TSP）に着目している。PSPは、高品質なソフトウェアを開発するための自己改善プロセスであり、TSPは、チームの構築とマネジメントのための枠組みである。また、TSPは、ソフトウェアプロセスに基づく循環的な開発プロセスを用いており、高品質なソフトウェアを計画通りに実現するための多くのベストプラクティスを組み込んでいる。しかし、Capers JonesによるとPSP/TSPは、中規模以上のソフトウェア開発において最も優れた成果をあげているが、小規模開発においてはアジャイル手法が優れているとされている。九州工業大学では大学院科目として、PSP/TSPを導入しているが、プロジェクトの立ち上げや計画立案に多くの時間がかかり、短い期間に多くのサイクルを回すことは困難である。そこで、TSPの俊敏性を向上させるために、開発戦略やアーキテクチャ設計等に関する新たな指針を導入した。 本稿では、これらの施策を学生プロジェクトに適用した結果について報告する。また、プロジェクトサイクルを短くした際の品質への影響や、教育的な観点からの効果について議論する。

紹介文 :
当社では利用時の品質の評価を実現するため、利用者用文書を活用した取り組みを行っている。SQIPシンポジウム2016で発表した内容であるマニュアルベーステストを行う時期や検証実施条件を考慮し、マニュアルベーステストで修正した内容が効果的かどうか検討した。なお、今回はマニュアルベーステスト技法を用いた評価の実施が可能かどうかの判断基準としてマニュアルユーザーテストを活用し、その結果からマニュアルベーステスト実施時の検証観点の考慮を行うこととする。
また、過去の評価結果に対し、当社サポート部門への問い合わせ分析による技法の効果測定を行った結果、問い合わせ数が減少しこれまでの施策が効果的だと考えられた。そこで、既存のマニュアル制作プロセスにマニュアルの品質保証を目的としたマニュアルベーステストとユーザーテストを組み込んだプロセスを構築し、適用することとした。「マニュアル評価ガイドライン」の評価観点と利用者文書の品質要求の品質特性とを紐付けしマニュアルの評価工程別に担保すべき品質の明確化し、プロセス改善を進めた。
今回は、当社が適用しているマニュアル制作プロセスの流れとマニュアル制作の一部を修正し、マニュアルベーステストとユーザーテストを適用し評価した結果を報告する。また、マニュアル制作プロセスでマニュアルの評価を行うことが、利用時の品質の向上に繋がることを定量的に示し、利用時の品質評価のためのマニュアルベーステスト技法の改良について解説する。