紹介文 :
ソフトウェア開発プロジェクトの規模は、ソースコードの行数という成果物の量によって定義されるLOC法、またはソフトウェアが提供する機能の量によって定義されるFP法で表現されることが多い。
一方で、サーバ等のハードウェアを導入し、ソフトウェアが稼働するようにIT設備を準備する基盤構築プロジェクトの規模は、メトリクスが確立されていない。
そのため、テストケース数やテスト時に摘出される欠陥数が適切な範囲にあるか、定量的に評価するための品質指標が無い課題がある。
そこで、LOCに該当する基盤構築プロジェクトの規模を表現するメトリクスを導出することで、この課題を解決できると仮説を立てた。
構築スケールに基づく品質指標を導出することを目的に、社内で2015年度より研究活動を開始しており、基盤構築プロジェクトの規模は「構築スケール（Cs：Construction Scale）」と定義した。
構築スケールに基づく品質指標は、以下4点を繰り返し実施することで導出した。

（１）基盤構築プロジェクトのメトリクス収集
（２）因子分析による基盤構築プロジェクトの規模に影響を与える因子の推定
（３）相関分析と重回帰分析による構築スケール算出式の導出
（４）構築スケールに基づく品質指標の有意性検証

本発表では、構築スケールに基づく品質指標の導出過程と有意性検証結果を報告する。

紹介文 :
ソフトウェア開発において、欠陥分析作業は必須のプロセスである。
この作業により、製品の品質もさることながら、プロセスの品質を推し測ることができる。
そのため、自社開発プロジェクトで欠陥分析作業は実施されているものの、その実、作業内容自体には標準というものがない。
分析作業を実施しなければならないことは開発プロセスに組み込まれているが、具体的な作業手順やその内容は標準化されていないのが現実である。
それらは、派生開発で継続的に受け継がれた内容であったり、報告者の独善的な内容であったり、レベルがまちまちな玉石混交な成果である。

上記の課題を解決するために、ODC属性（Orthogonal Defect Classification、直交欠陥分類）を軸とした欠陥分析パターンを案出、さらに欠陥分析作業を標準化することにより、分析レベルの一定化や作業の効率化を図ることを目的とした改善作業について報告する。

紹介文 :
RPA（Robotic Process Automation）はロボットによってホワイトカラーの事務作業を自動化・効率化する技術として近年多くの企業が採用している。そのような潮流の中、RPA開発の需要は年々増加傾向だか一方でRPA開発における課題も顕在化してきた。

例えば
①RPA開発は工数見積り手法が確立されておらず、過少見積となる場合がある
②非機能観点の設計ルールが確立されておらず、ロボット品質にバラツキが出やすい
の2点が挙げられる。

①RPA開発は機能数や複雑度合いによって開発工数は数人日～数人月と大きく変動するが要件定義段階で精緻な見積が実施されないまま開発に着手するとスケジュールの遅延や品質低下を招く。
②RPAはその自由度の高さからRPAツールを習得すれば直ぐに開発可能だが、複数の開発者にて同時に開発を進めるとエラーに対するリトライ方法が開発者毎にバラバラとなるなど運用が煩雑となり、結果リリース後の保守レベル低下を招く。

上記2点の課題を解決するため、弊社では
・ファンクションポイントを活用した規模試算と工数見積り
・RPA専用の非機能設計ガイド策定
を実施し見積精度と品質向上に取り組んできた。

本発表ではその概要と効果について述べたい。

紹介文 :
OEM向けにおける自動車用ECUの開発では一般的に約3年を要するが、アフターマーケット向けの場合、顧客要求により約１年での開発を要求され、従来の開発モデルでは顧客の要求納期に対応することができない。なぜならば、短納期がゆえに、仕様が固まっていないことがほとんどで、仕様を固めながら開発する必要があるため、開発の途中で仕様の変更や追加が起こるためである。このような開発では、ウォーターフォール型開発ではなくアジャイル型開発が向いていると考えられるが、当社において車載組込み開発においてのアジャイル開発は一般的ではないため、今回、従来のウォーターフォール型開発をベースにしながらアジャイル型開発とのハイブリッドで開発を実施した。

