2017年1月31日火曜日

「AirPodsを探す」機能が『iOS 10.3 Beta』に追加された! | AppBank – iPhone, スマホのたのしみを見つけよう

「AirPodsを探す」機能が『iOS 10.3 Beta』に追加された! | AppBank – iPhone, スマホのたのしみを見つけよう:

 色々言われているAppleのAirPods。この山ちゃんウェブログでも、この完全無線のイヤホンは無くしそうだと書いたことがありますが、そういう意見が多かったのか「AirPodsを探す」という機能がiOSで提供されそうだという話題が上がっています。AirPodsはBluetoothによる完全ワイヤレスのイヤホンで、iPhone7からイヤホンジャックが取り払われてしまい、Appleは音楽は無線で聴くよう方向付けようとしているようです(もちろん変換アダプタを使うこともできるようですが)。

 確かにコードがないのでコードが洋服やカバンなどに引っかかることがなく、耳から外れることもほとんどないようなのです。自分も通勤時はSOL REPUBLICというメーカーのスポーツタイプのイヤホンをしています。このイヤホンは左右のイヤホンが完全独立したタイプではなく、間をコードが繋いでいるのでワイヤレスの手軽さと落としづらさを両立している気がします。完全独立と違ういい点は、例えばコンビニで支払いをしようとか人に話しかけられた時に一時的にイヤホンを外して、ぶらっと首にかけておけるのです。完全独立タイプの場合、外したイヤホンの行き先がないので、ポケットに入れるとか手に持つことになってかえってスマートでない気がしているのです。

 自分が使っているイヤホンの話はさておき、そうやって外した時にポロっとどこかへ転がってしまった場合、AirPodsは結構な値段がしますので必死に電車の床や駅のホームを這いずり回ることになりそうでした。しかし今回リリースされるという「AirPodsを探す」という機能で、落としてしまったAirPodsを探すのもスマートにやろうというわけかも知れません。(個人的には、やはりインパクトはあるものの、完全独立である必然性はない気がするのですが) 

 もともとある「iPhoneを探す」に新機能として追加されるそうで、iCloudにサインインしているiOS端末とBluetooth接続したAirPodsの現在地情報が、画面の地図とAirPodsから発する音で確認できるのとか。AirPodsはBluetoothしか通信機能がありませんので、必然的にBluetoothの電波が届く10〜100m以内くらいにだけが探せる範囲ということになります。AirPodsはケースから出すと自動的に電源が入って以降はケースに戻さないと充電されませんので、充電が残っている時間内でなければなりません。つまり「あれ、そういえばAirPodsをどこかに忘れてきてしまったな」という場合を想定しているのではなく、耳からポロッと落ちてしまったとかちょっと外してポケットに入れたつもりがどこかにいってしまったというケースに限られそうです。もちろんそれでも十分で、これまでAirPodsは失くしてしまいそうだからなあと二の足を踏んでいた方は、そろそろ買い時かも知れませんね。

にほんブログ村 ITニュース

2017年1月30日月曜日

誰の命を救うべきか...自動運転車が抱える「トロッコ問題」MITがウェブ上でアンケート開始|ギズモード・ジャパン

誰の命を救うべきか...自動運転車が抱える「トロッコ問題」MITがウェブ上でアンケート開始|ギズモード・ジャパン:

 この山ちゃんウェブログは、人工知能(AI)に関する話題をいくつもしてきました。今回は、AIの中でも最近盛んな自動運転について、「トロッコ問題」というジレンマを考えて見たいと思います。人間が運転するのとコンピュータが運転する自動運転で、どちらの方が事故が減るのでしょうか。これは間違いなくAIによる運転だと言われています。しかし、残念ながらAIの自動運転をもってしても避けられない事故というのは存在し、交通事故を0にするには至らないと考えられています。そんな時、コンピューターが下すべき倫理的な判断はどちらなのかという問題です。

 さて、トロッコ問題というジレンマは次のような問題です。線路を走っていたトロッコが制御不能に陥りました。このままでは前方で作業中の5人は猛スピードのトロッコに轢き殺されてしまいます。しかし、あなたの前には線路の分岐器があります。あなたがトロッコの進路を変更すれば5人は助かりますが、切替え先の別路線でも1人が作業しているので、5人が助かってもその1人はトロッコに轢かれてしまいます。さて、あなたはトロッコを別路線に引き込むべきでしょうか? 

 つまりトロッコ問題は、単純に「5人を助ける為に他の1人を殺してもよいか」という問題提起です。功利主義にもとづくのであれば、人間5人の命の方が1人の命の5倍の重みがあるので1人を犠牲にして5人を助けるべきです。しかし一方で義務論に従うなら、誰かの命を別の目的のために奪って良いはずはなく、何もするべきではないという結論になります。

 トロッコ問題に似たトピックに「カルネアデスの板」という問題があります。それはこんな問題で、日本でも「緊急避難」の例としてよく話されます。船が難破し、乗組員は全員海に投げ出されてしまいました。1人が命からがらに板切れにすがりつきましたが、そこへもう1人同じ板につかまろうとする者が現れます。しかし、最初に板につかまっていた者は、2人がつかまれば板そのものが沈んでしまうと考え、後から来た者を突き飛ばして水死させてしまいます。

 2つの話題は厳密には異なる倫理的判断の場面ですが、共通しているのは「命の重さ」に比較論が成り立つのかということです。1人の命と5人の命では、5人の命の方が重いのでしょうか。自分の命と他人の命では、自分の命の方が重いのでしょうか。カルネアデスの板の方を先に考えると、これは自分と他人の命の重さ比較ですが、その重さを測るのが自分である限りは必ず自分の命の方が重くなるように思います。しかし、後から板にたどり着いた者があなたの愛する恋人ならどうでしょうか、あなたの愛する子供だったとしても自分の命を守るために突き飛ばして水死させてしまうでしょうか。おそらく最初この問題を読んだだけでは、そんなの自分の命が大切に決まっていると感じたと思いますが、恋人や子供の命が自分の命よりも重いと考えた人もいるのではないでしょうか。トロッコ問題の場合も同じように、1人の命よりも5人の命の方が重いと考えてしまいがちですが、その1人があなたの愛する恋人や愛する子供だったら話は別かもしれません。もしくは、1人の友人と5人の見ず知らずの他人との比較だったらどうでしょうか。人間としてのエゴが出てしまって、自分に近しい人の命を救うという方向に走ってしまいませんか。

 トロッコ問題で実際に5,000人からアンケートを取ると、最初の経路を切替えて1人を殺すのは、89%の人が「やむを得ない」と答えているそうです。しかし、トロッコの進路を変更するという手段で1人を殺してしまうのをやむなしと答える人が大多数にも関わらず、「トロッコを止めるために大男を橋の上から突き落とす」という手段の場合は、結果的に1人の命を犠牲にして5人の命を救うのは同じなのに、90%が間違いであると答えたそうです。同じように、「5人を救うために健康な1人を死なせて臓器を与える」というのはどうでしょう。この場合の数字はないのですが、おそらく大多数の方が「それはやりすぎ」と思うのではないでしょうか。

 「正義」というのは極めてあやふや主観的なものなのです。生物学者マーク・ハウザー氏によれば、人の道徳的判断は理性と理論よりも、直観と感情の影響が大きく、次のような傾向があるのだそうです。
(1)行動の原理:自ら働きかけて生じた害は行動しなかったために発生した害より悪い
(2)意図の原理:意図してとった行動で害が生じた時は、意図せずとった行動で害が発生した時よりも悪い
(3)接触の原理:肉体的接触を伴って危害を与えるのは、接触なく危害を与えるより悪い
この中で(1)は、例えば「いじめ」問題があるでしょう。教育現場では、積極的にいじめに関わった生徒と傍観した生徒は同じ罪だと教えられているかもしれませんが、人間の感情としては直接いじめた方が悪いと考えます。(2)は、我々は計画的殺人を犯した犯人は、はずみで殺人を犯した犯人より重い刑罰を課せられるべきだと考えるでしょう。(3)は(1)と似ていますが、トロッコ問題は肉体的非接触なので1人を殺すことを厭わなかった人たちが、橋の上から突き落とすという接触を伴う行為の場合は非難しました。

 こう考えてくると、AIによる自動運転が今の進路のままなら5人が死ぬ、進路を変えると1人が死ぬという状況にぶち当たった場合、基本的に直観と感情で行動するのではないAIの場合、進路を変えるべきかどうかは極めて難しい問題となるわけです。果たして現在実用化されている自動運転は、この辺りはどうプログラムされているのか、興味が尽きないところです。

にほんブログ村 AI・人工知能

2017年1月28日土曜日

フィボナッチ数列を使うとマイルとキロメートルが簡単に換算できる | ライフハッカー[日本版]

フィボナッチ数列を使うとマイルとキロメートルが簡単に換算できる | ライフハッカー[日本版]:

 今回はEric Ravenscraft氏の記事(日本語訳:コニャック氏)にあった、「フィボナッチ数列」の豆知識を紹介したいと思います。数学の世界ではあまりにも有名なフィボナッチ数列ですが、皆さんはご存知ですか。

 フィボナッチ数列は、前の2つの整数を足したものが次の整数になっている数列で、
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, ...
というように永久に続く数列です。最初の方を見てみますと、0+1=1, 1+1=2, 1+2=3, 2+3=5というように2つの並んだ数を足して次の数が得られるという寸法です。フィボナッチ数列は面白い性質をたくさん持っていて、例えばフィボナッチ数列に出てくる整数を1辺に持つ正方形を並べると、下の絵のように綺麗に螺旋状に並びます。

 この螺旋は「対数螺旋(ベルヌーイ螺旋・等角螺旋)」と呼ばれ、自然界でもオームガイの螺旋(↓)や渦巻銀河M51などに現れています。他にも、花びらの数はフィボナッチ数であることが多かったり、植物の花や実に現れる螺旋の数もフィボナッチ数であることが多いと言われています。ハチやアリなどオスに父親がない家系を辿っていくとフィボナッチ数列が現れるなど、自然界にはフィボナッチ数列があふれています。

 自然界だけでなく人工物でも、バチカン美術館の二重螺旋構造(↓)もこの対数螺旋の形をしていて、とても美しいですね。形が美しいのはそれもそのはず、フィボナッチ数列の隣り合う整数の比が近づく形こそ「黄金比」と呼ばれる値「1.6180339887...」なのです。

 実は今回の元記事にある、マイルとキロメートルの比は約1.609と黄金比に近いので、例えば8マイルはおよそ13キロメートル、13マイルは21キロメートルというようにフィボナッチ数列における次の数字・前の数字を見ることでマイルからキロメートル・キロメートルからマイルに換算ができるのです。この話、去年ポケモンGoが流行した時にアメリカ人に教えてあげたかったですね。任天堂が日本の会社だからなのか、ポケモンGoで歩く距離はキロメートルで表示されるので、5kmとは一体何マイルのことなんだとGoogleで調べた人がすごく多かったそうでしたしね。

にほんブログ村 科学ブログ

「お金を出すならモノより思い出」の科学的根拠 | ライフハッカー[日本版]

「お金を出すならモノより思い出」の科学的根拠 | ライフハッカー[日本版]:

 今回は、Travis Bradberry氏の記事(日本語訳は堀込泰三氏)をもとに、お金の使い先に関して考えて見ましょう。自分もそうですが、働いても働いても日々の生活でいっぱいいっぱいという方も多いと思います。可処分所得が少ないなら、優先的に幸福度が上がることに消費したいものです。

 コーネル大学で心理学を専門とするThomas Gilovich教授によれば、20年にも及ぶ研究の結果言えるのは、「モノにお金を使うな」ということだそうです。確かに、私たちは生活のための「衣・食・住」を整えて自由になるお金ができた時に、その余裕で贅沢なモノを買ってしまいます。ちょっといい服・ちょっといい時計・ちょっといい車、...自由になるお金をたくさん持つ人はそういうところへ使い先を向けているようにも見えます。しかし、モノを買った当初は幸福を感じますが、その効果はすぐに薄れていってしまいます。

 モノから得られる幸福感の問題点は3つあります。1つ目は「慣れ」の問題です。例えば、新しい時計を買った時は嬉しくて何度も眺めてはうっとりするのですが、すぐにその時計が腕にある光景に慣れてしまい、また新しい時計が欲しくなってしまいます。次は「エスカレート」です。慣れてしまった左腕の時計に代わって新しい時計を買おうという時は、前のものより高いもの・魅力的なものを求めてしまいがちです。そして最後は「所有」というのは「比較」につながりがちということです。欲しくて欲しくてたまらなかった時計を手に入れて腕に付けても、友人がもっと魅力的な時計をしていたら、その喜びは半減してしまうでしょう。Gilovich教授によれば、これらは「所有のパラドックス」とでも呼ぶべきもので、モノを買ったときに得られる幸福感はずっと続くと思ってしまいがちですが、実際にはモノで得られる幸福感は手に入れた最初をピークにして以降は急速に減衰していくのです。

 一方で、Gilovich教授だけでなく多くの心理学の研究者が、「モノより体験のほうが長期的な幸福をもたらす」と主張しています。体験から得られる幸福は、モノから得られる幸福とは大きく違います。モノから得られる幸福にある「比較」というマイナスポイントが、体験においてはほとんどありません。夏休みに家族でキャンプをした体験は、友人の家族で海外旅行に行った経験と比べることは意味がありません。そして、モノから得られる幸福がどんどん減衰してしまうのに対して、体験から得られる幸福感は普段は意識の下にあるかもしれませんが「思い出」として何度も呼び覚まして噛みしめることができます。Gilovich教授の言葉を引用しますと「体験は、あなたの中で有形財よりも大きな部分を占めます。人は、モノを心から好きになることはできます。自分のアイデンティティと結びつけて考えることもできるでしょう。それでもなお、モノとあなた自身は離れたままです。しかし、体験は実際にあなたの一部になります。私たちは、自らの体験の蓄積でできているのです」。

 そういえば、最近の若者は「車はいらない。お酒も飲まない。モノもそれほど欲しくない」という消費離れの傾向があると聞きます。バブル期の若者にとっては「車・酒・海外旅行」というのは三種の神器で大量消費の象徴でしたが、イマドキの若者はそうではないのです。バブル後の長い低迷期の日本で可処分所得が少なくなってしまった時代、例えば90年代中後半くらいから女子高生を中心に「プリクラ」という流行がありましたが、あれなどまさに「モノ」より「思い出」重視が如実に出たものと言えるかもしれませんね。つまり可処分所得が下がってしまったなら、少しでも効率的に幸福感を得られるものにそのお金を消費しようとしたのかもしれません。

 「モノより体験」という研究結果はすでに出ています。モノを買うことによる幸福は最初をピークにどんどん下降してしまいます。確かにモノは体験よりも長持ちするかもしれませんが、体験は「思い出」となってあなた自身と同化することで実はずっと長持ちなのです。

にほんブログ村 科学ブログ

2017年1月26日木曜日

人月神話の弊害?:文系エンジニアはなぜ誕生したのか~日本の現実 (1/3) - @IT

