orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

プライバシーマークは、パスワード保管時の暗号化を義務づける認証ではない件について

f:id:orangeitems:20190129205854j:plain

 

平文でパスワードを保管することとプライバシーマークの関係

宅ファイル便の個人情報漏洩事件が業界では大騒ぎとなっているのですが、1つ話題にしておかなければならないことがあります。運営会社はプライバシーマークを取得しているという事実です。しかし、パスワードが平文で保管されていたという状況についてギャップを感じる方も多いのではないでしょうか。

プライバシーマークは、個人情報を暗号化し保管することを義務化する規格ではないことを、共有しておきたいと思います。

 

プライバシーマークの大まかな成り立ち

概要

プライバシーマークの概要は以下の通りです。

 

privacymark.jp

プライバシーマーク制度は、日本工業規格「JIS Q 15001個人情報保護マネジメントシステム-要求事項」に適合して、個人情報について適切な保護措置を講ずる体制を整備している事業者等を評価して、その旨を示すプライバシーマークを付与し、事業活動に関してプライバシーマークの使用を認める制度です。

 

つまり、JIS Q 15001の中身に沿って運営している組織であることを認める規格です。従ってJIS Q 15001自体を知る必要があります。この中に、「個人情報は暗号化して保管すること」と書かれているかどうかがポイントとなります。

 

JIS Q 15001が読めるサイト

直リンクはありません。以下の方法でアクセスしてください。

 

1) JISのサイトを開く

日本工業標準調査会:データベース検索-JIS検索

 

2) 検索窓に、Q15001と入れる

f:id:orangeitems:20190129190903j:plain

3) 検索結果が出るので、「JISQ15001」のリンクを押す。

f:id:orangeitems:20190129191001j:plain

すると、全文を読むことができます。PDFならいいのになーと思いつつ。

 

JIS Q 15001の概要

なかなか本文を全部読み切るのは時間がかかります。内容はこんな構成になっています。※ワークトラストさんの図がすごくわかりやすいので引用しました。

 

f:id:orangeitems:20190129191605j:plain

引用:JISQ15001:2017とは|プライバシーマーク(Pマーク)の取得更新ならワークストラスト

 

この通り、本文があり、附属書A/B/C/Dが付いているという構成になっています。

 

JISQ15001における個人情報の技術的保管方法に関する文脈

結論から言います。

 

・本文「6.1.3 個人情報リスク管理」に、附属書Aに書かれている管理策を満たすことを義務化しています。

・附属書A「A.3.4.3.2」に以下の記載があります。

f:id:orangeitems:20190129192627p:plain

つまり、安全に管理しなさいと言っています。パスワードの保管にも関係していそうですね。内容については附属書Cを見なさいと言っています。

・附属書C「C.10 暗号」、これが唯一、個人情報保護時の暗号に対する記載となります。

f:id:orangeitems:20190129192838j:plain

 

つまり、方針を立てて実施することが望ましいとまでしか記載がなく、義務ではありません。個人情報のリスク管理方法として安全管理措置を行わなければならず、そのための方法としては暗号を用いることが望ましい。ここまでなのです。

 

ちなみに、具体的にはどのように管理策を立てればいいの?というガイドブック的なものの最新は下記の本で、有料です。

 

JIS Q 15001:2017対応 個人情報保護マネジメントシステム導入・実践ガイドブック 単行本(ソフトカバー)

 

この本、そうとう売れてるんだろうなと思います。以前の規格であるJISQ 15001:2006については、PDFでガイドブックが出ています。

 

JIS Q 15001:2006をベースにした個人情報保護マネジメントシステム実施のためのガイドライン 第2版(2018年4月10日掲載:1.5MB)

 

この中の「Ⅱ技術的安全管理措置として講じなければいけない事項と望ましい方法の例示」には、平文の記載もあるんですね。

f:id:orangeitems:20190129203243j:plain

やはり「望ましい方法」に対する記載なので、努力義務となっています。

極論を言えば、組織が望ましいと思わなければ必須ではありません。

 

プライバシーマークの現実

プライバシーマークは、個人情報の取り扱いに対する運用方法・体制を細かく見るのが主眼で、その技術的手法については管理の中で自主的に組織が決定するものとなっています。ワークフローの中でリスクに基づいて企業が自身で考え行動し改善できるようになっているかを測るものです。

JIS15001は望ましい対応について整理してはいますが、それを技術的に採用するかは組織の判断につきます。本文に「パスワードに準ずるものは平文で電子的に保管してはならない」、という記載があれば審査員もエビデンスを要求するのでしょうが、附属書における推奨項目にしかすぎないので見解を聞いてアドバイスをするぐらいまでしかできないのが現実かと思います。

プライバシーマークには「個人情報管理台帳」の運用が義務付けられていて、そこにもし、「電磁的保管」をしている場合に平文か暗号化かの区別の記載を義務付ければ少しは状況も変わってくるのになと思います。

f:id:orangeitems:20190129204651j:plain

この台帳のフォーマットも自由なので、プライバシーマークはどこまで行ってもパスワードの暗号化保管を強制しない、のですね。

 

まとめ

ということで、いくら認証された体制を保持しても、最後はリスクマネジメントを行う組織の力量に依存してしまうことが明らかだと思います。

リスク管理表を作るとき、リスクアセスメントを行う担当者がその対応や評価を誤ると、思ってもないリスクが降りかかってしまうという現実です。例えば、暗号化されていると思って評価表には暗号化している、と書いてあるのに、実は平文だとか。また、退会者情報は削除されているはずだ、と思ったら削除されていないとか。

リスク評価は体制が保証してくれるものではなく、最終的には現場の人々のスキルと取り組みに対する真剣さ、その活動を積極的に評価するマネジメント層と言ったところが大事だと思います。

セキュリティーに対する工数は、ビジネス上の経費となってしまうので、何もないと予算を減らされたり活動を評価されない傾向にあります。結果的に体制や認証は形骸化し、意味のないものになりがちです。

認証自体は社会にとって不可欠なのですが、それを取れば安心というのはファンタジーです。個々の組織でリスクを顕在化させないように活動していきましょう。

 

Peing脆弱性案件に見る初動のまずさ

f:id:orangeitems:20190129010731j:plain

https://peing.net/

 

質問箱Peingに脆弱性が発見されメンテナンス中に

現在、下記ツイートに関連して、質問箱Peingのサービスがメンテナンス中となっています。

 

 

上記の通り、少なくともPeingを連携していたツイッターアカウントに対して、第三者が勝手にツイートできてしまう仕様だったことは間違いないようです。また、だからといってログインできたり、ツイッター連携している他のサービスにログインできたり、ということはない、と否定しています。

しかし、いつからそうなっていたのかはわかりませんし、脆弱性がどんなメカニズムで発生していたのか。また、被害として具体的に何が挙げられるのかを記載していません。

 

