hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

老害の誕生

近年ラジオをよく聞くようになっていたから、ピエール瀧の逮捕には大変驚かされた。ここ数年、ピエール瀧リリー・フランキーが映画に出過ぎ問題がしばしば取り沙汰されていたが、こんな結末になるとは思いもよらなかった。

個人的には、逮捕されたとはいえ、麻薬で逮捕であり 20 代の頃からの常習者だったようだから、節度ある使い方をしていたわけで、役者や CM に引っ張りだこの状況で立場的にやっちゃだめだろ、とは思うものの、行為自体には特にどうも思わない。日本にもヒロポンが広く使われていた時代もあったし、ある種の宗教、音楽ジャンル、文化スタイルとは切っても切り離せないものでもある。スティーブ・ジョブズLSD に影響を受けた人だし、ついこの間はイーロン・マスクが番組で大麻を吸っていた。もちろん、素晴らしいものであると言いたいわけでもない。アルコール依存症がそうであるように、危険度の高い嗜好品であることには変わりない。リスクある嗜好品をどこまで許容するかは国民の総意が決めることだ。日本では一律 NG という判断がなされており、そこには合理性がある。だから、逮捕されるべきではなかったなどというつもりはない。

むしろ関心は、ピエール瀧逮捕の結果、過去の出演作や音楽作品の販売・配信が一斉に停止してしまったことの方にある。ただ、一般に言われている「他人に迷惑かけたわけでもないのに配信停止は過剰反応では」という論点とは多少異なる。むしろ、ピエール瀧が連続レイプ殺人魔であったとしても、作品は切り離して扱うべきなのか、ということの方にある。

ぷらすと by Paravi という番組で、映画・音楽ジャーナリストの宇野維正氏がマイケル・ジャクソンという天才が生み出した偉大な芸術を過去のゴシップ程度で潰すべきではないという論陣を張っていたが、私も感情的にはまったく同意見だ。犯罪は犯罪、やはり憎むべきものであるが、天才の生み出したものはそれ以上の価値のある希少なものだと感じる。被害者がいるのに、彼・彼女らの感情は無視するのか、という批判がある。たしかにそうなのだが、天才の価値はそれらの犯罪行為すら過小に評価せざるを得ないくらい重要であると思いたい。

誤解を恐れずに言うならば、犯罪行為はある意味「現実の」出来事だ。下世話で、狭く、閉じた世界の一部の人々の話である。一方で、天才の為したことは、世界に広く影響力を及ぼす。犯罪はどこにでもあり、誰にでもできるが、天才の偉大な成果物は希少であり貴重だ。

人権無視の酷い発想のように思えるかもしれない。しかし、これはほんの数年前までは一般的な捉え方だった。スティーブ・ジョブズのひどい人間性も、ロマン・ポランスキーの悪行も皆知っていながら、それを許容してきたのだ。

私に限って言えば、今でも天才の為したことの方が、その犯罪行為より重要だという考えを捨てきれない。しかし、このような考え方自体が古臭いものになりつつあることはひしひしと感じる。今はまだ MeToo 運動が一過性の出来事に見えているから抵抗する人も出てくるが、時代が移っていけば「何を当たり前のことを言ってるの?」となる可能性は否定できない。

チンギスハーンが攻めてくるたびに村人全員が虐殺される時代と現代では、殺人に対する倫理的な観念が異なるように、あるいは、今ではオフィス内でタバコを吸うことが異常なことになったように、「天才性」よりも「社会規範を守ること」の方が重視される時代になりつつある。個人的にはそのことをとても寂しく感じるけれども、時代が変われば物事の捉え方、その基準も変わっていく。当時は人気があった人が、その後顧みられないこともよくある話だ。

なるほど、こうして老害は生まれるのだな(と地球最後の男的なオチ)

2018年に読んだおすすめのビジネス書5選

昨年、40歳を超えてからというもの、残りの人生どう過ごすべきか考えることが多くなった。いっそ、そのことを書くのも新年一発目としてはいいのではないか、と思ったのだが、あまりにも陰々滅々とした内容になるため、昨年読んだビジネス書の紹介をすることにしてみた。

過去の文章を読んだことがあれば、私がいかにビジネス書のことを快く思っていないか、ということがわかるかと思う。多くのビジネス書は根拠に欠け、成功譚を大きく取り上げる一方、失敗した事例は端から切り捨てられている。

