ハタケ(システムエンジニア→ITコンサル)の日常とナレッジ展開ブログ

娯楽やお役立ち情報、人生で学んできた事やIT系(RPAメイン)の知識情報を気まぐれで発信していきます。twitter→@RPA_AI_it

業務側も知っていると役に立つ情報 第1章 ~ITアーキテクトの基礎知識編~

今回は「業務側も知っていると役に立つ情報」について、書いていこうと思います。何故これを書こうと思ったかというと、私が仕事をしている中で業務担当者とシステム担当者の話が噛み合っていない場面に多く遭遇しており、その原因として双方がお互いの事を知らな過ぎている事が大きな要因であると感じているためです。そのために業務部門の方がシステム部門が考えている概要を知れたり、システム部門側が業務部門側が考えている事の概要を知れたらいいなと思い、書く事にしました。今後、市民開発と呼ばれる業務部門側でアプリケーション開発を行っていくための役割や業務部門側で扱うシステムやツール検討に深く関わるビジネステクノロジストという役割の人に必要な知識になると考えます。

 

「システム部門の人とよく話が噛み合わない」「システム部門が何を考えているのか分からない」「市民開発者として今後活躍していきたい」という方には是非このブログを読んで頂ければと思います。


この記事はUiPathブログ発信チャレンジサマー!2022の31日目の記事です。前日の30日はw.wackさんとyamasaki_aaaaさんの記事です。

note.com

 


下記の内容を順番に書いていく予定です。内容が濃いため回数を分けて書いていこうと思います。この記事は第1章です。何故この記事を書いているかや、各章で説明している内容が何の役に立つかは別の資料で説明しているので、まずはこちらを見て頂ければと思います。

 

 

 

ブログ連載内容】



【目次】

 

ITアーキテクトとは

まずはITアーキテクトって何?から説明していきます。アーキテクトという言葉は構築家や設計者の意味を持つ英単語で、ITアーキテクトはビジネスの方向性やこうしていきたい等の要求(思い)に対して、ITシステムを使ってどう実現できるかを考えて、構成を考える役割です。会社で扱っている主要なシステム達はITアーキテクトの役割の人が、どの製品や技術を組み合わせて、実現したい要求を満たすかを考えて構築されています。ビジネスの戦略立案や要求の整理はITアーキテクトではなく、コンサルタントの人が行ったり助言に入ったりする事がありますが、コンサルタントではなくITアーキテクトやビジネスアナリストが要求整理部分を行う事もあります。情報システム部門で働いている人の中でも会社全体のシステム構成を検討できる人は多くはいないケースがありますが、どのように構成していくかはITアーキテクトの人が関わって作られています。

 

 



IT・社会(ビジネス)の変遷から見るITアーキテクチャ

続いて昔と今のITアーキテクチャーの違いを見ていきます。「何故歴史を知る必要があるのか?」という点において、私は3つ大きな効果があると考えています。


【歴史を学ぶ事で生まれる効果】
1.過去と同じ失敗を回避できる
2.昔から今を辿る事で将来の予測に役に立つ
3.何故その技術や製品が生まれたかの設計思想の把握に役立ち、製品や技術を正しく扱う力が身に付く

 

では、早速歴史の説明に移ります。ひと昔前は技術革新スピードは比較的緩やかでありましたが、インターネットの普及によって、会社のシステム構成(アーキテクチャー)や開発手法、セキュリティ等の技術革新が速いスピードで進んでおり、2022年の現在では全ての技術や製品の詳細を一人のITアーキテクトが把握する事がとても難しくなってきています。また、オフィスワークの多くの方は様々なシステムを既に扱っていると思いますが、IT自体が多くの人の仕事にとっての重要性が増して来ています。大枠は下記の図のような流れで進んでいますが、ポイントを絞ってパソコン(個人向け小型コンピューター)が日本に普及し始めたとされる1990年代の少し前の1980年代から説明していきます。

 