初動がまずい(と思う)

ここからは私個人の意見です。

脆弱性が発見されてその後サービスを閉じたのは正しいと思います。

しかし、そこからどんな脆弱性なのかを明確にしていないので、ツイッター上では様々な憶測が飛び交っています。

不安が広がり、とりあえずはPeingのツイッター連携解除しないと、今すぐ危険という噂が広がり、たくさんの人々が解除に動いています。

 

togetter.com

 

できれば、公式自ら情報提供するべきかと思います。

また、被害状況や対策が確定するまでは、利用開始にするべきではないと思います。このままだと1/29 8:00にはメンテナンスが終了してしまいます。まずは、今回の事象・原因・経緯を明らかにした後、安全宣言をしてから正常サービスに戻すべきかと思います。

運営会社のホームページにも、何も情報が記載されておらず、危機管理として初動がまずい、と思います。

 

どうすべきか

私の考える初動対応です。

(1)サービス停止
まずはサービスをすぐ停止する。サービス開始時間はこの時点では未定とする。

(2)第一報
SNS等で、脆弱性が発見されたためサービスを停止したことを知らせる。ただしこの時点では影響が明確ではないため、まずは事実だけの第一報とする。

(3)中間報告
以降、定期的に第二報、第三報等を作成し、わかったことを随時まとめる。特に影響範囲の確定が先。いつからそうだったのか、またどんな情報資産が漏えいした可能性があるか、その件数について確定し、報告する。また、ユーザー側で実施すべき項目がある場合も含めて逐次更新する。

(4)安全宣言
影響範囲が確定し、対策(暫定もしくは恒久)が決定した時点で、安全宣言を出し、サービスの開始を未来にスケジュールして報告する。影響が深刻である場合はサービスを長期中止にし、既存ユーザーについての対応を表明する。

今回は、(1)→(2)まで進んだものの、それ以降の更新(3)がなく、かつ(4)がないまま1/29 8:00にサービス開始すると宣言してしまっているので、初動がまずいと思っています。

ぜひ、上記のセオリーにのっとって、今わかっていることを逐次公開して頂きたいとおもいます。また、サービス再開時刻については、安全宣言を出すまでは未定とすべきかと思います。

去年の段階で100万人ユーザーいるということですので・・影響は小さくありません。

www.itmedia.co.jp

軌道修正を行い、早期にユーザーの不安を解いて頂きたいと思います。

 

追記(2019/1/29 9:45)

ホームページをのぞいてみましたが8:00になってもメンテナンスが明けていませんね。収拾がつくまで一度クローズした方がいいと思うのですが。

 

追記(2019/1/29 12:45)

追加のコメントが出ました。

 

ネットメディアも食いついてきた模様・・。

nlab.itmedia.co.jp

同社は29日に詳細を報告する予定としています。編集部が詳細を問い合わせたところ、公式Twitterに出ていることが全てとの回答でした。

 

これ以上何も公開しないということは、憶測を打ち消すつもりもないということなのでしょうか。

経緯を見守ります。

 

追記(2019/1/29 17:45)

中間報告的な情報がツイッターに更新されました。

 

 

 

 

 

 

 

 冒頭でも書きましたが、サービスを止めた後は、リカバリーより先に影響範囲を確認し速やかに報告したほうが後々楽になります。今回、憶測が乱れ飛んだために結局のところTwitterの連携解除が大変なスピードで進んでいるのではないかと想像します。

また、今回事象が特定されておりますが、ハッシュ化されたパスワードが表示されていたというのが気になるところです。TwitterはBcryptという方式を使ってハッシュ化しています。この仕組みについては、下記文書が詳しいです。

BCrypt(Blowfish暗号)について調べたので文書化してみました - Kamiya::Memo

Blowfish暗号についてざっと書かせていただきましたが、これらはあくまでもパスワードが流出した後に役立つものです。パスワードが漏れないことが一番ではあるのですが、二重三重に保険をかけると言った意味で保存するパスワードが暗号化するのが今は常識になってますね。

ただ、レインボーテーブルには強いBlowfish暗号も、辞書攻撃、ブルートフォースアタックに弱いです。結局パスワードそのものが当たってしまえばソルトもコストもほとんど意味を為さないんですよね…

 パスワードそのものにすぐに復号するのは無理だけれども、パスワードそのものが簡単だった場合には、ハッシュ値の中に書いてあるソルトを使って普通にbcryptでエンコードすると割り出されてしまうと理解しています。

 

※「・ハッシュ化されたパスワード」については、本当は漏えいしていないのではないか、トークンと間違えているのでは?という指摘もあるようで、推移を見守りたいと思います。運営のツイッターに書かれている以上、真偽が不明です。

 

追記(2019/1/29 21:30)

一度サービスインしたものの、再度問題が発見され、再度メンテナンス突入。

 

 

 

最早、公開脆弱性検査のようになってきました。

また、運営企業よりリリースも出ているのですが、

jiraffe.co.jp

 

私の感覚としては、第三者機関によるセキュリティに関する調査が完了するまで、サービスを再開してはいけないと思います。

 

追記(2019/1/30 9:45)

結局、収まるところに収まってきたという印象です。

 

 

 

ちなみに、ハッシュしたパスワードが漏れた件については、Twitterアカウントのパスワードではなく、Peingで独自に設定するパスワードのハッシュだそうです。

 

www.itmedia.co.jp

 このパスワードはPeing特有に設定するものであり、Twitterアカウントのパスワードとは異なる。ソルトはパスワードをハッシュ化する際にパスワードに付加する文字列で、ハッシュ値から元の文字列を推測しづらくするために利用するものだ。

 

今後はサービス開始を急がず、たんたんと調査が進められた後に開始されるでしょう。インシデント発生時の事例として学ぶべき内容の多いシナリオだったと思います。

 

追記(2019/1/31)

サービス再開したとのこと。

 

www.itmedia.co.jp

 

私の感覚よりすごく早い再開なのですが、この判断が正しいのかどうかは、ここから何も見つからないかどうかにかかっていると思います。

 

偽装請負よ、滅びよ。本当に滅びよ。

f:id:orangeitems:20190128104835j:plain

 

外国人技能実習生に対する偽装請負

なかなか偽装請負の問題が無くなりませんね。IT業界の話ではありませんが取り上げておきます。

 

mainichi.jp

愛知県の青果卸会社と関連会社の農業生産法人に雇用され、北海道の農家などで農作業に従事しているベトナム人技能実習生21人が解雇を通知された問題で、全員が25日付で解雇された。青果卸会社の担当役員は取材に「そもそも農作業ができる社員はいなかった」と明かし、事実上、派遣先農家に実習を丸投げしていたと証言。識者は、職業安定法違反(偽装請負)に当たる疑いがあると指摘している。

 

