SaaSのメリットとしては
・コストダウン
・スケールアウト（ここまではPaaS,IaaSも同じ）
・開発期間削減
は、よく挙げられるけど、「開発リスクが低減することがある」というメリットには、多くのSaaSの紹介で触れられていないような気がする。
これは、実はIaaSやPaaSでは得られないメリットでかつ、場合によっては、上記３つよりもはるかに強大なメリットなんだけど、
（このメリットがなければ、中小企業のSaaS導入は、中長期的には不利になるケースもある）
営業とか触れないんですよね・・・まあ、それこそ、リスキーな面もあんだけど・・・（＾＾；）
でも、これ知らないSIerは、たぶんクラウド販売で行き詰まる。
ということで、SIerさんのために、「開発リスク低減」の説明をしてあげよう・・・
■開発リスクを挙げてみる
開発リスクといっても、いろいろある。
（１）そもそも開発不可能ということが開発中にわかり、そこまでの投資や機会が無駄になるリスク
→（ありえない極端な例）：どんな数（何桁）でも、すぐに素因数分解するシステム
たしかに、１０００以下ならシステム化できるけど、３００桁とかあったら・・・
（２）開発可能なんだけど、納期に間に合わないリスク
→機会損失になる、場合によっては無意味に
(オリンピックのシステムが閉会式後にできても・・）。
（３）開発して、納期には間に合ったけど、仕様とあっていない
（４）開発して、納期には間に合い、仕様とも一致しているけど、そもそも、仕様が、要求と合わない
（５）開発上は何も問題なかったが、要求どおりやっても、ビジネス的には成功しなかった。
→開発者には何も問題ないけど、お客さん的には・・・・
スクラッチから開発した場合、このリスクのすべてが起こりえる。
■SaaSの場合、開発リスクが低減するケース
SaaSで、（１）～（５）のケースを考えると・・・
（１）は、目の前にモノがあるので、それをカスタマイズしないのであれば、ありえないリスク
（２）も、カスタマイズしないなら、もうできているので、ありえないリスク
（３）は、機能要件に関しては確認できる。非機能要件に関しては、とくに性能のレスポンスタイム
に関しては、（仮に試用できても、たまたまその速さということがありえるので）
はっきりしない・・・リスクとして残る
（４）は、ありえる。ただし、試用することで、要求をイメージしやすく、リスクが低減することもある
（５）は、ありえる。ただし、試用することで、要求をイメージしやすく、リスクが低減することもある
つまり、カスタマイズをしない場合は、（１）、（２）のリスクは回避でき、
（３）～（５）に関しても、試用ができれば、かなり低減する。
スクラッチから開発した場合、プロトタイプで確認しても、（３）～（５）は、はっきりしない。
なので、「カスタマイズをしないで済む場合は」開発リスクが低減する。
■注意点：開発リスクが低減しない、ないしは増加する場合
しかし、これは、あくまでも、「カスタマイズをしないで済む場合は」である。
カスタマイズが必要ならば、スクラッチのほうがよいこともある。
なぜなら、スクラッチなら、開発言語で表現できることは、なんでもできるが、
カスタマイズの場合、
・APIがないと実現できない(APIがないリスク）
・APIがあっても、開発するのだから、上記（１）～（５）のリスクを被る
→スクラッチと同じリスクを被る
・開発しようとしたとき、APIの振る舞い等の情報が公開されないリスク
・APIも変更されるリスクがある。
・フリーソフトのSaaSで、カスタマイズの際に解析が必要な場合、解析できないリスク
→プログラムがあまりにも汚い
というリスクが生じる(リスクが増加する）。
これが大きいと、スクラッチのほうが、開発リスクが少ない時もある。
■「カスタマイズをしないで済む」に潜むリスク
なお、「カスタマイズをしないで済む」と判断することにもリスクがある。
結局カスタマイズしないといけない場合だ。
このリスクは、カスタマイズの決定過程を分析し、その否定形をとることによってわかる。
カスタマイズの決定過程は、こんなかんじ。
・要求をまとめる
・要求と機能があっているかどうか、判断する（フィットギャップ分析）
・機能から導き出される操作を（思考）実行してみて、
実現可能であり、要求を満たしていることを確認する
ということは、リスクは、こんなかんじ
・要求がまとまってない、よくわかんないリスク
→ここでSaaSを決めてしまうと、SaaSの機能が制約に回ってしまうことも・・・
リスク増大
・要求と機能があっているかどうか、判断できない、判断が間違うリスク
→機能をよくわかっていない、甘い考えの場合起こる。
たとえば、売上日報がでること
要望は、カテゴリーごとにも出ることだが、全体しか出ないとか
これは、入出力を確認するとわかるんだけど、機能ベースで確認したとき、やばい
だけど、入出力まで、要求がまとまってないことも多い
・機能から導き出される操作が実現不可能
→たしかに、機能はある。でも、その機能を実現すると、夜間バッチが突き抜けるとか、
－２０度の冷凍室で、２時間以上操作とか・・・
■まとめ
・SaaSの場合、「カスタマイズをしないで済む」のであれば、
開発リスクを低減できる場合がある。
→安定的なビジネスの上でメリット
・ただし、「カスタマイズする」のであれば、開発リスクはスクラッチより上回ることもある。
・そもそも、「カスタマイズをしないで済む」かどうか、ちゃんと考えないと、
「カスタマイズをしないで済む」と思い込むリスクもある。
が、定型的なもの（総務関係に多い。財務とか、会議室予約、備品管理など）は
「カスタマイズをしないで済む」場合が多く、そーいうのだと、SaaSは開発リスクが低減できる。
※なお、ここでいうカスタマイズとはプログラムを組むものを指し、
・設定ファイルで変えられるもの
・Force.com Builder,(SugarCRMの）Module Builderで作れるようなもの
は、すぐにできるので、ここでは、カスタマイズに入れないものとする。
※それと、開発リスク低減と、開発コストや期間の削減とは意味が違う。
たとえば、大阪から、東京に行くとき
・大阪から、東京までの新幹線の費用を払うのと、
・大阪で、パチンコ屋さんに１０００円の費用をはらい、
儲かったお金で、東京まで行く
のとでは、後者のほうが、コストはかからない場合もあるが、リスクは、後者のほうが大きい。
この場合、多くの人は前者をとる（後者の人もいるけど）
アクセス
トータル
ランキング
