神奈川県出願システムトラブルはGmailの影響か？（342号）

前回、Gmailの迷惑メール強化対策についてのお話をしました。

丁度、その折に「神奈川県公立高等学校入学者選抜インターネット出願システム」というシステムでGmailとのメールのやりとりができないというトラブルが主にセキュリティ界隈で話題になっていました。

この件については、内実がよくわかっていない（公開されていない）点がたくさんありますので、この記事で前提としている内容が間違っている可能性が十分にあります。
あくまで筆者の見解としてご覧いただければと思います。

神奈川県公立高等学校入学者選抜インターネット出願システム

これまた恐ろしく長い名前のシステムですが、要は県立高校の受験に必要な手続きを行うための管理システムです。
具体的には、志願（出願）、受験料納付、受検票受領（印刷）、合格発表といった一連の手続きが行えるシステムです。
（以下、当システムを「出願システム」と書きます）

同様のシステムは既に他県でも導入されており、神奈川県でも今年から利用を開始したとのことです。

このシステムでは、学生が決まったアドレスに空メールを送付すると、案内メールが返信されることになっていて、以降は案内メールに従ってアクセスをします。

ところが、一部のアドレスから空メールを送っても、返信が来ないというトラブルが起きました。

そのトラブルが起きたアドレスというのがGmailのアドレスだったのです。

1月9日(火)に「メールの返信が来ない」という問い合わせがあったのですが、1月19日(金)にようやく解決したようですので、調査と対応に約2週間を要したことになります。

何がマズかったのか？

前回の記事をご覧になった方は想像がつくと思いますが、今回は出願システム側の設定に問題があったというのが真相のようです。

このシステムの稼動時期は2024年1月初頭だったようです。
ということは、システムテストはその数ヶ月前に実施しているはずです。

その中では、Gmailなど主要なフリーメールアドレスを使った動作確認も行っていたかもしれません。（行っていなかったかもしれません。その範囲は発注側の指示や費用によりますので、何とも言えません）

もし2023年9月あたりにシステムテスト（最終テスト）を行ったとしても、Gmail側でドメイン認証のルール適用前になります。その時点ではテストＯＫだったでしょうから、開発会社側がテストしても気付くことは難しかったでしょう。

ただ、ドメイン認証に関するルール記述はかなりお粗末でした。メール認証を含むサーバ構築経験はほぼないのでは、と思えるレベルです。

さらに信じがたいのが、解決に要した時間です。
1/9(火)に報告を受けていながら、解決が1/19(金)で10日間を要するのは異常です。

一般に、システム屋にとって本番稼動中のシステムでのトラブルは最優先事項です。
他システムでの打合せなどをキャンセルしてでも全力でトラブル対応に当たります。

トラブル対応に集中できる前提なら、多少複雑なトラブルでも原因を突き止めるのに三日も要りません。
システム屋が三日経っても原因がわかりません、と申告するのはほぼ間違いなく「たまにしか起きないトラブル」「発生のさせ方がわからないトラブル」です。
発生頻度が低いトラブルの原因究明が難しいのは、事象を起こしてシステムの動作を追いかけるという調査ができないからです。

ですが、今回のトラブル対応に立ち戻りますと、どうにも妙なのです。

今回はGmail側からエラーメールが返ってきていたと思われますので、サーバ上のログを調べれば30分で原因は突き止められそうです。
また、ドメイン認証に明るい人が社内にいれば、数時間（遅くとも翌日）には設定変更も終わりそうです。
仮に明るい人がいなくても、協力会社やお客さんに相談すればそのあたりに明るい人は数日中に見つかるでしょう。

ところが、現実には事象発見から対応完了の記者会見まで10日（9営業日）かかっています。発見日と完了報告日を除いても7営業日です。

これはいくらなんでも時間がかかりすぎです。

開発会社はメールサーバの設定やドメイン認証の仕組みをほぼ知らず、勉強しながら対応した可能性が濃厚です。
これが事実であれば、プロにあるまじきお粗末さです。

このような会社に依頼をしてしまった神奈川県の行政も不幸ではあります。
ですが、何の落度もないのにトラブルに巻き込まれた神奈川県在住の学生と保護者の不幸は比較になりません。

このトラブルで実力を発揮できないなんてことがないように祈るばかりです。

発注者の責任

さて、今回の一番の問題はロクな設定もできないダメ事業者にあるのは明確です。

だからといって、発注元である神奈川県を被害者と呼ぶことには筆者は低抗があります。

なぜなら、発注者にはシステム開発会社を管理監督する責任があるからです。

「お金を出した方がそこまでやらんとアカンのか？」とおっしゃる方もおられるでしょうが、システム開発では発注者と受注者の協力が必ず必要です。
スーパーで白菜を買うのとは根本的に違うのです。

最大の理由は「発注者の業務は発注者しか知らない」からです。
さらに「システム屋はその業務を知らないと作れない」からです。

農家はおいしい野菜を作るまでが仕事です。
そのために、各家庭でどう調理するかまでの情報は要りません。

ですが、システムは違います。
システムは発注側からの適切な情報供給がないと作れないのです。

ですが、ここで多くの発注者さんはうろたえます。
「発注者からカネを取るだけじゃなく、その上発注者側の時間まで取るのか？」
「発注者が業務のイロハを教えないといけないのか？」
というわけです。

