2017年3月27日月曜日

会社の命令より、自分の意思を優先させよ | DHBR編集長ブログ|DIAMOND ハーバード・ビジネス・レビュー

会社の命令より、自分の意思を優先させよ | DHBR編集長ブログ|DIAMOND ハーバード・ビジネス・レビュー:

 今回はハーバード・ビジネス・レビュー編集長・岩佐文夫氏の記事を元に、「辞令」と社員の働き方に関して考えてみようと思います。新年度を目前にしたこの時期、来期からの体制や異動が発表される会社も多いと思います。自分の会社も少し前にこの手の体制発表が社内のサイトに発表されました。これまで自分がいた部は来年度からなくなってしまい、自分も新たな部署に異動になりました。

 岩佐氏の元記事では、会社の命令だからと言って、異動による急な引っ越しや自分の望まない仕事も受け入れるというのは健全ではないと言われています。確かに、古き良き日本の会社では「この度○○部への異動を拝命し...」などと言って、会社からの異動の命令をありがたく受けてそれに従うというのが一般的でしたが、イマドキの時代は会社からの一方的な命令に嫌々ながら従う時代でもないということでしょう。会社の命令に従って、住むところも変えやる仕事も変えて、それでうまくいかなかったとき、それは「会社が悪い」と考えてしまいがちです。それはそうですよね。自分が住みたい街でもない街に強制的に住まわされ、やりたい仕事でもない仕事を会社からの命令という一点だけで嫌々やらされ、それで仕事の成果が上がらないからと言って、自分の頑張りが足らないとは考えたくないですよね。やはり、自分の適性を会社は見抜けていないんだとか、自分に適した仕事を割り当てないからこういうことになるんだと、会社や上司に責任をなすりつけてしまいがちで、会社にとっても社員にとっても不幸なことです。

 「辞令」とか「社命」というのはやはり強制力を伴うものなので、社員のモチベーションを著しく落としてしまう危険性があります。最近の会社では、そのリスクを考えキャリア面談などと言って来期以降の体制や本人の人事に関して上長と話をする機会を設ける会社も多くなっています。しかしひねくれた見方かもしれませんが、本人の希望を人事に反映させましょうというのは建前だけで、実際のところは形だけでも本人の希望を聞く姿勢を見せて、仮に望まない人事異動があったとしても意見を聞いてもらえたという満足感を植え付けるためでしょう。それが露骨に出てしまうと、結局のところ社員のモチベーションは下がってしまいます。

 たとえ望まぬ人事だったとしてもモチベーションを下げないために、自分の場合はその手の面談では一段階上のマネージャーとして自分という戦力を見たときにどう使って欲しいかという話をするようにしています。ちょうどタレントとマネージャーを一人二役で演じるつもりで、自分というタレントをどんな番組や映画にどう使ってもらうのが一番能力を発揮できるかを、マネージャーとしての自分がアピールします。会社全体の最適化のためや、部署や事業体制の今後のあり方の中で自分という駒をどう使うのが組織として理想的か、マネージャー目線で語るようにします。そして、本当の意味で本人の意見を受け入れてもらえるためには、役職という意味ではなく「実力」におけるポジションを得ておく必要があります。昔、音楽プロデューサーの小室哲哉氏が何かの雑誌で、レコード会社でどんなポジションにいるかというのは、リリースしたレコードのプロモーションにどれだけ力を入れてもらえるかという点でとても重要だということを話しておられました。どんなにいい音楽を作っても、レコード会社での地位を得ていないと売れない。逆にポジションを得れば、ミリオンヒットを手助けしてもらえプロデュース業や作曲業など幅広い活動が可能になる。これは、会社組織でも同じことなんだと思います。社内にポジションを得ていれば、実質的に本人の思いを会社の意思に乗せて実現することができるということなんだと思います。

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ニュースブログ

2017年3月25日土曜日

最新技術 一刀両断 - シンギュラリティへAIが抱える本質的な課題:ITpro