また、Automotive SPICEのアセッサー経験に基づき、優先順位の高いプロジェクト管理(MAN.3)に主眼を置いてプロジェクトを推進した。スケジュールやWBSのフォローも含めたプロジェクト進捗のレビューおよび報告を実施し、活動の達成度を明確化することで、最低限必要なエビデンス、ツール、開発環境が整っている状態を構築・維持しながら開発を推進できた。

本発表では、この活動の概要と進め方、工夫した点について、事例を交えながら紹介し、短納期で開発を行いながら、品質保証とリリース要求を両立した内容を報告する。

紹介文 :
機械学習では、従来のシステム開発のようにプログラムを直接的に記述する方法とは異なり、訓練データから帰納的に振る舞いが生成される。そのため、できることとできないことの境界を明確に把握することが容易ではない。また、機械学習は100%の精度を出すことができないため、誤った答えを出す可能性を踏まえた考慮が必要である。このような特性により、機械学習モデル単体での品質保証は難しく、機械学習システム全体としての観点から、機械学習モデルからの出力を運用時に監視や修正をするアーキテクチャ等についてはその必要性が言及されている。

紹介文 :
当社ではソフトウェアパッケージ製品の開発および販売を行っています。
製品開発プロジェクトは開発プロセスと品質保証プロセスを区別し、独自ではあるがウォーターフォール開発を行っていました。
近年開発プロセスをアジャイルに変えることにより、品質保証プロセスもアジャイルにシフトすることに課題を持っていました。

欧米ではアジャイル開発がスタンダードになりつつありますが、アジャイル開発における品質保証はまだ世の中に確立されていないように思えます。
アジャイル開発は動くソフトウェアを継続的に提供し顧客のニーズに素早く対応するプロセスですが、リリースしたプロダクトは品質が保証されたものか、また第3者に対してプロダクト品質を説明できるかの判断が難しいと言えます。

弊社の品質保証部門はプロダクトの出荷時に市場リリース可能な品質を持ったプロダクトであることを説明する義務があり、第3者が理解可能な品質説明が求められます。

本論文では開発プロセスがアジャイル開発であっても品質保証プロセスにおいてJIS X 25010:2013で定義されている品質特性を利用し品質保証プロセスの指標として活用することにより、最終的な成果物が第3者に対して説明可能なプロダクト品質であることの判断を可能とすることを目的としてます。
また、プロジェクト計画時に戦略的なテスト計画を策定し、アジャイル開発プロジェクトの進行と共に品質が確保され、段階を経て品質を積み上げる仕組みを提案します。

紹介文 :
本事例では、継続的開発されることにより得られるデータとQC七つ道具を応用しDevOpsのプラクティス郡を導入した事例を紹介する。本事例では、クライアントとの統合テスト環境がアプリケーションの不具合などが原因で不安定となり、プロジェクトのスケジュールが遅延する問題がたびたび起こっていた。この問題の根本原因を調査するため、障害件数、バグ件数、バグ修正日数などのメトリクスを収集し、QC七つ道具を用いて分析した。その結果、
1.開発工程における生産性の問題
2.テスト工程における生産性の問題
3.開発とテストとのやりとりに係る生産性の問題
が根本原因を誘発させていたことがわかった。これらに対する施策として、有用なDevOpsのプラクティスA.パイプラインの自動化 B.受入テストの自動化を行なった。その結果、統合テスト環境で検知するバグ件数の66%を削減、またバグの修正日数を中央値で10日から2日に改善した。

