音の鳴るおもちゃが苦手で、子にはあまり買い与えていない。

楽器ではなく、 ボタンなどのスイッチを押すと録音されて効果音が再生されるようなやつ。同時にランプが点滅したりもする。楽器ではないと書いたけれど、楽器やオーディオ装置を模した形をしていることも多い。

ランダムに音が鳴るのも苦手だし、プラスチッキーな外観も好きに慣れない。例外としてボタンを押すと短い歌が流れる "sound book" を 2-3 冊持っている。別に何らかの criteria を満たしからではなく、これらをいくつか買ったあとでもうたくさんという気持ちになった。強いていえば sound book は嵩張らないところがマシ。

自分たちはよくあるテックな親としてスクリーンも控えめにしか見せていないので、子は音に耐性がない。音の鳴るおもちゃ、にかぎらず音というものにはだいぶ sensitiveで、mall とかにいくと全方向から鳴る音にキョロキョロしている。過敏すぎが少し心配ではある。

そんなかんじで音の鳴るおもちゃのない家に「こどもちゃれんじ」の教材デバイス「はてなくん」がやってきた。別名タッチペン。ステルスインクを読み取るスキャナで、教材の冊子のページ内に埋め込まれたマーカー ID を読み取ってなんらかの録音を再生する。たとえば動物の絵をスキャンするとその動物の鳴き声が再生される。

さらにデバイス内に簡単な state を持てるらしく、クイズの設問マーカーをスキャンしクイズを再生したあとそのクイズの正解をスキャンし設問に答えることができる。たとえばページ左上のしまじろうアイコンをスキャンしたあとページ全体に描かれたモブから彼をさがしてスキャンすると該当キャラのよろこびの声が再生される、といったことできる。

タッチペンの「はてなくん」は音の鳴るおもちゃである。しかもかなり出来が良い、つまり子供を引きつける力の強いやつ。まず再生される声のデータが多い。見開き 5 ページくらいの冊子の各ページに 10 パターン以上の音声が再生される。先に書いた state を駆使してかなりインタラクティブだし 、たまにランダムで自分のテーマ曲を歌う easter egg まである。

コンテンツにはもちろんベネッセの稼ぎ頭「しまじろう」が登場する。しかもそのコンテンツが毎月更新される、というか毎月新しい冊子が届く。サイトによると 10 ヶ月分で合計 4700 音声らしい。そこらへんで売ってる嵩張るばかりの音の鳴るオモチャとは格が違う「面白さ」、刺激の強さがある。

開封した翌日、普段は寝起きの悪いその子は朝起きると「はてなくんで遊びたい」といった。昼寝から置きた時も、ふだんなら「ぶどうたべる？」とかいっておやつの力で意識を呼び戻すところ「起きてなにしたい？」ときいたら「はてなくん」と答えた。じゃあ遊ぶかと一緒にあそんでいたら・・・

おしっこをもらした。ここのところトイレトレーニングは順調で半月以上もらすことがなかったのに、タッチペンに夢中すぎて尿意を無視してしまったらしい。だいぶショック。文章にするとファニーだけど当事者にはおおごとなのだよ。

タッチペンの楽しさ、刺激の強さ、あるいは「エンゲージメントの高さ」は親である自分を不安にさせる。同類の刺激の強いおもちゃはずっと避けてきたのに、教材の顔をしたこの刺激テクノロジが突然乱入してきて焦る。

自分の中にある「音の鳴るおもちゃ」への抵抗は主に aesthetic なものだとなんとなく思っていたが、それだけでないことに気づいた。この抵抗は「スクリーン」への忌避に通じている: 当事者(子)の effort に対する reward としての刺激が強すぎる。簡単にヒマが潰せすぎる。

「音の鳴るおもちゃ」を選ぶ世の中の親を非難したいと自分は思っていない。スクリーンをはじめとする刺激物の影響に確固たる結論は出ていないはずだし、どのみち子育ては各人の判断でやるものだから。ただ、自分たちの中の standards や boundaries はなるべく一貫させたい。タッチペンはその壁を激しくぶちぬいてきたので動揺している。タッチペンにはスクリーンと同じような扱いが必要なんじゃないか。

というか、そもそも与える必要はあるのか?

教材である以上なんらかの学習効果を期待しているわけだが、その効果はこの刺激のコストに見合っているのか。今回のコンテンツを見る限りその見返りは感じない。他の本やトイで足りてんじゃね?

ウェブで世の親の声を眺めてみると、言語の獲得を助けるのが主要な効能として評価されているようす。つまりタッチペンで遊んでいたらしゃべるようになった、字が読めるようになった、というようなもの。幸い子はすでにだいぶしゃべるしひらがなも読めるようになってきたので、その点でタッチペンの助けは要らない気がする。

公式サイトはそのほかの効能ジャンルとして「数」「図形」「論理」「好奇心」を挙げている。そんなに高い効果あんの？コンテンツからそういう作為・・・・という書き方は悪意がありすぎるけれども、意図は感じる。しかしそんな思い通りにいくの？

他の教材なのかおまけなのかよくわからないコンテンツたちも、やはりテイストが親たる我々の趣味とあまりにも違い、その割に子供は夢中で、しかし教材としてのユニークな価値というものは感じられない。（世の中ユニークな教材なんてものはほとんどないだろうから、この批判がフェアでないのはわかっている。気分を書き下してるだけです。)

この受け入れられなさが刺激が強すぎるという「子のため」の判断から来ているのか、テイストの不一致という「自分のせい」なのか、冷静には見極められない。ただ親としての居心地の悪さがどうにも辛いので、夫婦協議の末に解約した。

ウェブを眺めてもタッチペンに対して自分と同じような不満は見つからない。しかし音の鳴るおもちゃへの批判はあるはずなので、やや不思議。きっと自分と同じような指向性の人はそもそもこの教材を購読しないのだろうね。不用意だった。ただ「こどもチャレンジ」がどういうものかわかったのはよかった。高い勉強代、あるいはうかつ税となった。

ソーシャルな場面、特に家庭で、ラップトップなりスマホなりの画面を眺めているのは感じが悪い。自分も食事中にスマホをされるのは不愉快なので家では夫婦とも食卓でのスマホはナシとしている。

一方、たとえば食後にソファなりベッドなりで画面を眺めているのはどうだろう。人にもよるだろうけれど、自分の感覚だとこれは食事中ほど感じはわるくない。一方で、子供がいるとやりにくいし、実際自分たちはあまりやっていない。しかし、結果として子供の目を盗んで画面を見るという本末転倒なことがしばしば起こる。なんか不毛。

いま子に画面を見せたくないのは、それが過剰に引力を持っているから。一旦画面に気を取られると、たとえば何らかの動画を見せろと tantrum が起こる。一旦見せても次々に見たがりきびしい。この問題は、ある程度は時間が解決すると思っている。

もう一つの問題は子に限ったことではなく、画面というものが持つ awkwardness に由来している。つまり、画面の向こうで何が起きているのかが外からわからない。

食卓の例にもどると、たとえば食事中でもちょっと調べものをしたいことはある。一方で、調べもののついでにソーシャルメディアなどをひやかすことも可能だし、実際に寄り道はおこる。画面が見えない事実も寄り道を招きがち。その寄り道はしないでほしいし、自分でもしたくない。画面が外から見えないとその不信感は払拭できない。

食卓に限ると、調べものとかはテーブルに電話を置いて作業しようと決めている。画面を隠さない。こうすると、少なくとも夫婦間での問題は解決する。地図を見るとか買い物アイテムを足すとか、別に他人に見られてもいいし。

ソファやベッドは同じ方法が使えない。こうした時間にソーシャルメディアなり何なりを眺めるのは何も悪いことではない。ただ問題が無いわけでもない。相手に話しかけたい時、あるいは話しかけられても構わないときに、良いシグナルがない。つまり画面を見ている誰かはいま「忙しい」のだろうか。それともどちらかというと「ヒマをつぶしている」のだろうか？ラップトップや電話の背中はこうした問いに答えてくれない。

ラップトップや電話のない世界では同じ場面で何が起こるか？テレビやテレビゲームは、そこで何が起きているのか筒抜け。ポータブルゲーム機は、すくなくともゲームをしていることはわかる。紙の本や雑誌を読んでいるなら、本や雑誌のタイトルはわかる。雑誌は、どの記事をよんでいるかまではわからない。ノートに日記を書く。日記を書いていることはわかる。何を書いているかは見えない。ノートと教科書をだして勉強をしている。科目くらいはわかる。電話で誰かと話す。筒抜け。

ここには何らかのシグナルがある。ゲームをしているなら、その場で話しかけてもムダだろうが（ゲームに集中しているから）、一方でそのラウンドがおわったら用事があると伝えることはできる。電話もおなじ。本や雑誌を読んでいるならたぶん話しかけて問題ない。日記も、たぶんだいじょうぶ。勉強は、そっとしておいてあげたい気もする。

プライバシーも、一定程度はある。つまり（少なくとも家族なら）日記を覗き込むんだりはしない。読んでいる雑誌を覗き込むのは、たぶん構わない。他人に知られてくない読みものは、そういう場面に持ち込まない。仕事の電話も席をはずす。

スクリーンにはこうした nuanced  なプライバシーやシグナルがない。それが awkwardness につながっている。

不透明でない画面の可能性

少し意外な発見として、デスクトップの画面は場合によってはシグナルがある。具体的には living rooms にデスクトップを設置すると画面はまわりに筒抜け。職場での画面も同じ性質を持っている。デスクトップを使っていたり、ラップトップを大きなモニタにつないでいると、作業はまわりに筒抜け。これはある種の制約としてもよく機能する: 仕事中あんましソーシャルメディアとかみてんなよ。まったく気にしない強い人もいるが、すくなくとも Facebook やってる同僚に仕事の話で割り込むのに気後れはない。

Kindle のデバイスも少し似たようなところがある、つまりすくなくとも本を読んでいるであろうことはわかる。カバーつきの本くらいの可視性。

スクリーンを使いつつ、適切な可視性で家族にシグナルを伝えることはできないものか。つまり、つかっているアプリなりみているウェブサイトくらいは外から見えてほしいんだけど、見せられないんですかね？

富豪的な解決は用途別にデバイスをわけること。これはインターネットにつながるデバイスとそうでないデバイスをわける、みたいな断線の仲間だけど目的は違う。機能するかもしれないが、そのためにはメインのデバイスでソーシャルをしない決断が必要で、それは自分はともかく他人（奥様）に強いるのは難しそう。

Surveillance dashboard をつくる。ブラウザ拡張や強い権限のあるアプリで、いまつかっているアプリやみているサイトを検出のうえなんらかの見える場所に表示する。おおがかり。あと iPhone 相手だと使えない。 ついでに寝室には surveillance dashboard 置きたくない。十分に非侵入的かつコンパクトで持ち歩けるデザインなら話は別だが・・・。

