カテゴリー: Noise

「なぜデジタル庁が国内ではなく米企業のシステムを導入するのか？」その答えはシンプルだ。既に国内ITベンダーは本格的なクラウドを運用できるだけの技術力を失っているからだ。

クラウドサービスの運用には高い技術力を要求される。10台の物理サーバーで構成されるシステムの複雑さを10とするなら、単純に考えても10台の物理サーバーで動作する10インスタンスの仮想サーバーの複雑さは100になる。物理層の上に、仮想化した物理層を動作させて、大規模なクラウドを運用しようとするなら、ハードウェアからOSやアプリケーションまで垂直統合したIT技術を求められる。これらを提供できるだけのIT技術を持つ企業は、日本国内には富士通とNECの二社程度しかみあたらない。そして富士通は既にクラウド事業から撤退を決め、NECはクラウド事業に参入すらしていない。

「さくらのクラウド」や「GMOクラウド」などクラウドを提供している事業者は何社か残っているが、それらは基本的な仮想サーバーを提供するに過ぎない。大手クラウドベンダーが200種にものぼるクラウドサービスを提供している事と比較してあまりにもつたない。そこには10年以上の技術差が存在している。

海外クラウドベンダーの力を借りなければ、最新のIT技術を活用する事すらままならないのが、デジタル敗戦国などと揶揄される国内IT産業の現実だ。

ちなみに「データが丸見え」というのは、あまりにもナンセンスな指摘だ。国威無い企業なら丸見えでも問題ないかといえば、そんな訳はない。またデータを見せないために求められるのは暗号技術と暗号鍵管理で、それらがしっかりしていれば「データが丸見え」などと言うことは起きない。

ただし有事に「システム障害を故意に起こされる」と言う可能性なら確かにある。これは別に何処の国のクラウドサービスを使おうが関係なく存在するリスクだ。これに対して米国政府の場合にはFedRAMP等の、民間向けクラウドサービスよりもさらに厳格なセキュリティ要件を満たす事を求めている。日本のガバメントクラウドのセキュリティ要件は知らないが、恐らくは同じレベルのものを要求するはずだ。そうしないと米国政府とシステムを接続出来ないからね。

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

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

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

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

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

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

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

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

「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社に…不具合の原因企業「分からない」

SMBCに続きNTTデータも被害を確認、広がるGitHub上のコード流出問題

とかくソースコードが流出したことが問題視されがちだが、本当に重要なのはソースコードが流出しても問題の無い運用体制・セキュリティ体制が取られている事にある。

大規模なソフトウェアの開発には数百人規模のエンジニアがかかわる事になる。その全員が悪意を持たず、過ちをおかすこと無く、善良かつ有能で忠誠心に溢れていることを期待するのは無理がある。如何に流出対策を厳重にしたところで、記憶までは消すことが出来ない。悪用する事が目的なら、故意に脆弱性を仕組んだり、あるいは脆弱性にかかわる部分だけを記憶できれば十分なのだから。

誤ってもインターネットの利用を制限しようなどとは考えないで欲しい。今の時代、全てのリファレンスマニュアルやバグ情報、あるいはサポートなど全てがインターネット経由なのだから。ましてgithubを制限しようものならオープンソースのコード利用が著しく困難になってしまいます。結果的に生産性が落ち、誰も得をしません。

デジタル教科書、紙と併用か・全教科か…文科省が５案提示

全児童にパソコンを行き渡らせる事が決定しているが、今更に教科書の電子化を議論しているらしい。電子教科書と紙の教科書を併用させるつもりでいるようだ。結論を言おう。パソコンを持たせるなら、教科書を電子化する以外に選択肢など存在しない。

数年前から登校する児童の荷物の多さが国政の場でも問題視されている（国も動き出した「重すぎるランドセル問題」）。時には体重の50%を超え、中には健康被害を受けている児童までいるというのだから、何故ここまで放置してしまったのか憤りさえ覚える。

健康被害を受けずに習慣的に運ぶことの出来る荷物の量として体重の20%程度が限度と言われている。仮に体重の20%としたときに、小学校低学年女子だと4Kg強程度が限界となる。

・ランドセル 1200g
・水筒（1リットル） 1200g
・パソコン（含むACアダプタ） 1200g
・筆箱 200g
・鉛筆（5本） 25g
・ノート（5冊）750g
これだけでも合計4575g。あっという間に重量オーバーである。

教科書の重量は1冊200～300g。結構重たい。パソコンを持たせたら、教科書を持たせる余裕など、そもそも残らないのだ。

たった1日の利用で750万円をGoogleから請求された企業

上記リンク先の企業は750万円の請求を受けたようだが、私自身も似た良いな経験はある。個人的に勉強がてらMicrosoftのAzule MLで遊んでいた。無料枠でリミットがかかるつもりで居たが、突き抜けて十数万円の請求金額が表示されていたのだ。あわててMicrosoftのサポート窓口に連絡して、請求を取り下げていただき事なきを得た。

IaaSやPaaSの使い方を試しながら学習する上で、この手のリスクは常に発生し、避けようがない。実験的に動かす場合にも、本番環境と同様に従量課金で料金が発生する。最初から完璧に習熟していて、絶対に間違えない人など居ない。いくら気をつけていたところで、見落としや設定ミスによる重課金が発生するリスクは常にあるのだ。

うっかり数百万円溶かしても「あほぅ」の一言で済ませてくれる組織でもない限り、実のところエンジニアは業務でPaaSを安心して使えない。「この機能を使えばこんなことが出来るはず・・・」と知識で知っていても、ミスを許容してくれる組織でない限り怖くて新しいことにチャレンジ出来なくなる。

クラウドへの移行を考えている・・あるいは既に実施している企業の役員の方には、この事を知っていて欲しいのだ。

ちなみに、色々と検索した限りでは、速やかに連絡すれば請求を取り下げてくれる事が少なくないようである。