人月神話の弊害?:文系エンジニアはなぜ誕生したのか~日本の現実 (1/3) - @IT:

 今回の話題は「文系エンジニア」という言葉がある不思議について、ご自身がIT企業でエンジニアの採用や生産性向上に携わるきのこる先生による記事をもとに、文系エンジニアというのはマヤカシだという話です。元記事の中で「エンジニア」は自分も関わる「ソフトウェアエンジニア」と同義で使われていますので、一旦ハードウェアやネッットワークなどは置いておきましょう。

 まず「文系エンジニア」というのは、海外には存在しません。というか文系の勉強をしてきた人が、高度なコンピューターの専門知識を前提とするソフトウェアエンジニア・プログラマーとして職を得るのは不可能に近いと思います。じゃあ理系ならいいかというと、理系でもコンピューターサイエンスの学位を持っていることが採用条件の場合も多く、それだけソフトウェアエンジニアがプロフェッショナルの仕事だと捉えられていることがわかります。

 一方で日本には「文系SE」というキャリアパスがあって、それは大学の文系学部を卒業して、就職後に初めてソフトウェア開発に携わるシステムエンジニア(SE)のことです。顧客から直接案件を受注する元請け企業の場合、SEは要件定義や設計といった上流工程や管理業務だけというケースも多く、高度なプログラミングスキルやコンピューターの知識がなくてもつとまる...そう考えられている節があります。自分は電機メーカーのソフトウェアエンジニアですが、専用システム・専用サービスのソフトウェアが対象でいわゆる「IT系」ではないのですが、顧客から直接受注するのでIT系に置き換えるなら元請け企業に相当すると思います。少なくとも自分が見えるソフトウェア開発の世界では、むしろ元請けエンジニアこそ高度なプログラミングスキルやコンピューターの知識が必要だと言えます。もしかしたら、この自分の主張には「本来は」とか「これからは」という但し書きが必要かもしれません。IT系の元請けは管理業務だけで、実業務のほとんどを一次下請けに外注し、一次下請けからさらに二次下請けへ再度外注して、二次下請けからさらに...という中間マージン搾取のヒエラルキー構造の場合、下請け企業のどこかにシステムアーキテクトと呼ばれてもいい程のスペシャリストがいて、その人が元請けSEが行うべき本来の「要件定義」や「設計」を肩代わりしていただけだと思います。もしくはそういう人がいない場合は、本来の期限がきても不具合だらけでカットオーバーできず顧客に迷惑をかけたり、人海戦術でバグフィックスしたりしてコストが膨らみ、顧客企業は追加料金を支払わされたりすることにつながっていたと思います。

 とても当たり前のことですが、元請け企業が担当する「要件定義」と「設計」の工程はハードウェアの世界でもソフトウェアの世界でも最も重要な工程です。「要件定義」は簡単に言えば「What」です。つまり「何を作るのか」を決めることです。何を作るのかを決めるのが難しいなんて、他の業界の人からすれば不思議に思うかもしれません。ところがソフトウェアの世界では、プロジェクトの失敗の原因は作るものを決められなかったことだというのはよくある話なんです。元請け企業のSEが「何を作るのか」を決められないまま外注するので、下請け企業は何を作っていいかわからない、そこで仕方なく独自に「要件定義」を行うことになるのです。次に「設計」というのは「How」のことで、どうやって作るのかということです。そして、建築などの世界ではモノ作りをできない人でも設計図を書くことができますが、ソフトウェアの世界ではそれは「ほぼ不可能」です。プログラムを書けない人がソフトウェアの設計をすることはできないのです。従って、元請け企業のいわゆる文系SEは、本来は自分たちの業務であるはずの「要件定義」「設計」を全て下請け企業に丸投げすることになるのです。

 これは自分の持論なんですが、「ソフトウェアにおける設計」とはデータベース設計やアーキテクチャ設計などだけでなく、多くの人が「製造」工程だと思っているプログラミング(ソースコードを作る作業)も設計だと考えるべきなんです。その証拠に、プログラミングの結果生み出される「ソースコード」は、日本語訳すると「基本設計図」になります。「ソースコード」は「設計図」なのだから、設計図を作る作業は「設計」なんです。そして「製造」という工程は、建築の世界では大工さんの作業ですが、ソフトウェアの世界ではEclipseやVisualStudioなど特殊なプログラム(開発環境と呼ばれます)が「自動的に」行なってくれるコンパイルやビルドという作業なのです。そう考えると、プログラムを書くこと(プログラミング)は設計そのものですから、プログラムを書けない人は設計ができない人ということになります。

 自分のこの意見に対して、そうだとしてもプログラミングは下流設計と呼ぶべきで、上流設計はプログラミングできない人でもできるんだと主張する人がいます。しかしそれは間違いです。いや、プログラミングを設計と呼ぼうが下流設計と呼ぼうが、百歩譲って製造と呼んでも、呼び方が問題じゃないんです。実際にソフトウェア開発を行なっている立場から言わせてもらえれば、全くプログラミングできない人がデータベースの論理設計・物理設計やアーキテクチャ設計・クラス構造の設計・タイミング設計などの上流設計もできるはずがありません。上流設計は、その設計アウトプットがどんなプログラムに落とし込まれて、実行中どんなメモリ配置がなされるか、プログラムの動きが分かった上でないと行なうことができません。プログラムの書けない人が書いた上流設計書は、そもそも実装できなかったり、実装できても動くはずがないゴミ箱行きがほとんどなのです。

 自分は本当の「上流設計」とは、次のように行なうべきものだと思います。まず、与えられた要件を実現するためのソフトウェアアーキテクチャ・データベースなど大まかな構成を考えます。次に、その中で特に実現が難しそうなところ、キモとなる部分、初めて採用しようとしている技術についてのプログラムを作ります。ここで作るプログラムは、実現性を確認したり、設計を詳細化するためやもっといい設計がないかを試行錯誤するための「お試し」プログラムです。そのためエラーハンドリングなど甘くてもいいですし、全体が動かなくても断片でいいので、とにかく「動く」プログラムを作ることが大切なんです。このお試しプログラムをもとにして、最初のアーキテクチャやデータベースなどの設計を詳細化したり、見直して修正を加えたりします。この作業を作るべき全体プログラムのいくつかの部分に対して行なったり、設計を変更した場所は改めてお試しプログラムを作ったりして、設計内容をブラッシュアップしていきます。いよいよこれで製品版のプログラムを作り始めても良さそうだとなった時、上流設計を終えて下流設計(プログラミング)の工程に移ります。そして、ここからのプログラミング工程は製品版のプログラムを作る作業ですので、エラーハンドリングもきちんと実装し見栄えやソースコード中に書くコメントにも気を配って書いていきます。この時、上流設計の中で作った「お試し」プログラムをもとにしてそれに肉付けしてく場合もありますが、多くの場合はお試し版はそのまま捨て去って新たにプログラムを作ります。このプログラミング工程になって初めて、外注へ発注を行なうのです。

 つまるところ、文系SEなんていうのはマヤカシです。いや、もちろん文系出身の方でも、就職後に本格的にプログラムやコンピューターサイエンスを勉強して活躍されている方もいるので、「文系SE」とひとくくりにするのは良くありませんね。プログラムを書けない上流設計者はマヤカシだ、と言い直しましょう。

にほんブログ村 ソフトウェア

2017年1月25日水曜日

「飲みュニケーション」「たばこ部屋」にも意義がある!? | プレジデントオンライン | PRESIDENT Online

「飲みュニケーション」「たばこ部屋」にも意義がある!? | プレジデントオンライン | PRESIDENT Online:

 今回は入山章栄氏の記事を元に、意外に重要な "アンオフィシャル" なコミュニケーションに関する話題です。「飲みニュケーション」なんてオヤジギャクはもはや死語と化している気もしますが、ビジネスを行う上でそのココロはとても重要です。

 重要なそのココロ。今風に言えば「トランザクティブ・メモリー」と言うのだそうです。会社組織を効率よく運営して利益を出そうとしたときに、メンバー同士の「情報の共有化」が重要だと言われます。情報の共有とはすなわち、みんなが同じことを知っているということですが、大きな会社組織ではこれまで情報共有化のためのコラボレーションツールとか社内SNSとかイントラのWebサイトとか、IT系のテクノロジーを駆使した仕組みがたくさん作られてきました。しかし実際に自分の会社を見てみますと、電機メーカーという性質上なのか技術系という性質上なのか分かりませんが、個人個人が持つ知識や情報の総和はとても大きく広範囲にわたっているため、それらを全員で共有するのは絶望的に無理があります。そこで登場するのが「トランザクティブ・メモリー」です。トランザクティブ・メモリーとは、「誰が何を知っているか」「この手の問題は誰に聞けばいいか」ということを知っているということです。

 本来の知識や情報そのものを共有する代わりに、このトランザクティブ・メモリーの共有を進めるのです。これなら比較的現実的な解になります。次の課題は「トランザクティブ・メモリーはどうすれば高められるのか」ということになりますが、その研究の中で面白いことが言われています。それは「直接対話によるコミュニケーション」が大切だという研究成果が得られているのです。メールや電話・社内コラボレーションツールのような情報システム経由のやりとりよりも、実際に対面して会話することで「誰が何を知っているのか」が組織に浸透するというのです。

 従来この役割を果たしてきたのが、タイトルの「飲みニュケーション」と「たばこ部屋」だったのです。実は自分は長男が生まれて禁煙するまでは2日で1箱くらいタバコを吸う喫煙者だったのですが、ちょうど会社に入った頃は分煙とか禁煙ブームで、会社では当然のように専用の喫煙部屋でしたタバコを吸うことはできませんでした。そして、まだ新人だった当時、この隔離された喫煙部屋で交わされる会話が意外にも重要だということに気づいたのです。先輩たちの誰がどんな仕事をしているのか、人事情報の噂話からどの営業がどの案件をどのくらいの確度で取れそうかといった情報まで、普段オフィスで机にいても絶対に入ってこないような情報がたくさんやりとりされていたのです。禁煙ブームの現代は喫煙者はたばこ部屋に押し込められていて肩身の狭い思いをしますが、この中で手に入る情報は極めて貴重な情報なのかもしれません。そして「飲み会」の場で入手される情報も同じ類いです。自分は仕事でいくつかの学会の標準化ワーキンググループの活動をしているのですが、その懇親会という名の飲み会で交わされる情報は、同業他社が今後どこに力を入れようとしているかとか顧客筋の力関係の情報だったり重要人物の情報など、とにかく会議室で交わされる情報よりもずっと重要な情報がやりとりされるのです。オフィシャルにとり交わされる情報の多くは「What」だとしたら、たばこ部屋や飲み会で交わされる情報の多くは「Who knows What」、ちょうどトランザクティブ・メモリーに相当します。

 そして入山氏がもう一つ言われているのが、ブレスト(ブレインストーミング)の効率に関してです。会議の中でも何かを決めるのではなくアイデア出しを主とするのがブレストですが、実際はブレストでのアイデア出しは効率が悪いという研究結果が出ているのだそうです。アイデア出しする手段が今の所ブレストくらいしかないのに、ブレストのアイデア出しは非効率という矛盾。この矛盾を「プロダクティビティ・ロス」と呼ぶのだそうですが、ブレストというスタイルは他の人に気兼ねしてしまって自由な発想や発言ができないのだそうです。確かに、エラい人が主催してさぁブレストするぞと会議室を押さえても、一般社員から出てくる意見はその人におもねるような内容ばかりになりがちです。

 情報は「What」と「Who knows What」の2種類に分けられます。そして、「Who knows What」はトランザクティブ・メモリーと呼ばれ、それは "Face to Face" の会話の中でやりとりすることで効率的な情報の共有がなされます。そして、ブレストのような「What」を生み出すような会議も実は非効率だというのです。残念ながら入山氏の元記事に「What」を生み出すのにブレストに代わる効率的な方法は示されていませんが、自分の実感としては、これも半分くらいは飲みニュケーションやたばこ部屋でのやりとりで刺激を受けてアイデアが出るというケースもありそうに思います。

 そういえば「革新的なアイデア」がビジネス上での競争力にダイレクトに影響するシリコンバレーのIT系企業(例えばGoogleなど)は、社内に娯楽施設を作ったり、無料で食堂を開放したり、オフィスの中央にカフェを設けたり、意図的に "アンオフィシャル" に情報交換をする場を多くしようとしているように思います。残念ながら自分の会社は古き日本企業特有の公務員的体質なので、そういった試みはなく革新的なアイデアが出ることもありませんでしたが、多くのスタートアップ企業では "アンオフィシャル" の情報交換をたくさん行って刺激しあい革新的なアイデアを生み出している気がします。もしかしたら企業の一生を見たとき、成長期は "アンオフィシャル" の情報交換がたくさん行われ、成熟期になると規模も大きくなったり公務員的体質が蔓延して "オフィシャル" な会議しか行われなくなり、やがて衰退に向かうという傾向にあると言えるかもしれませんね。革新的なアイデアやサービスが生まれない企業は、まずは社内に娯楽施設やカフェ・無料の食堂などで社員同士が "アンオフィシャル" の情報交換をする場を設けるといいかもしれませんね。

にほんブログ村 ニュースブログ

2017年1月24日火曜日

人工知能が人工知能をプログラムする時代がやってきた | TechCrunch Japan

人工知能が人工知能をプログラムする時代がやってきた | TechCrunch Japan:

 ついにこんな時代がやってきました。今回はそんな話題です。元記事はDarrell Etherington氏の記事を滑川海彦氏が日本語訳したもので、MITのレポートによれば、近く人工知能(AI)が人工知能のプログラムを書くことができるようになりそうだというのです。Google Brainをはじめ機械学習ソフトを開発している多くの組織で、AIがAIを作り出し、AIが作り出したAIは人間が作り出したAIと性能面で同等かそれ以上だったことが確認されたのです。

 AIの知能が人間の知能の総和を超える「シンギュラリティ(技術的特異点)は2045年くらいと予想されていますが、正直言ってそんな早く来るはずないだろうと思っていました。何と言っても人間はすごく賢いですし、AIが囲碁や将棋などで人間に勝ったからといって、それは専用にチューニングされた「単機能」のAIのことであって、あらゆる状況で臨機応変な対応ができる汎用的なAIは今後も100年やそこらではできないのではないかと思っていました。しかしこのニュースを読むと、うーんと唸ってしまいます。「AIが自分より少しだけ優れたAIを生み出す」、つまりAIが自分自身で「1× 1.01」ができるようになってしまうとあとはネズミ算式に性能や機能がどんどん向上してしまいそうです。

 自分はAIが発展しても、そのAIを開発・改良したりチューニングしたりメンテナンスしたりする仕事は人間に残される、つまりAIの能力をフルに発揮してもらうための周辺の仕事は人間に残される数少ない仕事ではないかと思っていました。ちょうど工場において生産の主体は機械やロボットですが、それを開発・改良したりメンテしたりするのが人間であるかのようにです。しかし今回のMITのレポートに関しては、それも怪しくなってきそうです。というのも生産機械のメンテは、油を注したり汚れを拭き取ったりリアル世界のメンテが主ですが、AIのメンテはソフトウェアのパラメータチューニングなどバーチャル世界のメンテが主だからです。AI自身がAIを開発・改良・メンテしだすと、その難易度や高度さはどんどん人間の手が届かない領域に入ってしまう可能性があります。そうなると、映画ターミネーターのスカイネットのように、人間対AIという対立の構図もあながち空想の世界と言えなくなってきます。

 ただ、そこまで空想を逞ましくしたところで、Etherington氏はAIの開発者さえ失業の危険に陥るわけではないと言われています。ただ、その根拠は現状ではAIにAIを作らせようとすると、莫大なコピューター処理能力を必要とすることだと言うのです。Google Brainに人間が作る以上のプログラムを書かせるには、800ものGPUを使用しなければならず、これはコストが合いません。(元記事では「画像処理能力があるプロセッサー」と書かれていますがいわゆるGPUのことで、AIのような機械学習には汎用的なCPUではなく単純計算が得意なGPUを使用することが多いんです) 単純にコンピューターがAIを開発する方が人間がAIを開発するよりコストがかかるから、まだまだ人間の開発者が必要だというコスト原理が論拠だとしたら、極めて弱い論理だと思いませんか。AIを使うより人間を使う方が安いから、人間は不要にはならないなんて。当然、AIがAIを開発するのに必要とするコンピューター能力を少なくするための研究開発も驚異的なスピードで進んでいますし、過去にも優れた技術が最初はコストが高くついても、大量生産や技術革新でコストが下がって広まった例はゴマンとあります。

 人間の仕事の大半が機械やAIを主としたコンピューターに取って代わられるという話がプログラム開発者にも当てはまってしまいそうだというのは、自分もソフトウェア開発の現場にいるのでうかうかしていられないという意味で重大な危機です。しかし個人的なマイナス点を除けば、このAIがAIを開発したりチューニングしたりするというのは、人類にとってはプラスに働くことでしょう。AIの元になっている機械学習は、これまで人間による開発・チューニングに多大な労力を必要としていました。そもそも機械学習の元になっているニューラルネットワークは、パラメータが極めて多い(だからこそ任意の関数を近似できるのですが)ので、カンと経験によるパラメータチューニングが必要だったのです。最新の人工知能がカンと経験なんていう職人技に依存しているなんて、なんだか変な気がしますが、実際に少しでもニューラルネットワークのプログラムを動かしてみれば意味がわかります。そんな職人技のチューニングをAIに肩代わりさせられれば、AIに対するハードルがぐっと下がって、多くの分野でAIを利用したプロダクトが市場に出る大きな助けになるはずです。

 今回はAIがAIをプログラムするという時代を迎え、ソフトウェア開発者の一人としては失業の危機かも考えると穏やかではありませんが、半信半疑だったシンギュラリティの世界も現実味を帯びてきそうだという話題でした。いやはや、我々はとんでもない時代に生きていますね。

にほんブログ村 AI・人工知能

2017年1月22日日曜日

ヤンキーも逃げ出す「超おバカ社会」がニッポンにやってくる

