「エンジニアになる」はゴールではない。Sansan CTO・藤倉成太が語る技術以上に大切なこと

エンジニアになれば、パソコン一台でどこでも働ける。出社時間はゼロ。
エンジニアになれば、給料が上がる。
エンジニアになれば、フリーランスになれる。

このようにエンジニア転職市場では、キャリアに関する甘い言葉が飛び交います。もしこうした言葉に心が揺れ、エンジニアを目指そうとするなら一度、冷静に考えてみてください。あなたは「エンジニアになること」そのものを、キャリアの目的にしていませんか？

Sansan CTOの藤倉成太さんは、「あくまで技術は手段に過ぎない。エンジニアはビジネスの目的意識を忘れないことが重要」と語ります。日本のSIerとシリコンバレー、両方での業務経験を持つ藤倉さん。現在はクラウド名刺管理サービスで有名なSansanのCTOを務めます。

日本のIT業界とシリコンバレー。両方を知る藤倉さんにエンジニアの仕事の本質と、未経験からエンジニアを目指す人へのアドバイスを聞きました。

■プロフィール
藤倉成太  Sansan株式会社 執行役員 / CTO（Chief Technology Officer）
株式会社オージス総研でシリコンバレーに赴任し、現地ベンチャー企業との共同開発事業に携わる。帰国後は開発ツールなどの技術開発に従事する傍ら、金沢工業大学大学院工学研究科知的創造システム専攻を修了。
2009年にSansan株式会社へ入社。現在はCTOとして、全社の技術戦略を指揮する。

2019年5月20日追記
Sansanの東証マザーズ上場が5月16日に承認されました。上場予定日は、2019年6月19日とされています。

どうやったら世界有数のエンジニアになれるのか考え「シリコンバレーで働くことにした」

—– 藤倉さんはSIerに勤め、シリコンバレーでも勤務。その後、Sansanに転職し、CTOに就任しています。CTOに就任するまで、具体的にどんなキャリアを歩んできたのか教えてください。

もともとものづくりが好きで、小学生の頃からプログラミングも好きだったんです。学生の頃は、ロボットを作りたかった。若者にはありがちな夢です（笑）。当時は機械系のエンジニアに会って、話を聞くことも多かったです。

ただ、現実にはハードウェアについて学べば学ぶほど「何かが違うな」という思いが芽生えてきて。ロボット自体は好きでしたが、仕事にするかどうかは別問題だったのだと思います。

そうして、大学4年で進路選択をやり直すことにしました。ロボットではなく、ソフトウェアの道に進むことに決めたんです。ソフトウェアもものづくりですから。

仕事とは一生をかけてやるものです。「一生をかけるなら、エンジニアとして世界でも一流と認められる人材になろう」。このように目標を定め、新卒の会社選びをしました。1998年のことです。

現地エンジニアの「日本にもソフトウェアエンジニアっているんだね」という言葉が忘れられない

どうしたら世界有数のエンジニアになれるかを考え、思いついたのが「シリコンバレーで働くこと」です。

今でこそシリコンバレーは有名ですが、1998年時点はまだ黎明期。Yahoo!とアップルは当時から有名でしたが、Googleですら創業間もない時期でした。ですが「シリコンバレーで働いているのは、世界一の集団に違いない」という確信はありました。1998年の時点でも、それくらいシリコンバレーは輝かしい場所に見えたんですよ。

ですが、当時の僕は本当にエンジニアとして大したことがなくて。プログラミング自体、BASICで遊んでいたり、ハードウェア制御や科学計算のためのプログラムがちょっと書ける程度のスキルでした。なので、いきなりシリコンバレーに行く勇気はなくて。だから「シリコンバレーに行けるキャリアパスがある日本企業」を選んで、就職試験を受けました。

結果、大阪に本社があるSIerに就職することを決めました。メインのSI事業に加えて、アメリカのプロダクトを日本向けにローカライズして展開する事業を行なっていました。その会社はシリコンバレーに駐在事務所があり、入社2~3年目の若手社員が現地に渡っていたんです。

入社後、ひたすら上層部の人に「シリコンバレーに行きたい」とアピールし続けたら、本当に現地に行けることになって。「いきのいい若手がいるぞ」と伝えてくれたのだと思います。

シリコンバレーの働き方は、やはり日本とは大きく違いました。シリコンバレーで、自分に起きた一番大きな変化は「日本発のプロダクトをやりたい」という思いが強くなったことですね。SIerを退職し、2009年にSansanに入社を決めた理由も「自分の手で自分のプロダクトを作りたい」という気持ちが強まったことが大きいです。

—– 「日本のプロダクトで勝負をしたい」と思うようになった動機を、もう少し詳しく聞かせてください。

