---
# System prepended metadata

title: Untitled

---

## 発表骨子
* 【１　講師から提示された課題の解釈】
    * 我々の課題：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




