2023年05月24日

◆ 富士通のバグ多発

 富士通のシステムでバグが多発していることが話題になっている。

 ── 

 バグの多発


 3月から5月にかけて、富士通のシステムでバグが多発している。住民票の発行など。
 コンビニの証明書交付サービスで住民票の写しを取得しようとしたら他人のものが出てきたー。2023年3月以降、同様のトラブルが横浜市や東京都足立区、川崎市で相次ぎ発覚し、注目を集めている。開発元はいずれも富士通Japanだ。
( → 相次ぐ住民票誤交付トラブル、富士通Japanのシステムに何が起こっているのか | 日経クロステック(xTECH)

 詳細は上記記事にある。

 ※ この後もバグは続いた。
   → 今度は徳島市でも判明、止まらない富士通Japan巡るコンビニ誤交付トラブル

 原因は? 


 原因は、富士通の体制がダメなことだが、具体的にはどこがどうダメなのか?
 「富士通の社員は、自分ではシステムを設計しないで、設計の分担を契約社員に割り振っているだけだ」
 という指摘があった。いわゆる多重下請けという体制のせいだ、ということになる。
 確かに、それはその通りなのだが、日本の大規模システム受注というのは、たいていがこうなっている。外国の場合とは違う。どうしてこういう差が生じたのか?
 

 ウォーターフォールとアジャイル


 これについて、「ウォーターフォールとアジャイル」という概念で説明した記事がある。
 (問題は)多重下請け構造によって、正しい手法でソフトウェアの開発がされていないことです。
 ソフトウェアの開発は、米国のシリコンバレーなどではアジャイルという方式で行われています。エンジニアが企画者や実際に使う人と直接コミュニケーションを取りながら開発する方法です。中国もそうですね。この方法によって、新しいサービスが米国や中国から次々と生み出されています。

 それに対して、日本の開発の多くはウォーターフォール方式です。工程別に分けて、モジュールごとに開発します。開発部分を多重下請けで働く人たちが担っています。

――ウォーターフォール方式だと、なぜよくないのでしょうか。

高井氏:私はいつも、システム開発はお絵描きと同じだと表現しています。あなたの好みの女性像を私が描く場合に、ウォーターフォール方式だとまずヒアリングをします。そのヒアリングした文字情報をもとに専門家に描かせて、出来上がったら見せます。これでイメージ通りの絵ができているでしょうか。

――それは難しそうですね。

高井氏:そうですよね。これがアジャイル方式だと、「目の大きさはこれくらいですか」「髪の毛の長さは」「髪の毛の色は」と聞きながら、同時に見せながら描いていきます。小さいパーツの確認も取りながら、全体像も見てもらう。シリコンバレーや中国ではこのようにして開発が実行されているのです。

――アジャイル的な開発が日本で浸透しないのは、どこに原因があるのでしょうか。

高井氏:一番大きな原因は、雇用規制があるからだと思います。システム開発は、開発をしているときと、運用・保守をしているときとでは必要な人数もスキルも違います。欧米では開発を早く済ませることによってクビになります。クビになるという言い方はよくないですが、いいものを早く作った人は、次の職場にもっといい条件で移ることができるのです。
 日本の場合は、雇用規制があることで解雇できません。社内のシステム開発の本来の目的は、自動化を進めて仕事をなくすことです。でもこの人たちや、開発によって仕事を失う人たちのことを配慮しなくてはいけません。そのためウォーターフォール方式にならざるを得ないのです。
( → IT業界の「多重下請け地獄」が横行し続ける真の理由:「IT後進国ニッポン」の病巣に迫る【前編】(1/4 ページ) - ITmedia ビジネスオンライン

 アジャイルでなくウォーターフォールであることが、現実無視のトンチンカンな製品ができることの原因だ、という指摘である。たしかに、ごもっとも。今回のひどいバグも、アジャイルでなくウォーターフォールであることが原因だ、とも言えるだろう。

 対策1(アジャイル)


 上のことからして、「ウォーターフォールでなくアジャイルであることを義務づける」というのが、解決策の一つとなりそうだ。契約条件にこれを入れておけば、ウォーターフォールを採用する富士通みたいな会社は自動的に排除されて、アジャイルをやる会社だけが採用される。そういう会社は、最初は無名なので、採用されにくいかもしれないが、「ウォーターフォールの会社を全部排除する」というふうにすれば、何とかなりそうだ。

 対策2(デジタル庁の介在)


 一方、別案もある。ウォーターフォールとアジャイルの中間(折衷案)みたいな方式だ。これは、本サイトが先に示したもので、次の図で示せる。


dijitalcho7.png


 この図の説明を、再掲しよう。
 受け取ったものをきちんと検収できる(不備がないか確認できる)だけのデジタル知識が必要だ。
 そういう役割を果たすのが、デジタル庁だ。

   (図)


 この図のように、現場と開発者とは、分断されている。両者は乖離している。顧客は、自分が本当に求めているものが何であるかを、うまく説明できない。

 そこで、この両者をつなぐ橋渡しをする者が必要となる。それが、デジタル庁だ。デジタル庁は、次の両方をよく知っている。
  ・ 現場における要求事項
  ・ その要求事項が IT用語では何を意味するかという IT知識


 こうして、橋渡しをする者がいるおかげで、双方の分断は解消される。
( → デジタル庁の問題: Open ブログ

 ウォーターフォールでは、「開発者 → 現場」という、一方的な流れだけがある。開発者は、現場の声を着ずに、一方的に押しつけるだけだ。
 アジャイルならば、開発者と現場は双方向的に交流があるので、情報の不通は自動的に解消される。これが理想だ。とはいえ、これはハードルが高い。
 そこで、開発者と現場の間に、デジタル庁という「介在者」が介入する。この介在者が、双方に御用聞きをして、情報の不通をできるかぎり解消する。……完璧ではなくとも、できる限りのことをすることで、バグの発生を最小限に抑えることができる。
 ※ 特に、過重な負荷テストは必須だ。今回も、そういうテストをやっておけば、誤作動は起こらなかったはずだ。
 ※ なお、「過重な負荷テスト」は大切なので、私もかつて、マイナンバーのシステムでテストしたことがある。その場合、見事にエラーが発生した。その体験記は、下記。
   → マイナンバーが申請できない: Open ブログ (コメント欄)

 ※ 以上のことを実施するためには、デジタル庁の大幅拡充が必要となる。統一的な情報システム部を、大規模に新設する必要がある。要員としては、プログラマーを大量に雇用する必要がある。自分で作るというよりは、納入されたプログラムをチェックするためだ。検査要員である。

 罰金(賠償金)


 今回は、バグがあったせいで、システムの稼働停止に追い込まれた。
 河野太郎デジタル大臣は5月9日の会見で、コンビニエンスストアで住民票の写しが取得できる「コンビニ交付サービス」について、運用している富士通Japanに対してシステムの一時停止を要請したことを明らかにした。
( → 河野大臣、コンビニ交付システムの一時停止を要請 200の自治体に影響 - ITmedia NEWS

  富士通Japan株式会社(以下、富士通Japan)の提供するシステムに起因した度重なる証明書誤発行およびそれに伴う個人情報の漏えいにより、自治体様ならびに証明書交付サービスをご利用の皆様に多大なるご迷惑ご心配をおかけしておりますこと、当社および富士通Japanとして重く受け止め、あらためて深くお詫び申し上げます。
 先般、富士通Japanより公表させていただいたとおり、当社および富士通Japanといたしましては、今後このような事態を起こさぬようシステムの運用を一時停止した上での再点検の実施に向けて、各自治体様と個別に調整を進めるとともにデジタル庁様、総務省様ほか関係機関のご指導をいただきながら準備を進めております。この度、本番環境にて実機点検を行うため、システム環境に応じ、SaaS型サービスでは6月4日(日)、オンプレミス型システムでは5月28日(日)までの期間で証明書交付サービスを停止いただく形での一斉点検実施について、富士通Japanのシステムをご利用いただいている全ての自治体様にお願いをさせていただきました。
( → 「Fujitsu MICJET コンビニ交付」システムの停止を伴う一斉点検について : 富士通

 だが、稼働停止よりは、罰金(賠償金)の支払いの方が効果的だろう。
 つまり、今回のようなバグがあった場合には、多額の罰金(賠償金)を請求できるようにするべきだ。最初の契約に、それを記載しておく。
 どうせ富士通の側は、「バグがあったら賠償金、なんていう契約はできません」と言い張るに決まっている。だから、そういう会社は、自動的に排除してしまえばいい。
 そもそも、アジャイルにしておけば、こういう馬鹿げたバグは生じにくいのだから、最初からそういう開発体制を取る会社と、契約すればいいのだ。
 


 [ 付記 ]
 あちこちでバグが多発しているが、すべてがシステムの欠陥だ、というわけではない。
 川崎の場合は、システムの欠陥ではなく、システムに追加したアドオンの欠陥だった。
  → 川崎市のコンビニ交付で他人の戸籍書類出力、市独自の富士通Japan製システムに原因 | 日経クロステック(xTECH)

 アドオンというのは、システム本体ではなく、おまけで付ける付属品だから、いい加減なものができやすい。これは、システム本体の欠陥とは別だ。
 むしろ、こういうアドオンを別に付けるという体制がおかしい。このようなアドオンは、最初からユーザーの要望を聞いておいて、システムに内在させるべきだった。その分、チェックも厳密にやるべきだった。

 ついでだが、「アドオンがダメだから、システムの全体を稼働停止にする」という判断は、おかしいね。ちゃんと区別するべきだ。

 富士通がダメなのは、ウォーターフォールと多重下請けによる開発体制の欠陥があるからだ。
 一方、アドオンがダメなのは、アドオン開発チームという小規模な開発チームにおける個別の事情だ。
 この両者は、事情が違う。一部の失敗で全体責任を取らせるのは、ちょっとおかしい。



 [ 余談 ]
 「デジタル庁がダメだ」
 という批判もありそうだが、その言い分は、今回については当てはまらない。
 デジタル庁の発足は 2021年9月1日。比較的最近なので、マイナンバーのシステムの発注には、間に合わなかった。
 日程表によるとデジタル庁の主導で、官公庁のシステムの標準化が実現するのは 2023〜2025年度。今年度から徐々に開始予定だという。
  → https://x.gd/l050x



 【 関連サイト 】
  → マイナカード、止まらぬトラブル 政治学者が危ぶむ「政府の勘違い」:朝日新聞



 【 追記 】
 今回の「富士通Japan」という会社は、富士通の子会社なので、富士通本体とは異なる。とはいえ、100%出資の子会社であるし、もともとの富士通の国内サービス事業は、(事業分割の形で)この会社に集約しているので、実際には「富士通本体の一部」であると見なしていい。形式的には、事業分割の形で、別会社(子会社)になっているが、100%出資でもあるし、実質的には「富士通そのものである」と考えて差し支えない。
 トヨタの( 100%出資の)子会社であるダイハツと同様だろう。

posted by 管理人 at 23:10 | Comment(4) | コンピュータ_04 | 更新情報をチェックする
この記事へのコメント
日本でアジャイルができにくいのは雇用関係だけではなく、注文者があまりにもIT音痴なためもあるように思います。とくに官公庁はIT化による人減らしと仕事減らしを避けるために、いままでずっとIT化に抵抗していました。そのためITに詳しい人はいません。こんな人達が注文者なら開発者は対応に困ると思います。
 話はそれますが、私はFortran世代ですが最近になってC#でプログラミングに励んでいます。C#ではクラスという概念があって、一つのクラスは完全に他のクラスから独立しています。そのため大規模開発を細分してそれぞれを独立にプログラミングできます。大規模開発ができるようになっているのはこのおかげなんですね。
Posted by よく見ています at 2023年05月25日 10:02
たぶんITに限らず、多くの技術分野で同様の事象があることでしょう。全部内製でこなしていた時代ははるか昔。「アジャイル」っぽく見せていて実は……という部分も結構見かけます。役所側に知見のある人が居なくなったのも結構前から。
Posted by けろ at 2023年05月25日 11:53
企画・概要設計フェーズは、「ウォーターフォール」、詳細設計・開発フェーズは「アジャイル」は普通にあります。少なくとも対立する概念ではないですね。
問題は"よく見ています"様のご指摘の「ITに詳しい人はいません」に尽きるような。
アジャイル開発は高速開発と同時に高速に検証することですが、実効的にテストできる人材、イレギュラーなテストパターンを発案できる人材が、発注側企業にいないと、絵に描いた餅です。
富士通ジャパンに非がないとは言いませんが、少なくとも印鑑証明書の件でのトラブルに対応するテストパターンを発注側は提示しているのでしょうかね?
Posted by 今日も通りすがり at 2023年05月26日 19:00
> 実効的にテストできる人材、イレギュラーなテストパターンを発案できる人材が、発注側企業にいないと

 それを担当するのが、両者の分断をつなげる介在者(デジタル庁だ)、と図で説明しています。
 21年発足なら、23年のチェックには間に合うはずだが。

> 印鑑証明書の件でのトラブルに対応するテストパターン

 原因ははっきりとは公表されていないが、どれも排他制御に問題があったらしい。
  → https://piyolog.hatenadiary.jp/entry/2023/05/22/000742
 
 そのために必要なのは、多数のアクセスが同時に発生するという、負荷をかけた実施テスト。このくらいは、発注者の指摘を待たずに、開発者が最低限のテストをするうちに含まれる。

 ちなみに、私がプログラムを書くときだって、これよりはもっと負荷をかけたバグ・チェックをやる。プログラムを書く仕事のうち、半分ぐらいは、バグチェックになるはずだ。
 富士通は、それをサボっていたとしか思えない。いい加減な未完成品を出して、「バグが出たら、その都度、直せばいいさ」と思っていたのだろう。いい加減すぎる。
Posted by 管理人 at 2023年05月26日 20:00
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

  ※ コメントが掲載されるまで、時間がかかることがあります。

過去ログ