A Long Reflection 2019 (3) - Bigness

もくじ。

大企業について書こうと思ったが、自分にとっては外資系というか非母語で働くという変化と受託開発から自社製品開発への変化も同時にやってきたのでれらは切り離しにくい部分がある。まずは別々に議論してみる。

まず大企業と大規模プロジェクトについて。自分は今の会社に入るまでは中小企業で働いていた。気づいていなかったが、働き方も中小企業に傾いていた。それを補正するのに苦労した。

規模と細分化

中小企業の働き方は役割が未分化である。製品のコードベースも大きくないからフロントエンドからバックエンドまでふつうに全部さわるし、人手がないからマネージメントはしないまでも TL っぽい立場にはなりやすい。色々やる。

その色々の品質は高くない。多くの場合、とりあえず動けばよい。ひどいところは直そうかな、くらい。要素技術を売るスタートアップのコア技術とかだとまた違うのかもだが、中小企業というのは基本的にしょぼいものをしょぼしょぼ作って売っているのである(殺されそうな発言)。しょぼいは酷い言い分で、ニッチというほうが良いな。

大企業は人がいっぱいいる。仕事も規模がでかいので、役割が細分化されている。マネージメントも管理職以外はそんなやらなくてよい。偉くなりたいなら TL くらいはやった方がいいだろうが、別にやりたい人(偉くなりたい人)はいっぱいいるので自分がやらなくても他に人はいる。ビジネスは成功している(からでかくなった)ので、その先に積み上げるものへの期待値は高い。

細分化の結果、個々人は専門家として仕事をしないといけない。その専門はわかりやすい(市場価値のある)切り口の場合もあるし、製品固有なニッチの場合もある。マネージメントも専門である。TL はある意味ではジェネラリストだが、それでも守備範囲のスコープは狭い。なぜなら個々のチーム自体の守備範囲が(相対的には)小さいから。"Uber TL" という TL の TL みたいなポジションもあるにはある。割とすごいプログラマがすごい視力をもってやる仕事とされている。なおスコープが小さいといってもコード量が少ないとは限らない。コードの総量が多いので。

自分はというと、チームのつくっている特定のアプリの性能の専門家となっている。でも性能の指標をすべて見ているわけではなく、起動レイテンシや Jank のような限られたメトリクスしか扱っていない。たとえば画像処理のスループットとかメモリ消費とかは他の人が見ている。前のチームは今より小規模だったので、もうちょっと色々見ていた。一方その前のチームは今よりずっと巨大で、自分が性能の専門家になる余地はなかった。

大企業というか大きなプロジェクトは仕事が進まない。具体的にいうとコード産出のスループットが低い。なぜなら満たさなければいけない期待値、品質のバーが高いからである。性能改善とかはその傾向が顕著かもしれない。コードを書くよりプロファイルやトレースを睨んでいる時間の方がずっと長い。

現実の問題に裏付けられた専門のニッチにどこまでも踏み込んでいく知的刺激は得難い。一方で、どうってことないコードをフルスタックで雑にいっぱい書く方がコード書きの筋肉はつくし潰しは効くだろうなと思う。

Small autonomous team で Microservices みたいのは大企業が中小企業の身軽さを取り戻す術とされている。Microservices でなくても、新規製品の立ち上げみたいなプロジェクトにはこれらプロジェクト規模の問題がなく比較的ザクザクとコードがかけるため、勢いのある人たちに人気。ただ自分はそういう仕事はしていない。今のチームも新機能やっている勢はそこそこコードのスループットがある気はする。コードを書くという視点だと、性能仕事は微妙。

まとめると、大企業はプロジェクトの規模が大きくなりがちで、結果として仕事は細分化、専門化しがちで、期待値の高さから品質のバーはあがりがち。ただし弱小製品や新規プロジェクトなど例外も多い。コードを書く量は総体としては少なくなりがちだが、程度にはばらつきがある。うまく仕事を選ぶと雑用がすくないぶんコード書きに集中できる面はある。

自分は専門家になるより E2E でコードを書きたいと思っていたし、TL/TPM 的にプロセスなどをコントロールできないことに強いフラストレーションを感じていた。性能の仕事はコードを横断することができるので良い。ただし新機能実装みたいな機会はない。プロセスについては超非生産的な年月を経て慣れた。どちらも適応には時間がかかった。

社内固有の事情

大企業はでかいので、社内固有の事情が色々ある。そうした社内固有の事情に関する知識は、転職を見据えると基本的には無駄。ただ日々の仕事には欠かせない。

社内知識にはスタックのように技術なものと書類や人間関係のように技術的でないものがある。運用のプロセスみたいのはその中間くらい。

まず技術的な知識について。自分の勤務先はオープンソースにあるような分野のものも色々内製している。そういう内製スタックに詳しくなるのは無駄だからと、なるべく近づかないようにしていた。

