SF ベイエリアで働く1人のソフトウェアエンジニアとして、楽しくエンジニアリングをやっていくために日頃からぼんやりと心がけている3つのポイントについて今回は書いてみたい。

インフラを作る側にいる

ソフトウェアエンジニアとして普通の Software Engineer から Senior Software Engineer、Staff Software Engineer とだんだん昇進していくにしたがって、より大きな成果を出すことを期待される。Staff レベルにはチームをまたいだ成果を出すことが求められる。そのためには多くの場所で使われるようなサービスやライブラリを作るのが一番成果としてわかりやすい。

会社とプロダクトが初期段階から成長していく過程で、最初は1つしかなかったエンジニアリングチームが大きくなるにしたがってインフラ側とプロダクト側に分割されていく。そのときにかならずインフラ側に属するようにしている。インフラチームは、プロダクトチームが短期間で質の高い成果を出せるようなインフラコンポーネントを整備するのが仕事だ。だから構造的にチームをまたいだ成果を出しやすい立場にある。

他にも、インフラチームにいるとプロダクトのリリーススケジュールからある程度の距離を置けるので時間のかかるより本質的でインパクトの大きい解決策に集中して取り組めるというメリットもある。

ライブラリを作る側になる

SF ベイエリアのような世界中で使われるプロダクトを持つ会社がたくさんある環境では、競争戦略や要求されるスケーラビリティのレベルが違ったりする関係上、キーとなるインフラコンポーネントは社内で作ることが多い。ユーザー数が増えてプロダクトが大きくなっていくにしたがって社内でコンポーネントを内製するメリットはどんどん大きくなっていく。

そういう環境では、自社のプロダクトの状況に一番適したインフラコンポーネントを設計、実装できる力を身につけていると強い。そのために既存のいろんなライブラリの利点と欠点を表層レベルではなく実務的、CS 理論的レベルで理解してることが必要になる。ある時点での判断は状況が変化すると結論が変わりうるので、それに応じて理解をアップデートしていくことも大切だ。

低レイヤー側に強みを作る

何かを理解しようとするときには、実装とそれを支える1つ下のレイヤーについて理解を深めるようにしている。少し遠回りなようだが最終的な理解の精度は高くなる。

たとえば、Objective-C を理解するために C で組まれたランタイムのソースコードを読む、Foundation API を理解するために C のソースコードを読んだり POSIX API の理解を深める、HTTP や WebSocket を理解するために TCP で HTTP や WebSocket の簡単なサーバとクライアントを書いてみる、というようなことをやってきた。

アーキテクチャはレイヤーの上にもう少し高度で粒度の大きいことをやってくれるレイヤーを積み重ねることで構成される。上のレイヤーはより直感的で便利なことをやってくれ、下のレイヤーの扱いにくい細部を隠す。そこには必ずパフォーマンスや細部のコントロールができなくなるなどのトレードオフがある。そのトレードオフについて深い理解を持つことは周囲との差別化につながる。エンジニアとして周囲にいい影響を与え続けられるようになるためには、表層的な理解では不十分で、多くのファクトに基づいた深い理解が必要だと考えている。

最後に

上にあげたポイントは、ぼくが自分自身の好きなことや状況に合わせて考えて実践していることであって、状況が異なる他の人にはあまり参考にならないかも知れない。他にもいろんないい道があると思う。それぞれの人が自分なりのやり方を考えるときの参考にでもなればいいなと思って書いたので、それくらいの距離感で受け取ってもらえればうれしい。