これについては、ある程度はYesと言わざるを得ません。
同じような業務でも組織によって少しずつ異なります。
その違う部分をキチンとシステムに反映しないと使えない業務システムが出来あがってしまいます。
そんなことにならないようにするには、必ず発注者側の協力が必要になります。

この点は開発会社側により大きな責任があります。
だから現行業務について開発会社は根掘り葉掘り細かいことまで確認するのです。

もちろん、発注者側からも情報提供を積極的に行っていただける方がシステムの完成度、ひいては発注者側の満足度は間違いなく上がります。

もうひとつ、発注側の責務として、開発会社のスキルを見抜く力が要ります。
これがないと、実力のない会社に実力以上のシステム開発を求めることとなります。

さて、ここで今回のトラブル事例を振り返ってみますと、発注側が開発会社の実力を見誤っていたであろうことがわかります。

開発会社の技量を全く把握できておらず、トラブルで何が起きているのかもわかってなかったのでしょう。
だから、トラブル解消に10日間もかかるのです。

発注側がこんな状態では、開発会社になめられても仕方ありません。
だって、何が起きていて、何をすれば収束するのかサッパリわからないのですから。
「早く直してくれ」と言ったって「それはGmail側の問題ですから」と返されればそれまでです。

これでは全く「管理監督」できているとは言えません。

管理監督できている状態であれば、こんな場合も発注側が事象を正確に理解し、開発会社に足りないスキルを見抜き、対処に必要な人を引っ張ってくることができます。

そうであれば、3日もあればトラブルは収束していたように思います。

何も発注者である神奈川県の教育局がそういったスキルを持つ人を雇用しろというのではありません。システム開発の要所要所でそういったアドバイザを雇い入れ、神奈川県の立場で発言してもらえば良いだけです。

これは県側だけでなく、実は対処方法がわからずに困っている開発会社にも福音だったはずです。

記者会見での不誠実さ

このトラブルについては、1月19日に記者会見が行われ、修正が完了した旨の報告が行われました。
それ自体はめでたい話なのですが、どうにもスッキリしないのがその原因説明のところです。

記事には次の記載があります。
　県教委は会見で、「（3学期が始まった）9日にGメールを利用した登録が集中したため、Gメール側で（利用に）制限がかかった」と述べた。
　（出典：毎日新聞 https://mainichi.jp/articles/20240119/k00/00m/040/321000c ）

上述の通り主要因は県側のシステムにあるとしか思えないにも関わらず、この表現ではまるでGmail側の課題であり、県側は迷惑を受けたと言っているようにしか読めません。

これについて、県側が開発会社にいいように操られているように見えます。
あくまで公開情報と筆者の想像ベースによる判断ですが、筆者はこの開発会社には全く好感が持てません。

まとめ

Gmailの迷惑メール対策で実際にトラブルになった事例が出てきました。

このトラブルはGmail側の問題というより出願システム側の問題で、システムの設定をしくじったことで出願システムの利用者に迷惑を与えた結果となりました。

今回の件では、いくつかの教訓を感じました。

１）同様システムの納入実績だけでの判断は危険

今回の開発会社選定では同様のシステム納入実績があることが前提となっていたそうです。それでも、今回のようなトラブルが発生しています。
「今まで成功してきたからといって今回も成功するとは限らない」パターンとでも名付けましょうか。
今回ハマったのはドメイン認証という新し目の技術要件を開発会社が習得できていなかったためではないかと思われます。
世の中は常に進歩していますので、開発会社といえど研鑽を怠ってはならないことを示しています。
逆に言えば、世の新しいことに積極的に取り組まない会社に未来はないということですね。

２）発注者の責務

上でも書きましたが、発注者の責務として、開発会社を管理監督できる能力が必要です。
そのためには、技術に明るく、その内容を発注者側に易しく説明できるアドバイザが必要です。
発注者自身がその能力不足を感じるのであれば、そういった人材をプロジェクトに入ってもらえる体制作りやそのための予算確保に取り組む必要があります。

３）インターネットの威力

今回のメルマガを書くにあたり、たくさんの方のX（旧Twitter）での発言を参考にさせていただきました。これだけの知を短時間で結集できるのはインターネットというネットワーク技術のなせるわざです。
筆者も今まで知らなかったサービスを知ることができました。
インターネットの威力を改めて感じました。

さて、上記を踏まえますと、今回の件は、第三者による事故報告書を作成すべき事案ではないかと思います。

今回の件は半田病院のランサムウェア被害（2022年）が復旧に2ヶ月以上かかったことに比べればずっと軽微です。

ご参考：
　2022年11月配信
　No283 医療機関のランサムウェア被害は避けられたのか？
　https://note.com/egao_it/n/n0ebd497cb311

ですが、他の自治体でも同様の事故は容易に発生します。

同様の事故を避け、知見を共有するためにも、事故の詳細を公表いただくことを強く望みます。

今回は、Gmailの迷惑メール強化対策にからめて、神奈川県の出願システムのトラブルのお話をしました。
次回もお楽しみに。

（本稿は 2024年1月に作成しました）

このNoteは筆者が主宰するメルマガ「がんばりすぎないセキュリティ」からの転載です。
誰もが気になるセキュリティに関連するトピックを毎週月曜日の早朝に配信しています。
無料ですので、是非ご登録ください。
h行ttps://www.mag2.com/m/0001678731.html
また、公式サイトでも最新版を公開していますので、そちらもどうぞ。

https://www.egao-it.com/