ヤンキーも逃げ出す「超おバカ社会」がニッポンにやってくる:

 今回の議論の元記事は山田順氏によるものですが、日本の人口減と例えそれを食い止めたとしても映画「26世紀青年(Ideocracy)」の世界が日本にもやってくるという話題です。

 2016年10月に総務省が明らかにした2015年の国勢調査の確定値として、日本の総人口は初めて減少に転じました。住民基本台帳による調査人口はすでに減少に転じてましたが、それをダメ押しするような形になりました。さらに国立社会保障・人口問題研究所によれば、日本の人口は2040年代に1億人を割り込んで、2060年には8674万人にまで減少すると推測されています。人口が減ることで、経済成長は不可能になり、税収減によって社会保障やインフラ維持すら困難になるという悲観論が圧倒的多数だと思います。山田氏も悲観論の立場で、従来「まちおこし」や「地域活性化」と叫ばれ、アベノミクスは「地方創生」と言い換えていますが、実際のところ有効な手は打てていません。例えば、移住促進なんて言いますがたとえ成功しても単に日本国内の人口移動に過ぎませんし、「ふるさと納税」なんて税金の付け替え先を変えるだけですし、「プレミアム商品券」という金券ばらまきにしても、そもそも日本全体の人口がシュリンクしていく中で少なくなる人間を地方が取り合っているだけと言えます。つまり過去行われたあるいは現在行われている地方再生策は、日本全体の人口が増えていかないと効果を発揮しないにも関わらず、肝心の人口は減少に向かっているというのが実態なのです。

 ところで山田氏は、そんな人口減に対抗してる層がいることを指摘しています。それは、地方都市や大都市圏の郊外にいる「マイルドヤンキー」と呼ばれる層です。ヤンキーとは言うもののひと昔前の「暴走族」や「不良」とは必ずしも同じではなく、彼らは地元をこよなく愛して、中学や高校を卒業しても大学生活や都会生活に憧れることなく、地元で就職します。彼らの特徴は、勉強があまり好きではなく20歳そこそこで「早婚」「デキ婚」、たくさん子供を産んで「キラキラネーム」をつけるというのが典型的とされます。厚生労働省の発表するデータによると、学歴が高い女性ほど子どもをつくらない傾向があるそうです。母親の学歴が高いと、キャリアと子育ての両立の難しさからキャリアを取る女性も多く、結果的に学歴に反比例するかのように子供の数は少なくなるということです。かつて「貧乏人の子だくさん」なんていう言葉があり、貧困層は貧困ゆえに労働力を必要とし、その最も簡単な解決策としてたくさん子供を作りました。高学歴・富裕層(エリート)は子供が少なく、低学歴・貧困層は子供をたくさん作るというのが傾向なのです。どちらかというと後者に属するマイルドヤンキーは、もしかしたらこれからの日本の人口減を食い止める役割を果たすかもしれないと期待されているのです。

 低学歴・貧困層がたくさん子供を作った時、日本はどうなるのでしょうか。そんな世界が描かれているのが映画「26世紀青年(Ideocracy)」です。「ideot(バカ)」と「-cracy(政治、国家)」の造語のタイトルがつけられこの映画は、とても上品とは言えない種類の映画ですが、エリート達は子供を作らず少子化に、その代わりバカだけが避妊をせず子供を作りまくりその挙げ句、バカだらけの世界になってしまったという映画です。

 人口減は経済成長を不可能にし、税収が減って社会保障やインフラが維持できなくなるという「悲観論」。そうならないために期待される「マイルドヤンキー」と呼ばれる層は低学歴・貧困層なので、例え人口減を食い止める働きをしても、人口における高学歴層は相対的に減少して低学歴な貧困層が相対的に増えるだけ。ザクッとまとめるとそんな議論の展開です。しかし基本に立ち返って、人口減はそんなに悪いことでしょうか。そして、バカばっかりになる世界は、そんなに悪い世界でしょうか。

 悪いに決まっている...人口減の悲観論を支持する方は当然そう反論されるでしょう。しかし、この山ちゃんウェブログでよく槍玉にあげる「シンギュラリティ(技術的特異点)」は2045年と言われていますが、現在の人間が担っている仕事の多くは人工知能(AI)に取って代わられると言われています。肉体労働はロボットや機械が、頭を使う仕事はAIが担う世界になっていくのです。人口が少なくなっても、経済成長を支えるのはコンピューターと人工知能ですし、介護だったり農業や工事現場の力仕事だったりのインフラを支えるのはロボットです。日本人がバカばっかりになっても、彼らはAI・コンピューターやロボットが生み出す富を消費するという重要な役割を担うことは可能です。そう考えると、技術の進歩とくに現在アメリカに遅れをとっているコンピューターやAIの分野で技術力を磨くことが人口減を補うためのキーになるかもしれません。日本の人口が減ったとしても、日本人がバカばっかりになったとしても、そんな逆転不可能に思える状況をひっくり返すことができるのは、コンピューター・AI・ロボットといったテクノロジー、そしてそれらを生み出す天才たちかもしれないと思うのです。

にほんブログ村 ITニュース

2017年1月21日土曜日

Amazonの音声認識「Alexa」は世界のIoTを席巻し「スマートフォンの次」のプラットフォームの覇者となりつつある - GIGAZINE

Amazonの音声認識「Alexa」は世界のIoTを席巻し「スマートフォンの次」のプラットフォームの覇者となりつつある - GIGAZINE:

 スマホが全盛の今だからこそ「スマホの次」、今回はそんな話題です。ビジネスの世界では、「仕組み」を提供する企業がエコシステムのトップとして君臨して利益を独占し、仕組みに乗っかって商売をする企業はそのおこぼれに預かるという構図が鮮明になっています。例えば、AppleはハードウェアとしてのiPhone・iPadもそうですが、音楽や映画・アプリを提供できる「仕組み」であるiTunesとAppStore、Android陣営ではGoogleのPlayストアがそれにあたりますし、GoogleといえばYouTubeも広い意味で「仕組み」を提供するものです。「仕組み」は「プラットフォーム」と言い換えてもいいでしょう。他の企業がビジネスをするプラットフォームを提供する企業がエコシステムの頂点に君臨するということで、今回ご紹介するAmazonもやはり同様です。

 さて、スマホに関するエコスシステムはAppleとGoogleがそれぞれの陣営を構成していますが、スマホの次を狙っているのがすでにオンラインショッピングで一大エコシステムを構成しているAmazonです。以前にAmazon Goを紹介した時もAmazon Dash Buttonを紹介した時もAmazonの「ドリーム・ファースト」とでも言うべき勢いが感じられると書きましたが、今回のEchoもそうです。いやどちらかといえば時間軸的にはEchoの方が先なのですが、Echoは話しかけるだけで様々な操作を可能とする最近にわかにホットになりつつあるパーソナルアシスタントAlexaを搭載したデバイスです。パーソナルアシスタントと言えば、AppleのSiriやGoogleのGoogle Assistant、MIcrosoftのCortanaも有名です。下の写真がEchoという製品で、最初に「ウェイクワード」と呼ばれる特定の言葉を付け加えることで、例えば「Alexa」と呼びかけるとその後の言葉を指示として受け取るわけです。(Appleの「Hey, Siri.」のようなものですね) 機能としては、音楽をかけたり、ネットで検索したり、Amazonで買い物をしたり、とスマホでできることを「声」だけで行ってくれるのですが、2014年にAlexaを搭載したこのEchoという製品は当時は日本で発売されなかったこともあって、自分はさほど耳にしなかった気がします。


 しかし、ここにきて日本でも発売が近いと言われているのでちょっとよく見てみると、このEcho(というよりもAlexa)でAmazonが虎視眈々と狙うプラットフォームがどういうものかが分かります。機能としては、いわゆる人工知能(AI)を搭載したパーソナルアシスタントでその実体はクラウド上にあり、EchoはAlexaを利用するための1つの端末に過ぎないという位置付けになります。Amazonの狙いがよくわかるのが、Alexa Voice Service(AVS)という音声認識機能とAlexa Skill Kit(ASK)と呼ばれるコンテンツ作成のためのキットをサードパーティに開放したことです。AlexaではSkill(スキル)と呼ばれるアドオンを使って独自の注文を処理させることができるのです。例えば、元記事に言われているのは、ドミノピザのSkilでAlexaがピザを注文したり、UberのSkillでAlexaが配車サービスを手配したり、というのが可能になります。つまり、Amazonで買い物をするというのも、単なるSkillの一つというわけです。実際に次々とSkillが作られていて、音楽ストリーミングサービスSpotifyやスマート電球hueなどのSkillもあるのだとか。


 スマホの先にAmazonが見ている世界。それは「音声インタフェース」で操作するという世界です。人とコンピュータのインタフェースは、パソコンではマウスとキーボード・ディスプレイだったのが、スマホやタブレットではタッチインタフェースになり、そして音声インタフェースへの進化するだろうと。Stratecheryのベン・トンプソン氏は「AlexaはOSである」という面白い指摘をしています。OSとは、広義にはハードウェアの差異を隠して様々なアプリケーションソフトウェアに標準的なインタフェースを提供するプラットフォームという意味ですので、音声によって様々なサービスを利用するためのOSの役割をAlexaが果たそうという考え方です。

 そしておそらくですが、IoT(Internet of Things)のインタフェースとしても、このAlexaを搭載したEchoのようなデバイスが使われることになるのではないでしょうか。音声でエアコンを入れたりお風呂を沸かしたり、そういった世界を見ているのではないかと思います。

にほんブログ村 AI・人工知能

2017年1月20日金曜日

東芝、損失7000億円規模か 半導体分社化、他社の出資2割:朝日新聞デジタル

東芝、損失7000億円規模か 半導体分社化、他社の出資2割:朝日新聞デジタル:

 ついにこんなことになってしまいました。自分もその片隅にいる電機メーカー業界の雄として君臨していた東芝が、米国の原発事業を巡って当初想定を大きく上回って7千億円規模に達する損失を計上する可能性が出てきました。東芝の自己資本は2016年9月時点で約3,600億円に下がっているそうで、債務超過に陥る可能性すら出てきたのだそうです。さすがにそれは回避しようと、資本増強のために主力の半導体事業を分社化して、他社の出資を受け入れることも検討しているようです。

 東芝の事業構造はこんな↓感じです(時事ドットコムニュースより)ので、半導体が分社化されるともはやインフラと諸悪の根源になってしまった原発くらいしか残っていないことになります。今後はインフラにもメスが入ることも予想されており、さすがに倒産になることはないのでしょうが満身創痍と言わざるを得ません。

自分も仕事上のお付き合いで東芝のインフラ部門に何人か知り合いがいるのですが、今後どうなるのか心配なところです。以前スティーブ・ジョブズ氏の素晴らしさは「ドリームファースト」を貫いたことだと書いたことがありますが、シャープや東芝の状況を見ていると、改めてその思いが強くなります。とても逆説的ですが、「ドリームファースト」の企業は「伸びる」し、「利益ファースト」の企業は斜陽になる。そう思えてなりません。

にほんブログ村 ニュースブログ

2017年1月19日木曜日

とあるスーパーが、三が日店を閉めた理由...苦情への返事に「素晴らしい」と賛同相次ぐ - ニュース - Jタウンネット 東京都

とあるスーパーが、三が日店を閉めた理由...苦情への返事に「素晴らしい」と賛同相次ぐ - ニュース - Jタウンネット 東京都:

 お正月も過ぎてあっという間に1月も18日になりましたが、今回はこの三が日に閉店したスーパーへの苦情の返事が素晴らしいという話題です。昔のお正月はたいていのお店が閉まっていて食料の買い出しにも困るので、三が日はずっとおせち料理とお雑煮、それに飽きた4日目くらいにようやくお店も開くので、ようやくハンバーグとか焼肉とかおせち以外のものを食べられる...そんなのが普通でした。それがここ20年くらいでしょうか、元日から開いているお店が多くなって、今では三が日だから閉まっているお店の方が少ないくらいに感じるようになりました。今回はそんな社会の流れと逆に行くように、三が日にお店を閉めたので、クレームがついたのでしょう。

 実際のお店の回答が、こちら(↓)。最初に、三が日の休業でご迷惑をおかけすることをしっかりお詫びした上で、三が日以外毎日営業できているのは職員がしっかり支えてくれるからで、そんな職員の頑張りに報いるための休業であることを説明、年末の品揃えを多くしたり休業明けにリフレッシュして頑張ることを約束する。とてもオトナな文章で、素晴らしい回答です。

 従業員を大切にしない会社が多い中で、社員に対する愛情をしっかり示して、かつお客さんからも逆に信頼感を得たのではないでしょうか。スーパーや量販店によく「お客様からの声」と称して、お客さんからのコメントとそれに回答を店長クラスの方が書いて貼り出してある、アレなんだと思いますが、この掲示板はお客さんも従業員も両方が見ることもポイントですよね。朝礼などで、従業員に向かって直接あなた方を大切にしていると言うよりも、お客さんに向かって自分は従業員を大切にしていると言っているところを従業員が見たとき、その伝わり方は直接よりも何倍も伝わるんじゃないでしょうか。

 「褒める時は間接的に」「叱る時は直接的に」がいいと言われています。例えば、いつも厳しい上司が、顧客を一緒に訪問した時に顧客に対してコイツは私の右腕なんですと言っているのを聞いた時、他の部署の人からあなたの上司があなたのことを褒めていましたと聞いた時、この上司のためなら頑張ろうという気になりませんか。逆に、間接的に自分の悪口が聞こえてくるといい気がしませんし、他の人がいる前で叱られようものならモチベーション下がってしまいますよね。そんな時は、会議室に二人きりで叱るとかそんな工夫があれば気遣いが伝わってくるかも知れません。

 そういう意味で、最近は会社のお偉方も一般社員も同じ広い部屋のの中で机を並べる形態のオフィスがありますが、自分はあまり賛成しません。エラい人はやはり個室があるべきで、部下を叱る場合はその個室に呼んで1対1で叱り、部下を褒める時は部屋の外に出てみんなに聞こえるように褒めるということをするのが理にかなっている気がします。褒めること・叱ること、どちらも相手だけでなく第三者の目を意識して行なうことで効果が挙げられるかも知れません。

にほんブログ村 ニュースブログ

2017年1月18日水曜日

全文表示 | 大炎上した大阪市の募集要項 「タダでプログラミング教育を」 : J-CASTニュース

全文表示 | 大炎上した大阪市の募集要項 「タダでプログラミング教育を」 : J-CASTニュース:

 今回は少し前にネット上で話題になっていた、「タダ」とはどういうことなのかという話題です。大阪市は今年1月12日「『平成 29 年度 大阪市プログラミング教育推進事業』の実施にかかる協力事業者の募集」と呼ばれる募集要項を公開しました。2020年施行の新学習指導要領で「プログラミング」を必修化することが検討されていることを受けてのもので、公募期間は今月30日まで、実施期間は来年度の1年間です。

 事業者に課せられているのは「小中学校におけるプログラミング授業づくり」「夏休みや土日等のプログラミング体験の提供」「教材・テキストの貸し出し、教員研修等その他の協力」ということなので、民間の力を教育現場に活用しましょうというどうということのない募集に思えますが、思わぬ項目があったのです。それは「人件費や消耗品費・教材費・交通費を含むすべての経費は事業者が負担すること」そして「事業者は事業を実施する物件に対する損害賠償責任を負うこと」というものです。さらにダメ押しで「業務を遂行するために必要な経費について本市は一切の費用を負担しない」と明記されています。つまり、タダでプログラミング教育を行ない、その過程で壊れてしまったパソコンや機材は弁償しなくてはならないというわけです。

 このトンデモ案件に対して、ネット上は「この世の地獄か?」「応募する意味あるん?」「すでにおかしい」などと炎上していますが、当の大阪市は「事前に数社にこの条件を提示したところ、無償はいかがなものかと言われたが、特定の業者との結びつきをなくし、公平性を担保するために『無償』という形をとった。無償という条件を変えるつもりはない」と涼しい顔。こんな条件の公募に応募して、自腹を切って事業を行なう意味って一体なんなのでしょう。何かウラがないと成り立たない事業ですよね。例えば、ここで実績を積めば、20年以降にプログラミングが必修化された時に優先的に請け負うことができるとか、将来プログラミング教育に使用されるITシステムを優先的に受注できる...とかなんとか。いやそれって相当グレー、というかおそらくクロですよね。

 もし文字通りの条件でウラがないシロだとしたら、事業者は持ち出しを少なくするための方策は打てそうですね。例えば、臨時に学校の近くの学生アルバイトでも雇って、人件費と交通費を圧縮する。壊れてしまって弁償するのはかなわないので、パソコンなどの機材は使わず、コピー代を削るために教材もプリントも使わない。授業は、テキトーにスマホとかタブレットを家で使った経験談でも話してお茶を濁すとか。「タダより高いものはない」なんて言葉がありますが、そんなことに巻き込まれて無駄な時間を過ごさなければならない子供達がかわいそうでなりません。

にほんブログ村 ITニュース

2017年1月17日火曜日

【1月下旬】大切なモノがすぐにみつかるスマートタグ Qrio Smart Tag(キュリオスマートタグ)|アスキーストア

