Message Passing

大企業におけるハイテク私感

大企業下っ端なので全然ハイテクとかしてない。 ここでいうハイテクは、それなりに (CS 的な) 難しさのある、それなりの規模のコードという風に解釈している。

ある程度成熟した大企業だと、インフラ部門とかリサーチ部門とかがあってハイテクなものを専業で作っている。 なのでハイテク指向な人はそういう部門ではたらく傾向がある。

一方のアプリやサービス部門の人は、実製品開発が好きだからそういうチームにいる。 だから個人の性向としてハイテクより仕事を片付けるのを優先しがち。 それを退屈に感じたこともあったけれど、最近は締切を守ってモノを出す姿勢も大事だなと考えるようになった。 なぜならちゃんとモノが出ていくから。大企業、野心的すぎて完成する前にお蔵入りしてしまうプロジェクトもよくあるね。

専業のインフラ部門とは別に、巨大製品チームはインフラ部門やリサーチ部門相当を内部で抱えている。 たとえば YouTube は Procella というデータベースを内製しているらしい。わけがわからない。 製品内ハイテクはインフラやリサーチ発のテクノロジよりドメイン依存で、身近な面もある。 とはいえ巨大製品のハイテクは黎明期の発明の二周目三周目なことが多く、個人作品というより組織戦の色が濃い。

そんなアプリ・サービス部門でもバーンと一周目のハイテクをキメる人はたまにいて、 そういう野心がある人はだいたい出世して TL とかになる。そして二周目三周目の製品内ハイテクプロジェクトを主導していく。

つまり実勢品でハイテクをキメられるくらいならもっと出世してるっつーの！（突然の八つ当たり。） 下っ端の実力は推して知るべし。

傍から見ていると、小さいチームより成功してある程度規模のあるチームの方がハイテクの機会は多いように見える。 というのも小さいチームは技術的障壁以前に product-market fit みたいので苦戦することが多いので、 よくいえばスタートアップ的に動くものを優先しがちだから。成功して、はじめてハイテクの必要性が生まれるのではないか。 あと勢い良く伸びている製品の方が予算の融通が効く面もある気がする。やんちゃする余裕がある。

テクノロジーありきの製品も色々あるけど、 というか自分が仕事で手伝っているのもそうした製品の一つだけれど、コアテクノロジは先に書いたようなリサーチ部門や、 リサーチ部門ではないにせよリサーチ的な性格のチームとから出てくることが多い。 たとえば実験的な OS を作ってしまうチームとか。

零細企業でのハイテク

自分が零細企業勤務だった十年前のことを考えると、その会社はなぜか自社ミドルウェア用に公開鍵暗号を実装していた。 細かいことは忘れたが他にも似たレベルの再発明ハイテクがもう一つ二つあったと思う。 再発明に見合う品質やユニークさはなかったと思うが、組織の未熟さゆえにこれらのハイテクは生まれることができた。 要するに良くない判断を止める人がいなかったからやんちゃできた。こういうのは零細、中小企業だと割とよくある話だと思う。

製品の要請から意味のあるハイテクが生まれることは、小さい企業でもあるだろう。 インフラ部門やリサーチ部門がないぶん製品チームが腕まくりしてハイテクに挑む。 karino2 はきっとこのケースに近いのでしょう。

企業規模とは無関係に、ハイテク自作の文脈でオープンソースの影響は無視できないと思う。 よいニッチを見つけないとオープンソースの既存実装に勝てない。 自分で何か書くと言い張るのは、昔よりやや難しい。 オープンソースの隆盛にあわせ、世の中全体としてハイテクを自作する割合は減っているんじゃないかな。 ソフトウェア産業は拡大してるから絶対数は増えてるかもしれないけれど。

ベテランの気晴らしハイテク

権力のある古株のエンジニアが、仕事に飽きて気晴らしにハイテクをはじめてしまうことがある。 そんなハイテクは難しくて新しいことをすること自体が動機になりがちで、製品の要請に基づかないことが多い。 その一方で権力者の仕事だけに割と影響範囲もでかくなりがち。

