2019年を振り返って

2019年も大晦日となりました。今年も多くの皆様にお世話になりました。

仕事について。今年もインターネット広告領域のエンジニアリングを中心に携わりました。幾分変化の多い年であり、経営統合もさることながらプロダクトとしても多数のアップデートを行いました。マルチフォーマット、OpenRTB部分の強化と拡充、ロギング基盤の強化を始め、チームとして多くの課題に向き合いました。またGDPR / CCPAはもとより、ITP / SameSite Cookie、SupplyChain Object / Seller.jsonなどの取り組みを受けて、プライバシー・透明性・データについてより一層向き合う時間の増えた年でありました。2020年代の世界に向けて、どのようにプロダクトを変えていくか。2010年代序盤のHypeを超えて、RTBが世界に溶け込み、何を作っていくか。オペレーションする世界がどのようになめらかで、効果的で、健全でありうるか。そういった課題を日本の片隅で考える、そんな一年でした。

去年よりもプログラマティック広告領域における次をつくる動きが増え、自らのプロダクト内部を変化し、未来に向けてのエンジニアリングがチームでできたことは嬉しい進歩でした。質とスピードは内に端を発します。Observabilityの向上、密度の濃い構造へと変えていくリアーキテクチャをしつつ、新規の機能追加や取り組みの加速をできたことはよい経験でした。ソフトウェアのスピードで事業を進めるのが時代の当たり前になり、期待値が高まる中で如何にスループットを保ちつつ質と向き合うか。これは現代のソフトウェアにおける市場からの要求との向き合いであり、内的なソフトウェアの複雑性と向き合う根拠であり、事業を期待通りのスピードと大きさで進めるために必要不可欠な行いであり続けます。年々成果を出すことの難しさを受け入れ、それでもなお何かを作らねばなりません。

今年も幾許かの読書をしました。振り返ってみると、腰を据えてじっと考える時間の多い一年でした。

良いお年をお迎えください。

失敗について振り返る

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

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

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

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

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

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

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

判断力をつけるには - 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)というのはなかなか教えられるものではなく、大方経験を重ねて覚えるものだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

剛柔の螺旋

人を捉えるとき、私は剛柔をもってその人を見る。

剛とは強さのこと。意志の強さ、こだわりの強さ、信念の強さ。何かを突き動かす力の大きさ。目的を達成するための強靭さ。個としての確固たる決意、スキル。強いものは周りを惹きつけ、動かし、うねりを作る。いつでも変化を起こすのは剛だ。

柔とはしなやかさのこと。受け入れられるものの大きさと深さ。多様な価値観を受け入れられる包容力と理解。受け流すのではなく受け入れ、受け止める強さ。変化を受け止め、自らを変え、対応できる力。

強さとしなやかさは両立する。人は両方をもっていて、それぞれに質や比重が異なる。誰にでも価値観があり、かつ何かを許容する。

しなやかさがなければ学びはない。まだ知らないこと、自分が未熟であることを受け入れ、新しい力を身につける。何かに長けている人でも、全てに長けていることはない。若さからも学び、他者から学び、理解する。力をつける。しかし信念のないところの学びは血肉にならない。

学びがなければ強くならない。ただ頑固なだけでは何者にもならない。何かをなし得るために身に着け、努力し、時間をかけ、実行する。そのために学び、変化を起こす。自ら生み出す。しかししなやかさがなければ、やがて変化できない自分がうねりに飲まれる。

---

同じ人でも年を重ね、経験を重ね、剛柔を変えていく。変えていないならしなやかさが足りない。経験を重ねてもしなやかであり続けるには、理解し続けなければならない。今の自分の価値観を覆され、今までのやり方では超えられない壁を感じ、変化を余儀なくされ、固執せず、自らを変え続ける。

剛柔の偏りは時としてなければならず、偏りないならどちらかが弱い。こだわりが少なすぎるなら流されるだけであり、受け入れるままになる。強すぎても弱すぎてもいけない。そうした波をしなやかに乗り越えている人は見ればわかる。そして自分よりこれを繰り返している人を前にすると自分の未熟さを痛く感じさせられるのだ。

明日も一歩進められるようにありたい。

武器としてのソフトウェア

今後10年かけて、ソフトウェアエンジニアリングのエッセンスは日本の企業で普及し、各職種に溶け込んでいくと私も思う。今もどんどん進んでいる。

