概要

品質とは“違い”も意味する。今や性能や機能による実用的側面よりも、ブランドを含めた“違い”による顧客の経験したい“コト”を通した情緒的価値が重要性を増している。情緒的価値は顧客側からも価値を高める“共創”が起こる。過去の産業革命では、新技術の出現の後、“標準化”や“Kaizen”といった新マネジメント思想を編み出した国が主役に踊り出ている。第４次産業革命では、AI等の人工物の科学の力も借りながら最も高級な発想法である“共創マネジメント”が価値創造の競争力になるのではないか。本講演では共創メカニズムについて、データと事例に基づき示す。またその発現に日本の技術者の背景にある“今＝ここ文化”との相性と、本来アートと一体であったはずの技能・技術の復刻にもふれたい。

概要

レビューを実施しても、重大欠陥の検出漏れは後を絶たない。検出漏れが発生する要因の一つとして、欠陥の検出難易度が高いことが挙げられる。検出難易度が高い欠陥とは、レビュー対象である成果物から記載すべき内容が抜け落ちている欠陥、将来の運用や保守性について考慮が漏れている欠陥が該当する。すなわち、検出難易度の高い欠陥は、成果物の記載内容のみをレビューしていては検出できない。

そこで我々は、作成者に掛かる認知バイアスに着目した。認知バイアスとは、人の思考を無意識に歪め、誘導するものである。作成者が認知バイアスに掛かることで、ヒューマンエラーが引き起こされる。その結果、成果物に必要な情報が記載されず、検出難易度の高い欠陥を混入してしまうのである。

本発表では、認知バイアスに着目したレビュー手法として、D2BOCs（Defect Detection from Background of Cognitive bias）法を提案する。D2BOCs法の特徴は以下の二つである。

1. 認知バイアスを推測し、欠陥の傾向を特定する
2. 高リスクの範囲を重点的にレビューする

効果検証により、重大欠陥・検出難易度の高い欠陥の検出にD2BOCs法が有効であることを確認できた。

概要

システムの出荷後障害を分析したところ、運用を考慮した設計が不十分であることが原因で重大な障害を引き起こしていることが分かった。
運用を考慮した設計を行うためには、設計書レビューに運用の観点を取り入れることが重要と考える。
レビューに観点を取り入れるPerspective-Based Reading（PBR）を開発プロジェクトで実践できるようにするため、全国7拠点113名のエンジニアに対し、レビュー手法の演習教育を実施した。
当部門では、個人の経験に基づいたレビュー（Ad Hoc Reading：AHR）を行うプロジェクトが多い背景を踏まえて、教育ではPBRとAHRの違いを参加者が実感できるような工夫を行った。
また、AHRとPBRのレビュー結果から得られたPBRの有効性について報告する。

概要

「顧客に言われたとおりに製品を作ってリリースした結果、やり直しになった、あるいは、クレームがきた」という事象は日常的に発生しており、それにより大きなコストの無駄や手戻りが発生している。これは、顧客からすべての情報を引き出すことができず、市場のニーズや開発の背景といったシステム開発工程よりもさらに上流の情報についてを明らかにせず要求や仕様化したうえ、このような状態で作成された仕様書に対して、以下の手段でレビューしていることが原因なのではないかと考えている。

• 自らの知識を頼りに、仕様に記載された内容のみをレビューしている。
• 要求と仕様を比較するだけのレビューをしている。

その結果、必要な指摘が行われずにレビューを通過してしまうことで、顧客の事前期待や要望を満たしていないまま仕様を確定し、その仕様を実装した結果、このような事態になってしまうのではないだろうか。
我々はそのような状態で作成された仕様書でも、市場のニーズや開発の背景からレビューの観点を導き出し、その観点をもとに仕様書をレビューすることで、ユーザーの利用時や顧客の課題、解決したい問題に応える仕様とするための指摘を行えるのではないかと考え、“コンセプトベースでレビュー”と名付けた手法を実施して検証を行った。
本発表では、その手法の紹介と、検証結果について説明する。

概要

