教育情報セキュリティポリシーに関するガイドライン22

皆さんこんにちは。

令和4年3月、教育情報セキュリティポリシーに関するガイドラインが一部改訂されました。

平成29年10月18日 策定後、何度か改訂を繰り返しているガイドラインです。HBI通信でもたびたび取り上げてきましたが、今回は最新版をご一緒に読んでいくことにしましょう。

参考資料については、繰り返し申し上げますが、あくまで「一例」です。ご自分の自治体に合ったものにするために、よく理解をして、具体的に落とし込めるくらいご確認いただければと思います。難しい言葉が頻繁に出てきますが、ご一緒にゆっくり読んでいくことで、教育情報セキュリティポリシーを、少しずつ身近なものにしていってもらえればと思います。よろしくお願いいたします。

参考資料　1.6.3. システム開発、導入、保守等

ガイドラインでまず心配しているのは「プログラム上の欠陥（バグ）によるシステム障害等により業務に重大な支障が生じるおそれ」です。もちろんそれは十分に予想し、対応すべきものですね。バグは必ず発生しますが、それを取り除いてリリースするためには、究極的には十分な時間と予算が必要だ、ということになります。

ガイドラインでは、調達から検証段階まで、何を確認していくと良いのかという提案がなされています。

予算も期限もありますから、無尽蔵にお金と時間を使っていい、ということにはなりません。限られた条件の中で、使いやすく、そしてセキュリティ的に安全なシステムを作っていくためには、事前のしっかりとしたイメージの共有や、その分野のシステム開発の経験者がいることを要件にする等、調達前の準備段階が非常に重要です。（以前に「統合型校務支援システム導入のための手引き」を読んだ時に詳しくご説明しています）

ただこのガイドラインでは調達後からの以下の段階での提案が書かれています。

• 情報システムの調達
• 情報システムの開発
• 情報システムの導入
• システム開発・保守に関連する資料等の整備・保管
• 情報システムにおける入出力データの正確性の確保
• 情報システムの変更管理
• 開発・保守用のソフトウェアの更新等
• システム更新又は統合時の検証等

私は運用の現場に長くおりましたので、その観点から行くと、行政職の皆様に一番ご注意いただきたいのは４と６になります。

４のシステム開発や、保守に関連する資料は、どういう場合にどのような開発が行われたかの経緯や、仕様の確認、要件定義が変更したことなどがわかるように残しておくのは重要です。

また、６の変更管理は、「いつまではどの機能がどうだったが、いつからはこうだ」ということが分かっている必要があります。ない機能を「前は使えたのに」とずっと探したり、「不便だな」と思いながら改善された機能に気づかず使ったりするのはとても残念なことですね。

また、８の検証時には、行政職の皆様はもちろん、実際に使用する現場の先生やICT支援員らの確認もあると安心です。

忙しいのでどうしても業者に任せる部分が多くなる、というのは本当によく理解しているのですが、できるかぎり行政職の皆様には関われる部分は関わっていただきたいと思います。

来週は参考資料の続き、技術的セキュリティについて読んでいきます。