エンタープライズアーキテクチャのセオリー DXの大前提

中山嘉之

本書はまず、DXがもたらすビジネス環境の変化を踏まえ、今後のEAのあるべき姿を明らかにします。その上で、「データHUBソリューション」を活用して、どのようにEAを転換すべきかを実践的に解説。データHUBの進化形である「サービスHUB」にも言及しました。さらに本書終盤では、DX時代に適合するIT組織やIT人材について述べています。



◆想定読者

本書は、企業のCIO（最高情報責任者）やIT部門長、ITアーキテクトをコア読者に想定しています。特に、旧くなった大規模システムの再構築を控えている企業をはじめ、経営層から「DX推進」の命題を与えられIT戦略の立案に携わっている方々、また、将来の企業システムに漠然とした不安をお持ちのユーザ企業及びベンダのIT従事者など、トップ層から現場SEまで幅広い層のお役に立つはずです。



◆拙著『ITアーキテクチャのセオリー』との関係

本書は、2018年刊行の拙著『システム構築の大前提――ITアーキテクチャのセオリー』の続編でもあります。DXへ向けて、前著のスコープをEAへと拡大。前著がブログ記事ベースだったのに対し、今回はより体系的に全編を書き下ろしました。既に前著を読まれた方は、DXに向けた新たなEAの展開について、そうでない方は著者独自のEAの解釈について、どちらも興味を持って読んでいただける内容にしました。

（本書「はじめに」より抜粋して編集）

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: リックテレコム
• 電子版発売日: 2023年10月20日
• コンテンツ形式: EPUB
• サイズ(目安): 16MB

[ブクログ · ★★★☆☆]

▪️Best Of Breedとは、各業務領域ごとに、様々なベンダ製品の中から自社に最も適したものを選択し、その組み合わせでシステム全体を構築することです。


▪️MDM(Master Data Mangement)システム
(1)正しいマスタデータを入力して、マスタの正本を一元管理する機能
(2)一元管理されたマスタデータを、各種業務システムに送り届ける機能

▪️MDM憲法
第１条：「ゴールデンレコードのデータ品質を保証しなければならない」
第２条：「一つのマスタデータを複数カ所で更新してはならない」
第３条：「個別アプリケーションの業務処理を載せない」
第４条：「異なるシステム間のデータ変換を一元的に扱う」
第５条：「システム変更にはデータ管理グループの承認を伴う」


▪️One Fact in One Place
　データベース設計のセオリーとして古くから言われている言葉に、「One Fact in One Place(1つの真実は1ヵ所に!)」があります。これが謂わんとしているのは、「正解が1カ所にしか存在しないような、冗長性を排除した設計にしないと、システムのあらゆる出力に差異が生じたり、メンテナンスがおぼつかなくなったりするぞ!」ということであり、具体的にはRDBにおける正規化につながる話です。
　もちろんこのセオリーは現在でも色褪せてはいません。ただ、企業システムがまだ小規模だった時代、この言葉の「One Place」の解釈は、「物理的な1ヵ所」という意味でよかったように思います。しかし近年、企業システムは業務の隅々までいき渡り、当時予想した以上に大規模なものとなり、一筋縄ではいかなくなってきました。

One Placeは論理的なもの
　則ち、従来のように「物理的に1ヵ所」という解釈のままだと、例えば、全社・全世界のあらゆるシステムから、唯一の共通マスタの正本をAPIでアクセスするというアーキテクチャとなってしまいます。これぞ大規模な密結合システムとなり、データ連携は大盛りのスパゲッティと化してしまいます。もし、重要なマスタがトラブルに見舞われてアクセスできなくなったら、全社のシステムが止まってしまいます。「それならハードウェアの二重化やホットスタンバイにすればよい」とITベンダは言うでしょう。しかし複雑性による運用保守問題は解決しません。
　こうしたことから筆者は、大規模システムにおける「One Place」は論理的な意味であると捉え、「論理データモデル上のエンティティが唯一つであること」と、拡大解釈することにしています。つまり、「物理的に同様のエンティティの複製(COPY)がエンタープライズ上のどこかに存在していてもよい」ということを言っています。
　但し、ここで注意を要するのが、この「複製」は、あくまで正本の複製であり、正本と完全に同期していかなければならないということです。アーキテクチャ上での密結合の連鎖を断ち切るためであり、複数のデータの値は保証されなければなりません。


