35分でわかる『DX時代を勝ち抜くシステム設計』とは！
～超上流工程ゼロから実装に繋ぐための処方箋～

2023年9月28日
ITエンジニア／コンサルタント
赤 俊哉
E-mail:toshiya.seki28496@gmail.com
Facebook・Linkedin・X
1

自己紹介
元ホームレス寸前から下請けプログラマー、SEとしてIT業界の最下層に入る。
ベンダー企業のSE/プログラマー、ユーザー企業システム担当、利用部門といったあらゆる立場からIT／情報システムに関わってきたのが強みの“叩き上げ”ITエンジニア／コンサルタントとして現在に至る。
様々な悲惨な？経験から上流工程の重要性について痛感するようになる。
さらにデータ中心でビジネス、システムを作り上げていくことが低迷する日本のIT復活の処方箋であると考えるようになる。
趣味？は末っ子のましゅー（８歳オス）との散歩。生まれ変わったとしても情報システムにかかわる仕事をしたいと考えている。
2

著作について• 著書：「SE職場の真実」（日経BP）、「どんづまりから見上げた空」（日経xTECH）「システム設計のセオリー」「要件定義のセオリー」 （リックテレコム）• 共著：「データ経営が日本を変える！」（JUAS出版）「システム設計のセオリーⅡ－クラウドベース開発」（リックテレコム） 新刊
3

執筆記事
・日経ｘTECH 「どんづまりのSE職場を今度こそ変える、データに着目して設計する4点の図！」
 https://xtech.nikkei.com/atcl/nxt/column/18/01195/022700084/

 「システム開発成功の鍵は「熱量」と「ワクワク感」、ショービジネスを見習おう」
 https://xtech.nikkei.com/atcl/nxt/column/18/01195/032700086/

4

取材記事
・日経ｘTECH＋日経コンピュータ
 「IT部門は事業創出を支援できる 試行錯誤してモデルを描こう」
 https://xtech.nikkei.com/atcl/nxt/mag/nc /18/020900021/112500126/

・JIIMA(公益社団法人日本文書情報マネジメント協会）

機関誌IM2023年7・８月号
 https://www.jiima.or.jp/im/im2023index/

5「システム設計のセオリーⅡ－クラウドベース開発」に関する記事について
・日経ｘTECH + 日経コンピュータ 「業務やUIからITインフラまで 広がり過ぎた「設計」に挑む」
 https://xtech.nikkei.com/atcl/nxt/mag/nc/18/020900021/071900143/

6

講座について・ｓｃｈｏｏ 「要件定義のセオリー DX時代に成功するシステム開発の要点」（全4回）
 https://schoo.jp/course/7578

7

講座についての紹介記事
・ｓｃｈｏｏさんに「要件定義のセオリー DX時代に成功するシステム開発の要点」の紹介とともに要件定義そのものについての解説を記事にしていただきました！
 「要件定義とは？基本のプロセスと構成要素・ポイントについて解説」
 https://schoo.jp/matome/article/1699

8

Agenda１．クラウドベース開発におけるシステム設計とは
２．本質は変わらない
・データ設計・プロセス設計
・データ×プロセスの関係性設計（CRUD設計）)
3．さらに超上流工程へ

9

Agenda１．クラウドベース開発におけるシステム設計とは
２．本質は変わらない
・データ設計・プロセス設計
・データ×プロセス設計（CRUD設計）
3．さらに超上流工程へ

10

システム設計（というよりセオリーシリーズ全般）の基本方針

システム開発を成功させるために
・ 「最小の労力で、最大の効果を実現する」
・ 「成果物は、より少なく、しかしより良く」ことを目指す！
11

システム開発は方向性によりアプローチは異なる！

