最近、マイナンバーカード関連のシステムトラブルが連日のように報道されている。システムのバグを完全になくすことは不可能であり、システムトラブルは避けようがないとも言えるが、バグ以前の運用設計の不具合も散見される。さすがにひどすぎると感じてしまう。
発注する側がシステムを軽んじているのではないだろうか。システム構築を簡単に考えすぎているのではないだろうか。また、受注する側もコストを下げるために最低限の機能すら下回るようになっているのではないだろうか。
以下に述べることはシステム構築の相見積もりで起こりがちなことである。何か特定のシステムのことを念頭に置いているのではなく、多くのシステムに当てはまる、日常的に目にすることである。マイナンバー関連のシステムで同様のことがあったかどうか、それは分からない。また、実際の開発においては多重下請け構造の問題も絡んでくるが、システム開発に携わったことのない人にも理解されやすいよう、今回はあえて触れない。見積もりの部分にのみ焦点を当てる。
システム構築の相見積もりに当たり、発注者側から複数のシステム構築業者に提案依頼書が提示されることがある。ここには大まかな要件が書かれているのみであり、システム構築事業者はこれを基に提案書（概算見積もり）を作成する。
この提案書の時点で他事業者よりも高額の見積金額であったら、検討対象から除外される可能性が高い。そのため、提案依頼書から読み取れる最低限の機能に絞って見積もり金額を算出することになる。そうしなければ、検討の対象にすらならないのだ。設計段階に入ったら当初の見積金額では収まらないことも分かった上で、それでも最初の段階では安価に見せなければならない。多くの場合、「提案依頼書に書かれていない事項については見積金額に含まれず、詳細設計時に改めて見積もりを提示する」旨のことが記載されている。
提案依頼書はせいぜい数ページから数十ページ程度のことが多い。これが、概要設計書になると10センチのファイルになり、詳細設計書になるとファイルが数冊分になることも珍しくない。つまり、実設計時には提案依頼書に書かれていない膨大なことを補足する必要があるのだ。よく、「システム構築を依頼すると概算見積もりの数倍の費用が掛かった」という話を耳にすることもあるが、当然とも言える。概算見積もりの時点では最低限にも満たない程度のことしか盛り込まれていないのだから。
時折、システム構築に携わったことのない人に説明するときに、「とりあえず動けばいいという程度のシステムを作るのならさほど難しくない。実運用面や耐障害性、保守性まで考慮したシステムを作るのが難しいのだ。」と話すことがある。例えば、運用面において理想的なケースしか想定しないのではなく、イレギュラーなケースをどれだけ想定してシステムに組み込むかで大きく異なってくる。特に、システムを操作する人が特定の担当者のみの場合と、不特定多数の場合とでは想定する範囲が天と地ほどの開きがあると言ってもよい。
このような点をどこまでシステムに盛り込む必要があるのか、これは発注者と受注者双方が開発期間やコストを相談しながら決めるしかない。しかしながら、当初の概算見積もり額が重しとなって、致命的な欠陥を抱えたまま運用開始してしまうことも多々見受けられる。
提案依頼書に書かれている程度の内容でシステムを構築した場合、とてもではないが実運用に耐えうるものとはならない。