最新技術 一刀両断 - シンギュラリティへAIが抱える本質的な課題:ITpro:

 今回は、日経NETWORKの北郷達郎氏の記事を元に、人工知能(AI)時代に人間に求められる能力について。これまで、山ちゃんウェブログでもAIやシンギュラリティは何度となく取り上げてきて、2045年ごろAの知能が人類の知能の総和を上回り(シンギュラリティ=技術的特異点)、人間の仕事はことごとくAIに奪われるという文脈の記事を何度か書いてきました。

 しかし、北郷氏はAI万能論にはかなり懐疑的です。そもそも「ノーフリーランチ定理」というのがあって、特定のモデルをあらゆる問題に適用すると、結局平均的な能力しか発揮できないというのです。現在流行りの深層学習(ディープラーニング)も万能ではないということを言われています。プログラムの世界ではよく「銀の弾丸」という言葉があって、全ての問題に通用する万能な解決策などは存在しないという文脈で「銀の弾丸などない」と否定的に使用されます。実際、今回のAIブームの火付け役となった米Deep Mind社のAlpha Goも、囲碁に勝つことに特化されたAIでした。残念なことに、何でもできる「汎用」AIはまだ存在しません。

 つまり、解くべき対象に応じて適切なモデルを人間が定義しないと、いかにディープラーニングといっても効果を発揮できません。北郷氏が「シンギュラリティ」の議論に懐疑的なのはそこで、人間がモデルを定義しないとうまく動作しないものが人間を超えることなどありえないだろうと言うのです。自分も、ディープラーニングほどではありませんが、その元となるニューラルネットワークのプログラムを作ってみました。学習率や活性化関数・隠れ層のニューロン数など「『メタ』パラメータ」とでも呼ぶべき、人間が「えいやっ」と決めるパラメータが数多くあります。メタパラメータの決め方次第で精度が全然違ったり、適切でないメタパラメータを使うと計算が発散してしまうことすらあります。その代わりに、メタパラメータがピタッと「ハマった」時は抜群の能力を発揮します。

 しかし、バリエーション数において囲碁は将棋より1桁、チェスより2桁多く、コンピュータが名人に勝てるのは10年やそこらじゃ無理だろうと言われていましたが、ディープラーニングというブレークスルーが生まれ、囲碁のチャンピオンを次々と破っています。現在、メタパラメータのうまい決め方や、ちょっと違った方面から解決をはかろうという「強化学習」なんていう手法もものすごい勢いで研究されています。従来のニューラルネットワークはネットワークが出した答えと正解の間の誤差を小さくしていく方向にネットワークの重み(パラメータ)を調整していく手法でしたが、強化学習はそうではなく、いい行動には「報酬」を与え報酬を最大化するよう学習していくモデルです。わかりやすく例えると、イルカのショーや飼い犬のしつけのようなものと言えるかもしれません。見事にジャンプしたり、人間が手をくるくる回してイルカもくるくると回ったら餌のご褒美をあげる。犬に「お手!」といって手を差し出した時に犬が手を重ねてきたら餌のご褒美をあげる。そうやって、こういう時はこうすればご褒美がもらえるということを学習していくのです。

 ここで言いたいことは、強化学習が全ての問題を解決できるということではなく、従来「AI冬の時代」と呼ばれた時代、ニューラルネットワークの階層を深くすると学習が進まなくなる「誤差消失問題」というのがあってニューラルネットワークは使い物にならないと言われてきました。しかし、積層デノイジングオートエンコーダやディープビリーフネットなどのブレークスルーでディープラーニングが可能になり、一気にAI全盛の時代を迎えました。対象ごとに人間がモデルを与えたりメタデータを決めなければならず「AIが独り立ちしない」という問題も、もう一段・二段のブレークスルーがあれば解決できるかもしれないということなのです。

 北郷氏の記事の中でもっと気になったのは、モデリングやメタデータの与え方はやがてAIが自分のものにして行ったとしても、最後まで人間の手に委ねられそうなことがあるということなのです。シンギュラリティの時代、AIの知能が人類の知能の総和を超えるとき、それでも人間にしかできないこととは...「解くべき課題の発見」だというのです。2045年、コンピューターとAIは与えられた課題を人間よりも早く正確に解決できるようになるでしょう。しかし、AIが解決するべき「課題」は人間が見つけてこなければならない。確かにこのご意見は一理ある、いやむしろその通りだと思います。技術的ブレークスルーによってAIが自身を強化できるようになると、加速度的にAIの能力は発展してあっという間に人間を超えると思います。それでも、その圧倒的な能力を何に振り向けるべきかというのは、やはり人間がコントロールする必要があります。

 人間に求められる能力は、これまでの教育の歴史や企業が求める人物像の変遷を見るとある程度推測できます。自分たちが子供の頃、というと30年も前の話ですが、受験戦争というのがあって、求められたのは「記憶力」が大きかったような気がします。和田秀樹氏の「数学は暗記だ」なんて本を読んで、とにかく知識を詰め込むことに勤しんだものです。2000年ごろから企業が「ソリューション」なんていう言い方をして、「課題解決能力」が求められるようになりました。例えば、計算は人間が頭を使わず電卓に任せるようになって、じゃあどんな計算をするかを考えるのが人間の役割になったように、今後はどんな課題を解決すればよいのか、つまり「課題発見力」が重視されるようになっていくのだろうと思います。


ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ITニュース

