スケールフリーネットワークで起こす
 DX2.0とQX（Quantum Transformation）

概要

過去10年間、インターネット関連の企業が、大きな株式企業価値を上げてきた。この背後には、スケールフリーネットワークという構造が存在する。このインターネットによる革命をDX1.0とすると、今後、今まで繋がっていなかった物がネットワーク化することによってDX2.0が起こることになる。これが本当に実現するには、物とデジタルをネットワーク化する、CPS サイバーフィジカルシステム技術を、スケールフリーネットワーク化出来るように実装することが大切である。そして、その先には、量子インターネットの世界が開けることになる。これらの、重要な技術と、コンセプトを、具体的な例を挙げながら紹介する。

事業活動と統合した品質マネジメントシステム確立に向けて

概要

当社では、グループ会社共通の基本理念のもと「質で語られる信頼のトップブランド」の確立を目指し、継続的に「品質」、「生産性」、「技術力」の向上に取り組んでいる。
この取り組みの一つに、事業活動との統合を目指した「i-Trintiy」（当社におけるQMSの呼称）の全社展開がある。事業活動との統合を目指すにあたっては、次の点が課題であった。
（１）品質関連施策が部分最適となっている
（２）マネジメントシステム未導入部門がある
（３）受託型ビジネス中心からサービス型ビジネスへのシフト
（４）複数のマネジメントシステムが存在している

本発表は、これら課題に対応し、事業活動と統合したQMSの全社展開を図るための第一歩として実施した取り組みについての事例紹介である。"

重回帰分析を用いたウォーターフォール開発の漸進的プロジェクト管理モデルの構築

概要

近年、組み込みソフトウェア機器の高性能・高機能化に伴ってソフトウェア開発は複雑化しており、QCDを守るためのプロジェクト管理は益々困難になってきている。特にウォータフォール開発においては、評価工程で発生する障害数を正確に予測し、適切な評価工数を設定することがQCDを遵守する上で重要になっている。

しかし、実際のプロジェクト開発の現場では、並行開発プロジェクトの有無やスコープの追加や削減などによりプロジェクト進行中にも品質見通しを変化させる要因が多く発生する。その変化要因に対して効果的な見積りのやり直しを行うことができないと評価工数が過剰になったり不足になったりして、コスト超過や日程遅延の問題を引き起こしやすい。

そこで筆者らはウォータフォール開発の状況に合わせて変化しがちである障害数の予測手法について検討し、プロジェクトを漸進的に管理するモデルを構築した。具体的には、ウォータフォール開発プロジェクトの障害数に影響を及ぼすと思われる影響因子について洗い出し、それら影響因子を使って障害数を予測する手法として重回帰分析を使った障害数の予測モデルを提案し、その実用性について検討を行ったので紹介する。

品質認証PSQの適応とソフト品質確保への活用

概要

当社の主力製品は、CG／VR、FEM、DESIGN(BIM・CIM・CAD)、WEBなどで、例えば、土木の設計分野ではユーザにわかりやすい品質指標がなく、重い瑕疵担保責任が生じるリスクがある。
社内では、ISO9001や品質確保の体制強化などを進めていたが、品質向上プロセスに対するアプローチのみでプロダクトに対する品質向上施策の不足を懸念していた中で、これを第三者プロダクト認証が可能なPSQ認証で補うことを考えた。この認証は、評価基準がISO/IEC25051:2014で、ソフトウェア品質特性を採用し、カタログ／マニュアル類を対象としたユーザ視点の品質評価が行われる点に着目し有効と判断した。
既に社内では、独立したテスト専業部署によるソフトウェアチェックの体制強化を行い、これに加え、最終テスト工程で第三者認証によるカタログ／マニュアル類の品質特性を踏まえた評価を行うことにより客観的な信頼性確保も可能になったと考えられる。
PSQ認証導入の有効性、必要性は、(1)購入予定者や利用者に提供する製品情報が正しくソフトウェアに実装されていることを保証すること、(2)実装されている機能が、テスト並びに検証作業により十分な品質を有することを保証することである。実現には、自社内で運用できる仕組みが構築され、品質確保を継続してゆくことが重要であると考えられる。
本発表では、品質認証PSQの適応並びに活用によるソフト品質確保について精査し、PSQ認証制度によるソフト品質確保に関する効果、有効性について紹介する。

プロジェクト立て直しと網羅的な検証を通し実感した基本の重要性

～日本地図と３割チェックによる品質の作りこみ～

概要