システム開発における仕様書や設計書は、制御された抽象度を保った厳密な記述により、開発対象が何であるのか、どう作るのかを明らかにする必要がある。また、開発者やテスト設計者などの後工程担当者の様々な関心事に応じて、参照・活用しやすい情報として整理されていることが望ましい。さらに、例えば機能仕様からテスト仕様を生成するなどの自動処理が実現できれば、開発を効率化することができる。そこで我々は、システム開発における基本設計書を対象としたテストケース一覧を自動生成するツールの検討を通して、設計書フォーマットの書きやすさや読みやすさ、テストケースへの自動変換、仕様記述の自由度について実験、考察した。

本論文では、仕様の構造化や、記述方法を制約するなどの試行錯誤をしていくアプローチを通して、特に、仕様の内容と記述に対する自由度を持たせる方法に関する議論をすることで、「制約を、自動化できる最小限にとどめ、仕様を記述するための自由度を残しつつ、後工程でもつかいやすい」基本設計書フォーマットを作成するためのアプローチを提案する。

概要

短納期型開発プロジェクトは要件定義・開発・テストが並行で実施されることが多く、以下の理由によりテスト工数の増加を招くという問題があった。

• 仕様変更多発のために手順記述式テストの修正による手戻り工数が増える
• テスト実行スケジュールが開発完了のタイミングに左右されるため、計画通りのテストができない

そこで我々は問題解決のために、マインドマップによるテスト分析を活用した探索的テストを適用した。このテスト手法を「FaRSeT（Flexible and Rapid Software Test）／ファルセット」とチーム内で呼んでおり、2015年頃から段階的にブラッシュアップを重ね、多くのプロジェクト（主に短納期の業務系システム）に対して適用してきた。

FaRSeTは、以下の２つの要素から成り立つ。

1. 仕様変更の影響を受けづらい業務要件の分析をマインドマップで行い、変更可能性の高いUI部分などは手順記述式テストを採用せずに探索的テストを活用する。
2. 開発スケジュールの変更に対応するため、探索的テストマトリクスにて品質状況や実施優先度の可視化と共有を行うことによってテスト実施個所の関係者合意を行う

FaRSeTを短納期プロジェクトへ適用した場合の効果が得られたため、この手法及び効果を報告する。

概要

JAXAでは、新規のシステムを開発する際、ソフトウェアの要求定義や設計段階で、要求の抽出や設計のレビュー、試験ケースの網羅性向上、運用への制約を抽出するためにFMEA（故障モードと影響解析）を行っている。FMEAの効果を向上させるためには、一般的に「故障モード」を如何に網羅的に導出するかと、システムへの影響が大きい「故障」を洗い出せるかが重要である。一方、ソフトウェアの製品としての特性からFMEAを適用する際、下記の課題が発生していた。

• 課題①：ソフトウェアへFMEAを適用する単位は抽象的なアイテムになるため、ソフトウェアの「故障（求められる機能を遂行できない）」を発想する難易度が高い。
• 課題②：ソフトウェアは、システムの利用や運用状況を分析して製作されるため、アイテム（機能等）の特性に合わせた上位システムへの影響を分析する難易度が高い。

本発表では、分析フレームワークで技術者の思考を段階的に誘導し、GSN（Goal Structuring Notation）とESD（Event Sequence Diagram）のビューによるレビューを行う方法で解決を試みた結果を説明する。

概要

ミッションクリティカルなお客様システムに対して、信頼性を中心とした非機能要件の充足性を向上させるために第三者検証を実施している。従来のシステム点検では、システムを構成するハードウェア、ソフトウェアの製品内部仕様や構造が把握できることを前提とし、製品内部の故障事象を始点とするホワイトボックステストにより、リカバリ設計の漏れが無いことを点検し、システム稼働前に障害を検出、対処を行ってきた。