【1月下旬】大切なモノがすぐにみつかるスマートタグ Qrio Smart Tag(キュリオスマートタグ)|アスキーストア:

 以前にTrackR bravoという商品を紹介したことがありました。500円くらいの大きさのタグで、家の中でいつも探してしまう鍵だとかどこに停めたかわからなくなってしまう自動車に付けておき、スマホアプリにその場所を知らせてくれるというものでした。今回ご紹介するのも、コンセプトは同じような感じですが、もうちょっと面白い仕組みを使っている「Qrio Smart Tag(キュリオスマートタグ)」という商品です。

 説明によれば、スマホとこのスマートタグをBluetooth(Bluetooth 4.0 Low Energy (BLE))で通信して、専用アプリからスマートタグのブザーを鳴らしたり、地図上からありかを確認したりして、失くしものをすぐに見つけてくれますよというふれ込みです。4G回線やWi-Fiを搭載しているわけではないのですが、TrackRなど他のタグより面白そうなのは、Bluetoothでスマホと繋がっている間は、スマホのGPS機能を利用して位置情報を記録しているのだそうです。つまり、自分のスマホを経由して位置情報をクラウドに持ち上げるので、通信が途切れる直前までタグがどこにあったかはアプリ上の地図で確認することができるのです。誰かに盗まれたとかではなく自分で置き忘れた場合なら、これで十分でしょう。

 しかし、この商品の面白いのは「紛失モード」というのがあって、スマホでこのモードに設定したタグは、同じ商品を使っている他人のスマホのBluetooth圏内に入った時に、その人のスマホ経由でクラウド上に位置情報を送信するというのです。なかなか面白いですよね。このタグそのものにGPSと4G回線を持たせれば、直接タグ自身がクラウド上に位置情報を上げられますが、このタグ1つ1つに毎月何千円もの回線契約をするのは非現実的ですし、一方でBluetoothだけではせいぜいスマホから20mくらいの中にタグがないと通信できない。そこで、自分のスマホだけでなく他人のスマホまで「踏み台」にしてしまおうという発想です。「踏み台」という言い方だとネガティブに聞こえますが、この商品を使う人は自分のスマホを他人にも踏み台にさせる代わりに、自分も踏み台にさせてもらいますよという、失くし物で困った時は「おたがいさま」という精神かもしれません。「おたがいさま」精神なんていかにも日本的だなぁと思ったら、やはり製造元のQrioは日本の会社だそうで、2014年にソニーとのジョイントベンチャーで起業された若いIoTベンチャー企業のようです。

 キャリアとは一定の上限までのパケット通信量なら定額という契約の方も多いと思いますが、パケット使用量を他人のために消費することを許容しない文化もあるかもしれません。しかし、通信量が何百MBとかいう大きな量なら難色を示す人も、数MB程度なら他人のために使ってもいいよという人は多いかもしれませんん。残念ながら紛失モードでも通信量がどの程度なのかわからないですが、単に自分のスマホのBluetooth圏内だけで通信する他の似かよった製品との差別化はまさにココにありそうですので、通信量と人々の許容度のバランス、あとはこの商品を多くの人が使ってくれないと踏み台にすべき他人のスマホが少なくて紛失モードというキラー機能が役に立たないかもしれません。

 この手のスマートタグで思うのは、なぜかスマホは必ず身につけていて忘れないという前提で商品コンセプトが作られていることです。それだけ現代人にとってスマホ依存症が進んでいるという見方もあるでしょうね。最近ですとスマートウォッチなんかも出てきているわけですから、今後は「スマホ」「スマートウォッチ」「スマートタグ」の3つがお互いに通信して互いの位置を確認し合うようになるかもしれません。

にほんブログ村 ITニュース

2017年1月16日月曜日

(天声人語)共通1次、涙の記憶:朝日新聞デジタル

(天声人語)共通1次、涙の記憶:朝日新聞デジタル:

 この週末は大学入試センター試験に臨んでいたという方も多いでしょう。今年は大雪に見舞われた地方も多いので、試験会場までたどり着くのが大変だったかもしれません。会場到着がギリギリになったりすると、落ち着いて普段の力が発揮できなかった方もいらっしゃるかもしれませんね。今回の話題は、そんなセンター試験と共通一次試験をトピックにした天声人語から。

 小説家・遠藤周作氏はご自身の作品が某大学の入学試験問題として出題された時、「主人公の心理を選べ」という問題に、4つの選択肢が全て正解だと思ったそうです。人間心理はとても複雑なのに、作者ですらどれも正解に見える問題を受験生に解けというのですから無茶な話です。でも実はそんな時には、問題文に魔法のワードがあるのです。それは「『最も』正しいものはどれか」というもので、主人公の心理として全ての選択肢は間違いとはいえないが、正しさに順位がつけられ、一番正しいものを選べという逃げ道なのです。こういった選択方式の問題の作り方の周囲には、様々なテスト用テクニックや例えば最初と最後の選択肢は正解になりにくいというような都市伝説がいくつも生まれてきました。ある程度そのテストの過去問などに慣れていないと、作者ですら遠藤氏のような状況に陥るのでしょう。

 そして、共通1次を衣替えしたセンター試験はいま見直しのさなかにあります。機械的なマークシートだけではなく、新たに記述式を取り入れるんだとか。元記事の記者の方は「記述式導入はマークシートだけより望ましいが、公平な採点をだれがどう担うのか課題」と述べられています。天声人語といえば朝日新聞のエース記者が書く、文章に穴がないよう細心の注意を払って作られた記事だと聞いたことがありますが、自分としてはここに敢えてツッコミを入れさせて頂きたいと思います。

 まず平等なテストに関して有名な、次のイラストをご覧ください(後で出てくる模範解答のない東大入試問題についての記事でも、同じイラストを載せました)。このテストでは、右の人物が「誰にとっても公平なテストをします。木に登って下さい」と言っています。この絵をみて考えさせられるのは、木登りが公平なテストでないのは明らかですが、そもそも「公平な」テストなんてものは存在し得るのでしょうか。例えば、数学や英語は障害を持つ子供にとっても公平なテストと言えるのでしょうか。
 以前に模範解答のない東大入試問題について書いたことを思い出しました。2016年の英語の問題で、その問題は「下の画像について、あなたが思うことを述べよ。全体で60〜80語の英語で答えること」というものというものでした。採点者によって大きく点数のつけ方が分かれそうですし、とても「公平な」試験ではないかもしれません。企業の入社試験に似たこの問題は、東大が「公平性・画一性からの決別」と「自らのポリシーに合致した学生を入学させる」という強いメッセージを発していると言うと言い過ぎでしょうか。

 であれば元に帰って、なぜ公平な試験が必要なのでしょうか。大学入試は公平な試験であるべきだなんて、単なる思い込みじゃないでしょうか。動物のテストのイラストを見てわかる通り、そもそも万人に平等なテストというのは存在しないのです。センター試験というのは、一見公平を装うようなマークシート方式ですが、専用のノウハウがなければ問題文の作者にすら解けない、極めて不平等なテストだと言えないでしょうか。大学入試は資格試験ではありません。「選抜試験」です。厳しい言い方かもしれませんが、大学側が「好みにあった」「ポリシーにあった」学生を採っていいんです。自分好みの学生を取るために、ポリシーに合う学生に有利になる試験を課してもいいのだと思うのです。もちろん、裏口入学とかコネを持つ学生は名前を書くだけで加点なんていうのは論外ですが、「こういうテストで高得点を取る学生に来て欲しい」というようなテスト問題にするのは、大学が自らが望む学生像をアピールすることにもつながりますし、学生を偏差値という画一的な物差しだけでなく人物や思想も含めて総合的に判断できるようになるかもしれません。多様性の時代とか個性の時代と言われる現代社会ですから、入試でもその大学にあったオリジナリティあふれる問題があっても良いのではないかと。そう考えた時、センター試験のマークシート方式の一部を記述式にするかどうかという手法の議論ではなく、現代の状況を考えた時にセンター試験という制度そのものをお役御免とするかどうかという議論こそ進むべきかもしれません。

にほんブログ村 ITニュース

異物混入か怪現象か。MacBookのドライブからコインを発見した人が多数|ギズモード・ジャパン

異物混入か怪現象か。MacBookのドライブからコインを発見した人が多数|ギズモード・ジャパン:

 今回はなんとも不思議な怪現象に関する記事。しかも最近だけでばく、密かに数年前から何件もマジックのようなコトが起きていたというのですから不思議です。

 その怪現象とは、なんと「MacBookのSuperDriveの中にコインが入っていた」という報告が何件もあるというのです。最近のMacBookシリーズはSuperDriveは外付けだけだと思うので、2012年と13年くらいまでのモデルなんだと思いますが、それでもまさかと思いますよね。1件や2件ならお騒がせなユーチューバーの自作自演とか、Twitter上に愚行をアップする一部の人たちの仕業かとも思いますが、そうならもっとインパクトのあることをしそうです。コインが入っているところも、個人的には十分にインパクトがあるように思いますが。何はともあれ、こちらのGreg Kilpatrickさんの動画をご覧ください。


 プラスティックの透明なカバーの下にはなぜか1枚のコイン。この動画は2011年に公開されたものなのですが、その後2013年・2016年にも同じような報告が別の人から上がっています。そういえば2014年12月に日本でも、カップ焼きそば「ペヤング」に昆虫が混入していたという事件があり、その後マクドナルドでも異物混入問題が出るなど、食品の異物騒動がありました。しかし、これはコンピュータですよ。しかもMacBookといえば薄型ノートPCですので極限までスペースを有効利用した実装がされていると思うんですが、こんなに大きなコインが入り込むスペースがあるとは。いやー、不思議なことってあるんですね。

にほんブログ村 ITニュース

2017年1月15日日曜日

東京新聞:声をきいて 子どもの明日(下) 子育て 孤立する母子:社会(TOKYO Web)

東京新聞:声をきいて 子どもの明日(下) 子育て 孤立する母子:社会(TOKYO Web):

 今回は少し重い話ですが、東京新聞の紙面から柏崎智子氏・小林由比氏・奥野斐氏の記事で母子の孤立に関する話題です。以前に、母娘が孤立し息が詰まってしまって、ついに母が幼い娘を橋の上から落としてしまうという悲しい事件を紹介したことがありました。自分も子供を持つ親なので、子供たちが苦しい境遇にいることは耐えられないほど胸が苦しく感じてしまいます。今回はその延長線上にもある記事かも知れません。

 元記事は、東京世田谷区と文京区のそれぞれでゼロ歳児の子育てに奮闘する女性の声を紹介しています。母乳を与えオムツを替えても泣き止まない子供に、どうしようもなく追い詰められていく様子が描かれています。世田谷区の女性は、子供が泣くとマンションの隣に住む男性から「うるせー」と怒鳴られ、心休まる暇もない様子です。父親・祖父母など育児に協力してくれる人はいないか、あまり全面的には協力を得られる環境にないようです。

 孤立した子育ては、虐待の大きな原因です。国の調査によれば、虐待によって死亡した子供の家庭の七割は、近所付き合いがほとんどありませんでした。東京の場合、特に子育てが孤立しやすく、三世代同居は全国最低の2.2%、仕事からの平均帰宅時間は全国で最も遅い19時45分。これらの数字からは、母子家庭などシングルペアレントだと孤立に陥りやすいというだけでなく、近くに祖父母がいないのでいざという時に頼れなかったり、仕事をする父親も帰りが遅かったりして頼りにくいという様子が想像されます。そういえば、最近SNSを使う子供は幸福度が低いという記事の中で、家庭の収入と子供の幸福度に明確な相関がなかったにも関わらず、母子家庭などシングルペアレントの場合はマイナスの相関があったことを紹介しました。シングルペアレントの場合、孤立した子育てになりやすいために親の方の精神状態も悪くなって、ひいては子供の幸福度に影響が出るという構図が推測されます。

 文京区では母子の孤立を救うために、「ネウボラ」と呼ばれる試みが始まっています。フィンランド語で「助言の場」という意味で、保健師が継続して相談に乗り子供と母親が家庭に引きこもらないように母子同士の交流の場も設けます。

 もちろん「公」の仕組みでの母子の孤立を救うための仕組みはとても重要なのですが、自分は子供を取り巻く「私」の環境がもっと良くなればいいのにという気持ちもあります。昨年問題になりましたが長時間労働のために父親がなかなか家庭に帰れず、父親が母親と子育てを分かち合えない。ご近所付き合いが減ってしまって、近所の人たちの助けも借りられない。最近高齢者の定義を75歳以上に引き上げる提案がニュースになりましたが、祖父母世代も現役ということが多くなって子育ての助けができづらい。この八方塞がりが1つでも解消されれば、孤独に陥ることなく子育てできる人が増えると思うのですが。お父さん・おじいさん・おばあさん・おじさん・おばさん・ご近所さん、一人で子育てを頑張っている人にはぜひ声をかけて助けてほしいものだと思います。

にほんブログ村 ニュースブログ

2017年1月14日土曜日

飲酒後にラーメン食べたくなる理由判明 英でマウス実験:朝日新聞デジタル

飲酒後にラーメン食べたくなる理由判明 英でマウス実験:朝日新聞デジタル:

 年末年始、忘年会だとか新年会だとかお酒を飲む機会が多かった方も多いと思いますが、ひと月前に知ることができていればもっと嬉しかったかもという、瀬川茂子氏によるニュース記事。

 お酒を飲んだ後、シメにラーメンという方は多いと思います。他にも、自分はあまりこのタイプではないのですが、シメはアイスクリームという方も多いのだとか。確かに居酒屋などで4000円飲み放題なんてコースには、最後にアイスクリームが出ることがありますね。実は、お酒の後のシメにラーメンやアイスクリームを食べたくなるのは、アルコールが食欲にかかわる脳の神経細胞を活性化させるためなのだそうです。英フランシス・クリック研究所のグループがマウス実験でこの関係性を突き止め、11日に科学誌ネイチャーコミュニケーションズに掲載予定なのだとか。

 アルコールは高カロリーなので、お酒を飲めば空腹感も満たされるはずなのに、実感としてはお酒を飲むと普段以上に食べ過ぎてしまいませんか。実は、多くの人が飲むと食べ過ぎてしまうことを実感していたにも関わらず、その因果関係はわかっていなかったのだそうです。自分も、何となく酔っ払うと自制心が働かなくなったり、満腹感を脳に伝えづらくなってしまうのかな、くらいに思っていました。

 実験でマウスにアルコールを与えると、飢えによって食欲が増す時に働く神経細胞が活性化することがわかったそうで、結果として食べる量が1〜2割増えることが確認されたのです。この神経細胞はマウスと人で共通のものだそうで、人間もお酒を飲むと過食しやすいということは科学的にも因果関係があったのです。それが分かっても、過食を防ぐことには繋がらないんですけどね...

にほんブログ村 ニュースブログ

2017年1月13日金曜日

ソーシャルメディアを使うほど、子どもの幸福度は下がる(特に女子)|ギズモード・ジャパン

ソーシャルメディアを使うほど、子どもの幸福度は下がる(特に女子)|ギズモード・ジャパン:

 今回の話題は、塚本紺氏によるシェフィールド大学の研究者が発表した論文「ソーシャルメディアの利用と子どもたちの健康」の紹介記事です。SNSが幸福度を下げると聞くと、えぇ意外だと思う人はむしろ少なく、やっぱりなと思う人の方が多いのではないかと思います。かくいう自分も、最初の感想は「やっぱり」と思いました。ただ、その原因はわかってはいないようで、論文の中でも3つの仮説が示されているそうです。

(1)「ソーシャル比べ合い」理論
 SNSに多くの時間を費やすということは、それだけ多くの人と繋がっているということですので、他の子どもたちと自分を比べてしまうからではないかという考えです。なるほど一理ありますね。社会に出る前の子供が自分の周りしか付き合いがない場合、だいたい経済的にも同じような環境の友人が多いかもしれませんが、SNSで世界中とつながると中には裕福な人もいるでしょう。他にもSNSでは、恋人との円満をやたら強調したり仕事や勉強の達成を強調したり、「幸せ自慢」のようなことも蔓延している気がしますので、それを真に受けて相対的に自己評価を下げてしまうこともありそうです。

(2)「有限リソース」理論
 当たり前ですが、バーチャルなSNSの世界での活動に多くの時間を取られるということは、リアル世界での活動に費やす時間が少なくなり、人と直接会って会話をしたり、身体を動かしたりすることが減ってしまうということです。