当社のWEB申込完結システムのアプリケーション刷新プロジェクトにおいて、結合テストの段階で、本来前工程で検出対処するべき製造・単体テストレベルの不具合が複数検出され、今後も不具合が発生する可能性が高い事が判明した。

また、その後の結合テスト・システムテストにおいても不具合が発生したため、保証するべき品質の評価が非常に困難となった。

そのため、不具合の内容の分析を実施し、それぞれの埋め込み工程や原因に着目して課題の整理と特定を行い、プロジェクトの立て直しを図った。

対策概要

• 単体テストのやり直し
• 結合テスト、システムテストの不具合の傾向分析の徹底
• リリースに向けた品質担保と客観性・透明性のある報告
• 後続の開発プロジェクトへの適応

これらの対策に対してDRE（欠陥除去率）、信頼度成長曲線などの一般的な評価、不具合一覧の内容に基づく評価など、プロジェクトの立て直しにおける事実を基にした取り組みのポイントを紹介する。また、開発リーダーとして品質改善を企図した「日本地図」「３割チェック」などの具体的なマネジメント施策や、苦労した内容およびその対策効果、気付きを紹介する。

メタモデルによる設計情報定義とマルチビューを活用した
トレーサビリティ記録方式の提案

概要

ソフトウェア開発において、段階的に進む開発の一貫性を担保し、製品の品質保証や安全性確保のためにトレーサビリティ管理が広く用いられている。トレーサビリティ管理により以下のような効果が期待できる。

【効果1】設計・検証の抜け漏れ確認による不具合予防
【効果2】設計変更や不具合改修時の影響範囲特定
【効果3】安全に対する説明責任履行

トレーサビリティ管理の効果の内、特に【効果1】を最大限享受するには、設計と同時進行でトレース情報記録することが重要である。しかし、度重なる設計変更が発生する現場では、トレース情報記録にかかるコストのため、開発後にまとめてトレース情報記録しているのが実情であった。

本発表では、度重なる設計変更が発生する現場でも、設計と同時進行でトレース情報が記憶できるトレーサビリティ記録方式として、「メタモデルによる設計情報定義とマルチビューを活用したトレーサビリティ記録方式」を紹介する。本手法を適用することで、トレーサビリティ管理にかかるコストが大幅に削減され、かつ、開発終盤で設計の抜け漏れ発覚し大きな手戻り工数が発生するリスクを減らす効果が期待できる。

リモートワークでの開発を前提とした
効果的なレビュー改善手法の提案

～オンラインの弱点克服・利点活用の工夫とレビュー成功要因の関連整理～

概要

リモートワークによるソフトウェア開発が急速かつ広範囲に普及した。この働き方の急激な変化に対し、ソフトウェア開発の現場では、品質や生産性を維持していけるように、これまでのやり方を踏襲しつつ、各組織でそれぞれ工夫を凝らして対応している。しかし、ドキュメント品質の著しい低下など、リモートワークに起因すると思われる品質問題が我々の所属組織で報告され始めている。今後もリモートワークによる開発が継続するであろうことを踏まえると、この問題の解決を避けて通ることはできないと我々は考えた。そして、ソフトウェア開発の品質や生産性を高めるためのプロセスの内、対面・対人で行うことが多いソフトウェアレビューが、特にリモートワークの影響を受けやすい点に着目し、その効果的な改善方法を検討することにした。

我々が考案したリモートワークでの開発を前提とした効果的なレビュー改善手法「UnReT 法（レビュー成功要因の関連把握とTipsの活用によるレビュー改善手法）」は、以下の 2 つの特徴を持ち、先行き不透明な環境の変化にもいち早く対応して迅速に柔軟に改善活動を推進できるように工夫している。

特徴 1 ：「レビュー成功要因の関連を整理することで、改善の目的を明確にする」

特徴 2 ：「オンラインの弱点克服と利点活用の工夫を収集・活用することで、効率的に改善を進める」

簡易実験とアンケート調査により、本手法の有効性を確認できたので報告する。

DRBFMにおける一人HAZOPの活用方法の提案

概要

派生開発において、変更箇所を漏れなく特定するために、DRBFMを実施することは有効である。ただし、DRBFMを実施するときには、「心配点の抽出漏れ」「心配点の要因の見逃し」を防ぐための工夫が必要となる。
本研究では、DRBFMにおいて、欠陥混入メカニズムの知識を蓄積した辞書と、HAZOPの結果の2つを活用する方法を考案した。考案手法では、HAZOPを実施するときに、以下の考えを取り入れた。