理想的には PC なり電話なりの背面に小さい画面があって、そこにアプリのアイコンなりサイトの favicon を出せるといいんだけど。そういう時代は来ないだろうなあ。

紙を選ぶ

より現実的に、画面でなくていいものを画面から追い出し、シグナルのあるメディアを受け入れることもできる。要するに紙の雑誌を買う。紙の本を買う。紙のノートで日記をつけるなど。

紙のメディアは「かさばる」という大きな欠点があるわけだが、その「かさ」がまさにシグナルとして機能する事実は無視できない。いわゆる affordance というやつ。本の affordance がどれだけ重要かは場合によるが、それが本当に priority なら紙の本を買うのはアリだと思う。ただ失うものも多いので悩ましい。

そんな理由で最近はためしに紙の本を買ってみている。でも技術書は厳しいね。でかすぎ。一方、たとえば Modern Operating Systems は表紙が賑やかで楽しいらしく子が興味を示す（まさかこのダサい表紙にそんな魅力があるとは）し、ヘネパタを読んでいる時に子が寄ってきたら裏表紙をみせて「これがヘネさん、これがパタさんだよー」とかいう話ができる。などなど affordance の力は感じている。

ただ長期的には family-aware で less awkward な media consumption device に出てきてほしいなあ。Apple と Amazon に期待。ていうか Kindle DX 帰ってきて！愛してた！

追記

その後も実現方法をぼんやり考えていたが、子供を画面に近づけたくないうちは無意味なアイデアに思えてきた。そのフェーズが終わり子供に画面、というか画面つきデバイスを渡すようになったら surveillance dashboard を作っていいかもしれない。

ハードウェアがあまり速くならない世界で、ソフトウェア開発はどうあるべきか。

マルチコア化や GPU 対応みたいのは、ある程度は進んでいるが「Many core が来るぞー」といっていた時に想像していた、全てのループとデータ構造が並列化される、みたいな勢いには至っていない。(知り合いもそんなことを言っていた。)

これは、端的にいうとクライアントサイドだとコア数がそんなに増えなかったからで、サーバサイドだと serving の inherent な concurrent nature を exploit すれば足りたから。Big data 方面の data parallelism は進展があったけれど, functional にしましょうね (Spark),  Stream も相性いいよ (Kafka), でもできれば declarative にしましょうね (SQL) というあたりでアプリケーションプログラマの用は足りた。こうした data processing や cloud のインフラを開発している人は色々難しい問題と戦っているだろうけれど、そういう人たちは別に many core とかいう前から大変だったはずなので、がんばってくださいね。

GPGPU についてはほんとに "general purpose" なコードを書く必要に迫られる人は少なく、何らかの(グラフィクスでない) specific purpose ごとに定型的なやりかたが生まれ、人々は分野ごとにそのパターンを使いまわしている印象。具体的には何らかのデータフローのフレームワークがあり、プログラマはそのノードを埋める CUDA のコードを書く。ML はそうだし、画像処理も似た感じ。他の分野はどうなのだろう。ゲームとかは general purpose してる人がけっこういるのかもしれない。物理エンジンとか、どうなのかな？

ある分野の専門家として上を目指すならそのドメインの定形フレームワークを自分で実装できた方がよいだろうけれど、それはなんでもかんでも GPU に追い出すぞ！みたいな勢いとは違う感じがする。一方でそんなフレームワークををかけるくらい CUDA に精通すればなんでも GPU に追い出せる能力を持っている気もする。

要素技術の話はさておき、プログラミングやソフトウェア開発の慣習は Moore's Law 時代の暗黙の前提がまあまあ残っていると思う。

たとえば「まずは正しく動くものを綺麗に書いて遅かったら高速化する」("premature optimization is the root of all evil.") というアイデア。Knuth のもともとの premise は正しいといえば正しいが、その「正しさ」はどんどん速くなるハードウェアによって割増されていたと思う。つまり書いたものがちょっと遅いことはよくあったが、ほっておくとハードウェアの高速化によって解決してしまった。

「綺麗に書いたらあとはハードウェアの進歩がなんとかしてくれる」というこの期待は、昨今はよく裏切られる。けれど、どうしたら code hygine と性能のバランスをとれるのかの答えは出ていない。Go, Rust, Swift のようなモダンで速い言語は答えの一部なのだろうけれど。特に Rust は zero overhead abstraction とかいってるし。

こうしたプログラミングの所作だけではなく、ソフトウェアの製品デザインにも暗にハードウェアの進歩を期待している。具体的には、人々は既存のソフトウェアにどんどん新しい機能を詰め込んでいく。ソフトウェアはじりじり遅くなる。

モニタリングやベンチマークといった fitness function enforcement によって性能低下を防ごうとするのがモダンソフトウェア開発ではあるけれど、新機能の追加によるちょっとした遅さを deliberate choice として受け入れる場面はしばしば目にする。つまり「この機能は重要だから」とトップダウンな判断でちょっと遅くなる。また完全な fitness function は存在しないので、気づかないところで色々おそくなったりしがち。たとえばウェブブラウザでいうとページの中で使うプリミティブはよくベンチマークされているがページの外側の UI は相対的にザル。

ハードウェアは今でもいちおう速くなり続けているので、こうした小さい性能低下は今のところあからさまでない。ただし「速くなった」と主張する新しいハードウェアの性能をエンドユーザが体感できる機会は減った。伸びしろをソフトウェアが食いつぶしてしまうから。

クライアントサイドはモバイル、サーバサイドはクラウド。ここ 5-10 年でユーザの性能に対する期待値は一旦リセットされた。だから「コンピュータは速くならない、遅い」という時代の空気はまだそれほど高まっていない。でも PC をとりまく倦怠感に似た空気は、そろそろ現世代のコンピューティングにもやってくるんじゃないの？

というかモバイルには「退屈なハイエンド新製品」という形で倦怠期が来ている。毎年 CPU が（ベンダー公称でなく実際に) 1.5 倍はやくなってたら別にカメラとか AI とかがんばらなくてもみんなスマホ買い替えてくれるよたぶん。クラウドも「自分でサーバを持たなければ自動的にハードウェアの進歩がやってくる」みたいな初期の約束はうやむやにされてるじゃん。それは別に AWS 鞘抜きでぼったくってるからではなく、ハードウェアが言うほど速くなってないからだよね。

話が逸れた。

プログラミングにしろソフトウェア製品のデザインにしろ、CPU 性能バブル期になんとなく染み込んだハードウェアの進歩に対する暗黙の期待が今でもあちこちに残っていると思う。Many core parallelism や GPGPU みたいなわかりやすくてかっこいい取り組みは気にされているけれど、日々の細々とした営みの中にも unlearn した方がよいものが色々あるんじゃないかな。

意図せず環境の sustainability を巡る議論とよく似た論調になった。子どもたちの未来のために限りある資源としての性能を大切にしていきましょう・・・というのは半ば冗談として、限られた機能の速いソフトウェアは、今も色々あるけど今後いっそう存在感がましてくる、かもね。Environmentally responsible products ならぬ responsibly performant software.

via What is Developmentally Appropriate Practice (DAP)? | NAEYC

NAEYC というのは幼稚園の業界団体みたいなもので、自分の子がいく preshchool も入っている。幼児教育本を探すにあたりこの団体の出している Developmentally Appropriate Practice in Early Childhood Programs という本の評判がよかったので、Developmentally Appropriate Practice というのが何なのか下調べしていたらこの資料をみつけた。（リンクされているドラフトの PDF.)

名前からして年齢相応のアクティビティのリストみたいなものかと思っていたら全然違った。幼稚園教育のスタンダードを定義するメタフレームワークみたいな話。しかもリンクされている PDF はその実現方法については議論しておらず「我々のスタンダードはこうです」という話だけをする。position paper を名乗っているのはそういうわけだったか。

書籍も中を覗いてみたいけれど、目次すらオンラインには見当たらない。ただ先の文書を読んで家での教育と preschool 運営はやはりだいぶ違うという認識に至ったので、あんまし参考にはならないかもな。自分は幼稚園の先生になりたいわけではないからね。

読書記録:

• How to Raise an Adult: Break Free of the Overparenting Trap and Prepare Your Kid for Success

おまえらは学歴にこだわりすぎだし過保護すぎる、厳しく、しかし愛のある親になろうな・・・という話。こう書くと退屈な本みたいだが、なかなか面白かった。

まず書いているのが Stanford の元 freshman dean (新入生担当課長みたいなかんじかな) である。そして著者自身 Palo Alto に住む二児の母でもある。超高級住宅街で子育てする学歴社会頂点勤務のひとが「学歴にこだわりすぎる」というこの圧倒的居心地の悪さが面白い。

本書の前半 1/3 は過保護な親の現状に関するレポート。なのだが、書かれている過保護っぷりがやばい。アメリカ社会共通のダメさ (helicopter parenting - 子がどこにいくにも車で連れてく)はそれなりに共感があるし、公園のような公共空間の過剰な安全指向についても身に覚えがある。しかしそこから先はアホかと呆れる話が続く: 子供の宿題をやる親、大学にだす出願エッセイを書く親（および代行業者）、修学旅行についてくる親、一日連絡がとれないと大学に連絡をよこす親、子の職探しをする親、職場の上司に人事考課の苦情を言ってくる親など、エクストリームな逸話が多すぎて他人事ながら面白い。アメリカの金持ちはアホだな・・・という気持ちになる。結果、そうした過保護が生み出す問題（子のうつ病、親の育児鬱、study drug 中毒など）について議論する中盤 1/3 も半分以上他人事に感じられ、がんばってくれやと冷やかしながら読んだ。ただ anecdotes としては面白かった。

後半 1/3 は、そうした現状を脱するための指針を議論する。ここは狂っていない upper middle 家庭向け parenting book guide といった体裁で参考になった。書き手はさすがによく取材というか調査しており、参考文献がとても充実していて良い。紹介されている本を何冊かは読むことになろう。議論されている指針自体も前半を踏まえると割とまとも（平凡ともいう）で、我々夫婦の感覚とまあまあ近い気がする。プロキシ言語化として役に立ちそう。

ただ最後が「Stanford と Harvard と Yale 以外にもいい大学は色々あるからこのへんのウェブサイトを参考にして探してくれよな」みたいな話でおわっており、アメリカの大学進学率何パーセントだよ主語でかいな、という白けはあった。高学歴の呪いの根深さを感じてしまう。いや Stanford も Harvard もすごいと思いますけどね・・・・。Amazon のコメント欄も絶賛と白けに分断されている。こんなところにも class divide.

しかし我が子の避けがたい helicopter parenting という現実をみると、アメリカの学校教育システムや社会そのものの変化もまた異常な過保護を生み出す何らかの避けがたい構造的な圧力を持っているのではないかと不安になる。10年後アメリカにいたとして、自分も気がついたら子の所在を GPS でトラックしつつ宿題をやっちゃったりするのではないか、巻き込まれるのではという恐怖。

