技術もマネジメントも壁にぶつかり、役員は退任、転職も失敗。それでも自らを肯定する、稲垣剛之の「螺旋型」キャリア
-
執筆 : 鈴木陸夫
- /
-
写真 : 藤原 慶
- /
-
編集 : 小池真幸
- /
ラクスのプロダクト部の部長・稲垣剛之さんのキャリアは、これでもかというほど思い通りにいっていない。
技術で生きていくと決めたつもりが、圧倒的才能を前に「それはまやかしだった」と思い知らされた。
ゲームを作りたくて入った会社で、任されたのはブログサービスの開発だった。
「もう一度イチエンジニアとして」と発起した直後に、またマネージャーを頼まれた。
開発を管掌する取締役のはずが、まったく専門外のバックオフィスまで任された。
憧れ駆動で足を踏み入れたAWSへの転職は「明確に失敗だった」。
役員という、通常であれば「上がり」とも思えるポジションから降りていることも含めて、一般的なモデルでは説明しにくいキャリアを歩んでいる。
「外から見たらしっちゃかめっちゃかですよね」と笑いつつ、今の稲垣さんはしかし、自身の歩みをひとつのまとまりのあるものとして肯定的に捉えているようだ。
あとから振り返って見出した「軸」など、後づけの物語にすぎないという見方もできる。一方で、これほど思い通りにならなかったキャリアをたどってなお、本人にさえ認知できていなかった何かが、一貫して選択を方向づけていたようにも見える。
思い通りにならなかった選択。人はどこまで、そしてどのようにして「自分のキャリア」として引き受けることができるのだろう。
プロフィール
- 稲垣剛之(いながき・たけし)株式会社ラクス プロダクト部 部長大学卒業後、CSK(現SCSK)に入社し、約10年間ウェブ系システムの開発に携わる。ニフティを経てクルーズに入社し、ECサービスの開発責任者や分社化した新会社の役員を務める。AWSでの技術サポートマネージャーを経て、2021年8月ラクスに入社。2025年10月より現職。
大工は無理でも、設計士ならいけるかも
登壇資料やnoteでの発信などを拝読すると、稲垣さんは一貫して「どうやって価値を届けるか」という問いに忠実な方に映ります。だからこそ手段に固執しすぎず、領域を拡張していくキャリアを歩んでこられたんだろうなと。振り返って、いつごろからそういう意識をお持ちだったんですか?
それでいうと、最初はまったくなかったです。そもそも、エンジニアを目指そうとはあんまり思ってなかったので。
そうなんですか。
私が就職活動をしたのって、いわゆる就職氷河期だった2000年ごろ、一番厳しかったときより少しだけマシなくらいの時期で。経済学部の文系学生だった私の頭の中に、エンジニアっていう選択肢はなかったんですよね。まあ正直、結構サボってる学生でもあったんで、どんな仕事に就こうかみたいな、ちゃんとした考え自体があんまりなくて。就職活動では最初、営業職ばかり受けていました。『下町ロケット』に出てくるような、みんなが知らないだけで、実は世界でめちゃくちゃ通用している部品を作ってる会社の営業がいいな、とか思って。
ただ、やっぱり氷河期なので、相当にきつかったんですよね。なかなか受からなくて。で、その中で徐々に興味が向いたのが、システムエンジニアだったんです。


どうしてSEだったんですか?
SEに関しては当時、世の中に「必ずしも理系学生じゃなくてもよくね?」っていう雰囲気が漂い始めてたんですよね。SEって、システムを作る仕事なので。プログラミングそれ自体というより、設計力とかコミュニケーション力が重要になる。プログラミングは教えればある程度なんとかなるし、文系学生でもいいんじゃないか、っていう理屈です。それで、大量募集している会社がいっぱいあったんですよ。
一方で、私にはもともと、世の中の非効率に対してモヤモヤするところがあって。学部の研究テーマに電子マネーを選んだのもそのためで、「なんで小銭なんて使ってるんだろう」「モタモタしているこの時間がもったいない」「この非効率をなんとかしたい」、そんなふうに思って、当時、電子マネーを実験的に取り入れていたイギリスまで調査に行ったこともありました。改めて考えてみれば、こうした非効率を解決するためにあるのがシステムなんですよね。
で、実際にいろいろな会社の説明会に行ってみると、「SEは大工ではなく、設計士なのである」みたいな言葉にも出会って。「大工はさすがに無理だけど、設計士だったらなんとかなるかも」と思って、そこからSEを目指す方針に切り替えた、という感じです。
それで選んだ最初の会社が、大手SIerのCSK(現SCSK)だったわけですか。
他にも何社か内定はもらっていたんですが、そこが一番会社として大きかった、というのが選んだ理由です。プログラミングをまったくやってこなかったから、やっぱりめちゃくちゃ不安だったんですよ。いくら設計士と言っても、最低限は大工のこともわかってなくちゃダメだろう、と。その点、大きな会社の方がしっかりした研修があることはわかっていましたから。
技術って楽しい。私は技術で生きていく
入社してみてどうでしたか。