偽装請負の何が悪いのか

労働者と、労働者に指示をする人の間に何の契約関係もない状態が諸悪の根源です。

今回の場合、外国人は農家から直接指示を受けています。教育も受けています。外国人は直接の上司が農家になると思いますよね。しかし農家は外国人と何の契約もありません。農家は外国人の健康状態や労働条件に気を遣う必要もありません。使用者責任がないわけですから。365日働かせても知ったことではありません。

一方で、本来の使用者責任は卸会社にあるのですが、目の前にいません。農家でどんな労働をしているか全くわかりません。そもそもどんな仕事をしているかもわかりません。もし問題があれば農家からクレームが上がってくるので、その人を引っぺがして交代人員を入れるだけの仕事です。教育もしてませんしだいたい仕事内容もわかりません。外国人は勤務時間を形式的に報告しているかもしれませんが、それだって正しいかどうかは怪しいものです。現場監督をしているわけではありませんので。

ということで、本来、農家に労働者を預けるのでしたら、きちんと派遣契約を結んで使用者責任を農家に担ってもらう必要があります。法的にもそうなのですが同義的にも全くおかしいです。

さて、この偽装請負の問題ですが、卸会社のメリットは何でしょうか。それは教育も労働管理もせず、派遣先に人を投げ込むだけでマージンを取ることができるということです。人集めに特化できれば数を裁くだけで売り上げをどんどん拡大できます。もし、派遣先にミスマッチだった場合は、別の派遣先に廻せばいいだけです。今回の農家もそうですがIT業界の場合も忙しいときと暇なときがありますから、自由に人を出し入れできて使用者責任を負わない農家もメリットがあり、教育や労働管理を省略できる卸会社にもメリットがあるのです。卸会社はそもそもスキルがなくてもよいので参入障壁も低いですし、仕事をまわしているうちに労働者がスキルを身に着けてくれるので、しめしめと言ったところです。

この偽装請負のロンダリングに参加する労働者は、派遣先を「ガチャ」と呼んでいて、幸運にもホワイト企業だったり高スキルの部門だったりすると思ってもみないスキルが身に付いたり、経験がつめたりします。一方で、無責任な派遣先だと、労働法上等なぐらいな奴隷労働をさせられたりします。少しのメリットと、無制限なデメリットがあり、過去の経験者として、偽装請負は無くなるべきだと信じています。派遣は派遣だし、請負は請負であるべきだと思います。責任は明確でないといけない。

2000年を過ぎたあたりからIT業界で横行したのですが、数年して取り締まりが厳しくなり大企業では対策が進んだと記憶しています。が、まだ法の目を潜り抜けるようなやり方が残っていると思います。

 

偽装請負よ、滅びよ。本当に滅びよ。

一番の問題は偽装請負が実現することで生まれる「益」によって、正しく運用する企業が経済競争に不当に負けることです。いわゆる不当競争により不当な勝ち組企業が生まれ、労働者がそこに巻き込まれてしまうことです。

ルールの運用が間違っていると結果も間違います。ルールをいかに審判に見えないように破るかで勝ち負けが決まってしまうスポーツは、結果として素晴らしい結果を生みません。素晴らしい選手、チームが称賛されず、誤った称賛を産むことになります。

どの業界でも、企業全体が正しい方向に進むように、当局には偽装請負について厳しく厳しく取り締まってもらいたいと切に願います。

 

偽装請負―格差社会の労働現場 (朝日新書 43)

宅ふぁいる便、480万件情報流出についてまとめる

f:id:orangeitems:20190126020333j:plain

 

問題の概要

宅ふぁいる便の情報流出がニュースになっています。

 

www.nikkei.com

大阪ガス子会社のオージス総研(大阪市)は25日、大容量ファイル転送サービス「宅ふぁいる便」で一部サーバーが不正アクセスを受け、全登録ユーザー数に相当する480万件の顧客情報が流出したと発表した。ログインに必要な利用者のメールアドレスやパスワード、生年月日などの情報が漏洩した。

 

今わかっている情報をまとめます。

 

問題の概要については以下の通り、公式ホームページに記載されています。

「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について(お詫びとお願い)

 2019年1月25日

「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について(お詫びとお願い)

 ファイル転送サービス「宅ふぁいる便」におきまして、一部サーバーに対する不正アクセスにより、約480万件のお客さま情報のデータが外部に漏洩したことを確認いたしました。

 ご利用の皆さまに多大なるご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。

 なお、現時点で具体的な被害は確認されておりませんが、引き続き第三者を含めた調査を行っており、詳細が判明次第、改めてお知らせいたします。

 

1.漏洩したお客さま情報
(1)内容
・「宅ふぁいる便」のお客さま情報
・メールアドレス、ログインパスワード、生年月日、氏名、性別、業種・職種、居住地(都道府県のみ) ※アンダーラインは漏洩が確定した情報

(2)件数
 約480万件

 

2.経緯、原因
・1月22日11時、当社が認識していないファイルが「宅ふぁいる便」サーバー内に作成されていることを確認し、システムを管理している社員およびパートナー企業に確認。
・1月22日13時、社員およびパートナー企業から作成していないとの報告を受け、第三者機関を含めて、原因の究明、被害状況などの調査を開始。
・1月22日19時、「宅ふぁいる便」サーバー内に不審なアクセスログを確認。
・1月23日10時50分、情報漏洩などの被害防止のため「宅ふぁいる便」のサービスを停止。
・1月24日20時、当社ウェブサイトにて「『宅ふぁいる便』サービスの一時停止に関するお知らせとお詫び(第一報)」を掲載。
・1月25日15時30分、お客さま情報の漏洩を確認。

 

3.お客さまへのお願い

・「宅ふぁいる便」と同一のユーザーID(メールアドレス)、ログインパスワードを用いて他のウェブサービスをご利用されているお客さまにおかれましては、誠にご面倒ではございますが、ログインパスワードを変更いただきますようお願いいたします。

・1月13日から1月23日まで、「宅ふぁいる便」のサービスをご利用いただいたお客さまにおかれましては、送信されたファイルをお届けできていない可能性がありますので、ご確認をお願いいたします。

 お客さまの大切な情報が漏洩する事態となり、大変なご迷惑、ご心配をおかけすることになりましたことを重ねてお詫び申し上げます。

 

4.宅ふぁいる便のサービス再開について
 現時点で、サービス再開の目途は立っておりません。

以上

 

<本件に関するお問い合わせ先>
株式会社オージス総研 専用受付 06-6584-0097
(土日祝含む 9:00~17:45)
お問い合わせメールアドレス :bs_inquiry_takufile@ogis-ri.co.jp

 

今回の問題範囲について

上記報告では不明な部分を追記します。

宅ファイル便ですが、有料の法人用と個人用があります。

 

f:id:orangeitems:20190126014337j:plain