紹介文 :
ビジネスの変化が急速に進む現代では、システム開発の工期短縮が強く求められている。
システム開発においてテストが要する工数は5割を超えるとも言われており、テストプロセスの改善は急務である。
多くの開発現場では、未だにスクリプトテストが主流であり、テストケース表などのドキュメント作成に必要な工数が重い負担となっている。
一方、探索的テストは、欠陥摘出効率の高いテスト技法として知られているが、スクリプトテストと異なり、テストケース表などのテストの詳細な内容を示したドキュメントを作成しないため、第三者に対してテストの十分性を説明することが難しい。

そこで我々は、探索的テストを応用した新たなテスト手法「SONAR Testing」を開発した。
SONAR Testingはテスト観点をベースとしたテストチャーターを用いることで、観点に対して網羅的なテストを計画できる。
また、テスターの行動を、画面遷移図やシーケンス図といったモデルに変換・可視化するツールを作ることで、レビューを通じて観点に対して十分なテストが実施されたかを確認できる。

本発表では、SONAR Testingの思想や運用方法、作成したツールの概要、および試行適用の結果を報告する。

紹介文 :
当社では64bit OSを搭載し、同OS上で動作するアプリをプリインストールしたパソコンを製造・販売している。筆者が所属する部門の任務は、出荷判定までに、すべてのOS不具合の原因を究明し、処置方針を決定することにある。

OS不具合の中には発生率が0.1%以下という低頻度で致命的な不具合も含まれる。このような不具合を再現させるには、同じ操作を1,000回以上繰り返すことが必要となる。当社ではこれまで自社製の連続試験ツール「Aginger」を用いた再現テストを行っていた。しかし、AgingerはGUI操作やキーボード入力の機能は備えていない。そのため、OS再起動後のサインインなど何らかのユーザ入力を行った場合に発生する現象の再現テストには使えず、人手で同じ操作を繰り返していた。その結果、多大なテスト工数がかかっていた。そこで、再現テストに市販のGUIテスト自動化ツールを活用することを考え、「eggPlant Functional」を導入した。

同ツールの導入効果を測るため、製品開発中に発生したある低頻度OS不具合について、人手でおこなう再現テストの工数と、eggPlant Functionalを用いて自動化した再現テストの工数を比較検証した。その結果、再現テストを約17分の1に効率化でき、大きな効果が得られた。本論文ではその成果を報告する。

紹介文 :
レビューの説明や指摘が作成者へ適切に「伝わる場合」と「伝わらない場合」がある。
また、「伝わる相手」と「伝わらない相手」がいる。説明や指摘の意図や期待が伝わらないと、レビューの効果は限定され、あらたな気づきや行動にもつながらない。

我々は、説明や指摘の意図や期待が伝わらない要因として、レビューアと作成者の「コミュニケーションスタイル」の違いに着目した。
つまり、お互いの価値観や考え方に沿わない伝え方をしているから、納得してもらえず、期待する行動にもつながらないのである。
レビューアが、作成者の「コミュニケーションスタイル」に合わせて、指摘の伝え方を変えることで、作成者は指摘を前向きに受け止めて、期待する行動を取ってくれるようになると考えた。

本発表では、「コミュニケーションスタイル」に着目したレビュー手法として、RCS(Review CommunicationStyle)法を提案する。
これは、コーチングで用いられている「コミュニケーションスタイル」の技法を、レビューに応用した手法で、作成者とレビューアの「伝達」方法と「行動」に変化を促す効果が期待できる。RCS法の特徴は以下の二つである。
簡易な方法でレビューコミュニケーションスタイルを診断
スタイルと状況別のレビュー戦略を提案
実験により、RCS法が作成者とレビューアの「伝達」方法の改善と「行動」の変化を促す可能性が高いことを確認した。

紹介文 :
当社では、お客様に納品した情報システム(以下、システム)で当社が保守を行っている全てのシステムを対象とした、保守作業に対するプロセスの点検(以下、システム点検)を実施している。これは年一回の頻度で実施する、保守作業プロセスの問題点を洗い出して改善していくことを目的とした品質改善活動である。事故事例からの再発防止策を「気付きを与える観点」として点検用のチェックリストに追加しながらシステム点検を実施してきた。システム点検導入後は保守作業プロセスの問題に起因する社外事故が大幅に低減しており、品質の改善に貢献してきた。しかし、近年は事故の低減が下げ止まり状態となり撲滅に至らないことが課題であった。そこで、従来のシステム点検項目で発見できなかった事故のポテンシャルを抽出するために以下の改善施策を講じた。