森田は過去に何度もこの気晴らしハイテクを目撃しており、そのせいで迷惑したことも一度ではない。 そのせいかこうしたプロジェクトには強い嫌悪があり、 反動でなるべく地味に堅実な成果を出したいバイアスがある。

とはいえ退屈していたベテランが考え事をしていたら製品の隠れた要請に気づいてしまうこともあるわけで、 あるハイテクプロジェクトが製品の要請なのか単なる気晴らしなのかは、最初ははっきりしない。 自分が「それ趣味プロジェクトでしょ」と斜に構えていたらいい成果を出したベテラン発のハイテクも何度か目にしてきた。

小粒な気晴らし

自分も今のチームに異動して三年。社歴に至っては十年。だいぶ飽きている。 あーなんか気の利いたコードを書きたいなーと思いつつ地味にバグをなおして暮らしている。

が、ふとした思いつきから年末に仕事でプログラミング言語を実装した。 三日で書いて二千行みたいな超小粒言語で、仕様も大学生の宿題みたいに素朴なもの。 GC も Java まかせで、ハイテクとは程遠い。 ただ「仕事でプログラミング言語を書く」というハッタリじみた響きが気に入っている。

これは性能試験のためにアプリの動作を自動化するミニ言語で、Android アプリの中で動く。 テスト用なので出荷バージョンには入っていない。

Android アプリの自動化は instrumentation という仕組みを使うのが定番だけど、性能テストの目的だと侵入的すぎて都合が悪い。 自分のいるチームではかわりにホスト側で動く Python のフレームワーク Mobly を使っている。 つまり ADB 越しに自動化をする。

これは悪くはないが、際どいタイミングの操作を書くのが難しい、というかできない。 たとえばアプリを起動してビューファインダーが表示された瞬間にシャッターボタンを押す、みたいなコードは書けない。 ADB 越しでは「ビューファインダーが表示された瞬間」を検知できないし、なんとかして polling するにしても負荷やレイテンシが犠牲になる。

自分はもともと自動化のロジックを Java でハードコードすれば良いと思っていたが、別の同僚が「(組み込み言語であるところの) Lua を使えばよくね？」と言い出した。自分も Lua はさわったことがあり、悪くないアイデアに思えた。 とはいえ Java で書かれたアプリの自動化のために C で書かれた Lua を使うのはインテグレーションが億劫そうだ。 世の中には luaj という Lua の Java 実装があるのでこれを使えばいいとも思ったが、 社内のアーカイブを検索すると過去に他の製品で行われた同じ試みが安定性の問題から頓挫した事例が見つかった。

一歩さがると、自分の目的には Lua すら大げさすぎる。ちょっとした制御構造があればいい。 自動化スクリプトの長さもせいせい 10 行くらいなので、性能も必要ない。 奇しくも年末にチームの hakcathon があり、良い機会だからと書いてみたら割とあっさり動くものが出来た。 コードサイズも 2000 行。Luaj の数万行と比べ一桁小さい。 え、言語とか作っちゃうの・・・と釘を刺す（まっとうな）同僚もいたけれど、コードサイズを見せたら納得してくれた。

さっそくいくつかのシナリオを自動化してみると早速アプリのバグが見つかった。手応えあり。

三ヶ月かけて書いた一万行のデータフロー DSL とくらべると格段にしょぼいけれども、 先に書いた大企業アプリ部門したっぱ勤めの現実を踏まえると自分の「ハイテク」はこんなもんかなと思う。 すくなくとも有閑ベテランの迷惑ハイテクではない・・・とおもってる。 なおこんなしょぼい成果だと迷惑もないけど出世の足しにもならない。残念。

そういえば一昨年くらいにやった profile guided pinning も自分の水準ではギリギリハイテクかな・・・ とおもったけど一週間くらいでやった雑な仕事なうえに Python と C++ それぞれ 100 行みたいな規模。ぱっとしない・・・。 いちおう自分なりにがんばった仕事なのでひっそり自慢させていただきます。

ハイテク企業で組織戦を先導してそうなはまじさんどうですか。