2019/10/30

失敗について振り返る

過去にした失敗について振り返るというのは、いつも大変だ。自分のできていない面と向き合い、フィードバックをもらい、変えていく。メモがてら思いついたままに書いておく。

最近の失敗はこれだ。最近というのはここ5年くらいの感覚で書いている。

* 大きな技術の波に乗らなかったこと。201x年でいうとiOS / Android。その代わりWeb技術を常に追っている。個人の興味としては以前そうなのだが、事業を作るエンジニアとしては視野が狭かった。螺旋の話でもある。
* 自分の考えによってソフトウェア主体にチームを変えられるきっかけがあったのに、動けていなかったこと。特に2014年から2015年にかけて様々な考えをしていたのにもかかわらず、なかなか他の人の行動を変えるまでに至らなかった。これは最近「ソフトウェアファースト」を読み、省みたことの一つだ。エンジニアから周りの大きな意思決定を変えられたのか?
* 行動しない時間の長いこと。手を動かして実践している時間がどれくらいあったか?動いている時間もあったけれど、圧倒的に考えて動けていない時間が長かったのではないか。試行回数が少なかったのではないか。

最近の良かった点はこれだ。

* 複雑なアプリケーションをシンプルにする方法について対面し、考え抜き、判断力を増すこと。判断力は実践で育つ。チームとしての判断も含め、常に考え続けること。大きな仕組みに育つアプリケーションを作り続けられていること。
* 自分の力だけでは解けない問題を解けるようになったこと。事業と組み合わさってエンジニアリングの力を発揮することについてトライ・アンド・エラーを重ねられていること。たとえばその瞬間にはやらないほうがいいと思っても、一晩空けるとまだ続けたほうがいいと思うこと。
* 自分よりも若い世代から学ぶこと。新しいツールセットや熱狂が生じるところへ飛び込んでいる人たちから学ぶこと。例えば今は未熟な方法に思えても、その中のいくつかは将来の自分のものづくりに影響する。

あとから振り返ると失敗のほうが多いかもしれない。偏りがあるからこそ、学べていることもある。しかし時間だけは同じだけ各人にふられているなかで、自分の選んだ時間の使い方の選択は良かったのかと常に考えている。

Netflixのビル・ゲイツ特集をみていると頭を殴られた気持ちになる。さあ仕事をしよう。

2019/05/18

判断力をつけるには - Evan Priestley氏への質問「どうやってプログラミングを覚えましたか」への回答を読んで

数日前に、Evan Priestley氏への質問「どうやってプログラミングを覚えましたか」への回答を久々に見て、改めて思うことがあったので書いておく。読んでない方は是非読んでみてほしい。

https://web.archive.org/web/20121111232231/http://ktamura.com/epriestley.html

日々ビジネスに関わるシステムのデザインを生業としていると、自分の設計がその後に大きな影響を与えることを感じられる。この文章では端的に、作り込みすぎる「オーバーエンジニアリング」について語られている。これが実に面白い。

PHPについてのフレーズも実に良い。

> フェイスブックでは、ぼくは「一番PHPを嫌っていないエンジニア」と自称していた。ぼくのことを「PHPバカ」と呼ぶ同僚もいた。ぼくは別にPHPのファンではないが、PHPに関しては膨大な知識を持っているので、他の言語を学ぼうと一念発起するには、それこそ膨大なエネルギーがいるのだ。それに、どのプログラミング言語を使うかってのは、多くの人が考えるほど重要ではないと思う。ぼくの経験上、一番PHPをバカにし、言語の重要性をうそぶく連中は、大体自分たちが提唱する言語でもロクな仕事ができないことが多い。

相変わらずPHPというのは嫌われがちな言語だ。僕は10年近く(気がつけばもう10年もプロダクションでPHPを書いている)この嫌われがちな言語を書いていて、給料をもらってきた。ああ、こんな端的にロクな仕事もできないだなんておこがましくて言えないんだけど、これはよくある話だ。これまた最近話題になったWorse is Betterだって、言語それ自体ではなくあるシステムに関するアプローチを話しており、ところでどの言語でも過剰に書く人あり、「複雑巨大システム」は生まれる。実践、あるいは仕事のなかで複雑巨大システムに触れ、その問題に気がついていて、少しずつでも改善をできるならば、そのコードに食らいついて改善できるならば、「判断力をつける」ことにつながっているのだ。

> ぼくが知る限り、判断力をつける一番の方法は、自分で設計したシステムを長い間メンテすることだと思う。

例えば自分の設計したシステムを半年後に関われないなら、設計から得られるフィードバックは限られてしまう。特にデータモデリングの問題は時間が経てば経つほど設計判断の良し悪しがでてくる。果たして設計時点でどの程度システムにまつわる変化を想像できていたか。あるいは変化に備えすぎていないか。自分の設計したシステムでなくとも、当時の設計判断がどうしてそうなされたのかを汲み取り、自分の次の設計に活かすことができるか。判断力をつけるヒントは身近にあるが、それを拾って力にするのはなかなか難しい。