アメリカにいた時の「外国人感覚」は大きかったかもしれません。アメリカにいると、日本のハードウェアに触れる機会はたくさんあります。ですが、日本のソフトウェアって本当に目にすることすらないんです。

シリコンバレーで現地の人と会話をし、日本からきたと伝えると「へぇ！日本にもソフトウェアエンジニアっているんだね！」と言われるんですよ。僕は決して愛国心が強いタイプではないですが、さすがに気持ちの良いものではありません。「畜生、なめんな！」と思ったことを覚えてます。

シリコンバレーでの日々はそんな調子だったので、現地の文化に自分を無理やり合わせているような感覚が抜けませんでした。だからこそ「日本のプロダクトで勝負したい」という思いが強くなったのだと思います。

日本のソフトウェアがシリコンバレーで全く受け入れられない理由

—– 日本のソフトウェアが、シリコンバレーで全くと言っていいほど使われない理由はなんだと思いますか？

正直「エンジニアの優秀さ」だけで言えば、日本もシリコンバレーも実はそんなに違わないです。「ものすごくハイレベルなエンジニア」なんて、実はシリコンバレーにもそんなにたくさんいないんです。

特に綺麗なコードを書くことに関しては、日本人の方が長けていると思います。日本のIT企業には「綺麗なコードを書く」ことが文化として根付いていますしね。シリコンバレーだと、そこまでコードの丁寧さには重きを置かない人も多くいます。

では、シリコンバレーでは何に重きを置くのか。答えは「世界を変えるようなサービスを作ること」です。日本だと「技術」を出発点として、「技術を使って、何をやろう？」とビジネスを考えがちですよね。

一方でアメリカでは「世界を変えるようなサービスを作るには、何が必要か」と考えます。技術は問題解決手段の1つなんです。ビジネスの考え方の出発点がそもそも違います。最終的なプロダクトの品質や、市場での受け入れられ方の違いにもこうした発想の違いは現れているのではないでしょうか。

—– 日本のIT業界では、SIerに代表される「下請け構造」が問題視されがちです。SIerとシリコンバレー、両方を経験した藤倉さんは「日本のSIer」についてどうお考えですか？

SIerの存在そのものが良くないとは全く思わないです。システムインテグレーション自体は日本だけでなく、アメリカにもありますしね。

ただ「文化の違い」は確かにあります。

シリコンバレーにいた時、技術カンファレンスでニューヨークタイムズのチーフアーキテクトの方が登壇されているセッションを聴講したことがあります。

今でこそ、日本でも新聞社のIT活用は大きく進みました。でも当時は、日本ではそんな事例は聞いたことがありませんでした。勉強会に行った時、僕はそもそも「ニューヨークタイムズに優秀なエンジニアがいること」自体に驚いたんですよ（笑）。一見、ITとあまり関係がなさそうな企業でも、アメリカでは「テクノロジーをどう自社のビジネスに活かせるか」を考え抜くのが当たり前なんです。

だから、アメリカでは「システムを作ろう」となったら発注元のユーザー企業が自社で設計を行うのが当たり前です。SIerが担当するのは、あくまで実際に手を動かして開発する部分だけ。SIerはフリーランスエンジニアを一気に集め、一気に開発。終わったらプロジェクトは即解散です。なのでシステムインテグレーションはアメリカにもあるとは言いましたが、日本より企業の数が少ないのもまた事実ですね。

—– 日本のSIerとは、大きく業態が違いますね。

日本のSIerは、設計部分からワンストップですよね。ユーザー企業は設計から開発までを全て委託するので、自社では設計について深く考えないケースも多いのではないかと思います。

ワンストップサービスは、確かに便利です。ですが、そのためにテクノロジーに関する知見が社内に蓄積しないのはもったいないと感じます。

地味な名刺管理サービスが「世界を変える」と確信。創業1年のSansanにあえて飛び込んだ

—– 藤倉さんは2009年にSansanに転職します。転職を決めた理由はなんですか？

僕が転職した時点で、Sansanは創業1年程度の企業でした。転職前に「名刺管理サービス」の説明を受けた時も「地味だな……」と感じたのが本音です。一聴しただけでは、将来性を感じなかったですね。ですが、代表の寺田と会って話をしてみると、「出会いから人のつながり方を変えていきたい」と言うんです。

そもそも名刺管理って、地味なようですが世界中の人が困っている課題です。しかも、多くの人が「自分が困っていることにすら気づいてない」もの。

そして、足元の名刺管理という課題を極めると、人と人との出会いの記録が蓄積されます。この出会いの記録、つながりの情報が本当に世界中で活用できるようになったら、世の中の出会いのあり方を変えることができる。