https://www.ogis-ri.co.jp/pickup/takufile/

 

このうち、個人向けの2つのサービス「宅ファイル便ビジネスプラス」「宅ファイル便」が影響を受けていると思われます。上記の”詳しく見る"というリンクの先は、現在報告書へのリンクとなっています。

有料のビジネスプラスには当然、メールアドレスやパスワードを使って会員登録が必要ですのでこれが流出したと思われます。

また、無料の宅ふぁいる便については2通りあります。プレミアム会員と言って会員登録をする方法が1つ。もう一つは会員登録なしで利用する方法です。方法は下記が詳しく掲載されています。

www.icatch-inc.jp

このように、プレミアム会員ではなく、会員登録なしで利用されていた方にとっては何の影響もないと思われます。

つまり、

・「宅ファイル便ビジネスプラス」会員
・「宅ふぁいる便」のプレミアム会員

これらの、メールアドレス、ログインパスワード、生年月日が、退会された方を含めて流出したと考えられます。

データそのものの流出は今のところ検出されておらず、調査が続いているとのことです。ただ、ファイルのダウンロード方法については、認証無しのURLからのダウンロードです。ということはWEBサーバーのアクセスログがあればダウンロードURLがわかってしまうことになると思います。ファイルは3日で消えるようですが。このあたりの詳しい情報についてはいずれ調査結果が出てくるものと思います。

 

宅ファイル便の歴史

歴史を掲載しておきます。

これまでの歩み | 連載企画

1999年06月
「宅ふぁいる便」誕生!

2000年頃
専用宅ふぁいる便(終了済)

2003年頃
クール宅ふぁいる便(終了済)

2005年04月
「宅ふぁいる便」事業化

2005年05月
メルマガ発行開始

2006年03月
会員数30万人突破!

2006年07月
オフィス宅ふぁいる便

2006年頃
宅ふぁいる便リサーチ

2007年06月
宅ふぁいる便プレミアム

2007年12月
会員数100万人突破!

2008年01月
宅ふぁいる便ポイント

2008年08月
「ソニンの明日に生きる言葉」書籍化

2009年12月
ファイル再送信、削除機能

2009年12月
「ギャザ朗」開始(終了済)

2009年12月
「にんげんラブラブ交叉点」書籍化

2011年03月
有料版「ビジネスプラス」

2011年04月
会員数200万人突破!

2011年11月
メルマガ&WEB連載「座布団エレジー」書籍化

2012年06月
送信容量300MBに拡大!

2012年06月
有料版の送信容量2GBに拡大

2012年06月
デスクトッププラス

2012年10月
ドラッグ&ドロップ対応

2012年11月
宅ふぁいる便 for iPhone

2013年01月
宅ふぁいる便 for iPad

2013年02月
会員数250万人突破!

2013年02月
WEB連載「ことわざ野球大喜利」書籍化

2013年03月
ウィルスチェック機能

2013年03月
簡易アップロード

2014年03月
ファイル圧縮機能

2014年08月
ダウンロード回数を無制限化

2014年08月
Androidでの送受信に対応

2015年02月
MacOS版「デスクトッププラス」

2015年02月
有料版の送信容量が5GBに

2015年03月
メルマガ&WEB連載「大人のお悩み教室」書籍化

2015年03月
iPhoneアプリ「圧縮おたの助」

2015年07月
一括ダウンロード機能

2015年07月
会員数300万人突破!

かなり古参のサービスですね。

 

追記(2019/1/28)

報告書が随時更新されています。

www.itmedia.co.jp

 

追記(2019/1/29 9:48)

本件、パスワードを暗号化せずに保管していたことが話題となっています。

 

f:id:orangeitems:20190129094911p:plain

https://www.filesend.to/faq.html

 

パスワードの暗号化はセキュアプログラミングの観点において常識となっています。

www.jpcert.or.jp

機密情報を格納する必要がある場合は、まず暗号化する。

 

追記(2019/1/29 21:00)

プライバシーマークについて気になったので調べておきました。

www.orangeitems.com

 

 

補足

新しい情報がありましたら追記、修正いたします。

 

ソースネクスト・ポケトークW、総務省適合要請の件まとめ

f:id:orangeitems:20190125221028j:plain

https://pocketalk.jp

 

ポケトークWについて

ソースネクストが販売するポケトークWという商品があります。

 

pocketalk.jp

翻訳機を超えた、夢のAI通訳機
POCKETALK®(ポケトーク)は、互いに相手の言葉を話せなくても、
まるで通訳がいるように対話できる音声翻訳機です。
対話のために設計された専用機ならではの、使いやすさが特長です。

 

明石家さんまさんがCMしているのでご存知の人は多いのではないでしょうか。

 


さんま、六か国語で“出っ歯”いじりされる 『POCKETALK(ポケトーク) W』新CM「服屋編」&メイキング

 

この商品ですが、実際の翻訳をやっているのはこの機械ではなくて、クラウド上のサーバーです。WifiもしくはSIMカードによるモバイル通信にて、翻訳結果を取得します。またこのポケトークWシリーズは、すでにグローバルSIMカード(2年契約)がついているので何か設定などをする必要なく、世界で使えるとのことです。契約が切れたら5,000円でまた2年延長できるとか。

 

アマゾンでも売ってましたが、30,088円と結構な値段。通信費がかかるので当然か。

 【公式】POCKETALK_W (ポケトーク) 翻訳機 +端末保証(3年) ホワイト

 

総務省に怒られる

こちらのポケトークWですが、総務省から今日(2019/1/25)怒られてしまいました。

 

www.soumu.go.jp

ソースネクスト株式会社に対する技術基準への適合要請

 総務省は、本日、電波法の規定に基づく認証取扱業者であるソースネクスト株式会社(代表取締役社長 松田 憲幸)が販売している無線設備(ポケトークW)について、技術基準への適合について必要な措置を講ずるよう要請しました。

 

事案の概要及び要請の内容

 ソースネクスト株式会社が電波法(昭和25年法律第131号)の規定に基づく認証取扱業者として販売している特定無線設備(ポケトークW)について、電波法に規定される技術基準に適合していない事実が判明しました。具体的には、Wi-Fi用の周波数として国内での利用が認められていない周波数帯の電波が発射されているとともに、技術基準の適合証明を受けていない周波数帯の電波を利用している状況でした。

 このような無線設備は、他の無線局に混信その他の妨害を与えるおそれがあり、また、利用者が当該特定無線設備を適正に利用することが困難な状態を生じさせることとなります。

 このため、総務省は、本日、同社に対して、厳重に注意するとともに、早急に技術基準に適合するよう必要な措置を講じ、その措置内容について報告するとともに、今後の再発防止策について速やかに提出するよう要請しました。

 総務省としては、今後も良好な電波利用環境を維持するため、引き続き、必要な対応に努めてまいります。

 