ただ後から気づいたこととして、その内製スタックの上に作られた製品固有のテクノロジ(画像処理、検索などなど・・・)はオープンソースに代替品が存在せず、ものによっては業界最先端だったりする。そうした製品固有のテクノロジを学ぶ税金として内製スタックは勉強しても良かった。反省。とはいえ規模の問題もあるので、製品固有テクノロジを学びたいならそのテクノロジの上で仕事をしないといけない。片手間で理解できるような代物ではない。検索について知りたいなら検索を仕事にしないとだめ。たぶん。

もうちょっと汎用的な内製技術スタックが「時代の先を行っている」とされている場合、未来を見るメガネとしてそれを学ぶのには意味があるのか?個人的にはあまり無いと思う。「時代の先を行っている」はだいたい当事者の思い込みで、実際はニッチな袋小路に過ぎないことが多い。その未来は来ない。上に書いたような理由からそれを理解するのは悪いことではないけれど別に未来じゃなくね?やはり論文なりオープンソースなり世間で評価にさらされないと勝敗はわかない。

しかし学ぶ意欲を得るにあたりファンタジーが助けになるのも事実。自分も、自分を騙せる勢いが残っているうちに内製テクノロジにどっぷりすればよかったなと思う。まあブラウザとかもオープンソースなだけでニッチ性は内製テクノロジみたいなもんだから、それを学んだのでよかったのかもしれない。未だに心のどこかでサーバサイドには「秘伝のタレ」があるというファンタジーを捨てきれてない。

技術的でない社内知識。たとえば人脈とか部門間の関係とか他部門の動向とか。ほんとに社内でしか価値がない情報だけれど、ゴシップ的な面白さはあるのでひやかし程度に詳しい人の話を聞くくらいでいいんじゃないかな。チームメイトなど、直接接点がある人たちとの関係を良好にするのは大事だと思う。自分がこれらをちゃんとできているとは思わないが。

半分くらい技術的な知識。たとえばプロセスや、それをとりまくツールと人間。自分が agile とかが好きなせいかもしれないけれど、これが一番学ぶに値するものだと思う。プロセスというのは細部は組織固有だけれど big picture は存在し、それはソースコードほどオープンでないし知識として明文化するのも難しい。そこそこ機能している "The Way"には学ぶ価値がある。そして座学で学ぶより実際に動いているものを目にするほうがずっと身につく。それらのプロセスが最適であるとは限らない。でも何も知らずに完全にランダムな解空間を探索するよりは良い。

企業 blog やオープンソースにはじまり Devops movement やその周辺 SaaS へと続く情報開示によって、様々な大企業 ways も段々と標準化、商業化されているような気はする。そうやって小奇麗になったバージョンを学ぶほうが効率的に思える一方、土着のプロセスが動く生々しさに触れる良さもある。自分は一時期こういうのに興味があったけれど、モバイル部門は音楽性が合わなすぎて興味を失ってしまった。ただ各種の社内ドキュメントはもうちょっと熱心に読んだほうが良いのだろうなあ。

官僚的なものごと

大企業が官僚的であるというのはたぶん事実だが、体感するフラストレーションはばらつきがあった。

ミーティング。自分はいま週に 1.5 時間くらいかな。チームの定例が一個と、1:1 が隔週から月一回くらい。隔週の demo day は時期によって開催頻度はまちまち。自分がヒラ社員すぎるせいとはいえ、これは会社の規模によらず割と少ない方ではないか。(しかもたびたびすっぽかしている。よくない。)

出張とか経費精算とかのペーパーワークはずいぶんラク。人事考課は、ちょっとめんどい。ただフェアさを考えると妥当かなと思う。制度に改定があるたび、下々の手間は少し減り、同時に透明度も少し失われている。

非同期でやるミーティング相当の行為。コードレビューとか、ドキュメントのレビューとか。まあそこそこ。やはりヒラなのでそんなに多くない。バグのトリアージは今の仕事はすごい多くて苦痛。ただ割と例外的な気がする。メールはそんなに書いてない。読むのは適当にやってる。

リリース。相当めんどくさいはずだが TPM がぜんぶやってくれる。専業の人間がいる時点で官僚的なのは事実。TPM ではなくエンジニアがやってるチームもある。自動化はされているが、自分たちのチームは割と激しく cherrypick するとか QA チームによる手動のテストが挟まってるとかのせいでめんどくささが増していると思う。官僚的だからというよりは、チームの練度不足に思える。

なんか新しいことをはじめる。自分の裁量でできる範囲なら特に面倒はない。人が欲しいとかエンドユーザから見える違いがあるとかだと大変。製品の表面積が小さいほどエンドユーザ向けの機能を足すのは大変だと思う。カメラアプリとかだいぶ大変。電子書籍はもうちょっとラクそうだった。どちらでもプログラマがやりたいと言い出した機能が入り込んでいくのを見たので、機能の筋の良さと本人のパッションに依存している。たとえばカメラの RAW 保存とかはプログラマ発だった気がする。