・事故の未然防止に直結する気付きを保守員に与えるために、踏み込んだ観点を記載したチェックリストの作成
・チェックリストの強化による項目の増大が結果的にチェックリストの形骸化につながることがないよう、点検項目を厳選し減らした

項目数を厳選し、従来の２／３程度まで減少させたが、点検の精度は向上し事故のポテンシャルを抽出することができた。その取り組みと改善施策について紹介する。

紹介文 :
ソフトウェア（以下、SW）をその製作目的に対して保証するためには、稼働後のシステム/ソフトウェアの利用や運用等の前提（以下、コンテキスト情報）を設計やそのレビュー時に考慮することが重要となる。SWの振る舞いがシステムの利用へクリティカルな影響を与える場合、コンテキストの考慮漏れは「想定外の状況や使い方」が発生し、最終的に致命的な事故につながってしまう。その「想定外」を減らすため、SW技術者は、与えられた仕様を満たすSWを製作するだけではなく、SW開発段階でもコンテキスト情報を踏まえた「リスクシナリオ」を識別し続けることが重要である。

一方、宇宙機システム開発では以下の特性のため、コンテキスト情報の抽出や伝達において難しさが存在する。

•利用目的（ミッション）の固有性が高く、システム毎にSWにとってコンテキスト差異が大きい。
•大規模且つ多組織による共同開発であるため、コンテキスト情報の伝達ミスが発生しやすい。
•シミュレーション解析及びモデリング中心であるため、SW技術者がコンテキスト情報を把握する難易度が高い。

本発表では、コンテキスト情報に着目した3つのビューを用いたリスクシナリオの作成方法、および3つのビューをより使いこなすノウハウを移転するためのレビュー技法を提案する。

紹介文 :
本グループは、AIシステム開発の現場で使える品質保証の観点を抽出することでAIシステムの品質保証活動を支援できる成果物を作成することを目標に活動してきました。品質保証の観点は、「AIシステムの品質保証をするために最低限やるべきこと」、および「AIモデルが最大限の精度を得るためにやるべきこと」の2面で考えました。実際に、簡単なAIモデルを作成して、精度などの改善を検証する過程で、具体的な品質観点を抽出しました。
発表では、本活動の成果物である「AIモデル開発を含むAIシステム開発プロセスの品質観点チェックシート」を中心にご紹介します。

紹介文 :
ソフトウェアの派生開発において、ソースコードの欠陥は「変更漏れ（追加漏れ／削除漏れも含む）」と「変更誤り」に分類できる。「変更誤り」については、変更仕様に対するテストを漏れなく誤りなく実施することで、欠陥の流出を防止することが可能である。

これに対して、我々の組織では、ソフトウェアメトリクスとレビューを活用し、テストの十分性の判断をしていたが、テスト漏れは検出しきれてはいないかった。

本研究では、「変更仕様に対するテストの漏れ」を検出するために、テストカバレッジの分析手法を考案した。短期間での開発が求められる派生開発において、現実的に実行可能な手法とするため、ソースコードの差分を抽出し、追加・変更箇所に対してテストカバレッジを算出する方針とした。
考案した手法を実開発に適用し、「変更仕様に対するテストの漏れ」及び「テストの漏れを誘発した“解釈誤りを起こす可能性の高い変更仕様”」を検出できた。考案した手法により、「変更誤り」に分類される欠陥の流出を防止する効果が期待出来る。