自分にはアメリカ学校生活への無知から来る不安があるので、それを払拭するためにもそのうち何らかの調査をしなければと思った。

夕方、晩飯を食べて風呂に入れると子はもう寝る時間。まったく戯れる時間がない。週末ためしに晩飯前に風呂に入ってもらうと食後に余裕が生まれた。

夕食前に子を風呂に入れたい。しかし奥様は炊事をしている。自分が帰ってきて風呂を担当する必要がある。17:45 くらいに帰ってくれば 30 分で風呂に入れて出して 18:30 前に夕食できる。しかしそのためには 17:00 ぴったりに退社しないといけない。

一方、朝は子の歯磨き補助やプレスクールの送り出し補助などで出社が遅れがち。9:00 仕事開始を miss することが増えており、8 時間労働のコミットメントが危ぶまれている。この slippery scope を下りたくない。遅れた日は帰りを少し遅らせて補っているが、子の風呂を担当するなら帰宅時間もハードデッドラインになる。それは無理なのでは・・・。

色々と愚痴の萌芽が脳内を渦巻くがそれはスルーし、できることを考える。そろそろ手を付けたくなかったものに踏み込んでいく必要がある。

候補 1: 通勤時間の短縮。自転車を買い直して自転車通勤する。三年前に盗まれて以来徒歩だった。これで 30-40 分増える。しかし自転車を使うと通勤を兼ねたジョギングが自分の生活から失われ、運動不足および脳内麻薬切れの恐れがある。また帰路のオーディオメディア消化もだいぶ減る。

候補 2: Mail WFH. 家でメールを読んでおく。朝か夜か。まあ朝だろう。いま課外活動に使っている朝の時間の一部を仕事メールの消化にあてる。家で仕事をやるのも課外活動を削るのもイヤだが、可能ではある。朝はどのみちインターネットでダラダラしがちなので、かわりにだらだらメールを読んでも大差ないかもしれない。あと会社で朝からメールを読んで勢いを損ねる残念さを克服できるかもしれない。

候補 3: 候補 1 のバリエーションとして、徒歩通勤で歩くのをやめ帰りも走って帰ってくる。そして自分の風呂ついでに子も風呂に入れる。一瞬名案かと思ったけど、現実的には自分は風呂に入れない可能性が高い。そして風邪をひく。危険。

候補 4: 候補 1 に加え、夜中にジムなり公園なりで走り脳内麻薬を補う。就寝が遅れるので朝の課外活動が削られるが、メールに削られるよりはマシかもしれない。朝走るよりは夜走るほうが、シャワーを夜の一回で済ませられて良い。あとジムで走れば本が読める・・・かもしれない。しかし夜はもうだいぶ疲れててきびしい気もする。本をよむ気力はなさそう。

候補 5: 仕事中いまよりカリカリ働く。できりゃ苦労しねえっつうの。言ってみただけ。

候補 6: 候補 2 (Mail from Home) と 候補 4 (自転車 + 夜のジム) を同時にやるとどうなるか？朝の課外活動の時間が睡眠とメールで完全になくなる。しかし会社でメールを読む時間を減らせ、かつフル 8 時間いられるので・・・仕事がはかどる。いや仕事はそこまで捗らなくていいな。アメリカのワーカホリックというかんじの時間割。

候補 7: 夜の睡眠を削り、昼休みに昼寝する。ハードワーク父母のあいだでは割とポピュラーなオプションである現実を目撃しているが、精神衛生および健康を損ねがちなのでパス。

自転車、あったらあったで通勤以外も便利だとは思うけれど、家の中には置く場所がなく外におくとまた盗まれそうにも思え、うーむ・・・。

課外活動か精神衛生と家族の時間のトレードオフ。むー・・・。まずはためしに朝メールを読んでみるかなあ。いちばん開始の敷居が低いので。

とかおもっていたら今日は奥様が夕食前に風呂をやっていてくれた。ありがたし。

なお以前書いた寝る前の家事は、できたりできなかったり。気力がない時もあるし、dish washer が done でない日もあるし、こうしてなにか書くのを優先する日もある。さぼった翌日はだいたい朝が遅れ、出社が遅れ、イライラしがち。自業自得だけど、そんないろいろちゃんとやるには意志力が足りてない。

最近たまたまハードウェアに詳しい人と話す機会があったので「なんかムーアの法則ってけっこう前におわっちゃってたんですね？」と水を向けたところ、「いやムーアの法則は今でもまあまあがんばっていて、おわってしまったのは Dennard scaling だと思うんだよね」と言う。

Moore's Law は半導体の集積度がどんどんあがっていくという話だった。プレイヤの数はどんどん減って TSMC とか数社になっちゃったしペースも少し落ちたけれども、プロセスはひきつづき細かくなっている。ただし集積度が上がることで消費電力がさがる、という現象はなくなった、

この「集積度があがると消費電力がさがる（そのぶんクロックを上げたりコアを増やしたりできる）」という現象が Dennand Scaling であり、それが 2006 くらいでおわったらしい。2006 年からしばらくはまだ電力バジェットに余裕があったからコアを増やせたし Big.Little みたいな発明も助けになったけど、以前のような勢いはもうない。

最近のスマホの SoC で CPU の占める面積がどんどん小さくなっているのもこの帰結らしい。Moore's Law によってチップの集積度は上がっている。しかしチップ上の回路をぜんぶ同時に使うと消費電力が多すぎる。しかし CPU はその汎用性から基本的にぜんコア同時に使いたいハードウェアである。だからダイの予算を活かそうとコア数を増やすと電力消費も増やさざるを得ない。つまり SoC 内の CPU の大きさはダイの面積ではなく電力によって制限されている。

なので CPU の性能向上でみると Denning だろうが Moore だろうが結論は変わらない。つまり、もう大して速くならない。

一方で CPU 以外は事情が違う。同時には使わない用途限定のハードウェア同士なら同じ SoC に詰め込んでいくことができる。そこで将来 CPU のかわりに色々な特殊用途の DSP なり DSA なりが色々 SoC につっこまれるようになった。たとえばカメラの ISP (image signal processor) とかすごいでかい。A13 では CPU よりでかい。これはカメラを使ってるときしか使わないハードウェアだからなのだね。

別の見方をすれば、CPU は SoC 上の面積では存在感が下がっているが、消費電力では引き続き目立っているのだろう。CPU にしても、たまにしかつかわない命令のための回路 (Dark Silicon) は増やせる。AVX とかはそういう枠、という認識。どのくらいの空間的・時間的粒度で回路をオンオフできるのかは自分にはよくわからない。CPU 業者の腕の見せ所でもある。

たまにしかつかわない DSP/DSA が増えているのはムダだとおもっていたけれど、電力や熱がボトルネックで SoC の面積は相対的に余裕があるのなら、ピンポイントで CPU をオフロードできるハードウェアでその余剰面積を埋めていくのは理にかなっている。Domain Specific Architecture, おもったより時代の要請だった。

そう考えると TLS ... はもうハードウェア支援ありそうだけど、あとは JSON のパースとかも ハードウェアにされちゃいそうだな。あとは GC とか色々研究あるけどそろそろ実践投入してもよくね? 個人的には View のレイアウトとかもなんとかしてほしいなー。などなど、あまった回路で DSA する将来には色々夢があってよい。

ふと手元にあったヘネパタをぱらぱら眺めたら 5 章にだいたいこのようなことが買いてあった。左様でありましたか・・・。

アカデミア的には 2011-2013 あたりに盛り上がっていた話らしい。

• Esmaeilzadeh: Dark silicon and the end of multicore scaling - Google Scholar 1700 citations
• Taylor: A landscape of the new dark silicon design regime - Google Scholar 160 citations

前に書いたことの続き。

以下では「人に教える」という行為のネガティブな話を色々書くわけだけれど、だから教えるのが良くない、という話ではない点に留意されたし。物事には多かれ少なかれ対価があり、この文章はその対価に話題を絞っているだけ。総体として教えるのがよくないとは特に思わない。自分は機会がないからやってないけれどね。

前の文章では教えないことの対価が言語化の不足だと書いたが、教えることの対価があるとすればそれはまず言語化の過剰、あるいは望ましくない言語化である。

人に何かをおしえるとき、特に企業のトレーニングのような実務的な文脈ではおおきく二種類のバイアスが入り込みがちだと思う。

ひとつめは単純化。人に何かを教える時は、わかりやすさのために物事のニュアンスを落として説明することが多い。アイデアの限界や例外は、しばしば省かれる。教わる側はなにもしらない状態から単純化して理解した状態になるからプラスだけれど、教える側はどうだろう。本来もっていたニュアンスを落とした言語化をすることで、当人のメンタルモデルからもそうしたニュアンスが失われることはないだろうか。ニュアンスは言語化されず単純な部分だけが言語化されたら、その単純さは reinforce されないか。

ふたつめのバイアスは overrating. 説明されるアイデアが過剰な「正しさ」を与えられてしまいがち。これはひとつ目の単純化の特殊ケースとも言える。どんなアイデアやプラクティスも、多かれ少なかれ「仮止め」としての性質を持つ moving target である。別の言い方をすると「いちおう動いてるっぽい、たぶんこういう理由でうまくいってる」くらいのアイデアは多い。しかし単純化によって「こういう理由でこのやりかたは<正しい>」という単純化がおこりがちである。ここでも教わる側はゼロよりはマシになるのでいいとして、教える当人は本来あるべき以上にアイデアを信じてしまうのではないか。棘のある言い方をすれば教えているアイデアを信仰化してしまう恐れはないか。

この overrating の延長として、教える側にいると自分の能力を過信しがちではないか。何かを教えると「生徒」からは「尊敬」されがちである。企業などだと公教育の現場みたいなピュア教育環境ほど極端な非対称性は生まれないけれど、それでも教えることで権威は生まれる。教える側が報酬としてこのブースト現象を「利用」するのは構わないと自分は思っている。ただその立場がエゴにつながる心配はしたほうが良い。教える立場からうまれた権威の影響半径は、体感よりも小さいから。

思い入れや権威があると、アイデアを捨てるのが難しくなる。Unlearning というのはただでさえ難しいのに、それに輪をかけると色々こじらせがち。自分が大切、重要、本質的などと公に訴えてきたものを、時代がかわったからといって「ごめんもうそれどうでもいいわ」とはなかなか言えない。一言多いのを承知でいうと Uncle Bob を見よ。

最後の対価は、これは対価なのか報酬なのかはっきりしないけれど、人に教えていると教えることの専門家になってしまうことがある。人に教えること、教えることについて考える時間が増え、結果として他のことに使う時間が減る。そういうキャリアは別に悪いものではないと思うけれど、本人の望みなのかは・・・どうなの？教えるキャリアに入りつつある同世代に聞いてみたいね。

