ココロミにきみ

本と体とプログラミング

本 Graphic Recorder

今週のお題「読書の秋」

「Graphic Recorder」清水淳子さん著。

会議の記録を、絵やイラストと共に作っていくGraphic Recorderのススメ。

相手と話していることのイメージを共有するために、紙に意見を書き込んでいって、グルーピングして、時系列を矢印で書いて・・・みたいなことをやっていたら、それが本格的に技法として使われていることをこの本で知った。

正直、読んでも”体系”というより”紹介”という感じだが、始めるのにきっかけが欲しいという人には向いていると思う。それか、ある程度実践したあと、もう一度見ると整理されるのかもしれない。

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

Graphic Recorder ―議論を可視化するグラフィックレコーディングの教科書

 

実際、文字にイラストを添えたり、関係性を矢印や絵で描いた記録は、パッと見で理解できる。記憶を紙に任せられるので、現在進行形のポイントだけを頭の中に置くことができて、考えの整理がその場でとてもしやすい。だから、みんなが発言しやすくなるのはあると思う。

個人的には講演でも何でもメモを取る習慣が染み付いていて、記憶はすべてノートに任せて頭の中は考えることのみに使うというのが癖になっている。逆にメモを取らなかった時代は、どれだけ頭を考えることに使えてたのか不安・・・。

 * * *

しかし、Graphic Recordingが良い事づくめあるならば、何でいままで、このやり方はメジャーにならなかったんだろう。記録は新人がやるものって会社が多くて、そんな改革が生まれる余地がなかったんだろうか。それとも会議は議論する場じゃない所が多かったから不要だったとか。。。

スキャン書類の傾き・回転修正ロジック

同一の多量の書類のスキャンにおいて、縦横にズレたり、回転した場合に自動的に正しい位置に戻すためのロジックを実際に作ったら上手くいった(当たり前だ)。Pythonで実装したがコードは書かずロジックだけ書く。

 

仕事で、AIで同一書類の数字(さらには文字)を読み取る際に、スキャンデータの位置ズレが普通に発生し、読み取り時のノイズが発生するのを防ぐのが目的だった。

f:id:molingit:20171002113252j:plain

↑こんな感じに修正される。

 

* * * * * * * * * * * * * * * * * * * * 

 

早速修正のロジックだが、スキャン時のズレには「横ズレ・縦ズレ・回転ズレ」があり、たいがいは複合のズレになっている。縦・横ズレの修正のほうが簡単だが、実はこれを先にやると二度手間になるので、実際の手順は

1.回転ズレ修正

2.縦横ズレ修正

で行う。説明は縦横ズレから行う。

f:id:molingit:20171002113257j:plain

こんな感じで普通にスキャン画像はずれる。なので、書類の枠組みを変更できる場合は目立たない程度に+記号などを枠外りに作り、その座標のズレを読み取ることで位置を修正する。変更できなければ書類の枠線などを使用する(と、できるんじゃないかな)

f:id:molingit:20171002113320j:plain

Pythonではcv2で読み取ってnumpyで行列にして、3cm角くらいの大きさで画像を切り取り、その中の+記号の中心をその座標とした。中心を見つけるには、切り取った3cm角の画像を行列にした際に、各行列の値0−255の中である閾値を超えたものの行列の座標を合計し、その平均を取った(実使用ではノイズがのる可能性がある)。

そして、理想の+座標と、実際の+座標のズレを引き算して、その分だけ行列全体をズラせばいい。理屈は簡単だけど落とし穴もある。

理想の+座標が意外に決まらなかったりする。元データがあるなら、それをPDFやJPGにパソコン上で変換して読みこめばいいと思いきや、その理想座標はスキャンで一番上手くいったデータとは全然違った。。。

* * * * * * * * * * * * * * * * * * * * 

さて回転修正。こっちのほうが数学的にめんどい。

f:id:molingit:20171002113302j:plain

こーゆーズレはけっこう頻繁におこる。ただし回転が5度を超えるようなズレは滅多に起こらないというか、そんなものはもう一度スキャンしてもらうほうがいいので、想定は2、3度のズレまで。(大きなズレは修正するための、指標の+が「読み取り3cm角」から外れてしまうので対応不可)

f:id:molingit:20171002113312j:plain

最初に説明した縦横ズレの際の、+記号を読み取るところまで同じで、今度は図にあるように、2つの+の座標をベクトルにする。

例えばB5用紙で、+記号を「上・真ん中」につけて、

・理想データ「上=O、真ん中=A 」

・スキャンデータ「上=O、 真ん中=B」

とすると、

 理想のスキャン時のOAベクトル=(1700,0)

 実際のスキャン時のOBベクトル=(1723,23)