• 複数人で分析を実施する前に、一人でHAZOPを実施する
• 図を利用する
• 30点を目指す
• 量が少ない人から報告し、同じことは報告しない

実開発において、DRBFMでHAZOPを活用した結果、「HAZOP実施者の立場・経験・知識によらず設計意図・利用意図からの“外れ”を抽出できる」「実開発において新たな心配点を抽出できる」という効果が確認できた。

アジャイル開発における欠陥検出のフロントローディングのための品質チェック方法の提案

概要

アジャイル開発において、イテレーションの中で欠陥検出のフロントローディングができれば、イテレーションの期間中に品質の高いプロダクトを開発することが可能になる。しかし、アジャイル開発における欠陥検出のフロントローディングの具体的な方法は明らかになっていない。本研究では従来のウォータフォール型の開発で行われているフロントローディングの方法に着目し、従来型の方法を応用した、アジャイル開発における欠陥検出のフロントローディングの具体的な方法を提案する。

先行研究で定義されたアジャイル開発向けの品質チェック項目から、イテレーションの初期段階または開始前に実施されるバックログ作成・バックログリファインメントに関連する品質チェック項目を抽出し、ウォータフォール型開発ではどのように品質を担保していたかを明らかにしたうえで、アジャイル開発に置き換え具体的な品質チェック方法を定義した。定義した品質チェック方法を用いて実際に欠陥の検出が可能かどうかを確認するために、過去プロジェクトの欠陥に品質チェック方法を当てはめてチェックを行った。結果として、本研究で定義した品質チェック方法をバックログ作成やバックログリファインメントのタイミングで適用することで、実装前の早期段階で欠陥を検出可能であることが分かり、アジャイル開発における欠陥検出のフロントローディングが可能になることを確認できた。

PMとQAが歩んだ越境体験によるアジャイルなチーム作りとその後のチャレンジ

概要

リクルートでは、大規模なプロダクト開発において、過去10年以上にわたり主にウォーターフォールアプローチを採用してきた。その一方、開発体制の一部では生産性の向上を目的としてアジャイル開発を採用。リーンアプローチも続けてきたが、メンバー同士の役割が大きく変化することはなかった。

結果、プロダクト開発に対する意識や理解のズレが発生し、QAメンバーのモチベーションや開発効率の低下といった事態を招いていた。

そこで昨年の発表では、新たなチーム作りにおいて「QAは固定化された役割の中で動くのではなくコミュニケーションをとりつつ全体の進捗に応じて緩やかな連携を行う」ことで、生産性の向上を図れるといった事例を紹介した。

今回は、さらに発展した取り組みをご紹介する。すなわち「QAメンバーの役割の再定義（越境）と、開発プロセスにおけるQAメンバーの立ち位置の変化だけではなくチーム全体の役割の再定義（越境）を行う」というものである。このことによりチームパフォーマンスの最大化にチャレンジしてきた。

長い間ウォーターフォール中心で取り組んできた大規模プロダクトの開発現場において、アジャイルなどの開発スタイルも取り入れてきた軌跡、さらにはパフォーマンスの担保と品質向上に向けて、チーム全体で役割の再定義に取り組み続けている事例をご紹介したい。

サービス開発初心者チームのDevOpsを用いた新サービス開発の進め方について

概要

本発表はこれまでサービス運営の経験がないチームが、自社の新サービス立ち上げにあたり、サービスリリース直後からサービス運用を問題なくできることを目標としてサービス開発に取り組んだ事例紹介となる。

DevOpsの考え方を意識してサービス開発を実施したことで、新サービス開発の目標であった、リリース直後から運用が問題なくできていることを達成できたと考えている。開発方法を自分たちなりにアレンジしすぎるのは問題もあるが、今回のサービス開発においては自分たちの状況をとらまえて、利用できるサービスマネジメントシステムを活用し、またアジャイル開発とウォーターフォールのハイブリットで進めていったことは問題ないと考えている。

サービス開発方法が今までのやり方と変わり、運用チームも巻き込んだDevOpsという考え方が今後は主流になっていくと考えられる。ただし、アジャイル開発におけるスクラムのようなわかりやすいフレームワーク（方法論）がDevOpsにおいては現状ないと考えられる。よって、DevOpsを進めたいがどこから手をつけてよいかわからないチームにおいては、今回の事例によってDevOpsを推進できるのではないかと考えている。

AIによる設計レビュー自動化への取り組み事例紹介

概要

