As a service時代のitガバナンス

as a Service時代のITガバナンス
SAPジャパン株式会社
プラットフォーム事業部シニアソリューションプリンシパル
林⽥宏介
2017年9⽉20⽇

© 2017 SAP SE or an SAP affiliate company. All rights reserved. 2Customer
⾃⼰紹介
氏名：
林田宏介（はやしだこうすけ）
会社/肩書き：
SAPジャパン株式会社プラットフォーム事業部
シニアソリューションプリンシパル
経歴：
国内IT企業・外資系コンサルティング会社やクラウドベンダーで
システムの開発からアーキテクトを担当
現在はSAP Cloud Platformの製品担当として従事

⽬次
ITを取り巻く環境の変化
as a Service(クラウド)時代の到来
顧客ニーズの変化とビジネス環境への対応
複雑化するシステム開発プロセス
as a Service（クラウド）時代のガバナンス

⽬次

〜システム環境の変化〜
集中型システム
（メインフレーム/オフコン）
クラウド
（as a Service型）
時間の流れ
ガバナンス強度
分散コンピューティング
（CS/Web多層型）
l 特徴
Ø ウォーターフォール型プロセス
Ø 各⼯程と成果物が明確
Ø 仕様変更に弱い
Ø リリース期間が⻑い
l 特徴
Ø ウォーターフォール/繰り返し型プロセス
Ø 各⼯程と成果物は明確だが、モデリングベース
Ø 要求/変更管理モデルの反復型プロセスのため仕
様変更には⽐較的強い
Ø リリース期間は従来と⼤きく変わらない
l 特徴
Ø アジャイル/リーンスタート型プロセス
Ø 各⼯程と成果物は明確にはしない（プロ
ジェクトごとに変動）
Ø 仕様変更に強い
Ø リリース期間はとても早い
1出典：Wikipedia

〜クラウドの誕⽣〜
クラウドコンピューティングの誕⽣
グーグルの当時の最⾼経営責任者のエリック・シュミット⽒が、カリフォルニアで開かれた「サーチエンジン戦略会
議」の中での“「ブラウザの種類も、アクセス⼿段も、パソコンかマックか、携帯電話かも無関係です。“雲(クラウド)”
のような、巨⼤なインターネットにアクセスすれば、その利益、恵みの⾬を受けられる時代になっています」”という発
⾔が語源
これ以前にも、特にグループウェアを中⼼にインターネット上で利⽤できるアプリケーションサービスが、アプリケー
ションサービス事業者（ASP）から提供されていましたが、クラウドコンピューティング以降は、インターネットベー
スのサービス利⽤形態までサービス化が広がることになる
結果として、インフラからプラットフォーム、アプリケーションまで多種多様なサービスがインターネットで提供
as a Service時代の幕開け

◯
〜開発者を取り巻く環境の変化〜
専業制ではなく全体を⾒渡せるエンジニアが求められる
IT業界はシステムエンジニア・サーバーエンジニア・データベースエンジニアなど領域ごとに専⾨のエン
ジニアが存在する分業制でしたが、as a Service時代になり、幅広くこなせるフルスタックエンジニアが
求められるようになりました。
その背景にあるのは、従来は専⾨のスキルを重要視されていた領域が、as a Service化によってより⼿軽
に扱えるようになったこと、また複数のサービスを組み合わせて要件に合わせたシステムを構築すること
が主眼に置かれるようになったことがあげられます。
❌ 複数の領域をカバーできるエンジニア
1出典：Wikipedia
領域ごとに専任のエンジニア

⽬次

as a Service（クラウド）時代の到来
〜新しい形のスタートアップ企業の誕⽣〜
クラウドサービスが次々に誕⽣
インターネットで提供できるサービスというクラウドの特性を活かし、IaaS/PaaSなどのクラウドサービ
スを利⽤することで、データセンターなど資産を持たなくてもサービスを提供できるようになった。
そのため、新しいスタートアップ企業が出来上がり様々なサービスが展開されることとなる
クラウドファーストベンダーの登場
システム開発でもクラウド時代のクラウドファーストベンダーが台頭
その背景には、クラウド化によりこれまでハードウェア含むインフラ・運⽤など、どうしても⼤⼿でない
と難しかった領域も、クラウド環境下では⾃前でできるようになりエンジニアスキルだけで勝負が出来る
ようになったことに加え、クラウドでの開発はアジャイル開発が主体となり、俊敏性の⾼い会社の⽅が優
位性が出しやすいといった特性がある