(3)「サイバーいじめ」理論
 説明の必要もありません。ネット上では、匿名性のあるSNSも多いので、リアル世界よりもむしろ「いじめ」が多く見られる気がします。いじめられれば当然幸福度は下がります。

 自分が子供の頃はちょうどファミコンが出始めた頃で、その頃も子供がみんな室内でのファミコンゲームに時間が取られるので、外遊びが減ったり人との付き合いが減ったりして問題だと言われたことがありました。ファミコンがSNSに変わっただけで、結局はいつの時代も一世を風靡する現象は、行き過ぎを心配する声を招きますが、実際に自分が大人になってから振り返ると、特段ファミコンがあったから幸福度が低かったようにも実感しませんので、(1)(3)が大きいのかなと個人的には思います。

 ちなみに、論文には他にも興味深いことが書かれていました。SNSが槍玉に上がるずっと昔、テレビをたくさん見ることがよくないと批判の対象になっていたことがありましたが、少なくとも幸福度に与える影響という意味では、テレビを視聴する時間ほぼ影響がなかったそうです。また、家庭の収入と子どもたちの幸福度にも関連性は見つからなかったとのこと。なんとなく先入観で、テレビをずっと見ている子は幸福度が低く、家庭の収入が多い裕福な家の子は幸せを感じるのかと思っていましたが、ちょっと意外ですね。ただその一方で、シングル・ペアレントの家庭では子どもたちの幸福度は相対的に低かったのだそうです。

 もちろん相関関係が確認されただけで、因果関係が証明されたわけではありませんが、子供を持つ親としてはやはり自分の子供にはいつも幸せを感じてもらいたいと思ってしまいまう。こう行った相関はちょっと気に留めておくと、家庭円満とか子供の非行防止とかにも繋がるのかもしれませんね。

にほんブログ村 ニュースブログ

スマホの電池を守る正しい方法|ギズモード・ジャパン

スマホの電池を守る正しい方法|ギズモード・ジャパン:

 ここのところ技術寄りだったり固い話題だったりが続いたので、少し息抜きして今回はスマホの電池を長持ちさせる方法。この元記事自体が2013年の記事の再掲だそうですので、スマホ全盛のこの時代、バッテリー寿命に関する情報のニーズはすごく大きいのかもしれませんね。

(1)注ぎ足し注ぎ足し
 まずバッテリーを長持ちさせるための最初の秘訣は、充電を満タンにしないこと、そして空っぽにもしないこと。その昔「メモリー効果」といって、満タンから空っぽにして潜在能力を「教えて」やらないと容量の一部を「忘れて」しまうっていう話がありました。この問題はないことはないのですが、ニッケル系電池の話であって、イマドキのスマホはリチウムイオン電池なので、100%→0%→100%なんて極端な使い方をするのではなく、注ぎ足しの方がいいのです。そして、できるだけ50%以上をキープして、40%くらいになれば80%くらいまで充電するという「秘伝のタレ」方式が一番賢いのだそう。

(2)冷やす
 リチウムイオン電池は熱が大敵です。熱くなるとスマホのバッテリーは速く劣化しますが、ここで言う「熱く」というのは真夏の酷暑環境で置いていただけでも劣化が速いのです。リチウムイオン電池の最大容量は平均気温0℃だと年6%、25℃では20%、40℃ではなんと35%も減るのです。スマホを冷蔵庫で冷やすなんて、ネタかと思いましたが暑い車内で長時間酷使した後など、現実に有効なことなのです。

(3)ワイヤレス充電しない
 これは(2)の焼き直しですが、あえて項目を分けています。対応しているスマホの場合、ワイヤレス充電はとても便利ですが、結構アレって熱が出るんです。つまり劣化が早く進んでしまいがちなので、できれば有線での充電がオススメです。

(4)空っぽにしない
 これも(1)の焼き直しですが、あえて項目を分けます。例えばiPadが古くなったので新しいのを買った、でも古い方も残してある。そんな人はいませんでしょうか。実はリチウムイオン電池は何もせず置いておくだけでもよくないのです。そんな時でもバッテリー劣化を避けるには、決して空っぽにしないことです。長期保管の際には最低40%残しておくのがいいそうで、毎月5~10%減りますので、2-3ヶ月に1回は取り出して「注ぎ足し」しましょう。

 今回はスマホのバッテリーを長持ちさせるためのコツを紹介しました。こんなこと気にしなくてもイマドキのスマホのバッテリーは3年とか5年とか持ちますので、気にしすぎはよくありませんが、ちょっとした心がけ程度で容量を減らさずに使えるのであれば、心に止めておくといいかもしれませんね。

にほんブログ村 ITニュース

2017年1月12日木曜日