きっと表計算を使っていない会社はもはや存在しないだろうし、業務プロセスにソフトウェアが何も介在しない会社というのは大きい規模では存在しないだろう。しかしなぜか慣習によってソフトウェアの世界のスピードを取り入れられれず、中にいる社員は普段からテクノロジーに触れているというのに自分の会社はなかなか進まず、世の中から遅れているように感じる。自社がソフトウェアを作っているか否かに関係なく、ソフトウェアが世界を変えるスピードについていけてないギャップが襲いかかってくる。資本主義の世界の中で、世界先端のテクノロジーをつかうエンドユーザは自社の社員であり、会社のプロセスだけが残されていく。

これはもう2011年から話されていることで、2019年にこの記事を書いている私もどうなのかな、と書きながら思っている。世界から取り残されているのだ。

自分は今後10年のなかで、ソフトウェアエンジニアリングの仕事は専門化と一般化の二極化が進むと考えている。専門化はそのままで、クラウドコンピューティングのバックグラウンドを支えるためのネットワークやOS、あるいは仮想化技術といった領域の進化。そしてデータ基盤を構築し、モデリングし、ロジックを組むことのスペシャリスト。こういう領域は引き続き進化していく。一般化は技術が容易に扱えるようになり、低コストで実世界に応用するという範囲の広がりのことをさしている。例えば音声認識がブラウザから簡単にできるようになったり、認証認可・データ保持・分析をする環境がすぐに立ち上がるようになったりする。「簡単にできることを知らない」人や企業に向けてそれを導入し、理解し、プロダクトや業務プロセスの中に取り入れてもらうという仕事はより広がりを見せていく。2011年のときよりもさらに、ソフトウェアは容易にできることを増やしてくれている。市場は素晴らしい。

先々週の次世代WebカンファレンスのAdセッション（動画）でyamazさんが話されていたように、広告の世界でもオペレーションというのはまだまだ課題がある。テクノロジードリブンに進んできたようにみえるであろうマーケティング + テクノロジーの世界においても、複数プラットフォームをまたいで多種多様なキャンペーンと広告枠を運用する上では業務プロセス改善とプロダクト生態系の進化の速さにギャップが有り、エージェンシーやプラットフォーマも人手で対応しなければいけないことも多い。そうした課題というのは今後他の業界でも違った形で顕在化するだろうし、今DXを進めなければといわれている業界であれば必ず将来同じ構造の問題に直面する。業務のデジタル化に生まれるデータは自社だけでなく複数サービスと連携し、そこではじめてWebプラットフォームで動くソフトウェアと競える環境になり、投資する合理性が生まれるからだ。

ソフトウェアエンジニアであるあなたが日々の手元足元の仕事を見渡したとき、果たして今の業務をどのように捉えられているだろうか。ただただ神エクセルをRDBに移すだけの仕事だと思うのか、業務プロセスごとリデザインして効率化し、かつ他のプロセスでも利用可能なサービスに発展的進化をさせると捉えるのか。そのスタート時点での見通しによっては、ソフトウェアが生み出せる最大価値は低いままになってしまう。

ソフトウェアエンジニアリングの武器は、抽象である。抽象化ができるから、ソフトウェアは実世界をつなぎ、具体に新しい面を見出し、問題として設定し、解くことができる。様々な業種でソフトウェアエンジニアリングの力が活きるというのはつまり、ソフトウェアとして解ける問題に現状を落とし込むことでレバレッジが効く状況を仮定しているということに他ならない。一介のソフトウェアエンジニアとしては、組織の投資戦略が果たしてどのようにソフトウェアにかけようとしているのかを見極め、どのような費用対効果が見込めるか（資産となるか）を実行し得るようにするというのがまた次の10年を面白くしていくだろうと思っている。

2019年に読んだ本

2019年に読んだ本をまとめておく。随時更新。

2018年
2017年

最終更新 2019/12/30

小説