上に書いた話の半分くらいは人になにかを教えていた時期の自分の経験に基づいている。また教える立場にいる人を横から眺めておもったことも混じっている。

世の中のキャリアに関するアドバイスでは、しばしば人に教えることの価値を強調する。それを否定する気はない。けれど対価が議論されない片手落ち感は長いこと気になっていた。どんな行為にも対価はあるでしょう。

そうやって対価を議論すれば、対価を割り引いて落とし穴を避けるための議論を積み上げることができる。実際、教えるキャリアの長いひとは何らかの手を打っているにちがいない。そうした議論は、教える行為の価値とセットで語られていいのではないか。ただ価値だけを語るのは、先に書いた overrating そのものだ。

A caveat: 自分は教育リテラシーに特別詳しいわけではない。教える身分の人の間ではこうした議論は既に行われていて、自分が知らないだけかもしれない。そういう文献などをご存知の方は興味あるのでお知らせください。

急ぎのバグ取りをしつつリファクタリングの準備。

• UI. GCA Observable か RxJava かで悩む。しかしそこでブロックされずに作業を進めたい。できることすでに多いので。
• RxJava introduction は直交したプロジェクトにしていいかもしれぬ。
• それとは別に Kotlin もやりたい・・・。
• OptionsBarController について理解が深まったのでなんとかしたい。
  • しかしこれは UI refactoring が一段落したあとだな。
• CaptureModule / Capature1CC もなんとかしたい。これはカッとなった勢いで断続的にやってくかんじだなー・・・自明なやつはぱぱっとやる。
• Gut feeling としてはやはり UI refactoring と Capture refactoring をばーっとやってさっさと済ませたいかんじか。10 月いっぱいくらいで明らかなダメさを取り除くところまでいきたいなあ。

出張で話すことがあるとすれば

• Rx
• Kotlin
• あたりか。

読書記録バックログ

• How Children Succeed: Grit, Curiosity, and the Hidden Power of Character

聞き始めた途中で、むかし日本語版を読んでいたことに気づいた。

• 成功する子 失敗する子――何が「その後の人生」を決めるのか

Amazon の履歴によると 2016 年に買っている。子供が生まれる心の準備としてよんだっぽい。このときには気づいていなかったが、実はモダン根性論の本だった。モダン根性論の集大成たる Grit の出版が同年なので、まあ気づいてなくても仕方ない。ちなみに本書には Grit の作者が根性理論(?)の研究者として登場する。2012 年出版の本に登場するくらいには昔から活躍していたんだなあ。

この本は育児のガイドブックというよりは育児や教育をとりまく状況のジャーナリズムなので、いまいち actionable な要素は少ない。ただ読み物としてはまあまあ面白い。なお本書のいう character というのは要するに根性 (self control や self-awareness などの meta cognitive skill) を指している、性格というとなんとなく先天的なものに思えるが、ここでは non-academic な skill を意味するのに使っているのだね。

話は貧困が子供の教育というか発達に与える影響の話から始まる。貧困家庭、治安の悪い家庭にいると、そのストレスだけで知性が阻害される。だから貧困家庭に必要なのはいわゆるアカデミックな教育ではなく、それ以前に（今でいうところの）physiological safety なのだ、それを行政はわかってない、というような話。幸い我々はいまのところ貧困家庭ではないので、金銭以外のリスクファクターである夫婦仲はがんばって良い状態にしておかねばな・・・と身を引き締めた（いつも気にしてますが）。

そこから話は段々とモダン根性論的になっていく。早期教育の段階から meta-cognitive skill を扱うプリスクールがあるという話や、アカデミックにフォーカスした charter school KIPP の失敗と立て直し、などに触れる。また貧困地域の学校のチェスクラブを全国大会に導いた教師の話などにも多くページを割いている。また根性/characterを定量的に評価、フィードバックする学校なども紹介されている。

本書の本題とは少し外れたところで考える事の多い本だった。

むかし自分は、才能という先天的なものはアンフェアな存在で、根性（モダンでも伝統的でも）によるスキルアップは後天的に努力でなんとかなるフェアなものだとぼんやり考えていた。だから talent を強調するアメリカの（日本もかもしれないが）育児や教育には違和感があった。

しかし根性あるいは character, meta-cognitive-skill の重要性が裕福で教育熱心な人々のあいだで認識され、根性をつけるモダンな教育というものが（本書で説明されているように）研究開発されると、金を払ってそういう先進的な根性教育 (!) を受けられる学校に進学させたり、親としての資源を子の根性教育に傾けるといったことが起こる気がする、というかたぶん一部では既にやられている。

これはつまり、「本人の」意思でなんとかなると信じていた努力というフェアネスの象徴が、親の金で買える資本主義的アイテムになるということである。自分は勤務先の関係で根性あるエリートを観測する機会にまあまあ恵まれているが、当人らの生い立ちおよびそうしたエリートの子息がうけている扱いは、資本としての根性というアイデアとまあまあ合致している。

逆にアンフェアだと思っていた「先天的な才能」のようなものには、ランダムな要素があるぶん少しはフェアネスが残っているように感じる。以前は 「poverty が prevailed な学校にいる brilliant で talented な child に機会を」というようなアメリカ教育論におけるフェアネスの主張を「才能だって不公平なパラメタじゃん」と斜めから見ていたが、すくなくとも class や capitalism の限界を乱数の力で超えていける可能性のぶん、何らかのフェアさはある気がしてきた。いわゆる gift という呼称が腑に落ちたとも言える。

自分の子には金の力でもなんでもいいから根性や生命力を身に着けてほしい。がそれはそれとして、子のなかにある才能というのを見出してやるのも大切だと思うようになった。何の才能があるかはよくわからないが・・・。

ところで本書ではぱっとしない学区から躍進するチェスのチーム I.S. 318 のストーリをつかい、アカデミックなスキル（ここでは暗に暗記みたいのを想定している）ではなくメタ認知的スキル（自己認識みたいなもの）こそが重要だという話をする。チェスチームのコーチが何を子供に教えるか、訓練するかの記述がストーリーのキーとなっている。のだが・・・

これ根本的にそのコーチがガチで強いチェスプレイヤーである事実が一番重要なんじゃないのかなあ。ガチチェスプレイヤーが様々な成り行きからその（本来ならぱっとしない）学校のチェスクラブのコーチになったある種の偶然こそが快進撃の理由であって、非認知スキルとかどうでもよくね？というといいすぎだけれども、他のぱっとしない学校やぱっとしない親からするとまったく再現性のない他人事ストーリーだよね。この事例をもとに教師が非認知的スキルを教えるようになればぱっとしない学校もかわる、という暗黙の主張を支えるのは無理がある気がする。そんなことしたってチェスつよくなんないでしょ、どう考えても。

一方でこれは根性について一抹の真実を伝えてもいる: メタな根性というものは存在しない。というか根性だけをピュアに身につけることはできない。何らかの具体的な mastery を通じて根性は獲得される。この本だとそれは Chess だったし、Grit では Ballet (Violin だっけ? わすれた)だった。

自分の子にただ「根性をつけてほしい」と願うのは不毛で、本人が好きになれるもの、才能のあるものを探すのを手伝ってあげたり、それを身につける過程で根性がつくよう後押ししてあげるというのが、望まれていることなのだろうね。こうかくと大変あたりまえの話に思えますね。そうですね。

根性と才能と訓練というのはかように噛み合っている。モダン根性論の理解が深まる一冊ではありました。

読書記録。

• The Writer's Process: Getting Your Brain in Gear: Anne Janzer

大きめの変更を始めるにあたり design doc 的なものを書きたいが時間がとれず、考えがまとまらず、もしかして design doc を書くのって文章を書く人々から学ぶことがあるのでは・・・みたいな謎の気の迷いから聴いた。それなりに興味深い本ではあった。プロセスの話で、どうやって時間をとるか、どういうフェーズがあるか、というようなトピックを議論していく。

時間がないのは、ソーシャルメディアとかしてるんじゃないよ、自分にあった時間帯を見つけて書くんだよ、みたいなことをいうんだけどいやそうじゃなくて他の仕事があるせいで時間がないのだよ・・・。しかし根本的に時間は必要なので確保するしかないという現実に目を向けることができたのはよかった。

その後仕事（バグ取りなど）の忙しさは一段落したので、時間をとって書くことができた。もともとそんなに長い文章ではなく、3-5 ページくらいの短いもの。こんなものすら書けないとは・・・。

フェーズは、Research, Incubate, Structure the idea, Writing the first draft, Let the draft reset, Revise... とつづく。

自分のように大きめのリファクタリングをするだけ、みたいなケースは「調査」が必要という事実を忘れがちだが、人を説得するのに design doc を書くんだからちゃんと調べて（この場合、既存のコードを丁寧に読んで）やることを正当化したり事前に整理した方がいいね、という当たり前のことを remind できた。

アイデアを整理するにあたり、freewriting すなわちなんでも頭にあることを書き出してみるアプローチを推していて、自分はこれを以前から braindump と読んでいるけれど、そういうのも自覚的にやってみたら割とよかった。 3 ページの mini doc なんてズバっとかけそうなものだけれど、それでも一段階 freewriting / brandump を挟むとだいぶ認知の負荷が下がって良い。それにしても blog 書くのにやってんだから design doc でもやれっつう話ではある。

The Writer's Process が想定しているのはたとえば「本を書く」ように文章そのものが最終成果物なプロジェクトである。一方で自分はソフトウェア開発すなわちコードを書くという具体的かつ専門的なゴールがあり design doc はその一部に過ぎない。なので良いドキュメントを書くことに重点を置きすぎるのは的外れだし、場合によっては BDUF につながる恐れもある。特に自分はコード中心探索的アプローチ原理主義者なので事前にドキュメントを書くことに強い reservation がある。

一方で design doc を書くと決めたならそれを機能させる必要があるが、内容に何を含めるかはともかく「作文のプロセス」にはあまり共通見解みたいのはない気がする。ちょっと探した感じではこれというのが見当たらなかった。まあソフトウェア開発にとって作文は本題でないから仕方ない気もするけれど、それにしても人々はどうやって書いてるんだろうね、ドキュメント。

自分は design doc をガっと書くような気合が失われているので、コードを読んで調査をまとめたり疑問やその答えを記録して、やりたいことを箇条書きして眺め、というのを二周くらいして、それからドラフトを書く、という簡易版 writer's process がよく機能した。

それにしても立ち入った考え事をする能力が弱っているなあ。こうやって crutch を探しながら進まざるをえない人生のきびしさ。

読書記録バックログ消化。

• Oh Crap! Potty Training: Everything Modern Parents Need to Know to Do It Once and Do It Right

トイレトレーニングのやりかたに関する本。知り合いの家で見かけたのを忘れないよう Amazon の wishlist にいれておいたらいつの間にかゆこっぷ（奥様）が買って聴き、自分も聴くよう促されたので聴いた。