入ったら、新卒の同期が200人もいたんです。そこでいきなり情報処理の試験があって、その結果でグループ分けされました。めちゃくちゃ優秀な人たちと、普通の人たち。そんな勉強を一切してきていない私は、当然、普通のグループです。
研修は朝9時から夕方6時まで缶詰状態。半年間、インターネットの基礎からプログラミングまで、ひと通りのことを全部教えてくれました。ただ、やっぱりプログラミングがとにかく苦手で。当時は今のようにウェブではないから、ただの黒い画面にアスタリスクをピラミッド型に並べる、みたいなプログラムなんですよ。見よう見まねでやるんですけど、どうしてもアスタリスクが横一列にズラーっと並んじゃったりして。苦労しました。
しかも、研修の成績で配属先が決まる世界だった。当時は教育や金融が大人気で、ウェブ系はまったく人気がなかったから、希望したわけではないんですが、ウェブ系にいくことになりました。ちょうどJavaが出てきたくらいの時代で、Cすらわからないのに、いきなりオブジェクト指向をやれと言われて。さらに3ヶ月ほどJavaの研修を受けて、そこからようやく現場に入りました。
現場に入るまでは、正直めちゃくちゃ嫌でした。プログラミングの部分で周りとの差がすごかったから。でも、それが現場に配属されたらガラッと変わったんです。
何が違ったんですか?
今でもそうなんですけど、私はおそらく「マニュアルを見ながら」みたいなことが無理なんですよ。目的さえあればいくらでも勉強するんだけど、研修時代には目的がないので。プログラミングができたからといって、それが何かに貢献しているわけじゃない。テストは単純に、それができたかどうかを確認するだけのものじゃないですか。
でも、現場に行くと、そこには必ず解決しなくてはいけない課題がある。学ぶのも、今あるソースをなんとかして動かすのも、全部その課題を解決するため。そういう環境に身を置いたら、3ヶ月から半年も経つと、なんとかなるようになったんです。
目的があるから頑張れる。エンジニアには必要がなくてもものを作ること自体が好き、技術それ自体が好きという人も多いですけど、稲垣さんはどちらかというと、そうではなかった?
そうですね。プログラミングやものづくり自体を楽しいと感じる体験は、どちらかというとあとから来た感じです。黒い画面にひたすらアスタリスクを書くのはめちゃくちゃ苦痛でしたけど、現場に行くと、自分がやったことで画面が動く。今まで見えていなかったものが目に見える形で現れて、それを誰かが使っているという状況が生まれる。そういう体験を重ねるうちに、プログラミングが楽しいものへと変わっていったんです。
なので、一時は「技術を極めよう」と思ったんですよ。もっと綺麗に作るにはどうすればいいのか。もっと早く作るにはどういう設計がいいのか。そのために新しい技術に積極的に手を出してみる。そういうふうになっていったんです。