[C#] .NETFramework3.5で問題になったSOAPメッセージの複雑さ制限

 今回は最近、仕事でハマってしまったC#プログラムネタです。以前に、C#でSOAPサービス参照を行う時に、.NETFramework4.5.1を使った場合、App.configファイルに以下の太線部の「おまじない」を書かないとOut Of Memoryのエラーになることを書きました。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.xml.serialization>
        <xmlSerializer useLegacySerializerGeneration="true" />
    </system.xml.serialization>

    <system.serviceModel>
        ..........(省略)..........
    </system.serviceModel>
</configuration>

 実はもう少し調べると、.NETFramework4でも同じことが起きるので、このおまじないを唱える必要があるかどうかは、「3.5以下なら不要・4以上なら必要」ということです。そしてHRESULT=0x8007000eエラーは、最初のSOAPサービス呼出の時に発生するので、一見うまく動き出したプログラムが突然メモリーを大量に使い出してついにはエラーで止まってしまういう不可思議な事象に見えてしまうのです。

 それまでSOAPのWebサービスを使用したクライアントプログラムは、.NETFramwroek3.5で書いていたのに、ある時4.5.1を使ったがために、こんな罠にハマってしまったという話だったのですが、実は今回、不覚にも逆の罠にハマってしまうという失態をしでかしたので、忘れないためにここに書き留めておきます。実は、ある既存のサービス環境が.NETFramework3.5環境で動いているので、それに合わせてわざわざビルドを4.5.1ではなく3.5にして提供しなければならないプログラムがあったのです。自分は、上記のおまじないのことも知っていたので、今度は.NETFramework3.5なのでおまじない不要としてプログラムを書き、3.5向けにビルドしたのですが、なんと今度は実行時に別の例外が出てしまったのです。それが、次のようなエラーです。

[ERROR] 操作 'yamachanService' の応答メッセージの本文をシリアル化解除しているときにエラーが発生しました。
Server stack trace:
   場所 System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.DeserializeBody(XmlDictionaryReader reader, MessageVersion version, X
mlSerializer serializer, MessagePartDescription returnPart, MessagePartDescriptionCollection bodyParts, Object[] parameters, Boolean isReque
st)
.....
 一体何を行っているのかわからず、ひとしきりハマってしまったのです。実は、クライアントプログラムを書くときに、すでにVisualStudio上で「下図のようにサービス参照の構成」を使用して相手先のサーバーの情報を設定して、それで普通に動いていたのです。ところが、相手サーバー側でサービスの追加変更があったために再度読み直してくれと言われ、下図の「サービス参照の更新」を行なうと、それ以降にプログラムを実行すると上記のエラーが発生してしまうというわけなのでした。(バックアップしていた、サービス参照更新前のプログラムに戻すと動く) サービス参照の構成・更新というのは、相手サーバーが提供しているサービスの名前とかパラメータとかの定義が書いてあるWSDL(Web Service Description Language)ファイルを読み直して、プロキシとなるクライアントプログラムを自動生成してくれるVisualStudioの機能なのですが、昨日の夜まで動いていたのが更新した途端に動かなくなったのだから、これはてっきり相手サーバーが何か悪さしたんだろうと思いました。


 ところが、Wiresharkを仕掛けて相手サーバーとこちらのプログラムの通信内容を調査したところ、相手サーバーは何事もなく正常通りにSOAPの要求を受け付けて応答も正しい応答を返していたのです。つまり、C#クラアイアントプログラム側になんらかの問題があったのです。実は、エラーメッセージとスタックトレースをよく調べればすぐに解決できたはずだったのですが、この時まさか自分側が悪いと思っていなかったのとサービス参照の更新時に謎のエラーも出ていたこと、ビルドを.NETFramework4にすれば事象は発生しない、というようにいくつものことがあって原因究明に手間取ってしまいました。

 要因はなんと、処理可能なSOAP メッセージの複雑さに対する上限を終えてしまったためでした。この処理可能な複雑さというのは、App.configの以下の太線部readerQuotasで定義されるのですが、今回の相手サーバー側のサービス追加変更で、ここの上限値をオーバーしてしまったのです。早速、ここの値を大きくして解決できたのですが、下記では ".." で表しておきます。適正値は環境や相手サーバーの提供サービスによって違いますので、それぞれに合わせた値にする必要があります。その値を探るのがメンドウですって? そんな方は、Integerの最大値2147483647を使用すれば大抵うまくいきます。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <system.serviceModel>
  <bindings>
   <basicHttpBinding>
    <binding name="YamachanAPIPortBinding" ...>
     <readerQuotas maxDepth=".." maxStringContentLength=".." 
       maxArrayLength=".." maxBytesPerRead=".." 
       maxNameTableCharCount=".."/>
    </binding>
   </basicHttpBinding>
  </bindings>
  <client>
   <endpoint address="..." .../>
  </client>
 </system.serviceModel>
 .....
</configuration>

実は.NETFramework4でビルドすると、このreaderQuotasは定義しなくてもエラーにならなかったので、.NETFramework3.5の時だけ問題が表面化したのでした。いやー。昨日まで動いていたものが突然動かなくなると焦るものですねー。それにしても、Microsoftのものって複雑な部分が隠されているので、うまく行っているときは快適ですが、一度うまくいかなくなるとあたふたしてしまいます。そういう意味で、プログラムとしてのC#は自分は好きな言語なのですが、いざという時の解析性の高さでまだまだJavaを手放せない感じです。


人気ブログランキング

いま、世界の大企業は「AI人材」を食い尽くそうとしている|WIRED.jp

いま、世界の大企業は「AI人材」を食い尽くそうとしている|WIRED.jp:

 昨日、中島聡氏のメルマガ記事をもとにAIに頭脳系の仕事を奪われた先、人間に残される仕事は、AIのおこぼれに預かるか頭の良い悪いではない軸を見いだすことの2通りしかなさそうだという議論を展開しました。今日はそんなシンギュラリティ(技術的特異点)へ向かってひた走る世界で、AI人材が引く手あまただというCade Metz氏の記事をもとに、仕事を奪われないためのスキルについて考えてみたいと思います。

 ここ数年の間に、IT系大手企業は、その名前を聞いたこともないような多くのスタートアップを先を争って傘下におさめてきました。TwitterはMad Bit・Whetlab・Magic Ponyを、AppleはTuri・Tuplejumpを、SalesforceはMetaMind・Prediction I/Oを、IntelはNervanaをそれぞれ買収してきました。さらにIT系だけではなく、GEもバークレーに拠点をおくスタートアップWise.ioを買収します。この買収された企業を皆さんはどのくらいご存知でしたか。電機メーカー業界にいる自分でも、勉強不足なのかこれらのスタートアップのことを知りませんでした。大手企業が買収合戦を繰り広げているスタートアップに共通しているのは、AI(人工知能)や機械学習の専門家集団だということです。

 そして、大手企業によるAI専門家の囲い込みは、その他の企業が置いてけぼりを食うことにつながる可能性があります。もともとWise.ioは「AIを民主化する」つまり誰もがAIを構築できるツールをつくることを掲げたスタートアップでしたが、GEに買収されてしまうことで、その魅力的なAI構築ツールも天才的な天体物理学者の人材もGEに飲み込まれてしまいます。3年ほど前にGoogleがFacebookとの買収合戦の末に勝ち取ったスタートアップDeepMindも、その大きな目的はAIの人材確保にあったと報じられています。Googleが515億円以上と報じられた巨額を投げ打ち、ラリー・ページCEO自らが手がけた肝いりの買収で手中に収めたかった人材こそ、神経科学者・ゲーム開発者・チェスの名人でもあるデミス・ハサビス氏その人です。当時、自分はDeepMindのことは全く知りませんでした。しかしそれから2年、DeepMindの名前もハサビス氏の名前も世界中にとどろいたことは記憶に新しいでしょう。あと10年か20年はコンピュータは人間に勝てないだろうと言われた囲碁において、人間のチャンピオンのイ・セドル氏を破り、今年に入ってからもトップクラスの棋士が集う中で60勝0敗という無敵を誇ったAI「AlphaGo」の開発者として。つまり、大企業は今こうしたAIの天才たちをこぞって囲い込もうとしているのです。限られたAI人材を奪い合う闘いにおいて、GoogleやGEのような企業は圧倒的に有利な立場にあり、中小企業にまでその人材や頭脳が"まわって"くることはまずないでしょう。

 裏を返せば、あなたがその貴重な人材になれば、引く手あまただということになります。GoogleやGEに狙われるほどの天才になれなくても、天才たちは大手企業に囲い込まれてしまっているので、もう1段か2段いや3段劣る人材でも人材市場では十分に魅力的に映るはずです。いまだ独立を保っているスタートアップSkymindの創立者クリス・ニコルソン氏は、機械学習が専門のデータサイエンティストを4人採用しようとしましたが、1人も雇うことができないそうです。普通のプログラマーだめなのでしょうか? 答えは、だめなのです。AIの構築は、標準的なソフトウェアエンジニアリングとはまったく異なり、プログラミングだけでなく、「数学」のプロであることと膨大な量のデータから結果を引き出すデータサイエンティストの技術が求められるからです。

 実は、自分もAIの入口にあたるニューラルネットワークのプログラムを作成してみました。単純パーセプトロンと呼ばれる1層のものは理解しやすいのですが、多層ニューラルネットワーク(多層パーセプトロン)になった途端に難易度が上がりました。その難しさはプログラムそのものの難しさというよりも、高度な数学に基づいたアルゴリズムを理解するのが難しいことと、あと特筆すべきはデバッグが難しいということです。機械学習では、プログラムの途中計算が正しいかどうかを判定することさえも難しかったのです。というのも、機械学習のアルゴリズムは人間の頭の中の考え方の仕組みとは全く違っていて、途中過程を見てもよく分からず一通りの学習をさせてテストデータを読み込ませてみて初めてうまく学習できていたことがわかるからです。また全体を通して、もっと数学をよく勉強しておけばよかったと後悔することしきりでした。特に確率統計分野は、高校でも大学でもあまり勉強しなかったので、突然ベイズ確率だとかシグモイド関数だとかハイパーボリックタンジェントだとかいう言葉が出てきても、そもそもそれって何だっけというところから始まってしまいました。

 最初に述べたように、シンギュラリティの世界が来てしまったら、人間に残されるのはAIやコンピュータ・機械のおこぼれに預かるような仕事か、頭がいいかどうかではない全く新機軸の価値観の元に新しい仕事を探すかの2通りになっていく可能性があるでしょう。しかしそうなってしまうまでには、まだ過渡期が25年くらいは続くとみられ、その間は人間から徐々にAIが仕事を奪っていくプロセスになります。この大きな流れは、残念ながらもはや止めることはできないでしょう。であるなら、あなた自身がAIを作る側の人間になれば、少なくとも向こう25年は安泰だと考えることもできるのではないでしょうか。シンギュラリティ後の世界でも、AIのおこぼれに預かる仕事には十分に就けるはずです。もしあなたがまだ学生さんで、自分は頭がいいと自負しているのであれば、そして将来せっかく一流企業に就職してもAIやコンピュータに仕事を奪われてリストラされたくないならば、今勉強しておくのは「数学」が最もオススメだと思います。

にほんブログ村 AI・人工知能

2017年1月11日水曜日

「豊かな社会」の悲惨な末路。なぜ機械化社会は格差を産んだのか? - まぐまぐニュース!

「豊かな社会」の悲惨な末路。なぜ機械化社会は格差を産んだのか? - まぐまぐニュース!:

 今回は、中島聡氏がご自身のメルマガ「週刊 Life is beautiful」の中で述べられている、今の世界情勢を作り上げた責任の一部は「豊かになる」ことを目指し過ぎたエンジニアにもあると述べられている議論についてです。自分もエンジニアの端くれですので、エンジニアには世界を変えてしまえる力があることはその通りだと思います。最近iPhoneが10周年を迎えたというニュースがありましたが、iPhoneを世に送り出したスティープ・ジョブズ氏は、まさに「良くも悪くも」世界を変えたと言えるでしょう。

 中島氏の言われる、エンジニアが作ってしまった嘆かわしい「今の世界情勢」とは、トランプ大統領の誕生・イギリスのEU離脱・ヨーロッパでの極右政党の台頭などの世界情勢の不安定さのことを指しています。過去の産業革命を振り返ると、機械化が人間から仕事を奪ってしまったことにより、人間が働く場は一次産業(農林水産業)から二次産業(製造業)、さらに三次産業(サービス業)とシフトしてきました。その結果、貧富の差が広がり、溜まりに溜まった貧者の不満がポピュリズムを台頭させ、ついにはトランプ大統領の誕生やイギリスのEU離脱につながった。大まかに言えばそんなストーリーで、この山ちゃんウェブログでも同じような議論を展開してきました。

 従来、機械やコンピューターにでもできる仕事をする人は相対的に報酬が少なく、人間にしかできない仕事をする人は高い報酬を得てきました。ここで言う、機械やコンピューターにでもできる仕事とは、Labourと呼ばれるような肉体労働だったり単純作業だったりで、人間にしかできない仕事とはWorkと呼ばれるような頭脳労働がメインでした。そして、人工知能(AI)の目覚ましい発展によって、従来は高い収入を得ていた頭脳労働者の仕事もコンピューターに奪われる事態になってきています。

 昨年末、衝撃のニュースが流れたことを覚えておられるでしょうか。富国生命がIBMの人工知能Watsonを導入することによって、人員を3割も削減するというリストラを発表したのです。人員削減の対象は膨大な情報量を一定の規則に則って仕分けする給付金査定の業務だそうで、まさにAIが得意とするような仕事でしょう。そして今後、同じように多くの知識や情報に基づいて正確な判断を下すことが主眼であるような仕事、具体的には弁護士・医師・証券アナリスト・ファンドマネージャーといった仕事は軒並みAIに取って代わられることが予想されています。重要なのは、ここであげた仕事はいずれも「頭がいい」とされる人が就いていた仕事で、基本的には高い収入を得ていた職種ばかりだということです。従来、機械やコンピューターに取って代わられるのは、基本的には頭をあまり使わない仕事だけでしたが、AIには頭を使う仕事をこそ取って代わられるのです。

 ここで1つの反論が予想されます。従来、例えば産業革命で蒸気機関ができたとき、人間の仕事は機械に取って代わられると危惧されましたが、実際にはそうはなりませんでした。オートメーション化が進んだときも同じ心配がなされましたが、実際は人間の仕事はなくなりませんでしたし、むしろ新たな職種が生まれるほどで人間が仕事を失うことはありませんでした。そう考えると、AIが頭脳を使った仕事を肩代わりしてくれたとしても、人間は仕事から解放されないだろうという反論です。

 しかし、自分は人間が仕事から解放されないだろうというのは賛成ですが、楽観的ではいられないと思っています。従来、縦軸に下に肉体労働を上に頭脳労働を置いた時、人間は下から上へ上へと追いやられてきました。下の方の仕事を機械に奪われ、より頭脳型の仕事を求めて上へ、コンピューターに単純作業を奪われてさらに高度な判断を求められる上の方へ。AIの知能の総和が人類の知能の総和を超えるとされる「シンギュラリティ(技術的特異点)」は2045年とも言われていますが、シンギュラリティの時代にはもはや人間にしかできないような仕事はほとんど残されなくなるのではないかと思うのです。すでに最上部まで追いやられた人間に、さらに上を開拓できる力は残されていないでしょう。

 したがって、将来的に人間に残される仕事は大きく2種類だと思います。1つは「AIのおこぼれに預かる仕事」です。AIといえどもコンピューターであり機械ですから、日々のメンテナンスやそれらの生産設備のメンテナンスなど、AIに目一杯仕事をしてもらうためのお膳立てをする仕事が必要です。そして2つ目は、「頭がいいかどうか」「頭を使うかどうか」だけではない、もう一つの軸を探すことです。その軸は今はまだ見えてはいませんが、芸術的なセンスがあるかどうかかもしれませんし、もっとエモーショナル(感情的)なものなのかもしれません。おそらく「頭がいい」とされてきた人々が、仕事をAIに奪われ頭の良さでAIに敵わないことが明確になったとき、彼らにとって1つ目の選択肢は耐え難い屈辱に感じるかもしれません。そのために、2つ目の選択肢を模索するのがこれからシンギュラリティまでの25年間の間に人間が総力を挙げて行うべきことなのかもしれません。

にほんブログ村 AI・人工知能

[Java] Springを使用したログ機能の覚書き(2)

 今回は前回に引き続き、Springを使用してエレガントにログ出力するテクニックです。前回の質問の2つ目「プログラムでLogInterceptorを一切使用していないにもかかわらず、なぜSpringがLogInterceptorのbegin()・afterReturning()・afterThrowing()を呼び出してログ出力できたのか」について、それができるための仕組み作りから種明かししていきましょう。

 実はSpringは、プログラムの起動時に設定ファイル「applicationContext.xml」を読み込んで、calculator(Calculatorクラスのインスタンス)とそのメソッド呼出時のインターセプターLogInterceptorを結びつけていたのです。それでは「applicationContext.xml」のファイルの中身を見て見ましょう(この設定フィル名はなんでもいいのですが、慣例的にこの名前を使用します)。

<?xml version="1.0" encoding="UTF-8" ?>
<beans>
  <!-- インターセプターを定義 -->
  <bean id="logInterceptor" class="com.dokkhwaymai.LogInterceptor"
      abstract="false" scope="singleton" lazy-init="false" autowire="default">
  </bean>

  <!-- クラスのインスタンスを定義 -->
  <bean id="calculatorImpl" class="com.dokkhwaymai.CalculatorImpl"
      abstract="false" scope="singleton" lazy-init="default" autowire="default">
  </bean>
  <bean id="calculator"
      class="org.springframework.aop.framework.ProxyFactoryBean"
      abstract="false" scope="singleton" lazy-init="default" autowire="default">
    <property name="target" ref="calculatorImpl"/>
    <property name="proxyInterfaces">
      <value>com.dokkhwaymai.Calculator</value>
    </property>
    <property name="interceptorNames" ref="logInterceptor" />
  </bean>
</beans>

 準備段階でのポイントは、インタフェースCalculatorと実装クラスCalculatorImplを分けて定義したことです。「applicationContext.xml」ファイルでも、実装クラスをid="calculatorImpl"として定義しています。これは、Spring上で"calculatorImpl"という名前でインスタンスを作るという意味です。通常はインスタンスを作る場合、new CalculatorImpl()というように「new」を使用しますが、Springを使う場合はそうではなくSpringにインスタンスを作らせるのです。次に、id="calculator"としてProxyFactoryBeanクラスなる何だか分からないクラスのインスタンスを作っています。この何だか分からないクラスですが、targetに先ほどのcalculatorImplが定義され、proxyInterfacesにCalculatorが定義されています。実はこれが大きなポイントで、この何だか分からないクラスのインスタンスは、内部的にcalculatorImplを保持し、そしてCalculatorインタフェースを使用してアクセスできるという定義なのです。(デザインパターンでいうところのProxyパターン、あるいはAdapterパターンと考えればわかりやすいでしょう)

 定義ファイルの「applicationContext.xml」を読み込んで、Springにインスタンスを作らせる、そして作らせたインスタンスを使用するときは、次のコードのようにします。

    ApplicationContext appContext = 
        new ClassPathXmlApplicationContext("applicationContext.xml");
    Calculator calculator = (Calculator)appContext.getBean("calculator");

このコードを見れば、インスタンス化されたcalculatorはCalculatorインタフェースを使用してアクセスできますので、前回に断片だけお見せしたコード
    calculator.add(3, 2);
とか
    calculator.add("abc", 2);
のようにメソッドを呼び出すことができるのです。つまり、普通にインスタンス化した
    Calculator calculator = new CalculatorImpl();
と外見上は同じようにcalculatorを使用することができるのです。しかし、しかしですよ。 Springに作らせたcalculatorは、実は何やらよく分からないProxyFactoryBeanクラスのインスタンスなのです。我々がcalculatorのメソッドを呼び出すときに、Springが勝手に
呼出直前・直後(例外発生の場合は発生直後)にそれぞれinterceptorNamesに定義したインターセプター(LogInterceptorのインスタンスlogInterceptor)のbefore()・afterReturning()・afterThrowing()を呼び出してくれるのです。

 さて、「プログラムでLogInterceptorを一切使用していないにもかかわらず、なぜSpringがLogInterceptorのbegin()・afterReturning()・afterThrowing()を呼び出してログ出力できたのか」の答えは、Springが設定ファイル「applicationContext.xml」の定義を読み込んで、calculatorとインターセプター(interceptor)を結びつけ、calculatorの各種メソッド呼出の時にインターセプターのメソッドを呼び出してくれるから、ということです。

 このことの何が素晴らしいかって、まず「ログ出力」というのは本来のプログラムで処理したいことではないので、本来の処理とログ出力のコードが混ざり合うと、何をやりたい処理なのか分からなくなってしまいます。ところが、Springのインターセプターを使用すると、本来の処理(CalculatorとCalculatorImpl)には全くログ出力のためのコードが存在しないのです。つまり、担当者によってやたら詳しくログ出力を埋め込む人と、大雑把にしかログ出力をしない人がいたとしても、ログ出力の詳細度とフォーマットを綺麗に整えることが簡単にできるのです。

 次に、例えば本番稼働時は性能を重視してログ出力はやめにしよう、というプロジェクトがあったとします。本来の処理とログ出力がごちゃ混ぜになっていれば、そこから全部のログ出力コードを削除するかコメントアウトしていかなければなりません。これは、自分の職場のような何百万行ものプログラムを書く場合、地獄の作業になってしまいます。削除の作業はまだしも、本来の処理コードが変わっってしまうので全部テストし直しということになるからです。それが、Springのインターセプターを使っていれば、「applicationContext.xml」で <property name="interceptorNames" ref="logInterceptor" /> を消せば良いだけです。あるいは、logInterceptorのクラスを何もしないクラスに置き換えてもいいかもしれません。何れにしても、設定ファイルだけの変更で本来の処理コードを一切変更しないで済むので、再テストも必要ありません。

 いかがでしたか。実はSpringは一昔前にサーバーサイドJava全盛の時に流行ったのですが、最近ではAndroid開発に押されてあまり脚光を浴びなくなってしまいました。しかし、ある程度の人数で開発するプロジェクトでは毎回、ログ出力をどうするかが議論されます。ログ出力のルールを定めても、各プログラマーにログ出力を任せてしまうと、個人差がモロに出てしまうので、管理しづらくなってしまいます。今回2回に分けてご紹介したSpringのインターセプターを使用すれば、管理者がLogInterceptorのコードを書いて、そのインターセプターで全プログラマーのインスタンスをインターセプト(横取り)してログ出力させれば、共通の詳細度で共通のフォーマットでログ出力を行うことができるというわけです。しかも、ログ出力のコードはLogInterceptorにしかありませんので、LogInterceptorさえしっかりテストしておけば、誰かがログを出力しようとしてNullPointerExceptionを起こしてしまうというような初歩的なミスを防ぐことができるのです。


人気ブログランキング

2017年1月10日火曜日

[Java] Springを使用したログ機能の覚書き(1)

 今年最初のプログラム技術の記事は、エレガントなログ出力機能の実装に関する覚書きを2回に渡って整理したいと思います。サーバーサイドのプログラムを書いていると、メソッドの引数や戻り値などをログファイルに出力し、何かあった時に解析の手立てとすることをよく行ないます。そして、Javaの場合はSpringというフレームワーク(このフレームワークは.NET版もありますので、C#でも実は同じことが実現可能です)と、この山ちゃんウェブログでご紹介したJacksonを使ったJSON形式文字列を使うことで、とてもエレガントなログ出力が可能になります。

 まずSpringフレームワークですが、このフレームワークは元々アスペクト指向プログラムとかDIコンテナとかというキーワードで一時話題になりましたが、その後肥大化してしまって、今ではトランザクション管理・MVCなど多くの機能を提供しています。Springを掘り下げて記事を書いても相当な内容があるのですが、今回は割愛してその中の「インターセプター」という機能を使って上手なログ出力をやってみましょう。「インターセプター」とは、よくサッカーやバスケなどで相手チームのパスを途中で横取りする「インターセプト」のことで、プログラムの場合は処理を横取りすることを指しています。「横取り」というのは、メソッドを呼び出す直前・直後に処理を「横取り」するという意味なのですが、文章ばかりではわかりづらいので、とりあえずソースを見てみましょう。

package com.dokkhwaymai;
import java.lang.reflect.Method;
import org.springframework.aop.*;
import com.fasterxml.jackson.databind.*;

public class LogInterceptor implements 
      MethodBeforeAdvice, AfterReturningAdvice, ThrowsAdvice {
  /* ログ出力先ロガー */
  private static Logger logger = LoggerFactory.getLogger(LogInterceptor.class);
  /* JSON文字列への変換用 */
  private static ObjectMapper objectMapper = new ObjectMapper();

  /* メソッド呼出のインターセプター */
  @Override
  public void before(Method arg0, Object[] arg1, Object arg2) {
    if (arg1==null || arg1.length == 0) {  // 引数なしの場合
      logger.info(arg2.getClass().getSimpleName()+"."+arg0.getName()+"begins."
    } else{  // 引数ありの場合
      StringBuilder builder = new StringBuilder(
          arg2.getClass().getSimpleName())
          .append('.').append(arg0.getName()).append(" begins with ");
      for (int i = 0; i < arg1.length; i++) {
        builder.append(arg1[i]==null ? "null" : builder.append(buildString(arg1[i])));
        if (i != arg1.length - 1)    builder.append(", ");
      }
      logger.info(builder.append('.').toString());
    }
  }

  /* メソッド戻り時のインターセプター */
  @Override
  public void afterReturning(Object arg0, Method arg1,
      Object[] arg2, Object arg3) {
    if (arg0 == null) { // 戻り値なしの場合
      logger.info(new StringBuilder(arg3.getClass().getSimpleName())
          .append('.').append(arg1.getName()).append(" returns.").toString();
    } else { // 戻り値ありの場合
      StringBuilder builder = new StringBuilder(
          arg3.getClass().getSimpleName()).append('.')
          .append(arg1.getName()).append(" returns with")
          .append(buildString(arg0));
      logger.info(builder.append('.').toString());
    }
  }

  /* 例外スロー時のインターセプター */
  @Override
  public void afterThrowing(Method m, Object[] args, 
      Object target, final Throwable ex) {
    StringBuilder builder = new StringBuilder(
        target.getClass().getSimpleName()).append('.').append(m.getName())
        .append(" throws ").append(ex.getClass().getSimpleName())
        .append(": ").append(ex.getMessage()).append(".");
    logger.warn(builder.toString());
  }

  private buildString(Object obj) {
    if(obj==null)  return "null";
    try{
      return objectMapper.writeValueAsString(obj);
    }catch(Throwable th) {
      return obj.toString();
    }
  }
}

 実はロガーそのものも深堀すると奥が深いので割愛して、ここではlogger.info()とかlogger.warn()と呼び出せば、ログファイルに書き出してくれるものとしておきましょう。

 まず、LogInterceptorクラスはMethodBeforeAdvice, AfterReturningAdvice, ThrowsAdviceというインタフェースを実装します。各インタフェースはbefore(), afterReturning(), afterThrowing()のメソッドが定義されていて、自分たちのプログラム上で、メソッド呼び出し直前にSpringがbefore()を呼び出してくれる、メソッド呼出し直後にSpringがafterReturning()を呼び出してくれる、もし呼び出したメソッドが例外をスローした場合はその例外をキャッチする直前にafterThrowing()を呼び出してくれるのです。

 例えば、次のような自前のインタフェースとクラスがあるとしましょう。

package com.dokkhwaymai;
public interface Calculator {
    abstract int add(String a, int b);
    ....
}

package com.dokkhwaymai;
public class CalculatorImpl implements Calculator {
  @Override
  public int add(String a, int b) {
    return Integer.parseInt(a).intValue() + b;
  }
  ....
}

 このクラスのメソッドadd()を呼び出すと、SpringがLogInterceptorクラスを使用して、次のようにログを出力してくれるのです(calculatorはCalculatorクラスのインスタンス)。
  (1) 正常時
    [プログラム] calculator.add(3, 2);
    [ログ] Calculator.add begins with 3, 2.
             Calculator.add returns with 5.
  (2) 例外発生時
    [プログラム] calculator.add("abc", 2);
    [ログ] Calculator.add begins with "abc", 2.
             Calculator.add throws NumberFormatException: For input string "abc".

 この例では引数も戻り値も数値型や文字列型ですが、たとえクラス型であってもJSON形式の文字列として、例えば
        [ログ] Calculator.complex returns with {"real":"3","image":"2"}.
のようにJSON形式で出力してくれます。

 今回はさらっと使用しましたが、LogInterceptorの各publicメソッドは「リフレクション」という、クラスそのものを表すクラスとかメソッドを表すクラスなど、プログラムより一段高いところの処理を行う機能を使用しています。リフレクションが使えるとプログラムの幅がぐっと広がりますので、それについてはまた別の機会に整理してみたいと思います。

 さて、LogInterceptorとCalculatorのプログラムを見て、一体何がエレガントなんだろうと思いませんでしたか? そして、上の(1)や(2)の[プログラム]のところではLogInterceptorを一切使用していないにもかかわらず、なぜSpringがLogInterceptorのbegin()・afterReturning()・afterThrowing()を呼び出してログ出力できたのだと思いますか? 次回は、この質問の答えを述べて、SpringがLogInterceptorの各メソッドを呼び出すための仕組み作りを整理してみたいと思います。


人気ブログランキング

『子育てに悩んでいる時点で正解なのよ』心がスッと軽くなる言葉12選

『子育てに悩んでいる時点で正解なのよ』心がスッと軽くなる言葉12選:

 今日は、お正月休み明け・3連休明けで仕事への足取りが重い方も多いのではないかと思います。そんな今回は、心が軽くなる言葉を取り上げたいと思います。元記事の12選から、自分のお気に入りの4つに厳選してお送りしたいと思います。

 まず1つ目は、人の陰口に悩む人へ向けたこの言葉。「陰口のいうのはレベルが低い人が高い人に向けて言うものなので、もし陰口を言われたならその時点で君の勝ち。何にも傷つく必要はない」 自分に内緒で悪口を言われていると感じたり、自分以外のみんなが結託しているように感じた時も、この言葉を思い出すといいかもしれません。

 次はタイトルにもなっている、子育てに悩むお母さん・お父さんの心を軽くしてくれる「子育てに悩んでいる時点で正解なのよ」という言葉。悩んでる時点で愛している証拠なのだから、子どもは大丈夫だよってことと、自分の子育てが正解だと思い込んでいる親のほうが危ないって言う二重の意味を持っています。「悩む」ことそのものが「正解」だと言う魔法の言葉。

 次は自分はコミュニケーションが下手・うまく人付き合いできないと落ち込んだ時に救われる、タレント有吉弘行氏の「人間、挨拶とお天気の話だけできればそれで十分だと思います」という言葉。何も人と深い話ができる必要なんてない、「今日はあったかいですね~」なんて笑っていれば、「いい人だ」って言われるので大丈夫です。

 最後は、学校でいじめられていたり職場の上司と合わなくて悩んでいたり、多くの我慢を強いられている環境にいる人が、精神的に追い詰められないための言葉。「自分が楽に生きられる場所を求めたからといって、後ろめたく思う必要はありませんよ。サボテンは水の中に生える必要はないし、蓮の花は空中では咲かない。シロクマがハワイより北極で生きるほうを選んだからといって、だれがシロクマを責めますか」 そういえば、昨年の大ヒットドラマ「逃げるは恥だが役に立つ」も、ハンガリーのことわざで、自分の得意分野で勝負しろとか自分の土俵で戦えと言った意味だそうです。不得意分野での戦いを強いられている人は、その不利な戦いから逃げてもいいんだよと逃げ道を準備してくれます。もっと言うなら、三国志演義で名宰相と名高いかの諸葛孔明は、戦において逃げることを恥とすら思っていなかった節があります。逃げることも戦略の1つで、目の前の戦いが不利だと感じたらすぐに逃げる、そして自軍が得意な地形や有利な環境で戦ったので、勝利を呼び込めることが多かったのでしょう。

 偉人の名言というほどのものではないかもしれませんが、ちょっと心が軽くなる言葉。頭では分かっていても、それをうまく言葉にしてもらったものに接した時、あぁそうなんだと腑に落ちることがあると思うんです。今回紹介した言葉も、誰かの心を少しでも軽くできると嬉しいですね。

にほんブログ村 ニュースブログ

2017年1月9日月曜日

【指紋ネット盗難】「ピースサインは危険!!」 3メートル離れて撮影でも読み取り可能  - 産経ニュース

【指紋ネット盗難】「ピースサインは危険!!」 3メートル離れて撮影でも読み取り可能  - 産経ニュース:

 今回はあなたの究極の認証情報が危険にさらされているという、国立情報学研究所の越前功教授による警鐘のニュース記事です。「究極の」という修飾をつけたのは、越前教授が警告を発する対象の認証情報が、パスワードや生年月日などではなく、完全にあなたをユニークに識別できるとされている生体情報である「指紋」だからです。

 自分が使用しているスマホのiPhoneのロック解除も、iPhone5sからTouchIDと称する指紋認証が使用されてします。他にも重要施設の入退室ゲートの認証や重要なコンピューターのログオン、銀行のATM、法務省の出入国管理システムJ-BISでも、個人認証に指紋が使用されています。生体認証は、虹彩や指静脈・掌形なども出て来てはいますが、やはりコストと技術の成熟度を考えると指紋は最もよく使用されているでしょう。

 しかし、最近のカメラの性能は素晴らしく、画素数も2千万とか3千万なんていう機種も出て来ています。越前教授によれば、従来は簡単に盗み取れないとされていた指紋も、例えば顔と手を一緒に撮影した写真をネットに掲示したりすると、一気に個人と指紋を特定されてしまう恐れがあるのだそうです。昔の技術レベルのデジカメであれば、写真から指紋まで再現しようとすれば、指先の拡大写真でもネットに載せない限りは大丈夫だったかもしれません。しかし、現代のデジタルカメラ・画像解析技術をもってすれば、3メートルの距離で撮影した画像からでも読み取ることができ、「自撮り」のピース写真をネットに載せでもすれば、いとも簡単に盗まれてしまうのです。

 パスワードを解析して芸能人や有名人のSNSを盗み見たり乗っ取ったりという事件が報道されることがありますが、そんな場合でも一時的に情報漏洩が起きてはしまうものの、パスワードを変更するなどすればその後は一安心できるかもしれません。しかし、一旦指紋情報が漏洩してしまうと、後から変更することができないのです。生体認証の強みとして喧伝されていた「時間によって特徴が変化しない情報」が、一旦漏洩してしまうと、大きな弱みになってしまうのです。指紋情報が盗まれたから指を取り替える、虹彩の情報が漏洩したから目玉を取り替える...というわけにはいかないのです。

 この手の被害のリスクは、画像が大量に出回る芸能人や有名人は特に高くなると思います。不自然に掌や目をカメラに見せないようにするわけにも行きませんし、本格的に狙われてしまうと危険かもしれません。もともと安全と言われていた生体認証技術が、テクノロジーの進展によって逆に危険なものになってしまうかもしれないなんて、なんとも皮肉なことですね。今のところ、一旦ネット上に出てしまった写真から生体情報を抽出されないようにする防御策はなさそうです。せめて、不用意に解像度の高い写真をネット上にアップしないようにするくらいしかないのかもしれません。


ITニュースブログランキング

「しっぱいしたらはげます」本来伝えたかったものと違う意味になってしまったモノ12選|@Heaaart - アットハート

「しっぱいしたらはげます」本来伝えたかったものと違う意味になってしまったモノ12選|@Heaaart - アットハート:

 今回はふふっと笑ってしまうような、書き間違いや読み間違いに関する元記事から。最初は書いた人の意図と違う捉え方をしてしまい、よく考えてからあぁそう書きたかったのかと気づいて可笑しくなることってありますよね。そんな元記事に紹介された中で、さらにお気に入りの厳選した4つの作品を。

 まず1つ目はタイトルにもなっているこちら。小学校に貼ってあったものだそうですが、平仮名って危険だなあと思うと同時に漢字って偉大だなあと思います。書き手は何も間違っていないのに、読み手が「!」となってしまいますよね。

 次はちょっとした書き間違い。絵が可愛らしいだけに、言葉の恐ろしさのコントラストがなんとも言えない雰囲気を醸し出していますよね。もちろん「HELLO」と書きたかったのでしょうが。

 一見何も間違っていないように見えますが、それは文脈から脳が適切に置き換えて認識してしまっているのです。脳の誤変換とでもいうべき案件です。だって、この文脈でまさかの長崎名物だとは思いもしませんから。

 そして最後は全く誰も悪くないこちら。「アウト」に続いてまさかの下ネタな訳あるはずないじゃないですか。あるはずないのに、そう見えてしまう。そして一度そう見えると、もうそうとしか見えなくなってしまう。走り書きにも注意が必要かもしれませんね。

 ちょっと軽めの面白ネタでした。共通するのは、書き手はまさかそんな風に読まれるなんて考えてもいないことでしょう。自分が書いたものをもう一度見直してみることの重要性を感じますよね。特にブログ記事なんて書いている場合には。

ブログランキング にほんブログ村

2017年1月8日日曜日

IoTで人が死ぬこともあるのではないか? | ReadWrite[日本版]

IoTで人が死ぬこともあるのではないか? | ReadWrite[日本版]:

 今回の話題は、この山ちゃんウェブログでも何度か取り上げているIoTのセキュリティ問題です。過去にも同じReadWriteの記事をもとに、IoTデバイスのハッキングに関する記事を書いたことがありました

 最初にセキュリティの専門家ブルース・シュナイアー氏による、フィクションストーリーを。あなたは病気で入院していて、生命維持装置につながれています。突然、心拍モニターがアラーム音を発し、あなたが心臓発作を起こしたことが通知されます。急いで手術室へ搬送しなければ、あなたの命は失われてしまいます。なぜかエレベータが動かず(非常用エレベータもやはり動かない!)、医療スタッフは階段を走ってあなたの元に駆けつけます。しかしあなたを搬送しようにも、エレベータが動かないことには、生命維持装置に繋がれたままのあなたを抱きかかえて手術室まで運ぶしかありません。スタッフの人力による必死の搬送にもかかわらず、時間は刻々と過ぎてしまい残念ながら手術室への途中であなたは息絶えます。

 このシュナイアー氏のフィクションストーリーの中であなたの生死を分けたのは、非常用も含めてエレベータが動かなかったことでした。実は、セキュリティが脆弱なIoTデバイスのために、病院の施設用ネットワークにハッカーが侵入してエレベータを止めてしまっていたのです。この悪夢のシナリオは、IoTのセキュリティが脆弱な場合には、現実に起こり得るのです。

 シュナイアー氏の「いまやあらゆるものがコンピュータだ」という言葉は、現代という時代を見事に言い当てています。例えば、車はコンピュータ付きの機械ではなく、4つの車輪とエンジンを持つコンピュータと理解すべきです。同じように、電気ポットはお湯を沸かせるコンピュータ、テレビは映像と音声を出力できるコンピュータ、エアコンは冷凍機や熱交換器・ファンなどを持つコンピューター、そしてエレベータはカゴや巻上げ機などを持つコンピュータ。我々の身の回りにある多くのモノの本質は、コンピュータなのです。つまり、IoT(Internet of Thngs)のT(Things)は「モノ」と訳されますが、実際のところはコンピュータなのです。これはものすごく当たり前のことで、いくらIoTと言ってもコンピュータを持たないものはインターネットに繋がることはできません。

 そしてその当たり前の前提を確認した後に、あなたはパソコンやスマホのOS更新・アプリのバージョンアップなどをどの程度の頻度で行なっているか考えてみてほしいのです。意識しないかもしれませんが、インターネットに繋いでいるだけで自動的に更新されたり、iTunesなどが最新アプリへの更新を促したりして、少なくとも数ヶ月に一度くらいは何らかの更新を行なっているのではないでしょうか。では、電気ポットやテレビ・エアコン・冷蔵庫・エレベータ・床暖房・お風呂・自動ドアなどは、どのくらいの頻度でソフトウェアの更新を行なっていますか。おそらく、ほとんどの方の回答は「やったことがない」ではないでしょうか。先に、身の回りのモノはほとんどコンピュータで、IoTにおいてインターネット接続されるのはコンピュータだと確認したにも関わらず、そのコンピュータのソフトは更新されていないのです。

 次に、あなたはパソコンやスマホをどのくらいの頻度で買い換えているか、考えてみてください。例えば、AppleはiPhoneの寿命は3年、MacBookの寿命は4年と発表していますが、長くとも10年以内くらいで買い換えるのではないでしょうか。では同じように、テレビ・エアコン・冷蔵庫・エレベータ・床暖房・お風呂・自動ドアなど、どのくらいの頻度で買い換えるでしょう。テレビなど買い換え周期がパソコンやスマホと同程度のものもありますが、冷蔵庫や床暖房・お風呂などはそうそう買い換えるものではない気がします。故障でもしないかいり、下手したら20年とか30年とか買い換えないかもしれません。何が言いたいかというと、モノを買い換えると自動的にその時点の最新ソフトが入ったコンピュータに置き換えられますが、身の回りのコンピュータの中には買い換えスパンが非常に長いものも含まれているということです。

 つまり、IoTでインターネットにつながるコンピュータの多くは、ほとんどソフト更新が行なわれないということになるのです。従来はそういうコンピュータはインターネットに繋がらないために、物理的にハッキングの脅威から隔離されていましたが、IoTではハッカーがインターネット経由でたどり着けるところに繋がるのです。一方、インターネットやITの世界はどんどん技術が発展し、ハッカーによるハッキング技術も驚異的なスピードで向上します。ある時点で有効だったセキュリティもすぐに陳腐化してしまい、脆弱なセキュリティホールになってしまいます。そうすると、冒頭のストーリーのようなことが現実に起きてしまうのです。これはIoTの仕組みそのものが持つ問題点で、メーカーがしっかりセキュリティを考慮した製品を作ればいいという単純なことではないと思います。便利さと危険性は表裏一体、本当にハッキングされたら命に関わるとか社会的影響が大きすぎるようなものは、ソフト更新の仕組みと運用をきちんと作り込むか、インターネットに直接は繋がないなどを考えないといけないと思うのです。


にほんブログ村 IT技術ブログ

2017年1月7日土曜日

子育て中のママに読んでほしい!絵本『ママのスマホになりたい』が考えさせられる|@Heaaart - アットハート

子育て中のママに読んでほしい!絵本『ママのスマホになりたい』が考えさせられる|@Heaaart - アットハート:

 今回はスマホとの付き合い方を考えさせられる絵本「ママのスマホになりたい」の紹介記事を取り上げさせていただきます。この絵本は昨年WAVE出版社から発売された、「ママがおばけになっちゃった!」シリーズで有名なのぶみ氏の作品です。

 ところで、1日にどれくらいスマホを触っているでしょうか。自分の場合、朝の通勤は電車で座ることができるので、ノートパソコンを開いてこの山ちゃんウェブログを更新していますが、帰りの電車は立っているので、スマホでネタ探しをしています。デバイスとしてのスマホは中毒というほどは使っていませんが、パソコンと合わせるとそれなりに長い時間電子機器を触っている気がします。

 話を絵本に戻しますと、実はこの絵本はシンガポールのある小学生が書いた作文が元になっているのだそうです。「親のことについて作文を書いてきなさい」という宿題で書いたのが「スマホになりたい」というタイトルだったのだとか。

 絵本の主人公「かんたろう」のママは、いつもテレビを見ていて、CMになるとスマホを見て、またテレビが始まるとテレビを見ます。たまに赤ちゃんが泣いた時は赤ちゃんを見ますが、かんたろうのことはいつまでも見てはくれないのです。

 かんたろうは、ママを独り占めしたくて部屋の片隅にダンボールで「スマホ」「テレビ」「赤ちゃん」が入れない、「かんたろうとママだけの国」を作りました。ママはスマホを置いてテレビを消して、この国に入ってきてくれました。「ママね、かんたろうが思ってるより、ずーっとかんたろうのことが好きなのよ」 だけど、かんたろうはこの国を作った本当の理由をママに言えなかったのでした。

 翌日、幼稚園で「大人になったら何になりたい?」と聞かれて、かんたろうは「ママが スマホばっかり見てるから、僕はスマホになりたい」と答えます。でもその後かんたろうが涙を流しながら話した言葉に本音が出ます。「でもね、ホントのこというと...僕のまんまでママに見てほしい」「ママが見てくれないと、 僕はいなくてもいいような気持ちになっちゃうよ...」 ちょうど幼稚園にお迎えに来たママは、かんたろうの本心に接したのでした。

 子育てに頑張っているママ・パパがたくさんいることでしょう。子供と一緒にいるとまとまって休息をとることも難しいですし、場合によっては夜中でさえも子供の夜泣きに付き合わされるかもしれません。自分の時間なんか、なかなか取れないのが現状でしょう。心身ともに疲れてしまう前にスマホで息抜きやリフレッシュするのは、疲れやストレスを溜めないために大切なことです。上手に付き合えば、持続可能(サステナブル)な子育てに一役買うことでしょう。ただ、何事も行き過ぎは良くありません。子供はこの一瞬一瞬も、いろいろなことを考えどんどん成長しています。よく見ていないと、子供が何を考えているのか・何を感じているのか・何を頑張っているのか、気づくことができないかもしれません。永遠に続くかに思える子育ても、人生の中で考えるとほんのひと時です。その貴重なひと時を、スマホよりも可愛い我が子と向き合う時間に充てられるといいなと思います。


にほんブログ村 ニュースブログ

2017年1月6日金曜日

初詣「ベビーカー自粛」要請で大騒ぎ 「差別」批判へ寺側の意外な言い分 : J-CASTニュース

初詣「ベビーカー自粛」要請で大騒ぎ 「差別」批判へ寺側の意外な言い分 : J-CASTニュース:

 今回は新年のイベント・初詣に関するこちらのニュース記事を取り上げさせて頂きます。ベビーカーを押して初詣に参拝することの是非について、新年早々ネット上で議論が広がったのだそうです。自分は年末年始は、帰省先の実家からさらに旅行に出かけて新年を迎えるのがかれこれ20年くらい我が家の定番になっています。子供たちが生まれてからは初詣よりも旅先にある遊園地で遊ぶことが多いので、こんな議論が沸き起こっているなんて知りませんでした。

 ことの発端は、東京板橋区の乗蓮寺が「ベビーカーご利用自粛のお願い」の看板を出し、それを見た乙武洋匡氏が「何の落ち度もない単に小さい子供を連れたママさんが初詣に来て、これを見て嫌な気持ちになると想像できないだろうか。なら松葉杖の人も、車椅子の人も足の悪い高齢者も、視覚障害者も全部遠慮しろと?」とツイートしたこと。ネット上ではたちまちのうちに賛否両論沸き起こり、東京都議会の音喜多駿議員が「少子化の最大の原因は、わが国が『子どもを産めば産むほど不自由になる社会』であることだと考えています」とブログで訴えるなど、ネット上で議論が沸き起こったのだとか。

 もちろん差別的な発想で赤ちゃん連れの家族の参拝を拒むなら、それは非難されても最もでしょうが、ネット上の議論が賛否分かれたように、この元記事のニュースをよく読んでみると、寺側の言い分ももっともだということがわかります。というのも乗蓮寺は数年前までは、専用通路を確保して係員をつけ安全を確保するなど、むしろベビーカーを押す参拝客によく配慮が行き届いた寺だったのです。ところが、この配慮・親切心が仇となり、ベビーカーが優遇される寺として知れ渡ったために、10歳を超えるような子供をベビーカーに乗せてそれに何人もの大人がつき、混雑時は1時間も待つ行列を尻目に専用通路を行く参拝客まで出てきたのだそうです。そしてとうとう、2015年そんな無神経な参拝客のベビーカーにつまづいたお年寄りが怪我をしてしまう事件が発生し、警察からの要請もあって「ベビーカーご利用自粛のお願い」の看板につながったのです。

 この寺側の事情を考えると、寺側の対応が障害者やお年寄りの排除へつながる、とか、これこそ少子化の原因だ、なんていう批判は的を射ていないことに気づかされます。問題の本質をあえて言うなら、それは日本社会が「誤った平等主義」に陥っているからと言えるのはないでしょうか。平等主義に「誤った」という言葉をつけたのは、その平等が正義ではない、あるいは本当の意味での「平等」ではないからです。もともと寺側がベビーカーを押す人は行列に並ばず直通通路を行けるようにした優遇処置を「ずるい」と思った人は、この「誤った」平等主義に陥っていると考えてもよいでしょう。

 このことは、以前にも掲載したことのあるイラスト↓が有名です。一見、同じ高さの台の上に乗せてあげる左側のイラストが平等のように見えますが、自分は「正義」あるいは「本当の平等」とは、右側のイラストであるべきだと思っています。統計を取ったわけではありませんが、この考え方は欧米の人に多い気がします。一方で左側こそあるべき平等で、右側のイラストを「ずるい」とか「不平等」だと感じる人は、日本人に多い気がするのです。「背が低ければ高い箱に乗せてもらえる」は「ベビーカーを押してれば直通通路を行かせてもらえる」に通じ、それを「ずるい」とか「不平等」と感じ、それなら自分もその恩恵を受ける立場になりたいという考え方。この考え方が、例えば収入が少ない人が税金を減免されたりすることを「ずるい」とか「羨ましい」と感じたり、不正をしてでも生活保護を受給しようとしたり、そういう日本人独特のマインドのような気がするのです。


 何でも欧米のやり方が良いわけでは無論ありませんが、こと「平等」というものに関しては、歴史的にも彼らの方が長く "こなれて" いるような気がします。日本社会が「誤った平等主義」ではなく、「正義」あるいは「真の平等主義」に成熟していれば、ベビーカーを押す人が直通通路を行くことが平等で正義のあるべき姿だという考え方になり、それを「ずるい」とか「羨ましい」と感じて不正を働く参拝客がなくなり、寺側の配慮がしっかりベビーカーを押す人や障害者・お年寄りに伝わったはずだと思います。ポイントは、日本社会が「誤った平等主義」に陥っているので、「真の平等主義」に成熟する必要がある、ということだと思うのです。


にほんブログ村 ニュースブログ

2017年1月5日木曜日

ニュース解説 - 2017年はAIとIoT、xTechが産業変革、ネットの脅威は攻撃範囲を拡大:ITpro

ニュース解説 - 2017年はAIとIoT、xTechが産業変革、ネットの脅威は攻撃範囲を拡大:ITpro:

 今回はまだまだお正月気分で、2017年の技術トレンドに関するニュースを取り上げさせて頂こうと思います。実は2日にも同じような話題を取り上げたのですが、ニュースソースを変えても同じような予想なのかを検証するためにも、今回は日経コンピュータの高橋健太郎氏・岡田 薫氏・玉置亮太氏・井上英明氏による元記事をベースにさせて頂こうと思います。

 元記事では、2017年の技術トレンドを人工知能(AI)とIoT(Internet of Things)とみているようです。いずれもこの山ちゃんウェブログで何度となく取り上げさせて頂いた話題で、そういう意味ではこのウェブログも王道を外していなかったと胸をなでおろすところです。

 AIは、自動運転・医療・金融など、より高度な分野への応用が進むと見ています。昨年12月には米Googleから独立したWaymoと本田技研工業が自動運転の共同研究に舵を切ったり、今日もインターネット上の囲碁対戦サイトに突然現れ、有名プロ棋士たち相手に60勝0敗と圧倒した謎のプレイヤー「Master」が実はDeepMind社によるAlpha Goの改良版だったことを同社のCEOデミス・ハサビス氏がTwitter上で明かしたニュースが駆け巡るなど、今年も話題に事欠かない状況が続きそうです。

 IoTは、大きく2つのトレンドがあると見ます。その1つ目は注目の無線通信技術「LPWA(Low Power Wide Area)」です。その名の通りの低消費電力と長距離通信だけでなく、低コストという特徴まで合わせ持つ技術で、単三電池で5~10年稼働、1つの基地局で半径10km以上をカバー、チップ価格が5ドル以下というIoTのエッジデバイスのためにこそ存在すると言ってもいいような性能です。今年はいよいよ商用サービスが始まり、以下の元記事より転載させて頂いた表のLPWA3方式のうち、免許不要で電波が遠くまで届きやすい920MHz帯を使うLoRaWANがまずは普及の先頭を走りそうです。

 そしてIoTのトレンド2つ目は、IoT基盤(IoTプラットフォーム)と呼ばれる分野です。IoTというのは狭義にはインターネットにつながる多くのモノ(エッジデバイス)のことを指しますが、本当に我々にとってのメリットを享受するためには
(1)エッジデバイスで多量のデータを収集
(2)ネットワーク(無線を含む)でそれを転送
(3)ビッグデータとして蓄積
(4)AIなどによるデータ解析でナレッジを抽出
(5)ナレッジを元にリアル世界へフィードバック制御
という大きなサイクルを回す必要があります(このことは以前の記事でも議論しました)。そのためには、この広範囲の技術分野に横串を指すIoT基盤(IoTプラットフォーム)が重要になってきます。従来より、IT系サービスにおいてはプラットフォームを制するものはビジネスをも制してきました。今回のIoT基盤をどこが制するのかが今年の大きな注目点でしょう。産業IoT分野では、ゼネラル・エレクトリック(GE)の「Predix」、日立製作所の「Lumada」、ファナックの「FIELD system」などの名前が挙がっていますが、いずれが一歩先に行くのかウォッチしたいところです。

 AI・IoTに続いて注目が集まるのは、特定業界のビジネスモデルや業界慣習をITで変革する「xTech(クロステック)」です。金融分野のFinTechが最も有名ですが、データベースの分散管理技術「ブロックチェーン」を実用化する動きが加速しそうです。自分はこのキーテクノロジー「ブロックチェーン」の本質をまだ捉えられてので、今年はこの山ちゃんウェブログでもこの分野を掘り下げていければいいなと思います。xTech分野では、金融以外にも、食を中心に医療・農業・健康といった分野の連携が進みそうで、農業×ITの「アグリテック」、食×ITの「フードテック」といったキーワードも出てきています。

 2日の記事と合わせると今年の注目テクノロジーは、AIとIoTを中心に、VR/AR・ドローン・自動運転、そしてxTechといったところでしょうか。自分自身が電機メーカーの技術者の端くれのためか、このウェブログでテクノロジーの話をするときはAI・IoTを中心にしてきましたので、今年はこの傾向をそのまま保持しつつxTechへも議論を伸ばせるといいなと思います。

ITニュースブログランキング

2017年1月3日火曜日

解けたら合格!? 学習院初等科先生が算数オンチ編集者に出題「正2.5角形を描け」 | プレジデントオンライン | PRESIDENT Online

解けたら合格!? 学習院初等科先生が算数オンチ編集者に出題「正2.5角形を描け」 | プレジデントオンライン | PRESIDENT Online:

 今回はお正月に家族揃っているところで、親子で考えてみたい算数の難問。その問題とは「正2.5角形を描いてください」というものです。ちょと待って。そもそも三角形は辺が3つ、四角形は辺が4つ、五角形は辺が5つ... 1角形・2角形はないので、3以上の整数でないと多角形は存在しないはずじゃないですか。それを2.5角形なんて、辺の数が整数じゃない多角形なんてそもそも存在するんでしょうか。この元記事は、森下和海氏が学習院初等科の大澤隆之教頭先生に取材した記事ですが、大澤教頭によれば「『○角形の○は辺の数』というのは、見えない心の枠。枠を取り払うと思ってもみない創造ができる」とおっしゃっています。

 常識・枠・当たり前と思っていたこと...様々な表現で表されますが、人は無意識に思考に制約を設けてしまっているので、自由な思考ができなくなっています。そして歴史的な大発見や大発明をした偉人は、その枠組みを外して自由な思考ができた人でした。そして、そのためには「なぜ?」という問いかけが有効なんだと思います。なぜ「○角形の○は辺の数」なのか、それは単なる思い込みなんじゃないだろうか、その問いかけが思考の制約を外してくれるきっかけになるかもしれません。かのアインシュタインの名言「大切なのは、疑問を持ち続けることだ。神聖な好奇心を失ってはならない」も、未知なる領域への好奇心という解釈だけでなく、それまで当たり前だと思ってきたことも疑問を持って見直してみることが大切だというようにも解釈できるでしょう。そして大澤教頭によれば、「なぜ」という疑問で創造性を育むのには算数や数学というのがぴったりだと述べられています。

 さて、そろそろ冒頭の問題の解答を。図は元記事から転載させていただきました。数学や算数は、わかっていることを図に表してみたり具体的な例を図にしてみると思考がガイドされやすいかもしれません。今回の問題だと、例えば図1のように正5角形を描いてみると、中に二等辺三角形が5つ入っています。二等辺三角形の頂角は「360°÷5」です。底角は、三角形の内角の和180°から頂角を引いて、2で割った(180°-360°÷5)÷2ということになります。正五角形の内角は底角2つ分なので、(180°-360°÷5)÷2×2となります。これを正n角形に拡張すれば「180°-360°÷n」ということになります。この一般則をよく知っている具体例に当てはめてみましょう。n=3にしてみれば確かに正三角形の内角60°、n=4だと正4角形(正方形)で内角90°と正しい値が得られます

 そしてこの一般則を正2.5角形にあてはめると、n=2.5を先の式に代入すれば、内角が180°-360°÷2.5=36°と求められます。図2のように内角36°で描いてみると、あっという間に隣りの辺同志が交差してしまいます。このあたりが本当の正多角形ではない「拡張版」正多角形の所以でしょう。そのまま構わずに書き続けると...出来上がった図形は...
こんな図形です!五芒星と呼ばれる図形が現れました。なんと、正2.5角形とはこんな五芒星のことだったのです。

 大澤教頭によれば、この世にはこのような計算によって導かれた発見がたくさんあるのだそうです。たとえば、冥王星は計算上この位置にあるはずだと考えられ、そこを探して見つかったのだとか。昨年ニュースになった、日本人が発見した新元素・ニホニウムも同様で、計算にもとづいて実験を繰り返して合成に成功したのだそうです。常識・枠・当たり前と思っていたこと...そういうものを取り外して自由な発想ができるようになるために、親子で算数や数学の問題を解いてみるのもいいかもしれませんね。


ブログランキング にほんブログ村

2017年1月2日月曜日

シリコンバレーVCが予想する2017テクノロジートレンド

シリコンバレーVCが予想する2017テクノロジートレンド:

 明けましておめでとうございます。この山ちゃんウェブログ新年一発目は、2017年のテクノロジートレンドに関する話題です。元記事は、日刊工業新聞電子版「デジタル編集部から」に掲載されたFenox Venture Capitalのアニス・ウッザマン氏による記事からさらに5件に絞ってみました。

(1)IoTとスマートホーム
 1つ目は、昨年この山ちゃんウェブログでもよく取り上げさせて頂いたIoT・スマートホームが、2017年にはより浸透してくるだろうという予想です。IoTが語られるとき、必ずスマート「ホーム」を題材にして生活がこんなに便利になるんですという言い方がされますが、現実的には「ホーム」よりも「ファクトリー」や「ビル」「シティ」など産業系のシステムが先行します。

 ただ実際には、インターネット接続されたIoTエッジデバイスのセキュリティに関して棚上げされたままです。良心的なメーカーは、少なくとも産業系IoTデバイスは直接インターネット接続しない「エアギャップ」という概念のもとに間接的な接続を行なってくるでしょう。昨年、直接インターネット接続されたIoTデバイスがハッキングされる事件が散見されましたが、被害が大きくなる寸前のところで食い止められることがほとんどでした。個人的には、今年も直接ネット接続されるIoTデバイスが多くなり、ハッキングによる大きな損害が発生してIoTに急ブレーキがかかりやしないかと心配しているところです。

(2)VR・AR
 昨年、オキュラス(フェイスブック傘下)がヘッドマウントディスプレー「オキュラス・リフト」をリリースしたり「Pokemon Go」が世界的にヒットしたりするなど、VR/AR関連がアツくなっています。今年はそんなVR/ARが一気にブレイクしそうです。

 ウッザマン氏の予想では、ARヘッドセットの技術力ではメタ(Meta)が注目だそうです。ネクストVR(NextVR)はスポーツスタジアムやコンサート会場などに実際にいるかのように楽しめるソリューション、リープ・モーション(Leap Motion)は仮想空間で実際にモノに触れる技術でオンラインストアのショッピング体験を大きく変える可能性がありそうです。

(3)人工知能(AI)
 昨年はDeepMind社(Google傘下)のAlphaGoなど、AIの発展が一般にも広く知れ渡った1年でした。AIの知能が人類の知能の総和を超える技術的特異点(シンギュラリティ)や、AIによって "頭がいい" とされる人の仕事がAIに奪われるかもしれないという話題も、この山ちゃんウェブログで何度か取り上げました。

 AIの潮流は、まず2017年は大きく2通りに分かれるのではないかと思います。1つ目はパーソナルアシスタント。Appleの「Siri」が一番手かという印象がありましたが、実は業界のスタンダードを作ったのは実はAmazonの「Alexa」なんだそうです。昨年末に米国でリリースされたGoogleの「Google Home」も今年は注目が集まりそうです。2つ目の潮流は、IoTによって大量に収集されたビッグデータの分析だと思います。パーソナルアシスタントほどの派手さはないものの、ビジネスのあらゆるシーンにAIによる自動分析が入ってくるのではないかと思います。

(4)自動運転
 4つ目はAIと一分野という言い方もできるかもしれませんが、市場の大きさを考えると独立項目にしたい「自動運転」です。この分野だと、テスラ・モーターズとウーバーが有名どころでしょうか。Googleも自動運転の先頭集団で、新会社Waymoへ研究開発が引き継がれています。もちろんこのままでは自動車の未来をIT企業に総取りされてしまうという危機感から、GMやトヨタ・ホンダなども必死で追いかけているという状況に見えます。

 自動運転はその技術レベルが、ドライバーが100%運転を行うレベル0から、完全な自動運転であるレベル4まで定義されていますが、現在実験中の各種自動運転システムはレベル4に達していると言われ、今年中に自動運転車によるライドシェアリングサービスがサービスインされる可能性もあると思います。

(5)ドローン
 昨年くらいから普通のニュースの中でもよく聞くようになった「ドローン」。すでに商品の配送向けにAmazonやアリババが試験的な導入を始めています。スポーツ中継などで迫力ある映像を撮影するためにドローンが利用されるケースも増えてきています。さらにAIを組み込んで、ドローンが自律的に飛行プランを立てながら障害物を避けて飛ぶことができるようにもなってきているので、セキュリティー面でも活用されるケースが増えてきそうです。

 全体的に2017年は新しい方向性が出てくるというより、昨年までの方向性がより顕著になり進展するという予想です。斬新なトピックというわけではありませんが、着実に進化していくという1年になりそうです。この山ちゃんウェブログでも昨年同様テクノロジーに関する話題も多く取り上げていきたいと思います。今年もどうぞよろしくお願いいたします。

ITニュースブログランキング