機能ではなく、新しい製品を始めるのは、きっとすごい大変。自分には無理だし、エラ目の PM とかでないと正しい攻略パスを進めないんじゃないかな。PM と仲良くなれば良いという話かもしれないが。

新機能にしろ新製品にしろ始めるのは大変だけど世に出すのはもっと大変で、リリース前のプロジェクトはしょっちゅうキャンセルされている。世に出たものもよくディスコンして世間の顰蹙を買っているけれど、あんな生易しいもんじゃないんだぜ。今のところキャンセルでもクビにはならないのはめでたい。

日々の仕事の官僚性。ビルドが遅いとかテストが遅いとかは技術的な官僚的オーバーヘッドと言えよう。コードレビュアがみつかんないみたいのは、昔でかいチームだった頃はよくあった。今はあまりない。忙しくて全然レビューしてくれない時はたまにある。分散バージョン管理のおかげで、仕事の並列化はやりやすくなった。多少ブロックされても遅延を隠せる。

コードにおける官僚性。なんかのインテグレーションをするとか、コードの静的チェックとか。UI の見た目の足並みを他アプリと揃えるとか。まあまあある。そして、これは大きいチームにいるより小さいチームにいる方が負担を感じる。なぜならシステムが巨大なチームのために作られているから。大きなチームだと、面倒なことは割と誰かがやってくれる。(自分がその面倒な担当にならなければ。)

総体として、自分の役割を果たしている分にはたいしたオーバーヘッドを感じないが、役割を超えてなにかしようとすると非現実的に大変な印象。自分は最初のころ役割をよくわかってなかった。そのせいで無駄に苦労をした気がする。

英語と外国

英語と外国の影響は理論的には大企業である事実とは直行しているはずだが、自分の場合は大企業による影響を reinforce している。すなわち、フルスタック雑用リーダシップではなく末端専門家プログラマとしての振る舞いを後押しされている。

英語の影響、すなわち言語バリアは、プレゼンやメールや立ち話といった自然言語による説得を難しく、かつ高価にする。その結果、1. 事前に説得するより実際にコードを書いて結果をだしてからもっていくようになる 2. 主観的な性格が強いもの(例: コード品質)より成果を客観的に見せやすいもの(例: 性能)を目指して仕事をするようになる。3. 人に頼むのではなく自分でやるようになる。4. 他人の仕事に口を挟まなくなる。全体として、リーダーシップ/マネジメントではなく末端/ICであることを志向するようになる。

外国であることの影響、すなわち人的ネットワークの喪失の影響。これは日本で育んだネットワークが役に立たないからでもあるし、言語バリアのせいで新しいネットワークを育てられないせいでもある。家族がいると社外のイベントの類も全然顔をだせないし、社内の業務外グループみたいのに参加する余力もない。結果として、仕事では人づてに裏で口を利いてもらうとかはできないし(これは日本にいたときもしたことない気がするが)、同じく人づてに面白い仕事を探すこともできない。社外でも社内でも。結果として 1. 転職とかをする気がおきない(人づてに行き先がみつからないから) 2. 自分のプレゼンスを高めるためにがんばる、みたいなことをしない。(プレゼントする先がないから。)といったことがおきた。最初のチームにいたときは社内ソーシャルメディアで管をまくチームメイトもいたので自分も割とやっていたが、今はもう社内ソーシャルメディアもしなくなった。

まあ社外とか社内の遠い何処かとかはさておき、チームの隣人に対してはもうちょっとつきあいよくしてもいいかもしれないと最近は思っている。人として。人間的な接点がないと仕事場に「所属してる感」がなくてやや寂しい。ただ同僚とランチとか時間の使い方として贅沢すぎてちょっときびしい感があるし、週末に遊びに行くとかありえないかんじ。子供ができる前にもうちょっと社交しておくべきだったと思う一方、既婚者にはそれもバー高めなのだった。


全体として、大企業/外国ぐらしは自分を専門的なテクノロジを末端で行使する人にしている気がする。専門性がニッチに先鋭化していくのは望ましくないが、技術以外の側面を捨てるよう後押しされるのはプログラマとして生きていく上でいい圧力ではなかろうか。職業人生の前半と互換性がなさすぎて苦労はした。最初から大企業にいる人々はエリートネイティブという感じでうらやましいが、彼らは大企業にいるからエリートなのではなくエリートだから大企業にいるのだった。

もうひとつ、こうした圧に任せているとまったくエラくはなれないね。外国人でも圧と戦いながら大企業の中で偉くなっていく人々には尊敬がある。でも自分は舵を切りたくなったらそれを後押しする圧のある環境に移る方がいいな。そういう日が来るのか、そういう日が来たとして異なる環境が自分を受け入れてくれるのか、不安はあるけれども。