▪️マスタ系エンティティの特徴
①インターネット上のサイトを通じて不特定多数のユーザから頻繁にアクセスされる
②顧客の会員情報など、データの更新頻度が高くリアルタイム性が重視される
③主としてマーケティング、SFA、CRMといった営業系フロントシステム間で共有される


昇進しても技術習得は継続
　1番目は、「マネジメントを行う人=役職上の管理者」という解釈を背景にして、大企 業では「一般職から管理職に昇進すると、マネジメントだけを行う人になる」という誤解 があったように思います。PMとアーキテクトの二足のわらじを一足にすれば、仕事量 が減るので個人は楽をできますが、企業としての生産性は落ちるはずです。余談ですが、 前職時代にR&D部門からIT部門へ転籍した部長さんが「自分は主任研究員、研究所 長と昇進するにつれ無能化しました」と話していたことを思い出します。この無能化は 「あくまで研究者として」という意味だったのですが、当時の人事制度がエンジニアの生 産性向上を阻んでいると嘆いていたのでしょう。
　2番目は、「ITアーキテクト=優秀なプログラマ」という誤解を背景にして、外部のSlerへのアウトソーシングが広がりました。IT環境がオープン系に移行する段階で、新 たなプログラム言語を習得するハードルが高かったこともあり、同時期にSIerが次々 と立ち上がってきました。システム構築における“デザイナー”の必要性を考えずに、 「アーキテクトをユーザ企業に残さなくてもよい」という風潮が出来上がってしまったと 記憶します。
　3番目は、大規模システム開発が相次ぐ中で極度の分業が行われるようになったこと を背景にして、多くのサブシステムを横断するシステム管理者、さらには各システムを 横断するプロジェクト全体の管理者といった管理者のヒエラルキーが形成されました。 その結果、システムの中身よりも、表面的な進捗管理だけでも何とかしようということで、 PM偏重主義が生まれました。昨今のプロジェクト現場において、PM担当にシステム の中身を質問しても、システム名と主要機能の名前程度しか答えが返ってこないケース はざらにあります。いくらプロジェクトが成功しても、的外れなシステムを作っていたの では、損失を増産しているだけです。
　これからのDX時代には、ビジネスとシステムは表裏一体になってきますので、シス テムをデザインする人材が社内にいなければ、ビジネスイノベーションを起こすのは難 しくなります。また、本来プロジェクトの管理者は、構築するシステムがどのようなイノ ベーションを起こそうとしていて、そこにはどんな技術的課題が潜んでいるかといった 中身を知っていなければ、到底スピーディーなプロジェクト推進はできないでしょう。 よって、IT部門のミドル層はマネジメントとアーキテクトの両方のスキルを身に着けていなければなりません。
　筆者は、「優秀なアーキテクトはロジカルに課題を解決する能力をもっているので、プ ロジェクトマネジメントもできないはずはない」と常々思います。同じような専門性を必 要とする社内部門に経理部門がありますが、複式簿記や仕訳が分からないトップやミド ル層は皆無ではないでしょうか。
　無理にその役割をマネジメントだけに限定することは、技術音痴のPMを乱造するこ とにつながります。大規模プロジェクトで近年よく見受けられるコミュニケーションロス を引き起こし、挙句の果てにプロジェクトは炎上することになります。

[ブクログ · ★★★☆☆]

決して内容は悪くないし参考になるが、前作の完成度が高すぎた。どうしても前作から受けた衝撃と比較してしまう。