> 限りなくシンプルなデザイン(as simple as possible but not simpler)というのはなかなか教えられるものではなく、大方経験を重ねて覚えるものだ。

僕が働いていて最も素晴らしいと感じるエンジニアはすべて、限りなくシンプルなデザインを骨の髄まで染み込ませている。彼らの書くコードは常に「読みやすく」「わかりやすい」。なぜなら向かっているコトに対して向き合い、率直に問題を解いているからだ。何が問題であり、何をすべきであり、なぜそうしたかがわかるようにかかれている。コードコメントからは「なぜそうしなかったか」もわかるようになっている。コードそれ自体がシンプルであることは、システムを掘り下げ、理解し、必要な複雑さを計算し、感じ、噛み砕かなければ実現できないものだ。

シンプルなデザインを実現するための判断力を育てる一番の方法はペアプログラミングだ。なぜその方法で書かれたのかを、コードレビューで気がつくことは難しい。気がつけるならば、その実現方法の素晴らしさをわかるならば、自ら体現できるからだ。しかしシンプルさは、見た目のシンプルさ故に、簡単にみえる。簡単に表されているコードでも、その簡単さを実現するための設計プロセスを知るには時間がかかる。すばやく判断を積み重ね、あるいは無意識に良い方向に向かう程にそれを繰り返し、意識的な判断の必要な層を少なくしていった先に、頭に積み込めるスタックの範囲をスイートスポットにたどり着けるところまで縮めていって初めてシンプルな設計が現れる。次元の違う設計を体感するには隣で考えをトレースしようとすることが最も近道だ。しかしながら、あくまでそれは過程の体験であり、運用した時間をショートカットすることはできない。

力をつける方法は継続しかない。好奇心を持ち続け、思考し、実験し、これを繰り返すことでしか血肉にならないのだ。

2019/04/27

さよならファーストプレイス

灯を消したその瞬間に、初めてその場所の大切さを知る。

なぜか人が集まってしまう社内バーAJITOは本当に愛されている場所だった。18時半になると少しずつ人が集まってきて今日の仕事やら世相や流行りのゲームについてなんやかんや話をし、楽器をいじり始め、パソコンいじりをし、酒を飲む。今日もまさにそんな一日だった。引っ越しの荷造りを終えて、どの座席におくるのかをシールで貼り、いらないものをひたすらに捨てた。

今日はファーストプレイスでの最終日だった。オフィスがゴールデンウィーク明けから移転するためだ。ファーストプレイスは自分が社会人としてはじめて働き始めたオフィスだ。いろんな人と出会い、仕事をし、考え、議論し、多くの時間を過ごした。

最終日だとわかっていてもなぜか実感がわかない。しかし今日は変だった。夜中に人が増えてきて、そういえばAJITOに飾ってあるトロフィーなんかを梱包しないとねと作業を始め、もう終わる平成の懐メロをiPadが流し続け、倉庫の奥にあった賞味期限切れの非常食にお湯を注いで食べた。246の上を走る首都高速をみると、10連休に差し掛かる金曜日の夜らしい渋滞をしていた。電子ドラムはしまってしまったがフレームドラムとカホンを出して、あるいは梱包したはずのギターを取り出して、適当な歌を弾いた。

最終日だからと冷やしたビールがまだ冷蔵庫に20本ほどあったのでみんなで飲んだ。日本酒が余っていてそれも飲んだ。赤ワインのスパークリングもあった。コップはしまってあったので、オレンジ色のファンタの紙コップでスパークリングワインを飲んだ。水はもうなかった。

そしていろんな話をした。今の事業のこと。スキーのこと。10連休にSEKIROをなんとかクリアしようということ。これからの将来のこと。

ふとAJITOの船のオブジェを眺める。なんでこんな大きなものがオフィスのフロアにあるんだろうねとつぶやく。当時一番奇抜なデザインだったものを選んだんだよという。一応分解できるつくりになっているのだが、もう船は処分される。エレベーターを出て、船がある。そういう光景はもう無くなる。変な会社の光景はなくなってしまう。

なんであんなデザインだったんだろうねと誰もがいい、そしてここが良かったという。よくわからないけど集まってしまう場所があり、なぜか自然に話を始めてしまう。そういう場所がファーストプレイスのAJITOだった。僕もここでたくさんエンジニアリングの話をして、SICPの感想会をやって、ときどき取り組んでいる問題について議論して、ギターを弾いたりした。当時もきっと多くの技術的な話をAJITOでしていた。

場所が文化をつくる。場所に人がいて、集まって、文化ができる。気がつけば文化を作ってきた。次の新しいオフィスでは文化を持って、場所を作ろうと思う。次は場所を作る側だ。そうやって人は何かを良くしていく。

さよならファーストプレイス。