シェア
はてブ
幅広い領域のスキルを身につけることで、エンジニアは解決できる課題の種類が増えます。課題解決がエンジニアの仕事だとするならば、スキルの多様性はエンジニアとしての価値向上に直結するともいえるでしょう。
かつて株式会社ラブグラフ（以下、ラブグラフ）のリードエンジニアを務め、同社を退職後はフリーランスとして活躍する成澤克麻さんは、フルスタックなスキルを持つWebエンジニアです。フロントエンドからサーバーサイド、インフラまで広域なスキルを有し、Webサービス開発の業務全般に対応可能。また、大学院では自然言語処理の研究に従事し、トップカンファレンスに最年少で査読論文を通した経験を持ちます。
成澤さんのフルスタックさは技術方面だけにとどまりません。経営戦略の立案や事業開発、マネジメント、採用、企画、分析、マーケティング、CSなど、いわゆる事業・管理系のスキルも習得。自他ともに認める“事業に強いエンジニア”なのです。
一見すると「天才型でどんなスキルもすぐに習得できる人物」のようにも思える成澤さん。ですが、力をつけられたのは「より高いスキルが求められる環境に飛び込み、試行錯誤した経験があったからこそ」だと彼は語ります。本稿では成澤さんのキャリアを振り返るとともに、効果的な学習を行うために必要なノウハウやマインドを伺いました。
仕組みが整った世界から、何もない荒野の環境へ
──もともと成澤さんは大学院で自然言語処理の研究に携わっていたのだとか。データサイエンティストなどの道もあったと思うのですが、大学院卒業後はDeNAに新卒入社して、ゲームの開発・運用に携わっています。これはなぜですか？
もちろん、大学院での研究を活かしてデータサイエンティストになる選択肢や、研究者を続ける選択肢も考えてはいました。ですが、研究を突き詰めること以上に、優秀な方々が集まる刺激的な環境で働きたいという気持ちが強かったのです。
私は学生時代から、切磋琢磨できる場所に身を置くことが好きでした。余談ですが、中学・高校では音楽に没頭していて、一時期はプロのサックス演奏者を目指していたくらいです。朝も昼も夜も起きている間はずっと、楽器の練習ばかりしていました（笑）。プロになる道は途中で諦めたものの、当時からストイックにスキルを磨くことにやりがいを感じるタイプでした。
──その後、DeNAからラブグラフへ転職されます。これはどのような理由からですか？
徐々に自分の技術的な成長が望めなくなってきたと感じたからです。すでに大きな売り上げが発生していて運用年数も長いソーシャルゲームの、システム根幹部分のアーキテクチャや採用技術を大きく変更するというのは、当時の状況では現実的ではありませんでした。また、そこまで大きくないいちエンジニアができるような改善はすでに先輩方が取り組んでおり、業務の上で新しい経験を得る機会はだんだん少なくなっていました。
──同じ環境で働き続けても、成長が難しい状態になってしまったわけですね。
DeNAという企業自体はとても好きでしたから、社内での配置転換を検討し始めました。それと同時に、キャリアについて考える良い機会だと思い、転職を検討するようにもなりましたね。コンタクトをとったのは2社。大学時代のインターン先だったPreferred Networksと、もともと社長の駒下（純兵）と知り合いだったラブグラフです。このうち、ラブグラフの業務に魅力を感じて入社に至りました。
*…Preferred Networksは機械学習・深層学習（ディープラーニング）などの最先端技術の実用化により、イノベーションの実現を目指すスタートアップ企業。ラブグラフは「撮りたい」カメラマンと「撮られたい」ユーザーを繋ぐ、出張撮影サービス「Lovegraph」を日本全国で展開しているスタートアップ企業。
──Preferred Networksは技術レベルの高い会社として知られています。Preferred Networksと比較して、ラブグラフがより魅力的だと感じたのはどのような点ですか？
Preferred Networksは日本でもトップレベルの技術力を持つ会社ですし、入社すれば間違いなく面白い仕事ができたと思います。ラブグラフを選んだ理由は3つですね。
1つ目はWebサービス開発のスキルを磨くことです。今もそうですが、私は“Web”の世界に強い興味を持っているため、Webサービス開発に関連する一連の業務を、一通り経験できるような環境に身を置きたいと考えていました。その面で、機械学習・深層学習の研究・開発を専門とするPreferred Networksよりも、Webサービスを提供しているラブグラフの方が興味にあっていました。
2つ目は写真です。私はフォトグラファーとしても活動しているため、写真の話を日常的にできる環境は魅力的でした。余談ですが、思い出深いエピソードがあります。入社前の面談時に案内された倉庫に、富士フイルムのハイスペックなカメラが山積みになっていました。富士フイルムと提携しておりカメラを支給されているそうなのですが、あれは感動しましたね。
3つ目はビジョンですね。ラブグラフは「幸せな瞬間を、もっと世界に。」というビジョンを掲げている会社なのですが、代表の駒下が目を輝かせながら幸せな世界観について語っていて、そのビジョンに共感した優秀なメンバーや全国のカメラマンが集まっていて、そして色んなお客様がサービスを好きだと言ってくれていて、そんな世界観が良いなと思って入社しました。
──社員が数千名規模のDeNAと黎明期スタートアップのラブグラフとでは、企業としての仕組みにかなり差があったのでは？
本当にそうですね。転職後、最初に感じたのは“仕組みがない”ということでした。DeNAにいた頃は、全タスクの開発スケジュールがきっちり決められていましたし、開発対象となる機能を決める人やプロジェクト全体を管理する人など、メンバーの役割分担も明確でした。ルールや仕組みがすでに構築されていたわけです。
一方、黎明期のスタートアップだったラブグラフはそれが一切ありません。私が入社した頃に唯一存在していたルールといえば、朝会を毎日開催することくらいでした。
──機能の開発はどのような流れで進んでいくのですか？
よくあるケースとしては、誰かが雑談のなかで「こんな機能があれば便利では？」といったアイデアを出し、その内容をイシューとして書き溜めておきます。エンジニアはイシューのなかから、次は何に着手すべきかを個人で判断。実装とテストを行い、任意のタイミングでリリースするといった流れで、かなり個人の裁量が大きい運用でした。
設備が万全に整った世界から、急に何もない荒野に放り出されたといいますか。ちなみに当時のラブグラフのオフィスはまだメンバーや物品が少なくて、物理的にもがらんとした荒野のような状態でした（笑）。
2016年8月のオフィス引っ越し直後に撮影。
システム障害でサービスが数時間停止。その経験から何を学んだか
──黎明期のスタートアップで働いたことで、どのような学びがありましたか？
「自分がやるしかない」という環境に身を置くことが、自身の成長につながることですね。というのも、ラブグラフでは一時期かなりハードな状況で働かざるを得ない状況でした。
ラブグラフで働き始めてから2年目のときに、創業期から在籍していた優秀なエンジニアが退職し、エンジニアが私1人になってしまいました。開発体制として相当な痛手です。しかも、同時期にビジネスの中核を担っていたCOOも退職したため、事業としても危機的な状況に陥りました。
──核となるメンバーが2人抜けるとは、相当なピンチですね……。
なんとか会社を支えていく以外にありませんから、抜けた2人の穴を私が埋めるしかないと思いました。エンジニアとしてプロダクト開発を行うだけではなく、経営会議に参加して事業計画を立てることまで、なんでもやりましたね。相当に大変な状況でしたが、「最後は自分がなんとかしなければいけない」という気持ちで業務に当たったことは、自分自身の成長につながったように思います。
──その時期に経験したことで、印象に残る出来事はありますか？
システムの開発・運用に関していえば、エンジニアが1人になった直後くらいに、Webサービスが数時間ほどダウンする大きな障害を一度だけ発生させてしまったことがありました。
技術的な詳細をお話しすると、この頃は退職したエンジニアが本番環境をDocker化してAmazon ECSを用いたアーキテクチャにした少し後でした。当時の自分はまだAmazon ECSにそれほど慣れておらず、すぐに原因を特定できなかったのです。もちろんロールバックは試みましたが、ロールバックをしても障害が解消されない状態が継続していました。
──聞いているだけで胃が痛くなります……。
その頃から関わり始めていただいていた副業のエンジニアの方々にもヘルプの要請はしたものの、システムについて一番理解しているのは私であり、自力でなんとかするしかありませんでした。私が根本原因を特定しない限り、Webサービスを再開できない状況に追い込まれました。
まずはAmazon ECSの仕様を把握する必要があると思い、AWSの公式ドキュメントなどをひたすら読み進めました。あのときの集中力は、普段とは比べものにならない程でしたね。その甲斐もあって、かなり切羽詰まった状況でしたが、なんとか復旧に成功しました。
システム復旧後は、2度と同じ障害を起こしてはいけない、もしくは起きたときに迅速に解決しなければならないという思いで、周辺知識の学習に没頭しました。このときの経験を通じて、DockerやAmazon ECS関連の知識が相当に蓄積されましたね。
私は常々、スキルを身につけたいのならば、まずはそのスキルが必要とされる場所に飛び込むことが大事だと思っています。この事例では多くの方々にご迷惑をかけてしまったものの、自分が障害を解決するしかない状況に追い込まれたことが、結果的には自分自身の成長にもつながりました。
──成澤さんは経営戦略の立案など、事業寄りのスキルも習得されています。それも、この時代の経験で身につけたものでしょうか？
まさにそうです。COOが不在のなか、誰かが良い経営戦略を立てなければ、会社が立ち行かなくなる可能性もある。そうなったら働いている仲間や株主のみなさま、そして何よりユーザーの方々を不幸にしてしまう。ならば、自分がその役割を果たすために、意地でもスキルを習得するしかないですよね。
──成澤さんのマインドが伝わってきます。スキル習得を行う際、何かしら学習効率を高めるために工夫されていることはありますか？
インプットとアウトプット、レビューの3つをバランス良く実施することが大事です。これは、自分が写真の技術を教えるときによく話すことでもあるのですが、エンジニアリングや事業運営においても当てはまります。
私が経営戦略に携わり始めた頃、大してインプットもせずアウトプットばかりをしていたため途中で行き詰まりました。しかし、例えばエンジニアが新しい言語に触れるときは、ただ開発を始めるのではなく、まずは公式ドキュメントを一通り読んだり、さらに詳しくなるためには本を読んだりしてインプットもしますよね。それと同じく、ビジネスの場でも、さまざまな書籍から知見を学んだり、株主や顧問の方々からレビューを受けたりすることが大事でした。そしてそうやって、インプットとアウトプット、レビューの3つをひたすらやり続けた結果としてスキルが身に付きました。
──記事の読者であるエンジニアのなかには、エンジニアリングのインプット方法は知っていても、どのような方法で事業運営に関する知識をインプットすべきか分からない人も多いはずです。成澤さんのおすすめの方法はありますか？
これは私がよく用いている方法なのですが、自分が興味を持っている領域に関して、1冊ではなく複数の本を読んでみることをおすすめします。全ての内容をきっちり読み込む必要はなく、最初は斜め読みレベルで構いません。
私の場合は例えば、蔦屋書店などに行きコーヒーを1杯買ってから、今の自分が求めている情報が書かれていそうな本を10冊くらい探してきます。つぎに、それぞれの本の目次を読み込む。10冊くらい目を通すと、どの本でも解説されている内容や、今の段階では学ぶ必要のないことなどが見えてくるため、その領域に関するガイドマップが頭のなかにできるはずです。そのうえで、重要そうなキーワードについてさらに調査を進めていくことが多いですね。
誰かを幸せにするために技術を用いる
──フリーランスエンジニアのなかには、特定の技術だけを極められればいい、というマインドの方もいます。成澤さんがスキルの幅を継続的に広げていきたいと思われるのはなぜでしょうか？
前提として、技術は事業を成長させるための手段だと考えているからです。さまざまな技術の選択肢を持っている方が、成功確率は高くなりますよね。
こう考えるようになったのは、ラブグラフでの経験が大きく影響しています。ラブグラフにいた頃もエンジニアとして研鑽を続けていたものの、自分の能力不足を感じる場面は数多くありました。今思い返しても「当時ああしていれば、より会社を発展させられたかもしれない」「あのスキルを持っていれば、ユーザーや同僚をより幸せにできたかもしれない」と感じることが山ほどあります。そんな経験をくり返さないように、いつでも最高の技術を使えるようにしておき、事業の成長に寄与したいという思いを持ち続けていますね。
──フルスタックなスキルは、会社や誰かの幸せに貢献するためのものなのですね。
私が技術だけではなく事業寄りのスキルを積極的に習得するのも、そのためです。だからこそ、フリーランスになってからもプロダクト開発だけではなく、参画している企業の事業戦略や企画などの立案にも積極的に携わっています。
もしも、自分が開発に専念するだけでユーザーを幸せにできるならばそれで十分かもしれませんが、そうではないケースも多いですから。それに、やはり技術のことを熟知している人が事業にもコミットメントした方が、より良いアウトプットができるように思います。
チャレンジの秘訣は許容できるリスクかどうかを見極めること
──今回のインタビューのなかで成澤さんは「スキルが求められる環境に自ら飛び込んでみることが大事」というメッセージを強く語られていました。とはいえ、読者のなかにはリスクのある挑戦をすることに躊躇される方もいるはずです。そういった方々に伝えたいことはありますか？
挑戦しやすくするための考え方は2つあります。まずは、自分にとってリカバリのきくリスクなのかを考えたうえでチャレンジすることです。私はDeNAという大企業から黎明期のスタートアップに飛び込みましたが、正直なところ転職前は、万が一ラブグラフが倒産したらどうしようという不安な気持ちもありました。
しかし、曲がりなりにもDeNAで2年間働いた実績があるわけですから、その後の転職が一切できなくなるとか人生が終わるなんてことは絶対にない。最悪のケースで2年間を棒に振るくらいでしょう。そのくらいのリスクならば許容できると考えたからこそ、実行に移せた部分はあります。
もうひとつは、いきなり未経験の領域に飛び込むのではなく、自分が現在持っているスキルから“隣の領域”を目指すことです。例えば、これまでサーバーサイドの開発だけに携わっていた人が、いきなりデザイン系に飛び込むのは難しいですよね。そうではなく、サーバーサイドエンジニアであれば、次はフロントエンドの開発に挑戦してみる。そしてフロントエンドの開発をやりつつ、余裕がでたら次は簡単なUIデザインは任せてもらう、そしてだんだんデザインの仕事を引き受けていくという感じでしょうか。
始めてデザインの仕事をするときは、もちろん本職のデザイナーほどデザインはできないけど、普段からUI開発をしていればある程度はできるはず。それに、フロントエンジニアなら「実装しやすいUIデザイン」を考えることはできて、最悪デザインの仕事があまりできなくても一定の価値は出せる。そういった面で、"隣の領域"にいくと仕事を任せてもらえやすく、失敗したときのリスクも低いと思います。
私が新しい環境に飛び込む際にも、要求される業務の半分は現状のスキルでこなせ、もう半分は新たなスキルが必要となる環境を選ぶことを意識しています。自分ができる仕事を終わらせたあとに、残りの時間でもう一方のスキルを磨いていく。徐々に自分ができる仕事の割合が増えれば、新しく身についたスキルを武器にして次の環境にチャレンジしていく。私の場合はそのくり返しですね。
──スキル習得において参考になる考え方ですね。最後に成澤さんが今後の目標にしていることを伺わせてください。
今後も技術だけではなく、事業がわかるエンジニアになっていきたいという気持ちは変わりません。そして、両者は相反するものではなく、両方のスキルを持っているからこそできることがあるはずだと思っています。技術のことを上から下まで理解しているからこそ、立てられる事業戦略もあるはずですから。
今、友人と一緒にやっている会社で構想しているSaaSのプロダクトが良い例です。その会社は営業コンサルティングが主な事業ですが、クライアントが事業運営上で抱えている課題を、最先端の技術を使うことで解決するアイディアを最近思いつきました。
手前味噌にはなりますが、このアイディアはビジネスドメインのことを理解しつつ、技術についても深い知識を持つ人間でなければ思いつかないはずです。自分が広域なスキルを習得してきた成果を発揮できそうだと思っていますし、そのプロダクトを実現できることに自分自身とてもワクワクしています。
取材・執筆：中薗昴 写真撮影：村上怜