何が原因か

 この、「Wi-Fi用の周波数として国内での利用が認められていない周波数帯の電波が発射されているとともに、技術基準の適合証明を受けていない周波数帯の電波を利用している状況」というのは具体的に何を示すのでしょうか。

 

日本語のマニュアル(PDF)がこちらにあります。

この中に、Wifiの仕様が書いてありますが、「802.11a/b/n/g 2.4GHz/5GHz帯」としか書いておらずこれだけではわかりません。

 

さて、同じような問題が去年あったのを思い出しました。

 

www.orangeitems.com

無線LANには2.4GHzと、5GHzの2種類の周波数帯があるのはご存知かと思います。2.4GHzは屋外で使うのは全く問題ないのですが、5GHzについては何種類か規格がありほとんどは屋外仕様が禁じられています。ファームウェアアップデートにより、屋外不可の電波が飛ぶようになってしまったのではないかと推察します。

 

上記の記事に詳しく書いてありますが、5GHzのWifiにはいくつか規格があって、日本では屋外で飛ばしてはいけない電波があるのです。こちらに引っ掛かっているものと思います。

 

なお、技適は下記に、受けたという記載がありますが。

pc.watch.impress.co.jp

なお、「ポケトークW」については、技術基準への適合性を満たし、認定を取得しているとする。

 

おそらく、申請していない電波のことを指して「技術基準の適合証明を受けていない周波数帯の電波を利用している」と表現されたのではないかと推測します。

 

ソースネクスト社の対応

ソースネクスト社から報告書が出ていました。

2 . 本件に対する当社の対応
本日付で、本件技術基準に適合させるためのアップデータ配信を開始いたしました。
アップデート方法はこちらからご確認ください。

 

ファームウェアのアップデートで対応するとのことです。強制アップデートとかできるのかな・・?(多分無理じゃないかと)。

アップデートしないポケトークWは違法電波を垂れ流すことになるので、本当にこの対応だけで終結するのかはよくわからないのでニュース等を注視しておきます。

5GHz帯には要注意ですね。

 

2020年春期から基本情報処理試験の出題が見直し。プログラミング能力・理数能力等を重視され、Pythonが追加になりCOBOLが無くなる。

f:id:orangeitems:20190124140345j:plain

 

基本情報処理試験を受験予定の方は注意(2020年春期~)

経産省の基本情報処理試験出題内容が、2020年春期より見直しになると、本日(2019/1/24)IPAが発表しました。

 

www.ipa.go.jp

IPA(独立行政法人情報処理推進機構、理事長:富田 達夫)国家資格・試験部は、国家試験である「基本情報技術者試験」について、AI人材育成のニーズ等を踏まえ、出題の見直しを実施しました。具体的には、プログラム言語の見直し(COBOLの廃止、Pythonの追加)、プログラミング能力、理数能力等に関する出題の強化です。これらの詳細をIPAのウェブサイトで公開しました。

 

COBOLが消える

特に、COBOLが無くなったのが驚きです。

このプログラミング言語の問題ですが、以下の変遷をたどっています。

・昭和45年(1960年)から「第二種情報処理技術者試験」として実施。平成13年(2001年)より「基本情報処理技術者試験」となる。

 

・昭和45年(1960年)から昭和51年(1976年)までは、FORTRAN、ALGOL、COBOL、PL/I、アセンブラ言語のうちから一言語を選択

 

・昭和52年(1977年)からは、FORTRAN、COBOL、PL/I、アセンブラ言語のうちから一言語を選択

 

・平成4年度(1992年)秋期からC言語を追加

 

・平成13年度(2001年)秋期からは、FORTRANとPL/Iが削除され、Javaが追加となった。

 

参考:

https://www.jitec.ipa.go.jp/1_11seido/s44_h6har/old_k2_1.html

 

したがって、COBOLは試験の発足当初から生き残っていた言語であり、60年の時を経て削除されてしまうことになったわけです・・。

COBOLが厚生労働省の勤労統計問題の原因にされた記事が話題になった翌日に、IPAがすごいタイミングで削除してきたと思うのですがいかがでしょうか。

 

www.orangeitems.com

 

変更内容詳細

見直しの内容です。

(1)午後試験で出題するプログラム言語の見直し

「COBOL」について、教育機関等における指導言語としての利用の減少、本試験における受験者の選択率の極端な低下により、2019年の秋期試験をもって出題を廃止
「Python」について、適用範囲の拡大と利用の増加、機械学習やディープラーニングに関わる主要なOSSでの採用の広がり等により、2020年の春期試験から出題に追加

 

(2)午後試験の出題数、解答数、配点等の見直し(適用時期:2020年の春期試験から)

選択問題を構成する分野の統合を実施し、出題数及び解答数を、現行の13問出題7問解答から、11問出題5問解答に変更

プログラミング能力等を重視し、配点を変更

詳細は次の表のとおりです。

見直し後:

f:id:orangeitems:20190124135601p:plain

見直し前: 

f:id:orangeitems:20190124135625p:plain

 

(3)午前試験での数学に関する出題比率の見直し(適用時期:2019年の秋期試験から)

理数能力を重視し、線形代数、確率・統計等、数学に関する出題比率を向上

 

ということで、丸暗記より、理数能力が問われるようになること。またPythonが登場しデータサイエンスに準じた学習が反映されるようになったといったところでしょうか。

なお、開始時期は2020年春期からですのでお間違いなく。

 

Emergency Directive 19-01「DNSインフラストラクチャ改ざんの軽減」

f:id:orangeitems:20190124120323j:plain

 

DNSの改ざんが多発しているとのこと

アメリカ政府も閉鎖が長期化する中でよくやっているなと思いますが、米国土安全保障省のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)が緊急指令を各省庁に出したそうです。

 

www.itmedia.co.jp

米連邦政府機関でWebサイトのドメインのDNSインフラが改ざんされる被害が多発しているとして、米国土安全保障省のサイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は1月22日、全省庁に緊急対策を指示した。

 

記事内には緊急対策命令のリンクがないので調べるとともに、内容を調査しました。

 

 緊急指令

下記が、実際に公開されている指令です。

 

cyber.dhs.gov

 

具体的な攻撃手法

どんな攻撃手法なのかなあと思ったところ、以下の記載がありました。

次の手法を使用して、攻撃者はWebおよびメールのトラフィックをリダイレクトして傍受し、他のネットワークサービスに対しても同様のことを実行できます。

1. 攻撃者はまず、DNSレコードを変更する可能性のあるアカウントのユーザー資格情報を危険にさらすか、別の方法でそれらを取得します。