技術を追求することそれ自体が好きになっていった。
もちろん目的意識がまったくなかったわけではないですけど、マネジメントよりも技術を極めていく、具体的にはアーキテクトだったりの道を突き詰めたいと思っていた時期が、20代後半から30代前半にありました。『Java World』とか『WEB+DB PRESS』とかを毎月買って、そこに載っている、まだプロダクションコードでは使われていないような技術を自分なりに試してみたり。幸い、仕事柄いろいろな現場へ移って、試す機会が結構あったので。
自分だけで何かを作って試すより、実際に動く現場で試す方が、自分の場合は身につきやすいし、考えることができる、というのは感じていました。個人でやっていると妥協しちゃうんですよ。結局、自分に言い訳ができちゃう。自分に甘いので、言い訳ができる環境だと、たぶんやらなくなっちゃうんですよね。「わからないところは触れなくていいか」みたいな感じで。
でも、現場で適用するとなるとめちゃくちゃ工夫するし、めちゃくちゃ考える。「なんとか適用しよう」っていう脳味噌になる。そういうところには、もともと持っていた目的志向が出ていたんじゃないかなと思います。
技術力じゃないなら、自分の価値ってなんだろう
「一時は」技術を極めていきたいと考えていた。SIerで9年半働く中で、それが変わっていったということですか?
20代後半にもなると、やっぱりイチエンジニアで、というわけにはいかなくなるんで。業務委託とか社員のエンジニア数人を引っ張る、開発リーダー的なものをやる立場になりました。でも、このころの私は、リーダーとかチームとかいうことをあんまり考えてなかったんですよ。もちろん立場上、面倒を見ることはしていましたけど。意識にあったのは「私自身がどれだけ技術を発揮できるか」ということだけでした。
そんな中、自分がリーダーとして、一個下のサブリーダーと一緒にプロジェクトを立ち上げる機会があって。当時の私は、自分は結構技術のできる方だと思っていたんですが、彼も同じぐらいのレベルで会話できる人だったから、二人で相談しながらアーキテクチャから作るのは、めちゃくちゃ楽しかったです。
その後、チームメンバーがつくフェーズになって、私には10人ついて、彼には5人ついた。ショックだったのは、そこからの個としての生産性が、彼の方がすごかったことでした。私はまったく生産性が上がらなくて。


技術力には自信があったのに、その自信のある部分で負けたと感じるような経験だった?
今考えれば、私は10人も見ているわけだし、生産性が上がらないのも当然なんですけど。当時は個としてしか考えてなかったので、そういう考えにはまったく至らなくて。「私は彼ほど生産性を出せていない」「世の中には到底敵わないような優秀なやつがいるんだ」と思った出来事でした。
そう思い始めた矢先に、今度は当時急成長していた大手のネット企業に常駐することが増えて。合わせて5年以上お世話になったと思いますが、そういうところへ行くと、「これまで自分がやってきたことはなんだったんだ」と思うぐらいのレベルの人がたくさんいて。さらに殴られるみたいな経験をすることになりました。
同じ会社の中でさえ、到底敵わないすげえやつがいると思ったのに、そういう会社ともなると、本当に技術が大好きで、私が1週間かかることを2、3日で仕上げるような人がごろごろいて。 そういう人たちを見たときに、「ああ、ちょっとこれはダメだ」「技術で生きていけると思ったのは、まやかしだった」と思いました。自分は技術にのめり込んでいたつもりでいたけれど、どうやらそれも違ったんだ、って。会社の中では努力をしていた方だったと思うんですけど、彼らのそれは次元が違ったので。
それからですね、「自分の価値は何か」と考えるようになったのは。
圧倒的な存在を前にして、別の道を模索するようになった。
そのヒントをくれたのも、さっき言ったサブリーダーの彼でした。プロジェクトが終わった3、4年後に、飲む機会があったんですよ。そこでわかったのが、当時の私がいかに自分個人の生産性でしか物事を考えられてなかったか。逆にチームとしての生産性を考えていた彼に、「自分は5人見るので手一杯だった」「稲垣さんは10人も見ていたのに、よくあれだけの生産性が出せましたね」と言われて。
そこでようやく気づいたんですけど、私は自分でも意識しないままに、どう振る舞えばチームに貢献できるかを考えて、チーム全体の生産性を引き上げていたようなんです。この出来事をきっかけに、「自分の価値は個人としてではなく、チームとしての生産性を引き出すところにあるのかもしれない」「ここが強みになるんじゃないか」と思い始めました。
話としてはとても納得ですが、「技術を極める」と決めた道を諦めることに、なんらかのネガティブな感情はなかったんですか?
いやー、めちゃくちゃありました。すごい人たちを見て「自分はあそこまではいけない」と思ったのは事実なんですけど、まだ自分の中では「やれるんじゃないか」という未練もあって。一方で、「どうやらリーダーには向いているらしいぞ」とも思っていたので、そのあいだで葛藤する時期がしばらく続いた感じです。
ただ、さっきも言ったように、自分では技術に関してはできる方だと思ってたんですけど、周りの認識はどうやら違ったようで。開発リーダーだったあるとき、技術に口を出したら、全員から総スカンを食らったんですよ。「技術のことはサブリーダーに任せてくれればいいから」「稲垣さんはもっと上の方をどうにかしてよ」という意味のことを言われて。
そこで、「他にできる人がいないなら自分がやるけど、自分より得意な人がいるなら、その仕事はその人に任せればいい。全体を見て何が一番足りないのかを考えて、自分はそこをやる方が、組織としての成果につながるんだ」と思うようになりました。そう考えてからは、自分は開発リーダーに向いていると思えるようになったし、苦でもなくなりましたね。


