こんにちは。
ライジングサン・システムコンサルティングの岩佐です。
この記事では、ITコストが高騰してしまう３つの理由について解説します。
おそらく多くの方は、「なぜITコストはあんなに高いのか？」という疑問を持たれていると思います。
私が考えるITコスト高騰の原因は以下の３つに集約されます。
1.多重下請け構造
2.アウトソーシング比率の高さ
3.一括請負契約
それぞれ、解説していきます。
目次
1.多重下請け構造
もはやこれを問題視しない人はいないであろうと思いつつも、なかなかなくならないのがこの多重下請け構造の問題です。
多重下請け構造とは、営業力のある大手IT企業が受注した仕事を、２次請け・３次請けの企業に段階的にアウトソーシングする構造を言います。
例えば一次請けの企業は、営業窓口とプロジェクト管理を、２次請けの企業は設計のみを、３次請けの企業はプログラミングとテストを、そしてシステム完成後の運用は全く別の企業へと、多段階的に仕事がアウトソーシングされる構造を「多重下請け構造」と呼びます。
これは一見合理的な構造に見えますが、この構造がソフトウェア開発コストを著しく高騰させている一つの要因になります。
例えば一次請けの大手IT企業は、社員の給与水準も高く、顧客を獲得するために多大なマーケティング費用や営業コストをかけています。
これを回収するために、受注金額の取り分が大きくなります。
1-1.ITコストの半分以上は価値を生んでいない！？
一般的には20〜40%というのが私の経験則、そして多くの業界通から聞く水準のようです。
つまり、あなたの会社が5,000万円でソフトウェア開発をアウトソーシングした場合、1,000万円〜2,000万円は、実際のソフトウェア開発に使われるのではなく、彼らがそれまでにかけてきたマーケティング費用、営業コスト、そして全体をマネジメントするための費用..
言わばあなたの会社に取ってほぼ無価値なものに消えていくということです。
もちろん、このことが悪いというものではありません。
一次請けの大手IT企業は、顧客開拓の為に、絶えずマーケットを調査・分析し、多くの営業スタッフを抱えて見込み客と接触し、地道に案件を掘り起こしているのです。
当然そのためのコストはかかります。また、その会社のブランド力を保ち続けるためには、優秀な人材を揃えなければならないでしょうから、給与水準も高めになることは想像に難しくありません。
しかし結果として、ソフトウェア開発をアウトソーシングした時の費用内訳の20〜40%は、このような直接あなたの会社の利益に貢献しない費用に消えていきます。
また、ソフトウェア開発プロジェクトの打ち合わせの場で、ほとんど発言もせず、ただ座って話だけを聞いているソフトウェア開発会社側の人を見たことはないでしょうか。
こういった方は、何の価値提案もせず、ただ座っているだけで間を抜いている可能性があります。
私も1〜２回ほど遭遇した経験があるのですが、名刺は１次受け企業の会社名とロゴが入っているにもかかわらず、実際には別の会社に所属する人で、ただ座っているだけで受注額の１〜２割を抜いていく業者がいます。
このような会社が間に２〜３社入ると、発注費用全体の６〜７割程度は全く無価値なものに消えていきます。
そして、実際に仕事をする最終下請けに回ってくるお金は、全体の半分以下。
これでは、いくら技術力があっても仕事に対する動機づけが上がるわけがありません。当然、実力のあるエンジニアをしっかりとアサインすることもできないので、できあがってくるものは相当品質が悪くなります。
しかも、要望を伝える側の企業と、実際につくるプログラマの間には何社も入っているので、言わば伝言ゲームのようになってしまい「情報の質」が劣化します。
その結果、「伝えていたものと出来上がって来たものが全く違う」といった「よく聞く」問題が発生します。
1-2.頼りになる情報システム部門担当者は少ない
私が残念に思うのは、受注側も発注側も、このことを「異常」だと感じていないことです。
特に発注側の窓口が情報システム部門の場合、「まぁIT業界なんてそんなものだ」と、ある意味「業界通」のように振る舞ってしまい、自社の利益のためにそこを突き崩していくような行動を起こす人が極めて少ないのです。
実際私も１０年以上、情報システム部門で社内SEの仕事に従事していたので気持ちは解ります。この構造を突き崩すのは非常に難しいです。
さらにソフトウェア開発プロジェクトは非常に失敗率の高い投資でもあります。
結果、「もし失敗しても大手の◯◯に依頼してダメだった」という理由であれば、まだ言い訳もできます。
それが名もない中小のソフトウェア開発ベンダーにアウトソーシングして失敗すると、「なんでそんな会社に頼んだんだ！」と言われることは目に見えています。
特にIT投資の稟議決裁権のある世代の方々は、この大手ブランド志向が非常に強いのが特徴です。
もし、プロジェクトが失敗しても「大手の◯◯に頼んでも失敗するのか…」と、ある意味失敗に対する「納得感」が得られれば、発注窓口になるスタッフへ降り注ぐ火の粉も少なくなることが期待できます。
結果、情報システム部門のスタッフも、問題があることはわかっていながらも、それを解決するために具体的な行動に打って出ることが非常に難しい、根深い問題なのです。
少し長くなってしまいましたが、ITコストが高騰してしまう理由のひとつとして「多重下請け構造」を挙げました。
2.アウトソーシング比率の高さ
これはより直接的な表現をすると「丸投げ」が多いということです。
実はソフトウェア開発は、自社でやるべき部分をしっかりとやれば、コストは相当下げることができます。
自社でやることと言っても、それ程難しいものではありません。プログラミングの知識もいらないですし、ネットワークの知識も必要ありません。
もちろん、これらの知識があるに越したことはありませんが、中途半端な知識があるだけでは、かえってコスト高になる可能性もあります。
自社でやるべきことは、IT投資を通じて一体何を実現したいのか、何の問題を解決したいのかを徹底的に分析し、それを可視化することです。
一般的には、この可視化されたドキュメントの事を「R.F.P（提案依頼書）」と呼びます。
2-1.RFPの記述はユーザ企業が最低限実施すべきITコストの削減策
このR.F.Pをしっかりとまとめるだけで、ソフトウェアの開発費用は軽く２〜３割は落ちるはずです。
最近はR.F.Pの記述を専門にサポートするITコンサルタントもいますし、関連書籍もたくさんあります。またネットにもR.F.Pの書き方に関する情報はかなり出回っているので、ぜひ研究してみてください。
実は弊社も、起業した時に最初に始めたサービスは、このR.F.Pの記述をサポートする事業でした。
実際、数社のお客様のR.F.Pの記述をサポートさせていただきましたが、やはり第３者の目線が入ると、自社の課題や目指すべき方向性がより明確になります。そしてまた違った目線からIT投資や課題を俯瞰できることが、非常に喜ばれたことを記憶しています。
また、私自身が社内SEをしていた時も、半年間かけてR.F.Pを作りこんだことで、結果的に「億レベル」の開発コストを削減した経験があります。
R.F.Pはうまく記述すれば、開発コストを一気に下げることができる非常に有効な手段です。これからソフトウェア開発のアウトソーシングを検討されている企業はぜひ挑戦してみてください。
2-2.RFP記述にあたってのアドバイス
ここでひとつ、いくつかのR.F.Pを作ってきた私から２つのアドバイスです。
よくR.F.Pに予算金額は記述すべきか否か…というご質問を受けるのですが、私は必ず記載したほうが良いとお応えしています。
できれば、ここに記述する予算は、実際の手持ちの予算の７〜８割程度の金額で記載するのが良いでしょう。
優秀なベンダーであれば、その予算の中で最大限、お客様が実現したいことを考えて提案をしてくれます。
逆に残念なベンダーであれば、その予算を度外視して、どこかの会社に提出した提案書のコピーを、社名だけ変えて提出されるケースもあります。
次に、少額でも良いのでR.F.Pに対する提案費用を支払うことをぜひご検討ください。。
日本では未だに「提案はタダ」という風潮がありますが、実は提案書を書く仕事というのは非常に難しく、本来であれば経験のある優秀なスタッフを数週間張り付かせて行いたい作業です。
しかし、提案に対してお金を支払う企業はまずないので、どうしても「やっつけ仕事」のような提案になってしまいます。
結果、とても自社の課題解決の為の提案書ではないと思われる「トンチンカン」な提案が出てくることになります。
逆に、10〜20万円でも良いので、少しでもお金を入れる企業であれば、提案する側のベンダー側の熱の入れ方も変わります。
提案に対してお金を支払うことに稟議がおりる会社はほとんど無いと思いますが、質の高い提案にはお金を払っても絶対に損はありません。
是非一度検討してみてください。
3.一括請負契約
私はこの一括請負契約が、先述した２つの問題をも内包する最も根深い問題だと思っています。
一括請負契約の最も大きな問題は、受注する側がソフトウェアの完成責任を追う契約です。しかし、ソフトウェアを発注した時点ではその「完成が定義できない」もしくは「何をもって完成とするのかが非常に曖昧」なのです。
さらに契約時点で決裁される「見積もり金額」の算出も、冷静に考えるとかなりおかしなことに気づきます。
つまり「ゴールがどこかわからないのに、そこに行き着くまでの金額は◯◯◯◯万円です。」という契約になっているのです。
ベンダー側は「見積もり」…つまり「予測」として提示した金額にもかかわらず、いつの間にかその金額は「コミットメント」に変わってしまい、必ずその金額で完成させるという約束事になってしまうのです。
3-1.過大な見積もりバッファ
このような契約条件なので、ベンダーは「不測の事態」に備えるために、過大な見積もりバッファを積み上げます。
つまり、最初は「5,000万円でできるかも…」と見積もりしても、開発の過程で次から次に新しい要求が発生する可能性を見越して、1,000万円・1,500万円・2,000万円と、保険としての金額を積み上げておくのです。
この過大な見積もりバッファの存在は、何もベンダーが悪いということではありません。
完成が定義できない状態、もしくは完成の定義が非常に曖昧な状態にも関わらず、作り手側が「完成責任」を追わなければならないという構造に問題があるのです。
また、過大な見積もりバッファが積み上げられるには、「納期の絶対死守」という商慣習も影響しています。
例えばあなたが、上司から「◯◯◯の資料を作るのにどれぐらいの時間がかかる？」と聞かれた時に、ざっくりと２日程度でできると見積もったとします。
しかし、「絶対に２日で仕上げられるか？」と問われると、すごく不安になるのが人としての自然なメンタリティです。
結果、やはり３日ください。５日くださいという形で作業見積もりが増えていきます。
見積もりというのは人間がやるものなので、こういった人の心情を無視して評価することはできません。
何かしらの外部条件だけをコンピュータに入力して計算させれば見積もり期間と金額が出てくるというものでないかぎり、そこには必ず人間の作業や感情といった不確実性が介入してくるのです。
3-2.見積もりは最大16倍の幅でブレる
一括請負契約の金額が合意される時点というのは、そのプロジェクトに対して最も情報が少ない状態です。
つまり、プロジェクトに対する学習習熟度が最も低い状態、未熟な状態で金額の合意がなされます。
この最も情報が少ない段階で見積もった金額は、最大で16倍もの振れ幅があることが研究によって明らかになっています。
こちらに表示した図は、「不確実性コーン」と呼ばれる、時間の経過と見積の正確度の相関関係を表したチャートです。
この図からは、初期コンセプトの段階で最も大きな見積もりで４倍、最も過小に見積もったもので0.25倍となっています。
つまりプロジェクトの初期段階では最大で16倍もの振れ幅が出てしまうのです。
なんとかソフトウェア開発プロジェクトの金額を正確に見積もれる方法はないかと、世界中の優秀な研究者・技術者が日夜研究を重ね、そして試行錯誤を重ねても、この現実は変えられないようです。
また、先に上げたRFPをベンダーに提示して、複数の会社から見積もりと提案を請けたとしても、経験上数倍の開きが出ます。
その理由は、この不確実性コーンの図に全て現れています。
私はこういった現実があることも考慮して、R.F.Pには予算金額を明示したほうが良いと思っています。
そして、見積もりをする側の開発ベンダーは、この不確実性に対応するために「過大な見積もりバッファ」を積み上げます。
この不確実性コーンの事実を知れば、過大な見積もりバッファが積まれてしまうことについても、ある程度納得できるのではないでしょうか。
「それでも金額を下げろ！」となると、今度は当然、ソフトウェアへの品質に問題が出ることは、想像に難しくありません。
まとめ
この記事では、ITコストが高騰してしまう理由について、以下３つの視点から解説しました。
1.多重下請け構造
2.アウトソーシング比率の高さ（丸投げ）
3.一括請負契約
どの問題に関しても一朝一夕では解決が難しい問題かもしれません。
しかし、この問題をいつまで放置していても、絶対に自然解決はしないですし、何よりプロジェクトを発注する側も受託する側もお互いが不幸になるような構造です。
私達はこの問題を少しでも解消し、お客様の費用対効果を上げるために、「多重下請け構造には入らない」「丸投げのプロジェクトは請けない」「全て準委任契約によるアジャイルソフトウェア開発」という３つを実践しています。
業界全体が変わっていくにはまだまだ時間がかかると思いますが、少しでも多くのユーザ企業、そして開発ベンダーがこの問題を解決するための具体的なアクションを起こすことを望みます。
最後に、実はこの記事には、ある大きなコスト要素について記述していません。
それが「運用・保守費用」のコストについてです。
本件に関しては、また別の機会に、ITコストではない別の視点から取り上げたいと思います。
最後までお読みいただきありがとうございました。
この記事にご興味を持たれた方には、こちらの記事もおすすめです。