みたいな値になる。単位はよくわからない。でそのベクトルがなす角θをアークサインと外積で求めることができる。アークコサインはオススメしない。

f:id:molingit:20171002113307j:plain

で、求めたこのθはラジアン表示なので、度数に直してscipyで回転させる。どうもこの処理が大変らしいので(けっこう時間がかかる)θが0.1(0.05くらい?)以下だったら回転修正させないというのもありかもしれない。

数字のイメージとして0.1は小さいけど、画像の回転としてはけっこう大きいので、B5サイズなら人間の目からしても0.1度は完全に回転ズレとして認識されてしまう(から外野が云々・・・)。あとはAIで読み取るさいにノイズがどの程度のるかで、無視すべき回転角度を実際の使用のなかで変えていく必要がある。

 

* * * * * * * * * * * * * * * * * * * * 

 

このように実際には回転修正をして、その後、縦横ズレ修正を行うと、最初に示した理想の位置にスキャン画像が整列してけっこううれしい。

ただ、実際にここに書いてあるようなことをやる人はその前に、PDFをJPGに直すところでも悩む気がする。僕は悩んだというか、ライブラリのバージョン対応などで時間をとても取られた。

まぁこれで、AIによる数字認識につなげて自動読み取りが本格的に動かせる状態になるので、ハッピーではある。みなさまの成功を祈りつつ。

 

 

本 涙の理由

今週のお題「読書の秋」

「涙の理由」茂木健一郎さんと重松清さん対談。

「泣けた」と「泣ける」の違いが重松さんの問題意識の始まりだった。「泣けた」は、” 自分のオリジナルな経験としての涙 ” の可能性があるが、「泣ける」はある一定のタイプの感情を持つものの選別であり、誰にとっても同じな製品のような涙であると。

涙の理由

涙の理由

 

涙の理由はいくつかあるが、一つは痛さからの涙。そしてもう一つ思いつくのは感動としての涙。その感動の涙には「泣ける」涙以外にも、生涯で一度も流さないかもしれないけれど、とても貴重な涙があるという。

それは、人生のパズルのピースがカチッと嵌った時だけに、訪れるかもしれない貴重な経験としての涙。 それは、自分の存在を超えた何かに出会い、それまでの人生の意味と、これからの新たな可能性を感じたときに流される涙だと。

 * * * * * * * * * * * * * * * * * * * * * *

そういう生き方を称して、「長編小説的生き方」という言葉を個人的に提案したい。この本に出てくる長編小説の定義は、村上春樹さんや宮崎駿さんのように、作者も最初は結末を知らないで作り始める物語のこと。

(最初から枠組みを設定したり、自分を安全圏に置くのではなく)目の前にある物事に対して、自分自身をも賭け金としながら、一つずつ丁寧に向き合っていくことで、結果的になんらかの形につながっていくという生き方。もしくは仕事の仕方。ゴールは見えないし度胸もいるけれど、自分を超えたモノゴトに出会え得る、茂木さんたちのいう感動の涙に出会え得る生き方になっていると思う。

 * * * * * * * * * * * * * * * * * * * * * *

 茂木さんの問題意識は、「その感動の涙を流せる人生を送ることが、ネット社会のフラット化やグローバル化に対する唯一の対抗軸だ」と結論した。

人生で一度流すか流さないかぐらいの涙を基準に生きようという潔さ自身が、その人の人生を作っていくのだと思う。

僕は「長編小説的生き方」でその涙を目指そうと思う。

本 伝えることから始めよう

「伝えることから始めよう」髙田明さん著。

ジャパネットたかだの髙田さんがその半生と、得たものを綴った。髙田さんはいつも「今」に集中する。「今」を大事にするからこそ、それまでにないリアルタイムのテレビショッピングを思いついたのだと。そしてその生放送で自分がTV画面の中が話している最中にも、その話が視聴者にちゃんと伝わっているのかどうかが、即座にかかってきた注文の売上の数字として刻々と表われるのだという。

伝えることから始めよう

伝えることから始めよう

 

髙田さんの話は、なにかの修行のように思えてくる。過去も未来もなく、ただ目の前の相手にいかに満足してもらえるかを、ひたすら追求する。そのあり方が企業体質にもなっていて、目標がなく、他社と比較せず、自己更新を続けるという。

企業としてとっても珍しいけど個人的にはすごく魅力を感じる。ってか、このやり方ってすごく自然なことじゃないだろうか?世界がすごい速度で変わっているなかで、数年後の目標を立てることにどれほど意味があって、目標をたててしまったばかりに、縛られることのほうが多くなってきているんじゃないだろうか。

 

この方法論を聞いて思いつくのが脳科学者の池谷裕二さんの研究法。仮説を立てずに目の前の ” 脳 ” が「より分かるようになるかもしれないアイデアや新技術」をひたすら試しまくっていって、出た結果から脳の新しい知見を得ていく。