2017年3月23日木曜日

子持ち女性ほど「妊婦いじめ」がキツい矛盾 | 自衛隊員も学ぶ!メンタルチューニング | 東洋経済オンライン | 経済ニュースの新基準

子持ち女性ほど「妊婦いじめ」がキツい矛盾 | 自衛隊員も学ぶ!メンタルチューニング | 東洋経済オンライン | 経済ニュースの新基準:

 今回は、日本メンタルアップ支援機構代表理事・大野萌子氏による「マタハラ(マタニティハラスメント)」のメカニズムに関する話題です。マタハラといえば、子育てを奥さんに任せっきりのオジさんが無神経に子持ち女性に嫌味を言うことを想像しがちですが、実態はそうではないのだそうです。むしろ、自ら出産・子育ての大変さを経験した女性の方が辛辣な加害者になりがちなのだそうです。

 出産・子育ての大変さを身をもって理解しているからこそ、理解して気遣いができそうに思いますが、そこが落とし穴で、自分の経験に基づいて言える強みが悪い方向に働きがちなのです。例えば、つわりで気分が悪い妊婦に対して「私は、そのぐらいで休んだりしなかった」「妊娠は病気じゃない」とか、子供の病気や行事で休みを取ろうとする母親に対して「そんなことで仕事続けられるの?」「ちょっと過保護じゃない?」といった具合です。

 私たちは、近い立場の人や共通点の多い人に対してこそ、些細なことで気持ちが揺れる傾向があります。大野氏の言われる例だと、有名な経営者が何億円も稼いだ話を聞いても「すごいな」程度なのに、たいした実力もない会社の同期が自分を差し置いて昇進した日には夜も眠れないくらい嫉妬するものです。トランプ米大統領がクリントン氏を破った先の大統領選でトランプ氏を支持した白人の貧しい階級の人々は、雲の上の大富豪であるトランプ氏を支持し、すぐ上のエリート階級を代弁するクリントン氏にはNOを突きつけました。他にも、もともと独身同士仲が良かったのに、相手が結婚して幸せに暮らしていると先を越されたようでムカつくとか。立場が違いすぎる人に対しては、違う点が多すぎるので逆に少ない共通点を見出そうとする力が働き、一方で立場が近い人に対しては共通点が多すぎてむしろ違いを探そうとする力が働くように思います。女性は男性に比べて調和を大切にすると言われていますので、逆に、少しの違いを敏感に感じ取って、仲間外れにしたりされたりということをしがちという側面もあるでしょう。

 十把一絡げに「女性活躍推進」と言うのではなく、働き方の多様化とそれに合わせた評価制度(収入面でも役職面でも)を細かく体系化することが必要でしょう。つまり、立場が近いために「違い」に目が行きがちなのに、評価方法が「一緒くた」だと不満が溜まりやすいからです。結婚・出産・育児の事情もそれぞれ違いますし、仕事に対する考え方も違います。それなのに評価が均一的だと、働き方の違いばかりが際立って「同じ給料なのに、私ばかりに負担がかかっている」というようになります。それならばむしろ「働き方の違い」に対応するように「評価の違い」を設けるようにすれば、「私にばかり負担がかかっているけど、その分給料も役職も上だから」というようになるでしょう。

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ニュースブログ

2017年3月21日火曜日

2040年頃、今の仕事の8割くらいが消滅する:日経ビジネスオンライン