しかし、その一方でいろいろなビジネス書を読むうちに、成功者がなぜそのような結論に至り、決断に至ったのか、というプロセスには意味があるのではないか、と思うようになった。経済政策も同様ではあるが、学術的結論を待つには人生は短すぎる。限られた時間の中で有効な手を打たなければならない時、何を理由に実行したのか、そこに興味を覚える。

 

1冊目:正垣泰彦著「サイゼリヤ おいしいから売れているのではない 売れているのがおいしい料理だ」

サイゼリヤ社長がノウハウを書いた本。冒頭から店を出したものの客は来ないわ、客同士の喧嘩が原因で火事になり店舗を消失するわ、とツカミも完璧なのだが、今のサイゼリヤになるまでに行った施策となぜそなければいけないのかという理屈が事細かに語られており、とても為になる。飲食店に限らず、この本で語られていることを自分の業種だとどうだろうかと置き換えて読むと、いろいろ気付かされることもあるのではないだろうか。

 

2冊目:大竹慎太郎著「起業3年目までの教科書」

起業3年目までの教科書 はじめてのキャッシュエンジン経営

起業3年目までの教科書 はじめてのキャッシュエンジン経営

 

起業を確実に成功させる驚きの方法が書いてある。一般にこういうのは眉唾だと思うのだけど、この本の結論にはおおいに納得させられた。結局のところ、起業を成功させたければ、情熱とコミュニケーション力だけあればよく、ビジネスモデルなんてものはビジネスの拡大期にでも考えればいいのだ、という身も蓋もない話。

 

3冊目:島田潤一郎著「あしたから出版」

あしたから出版社 (就職しないで生きるには21)

あしたから出版社 (就職しないで生きるには21)

 

資産も実績も人脈も何もない著者が、情熱だけで翻訳権を得て、和田誠高橋和枝に挿絵を頼み、出版社を立ち上げた経緯を記した本。情熱の力は何物にも勝る!

 

4冊目:パティ・マッコード著「NETFLIXの最強人事戦略」

NETFLIXの最強人事戦略 自由と責任の文化を築く

NETFLIXの最強人事戦略 自由と責任の文化を築く

 

この本で書かれているノウハウは基本的に気が狂っているので、普通の日本企業が真似するのはやめた方がいいだろう。トヨタかんばん方式同様に、NETFLIXの会社の仕組み、培ってきた文化に最適化されただけかもしれず、あまり一般化するような話ではないように思える。

ただ一方で、世間と常識とされている組織運営のノウハウが本当に意味のあることなのか考え直す一助にはなるように思う。最近、ホラクラシーという組織論も出てきているが、従来型の組織運営スタイルが本当に効率的なのか、問い直されるフェイズに来ているのは確かだ。

 

5冊目:オースティン・クレオン著「クリエイティブの授業」

クリエイティブの授業 STEAL LIKE AN ARTIST

クリエイティブの授業 STEAL LIKE AN ARTIST "君がつくるべきもの"をつくれるようになるために

 

ビジネス書というより自己啓発書に近いものだが、クリエイティブなことを始めるためのガイドとして素晴らしいと感じたので紹介したい。この本の良いところは、「100%のオリジナリティなんてない」、「まずは好きなアーティストから盗め」などアドバイスがいちいち実践的という点。「定職を持とう」「平凡に生きよう」みたいなアドバイスもある。

悩んだとき、人生に躓いたときに読み返したくなる一冊。

AWS Lambda が AppEngine になった日

11/30 の発表で、AWS Lambd が ALB のバックエンドとして使えるようになったという発表があった。

話題としては、同時に発表されたLambda の COBOL サポート(なんでや)に完全に隠れてしまったが、これはものすごく画期的なサービスだ。

前回「サーバーレス・コンピューティングの終着点」という記事を書いたが、データベース以外の部分についてはこれが実現したと言っていい内容となっている。

GCP には大昔から従量課金のアプリケーション・サーバーとして AppEngine が用意されていたが、AWS には Elastic Beanstalk という単に実行環境がプリセットされた EC2 や使い勝手が悪い API Gateway しかなかった。

今回のリリースで、AWS Lambda が ALB のバックエンドとして使えるようになったことで、Tomcat や Express にあたる部分として Lambda がその役割を担えるようになった。しかも、Lambda の起動時間の遅さを ALB のヘルスチェック機能を使うことでウォームアップ可能というおまけ付きだ。

