こんにちは。
ライジングサンシステムコンサルティングの岩佐です。
この記事では、一般的に入手可能なR.F.Pの書き方指南にはあまり書かれていない、IT投資を成功に導くための３つのポイントを解説します。
そのポイントとは次の３つです。
・予算を明記する
・数値化された目標を明記する
・優先順位を記述する
この記事の解説で一貫してお伝えしたいことは、現在一般的に入手可能な「R.F.Pの書き方」の前提となっているのが、ウォーターフォール手法と呼ばれる１世代前の、非常にリスクの高いシステム開発手法を用いることが前提になっていることです。
今後、ビジネスはますます複雑で変化の激しい環境にさらされます。
そんな環境下において、旧態然としたリスクの高い手法を用いるソフトウェア開発プロジェクトは、特にユーザ企業側が大きなリスクを背負うことになります。
この記事では、そのリスクを避けるためのポイントとなる３つの要素について説明します。
目次
1.予算を明記する
R.F.Pには必ず予算を明記すべきというのが私の意見です。
実はRFPに対する予算の明記には賛否両論あり、予算を明記すべきではないという論調も実はかなり強く存在します。
予算を明記すべきでないという論調には、大きく２つの文脈があります。
1-1.経験のあるベンダーほど見積もりが高い？
ひとつは、「経験のあるベンダーの提案ほど安いはずだ。金額を書いてしまうと、安い金額でできるにも関わらず、予算枠いっぱいで見積もられる。」という理由。
もうひとつが、「そもそも自分たちが調達したいと思っているソフトウェアがいくらで完成できるかわからないので、金額の書きようがない」という理由です。
まず前者に関しては、大きな勘違いをされている可能性があります。
経験のあるベンダー程、提案金額は高く提示しますし、そうすべきです。
それには２つの理由があります。
まずひとつ目の理由として、経験があるということは、それだけ高品質なものを、早く提供できるスキルがあるからです。
高品質なものを早く届けることができる能力は、非常に高い付加価値のひとつです。
例えば、新入社員と２０年選手では２０年選手のほうが、給与金額の差の何倍も仕事のクオリティが高く、そしてスピードも圧倒的に早いはずです。
特にソフトウェア開発の分野では、個々人の能力の差が非常に大きく、熟練した技術者とそうでない技術者の能力には、10〜20倍の差があると言われています。
ふたつめの理由として、能力と実績のあるベンダーは「安売り」する必要がありません。逆に能力のない、経験の無いベンダー程、仕事を取るために安売りしなければなりません。
このように、金額を提示する側の立場に立てば、「経験のあるベンダーの提案ほど安いはずだ。」という仮説がかなり怪しいことが解ります。
1-2.開発費用の相場感がわからない？
次に、「そもそも自分たちが調達したいと思っているソフトウェアが、いくらで完成できるかわからないので、金額の書きようがない」という理由です。
しかしこれは、「手段が目的化している」典型的な例です。
IT投資の目的は「決められた性能のソフトウェアを決められた予算で買ってくる」ものではありません。
後述しますが、IT投資の目標はあくまでも「決められた予算内で、設定した目標値を達成すること」です。
なので、「自分たちが調達したいと思っているソフトウェアがいくらで完成できるかわからない」という考え方ではダメです。
正しくは「手持ちの◯◯◯万円で、労働生産性を◯◯％向上させるためのソフトウェアを◯◯までに調達するにはどうすればよいか」と考えるべきです。
そして「手持ちの◯◯◯万円」を決めるのは、当然ですが経営トップです。経営トップが、自社の懐事情…つまり決算書から、IT投資に割り当てることのできる予算を算出し、その範囲内で望める最大のリターンは何かという流れで考えるべきなのです。
もしあなたが家を買う場合、もしくは自動車を買う場合、最初に自分の欲しい家やクルマの機能や性能を定義し、その後に「いくら必要か」を考えるでしょうか？
多くの人は、まず最初に自分の「おさいふ事情」から、ざっくりとした予算を設定し、その範囲内で、自分の欲求を満たすことができる最適な家やクルマを探すはずです。
私は、ソフトウェア開発もそうあるべきだと思います。
そうすると次は「家やクルマは相場感が何となくあるから予算が立てられるけど、ソフトウェア開発の相場感はわからない」と言われることがあります。
ここで重要な事は、「ソフトウェア開発に相場感はない」ということです。相場感があるのはあくまでも、ソフトウェアを開発する技術者の人月単価のみ。ソフトウェア開発の相場感はありません。
例えば「一般的な在庫管理システムの相場っていくらぐらいですか？」と100人のソフトウェア開発エンジニアに聞いても、困惑されるか、極めてばらつきのある金額が出てくるでしょう。
相場感は、その技術者の経験からのみしか出てきません。その技術者がいつも数億レベルのプロジェクトしか経験指定なければ、その相場感は相当高くなるでしょうし、日曜プログラマとして趣味でプログラミングしている人に聞けば「そんなのフリーウェアでいくらでもありますよ」と答えるでしょう。
このようにソフトウェア開発の相場感は、それを語る人の経験によって大きなばらつきがあるので、実質的には存在しないようなものです。少なくともそんな属人的な情報をもとに、予算を組むべきではないでしょう
予算算出の根拠は、あてにならない相場感やベンダーからの「相見積もり」であってはなりません。あくまで自社の懐事情…つまり「決算書」であるべきです。
1-3.そもそもソフトウェア開発の見積もりはあてにならない
予算明記に関する最後の私見として、ソフトウェア開発プロジェクトの見積もりが如何に不正確であてにならないかというご説明をします。
こちらに表示しているのは、不確実性コーンと呼ばれるものです。
不確実性コーンとは、見積もりを算出する時点と、その時点で見積もられた数字の正確性を表現したグラフです。
このグラフを見ると、システム企画の最初に見積もった数字は、最終的な結果と比較して0.25倍から4倍もの開きがあることが解ります。
最低見積もりと最高見積もりの差は16倍です。
例えばR.F.Pをベンダーに出して、戻ってきた提案書に記述されていた金額が1.2億円と750万円だった場合、750万円のベンダーのほうが優秀で経験も豊富だろうから、安いベンダーの方に発注しよう…と思われますか？
まず思わないと思います。
そしてこの金額から、「相場感を…」と言っても算出はできません。
個人的な経験からここまで開くことはあまりありませんが、半年ほどかけてほぼ要件定義が終わったレベルのR.F.Pを配布して得られた見積もりでも、２〜３倍ほど開くケースは日常茶飯事です。
２〜３倍の開きがある見積から「相場感」を算出することはやはりできませんし、安い金額のベンダーに発注するのも非常に危険です。
このような理由から、ユーザ企業が主体的に予算を確定させ、その予算内でどれだけベンダーが魅力的な提案をしているのかの目利きをすることが重要なのです。
2.数値化された目標を明記する
数値化された目標とは、一般的に言われるKGIやKPIになります。
KGIは「Key Goal Indicator（キーゴールインジゲーター）」の略で、一般的には「重要目標達成指標」と翻訳されます。
次にKPIは「Key Performance Indicator（キーパフォーマンスインジゲーター）」の略で、一般的には「重要業績評価指標」と翻訳されます。
簡単に例えると、KGIは目的地。そしてKPIはその目的地に確実に近づいていることをしめす「一里塚」のようなものと思っていただければ大丈夫です。
例えば労働生産性の向上を目的としたシステム開発であれば、現在の総労働時間と目標とする総労働時間となりますし、在庫管理システムの導入による在庫金額の圧縮であれば、在庫回転率や在庫金額の現在値と目標値がそれにあたります。
またWebサイトの構築であれば、ページビューの現在値と目標値、もしくはWebサイト経由での問合せ件数や資料請求件数の現在値と目標値等がその候補となるでしょう。
ここに上げた数値目標が、将来的なソフトウェア開発の成功の基準となります。
2-1.なぜ数値目標を明記する必要があるのか？
KGIとKPIを記述するひとつ目の理由は、自社としてのIT投資の成功を定義するためです。
一般的なソフトウェアエンジニアリングの教本やインターネットで入手できる情報では、ソフトウェア導入の成功を「品質（Quality）」「予算（Cost）」「納期（Deliverable）」が、あらかじめ決めた範囲に収まったか否かで定義されています。
この「品質」「予算」「納期」の頭文字をとって「QCD」と一般的には呼ばれますが、ユーザ企業がこのQCDが達成できただけで「ソフトウェア開発の成功」と捉えるのは早計です。
Q.C.Dの達成度合いがソフトウェア開発の成功の指標となるのは、ソフトウェアの完成がゴールとなるシステム開発会社やソフトウェア開発技術者です。
ソフトウェア開発を委託する側…つまりユーザ企業にとっての成功はQ.C.Dの達成以上に、ソフトウェアの導入によって狙った目標を達成できたか否かにするべきです。
つまり、IT投資の手段としてソフトウェア開発をするユーザ企業であれば、QCDの達成だけに着目するのではなく、ここで設定した目標数値を達成できたか否かが極めて重要な成功指標なのです。
もちろん、当初設定した予算をオーバーしない、リリース納期をオーバーしないことは極めて重要な事です。
しかし、当初予定していた品質…ここではよりわかりやすくするために、「品質」を「機能」と読み替えましょう。
その機能が当初予定していたものの３分の１しか実装しなかったとしても、ここで設定した目標数値を達成できれば、それは、ユーザ企業側とすれば「成功」と捉えるべきです。
しかも、当初想定していた機能の３分の１しか開発しないのですから、投資回収率としては極めて高いものになるでしょう。
何よりも、最初に予定していた機能を100とした場合、その100の機能を完成させないと、目標数値が達成できないという相関関係はありません。
2-2.完成した機能の３分の２は使われていない
これには具体的な調査結果があります。
アメリカのスタンディッシュグループによると、完成したソフトウェアの機能を100とした場合、実際にビジネスに貢献している機能はたったの２割。
そして全く使われていない機能は45%で、ほとんど使わないが19%。
両者を足すと、ほぼ３分の２はビジネスにほとんど、もしくは全く貢献していないということになります。
このようなムダを排除するためにも、「すべての機能を定義し、全ての機能を実装する」という考え方を受け入れるべきではありません。
企業におけるソフトウェア開発はあくまでも「投資」であり、確実なリターンを追求すべきです。そしてそのリターンは、当初予定していたすべての機能を開発するから得られる…
という相関関係は全く無いのです。
ソフトウェア開発ベンダーは、より多くの機能を作りこむことで、売上が上がる構造になっています。
よって、彼らの思考にある根底は、「如何に大規模システムを開発するか」が大きな価値基準になります。しかし、ユーザ企業が同じ価値基準でIT投資を語るべきではありません。
そのためにも、R.F.Pには、該当プロジェクトで達成すべき数値目標は必ず明記するようにしましょう。
2-3.判断基準を明確にする
数値目標を明示する２つめの目的は、システムに組み込む機能を決める時の判断基準を明確にしておくためです。
システム開発プロジェクトでは、予算と時間の制限から、全ての要求機能をシステムに組み込むことができません。（そして組み込む必要はありません。）
その場合、組み込む機能の取捨選択が必要になります。
この取捨選択の判断基準にKPIやKGIの達成にどれだけ貢献できるか…という考え方をするのです。
残念な企業では、この判断基準に「声の大きさ」や「社内政治的なパワーバランス」が働くことがあります。
その結果、ビジネスへの貢献度が非常に低く、「◯◯部長満足度の高いシステム」「◯◯部門満足度の高いシステム」、最悪なケースとしては「ベンダー満足度の高いシステム」や「情報システム部門満足度の高いシステム」が完成してしまいます。
そうならないためにも、明確な数字による判断基準を持つべきなのです。
3.優先順位を記述する
この優先順位を記述するということも、一般的に入手できるR.F.Pの書き方指南にはあまり書かれていない事です。
その背景には、現在流通しているR.F.Pの記述後に調達するソフトウェアの開発手法が、「ウォーターフォール手法」と呼ばれる、１世代前の非常にリスクの高い開発手法を用いることが前提になっているからです。
ウォーターフォール手法のリスクが高い理由は、プロジェクトの最初の段階で、すべての機能・すべての予算・そして全てのスケジュールを確定することが前提になっていることです。
これは、ソフトウェアの完成をゴールとするシステム開発ベンダーならよいのですが、ソフトウェアを利活用することで収益性を上げたいユーザ企業にとっては、リスクの高いことです。
3-1.QCDを確定させる有益性はあるか？
R.F.Pを記述する時点では、そのプロジェクトに対して最も情報が少ない状態であり、かつ最も学習習熟度が低い状態です。そのような極めて未熟な状態にも関わらず、そのシステムに対するすべての機能・予算・スケジュールを決定することは、果たして有益なことでしょうか。
私は全くそうは思いません。
この時点で重要なことは、理想の機能・予算・スケジュールに関する大まかな青写真を描くことであり、その青写真をどういった順番で実現すれば、早期に投資したコストが早い段階で回収可能かという予測です。
もちろん、予算とスケジュールが確定しないことには、社内で稟議がまわせないという都合もあるでしょう。しかし、ユーザ企業におけるソフトウェアの導入目的は「ソフトウェアを完成させること」ではなく「ソフトウェアを利活用して収益性を向上すること」です。
よりシンプルな表現をすれば、「ビジネスを成長させること」となるでしょう。
ビジネスを成長させるには、試行錯誤が必要です。そして試行錯誤には「優先順位」が重要です。
3-2.試行錯誤こそ成功に必要なこと
なぜなら、試行錯誤とはスモールステップで小さな行動を積み上げながら軌道修正しつつ、設定した目標に少しづつ近づいていくことだからです。小さな活動の積み重ねなので、複数の事柄を同時に、大きく進めることはできません。
ウォーターフォール手法は、最初に定義した全ての機能を全て開発して、全てリリースすることが前提になっています。これを「ビッグバンリリース」と呼びます。
しかし、先にも上げた通り、ソフトウェアの３分の２は実際にはビジネスに貢献していないのです。
であれば、そのようなムダな投資が発生しないためにも、段階的に少しづつ、必要な機能を、必要なタイミングで、必要な品質でリリースするほうが、より確実なリターンが望めます。
現在は、一昔前のように、狙った通りの投資をすれば、そこそこのリターンが得られるような甘い時代ではなくなりました。
卓越した経営者やビジネスパーソンであっても、狙った通りの結果を出すことができない、非常に不確実性の高い時代です。
3-3.ビジネスとITは不可分だからこそ…
そして現在、ビジネスとITは不可分…つまり分けられない時代です。
ということは、ビジネスに試行錯誤が重要なのと同じく、ソフトウェア開発プロジェクトにも試行錯誤が必要だということです。
先に上げたウォーターフォール手法は、試行錯誤が必要なソフトウェアの開発には向きません。
つまり、現在のような環境下におけるソフトウェア開発には向かないということです。
もし、あなたのプロジェクトが、最初に描いた青写真通りの機能が完成しさえすれば、確実に望むリターンを期待できる単純なものであれば、わざわざ優先順位を決める必要性は低いかもしれません。
しかし、複雑で不確実性の高い問題を解決するためのIT投資であれば、ぜひその問題を解決するまでの優先順位を決めて、スモールスタートでかつ、定期的に振り返りをしながら、その優先順位が目標を達成するために本当にベストな方法なのかを常に検証し、軌道修正をしながら前に進むことが必要でしょう。
その為にも、ソフトウェアのリリース優先順位は、ユーザ企業が主体的に決めるべきなのです。
まとめ
この記事では、一般的に入手可能なR.F.Pの書き方指南書にはない、３つの要素について解説しました。
この記事で一貫してお伝えしたかったことは、現在入手可能なR.F.Pの書き方を解説する情報が、ウォーターフォール手法を前提にしていることです。
記事中でも述べた通り、ウォーターフォール手法は、既に時代遅れでリスクの高いソフトウェア開発手法です。
そして、今後主流となるソフトウェア開発手法は、アジャイルソフトウェア開発手法と呼ばれる、小さくはじめて大きく育てるアプローチに向いたソフトウェア開発手法です。
アジャイルソフトウェア開発手法に関しては、弊社のブログでもいくつかの記事を書いておりますので、ぜひそちらも合わせてお読みいただけると、より理解が深まると思います。
最後までお読みいただきありがとうございました。
この記事を読まれた方には、こちらの記事もおすすめです。
