中山嘉之のレビュー一覧

システム構築の大前提－－ITアーキテクチャのセオリー

中山嘉之

現行のIT環境を取り巻くバズワードにとらわれることなく、本質的にシステムを構築する上で何が大事かということを「データ」という観点から述べている。

ここまで的確だとある種自明になっていることなのだろうが、それが価値を持つのは「実行するのが難しいから」だと思っている。

スピードがどんどん早くなる中、会社組織やシステムもどんどん複雑になり、相反していく中で開発を行っていくのは非常に難易度が高い。そしてコストや品質、納期も当然ある。

そうした妥協を続けた結果の産物が現状の環境であり、天才が解決するGAFAとかと違い、日系は地道にやっていくしかない、ということを語っているように感じる。

I/F標準は特にその表面の議論に閉じてしまうことが多く、いわゆるStep論で後回しにされそのまま消えてなくなってしまう。。。

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

中山嘉之

組織的な話を含み、かつシステム開発プロセスの中では抽象的な部類の内容が多いので、まだまだ自分的には理解したとは言えない本。どこかで戻ってくる予定です。

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

中山嘉之

データの流れを中心に考える。
システム間を直接つなぐP2Pではスパゲッティ化する。システム間の連携はなくべく疎とすることで、個々のシステムの刷新をしやすくすることもできる。
そのためには、データHUBをつくる。
HUBにマスタや共通トランザクションをもたせる。

システム構築の大前提－－ITアーキテクチャのセオリー

中山嘉之

国内外問わず、既存企業にとってDXは死活問題である。そして2025年の崖と言われるように、従来の企業内システムが足かせとなることは目に見えている。コンサルタントは、バイモーダルやSOR/SOEのように分けて、新規投資を進めようとするが、既存システムがカバーする業務プロセスやデータを無視して、新しいことだけやっても事業価値に繋がらない。既存システムをDXに適応するよう、変革しなければならない。そしてこの変革は経営的観点から、短期的なROIも考慮してビックバン的に一度に行うのではなく、価値を出しながら少しずつ行う必要がある。このトランスフォームをどうやって実現するか？

本書の答えは、エンタープライズアーキテクチャ、特にデータハブによる疎結合型のシステムである。筆者は協和発酵キリンの情報システム部長として、データハブを構築し、その手法はIT協会のITマネジメント賞として評価された。データハブでは、ゴールデンレコードすなわち会社の正式データとして、マスタとトランザクションを一元管理し、全てのシステムはデータハブとデータ連携を行う。データハブでは、顧客と得意先などの意味を一般化して、さまざまな業務で活用できる構造にする。トランザクションも一般化して、タイムスタンプと取引コードにより汎用性を持たせる。

なるほど確かにこの方法は、大切なデータを自社システムの中心に据え、クラウドを含めさまざまな周辺システムを上手く活用できるアーキテクチャであり、非常に参考になる。しかし、多くのベンダーが提案するデータ一元化やデータ仮想化、データレイクなどとは異なる考え方で、両立も不可能ではないものの、構築のアプローチが違うため、ベンダー依存の強い企業には難しいだろう。

データを自社のものに、まずはここからである。

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

中山嘉之

▪️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を乱造するこ とにつながります。大規模プロジェクトで近年よく見受けられるコミュニケーションロス を引き起こし、挙句の果てにプロジェクトは炎上することになります。

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

中山嘉之

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