はじめに

当コラムでは、これから３回に渡ってSaaSシステムの導入の当たってのプロジェクト管理のあり方と特徴を、従来のSBO開発に於ける一般的なプロジェクト管理手法との比較も交えて、今後３回に渡って考えてみたい。

初回の今回は、SaaS導入の際のプロジェクト管理の特徴と概要を検討する。

SaaSシステムへの期待と特徴

まず、最初にSaaSシステムに対して顧客が何を期待して選択し導入するのかを確認しよう。

• 低コストで導入・運用できるから
• 短期間での導入ができるから
• 運用やシステム管理などの手離れがよいから

実際には、上記の他の理由を含めて複数の理由が複合的に存在すると考えられるが、一般的なSaaSシステムの特徴からいっても上記の３つは、SaaSシステム導入の意志決定をする上で大きな要因であろう。
そして、プロジェクト管理についても、顧客の３つの期待に応えられるものでなくてはならない。

次に、導入する側の立場から見たSaaSシステムの特徴として、以下のものが挙げられる。

• コンフィグレーションによるシステムカスタマイズ
• 標準機能の利用が前提
• ネットワーク経由による機能利用
• Webシステム

これらのSaaSシステムの特徴とSaaSに対する顧客の期待がSaaSシステムの導入プロジェクトの管理手法のどのような影響と特徴を与えるのかを以下に見てみたい。

従来のスクラッチ開発（以下SBO（System by order））によるシステム導入とSaaS導入の違い

これまでのSBOによる個別のシステム開発方法論との違いを具体的に見ていこう。

SaaSによるシステム導入の場合にポイントとなるSaaSシステムの特徴は以下の点にある。

• 機能が最初からある程度利用できるように用意されている
• コンフィグレーションにより機能設定を行う
• 基本的に企業単位でのシステムそのものに対する機能追加はできない
• コンフィグレーションを変更することにより適用機能の変更や追加が可能

上記の特徴を鑑みた場合、SaaSシステムの導入の大きなポイントは、これまでのウォーターフォールモデルではなく、スパイラルモデルで導入が進んでゆく、という点である。

もう少し詳細に説明すると以下のようになる。
ウォーターフォールモデルによるSBO開発の場合、現状調査 → 要件定義 → 基本設計 → 詳細設計 →プログラム開発 → テスト → ユーザーテスト → 社内導入 という順番に開発・導入プロセスが進んでゆく。この際、ウォーターフォールモデルは基本的に前工程に戻ることは想定していない。プログラム開発中に要求仕様に変更があったとしても、そのまま開発を続けるか、或いは相応のコストと工数を掛けて前の工程に戻るかの判断を都度しなければならない。

一方で、SaaSシステムの場合は、最初から本稼働後に利用する利用企業別の本番環境が用意されているので、導入当初から本稼働環境に直接コンフィグレーションしてゆくことになる。その際、SaaSシステムの特徴として説明したように標準機能の利用が前提となるので、現状調査やFir/Gap分析というプロセスは意味がない。つまり、SaaSシステム導入の流れとしては、現状調査 → 導入戦略策定 → 適用設計 → コンフィグレーション → テスト → ユーザー確認 の流れを繰り返し、納得のゆくところまでコンフィグレーションを煮詰めた段階で社内導入してゆく流れになる。

この時にウォーターフォールモデルとの最大の違いは、機能面からの導入プロジェクトの明確な完了基準を設定できない、ということである。どういうことかというと、論理的にはSaaSシステムの導入プロセスにおける現状調査 → 機能適用範囲設計 → コンフィグレーション → ユーザー確認 の流れは永遠に続けることができるため、ユーザーの要件や環境変化、場合によってはSaaSシステム自体のバージョンアップ等の理由によるシステム要件の修正・追加を半永久的に続けることが可能である、ということである。これは、SaaSシステムの特徴とメリットにもなるが、つまりはSaaSシステムは、企業の要望に合わせて永遠に変化することのできる業務基盤環境である、と言うことができる。

従来のパッケージによるシステム導入とSaaS導入の違い

次にパッケージシステムの導入とSaaSシステムの違いを見ていこう。

パッケージシステムも一般にはSBOによるウォーターフォールモデルによるに順じるが、パッケージシステムの場合は、SBOによるウォーターフォールモデルの流れの他に機能調査やFir/Gap分析がタスクとして加わり、また、基本設計の代わりにコンフィグレーション設計となり、開発の代わりにコンフィグレーションのプロセスとなる。またFir/Gap分析の結果、追加機能が必要な場合は追加開発というプロセスがウォーターフォールモデルのサブプロセスとして一連の開発プロセスが追加される。