イチエンジニアに戻る、はずだった
その後、最初の転職先にニフティを選んだのは、どういう理由でしたか。
それまでやってきたのはSIだったので、「自分が作ったサービス」と言えないことに、ずっと引っかかってたんです。お客さまに「もっとこうした方がいいものができますよ」と提言しても、「予算の都合で直せない」とだけ言われて、結局、使われないとわかっているものを作ることになる。そういう体験をたくさんしたので、「このままSIで働き続けてていいんだろうか」というモヤモヤを抱えていました。
それでも、若いうちはいろいろなプロジェクトに関われることが楽しかったんで、よかったんですけど。30歳を超えて、「自社に戻って、スーツを着てお金の管理をする側に回れ」と声がかかったことが、転職を決める引き金になりました。先輩を見ても、やっぱりそれがキャリアとしての既定路線で。でも、「そっちに回るくらいなら、自分は製品開発の方が向いてるんじゃないか」と思って。
なるほど。
ニフティを選んだのは、自社サービスがやれることに加えて、大手グループの後ろ盾があって安定していたからです。ベンチャーか大企業かで迷って、その中間を選んだわけです。もともと大きな会社にいたので、いきなりベンチャーに飛び込むのは怖くて。今考えると、この選び方自体が中途半端だったんですけど。
それは自然ですよね。
ニフティには、新規プロジェクトの開発リーダーとして入りました。プロジェクトを企画した責任者と一緒にプリセールスに回って、ヒアリングしたことをもとに開発を進める、っていう役割です。前職の経験が生きる仕事でしたし、一応、希望通り「自分のサービス」と言える状態になった。
ただ、ニフティは結局、1年半という短い期間で辞めることになりました。


どうしてですか?
自分でいろいろ抱え込みすぎて、いっぱいいっぱいになってしまったからです。
自社サービスの開発リーダーに加えて、途中からは受託系の別のサービスのプロマネも兼務するようになって。開発をやりたくて入ったんですが、頼まれると断らない性分なので引き受けていったら、気づけば半分がプロマネの仕事になっていた。開発リーダーの方もプリセールスからやっていたので地方出張が多いし、開発はオフショアなので、ことあるごとに福岡まで行く必要もあった。本当にいろいろやりすぎて、「自分は何をしてるんだろう」っていう気持ちになっちゃって。
完全に消耗してしまって、このときは次を決めないで会社を辞めたんですよ。
だからその後、半年くらいは無職です。「正直、ITとかもういいかな」と思ってましたから。好きなことやろう、酪農の仕事でもないかなと思って、北海道を旅したりもして。
でも、その時点で35歳だったので、現実的には、ゼロから何かを始めるのはなかなかきつい。というわけで、やっぱりITに戻ろうと思って入ったのが、ベンチャー企業のクルーズでした。
到底敵わないと思うようなすごい人たちに出会って、一度はプレーヤーではなくリーダーとして生きようと思った経緯をお話ししましたけど、このタイミングで考えていたのは、「もう一度イチエンジニアとしてやろう」ということでした。EMとか開発リーダーとかには、まったく興味がなかったです。
2社目を決めるときに、大企業とベンチャーのいいとこどりを狙った結果、中途半端になって失敗したという気持ちがあったので、今回は技術力の高いベンチャーに振り切ろうと思って探していきました。
ここでまた戻るんですね。その中でクルーズだったのはなぜですか?
このころ、世の中ではガラケーゲームの開発が盛り上がっていたので、やってみたいと思って。いくつかゲームの開発をしているベンチャーを受けた中で選んだのがクルーズでした。でも、いざ入社したら「ごめん、ブログサービスの方をやってくれ」と言われて。ただ、ゲームがやりたかったのは「その方が食いっぱぐれないかな」くらいの動機だったので、イチエンジニアとして働けるならなんでもいいかと思って、引き受けることにしました。
で、どうでした?
クルーズは当時、読者モデル向けのブログサービスを展開していて、PVもかなりあったんです。こんなにトラフィックの多いサービスを、アーキテクチャの部分から手掛けられる機会はなかなかないので、技術的には楽しかったですね。実質2、3人で作るような感じだったので、自分たちで作ってるっていう感覚があった。リリースするとお客さまからの反応がすごかったり、目に見えてPVが上がったりしたので、わかりやすかったですし。「エンジニアに戻ったんだな」「自社サービスのエンジニアのど真ん中に来たな」っていう感じがすごくありました。
でも、しばらくすると、上司に「マネージャーをやってくれないか」と打診されて。
あー。
正直、「またマネージャーか」と思ったんですけど、当時のマネージャーは新卒でクルーズに入った20代後半の人で、見るからに大変そうにしていたし、まあ仕方ないか、と思って。自分でも引き続き手を動かしつつ、10人くらいのメンバーを見ることになりました。その後、「開発だけではなく企画系の人のマネジメントもしてくれ」と言われて、ブログサービスのプロダクト責任者みたいな立場になりました。


