orangeitems’s diary

クラウド専任の40代インフラエンジニアが書くブログ。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。

システム開発、見積段階の費用が当てにならない件

f:id:orangeitems:20220131122608j:plain

 

さきほど、

 

 

なんてツイートをしたところ、直後に見たニュースがまさに関連していたので面白かった件です。

 

www.tokyo-np.co.jp

 相次ぐ契約変更で費用が膨張したマイナンバー事業で、関連システムの整備・運用で繰り返された29回の変更のうち、23回は利用する自治体からの要望によるものだったことが分かった。複数の自治体担当者は「事前テストが不十分だった」と証言。システム稼働前の検証不足が、運用開始後の変更多発を招いた可能性があり、事業費を増大させた。

 

そう、システム開発時点で全ての要件を明確にし、その後そのまま動くことが保証できるなら金額が増えることはないんです。

手に入れてもいないものについて、あれこれ「こうあるべき」を想像したところで、抜けたり気が変わったりするのが人間というもの。

システム開発の依頼を受ける側はそんなこと、長い歴史の中で十分承知しているのです。だからまずは、柔軟な対応ができるように見積の中に「バッファ」を入れておく。私はもともとの要件の工数に対して、最低2倍、最大5倍くらいは考えます。

だって、受注してから絶対になんやかんや求めてくるじゃないですか。

・この仕様、こうできない?

・打ち合わせしていい?

・追加でこれやってくれない?

杓子定規に、いえ、ご提案時に入っていない仕様ですからできません。追加案件としてご提案しますので別途予算を取っていただけますか?。ってプロジェクト初期からお断り前提なのは角も立つので、そういう状況をできるだけバッファで対応できるようにしておきます。

ただ・・、バッファすら使い果たすような大型の変更が発生したら、さすがに顧客もわかります。これは別の仕事にしようか、提案書作ってくれる?、と。

そうやってITの世界はまわっていて、至極当然のように思えるんです。このマイナンバーの件だって。

事業費が膨らんだというより、事業費を予算化する時点で地方自治体の変更事項を定義できず、追加オーダーが増えてしまったということですよね。

だから、おそらく事業費の見積時点のバッファを2倍にしておけば、きっと予算内に収まっただろうと思います。

結果、デジタル庁が言うようにシステムも安定しているし、利用できる状態にもなっているということで、至って普通で正常だな・・と。

検証不足で事業費が膨らんだんじゃなくて、検証不足で予算が過小だったということですよねこれは。

逆に、お金を払わず仕様変更もせず、さあ使ってくださいを強行すればそれはそれで「使えないシステムに・・・億円」なんて見出しは出るでしょうし、どうすればいいんだ、これで正しいじゃないか、と思ったこの記事でした。

できるだけ当初見積から増額とならないように気を遣ってるけど、限度はあるんですよ・・ね。