投稿者: knarita

茨城・つくば市、県立校でネット投票

高校の生徒会レベルで行うのは許容範囲だが、公共性の高い用途で使うのなら、十分な議論が必要だ。インターネットを使った選挙活動と、インターネットを使った投票の間には大きな谷があるのです。

紙による選挙では以下の様な事柄が守られています。
・匿名であること。誰が誰に投票したのか、誰にも分かりません。
・強要されないこと。選挙会場で衆人監視の元で投票するので、誰かに強要されることはありません。
・重複投票できないこと。選挙管理人監視の下で本人確認を行い、既に投票を行ったか管理しているため、重複投票は困難です。
・検証可能なこと。後日に再集計するなど、選挙結果を検証可能です。

実はインターネット投票では「匿名であること。」と「検証可能なこと。」を両立することが極めて困難なのです。また「強要されないこと。」を保証する事も難しくなります。ここがインターネット投票を行っている国家が少ない所以です。

一人の方が複数回投票したりといった事を防いだり、あるいは漏洩したユーザーアカウントを使った成り済ましを防ぐには、誰が、何時、何処から、誰に投票したかといった情報を記録せざる得ません。厳重に管理するにせよ、暗号化するにせよ、システムを管理する立場にある人には、誰が誰に投票したか分かってしまいますし、第三者に情報漏洩するリスクもあります。誰に投票しかという記録を残さず、集計結果だけを記録すれば匿名性を保持できます。ですが、その場合には後から検証する事も出来ませんし、何者かが選挙結果を改竄したばあいに検証できなくなります。

例えば電子政府で有名なエストニアではブロックチェーンを活用したインターネット投票システムを運用しています。投票内容を何度でも変更可能で、仮に強要されたとしても、後日に変更可能とすることで強要できないことを担保しているわけです。そして後日に変更可能と言うことは、投票内容は個人に紐付けられており、誰が誰に都票したかも記録されている事になります。

「インターネット投票にする」と言うことは、いままでは匿名投票だったものを、記名投票に変更するという事になります。ここは十分な議論と、周知が必要なところです。

私的にはインターネットを活用した選挙活動と一緒に、インターネットを活用した投票も早く実現して欲しいところですけどね。

「COBOL」プログラムが古くなっても動き続ける“切実な理由”

理由と断りつつ、理由に一切触れていない辺りが、多分一番切実な理由なのだ。

COBOL言語で開発されたシステムの特徴を上げてみましょう。

・データに関する設計思想の違い
COBOLシステムと現行の一般的なデータベースとでは大きく設計思想が異なる。OBOLのデータベースは転記を繰り返しながら必要なデータを作成する。対して現行のシステムではデータ正規化を行い重複するデータを排除して管理しやすいようにする。

・可用性や信頼性に関する設計思想の違い
当時のコンピューターシステムはハードウェアで可用性と信頼性を高めるように設計されている。現行のシステムの多くはハードウェアは不定期に故障する事を前提にソフトウェアにて可用性や信頼性を高めるように設計されている。

・言語習熟の困難さ
COBOLの言語仕様自体はシンプルです。ですが実際のプログラムは各ベンダーが提供するミドルウェア上に構築されています。ミドルウェア部分は各ベンダーに依存しているため、これに習熟するためには実機での学習が必要です。ですが新たに実機を入手する事は困難です。そのためにCOBOLに習熟したエンジニアを新たに採用するのは難しくなります。

それらの理由により、COBOLで作成されたシステムを別の言語に移行しようとすると、人員が不足している状態で、現行システムを調査して仕様を調べ、全てを再設計する事を余儀なくされる事にります。リスクが大きくなりすぎて、業務上許容出来るリスクの上限を超えてしまうため、移行出来なくなるわけです。

かといって、このまま何もしなければハードウェアの老朽化によりシステムが停止するリスクが上がり続けます。許容出来るリスクにおさめるために、どんなに高価でもハードウェアを更新して、延命をはかるしかありません。

本来ならシステム移行に伴うリスクが許容出来なくなるほど大きくなる前に移行を進めるべきでした。高価な専用ハードウェアの更新や、COBOL資産を残したままのシステム移行によって延命してる話しが増えていますが、それでもリスクは少しづつ増大しているはずです。何処かでリスクを精算する事は考え続けなくてはなりません。

