この事例は、内製化（インソース）指向の強い企業でのケースとなるが、自社要員だけでは困難な場合には、監査部門に外部ベンダーの有識者を取り入れつつ実行・推進することで、デジタルビジネスの構築と自社社員のケイパビリティ（能力）向上を両立させながら進めることも可能である（その際の外部ベンダがクラウド関連の実績や技術力が高いだけでは、従来の外注によるシステム開発が単にクラウド上で行われるだけに過ぎず、かつ、そのベンダが得意なクラウドサービスにロックインされてしまうリスクがあることは念頭においてベンダ選定すべきである）。
クラウド時代の開発や運用に係るプロセス・ガイドラインの整備
一般的なITシステムのライフサイクルとは、ウォーターフォール型に代表される「Vモデル（企画や計画、要件定義、基本や詳細設計、実装、単体／結合試験、総合試験、移行や運用試験、受入試験、移行、運用及び定着化）」に則り開発、運用されるケースが多い。（当然システム化の規模にもよるが）1年〜数年に渡って開発プロジェクトが遂行され、複数年の運用業務を経てベンダとの契約期間や保守期限をトリガーに更改プロジェクトが再度開始される、というケースが多い。
プロジェクト全体を通して、自社と外部ベンダとの間には「SOW（作業範囲記述書）」に基づく厳密な請負契約（多くの企業・団体のシステム開発案件において準委任契約というケースは少ない）が存在し、契約内容に対する検収によって報酬の授受がなされることはIT業界に従事する者であれば当たり前の話である。
一方、これまで述べてきた「デジタル化に向けたクラウド利用」という文脈において、上記のような従来当たり前とされてきたプロセスに少なからず違和感を抱くことはないだろうか。その違和感の正体は、前述したクラウドの特徴の1つである「Quick & Dirty（より早く、簡単に作り出す）」とのギャップである。特に、競合他社との激しい争いを繰り広げているマーケティング部門や事業部門の立場からすると、IT領域に限らず新しいビジネスアイデアを実現するために約1年間を費やすということは、現実的なタイムラインとして受け入れがたいことは想像に容易い。
そのようなジレンマを解消するための方法の1つとして、従来のウォーターフォール型（システム開発→システム運用）ではなく、IT資産を可能な限りサービス化した上で、サービス需要とサービス供給を同時並行させることが可能なようプロセスを整備することが挙げられる。若干のバズワードとして認知されているDevOpsに代表される開発/運用手法もこの1つに分類できる。
いずれにせよ、クラウド時代のプロセス・ガイドライン整備における本質的な論点は、「自社のIT資産をサービス化するとは何か」という問いに対する解を導出することに他ならない。読者の中には「われわれは既に（プライベートもしくはパブリック）クラウド上でサービスカタログを定義して運用できている」と思われる方もいるかと思うが、この機会に一度点検して頂きたい。