紹介文 :
近年のソフトウェアテストに求められる「自動化・AIなどの新技術との共存」「大規模・短納期なプロダクトの品質保証」に対し、従来のような「コマンド＆コントロールでテスト実行をこなすオペレータ」による人海戦術では太刀打ちできない。
そのため、「コマンド＆コントロールで膨大なテスト実行をこなすオペレータ」から「自律的に思考するクリエイティブなテストエンジニア」への転身を促進することが重要であると考えた。

テストエンジニアのスキルアップ・キャリア形成のための教育・トレーニングには様々な手法がある。これまでWACATE（ソフトウェアテストの1泊2日合宿形式勉強会コミュニティ）では、「ワークショップ」という手法を用いることで一定の効果を得てきた。そこで、若手テストエンジニアを主な対象とし、広く適用可能なエントリレベルの新たなワークショップの開発を行った。

ワークショップのテーマとしては、テストエンジニアのスキル領域の中でも「ソフトスキル」が該当することを特定し、特に「自律的な思考」に着目することとした。また、対比する形で「コマンド＆コントロール」を置くことで、より「自律的な思考」にフォーカスする新たなコンテンツを開発することができた。

本発表では、『テストエンジニアのマインドを、表を埋める単純作業からクリエイティブなモデリングに変えていく』活動を推進する一手法の提案として、実施内容の紹介と検証結果について説明する。

紹介文 :
システム開発において、発注者から提示された要求をもとに開発者がシステムを構築することが一般的であるが、元々の要求から漏れていた仕様や使われ方が後工程で判明し、対応のために大きな手戻りが発生することがある。

要件定義から運用に至るまでに複数の異なる会社や組織が関与する場合、自分たちの責任範囲を全うすることに注力するあまり、発注者の要求は満たしていても、実際の利用者の満足を得られないものに仕上がることがあるためである。

要求工学の分野においてはＲＥＢＯＫやＢＡＢＯＫのような知識体系があり、それらの知識に精通していればこのような不幸は起こりにくくなると期待できるが、知識習得と実践での活用には一定の時間とコストを要するため、全ての要員やチームに力量を求めるのは難しい。

このような現状でも、大きな手戻りによる時間や信用のロスを何とかして防ぎたい。そこで我々は、現実的なコストで効果を引き出せる「設計着手前レビュー」を提案する。

この手法は５Ｗ１Ｈというよく知られたフレームワークを活用していること、またその思考の過程を落とし込む「着手前要求確認フレームワーク」（Ｅｘｃｅｌファイル）で実現できることから、導入のハードルは低い。また、設計に着手する前に一度要求の見直しを行うことから、たとえ１つでも漏れを早期発見できればメリットは大きいと言える。

本発表では、その手法の紹介と検証結果について説明する。

紹介文 :
稼働年数が15～20年と長期間稼動するインフラ系システムでは、顧客からの質問や障害対応に関する保守運用データが障害管理データベースに蓄積されている。一方で人員の入れ替わりにより人に依存するノウハウは減少傾向にあるため、保守運用の知見が重要になるレビューでは影響度確認などの精度が落ちるリスクが生じている。

そこで、レビュー参加者のノウハウ不足を補うために、機械学習であるWord2Vecと専門用語辞書を用いて保守運用データから知見を導出するレビュー支援システム(QA Assist)を構築した。QA Assistは改修内容を入力すると改修に関連のあるキーワードや過去の障害事例を出力し、参加者が類似障害事例として参照することでノウハウ不足を原因とする障害を未然に防止する。QA AssistのPoCにおいて、機械学習で使用した専門用語辞書の精度が低く出力した障害事例に偏りが出た。その改善策として、少量の専門用語を基に機械学習を行うことで高精度な辞書を作成するツール(Smart Dictionary)を開発した。

QA AssistとSmart Dictionaryを組み合わせることで適切な類似障害事例を提示することが出来るようになり、改修起因障害をQA Assist導入前後で25%削減することに成功した。本発表では弊社が抱える業務上の課題やシステム構築の工夫点、利用事例及び導入効果を紹介する。

