システム開発で正確な見積もりが不可能な理由
世の中には大小さまざまなシステムが使われていて、その開発をシステム開発の会社等に依頼する時は必ず見積もりを作ってもらうと思います
開発する側の人間からみると、正確な見積もりを出すのは案外難しかったりするので、その辺を１開発者の戯言だと思って聞いてほしいです
とあるシステム開発の例
「こんなシステムを作ってほしんだけどー」
「わかりやっした！ じゃ、見積もり作りますねー」
そして数日後、
「あのシステム開発の案件なんですけど、○○円になりますー」
「ふーむ、なるほどー。ちょっくら社内で検討しますねー」
おそらく依頼する会社は複数の開発会社に見積もりを書かせて、値段やその開発会社の信頼性なんかを軸にどこに開発をさせるかを検討します
ここで例として、とあるサービスを運営しているXYZ社がシステムの開発を依頼する場合で考えてみます
サービスは以下の画面１個のみ
名前をフォームに入力して、送信ボタンを押すだけのいたってシンプルなシステム
このシステムを、例えば、３つの開発会社A,B,Cに見積もりを依頼して、出してきた金額は以下のものだったとします
A社「100万円」
B社「200万円」
C社「300万円」
この３つの見積もりをみたら、金額だけなら誰もがA社に依頼したいと思うでしょう
同じシステムを作るのに、A社とC社を比べると三倍も開きがあります
これはあくまで例ですが、システム開発の見積もりは実際にそれくらいに開きが出ます
それはなぜか？
不確定要素をどの程度バッファーとして盛り込むか
システム開発とはそもそも、基本的には顧客の要求する仕様を実現する、いわばオリジナルのオーダースーツを作るようなものです
既成のスーツとは違い「胴回りは細めで、肩周りはゆとりをとって、腕丈は長く」
そんな細かいオーダーに答えます
つまり、開発する方から見ると今までやったことがない内容も多分に含まれます
スーツの例だと、「胴回りを細くしたスーツは今まで作ったことがないな・・・」
と言ったケースです
その今までやったことがない不確定要素をバッファーとしてどの程度盛り込むかで金額に差が出てきます
バッファー無しの場合
バッファーが一切ないと、実装が順調に進んでるうちはいいのですが、一度不確定要素による足踏み状態になれば、すぐさま見積もり金額から足が出て赤字の状態に突入してしまいます
バッファー山盛りの場合
では逆にバッファーを余裕を持って山盛りに積んでおく場合はどうでしょう
これなら不確定要素によって多少作業が止まってしまっても赤字になることはありませんが、見積もり金額が高くなります
当然、依頼する方はこの見積もり金額に納得しません
実は裏では膨大な処理が
このXYZが運営するサービス、見かけはシンプルなシステムですが、その裏には膨大なシステムが動いていて、入力された名前を元に国民台帳を検索して照らし合わせ、電話番号と住所を引っ張ってきて、他のサービスと連携させる
そんな処理が裏では動いていたとしたらどうでしょうか
Aの見積もり金額では大赤字かもしれないし、Cですらギリギリ黒字かもしれません
ちょっと例が極端すぎて実際にはあり得ないかもしれませんが、見積もりの時には気がつかなかった小さな機能というレベルでは十分にあり得る話です
「そんなものはソースコードを見ればわかるだろう」
と言う人もいるかもしれません
確かにその通り
ただ、他人の書いたスパゲッティー化したソースコードを読むのは時間がかかります
時間がかかるということはコストがかかるということと同義です
見積もりの失敗はプロジェクト炎上につながる
システム開発において正確な見積もりは、請け負う側にとってそのプロジェクトが黒字になるか赤字になるかという重要な要素を含んでます
例えば上の例で100万円を提示してきたAは、見積もりが甘い可能性があります
もしかしたらバッファーが０に近いかもしれません
その場合、実際にはAの想像を超える開発コストが必要になる可能性があります
その場合Aはどうするか？
想像を超えた分の実装コストは赤字になってしまうので、とにかく早く終わらせて赤字を圧縮したいと考えます
システム開発とはほとんどが人件費
人のコストです
開発にかかる時間が長くなればなるほど、コストは膨らんでいきます
手っ取り早く動くだけを目標としたプログラミングをすると、ソースコードは汚くなりガチです
「ソースコードがいくら汚くてもとりあえず動きさえすれば良いし、顧客は動いていれば内部の作りなど関係ない。」
そういう考え方もあります
しかし、そういうソースコードは保守作業がとても大変で、例えばちょっとした機能追加にも時間がかかるようになります
とてもじゃないけどその数年後に待ち受けるだろうシステム移行なんかやれたもんじゃありません
見積もりの失敗を防ぐには
以上のことから見積もりの失敗は、開発する方だけでなく依頼する方にとっても痛手が大きいものとなります
双方が得しない結果なのです
ではどうすれば良いのか
これは全てに当てはまるケースではないと思いますが、あくまで一例ということで開発を依頼する側ができることを考えてみました
機能を説明できる仕様書を作ってみる
システムの仕様書って以外と無いことが多いです
あったとしても古くなっていて、ほとんどあてにならない場合も多い
「仕様書ってなにそれ？美味しいの？」
そんなサービスに携わったことのあるエンジニアは多いと思います
特にウェブ系は多い傾向にあります
そうなると見積もりを出す方としては、現状のサービスとソースコードやデータベースを元に見積もりを取ることになります
んが、これはかなり時間のかかる作業です
開発を依頼する方にとっては、見積もりのために時間を割くのはそれ自体がコストになります
だからなるべく、今ある物（サービスやソースコード）を開発する人に丸投げしてみてもらおうとします
依頼するかどうかの決まってない人間に、多大な時間をかけた上で結局依頼しないのは無駄なコストに他ならないので、だからなおさら丸投げしようとします
開発するシステムが誰にでもわかりやすいシステムなら良いのかもしれません
しかし業種によっては専門用語だったり、独特な商習慣がシステムに含まれていたりします
こういうものを理解せずに見積もりを作ると、金額が甘くなり最後に炎上する結果に繋がります
とはいえ一々開発する人を呼ぶたびに説明していたのでは労力が半端ないでしょうから、簡単な機能を説明した仕様書を作成するのはどうでしょうか
そうやって既存のものを丸投げするのではなく、ある程度依頼する方からも歩み寄ることが必要だと思いますね
多少の見積もり費用を支払う
見積もりを出すのは無料
これが見積もりを甘くしてしまう最大の要因かと思います
なぜなら、システムやソースコード、仕様書を見てどの程度の規模なのか、実現できるのかを算出することは、それ自体が開発作業に片足を入れる行為だからです
例えば、仕様書やソースコードからどのくらいの実装コストが必要かを算出するのに２日間かかったとします
その後、無事に契約となり実装に10日間かかったとします
しかし開発する人間のコストとしてはこの実装にかけたうちの２日間は、見積もりに費やした2日間となんら変わりません
やってる内容は異なりますが、開発する人間を2日間使ったという事実は変わらないんです
「いやいや、見積もり作業とプログラミングは作業が違うからそもそも単価が違うでしょ」
という人がいるかもしれません
確かに会社などの複数の人間が分担して作業している場合はその論理は当てはまるかもしれませんが、個人で請け負う場合は関係なかったりします
開発する方からすると、見積もりを出す段階というのは当然ですがまだ契約に至るかわかりません
だから時間をかけて正確に見積もりを出しても契約に至らないと、その見積もりにかけた時間は無駄なコストになってしまいます
だからあまり見積もりには時間をかけたくありません
しかし、そうすると甘い見積もりが出来上がるというわけです
そこで多少なりとも見積もり費用をもらえれば、その見積もりを出す作業は仕事として成立します
だから正確な見積もりになる可能性がグッと高くなり、その後の無駄なコストを抑えられる結果となります
期日を余裕を持って設定する
「システム開発は期日よりも遅れるもの」
とんでもないことを言って様に聞こえると思いますが、依頼する側はそう考えておくと割と失敗が少ないと思います
なぜならシステム開発は不確定要素が多く、予想どうりには進まないことが多いからです
海外のゲームやソフト会社を見てみると、よくリリース予定日が延期になります
まるで「リリース時期なんてあってないもの」とでも言わんばかりに延期します
日本は期日を守る意識が異常に強すぎて、その日までに絶対間に合わせなければならないことが多いです
システム開発のスケジュールが期日から遅れそうになると、どうなるか
まずエンジニアが終電帰りになります
それでも終わらないときは徹夜、休日出勤と続きます
そうなるとエンジニアは「とにかく早く実装を終わらせる」ことが大きな目標に切り替わります
そうするとソースコードは汚くなり、バグが多いシステムになりソフトウェアの品質は大幅に下がります
結果的にろくに動かないシステムが出来上がり、疲弊したエンジニアは退職し、残ったシステムはバグまみれでろくに稼働もできず、移行も困難
そんな状況はシステム開発ではよくある話です
だからこそ期日は余裕を持って設定し、多少遅れたとしても影響が出ない様にしておくことが重要です