バックオフィスも、突き詰めれば「新しい言語」の一つ
当たり前かもしれないですが、いろいろな領域を行ったり来たりしているのは、必ずしもご自身の意思ばかりではないんですね。
むしろ、人から言われて引き受けているものばかりですよ。転職を除くと。自分から「やりたい」とは全然言ってない。この後もずっとそうです。
クルーズは、ブログサービスとは別にECのサービスを新たに立ち上げるんですが、これがなかなかうまくいかずに、テコ入れが必要な状況になって。そちらの事業担当者から「手伝ってくれないか」と言われて、好調だったブログサービスを離れてEC側の開発リーダーになり、その後は企画系のリーダーも兼務するようになりました。
さらに、ECが順調に伸びて分社化の話が持ち上がると、今度は「新しい会社の役員をやってくれないか」と言われました。でも、このときは引き受けるかどうかでかなり迷ったんですよ。なんでかというと、そのころ私は、会社を辞めることを考えていたから。


どうしてですか?
長くやっていることで、みんなが私の言うことを聞いてくれすぎるようになってたんですよね。私としては毎回、「本当にこれでいいんだろうか」という疑念も持ちながら意思決定しているわけですけど、そういう自分に対して意見してくれる人がいなくなっていた。
この状況は、事業を伸ばす意味でも良くないし、自分個人としても、刺激がなくて、成長が鈍化する要因になっているかもしれない。だから、潔く身を引くことを考え始めていました。これは毎回プロジェクトが変わるSIにはなかった悩みで、「自社サービスだとこういうことが起こるのか」というのを初めて知りました。
最終的に引き受けたのは、役員とか取締役は、普通に転職したのではなかなか経験できないことだと思ったからです。次の選択をするのは、数年やって成果を出してからでいい。せっかくもらった切符を、わざわざ破棄する必要はないよな、と。
役員になったことで、状況はいろいろと変わりましたか。
劇的に変わりましたね。というのも、当初は開発を管掌するように言われていたのが、直前になって、バックオフィスも見ることになって。
エンジニアの採用を通して、人事に関することをそれなりにやってきてはいましたけど、実際にはバックオフィスなんて、右も左もわからない領域です。データセンターの移転は経験してても、オフィス移転なんてどう考えればいいのかまったくわからない。人事、労務、法務、経理の全部を見ないといけないし、それでいて開発も管掌する。見なければならない領域が、一気に広がった感じでした。
相当に大変そうですね。
もちろん、すんなりいったとは言えないですけど、ただ、基本はこれまでやってきたことと一緒だな、と思ってやってました。
そうですか。
私は物事を抽象化したり、それをまた具体化したりして考えるんですけど、これまでもエンジニアとかデザイナーとか、専門性が極めて高い人たちを見てきたので。自分よりも専門性の高い人たちをリードしていかないといけない立場が多かったんです。その中で、自分がどう振る舞うとチームとして一番成果が出せるか、というところにフォーカスしてやってきていました。
自分の役割は専門性を発揮することではなく、専門性を担う人たちが最高のパフォーマンスを発揮できるよう、チームに足りないところを補う。その点で言えば、バックオフィス業務を専門とする人が相手であっても変わらない、っていうことですか?
そうです。とはいえ、まったく専門性がないのでは、彼らとの会話もままならない。そこは学習する必要があります。
そんなときは、カジュアル面談の場で、とにかく話を聞かせてもらうようにしています。ちょうど経理や法務の人をたくさん採用しなくてはならないタイミングでもあったので、一人ひとりとお会いして。聞き役ばかりで申し訳なかったんですが、バックオフィスの仕事がどういうもので、どんなモチベーションで働いているのか、マネジメントする上でどの程度の知識が必要なのか。そういったことを、みなさんから教わっていきました。


