DXと従来のシステム開発は何が違う？ 開発工程で知っておくべきことをまとめてみた：デジタル変革のメソッド どこから挑む？ どこから変える？（1/2 ページ）

DXプロジェクトで開発するシステムは、業務の効率化を目指す従来のシステムとは役割や位置付けが異なるため、その開発も異なるアプローチが必要だ。どのようなことに気を付けるべきか。

[池田昭規，豆蔵]

この連載について

　本連載では、DXとは「デジタル時代に有効な事業経営、企業経営へ変革して、かつ変革し続けること」であると定義している。過去4回の記事では、デジタル変革（DX）は何のために必要であるのか、目的、戦略やビジネスモデルの変化などのデジタル変革の全体感とその意義について事例を交え解説してきた。以降の連載では、DXを実現するために必要な人材育成やプロジェクト管理、システム構築などの具体的施策の進め方について解説する。

筆者紹介：池田昭規（いけだ あきのり） 豆蔵 デジタル戦略支援事業部 シニアコンサルタント

大学時代はバイオテクノロジー系の学部で白衣を着て実験に明け暮れていたが、隣の研究室で行われていたコンピュータによるゲノム解析に心を奪われ、ITの世界へ。

これまで、金融、製造、医療、通信、官公庁、コンテンツおよびプロダクト開発などさまざまな業種のシステム開発に参画。オブジェクト指向設計およびプログラミング、ネットワーク技術、アジャイル開発、友人とのスタートアップ企業設立などの経験を踏まえ、豆蔵の各プロジェクトにパートナーとして参画、後に入社。複数のデータ基盤構築やアジャイル開発関連のプロジェクトへのコンサルティング、プロダクトマネジメントのコーチングを並行して実施中。

　6回目となる本稿のテーマは、デジタルトランスフォーメーション（DX）に必要なシステムの開発と運用だ。

　DXにおいて構築するシステムは、業務の効率化を目指す従来のシステムとは役割や位置付けが異なるため、開発工程や運用も異なるアプローチが必要になる。本稿では、特にデータ利活用基盤の開発上流工程で「どのようなことを考え、実施すべきか」を解説する。

要件定義だけでは不十分、開発の前に必ず決めるべきこと

　DXについて触れる前に、要求開発について説明する。従来のシステム開発は要件定義フェーズから始まることがほとんどだが、これは「何を作るのかが正確に決まっている」という前提ありきだ。前提を明確にしておくことは、システム化の範囲を明確にするためにも必要だ。

　要件定義とは、「ビジネスとして成し遂げたい事柄の一部をシステムで実現するための手段を定義すること」であり、成し遂げたい事柄（＝ビジネス要求）の定義はしない。しかし、作ろうとしているシステムが本当にビジネス要求に応えられているのかを判断するためには、「何に使われるのか」「どのように使われるのか」「誰に使用されるのか」などといったビジネス要求を明確にすることが必要だ。「〜がやりたい」という要求があってはじめて、「〜が必要」の要件定義ができると言える。

　要求を明確にする活動は要求定義と呼ばれていることが多い。しかし、要求開発は「要求は、突然出現するものでは無く、ロジカルに開発されるべきである」という考えにおいて、要求定義とは異なる。

図1　要望から要求、要件へ（出典：豆蔵の提供資料）

　要求開発を実践していた「要求開発アライアンス」は残念ながら活動を休止しているが、活動内容については、『「正しくない要求に正しく応えるのはもうやめよう」要求開発アライアンスが発足』に記載があるので参考にしてほしい。

DXと従来のシステム開発との違い

　基幹システムを例にとって考えてみよう。基幹システムは既存業務の効率化などを目的として構築されるため、その開発や刷新などにおいては、既に業務フローが存在していることがほとんどだ。開発時は、「なぜ開発するのか（さらなる効率化や改善、追加機能など）」といったビジネス要求が明確になれば、その後は通常のシステム開発としてプロジェクトを進められる。

　一方、DXプロジェクトで開発するシステムはこれとは様相が異なる。データ基盤システムの機能としてよく挙げられる「データの蓄積」はビジネス要求ではなく、DWH（データウェアハウス）やデータレイクの構築も当然ビジネス要求とは違う。

　BIツールでデータを見たいという要求はHOWであり、ビジネス要求ではない。「何をしたい」から、データを蓄積してBIツールでデータを見ることを欲しているのか――ビジネス要求では、それにきちんと答える必要がある。

　一方、RPA（Robotic Process Automation）やAI（人工知能)を使った業務改善はDXの一部であるデジタル化にすぎない。DXの本丸は改革、変革ともいうべき「新規事業開発と継続」にある。そのビジネス要求を支えるHOWとしてのシステムを明確にした上で、その実現要素としてRPAやAIを位置付け直す必要があるということだ。

企画構想とビジネス要求の明確化、仮説実証としてのPoC

　DXにおいては「何をしたいのか。何のためにシステムを開発するのか」を明確にすることが不可欠だ。本連載の初回で紹介した「WHY」「HOW」「WHAT」をビジネス要求として捉えてみよう。開発すべきシステムは、「ビジネス要求に対してシステムで実現できる事柄を作り上げ、ビジネスに貢献する」ことが責務となる。

　そのために、図2に示すような内容を持った企画構想をビジネスとシステムの両サイドが協力して作成し、進めることが重要だ。これは、システム開発という視点ではなく、新規事業開発企画を一緒に作り上げるという言い方がマッチしている。その上で、システム化に向けた方針などを考えることになる。

図2　基本構想目次例（出典：豆蔵の提供資料）

　この企画構想（筆者が実際のプロジェクトで作成した、豆蔵オリジナルのもの）を基にしたプロジェクトは、本当にこのまま進めて良いのだろうか。今後、想定と違う事象が起こる可能性を考えて、大規模な開発フェーズに移る前に企画構想を仮説としたPoC（概念実証）の実施を強くお勧めする。PoCによって、企画構想をよりブラッシュアップでき、ビジネス要求やシステム化の範囲もさらに明確になる。

　ただ、PoCを何度も繰り返すことによる「PoC疲れ」に陥らないよう、具体的な検証ゴールとその終了条件を関係者で共有することが望ましい。

　DXでのシステム構築と言えば、「データ利活用基盤」と呼ばれる構成が思い浮かぶ。大量かつ多岐にわたるデータを分析するために、「必要な情報を必要なときに必要な形式で取り出せる」データ処理システムだ。ETL（ELT）やDWH、データレイク、データマート、BIツールなどで構成されるが、ここでは構成要素にはふれず、概念として考えてみる。

　これまでの一般的なシステム開発は最適化や効率化などを目指すことが多く、2015年のGartnerが提唱したバイモーダルITベースで考えると、モード1のシステムに対する改善の視点とその能力（オーディナリティケイパビリティ）が求められてきた。

　しかし、変革という能力（ダイナミックケイパビリティ）を必要とするDXにおいて、データ利活用基盤は変革構想を支える要素であり、常に刷新を求められ続けるモード2のシステムだ。モード1と比較して、戦略や人材などさまざまな観点で違いを考える必要があるが、特に開発プロセスとスピード感、組織構造、システムに求められているケイパビリティの違いなどに気を付けることが重要だ。