〜既存ベンダーも参⼊しサービスの乱⽴化〜
クラウドサービスの乱⽴
クラウドコンピューティングがもともと、雲（インターネット）で提供されるサービスというそもそもの定義
が曖昧だった上に、各企業も⾃社のサービスを売るためにインターネットをネットワークという定義に解釈を
拡⼤して”クラウドサービス”として展開し始めたため、結果的にクラウドサービスの乱⽴状態となる
データセンターのホスティング+アウトソーシング/
マネージドサービスをプライベートクラウドサービスして提供
ソフトウェアベンダーが⾃社の製品をインターネットベースで提供
ASP事業者が⾃社のサービスをクラウドとして提供
インターネットをネットワークまで解釈を拡⼤既存サービスをクラウドとして提供
as a Serviceの乱⽴XXクラウドの乱⽴

◯❌
〜Everything as a Serviceへ〜
Everything as a Serviceという考え⽅へ
as a Serviceは何をサービスにしていい、かつ時代の進化により⾞や家電のみならず、腕時計やシャツなど
のウェアラブル製品にもセンサーが取り付けられ、様々なものがネットワークに繋がるようになってきたた
め、それに紐づいてサービスはさらに増殖していく
そのため、SaaS/PaaS/IaaSといったサービスひとつひとつを追っていっても新しいサービスが次々⽣まれ
てくるため、全てがサービスとして提供されてくるという考え⽅にシフトして⾏く
サービス⼀つ⼀つを⾒ていく全てがサービスとして考え、そのトレンドを追う
⽊（サービス単体）ではなく、森（サービスを含む全体の流れ）を⾒るようにシフト
この流れは、ガバナンスの観点で重要！

⽬次

〜ユーザを取り巻く環境の変化〜
クラウド、モバイルの普及に伴い、特に個⼈向けの利便性が格段に向上
社内ITの利便性の悪さがクローズアップされ、ユーザの不満が⼤きくなる
クラウドサー
ビスの台頭
モバイルの普及と
BYODの浸透
SNSやクラウドファイル共有
など利便性の⾼いツール
ユーザを取り巻く環境
社内のシステム環境
進化し続ける
新しいサービスの導⼊にはセキュリティポリシーの改定や、
運⽤の仕組みを構築しないといけず整備が追いつかない

〜ITの進化と競合の変化〜
⾃動⾞メーカーメーカーの⾞部品⼯場
スマートファクトリー電気⾃動⾞/⾃動運転
ITによるデジタル化
クラウド以降、ITの進化は加速しデジタル企業がライバルになるケースも増えてきている
IT技術 IT技術
IT企業

〜シャドーITの浸透〜
クラウドファイル共有の利⽤
Ÿ クラウドストレージの利⽤による重要情報のやり取り
Ÿ モバイルデバイスの利⽤(BYOD)
Ÿ 個⼈スマートフォンやタブレットを利⽤した、メールや個⼈⽤のクラウドストレージ経由での顧客情報のアクセス
SNS利⽤
Ÿ ビジネス向けSNSの利⽤による、顧客とのやり取りがIT部⾨の知らないところで⾏われる
社内整備が追いつかないと、各部⾨が判断して各種クラウドサービスを導⼊してしまう
Ÿ 業務効率を向上させるためにモバイルの活⽤を独⾃にすすめる
Ÿ 他社よりも先んじるために、オンデマンドに扱えるCRM・BIの導⼊をすすめる
シャドーIT化
その結果
IT部⾨が認知していない複数のシステムが出来上がってしまい、コントロールができない状態に・・・

⽬次

複雑化する開発プロセス
〜集中型システムの開発プロセス〜
メリット
• ⼿戻りが発⽣しない限りにおいては管理・品質担保ともにしやすい
• フェーズ間の成果物の前後関係が明確で、流れに乗る限りは開発もしやすい
• 各⼯程の成果物、品質のチェックポイントが明確で⼯程ごとの監査がしやすい
デメリット
• 変更が発⽣した場合、内容によっては外部設計まで戻らねばならないため遅延が発⽣しやすい
• 完成するまでシステムの全体像が⾒えないため、ユーザ要求の多い領域での開発には向かない
• 開発途中での機能変更がしずらいため、コストのアジリティ性が低い
主に⼤規模開発のような解決すべき課題や⼿法が明確なシステム開発では今でもよく利⽤される
要件定義外部設計内部設計
実装/単体
テスト
システム
テスト
受け⼊れ
テスト
各⼯程の成果物が明確で、前フェーズの成果物が後フェーズのインプットになる
プロセスはV字モデルになって
おり、開発とテスト⼯程の確認
ポイントも明確
要件定義
外部設計
内部設計
開発/単体テスト
結合テスト
システムテスト
受け⼊れテスト