その方法、いいですね。誰でもとれる方法ではないですけど。
で、やっていく中では、さらなる共通点も見つけました。エンジニアもバックオフィスも、すごく頑張っているのに、それを外にアピールするところが弱いんだなって。
エンジニアをマネジメントしているときには、頑張っているわりに説明がうまくいかなくて、損をすることが多いなと感じていました。「言ったところでどうせ伝わらないし」と思っている節さえあった。そこを翻訳してあげるだけでも、私の価値が出るところがありました。
これはバックオフィスの人たちにも共通している部分で。それで、その翻訳をやろうと思ったんです。経理の人たちが何に困っていて、彼らの仕事は何にどうつながっているのか。彼らから聞いて、それを外に通じる言葉に変換して伝えていく。
そうやって抽象化して考えると、バックオフィスという領域も、新しい言語を覚えるのとそんなに変わらないな、と思ってやっていました。
明確に失敗だった。だから気づきがあった
でも、もともとクルーズに入ったときは「イチエンジニアに戻りたい」と考えていたはずですよね。だいぶ遠くまで来た印象ですけど、このころはどんなことを考えていたんですか?
特別、何も考えてなかったんじゃないかな。キャリアを通じてそうなんですよ。目の前にある楽しいことをひたすらやってきた結果、今がある、ということがほとんどで。「どうなりたい」というビジョンから、バックキャストとかゴールオリエンテッドで考えることはあんまりないんです。「そっちの方が面白そう」「そっちの方が会社に貢献できそう」ということの方が大きくて。
そうなんですね。
「断らない方がいい」という考えは、SI時代から本能的に持っていたものだという気がします。お客さまに言われたことはもちろんですけど、初めてやるプロジェクトなのに断るのは違うよな、と思ってました。まずはやってみる。中途半端にやるとつまらないけど、本気でやるとわりとなんでも面白い、ということが経験からわかっていたので。新しいテーマを与えられたら本気でやる。そこで線引きはしない。なんで、このときも、バックオフィスも含めて楽しんでやっていました。
のちに、自分にとっては「製品を作る」ことに関わるのが、モチベーションを保つ上ですごく重要で、その軸を外すとなかなか難しい、ということに気づくんですけど。このときはまだそれより前で。ただ、幸いなことに、バックオフィスだけでなく開発を見る立場にもあったので。開発だけを見る毎日に少し飽き始めていたタイミングで、バックオフィスという新たなチャレンジの機会をもらった。それでいて、開発も手放すことなくやり続けられたのがよかったんだと思います。