マクロやRPAなどを使って業務を自動化して何十時間も節約しているのに給与は…みたいな話しを時折見かけるので、何故給与が増えないのか考察したいと思う。

マクロやRPAなどの活用による業務の効率化は二つの段階に分けられる。

・1stステージ
マクロやRPAを利用した自動化により、事務作業にかかる時間が削減されている状況。この段階は従業員個人の能力により業務時間の削減がなされている。作業負担の軽減により同僚からは感謝されたりはする。だがこの段階では会社の利益には繋がっていない。

・2ndステージ
自動化により削減された時間をより付加価値の高い業務に割り当てたり、あるいは余剰人員を人手の足りない部署に異動したり、従業員の解雇を行っている状態。

マクロやRPAの開発と維持には費用が発生している。作業時間の短縮により不要になった労働力を異動あるいは解雇するなり、短縮された時間を用いてより付加価値の高い作業を行うので無ければ、会社としては開発と維持にかかる費用分を損した状態になってしまう。

「マクロを勉強して自動化しました」という話しをしているとき、殆どの場合は1stステージの状態にあり、まだ会社に利益を生み出せていない。故に給与が増えることを望むなら、1stステージ→2ndステージへの移行が重要になるのだが、ここが難しい。

余剰人員異動や解雇には人事権が必要になるし、より付加価値の高い業務を生み出せる人材は自動化人材よりも貴重だ。2ndステージの実現には管理職の協力が必要不可欠になる。管理職者に1stステージで自動化の恩恵を見せて、2ndステージに移るための協力を得なければならない。

…が、そこで自動化を進められる素養を持つ上司なら、従業員に言われるまでもなくIT化を進めているはずだよね…的な達観があったり無かったり。

と言う訳でマクロを使えたり、RPAを使いこなせたからと行って突然に給与が増えることは無い。でも使える手札が増えれば、選択肢も増えるわけで、今後にチャンスをものに出来る可能性が増えるわけで、無駄では無い。

Andoroid版 COCOAの修正版リリースや、AWSの障害により気象庁のWEBが停止したニュースを受けて、政府のIT関係の調達について再び議論が起こっている。

COCOAではリリース以降、管理責任が曖昧のまま致命的な不具合が指摘されていたにもかかわらず数ヶ月にわたって放置されていた事が問題となった。他にもiOS版で接触履歴が初期化されるなど致命的な不具合が残っている。

AWS等のクラウドを使うのは、良い試みだと思う。ただし、実態として何処のクラウドサービスでも数年に毎に大規模な障害が起こっている。細かな障害に至っては日常茶飯事に発生する。クラウドだから可用性（信頼性）が高まるという訳ではない。したがってライフラインに直結するようなサービスをクラウドの載せるなら、一部のデータセンターが停止しうることを前提に冗長化しておくのが当然で、それを怠っていたのなら重大な問題だろう。

そもそも民生用のAWSで動かしていたのも如何なものか。例えば米国政府もAWSを積極的に利用している。AWS GovCloudとして提供されているそれは、FedRAMP等の米国政府の要求するセキュリティ要件を満たす。Amazonは従業員のバックグランドチェックを行い、米国市民以外が運用に関わらない体制を取り、民生用とは切り離された独立したデータセンターで運用されている。日本政府もAWSのクラウドを導入する事が決まっているが、はたして何処まで要件を纏めているのだろう？

結局の所はcocoaの不具合と同じ問題に行き着くのかもしれない。厚労省に限らず、発注元である政府に、情報システムの開発・運用要件を纏めてる能力が無くなっている事の証左に見える。

新たに組織されようとしているデジタル庁には大きく期待しているのだが、結局の所、以下のような問題の本質に行き着くのではないかと思う。

• 現在の賃金・雇用体制では専門家を雇用するにも十分な賃金や地位を出せない。
• 政府内において専門家を育成する事も出来ていない。

18日に河野太郎規制改革相が公務員の残業代を全額支給すると共に、労働実態を把握するように指示をしている。この事が公務員の人事制度改革に繋がることを期待してやまない。

IT media:AWS障害、5時間でほぼ復旧　気象庁Webサイトなどに影響
CNET Japan:通知の不具合を解消、1日1回程度アプリ再起動を推奨–接触確認アプリ「COCOA」修正版
東京新聞:COCOA開発受注企業が事業費94％を3社に再委託、さらに2社に…不具合の原因企業「分からない」