SaaSシステムに於いても、基本的な流れはパッケージシステムと同様にコンフィグレーションにてシステム設定を進めてゆくため、パッケージシステムの導入プロセスに準じる部分が多いが、SaaSシステムの導入の場合には基本的に追加開発を想定しないため、追加開発によるシステムコンフィグレーション上の制約等が加わるケースが少なく、そのためにスパイラル工程におけるシステムのブラッシュアップの自由度を高く保持したまま導入プロセスを進めることが可能である。

また、パッケージシステムの場合、導入の前にパケージシステムそのものの購入やパフォーマンス要求定義とそれに合ったハードウェアの構成及び調達、調達したハードウェアの設定、OSやミドルウェアのインストール及び設定なども作業が必要となるが、それらの作業項目も導入作業の一貫としてプロジェクト管理として管理する必要がある。特に購入・調達に関連する作業は、発注購買に関する社内手続きを含めた一定の手続きと実際納入されるまでの時間がかかるので注意が必要である。

SaaSシステムの導入の場合、システム基盤に関するプロセスは必要ない。

運用時のSBOシステムとSaaSの違い

SBO開発のシステム 及び パッケージシステムの場合、一度リリースした後で要件や環境の変化による機能追加開発は基本的に開発プロセスと同様のプロセスを経て行われることになるため、どうしてもそれなりの開発工数と費用がかかってしまう。

しかし、SaaSシステムの場合、コンフィグレーションによる機能設定が中心になるため機能変更が必要な場合はコンフィグレーションの変更を行えば良い。この特徴が特に顕著に現れるのが出力帳票や分析機能系で、SaaSシステムの場合は利用企業の管理者又は使いたいユーザー自身が帳票や分析機能のコンフィグレーション設定を自分自身で変更して個別に作成してゆくことなるが、SBOやパッケージシステムの場合は、ベンダーを呼んで欲しい帳票や分析機能の概要を説明し、それをベンダーが持ち帰りサンプル帳票などを作ってユーザーに要件確認をし、その後開発にかかり、テストの上、リリース、という流れになる。

これは、大きな違いで、SaaSシステムがリアルタイムで帳票を作成できるのに対し、SBOやパッケージシステムはどうしても一定の時間を置いた後のリリースとなる。SaaSシステムはリアルタイムであるため、ワンショットで必要な分析も、データを落としてエクセルで分析、という形をわざわざとらずに、SaaSシステム上でやりたい分析ロジックを設定して、試行錯誤しながら分析を進めてゆく、というシミュレーションに近い流れを業務システムの本番環境上でユーザー自身ができる。

SBOやパッケージシステムとSaaSシステムの根本的な違い

以上のようにSBO開発又はパッケージシステムの導入とSaaSシステムの導入の方本論の違いを見てきた。プロジェクト管理上の方法論や細かいテクニックなどの際はここで書き切れなかった点も含め様々な点に及ぶが、まとめ的に言うと、SBO及びパッケージシステムの導入とSaaSシステムの導入の根本的で最も大きく違う点は、ユーザーにとってのシステム投資リスクにある。

システム投資リスクは、ユーザーのシステム導入の意志決定に直接関わるため、その後のプロジェクト管理に大きく影響を与える。例えば、パッケージシステムは、まずパッケージの購入の意志決定を行いその後で購入したパッケージを如何に社内適用してゆくか、という観点が強くなる。また、その場合、先にも述べたようにハードウェアやインストール工数も最初にかかってくる。つまり、投資リスクを最初に負うことで導入プロジェクトを始めることになる。

SaaSシステムの場合は、期間契約による使用権の購入になるので、もし気に入らなければ次回の契約更新をしなければいいので投資リスクを抑えられる。また、ハード費用やインストール費用も不要である。これは、導入に於ける投資リスクを使用期間で分散させている、と考えることができる。

極端に言うと、SBOやパッケージシステムの場合は、使ってみる前にエイッと決めて、その後使い方を考える、という流れなのに対し、SaaSシステムの場合は、試しに使ってみて気に入れば使い続けるし、嫌ならやめる、という選択肢がユーザー側のオプションとして保持されたままシステム機能を利用できる、という違いがある。

一般には見過ごされがちなこの違いは、システム戦略を考える上でもシステム導入方法論上も極めで重要な違いなので、次回のコラムでもう少し詳細に考えてみたい。