我々のチームでは、これまで人手に頼っていたドキュメントレビューの自動化に取り組んだ。
取り組みの当初は、予め定義したチェックルールに従って設計ドキュメント記載中のキーワードを判定する仕組み(キーワード判定方式)を採用し試行を重ねた。
しかしチェックルールに従ってドキュメント記載のキーワードを判定する仕組みでは、文脈を理解した判定ではないため誤指摘が多く発生する問題を克服することが出来なかった。 

文脈も踏まえたドキュメントチェックをするために、AIアルゴリズムのBERT (Bidirectional Encoder Representations from Transformers）を採用することとした。BERTアルゴリズムで高い解析精度を得るために、従来のキーワード判定方式で指摘した結果を社内ベテラン技術者にて精査しAIへの教師データとした。

ドキュメントチェックの誤指摘率は、キーワード判定方式時は約90%であったが、BERTアルゴリズム採用時は 5%まで削減することができた。
本発表では、設計レビューでのAI活用ポイントと隘路事項について紹介する。

閉ループ制御システムに対する異常シナリオ分析のための情報検索

概要

閉ループ制御システムは、物理量の観測とアクチュエータによる制御を繰り返し、制御に対する観測の期待値と実際の観測結果の誤差の累積により、異常シナリオを引き起こす。従って該当システムで異常シナリオを識別するためには、以下の条件の組合せと順序を特定する必要がある。

• 条件1：物理量に対するセンサの観測誤差要因
• 条件2：物理量に対するアクチュエータ制御の誤差要因
• 条件3：センサが観測可能な範囲と、アクチュエータが動作可能な範囲から定まる運用条件

上記のうち、条件3（運用条件）は「観測と制御」の状態及び遷移順や物理環境の条件の無数の組合せから定まるため、設計対象システムで起こりうる条件の特定が困難である。本研究著者らの先行研究は、設計対象システムの既知の運用条件と特性情報を構造化し、得られた「故障モード導出経緯」をクエリとして過去の不具合情報を検索した。そして、検索結果から識別した運用条件と該当のクエリから異常シナリオを特定していた。

しかし、クエリが条件1や2を含まない場合、閉ループ制御システムの異常シナリオを特定する事が困難であった。

本発表では、観測と制御を物理量との因果関係で結び付けたクエリにより、過去の不具合情報を検索し、その検索結果から運用条件を識別する事により異常シナリオを特定する方法を提案する。さらに、提案手法を実システムに適用し異常シナリオを識別した実験結果を紹介する。

ニューロンカバレッジ技法を用いたAIモデル特性分析によるテスト十分性向上施策

概要

AIモデルの品質要件の一つに，様々な外乱要素に耐え得る「頑健性」がある。弊社では手書き文字を含む帳票から必要な情報を読み取りデータ化する帳票認識ソフトウェアを開発しており，本ソフトウェアが搭載するAIモデルにも高い頑健性が要求されている。

頑健性の評価手法として、効果的なメタモルフィック関係を利用してテストケースを作成するメタモルフィックテストが有効であることが報告されている。しかし、本テストにおけるテスト十分性向上およびテスト十分性評価が大きな課題となっている。

そこで本報告では、メタモルフィックテストのテスト十分性向上施策として、ニューロンカバレッジ技法を用いたAIモデルの特性分析を提案する。ニューロンカバレッジ技法とは、ニューラルネットワーク内のニューロン活性化を基準としたテストケース評価技術およびカバレッジ率を上昇させるテストケース生成技術である。弊社で開発したニューロンカバレッジツールを使用し、帳票認識ソフトウェアが搭載するAIモデルのカバレッジ率が外乱によるデータ変化に対してどのような遷移を示すか分析した(AIモデルの特性分析)。そして分析結果をもとに、メタモルフィックテストのテスト十分性向上に寄与する効果的なテストケース範囲を明確にした。

また今後検討を重ねる必要があるが、カバレッジ率を品質指標とすることでテストケースの量的/質的基準を策定でき、テスト十分性評価に繋がると考えている。

仕様書をテストベースとして理解するためのStrategy分析

概要

仕様書は正しく理解していますか。仕様書の書き方やインテグリティ（完全性）など仕様書を記述する研究や事例発表は多くありますが、仕様書の理解する方法は存在せず担当者に依存しています。また仕様書はプロダクトのリテラシーがある前提で記述されていることが多く、組織横断の品質保証やテストの担当者はプロダクトの知見が乏しい状況でも仕様を理解することが求められます。
本講演では、テストエンジニアのエキスパートが仕様書をテストベースとして理解するプロセスを形式知化した取り組みを紹介します。

『品質保証部門やレビュー担当者、テスト担当者から見た
「仕様書あるある」について語る』

モデレーター

森崎 修司 氏

名古屋大学

パネリスト

足立 久美 氏

㈱デンソー

パネリスト

柏倉 直樹 氏

㈱ディー・エヌ・エー

パネリスト

神崎 大輔 氏

富士通㈱

パネリスト

桑村 陽子 氏

日本電気㈱

パネリスト

佐々木 方規 氏

㈱ベリサーブ

パネリスト

町田 欣史 氏

㈱エヌ・ティ・ティ・データ

人間中心の創造とKMデザイン思考

概要

あらゆる場面でDX化の加速が求められている今日、企業はデータドリブンであることと同時に、人間中心の価値創造の能力獲得が求められている。日本で80年代後半から緩やかに拡がってきたデザイン思考は、創造と開発の現場が持つべき共通の思考法として、今、改めて重要視されていると認識する。
本講演では、「今なぜデザイン思考か」、「創造とは何か」、「コニカミノルタ独自に進めるデザイン思考」等について、事例を交えながらご紹介し、皆さまと考えあう一助にしたい。

DX時代の品質保証

概要

ライフサイクルを通じた品質保証のために、「開発前工程(企画、PoC)」と「開発後工程(運用・保守、継続的改善、新しい価値提案)」で、品質を作り込む。それを評価し、改善し、新しい価値を提案します。
そして、その循環を生み出す活動の枠組み（品質保証スキーム）と、品質を保証するための方法とその指標（品質保証ガイドライン）を考えて、何が必要か、なぜ必要かを提案します。

品質保証を腹落ちさせる施策の導出

概要

昨今のソフトウェア開発は、スピード優先になりつつありますが、今なお品質は、ビジネスを成功させるための重要な価値のひとつです。
ソフトウェア開発には、バグの撲滅だけでなく、多様な品質特性を満たすこと、他業界との共創・協業、さらには健全なプロジェクトを推進できる人財が期待されています。
しかし実際の開発や品質保証の現場では、「わかっているけど・・・」、「そうはいっても・・・」、「実践できない！」というつぶやきが増えているのではないでしょうか。
そこで、「品質保証部長の会」がこれまで積み上げてきた知見を活かして、多様化するソフトウェア開発の現場に、より腹落ちできるような施策が求められているのではないかと考え、今期の活動を進めてきました。
本発表では、ソフトウェア開発と同様に人に依存する要素が多い交通安全のノウハウを「わかっているけどできない」の解決に活かし、腹落ちできる施策を導いた活動の成果を紹介します。みなさまの品質保証活動の参考になれば幸いです。

品質課題を解決する自動化の勧め

～品質ガードレールのその先へ～

概要

ソフトウェア品質保証における“自動化”というと、ソフトウェアテストの自動化が真っ先に検討されると思われます。しかしソフトウェアテストは品質保証活動における取り組みの一つでありテストの自動化による効果も、効率化やコスト適正化などピンポイントな結果になる傾向があると思われます。
そこで本活動では、視点を広げてソフトウェア開発およびその後のシステム運用をスコープとした品質保証活動全体の自動化とその効果について議論を進めて参りました。
今期はコンセプやアウトライン段階の提案になっていますが、これをきっかけに皆さまと一緒に品質保証活動の自動化について意見交換できれば幸いです。

ゲームを使った人財育成

概要

高い品質保証スキルを持ったベテランQAの知識を伝承する際、マニュアル、観点表やチェックリストなど形式知としての伝承が行われています。
しかし、ベテランQAが過去の失敗や大規模障害といった実際の経験から得た知識は非常に有用性が高いにも関わらず、形式知化することが困難で多くの企業で課題となっています。
私たちは、現在教育分野で注目されているゲーミフィケーションが知識の伝承に活用できるのではないかと考え、現実世界では許されない失敗や、若年層が経験できない大きな成功体験をゲームの世界で経験し、思考の過程やベテランを交えた振り返りの場を通じて得た体感（身体知）が、効果的な人財育成に繋げるための工夫点について検討を行いましたので、本発表にてご紹介致します。

クオリティトーク

～ソフトウェア危機はなぜ起こるか、私たちに求められていることは何か～

メンバー

飯泉 紀子 氏

㈱日立ハイテク

メンバー

大場 みち子 氏

公立はこだて未来大学

メンバー

小島 嘉津江 氏

富士通㈱

メンバー

誉田 直美 氏

㈱イデソン

メンバー

森田 純恵 氏

㈱富士通ゼネラル