さきほど、
案件の見積なんて、どうせ要件通りには進まないし打ち合わせあれこれ求められるし、準備のための検証の時間もあるし、あれやこれやで高くなるけど、譲らない。
— orangeitems🍊 (@orangeitems_) January 31, 2022
で、始まったら、はい要件変わった、打ち合わせ発生、検証実施、そうなるよね。
なんてツイートをしたところ、直後に見たニュースがまさに関連していたので面白かった件です。
相次ぐ契約変更で費用が膨張したマイナンバー事業で、関連システムの整備・運用で繰り返された２９回の変更のうち、２３回は利用する自治体からの要望によるものだったことが分かった。複数の自治体担当者は「事前テストが不十分だった」と証言。システム稼働前の検証不足が、運用開始後の変更多発を招いた可能性があり、事業費を増大させた。
そう、システム開発時点で全ての要件を明確にし、その後そのまま動くことが保証できるなら金額が増えることはないんです。
手に入れてもいないものについて、あれこれ「こうあるべき」を想像したところで、抜けたり気が変わったりするのが人間というもの。
システム開発の依頼を受ける側はそんなこと、長い歴史の中で十分承知しているのです。だからまずは、柔軟な対応ができるように見積の中に「バッファ」を入れておく。私はもともとの要件の工数に対して、最低２倍、最大５倍くらいは考えます。
だって、受注してから絶対になんやかんや求めてくるじゃないですか。
・この仕様、こうできない？
・打ち合わせしていい？
・追加でこれやってくれない？
杓子定規に、いえ、ご提案時に入っていない仕様ですからできません。追加案件としてご提案しますので別途予算を取っていただけますか？。ってプロジェクト初期からお断り前提なのは角も立つので、そういう状況をできるだけバッファで対応できるようにしておきます。
ただ・・、バッファすら使い果たすような大型の変更が発生したら、さすがに顧客もわかります。これは別の仕事にしようか、提案書作ってくれる？、と。
そうやってITの世界はまわっていて、至極当然のように思えるんです。このマイナンバーの件だって。
事業費が膨らんだというより、事業費を予算化する時点で地方自治体の変更事項を定義できず、追加オーダーが増えてしまったということですよね。
だから、おそらく事業費の見積時点のバッファを２倍にしておけば、きっと予算内に収まっただろうと思います。
結果、デジタル庁が言うようにシステムも安定しているし、利用できる状態にもなっているということで、至って普通で正常だな・・と。
検証不足で事業費が膨らんだんじゃなくて、検証不足で予算が過小だったということですよねこれは。
逆に、お金を払わず仕様変更もせず、さあ使ってくださいを強行すればそれはそれで「使えないシステムに・・・億円」なんて見出しは出るでしょうし、どうすればいいんだ、これで正しいじゃないか、と思ったこの記事でした。
できるだけ当初見積から増額とならないように気を遣ってるけど、限度はあるんですよ・・ね。
