最近ますます増えつつあるパブリッククラウドの導入事例だが、本稿では社内で利用する業務システムをWindows Azureで実装した事例を全2回にわたって紹介する。1回目となる今回は検討プロセスに焦点を当て、なぜWindows Azureを選んだのかという理由について説明していく。

執筆者紹介

三宅和之(MIYAKE Kazuyuki) - ソフトウェアプロセスエンジニアリング


ソフトウェアプロセスエンジニアリング(SPEI) 代表取締役COO。PMP及びCMA。信託銀行のクオンツアナリストから要求アナリストへ転身しSPEIを設立。「要件定義とアーキテクチャからシステム開発を変革する」をテーマに活動しているSPEIでは、主に要件定義・プロジェクトマネジメントを担当。近年はクラウド時代に最適な要求プロセスとは何かを追求すべくプロジェクトに邁進している。近著に『要求の「基本」原則』(発行:技術評論社)がある。

パブリッククラウド採用の背景

プロジェクト開始のきっかけはこうだ――「基幹システムの周辺に新しいビジネスや業務の変更に対応するためのExcel等のファイルがあふれている。業務効率面でもコンプライアンス面でも問題が多くなってきたので、きちんとしたツールとして整備できないか」。

基幹システムの周辺業務に対応させるためであれば、基幹システムを改修すれば良いはずだ。しかし、新しいビジネスや業務の場合、それが基幹システムに組み込むほどの永続性があるかどうかわからない。また、基幹システムの改修には情報システム部門との調整(説得)というユーザ部門にとっては敷居の高い作業がついて回る。そのため、安易に基幹システムに手を入れるという決断はできない状況であった。

ユーザ部門の要求を端的に表現すると「短期間・低コストでExcelを置き換える程度のツール(仕組み)を入れられれば良い」ということだ。このプロジェクトに限らず、同様のニーズは非常に多く目にする。

オンプレミスの壁

システム導入に向けた検討に着手する際、最初に必ず確認と合意をしておかなければならないのは、期間とコストである。このプロジェクトの場合、コンプライアンス対応を急がなければならない事情があったため、システム導入までの期間は最大でも3ヶ月しかなかった。また、年間予算計画に含まれていたプロジェクトではなかったため、コストはできるだけ小さくしたいという状況だった。

この時点で、導入に時間がかかるオンプレミス型システム開発という選択肢はほぼ消えた。新規ビジネスであり基幹システムとも関連が深い業務であったため、既製の業務パッケージも適用できない。特にハードウェアの調達や情報システム部門とのシステム導入調整に時間や手間を要するオンプレミス型システムの導入はほぼ不可能だった。

パブリッククラウドの検討へ

そこで候補に浮上したのが、パブリッククラウドを活用したシステム構築だった。プロジェクトは2010年初頭のことだったので、今のようにパブリッククラウドという言葉や概念は定着していなかったが、Salesforceや当時正式発表されたばかりのWindows Azureが徐々に注目され始めてきた時期だ。

パブリッククラウドならば少なくともハードウェアの調達や情報システム部門との各種調整がほとんど発生しない。この点に着目し、具体的なソリューションの検討を開始した。