しかしながら、近年のミッションクリティカルシステムはOSSを含めたマルチベンダー構成が主流となっており、構成する製品の内部仕様の全ては公開されていないことから、ホワイトボックステストは適用出来ず、ブラックボックステストによる点検のみとなる。ブラックボックステストの課題は、業務プロセスの無応答のような、外部仕様として表れない例外事象に対するリカバリ設計の不足、および設計漏れにより発生するトラブルを、システム稼働前の点検で検出、対処することが難しいことである。

この課題に対し、内部仕様が不明確なマルチベンダー構成システムの点検手法として、製品内部仕様として表れる故障事象に着目するのではなく、故障がシステムの業務処理に与える影響とその応答をモデル化し、モデル化した応答に対してシステムが備えるべきリカバリ設計を可視化する「フェールセーフ設計に対する点検手法」を開発した。その点検手法と適用結果について報告する。

概要

IoT時代における開発方法論は、セーフティだけやセキュリティだけを意識したものではいけない。例えば、セーフティの考え方では、可用性を重要視するため、機器連携をする際に、情報の機密性を保持できていないことがある。また、セキュリティの考え方では、機密性を重要視するため、利便性や機能性を損なう可能性がある。すなわち、これからIoT時代を迎えるにあたって、セーフティとセキュリティ、それぞれにバランスよく対応できる開発方法論が必要である。しかしながら、バランスよく対応できる開発方法論は確立されておらず、既存のセーフティにおける開発手法や、セキュリティにおける開発手法がどの程度バランスよく対応できる設計手法として使えるのか、検証もされていない。本稿では、セーフティの分野で実績のあるSTAMP/STPAを、セキュリティの分野とコラボレートさせた結果、その有効性を検証できたので、セーフティ＆セキュリティ開発のための方法論として提案する。 本発表では、新しい安全解析手法「STAMP/STPA」をセキュリティ適用し、さらに、STRIDEを脅威分析手法として適用したことによる成果を中心に述べる。

概要

ベースソフトを部分的にしか理解できていない状況での作業が強いられる派生開発において、変更漏れに分類される欠陥の流出を防止することは重要な課題である。
組織の流出欠陥情報を分析し、派生開発で特定が漏れるソースコードの変更箇所には、次の3つのタイプがあることがわかった。

　A)変更仕様から直接特定可能な箇所
　B)ソースコードの変化点から直接影響を受ける箇所
　C)設計制約の変化から影響を受ける箇所

C)の「設計制約の変化から影響を受ける箇所」については、変更漏れを防止するための効果的な手法がなく、変更箇所特定漏れにより、欠陥が流出した。この問題は、ベースソフトの調査が、人の知識・経験に依存していることから起きる。

本研究では、「設計制約の変化から影響を受ける箇所」を漏れなく特定するために、ベースソフト調査手法を開発した。提案手法の技術要素として、「欠陥混入メカニズムの知識の表現方法」と「欠陥混入メカニズムの知識を活用したDRBFM実施手順」の2つを定義した。
実験により、提案手法を適用することで、過去に発生した変更箇所の特定漏れが再現しないことを確認した。本手法を実開発に適用することで、派生開発における変更漏れ確実に防止する効果が期待できる。

概要

既存システムの改修を行う派生開発では、スクラッチ開発に較べて開発コスト、期間を低減できるメリットがある一方、無影響確認を含めた大規模なテストが必要となるが、開発側が作成したテストケースの妥当性を顧客側が判断する事は時間的にもスキル的にも難しいのが一般的である。

そこで我々は、開発工数見積りにおいては普及が進む第三者による検証をテストケース見積りに応用し、開発側が作成したテストケースと第三者が作成したテストケースを比較し検証する手法を考案した。

本発表では、本手法によりテストケースの網羅性を客観的に評価し適正なテスト計画とする事でテスト品質の向上に寄与できることを示す。 加えて、CRUD表からテストケースを自動生成する手法もあわせて発表する。

概要