池谷さんのやり方は単年度予算が取りにくく、いつ論文になるかも分からず、現行の科学を支える制度には馴染みにくい問題があるのだという。しかしそれを超えるメリットがあるという。仮説がないので研究者のバイアスがなくなり、仮説を立証したいがためのデータの辻褄合わせもなくなり、出てきた結果の意味をすべて生かすことができる・・・だっけかな。

 

結論。髙田さんは「目の前にあるものから始める」という人生のスタンスが、たまたまテレビショッピングに発展したために、自分が一番知られている形として「伝えることから始める」というタイトルになったと。

本 マチネの終わりに

「マチネの終わりに」平野啓一郎さん著。

 これはやはり幸せな話だと思う。

どこにでもいる愛し合う人たちがいて、それぞれが抱える問題があり、さらに相手の悩みを受け止めたいけど、自分の悩みは相手に背負わせたくないという葛藤があり。その遠慮がまた相手を傷つけて。そこに第三者の思惑が絡んできて、二人は望みとは違う人生を歩み始めてしまう。ある時、ふと気づくとそれぞれが別の形の、望んだものとは違う形の幸せを実現してしまっている。

全部の願いは叶いはしない。一番の願いが叶うかどうかも分からない。他人の邪魔を呪うこともきっとある。あの時、こうだったら…という思いを噛み締めながらも、その時に出来ること全部やったか?と言われればきっと黙るしかない。

理不尽さも含めて、二人がそれぞれに人生を受け止めているからこそ、この話が幸せな印象を与えるんだと、やっと分かった。 

マチネの終わりに

マチネの終わりに

 

 個人的な経験で、遠距離恋愛をしてたときにメールの不具合が二人の関係に響いたことがあった。セキュリティ・システムが知らないうちに変更されたせいで、いままで届いていたメールが届かなくなり、お互いにメールを送ってるのに全然返事がこないことにやきもきしつつ、忙しいのを邪魔するのも悪いしと遠慮しつつ。

じゃあ電話してみればよかったのに、もしくは気になるなら直接会いに行けば良かったじゃん?というのはその通りだと思う。でも、その時は連絡が取れないことがたいしたことだと思わなかった。これはちょっとしたことで、すぐになにか原因(忙しさのピークが過ぎて返信がくるとか)がわかって解決するだろうと思っていた。

振り返ってみるとそれは結構重要なターニング・ポイントだった。メールトラブルの話は解決したのだけど、心に大きな傷を残した。お互いに相手が悪いわけじゃないのは知っているけれど、心に受けたダメージが帳消しになるわけでもなかった。

その後、僕側に問題があって別れてしまったのだけど、メールトラブルは別れるに至る上で少なくない役割を演じたと思う。(その時はメール会社の人を「なんてことをしてくれたんだ!」と結構恨んだ)

そして僕はこの個人的な経験をまだ、幸せな過去として捉えることができずにいる。またいつかこの本を読む時に、もしくは死ぬまでに幸せな経験として捉え直せるようになるのが個人的な課題だと思っている。

 

本 経済数学の直観的方法

「経済数学の直観的方法」長沼伸一郎さん著。

マクロ経済学の数学的な根本を、科学の発達の歴史に応じた理解で紐解いてしまう。こーゆー本に出会えるのは本当に幸せ。

* * *

すべては1661年のフェルマーの原理が始まり。それは「光はそのかかる時間が最小限になるように、水の中やガラスの中の進む経路を選ぶ」というもので、この原理を当時の人々は神の摂理の現れだと考えただろうと。そこに2体問題を解決する天体力学の発達と微積分の発見が加わって、最小値を求めるラグランジュアン力学が続き…(経済の)動的平衡理論までは大筋理解できてしまう。(高校までの数学はがんばって追う)

つまり、経済政策を決めてる人たちの頭の中にあるのは、2つの要素の最大効率(もしくは無駄を最小限)にすることを、頭のなかでトレードオフして考えているのだと。天体力学とフェルマーの原理から基本形はなにも変わっていない。ちなみに3つ以上の要素の最適解は基本的に解けないことも、フェルマーの時代から変わっていない。

* * *

経済数学の直観的方法 マクロ経済学編 (ブルーバックス)

経済数学の直観的方法 マクロ経済学編 (ブルーバックス)

 

余談として、社会現象から大づかみで帰納法的(マクロ的)にその構造を理解するケインズがヨーロッパではokなのにアメリカでは受け入れられず、ミクロ現象(個人)から演繹してマクロ(社会)に繋がるまでの理屈を確立できたときにアメリカで受け入れられた、という話はメカラウロコだった。

