１.前言

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 制定整体构想阶段

在整理分析未来的理想状态时，识别企业的利害相关方、进行利害相关方间的价值分析是很重要的。方法有很多，下面介绍的是两个较有效的能毫无遗漏地提取出所有要素的方法。

（1）REBOK の洋葱模型(注3）（图2）

REBOK（Requirements Engineering Body Of Knowledge）读作R-E-BOK，是一种需求工程知识体系，将为了理解和活用需求工程所必需的需求工程的知识，从实践出发进行整理，形成体系化的方法。洋葱模型就是一种获取REBOK 的需求，识别利害相关方的一种技术方法。将实现的软件摆在椭圆的中心，从中心向外将会产生影响的利害相关方可视化。也可以灵活变通，将服务或产品放置在椭圆的中心。

（2）顾客价值连锁分析(注4）

顾客价值连锁分析，是为了锁定服务和产品所针对的真实顾客群，将全部全利害相关方梳理出来，将利害相关方之间的金钱、信息（包含服务、规则等）的往来进行整理，把谁向谁提供了何种价值这一点明确可视化的一种技术方法。

3.2 商业模式变革阶段

（1）系统架构的分析(注5）

从利害相关方的需求出发定义出要件，进行服务开发。基于要件定义进行服务开发（功能开发），为此可以使用系统架构分析法，能够毫无遗漏地提取应开发的功能。即把被要件定义过的功能按照“物按照组成部分”、“处理作业按照时间轴”等的标准进行分解，然后分别定义分解后的各个功能的实现手段。

（2）XP（测试驱动开发等）(注2）
在新服务的开发过程中，为了实现系统架构分析后的未来理想状态，按照较小的服务单位（功能单位）进行开发、投放及修改。此时可以进行针对小服务单位开发的敏捷型开发。敏捷型开发手法有很多，这里从中抽取了以下3种最能够体现打造品质方面要求的XP（Extreme Programming）的方法进行介绍。

① 测试驱动开发(注2）

测试驱动开发是从仅记述必需的代码这一观点出发，最初记述测试所需的代码，然后记述应用程序代码。在完成应用程序代码的过程中不断重复测试，测试通过后再进行提炼应用程序代码的重构。此种方法使得应用程序代码的记述抽象的恰到好处，运维时候也比较好操作。而且，测试代码可以重复多次利用，在每天都要修改源代码再行投放的那种重复交付环境下可以发挥更大的效果。

② 重构(注2）
重构就是为了保持来自顾客的服务行为的同时，提升软件的可维护性（易于理解和修改），改变软件的内部结构。例如，很多并不需要的备注、重复/相似代码（代码克隆）、庞大的类结构、冗长的method构造、包含这些条件分支较多的复杂代码等的软件都需要进行重构。

③ 结对编程(注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）测试技法

在确认品质的系统测试中将利害相关方的需求事项一网打尽是十分困难的。对风险较大的故障现象，为了确认其不良状态的有无以及检出不良状态，下文介绍两种有效的测试技法。这些技法也可以应用在其他阶段的系统测试等。

① 基于风险的测试(注2）

基于风险的测试是指，假设软件影响了服务可能引起不良状态的情形，用测试来确认这些不良状态实际是否会发生。基于风险分析的思路，可以优先从风险较大的情形开始测试。

② 较少因子的组合测试(注2） 组合测试，是指为了决定测试条件（因子、水准）的组合搭配的测试方法。这里的因子是指测试对象的项目、水准是指项目可能取得的值。有研究报道说，软件发生故障时，大多数是2个因子等较少因子的组合引起的。这里会用到直交表等。

4. 品质保证相关的目前课题

4.1 确定第三方平台的选定方法

在实现快速导入和高扩张性方面，云服务等的第三方平台在DX推进中必不可少。但是，因为没有建立品质保证方法，这些平台的使用就会存在风险，如何确定这些服务的选定方法就成为面临的课题。例如，在利用目前的云服务时，参考“政府信息系统的云服务使用相关的基本方针”(注9）等，从“运行实绩”、“事业可持续性”、“安全应对”、“法制度・规格等的应对”等信息出发，选择能够判断出事业风险最小的云服务的案例较多。

4.2 向顾客等提供全生命周期的价值

一旦服务上线，就需要监控是否有在持续向顾客提供价值，并通过改善措施等持续提供价值。为此，设定服务水平指标、顾客利用服务时的品质评价指标等的KPI（Key Performance Indicator），建立能够保证持续提供顾客全生命周期价值的体系就成为所面临的课题。