大企業でプロダクトエンジニアとして働いたら、コーディングのスキルが下がっていた
背景
Shopifyという会社に1年半前に転職しました。あれよあれよと会社が拡大して、現在は従業員一万人弱くらいです。
画像元 公式ではない雑な情報です。あくまでイメージ
その前はChartmogulという、せいぜい20人、30人ぐらいの会社にいました。
なぜ表題のようなことを思ったか
面接インタビュアー側として、出題することになるコーディング問題を自分で試しに解いていました。一年半前には自分が受ける側の立場だったので、自分の腕前の定点観測ができました。
やってみてどうだったか。
コーディングにおけるシャープさという観点では明らかに衰えているな、と思いました。問題が与えられて、それに短時間で、論理的に向き合う力とでもいうのでしょうか。
自分は現職でマネージャの立場になったわけでもないので、これはマズイ。なんとなくこの一年くらいそんな気はしていたので、これを機会にもうちょっと深堀してみます。
なぜこうなったのか
背景として、自分は大規模なコードベースの中で、新機能の開発に注力している部署にいます。かなりインパクトのUpper Bound（伸び代）がでかい機能を作っていて、Shopifyが掲げるミッション "Make Commerce Better For Everyone"にダイレクトに貢献できる部署です。
この環境下では、既に組まれたパターンの中で「どううまく立ち回るか」という脳みそしか発達してこなかった、というのがでかいかなという現時点の分析に至りました。
社内で毎日のように使う言葉の中に「Alignments」というものがあります。動詞で使うと、"Get aligned" "I'm aligned with ***" とか。
Align - 合意に至る
これは他チーム、部署、組織とどのように合意にこぎつけるのか、その一連の流れをさします。
プロジェクトのライフサイクルとして、大まかに：
- プロジェクトの立ち上げ
- ステークホルダー明確化（他チーム、部署、他の会社）
- テックデザインを書く・プロトタイプをざっくりつくる
- インターフェースデザインのPRのマージにこぎつける
- サブコンポーネントのPRをどんどこ作る
という感じで進んでいきます。この全てのタイミングでAlignmentが必要になってきます。
革新的な機能は、往々にして既存のコンポーネントの中で完結しません。コンポーネント、チームをまたいだ開発をして初めて、インパクトのあるものができます。
最近やっている開発で影響を受ける他部署・チームの数を数えると、大体４、５の異なるライン・意思決定主体に及びます。彼らをいかに初期段階から特定できるか、彼らがすでに抱えている優先順位・ロードマップをどうすり合わせをするのか、というのが一番のレバレッジのきく作業になります。
PRの作成時のAlignmentを深堀り
たとえばDB Read周りのCachingという課題に対し、この規模までスケールする上で、対策がすでに何重にもなされています。
抽象化もそこそこされているので、自分がコードを書いているときに一番気にしているのは、「これは今あるパターンを侵害していないか」 ということなんです。
「そこそこ」というのがポイントで、自分も開発者の端くれなので「俺ならこう書く」というむらむらっとすることは多々あります。ただ、それをきちんとテックデザインとして仕上げるとなるとけっこうしんどい。
各デザインには歴史があり、それに依存するたくさんのコンポーネントがあります。俺はこうは書かないかな、と思っても、そのオーナーのチームと議論する時間があるくらいなら、機能開発をがりがり進めようという思考回路になっていました。
翻ってひとつ前の会社では
前職の会社では、そういった「いいからこれに従っておけ」というものがありませんでした。自分たちで、何が大事なパターンなのかデザインをしていかなければいけなかった。
会社全体としての集合知としては、現在の会社の方が格段に上だと思います。ただ、それらにすぐにアクセスできるか、という意味では、前職の方がシンプルでした。
悪いデザインを自分たちですぐ踏みそうになる、というのは、プロダクト運営においてはリスクです。でも、一ソフトウェアエンジニアとしては、そうではない。地雷が身近にあるという緊張感が、レベルアップに寄与します。
幽遊白書より 戸愚呂先生に教わったことはいくつもある
大企業で設計側にまわるためには
会社としての選択と集中という観点では、全員が設計してたらそれは全然効率よく進まないです。設計というのは、そもそも全員が考えなきゃ進まないんだったらいい設計じゃないですよね。抽象化できてないのですから。
だから、大きな会社が大きくなった過程で自然に生まれてきた 「API設計者」と「API使用者」のデベロッパーのピラミッド構造 があり、そのピラミッドのてっぺんの人たちがガンガン進めている設計があります。
作る人と使う人
そこに上り詰めるためには、もちろん有無を言わせない技術力・設計力はとても大事だと思います。でも、忘れてはいけないのは、コミニケーション能力です。
- 設計で必ず生まれるトレードオフ（取捨選択）。それが何故このドメインで長期的に効いてくるのか、ということを短期間でキャッチアップするためのヒアリング能力。
- それを、アドホックなグループディスカッションで有無を言わせず納得させるプレゼンテーション能力。
ここらへんが必要になってきます。コロナ禍、フルリモート環境で、母語ではない言語で、ここに投資することができなかった。
だから技術力が今落ちているのも仕方がないかなと。これが自分のここ一年半の振り返りです。
これが他の人に当てはまるわけではない
あらためていう必要もないですが、これは自分一人が、このタイミングで通ってきた道です。Shopifyは一緒に働く人がナイスな人しかいなくて（大企業でこれは、けっこう偉業だと思う） めちゃくちゃ働きやすく、やりたいことをやらせてくれる環境です。
個々人に裁量がある、という意味で、Sky is the Limit（どこまで伸びるかはあなた次第）という形容がぴったりはまる会社です。
この自己分析通りに他人が歩む確率はとても低いので、Shopifyに入るのが悪い選択肢、という誤解はしないでください。どちらかというと、組織が大きくなるにつれて一開発者が意思決定をするときのアドバイスとして受け取ってもらえれば幸いです。
これからどうするのか
この振り返りが前年末にできたことで、自分の意思をリードに伝えることができました。今月（2022年3月）から、Production Engineeringというグループに移籍しています。その中でも、SRE (Site Reliability Engineer)のチームに所属することになりました。
一年半、機能開発をガシガシやってきたことで、逆にSRE側にまわったときに「お互いの気持ちがわかるデベロッパー」になれるのかもな、と思っております。どう生かすは私次第。
大企業の本質的な辛みでいうと、ピラミッド構造、そこに生じる根回し・コミュニケーション能力へのパラメータの割り振り、というのは今後自分がどう向き合いたいか、決めていません。
大きくなっていく組織を効率的に動かすための力学と、個々人の成長可能性はトレードオフにあるのかな、と悲観的に思いますし、それはまだまだ見ている世界が狭いだけだ、とも思います。
会社側の目線・マネージャー側の目線にたったら、どう改善できるか
うーん、どうやるんでしょうねぇ（爆
けっこう鍵を握るのは、偶発性（セレンディピティ）を特にオンラインでどうやって起こすか、ということだと思うんですが、これはまた別の機会に。
この記事は、思考を育てるノートアプリSuikoを使って書きました。
ご興味ある方は下記のリンクより、ベータテストにご参加ください。
それではまた！
Discussion