実際、簡単なプログラムを使って確かめてみたが、ウォームアップ後であれば、1リクエストあたり 60ms で返答がある。十分なレスポンスタイムだ。しかも AppEngine とは異なり、1リクエスト15分までは待つことができる(お金はかかるが)。時間のかかる作票処理にも対応できる。

現在の Web アプリケーションは、仮想DOM を使ったクライアント部分とサービス呼び出しのAPIを分離するのが一般的となっているが、前者については S3 など完全に static なアプリとして提供し、後者については Lambda を用いて処理を行う、というのがベストプラクティスになるだろう。

残念ながら現時点では RDBMS までサーバーレスにするのは難しい(Aurora サーバーレスはあるものの、起動時間の問題で Web アプリの要件には適さない)。当面は DynamoDB のような NoSQL で、という話になるだろうが、やはり使い勝手や管理面で問題になる。リクエスト起動可能な RDBMS というのが次のホットトピックになるのではないかと思われる。

サーバーレス・コンピューティングの終着点

最近、クラウドはもはや前提となり、さらにサーバレスが当たり前に使われるようになってきている。サーバーレスという言葉が出ると、サーバーばないという話ではないよ、という話が出たものだったけれど、もはやそんな枕言葉が不要になるくらいに普及している。

クラウドで開発が変わるという話もあったが、Google が最初に提唱した PaaS 的な方法論はあまり流行らず、従来型の三層アーキテクチャ(Web-AP-DB)を実現できる IaaS+α を推し進めた AmazonAWS が勝利を得た結果、開発手法そのものには大きな変化はなかったように思う。しかしそれも、サーバーレスの登場でフェイズが変わるかもしれない。

究極のインフラ環境というものを想像したとき、制約を無視すれば無償で無制限に資源を使えるというものだろうが、経済学が教えるように資源は有限である。その前提で考えれば、使った分だけコストがかかる、が真に実現できた状況こそ究極のインフラ環境と言えるだろう。

それがクラウドなんでは? と思われるかもしれない。しかし、例えば、EC2 にしろ RDS にしろ、起動しているか起動していないかで決まっており、CPUやメモリなど実際のリソース使用量によって決まっているわけではない。

もちろん、スケールアップに頼るのではなくスケールアウトすれば良いわけだが、その粒度が問題となる。サーバーレスの登場で従来はサーバー単位だったものがリクエスト単位にまで分割できるようになった。

すでに「サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス」という書籍が出ているけれども、おそらくこれからのWebアプリケーションはこのような方法論がベースになるだろう。

HTML/JavaScript 層は、CDN やオブジェクトストレージにも配置できる静的リソースとして作成し、そこから API Gateway を通してREST でサーバーレスの処理を起動する。すでに静的リソースに関しては、ほとんどタダみたいな金額で公開できる。処理はサーバーレスとなり、使用した分だけ課金される、というだけでなく、スケールアウトも容易となる。現状は、DynamoDBのような NoSQL だけが使用量に応じた課金という体系となっており制約があるものの、Aurora がサーバーレス化されたように使用量での課金が可能な RDBMS が次の選択肢として出てくるだろう。

ここまで来れば、残された課題は、起動時間の遅さ(レスポンスの悪さ)だけだが、一定数の常設サーバの存在さえ許してしまえば問題ではなくなる。現時点では、サーバーレスとウォームアップの組み合わせをうまく扱う方法はないが、Kubernates の Knative が発展すれば自然にできるようになるだろう。今はサーバーレス=AWS Lambda という風潮が強いが、Knative のように特定のプラットフォームに縛られないサーバーレス基盤が発展していき自由度も高まっていくのではと思う。

このようなシステム構成が一般的になれば、Git リポジトリと資源の制約情報を与えるだけで、すべてをよろしくやってくれる究極の DevOpts が実現できるのではないかと思うし、世の中そこに向けて急速に進んでいくと考えられる。

 

 

褒めるべきか叱るべきか、それが問題だ(続)

以前、「褒めるべきか叱るべきか、それが問題だ。」というエントリを書いた。ただ、そのときにはうまく考えをまとめることができず書けなかったことがある。それは、「怒らないためには期待しなければよいのではないか」という点だ。

昨今、「アンガーマネジメント」という言葉が流行っているが、その方法論のひとつに「こうあるべきを手放す」というものがある。私自身を振り返って、なぜ自分は怒りの感情を持ってしまったのかと自己分析すると、ほとんど「期待したとおりに相手が行動しなかった」場合だったと思う。相手に対し怒りを覚えるのは、当然それ相応の期待や予測が存在するからで、そこに何らかの期待がないならば、怒る理由自体がそもそも存在しない。

