マイナシステムのテストは十分だったか
「ソフトウェアが改修を前提としているなら、マイナンバーカードを運用するソフトウェアも、気長に改修と改善を待ちながら、発覚した問題に対処していけばいいんじゃない？」
そう思いたいところだが、例えば公金口座の受取口座の登録が他人のものになっていたという事例はどうか。利用者の登録ミス（ログアウトしなかったため前の人の情報が残ったままのところに別の情報を入れてしまった）とされているが、こうした状況は設計段階かテスト段階で対策を打っておいてしかるべきものだろう。
一般の利用者はエンジニアが思いもよらない動作をしたりするものなので、すべてを予測して先回りするのは難しい。しかし、実利用の前に「一般の利用者」に使わせてどういう事態が起こりうるかを洗い出し、対策を打つことはできる。
ただし、時間と費用があれば、だが。
なぜそういうことが行われなかったのか（あるいは行われたが不十分だったのか）。本書が訴えるソフトウェア開発の誤解が、マイナンバー関係の行政の現場に蔓延っていたからではないか、と疑ってしまう。
また、詳しいことは専門家の説明を待ちたいが「マイナンバーで一元管理」というイメージとは裏腹に、実際には「情報を一元管理せず、カードで各々の情報を呼び出す」仕様になっており、この齟齬も仕様設計や運用を複雑化させているように思える。
ソフトウェアは「一品モノ」
４章では「ソフトウェアは一品モノ」であり、それぞれのシステムは依頼に応じつつも、それぞれのエンジニアの思想や思考によってオーダーメイドで作られていることが指摘される。
外からは同じように見えても、中の作りは全く違う（作った時代や、使われているプログラム言語さえ違う）ことがほとんどだ。
あるシステムとシステムを連携させようという時、「相手側」がどんな思想で設計されたものかは、文字通りフタを開けてみなければ分からない。柔軟性を前提にしていたとしても限界はある。
ソフトウェアやシステムを作る側は、当然、開発前の確認期間や開発後の試用期間を十二分に持ちたかったはずであり、筆者（梶原）とはレベルの違うプロのエンジニアたちができる限りのことをやっているはずだと信じたいが、一方でマイナンバーカードの場合、そうした期間をどの程度持てたのかは気になるところだ。
各システムが、設計当初は連携を想定していなかった（かもしれない）一品モノであることを考慮せず、「他の国だってやっているんだ、がっちゃんこして、大人数で気合を入れてやればすぐできるんだろ」という無茶ぶりが、どこからか現場に降ってきてはいなかったかと想像してしまうのだ。
