10年かけて、世界で通用するソフトウェアエンジニアに。自分の得意分野を磨いてキャリアアップ

僕はコンピューターサイエンスを修めたわけでもなく、小さいころからコードを書いていたわけでもない状態でこの業界に入りました。最初はソフトウェアエンジニアですらなく、新卒から10年のうちでコードをしっかり書いていたのは3年程ですが、Big Tech とも呼ばれる Amazon ではシニア開発エンジニアに昇進でき、転職した今はスタッフソフトウェアエンジニアとして働いています。第3回では、どうやってそこまで叩きあげてきたのかの話をしつつ、コードを書く以外のスキルやソフトウェアエンジニア以外の役割もご紹介できればと思います。

• keyboard_arrow_down ソフトウェア開発未経験のままインフラエンジニアでキャリアスタート
• keyboard_arrow_down 1年間のソフトウェア開発、3年間のソリューションアーキテクト
• keyboard_arrow_down 再びソフトウェア開発、シニアへの昇進
• keyboard_arrow_down サポートエンジニア、そしてスタッフソフトウェアエンジニアへ
• keyboard_arrow_down コードを書く力だけが必要とされる能力ではない
• keyboard_arrow_down Individual Contributor (IC) として上に登っていくためには
• keyboard_arrow_down 連載まとめ

パソコンは Windows 3.1 の頃から家にあって、小学校高学年の頃に親に頼み込んで ISDN （64 Kbps!） を契約してもらってからインターネットにも触れましたが、学生時代はプログラミングなんてものにはまったく興味なく過ごしました。中学高校では HTML と CSS でリッチな UI がつくれるらしいと知ってホームページなるものをつくってみましたが、それだけでした。大学では授業や研究で多少は Java や C/C++ を触りましたが、あくまでも手段であり何かをつくりたいとは思っていませんでした。

その後、就職活動をするにあたって、どうやら自分がインターネットで使っている Google 等のサービスもソフトウェアで動いているらしいと認識して、そこからソフトウェアエンジニアに興味をもって受けた中で内定をもらえたのが DeNA でした。入社後の新卒の配属先を決めるにあたって選択肢が2つあり、ソフトウェア開発とインフラ担当の2部署がありました。ソフトウェア開発の部署はわからないなりにも多少仕事のイメージはついたものの、もうひとつのインフラ担当の部署はサーバーもネットワークも全然理解していなかったので、まったく仕事の想像がつかない部署でした。

そこで、どうやら僕は知らないことを学ぶ方が好きな性格らしく、敢えてよくわからないインフラ担当の部署の配属を選びました。当時の DeNA はデータセンターにネットワーク機器やサーバーを自前でたくさん並べて運用していました。僕は何もわからないけれどもデータセンターに行って、納品された大量のサーバーの段ボールを開けてラッキングしてその後1台1台セットアップする、といったことからキャリアを始めました。

折しもソーシャルゲームという物がヒットし始めた頃で、僕はサーバーサイドのインフラ担当としていくつかのソーシャルゲームタイトルの運用をしました。それまで DeNA が経験したことのないようなレベルのトラフィックを捌きながら、成長していくサービスを支えるためのオンコール対応やキャパシティプランニング、データベースのクエリ分析や水平・垂直分割などをしていました。

ここでの経験は、分散システムの機微を肌で理解し、未知のトラブルに対していかに対応するかの技術が身に着けられたので、非常に良いものでしたが、コードを書くことはほぼありませんでした。代わりに、他人が書いたコードを隅から隅までどうやって素早く読み解くか、という技術が身に付きました。

新卒から4年程はそんな感じで、仕事でソフトウェア開発をすることはほとんど無かったですが、個人では勉強がてらいろんな言語を触ったりアルゴリズムの勉強をしていました。そんな時にDeNA でまったく新しいサービスを開発する部署ができ、僕はその時点ではプロとしての開発経験ゼロでしたが、その新設の部署でソフトウェア開発者をさせてもらうことになりました。

一緒に入った数人のエンジニア達と全体設計から技術スタックの選定、基盤となるコードやライブラリの開発、更にはセキュリティ関連の実装や CI/CD の設計実装、などなど、ビジネスロジックの開発以外も含め手広く経験することができました。たった1年弱の期間でしたが、これが僕の人生で唯一がっつりとソフトウェア開発を行った時期になります。