2. 次に、攻撃者はAddress(A)、Mail Exchanger(MX)、またはName Server(NS)レコードなどのDNSレコードを変更して、サービスの正当なアドレスを攻撃者が制御するアドレスに置き換えます。これにより、ユーザートラフィックを合法的なサービスに渡す前に、ユーザートラフィックを操作または検査のために独自のインフラストラクチャに振り向けることができます。これは、トラフィックのリダイレクト期間を超えて持続するリスクを生み出します。

3. 攻撃者はDNSレコード値を設定できるため、組織のドメイン名に対して有効な暗号化証明書を入手することもできます。これにより、リダイレクトされたトラフィックを復号化して、ユーザーが送信したデータを公開することができます。証明書はドメインに対して有効であるため、エンドユーザーはエラー警告を受け取りません。

この活動によってもたらされる政府機関の情報および情報システムに対する重大かつ差し迫ったリスクに対処するために、この緊急指令は、未知の改ざんによるリスクを軽減し、各機関に対する不正なDNS活動を防止し、無許可の証明書を検出できます。

 単純な話で、DNSサーバーの管理権限を奪われたらのっとられますよ、ということです。

・Aレコードを書き換えて、フィッシングサイトを構築されたり別のサイトを表示したりできる
・NSレコードを書き換えて、悪意のある別のDNSサーバーに振り向けられ、名前解決を自由にコントロールされてしまう。
・MXレコードを書き換えて、メールを全部取られる
・名前解決できればドメイン認証で正当なサーバー証明書が取得できてしまう

まあ当たり前の話ですね。当たり前なのに指令が下りるということは、乗っ取りが成功する事例が発生しDNSサーバーの管理品質が低いことが明らかになったためだと思います。

 

必要なアクション

指令の中にある必要なアクションが興味深かったので触れておきます。

対応1:DNSレコードの監査

10営業日以内に、すべての.govまたはその他の代理店管理ドメインについて、すべての権限のあるDNSサーバーとセカンダリDNSサーバーのパブリックDNSレコードを監査し、目的の場所に解決されることを確認します。そうでない場合は、CISAに報告してください。

CISAは、NSレコード、および組織のユーザーおよび一般に提供される主要なエージェンシーサービスに関連するもの(たとえば、エージェンシーの任務の中心となるWebサイト、MXレコード、またはその他の利用率の高いサービス)を優先することを推奨します。

対応2:DNSアカウントのパスワードを変更する

10営業日以内に、代理店のDNSレコードを変更する可能性があるシステム上のすべてのアカウントのパスワードを更新します。

CISAは、複雑で一意のパスワードを容易にするためにパスワードマネージャを使用することを推奨しています。

対応3:DNSアカウントに多要素認証を追加する

10営業日以内に、代理店のDNSレコードを変更する可能性があるシステム上のすべてのアカウントに対して多要素認証(MFA)を実装します。

MFAを有効にできない場合は、CISAにシステムの名前、必要なスケジュール内に有効にできない理由、および有効にできるタイミングを指定します。

CISAは、フィッシングに対して回復力のある追加の要素を使用することをお勧めします。NIST SP 800-63bに準拠して、ショートメッセージサービス(SMS)ベースのMFAはお勧めできません。

対応4:証明書の透明性ログの監視

10営業日以内に、CISAは、Cyber​​ Hygieneサービスを介して、新たに追加された証明書を代理店ドメインのCertificate Transparency(CT)ログに定期的に配信します。

受領時に、機関は直ちに彼らが要求しなかったと発行された証明書のためにCTログデータを監視し始めなければならない。機関が証明書が無許可であることを確認した場合、その証明書を発行元認証局およびCISAに報告する必要があります。

 ということで、

1)DNSレコードをもう一度確認しなさい
2)DNSサーバーを管理するIDのパスワードを変更しなさい
3)DNSレコードを扱うシステムについて、多要素認証を導入しなさい
4)証明書が正しいか確認しなさい

といった結構普通のことが書かれていますが、面白い内容も含まれています。

まず、パスワードマネージャーを使うことを推奨している点です。パスワードをおぼえることはもう非現実的で、おぼえる運用にするとabc123みたいなリスト攻撃に脆弱な文字列になってしまう件の反省ですね。

また、SMS(ショートメッセージ)で多要素認証を行うのはもはや非推奨というのも興味深いです。

あと、CTログへの定期配信というのもあまり聞きなれませんね。

 

とりあえず、DNSサーバーへの攻撃が流行していることは頭に入れておくべきで、JPCERTやIPAもおそらく周知して来るのではないかなあと思います。

 

「COBOLプログラムのバグ」に見る内製化の限界

 

f:id:orangeitems:20190123173949j:plain

COBOLのバグ・・?

厚生労働省の統計誤りについて、COBOLプログラムのバグが原因という記事が話題になっていますので取り上げておきます。

 

agora-web.jp

情報システムを役所の技官が、COBOLのレガシーシステムで構築するのも間違いのもとだ。歴代の厚労相を国会に証人喚問するなどというスタンドプレーより、まず厚労省のコンピュータをオープンシステムに更新し、事務処理を透明化して、第三者がチェックしやすい体制にすべきだ。

 

ツイッターのトレンドにCOBOLが入ってくるぐらいに盛り上がっていて、

・COBOLを悪者にするな
・COBOLを読める=高齢者はおかしい
・体制の問題であってシステム更新しても同じ

というような意見で溢れかえっております。

 

報告書の記載

厚生労働省の報告書にも、きちんとCOBOLプログラムのバグについて記載されています。

一方、職員・元職員のヒアリング調査によれば、企画担当係とシステム担当係との間の作業発注及び作業のフォローアップの仕組みやシステム改修の進め方については、以下のような供述が見られる。

・抽出替え等によりシステム改修の必要性が生じた場合には、企画担当係とシステム担当係が打ち合わせをしながら、必要な作業を進めていくが、その際にはすべての仕様をペーパーで依頼する訳ではなく、口頭ベースで依頼することもあった。なお、毎月勤労統計調査については、具体的なシステム改修関係の業務処理は係長以下で行われ、一般的には課長や課長補佐が関与しない。

・システム改修の依頼を受けたシステム担当係は外部業者等に委託することなく自前でシステム改修を行うことになるが、毎月勤労統計調査に係るシステムのプログラム言語はCOBOLであり、一般的にシステム担当係でCOBOLを扱える者は1人又は2人に過ぎなかった。このため、一般的にシステム改修を行う場合はダブルチェックを行うが、ダブルチェックができない場合も多かった(平成15(2003)年当時はCOBOLを扱える者は2人いたが、それぞれが別の仕事を分担して処理していたため、当該者同士でダブルチェックをするようなことはなかった。)。

・一度改修されたシステムのプログラムの該当部分は、それに関連するシステム改修がなされない限り、当該部分が適切にプログラミングされているか検証されることはなく、長期にわたりシステムの改修漏れ等が発見されないことがあり得る。

 

これって内製化リスクの顕在化ですよね