紹介文 :
我々はモバイル端末向けゲーム開発におけるEnd to Endテスト(以下E2Eテスト)の自動化に取り組んでいます。これらE2Eテストは1回のテストに10分以上もかかる長編テストとなるため、テストケースの記述にはコストがかかりますし、テスト結果は外乱の影響を受けやすく不安定で失敗の原因分析が必要となります。

これらに対する取り組みとして、テストケースの記述についてはキーワード駆動型テストフレームワークを導入してシナリオと端末操作処理を分離しています。またテスト結果に対しては、当初は実行ログと端末画面のスクリーンショットで確認していましたが、テキストで出力されたログは非エンジニアにはわかりにくくスクリーンショットは欲しいタイミングの記録ができるとは限りません。そこで端末の実行画面を動画として保存しそこにログ情報を字幕として重ねることで両者の欠点を補うことにしました。
これにより、非エンジニアへ直感的な動画での説明ができるようになっただけでなく、テスト実行時の「端末の処理内容」と「テストスクリプトの処理内容」が見えるようになったことで、テストエンジニアは自動テストを改善するためのツールを手に入れることができました。

現在はまだ自動E2Eテストの改善に着手し始めた段階ですが、同様にテスト自動化に立ち向かう方々へ参考となるように我々の取り組みを紹介します。

紹介文 :
ソフトウェア製品の顧客満足度向上のためには、製品の使いにくさの問題を検出し改善することが求められる。弊社評価部門では、使い勝手評価としてSQiP2016で発表した「インタラクションデザイン評価手法」をこれまで84製品で実践し、定量的な裏付けである「操作時間」「手番数」を基に使い勝手の向上具合を可視化し評価してきた。
しかし「操作時間」「手番数」の定量データだけでは、使いにくさの問題検出は可能だが、改善点の絞り込みに時間がかかる。これらの手がかりを得るため被験者ヒアリングにて以下を確認してきた。しかし、被験者が無意識に見ていた、あるいは意識的に見ることができなかった部分は回答から改善点が得られないことがある。

・製品や画面の構成を理解できているか、操作の躓きのきっかけは何か
・何かを探すとき、図や説明は視野に入っていたのか

これらを踏まえ、被験者の記憶に頼らず、視線の動きの可視化により前述の手がかりを定量的に捉える手法を考案した。
本取り組みのねらいは、インタラクションデザイン評価へ新たに視線検知技術を導入し、定量的な評価結果を基に開発者が納得できる改善案を提示することで、よりUX面で国際競争力の優れた製品開発を促進することである。

本発表では、視線の動きから製品の使いにくさの問題を検出し、改善点を絞り込む方法と実践結果、および今後の研究の方向性を報告したい。

紹介文 :
従来のウォーターフォール開発モデルにおいて厳格な開発管理を通じて規律を守るスタイルから、自律して最適解を自ら考えるアジャイルスタイルに切り替えたとき、アジャイルの経験の浅い開発チームは何に注意を払えばよいのかを判断できず、試行錯誤が続いた。
その結果、アジャイル開発手法の1つであるスクラムを取り入れたどの開発チームも、プロダクトバックログが増え続け、納期がどんどんずれていく失敗を繰り返した。
これは、スクラムのバックログ管理を正しく理解していなかったこと、開発管理があいまいになったこと、品質部門が第三者視点で開発管理にどのように関わるべきかを決めきれずに進めていたことなどが原因であると分析した。

対策を考えるとき、スクラムにおける開発管理の節目となる「スプリントレビュー」と改善の機会となる「ふりかえり」に注目した。スプリントレビュー時に、従来の定量的管理の考え方を取り入れて、客観的な判断指標を設定し品質部門が定量的管理を主導するなどの開発プロセスを構築した。そして、スプリントレビューで抽出された課題をふりかえりで議論することを定着させた。

本発表では、以上の経験もとに、ウォーターフォール開発経験者がアジャイル開発を始めるときに陥りやすい点と、経験をもとに得られた知見を紹介する。