この話題で 300 pages / 8 hours 書けるってすごいな・・・という感慨があるが、さすがに専門家として obsess してるだけあって網羅的だった。網羅的ってなんだよと思うかもしれないけれども、そういうことってあるのだよ。

内容をかいつまんで書いても仕方ないので書かないが、トイレトレーニングには親のコミットメントが必要だぞ、という前提からはじまる本だった。重要なコンセプト（というのがあるのだよ）を何度も繰り返すので、叩き込まれる感じがある。おかげで役にはたった。若干スパルタ過ぎるのため全てをフォローできているわけではない。まあ自分よりもゆこっぷのほうが頑張ってくれた。

この本を読むと、その前に買った何らかの日本語のランダムなトイレトレーニング本はまったく情報量のないゴミだったなあと思う。インターネットの anecdotes を集めたようなやつ。育児関係で素人のコメントをランダムに載せてどうするんだ・・・。

トイレトレーニング、他の育児マイルストーンと同じくどれくらい苦労するかは子次第、および保育園/託児所次第という面もあるらしい。まったく何の苦労もせずパンツに移行したという人も、何ヶ月もてこずっているという人もいた。

ここまで書き忘れてたけど気になっていたことを思い出した。

ハードウェア集積度アップの歴史はダウンサイジングの歴史でもある。ハードウェアは小さく安くなり、イノベーションのジレンマがおこる。2008 に iPhone が登場し、コンシューマ向け計算機のダウンサイジングがおきた。Moore's Law がおわるとこのサイクルもおわるのか？

PC はある時期まではガンガン値段が下がっていったが、下げ止まった。むしろハイエンドはちょっと値上がりしてる。モバイルもハイエンドは値上がりしている一方で、PC と比べると値段の下落は最近まで続いていた。OLPC が 2005 年に夢見た $100 laptop は $50 smartphone という形で商業的に実現している。 ただ、さすがにもう値下がりしなそう。

Moore’s Law による集積度向上が続いたのなら、このあと更に小さいコンピュータが登場するはずだった。しかし CPU はもう(指数的には)速くならない。既存のフォームファクターは色々な改善を寄せ集めてがんばればいいとして、桁違いの計算性能がもたらすはずだった新しいフォームファクターはどうなってしまうのか。

Apple Watch みたいな画面つき時計や各社の喋るスピーカーは新しいフォームファクターの例である。（IoT みたいなエンタープライズ方面はもっと色々あるのかもしれないけれど詳しくないので触れないでおく。）あいつらは半導体業界の進歩が生み出した時代の子なのか？それとも半導体業界の停滞を押し切って出てきた、ちょっと無理のある存在なのか？

時計とスピーカーは同列に議論できない気がするので別々に考えてみる。

Smartwatches

コンシューマ向け計算機のダウンサイジングという点で post mobile の筆頭にいたのが時計だった。スマート時計は Apple Watch が一強で、そのほか Fitbit などの雑魚っぽいのがいるという理解。自分は Fitbit を使っている。こいつに可能性を感じるのはわかるが、どうにも遅い。ゆこっぷ（奥様）がつかっている Apple Watch をみるとだいぶマシだが、やはり遅い。

iOS 開発者の話とかを読んでいても、時計アプリは速度とかメモリが可能性の上限を決めているように伺える。今後時計の CPU は速くなるのか。ある程度はなるだろうが、指数的には進歩しないだろう。バッテリーが大きくなる様子もないからモバイル初期のような勢いも期待できない

... といっても Apple Watch はすでに 64 bit dual core だし Snapdragon も 4 core らしいけど。Galaxy Nexus (2011) くらいのイメージ。思ったより速い・・・。ただバッテリーの小ささを踏まえるとスペック上の性能を発揮できる時間はスマホ以上に限られていて、プラットホームもなるべくアプリを寝かそう殺そうとしてくるであろう。

時計のバージョンアップにも省電力志向は反映されている: 汎用アプリプラットフォームとしてより Fitness への特化を進めている。用途限定の省電力チップを足しセンサ情報を処理したりする。こうした用途限定ハードウェアではサードパーティのアプリのかわりにプラットホームの中の人が書いたコードが重要な役割を果たす。アプリはなんらかの集約済みデータにアクセスできるだけ、みたいな世界。

Smart Speakers

スマートスピーカーは時計よりでかいし給電もされるから、理論上はスマホと同じかそれ以上にパワフルになりえる。しかし収益モデルの違いなどから価格が安く、結果として CPU もケチられている。この Wiki によれば Echo Dot とかは MediaTek の ARM 1.3GHz 4 core. 上の Snapdragon Wear と同じクラスっぽい。

そしてどのみちアプリ開発者にはアクセスできない... が Alexa Built-in のデバイスをつくるために Amazon と提携するという路線があり、そういう意味で open platform ではある。ただ Echo 以外で Alexa 入りのキラーデバイスみたいのは聞いたことが無いな。

時計と違ってセンサーもあまりないし、Alexa デバイスをつくりたいならプラットホームは least common denominator になりがちで、時計のように小さいなりにがんばった SoC がやってくる期待は今のところなさそう。

Observation

コンシューマ向け Post-Mobile のフォームファクターである時計とスピーカを眺めた。これらはまあまあ売れているが、次なるプラットホームの決定版という勢いはない。今のところニッチに留まっている。

では iPhone のようなまだ見ぬブレイクスルーによってこれらがニッチを抜け出す日は来るのか。わからないけれど、半導体の進歩はあまり助けてくれなそうではある。Edge TPU や NPU のような省電力 DSA が降りてくる展開を当事者は期待しているかもしれない。しかし時計やスピーカに乗った DSA が中の人以外からアクセスできるようにはならなそうなので、自分のような外野は遠くから健闘をお祈りしていればいいかな。

そういうハイテクとは関係なく、1.3GHz x4 core の CPU はスピーカや時計に使うくらいしょぼいものであるというのは個人的な学びだった。年寄りなせいで 1GHz とかいまだにすごい速く感じてしまう。ARM かつ省電力のプロファイルだからという面はあるにせよ、これらの「遅さ」を内面化できないと危うい。ラズパイとか触った方がいいかもなあ・・・。RP4: Cortex-A72 1.5GHz x4 core.

付随する問いとして、2011 年のスマホ相当の CPU を載せている 2019 の時計やスピーカ, 8 年後には 2019 年のスマホ相当の CPU を載せているのだろうか。Moore's Law の slowdown が事実ならこの期待は満たされないわけだけれど、なんとなくそのくらいは速くなりそうじゃね？2027 年だよ? すごい未来じゃん?

未来のことはわからないね。

このブログを Letters + Fragments 方式にして 5 ヶ月。まあまあ機能している気がするものの、欠点や不満もわかってきたので微調整したい。

欠点そのいち。Fragments が若干雑すぎる。自分が雑に書けるのはいいが、ゴミ度が高すぎてこれ publish してどうすんの感がある。一方で自分が雑に書くにあたり publish する精神的敷居が邪魔になるときもある。端的にいうと仕事の脊髄反射的愚痴を書きたいのに若干はばかられる。そういうのはその瞬間に溜飲をさげるべく書きたいだけであって別に公開したくはない。WordPress として別の post にすれば非公開にはできるけれど、そんな大げさなもんじゃないのだよ。脊髄反射なのだよ。

欠点というか不満そのに。Letter をかく前に下書きというか頭にあることの箇条書きをする場合があるが、その敷居が高い。今は独立した（非公開の）Post にしているが、自分が wordpress.com 上で眺める時のノイズになりがちである。あと独立した post をつくる、という行為が僅かにめんどい。とはいえ Fragments にダンプしてしまうと自分以外には本当に意味不明なため邪魔すぎる。

不満そのさん。日々の reflection が足りてない感じがする。一日の最後に日記を書く、みたいな行為はやはり必要なのではないか。仕事日記は週に一回くらい書いているけれども、独立した Post をつくる腰の重さが頻度を下げがち。Fragments くらい日常に解けこめるとよい。

といった点を踏まえ、Fragments は非公開にして自分用のゴミ溜めとして使い（欠点 1, 2 への対処)、それとは別に公開日記をつける(欠点 3 への対処)、という風にしてみたい。公開日記はなんとなく毎日つける気力はない気はする。あと公開する必要があるのかはわからない。

まあやってみます。来週より。

WP 上での運用としては、公開日記を従来の fragments category におき、自分のゴミ溜め用に別の category をつくることにする。ほんとはここまでの fragments も非公開にしたい気がするけれどめんどくさいので放置。クビになるほどまずいことは書いてないはずだからいいでしょう・・・。

2019-11-18 追記

二ヶ月くらいやってみたところ、この「公開日記」部分は表面的には従来と大差ないことがわかったのでタイトルなどを従来の Fragments に統一した（これまでは無駄に Reflections という名前にしていた)。それとは別に非公開の "timeline" というゴミ捨て場が運用されている。

つづきもの。まず CPU と仲間たちがどうやって Moore's Law を終えたのかを雑に考える。

PC

身近なところでまず PC クラスの CPU を考えてみる。あまり良い資料がないなとおもっていたら Apple が全製品のスペックをカタログ化しれていたので冷やかす。やはり印象としては同じで、2005 年くらいまではびゅーんと伸びていく。Apple は 2006 年あたりで Mac を Intel に移行して PowerPC に見切りをつけるが、皮肉なことにこのへんで Moore's Law がおわってしまい Intel CPU たいして速くならない。Intel Core とかいってた頃。

2006 年の初代 Intel Macbook Pro が 2GHz x2 core. 2019 年の最新機種が 2.4 GHz x8 core なのでクロック数は 13 年で 2 割しか増えてない... というのは若干フェアではなく、2019 年のCore i9 は TurboBoost で 5GHz までクロックを釣り上げられるので 2.5 倍増えたと言えないこともない。そしてコア数は 4 倍。（値段は二倍くらい？)

つまりクロック周波数という Moore's Law Pop Culture の基準では 2 割, TurboBoost とマルチコアを考慮すると 2.5x4  = 10 倍増えた。13 年、ゲーム機に世代分なので昔なら周波数だけで百倍速くなったところで定常周波数は二割、マルチコアと TB あわせても 10 倍。時代がおわった感がある。

コア数や TurboBoost など色々な条件付きで性能を議論しないといけなくなった事実も Post-Moore 時代の特徴と言える。CPU にしてもたとえば Core Duo は 2MB の L2 cache だったのに対し 2019 の Core i9 は 16MB の L3 cache がある。PC 全体の性能でみると、各種バスは速くなっているし SSD という大きな変化もあった。二割しか速くなってない、というのはまったくフェアでない。13 年のあいだに 100 倍はないけど 3-5 倍くらいは速くなってるような気がする。まったく何の根拠もない主観だけど。