足元の課題解決と、「出会いのあり方を変える」という壮大なビジョンがしっかりと紐付いていることに納得したので、転職を決めました。

—– 現在、藤倉さんはCTOです。マネジメントと実際のコーディング、業務の比率はどれくらいですか？

去年の6月に就任して、今はマネジメントが10ですね。

CTOの働き方は、企業の規模やフェーズによって大きく変わると思います。創業間もないベンチャーなど、小さな企業であればCTO自身がバリバリとコードを書くのはよくあることです。

一方で規模が拡大してくると、CTOの業務はマネジメントが主になるのが一般的かもしれません。仮に同じような規模でコードを書いているCTOがいるとすると、その人の圧倒的な武器がコードを書くことなんだと思います。

—– Sansanで使用しているプログラミング言語とフレームワークを教えてください。

法人向けクラウド名刺管理「Sansan」は、WebアプリケーションがC#.NET。個人向け名刺アプリ「Eight」はサーバーサイドがRuby on Rails。インフラはAWSをメインで使っていますが、AzureやCGPも適材適所で使い分けています。

モバイルアプリはどちらもSwiftやKotlinを使ってネイティブで開発していますね。

これらとは別に社内では機能改善に向け、機械学習も行っています。機械学習向けの言語としては、C#やPythonを使っています。

—– Sansanでは2012年に「Eight」でRuby on Railsを初めて本格導入したそうですね。藤倉さんが考えるRuby on Railsの魅力とは何でしょうか。

リファレンスの質と量では、Webアプリケーション開発向けのフレームワークとしてやはりRuby on Railsが圧倒的です。Ruby自体の型付けが弱いため、アプリケーションの規模が大きくなるほどバグ対応に難を抱えやすいという課題はあります。でも思ったものをスピーディーに実装できるのは、やはりRuby on Railsです。

デメリットを正確に把握しておく必要はありますが、スピード感が求められる開発では非常に魅力的なフレームワークであることは間違いないですね。Rubyの開発者のまつもとゆきひろさんが日本人ということもあり、情報の手に入りやすさという点でも日本人であれば学習する価値が特に高いと思います。

ビジネスの目的意識を忘れない。阿吽の呼吸も必要。Sansan CTOが語る信頼できるエンジニアの条件

—– 藤倉さんが信頼するエンジニアとは、どういうエンジニアですか？

まず前提として、僕はSansanのエンジニア全員を僕の全人格をもって信頼しています。同じ船に乗ってる以上、何か問題が起きたらその責任はきっちりと自分が負うという覚悟を持っています。

一方で、エンジニアとはいえビジネスマンとして「事業に対してきちんと成果を残せるかどうか」は大事ですね。エンジニアの場合、成果を出すためにもっとも必要な要素は圧倒的な技術の基盤です。ちゃんとした技術がないと、成果なんてそもそも出せないです。そこは絶対に忘れてはいけない。

とはいえ、全員が超ギークである必要はないとも思っていて。技術が好きだとか、ものづくりにきちんと向き合う姿勢があるかどうかが、エンジニアには求められると思います。

Sansan CTOが考えるリモートワークのデメリット

—–未経験からエンジニアを目指す方の多くは、エンジニアになれば「場所を問わずに働ける」「パソコン一台で仕事ができる」ことに魅力を感じる傾向があります。ですが、実際にはリモートワークはメリット・デメリットがそれぞれあります。

Sansanでも在宅勤務制度が取り入れられていますが、藤倉さんは「リモートワーク」についてどう考えていますか？

企業でチーム開発を行うケースでは、リモートワークを積極的に推す立場ではありません。

チーム開発は何より「空気感」「阿吽の呼吸」が大事です。緊急対応があれば、スクランブル体制で対応しなくてはいけないこともあります。そんな時に、Slackのテキストでやり取りするのは現実的ではないですよね。

—– 確かにそうですね……。

リモートワークでは、チームビルディングの難易度も上がります。全社員がリモートワークという特殊な組織を除けば、どんな会社でも基本的に「チームの本体」が一箇所に物理的に存在することになります。すると、リモートの社員は本体に対して遠くから参加する形になります。

結果として、当人が意図しなくとも、当然リモートのメンバーには疎外感が出てきてしまいます。本体でどんなやり取りが行われているのか見えづらいですから。「みんなが何やってるのかがわからない」となって、投げ出したくなる瞬間も出てくるはずです。

ですが、その状況に文句を言ったらおしまいです。厳しいようですが、リモートで働く道を選んだのはリモートの社員本人ですから。

—– リモートワークは現代的な働き方として取り上げられる機会が多いワークスタイルです。ですが、実際には難しさも多く存在するのですね。