(筆者は2010年頃から社会人として働いており、様々な文献やサイト、人等から情報を収集して書いています。もし事実と違う部分がありましたらご指摘頂けると幸いです。かなり長いのでポイントをより理解し易いように簡略版を別途作成しようと思います(-_-))

 

出典:経済産業省 「デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ、対話に向けた検討ポイント集 第1章(デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ(METI/経済産業省))」

 

1980年代:ワープロ専用機とパソコン、汎用機の説明 

 

1980年代初期にワープロ専用機が普及し、それまで手書きだったものがデータで処理されていく事が増えていきました。1985年頃にはパソコン対してWindows OSが発売され、GUI(Graphical User Interface)を使用して画面上のアイコンを操作する事が可能になり、次第にパソコンが普及していきます。この頃の会社のシステム構成(アーキテクチャー)はメインフレーム(汎用機やホストコンピュータ)という物置のような大きさのコンピューターに給与計算や在庫管理等多くの業務システムを一括(バッチ)処理させていくのが主流の時代でした。日本でパソコンが一人に一台割り当てされ始めたのは1990年代頃との事です。

 

 

パソコンが普及していくとEUC(エンドユーザーコンピューティング)という情報システム部門以外の人が自主的にコンピュータを操作して、自分あるいは自部門の業務に役立てる活動が始まりました。当時は誰もが手を出せるものではなく、一部の人が少し手を出していた程度だったそうです。

 

1990年代:クライアントサーバ、インターネット、VBA(EUC本格化)、アウトソーシングERPの説明

 

1990年代に入りパソコンの性能向上と価格の減少により、パソコンとパソコンをLAN(※1)接続する優位性が認識され始め、ネットワークを利用して処理を分散していくアーキテクチャーとして、メインフレームでの集中管理モデルから徐々に処理をクライアント(パソコン)とサーバ(※2)で分けて行うクライアントサーバモデルが主流となっていきます。クライアントサーバ時代から関係データベース(リレーショナルデータベース)というデータを表に似た構造に蓄積するようの技術が広く活用されるようになりました。データの場所が分散されたものを纏めて分析するためにデータウェアハウス(※3)という技術や1つのシステムで扱っているデータを他のシステムでも扱いたい場合にデータを移動したりする必要が出てきて、これを容易にしやすくするために、ETL(extract=抽出、transform=変換、load=ロード)ツールが普及していきました。


※1 ローカルエリアネットワーク。限られた範囲内にあるコンピュータなどをケーブルや無線電波などで接続し相互にデータ通信できるようにしたネットワーク

※2 利用者の要求(リクエスト)に対して、それに応答したデータを提供するコンピュータやプログラム

※3 複数システムから大量のデータを時系列で蓄積するシステム

 

 

1989年時点では、ワープロがなくなると予想している人は多くなかったそうですが、パソコンの方が文書作成に加えて、他の用途でも利用する事ができ、性能や機能の進化も早かった事から徐々に市場を奪われ、2002年に日本国内でのワープロ専用機の生産が終了しています。技術の進歩によって、当時の当たり前や世界観は時代と共に変わっていきます。

 

 

1991年に日本のバブル景気 (バブル経済)が崩壊し、経済が高度経済成長期から、後退期へと転換していきます。

 

 

1990年代の半ばからインターネット(※4)利用の爆発的な普及によって、Webシステムが広く使われるようになり、インターネット経由で様々な場所から処理を行えるようになっていきます。この頃にVBAVisual Basic For Applications)がExcelに搭載されて、前述で説明しているEUCによってVBAのプログラムが様々な場所で開発されて、作成者以外がメンテナンスできないが、なくてはならないものとなってしまったりして情報システム部門に面倒を押し付けられたり、そのツールがないと業務が回らないが止まった時に直せる人もいないので業務に支障が出る問題が多発したそうです。現在は市民開発という言葉も出てきていますが、情報システム部門側はまた過去と同じ過ちが発生するのではないかと市民開発を行う事に慎重になっている人が多くいます。市民開発については、第5章の記事でEUCとの違いも含めて深く説明や考察していきます。技術は上手く扱えば、会社にとって有益なものになりますが、使い方を誤ると不利益を与えるものになってしまいます。

 

