システム開発はもっと明朗会計にならなければいけない

数ヶ月前、都内某所に引っ越しを行ったのだけれど、その際、何箇所かに引っ越しに見積りをしてもらってわかったことがある。まったく明朗会計ではないのだ。いろいろ情報を集めた結果わかったのは、きちんと相見積を取った上で、あそこはこの値段だったので、こっちも下げてくれみたいな交渉をしないと、最安値の三倍程度の金額になることもあるようだ。数千円の違いだけならば、たいした話ではないが、数万から数十万違うとなれば真剣にならざるを得ない。正直なところ、引っ越しのために荷物をまとめたり、各種申請で忙しい時になぜわざわざ引っ越し程度のために余計な労力とお金をつぎ込まなければならないのか理解できない。

結局、日通の単身パックという金額設定がほぼ定額のプランを選んだ。値段も安かったので助かったが、それ以上に騙されることがないという安心感の方が大きかった。引越し作業も（これは引越し業者というより作業者によるところが大きいのだろうが）非常にてきぱきと行ってくれて、満足だった。もし、他の会社の最初の見積りを信じたら同じ引っ越し作業に三倍の金額がかかるところだった。

ひるがえってシステム開発の話。もちろん私もシステム開発に従事する人間であるから、見積りの難しさは知っている。特に初期の見積りは、曖昧な前提に基づくため、結果は曖昧にならざるを得ない。「販売管理システムを導入するんですがいくらくらいかかりますか？」と言われても、その条件だけでは、数万円の市販会計パッケージからERPをアドオンカスタマイズした数十億円のものまで想定し得る以上、見積りようがないのは事実である。

しかしながら、お客に立場からすれば不安になるのもわかる。作って欲しいシステムのイメージは漠然とはあって、それを実現してほしいだけなのだから、それが1000万なのか2000万なのか一億なのか業者から教えてもらえるのが当然なのにも関わらず、たいてい予想よりも大きい金額を出してきて（これはSIerがぼったくっているという意味ではない。システムの開発には想像以上にお金がかかるのだ）、前提が代わるたびに追加費用が請求される。お客が不信感を抱くのも致し方ない。

どうやったらこの問題を解決できるか。

まず、見積りは二つのステップから成る。ひとつは要件を決めること。もうひとつはその要件から費用を割り出すこと。

まず、後者について考える。要件が決まれば、KKDなりKLOCなりFPなどで工数を割り出し、工数に対し人月単価をかけ費用を割り出すのが一般的となる。しかしながら、KKDは論外としても、KLOCなりFPがどれくらい信頼できるのだろうかという問題は残る。

ところが、最近 JUAS のソフトウェアメトリックス調査を読んでいて面白いことに気付いた。以下の二つの図を見て欲しい。

まず、KLOCだけれども、まったく参考にならない。個人的経験からも、機能の開発にはそれに付随して考える時間が大半を占めており実際にソースコードを作成する量や時間は重要ではない。また、JavaだろうとPHPだろうと、フレームワークが違えば作成するコード量はまったくことなり、機能要件から想定KLOCを求めるという作業に無理がある（実際、別のページには Java のプロジェクトに限定して全体工数とKLOCを比較したグラフもあるが、まったく相関がみられない）。

それに対し、FPは明確な相関が見られる。しかもこの図は工数ではなく費用で出ている。このことからわかることは、FPを計算出来る程度まで要件が落とし込めていれば、費用は自ずと決まるということである。そして、これより安く発注しようとすれば、プロジェクトの品質、納期のいずれかが割を食うだろうということであり、著しく安く発注するならば、プロジェクトの破綻を自ら招いているということが明らかになる。

あとはFPを求めるだけである、と言ってもそれが難しいのは明らかである。なんせ、要件という曖昧なものからシステム機能にまで落としこむのであるから。そこで提案なのだが、むしろ、この作業を客側と共有してはどうだろうか。要件からシステム機能への落とし込みはお客では難しいだろうから、そこまでは SIer が受け持つ。しかしながら、FPの算出方法はお客に教え、後の費用の計算はお客自身に行ってもらえばいい。予算オーバーであれば、自分自身で機能を削るしかなくなる。

ここまで書いて今までの経験を照らし合わせると、一点うまくいきそうにない点に気付いてしまった。きっとお客はシステム系の管理機能を削り始めるのではないか。たしかにシステム系の管理機能は、データベースを直接修正すればなくても良い機能ではあるものの、矛盾したデータ登録が発生しやすくなってしまい、運用品質を落とすことになる。お客にして見れば、運用品質が低いのは運用者の問題であることにしてしまえるので、削らない理由にまで思い至らないかもしれない（人は概ね自分の理解の及ばない仕事を過小評価するものだ）。

システム開発を明朗会計にするには、もう一段工夫がいりそうだ。