しかしこのあとクルーズを辞めてAWSへと転職します。
役員として数年やって、事業にもひと区切りがついたタイミングで、自分も次に行こうと思ったんですが、急には辞められないじゃないですか。ということで、まず役員を退任して、その後、会社も辞めることにしました。
転職先はいろいろ考えたんですが、基準として持っていたのは、まずBtoBの事業をやっている会社であること。というのも、クルーズでやってきたのはBtoCで、たくさんのお客さまがうちのサービスを通して服を買ってくれていたけれど、なぜその服を買ってくれたのか、といったことは、データでわかる以上にはわからなかったので。直接お客さまとやりとりできるBtoBの方が、その点では手触り感があると思いました。
もう一つの基準は、これまで私が経験してきていない製品フェーズにいる会社であること。ファッションECにはZOZOという強烈なトップがいて、クルーズは追いかける立場でした。なので、今度はなんらかの領域でトップを進んでいる会社がいいと思って、いくつかの会社とカジュアル面談をして。
そんなときに、たまたま来たのがAWSからのスカウトでした。
あちらからのスカウトだったんですね。
ここまで触れてきませんでしたが、自分は昔からGoogleという会社に憧れを持っていて。いつの日かそこで働きたいと夢を抱いていたときもありました。さすがに技術力的に無理だろうと考えて別の道に進んだわけですけど、そこに、Googleではないけれど、天下のAmazonからスカウトが来た。開発ではなく、技術サポートのマネージャーとしてのオファーでしたが、まあそれでもいいや、と思って面接を受けました。
ところが、一次面接はボロボロでした。ほとんど準備もせずに臨んだら、過去に行った意思決定の理由を徹底的に掘り下げてくるAmazonの面接に完全にやられて。「これはダメだな」と思ったんですけど、運良く通過することができた。それで、続く最終面接は入念に準備して、なんとか内定をもらうことができました。
他にも4社くらいから内定をもらっていたので、結構悩みました。ただ、最終的な決め手は、Googleに引けを取らないネームバリューと、「あれほど大変な面接を通ったんだし」というところ。技術サポートとしての採用という点には不安もありましたけど、自分と同じ開発出身でその仕事に就いている人から話を聞いて、いけるだろうと判断して。
入ってみてどうでしたか?
嫌な予感の方が的中しましたね。いや、同僚のマネージャーはみんな優秀だし、Amazonのメカニズムを裏側からいろいろと知れて、すごく学びは多かったんですけど。モチベーションが続かなかったです。自分は、根底に「ものを作る」というところがないとモチベーションを保てないんだってことに、ここで初めて気づかされました。新しいチャレンジ自体は好きだし、まったく抵抗もないんですけど、「ものを作る」という軸がブレると、どうやらダメなんだなって。
仕事とは別に、プライベートで何かを作ることで、その軸を満たそうとは思わなかったんですか?
ならなかったですね。私はサボりがちなので、個人で作る方のモチベーションがないんですよ。そこはずっと一貫してます。


そういう言い方をしなくていいのかもしれないですが、じゃあ、この選択は稲垣さんにとって……。
明確に失敗でしたね。でも、失敗だったからこそ、強烈な気づきがありました。
それで再転職したのが現在のラクスですか。
実は、クルーズを辞めたときに内定をもらっていた企業の中に、ラクスもあったんですよ。ラクスはBtoBサービスをやっている会社ですし、「楽楽精算」は経費精算の分野で導入社数トップクラスのサービス。私が求めていた二つの条件を満たしていました。前回はネームバリューに引っ張られてAWSを選びましたが、今度は最初に決めた条件に立ち返って選ぼうと思って。それで改めて受けさせてもらったのがラクスでした。
昔は「こういう人になりたい」「この人と働きたい」といったことを意識していたところもあったんですけど、このタイミングでは、そこはあんまり気にしてなかったですね。会社の内部がどうであれ、必要なら自分で変えていけばいいと思っていたので。それよりは、私にはどうしようもない外部環境の方、「変えられない部分」を見て、ラクスに決めた感じです。
螺旋型キャリアの生存戦略
転職の場面を除けば主体的な選択はそこまでなくて、環境からの要請の方が大きかったというのは、実は『LIFE DRAFT』のインタビューで度々耳にしてきたお話でした。それでいて他の人とは違う、その人らしいキャリアが形成されていくというのが面白いですよね。
そうですね。振り返ってみると、自分が描く理想は、その時々で変わってきたように思います。最初は、個としてなんとか勝ちたいという思いがすごく強かった。でも、自分よりすごい人たちと出会ったことで、自分が勝負するのはそこじゃないし、技術を極めたいわけじゃないんだ、となっていった。自分が楽しいと感じるのは、技術そのものというより「ものを作る」こと。そして、それがお客さまのもとに届くのが楽しいんだな、と。となると、一人でやるより複数人でやった方が良さそうだ、成果を出すには、自分にない力を持った人たちと一緒にやるしかない、というふうになっていきました。
「成果」の概念とか、「いいものを作る」という言葉が指す意味も、キャリアの前半と後半とでかなり変わった気がしますね。
SIのころは、納期と人数を渡されたら、不具合のないものを作るのが誰よりも得意だ、ということをアイデンティティにしていました。それが、私にとっての「いいものを作る」だった。でも、自社サービスをやるようになって、お客さまに価値を届けられるような製品を作ろう、事業に貢献できる製品を作ろう、という意識に変わっていきました。不具合なく作るだけではダメで、お客さまに届いて、収益を生み出さないことには事業として成立しない。そうすると、やっぱりエンジニア以外の人も含めてリードしなくてはならなくなる。