※4 通信回線を介して世界各地の個人や組織のコンピューターがつながっている、地球規模の巨大なネットワーク。wwwというインターネット上に散在する文書同士を相互に参照可能するシステムの登場も普及した要因の一つとされる

 

 

同じ頃に日本でアウトソーシングという言葉が使われ始めてブームの様に推進されていきました。アウトソーシングは「社内の業務を外部の企業に委託すること」です。日本ではアウトソーシングという言葉が流行り始める前から外部委託をしている所があったそうですが、更に業務領域を拡大したり、大きな会社はグループ内の業務を集約して行うシェアードサービスを作ったり、海外の企業に委託したりするケースが増えていきます。

 

 

1990 年代の終わりごろには、ERP(Enterprise Resource Planning(エンタープライズ リソース プランニング))という手法が登場します。ERPは主に企業のヒト、モノ、カネ、情報を効率的に管理・配分して全体最適を目指す手法です。ERPは具体的には下記の図で表すと「財務会計」「管理会計」「生産/在庫」「人事管理」「マーケティング管理」「物流およびサプライチェーン管理」部分で扱われます。単一のシステムで基幹業務を集中管理しようする考え方で当時は設計されていました。よく同じようなもので登場するCRM(Customer Relationship Management(カスタマーリレーションシップマネジメント))は顧客管理に特化して扱われるもので、SCM(サプライチェーンマネジメント)はERPの中の「物流およびサプライチェーン管理」に含まれます。

 

黄色のオブジェクトがシステムで白の□内が業務を表している概念図です。