以前の下記エントリーで記載しました。

 

www.orangeitems.com

ですから、デジタルトランスフォーメーションを進めようとする企業は、知っておくべきです。おそらく今の情シスの人間だけでは人数が足りません。その倍は少なくとも必要です。稼働が無くてもです。そして教育を常に実施しなければいけません。社内に業務が無ければ外の企業の仕事も請け負ってでも経験しないと人が育ちません。大企業がそれでもデジタルトランスフォーメーションにトライするのは、人材がいるからなのです。中小企業が流行に乗って飛び乗ると、人材が流出した後システムだけが残り、しかも基幹業務にまで入り込んでしまい、内製化した運用保守業務が万が一おろそかになったときに会社の基幹業務ごと深刻な影響を受けることにつながりかねません。

 

別にCOBOL言語じゃなくて、GoでもPythonでもRでも起こりますよね、今回の件。ベンダーにアウトソースすることが悪で、内製化こそ善だと信じている人も結構多いと思います。しかし、下手に非IT業種にて内製化した場合には運用スキルのある人材が不足しているため、ベンダーでは当たり前にやっているようなリスクヘッジが全くできないケースが生まれることを知る必要があります。

内製化がうまくいくのは、運用スキルのあるマネージャーが在籍しているときに限ります。マネジメントがなくなった瞬間に運用マニュアルはどんどん陳腐化していき、だんだん属人的な「現場のやり方」まで落とし込まれていき、結果的に大事故につながります。内製化するならするで、それに相応する体制と人材が不可欠です。さらにこれが保たれているかを第三者的にチェックする機構が必要です。ベンダーがISO9001を取得して品質管理認証を受けている理由がここにあります。

情報処理をナメてはいけません。システムにやらせるのであればきちんとシステムを扱えるベンダーに委託するべきです。人材不足の内製化は、医療に対しての民間療法に似たものがあります。起こるべくして起こった事故です。ベンダーはだてに専門家ではないのです。

 

ブレインテックが導くフィクションの世界

f:id:orangeitems:20190123153402j:plain

 

ブレインテックを知ってしまう

今日、初めてブレインテックなる言葉に触れて気分が悪くなってしまった。

 

www.itmedia.co.jp

「ブレインテック」という言葉を聞いたことがあるだろうか? Brain(脳)とTechnology(技術)合わせた造語で、直訳すると「脳技術」となる。脳がどのような活動をしているかを見える化し、そこに働きかけるテクノロジーという意味で、イスラエルで生まれた言葉だ。米国などでは同じ意味でニューロテクノロジーと呼ばれることも多い。

 

現状、研究の初期段階でありまだ商品化する状況ではないのだが、今後この研究が進むとめまいのするような状況が起こるのではないかといういろいろな想像に見舞われてしまった。ブレインテック自体の定義や現状は上記記事に譲るとして、この技術が発展したあとに起こりそうなフィクションをまとめておきたい。

 

議論の整理

脳の情報をデジタルにアウトプットできるという仮説を前提として、Facebookは文字入力の際キーボードやフリック入力を使わないで、脳から直接サービスに入力する仕組みを考えているという。現在のところ何らかのデバイスに筋肉運動にて物理エネルギーをインプットするか、音声をデバイスに聞き取らせ文字に変換することで、文字入力は達成できている。これを、脳の信号だけで完結させようとする試みだ。これを実現するのは脳に埋め込んだチップであると記事は説明していた。とすると、脳の信号をチップが読み取り読み取ったものをWifiなど何らかの形で外部にアウトプットしそれをデバイスが受信するということになる。

逆に、外部からの情報を脳にインプットする仕組みも実現するという。もちろんそれを融通するのもチップだ。チップが外部情報を脳に対して信号を送ることにより実現するという。

このように、脳からみてアウトプットする領域と、インプットされる領域があり、これを融通するのはチップだという。この場合、技術的にはアウトプットする方が簡単でインプットするほうが難しそうだ。脳の現象をチップが読み取るときはチップに対するプログラミングであるのに対し、チップが脳に働きかけるときはこれはデジタルでは理屈がつかないので高度にならざるを得ない。そうすると、Facebookがやっているようにまずは脳から直接アウトプットできることの方が優先されるべきだろうし、実際突破口はそこなのだろう。

まずは、アウトプットが先に実現すること。また脳にチップを埋め込むことも実現することを前提にフィクションを考えてみたい。

 

フィクション1

人々はまず、キーボードやマウスの代わりとして脳を活用しだすだろうが、明らかにもっと違う使い方ができる。埋め込むチップは別にセンサーだけの機能に絞る意味がない。CPU+MEMORY+ストレージを小型化したコンピュータをすでにチップ化できる。昨年IBMが発表した超小型コンピュータはもうすでに砂粒だ。

jp.techcrunch.com

チップ自体がOSでありアプリケーションを内蔵でき、ストレージとしての機能があるのであれば、脳の情報を溜めこむことができる。人間が考えた情報をわざわざクラウドなどのサーバー上に取り込む必要は全くない。脳の中のチップに保管しておき、その内容をスマートフォンなどのデバイスで自由に読み取ることができる。

もちろん、まずはテキスト情報のみが保管されるのだが、技術が進めば視覚情報や聴覚情報、さらには触感や味覚、感情までがデータ化される。脳の情報をデジタル化するための処理はあくまでもチップにて完結し、これを読み取ることは初めのうちはデジタルデバイスでの処理になるだろう。

そうすると、人間自身があたかもスマートフォンのように振る舞える。カメラは目についているのでパノラマ写真や動画撮影も自由自在だ。人間の目は大変高性能なので、暗くなっても鮮明に確認できる。また、もともと3Dに対応しており奥行きを再現することもできる。録音機能も優秀で、サラウンド対応となる。

チップにアプリケーションを入れれば、インターネット上のメディア、例えばSNSにチップ上の情報を投稿できるようになる。こうなると、もはや自分自身がスマートフォンになった感覚に囚われるだろう。

ここまでがフェーズ1となる。

 

フィクション2

さらに。脳に対してチップからインプットするのが難しいとは書いたが、実は別の分野の応用が可能だ。VRである。脳のチップの情報をもとにVRデバイスが動くようになればかなり精密に脳をだますことができる。現在の最新のVRは瞳の動きを見て人間がどこを見ているかを判断し、そこに情報処理を集めて緻密な表現を行っている。

news.nicovideo.jp

VRデバイスがアクセスできるのはまだ瞳の動きが精いっぱいで、中身の人間の情報がブラックボックスなので苦労している。これを脳の情報がデジタル化されたチップと連動させると一気にVRデバイス側で何を見せるかの変数が多様化する。チップにVR用のアプリをインストールしておき、そのアプリと連動してVRデバイスが動くようにすれば、もはやあとはアイデアの問題だけになる。