きのこカンファレンスのプレゼンテーションでは、ご自身のキャリアを「螺旋型キャリアの生存戦略」というテーマで振り返っていました。これはどういうことなのか、改めて伺ってもいいですか?
専門性の高い職業の人のキャリアって、どこかのタイミングで、専門性かマネジメントか、みたいな二者択一を迫られますよね。どちらかを選んだら、もう片方には戻ってこられない片道切符なんじゃないか。私自身、そういうものだと思っていたし、そのことがエンジニアのキャリアを考える上では大きいと思っていました。
でも、改めて自分のキャリアを振り返ってみると、その二つの道を行ったり来たりしている。なんなら役員までやったあとに、また現場に戻ってもいる。そうか、別に戻れるんだな、と思いました。
ただ、そうやって行き来しているうちに、視座が変わって、それまでは見えなかったものが見えてくる部分もある。その意味で、キャリアは決して片道切符の二者択一ではなくて、螺旋型に進んでいくものなんじゃないかと、今は思ってます。
その上で、大事なのは、螺旋の真ん中に軸があることだと思っていて。私の場合、それはエンジニアとしてのマインドなんですよね。自分は今もエンジニアだと思っている。エンジニアのまま、プロダクト組織のマネージャーをやっている、みたいな感じです。いろいろと行ったり来たりしているように見えて、私の中では「ものを作る」という、螺旋の真ん中の軸はまったく変わっていません。


ここまでお話を伺ってきた今なら、稲垣さんのキャリアがそのような螺旋型で進んできたというのはよく理解できますし、軸が大事というのもよくわかる。わからないのは、その軸はいつ、どのようにして見つければいいのか、ということです。「私はこれしかやりません」と決めてしまっては螺旋型にはならないわけで。何が主体的にとり得る「戦略」なんでしょうか?
私自身について言えば、キャリアの最初の方は、確かにあんまり軸がなかった。40代後半になって、AWS時代のような失敗もして、ようやく「振り返ってみると、こういう軸があったのかも」と気づいた感じです。もともとなんとなくはあったのかもしれないけど、経験していくうちにメタ認知できるようになっていった。
振り返るのは、やっぱり転職や退職のような大きな意思決定をするときが多い?
そうですね。あとは最近、採用目的でイベントに出るようになって、自分のことを言語化しないといけない機会が増えたので。人に伝えるには、解像度高く言語化しないといけない。自分のためだけだと結構難しいし、ぶっちゃけサボれるんですけど、採用のため、伝える相手のためというモチベーションがあると、つらくてもできるんですよね。相手がいるとサボれないので。
螺旋型キャリアっていう整理も、キャリアについて話さないといけなくなって、改めて振り返ったら「ああ、そうなんだ」と気づいたっていう話で。外から見るとしっちゃかめっちゃかで、「なんで役員までやった人がまた現場に戻ってるんだ」みたいに見えると思うのですけど。でも、振り返って分析し、言語化してみたら、こういう軸があったんだ、とわかった感じ。
そういう意味では、あんまり「戦略」じゃないのかもしれないです。でも、ちょっとでも「戦略」と言えることがあるとすれば、それは何事も断らずに、まずは全力でやってみる、ということに尽きるんじゃないでしょうか。失敗も含めて、いろいろと経験することで見えてくるものだと思うので。いただいたチャンスを、次の機会にどう活かせるかと考える。その連続性の中で見えてくるのが、自分なりの軸なんだと思います。


LIFE DRAFTは、人間を取材する。
既にあるITエンジニア像をなぞるのではなく、その人がどう生きてきたのかを丁寧に聞くことで、エンジニアという生き方を描きたい。有名CTOや凄腕ハッカーばかりを取り上げたりはしない。キャリアも属性もバラバラのエンジニアに、じっくりと話を聞いてみたい。
インタビューで聞いているのは、技術や仕事のことだけじゃない。家族のこと、身体のこと、迷い、偶然、諦め、死生観、言葉にならなかった心の揺動。ほんとうは、そういうものの上にエンジニアという生き方があるはずだ。人はみな、それぞれに固有の生を生きている。その抽象化できない生き様を、LIFE DRAFTは一つ一つ映していく。
かつてないほどにキャリアが多様化するエンジニアの今日を、私たちは描いていく。数えきれない生き方がある。