* かもめのジョナサン 完成版 (新潮文庫) 文庫 – 2015/6/26 リチャード バック (著), Richard Bach (原著), 五木 寛之  (翻訳)
* 琥珀のまたたき 単行本 – 2015/9/10 小川 洋子  (著)
* 過ぎ去りし王国の城 単行本 – 2015/4/24 宮部 みゆき  (著)
* 親指の恋人 単行本 – 2008/1/29 石田 衣良  (著)
* 欲望という名の電車 (新潮文庫) 文庫 – 1988/4/8 テネシー ウィリアムズ  (著), Tennessee Williams (原著), 小田島 雄志 (翻訳)
* とり残されて (文春文庫) 文庫 – 1995/12/8 宮部 みゆき  (著)
* ダンス・ダンス・ダンス (講談社文庫) 文庫 – 2004/10/15 村上 春樹  (著)
* ムーンナイト・ダイバー 単行本 – 2016/1/23 天童 荒太 (著)
* 蜜蜂と遠雷 (幻冬舎文庫) 文庫 – 2019/4/10 恩田 陸  (著)
* 騎士団長殺し (新潮文庫) 文庫 – 2019/3/28 村上 春樹  (著)
* i(アイ) (日本語) 単行本 – 2016/11/30 西 加奈子  (著)
* 革命前夜 (文春文庫) (日本語) 文庫 – 2018/3/9 須賀 しのぶ  (著)

技術書

* 入門 監視 ―モダンなモニタリングのためのデザインパターン 単行本（ソフトカバー） – 2019/1/17 Mike Julian (著), 松浦 隼人  (翻訳)
* 失敗から学ぶRDBの正しい歩き方 (Software Design plus) 単行本（ソフトカバー） – 2019/3/6 曽根 壮大 (著)
* LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (著), 武舎るみ (著)
* データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理 2019/07 Martin Kleppmann　著、斉藤 太郎　監訳、玉川 竜司　訳
* レガシーコードからの脱却――ソフトウェアの寿命を延ばし価値を高める9つのプラクティス 2019/09 David Scott Bernstein　著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士　訳
* ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics Kindle版 ルーク・ホフマン (著), 岡澤裕二 (翻訳), 和智右桂  (翻訳)

その他

* ［実践］小説教室　伝える、揺さぶる基本メソッド 根本昌夫  (著)
* FACTFULNESS（ファクトフルネス）10の思い込みを乗り越え、データを基に世界を正しく見る習慣 Kindle版 ハンス・ロスリング (著), オーラ・ロスリング (著), アンナ・ロスリング・ロンランド (著), 上杉 周作  (翻訳), 関 美和 (翻訳)
* お金の流れで読む 日本と世界の未来 世界的投資家は予見する (PHP新書) Kindle版 ジム・ロジャーズ (著), 大野 和基 (翻訳)
* マネタイズ戦略――顧客価値提案にイノベーションを起こす新しい発想 Kindle版
川上昌直  (著)
* ソフトウェア・ファースト Kindle版 及川 卓也  (著)
* 十頁だけ読んでごらんなさい。十頁たって飽いたらこの本を捨てて下さって宜しい。 (新潮文庫) (日本語) 文庫 – 2009/8/28 遠藤 周作  (著)
* 吉田の日々赤裸々。3　ゲームデザイナー兼取締役の頭の中 (ファミ通の攻略本) Kindle版 吉田直樹  (著)

2019年やりたいことのリスト

途中で編集してもよいルールとする。年末に振り返る。

1. 新しいプログラミング言語を1つ以上覚える
2. 引っ越す
3. 1日に1食以上野菜を食べる
4. 飲酒は月に12日までとする
5. 短編小説を1本以上書く
6. ゴルフのスコアで100を切る
7. ゴルフのレッスンを始める
8. 演奏会に1つ以上でる
9. 週に2回以上運動する
10. 週に1本以上ブログを書く
11. ヨーロッパ旅行に行く
12. 月に2箇所以上行ったことのない場所にいく
13. 月に1つ今までにやっていないことを始める
14. 月に1回以上登壇する
15. 月に1冊以上技術書を読む
16. 月に2冊以上小説を読む
17. ajitofmを20本以上録る
18. ajitofmのパーソナリティを増やす
19. 月に1人以上新しい人と1時間以上話す
20. 親しい友達と3ヶ月に1回以上会う
21. 月に1曲以上新しい曲を弾く

習慣化のためにスプレッドシートをつくった。誰でも見れます。 https://docs.google.com/spreadsheets/d/1xX6D0icGHe4e40nN3tZXsj0xCu-LZiBLaxxgfSkrDuk/edit#gid=0