著者は言葉にしていないが、帰納的か演繹的かという手法の選択の仕方が、カトリック(ヨーロッパ)とプロテスタントアメリカ)のそれぞれのイメージに合ってる気がするのは自分だけか。

さらにこのイメージの続きとして、「個人をたしても、集団(だけが持つ力)にはならない気がするけど、そこはアメリカ的にはOKなのかな?」と直観的に思ったのだけど、その発想は福岡伸一さんの「世界は分けてもわからない 」や「動的平衡」が自分に深く浸み込んできたからそう思ったんだなと。感慨。

ちなみに現在流行りのDeep Learningの発想は、ミクロな現象(ニューロンの一つ一つの振る舞い)を演繹させて、マクロな現象に繋げるという方法論だが、まさにこれはアメリカ的だと思う。もしこれが行き詰まったら、そのあとは理屈から言えば、マクロからの帰納的なAIの発想の余地は残されていると思う。それが出来るのはヨーロッパ人や日本人などかもしれない。

* * *

一つのアイデアを理解することで次々に考えることが増える、本当に面白い本に出会った。

PYCON JP 2017に参加(プログラミング勉強会)

PYCON JP 2017というプログラミング勉強会に参加した経験をまとめておきたい。

今年2017年は参加者とスタッフ合わせて800人超が早稲田大学の一角に集まって、二日間に渡る発表や交流を行った。

f:id:molingit:20170909212853j:plain


PythonというプログラムはAIやビッグデータの処理から、IoT(電子機器の操作)まで幅広く対応しているのが特徴で、それだけに演題テーマも多岐にわたっている。そのため200人は入る教室が3つ同時に稼働して、それぞれPythonに関連した最先端の知見や、業務や研究での利用方法など30分間説明しまくる。話の途中でも30分ジャストで問答無用に切られるのが心地いい。演目の1/3は英語なので大変!!

 
印象に残った1つは、Amazonが提供しているサーバを借りて、そこにプログラムを乗っけて、手持ちのパソコンはデータの窓口だけをするという処理の仕組み。概念としては知ってたけどそれを業務でガシガシ動かしている人の話を聞いたら、初めて聞く要素や名前が多すぎて、英語の発表よりもついていけなかった。。。
もう1つはIoT系の発表で、バックトゥーザ・フューチャーのドクの若い頃「キャラ」で、演目は何でもいいから彼に話をさせて、自由に動き回させることがPython界というか日本の幸せになるだろうと思える何かを持っていた。
 

f:id:molingit:20170909224553j:plain

* * *
 
発表から視点をかえて会の周りに目を向けると、提供される弁当が美味しいのがけっこうすごい。5、6種類から選べて二日間ともランチには気合が入っている。さらには1日目の夜はパーティがあって料理とビールが振舞われるし(ベジタリアン向けやハラルもある)。3時のお茶もあるし、朝はサンドイッチ弁当も非公式に配られている。
 
そしてお昼の時間や休憩時間を通して、スポンサー企業との交流や求人募集が行われている。中身は知らない。
 
* * *
 
とても刺激になったし楽しかったんだけど、やはり一傍聴者ではダメなことが分かった。他人に伝えるべきモノを持っている人はスピーカーになって壇上で話している。何かを持ってても発表審査に落とされた人たちがいて「落ちた人たちによる事前飲み会」まで開かれている。
誰でも何かを持っている人と繋がりたい。持ってない人は繋がれない。当たり前。本当にこの会を楽しめるのは自分から持ち出して何かを提供した人。

そのことが分かってから、基調講演の意味や、振る舞いの基準が分かった。Pythonというプログラムを使っている人たちが集っているのだけど、誰もが当事者意識を持って、勉強会も盛り上げて、Pythonというプログラム全般を盛り上げていかないと、Python界自体が没落していって、趣味や仕事自体がなくなってしまう。そんな恐怖感が底の底にありつつ、やるなら楽しくやろうよ!というのが弁当の美味しさに現れてたりするんだろう。
 

f:id:molingit:20170909224544j:plain

二日目の基調講演はオープン・ソース・ソフトウェア(OSS)をみんなで作っていこうという話だった。話の内容より彼の問題意識が最初わからなかった。なぜ、OSSを手伝わないといけないの?というのが正直な最初の感想だったが、それは当事者意識がなかったがゆえの発想で、彼にとってはOSS当事者を一人でも増やさなければならないことは自明の理だったんだと。その当事者意識がPythonというプログラムに関わる人たちの根底にある発想だったんだなと。当事者意識を持った人たちの集まりならば、ちゃんと自分が属したら楽しいに決まっている。
 
明日は今回初めて自分が関われる、一日でプログラムを書いて何か成果をあげる「スプリント」という最後のイベント。何かを提供できるだろうか?