だから、怒らないためには、いかに「期待を持たないか」ということが重要になる。とはいえ、一方で「期待を持たない」ということは、果たして良いことなのだろうか、という疑問もある。期待というのはある種のこだわりの表れであるし、こだわりというはその人が伝えたいことであるわけだから、重要な事柄なはずだ。自分がこだわっている事柄を相手に理解してほしいからこそ期待するのだろうし、その結果として伝わらないことに憤りを覚えることになる。

なぜ今回、2015年のエントリの続きを書こうと思ったのかと言うとPodcastTuring Complete FM」の30回の最後で、まさにこの話が議論されていたからだ。

Rui「思うんですけど、教えるときに厳しすぎる人が多いなというイメージがあり、自信を失わせる方向で教えるのではなく、自信を増やす方向で教えるほうがいいんじゃなかなって」

hikarium「自信を失わせるのは本当に良くない。最初にできないのは悪いことじゃないですもんね。」

Rui「できないから逆にいるわけですからね。」

hikarium「できるんだったら来なくてよいので。だから、できるようになっていこうとしている人には本当に優しく接してあげるというか。当たり前のことですけど。」

Rui「hikarium とかちょっと厳しいときもありましたよ。」

hikarium「すみませんでした。たまになんか、てか、結構言われるんですよ。hikariumはスパルタだからって、たまに言われるんですよ。」

Rui「別にそんなつもりはないんでしょう?」

hikarium「あ、いや、ちょっとスパルタっぽくしているときはあります。でも、それは意図したものです。」

Rui「じゃあ、それをやめればいいんじゃないですか。それを。」

hikarium「でも、今回は……今回もちょっと駄目でした?」

Rui「僕はhikariumを知っているから、hikariumなみに優しくしているのかな、と。」

hikarium「いや、難しいですよね。」

Rui「まぁ、でも、それは、それこそ訓練じゃないですか。教え方と言うかテクニックがあり。心構えというよりはむしろテクニックですから。」

hikarium「あーなんか、自分が教えているのは、できそうな人を教えているので。だから、ちょっと期待値を高めに投げているので。それがちょっとスパルタっぽく見えるのかなっていうのがあるかもですね。外から見ると。」

Rui「別に期待しなければいいんじゃないですか。それはなんか言い方の問題だけど。別にこれくらい教えたんだから、これくらいできるだろう、と思わなければいいんじゃないですか。」

hikarium「たしかに、それもあるかも。せっかくだからいろいろやってほしいじゃないですか。まぁ、そうですね。高い目標を立てるというよりは、少しずつできる目標を立てて、それができたらすごいっていうことを言ってあげて自己肯定感を高めてあげるのは本当に大事なことかなと思います。」

Rui「本人が目標を立ててそれを達成するのはいいですけど、別にこっちがそれを期待する必要はないですからね。これくらい教えたから、これくらいできるはずなのに、なんでできないんだ、と思っても仕方ないから。」

hikarium「なんでできないんだという思考が一番危ない。」

私も歳をとったからかもしれないけれど、今となっては Rui さんの言うことがよくわかるし、若いときには hikarium さんに近い気持ちを持っていたな、と感じる。

一般化できるものなのかはわからないけれど、年齢と共にある種の尖った部分は減ってくるものだとは思う。若い頃には自分の考えは他の人にも理解できるものだ、という誤解があるけれども、多くの経験をする中で、世の中にはいろいろな人がいて、いろいろな考えを持っていて、そして必ずしも自分の考えが正しいとも限らない、ということがだんだんとわかってくる。そして、期待をするという概念自体、実はどうでもいいことなのではないかということに気付いてくる。

結局のところ、教育の結果などというものは教えられた当人次第なのであって、教える側がどうこうできるものではない。ようは「馬を水辺に導く事はできるが馬に水を飲ませる事はできない」ということだ。教える、ということは教えられた当人に伸びる”きっかけ”を与えるに過ぎない。そういう意味で期待をすること自体、余計なことなのかもしれない。

Python StatsModels メモ

R と比較すると微妙にサポートされていない機能があって困ることが多い StatsModels ですが、Python に寄せていきたいので、できるだけ使ってみてます。

ライブラリのロード

import statsmodels.api as sm

# R互換の関数方式を使う場合はこっち
import statsmodels.formula.api as smf

データのロード

