セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

システム開発の見積もりは、覚悟と覚悟のぶつかり合いだ

システム開発の見積もりには、色々な手法があります。

ファンクションポイントとかCOCOMO法とか。

これらはなるべく見積もりの根拠を確かにし、実際の工数とのブレがなくなるようにするために考え出された方法です。

しかし、いくら根拠を以って正確に見積もりを出そうとしても、実際に請負開発を受注する際には、ほとんど意味がありません。

ソフトウェアの開発コストは、色々な要素に左右されるわけですが、最後に物を言うのは「覚悟」です。

ソフトウェア開発費用はブレが大きい

そもそも、いくら正確に見積もりをしようとも、ソフトウェア開発のコストは、ブレが大きすぎます。

不確定要素が多いというのも勿論ですが、同じ機能を納品するにしても、業種や会社、プロジェクト、担当者によって、工程の進め方や求められる品質、仕様の精度が全く違うので役にたたないのです。

例えば、金融系とメディア系では、品質に求められる工数が10倍から100倍程度は違います。

広告やメディア系の業界で100万円ぐらいで流れてる案件を銀行や電力、通信系大手は、数千万から億の単位で扱います。

これは、ひとえに品質に対する要求の無茶苦茶加減から来ています。

ちょっとまえに、ウォーターフォールの話題で盛り上がりましたが、金融系などは、典型的にウォーターフォールを好む業界で、その為、プロジェクトの失敗も多いのですが、それをベンダーに押し付けてガチガチに品質を求めるという、無茶を繰り返した結果、ベンダー側の安全マージンが肥大しきっていて、工数の概念がおかしな事になっています。

それでも、積み上げた実績と大きくなり過ぎた開発工数を受けきれるベンダーが他にいないため発注されます。

例えば、普通に考えて300万あればお釣りが来そうな案件に3000万の値札を付けて、担当者の顔を立てるため10%値引きして2700万で売るなんてことがまかり通っている世界です。

2700万で発注した担当者は300万を自分の実績として「あいつら叩けば下げるんですよw」なんてホクホク顔ですが、僕は真顔でした。

そんな世界での見積もりに、どの程度精度や根拠が必要かは、甚だ疑問ではあるのですが、相手を納得させる舞台装置としては一定の効果があります。

とは言え、300万の世界に生きている人に3000万と言ってもびっくりされるだけなので、相手の予算感をなんとか聞き出して、逆算でそれっぽく仕立てるのが腕の見せ所です。

それでも、制作系のシステム会社(僕の用語で海の民)が、コンペに参加していると、こちら(山の民)の見積もりで300万の案件に平気で30万とかで突っ込んでくるので油断ができません。

完全に赤字だと思うのですが、あちらの世界で働いた事がないので、どうやって成り立っているのかは謎です。

この様に、現実世界の見積もりでは、様々な思惑や皮算用が入り乱れ、魑魅魍魎が跋扈する世界ですので、教科書通りの工数計算なんて全く意味をなしません(と言うのは言い過ぎで、内部的な最低ラインを引くのに役立ちます)。

最終的に必要なのは、その仕事を「受けるのか」「受けないのか」という覚悟ということになります。

受託案件を受注するパターン

良いパターンは、そのお客さんと何回か仕事をしていて、品質レベルや担当者の人となりを把握していて、信頼関係が気づけていることです。

この場合は、安全マージンを限界まで削る事ができますし、工数の根拠についても過去の実績との比較ができますので、かなり確かです。

そうではない、パターンでは、最初の受注はある程度冒険しないと取れません。

馴染みの業者で済むのであれば、そもそも案件の話しが回ってこないので、一見さんで回ってくる案件は、地雷であることが多いです。

「今までの業者と喧嘩別れして、ドキュメントも何もなく、動いているシステムを見て改修して」という案件が、典型例で、これほどまでに世の中には、ドキュメントを書かないシステム屋が多いのか!?と感嘆するほど、お決まりのパターンになっています。

こういった、世間に回っている案件をコンペで取ろうとすると、確実に炎上します。どうやっても無理なのです。

取るとすれば、1件目の案件は捨て身で取りに行って、炎上してでもやりながらコードを整地して、それ以降の案件で儲けを出すというプランも有りますが(というか、儲けを出すにはそれしか無い)、歩の悪い博打な上に、炎上案件でメンバーがドロップする可能性も高いので、ほぼ割に合いません。

これを避けるパターンとしては、個人的な知り合いなど、人同士のつながりを通して、案件を探す方法ですが、そもそもシステムを外注した経験があまりない会社を対象に、需要を掘り起こすパターンになり、営業費用とスキルが要求されます。

少なくとも、半年・一年と仲良くお付き合いをして、信頼関係を築いたうえで、困っていることの相談に乗り、その有効な解決手段がシステム導入だった場合に受注に繋がる可能性が、わずかながら発生するという具合なので、薄く広く各方面に顔を売る必要があります。

あまりの道のりの果てしなさに途方に暮れます。

本を書くとか、業界の有名人になれば、多少楽になるかもしれませんが、営業のために本を書くというのもモチベーションがわかないですし、そもそも売れる本を書くのはもっと難しいです。

そして、どのパターンでも、最終的には「この会社(人)と一緒に仕事ができるだろうか?」という一点に集約され、覚悟が決まれば飛び込むという形になります。

受託開発の厳しさ

そもそも、中小企業にとって、受託開発で生き延びるというのは、かなり無理ゲーです。

もちろん、成功している企業もあるでしょうし、そもそも、僕の営業力は小学生以下幼稚園児未満といったところなので、皆もっと上手くやっているのかもしれません。

受託開発で生き延びる唯一の(言い過ぎか)方法は、お得意様を掴むことです。

大企業で金払いの良い上得意を作り、決して離さないようにすることで、安定的にリスクの少ない案件を受けることができるようになるのだと思います。

実体を伴わない見積もりに意味は無い

営業の上手い下手にかかわらず、システム開発の見積もりに根拠なんてものは乏しく、「客の予算」と「双方の覚悟」で決まると言うのは確かです。

よく社内社外問わず、企画書を元に「見積だけして」という依頼をもらうことがあります(こういうのも大歓迎なのですが)。

しかし、現実的には受注側(つまりこちら側)に「受注するぞ」という覚悟がない限り、あまり意味のある数字にはなりません。

特にスタートアップ案件だったりすると、以前に書いた、必要なシステムを自分自身で知ることのできない「不可知の原則」により、「事前に見積をして発注する」という行為自体、無意味です。失敗して金をドブに捨てるだけです。

そもそもスタートアップ自体が、「覚悟」の塊なので、その覚悟を受け切れる外注業者はいないでしょう。

頑張ってエンジニアを探して自分たちで作らないとダメです。

システム受託業者だって事業でやっているので、開発に費用がかかれば請求するし、スタートアップを成功させるのが目的ではないのです。

落ちない

ダラダラと長くなりましたが、落ちなさそうなのでこのへんで。

システム開発の見積もりについて、思うところでした。

black jelly bean