「システムにはミスがつきもの」はそうだが
マイナンバーカードについて、誤登録などのミスが報じられると「ソフトウェアはバグがつきものなのだから、発覚したミスはプログラムを修正すれば済む話。大騒ぎすることはない」というコメントが散見されるようになった。
運用開始直後のソフトウェアにはミスやバグがつきものだということが、これほど広く知られるようになったかと、（一応）元システムエンジニアの筆者（梶原）としては感慨深くもある。ソフトウェアをハードウェア（工業製品）と同一視せず、「リリース後も改修が続くものだ」とする理解は、それほど一般的ではなかったと思われるからだ。
だが、「改修はつきもの」という理解は、さらなる誤解と表裏一体でもある。今度は「ちょちょっと直せばすぐうまく回るようになるんでしょ？」というソフトウェアに対する誤解が生じてくるからだ。
さらに言えば、「ソフトウェアにバグはつきもの」は、ソフトウェア開発のほんの一面に過ぎない。こうしたソフトウェア開発に関する誤解を解き、ソフトウェアと利用者、テクノロジーのいい関係を構築しようというのが倉貫義人『人が増えても早くならない』（技術評論社）だ。
タイトルは、「プログラマーの人数を増やせば増やすほど、ソフトウェアの完成は早まるのでは？」という誤解に対する回答だ。
〈遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである〉という格言（フレデリック・Ｐ・ブルックス『人月の神話』）を引き、情報共有やメンバー間のコミュニケーション、タスクを細分化して「誰にどこを割り振るか」を考える労力などによって、「むしろ人を増やすことでソフトウェアの完成は遠のく」ことを説明する。
本書ではこうした誤解を8つの章で易しく解説。ソフトウェアやプログラムとはなんであるか、が分からなくても、エンジニア経験がなくても理解できる視点で、具体的にソフトウェア開発の要点を教えてくれるのだ。
プログラムには個性と美学がある
システムエンジニアやプログラマーは「ＩＴ土方」と評されることもある。これは長時間労働などで仕事がきついこと、多重請負の末端にいること、比較的低スキルの仕事で単価の低い仕事をさせられるというブラックなイメージから来る揶揄なのだが、本書を読むとこうしたイメージは一変する。
プログラムにはエンジニアにしかわからない美しさがあり、中でも一流のプログラマーや設計者は一定の美学と得意分野を持つアーティストに例えられているからだ。
確かに（非エンジニアの印象とは違って）プログラムは個性が出やすいものであり、これがソフトウェア開発のマネージメントの難しさに繋がってもいる。個性が出やすいものであるにもかからず、属人性を排除しなければならないからで、それは「後から誰が見ても、何をしているのかすぐわかる」プログラムにしておく必要があるためだ。
文章を「後から誰かが直すことを考慮して書いておく」人はいないが、プログラムは他者による改修を前提としている。これはミスやバグを直すという意味だけではなく、後からどんな機能が欲しくなるか、どういう動きに変えていくか分からないため、プログラムに発展性を持たせるために必要なことなのだ。
マイナシステムのテストは十分だったか
「ソフトウェアが改修を前提としているなら、マイナンバーカードを運用するソフトウェアも、気長に改修と改善を待ちながら、発覚した問題に対処していけばいいんじゃない？」
そう思いたいところだが、例えば公金口座の受取口座の登録が他人のものになっていたという事例はどうか。利用者の登録ミス（ログアウトしなかったため前の人の情報が残ったままのところに別の情報を入れてしまった）とされているが、こうした状況は設計段階かテスト段階で対策を打っておいてしかるべきものだろう。
一般の利用者はエンジニアが思いもよらない動作をしたりするものなので、すべてを予測して先回りするのは難しい。しかし、実利用の前に「一般の利用者」に使わせてどういう事態が起こりうるかを洗い出し、対策を打つことはできる。
ただし、時間と費用があれば、だが。
なぜそういうことが行われなかったのか（あるいは行われたが不十分だったのか）。本書が訴えるソフトウェア開発の誤解が、マイナンバー関係の行政の現場に蔓延っていたからではないか、と疑ってしまう。
また、詳しいことは専門家の説明を待ちたいが「マイナンバーで一元管理」というイメージとは裏腹に、実際には「情報を一元管理せず、カードで各々の情報を呼び出す」仕様になっており、この齟齬も仕様設計や運用を複雑化させているように思える。
ソフトウェアは「一品モノ」
４章では「ソフトウェアは一品モノ」であり、それぞれのシステムは依頼に応じつつも、それぞれのエンジニアの思想や思考によってオーダーメイドで作られていることが指摘される。
外からは同じように見えても、中の作りは全く違う（作った時代や、使われているプログラム言語さえ違う）ことがほとんどだ。
あるシステムとシステムを連携させようという時、「相手側」がどんな思想で設計されたものかは、文字通りフタを開けてみなければ分からない。柔軟性を前提にしていたとしても限界はある。
ソフトウェアやシステムを作る側は、当然、開発前の確認期間や開発後の試用期間を十二分に持ちたかったはずであり、筆者（梶原）とはレベルの違うプロのエンジニアたちができる限りのことをやっているはずだと信じたいが、一方でマイナンバーカードの場合、そうした期間をどの程度持てたのかは気になるところだ。
各システムが、設計当初は連携を想定していなかった（かもしれない）一品モノであることを考慮せず、「他の国だってやっているんだ、がっちゃんこして、大人数で気合を入れてやればすぐできるんだろ」という無茶ぶりが、どこからか現場に降ってきてはいなかったかと想像してしまうのだ。
現場の心情が思いやられる
こうした無知から来る無茶ぶり（圧力）を現場にかけかねない責任者はもちろん、社で何らかのソフトウェアを利用している経営者など、システムにかかわるすべての人たちは今からでも遅くないので〈プレッシャーをかけても生産性は上がらない〉と題する本書の5章を熟読してほしい。
「現場にプレッシャーをかけて完成を急がせると、その代償に品質が下がる」
「急がせたために妥協した品質をリカバリーするのは大変」
「土台がぐらぐらのまま、さらに機能を載せると重ねた機能の分だけ改修もコストも厳しくなる」
「そうして数年たつと、これ以上機能を追加しようにも手が出ない状況に陥る」
これはソフトウェア開発だけでなく、ビジネス全般に当てはまることでもあるが……。
マイナンバーカードへの賛否はともかく、本書を読むと現場の心情にも思いをはせたくなる。