2040年頃、今の仕事の8割くらいが消滅する:日経ビジネスオンライン:

 今回の記事は、前回の続き。川島蓉子氏が孫泰蔵氏にインタビューした記事なのですが、前回の主題がIoT(Internet of Things)だったのに対して、今回は「シンギュラリティ」。シンギュラリティは技術的特異点などと訳され、2045年くらいに人工知能(AI)の知能が全人類の知能の総和を上回ると言われています。そして、その時は人間の仕事のほとんどをAIをはじめとするコンピューターや機械が奪ってしまうと言われています。この山ちゃんウェブログでもシンギュラリティは何度となく取り上げているテーマで、やはり悲観的な見方でとらえてきました。

 孫氏の考えるターニングポイントは、自分が考える2045年よりさらに早い2040年。現在の仕事の8割くらいは無くなっているだろうと。その頃は街は失業者で溢れかえってしまうという予想は、あながち絵空事ではありません。もちろん、AIやコンピューターに取って代わられた人が失業者となってしまうのですが、孫氏は失業には実は2種類あると言っています。1つ目は「構造的失業」で、市場や産業そのものが消滅したりして労働者が不要になって失業してしまうこと。実はシンギュラリティで発生する大量の失業はこのタイプではなく、もう一つの「摩擦的失業」です。つまり、人間が行なっていた仕事をAIやコンピューターがこなすようになると、人間に求められる仕事は従来とは違う仕事になるにもかかわらず、人は簡単には新しい仕事に対応できない。結果的に、労働者の需要はあるのに、失業者がその供給源になれないのです。

 街に失業者が溢れる2040年、街はスラムと化す可能性があります。食べるのに困った人々は、あてもなく街に出てきますがそこに職はありません。収入がない上に住む場所もない。そういう貧しい人々が、何となく裏通りみたいなところに溜まってしまいます。そして、やがて非合法な仕事に手を染めるようになります。そうすると、一般の人たちは怖くて裏通りには近寄れなくなり、ますますスラム化が進みます。もちろんここで描いたストーリーは架空のお話ですが、2040年頃の日本の大都市に起きうるかもしれない話なのです。

 この山ちゃんウェブログでこれまで述べてきたのは、いわゆるブルーカラーと呼ばれる人々のような肉体労働を中心とする仕事(=Labour)は機械やロボットに取って代わられ、ホワイトカラーと呼ばれる人々の頭脳労働を中心とする仕事(=Work)はコンピューターとAIに取って代わられます。特に何度も述べてきたのは、従来は頭がいい人がその頭の良さゆえに高給を取っていた仕事こそ軒並みAIに奪われるということです。これまでの延長線上で想像してしまうと、コンピューターやAIに仕事が奪われると言っても、医者・弁護士・裁判官・トレーダー・経営者といった頭がいい人が就く仕事は安泰じゃないかと思ってしまいます。しかし、そうではないのです。AIはむしろ、そういう頭が良い人の仕事をこそ奪って行きます。そして頭のいい人は大抵プライドが高いので、「人間に残される種類の仕事=AIのおこぼれに預かる仕事、または頭の良し悪しとは関係しない軸で評価されるような仕事」へなかなか対応できないのです。

 頭がいいと言われる人が就いていた仕事がAIに奪われてしまうと、彼らには一体どんな仕事があてがわれるのでしょうか。孫氏は、それまでの「やる仕事」から「つくる仕事」へシフトすると述べられています。例えば法律の仕事だったら、弁護士や裁判官・検事の仕事は軒並みAIに奪われますので、リーガルデザイナーやリーガルアーキテクトと呼ばれるような、法律や規制そのものをデザインするのが人間の仕事になるというわけです。つまり、AIやコンピューターがやる仕事を作ること=「メタ仕事(自分の造語ですが、普通の仕事(AIやコンピューターがこなす仕事)より一段上に位置する仕事)」こそが人間に残される最後の砦というわけです。

 自分は、シンギュラリティの時代に人間に残される仕事は、AIやコンピューター・機械などのおこぼれに預かる仕事(つまり、ソフトウェアや機械の保守メンテナンスなど)か、頭がいいかどうかとは別の軸で評価されるような仕事(例えば、芸術方面や心理カウンセラー・水商売のような心を癒す方面の仕事)の2種類ではないかと予想してきました。しかし孫氏は、人間に残される仕事は「メタ仕事」だと言われており、自分の予想よりもう少し楽観論にあると思います。しかし、自分の発想の中にはなかったメタ仕事は、頭がいい人が行う仕事ではありますが、相当高いレベルの頭のいい人しか行なえないような仕事でもあります。創造性も想像性も豊かな発想の持ち主で、ある意味直感的に未来を見通せるような、そんなハイレベルに頭のいい人にこそ行える種類の仕事ではないかと。そういう仕事も確かに人間には残されるでしょうが、自分としてはやはりそんな資質を持つ天才は一握りであって、大部分の秀才レベルの頭がいい人はむしろ仕事にあぶれるのではないかと心配なところです。

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ITニュース