その後は、Amazon に入って AWS のソリューションアーキテクトという、お客さんと話をして技術的なアドバイスをする仕事を3年程やりました。DeNA でインフラ担当の時には他人の書いたソフトウェアを運用していましたが、今度は他人の書いたソフトウェアを売る仕事になりました。ソリューションアーキテクトでの経験は非常に有益で、今でも役立っています。お客さんと会話して本質的な課題を探る技術、やりたいことに対して最適なアーキテクチャを瞬時にデザインして説明する力、さらには自分の担当以外にも世界中の数多の業界のお客さんのシステムをたくさん目にすることができて、審美眼が磨かれました。

一方で、Amazon 規模でのソフトウェア開発にも一度は携わってみたかったので、カナダへの移住と合わせてソリューションアーキテクトから開発エンジニアへと役割も変えました。カナダへ移ったあとは Amazon S3 という世界最大規模のオブジェクトストレージサービス、および Amazon EKS というコンテナ基盤を提供するサービスの開発エンジニアを3年程やりました。

Amazon は “You build it, you run it” というモットーなので開発者でも運用の比重が非常に高く、オンコール （アラートへの対応を当番制で24/7で行う） のローテーションに入ることは重要な期待値です。特に S3 は非常に複雑な分散システムなので、数か月かけてじっくりと仕組みを把握しつつ、シャドーイングという当番の人の横についてオンコールをするトレーニングを経て、僕もオンコール対応にあたっていました。ソフトウェア開発の仕事の方では、ビジネスロジックの開発よりも運用周りやキャパシティに関わる周辺ツールといった他の人が苦手とする分野の開発を多く担当しました。

S3 の仕事にようやく慣れてきた頃、複数のチームに跨ったシステム全体のキャパシティの課題を解決するプロジェクトを牽引することになりました。すごく単純化すれば解決策自体は自明で、システムのスケールを制御しているいくつかのパラメータ（例えばスレッド数）を大きくするだけで良いはずでした。しかし、問題は今までそこまでスケールさせたことがないので何が起こるかがわからない、そもそもどこまでスケールさせればいいのか誰もわからない、という事でした。

なので、課題を整理してターゲットの数値を明確にした文書を書いて関係者と合意を取り、次に関連するコンポーネントのコードを読みメトリクスを分析しまくって、実際にどのパラメータをいじる必要があるのかを特定しました。そしてステージング環境で負荷試験ができるようにしてパラメータ変更の副作用を洗い出し、最後にパラメータ変更のロールアウト計画を書き上げて、たくさんの関係者とレビューして安全に本番環境へ適応できるようにしました。

実際に変更したところだけ見れば数個のパラメータを変更しただけですが、それを安全かつ確実に行うために半年以上費やして準備をした形です。これだけ苦労したのは、対象のシステムがいわゆる単純なリクエスト・レスポンス型ではなく、それらを統合管理する”コントロールプレーン”と呼ばれる非同期ワークフローのお化けみたいなシステムだったためで、負荷試験ひとつとっても工夫しないと簡単には実施できませんでした。

このプロジェクトが主な貢献となって、シニア開発エンジニアに昇進することもできました。Amazon ではシニアになると、コードを書く機会よりも上記のプロジェクトのような曖昧かつ複数のチームを巻き込むものを牽引して、他の開発者にタスクを分散していくといった仕事が増えます。そのため、コードを書く機会の方を重視して敢えて昇進しない人というのも一定数いたりするぐらいです。

その後は、Autify というスタートアップに転職し、今度はサポートエンジニアになりました。再度、他人が書いたソフトウェアを扱う側に戻りましたが、今度はお客さんの課題を直接的に解決する仕事になりました。もちろんサポートエンジニア自体はそれまでやったことが無かったのですが、トラブル対応は DeNA の時も Amazon の時もずっとやってきているので慣れたものでした。

新しかったのは技術ドメインの方で、ブラウザやモバイルアプリの自動操作関係は全然触ったことが無かったので学びが多かったです。サポートエンジニアを1年ほどやってみて、今度はもっとビジネスに近い領域に貢献したいと思うようになり、最近ではスタッフソフトウェアエンジニアとして新しいサービスや機能のデザインに、主に技術的な観点から貢献しています。

10年強の経験を改めて振り返ると、ソフトウェア開発者としてコードを書きまくる仕事をしたのは、実は DeNA での新サービス開発をした1年弱くらいでした。Amazon では運用そのものや先述のプロジェクトのようにソフトウェア開発以外で貢献することの方がむしろメインでしたし、それ以外のキャリアはインフラ担当やソリューションアーキテクトをしていました。ですが、Amazon ではシニアとして認めてもらえ、今はスタッフとしてデザインや他の人が書いたもののレビューをしています。どうしてコードを書かない人がここまでキャリアアップできたのでしょうか。