〜繰り返し型開発プロセス〜
メリット
• ⼿戻りがあっても戻りやすく、開発中に機能の取捨選択が可能
• プロセスは複雑だが⼤きな流れは従来と変わらないため成果物や品質の監査をしやすい
• 早い段階で動くものを⾒せられるので、ユーザ要求を取り込みやすい
デメリット
• システムリリース期間⾃体は従来型とそれほど変わらない
• 迅速に素早く新しいシステムを展開したい、または検証型アプローチの適応は難しい
ウォーターフォールでは難しかった⼿戻りリスクや、ユーザ要求の取り込み、機能コントロールを
可能にするため、開発フェーズを反復型にしたモデル
⽅向付け推敲（すいこう）作成移⾏フェイズ
要件定義
分析/設計
開発/テスト
評価
・プロジェクトスコープの決定
・基本要件の抽出
・アーキテクチャの確⽴
イテレーティブ(反復)型
(段階開発モデル)
・全機能の開発
インクリメンタル型
(コンポーネント開発モデル)
・ユーザ環境への移⾏
要件定義
分析/設計
開発/テスト
評価
・・・
機能単位に繰り返し開発
段階的に機能を完成させる
繰り返しプロセス

〜価値重視型プロセス（アジャイル・リーンスタートアップ）〜
繰り返し型は要求変更にも強いプロセスではあるものの、as a Service（クラウド）時代のプロセ
スとしてはリリースまでの期間が⻑すぎるため、課題を即時解決、課題を洗い出しながら仮定を検
証するプロセスが主流になってきている
要求
設計
実装
テスト
課題：Known 解決策：Unknown 課題：Unknown 解決策：Unknown
初期モデル
アジャイル開発リーン・スタートアップ1
運⽤
解決策が未知の場合は反復を
繰り返しながら段階的に開発
課題・解決策ともに未知の場合は実⽤
最⼩限の製品（Minimum Viable
Product）からフィードバックループ
を回しながら発展させる⼿法が有効
要求
設計
実装
テスト
仮説
検証考察
フィードバック
フィードバック
課題を元に仮説を検証
仮設を実装
（アジャイル開発）
メリット
• ユーザが必要なタイミングに提供できる
• 成果物は必要なものしか作らない（機能ごとに
バラバラの可能性もある）
• 短期間でリリースし、必要に応じて拡張できる
アプローチが取れる
• 作成中でも開発を辞めてしまうことも可能
• リリース後に想定していた価値がなければ捨て
る事も可能
デメリット
• 体制をきちんと組めなければ全くコントロール
が効かなくなる
• 従来型のコスト管理ではコントロール出来ない
1出典：エリック・リース『リーン・スタートアップ－
ムダのない起業プロセスでイノベーションを⽣みだす
』

〜DevOps〜
開発プロセスが進化してゆきリリースが早くなると、それに紐づいてシステム運⽤も対応出来るよ
うにアジリティ性を⾼めるという、DevOpsという考え⽅が⽣まれました
要件定義
分析/設計
開発/テスト
評価
基盤設計環境構築テスト
リリース
プロセス
デプロイ
運⽤
開発
リリースまでの時間の差
1出典：Wikipedia
✖
Chef/Puppetなどインフラを
⾃動化するツール、PaaSなど
クラウドサービスを活⽤従来のプロセス
構築したシステムを迅速にリリース・展開して競争⼒を⾼める
◯DevOps

⽬次

開発プロセスの複雑化テクノロジーの進化ビジネス環境の変化
新しい法規制
継続的な法改正
罰則の強化
新しいマーケット
新しい商品/サービス
新しい脅威
IoTの活⽤による異業種
からの参⼊
クラウド
インフラも含めた⾃動化
新たな脆弱性の発⾒
新しいコントロールのニーズ GRC領域のアプローチの⾒直し
シャドーITなど
新しいリスクの表⾯化
© 2017 SAP SE or an SAP affiliate company. All rights reserved.
22
(*1) GRC : Governance, Risk and Compliance
as a Service(クラウド)時代のガバナンス
〜環境の変化によるアプリケーションITのGRCの複雑化〜
GRC環境の複雑化
クラウド時代になり、ビジネス環境の変化ややテクノロジーの進化により開発プロセスも複雑化し
てきたため、ガバナンスが保たれた状態を維持するのが難しくなってきています