2017年3月20日月曜日

やはり、IoTでおっかないことは起こるんですよ:日経ビジネスオンライン

やはり、IoTでおっかないことは起こるんですよ:日経ビジネスオンライン:

 今回は川島蓉子氏がMistletoe代表取締役社長兼CEO・孫泰蔵氏にインタビューした記事を元に、IoT(Internet of Things)を考えてみようと思います。この山ちゃんウェブログでも何度となく取り上げてきたテーマですが、東京大学在学中にYahoo! JAPANの立ち上げに参画するなど、先端テクノロジーに関わってこられた孫氏のご意見はどんなものでしょうか。

 日本において、情報革命と呼べる最初は1995年にインターネットが本格化したところから始まります。この当時大学生だった自分は、パソコン通信とかインターネットとかなんだかすごいよ世の中になりそうだという予感がしたことを覚えています。パソコンを触ることができないとこれからのに必要とされなくなるんじゃないかという危機感で、富士通のFMVシリーズのデスクトップパソコンを買った時期でした。ただ、この時期はダイヤルアップと言って電話回線とモデムを使った最高56kbpsという通信でしたので、ホームページに画像が含まれていると表示までとても時間がかかったので、ブロードバンド化と呼ばれた2002年まではインターネット黎明期という感じでした。2002年、自分は社会人になって少しした頃でしたが、この頃になってようやくインターネット上で動画が流せるようになり、世間ではWeb2.0と言われるようになりました。それまでYahooやライブドアなどポータルサイトと呼ばれるサイトからの一方的な情報の発信より、消費者同士・個人間の情報のやり取りが活性化した頃でした。次のターニングポイントは2007年。スティーブ・ジョブズ氏率いるAppleがiPhoneを発表した時です。それまでインターネットを使うとき必要なのはパソコンでしたが、この頃以降携帯型端末でインターネットにアクセスする現在主流のスタイルが確立されて行きました。インターネットが常に身につけた端末から繋がる身近なものになり、FacebookやTwitter・LINE・InstagramといったSNSサービスが広がりました。

 その「次の世界」と言われているのが、一昨年あたりから盛んに言われだしたIoT(Internet of Things)です。それまでのインターネットでは、接続された端末はパソコンであれスマホであれ、使っているのは人間という共通点がありましたが、IoTの世界ではモノが直接的にインターネットに繋がっていて向こう側に人間の存在を前提としない世界です。そんな世界では、孫氏はたとえば「プレディクティブアナリシス=予測分析」が進化するだろうと言われています。孫氏の率いるMistletoeが支援しているフィンランドのスタートアップで、街中にあるゴミ収集に関するプロジェクトを実例に挙げておられます。ゴミ箱にセンサーを付けインターネット接続されることにより、1つ1つのゴミ箱にどれくらいゴミが溜まっているかをインターネットを使って把握できるようになります。予定されているお祭りやイベントなど、ゴミが増えそうな条件も入力情報として使用します。気温や天気などでもゴミの量は変わりそうなので、それも条件に入れます。すると、イベント情報と気温・天気を入力条件として町中のゴミ箱のゴミの量を出力値とするグラフを描くことができると思います。このグラフを人工知能(AI)で解析することにより、例えば来週のイベントと天気予報からゴミの量を予測することができるというわけです。そうすると、ゴミ回収車に効率的な回収の道順を教えられ、回収車の数を減らせたりガソリン代を減らせたりするというわけです。

 IoTと言うとセンサーなどIoTデバイスとそれをインターネットにつなぐエッジデバイス、そして無線通信など要素技術にばかり注目が集まりがちですが、この山ちゃんウェブログでは、大量のセンサーから収集したビッグデータを人工知能(AI)で分析し得られたナレッジを元にリアル世界へフィードバックするまでの大きなループが本質だということを書いたことがありました。孫氏の出された「予測分析」というサービスは、この大きなループのことを言われていると思います。もちろんビジネスとして、IoTデバイスの開発を行なっている企業もあれば、エッジデバイスの開発を行っている企業も無線通信を提供する企業もあります。しかし「IoTって何なの?」という質問に対する答えが「全てのモノがインターネットにつながる」だとして、「それで何がウレシいの?」に対する答えは、孫氏の言われる「予測分析=未来が予測できること」やこの山ちゃんウェブログでいうところの大きなループと言えるかもしれません。

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ITニュース

