中山嘉之の作品一覧
「中山嘉之」の「エンタープライズアーキテクチャのセオリー」「システム構築の大前提－－ITアーキテクチャのセオリー」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
システム構築の大前提－－ITアーキテクチャのセオリー
ビジネス・実用
4.51巻3,080円 (税込)プログラマの開発資産はソースコードでしょう。けれど、ユーザ企業に大切なのはデータ（情報資源）の方です。この真理は、クラウド移行、ビッグデータ、IoT、AI導入等により重要度を増しています。企業がデータセントリックの視点に立ち返るべきは、むしろこれからでしょう。本書の著者が「伝説の情シス部長」、「日本を代表するITアーキテクト」と呼ばれる理由もそこにあります。 ■「本書を推薦します。」 ・山岸耕二氏（株式会社メソドロジック代表取締役社長） ・細川 努氏（株式会社アーキテクタス代表取締役社長） ・渡辺幸三氏（有限会社ディービーコンセプト代表） ※本書の内容は、株式会社アイ・ティ・イノベーションのホームページに掲載されている計100回の連載「現場を極めたITアーキテクトが語る」のコンテンツを全面再編集し、著者自身による大幅な加筆・修正を加えて1冊にまとめたものです。 -
エンタープライズアーキテクチャのセオリー
ビジネス・実用
3.51巻3,410円 (税込)本書はまず、DXがもたらすビジネス環境の変化を踏まえ、今後のEAのあるべき姿を明らかにします。その上で、「データHUBソリューション」を活用して、どのようにEAを転換すべきかを実践的に解説。データHUBの進化形である「サービスHUB」にも言及しました。さらに本書終盤では、DX時代に適合するIT組織やIT人材について述べています。 ◆想定読者 本書は、企業のCIO（最高情報責任者）やIT部門長、ITアーキテクトをコア読者に想定しています。特に、旧くなった大規模システムの再構築を控えている企業をはじめ、経営層から「DX推進」の命題を与えられIT戦略の立案に携わっている方々、また、将来の企業システムに漠然とした不安をお持ちのユーザ企業及びベンダのIT従事者など、トップ層から現場SEまで幅広い層のお役に立つはずです。 ◆拙著『ITアーキテクチャのセオリー』との関係 本書は、2018年刊行の拙著『システム構築の大前提――ITアーキテクチャのセオリー』の続編でもあります。DXへ向けて、前著のスコープをEAへと拡大。前著がブログ記事ベースだったのに対し、今回はより体系的に全編を書き下ろしました。既に前著を読まれた方は、DXに向けた新たなEAの展開について、そうでない方は著者独自のEAの解釈について、どちらも興味を持って読んでいただける内容にしました。 （本書「はじめに」より抜粋して編集）
ユーザーレビュー
-
Posted by ブクログ
ネタバレ現行のIT環境を取り巻くバズワードにとらわれることなく、本質的にシステムを構築する上で何が大事かということを「データ」という観点から述べている。
ここまで的確だとある種自明になっていることなのだろうが、それが価値を持つのは「実行するのが難しいから」だと思っている。
スピードがどんどん早くなる中、会社組織やシステムもどんどん複雑になり、相反していく中で開発を行っていくのは非常に難易度が高い。そしてコストや品質、納期も当然ある。
そうした妥協を続けた結果の産物が現状の環境であり、天才が解決するGAFAとかと違い、日系は地道にやっていくしかない、ということを語っているように感じる。
I/F標準は特にその表面の議論に閉じてしまうことが多く、いわゆるStep論で後回しにされそのまま消えてなくなってしまう。。。 -
-
-
Posted by ブクログ
国内外問わず、既存企業にとってDXは死活問題である。そして2025年の崖と言われるように、従来の企業内システムが足かせとなることは目に見えている。コンサルタントは、バイモーダルやSOR/SOEのように分けて、新規投資を進めようとするが、既存システムがカバーする業務プロセスやデータを無視して、新しいことだけやっても事業価値に繋がらない。既存システムをDXに適応するよう、変革しなければならない。そしてこの変革は経営的観点から、短期的なROIも考慮してビックバン的に一度に行うのではなく、価値を出しながら少しずつ行う必要がある。このトランスフォームをどうやって実現するか？
本書の答えは、エンタープライズアーキテクチャ、特にデータハブによる疎結合型のシステムである。筆者は協和発酵キリンの情報システム部長として、データハブを構築し、その手法はIT協会のITマネジメント賞として評価された。データハブでは、ゴールデンレコードすなわち会社の正式データとして、マスタとトランザクションを一元管理し、全てのシステムはデータハブとデータ連携を行う。データハブでは、顧客と得意先などの意味を一般化して、さまざまな業務で活用できる構造にする。トランザクションも一般化して、タイムスタンプと取引コードにより汎用性を持たせる。
なるほど確かにこの方法は、大切なデータを自社システムの中心に据え、クラウドを含めさまざまな周辺システムを上手く活用できるアーキテクチャであり、非常に参考になる。しかし、多くのベンダーが提案するデータ一元化やデータ仮想化、データレイクなどとは異なる考え方で、両立も不可能ではないものの、構築のアプローチが違うため、ベンダー依存の強い企業には難しいだろう。
データを自社のものに、まずはここからである。 -
Posted by ブクログ
▪️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を乱造するこ とにつながります。大規模プロジェクトで近年よく見受けられるコミュニケーションロス を引き起こし、挙句の果てにプロジェクトは炎上することになります。
