2023年4月21日、新潟県は公文書管理システム上に登録された文書の添付ファイル約10万件が消失する事故が発生したことを公表しました。ここでは関連する情報をまとめます。 大量ファイル消失も県民への影響限定的と見解 2023年4月9日にファイルの消失事故が発生したのは県が運用していた公文書管理システム。2023年3月24日21時から2023年3月31日23時59分までにシステムに登録されたファイル10万3,389件が消失したことを事業者が確認した。新潟県は今回のファイルの大量消失は、庁内業務（庁内の意思決定手続きにかかるもの）で処理が既に行われたものであって、県民や事業者などへ直ちに大きな影響が及ぶことは想定していないと見解を示している。また事業者によれば、今回の事故は新潟県の公文書管理システムでのみ生じたもので、他の地方公共団体では発生していないとしている。 新潟県は行政DXの一環で庁内の

5/18 追記色々情報が出てきたので答え合わせ。 前提として、 接種番号は自治体が発番する。そのため、このシステムは、入力された接種番号が正しく存在する番号かどうかさえ確認するすべはない（形式的に間違っている番号はわかる）。 接種番号は自治体が発番するため、接種番号と接種者の情報を紐付けられるのは自治体のみ。接種番号に対応する郵便番号や生年月日も、このシステムはわからない。 接種券は、このシステムが開発着手する前から印刷されていた。チェックディジットやハッシュは、その時点で接種番号の仕様に含まれていなかった。 大規模接種会場の予約システムなんて話が裏で進められ始めたのが今年の1月。接種券の印刷・送付の通達が出たのは去年の12月。　その通達では、券番号として、自治体内で一意であることしか定められていなかった。 このシステム、ひいては大規模接種の目的は、早期にワクチン接種を完了させること。　し

「国でシステムを導入する難しさを感じた」――平井卓也デジタル改革担当相が2月12日の会見で、政府の接触確認アプリ「COCOA」の不具合について、厚生労働省担当のCIO（最高情報責任者）からヒアリングを受けたことを明らかにした。会見では不具合の原因がアプリのAPI連携にあったことを説明した上で、今回の不具合から得た課題やデジタル庁を創設する意義などを改めて強調した。 COCOAは陽性者と1m以内、15分以上の接触があったユーザーに通知を送るアプリ。厚生労働省は2月3日、Android版アプリに新型コロナウイルス陽性者と接触したユーザーへの通知が送られない不具合があったと発表。厚労省によると2020年9月28日のアップデート以降、Androidでは接触通知APIから出力される値が想定と異なっていた。このため、接触が正しく通知されなかったという。 こうしたことを踏まえ、平井大臣は今回の不具合の原

接触確認アプリの不具合という問題の所在は、OSSコミュニティではなくリリースプロセスの不備にあるのでは いよいよリリースされた厚生労働省の接触確認アプリですが、「ストアで接触確認アプリと検索しても見つからない」「利用開始の日付が更新されてしまう」「初期設定時にBluetoothの許可をしないとアプリが立ち上がらない」などといった不具合が見つかり、Twitter 等で、接触確認アプリのベースとなるコードをオープンソースで開発し提供した Covid19Radar コミュニティ（以下OSSコミュニティ）に対して批判が出ています。 しかし、接触確認アプリの不具合に対して、問題の所在をOSSコミュニティそれ自体と捉えて、殊更これを責めるというのは、日本のOSSコミュニティの文化醸成のみならず、IT業界にとっても良いことでは無いと考えます。 「誰が悪い」といった責任論は問題の所在の全容を見えにくくして

厚生労働省は現在、新型コロナウィルス感染症（COVID-19）の“感染が疑われる濃厚接触”を通知する｢接触確認アプリ｣の開発を進めている。 開発を受注したのは日本国内のベンダー。一部で｢米マイクロソフトが受注した｣と報道されたが、これは間違いだ。とは言え、マイクロソフトが無関係というわけではない。そこには多少事情がある。 実は、日本で使われるアプリのベースとなる部分は、個人が中心となったボランティアベースのプロジェクトで、オープンソースとして開発されたものを利用している。 そのアプリは、なぜオープンソースで開発されたのか？　そして、そこに人々はどう関わっているのか、開発にかかわった関係者を取材した。 接触確認アプリがどういうものか、おさらいしておこう。 接触確認アプリは、スマートフォンのBluetooth機能を使い｢一定以上の長い時間、スマホを持っている人同士が近くにいた｣情報を記録するア