研究開発におけるソフトウェアプロダクトは、インキュベーションから商用にいたるまで幅広く、その種類も業務アプリケーション、メディア処理エンジン、OSS、ミドルウェアなど多種多様である。こうしたプロダクトの多様性が開発ベンダやリリース先の事業サイドとのトラブルの原因になることがある。例えば、開発主管が品質（非機能要件）の作りこみの程度を把握できていないために開発作業に過不足があり要求する品質を達成できない場合や、開発主管（研究所）が想定していない使い方を事業サイドがする場合である。このような問題を解決するために、利用条件を明確化し、どのような品質を念頭において開発をするかをあらかじめ計画することを徹底することが求められていた。

そこで、ソフトウェアプロダクトのリスクマネジメントを目的として開発標準を策定し、プロダクトの使われ方で分類した「品質クラス」の概念と、ISO/IEC 9126の品質特性を105の具体的な観点にブレークダウンした「品質確認表」を導入した。それにより、使われ方を意識した非機能要件設定とそれを具現化するための開発作業の具体的な取捨選択が可能になった。
さらに開発標準を中心に据えた(1)リスクマネジメント運用のルール化、(2)形骸化防止のためのモニタリングと第三者チェック、(3)実プロジェクトの開発文書の公開とe-learningによる自学自習、(4)集合知共有を目的とした統計データ公開を制度設計し、システム化を行った。

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

概要

プロジェクトを遂行する上で、一番厄介なものは人間関係といえる。
プロジェクト内での衝突・言った言わない問題などに代表される人間が関わる問題・課題をできる限り事前に取り除き、プロジェクトの失敗をなくすことが理想である。
本稿では、上述の問題・課題としてコミュニケーションエラーに焦点を当て、解決へのアプローチを提案する。

問題・課題を解決するときには、様々なツールや手法から選択する必要がある。
エラー特性のモデル化、およびツール・手法のモデル化をすることにより、適用特性・場面によって モデルを選択し解決手段を効果的に使うことができる。このことにより、プロジェクトマネジメントの成熟度やチームの友好度が異なる組織においても、これから起こりうる問題・課題に対してモデルを事前に参照し対策を施すことにより、円滑にプロジェクト遂行を行いプロジェクトの失敗を防ぐことができると考える。
これにより、組織やプロジェクトを横断した共通の問題・課題などを解決するためのプラットフォームになるのではと考えた。

そのアプローチ方法として、マズローの欲求段階と TOC の抵抗の六階層を用いてモデル化したもの、およびツールや手法などによる解決手段を心理的障壁（エラー特性の各分類）ごとに分類したRPGモデル（仮）を提案する。

概要

ソフトウェア開発で行われるようなプロジェクトの完遂までに生じる諸問題を検討するタイプの会議を対象として考える。ステークホルダーは会議を開き、議論を通して現状を認識し、問題に対する合意形成を行う。

しかし、我々はその会議において参加者は想起した自分の意見を必ずしもすべて発言という形で表出しないのではないかと考える。例えば会議中に持っていたものの結局発言されなかった意見や会議終了後に思いついた意見など、それらの意見は発言を記録する議事録には記録されていない。しかしその発言されなかった想起のもととなった意見や疑問も消えてしまったと考える理由はない。いつかもう一度想起されて表に出てくる可能性がある。次の会議か次の次の会議かもしかして成果物が出来上がってなにか問題が発生してから思い出されるその意見は、時間やコストを消費し、成果物の機能や特性に影響を及ぼすものであったかも知れない。

記録されなかったために問題として認識されず、議論もされなかったために問題は潜在化したままになったのである。我々はこの問題を解消するためには、まず会議で参加者が想起した意見をそのタイミングで収集して記録する必要があると考える。我々はMinute Paperと呼ばれる質問紙でそのような意見が記録できるか実験を通して確認し、それをフィードバックすることで今後の議論に含めることができるか検証した。

概要

近年のクラウド進展により、ITサービスビジネスはますます活況を呈しています。
特に、クラウドサービスにおいて、お客様の価値向上の期待に応えてSoEとしての価値向上提供を実現するためには、従来のSIビジネスにおける品質保証の考え方から大きく踏み出し、変えていくべきと考えています。

私たちのグループでは、具体的なITサービス事例をもとにして、従来のSIと比較しながら、ITサービスの品質保証の考え方や役割分担などの議論を進めてきました。
この内容を皆さんと共有し、ITサービス時代における品質保証の有り方を考えていきたいと思います。

概要

昨年度は「つながる世界の到来」によってあらゆる想定外が発生してしまい、“ldquo;つながり”rdquo;の把握やリスクの発見、機器やシステムの管理が難しくなる“ldquo;IoT時代”rdquo;の困りごとをとりあげました。まずはどのようなリスクがあるかを知ること、そして、経営者自らのリーダーシップが必要であることを結論としました。

今年度は、IoTシステムの品質を確保するために何が必要か？
変化の激しい今の時代およびこれからは、今までと同じ考え方・手法では通用しないのではないだろうか？どのようにしていけば良いのか？討議してきたことを発表します。

概要

セキュリティの脅威が増す中で、ソフト開発におけるセキュリティ品質の確保の重要性と責任も増しています。
品証部門として、セキュリティの確保をどう行うべきかをMicrosoftのセキュリティ開発ライフサイクル（SDL）をベースに7期より検討してきました。
第8期では上流工程における脅威分析手法を紹介し、CVSSv3を用いたリスク評価手法を提案しました。
第9期では、下流工程にフォーカスし、セキュリティリスクに基づいたテストをする中で、OWASPやIPAのガイドラインなどに沿った脆弱性テストの例を紹介します。また、改めて既存の品証部門がセキュリティに関与する意義にも言及します。

概要

IoTなどの環境変化に対して、製品出荷後のサービスの強化による製品の価値を上げ続けること（サービス志向）が求められ、顧客が求める品質の変化に応えることが急務となっています。
しかしながら、こういった時代の変化に対して「従来の品質保証活動だけでいいのか」「なんらかの新たな役割が必要ではないのか」といったように、日々発生する品質問題に対応しながら、暗中模索しているQAは多いと思います。

そこで、我々は「サービス志向の時代に新たに求められる品質」を定義し、「新しい価値を提供するためにQA部門がすべきことは何か、変わる必要があるのか」について議論し整理したので、具体的な方向性について提案します。

この提案は、サービス志向の時代の品質保証活動に関わるQAの存在意義を再考し、どのように企業、その先の顧客に貢献していくべきかについて、皆様の道標（みちしるべ）になると考えます。

概要

第8期では，品質保証部門で「高品質力人財」を育成することの重要性を「ハンカチモデル」で表現し，個人に宿る品質力を引っ張り上げることで高品質力人財が育ち，それが組織や開発現場の品質文化を醸成していく好循環ループを形成する流れをまとめました。

しかし，市場要求や技術スピードが急速に変化している今，高品質力人財の養成も急務であり，従来の人財育成では会得に時間がかかるものとされてきた「経験」にあたる部分を，より効率的に他人から伝承する方法はないかと考えました。

そこで、今期では収集した経験伝承事例からQAの品質力を掘り下げ、パターンなどを用いた品質力伝承プラクティスを提案します。これにより，QAに携わる後進への継続的な品質力伝承、および開発部門のプロ人財育成にも積極的な貢献がなされることで，QAの価値向上につなげることが可能となります。

概要

AI（Artificial Intelligence:人工知能）がさまざまな場面で使われ身近になってきている。なかでも機械学習の利用が盛んである。機械学習を組み込んだシステムの開発は、従来のソフトウェア工学の知見だけでは不十分と言われている。また、データにより予測精度が変動するという機械学習の特徴は、品質保証における課題となりうる。本論文は、機械学習に焦点を絞り、その品質保証の動向調査結果を解説する。

概要

あらゆるモノがインターネットに接続されるIoT（Internet of Things）システムが急増している。IoTシステムでは、セキュリティの脆弱性を突いて、サイバー攻撃の踏み台にされる事例や、モノ側の安全性を侵害される事例など、トラブルが多様化している。一方でIoTシステムには、機器の長期間利用やリソースの制約などの特性もあり、品質保証が難しくなっている。本論文は、IoTシステムのトラブル事例、および品質保証の動向調査結果を解説し、考察する。