出典:日本ITガバナンス協会 ITによる変革の方法論集ある ITコンサルタントツールボックス ITマネジメント編 ITのアーキテクチャマネジメント(https://www.itgi.jp/application/files/7316/0862/6794/14IT.pdf)

 

 

ERPを行うためのソフトウェアパッケージとしてERPパッケージが売り出されました。(パッケージという言葉が出てきたら大体袋に色々入っているセットをイメージすると良いです。ERPパッケージはERPを行うためのシステム群を1つに纏めて提供しているセットです)

 

 

ERPパッケージが登場する前は様々な企業が独自に「財務・会計、人事管理、販売管理、調達・購買...etc」のシステムを作っていたところに、各企業が共通して使えるような機能を汎用的に利用できるパッケージングされたものを提供する企業が登場したのです。現代でいうとSAPやオラクルが代表例です。ERPパッケージを扱う事で一から開発しなくても良くなり、開発や運用を効率的に行う事ができました。「システムは作るもの」という考え方から「システムを買う」という考え方ができました。しかし、日本はこのERPパッケージ導入で当時失敗している企業が多くあると言われています。業務は時代によって、自社が提供するサービスや製品、考え方や法律が変わる事によりシステムも一緒に進化していく事が求められます。ERPパッケージで実現できない部分を独自に追加で開発を行う事を「アドオン開発」といいますが、日本はアドオン開発が他の国に比べて多いと言われています。アドオン開発部分が多いと、時が経つにつれてERPパッケージ自体は進化をしていくのに対して、アドオン開発部分への影響が出てしまったりして維持していくのに膨大な運用コストを消費してしまいます。日本はサービスレベルが高かったり、他社との差別化の部分が多かったため、グローバルで開発されたERPパッケージだけでは要件を満たせず、アドオン開発が必要な企業もあったと思われますが、ERPパッケージ導入前の働き方をそのままERP移行後も考え無しにやろうとして、余計なアドオン開発をしてしまった企業も多くあるとされています。

 

 

製品や技術を購入する側は企業存続及び利益拡大していくためにどうしていくか、何のためにその製品や技術を扱うのか、導入後の事も考慮して販売側の営業トークの言いなりにならずに使い方を考える必要があります。考え無しに特定の製品を導入するだけでは上手く扱えません。言いなりにならない様にするためにも今回説明していく知識が役立ちます。

 

 

2000年代:エンタープライズアーキテクチャー、SOAクラウドの説明

 

2000年頃にEA(エンタープライズアーキテクチャー)という企業構造を最適な姿に変革するために企業やシステムの全体構造を示す方法論、全体最適化を図るための全体設計図として流行していきました。「ビジネスの視点」「データの視点」「アプリケーションの視点」「情報技術の視点」から業務フローやシステム、ネットワーク、ソフトウェア、ハードウェア構成図等を用いて会社のITの現状を整理し、将来のモデルを作成するの使用されます経営部門や利用部門が全体や部分的な把握ができないと現状把握や将来のモデル設計がし難くくなるため、現在どのような業務があって、システムがどのように使われているかが可視化されている事は非常に重要です。

 

出典:DX白書2021_第4部 DXを支える手法と技術(https://www.ipa.go.jp/files/000093702.pdf )

 

 

EA(エンタープライズアーキテクチャ)の流行と合わせて、利用者側から見たソフトウェアの機能単位である「サービス」の組み合わせによってシステム構築していくアーキテクチャとしてSOA(サービス指向アーキテクチャ)というものが注目されていきました。サービス単位というは「請求書を処理する」のように利用者側の視点からみた作業単位を指します。サービスを部品のように細かく分ける事で様々な製品と結合させてシステム全体を組み立てる事が可能になっていきました。修正が必要な時にそこのサービス以外は影響を受け無くしたり、いらなくなったらそのサービス部分だけを切り離したりする事もできます。このような作り方を疎結合させて作ると言います。

 

 

2000年代後半からクラウド(※5)というものが登場しました。Amazonが2006年に企業向けのクラウドサービスの提供を開始し、クラウドの普及と発展は爆発的に進んでいきました。2010年頃までは、今までデータを社内の閉じたられたネットワークで管理する方が安全であり、クラウドは情報漏洩が怖い、使えないと考える人が多くいましたが、クラウドの技術が発展し、セキュリティレベルも高くなり、大手の企業も積極的に利用していくようになっていきました。2022年現在では日本政府もクラウドを積極的に利用していく方針が出ています。2010年以降は「エッジコンピューティング」という考え方に更に進化し、エッジサーバや操作デバイス側にデータ処理や分析を行う事で、通信の遅延やリアルタイム性を高めています。エッジサーバはクラウドと利用コンピューターの中間に位置するサーバです。


※5 ユーザーがサーバーやデータ保存場所やソフトウェアを持たなくてもインターネットを通じて、サービスを必要な時に必要な分だけ利用する考えや利用形態

 

2010年:マイクロサービスアーキテクチャー、バイモーダルIT、iPaaS、RPAの説明

 

2010年中頃にはビジネスや技術の進化スピードが速く、システム新規開発や改修に「変更容易性」「スピード」「拡張性」がより求められてきており、それを解決するための考え方として、マイクロサービスアーキテクチャーという、小さなサービスを組み合わせて構築する考え方が広まっています。前述で出てきたSOAと似ていますが、大きな違いは「サービスの粒度が更に小さい」「API(※6)を介した通信(SOAは複数の通信方式があり複雑)」「各サービスが独立したデータ保存場所を持つな点です。マイクロサービスとは別のアーキテクチャーでモノシリックというものがあります。モノシリックはサービス毎に切り出さずに1つのシステム内で機能を充実させて作る考え方です。どこかを修正すると他に影響が出ていないか確認やテストに多くの工数が掛かってしまったり、サービスが丸ごと異常で使えなくなってしまう作りですが、管理がしやすい(単純な構成)や大量明細を処理し易いメリットがあります。一つの大きなシステムに少しの改修をする場合も、他に影響がでないかの影響調査やテストが大変で、それを疎かにすると間違った処理をしてしまったり、システムが止まってしまう原因に繋がります。「少し直すだけじゃん」と業務部門側の方でたまに発言する人がいますが、問題を起こさないようにするための作業があり、時間やコストが掛かるのです。

 

※6  アプリケーションプログラミングインターフェース。ソフトウェアの機能や管理データなどを、外部の他のプログラムから呼び出して利用可能とする仕組みや規約

 

出典 IPA エンタープライズシステムへのマイクロサービスアーキテクチャー適用の実践(

https://www.ipa.go.jp/files/000064276.pdf)

 

 

全部のシステムをマイクロサービスにすれば、追加開発や切り離しが簡単にできると思われた方もいるとおもいますが、マイクロサービスも万能ではなく、運用が複雑になったり、設計の難易度が高かったりする面もあり、今後どこをクラウドやマイクロサービスで構成するのか、どこをERP等パッケージを使うのか、どこを自社で独自に開発するのか、それぞれをどのようにデータで繋ぐのか、分析させるのかを考えて設計していく必要があり、とても難易度が高くなってきています。ERPも必要な機能を絞り込んで利用して、足りていない部分は他のアプリケーションを組み合わせたり、個別開発していくようなポストモダンERPという考え方が登場してきています。この複雑化しているシステム設計を考えるためにそれぞれの領域に適した技術を用いる考え方として、「SoE」「SoR」「SoI」という考え方(バイモーダルIT)が誕生しています。安定が求められるシステムとスピードが求められる箇所で開発手法や技術の使い方を変えるというものです。様々な場所にデータが散らばってしまう課題を解決するために、データを処理できるように様々な場所から大量に集めて貯蓄しておく技術であるデータレイクが再注目されてきていると感じます。(前述のデータウェアハウスとデータレイクのいいとこ取りをしたデータレイクハウスというものが誕生しています)

 

出典:第1回 DX時代のITアーキテクチャとグランドデザインによる展開:株式会社 日立コンサルティング (hitachiconsulting.co.jp

 

 

また、様々な複数クラウド間と自社システムを繋いだりする技術として、iPaaSが2010年頃から注目されていきます。前述に出てきたETLやELT(Extract(抽出) Load(書き出し)Transform(変換))、EAI(Enterprise Application Integration)、ESB(Enterprise Service Bus)を含む広い概念で、iPaaS製品毎に特長があったりします。ELTEAI、ESBの説明の詳細は今回省きますが、大量データの処理に向いていたり、少ないデータでリアルタイムの処理に向いていたりで扱う場所に違いがあります。データ連携の方法が他にあるんだなと存在をまずは知って頂いて、深く関わる時がきたら違いについて調べて貰えたらと思います。

 

出典:iPaaS といってもいろいろな種類があるので分類してみよう~レシピ型、ETL/ELT、EAI、ESB~ - CData Software Blog 

 

 

2018年には日本でRPAが急速に拡大していきました。日本国内で様々なRPA製品がリリースもされています。RPAはRobotic Process Automationの略称であり、ソフトウェアのロボットが作業を自動化するツールや技術の事を言います。人がパソコンで行う操作を模倣する事ができるため、APIやiPaaSで自動化できない部分も自動化を行う事も可能です。近年ERPパッケージのSAPやCRMのSalsesforceもRPAの機能をRPAベンダーを買収して独自に持ち始めたり、RPAベンダーがiPaaSを扱えるようにしたりと、各製品ベンダーでiPaaS(API連携)、RPAの分野への競争が激化してきています。これは人の手を介さないで良い箇所はできるだけ自動化可能にしていくのと、変化への対応スピードが求められる箇所に柔軟に対応可能にしていく流れが背景にあり、iPaaSだけではなくRPAの技術も拡大し続けているのだと思います。システム開発を待っていたら現場が崩壊してしまうシーンでRPAが活躍した事例があります。ですが、RPAも万能ではなく、複雑すぎるものや画面変更が多いシステムに弱い等弱点はあります。また、RPA以外でもプログラミングをたくさん書かなくてもシステムを作れるローコード、ノーコードツールも同じように徐々に活用が広がってきています。業務部門が開発するものは、VBAもRPAもローコード系も全て前述の過去のEUCのような問題を回避して失敗を繰り返さないようにする必要があります。どのように回避していけば良いかは第五章に書いていこうと思います。

 

まとめ

 

これまで説明してきているもの以外にもAIやビッグデータ、5G、ブロックチェーン、ロボティクス等これまでの仕事の常識を変えていく破壊的な技術革新が次々起きています。IT自体そのもので利益を拡大していく事も可能な時代となり、ITの活用は効率化だけに留まらなくなってきています。ITアーキテクトはこれらの技術の進化に合わせて、自社のシステムの現状を把握しつつ、どのように構築していくかを考え、管理を行っています。本質的な問題を把握し、解決策を考え、判断を行い、技術者や経営側にわかり易いように説明を行い、最新技術動向を抑え、様々な価値観や視野を持ち、問題を予見できる人達が考え抜いて社内のシステムは構築を続けているのです。更に近年、データを上手く使ってビジネス戦略やマーケティングに活用していく企業が増えており、データの重要性がこれまで以上に重要と言われてきています。それに伴い、システム構造を検討するITアーキテクトにもビジネスやデータサイエンスの知識や能力も求められるようになってきています。(幅広すぎぃ...)

 

 

今回触れていない用語やイベントもありますが、説明してきた歴史を年表に纏めたものは下記の通りです。年表はそれが誕生した経緯や他との関係性、これからどうなっていくのかを考えるのに良い情報だと思います。業務改革や改善の用語は第3章で触れていきます。

 

(それぞれの技術についての情報を筆者が年表にしたもの)

 

 

システムアーキテクチャーの考え方の流れは「集中⇒分散⇒集中⇒現在(2022年)はまた分散」とされています

 

出典:システム構成(集中と分散)の歴史<経営とIT<歴史<木暮仁 (kogures.com)

 

 

 

歴史の纏めです。大きなコンピュータ(汎用コンピュータ)が登場してそこに処理を集中していましたが、パソコンが高性能且つ安価になったのとサーバーの登場で処理を分散して設計していくようになりました。その後、データーベースやシステム間の連携を効率的に行えるような技術が次々誕生し、クラウドが登場してからはクラウドを上手く扱っていくのが当たり前となり、クラウドと社内システムの連携を効率的に行う必要が出てきました。クラウドを上手く扱っていくためのクラウドネイティブという考え方の重要性が増し、様々なデータベース、データ連携技術、ERPCRMがそれぞれ進化しており、それらを上手く活用して、近年会社内のシステムが再構築されていっています。クラウドの活用により、これまで社内の環境にだけ存在していた重要なデータが社外のネットワーク上に所持する使い方も増えており、セキュリティの考え方も併せて見直しがされています。

 

 

情報漏洩は自社ビジネスに与える影響が大きいため、各自特に気を付けましょう。新しい技術やツールを使いつつ情報漏洩を防ぐためにはセキュリティや技術に関する知識が一定必要になります。また、自分が時間を掛けて改善しようとしている事が、システム部門側で新規開発や改修している最中だった、、となってしまう事もありますので、会社の状況や方針を把握したり、システム部門と連携を取って進める事と新しい技術や製品を導入する際には、導入する事を目的とするのではなく、「解決したい課題や目指したい姿が何で、そのために製品や技術を使って解決する」という考え方が大切です。

 

 

 

 

第2章について

次は「会社内の主な業務や部署について」「バックオフィス、フロントオフィスの違い」「バックオフィスのシステムが進んでいる世界観」について説明していきます。会社のデータの流れや他部署との関係性(部門横断の視点)を把握するために必要な知識となります。

 

 

syachiku-inu.hatenablog.com

 

 

参考サイトに第1章で説明している情報の詳細情報が書かれていたりしますので、興味がありそうなサイトがあれば、是非確認して理解を深めていってください。

 

 

これまでの内容に関わるお勧めの書籍紹介

ITの歴史や上記の説明に関わるものでお勧めの書籍を紹介します。

 

①コンピューターってどんなしくみ?:デジタルテクノロジーやインターネットの世界を超図解 (子供の科学★ミライサイエンス)

コンピュータの仕組みやコンピュータ同士が繋がる仕組みや簡単な歴史、コンピュータの何が危険なのかわかり易いように書かれている子供向けの書籍です。コンピュータやネットワークの仕組みが全然分からないという方にとてもお勧めです。メモリ?CPU?OS?という方でもついていけます。楽しみながらITの基礎知識を学べます。ここに記載されている事が理解できると、ITパスポートの参考書に書かれている内容も理解し易くなるため、ITリテラシー向上の入り口としてお勧めです。

 

 

 

参考サイト

「IT関連の歴史」目次<木暮仁 (kogures.com)

IT部門の歴史的変遷<経営とIT<歴史<木暮仁

アーキテクチャ主導の企業情報システムへ~2014.3.3 第8回要求シンポジウム~(ipa.go.jp)

現場を極めたITアーキテクトが語る!「成功へ導く極意」 | 株式会社アイ・ティ・イノベーション (it-innovation.co.jp)

インターネット歴史年表 - JPNIC

monthly_somu2013_06.pdf (jmac.co.jp)

〇民間及び行政のアウトソーシングの考え方について

(http://www.ecpr.or.jp/pdf/ecpr10/32-37.pdf )

ワープロ専用機はなぜ廃れてしまったのか | kako blog

JPCERT/CCセキュリティインシデント年表
安全なウェブサイトの作り方 - 1.6 CSRF(クロスサイト・リクエスト・フォージェリ):IPA 独立行政法人 情報処理推進機構

IPA:IT アーキテクト育成ハンドブック第2版 (https://www.ipa.go.jp/files/000010253.pdf)

IPA 独立行政法人 情報処理推進機構:超上流から攻めるIT化の事例集:各社資料一覧

〇日本ITガバナンス協会:ITのアーキテクチャマネジメント(https://www.itgi.jp/application/files/7316/0862/6794/14IT.pdf)

読者10人と考えた「Excelレガシー」再生への道(2ページ目) | 日経クロステック(xTECH)

業務システムの歴史から考える RPA の未来①(1960年代~1990年代) - Enterprise Blue Ocean ◮ (ebocean.work)

ERP とは | エンタープライズリソースプランニングの定義 | SAP Insights

ERP導入の羅針盤 | JSUG -Japan SAP Users’ Group-

ビジネスとITを全体最適に導くEA(上):ビジネスモデリング事始(2) - ITmedia エンタープライズ

デジタル経営時代のEA(エンタープライズ・アーキテクチャ) - KPMGジャパン (home.kpmg)

ソフトウェア・シンポジウムのテンプレート (sea.jp)

総務省|令和元年版 情報通信白書|情報システムの進化

総務省 平成の情報化に関する調査研究

(https://www.soumu.go.jp/johotsusintokei/linkdata/r01_01_houkoku.pdf)

iPaaS といってもいろいろな種類があるので分類してみよう~レシピ型、ETL/ELT、EAI、ESB~ - CData Software Blog

Web発展の歴史とRESTの躍進 - 研鑽の日々 (hatenablog.com)

iPaaSの動向と将来予測|アクセンチュア

データベース 歴史 snowflake - Bing video

【シリーズ】知られざる、サイバーセキュリティの歴史 #1

トヨタ企業サイト|トヨタ自動車75年史|トヨタ生産方式|トヨタ生産方式の変遷

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.1 | Think Blog Japan

SOAとマイクロサービスアーキテクチャーの違い - Talend | Talend

18年後の惨状を完璧に予言したのに失敗したe-Japan戦略、DXも二の舞いだぞ | 日経クロステック(xTECH) (nikkei.com)

デジタルトランスフォーメーションの加速に向けた研究会 中間とりまとめ(METI/経済産業省)

ITR Market View:ERP市場2022 | ITR