シェア
はてブ
ソフトウェアエンジニアの藤吾郎（@__gfx__）と申します。最近、IC（Individual Contributor / 個人貢献者†）という言葉でキャリアが語られることも増えてきたように思います。この記事では、ソフトウェアエンジニアにおけるICというキャリアパスについて、自分の認識と経験を交えて次の点から解説していきます。
- ICというキャリアパスがあることを、ソフトウェアエンジニアに知ってもらいたい
- 私が39歳という年齢でIC一本でいくと決意するに至った経緯は？
† Individual Contributorにはまだ広く認知された訳語がなく、ここでは原文のニュアンスに近い訳を掲載しています。一般には「管理職」の対比として「専門職」と呼ばれることもあります。（注釈を追記）
「IC」とはどういったキャリアなのか？
ICとは、マネジメントの責務のない専門職です。単に「管理職（マネージャ）」との対比として用いられることもありますが、企業におけるキャリアパスとして明確に定義されることもあります。例えば以下にあるLinkedInやIndeedの記事では、企業におけるICの役割や能力が解説されています。
▶ What are individual contributors? - LinkedIn
▶ What Is an Individual Contributor? - Indeed.com
このように呼称としてはもともとUSの企業が由来ですが、日本でもICのキャリアパスを用意する会社が増えているようです。たとえば最近でも、IoTベンチャーの取締役CTOだったSongmuさんがサンフランシスコ・ベイエリアを本拠とするスタートアップ「Launchable」にICとして転職したエントリが話題になりました。
▶ 41歳のエンジニア、マネージャーからICへのキャリアチェンジ | おそらくはそれさえも平凡な日々
管理職ではないキャリアとしてのIC
ICは、管理職ではない専門職を意味する言葉です。管理職という役職の対比に当たるので、ICも役職といえるかもしれません。社内にICというキャリアパスがある場合、その「出世」はICの職位が上がることを意味します。
例えば、私の現職（Fastly, Inc. / 本社はサンフランシスコ）の技術部門において、ICは「Engineering Individual Contributor」として、E1（下位）からE7（上位）までが定義されています。一方の管理職では「Engineering People Manager」として、M3からM7までがあります。この2つのキャリアパスは、求められるスキルに一定の重なりはあるものの、異なる出世の階段として定義されています。
私の場合はE3（Engineer）として入社し、現在もこの職位です。次のE4（Senior Engineer）になるには、スキル・コミュニケーション能力・顧客理解・リーダーシップなどの点で、E3よりも高い水準で評価される必要があります。コミュニケーション能力でいうなら、E3では「議論に貢献したりファシリテートする」ことが求められ、E4ではさらに「意見の衝突をうまいこと解決する」ことなどが加わります。
なお、ICだからといって管理職に必要とされるスキルが全く不要というわけでもありません。職位が上がるにつれて、例えばプロジェクトをリードしたり、チームの内外とコミュニケーションを取りながらプロジェクトを進めることが求められます。小さなプロダクトであれば、実質的にプロダクトマネジメントを担うこともあります。ICというのは、単に部下を持たないというだけのことです。
余談ですが、一般に「Senior Engineer」の次は「Staff Engineer」と呼ばれることが多いようです。カタカナで「スタッフエンジニア」と書くと字面が頼りないのですが、ソフトウェアエンジニアとしてはかなり上位になります。
これからICを定義する企業は増えるか
規模が大きな会社でも、明確にICというキャリアパスがあるとは限りません。例えば「エンジニア」の上位の職位で「（エンジニア）マネージャ」が配置されているのであれば、ICというキャリアパスが確立されているとは言えません。私が過去所属した企業でも、ごく一部のエンジニアには「スペシャリスト」というキャリアパスが用意されることはありましたが、決してそれは普通のキャリアパスではなかったように思います。やはり「出世」というのは管理職になることだという印象です。
一方で規模が小さな会社では、そもそもキャリアパスそのものがないこともあるでしょう。もっとも私の前職はスタートアップでしたが、IC的な働き方をしていました。創業メンバーではありませんし、チームをリードこそすれマネジメントはしなかったので、組織として定義された職位はありませんでしたが、ICではあったと言えます。
それでも、ベイエリアのエンジニアリング文化を理想としている日本の技術系スタートアップでは、明確にICを定義しているベイエリアのスタートアップに倣って、これからICというキャリアパスを明示的に用意する組織も増えてくると思います。
所属企業のエンジニア組織にICというキャリアパスがあるかどうかはそれほど重要に思えないかもしれませんが、自分がICであると自覚するにはキャリアパスが存在するほうがよいでしょう。
私がICというキャリアパスを選ぶことになるまで
ここからは、私のキャリアパスについてお話します。私は生涯、現役ソフトウェアエンジニアでありたいと考えています。しかし、私がICというキャリアパスを認めて自覚するようになったのは、2019年に現職に転職してからです。それまでは「ICという名前は知っている」という程度でした。
ソフトウェアエンジニアになるつもりはなかった
私の社会人としてのキャリアの始まりは、家業の手伝いや飲食店のアルバイトでした。20歳前後、高校を中退してから数年間はフリーターとして過ごしていたのです。趣味ではPerlやJavaScript、C/C++を使ってWebサービスを動かしてはいたものの、ソフトウェアエンジニア（当時の認識だと「プログラマー」）になろうとは思っていませんでした。
もともと志望していなかったというより、選択肢として明確に「ない」と思っていました。というのも、私がプログラミングを独学しはじめた2000年代初頭では、ネット（当時はBBSや掲示板と呼ばれるシステムを中心に、さまざまなサイズのコミュニティが各地に分散してありました）で語られる「プログラマー」や「システムエンジニア」の職場環境はひどく悪く、自分にはとうてい務まりそうにないと考えたからです。
しかし、家業にはあまり興味が持てず、飲食店も働くにつれて自分向きではないと考えるにいたって、別の職業を探すことにしました。いろいろあって高認（高等学校卒業程度認定試験）を取って大学に進んだのが24歳のとき。この頃はカウンセラーないし心理系の専門職に就こうと考え、心理学科に入りました。
それから4年間の大学生活は学業やサークルを楽しんで過ごしましたが、一方で心理学は学ぶにつれて職業にするほどにはしっくりこなくなり、卒業後の方向性については苦悩することになりました。
27歳で選択したソフトウェアエンジニアをウロウロする10年
大きな転機はコミュニティとの出会いです。在学中に友人がRubyKaigi 2008のスタッフをしていたことをきっかけにRubyコミュニティを知り、そこから竹迫（@takesako）さんに誘われて、主催するShibuya.pmに出入りするようになりました。当時、最も熱中していたプログラミング言語はPerlで、RubyKaigiでもPerlをテーマにLTしたりしていたことでPerlコミュニティの目に止まったようです。
そして、Shibuya.pmで知り合った人たちがソフトウェアエンジニアリングについて楽しそうに語っているのを見て、プログラマー職に就いてみようと決意したのです。大学を27歳で卒業し、当時Shibuya.pm界隈で転職する人が多かったDeNAに新卒で入社し、2年を過ごします。その後、スタートアップに行きますがあまり合わず半年で辞めて、DeNAの元同僚に誘われたCookpadで3年を過ごします。さらにCookpadから出て起業した元同僚に誘われて、スタートアップであるBit Journeyに転職します。
ここまで、とくに将来のキャリアパスやスキルの方向性を考えて、転職先を決めていたわけではありません。むしろプロダクトや会社の第一印象が大きく、考えていたのはこういったことでした。
- 自分や家族が使うようなプロダクトのために働きたい
- プログラミングは好きなので、開発をメインにしたい
- マネージャが向いてるとは思えないし、やりたくもない
例えば最初の転職先のスタートアップは半年で辞めたものの、当時興味をもっていた「教育×スマートフォン」をテーマにしていました。Cookpadにいたのは料理が趣味だからです。Bit Journeyで開発していたのは、Cookpad社内で使われていたGroupadという内製wikiにインスパイアされたサービスでした。
スキルの面でも、その時々のプロダクトにとって必要な技術に集中した結果、Objective CやJavaでスマホのライブラリやアプリ、Perlでサーバーサイド、Railsでサーバーサイド、JavaScript/TypeScriptでWebフロントエンドと、広く浅く手を広げてきました。
いずれの職場も明示的にICという役職があったわけではありませんが、なんとなく「上（マネージャ）に行きたくない」という思いでウロウロしていたため、IC的な専門職の働き方を続けることになりました。
Fastlyに入社して初めて明示的にICとなる
Bit Journey時代に子供が生まれます。子供の教育を海外で受けさせたいという妻の希望や、今後のキャリアの選択肢を増やしたいという私の希望もあり、海外に拠点のある会社を探して、現職のFastlyに転職しました。技術的にはもともと経験したかった低レイヤー・ミドルウェアの開発であること、またDeNAやCookpad時代の元同僚がいることも決め手でした。
ここにきて初めて、能動的にキャリアパスやスキルの方向性を考えた転職活動をしたのです。そしてFastlyに入って初めて、Engineering Individual Contributorという明示的に用意されたICになりました。
これまでもずっと同じように専門職として働いてきましたが、なんとなく「上」に行きたくなくてウロウロしていた場所には、実はICという名前があったのです。さらに、ここではずっとICとして職位を上げていくことができます。私はこの状況をとても気に入っています。
現在の私は、現職でICというキャリアパスに乗ったことでICを自覚し、ICであることにアイデンティティを見出しています。
ソフトウェアエンジニアとして働く主軸としてきたもの
これまでのキャリアは前述のようにかなり行きあたりばったりでしたが、その中にも不動となる主軸が2つありました。これはソフトウェアエンジニアとして何年も働いてから振り返ってみて、こう考えるとしっくりするものです。
1つは「毎日楽しく開発したい」ということ。私はプログラミングが好きです。とにかく動かすことを念頭に雑にプログラミングするのも好きですし、保守性と安全性に注意を払って綿密にプログラミングするのも好きです。新しい技術を追いかけたり使うのも好きですし、枯れた技術で開発するのも好きです。
もう1つの軸は「選択肢を常に複数確保する」ことです。特にキャリア初期の迷走期を思い返すと、選択肢が1つもない状態は不安なものだと強く思います。選択の余地は、ソフトウェアエンジニアのキャリアパスに限定したとしても、どこにでもあります。ロール、チーム、プロダクト、会社、居住地、居住国、技術分野、言語。いずれも好調・有利なときもあれば、不調・不利なときもあります。
そして現職でICというキャリアパスを知ったときに、自分の軸を守りながら会社で職位を上げていく働き方が、ICであればできそうだと自分の中でしっくりきたのでした。例えば「毎日楽しく働きたい」思いを支えるために情報収集を日々行うことは、ICとしての成長につながります。「選択肢を複数確保する」ことも、ICとしてのリスクヘッジそのものなのです。
ICに自覚的なエンジニアと企業がもっと増えることを願って
私にとってのICは、それを目指した結果というよりは、紆余曲折するうちにいつのまにかそうなっていたというキャリアです。興味のあるプロダクトを渡り歩くことはいい経験でしたが、一方でキャリアパスについては「職位の階段を登るとマネージャになってしまうのか」と何となく落ち着かない気持ちでした。
そして今、現職を含めてベイエリアではICが明示的に定義されており、それが普通だと知って、安心してICでいられます。おそらく今後も、ICのある会社で働き続けるに違いありません。本記事を通じて、ICについて自覚的なソフトウェアエンジニアが増えて、その結果ICのキャリアパスを置く企業がもっと増えるといいと願っています。
編集：はてな編集部
藤 吾郎
株式会社ディー・エヌ・エー、クックパッド株式会社、株式会社ビットジャーニーでのソフトウェアエンジニア経験を経て、2021年現在ファストリー株式会社に勤務。インターネットとプログラミングが好きで、ツールやライブラリをOSSとして多数公開している。
ブログ：Islands in the byte stream
