## 発表骨子
* 【１　講師から提示された課題の解釈】
* 我々の課題：DXレポートを起点にDXの課題解決策を探る
* DXのあるべき姿、DX課題解決のための新たな価値やビジネスモデル
* モデリング→効果を検証

* １ 具体的な取り組み
* DXレポート１、２を読む
　　 * DXレポートでDXが進まない原因を考察
　　 * DXレポートを読んでも（こうしなさいとたくさん書いてあるが）、IT企業は実際にどうすればよいのか、何から始めればよいのか分からない
* 私たちのDXの定義（企業価値を高める）　言葉の定義(DX、SoE、SoR)
→企業価値を高めるために何か有効か？　ペルソナ定義、カスタマージャーニーマップ作成
→カスターマージャーマップから、企業内のデータ・システムがバラバラに管理されていることが問題と考えた（それにより、余計な稼働がかかって面倒）
→企業がDXの第一歩として目指すべきモデル、具体的な構築方法を提示
　　 * 企業の全てを理解するための仕組みづくり
　　　 →デジタライゼーションによるリアルタイムでの把握

* ２．目標　考案したビジネスモデルを構築するために必要な情報を整理、検証？
→企業がDXの第一歩として目指すべきモデル、具体的な構築方法を提示
　※共通領域における

* ３．全員が一軍
増本さん：
香月さん：
太田：

* 【2 モデル化】
* 1.課題をどの様に抽象化・モデル化したか
* DXレポートに記載があることを抽象化した
* →共通、SoR（業務共通）、SoE（競争）の３つに分けた
* →共通部分の細分化（必要なものを考える）

* ２．課題として扱わないこととした事象は何か
* SoR,SoEは対象外にした
* →SoEは各社で考える
* →SoRは業界ごとに考えてね

* ３．困難な点、工夫点
* （工夫点）
* Agileプラクティスのインセプションデッキを活用し、「我々はなぜここにいるのか」を定義するた我々の考えるDXとはを定義した
* （困難な点）
* DXレポートの中でも用語が統一されておらず、共通認識を合わせるのが大変だった

* 【3 アプローチ（手法・ツール）】
* 1 課題解決へのアプローチ、手法、ツールの選択や利用の方針をどう定めたか
* DXレポートを見た所、具体性がない
* →具体性を出すための手法を使う方針とした

* 2 どの様な背景・性質を考慮し、どの様な手法・ツールを選択したか
* 名詞抽出（要件抽出）：DXレポートが示す要件を抽出するために活用
* ペルソナ定義・カスタマージャーニーマップ：DXを進めたい人の気持ち、進まない原因を抽象化・モデル化するために活用
* もう一度名詞抽出（リソースの視点で抜き出す）？

* 3 どの様な効果期待し、どの様な手法・ツールを選択したか
*　DXレポートを具体化することを期待した

* 【4 評価】
* 1 アプローチ選択、モデル化、手法、ツールの適用の効果、効果の評価方法
* モデルの評価：ADD（設計）/ATAM(評価)
* GDTAモデルによる検証
* P16参照
* https://lms.topse.jp/pluginfile.php/17468/mod_folder/content/0/2021%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E6%80%9D%E8%80%83%E8%A6%81%E6%B1%82%E5%B7%A5%E5%AD%A6c.pdf?forcedownload=1
*　ビジネスの評価：ビジネスモデルキャンバス、バリュープロポジションキャンバス、マジックトライアングル、期間と収益のシミュレーション（システムダイナミックス／Vensim）
*　
* 2 取り組みの効果が目標に対してどの程度か
*
* 3 達成できなかった場合、その要因、どのようにすべてだったか
* 4 取り組みの成果、汎用性、一般性

* 【5 今後の課題】
* １．残された課題は何か？
　　 実際に誰がやるのか、ステークホルダの説得、予算

* ２．その課題はどのように取り組むえべきか？

* ユーティリティツリー
品質特性 関心事 重要性 難易度 シナリオ 品質要求抽出元 書いた人
セキュリティ 認証・認可 H H SaaS利用の認証・認可・監査を必須とする 　 グループ演習 増本
機能要件 　　システム間連携 　H M システムを利用する場合はSSO/MFA 　 グループ演習
　　システム間連携 　H M システム間が連携し無駄な事務作業を削減する 　グループ演習
・SaaSログインで勤務開始 グループ演習
・異動時に少額備品の変更も自動で実施 グループ演習
・インベントリ情報からライセンス数を自動で把握 グループ演習
・新規ユーザの各SaaSのアカウントは自動登録 グループ演習

採用手法 センシビティ（長所） トレードオフ（短所） リスク
SaaS利用の認証・認可・監査を必須とする 　 SaaSへのアクセスはIDaaS/CASBで認証認可する IDaas/CASBが落ちると使えなくなる
　CASBのログをSIEMで監視する
システムを利用する場合はSSO/MFA IDaaSを利用してSSO/MFA IDaaSが落ちると使えなくなる
SaaSログインで勤務開始 就業システムへの打刻が不要となる 　PCを使わないと勤務開始にならない
異動時に少額備品の変更も自動で実施 ユーザ管理システムと資産管理システムが連携する
インベントリ情報からライセンス数を自動で把握　装置管理システムと資産管理システムが連携する 自動でライセンス購入まで連携するかは別途相談
新規ユーザの各SaaSのアカウントは自動登録 IDaaSの機能で実施する 　自動でライセンス購入まで連携するかは別途相談