import pandas as pd
data = pd.read_csv('data.csv')
# TSVは、data = pd.read_csv('data.tsv', delimiter='\t')
data = data.fillna(0) # 欠損値がある場合は 0 で埋める

モデルの定義

単回帰

model = sm.OLS(data.y, sm.add_constant(data.x))
#  あるいは、 model = smf.ols('y ~ x', data)
results = model.fit()
results.summary()

重回帰

model = sm.OLS(data.y, sm.add_constant(data[ ['x1', 'x2', 'x3'] ]))
#  あるいは、 model = smf.ols('y ~ x1 + x2 + x3', data)
results = model.fit()
results.summary()

ロバスト回帰

model = sm.RLM(data.y, sm.add_constant(data.x))
#  あるいは、 model = smf.rlm('y ~ x', data)
results = model.fit()
results.summary()

分位点回帰

from statsmodels.regression.quantile_regression import QuantReg
model = QuantReg(data.y, sm.add_constant(data.x))
#  あるいは、 model = smf.quantreg('y ~ x', data)
results = model.fit(q = 0.5) # 50%分位点
results.summary()

リッジ回帰、ラッソ回帰、Elastic Net

model = sm.OLS(data.y, sm.add_constant(data.x))
results = model.fit_regularized(L1_wt=0) # L1_wt が 0 の時 リッジ、1の時ラッソ、その間が Elastic Net
results.params

OLSと同じだが、fit の代わりに fit_regularized を使う。ただ、fit_regularized だと、なぜか summary() が None を返すので、params の値を参照する必要がある。

一般化線形モデル (GLM)

model = sm.GLM(data.y, data.x, family=sm.families.Gamma())
#  あるいは、 model = smf.glm('y ~ x', data, family=sm.families.Gamma())
results = model.fit()
results.summary()

一般化線形混合モデル (GLMM)

model = sm.MixedLM(data.y, sm.add_constant(data.x), groups=data.g)
#  あるいは、 model = smf.mixedlm('y ~ x', data, groups=data.g)
results = model.fit()
results.summary()

グラフの表示

import matplotlib.pyplot as plt
plt.scatter(data.x, data.y) # 散布図
plt.plot(range(int(data.x.min()), int(data.x.max())), results.predict(range(int(data.x.min()), int(data.x.max())))) # 折れ線グラフ

# 図表をクリアする
plt.clf()

「グラフをつくる前に読む本」が名著だった話

最近、Twitter 経由でおすすめされている本を買うことが多いんだけど、これもその中の一冊。

装丁とタイトルだけ読むとグラフの書き方を図解で学ぶハウツー系の軽い本のように思えるけど、予想をいい意味で裏切る良書だった。似たような資料としてマッキンゼーのスタイルガイドがあるけれど、こっちの方は基本というより応用編的な難易度でなかなか使いにくく感じていたので、この本のシンプルさには感銘を受ける。

何がいいかと言えば、各グラフの説明だけでなく、そのグラフが生まれた歴史までがきっちり調べて書かれているところ。てっきり、いろいろなところで生まれたグラフ概念が洗練されて今の形になったのだと想像していたのだけど、現在使われているグラフのほとんどが1786年に発行されたウィリアム・プレイウェア著「The Commercial and Political Atlas」を起源とするというのには驚かされる。なんて有能な人なんだ。

とはいえ、このプレイウェア氏、様々な事業に挑戦したものの失敗し、詐欺、恐喝、名誉毀損と犯罪尽くめの晩年だった挙げ句、グラフの生みの親として評価されたのは19世紀以降と残念な人生だったようで。世の中うまくいかないものですなぁ。

もちろん、この本の良いところは歴史や用語の定義などきっちりバックグラウンドを書いているところだけではない。グラフの使い方について次のようなわかりやすい指針を示しているのは大変実用的だと思う。しかもこの内容を惜しげもなく本の最初にもってきてるは理解を容易にする意味でとても良い。

得意な表現方法 個別 全体
実数 割合
データ間の比較 棒グラフ レーダーチャート 円グラフ
積み上げ棒グラフ
時間の経過による推移 折れ線グラフ 面グラフ
データの偏り ヒートマップ
データ項目同士の関係 散布図

そうそう、これが知りたかったんですよ。*1

円グラフは使ってはいけない、という主張も説得的。なるほど、今後は円グラフでてきたら眉につばを付けて見るようにしよう、という気になる一冊。

*1:本書内での主張とグラフの配置が微妙に違っていたので一部修正しました