2017年3月18日土曜日

[C#] log4netとDynamicJsonでAPI呼出しをログ出力する覚書き

 今回はまた元ネタなしのプログラム覚書きですが、とても再利用しやすいログ出力の話題です。以前にSpringを使うとログ出力がとてもエレガントかつスマートに実装できるという記事を書いたことがありますが、大掛かりなプログラムならいざ知らず、ちょっとしたツール程度ならSpringフレームワークを持ち出すのは仰々しいという気もしないでもありません。そこで、今回はC#でちょっとしたツールを作るときに便利に再利用できる、メソッド(API)呼出しログを出力するテクニックをご紹介しましょう。

 ログ出力にはlog4netというライブラリを使用し、オブジェクトをログに出すときに文字列するのはJSON形式で出すのが便利です。JSON形式に変換するのは、前の記事で紹介したDynamicJsonが便利です。

 さっそくプログラムコードを見てみましょう。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Codeplex.Data;
using log4net;
namespace Yamachan
{
 public static class API
 {
  // ロガー
  private static ILog logger =
    LogManager.GetLogger(System.Reflection.MethodBase
    .GetCurrentMethod().DeclaringType);
  // APIの実行をログ出力とともに行なうメソッド
  public static TResult Invoke<T1, TResult>(Func<T1, TResult> api, T1 arg1)
  {
   try
   {
    logger.Debug(timeStamp() + api.Method.Name
      + " begins with " + str(arg1) + ".");
    TResult result = api(arg1);  // API呼出し
    logger.Debug(timeStamp() + api.Method.Name
      + " ends with " + str(result) + ".");
                return result;
   }
   catch (Exception e)
   {
    logger.Warn(timeStamp() + api.Method.Name + " throws "
      + e.GetType().Name+" : "+e.Message, e);
    logger.Warn(e.StackTrace);
    throw e;
   }
  }
  public static TResult Invoke<T1, T2, TResult>(Func<T1, T2, TResult> api,
    T1 arg1, T2 arg2)
  {
   try
   {
    logger.Debug(timeStamp() + api.Method.Name
      + " begins with " + strDigest(arg1) + ", " + str(arg2) + ".");
    TResult result = api(arg1, arg2);
    logger.Debug(timeStamp() + api.Method.Name
      + " ends with " + str(result) + ".");
    return result;
   }
   catch (Exception e)
   {
    logger.Warn(timeStamp() + api.Method.Name + " throws " +
      e.GetType().Name + " : " + e.Message, e);
    logger.Warn(e.StackTrace);
    throw e;
   }
  }
  // ...以下同様に、引数が増えた場合のメソッドも準備する

  // プライベートメソッド
  private static string timeStamp()
  {
   return DateTime.Now.ToString("yyyy/MM/dd HH:mm:ss ");
  }
  private static string str(dynamic obj)
  {
   return DynamicJson.Serialize(obj);
  }
 }
}

 つまり、ログを出力するときはメソッドのラムダ式と引数を渡して、↓のように呼び出すことになります。以前示したSpringのインターセプタという仕組みを使ってログ出力する場合は、APIを使うユーザーは何も考えずちょうど↓の[旧]のようなコードを書けば、メソッド呼び出し時とリターン時に強制的にログが出力されましたが、今回の方法はAPIを使うユーザー側がAPIを呼び出すコードの書き方を変えなければならないのが今ひとつかもしれません。しかし、大規模システムで数多くのプログラマーが作る場合はSpringの強制的にログ出力されるのがエレガントですが、1人でちょっと作るようなツールの場合は大げさです。そんなとき、今回のような方法を使ってみるといいと思います。一度使ったAPIクラス(↑)は何度でも使いまわせますしね。

  [旧] var user = client.login(userId, password);
  [新] var user = API.Invoke(client.login, userId, password);

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ソフトウェア

2017年3月17日金曜日

[C#] DynamicJsonでJSON形式とオブジェクトを相互変換する覚書き

 今回はまた元ネタなしのプログラム覚書きですが、以前にJavaの場合にはJacksonというライブラリを使ってJavaオブジェクトとJSON形式の文字列を行ったり来たりできるという記事を書いたことがありました。最近プログラムを書いていて、JSONの便利さがハンパないと改めて感じているので、今回はそのC#版を紹介してみたいと思いまし。C#では、DynamicJsonというライブラリがとても便利に使えます。C#では、dynamic型という、リフレクションを簡単に書くための仕組みがあるので、DynamicJsonを使えば、JavaでJacksonを使うよりはるかにお手軽にC#オブジェクトとJSON文字列の行ったり来たりが実現できます。

 実際にプログラムのサンプルを見てみましょう。HTTPで要求するとJSON形式の文字列で応答を返してくれるような、そんなWebサービスを使うクライアントのサンプルです。ここでは、新規にデータを作成するCreate()とidを指定してデータを取得するFetch()のみ示していますが、検索や更新・削除といったメソッドも同じように作ることができます。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Web;
using Codeplex.Data;

namespace Yamachan
{
 static class WebServiceClient
 {
  // Webサービス要求先
  public string EndPoint { get; set; }
  // Webサービス呼び出し
  public static dynamic Create(string entityName, dynamic entity) 
  {
   var client = new WebClient();
   client.Encoding = Encoding.UTF8;
   var responseText = client.UploadString(EndPoint + "/"
     + entityName, "POST", DynamicJson.Serialize(entity)); // (1)
   return DynamicJson.Parse(responseText);  // (2)
  }
  public static dynamic Fetch(string entityName, dynamic id)
  {
   var client = new WebClient();
   client.Encoding = Encoding.UTF8;
   var responseText = client.DownloadString(EndPoint + "/"
     + entityName + "/" + id.ToString());
   return DynamicJson.Parse(responseText);  // (3)
  }
  ......以下同様
 }
}

 まず、Create()を見てみます。これはデータベースのテーブル名に相当するentityNameと新たに作成するレコードをentityとして引数にとって、サーバーへPOSTで新規作成の要求を出します。サーバーからは作成されたレコードの情報がJSON文字列で戻ってくるという前提です。何と言ってもこのメソッドのミソは、(1)で作成するべきレコードの情報をJSON文字列に変換しているところと、(2)で戻ってきたJSON文字列をdynamic型のオブジェクトに変換しているところです。どんな型のオブジェクトでも、DynamicJson.Serialize()とやればJSON文字列に変換してくれますし、逆にJSON文字列はDynamicJson.Parse()とやればオブジェクトに戻してくれるというのです。どうですか、とても強力だと思いませんか。JavaのJacksonライブラリーは、データの型(クラス)をとても意識しないといけませんでしたが、なんとDynamicJsonではほとんど型(クラス)は意識の下の方に沈んでしまっています。

 同じようにFetch()はidをURLにエンコードし、サーバーにGETでデータの要求を行います。やはり戻り値はJSON文字列であることを前提にしていますので、(3)でオブジェクトに戻しているというわけです。例えばこのFetch()を使うときは、次のようにあたかも普通のメソッド呼出しと同じように使うことがd家いるというわけです。戻り値がdynamic型なので、(4)のように戻り値オブジェクトのプロパティに簡単にアクセスできるというわけです。

  dynamic retValue = WebServiceClient.Fetch("user", 1);
  string name = retValue.Name;  // (4)
  string email = retValue.Email;   // (4)

いかがでしたか。JSONそしてDynamicJson、とても便利だと思いませんか。ただ一つ注意点は、dynamic型は裏ではリフレクションが使用されてますので、(4)の時にサーバーからの戻り値のJSON文字列にNameとかEmailというプロパティが入っていなければ、実行時エラーになるということです。つまり、サーバー側が急に戻り値のJSONオブジェクトにNameやEmailというプロパティを入れなくなったら、クライアント側は実行時エラーになってしまいます。これは、型(クラス)を意識しなくて良くなっている代償です。ただ一方で、サーバー側が新たにAddressというプロパティを追加したとしても、C#のクライアントはそれを意識する必要がありません。こちらは、型(クラス)を意識しなくて良くなっているメリットですね。

ブログランキングに参加しています。よろしければポチッとご協力をお願いします
にほんブログ村 ソフトウェア