ひとつは、コードを読む力があったからでした。僕はもともと CS の素養がない状態かつ開発業務自体を与えられない状態で、自力でソフトウェア開発を学びました。そのため、他人が書いたコードを読み漁ってそこからパターンを見出しながら自分のスタイルをつくっていきました。なので、どれだけ大規模なコードベースでも読んでいくことに抵抗がなく、そのお陰で S3 でのプロジェクトのような読み解くことが重要なタスクもこなすことができるようになりました。

しかし、周りを見てみると意外とコードを読むのを苦手としている人も多かったので、キャリアを構築する上ではうまく差別化できたと思います。
注: 詳しい話は別途ブログにもまとめていますので、よければこちらもご覧ください。
コードが読めるソフトウェア開発者

もうひとつは、文書を駆使していろんな人を説得していける力があったからです。これは Amazon で徹底的に鍛えられた技術ですが、コミュニケーションツールとして文書を用いていくことで、複雑に関わりあうステークホルダー間での合意形成を効率よく行うことができます。その文書を高い質・量で生産していけるスキルは、より大きなスコープで成果を出すために非常に効果的です。口語やスライドショーのような形式とは違い、Amazon が用いる「 Narrative （物語） 形式」と呼ばれる文書のスタイルは、同期でも非同期でも情報の伝達を正確に行うことができて本当に強力です。

僕は文書を書くのはもともと好きでしたし、Amazon では Narrative のスキルを上げるためのトレーニングなども受け、今でも僕のメインのアウトプット形式として活用しています。
注: こちらも詳しい話はブログにまとめてあります。
質の高い技術文書を書く方法

最後に、ソリューションアーキテクト時代に特に鍛えられた、システムの設計力も重要でした。分散システムに置ける勘所、適材適所を使い分けるパターンの引き出しと創造力は、トラブル対応から新しい仕組みを実装して運用するところまで、すべての場面で役に立ちます。Amazon にいた時には、社内に過去10年以上分がストックされている技術的な発表の動画を見まくって、知識を吸収していました。特に、“Design for failure” と呼ばれる常にありとあらゆる箇所で障害が発生することを考慮できる深い思考は、事前に問題を察知できることになるので地味で気づきにくいですが、安定したシステムを提供するためには欠かせません。
注: 例えば Cell-based Architecture は非常に有効な手法です。英語ですが、こちらで記事を書いています。

Individual Contributor (IC※) として上に登るためには、何かしら他の人にはできない、そして自分ひとりだけでは出せないような高い価値を出し続ける必要があります。それが、バリバリとコードを書いて画期的なサービスを生み出し続けることの人もいれば、チーム内外と密にコミュニケーションをとり続け、チームを引っ張っていくマネージャーに近い様な動き方のできる人、そして僕のように既存の環境を読み解いてアイデアを文書としてまとめて合意を取り他人を動かしていく人、など人によってさまざまな価値の出し方があって、正解はないです。自分の得意分野を見極めて、それを最大限に活かして結果を出す方法を見つけていくと良いでしょう。
（※） ：IC とは、People Manager の様にチームのパフォーマンスで組織に貢献するのではなく、個人の能力で組織に貢献していく働き方です。

また、その「得意」はソフトウェア開発そのものではないこともあります。僕が経験してきたインフラやソリューションアーキテクト、サポートエンジニアのように、ソフトウェア開発の周辺にもたくさんの役割があり、ソフトウェア開発の高いスキルがあることはそれらの役割を行うにあたっても非常に価値の高いものとなります。ほかにも、プロダクトマネージャーやビジネス開発、テクニカルセールスまで、よりビジネスに近い役割もたくさんあって、高い開発スキルを元にそうしたポジションに登っていく人を何人も見てきました。

過去ブログ：ソフトウェア開発スキルを活かせるB2B SaaS 企業でのポジション

最後に、こうした IC としての高いスキルには国や地域の違いというものはなく、僕は日本とカナダで学んだスキルの総合力で、世界で通用できるようになりました。皆さんも IC として上に行きたいという志向があれば、社内の周りをみるだけでなく、世界を見て自分の得意なところを発見し、それをとことん磨き上げていくことで、世界でも十分通用するようになれるのではないでしょうか。

というわけで、僕がこの10年でしてきた経験を、移住・英語・スキルという3つの切り口でお話させて頂きました。これらが何かしら似たようなキャリアを考えられている方の参考になったのであれば幸いです。僕自身も、この10年間を通して先達の方からたくさん教えて頂いたことでここまでたどり着くことができましたので、ぜひ“恩送り”をしたいと考えています。何かしら僕でご相談にのれることがあるようでしたら、いつでもご連絡下さい。
※ 1on1 のお申し込みはこちら。