そういえばここ 20 年くらいの PC における大前提の大きな変化として、主戦場がデスクトップからラップトップにうつった。結果として PC といえども消費電力の影響を受けるようになったし、排熱の要件もタイトになった。結果として単純にコアを増やし続ければ良いというわけにもいかなくなった。

ラップトップの主流化はいつ起きたのだろうね。個人的には Macbook Pro あたりからラップトップに完全移行した記憶がある。世の中的には Netbook のあとに Ultrabook とかいうのがでてきて、それが普及したようなイメージ。Intel が Ultrabook と言い出したのは 2011 年。Macbook Pro は初代が 2006. まあ 2011 以前にも速くて軽いラップトップは一定程度あって、自分は VAIO Z というのをつかっていた。これは 2004 年らしい。雑にいうと 2005-2010 年の間に段々とそうなった感じだろうか。

Servers

サーバサイドの CPU はもともと PC の CPU を定数ファクター速くしたものという印象だったけれども、PC がラップトップ主流化で電力キャップされるに従い給電や排熱に融通しやすいサーバーとの差は大きくなっていったと思う。

いま見てみたら最高級の Xeon は 2.6-3.8GHz x 56 cores らしい。値段はさっぱりわからないが Arstechnica の記事をみると 36 コアのバージョンですら $10000 かららしいので、$20k - $30k くらいだろうか。消費電力も 400W とかまったくわけがわからない。一つのサーバはこれを 4 つまで挿せるらしいので、そのサーバは 200 コアくらいあるのか。すごいね。

まあ今どきサーバを買う人なんてほとんどいないわけなので次は EC2 を見てみる。Compute Optimized な C5 instance は c5.metal というやつで 96 vCPU. TurboBoost で 3.5GHz. 上に書いた上限の半分のコア数のやつくらいまでは売ってることがわかる。(ついでに GCE をみると・・・よくわからないが 64 vCPU まで増やせるとある。)

PC の初代 Macbook Pro と比べるべく 2006 年の Xeon のうち一番値段が高いやつを Wikipedia のリストからさがしてみると 7140N が $2000. 3.3GHz x2. MBP の Core Duo とコア数は同じ、動作周波数が 8 割増くらい。サーバという単位でみると、たぶんこの Xeon を 4 つくらい挿せるサーバがあったことでしょう。しらんけど。

13 年の差分をみると、動作周波数は 3.3GHz -> 3.8GHz で 2 割増。コア数が 2 -> 50 で 25 倍。あわせて 30 倍くらい。ラップトップの 10 倍よりは伸びているけれど、値段も 10 倍くらいになってるので正しく比較できてる感じがしない。雑に 2019 年製から $2500 くらいの CPU をさがすと 6240 が 2.6-3.9GHz x 18 cores. これだとだいたい 10 倍くらいでラップトップと同じ水準の成長となった。

つまりサーバの CPU はだいたい PC と同じ経緯を辿っているだが、金とデータセンターの力よくわからん。よくわからん。ででかいコア数を積み増していた。

なお Intel のサイトにはプロセスの集積度も載っている。2006 年の 7140N が 65nm, 2019 年の 9282 が 14nm. 4 倍、というか面積でいうと 16 倍?  更に 10 年遡った 1995 年の Pentium Pro は Wikipedia によれば 500nm くらいっぽいので 1995 -> 2006 は 7.5 (or 60) 倍だった。

2006 年から 2019 年のあいだにおきたサーバサイドの大きな変化は言うまでもなくクラウド。でもそれが CPU の発展にどういう影響を与えたのか、自分にはよくわからない。$10000 を超える超高級巨大 CPU を作る気になったのは仮想化のおかげだろうから、そういう広い意味で「クラウド」の影響はあるかもしれない。

クラウド業者のデータセンターは小規模なサーバファームと比べ圧倒的に電力消費にうるさいので、以前と比べ野放図に電力を使えなくなった面はありそう。それがなるべくコア数を増やし集積度をあげるという方向に背中を推したのか、それともでかい CPU を避ける圧力となったのか。まあ結果をみるに前者なのだろうな。

Mobile

2006 年にはモバイルは・・・なかった (雑すぎる近似。)

iPhone よくわかんないので Android. 2008 に G1 がでた。CPU は Qcom の ARM11 で 528MHz x 1 core. ときは流れ 2019 年の Galaxy S10 は Snapdragon 855 で "1x2.84 GHz, 3x2.42 GHz and 4x1.8 GHz".

動作周波数が 5 倍, ぜんぶのコアをあわせると 30 倍。Moore's Law の期待値 100 倍には届かないにせよ 13 年で 10 倍の PC よりは健闘している。毎年でる電話機の新しいモデルは前の世代より体感できる程度には速くなっているから。その経験則とも一致している。

この健闘はどこから来るのか、雑に想像してみる。ひとつにはモバイルに流れ込んだ資本の勢いだろう。PC 全盛の時代の ARM ファミリーは Intel に比べたらたいした技術力はなかったろうが、モバイルの隆盛にともない金が流れ込んで相対的な技術的洗練が進み、Intel との距離を縮めた。別の言い方をすると、限界までアーキテクチャ的な無理をしてきた Intel に対し素朴さを保ってきた ARM 勢が、その素朴さ貯金を取り崩して性能を手に入れた。

もうひとつはバッテリーサイズの巨大化。ラップトップ PC が薄型化によってバッテリーサイズを削られたのに対し、モバイルは画面の巨大化に伴う筐体サイズの増大に助けられ、バッテリーサイズを増やせた。おかげでマルチコア化など性能を電力で買うアプローチを積極的に使えた。

結果として PC とモバイルの距離は縮まった。性能ポップカルチャーの北極星 Geekbench によれば Macbook Pro 2019 のスコアが 6900 で Galaxy S10+ が 2100.  3.3 倍くらい。価格差はもっとある・・・のはいいとして、たとえば G1 と初代 Macbook Pro なんてたぶん 10 倍以上差があったことでしょう。

GPU

進歩してるんだろうけれど、よくわからない。すごい雑な印象として、少なくともモバイル CPU くらいのペースでは速くなってるかんじ。Intel CPU ほど終わってしまった印象はない。

計算の性格上 CPU と違って容赦なく並列度を上げていけるので、並列化に重点を置いて増やしている印象がある。あと AI/Crypto で存在感を増し、かつ Cloud 到来にともないデータセンターの中でバスパワーとかの遠慮なく電力を使えるハイエンド機がでてきたのも高速化に寄与している気がする。

あと CPU と比低レベルの ISA とかを公開していないぶん互換性の制約がすくないので、回路の非効率は CPU よりすくなく、そのぶん性能の伸びがよい、という面はあるのかもしれない。

それ以外はターゲット領域の CPU に足並みを揃えて進歩してるのではなかろうか。つまり: よくわからん。

FPGA, ASIC and Domain Specific Architecture

サーバや PC の世界ではごく限られた用途のニッチという理解。一方モバイルの SoC は面積の半分以上が CPU および GPU 以外すなわち ISP などの ASIC なので、モバイルにおける Moore's Law の文脈でこいつらの存在感は無視すべきでない。

が、全然わからん。ビデオの codec などは PC でもモバイルでも CPU (のふつうの命令を処理するところ/AP)以外がやっているわけで、それなりに予算を使っているはずなんだけど。

TPU, NPU や PVC のような DSA は emerging technologies なんでとくに歴史として振り返るものはない気がする。

SIMD

CPU は引き続き AVX や Neon などのメディア処理専用命令を足し続けて動作周波数あたりのスループットの改善を試みた。AVX は最初のバージョンは 2011 年, AVX512 というのが 2016 から入り始めて、じりじり命令を増やしている。2011 以前にも MMX や SSE があった。ARM も昔から NEON があり、AVX512 に対応するものとして SVE というのがあるらしい。

System

システム全体でみると、歴史的にはそもそも CPU 以外、つまり IO とかが性能のボトルネックという場面が多かった。それを補填するために CPU はでかいキャッシュを積み続けバスも太くなり、その傾向はおおむね続いているという理解。バスについて考えると、モバイルは SoC なので標準規格に引きずられず自分の都合で色々できる利点がある。データセンター業者も非標準な I/O をつかいがち。

CPU がもたもたしている間に I/O は高速化をつづけ、ギャップは小さくなっている気がする。ストレージだと SSD や NVM. ネットワークも 1Gbps から 10Gbps, 100Gbps と規格が改善し、AWS もインスタンス間は 25Gbps とかいってる。データセンターについてはクラウドの台頭に伴うこうした著しいシステムレベルの改善が CPU の停滞感を隠してきた印象。

モバイルも、よくわかってないけど色々進歩してるんじゃないの？そういえば 3G から LTE になったのは大きかったね。これも 10 倍以上 100 倍未満の改善。モバイルじゃないけどいわゆる「ブロードバンド」な帯域は 15 年でどのくらい速くなったのだろう。いまいち調べる方法がわからない。

Observation

「なにがおきたのか」という当初の疑問に自答すると:

まず上に書いたスペックの二点比較だけからは自明ではないが当たり前の事実として、動作周波数上昇の slowdown はいきなり起きたわけではなく、徐々におきた。CPU 業者はあの手この手で slowdown の影響を補填しようとした。

わかりやすいのがマルチコア。動作周波数の停滞に伴いコア数が増えた。ただ PC やモバイルでは思ったほど増えず、せいぜい 8 コアくらいが現状。サーバ側は 100 コアみたいな勢いのでかい CPU もあるが、値段も消費電力もアホみたいに高いので CPU が期待通りの性能上昇を果たしたと解釈するのは無理がある。どちらかというと昔からある HPC/スパコンみたいなジャンルに Intel が踏み込んでいったと見る方が正しい。

消費電力の壁から、可変周波数が普及した。Intel は TurboBoost があるし、ARM の一族もふつうにクロック数が上下して最大周波数での可動時間はほんとに短い。動作周波数を下げるだけでなく一部のコアを止めることもできる。

ARM 家は可変長クロックにくわえ Big.Little のような非対称コアが現れた。Snapdragon 855 にいたっては Prime 1, Gold 3, Silver 4 みたいな三段階構成。

同一クロックでのスループットを稼ぐ SIMD は昔からあって特に Moore's Law 関係ないのかもしれないけれど、引き続き強化されつづけている。

システム全体でみると CPU の存在感は相対的に下がり、グラフィクス以外の用途、というか 主に ML のおかげで GPU がもてはやされるようになった。特にデータセンターでは PC 相手には役不足なかんじのでかい GPU も重宝されている。モバイルも同様に GPU の存在感は増しているし、GPU だけでなくメディア用途などの ASIC も SoC の面積予算を多く使っている。

単純なコンピュートだけでなくシステムレベルでの改善もデータセンターを中心に進んだ。ネットワークもストレージもだいぶ速くなった。15 年のスパンだと 100 倍まではいかないにせよ 10 倍よりは改善している。モバイルにしても LTE がやってきた、今年から来年にかけて 5G がくることになっている。家庭のブロードバンドはよくわからない。