ひどい状態だ。ユーザー企業が丸投げしていたシステムの保守運用業務からITベンダーが撤退する動きを捉えようと企画した、この特集「極言暴論スペシャル！」だが、アンケート調査から浮かび上がってきたのは、予想以上に進む保守運用の現場の劣化と、客先に塩漬けにされ将来が見えない技術者の姿だ。多くのユーザー企業で保守運用の現場は「限界集落」と化しており、まもなく大惨事となりそうだ。 この特集ではITベンダーとユーザー企業の関係者を対象に実施したアンケート調査を基に、これまで4回に分けて、ITベンダーの撤退の動きや撤退理由、常駐技術者の境遇、ユーザー企業側の言い分などを紹介してきた。システム開発における多重下請けや炎上プロジェクトの問題がよく知られているのに対して、システム保守運用の問題は表沙汰になることが少なかったが、ITベンダーの“実力行使”により一気に明るみに出たと言える。 アンケート調査から見えて

謝ったんだから、アナタが悪いんですよね。：「訴えてやる！」の前に読む IT訴訟 徹底解説（41）（1/3 ページ） 納品したシステムに「バグが残っているから」と支払いを拒否したユーザー。軽微なバグであり、改修のメドが立っているにもかかわらず彼らが強く出た根拠は「ベンダーの謝罪」だった。 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回は、納品したソースコードの権利は発注者、受注者、どちらにあるのかを取り上げた。 今回は「謝罪」について考えてみたい。 開発プロジェクトで何らかの問題が発生したとき、本当は自分たちに非があるとは思っていないが、「取りあえず謝っておこう」と考えるベンダーは少なくないだろう。筆者も昔、ユーザーテスト時にトラブルが発生し、「正式な謝罪文の提示がないかぎり、ここから先の作業はさせない」とユーザーに言われ、自分たちに非があるかのような文章を

「鶴の一声」が通用しない現場――山本一郎氏が聞く、中小企業におけるIT導入失敗事例の傾向と対策：開発残酷物語（2）（1/3 ページ） トラブルの原因は何だったのか、どうすれば良かったのか、同じトラブルを起こさないようにどういう手だてを取ったのか。実在する開発会社がリアルに体験した開発失敗事例を基に、より良いプロジェクトの進め方を山本一郎氏が探ります。 クライアントの要求がまとまらない、開発工程に入ってから仕様変更が相次いだ、でも納期は変わらない――システム開発の現場では、日々阿鼻（あび）叫喚のトラブルが起こっている。 しかし後から振り返れば、トラブルには幾つかの共通点があり、事前に注意していれば防げたものも少なくないことに気付くだろう。 「開発残酷物語」は、システム開発会社比較検索サービス「発注ナビ」ユーザーのシステム開発会社の方々に過去失敗事例をお話しいただき、契約で押さえるべきポイント

メンバーの「順調です！」を鵜呑みにした結果――山本一郎氏が聞く、会社成長期に起こりやすい炎上事例と対処法：開発残酷物語（1）（1/4 ページ） トラブルの原因は何だったのか、どうすれば良かったのか、同じトラブルを起こさないようにどういう手だてを取ったのか。実在する開発会社がリアルに体験した開発失敗事例を基に、より良いプロジェクトの進め方を山本一郎氏が探ります。 クライアントの要求がまとまらない、開発工程に入ってから仕様変更があいついだ、でも納期は変わらない――システム開発の現場では、日々阿鼻（あび）叫喚のトラブルが起こっている。 しかし後から振り替えれば、トラブルには幾つかの共通点があり、事前に注意していれば防げたものも少なくないことに気付くだろう。 「開発残酷物語」は、システム開発会社比較検索サービス「発注ナビ」ユーザーのシステム開発会社の方々に、自慢（？）の失敗事例を披露いただき、契約

システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい

(追記1：2016/7/11　7/7以降のブログ記事などを追加) (追記2：2016/11/24 延期発表の記事を追加) こんばんは。SE兼PM見習いです。 例のみずほ銀行の次期システム開発が話題になってますね。 blog.livedoor.jp blog.livedoor.jp 毎年この時期に、みずほ案件がグダグダだよね、という情報が出てくるのはもう恒例行事となってますが、開発工程終盤を迎えていよいよヤバイ状況が隠しきれなくなっているようです。 趣味が悪いと言われますが、デスマウォッチャーでして、特にこのみずほ銀行案件をウキウキとウォッチングしているのですが、ここでブックマークしている過去の情報を時系列に振り返ってまとめてみたいなと思います。 2002年〜合併時のシステム障害〜 次期システム案件の話に入る前に、みずほ銀行合併時の大規模システム障害に触れておく必要があります。 https: