１.はじめに

DX（Digital Transformation）とは、 経済産業省「DX 推進指標」(注1）より、「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に製品やサービス、ビジネスモデルを変革するとともに、業務そのものや組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」と定義されている。

すなわち、DXは、顧客や社会への新たな価値創出が求められ、価値に対する品質も従来の当たり前品質(注2）からライフサイクル全般で顧客等に価値のある一元的品質(注2）、満足度を上回る魅力的品質(注2）に移行している。これらの品質を満たすには、基本的な品質技術・技法の組合せ活用が重要である。本稿ではDX推進に役立つ基本的な取り組みやソフトウェアの品質技術を述べる。

2. DXプロセスでの基本的な取り組み

2.1 プロセスのケース

事業会社におけるケースを述べる。 DX の定義から「全体構想策定」を実施の上で、並行的に、「ビジネスモデル変革」、「既存業務見直・既存システム近代化」のフェーズを実施する。

（1）全体構想策定フェーズ
経営層、事業部門、IT 部門等で体制を構築し、ビジョン策定、現状分析、将来のあるべき姿作成、課題抽出、PoC（Proof of Concept：概念実証）による導入可能性検証、要求定義等を行う。

（2）ビジネスモデル変革フェーズ

事業部門が取引先等ステークホルダー間とのビジネスシステム・課金モデル構築やサービス開発を行う。またIT 部門は、事業部門のサービス開発を支えるためにデジタルプラットフォーム構築やマイクロサービス開発・改修等を行う。

（3）既存業務見直し・既存システム近代化フェーズ

事業部門がビジネスモデル変革に合わせて、既存業務標準化及び見直しを行う。またIT 部門はレガシーシステムである既存システムの近代化を行う。

2.2 基本的な取り組み

（1）気軽に会話できる環境づくり

全体構想策定等の初期フェーズでは、事業部門は先端デジタル技術やそれがもたらす価値の知見はないことが多い。結果、将来のあるべき姿の議論では既存業務改善／既存システム改修レベルに終始することもある。そのため事業部門がIT部門に気軽に相談でき、デジタル技術等を理解すること、アイデアを創出すること等の環境づくりが重要である。

（2） DX の取り組みの認知度が上がる仕組みづくり

顧客等動向を熟知した事業部門が主体的にDXを推進する。しかし、ビジネスモデル変革や業務見直しは、ゴールが見えない中で、ステークホルダー間の横断的な利害調整が多く、モチベーションが下がることがある。そのため、DXの取り組みが社内報等で会社全体に認知されること、評価に繋がる等でモチベーション向上に繋がること等の仕組みづくりが重要である。

（3）目的が明確なところから進める

データは宝の山といわれるように、一般的にビジネスに関係する情報は何でもデータ化したいと考えがちである。しかしサービスにとって必要なデータが見つかりにくいこと、サービスには重要でないデータの保守で他の重要なデータが利活用できないこと等の本末転倒な結果になることがある。そのため、データの利活用シーンを5W1Hで分析して、目的が明確なところから進めることが重要である。

3. フェーズ毎のソフトウェアの品質技術

主に品質作り込みの観点で、フェーズ毎のソフトウェアの品質技術を述べる（図1-1、 図1-2、図1-3）

3.1 全体構想策定フェーズ

将来のあるべき姿の作成で、企業にかかるステークホルダー識別、ステークホルダー間価値分析が重要である。これら技法は複数あるが、効果的に漏れなく抽出できる以下の2つの技法を述べる。

（1）REBOK のオニオンモデル(注3）（図2）

REBOK（Requirements Engineering Body Of Knowledge）とは、アールイーボックと呼ばれ、要求工学知識体系であり、要求工学を理解し、活用するための手引きとなる要求工学の知識を実践の視点から整理し、体系化したものである。オニオンモデルとはREBOK の要求獲得技術のステークホルダー識別を行うための技法である。これは楕円の中心に実現するソフトウェアを置き、中心から外側に向けて影響を与えるステークホルダーを可視化する。この楕円の中心にサービスや製品を置いて活用することもできる。

（2）顧客価値連鎖分析(注4）

顧客価値連鎖分析とは、実現するサービスや製品に対する真の顧客を特定するために、全てのステークホルダーを洗い出し、ステークホルダー間のお金や情報（サービス、ルール等含む）のやり取りを整理することで、どのような価値が誰から誰に提供されているかを可視化する技法である。

3.2 ビジネスモデル変革フェーズ

（1）システム・アーキテクチャの分析(注5）

ステークホルダーの要求から要件定義を行い、サービス開発を行う。要件定義からサービス開発（機能開発）を行うために、開発すべき機能を漏れなく抽出できる技法にシステム・アーキテクチャ分析がある。これは要件定義された機能を「モノをパーツ」、「処理を時間軸」等で分解し、それぞれ分解した機能に実現する手段を明確に定義する技法である。

（2）XP（テスト駆動開発等）(注2）
新規サービス開発では、システム・アーキテクチャ分析後に将来のあるべき姿に向けて、小さなサービス単位（機能単位）で開発・リリース・改修を行う。その際に小さいサービス単位で開発していくアジャイル型で開発を行う。アジャイル型開発手法は複数あるが、その中でも品質を作り込む思想が最も反映されているXP（Extreme Programming）の以下3つの技法を述べる。

① テスト駆動開発(注2）

テスト駆動開発は、必要なコードのみを記述する観点から、最初にテストをするためのテストコードを記述し、次にアプリケーションコードを記述する。そして、アプリケーションコードを完成させる過程でテストを繰り返し実行し、そのテストを通過するとアプリケーションコードを洗練するリファクタリングを行う。この技法はリファクタリングにより適切な抽象度でアプリケーションコードが記述でき保守性が向上する。またテストコードは何度も使えるため、日々ソースコードを改修してリリースするような継続的デリバリ環境で効果が発揮できる。

② リファクタリング(注2）
リファクタリングとは、顧客からのサービスの振る舞いを保ちつつ、ソフトウェアの保守性（理解や修正のしやすさ）を向上させるために、ソフトウェア内部構造を変化させることである。例えば、多くの不要コメント、重複・類似コード（コードクローン）、巨大なクラス構造、長すぎるメソッド構造、条件分岐が多く複雑なコード等が含まれたソフトウェアがリファクタリングの対象となる。

③ ペアプログラミング(注2）

ペアプログラミングとは、1つのプログラムを2人で開発する技法で、1人がプログラムソースコードを書いている間にもう1人がコードチェックしてコードを洗練する。品質作り込みのほかに、開発ナレッジやスキルを共有でき、属人化を防止できる。なお、ペアプログラミングの生産性は2人が別々にプログラミングを行う場合に比べて15％程度しか低下しないという研究結果も報告されており、多くの場合には単純に2倍の工数を要するわけではない。

（3）データ品質の向上
サービスでのデータ利活用の際に、利用しやすいような利用時の品質の向上が重要である。その際に効果的な以下2つの技法を述べる。

① データ品質モデル特性の活用

デジタルプラットフォームに収集するデータは、以下の問題がある場合がある（表1）。

そのため、サービス開発時に、ISO/IEC 25010の「データ品質モデル特性(注2）」、政府IT 総合戦略室「データ品質管理ガイドブック(注6）」、総務省「統計表における機械判読可能なデータ作成に関する表記方法(注7）」等を参考にしてこれらデータの補正や名寄せ等を行うほか、サービスリリース後のデータ運用の仕組みも構築する。

② データカタログの整備(注8）

データカタログとは、データの所在地や内容等を明確にし、データの理解や発見を容易化するものである。これにより、利用者が必要とするデータを必要な時に取得できるようになる。エコシステム全体でデータの存在をより広く認知してもらうためにはデータカタログ項目の共通フォーマットを設けることが重要である。共通フォーマットを用いることでエコシステムのステークホルダーのデータカタログとのデータカタログ情報の連携が容易になり、データの存在の認知度が上がる。

3.3 既存業務見直し・既存システム近代化フェーズ

（1）データアーキテクチャの再設計
既存システムの近代化では、業務標準化と合わせてパッケージ（クラウドサービス）利用化、また業務見直しと合わせて保守性向上等を行う。後者に関して、その中核であるデータベースは「1つの事実は1つの場所に」という思想で設計されたものが多く、複数システムがスパゲティ状に絡み合った形で密結合されている。これは中央集権的データ統治を必要としたホストコンピューター時代には適したが、現代では保守性に問題がある。そのため、現状及び将来のあるべき姿における業務やステークホルダーと照合し、「どこにどのようなデータを配置して、これをどのような経路で、どのようなタイミングで、利用者に届けるか」を再設計すべきである。要は、業務でデータ一貫性を必ず必要とするタイミングを見極め、それに基づいて設計する適度な疎結合により保守性を向上させる。

（2）テスト技法

品質を確認するシステムテストでステークホルダーの要求事項を100％網羅することは困難である。リスクの大きい事象に対する不具合有無の確認や不具合検出に効果的な以下2つのテスト技法を述べる。これら技法は他フェーズでのシステムテスト等でも活用できる。

① リスクベースドテスト(注2）

リスクベースドテストとは、ソフトウェアがサービスに影響する不具合を起こしそうな状況を想定し、それら不具合が実際に発生するか否かを確認するテスト技法である。リスク分析に基づいてリスクが大きいものから優先的にテストができる。

② 少ない因子の組合せテスト(注2） 組合せテストとは、テスト条件（因子、水準）の組合せを決定するためのテスト技法である。ここで因子とはテスト対象の項目、水準とは項目が取り得る値のことをいう。ソフトウェアの不具合の多くは、因子数が2つのような少ない因子数組合せで発生している研究報告もある。これは直交表等を用いる

4. 品質確保のための現状の課題

4.1 第三者プラットフォーム選定方法確立

導入スピードの速さや拡張性が高い点で、DXではクラウドサービス等の第三者プラットフォームの利用は不可欠である。しかし、品質保証の方法が確立されていないため利用にはリスクがあり、これらサービスの選定方法確立が課題である。例えば、現状のクラウドサービス利用時には「政府情報システムにおけるクラウドサービスの利用に係る基本方針」(注9）等を参考にして、「稼働実績」、「事業継続性」、「セキュリティ対応」、「法制度・規格等への対応」等の情報から事業リスクが最小になると判断できるクラウドサービスを選定するケースが多い。

4.2 顧客等ライフサイクル全般での価値提供

サービスをリリースしたら、顧客に価値を提供し続けているかの状況をモニタリングして、改善等通じて継続的に価値を提供することが必要である。そのため、サービスレベル指標、顧客利用時品質評価指標等のKPI（Key Performance Indicator）を設定して、顧客ライフサイクル全般で継続的な価値提供を保証する仕組みの確立が課題である。