リモートワークで成果を上げるには、業務に対する「圧倒的な自分ごと」感覚が必要です。実際にSansanでリモートワークをしているメンバーは、自分ごととして業務に向き合う力が強いです。やはり「自分だけが蚊帳の外に置かれている」ような感覚に陥りやすい働き方ではあるので。

だからといって、投げ出してしまったら仲間からの信頼を失うことになります。物理的に離れているなら、せめて心理的な距離を保つ努力が必要でしょう。

—– 藤倉さんは、こうした働き方のメリットはどう考えていますか？

家庭の事情などがあった時に、対応しやすいのは事実ですよね。確かにエンジニアは、パソコンさえあれば働ける職種ではありますから。

チーム開発の場合はオフィスに集まって働いた方が明らかに効率的ですが、やろうと思えば柔軟性の高い働き方も実現できるとは思います。大切なのは、リモートを選ぶ前にデメリットをきちんとすり合わせすることだと思います。

エンジニアになること自体はゴールではない。エンジニアを目指す人へのアドバイス

—– エンジニアとは「35歳定年説」が長く叫ばれてきた仕事でもあります。近年では35歳を大きく超えても活躍するエンジニアも増えました。ですが、一方で技術の変化についていけなくなるエンジニアが少なくないのも事実です。エンジニアとして長く活躍し続けるために、大事なことはなんだと思いますか？

技術が大好きで「自分には技術しかない」と言い切ることですかね。

特にSIerでは、事業の構造上、プログラマーよりもマネジメント人材が重宝されます。SIerは開発プロジェクトを回すことが本業なので、ある程度コードが書ける均質なエンジニアを大量に雇い入れます。尖った優秀なエンジニアはあまり必要ありません。ゆくゆくはプロジェクトマネージャとなって巨大な案件を次々に回すのが、SIerのもっとも理想的で「エキサイティング」な働き方ではないでしょうか。

特に日本のIT業界では、そのような働き方が一般的なキャリアパスとして求められてきました。だから、エンジニアの世界では35歳定年説が長く叫ばれてきたんだと思っています。コードを書くのは35歳くらいまでにして、あとはマネジメントに回って巨大なビジネスに携わってほしいと。

そうした状況は、自社サービスを提供するIT企業の増加で変わりつつあります。Sansanも自社サービスを提供するIT企業です。僕らの場合は、案件の規模以上に「どうやったら世の中に対して価値を提供できるか」を重視します。だから、尖った優秀なエンジニアには、エンジニアとしてのキャリアを作るチャンスがいくらでもあります。

でも優秀なエンジニアで居続けるには、スキルを伸ばし続ける必要があるのも事実です。IT業界は変化が早いですから。

毎日スキルを磨き、技術と真剣に向き合い続けることが大事だと思います。他のことには目もくれないような熱意が必要ですね。

—– 長く活躍するために「プログラミング以外」に大事なスキルがあるとすれば、それは何でしょうか。

僕にとっては、エンジニアも営業もコンサルタントも同じ「職業人」です。抽象性の高いレベルで言うと、事業の方向性を理解し、明確に問題を定義することは共通しています。そして、具体的な問題解決策に取り組む際に、エンジニアは手段としてソースコードを書くわけです。

このように問題解決策が、エンジニアの場合は「システムを作ること」が大きな割合を占めます。このことが、エンジニアと他の職業の主な違いです。つまり、ベースとして大事なのは「問題解決能力」です。

問題を解決するには課題を定義し、構造を理解するスキルが必要です。長く活躍し続けるには、こうした力を磨くことが大事だと思います。

—– 未経験からエンジニアを目指す方に、アドバイスをお願いします。

1つは「目的をちゃんと持つこと」です。エンジニアになることそのものは、手段でしかありません。わかりやすく言えば「世の中のためになることをしたい」というのが目的で、その具体的な手段の1つがエンジニアリングです。

目的と言っても、大層なものである必要はないと思います。日常生活で困っていることがあれば、それをもう少し便利にしたいのでプログラミングを学んでアプリを作る。その程度のことでも十分なので、エンジニアになって何をしたいのか、イメージしてワクワクできると良いと思います。

もう1つは「自分なりの技術の楽しみ方を見つける」ことです。

何事も楽しんだほうが絶対に成長できると思っています。

どんな人だって、初めてコードを書き、画面に「Hello world!」と表示されたときには感動するものです。でも悲しいことに、プログラミングがどんどん分かれば分かるほどワクワク感を失っていく人も多いんですよね。

技術をずっと楽しめる人もいるし、意識的に楽しみ方を見つけたほうがいい人もいます。エンジニアとして成長し続けるためには、自分なりの技術の楽しみ方を見つけて、ワクワクする気持ちを持ち続ける工夫をしてみてください。

↑目次へ戻る