というわけで...

CPU の動作周波数停滞は CPU 内外の数多の改善によって覆い隠され、計算機業界全体としてはこの 15 年もひきつづき進歩を実感できた。PC は動作周波数依存のパラダイムから脱しきれずに停滞感があったが、サーバサイドはデータセンターへの集約にともなうアーキテクチャの刷新がシステム全体の性能を高めたし、モバイルは雑魚っぽいところから本気度の高い SoC へと進歩し、デバイスの巨大化によるバッテリ容量の増加もそれを助けた。

ただし Moore's Law のようなわかりやすく乗っかりやすい単一の指標はもうない。レイヤのあちこちでおこるブレイクスルーをその周辺にいる人々が活用し、産業全体としてなんとなく前にすすんでいるのだろう。

こうした変化をプログラマやソフトウェア開発チームはどのように受け入れたのか、については別項で。

少し前に Podcast で Reality Engine の論文をよんだとき、この時代の CPU クロックのあがりっぷりにビビった。いわゆる Moore's Law というやつ。Mooore's Law は半導体の集積度について言及しているのでそれをクロック数として解釈するのはポップカルチャー的ではある。ただ近似としてはあってる。

Podcast では Reality Engine の比較としてなんとなく PS1, PS2 を引き合いに出した。その延長としてゲーム機を例に考えてみる。

ゲーム機、だいたい 6-8 年に一回くらい新しい機種が出る(1983 にファミコン, 1990 にスーファミ,  1994 に PS1,  2000 に PS2, 2006 に PS3, 2013 に PS4. 2 つの系列を混ぜてる雑さは見逃されたし。) このサイクルに Moore's Law を当てはめると、だいたい世代が一つ上がるとクロック数がひと桁増えるかんじになる。6 年 = 4 Moore Cycle = 16 倍、みたいな計算。スーファミの CPU が 2MHz, PS1 が 33MHz, PS2 が 300MHz, PS4 が 3200GHz なので、この間のクロック数はじっさいひと桁づつ増えている。

このあと PS4 の CPU は 1.6GHz x 8 core となり、クロック数が下がってコアが増えた。CPU アーキテクチャが PPC から x86-64 にかわったので厳密にクロック数で比較はできないが、ひと桁は増えてないという雑なレベルでは間違っていないとおもう。そしてコア数がひと桁近く (8 倍) 増えている。

この数字から判断するに, Moore's Law は 2006 から 2013 の間に終わったと言える。議論の雑さにも関わらず、これは自分の肌感覚とも合っている。

自分は Moore's Law が最後にフルスピードだった 2000 年代前半に大学を卒業した。だから自分の中の色々な常識や期待は Moore's Law を織り込んでいる... とおもっていた。でも Post Moore な 2019 年にこうしてぼんやりプログラマをやっていて、クロック数が倍々で増えていく当時の身体感覚はすっかり失われていている。そういえば学生の頃はクロック増えまくってたわ。最近のラップトップとか全然速くなんねーな、と思いつつ受け入れてたわ。

こんな大きな変化が起きたのに何事もなく生き延びている自分と業界にびっくりする。まあ何事もないわけでなく、大きな変化は起きたのだろうけれども。でもあんまりそういう体感ないじゃん？あたしの感性にぶすぎ？

いい機会なので、何が起きたのかを自分の中で整理してみたい。関心は大きく分けて２つある。ひとつ目はハードウェアの中の Moore's Law がどう終わったのか。ふたつ目は、プログラマというかソフトウェア開発はその事実をどう消化したのか、あるいは消化できていないのか。

この２つを言語化する気力があるかわからないので、とりあえずは「法則の時代がおわってたことにも法則が成り立っていたことにも同じくらいびっくりした」という事実だけを記録しておく。

追記

がんばってかいた:

• How It’s Been Ending (2) – CPU
• How It’s Been Ending (3) – Downsizing
• How It’s Been Ending (4) – Dennard Scaling
• How It’s Been Ending (5) – Software Development
• How It’s Been Ending (6) – Me
• How It’s Been Ending (7) – The Ecosystems

「週末一日働くかわりに平日一日休みたい」というようなことを言う人がいる。自分もたまにそう思うことがあった。今日、子を暑さから逃すため平日に仕事を休み涼しい Monterey の水族館にでかけたところ、いつも混んでいてうんざりしがちな水族館が人影まばらなすばらしい場所になっており感動。この「平日週末スワップ」という（実現することが稀な）願望のことを思い出した。

これは、昔は結局やることはあまりなかったし、今もできる気がしない。なぜか。

昔、というのは妻子を持つ前かつ東京で働いていた頃だけれども、スワップをしたい動機は主に仕事の生産性アップだった。人がいないところで集中して働きたいという。平日に休みがほしいとは特に思わなかった。無趣味ひきこもりだったので避けたい週末の人混みもさほどなかったし、有給もだぶついていたから平日たまにどこかいきたいならふつうに休みを取ればよかった。労働時間の柔軟性もあったから休む必要すらなく、午前中に用を足して午後から遅く働くオプションもあった。

有給が少なく労働の柔軟性のない仕事をしていた頃も同じようなことを考えたが、当時はそもそもスワップを実現できる人事的な柔軟性がなかった気がする。自由のきかない零細中小企業とはそういうもんである。

今はどうかというと・・・。理論上はそれなりに制度の柔軟性があり、かつ自分は平日の休みを欲しているが、いざやろうと考えてみると腰が重くなる。なぜか。

まず仕事はそれなりに調整しないといけない。チームに周知するくらいは必要。結果として若干のカルマを消費する。しかし自分はカルマに余裕がある気がしていないので、そうした調整活動に身の危険を感じてしまう。巨大な締め切りが過ぎ、緊張が低い時期ならまた違うかもしれないが。あと休日に仕事をする側で家族の logistics をなんとかするのも面倒。

全体的に、得られるものが norm から外れるコストを justify していないという gut feeling がある。なぜ得られるものが重要に思えないのかというと・・・有給とって休めばよくね？と思うからだろうなあ。そんなにバンバン使えるほど有給があるわけでもないので気のせいにも思えるが・・・。

あるいは具体的に行きたい場所がそれほどない曖昧な状態で休みの確保というめんどくさいことを考えているから気が乗らないのであって、もうちょっと平日に行きたい具体的な場所リストが育ってくるとがんばってやりくりする気も起こせるかもしれない。

製品寿命が伸びてくると登録されたバグの数がどんどん増え手に負えなくなる。

対策として、まずはバグの優先度の解釈が厳密化される。たとえば P3 は「いつかやるかもしれないバグ・新機能」みたいな扱いになる。バリエーションとして「いつかやるバグ」というマイルストーンをセットすることもある。GTD 信者には "someday maybe" といえば通じるだろうか。

症状が進行すると本当にいつかやりたいバグと単に放置されているものの区別がつかなくなる。この段階での対処は色々ある。

たとえば「いつかやるバグ」とは別に「冷凍保存したバグ」というマイルストーンが追加される。「もうやりません」という意思を明示するぶん、ある種のコミットがある。バグを登録した人や新機能を要求した人はその意思を受取り、文句をいったり諦めたりする。

より激しい対処として、一定期間なんのアクティティビティ（コメントなど）が観測されなかったバグを一律 "Obsolete" とマークして閉じる「バグ破産」というアプローチも見たことがある。これはほんとにひどい話だが、よく考えると「バグ破産」で閉じる行為自体がひどいというよりは、そこまで手に負えなくなってしまった事実が問題に思える。

ここまではチームや組織単位での対策。これらとは別に、自分は個人的にバグを弔うやりかたを一つもっている。それは「墓場バグ」をつくること。

どうにもならないが、度々報告される問題がある。自分の仕事だと「遅い」というやつ。わかってる。手も打ってる。良くする計画もある。でも完全には治らない。原因はまちまちだが、はっきりもしない。そういうバグのために自分は「遅いバグの墓場」というバグをつくっている。新しい遅さバグが報告されたら、ログを睨んで何らかの診断を下し、特に新しい情報がない場合（すなわち大半の場合）はその遅いバグを「墓場バグ」の重複報告としてマークする。「遅いバグの墓場」は、遅さの種類に応じて複数個用意してある。

診断をコメントし、ありがとう、がんばってるからよろね、と挨拶してバグを墓場バグに重複登録 (dedup, de-duplicate) する。バグを登録してくれた人も納得するし、バグも成仏するであろう。たぶんね。

「なんか画面の表示が乱れる（がちょっとつつくと直った）」というバグも度々うけとる。これも原因はよくわかっていない。アプリのレイヤではなく OS のバグであることはログから確かなのだが、では OS の何が壊れているのかはよくわからない。こうしたバグは、受け取られるたびに色々な人の間をたらいまわされ、各段階で各人が時間を無駄にする。不毛なので、自分のところに来たときに「いつものやつ」だとわかったら「描画乱れの墓場」に dedup する。

こうした墓場バグがあると、問題のカテゴリに名前がつくおかげですくなくとも「似たような問題前にも見たな・・・」みたいなことが減る。そして既存の類似バグに dedup するよりは後腐れなくていい。コメント欄も荒れにくいし。

これらの墓場バグ自体は、冷凍バグなりなんなりの「やるきはないが閉じないバグ」に所属している。明らかに suboptimal な所作だけれども、生きていくために目をそらしたい現実もある。あのバグたちにはせめて成仏してほしい。

なお遅さバグについては、直す気はあるという意気込みを込めて墓場ではなく動物園と名付けている。"Zoo of the slowness"  みたいな。Graveyard だとしょんぼりしちゃうけど、Zoo はなんとなく楽しげでよい。今日も速くしてくぞ！

• The Math behind Project Scheduling, Bug Tracking, and Triage | USENIX このトークみてみようかな・・・。

https://twitter.com/kazuho/status/1170911284713230336

そうっすね・・・という。自分も upstream するみたいな言い回しはそもそも WK なり Chrome なりで身につけたはずだが、もうマインドセットがオープンソースじゃなくなってるなー。

via Blow to 10,000-hour rule as study finds practice doesn't always make perfect | Science | The Guardian

モダ​ン根性論ポップカルチャーのはしりのひとつ Outliers (5000 Amazon reviews!) が論拠としている 1993 年の研究を replicate しようとしたけどだめでした、という研究の話。ふーんとリンク先の論文も眺める: The role of deliberate practice in expert performance: revisiting Ericsson, Krampe & Tesch-Römer (1993) | Royal Society Open Science. 割と面白い。

