2020.06.03
5月20日にスタートしたものの、その日のうちにトラブルが発生し、即座に受付中止となった雇用調整助成金のオンライン申請。今回に限らず、「政府系のソフトウェア」ではバグが頻発しますが、その原因はどこにあるのでしょうか。
世界的エンジニアが提言、政府系ソフトウェアのミスをなくす方法
先週、「雇用助成金のオンライン申請を停止 開始初日にトラブル」という報道がありました。
厚生労働省は20日から運用を始めた「雇用調整助成金」のオンライン申請でシステムトラブルが発生し、受け付けを停止したと発表した。再開のめどは立っていない。（中略）
厚労省が調べたところ、同じタイミングで申請した人に同じIDが割り振られ、先に登録した人の氏名、携帯電話番号、メールアドレスなどが見られるようになっていた。パスワードや給与情報も見られるようになっていた可能性があるという。
「同じタイミングで申請した人に同じIDが割り振られ」という部分がとても重要で、まともな人がソフトウェアの開発に関わっていたら、決して生じないようなミスです。この手のシステムにとって、IDの発行は要であり、ID発行がだらしないサービスは、麺が茹で過ぎなラーメンのようなものです。
この手のバグは、単に「担当者のミス」で生じるものではありません。大学でコンピュータ・サイエンスを勉強した人であれば、こんな初歩的なミスは決してしないし、この手のバグが紛れ込まないための様々な仕組み（コード・レビュー、アーキテクチャ・レビューなど）が存在するはずです。
つまり、よほどの「構造的な問題」がない限りは、こんなバグが見逃されるはずがないのです。
ラーメン屋で言えば、「麺の茹で方がラーメンの命であることを知らないバイト君が麺を茹でている」ようなイメージです。
これはバイト君が悪いのではなく、バイト君にそんな重要な仕事を任せてしまった店長が悪いのですが、さらに遡れば、そんな店長を雇ってしまう人事システムが悪いのです。
こんなバグが生じる背景には、
- 政府から受注したITゼネコンには自らソフトウェアを書く人・書ける人がおらず、仕様書を書いて下請けに丸投げするだけ
- その下請けは、大学でちゃんとソフトウェアの勉強をしていない文系の派遣社員を低賃金で雇い、劣悪な労働環境でコードを書かせている
- 書かれたコードをレビューをする習慣やシステムが存在しない
- クライアントの打ち合わせ、仕様書の作成、見積書の作成などには膨大な時間を書けるわりに、コードのクオリティを上げることには時間をかけない
- ITゼネコンには役所からの天下りが、下請けのソフトウェア会社にはITゼネコンの天下りが役員・顧問・相談役として働いており、ほとんど仕事をせずに「口利き」だけをして高給をもらっている。
などの、日本特有の事情があると考えて間違い無いと思います。
政府→ITゼネコン→下請け企業→派遣会社→派遣社員という多層構造ゆえに、実際にソフトウェアを作る人は薄給で働かされる上に、当事者意識には乏しく、学校を卒業してから短期間の研修で覚えた上っ面のプログラミング・スキルだけでソフトウェアを作らざるを得ないから、こんな質のものが世の中に出てしまうのです。
日本のソフトウェア作りの構造的な問題に関しては、私は随分と昔から指摘し続けていますが（参照：「ソフトウェアの仕様書は料理のレシピに似ている」2006年3月）、全く改善される様子はありません。
その背景には、「正社員を簡単に解雇してはいけない」という雇用規制があり、それ故に出来た人事制度が、（上流の企業が）せっかく雇った理系の大学卒の人たちをソフトウェア・エンジニアのような専門職の人として養成することを許さなくなっているのです。
先日も、政府が新型コロナウィルス感染対策として「接触確認アプリ」なるものを開発すると発表しましたが（参照：「『接触確認アプリ』を6割が導入すればロックダウンも回避可能？首相が6月のアプリ投入を明言」）、どんなものになるか心配です。
ちなみに、こんな状況を打破する、とても良い方法を提案したいと思います。
政府系のソフトウェアは全てオープン・ソースの形で行うのです。大雑把な要求仕様書と予算は政府が作り、実際のソフトウェアは、公募するのです。
それもこれまでのような（実績がある会社の中から、一番安い見積もりを出した会社が受注する）競争入札ではなく、実際にある程度動くものをソースコード込みで提出してもらいます。
そして、出来の良いものを作ってきた上位3社（個人やグループでも結構です）を選び（この選択過程は全てオープンに行います）、そこまでの労力に対する報奨金（公募時にアナウンスします）を支払い、そしてそこから1社をプライムベンダーとして選び、オープンソースな形でそこが開発を中心になって進め、残りの2社にはコードレビュー、テスト、バグ探しを手伝わせます。
開発費は人月工数ベースではなく、公募時に決めた価格を支払いますが、予定の日時までに完成しなかった場合にはペナルティとして大幅に（40％程度）減額し、そこからは別の1社がプライムベンダーとなって開発を引き継ぎます。
また、リモートワークを可能にするために、仕様書の作成、公募、開発の全てから会議（オンライン会議も含めて）を排除し、全てのコミュニケーションをSlackもしくは相当するサービスを利用した非同期の文字によるコミュニケーションで行います（そしてこれが議事録として残ります）。
例えば、予算1億円のプロジェクトであれば、公募時の報奨金3,000万円（1,000万円づつ）、本開発はプライムベンダーが4,000万円、サブベンダーが1,500百万円づつ、ぐらいのイメージです。
こんな形の公募には以下のような利点があります。
- オープンソースなので、作ったものは（公募で集まったものも含めて）国民の（実際には人類の）共通財産になり、一つの地方自治体が作ったものを別の地方自治体が（そのまま、もしくは改変して）使うなども可能になる
- 実力勝負になるため、天下りによる官民癒着体質から脱却できる
- ITゼネコン、派遣会社のような中間搾取団体が排除される
- 少数精鋭のフリーランス・グループが有利になるため、人材市場に流動性が生まれる
- （会社など作らずに）プロジェクトごとに集まるという新しい働き方が可能になる
先週紹介した、堀江貴文さんの「東京改造計画」が本当に実行されることとなったら、このアイデアも是非とも採用していただきたいと思います。実際にやるとなれば、公募システムそのものも喜んで開発します。
※ メール・BLOG の転送厳禁です!! よろしくお願いします。
コメントをお書きください