• ToBe(あるべき姿）指向か• AsIs（今ある姿）指向か 「改革／DX」と「改善」ではアプローチは異なる
 “システム設計のセオリー”はどちらにも対応可能

12

ToBeとAsIsにおける要件定義、そして設計へ• 改革／DX
 ①目指すべき理想のToBeを考え抜き、「要求」としてまとめる
 ②AsIs 分析を通じて現状,制約、前提を加味する
 ③実現を目指すための新しいToBeを作成し、「要件」としてまとめる• 改善
 ②③の順番で「要件」をまとめる「要件定義のセオリー」より
13

ちょっと脱線？・・・エンタープライズアーキテクチャ• エンタープライズアーキテクチャ（EA）
 “米国でエンタープライズアーキテクト（企業の設計士）が人気”という記事が日経新聞に掲載される
 EAは全社(企業全体）のシステム設計図(体系）14エンタープライズアーキテクチャ（EA）は全社のシステム設計図！
・ 全体を意識しつつ個別のシステム設計を行う必要がある！
 開発プロジェクト単体だけを体系化しても意味がない！

 全体を体系化していくとともに、それを継続的な取り組みとしていく！
SaaS

ローコード開発

Ａシステム

Ｂシステム

Ｆシステム

Ｃシステム

Ｄシステム

Ｇシステム

Ｅシステム

開発対象システム

BA
DA
AA
TA

ERP
15

変化と進化に対応し続けるエンタープライズアーキテクチャ
・「経営環境の変化」「テクノロジーの進化」によりビジネス／業務は影響を受ける！
 クラウド、ERP、SaaSサービス、ノーコード／ローコード開発ツール、AI、IoT、NoSQL等のTA（技術体系）、AA（適用処理体系）、DA（データ体系）の進化によりBA(ビジネス（業務）体系）は激変していく！
経営環境の変化BA
DAAA

BA: ビジネス(業務)体系（Business Architecture）
DA: データ体系（Data Architecture）
AA: 適用処理体系（ Application Architecture）
TA: 技術体系（ Technology Architecture）

TA

テクノロジーの進化
16

システム設計とは・システム設計 ＝ビジネス／業務設計＋IT設計
 システム設計はITの設計だけで成り立っている訳ではない ビジネス／業務の設計とIT設計を両方行うのがシステム設計
 ビジネス／業務設計をきちんと行わないシステム開発は間違いなく破綻する クラウドベース開発であろうともビジネス／業務設計は必須

BA
システム設計 ＝ビジネス／業務設計＋IT設計

ビジネス／業務設計の範囲・・・データ・プロセス・その関係性の設計

DA
AA

IT設計の範囲・・・実装に関わる設計

TA
17

ビジネス／業務設計とは・ビジネス／業務設計＝（ビジネス／業務で使用するデータ、プロセス、およびそれらの関係性についての設計）
 データ設計 ： リソース系とイベント系のビジネス／業務データの設計、および連携仕様の把握

 プロセス設計 ： UX（User Experience：ユーザー体験）を最大化するビジネス／業務シナリオを可能とするためのビジネス／業務プロセスの設計
 CRUD設計 ： データとプロセスの関わりについての把握、定義、設計

18

IT設計とは・IT設計＝（ビジネス／業務に必要となるIT機能・UI・データ・その他アーキテクチャの設計）
 データ設計： 使用するIT機能とUIで扱うデータベースの設計、およびデータ連携の設計

 機能設計 ： 業務プロセスとUIを実現するために必要なIT機能の設計
 UI設計： 業務プロセスとIT機能を実現するために必要なUIの設計

 その他アーキテクチャ設計： 開発方法、インフラに応じたDD（データアーキテクチャ）、AA（アプリケーションアーキテクチャ）、TA（テクノロジーアーキテクチャ）の設計
 クラウドベース開発においてTAはクラウド環境が前提となる。

19

クラウドベース開発における設計の考え方

・論理設計と物理設計の位置づけ
 システム開発を行う目的と方向性に基づき、「何を」すべきかの大枠を論理設計の前半で固める

 論理設計の後半と物理設計を繰り返し行う
 論理設計にて「何を」をすべきか、物理設計にて「どのように」をすべきかを具体化していく

20

開発手法による違い：ウオーターフォール型の場合

21

開発手法による違い：アジャイル型の場合

22

クラウドべース開発時代における3つの選択肢

・『①作らない開発』『②極力作らない開発』『③作る開発』
 これからはなるべく『①作らない開発』を指向する時代！

23

Agenda１．クラウドベース開発におけるシステム設計とは
２．本質は変わらない・データ設計
・プロセス設計
・データ×プロセス設計（CRUD設計）
3．さらに超上流工程へ

24

「変わらないもの（こと）」と「変わるもの（こと）」とは・「変わらないもの（こと）」とは！
“上流工程”“データ中心”を指向すること

”データそしてプロセス“をきちんと設計すること の重要性
・「変わるもの（こと）」とは！
 “テクノロジーの進化へ対応”
 “経営環境の変化への対応”の必要性
25

データ設計：データモデル例＊IE法にて記述 例えばクラス図等、どんな記法を用いようとかまわない26

データ設計：工程毎に作成すべき『データモデル』

27

プロセス設計：UXの最大化
・ UXの最大化を指向するプロセスモデル
 わかりやすく業務フローに落とし込む！

 最適な業務フローから最大の価値を持つプロセスを抽出する！

28

プロセス設計：プロセスモデルと工程

29

プロセス設計：プロセスモデル(業務フロー例）＊BFDにて記述 例えばBPMN等、どんな記法を用いようとかまわない30プロセス設計：業務プロセス・IT機能・UIの関係

・ビジネス／業務プロセスの構成要素
 業務プロセスは1つもしくは複数のIT機能より構成される
 業務プロセスは1つもしくは複数のUIより構成される

 最高のUXを実現するために必要なUIを定義する

31

《重要》データの繋がりを確保する！

・データ／プロセスともにデータの繋がりを意識する！
 データの繋がりをすべてデータモデルで管理する
 同じくデータの繋がりをすべてプロセスモデル（業務フロー）で管理する＊データ＊プロセス

32

CRUD設計：何故「CRUDマトリクス」なのか

・「システム設計のセオリー」「要件定義のセオリー」
そして本書「システム設計のセオリーⅡクラウドベース開発」において「CRUDマトリクス」を大きく取り上げている、何故か！
 「今どき流行らない」
 「古臭い」 「他にもいくらでもいいやり方がありそうなもの」
 「もっと今風？のやり方を紹介してほしい」
 「知っている人すら少ないのでは」

33

CRUD設計：CRUDマトリクスとは・データとプロセスの関係性を見える化する＊データ＊プロセス
34

CRUD設計：データモデル・プロセスモデル・CRUDマトリクスの関係

35

CRUD設計：論理CRUDマトリクスの例＊データ×プロセスのCRUDマトリクス

Ｒ

Ｒ＊データ×機能（プロセスの構成要素）のCRUDマトリクス

36

CRUD設計： CRUDマトリクス設計情報の継承

お互いにCRUD
定義を継承

37

Agenda１．クラウドベース開発におけるシステム設計とは
２．本質は変わらない
・データ設計・プロセス設計
・データ×プロセス設計（CRUD設計）
3．さらに超上流工程へ

38

情報システムの使命を果たすために•情報システムの使命「適切な時に、適切な人（場所）が、適切な（品質）の情報をｉｎｐｕｔ（入力）することにより、必要な時に、必要な人（場所）へ、必要な（品質）の情報を ｏｕｔｐｕｔ（出力）する」 為に存在する
 データライフサイクルはシステムライフサイクルより長い⇒ビジネスをデータ中心で考えることは必然 ビジネス ／業務と情報システムを繋ぐのは「データ」であり「プロセス」だけではどうにもならない
データ中心型ビジネスアプローチ（DOBA）＜データライフサイクル＞＜システムライフサイクル＞
39

日本のEAに対する理解の致命的な間違いを正す
・ 《大問題》 ビジネス アーキテクチャが“プロセスアーキテクチャ”になってしまっている！
 ビジネスアーキテクチャ（BA）においてビジネスではなくプロセスのみしか考えない人が数多くいる
 これは明らかな旧来からのプロセス指向アプローチであり、DXなんて到底無理 ビジネスはプロセスだけでなくデータとプロセスの組み合わせで成り立っている
 必然的にビジネスアーキテクチャ（BA）おいてビジネスの全体像把握とともにビジネス実現に必要なデータ、プロセス、そしてデータとプロセスの関係性までを明らかにして体系化していく必要がある

BA
DA

×プロセスアーキテクチャ〇ビジネスアーキテクチャ★BAにおいて全体像、データ、プロセス、データとプロセスの関係性 の構築は必須

AATA40超上流工程ゼロから始めるシステム設計
・データ中心型ビジネスアプローチ
DxBA（ｘ・・・centric,driven,orientedなんでもいい）・・・通称ＤＯＢＡ
 データ中心型ビジネスアプローチは超上流工程から実装まで一気通貫を可能とする
 実現にはビジネス／事業創出と併行してビジネス体系（ＢＡ）として4点の図を作成することにより「設計を始める」ことになる 「システム設計のセオリー」の内容に繋ぐことを可能とする”超上流工程ゼロ“からの考え方でもある

BADA
AA

TA41ビジネス体系を表す4点の図
 「ビジネス鳥瞰図」
ポンチ絵でもいいので全体像をつかむために描く。
ビジョン、目的、方向性がわかるようにするとともに、この時点で明確な制約、前提があれば書き出しておく。

 「ビジネス地図」
最大の価値を生み出すビジネス、業務のあり方を描く。

 「ビジネス航路図」
ビジネス地図を最適に巡ることにより効果を出す道筋を示すためにビジネス、業務の流れを描く。

 「ビジネス行動図」
ビジネス航路図で辿り着いたビジネス地図のある地点で実践すべき行為を表すために描く。

42

作成手順の概要
ビジネス (業務）④①
概念データモデル④

あり方

ビジネス鳥瞰図
②

データ④

ビジネス地図

ポンチ絵でもなんでもよい
全体像

②
プロセス

ビジネス航路図CRUDマトリクス③

業務フロー図（ユーザーシナリオ）流れ③
データ×プロセス④

ビジネス行動図④

実践すべき行為＊データ中心型ビジネスアプローチはあくまで考え方であり記法はなんでもよい43

４点の図と「システム設計」にて作成したモデルとの関係性
④

④

データ

④

ビジネス地図(概念データモデル）

ビジネス

①

ビジ
ネス鳥
瞰図

ビジネス行動図(CRUDマトリクス)

③

②

プロセス

②
ポンチ絵でもなんでもよい

データ×プロセス④

ビジネス航路図（業務フロー図）③④

ビジネス地図、ビジネス航路図、ビジネス行動図はそのままシステム設計のモデルとして継承できる！

44

４点の図を作成するために・ 「自分達、皆で」脳みそを絞って考え抜き作成する 書いては消して、書いては消して、を繰り返して、仕上げていく この試行錯誤の繰り返しが重要
 ホワイトボード等をできれば数枚用意して使用 関係者で囲んでワイガヤ
 ビジネスと4点の図を整合性を保った状態で一体化していく。
 立場の違う者同士がわかりあえることを最優先に考える
 誰でも描ける、読めることを目指し、なるべくシンプルでわかりやすく描く・・・・・・等々、留意点がいくつかあるけれども詳しくは別の機会に！

ビジネス鳥瞰図：ポンチ絵
ビジネス地図：概念データモデル
ビジネス行動図：CRUDマトリクス

ビジネス航路図：業務フロー図

45

DOBAからシステム設計へ(超上流工程から実装まで）
・ 情報システムの使命を実現するために
 ビジネス／業務の創出とともに必要なデータ、プロセス、その関係性を「4点の図」を描くことで明らかにしてビジネス／業務体系として構築していく 設計、そして実装へ繋げていく(一気通貫を目指す）
データ中心型ビジネスアプローチ（DOBA）【ビジネス／業務体系を表す4点の図】①ビジネス鳥瞰図(全体像）②ビジネス地図(あり方）③ビジネス航路図（流れ）④ビジネス行動図(実践すべき行為）「情報システムの使命」の実現！
データ:データモデル

×

プロセス：プロセスモデル(業務フロー）
データとプロセスの関係（CRUDﾏﾄﾘｸｽ)

46

データ中心型ビジネスアプローチについて詳しくは・・・・・
・以下にて詳しく解説して（する）ます！
 パシフィコ横浜にて開催されるEdgeTech+にてJUAS高度化プロジェク
トとして講演予定です(私も登壇します！）★11月16日 15:00～15:45「データ経営が日本を変える！ー DXを成功させるデータ中心型ビジネスアプローチ（DOBA） ー 」

 先ほど紹介したschooオンラインコース「要件定義のセオリー」にて要求モデルとして説明していますのでぜひとも視聴してください その他同様に先ほど紹介した記事でも取り上げてます 次作のセオリーシリーズにて大々的に？取り上げる予定です47まとめ

・「鳥の目を持って地べたを這う」
 「正しい」システム設計は、全て上記精神？を持って臨めば必ず成功する！
 （と私は確信しています！）

48