コーポレートガバナンスは、企業統治と訳されていますが、誤解を招く可能性がある。
統治と訳すと、治めるとか、君臨するというニュアンスがありますが、本来は、
Govern＝律するという意味で、Governance＝律した状態を意味します。
コーポレートガバナンスは、
１）コンプライアンスを達成しつつ、
２）リソースを有効かつ適切に配分し、予定した利益を創出できるように、
経営者を律するというのが、コーポレートガバナンスの本来の⽬的です。
〜コーポレートガバナンス本来の意味（GRC）〜
→カルチャー、ポリシー、業務プロセス、各種ルールなど、事業運営上の基盤となる仕組み

リスクの語源をたどりますと、ラテン語のRisicare （リジカ〜レ）です。
これには、以下の２つの意味があります。
１）「岩⼭の間を船が航海する」という意味
⾮常に危険であるというネガティブな意味
２）「勇気を持って試みる」という意味
チャレンジしなければ、成果は得られないというポジティブな意味
〜リスクの本来の意味（GRC）〜
→リスク管理とは危機管理と業績⽬標達成を両⽴させるために⾏う組織化された取り組み

コンプライアンスの⽇本語訳は“法令遵守”になっているが、法令遵守はコンプライアンス
の⼀部に過ぎない。
コンプライアンスの語源は、ラテン語のcompleoである。満たす、充⾜するという意味。
元々の意味は、神の負託に応える。そこから転じて、社会的要請に応える。
社会的背景、国民のニーズ
法令
企業、個人
【法令遵守】
【コンプライアンス】
〜コンプライアンスの本来の意味（GRC）〜

〜GRC環境が整った状態〜
枝葉
幹
根
根幹部分がしっかりしていれば多少のリスクはあっても枝葉は育つ
根
幹
部
分
コンプライアンス
リスク
ガバナンス
多
様
化
部
分
GRCが実現されているのは⽊がいい状態であると⾔える

〜as a Service時代のGRC -領域の分解〜
API/BPM層
ユーザー
体験
IoT コラボレー
ション
アナリティ
クス
ビジネス・
サービス
モバイル
受発注系システム
⽣産管理システム
(⼯場)
(⼯場)
店舗管理システム
(店舗)
(⼯場)
(⼯場)
(⼯場)
会計系システム
変
化
が
少
な
い
変
化
が
激
し
い
多様化
（枝葉）
⽀柱/道
（幹）
基幹
（根）
統合認証基盤
⽊と同様に根幹部分が重要
システムを⽊に例えてみると・・・

〜多様化（枝葉）〜
• 役割
Ø 基幹部分からAPIを経由してデータを取得・更新
Ø 環境の変化に応じて新しいサービスを⽴ち上げる
Ø 不要な（なりそうな）サービスは停⽌してしまう
• 環境・開発プロセス
Ø クラウドを全⾯的に活⽤しアジリティ性の⾼い環境を利⽤
Ø アジャイル/リーンスタートアップ型で迅速な開発
Ø 可能な限り⾃動化できる環境・サービスを利⽤する
• ガバナンス
Ø プロダクトバックログで実装機能を管理し実装範囲を決める
オーナーを⽴てて、⽅向性を含めてきちんとコントロールする
Ø 案件単位の発注⽅式ではなく⼈⽉単位と期間の契約が好ましい
Ø ⼿順をできるだけ⾃動化する（⼈⼿を返すほどリスクが⼤きくなる）
Ø チーム体制を整え役割と責任範囲を明確にする
枝葉を全部追おうとせずに、幹を⾒るようにする

〜⽀柱/道（幹）〜
• 役割
Ø 基幹部分からのデータとユーザ管理・アクセス権限などを⼀元的に管理
Ø データやユーザのアクセスコントロールを⾏う重要な部分
Ø この部分の管理をしっかりすることでガバナンス性を保つ
Ø 連携性を考えクラウドが望ましい
Ø 繰り返し型プロセスでの段階的な機能拡張
• ガバナンス
Ø 重厚⻑⼤なプロセスではなく段階的に拡張できるプロセス
Ø 実⾏（共通）基盤を確⽴させ、実装機能と分けて管理する
Ø 実装機能の要求管理と障害管理、コードを紐づけて管理する
as a Service時代のガバナンスではこの領域の管理が最も重要

