4月から新卒2年目になりました。心機一転、4月の間は色んな面から働き方やエンジニアリングを振り返っていました。業務的にも僕が判断したり自分で設計する部分が広くなってきたので、その辺りについてのやり方も変わって来ました。
事、4月に入ってからは設計の時間が増えました。どうもコードを書き始めるための十分な材料が揃っていなかったので、ひたすら外部環境について調べてみたり、既存のシステムよりも上手く楽にやる方法というのを探ることに頭を使っています。既存のシステムや同じ事業部で書かれているコードを読みながら、「あー、この部分の設計はさすがだなー」とか、「ここの部分はみんな一回壁に当たるところだよなー」とか言いながら大量のコードに目を通しつつ、あとは頭のなかで熟成させます。そうすると寝る前や帰り道、もしくは朝起きて朝食を作っている時なども色んなことを思いつきやすいらしく、ぱっと良い実装のアイデアや綺麗で手間のかからない設計が生まれてきます。そういう「なんとなく仕事してるようなしてないような、でも、してる」ような時間というのが相対的に増えたのが、4月のハイライトだったように思います。
最近は広告のデータ周りのことをやっていて、随分と仕事の幅も広がったなぁと感じています。web広告というのは一見複雑なように見えます。私がやっているのはDMPというデータを集めてそれを活かす、ということに特化したところです。データを見るときには仮説を立てて徐々に徐々に深堀りしていきます。しかし、深堀りしすぎてもいけなくて、もう少し広い目に戻らなければならない時もあります。なんだか大学院生のときに教授から「鳥の眼と虫の眼や」と言われていたことが僕の中では身にしみていて、分析しているときは毎日がその繰り返しです。この繰り返しの効率というのが徐々に上がってくるのでまた楽しいものです。同じトピックについて一つの視点、例えばこの行動をしているユーザは一体全体どのような経路からやってきているのだろう、というような大テーマについて深掘って行くとどんどんユーザのその時の行動動機が頭のなかに描けてきます。一人のユーザのことを考えすぎても大きな結果につながる因子が出てくることは少ないですが、何かその時々のユーザの頭のなかについて想像することで、あるときとても豊かな事実にたどり着きます。そうやって、デジタルな世界からとても人間らしい何かに近づいていく過程というのは、とても魅力的です。
分析といえば最近は論文を読む会を社内ではじめました。広告技術関連論文をそれとなく読み合わせる会です。輪講です。これは至って研究室のスタイルに近いもので、毎週1本論文及び発表者を決めて、60分発表30分議論といった形でも催しています。やっていて面白いのは、大学院にいたときは実データに乏しく「実際に役に立つ感じ」というのが得がたいものでしたが、今は僕達の手元にデータが有るという点が生み出す学習効果です。論文を読みながら、「僕達ならこれをどのように利用できるだろう」「このモデルは私たちの実感と直感的には合わないがなぜだろう」「自分たちが見えていなかった外因性をこの人達はすごく気にしている」「立派な数式に落としこんでも結果は極めて単純だよね」等など、実際に現場でデータを扱っているからこそ見える視点というのがあります。僕のやっているような仕事を抽象化して学術論文にするというのはすごくハードルの高いと感じていますが、こうして同業者で研究を外に出すことができている企業というのはこれまた素晴らしいなぁと感じます。やはり実学の分野において学術との距離感というのはあるなぁと感じていて、これをお互いに歩み寄っていくことによってまた新しい発見が増えていくものだと思います。その試みのためのフィールドとして、web広告というのは魅力的な分野の一つです。
そういうところを行き来しながらプロダクションのコードを書いていると、やはりあまり時間というのは残らず、如何に必要最低限で価値を出すか、というところに僕自身の価値観が寄ってきています。これは健全であると思っていて、GNUツールの数々がそうであるように、最小のコードで筋の良い仕事を可能にするというのはエンジニアの美徳だと思うし、文化の成す技だなぁと思うのです。
$ cat some_log_files | using_some_mapper | sort_by_some_keys | and_aggregate_it > output_to_file
データをつかって仕事をするというのは面倒なことも多いですが、如何に綺麗に物事を当てはめて、それを適当に加工して、纏めあげて、つかいやすい形で手元に戻せた時点で8割の仕事が終わっています。それは分散環境下であれ、このPC上であれ、どこでも変わらないことです。などという当たり前のことを可能にしてくれているのは、やはり小さいツールが上手くお互いに仕事をこなしているからに他なりません。大抵仕事が失敗する場合というのはこれが一つの大きな仕事になっているときです。
$ using_some_mapper_and_sort_by_some_keys_and_aggregate_it_and_output_to_file some_log_files
この仕事だけにしかこの長い命令は使えないかもしれません。後から見た人が一体全体中で何をしようとしているのかを把握するのも大変です。あと、途中の処理の順番を間違えたりしていたら、それを修正するのも何やら大変そうです。どうも、はじめは何か大層立派なものを作ろうとしてしまうわけですが、僕のように一度に多くのことを考えられない人というのはこういうものを作ってしまう上手くいきません。小さいものを作って、つなげたほうが楽です。でもこれって、書くものの数はとても少ない割に、如何にこれらを小さくまともに素なものにするか、ということを考えるほうが大変です。
GrowthForecastはそういう点において素晴らしいです。このツールが素晴らしいのは、データを一旦継続して格納することを決めてしまえば、httpプロトコルでしゃべっているだけでデータを視覚化できることです。でも、意外とツールとしては面倒なことをやっています。データを貯める場所を作り、httpで喋れるようにし、グラフを書きださなければなりません。「そんな面倒ならGNU plot使えばいいじゃない」と思うかもしれませんが、継続してデータを貯めていくということは意外と面倒なのです。ところが、cartonを使って環境をつくり、あっという間にデータを溜め始めることができます。これは小さなツールを組み合わせて上手くツールを小さく使いまわしやすくした好例であると思いますし、こういったソフトウェアが公開されているというのは素晴らしいことです。社内でも徐々に広がりを見せつつあります。その様を見て、やはり設計の良いツールというのはドメインを変えても上手くフィットしていくのだな、と思います。僕もそういう筋の良い設計をできるようになっていきたいです。
こうして、もう4月も終わってしまいそうな時分ながら、改めて仕事を振り返ってみると、たくさんの先人の知恵を借りながら目の前にある課題に向かう時間がほとんどでした。sicpを読んだり、統計の本を読んだり、
#ajitingしたりしながら、やはり僕は良い設計というものにこだわっていたい、と思うのでした。
