データ中心型ビジネスアプローチ（DxBA 通称DOBA)が日本のITを救う！
以下は、3月に日経クロステックに掲載された記事の元原稿を校正したものになります。第一回目分になります。実際掲載された記事とは内容がたいぶ異なります。
私が最近提唱しているデータ中心型ビジネスアプローチ(DxBA 通称DOBA)についての説明になります。
☆DOBA（データ中心型ビジネスアプローチ）とは
「データ経営が日本を変える！」https://juas.or.jp/library/research_rpt/various/#dataでは以下の通りDOA及びDOBAを説明している。
「DOA とは、Data Oriented Approach(データ中心アプローチ)の略であり、業務システムの設計手法の一つで、システムの扱うデータの構造や関係を定義し、それに合わせて処理や手順の流れを決めていく方式である。」
「DOBA とはData Oriented Business Approach、つまりビジネス視点においてデータ中心指向で考えることを指し、DOCA とはData Oriented Computing Approach、つまりコンピューター視点においてデータ中心指向で考えることを指す。
従来、巷間で唱えられてきたDOA とは、システム開発の方法論としてのDOCA であり、システムのビジネス・経営に対する価値が飛躍的に高まってきた今日において、経営に対し重要な要素となるData とBusiness の関係を再定義したDOBA の重要性を改めて認識する必要がある。」
今、そしてこれからやるべきはDOBAであり、実践するためにはEA、エンタープライズアーキテクチャにおけるBA、ビジネス（業務）体系の構築からデータ中心で行うことが一番の近道になる。
エンタープライズアーキテクチャとは企業全体のシステム設計図のことである。システム設計というと実装に関する設計、というイメージが強いが、そもそもシステムとはビジネスとIT、そしてその関係を繋ぐデータで成り立っており、システム設計とはその全てを設計することである。
「システム設計」とは、「ビジネス／業務設計」と「IT設計」から成り立つといってもよい。
EAといえば、一般的に有名なのは4層の三角形を描いた図だろう。興味がなくても一度は目にしたことがあるかもしれない。
EAは上図のように4層で構成される。
BAとは、ビジネス、業務の設計思想、および、基本構造、体系を表す。日本語ではビジネス（業務）体系と呼ぶ。
DAとは、データの設計思想、および、基本構造、体系を表す。データ体系と呼ぶ。
AAとはアプリケーションの設計思想、及び基本構造を表す。適用処理体系と呼ぶ。
TAとはIT基盤の設計思想及び基本構造を表す。技術体系と呼ぶ。
対象となるのは前述したとおり、企業のシステム全てである。マーケティング用語ではSORと称されるエンタープライズ系システム（基幹系システムといってもよいかもしれない）、SOEと称されるコンシューマー向けシステム、全てが対象となる。またそれぞれはERP、ノーコード／ローコード、SaaSサービス、スクラッチ開発等により開発される。スクラッチ開発においてもウオーターフォール型開発されたシステム、アジャイル型開発されたシステムがある。これら多様なシステムを継続的に全て体系化していく。一過性で終わるのではなく継続性が重要である。EAは企業が存続する限り体系化し続けなければならない。
図3 EAは全てのシステム設計を継続的に体系化する
EAでは、最上層にBA、ビジネスアーキテクチャがどんと鎮座している。(以下、BAもしくはビジネス（業務）体系と称す）
ビジネスと業務という言葉は、ここでは同一のものとみなしている。個人的にはビジネスというと経営に近く、業務というともう少し現場寄りというイメージがあるが、そういった議論はここでは取り上げても意味ないので、同一のものと見做すこととする。
☆ビジネス（業務）≠プロセス
勘違いしている人がいるので説明しておきたい。
ビジネス（業務）とはビジネス（業務）プロセスだけのことではない。
企業は、なんらかのリソース(資源）を最大限用いてイベント（出来事）活動を行っていく。
つまりなんらかのリソースを表すデータを基盤として作った上でイベントを表すデータを生み出す行為の連鎖がビジネスであり業務である。ビジネス（業務）とはITを用いるかどうかを問わずデータとプロセスの組み合わせで成り立っているのである。とはいえ昨今はITを用いないシステムはほぼない。そうである以上、尚更この考え方を基本としないといけない。
ビジネス（業務）プロセス以上に取り扱うビジネス（業務）データに着目しなくてはいけないはずだ。
BPRという言葉が昔流行った。日本ではそのままカタカナでビジネスプロセスリエンジニアリングと称した。
この言葉が独り歩きしてビジネス（業務）＝プロセスと考える人が多くなってしまったように思える。つまりプロセスをなんとかすればビジネス創出、改革ができると勘違いしたのである。
間違ってほしくないのだがBPRはあくまで改善を目指すものである。プロセスだけいじっても改革はできない。
同様にビジネスを創出することはできない。DXも同様だ。ビジネスはプロセスだけでは成り立っていない。
冒頭でも紹介した通り、JUASより「データ経営が日本を変える！」という書籍を出版した。筆者も執筆陣に加えていただいた。
JUAS Webサイトより無料で全文Pdfにてダウンロード可能である。
https://juas.or.jp/library/research_rpt/various/#data
Amazon Kindle版でも読める。
https://www.amazon.co.jp/dp/B0BB2D9B5X
データが重要とか、なんだいいつつもプロセス指向から抜け切れない日本の今の状況に危機感を覚えた有志が約5年議論を重ねた結果だ。是非ご一読願いたい。
ビジネスをデータ指向で捉えていないこと！
これが日本のIT、いや日本が抱える大問題だ。なんとかしなくてはいけない。
解決策としてBAの構築からデータ中心で行うDOBAの実践を提案したい。
その際に作成する４つの図について説明する。
☆４つの図
筆者は、BAを構築するにあたり、ビジョン、目的、方向性等を明らかにした上で、まずイメージするビジネスをわかりやすく図式化するのが良いと考えている。文章でずらずら書いても誰も読んではくれない。新ビジネスが新ECサイト構築等の顧客接点が重視されるようなものであれば、カスタマージャーニーマップのようなものでもよい。ユーザーシナリオを図式化したものでもよいかもしれない。とにかくビジネスイメージをポンチ絵でもいいので書いてみる。そして議論し、書き直す。なので、実際に手を動かして書く人以外に関係者をなるべくたくさん集めてわいわいやる。一度に集めるのが無理なら複数回やる。
そして皆の合意をポンチ絵に落とし込んでいく。このポンチ絵は複数枚になってもよい。
一旦ポンチ絵ができたら、少し頭の中を切り替えよう。このポンチ絵からビジネスの構成要素であるデータ、プロセスに関するものを切り出す。まず、ビジネスで必要と思われるデータをなんらかの図式に写像する。そしてプロセスも同様に。そしてその関係性まで確認可能な図式を作成する。
この4点の図を作成するところまでがDOBAを実践する際にBAでやるべきことになる。
上記、ビジネス（業務）モデルとしてのポンチ絵を「ビジネス（業務）鳥瞰図」、データに関する図式を「ビジネス（業務）地図」、プロセスに関する図式を「ビジネス（業務）航路図」、データとプロセスの関係性を表す図式を「ビジネス（業務）行動図」と呼ぶ。
この4つの図式をけんけんがくがく議論しながら仕上げていくのである。
以下にそれぞれの４つの図を定義する。
●ビジネス（業務）鳥瞰図
ポンチ絵でもいいのでビジネスの全体像をつかむために書く、ビジョン、目的、方向性がわかるように。この時点で明確な制約、前提があれば書き出しておく。ITシステムに落とし込む、つまり実装に繋げることはないため、形式に囚われる必要はない。無理に1枚にまとめる必要はない。
●ビジネス（業務）地図
ビジネス、業務により最大の価値を生み出すビジネス、業務のあり方を書く
●ビジネス（業務）航路図
ビジネス地図を最適に巡ることにより効果を出す航路を示すためにビジネス、業務の流れを書く。
●ビジネス（業務）行動図
ビジネス地図のある地点で実践すべき行為、つまり「ビジネス（業務）地図」と「ビジネス（業務）航路図」の関係性を表すために書く。
以下に4つの図の関係と作成手順を示す。
筆者の場合、「ビジネス地図」は「概念データモデル」、「ビジネス航路図」は「業務フロー図」及びユーザーシナリオ、「ビジネス行動図」は（概念レベルの）「CRUDマトリクス」で書く。
これ以外であってもBAをこの4つの視点で体系化できればどんな書き方でもよい。
図式作成にあたり、留意点がいくつかある。
一つめは、わかりやすさだ。ビジネス（業務)には複数の立場が異なる人が関わる。ITに詳しくない人含めて関係者にとってわかりやすい表現である必要がある。わからないものはすぐに興味を失ってしまう。
つまり「わかりやすいこと」を最優先にする。それも立場が違う人同士であっても。
二つめは、外部の力を借りてもいいが、「自分等で書く」ことだ。
ビジネスモデルを外部のコンサルタントにまとめてもらって、それをそのままシステム化しようとする人がいるがやめた方がいい。あくまで自分達のビジネスである。例え素晴らしい提案をもらおうが自分達の手で書き直してみた方がいい。綺麗なスライドより試行錯誤して手書きでくしゃくしゃに書いたポンチ絵の方がよっぽど価値がある。
それ以外にも
・プロジェクト単位ではなく全社で書き方は統一する。
・ビジネス用語で書く。（IT用語禁止？）
・書いては消してを繰り返し行える。試行錯誤を許容する。
・なんらかの実装手段への転換を可能とする。
（「ビジネス鳥瞰図」以外の３つについては記法になんらかのルールが必要）
・最小の労力で最大の効果を生む。
ことに留意とする。
これをまずプロジェクト単位で書いていくことになる。その際は、全体との整合性を意識しつつ範囲、外部（他システム含む）接続有無は明確にすること。スコープが定まる。
間違ってほしくないのは、DOBAは開発手法でも記法でもない、ということだ。決して一神教にならない。八百万の神が宿る日本ならではのデータ中心指向の考え方だ。様々な手法、記法を包含する。つまり書き方はなんでもよいということだ。上記はあくまでDOBAを実践するための一つの方法にすぎない。
そして・・・もちろんDX実践においても有効であることはいうまでもない。
この記事が気に入ったらサポートをしてみませんか？