〜幹部分のリスクアセスメントのポイント〜
幹部分のリスクアセスメントの中⼼は認証・アクセス権限
SAP_ALL
X
Legacy
③特権ユーザー管理：
特権ユーザ業務の統制とモニタリング
②アクセス権限監査：
最新設定情報に基づいたアクセス権限監査
⑤ロールメンテナンス：
業務視点でのロール定義と維持/運⽤
④権限申請/付与：
権限申請/付与プロセス
①リスク分析：
職務分掌リスクならびにクリティカルな処理の検知と是正
ここのコントロールができれば、枝葉がいくら多様化してもGRCは実現される

〜基幹（根）〜
• 役割
Ø 企業にとって重要なマスターデータを管理・運⽤する
Ø 場合によっては法的責任も負うシステム
Ø ⻑期間にわたって管理・運⽤される
Ø 責任をもって管理できる場所
Ø ウォーターフォールでの開発
• ガバナンス
Ø 各種設計書やテスト仕様書などプロセスの明確化（整合性）
Ø データアクセス管理（ベンダー管理）の徹底
Ø 厳密な変更管理とプロセス
Ø 信頼性を評価する仕組み（強い監査性）
この領域は変更よりも守ることが重要

〜やってはいけないパターン〜
枝葉だけを⾒てしまうと、新しいものがどんどん出てくる為ついていけなくなる
とはいえ、新しい技術に⽬をつぶって無視はしていられない現状も・・・
IoT
Machine
Learning
AI
BigData
クラウド
オムニチャネル
BYOD
DevOps

〜守るべきものを明確にする〜
システム全部を守ろうとするのではなく、企業にとって重要なものは情報（データ）
どこに何のデータが⼊っていて、それぞれの重要度を把握できていることが重要で、
コントロールができていれば、枝葉がどのように伸びるかの把握ができる
⼀番⼤事なのは、きちんと運⽤できて⼤事な情報を守る仕組みが作れていること
情報漏洩の８割は誤操作や管理ミスなどの⼈為的要因
格納されているデータの種別とシステム
データの重要度と流出時のリスク度合いの把握
データの通し⽅
・データごとに許可できる権限の整理（参照・更新などをロールごとに整理）
認証の⾒直し
・ユーザ/パスワード⽅式ではなく、SSO+⼆要素認証など堅牢な認証を取り⼊れる

不正を許す機会
やろうと思えば、やれてしまう機会がある
不正をしようとする動機
そうしたいと思う動機がある
不正の実⾏の正当化
不正⾏為を⾏う際に感じる良⼼のか
しゃくを正当化する理由付けができる
仕組みだけでなく、もう⼀つ気をつけないといけないのは不正⾏為です。
不正⾏為は①機会、②動機、③正当化という３つの不正リスク（「不正リスクの３要素」）が
全てそろった時に発⽣する確率が⾼まると考えられている。
〜ドナルド・R・クレッシーの”不正のトライアングル”〜
不正の
発⽣
情報流出の⼈的要因で気をつけなければならないのが故意や悪意によるもの
⾦銭を得たい、不満や恨みといった負の感情に機会が重なると⾃⼰正当化しやすい

〜SIモデル構造からみる問題〜
⽇本のシステム開発ではSIerモデルが⼀般的ですが、⼆次受け三次受けといった構造化することが多く、
開発する技術⼒と責任意識のバランスが崩れやすいため、これを是正しないと不正が起きやすくなる
一次受け
下受け
孫受け
発注者
技
術
力
責
任
意
識
不正を防ぐためには
• 発注者側にもITスキルの⾼い⼈間を参画させる
• 本番環境の操作は可能な限り発注者側の社員のみが⾏う
• 発注者は全ての開発者の出⾃を把握しておく
• 孫請けまで含めて責任意識を徹底させる（ガバナンス）
機会も動機も持たせず正当化させない⼟台を作り上げる

〜まとめ〜
全体を⾒た上で、重要なデータを守れる状態を担保し、
その上で新しいチャレンジを実現できる環境を整備する
アクセスコントロール
プロセスコントロール
リスクマネジメント
不正検知
ベンダー管理
信頼性の担保
データとプロセスの整合性管理
変更箇所の記録
ビジネス要件ごとの優先順位
新しいテクノロジーの検証
データを活⽤した攻めのITの実現
⼟台と幹がしっかりしていれば、
危険な状況になっても⼤事な情報
を守ることができる
⼟台と幹がしっかりしていることで、
枝葉が伸びていく⽅向性を把握するこ
とができるし、イレギュラーな物が出
てきても切ってしまえば良い

ありがとうございました

As a service時代のitガバナンス

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie As a service時代のitガバナンス

Ähnlich wie As a service時代のitガバナンス (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

As a service時代のitガバナンス