視覚や聴覚だけではなく、感情や人間の知識レベルまで判断し、コンテンツをコントロールできたらどうだろう。VRの可能性はブレインテックと深く関係しているといっても間違いないと思う。

 

フィクション3

技術の可能性を語り始めると明るい未来しかなさそうだが、ブレインテックが現実化すると、社会はこれをどう向き合うのか。もはやスマートフォンのレベルではない。近代史の中でテレビが現れテレビっ子なる言葉で揶揄されたが我々の世代は乗り越えた。そのうちテレビゲームが現れ、今度はゲーム脳という言葉まで生まれた。これは今の20~30代くらいか。そしてスマートフォンが現れ、スマートフォン依存とかそれにひもづくSNS依存のような言葉が生まれ、そして簡単に個人の発信が炎上するような社会となり今まさに、社会問題化している。

そしてこのブレインテック。これまでの技術進化の比ではない。

学生の脳にチップが生みこまれていたら、暗記とは何かが根底から揺らぐ。そのうちチップの内容を脳にフィードバックする技術が生まれたら、もはや人間は単なるクライアントとなる。そこにネットワークが存在したら、試験中にWikipediaにアクセスしその内容を脳にフィードバックし書き写すのか。そもそも、脳からデジタルデバイスに直接書き込めるのに、紙に文字を書くことがどれだけまどろっこしいか。

また、脳のインプットだけチップのストレージに書き込むだけではなく外部デバイスからも書き込みできるのであれば、あらゆる知識が脳に入ることとなる。単に情報を溜めこむだけなら誰でもできるようになる。あとは情報処理の差とはなるが、それさえもチップ上のプログラムが代替してくれる。例えば時刻表のデータがあるとして、そのデータだけでは、東京駅から新宿駅へ今から移動していつ到着するかは調べないとわからない。しかし乗換案内アプリをチップに埋め込めれば、ストレージ内のデータを情報処理してくれる。もっと言えば、ネットワークがつながっているのであればチップを通じてインターネットに問い合わせし返った情報を脳が受け取ればいい。

また、VRの世界が、ブレインテックによって大きく進化してしまえば、「ソード・アート・オンライン」のように脳の世界だけで別世界に囚われてしまうことだって大いにありうる。脳を100%だませてしまえば、それは現実と同じ意味に変わる。

 

まとめ

以上、私の気持ち悪さが共有できただろうか。

ハイリターンである技術は、ハイリスクを伴う。

原子力しかりだ。

ただ、人間は未知に対して探求する本能をもち、そこに課題があれば解決してしまうまで歩みを止めないだろう。

できるだけ想像力を発揮して、未知のリスクに準備をしておくことは重要だろう。それはゲノム編集の議論と同義だと思う。

www.shinmai.co.jp

 

NTT DATA Innovation Conference 2019に行こうかと

f:id:orangeitems:20190122212641j:plain

 

NTTデータの一大イベント

人月商売だの、多重請負の温床だの、顧客の下請けだの、いつもどこかで批判の多いSIerですがよくよく見るときちんと戦略的に動いているということを実感できそうなイベント「NTT DATA Innovation Conference 2019」が、今週金曜日(2019/1/25)に溜池山王で開催されます。

NTTデータは日本におけるSIerの王様のような企業です。私自身は全くご縁もなかったのですが昨今のIT業界の在り方に興味を覚えるに従い、ではSIerはどう業界を捉えているか興味があり内容を調査してみました。

 

NTTデータのビジョン

午前に基調講演、午後に各セッションという、よくある構成です。

それぞれのセッションについて取りまとめる前に、NTTデータの考え方がまとまった絵がありましたので引用します。

 

f:id:orangeitems:20190122205716j:plain

 

お客様にとってのデジタル化

デジタルトラスフォーメーション(DX)を成し遂げるためには5つの分野が大切とおっしゃっています。

 

■ビジネスプロセスの変革
 デジタルを通じて、お客様の仕事のあり方自体を大きく変えていくこと。

■エコシステムの再構築
 デジタルを通じて、お客様のビジネスを支えるサプライヤー・協力会社・ユーザーなどの関係を再構築すること。

■新たな体験の創造
デジタルによってこれまでの製品やサービスを、エンドユーザーへ新たな体験として届けること。

■新しいサービスの創造
お客様がこれまで手掛けていなかった新しいサービスを、デジタルによって実現すること。

■新規ビジネスモデルの創出
お客様の既存のビジネスモデルとは全く異なるビジネスモデルを、デジタルによって実現すること。

 

デジタル化を実現する技術領域

DXを実現するために必要な技術手段として、6つの分野を提唱しています。

 

■Data & Inteligence(データと知性)
データ資産そのもの、これを利用したAIやデータサイエンスなどの領域。

■Inteligent Automation(知的な自動化)
単なる自動化ではなく、複雑な課題に対して自動的に解決していくプロセス。

■Customer Experience(顧客体験)
いわゆるCX。商品やサービスそのものではなくそれを手に取り消費する顧客側の立場に立って物事を考えていくこと。

■Internet of Things(モノとしてのインターネット)
IoT。有名すぎる概念。センサーをあらゆる物体に取り付けることにより、世界をより知ることができる。

■IT Optimization(ITの最適化)
旧来のIT資産を最新化(モダナイゼーション)することにより、保守性・柔軟性を高めより高い生産性を実現しようとすること。コンテナとかクラウドとか。

■Cybersecurity(サイバーセキュリティー)
デジタル化することにより、ビジネスプロセスによりデジタルが関与することになる。したがってデジタルプロセスに特化したセキュリティーの重要性がいよいよ高まることになる。

 

各セッションはカテゴライズされている

それぞれのセッションは、上記のカテゴリーのうち、どの内容にあてはまるのか明記されています。DXへのアプローチにはいろいろな組み合わせがありますから、数あるせしょんの中でよりイメージが合うものに参加すると良いと思います。

例えば、下記のように表記されています。

f:id:orangeitems:20190122211642j:plain

※「新しいサービスの創造 → Data & Inteligence」といった見方。

 

IT業界に属する人はぜひ参加をお勧めします

特に、営業部門の方であったり、お客様担当のエンジニアであったりする方は、このようなイベントにはぜひ参加したほうが良いと思います。もちろん、ただ参加しても得られるものが限られます。今回のこの6つのDXおよび5つの技術分野の絵はかなりよくできています。別にNTTデータに所属していなくてもどのSIerにいても有用なツールになります。他の企業はまた違った製品やサービスで、これらを実現しているに過ぎません。

この絵を頭に入れて、自社のサービスを整理したりプレゼン資料を作ったりすると、ぐっと説得力が増すと思います。かついろいろなセッションを聴くことで自身のプレゼンに活かすことができます。

他のSIerも同じようなイベントを開催していますので、ぜひ興味を持っていただければと思います。