• 元研究、およびこの研究は great, good, less good の violinist をあつめて比較している。これどうやってあつめるかというと: Great と good は一つのエリート音楽学校からサンプルする。具体的には学校の教師にノミネートしてもらう。Less good はエリートではない音楽学校から適当にサンプルする。
• モダン根性論用語になった "deliberate practice", 具体的には "teacher-designed practice" だった。対にあるのは self-guided practice らしい。Deliberate practice ってなんとなく自分で工夫して負荷を高めるもののように考えていたけれど逆だった・・・というか、もともとは Delibrate practice の定義は存在しなかった、あるいは主張に応じてコロコロ変わった、らしい (4.1)。この論文は元論文著者 Ericsson の雑さを強く批判している。
• 練習以外の activities についても時間の情報を集めている (table 3). たとえば "意識の高い会話 (professional conversation)" みたいのもはいってる。

この論文のキーとなる発見は

• Good および Great 勢は Less Good 勢より圧倒的に練習している。
• Great​​ 勢と Good 勢は practice も teacher-designed practice も大差ない。（むしろ great 勢の方がちょっと少ない。)

この論文の趣旨はオリジナル論文の主張の replication なのでそのほかの点については細かく議論していないが、外野としてグラフを眺めるとなかなか趣深い。特に "3.5. Retrospective estimates of practice during development" のセクション、自己申告による練習時間の経年変化。

• Best 勢は人生序盤 (8 歳くらいまで) の teacher-designed practice の量が Good/Less Good よりだいぶ多い。しかし 12 歳あたりで Good が逆転する。つまり violin で Great になるには幼少期に教師に鍛えられるのが重要なのではないか。逆に一定程度年をとったあとにキャッチアップしようとしても難しいのかもね。この一定程度というのが 12 歳であるあたりに violin 業界の厳しさを感じるが。
• Good 勢の練習量は 15 歳あたりから Best よりもだいぶ多い。(二割くらい違う。) そして Good の練習量は 18 歳に向けてどんどん増えていくが、そこで頭打ちになり下がり始める。一方 Best 勢の練習量（Good 勢より少ない)は 18 歳を過ぎても下がらない。ボンクラ努力家が 18 で自分の限界に気付かされる様を見るようで気の毒。

音楽の世界は厳しいなあ・・・。

あと Best と Good が同じ学校の同級生で、Less Good は別の学校という事実にも趣があるね。Good/Great と Less Good の差はほとんど peer pressure で説明できそう。実力をつけたいなら厳しい環境に身を置くのが大事だね。

プログラマ、音楽家と比べるとほんとに平和なものでよかったな・・・と思う。

• Best でなくてもふつうに生活できる。
• 幼少期にプログラミングを教えてくれる teacher とかいない (少なくとも一般的でない). Teacher-designed practice もあんましない。

Best と Good を violinist を区別するものが (12 歳以降の) practice でないならなんなのか。幼少時の訓練なのか「才能」なのかそれとも他のなにかなのかはよくわからないが、音楽のように成熟した世界ですらこれなのだから、プログラマみたいに雑で新しい世界でそこそこの成果を出したいなら、いくらでもやりようはあるのだろうね。まあ AI 方面はアカデミアという超成熟した過当競争世界にも見えるけれど。

「後輩を指導する」みたいなことを基本的にあまりやらなくてよい立場にいる。誰かを指導する行為には副作用があり、それを被らずに済んでいる事実を appreciate している。

多くの人々が無意識に払っているであろう「教えることの対価」についてそのうち書こうと思っていたが、最近は逆側にある「教えないことの対価」に出くわしがちなので、まずそれについて書く。

隣の席の同僚の書く UI まわりのコードにやや不満がある。性能改善のために UI まわりもさわりたいのだが、変更に弱くバグりがちで困っている。これはもうちょっと MVC とか MVP とかなんか architectural pattern みたいのも考えてくれや Flux にしろとはいわねえからよ・・・という抽象度高めの不満と、それコピペしたり雑に分岐する前にもうちょっと考えて整理してくれや・・・という細部への不満がある。

抽象度高めの方は件の同僚以前に昔からそうなので、これは「なんとかしなかった」the lack of action に対する不満であり、期待値が高いだけと言える。細部のもうちょっとなんとかならんのか感はモバイル専業でやってきたおっさんとかにありがちな症状なのだが、その同僚は割と若い。年齢関係なかったねごめんね・・・。つまり勤務先でモバイルをやってるだけだとこういうコードになってしまう気の毒さ。

おっさんのコーディング傾向に口を挟むのは不可能だと前のチームで学んだ。しかし若者はまだ救えるかもしれない。フィードバックしてあげたい。しかしあまり良いフィードバックをできる気がしない。その同僚は、成果はだしている。本人はコード品質で struggle を感じている様子はない。だから下手に口を挟んでも余計なお世話。コードレビューとかで場当たり的になんか言うことはできるが、もうちょっとこう、あなたのコードはこういう傾向があるからこれ読んで勉強のうえ補正してちょ、きっといいことあるから、みたいな一歩さがったフィードバックを、本人が有用性を感じられる形でできないものか。

こういうの、たとえば自分が昔そうであったように、ランダムな新卒入社メンバーをメンターする、みたいな立場で組織から「新人教育」を期待され続けてきたなら、時間や労を割いて人に何か教える方法を考えるだろう。それを 10 年 20 年と続けていたら、バンとアドバイスの一つもできそうな気がする。そしてその先輩的アドバイスは組織と文化の力で割と聞き届けられがち。昔は先輩面してそういうことを考えていた時期がある。

しかしそういう身分を脱し 10 年ちかくヒラ暮らしをしているので、いざ誰かにアドバイスをしたいと思っても壁を感じる。他人のやり方に口を挟むことに強い抵抗があるし、その抵抗を乗り越えられる説得力ある言説を自分の中に積み上げられていない。

自分はオブジェクト指向なり関数型なりのデザインの本を一定程度読んでいるし、いわゆるプログラミング指南書もいくつか読んできた。ただ基本的には読んで感心して影響を受けて内面化して忘れる、というサイクルで消化しているため、他人のコードの傾向から適切な文献なり文献内の「ベストプラクティス」なりを論拠として引用はできない。

「引用できないなら身についたとはいえない/消化不良なのでは」という批判は、何割かは正しい。一方で他人を説得する必要がないなら、その場で納得して結論を受け入れコードの書き方を変えれば、それは内面化され身につく面もある。これは若干 cargo cult 的な危険を孕んでいる一方、少なくとも読んだ瞬間にはある程度批判的に評価しているはずで、その時点の前提が崩れない限り問題はない。そして問題があれば、それは体感できる・・・こともある。

こうした雑な学習はコストが低いので、かならずしも割は悪くない。人に教えられないのは雑さの対価といえる。逆に言えば、雑なまま前に進んでいけるのが人に教えずに済む強みである。

表題にもどると、人に教えないでいると仕事のプラクティスなどを説得力ある形で言語化できない、かもしれない。その機会が少ないから。結果としてチームメイトなどへの影響力が下がる、かもしれない。

しかしこの隣人のコードをなんとかしないと日々が厳しい。どういうオプションがありうるか。

• 適当にぐぐってでてきたアドバイスを鵜呑みにして伝える。職業倫理的に NG な感。
• いい機会だからと必要文献をばーっと買い集めて読み、整理してみる。これは興味深いプロジェクトな気がする一方「雑なまま進める」という自分の利点を損ねてしまう気もする。時間のない身に割が合うのか。
• 高位のフィードバックは諦め、必要に応じて適当に相手のコードをレビューしたり書き直したりしつつ付き合っていく。とりあえず書き直しても大丈夫な程度には関係性を維持できている、というか相手が不遜じゃないのが幸い。

なんとなく個人をピンポイントで先輩面するのは企業文化的にあわなそう。あと現状のコードのだめさはその同僚のせいだけでもないので、なんか言われると腹も立とう。もうちょっとこう、チームに対してなんかを提案する、プレゼンするのが筋に思える。そしてこれは主張の品質の bar を一層高くするなあ。しかし他人のやりかたに口を挟む以上、この高さは必要なものに思える。

最後のオプションすなわち現状維持で当面はいいとして。コード品質に関するアドバイスたちをレビューし、現時点での妥当解のスナップショットを研究するのは面白そうではある。しかし時間の無駄な気もする。なんかもうちょっといい切り口ないかな。うーむ・・・。

OS リリースという節目も来たことだし、まっとうな会社員としていいかげん OS の dogfood を再開(一年ぶり)しようと考えてみるが、どうにも gut feeling が拒絶してくるなあ。この胃の痛さの出処はなにか。

外出先でいきなりバッテリーが drain されるなどして Google Map が使えなくなる恐怖。通知まわりのバグで奥様からの緊急連絡に気づき損ねる恐怖。写真とって、といわれてカメラが動かない/あとで写真が消える恐怖。(カメラ周りは過剰反応している可能性がたかい点に注意されたし。）

これはリリース前の OS が理不尽に不安定なせいだけではなく、電話機というものが生活に密着しており、かつ自分の生活に精神的余裕がないという事実のあらわれに思える。となると、やはりバックアップにちゃんと動く安全なデバイスを持って piece of mind しつつ、地雷バージョンを日用したい。つまり、ふだんは不安定な子を使う。しかし鞄の中にはつねにちゃんと動く子が入っている。

最初の悩みは一枚しかない SIM をどちらに差すか。まあ答えはバックアップ機一択なのだが、そうすると地雷の子を使いつづけるよう自分を仕向けるのが難しい。SIM を複数使える MVNO に乗り換える, 会社から SIM を支給してもらう...  といった選択肢は色々人生をややこしくしがちなので今は保留する。SIM なしで日用できるのかというと、自分の平日はだいたい under Wi-Fi なのでだいじょうぶです。

たぶんバックアップ機からは本当に重要なアプリ(すなわち地図とテキストとカメラと写真)以外をすべて消し去り、机の上におかなくてもよいようにすることだろう。というか前そうやってた気がするのだがなぜやめてしまったのか・・・と考えるにそのデバイスでしか起きないとされるバグの調査で wipe してしまったんだな。そういうことは滅多にないんだけど年に一回くらいはあり、年に一回あれば dogfood の習慣を断つのに十分なのだった。

ついでにバックアップ機からはすべての BT ephemeral を消し去るのも良いだろう。

最近うまれた新しい問題: 自分はメッセージングを SMS に統一してしまった！なぜなら Hangout が滅びてしまったから・・・。これだと SIM のないデバイスで不都合がある。SMS 以外で奥様への負担の少ない選択肢を考えないとなあ。おとなしく FB Messenger を使うか。やだけど・・・Signal や Telegram つかいたいなー・・・しかしそういう話ではないのだよ・・・。

バックアップ機は Pixel 2 XL. 地雷機は新デバイス...はなくすとやなのでしばらく Pixel 3 を使い、新しいのが発売され次第そっちにスイッチするとしよう。そしてアプリのセットアップがめんどいので発売まではあまり色々インストールせず質素な電話機生活をしときます。

追記

二台持ち再開した。