* ユーティリティツリー

| 品質特性 | 関心事 | 重要度 | 難易度 | シナリオ | 品質要求抽出元 | 書いた人 |
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| 性能 | | | | | | |
| 変更容易性 | 別SaaSへの移行 | L | M | 使用しているSaaSが陳腐化、サービス終了になった際に別のSaaSへ移行が可能 | グループ | 香月 |
| 可用性 | | | | | |
| セキュリティ | 認証・認可 | H | H | SaaS利用の際、認証・認可・監査を必須とする | グループ | 増本 |
| 保守性 | 俗人化の排除 | H | M | 利用しているシステムの運用保守の俗人化なくす | DXレポート1 | 香月 |
| 機能要件 | システム間連携 | H | M | システムを利用する場合はSSO/MFA | グループ | 増本 |
| | | H | M | システム間が連携し無駄な事務作業を削減する | グループ | 増本 |
| | | H | M | SaaSログインで勤務開始 | グループ | 増本 |
| | | H | M | 異動時に少額備品の変更も自動で実施 | グループ | 増本 |
| | | H | M | 新規ユーザの各SaaSのアカウントは自動登録 | グループ | 増本 |

* アーキテクチャ的手法
* IDaaSの活用により認証機能の一元管理（ゼロトラスト）
* CASB(クラウドサービスの利用状況を可視化/制御)の導入
* SIEM（ログ管理）導入により不正利用の検知
* SaaS・パッケージの活用（ノンスクラッチ）※DXレポートの主張
* 資産管理システムの導入によりクライアントPCを一元管理する

* シナリオ評価

| シナリオ | SaaS利用の際、認証・認可・監査を必須とする | | |
| -------- | -------- | -------- | -------- |
| | センシビティ（長所） | トレードオフ（短所） | リスク |
| IDaaSの活用により認証機能の一元管理（ゼロトラスト）| SaaSへのアクセスはIDaaSで認証することが可能 | | IDaasが落ちると全システムが使えなくなる |
| CASB(クラウドサービスの利用状況を可視化/制御)の導入 | SaaSへのアクセスはCASBで認可することが可能 | | CASBが落ちると全システムが使えなくなる |
| SIEM（ログ管理）導入により不正利用の検知 | | | |
| SaaS・パッケージの活用（ノンスクラッチ）※DXレポートの主張 | | | SaaS自体のセキュリティ強度に依存する |
| 資産管理システムの導入によりクライアントPCを一元管理する | | | |

| シナリオ | 異動時に少額備品の変更も自動で実施 | | |
| -------- | -------- | -------- | -------- |
| | センシビティ（長所） | トレードオフ（短所） | リスク |
| IDaaSの活用により認証機能の一元管理（ゼロトラスト）| ユーザ管理システム（IDaaS）と資産管理システムが連携し、いずれかの情報を変更すると双方に同期される | | |
| CASB(クラウドサービスの利用状況を可視化/制御)の導入 | | | |
| SIEM（ログ管理）導入により不正利用の検知 | | | |
| SaaS・パッケージの活用（ノンスクラッチ）※DXレポートの主張 | | 資産管理システムとユーザ管理システムの連携が可能なSaaS・パッケージの採用に限定される | |
| 資産管理システムの導入によりクライアントPCを一元管理する | ユーザ管理システム（IDaaS）と資産管理システムが連携し、いずれかの情報を変更すると双方に同期される | | |

| シナリオ | 使用しているSaaSが陳腐化、サービス終了になった際に別のSaaSへ移行が可能 | | |
| -------- | -------- | -------- | -------- |
| | センシビティ（長所） | トレードオフ（短所） | リスク |
| IDaaSの活用により認証機能の一元管理（ゼロトラスト）| - | 移行先のSaaSがSAML認証に対応している必要がある | |
| CASB(クラウドサービスの利用状況を可視化/制御)の導入 | | 移行先のSaaSがCASBに対応している必要がある? | |
| SIEM（ログ管理）導入により不正利用の検知 | - | 移行先のSaaSがSIEMに対応している必要がある | |
| SaaS・パッケージの活用（ノンスクラッチ）※DXレポートの主張 | | | |
| 資産管理システムの導入によりクライアントPCを一元管理する | | | |

| シナリオ | 利用しているシステムの運用保守の俗人化なくす | | |
| -------- | -------- | -------- | -------- |
| | センシビティ（長所） | トレードオフ（短所） | リスク |
| IDaaSの活用により認証機能の一元管理（ゼロトラスト）| - | - | IDaaSの運用が俗人化しないか？ |
| CASB(クラウドサービスの利用状況を可視化/制御)の導入 | | | |
| SIEM（ログ管理）導入により不正利用の検知 | - | | |
| SaaS・パッケージの活用（ノンスクラッチ）※DXレポートの主張 | システムの運用保守自体はSaaS提供ベンダーにて実施する為、導入企業での俗人化は防げる | SaaSベンダー内での俗人化は防げない | SaaSベンダーの仕様や対応方針に依存する |
| 資産管理システムの導入によりクライアントPCを一元管理する | | | |

* シナリオA（例
採用手法 センシビティ（長所） トレードオフ（短所） リスク
通信の暗号化 性能が劣化する XXXXX