* 要件の抜き出し DXレポート１：増本、DXレポート2：香月、太田

## 宿題事項を以下に記載お願いします
凡例)DX1or2 Pxxx 文言コピペ　　　要約
例)DX1 P31 ベンダー企業は、ユーザ企業のシステム刷新をサポートしつつ、自社の資金や人材をAI・アジャイル開発・マイクロサービス等の最先端分野にシフトさせ、新たなデジタル技術を駆使したプロダクトの提供等を通じて、競争力を高め、世界の主戦場たるビジネス領域に挑んでいく　→　開発プロセスはアジャイル開発を使用すること

DX2 P13　これまで以上の迅速性を持って変革し続ける企業こそがデジタル企業として競争優位を獲得できている。

### DX1
P38から（ググると意味が異なる）
SoE：競争領域のために構築するシステム
SoR：企業の競争力に関わらない協調領域のシステム（ex)地銀共同センター
基盤：全産業で共通化出来る部分（メッセージング、人事管理、給与管理、稼働管理等）
共通：上記全部
その他：システム外

DX1 P4 DX によりビジネスをどう変えるかといった経営戦略の方向性を定めていくという課題もある →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P4 既存システムが老朽化・複雑化・ブラックボックス化する中では、データを十分に活用しきれず、新しいデジタル技術を導入したとしても、データの利活用・連携が限定的である →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P4 既存の IT システムがビジネス・プロセスに密結合していることが多いため、既存システムの問題を解消しようとすると、ビジネス・プロセスそのものの刷新が必要となり →ビジネスモデルと疎結合であること、システムがモジュール化されていること？(SoE)
DX1 P4 既存システムの運用、保守に多くの資金や人材が割かれ、新たなデジタル技術を活用する IT 投資にリソースを振り向けることができない →運用・保守コストが低いこと（共通）スケールアウト・イン、運用自動化（SoE）、カスタマイズしない、SaaSを利用（基盤）※深堀りすると色々ありそう
DX1 P4 既存システムを運用・保守できる人材が枯渇し、セキュリティ上のリスクが高まる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P4 IT システムの見直しには、デジタル技術を活用してビジネスをどのように変革するかについての経営戦略が必要 →経営戦略があること（その他）
DX1 P4 実行する上での体制や企業組織内の仕組みの構築等が不可欠 →推進体制があること（その他）
DX1 P5 新たなデジタル技術を活用して、どのようにビジネスを変革していくかの経営戦略そのものが不可欠 →経営戦略があること（その他）
DX1 P6 データを収集・蓄積・処理する IT システムが、環境変化、経営・事業の変化に対し、柔軟に、かつスピーディーに対応できることが必要 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P6 「レガシーシステム」となり、DX の足かせになっている状態が多数みられる
DX1 P6 「ドキュメントが整備されていないため調査に時間を要する」※レガシーシステムの定義 →設計、運用ドキュメントが整備されていること(共通)
DX1 P6 「レガシーシステムとのデータ連携が困難」※レガシーシステムの定義 →他システムとデータの連携が可能なこと(共通）
DX1 P6 「影響が多岐にわたるため試験に時間を要する」※レガシーシステムの定義 →システムが疎結合であること？システムがモジュール化されていること？構成管理の自動化？(SoE)※深堀りすると色々ありそう
DX1 P7 「技術的な制約や性能の限界がある」※レガシーシステムの定義 →スケールアウトが可能(SoE)
DX1 P7 「有識者がいない、ブラックボックス化しているため触れたくない」※レガシーシステムの定義 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P7 「維持・運用費が高く、改修コストを捻出しにくい」※レガシーシステムの定義 →運用・保守コストが低いこと（共通）スケールアウト・イン、運用自動化（SoE）、カスタマイズしない、SaaSを利用（基盤）※深堀りすると色々ありそう
DX1 P7 「分析に必要なデータが不足している、ない」※レガシーシステムの定義 →経営戦略を建てる上で必要なデータが揃っていること（共通)
DX1 P7 「特定メーカーの製品・技術の制約があり、多大な改修コストが」※レガシーシステムの定義 →特定ベンダ固有の機能を使用してないこと（共通)
DX1 P7 「特定技術に関する技術者を確保するのに、多大なコストがかかる」※レガシーシステムの定義 →特定ベンダ固有の機能を使用してないこと、人材のスキルを管理していること、人材育成ルールが整備されていること（共通)
DX1 P7 「メーカーのサポートが切れており触れたくない」※レガシーシステムの定義 →システムのライフサイクルが管理可能なこと（共通）SaaSの利用（基盤）
DX1 P7 データを最大限活用すべく新たなデジタル技術を適用していくためには、既存のシステムをそれに適合するように見直していくことが不可欠 →短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P7 「自社システムの中身がブラックボックスになってしまったこと」※レガシーシステムの定義 →設計、運用ドキュメントが整備されていること、人材のスキルを管理していること、人材育成ルールが整備されていること(共通)
DX1 P7 「ユーザ企業において、自社システムの中身が不可視になり、自分の手で修正できない状況に陥ったこと」※レガシーシステムの定義 →設計、運用ドキュメントが整備されていること、人材のスキルを管理していること、人材育成ルールが整備されていること(共通)
DX1 P7 システム全体が一体化した古いアーキテクチャや開発技術はメンテナンスによって肥大化、複雑化する傾向にあり →システムがモジュール化されていること(SoE)
DX1 P7 開発から時間が経っているためレガシー化の確率が上がる →システムのライフサイクルが管理可能なこと、定期的にシステムの見直しを行っていること（共通）
DX1 P7 開発から時間が経っている場合、レガシー問題の発生確率は上がる →システムのライフサイクルが管理可能なこと、定期的にシステムの見直しを行っていること（共通）
DX1 P8 不十分なマネジメントによるレガシー化の繰り返し(レガシーシステム問題はマネジメントの問題でもある) →マネジメントの問題（その他）
DX1 P8 単純なリホストや、プログラムのコンバージョンだけでは、一時的にはコストは下がっても、本質的には「ブラックボックス化」は解消されていない →要件に応じたシステム構成となっていること？（共通）
DX1 P8 ウォーターフォール型開発への根本的な見直しが起こった →要件に応じた開発モデルを採用していること（共通）
DX1 P9 システム刷新（モダナイズ）のときに求められるのは必ず「要件定義」であり、精緻な要件定義が根本的に困難な状況から、曖昧なままシステム刷新・改修が進められ、トラブルの原因となる →システムの要件が明確になっていること（緻密である必要はないが曖昧さがあるのはNG）（共通）
DX1 P9 レガシーシステムの問題を経営課題として、真正面から取り組まないまま時間が経過してしまっている →情報システムを経営課題として管理していること（その他）
DX1 P9 各事業の個別最適化を優先してきたため、企業全体の最適化が図られなかった →経営に必要なデータが集中管理されていること、、各部門で容易にデータの利用が可能なこと（共通）※深堀りすると色々ありそう
DX1 P9 システムが複雑となり、企業全体での情報管理・データ管理が困難となっている。 →企業全体で情報管理・データ管理が可能なこと（共通）
DX1 P9 データ・情報資産を数多く保有しているにも関わらず、連携が難しく、活用しきれていない、全社最適に向けての活用が困難になっている →企業全体の最適化が図られているシステムであること、経営に必要なデータが揃っていること、各部門で容易にデータの利用が可能なこと、複数システム間でデータ連携が可能なこと（共通）※深堀りすると色々ありそう
DX1 P9 ユーザ企業の内部に情報システムに関するノウハウが蓄積しにくい。 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P9 諸外国のようにユーザ企業が社内に IT エンジニアを抱えて、開発を主導している場合は、高頻度でかつ小規模に（細かく）プログラムをメンテナンスしつづける形態が一般的になる。 →短期間での機能追加・機能変更が可能であること、継続的に機能追加していること（SoE)※深堀りすると色々ありそう
DX1 P9 短期間でメンテナンスを行い続ければ、結果的にブラックボックス化は起こりにくい →（意味不明）
DX1 P9 個人が持つノウハウもメンテナンスによって他のエンジニアに伝承しやすくなる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P9 メンテナンスをある程度の間隔でまとめて行っていくことになり、ベンダー企業側にノウハウが蓄積される。 →短期間での機能追加・機能変更が可能であること、継続的に機能追加していること（SoE)※深堀りすると色々ありそう
DX1 P9 この形態では、要求仕様を整理・調達し、契約を結び、ウォーターフォール型開発を行うので時間もかかる。 →短期間での機能追加・機能変更が可能であること、継続的に機能追加していること（SoE)※深堀りすると色々ありそう
DX1 P10 大規模なシステム開発を行ってきた人材が定年退職の時期を迎え、人材に属していたノウハウが失われ、システムのブラックボックス化が起きている →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P10 ユーザ企業においては、IT システムに関するノウハウをドキュメント等に形式知化するインセンティブは弱い。そのため、ノウハウが特定の人の暗黙知に留まっている。 →設計、運用ドキュメントが整備されていること(共通)
DX1 P10 特定の技術者が「有識者」として居続ければ、組織としての管理がおざなりになってしまう※ユーザ企業 →設計、運用ドキュメントが整備されていること(共通)、人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P10 国内にはスクラッチ開発を好むユーザ企業が多い。スクラッチ開発であるが故に、個々のシステムに独自ノウハウが存在するようになってしまう →システムが共通化されていること(SoE)、SaaSやパッケージを利用すること（基盤）※深堀りすると色々ありそう
DX1 P11 現状業務にぴったり合った、実は過剰品質となっているシステムを求める声が国内企業には強い →システム化の際、業務を見直していること（SoE)、SaaSやパッケージを利用すること（基盤）
DX1 P11 汎用パッケージやサービスを活用している場合は、ユーザ企業内からノウハウがなくなったとしても、同様のノウハウを持つ人材は世界中に存在するため、対応は可能である →SaaSやパッケージを利用すること（基盤）
DX1 P11 汎用パッケージを導入した場合も、自社の業務に合わせた細かいカスタマイズを行う場合が多い。この結果、多くの独自開発が組み込まれることになるため、スクラッチと同様にブラックボックス化する可能性が高い →SaaSやパッケージを利用すること、パッケージを利用する場合は細かいカスタマイズをしないこと（基盤）
DX1 P11 品質管理（QC、QA)手法を積極的に取り入れ、これを元に現場力に磨きをかける「改善活動」に注力してきた。その結果は多くの成果を生むとともに、システム改修による複雑化の一因 →パッケージを利用する場合は細かいカスタマイズをしないこと（基盤）
DX1 P11 「改善活動」からのシステム改修はそのときの環境条件やユーザの利便性を追求したものが多く、「過剰サービス」「過剰品質」の要因 →パッケージを利用する場合は細かいカスタマイズをしないこと（基盤）
DX1 P11 ハードウェアやパッケージの維持限界がきたときにはじめて発覚する →システムのライフサイクルが管理可能なこと（共通）
DX1 P11 レガシー問題を根本的に解消しようとしても、長期間と大きな費用を要する上、手戻り等の失敗のリスクもある中で、根本的にシステム刷新をするインセンティブが生じにくい →経営の問題（その他）
DX1 P12 ユーザ企業のシステムが複数のベンダー企業により構築されている場合が多いため、１つのベンダー企業がシステムの仕様の違いやデータを完全に取得できず、複数のベンダー企業が関わるシステム全体を俯瞰することができないといった問題もある →設計、運用ドキュメントが整備されていること、システム間の連携がドキュメント化されていること(共通)※深堀りすると色々ありそう
DX1 P12 レガシー問題に対する改修プロジェクトは自社経営陣の理解を得にくく、現状の業務を大きく変更するわけではないので、システムの価値は高められるが、経営者から見て価値が見えにくい。将来的なリスクはあっても説明しにくい。 →経営者の問題（その他）、運用・保守コストが低いこと（共通）
DX1 P12 ハードウェア交換、ソフトウェアコンバージョンだけでは、ブラックボックス化は解消されない →要件に応じたシステム構成となっていること？（共通）
DX1 P12 新しいデジタル技術を導入して、新たなビジネスモデルを創出する →新しいデジタル技術が導入されていること（なんか違う）（SoE)
DX1 P13 我が国企業は米国企業に比べて、「業務効率化 / コスト削減」のための「守りの IT 投資」に重点を置いている →運用・保守コストが低いこと（共通）
DX1 P14 レガシーシステムの中には、短期的な観点でシステムを開発し、結果として、長期的に運用費や保守費が高騰している状態のものも多い →長期的な観点でシステム化すること、運用・保守コストが低いこと（共通）
DX1 P14 技術的負債は、経営上のリスクとして経営者が認識すべきものである。 →経営戦略の問題（その他）
DX1 P14 短期的な観点でのシステム開発とは、リリース時点では最善の仕様、技術を採用しているが、期限やコスト制約の中で本来取り込むべき機能が取り込めていない、もしくはリリース当時は最新だった技術が時代とともに劣化し、新たな技術が出てきているにも関わらずそれを採用しないことで新たな技術の恩恵を受けられていない →要件が明確化され実装されていること、要件に応じたシステム構成となっていること？（共通）
DX1 P15 技術的負債：メインフレームがそのまま残っている場合で、アプリの拡張やデータの抽出が高コストになっている状態 →短期間での機能追加・機能変更が可能であること（SoE)
DX1 P15 技術的負債：メインフレームをオープン化したものの、アプリがCOBOLのまま残存し、表形式のデータがテキストファイル形式で管理されていたり、Java等で再構築しても機能不足していたるする状態 →要件に応じたシステム構成となっていること？（共通）
DX1 P15 技術的負債：オンプレのシステムをそのままクラウド環境に移行したため、クラウドの利点を最大限活用できていない →要件に応じたシステム構成となっていること？（共通）
DX1 P15 IT コスト全体に対する運用経費の割合に着目してシステムを刷新 →運用・保守コストが低いこと（共通）
DX1 P15 IT 運用経費の削減に着目 →運用・保守コストが低いこと（共通）
DX1 P15 データが契約単位で管理されていたため、顧客ごとに、複数のサービスに関するデータを活用しての新たなサービス提供につなげることができなかった →必要なデータは一元管理されていること（共通）
DX1 P15 テーブル構造の見直し（契約単位の管理→顧客単位の管理）やバッチ処理の改善により、顧客ごとのサービス向上 →必要なデータは一元管理されていること（共通）
DX1 P15 ３０以上の各事業会社が有するシステムの機能を全て洗い出して整理し、業務プロセスの最適化も含めて経営全体のコミットの下でシステム刷新 →機能が重複したシステムがないこと（共通）
DX1 P15 グループ事業会社全体の IT リソースを集約し、共通システム基盤を構築 →システムが集約されていること、基盤部分は共通化されていること（プライベートクラウド？）（共通）
DX1 P15 コスト削減を実現。生産・販売プロセス等の全体最適化、グローバル対応を実現。また、当該基盤を活用し、量販店のＰＯＳデータをＡＩ分析することで高度需要予測を実施。社内の生産や出荷調整を最適化することで、量販チェーンの売上効率を最大化。 →システムが集約されていること、基盤部分は共通化されていること（プライベートクラウド？）、要件に応じたシステム構成となっていること？（共通）
DX1 P15 システムの連携・拡張を柔軟に行いやすくなった →短期間での機能追加・機能変更が可能であること（共通）スケールアウト（SoE）
DX1 P16 経営層の強いコミットがある。 →経営上の問題（その他）
DX1 P16 事業部ごとに個別最適されたバラバラなシステムを利用しており、全体最適化・標準化を試みても、各事業部が抵抗勢力となって前に進まない。 →経営上の課題（その他）、経営に必要なデータが集中管理されていること、、各部門で容易にデータの利用が可能なこと（共通）※深堀りすると色々ありそう
DX1 P16 既存システムの問題を解決するためには、業務自体の見直しも求められることになる →パッケージを利用する場合は細かいカスタマイズをしないこと（基盤）
DX1 P16 CEO としての価値が問われるので、自ら自社の IT システム、サイバーセキュリティの現状を把握し、将来へのビジョンを示さなければいけない →システムのライフサイクルが管理可能なこと（共通）
DX1 P17 CIO はベンダー企業を客観的に評価できることが重要な責務である →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 世に知られていないが、新たな価値を提供できるベンダー企業を使って結果を出す →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 我が国の CIO は有名なベンダー企業に頼んだから大丈夫という考えに陥りがち →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 ユーザ企業側の選定責任は不明確で、ベンダー企業側の責任となりがち →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 要求仕様や指示に抜け漏れや曖昧さがあっても、トラブルが起きると我が国ではベンダー企業の責任とされる →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 我が国では CIO や情報システム部門が、複数のベンダー企業の提案を受けて、自社のビジネスに適したベンダー企業を判断するよりは、これまで付き合いのあるベンダー企業からの提案をそのまま受け入れてしまいがち →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P17 システム投資を行うプロジェクトにおいては、事業部門と情報システム部門の役割分担も重要 →事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P17 システム投資を行う目的は、システムが開発できたかではなく、ビジネスがうまくいくようになったかどうかで判断されるべき →システムの要件が明確になっていること（共通）
DX1 P17 事業部門がプロジェクトのオーナーシップを持って、仕様決定、受入テスト等を実施していく →事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P17 事業部門と情報システム部門でコミュニケーションが十分にとられていない →事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P17 全社最適を実現する観点から、事業部門が業務をシステムに合わせることが求められる →システムの要件が明確になっていること（共通）
DX1 P17 ユーザ企業における IT 人材の不足が深刻な課題 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P18 ベンダー企業に経験・知見を含めて頼らざるを得ないというのが現状 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P18 業務プロセスや周辺システムとの関係を明確にして、将来あるべきシステムのビジョンを描くことが非常に重要 →システムの要件が明確になっていること（共通）
DX1 P18 ビジネス上どんな脅威に晒されているかを分析し、それに対して新しいデジタル技術で何ができるのかを企画できる人材 →システムの要件が明確になっていること（共通）
DX1 P18 今後、老朽化したシステムの仕様を把握している人材がリタイアしていくため、そのメンテナンスのスキルを持つ人材が枯渇していくことから、どのようにメンテナンスしていくかという課題 →設計、運用ドキュメントが整備されていること(共通)、人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P18 ユーザ企業としては、IT エンジニアの確保と教育も課題 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P18 要件定義から請負契約を締結するケースも少なくない。これは、ユーザ企業がベンダー企業に要件定義から丸投げの状態になってしまっており、そもそも何を開発するかをベンダー企業に決めてくれと言っていることと同じである →システムの要件が明確になっていること（共通）、ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P19 ユーザ企業は企業として何をやりたいかを示すことが重要 →システムの要件が明確になっていること（共通）、ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P19 要件を確定するのはユーザ企業であるべきことを認識する必要がある →システムの要件が明確になっていること（共通）、ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P19 ユーザ企業とベンダー企業との間の責任関係や作業分担等を明確にしておく必要がある →ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P19 ユーザ企業自身が現行システムがどのくらい肥大化・複雑化しているのか分からず、現行の仕様も不明確であるにも関わらず、現行機能保証という条件でシステム刷新をベンダー企業に業務委託する場合が多い →システムのライフサイクルが管理可能なこと（共通）、設計、運用ドキュメントが整備されていること(共通)
DX1 P19 情報システム部門と事業部門や経営企画部門との十分な連携がないために、必要とする要件を明確化できないまま発注することもある →事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P20 要求仕様が不明確な状態で小刻みな開発を繰り返すことで具体化していくような案件もある →要求仕様が不明確な場合はアジャイル開発を利用する（SoE)
DX1 P20 そのような開発方法に沿った契約形態が整備されていないという課題がある →その他
DX1 P20 ユーザ企業のアジャイル開発に対する理解が低い場合、ユーザ企業とベンダー企業との間に協調が生まれにくい →その他
DX1 P20 ユーザ企業にとってはどのような機能が必要になるかということをベンダー企業に任せればよいと誤解することがあり、プロダクトのオーナーシップの責任まで放棄してしまうと、結果的に開発がうまく進まない →システムの要件が明確になっていること（共通）、ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P21 パブリッククラウドのように、企業の業務システムにも大きな影響を与えるような、新しい基盤技術の変化も急速に進んでいる。 →要件に応じたシステム構成となっていること？（共通）
DX1 P22 垂直統合的に IT システム構築に必要なほとんどの機能を提供するメガクラウドによって、個別開発すべき部分を圧縮し、IT 投資効率を高めることがグローバルスタンダードとなる可能性もある →要件に応じたシステム構成となっていること？（共通）
DX1 P22 グローバルクラウドプレーヤーは IT システム構築に必要な機能の全体を内製化し垂直的に統合化する方向にある。各機能の個別調達に比べて、コストは削減され、機能適用の迅速化など、システムの競争力はさらに高まる →要件に応じたシステム構成となっていること？（共通）
DX1 P22 基盤ソフトウェアは IaaS としてグローバルクラウドに、アプリケーションは SAP 等のクラウドエコシステムに標準化されることで、ユーザ企業にとっても本質的には IT投資効率の向上が期待される。 →要件に応じたシステム構成となっていること？（共通）
DX1 P22 クラウド型データセンターの普及は、ユーザ企業におけるサーバの設置や調整作業が不要となるため、従来のシステム開発スタイルを大きく変えることが見込まれる。 →要件に応じたシステム構成となっていること？（共通）
DX1 P23 顧客接点を高度化するシステム（SoE = Systems of Engagement）の領域では、顧客を起点として、変化し続ける顧客ニーズや行動パターンに柔軟に対応するシステムであることから、要件が常に変化することが前提となり、IT システムが顧客との絆（engagement）を強化することを目的とする。 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P23 DX を推進するためには SoR、SoE 両方のバランスをとることが求められ →要件に応じたシステム構成となっていること？（共通）
DX1 P23 ITエンジニアのスキルシフトが必要とされ →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P24 要件変更を前提とした開発への対応ができるアジャイル開発の活用 →要求仕様が不明確な場合はアジャイル開発を利用する（SoE)
DX1 P24 システムを小さな機能に分割し、短いサイクルでリリースができる →システムは小さな機能に分割されていること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P24 API/Web API ベースの疎結合構造によるモジュール化されたサービスの利用による、大規模システムのコストとリスクの大幅な圧縮と変化への適用性の向上 →疎結合であること、モジュール化されていること（SoE)
DX1 P24 ベンダー企業は変化の速いデジタル技術にキャッチアップできる人材を活用してユーザに価値を提供することが求められる。 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P24 新たなビジネス・モデルの創造・既存システム最適化を進める上では、ユーザ企業もベンダー企業も単独では取り組めない課題に直面している →ユーザ企業・ベンダ企業が連携してシステムを構築すること（その他）
DX1 P24 顧客が提示する仕様に合わせたシステム開発の受託者から、新しいビジネスモデルを顧客と一緒に考えるパートナーへの転換が求められている →ユーザ企業・ベンダ企業が連携してシステムを構築すること（その他）
DX1 P24 既存システムの運用とメンテナンスは年々コストが増大するのみならず、歴史的に積み上げられてきた機能に対して、全貌を知る社員が高齢化したり、退職したりして、更新におけるリスクも高まっている。 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P25 業務やプラットフォームなどの変更ごとに追加・改修が行われてきた中、コストの全体最適化ができていないことに加えて、機能の全体像を把握している社員も減り、プラットフォームのサポート終了などの事態が発生したときの改修に伴うリスクが高くなっている　→人材のスキルを管理していること、人材育成ルールが整備されていること（その他→システムのライフサイクルが管理可能なこと（共通）
DX1 P25 (技術的な困難さ）巨大化したシステム →システムは小さな機能に分割されていること（SoE)※深堀りすると色々ありそう
DX1 P25 (技術的な困難さ）バラバラな基盤、保守体制 →プラットフォームが共通化され、保守体制も共通化されていること（共通）
DX1 P25 (技術的な困難さ）本来の要件をもはや誰も覚えていない →→要件に応じたシステム構成となっていること？（共通）システムのライフサイクルが管理可能なこと（共通）
DX1 P25 ハードウェア、ソフトウェアともに、重要製品の製造中止やサポート終了が起こることで、現行機能の維持そのものが困難になる →システムのライフサイクルが管理可能なこと（共通）
DX1 P25 汎用系の処理系サポート終了により、将来のシステム維持管理が困難になる。違う言語による再構築に追い込まれる →システムのライフサイクルが管理可能なこと（共通）
DX1 P26 あらゆる産業において、新たなデジタル技術を活用して新しいビジネス・モデルを創出し、柔軟に改変できる状態を実現することが求められている。 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P26 ベンダー企業は、既存システムの運用・保守にリソースを割かざるを得ず、成長領域であり主戦場となっているクラウドベースのサービス開発・提供を攻めあぐねる状態になる →運用・保守コストが低いこと（共通）
DX1 P28 DX を実行していくに当たっては、データの利活用が鍵となる。そのため、データを蓄積・処理する IT システムが、環境変化、経営・事業の変化に対し、柔軟に、かつスピーディーに対応できることが必要である。 →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P28 その基盤たる企業データの利活用・連携が限定的である →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P28 DX を進める上で、データを最大限活用すべく新たなデジタル技術を適用していくためには、既存のシステムをそれに対応できる形に見直していくことが不可欠である。 →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P28 「DX 推進システムガイドライン」を策定する→実際に公開されたのは、「DX推進ガイドライン」でシステムが抜けてる
DX1 P29 DX 推進システムガイドラインの構成案：（失敗ケース）経営者が明確なビジョンがないのに、部下に丸投げして考えさせている →経営者が明確なビジョンを示すこと（その他）
DX1 P29 DX 推進システムガイドラインの構成案：（失敗ケース）ビジネスの観点で困っていることが何か、あるべき姿が何かを考えずに刷新に踏み切る →システムの要件が明確になっていること（共通）
DX1 P29 DX 推進システムガイドラインの構成案：（失敗ケース）システム刷新には経営者のコミットが必要であり、情報システム部門にのみ任せることは失敗のもと →経営者が明確なビジョンを示すこと（その他）
DX1 P30 DX 推進システムガイドラインの構成案：仮説検証の繰返しプロセスが確立できているか →開発プロセスが明確になっていること（その他）
DX1 P30 DX 推進システムガイドラインの構成案：仮説検証の繰返しプロセスをスピーディーに実行できること →開発プロセスが明確になっていること（その他）
DX1 P30 DX 推進システムガイドラインの構成案：実行して目的を満たすかどうか評価する仕組みとなっていること →開発プロセスが明確になっていること（その他）
DX1 P30 DX 推進システムガイドラインの構成案：事業部門がオーナーシップを持って、仕様決定、受入テストを実施する仕組みになっているか →開発プロセスが明確になっていること（その他）事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P30 DX 推進システムガイドラインの構成案：事業部門と情報システム部門の間でコミュニケーションが十分にとれる仕組みとなっているか →開発プロセスが明確になっていること（その他）事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P30 DX 推進システムガイドラインの構成案：業務や製品に問題の原因がある場合、業務や製品自体の見直しを行っているか →システム化の際、業務を見直していること（SoE)
DX1 P30 DX 推進システムガイドラインの構成案：ユーザ企業は、複数のベンダー企業の提案を受けて、自身のビジネスに適した提案を自ら選択・判断できているか →システムの要件が明確になっていること（共通）
DX1 P30 DX 推進システムガイドラインの構成案：ユーザ企業とベンダー企業が責任分担を明確にしつつ、ユーザ企業は、企業として何をやりたいかを示しているか →システムの要件が明確になっていること（共通）
DX1 P31 DX 推進システムガイドラインの構成案：システムができたかどうかではなく、ビジネスがうまくいったかどうかで評価する仕組みとなっているか →システムの要件が明確になっていること（共通）
DX1 P31 DX 推進システムガイドラインの構成案：IT システムやその投資に対する経営の観点からのガバナンスが効く仕組みとなっているか →システムのライフサイクルが管理可能なこと（共通）
DX1 P31 DX 推進システムガイドラインの構成案：情報資産の現状を分析・評価できているか →システムのライフサイクルが管理可能なこと（共通）
DX1 P31 DX 推進システムガイドラインの構成案：どのデータをどのシステム、環境に移行するかの仕分けやプランニングができているか →システムの要件が明確になっていること（共通）システムで使うデータが明確になっていること（共通）
DX1 P31 DX 推進システムガイドラインの構成案：例）頻繁に変更が発生し、ビジネス・モデルの変化に活用すべき機能は、クラウド上で再構築 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること、クラウドの利用（SoE)※深堀りすると色々ありそう
DX1 P31 DX 推進システムガイドラインの構成案：例）変更されたり、新たに必要な機能は、クラウドへ追加 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること、クラウドの利用（SoE)※深堀りすると色々ありそう
DX1 P31 DX 推進システムガイドラインの構成案：例）肥大化したシステムの中に不要な機能があれば、廃棄 →システムの要件が明確になっていること（共通）システムのライフサイクルが管理可能なこと（共通）
DX1 P31 DX 推進システムガイドラインの構成案：例）今後、更新があまり発生しないと見込まれる機能は、その範囲を明らかにして、塩漬け →システムの要件が明確になっていること（共通）システムのライフサイクルが管理可能なこと（共通）
DX1 P31 DX 推進システムガイドラインの構成案：ユーザ企業における非競争領域、すなわち協調領域には、標準パッケージの導入や業種ごとの共通プラットフォームの利用等、コスト削減や競争領域へのリソースの重点配分を図っているか →SaaSやパッケージを利用すること（SoR、基盤）
DX1 P31 DX 推進システムガイドラインの構成案：IT システムについても、廃棄すべきものはサンクコストとしてこれ以上 コストをかけず、廃棄できているか →システムのライフサイクルが管理可能なこと（共通）
DX1 P31 DX 推進システムガイドラインの構成案：レガシー刷新後のシステムには、新たなデジタル技術が導入され、ビジネス・モデルの変化に迅速に追従できるようになっているか →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P31 DX 推進システムガイドラインの構成案：（先行事例）ビジネス上頻繁に更新することが求められるものについては、マイクロサービス化によって細分化しながらアジャイル開発により刷新していくアプローチもある。これによ り、リスクも軽減できる可能性もある →システムのモジュール化（SoE)
DX1 P31 DX 推進システムガイドラインの構成案：業務の簡略化や標準化を行い、システムのカスタマイズコストと それを実施することによる経営のメリットのバランスを評価しているか →システムの要件が明確になっていること（共通）
DX1 P32 DX 推進システムガイドラインの構成案：経営者は、関係事業部門や情報システム部門とともに、プロジェクトを管理して、問題発生時には経営層が迅速に対応策の検討、意思決定を行っているか。 →経営者が明確なビジョンを示すこと（その他）、事業部門と情報システム部門で連携してシステム開発を行うこと（その他）
DX1 P32 DX 推進システムガイドラインの構成案：DX の取組は、完了するものではなく、環境やビジネス・モデルの変化に合わせて、継続的に行われるものになっているか →システムの要件が明確になっていること（共通）システムのライフサイクルが管理可能なこと（共通）
DX1 P32 ユーザ企業自身が IT システムの全体像を把握できるように、「見える化」指標と診断スキームを構築する。 →システムのライフサイクルが管理可能なこと（共通）
DX1 P32 コストや時間といったリスクを評価する以前に、自社の情報資産を正確に把握できていないため、どこに課題があり、どのように構築していけばよいか判断がつかないことが挙げられる。 →システムのライフサイクルが管理可能なこと（共通）
DX1 P33 このため、企業の DX の推進の足かせになっている既存システムのアセスメント（情報資産の「見える化」）は、経営者がシステム刷新を決断する上で、非常に重要である。 →システムのライフサイクルが管理可能なこと（共通）
DX1 P33 、経営者自らの理解を高めるべく、ベンダー企業やコンサルティング企業各社が評価を行うに先立って、簡易な形で統一的に情報資産を「見える化」する指標とそれに基づく診断の仕組みの構築が必要である。 →システムのライフサイクルが管理可能なこと（共通）
DX1 P34 既存システムがブラックボックス化してしまった要因として、ITシステムに対するガバナンスが機能していなかったことが挙げられる →システムのライフサイクルが管理可能なこと（共通）
DX1 P34 情報資産の診断については、以下の理由から、ユーザ企業およびベンダー企業双方から中立的な立場で客観的に診断する仕組みが必要である →中立な情報資産の診断サービスを提供すること（ベンダ）
DX1 P34 診断に当たっては、情報資産の「見える化」に加え、IT システムを刷新するに当たっての体制・仕組みや実行プロセスの状況についても評価を行うことが必要である →診断サービスでは左記の対応を行うこと（ベンダ）
DX1 P36 ビジネス上頻繁に更新が求められる機能については、レガシー刷新後のシステムにおいて新たなデジタル技術が導入され、ビジネス・モデルの変化に迅速に追従できるようになっている必要がある。 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P36 刷新後の目標設定については、経営者、事業部門、情報システム部門等プロジェクトに関わるすべてのステークホルダが認識を共有していることが重要である。 →システムの要件が明確になっていること（共通）
DX1 P36 不要な機能を廃棄し、規模と複雑度の軽減を図ること →システムの要件が明確になっていること（共通）
DX1 P36 経営環境の変化に対応して、事業ポートフォリオを柔軟に見直し、そのために資産の入れ替えも常に行っていくことが求められる →システムのライフサイクルが管理可能なこと（共通）
DX1 P36 、情報資産の現状を分析・評価し、廃棄できるものの仕分けを行うことが重要 →システムのライフサイクルが管理可能なこと、常にシステムの見直しを行うこと（共通）
DX1 P37 ビジネス上頻繁に更新することが求められる機能については、刷新後のシステムにおいて、新たなデジタル技術が導入され、ビジネス・モデルの変化に迅速に追従できるようになっている必要がある。 →ビジネスの変化に追随可能なシステムであること、短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P37 システムがモジュール化された機能に分割され、短いサイクルでリリースができる状態にしていくことが求められる →システムはモジュール化すること（SoE）短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P37 ビジネス上頻繁に更新することが求められる機能については、システム刷新における移行時において、マイクロサービス化することによって細分化し、アジャイル開発方法により段階的に刷新するアプローチも考えられる →システムはモジュール化すること（SoE）
DX1 P37 企業の競争力に関わらない協調領域については、個社が別々にシステム開発するのではなく、業界毎や課題毎に共通のプラットフォームを構築することで早期かつ安価にシステム刷新につなげることができると考える →共通プラットフォームを構築すること（SoR）
DX1 P37 、製品やサービスの競争力に寄与しない非競争領域については、業界内外を含めて業務の共通化やシステムの共通化を図っていき、複数の企業が共同でシステムを構築すること →SaaSやパッケージを利用すること（基盤）
DX1 P38 協調領域の見極めを行う：共通プラットフォームを構築 →共通プラットフォームを構築すること（SoR）
DX1 P39 処理量が増加するアプリケーションを想定して、クラウドの上で使いながらスケールアウトにより処理量の変化に迅速に対応可変とする →スケールアウト・インが可能なこと（SoE)
DX1 P39 アジャイル開発を活用して、小規模な機能からユーザに求められる機能を試用しながら、有効な機能やソフトウェアを探索的に作成し共通化機能として作り込む →短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P40 共通プラットフォームは複数の企業や団体が利用するため、参画するユーザ企業が当事者意識を持つことが本質的に重要である。このため、発注側の責任としての責任・役割分担を明記した契約内容を整備し、その記載内容にコミットして共同利用に参画する形とすべきである →発注側の責任としての責任・役割分担を明記した契約内容を整備すること、その記載内容にコミットして共同利用に参画する形とすること（SoR)
DX1 P40 グローバルで通用する技術（オープンソース等）を利用する →ベンダ固有の技術を使わないこと、グローバルで通用する技術を採用すること（共通）
DX1 P40 既存システムの刷新が実行され、既存システム上のデータを活用した本格的な DX が可能になる →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P40 人材や資金等のリソース配分においても、既存システムの維持管理に投資されていたものを、新たなデジタル技術の活用による迅速なビジネス・モデル変革に充当することができるようになる →運用・保守コストが低いこと（共通）
DX1 P41 ベンダ企業：システムの維持管理のために投入されていた人材・資金が解放され、これらのリソースを最新のデジタル技術を活用したサービス提供に配分する →運用・保守コストが低いこと（共通）
DX1 P41 ベンダ企業：常に進歩し続ける最前線のデジタル技術の分野で競争力を維持し続けることが重要になる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P41 ベンダ企業：AI 等を活用したクラウドベースのアジャイル開発によるアプリケーションの提供 →意味不明な例なので略
DX1 P41 ベンダ企業：ユーザ企業が行うアジャイル開発に対するコンサルティング、最先端技術の提供 →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P41 ベンダ企業：要件変更を前提とした対応ができるアジャイル開発を活用できる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P41 ベンダ企業：システムを小規模でモジュール化された機能に分割し、短サイクルリリースができる →システムはモジュール化すること（SoE）短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P41 ベンダ企業：API/Web API ベースの疎結合構造により小規模サービス化 →システムはモジュール化すること（SoE）短期間での機能追加・機能変更が可能であること（SoE)※深堀りすると色々ありそう
DX1 P41 ベンダ企業：受託業務から脱却し、最先端技術活用の新規市場を開拓し、アプリケーション提供型のビジネス・モデルに転換していくこと →その他（その他）
DX1 P41 ベンダ企業：ユーザ企業と協働しつつプロダクトを開発し、そのプロダクト開発における資産・知財をベンダー企業が保有し、他の顧客にも販売していく →その他（その他）
DX1 P42 契約面においても、必要な見直しを行っていくことが求められる →その他（その他）
DX1 P42 自社のリソースの充実に加え、他社とのパートナーシップを強化していくこと →その他（その他）
DX1 P42 要件定義工程と設計開発工程を分離することを明確化する →要件定義工程と設計開発工程を分離すること（その他）
DX1 P42 ユーザ企業による要件定義の丸投げを防止できるようにする。 →システムの要件が明確になっていること（共通）、ユーザ企業が主導権を握ってシステム開発すること（その他）
DX1 P43 ユーザ企業、ベンダー企業双方がアジャイル開発に対する理解を十分に共有すること →その他（その他）
DX1 P46 求められる人材スキルを整理し、必要な対応策を講じていくことが必要である →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 業務内容にも精通しつつ IT で何ができるかを理解し、経営改革を IT システムに落とし込んで実現できる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 各事業部門においてビジネス変革で求める要件を明確にできる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 ビジネス変革で求められる要件をもとに設計、開発できる →→人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 求められる要件の実現性を見極めた上で、新たな技術・手法を使った実装に落とし込める →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 ユーザ起点でデザイン思考を活用し､UX(ユーザエクスペリエンス)を設計し､要求としてまとめあげる →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 ユーザ企業の人材にあっては開発手法を学び、ベンダー企業の人材にあっては開発に従事しながら業務を知る →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P47 IT 人材のスキルの明確化や、学び直しによる人材育成が進められることが期待される →人材のスキルを管理していること、人材育成ルールが整備されていること（その他）
DX1 P48 IT システム刷新は、経営者は中長期的な観点から実行の可否を検討することが求められる →経営者の問題（その他）
DX1 P48 IT システムは、経営戦略や業務に合わせて全体最適化を実現することが必要である →システムの要件が明確になっていること（共通）
DX1 P48 ユーザ産業、ベンダー産業全体が、人材や技術等の問題をも勘案して、一定の時間軸を共有し、DX 実現のためのシステム刷新 →その他（その他）
DX1 P52 データを最大限活用すべく、デジタル技術を駆使してビジネスを迅速に展開できる →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P52 様々な人やモノ、企業、産業等が相互に繋がることによってデータが流通し、新たな付加価値が創出され、社会課題が解決できる →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）
DX1 P53 新たなデジタル技術を用いてデータをフルに活用できる状態になり、新たなビジネス・モデルを生み出し続けるようになる →システムの持つデータの活用が可能なこと、他システムとデータの連携が可能なこと(共通）

### DX2 1～4章
* DX2 P3　DXの本質とは、単にレガシーシステムの刷新・高度化ではなく、事業環境の変化に迅速に適応する能力を身につけること、その中で企業文化（固定観念）を変革（レガシー企業文化からの脱却）すること
* DX2 P3　DX変革は、経営トップが自ら変革を主導することが必要
* DX2 P4　企業がレガシー企業文化から脱却し、変化に迅速に適応し続けるためには、DX推進について関係者間で共通理解の形成・社内推進体制の確立が必要
* DX2 P4　競合他社との協調領域を形成することや、DX推進にあたり対等な立場で伴走できる企業とのパートナーシップ構築が重要
* DX2 P4　ベンダー企業も従来の受託開発型のビジネスモデルからの脱却が必要
* DX2 P4　変革を遂行する人材の確保が必要
* DX2 P5　企業がデジタル技術を駆使して価値を創造し続けるデジタル企業への変革に加え、業種・業界ごとの縦割りの構造から、機能ごとの横割りの構造へと産業構造を変革する必要（引用元：Society5.0）
* DX2 P5　デジタル社会とは、価値創出の源泉が現実空間からサイバー空間へと移行。様々な企業や組織が連携し、社会課題の解決や新たな価値、体験の提供が迅速になされ、安心・安全な社会が実現。グローバルで活躍する競争力の高い企業や、カーボンニュートラルなど世界の持続的発展に貢献する産業が生まれる社会
* DX2 P5　DXレポート1は、2025年までにレガシー刷新に計画的に取り組む必要性とデジタル技術を前提とした企業経営の変革の方向性を指摘
* DX2 P8　経営視点指標では、平均的な企業は経営層による危機感・必要性の欠如に加え、適切なガバナンス、DX人材の育成・確保に関する成熟度に課題
* DX2 P8　IT視点指標では、経営のスピード・アジリティに対応したITシステムの構築や事業部門のオーナーシップに課題
* DX2 P8　DXの推進・デジタル化への取組は、既存ビジネスの範疇で行っており、経営の変革という本質を捉え切れていない。これを踏まえ、DXの加速に向けた施策の検討において、従前の方針とは異なるアプローチを採用する必要
* DX2 P12　ビジネスにおける価値創出の中心は急速にデジタル空間へ移行、今すぐ企業文化を刷新しビジネスを変革できない企業は、デジタル競争の敗者。デジタル技術によるサービスを提供するベンダー企業も、受託開発型の既存のビジネスモデルではこのような変革に対応できない
* DX2 P13　ビジネスにおける価値創出のためにデジタル技術を活用し、迅速性を持って変革し続ける企業がデジタル企業として競争優位を獲得
* DX2 P14　デジタル志向の顧客が増加している中、その変化に企業も対応することが必須
* DX2 P14　企業は顧客・社会の課題解決のための仮説となるプロダクトやサービスを繰り返し市場に提示し、データに基づいて顧客・社会の反応を把握しながら、迅速にプロダクトやサービス、その提供体制にフィードバックし続ける必要がある
* DX2 P14　DXの定義は、「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立する」こと（引用元：DX推進指標とそのガイダンス）
* DX2 P14　企業が競争上の優位性を確立するには、常に変化する顧客・社会の課題をとらえ、「素早く」変革「し続ける」能力を身に付けることが重要
* DX2 P14　企業は生き残りのために、中長期的な課題も見据えながら短期間の事業変革を達成し続ける必要がある。そのため、短期間で実現できる課題を明らかにし、ツール導入等によって解決できる足元の課題には即座に取り組み、DXのスタートラインに立つこと
* DX2 P15　競争優位の獲得という戦略的ゴールに向かって繰り返し変革のアプローチを続けることが企業に求められるDX
* DX2 P15　顧客や社会の課題の変化にあわせ柔軟・迅速に企業のITシステムを変革していくことが必要
* DX2 P15　デジタル社会において、ベンダー企業とユーザー企業は共に、高収益な領域で利益率の高いビジネスへとDXを推進していく必要がある。そのために、現行ビジネスの維持・運営から脱却、価値創造型のビジネスを行う
* DX2 P15　価値創造型ビジネスでは、ユーザー企業は絶えず変化する顧客のニーズに対応するために自社のITシステムを迅速に更新し続ける必要がある。最もニーズの高い機能を迅速に開発し、フィードバックしながら変化に迅速に対応できるアジャイル型開発でなければ変化の速さに対応できない
* DX2 P15　顧客や社会の課題を正確にとらえるため、ベンダー企業はユーザー企業とDXを一体的に推進する共創的パートナーとなっていくことが求められる
* DX2 P15　日本では、ベンダー企業自身が提供するITを強みとし、デジタル活用して新たな価値提案をする新ビジネス・サービスの提供主体となっていくことが期待される
* DX2 P15　顧客のビジネス変化が速く、要求も変化し続ける中で、将来のベンダー企業には、顧客企業と自社のDXをともに進めていくことが求められる
* DX2 P16　今後の新たなベンダー企業像
* (1) ユーザー企業の変革を共に推進するパートナー
• 新たなビジネスモデルを顧客と共に創出する
• DXの実践により得られた企業変革に必要な知見や技術を広く共有する
• レガシー刷新を含め、DXに向けた変革を支援する
* (2) DXに必要な技術・ノウハウの提供主体
• 最先端のデジタル技術等を習得し、特定ドメインに深い経験・ノウハウ・技術を有する専門技術者を供給する
• 専門家として、技術、外部リソースの組合せの提案を行い、デジタル化の方向性をデザインする
* (3) 協調領域における共通プラットフォーム提供主体
• 中小企業を含めた業界ごとの協調領域を担う共通プラットフォームをサービスとして提供する
• 高度なソフトウェア開発（システムの構築技術・構築プロセス・体制）を核にしたサービス化とエコシステムの形成を行う
* (4) 新ビジネス・サービスの提供主体
• ベンダー企業という枠を超え、デジタル技術を活用して新ビジネス・サービスの提供を通して社会への新たな価値提供を行う
* DX2 P17　デジタル企業への変革には、DXを推進する関係者間での共通理解の形成や社内推進体制の整備といった事業変革の環境整備に取り組む必要がある。また、DXは個社だけで実現できるものとは限らず、競合他社との協調領域の形成や変革を対等な立場で伴走できる企業とのパートナーシップの構築にも取り組む必要がある。さらに、これらの変革を遂行する人材の確保も必要。
* DX2 P17　コロナ禍のような急速な事業環境の変化に対し、最も迅速な対処策として市販製品・サービスの活用による迅速な対応を検討すべき。このようなツールの迅速かつ全社的な導入には経営トップのリーダーシップが重要
* DX2 P17　ツール導入が完了したからといってDXが達成されるわけではないことに留意する必要あり、短期的、中長期的対応の取組へと発展させるべき
* DX2 P17　製品・サービスの導入による事業継続・DXのファーストステップ
* (1) 業務環境のオンライン化
• テレワークシステムによる執務環境のリモートワーク対応
• オンライン会議システムによる社内外とのコミュニケーションのオンライン化
* (2) 業務プロセスのデジタル化
• OCR製品を用いた紙書類の電子化
• クラウドストレージを用いたペーパレス化
• 営業活動のデジタル化
• 各種SaaSを用いた業務のデジタル化
• RPAを用いた定型業務の自動化
• オンラインバンキングツールの導入
* (3) 従業員の安全・健康管理のデジタル化
• 活動量計等を用いた現場作業員の安全・健康管理
• 人流の可視化による安心・安全かつ効率的な労働環境の整備
• パルス調査ツールを用いた従業員の不調・異常の早期発見
* (4) 顧客接点のデジタル化
• 電子商取引プラットフォームによるECサイトの開設
• チャットボット等による電話応対業務の自動化・オンライン化
* DX2 P18　DXは製品・サービスの導入のみで達成されるものではなく、企業の経営者が自ら考え取組を進める必要がある
* DX2 P18　本レポート、DXレポート1、DX推進指標とそのガイダンス、デジタルガバナンス・コード、民間の事例集等を参考にDXの理解を深めることが重要
* DX2 P19　DX推進では、経営層、事業部門、IT部門が協働してビジネス変革に向けたコンセプトを描いていく必要がある
* DX2 P19　DXを推進する関係者の間で基礎的な共通理解を初めに形成することが必要
* DX2 P19　デジタルを用いたビジネス変革には、経営層の課題をデータとデジタル技術を活用していかに解決していくかという視点と、デジタルを活用することで可能となるまったく新たなビジネスを模索するという２つの視点がある。前者は経営層や事業部門が、後者はデジタル技術に詳しいIT部門が、互いに業務変革のアイディアを提示し、仮説検証のプロセスを推進することが求められる
* DX2 P19　対話をスムーズに実現するために、IT部門が経営層や事業部門と対等な立場で議論できるようマインド・環境を経営層が変えていく必要がある
* DX2 P19　関係者間での協働を促すために、アジャイルマインド（俊敏に適応し続ける精神）や、心理的安全性を確保すること（失敗を恐れない・失敗を減点としないマインドを大切にする雰囲気づくり）が求められる
* DX2 P19　CIO/CDXOがどのような役割・権限を担うべきか明確にした上で、DXを推進するための適切な人材が配置されるようにするべき
* DX2 P20　デジタル化に係る投資には、事業部門の業務プロセスの見直しを含めたIT投資の効率化にとどまらず、不要となる業務プロセスと対応するITシステムの廃止・廃棄にまでつなげることが必要、こうした決断には経営トップのリーダーシップが欠かせない
* DX2 P20　製品・サービスを短期間で市場に投入するスピードが重要、スピード確保のためシステムは「作る」よりは、他社を含めた既存のサービス等を「使う」、「つなげる」ことにより迅速に価値創出する発想が必要
* DX2 P20　デジタルの活用により、現実の場所を問わずに働くことが可能となるため、これを機に遠隔でのコラボレーションのあり方を議論していくことが重要
* DX2 P21　従業員の安全を確保するためにも、これまでの業務プロセスを抜本的に見直すことが必要
* DX2 P21　コロナ禍以前の「人が作業することを前提とした業務プロセス」を、デジタルを前提とし、かつ顧客起点で見直しを行うことにより大幅な生産性向上や新たな価値創造が期待できる。それに伴うシステムやデータについても見直しや廃棄することで、迅速なDXの実現が可能
* DX2 P21　業務プロセスが顧客への価値創出に寄与しているか否かという視点をもち、恒常的な見直しが求められる
* DX2 P21　DX推進指標の活用で、DXの推進状況について関係者間での認識の共有や、次の段階に進めるためのアクションを明確化することが可能。アクションの達成度を継続的に評価するためにもDX推進指標による診断を定期的に実施することが望ましい
* DX2 P21　自社の強みとは関係の薄い協調領域とビジネスの強みである競争領域を識別するとともに、協調領域におけるIT投資を効率化・抑制し、生み出した投資余力を競争領域へと割り当てていくことが必要
* DX2 P22　協調領域については自前主義を排し、経営トップのリーダーシップの下、業務プロセスの標準化を進めることでSaaS、パッケージソフトウェアを活用し、貴重なIT投資の予算や従事する人材の投入を抑制すべき
* DX2 P22　IT投資の効果を高めるために、業界内の他社と協調領域を形成して共通プラットフォーム化することも検討すべき
* DX2 P23　スモールスタートで迅速に仮説としての製品・サービスを市場に提示し、データドリブンで仮説検証を実施、その結果を用いて製品・サービスの改善へとつなげるというサイクルを繰り返すことで、より良い価値提案が可能。サイクルを短期間かつ効率的に実施できるかが重要
* DX2 P23　競争領域を担うシステム構築は、仮説・検証を俊敏に実施するため、大規模なソフトウェア開発を一括発注し長期間をかけて開発するのではなく、アジャイルな開発体制を社内に構築し、市場の変化をとらえながら小規模な開発を繰り返すべき
* DX2 P23　競争力を担うITシステムの開発体制については、企業が自ら変革を主導していくことが重要
* DX2 P23　開発体制の変革を確実に推進させるために対等な立場で活動してくれる企業や、必要な技術・ノウハウを提供してくれる企業とのパートナーシップを構築することが重要
* DX2 P25　ベンダー企業が内製開発へ移行するための支援や、伴走しながらスキル移転することに対するニーズが高まる。ベンダー企業はこうした事業機会を顧客企業への客先常駐ビジネスとするのではなく、対等なパートナーシップを体現できる拠点において、ユーザー企業とアジャイルの考え方を共有しながらチームの能力を育て（共育）、内製開発を協力して実践する（共創）べき
* DX2 P25　パートナーシップを維持することで、ユーザー企業の事業を深く理解し、新たなビジネスモデルをともに検討するビジネスパートナーへと関係を深化させていくべき
* DX2 P26　ITの強みを活かしながらデータとデジタル技術を活用して市場に新たな価値提案を行っていく中で、ユーザー企業のDXを起点に、ベンダー企業自身も変革していくことが重要
* DX2 P26　テレワーク環境下においても機能するジョブ型の雇用に移行する方向で考えるべき
* DX2 P26　とにかく雇用をジョブ型にすれば良いということではなく、まずはジョブ（仕事の範囲、役割、責任）を明確にし、そのうえでさらに成果の評価基準を定めることから始める
* DX2 P27　DX推進には、構想力を持ち、明確なビジョンを描き、自ら組織をけん引し、また実行することができるような人材が必要。この人材については（外部のベンダー企業に任せるのではなく）企業が自ら確保するべき
* DX2 P27　DX推進では、企業が市場に対して提案する価値を現実のシステムへと落とし込む技術者の役割が極めて重要
* DX2 P27　常に新しい技術に敏感になり、学び続けるマインドセットを持つことができるよう、専門性を評価する仕組みや、リカレント学習の仕組みを導入すべき
* DX2 P27　副業・兼業を行いやすくし、人材流動や、社員が多様な価値観と触れる環境を整えることが重要

### DX2 5～6章
* DX2 P28　企業がレガシーカルチャーから脱却して個社の DX を確実に前進させる
* DX2 P28　DXに関する共通理解の形成や DX 戦略の立案の支援といった「事業変革の環境整備」の支援に踏み込む必要がある。
* DX2 P28　個社のみでは対応しきれない顧客・社会課題を迅速に解決するためには、個社の垣根を越えた協調領域のプラットフォーム形成の支援や、デジタル市場の将来像を見据えた産業構造の再設計といった「デジタル社会基盤の形成」を促すべき
* DX2 P28　DX の推進においては、あるべき論を語るのではなく、自ら変革をけん引し現実の課題の解決や新たな価値の提案を推進するような、実行力のある人材が求められる。
* DX2 P28　過去の企業文化を打破するためには、新しい発想を持つ若手人材や外部人材が活躍できる環境整備も必要である。
* DX2 P28　デジタル社会を実現することによる恩恵が我が国全体にあまねく行き渡るためには、市場原理に委ねるだけでは解決が難しい産業変革が不可欠であり、地域の中小企業への支援も含めた「産業変革の制度的支援」も重要な取組
* DX2 P28　「事業変革の環境整備」「デジタル社会基盤の形成」「人材変革」「産業変革の制度的支援」の４つの領域において、政府の政策の方向性を示す。
* 事業変革の環境整備
* DXの認知・理解向上の必要性
* DX は地域・中央の差や企業規模の大小に関係なく成長のツールとなるものであり、こうした企業における DX の認知・理解向上策は重要である。
* DXの認知・理解を深めるための政府対応策
* DX の認知向上に向けては、デジタル化を行うきっかけとなるツールとして、事例集を作る
* DX の理解向上に向けては、共通理解形成のためのポイント集を活用する。
* 中小企業においては、DXを社内のリソースだけで推進することが難しいと考えられることから、DXに取り組む企業が集まり経験やノウハウの共有を通じて DX を推進する場の形成支援等を検討
* DX推進体制の整備の必要性
* 経営層、事業部門、IT 部門が対話を通じて同じ視点を共有し、協働してビジネス変革に向けたコンセプトを描いていく必要がある
* まずは経営者が、将来のビジネスを見据えた上で取組の方向性となるビジョンについて、関係者間の対話を通じて示すことが重要
* 、DX とは何か、会社のビジネスにどう役に立つのか、という基本的な事項についての共通理解が企業内で形成されておらず、DX という言葉を用いた場合に思い描くビジョン、コンセプトが様々な状況にあるため、具体的なアクションにつながらないという問題が見られる。
* DX推進体制の整備のための政府対応策
* DX の加速には経営層のマインドが重要であり、それらを社内外に発信・伝達するための対話が不可欠
* 関係者間での対話の中身の勘所を示すにあたり、企業が抱える課題（Why、What、How）それぞれの「分からない」を「分かる」にするための意識向上施策として、経営層向けに対話の中身をとりまとめた「ポイント集」を整理する
* CIO/CDXO の役割再定義
* DXを推進する経営レベルでのポジションとして CDO(Chief Digital Officer)やそれに類した CDXO を設ける企業が我が国でも増えてきている。
* CDO は DX の戦略策定とその遂行に責任を負うが、そのための役割としては主に次の３つがある。
* DX の戦略策定
* DX の戦略を推進するための全社的なコーディネーション
* DX 推進のための企業文化の変革
* これに対して、CIO は既存の IT システム一般を効率化すること等に責任があるとされる。
* DX 推進を経営レベルで推進できるようにするためには、CDO や CIO の役割を明確にする必要がある。
* CIO の役割を広く捉えた「平成 21 年度 IT 人材育成強化加速事業（CIO 育成カリキュラム策定事業）報告書」によると、目指すべき CIO 像として Chief Intelligence Officer、Chief Innovation Officer、Chief Information Officer としての３つのミッションと役割が定義されている（図 5-3）。この中で、Chief Innovation Officer の役割が主として CDXO の役割に相当する。
* 全社横断のビジネス変革：部門や組織を超えてグローバル全体を横断して、ITを生かした「ビジネスモデルの変革」「ビジネスプロセスの変革」を推進し、企業の競争力向上の貢献する
* CIO/CDXO の役割再定義に向けた政府対応策
* DX をけん引する経営層の機能として、こうした CxO が担うべき役割や、ガバナンスの対象事項について再定義を行うこととする。
* これにより、経営層や事業部門、現場等との意思疎通や合意形成が促進されるとともに、企業が DX を推進するにあたって適切な人材をアサインし、デジタル技術を有効に導入、活用できるようにする。
* DX 成功パターンの策定の必要性
* 二つの視点に基づいて DX に向けた戦略を立案する必要がある。
* ビジョンや事業目的といった上位の目標の達成に向けて、デジタルを使いこなすことで経営の課題を解決するという視点
* デジタルだからこそ可能になる新たなビジネスモデルを模索するという視点
* DX 成功パターンの策定の政府対応策
* DX の具体的な取組領域や、成功事例をパターン化し、企業において具体的なアクションを検討する際の手がかりとなる「DX 成功パターン」を策定する
* DX 成功パターンには、DX に向けた戦略の立案・展開にあたって前提となる「組織戦略」と「事業戦略」、「推進戦略」が含まれる
* 組織戦略：
* DX の成功事例のうち、組織の観点で特徴があるものに、経営者・IT 部門・業務部門が協調して推進する、というパターンがある。
* 企業の方針を決めるにあたっては、このような三位一体の対話によって共通認識を形成すべきである。
* 事業戦略：
* ：「顧客や社会の問題の発見と解決による新たな価値の創出」と、「組織内の業務生産性向上や働き方の変革」という二つのアプローチを同時並行に進めることが重要である。
* 既存事業の見直しにより産まれた投資余力を新事業の創出にあてることで、企業の競争力と経営体力を高めることが出来る。
* 推進戦略：
* 重点部門を見極め、小さく始めて、段階的に全社的な取組みに広げることを検討すべきである。
* まず重点部門で成功事例を作り出してから組織全体へ展開し、あわせて、DX を推進する上での課題を早期に明らかにしつつ対応する、というアジャイル的な DX の推進が成功への鍵となる。
* 企業が DX の具体的なアクションを組織の成熟度ごとに設計できるように、DXをデジタイゼーション、デジタライゼーション、デジタルトランスフォーメーションという 3 つの異なる段階に分解する
* デジタイゼーション
* アナログ・物理データの単純なデジタルデータ化　典型的には、紙文書の電子化
* デジタライゼーション
* 個別業務・プロセスのデジタル化
* デジタルトランスフォーメーション
* 全社的な業務・プロセスのデジタル化、および顧客起点の価値創造のために事業やビジネスモデルを変革すること
* これらはインダストリー4.0 等で定義されている構造と同一であり、世界的に共通に認識されている定義といえる
* DX の取組領域を明らかにするために、DX の各アクションを取組領域と DX の段階に分けて整理したものを、DX フレームワークとする
* P.36 図5-10を見た方がわかりやすい
* DX 推進状況の把握
* 既存の IT システムに関する技術的負債や DX 対応度合いを可視化し、対策が必要なシステムを特定するための指標として、プラットフォームデジタル化指標を策定する。
* システムを最適化する際にどのような技術が活用できるのかを整理して体系化したものとして、プラットフォーム変革手引書を策定する
* これらは情報処理推進機構（IPA）において、試行評価も含めて策定中であるが、早期の完成を目指す。
* デジタル社会基盤の形成
* 共通プラットフォーム推進
* 企業が経営資源を競争領域に集中するためには、個社が別々に IT システムを開発するのではなく、業界内の他社と協調領域を合意形成して共通プラットフォームを構築し、協調領域に対するリソースの投入を最小限にすべきである
* 共通プラットフォームを中心としたエコシステムの構築を最終的なゴールとするには、その中立性の担保が重要となる
* デジタルアーキテクチャ推進
* 個社のみでは対応しきれない顧客や社会の課題を迅速に解決するために、デジタル企業同士が横連携してエコシステムを形成できるデジタルプラットフォームを形成することが重要
* 異なる事業者間や社会全体でのデータや IT システムの連携を容易にするために、2020 年5 月、情報処理推進機構にデジタルアーキテクチャ・デザインセンターを設立
* 産業変革の制度的支援
* ツール導入に対する支援
* DX が進まない企業、または何から始めればよいかわからない企業にとっては、このような製品導入の成功を「経営のリーダーシップにより企業文化を変革する小さな成功体験」とし、DX のファーストステップと位置付けることが肝要である。
* 多くの中小企業では、DX 以前の問題として IT 機器の導入をはじめとするデジタイゼーションの段階にさえも進んでいないのが現状である。
* 産業変革のさらなる加速
* ユーザー企業とベンダー企業の共創の推進
* 企業がラン・ザ・ビジネスからバリューアップへ軸足を移し、アジャイル型の開発等によって事業環境の変化への即応を追求すると、その結果として、究極的にはユーザー企業とベンダー企業の垣根はなくなるとの方向性を見出している。
* デジタル技術を活用するビジネスモデル変革の支援
* デジタル技術を活用したビジネスモデルの変革に取り組むことが重要である。こうした取組の成功確率は低く、コストも大きいため、政府による後押しが必要である。
* DX 投資促進税制
* 中小企業向け DX 推進指標の策定
* DX 認定企業向けの金融支援
* 研究開発に対する支援
* リアルデータや AI を活用してビジネスモデルを転換する企業を支援するために、研究開発税制について見直しを実施
* 具体的には、控除上限を引き上げ、研究開発費を維持・増加させるための税額控除率の見直しを行うとともに、クラウドを通じてサービスを提供するソフトウェアに関する研究開発を対象に追加する。
* 人材変革
* リスキル・流動化環境の整備
* 各企業において社内の DX 活動をけん引する DX人材の存在が不可欠である。
* ここでいう「DX 人材」とは、自社のビジネスを深く理解した上で、データとデジタル技術を活用してそれをどう改革していくかについての構想力を持ち、実現に向けた明確なビジョンを描くことができる人材を指す。
* DX 人材には、社内外のステークホルダーを自ら陣頭に立ってけん引し、DX を実行することが求められる。
* 我が国においては人材の流動性が低い上に、IT 人材が IT 企業に偏在しているため、現時点において、ユーザー企業がDX を実行するために必要な人材を自らの組織内に十分に確保できる状況にはなっていない。
* 企業内で DX 推進のためにリカレント教育を行っている企業では、DX 人材の不足感が少なく、逆に、リカレント教育を行っていない企業では DX 人材の不足感が高いことが米国における調査で明らかになっている
* 社会全体として学び直し（リカレント教育）の仕組みを整備していくことが重要
* IT エンジニアによる新たな技術の習得等、継続的かつ頻繁にスキルをアップデート（リスキリング）する場をいかに提供するか
* 6章　DX レポートでの指摘とその後の政策展開
* P46　協調領域のクラウド・共通プラットフォーム活用、競争領域の内製化を進める
* P46　これにより、企業のバリューアップに資する IT 投資、経営の俊敏さが向上し、ユーザー企業で活躍する IT 人材が増加することが期待される。
* P46　ベンダー企業は受託型開発からサービス提供型等の高付加価値ビジネスへ移行することが求められる。
* P46　従前の IT 導入が効率化、コスト削減を主目的としていたのに対して、DX の本質的な価値は新たな価値創出である。
* P46　DX を実現する上では、ビジネス部門と IT 部門が一体となって戦略策定と実行、検証を繰り返していくことが重要であり、ビジネス戦略と IT システムを迅速かつ柔軟に対応させていくことが求められる。
* P46　データをいかに有効活用して新しい価値を創出するか、その基盤となるIoT（Internet of Things）の活用、CPS（Cyber Physical System）の構築、さらにビッグデータを管理できるクラウドコンピューティングの活用等が課題
* P47 データは複数の主体が共有して活用する方が多様な価値を提供できるという共有財としての側面が強いことが特徴
* P47 ユーザー企業、ベンダー企業共にそれに適した産業構造への転換を意識することが重要
* P47 既存システムは長年の仕様追加・変更や開発担当の変更等により、システムが複雑化したり、ブラックボックス化したりすることにより、技術的負債化しつつある。
* P47 ユーザー企業に起因する問題（経営の IT 知見の低さ、等）
* P47 ベンダー企業に起因する問題（関係の特殊性・ユーザー企業のベンダーロックインよる超過利潤享受による変革への誘因の低さ等）
* P48 企業において DX が進まない理由としては、以下が考えられる
* 企業において DX が進まない理由としては、以下が考えられる
* 多くのユーザー企業においては、ベンダー企業等の専門家に自社の DX を丸投げしており、そのためにデジタル技術について理解が不足している。
* デジタル技術について理解が不足しているが故に、ビジネス変革が中途半端なままである。
* 社内 IT 部門と経営や他部門の対話不足とそれに依るレガシーシステムの温存
* ユーザー企業においては、基本的に、社内の IT 部門が唯一知見を保有する。
* しかしながら、IT 部門と経営者、さらに事業部門との間で対話が不足している。
* 結果的に、ビジネスと IT の融合が必要な DX が進まず、IT 部門としても、レガシーなシステムを温存することとなる。
* 「DX が進まない理由」を生み出しているのは、企業において「DXは進めた方が良いと理解している」ものの、「自社は健全である」との誤認であるといえよう。
* P48 企業の行動を変容させるためには、以下の 2 点が必要となる。
* 企業の内面への働きかけ（認識の入れ替え）
* 企業が自社で、自社の DX 推進状況に対する立ち位置を客観的に把握し、（場合によっては）DX が進んでいないこと認識する。
* 周辺環境の整備
* 企業の外側から、DX 推進状況に対する評価を行うことで、DX を推進させる環境を整備する。
* P49 経済産業省は、DX 推進施策として企業の内面へ働きかけるための DX推進指標等の策定、および周辺環境の整備としてデジタルガバナンス・コードの策定とそれを用いた認定制度を施行している。
* P50 経営者に求められる企業価値向上に向け実践すべき事柄を「デジタルガバナンス・コード」として取りまとめた
* IT システムとビジネスを一体的に捉え、新たな価値創造に向けた戦略を描いていくこと
* ビジネスの持続性確保のため、IT システムについて技術的負債となることを防ぎ、計画的なパフォーマンス向上を図っていくこと