ITエンジニアのキャリアに本気で向き合うメディア
ITエンジニアのキャリアに本気で向き合うメディア
目次
■エンジニアの軌跡
2017.07.11 2024.03.28 約5分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。vol.16は、アメリカのスタートアップで働く堤 修一（@shu223）氏にスポットを当て、「面白い」仕事の呼び寄せ方を伺います。この対談は、2部構成（vol.15・vol.16）でお届けします。
idesaku：DevRelay- vol.14 では「自分が面白いと思う仕事が集まってくるようにコントロールしていた」と伺いました。フリーランスとして、「自分が楽しい」と思える仕事だけをやっていくのって、とても難しいイメージがあります。そのあたりの「コントロール」の仕方について、もう少し詳しく聞かせていただけないでしょうか。
shu223：先ほども少し触れたのですが、まず、ブログでの情報発信を含めて、周りに自分をどういうふうに認知してもらうかという「見せ方」がありますよね。それに加えて、お客さんと話すときに、Win-Win になるような提案を積極的にしてみるというやり方もあると思います。
過去の例になるのですが、かつて Apple Watch の SDK が出たくらいのタイミングで、新しいものが好きな企業から「会社にきて、Watch でどんなことができるのかディレクター向けに講義をしてほしい」という依頼が来たことがありました。ただ、講義って準備が大変で、その割にこの依頼はちゃんとした新人研修とかではなく1回限りの説明なので、値段をどう付ければいいかもよく分からなくて。あと、1時間ぐらいの説明のために先方のオフィスに行くのもオーバーヘッドが大きいなと。
なので、講義という先方の依頼そのもので考えるとお断りしましたが、一方で、自分でも出たばかりの Apple Watchアプリを作る仕事はやってみたいと思っていたので、結果として「クライアントの会社に行き、その会社が持っているアイデアをその場で聞いて、それらのアイデアについて Watch の SDK で何ができて何ができないかを説明した上で落としどころを決め、その日のうちにできるアプリを書いて渡す」という形ではどうかという提案をしました。
idesaku：それはユニークですね。
shu223：この形だと、自分は Watchアプリを作った経験が得られますし、お客さんも自分たちのアイデアが反映されたアプリが手に入りますよね。シンプルに1日の請求で済むので金銭面でもお互いにとってリーズナブルですし。お客さんからの依頼をそのままで受けたり断ったりするのではなく、依頼する側と自分の両方にメリットがある形での提案を臆せずにしてみるというのも、案件をコントロールする良い方法のひとつだと思います。
idesaku：その場合、金額については工数ではなく、拘束時間をベースにした見積もりを出すのですか。
shu223：1日〜5日程度でできるプロトタイプ等は工数ベースで請けることもありましたが、基本的には拘束時間ベースで請けてました。事前の「見積もり」については、ほとんどやらなかったですね。
正直なところ、作る前から、どのくらいの手間や時間がかかるかはわからないじゃないですか。きちんと見積もろうと思うと、頭の中で1回作らなきゃいけないわけですけれど、そういう作業って、かなり時間がかかりますし、手を動かしてものをつくるよりも楽しくないですし、結果的に成立しなければ見積もりにかかった時間分の料金はたいてい請求できませんし。さらに、開発中にお客さんが仕様を変更したくなることって必ずあると思うし、拘束時間ベースの方がそういう変更に柔軟に対応できますしね。
idesaku：たしかに（笑）。
shu223：だったら、お客さんのところに1日行って、その日にできる分の仕事をして対価をもらうという形のほうが、お互いに納得感が大きいんじゃないかと思っています。
もちろん、このやり方だと、僕ひとりの持つ時間に対して収入がスケールしないので、そこは考えどころですよね。値段を上げるというのは手っ取り早い解決策なのですが、かといって上げすぎると面白いスタートアップの仕事ができなくなる可能性も増えるので、そのあたりはちょうどいいくらいのところでバランスをとるようにしていました。
idesaku：サービス全体に関わるようなアプリの構築を長期で請けるようなケースはあまりなかったのでしょうか。
shu223：明確な文書で年単位になるような長期の契約はしませんでしたが、アプリが出るまで責任持ってやりますという暗黙の了解が会社と僕との信頼関係の上にあり、稼働日数はその時々の先方や僕の都合で柔軟に調整しながら、最終的に先方が出したいときにものが出せるようにする、という形で関わることはありました。
idesaku：それは、日本企業がクライアントのケースですか。海外の企業とそうした形で仕事をするのは、特に英語が苦手だと、交渉面で大変だと思うのですが。
shu223：こういうやり方でやっていたのは日本の企業ですね。といっても意図的に日本の企業に限定していたというわけではなくて、アプリの開発をまるっと請けるのはそれなりに時間もかかるし万が一ピークが重なると手がまわらなくて迷惑がかかる恐れがあるので、まるっと請けるケースは基本的に同時期に1社のみに限定していて、それらは日本の企業だった、というだけです。
ただ実際に、ある海外のクライアントとは交渉が面倒な話になりそうだったので「まず作る。気に入ったら金をくれ」という仕事をしたことがあります。
idesaku：それはチャレンジング（笑）。
shu223：それも Watch に関する仕事だったのですが、万が一、お金にならなかったとしても、Watch開発に関する知見が得られるという意味で、自分のメリットにはなるという計算はありました。自分のプライベート時間に勉強しても知見は得られるとはいえ、僕の場合、いくら興味があっても、仕事としてやらなければ1日8時間はできないので。
これがたとえば、アプリの古い iOS への対応のような仕事だとして、それがお金にならなかったら、 「今後も古い iOS対応を得意とするエンジニアとしてやっていきたい」とでも思ってない限りは自分としては得られるものがほとんどないですよね。ただ、最悪それでも、作ったものを OSS化したり、ブログネタとして消費したりという可能性については考えたと思います。
いろんなパターンを挙げてみましたけれど、請ける仕事を自分にとっても「メリットがある」ものにする方法は、いろいろあると思いますよ。
idesaku：堤さんの場合、20代までのビハインドが、30代以降のアクティブな活動の原動力であり、現在につながる糧になっている部分が大きいのではないかと思います。そう考えると、キャリアの中で一般的に見て「マイナス」と捉えられてしまいがちな要素があったとしても、長い目で見れば「帳尻」を合わせることは十分できると思わされますね。
shu223：今、僕がこうした形でやれているのは、大学時代までに自分の中に溜まった「グツグツしたもの」が吹き出しているという一面もあると思いますし、20代を何もせずに過ごしてきたという危機感への反動というのもあると思います。
よく、社会人になってから「大学時代にきちんと勉強をしておけばよかった」という人がいるんですが、その大学時代の時点では、その人にとっては「やらない」という選択をすることが必要だったんだと思うんです。なので、僕は大学時代に勉強をサボって、その知識が今になって必要になることがあっても、「勉強しておけばよかった」と後悔することはないですね。「その当時にサボったおかげで今がある」という部分も少なからずありますし、サボった分を今から勉強するなり、その知識はないものとして戦う方法を考えるなりします。
僕は、20代のころに仕事に熱心になれず、会社をクビにならない程度にサボって過ごしていた時期があります。その当時、世の中に対して何も生みだせていなかったのは明らかですが、もし、そのとき普通に仕事をしていたら、その後もしプログラマに転身する機会があったとしても、今のような形で活動するようなこともなく、普通のエンジニアとしてキャリアを終えていたかもしれません。何がどう転ぶかは、だれにも分かりませんよね。
idesaku：ちなみに、将来的に「起業」するようなことは考えていらっしゃいますか？
shu223：今のところ考えていません。これは、あくまで「今のところ」考えていないという意味であって、「将来的にわたってやらない」という意味ではありませんが。
idesaku：何らかの条件がそろったり、タイミングが合ったりすればやるかもしれないということですか？
shu223：うーん、自分が起業を「面白い」と思うことがあればやるかもしれません。でも、いろんなスタートアップをフリーランスの立場から見てきて、「自分でもやってみたい」とは今のところは思ってないですね。
idesaku：起業は「大変そう」ということですか。
shu223：それもあります。でもそれ以上に、ひとつのプロダクトや組織そのものを継続的に維持・成長させていくことよりも、技術に対してコミットして、色々な会社やプロダクトに関われることの方が楽しいと今は思ってるんです。
idesaku：堤さんのこれまでのお話しだと、魅力を感じたプロダクトに関わる仕事を「面白い」と思っておられるようにも感じたのですが。
shu223：これ、言葉にすると、ものすごく無責任に見えてしまうかもしれないんですけれど、作った後のプロダクトが成長する様子を見届けることよりも、最初にプロダクトを作る段階に関われることのほうが楽しいんですね。
idesaku：なるほど。業界的にも、サービスのためのアプリケーションをスクラッチから作れる人材は貴重だと思います。
shu223：自分は、何かモノやサービスを作るプロジェクトの言い出しっぺにはなれないんです。むしろ、そういう話が出てきたときに、一口乗らせてもらえるように口を開けて待っているようなところはありますね。
ただ、開発ができるエンジニアは世の中に大勢いるし、自分は開発に関して「他の誰も真似出来ない」ような特別なスキルを持ってもいません。でも、「モヤッとはしているけど面白そうな事業アイデア」の芯をつかんで、事業の優先度やタイミング、プロダクトオーナーのこだわり等も考慮しつつ、具体的なアプリの実装に落とし込む、という過程は得意かなと思っています。
つまり、「0から1」ではなく「1から10」でもなく、「0.1から2」ぐらいにするようなことに、一番興味があるし、それが自分に向いているとも思っています。
idesaku：たしかに、堤さんの場合、単に仕様書どおりにものを作るだけではなく、交渉や提案を含めた総合力が非常に高いように思います。
idesaku：今、30代前後の人に、先達としてアドバイスするとしたら、どんなことを言いますか。
shu223：人それぞれ状況や考え方が違うので、僕の成功体験の一部だけを切り取ってアドバイスするのは難しいですね。
例えば、僕の場合、世の中に自分の存在を発信しないと始まらないと思っていたので、その意味で「ブログ書くのはいいよ」というアドバイスをしていたことがあったんですけど、書き始めてもなんとなく億劫になってやめてしまうというパターンを何度も見てきました。「ブログで発信する意味」は人それぞれの状況や考え方によって違うので、そこを考えずにただ書いてても結局あまり意味を感じられなくてやっぱり億劫になると思うんですよね。人それぞれに向き不向きというのはあって、たまたま自分には「ブログを書く」というやり方が向いていただけかもしれない。
だから、自分がやってうまくいったという理由だけで、人に「これをやったほうがいい」とアドバイスするのは難しいですね。「それぞれ自分に合った方法を考えましょう」というのが一番良心的かもしれません。
idesaku：最後になりますが、DevRelay- vol.12・DevRelay- vol.13で登場したすぎゃーんさんから「堤さんはどこまでいきたいと思っているのか聞いてほしい」というリクエストをもらっていました。
shu223：「どこまで」というのは、決めていないし、見えないですね。5年後も、3年後も見えないのですが、1歩先くらいは見ているという感じでしょうか。
今、フリーランスを休業して、米国の「Fyusion」という会社の社員として働いています。正直なところ、フリーランスは自分に最高に向いていると思っていたので、海外の会社であっても就職したいとは思っていなかったのですが、いくつかの目的があって決めました。まだ苦手な「英語」を身につけるには海外の会社に入って一緒に仕事をする中で身につけるのが一番の近道そうだということと、僕が次に手を出したいと考えていた「コンピュータビジョン」「GPU処理」「3Dプログラミング」「機械学習」といった技術をプロダクトで活用している会社だったというのが大きな理由です。フリーランスではなく社員になったのは、声をかけてくれた Fyusion がアメリカの会社で、オフィスに行って一緒に仕事をするには就労ビザが必要で、そのためには社員になるしかない、という理由です。
idesaku：そこが今、堤さんが一番「面白い」と感じる領域だったということですね。
shu223：はい。ただ、Fyusion のリサーチチームには「機械学習」や「コンピュータビジョン」の領域で博士号を持っているような専門家がゴロゴロいて、今からそこにがっつり突っ込んでいっても勝負できないと思っています。
で、どこで勝負するかというと、それには、前に取り組んだ「BLE」での成功体験がありまして。僕は何年か前、アプリ開発にちょっと飽きてきた頃に、ハードウェアや電子工作にも興味があって、Arduino のワークショップに行ってみたことがあったんです。そのときに音を出す回路を説明書通りに組んだのですが、思ったのが「音を出すだけなのに、自分で回路を組もうとするとこんなに複雑になるなんて！」ということで（笑）。
音なんて、iPhoneアプリでやろうと思ったらすぐに出るわけじゃないですか。この調子だと、自分が面白いと思うハードを作れるようになるまでの道のりは遠いなと。そこで、自分でハードをつくることは早々に諦めて、アプリサイドからハードに関われることはないかと模索しているうちに、アプリとハードとの間で通信をする BLE に詳しくなったんです。ここができるようになったことで、自分ではハードを組めなくても、ハードを作っている人たちと一緒に仕事ができたんですよ。
そうした中で、Moff Bandというウェアラブルおもちゃや、「WHILL」という次世代車椅子の開発に関わったりする機会がありました。結局自分自身はハードの開発技術はないままなのですが、そのアプリを作ったことで「ハードを一緒に作った」という充実した感覚が得られて、すごく面白かったんです。
それから次に取り組みたい分野として「機械学習」や「コンピュータビジョン」が出てきたわけですが、この分野でも BLE の時と同様に、自分自身は「機械学習」のエキスパートになれなくても、その学習済みモデルをクライアントサイドから活用する部分を受け持つことで、面白いことができるんじゃないかと思いました。
Fyusion は、その分野に関していち早く取り組んでいたんですね。
BLE のときとちょっと違うのは、実は学習済みモデルをクライアント側で利用するにも、モデル構築側とセットでトライアンドエラーを回せないといけない、ということがわかってきて。そうなると僕が機械学習についてしっかり勉強してモデル構築するよりも、機械学習のエキスパートが iOS のシンプルな動作確認用コードをちょっと改変しながらトライアンドエラーを重ねた方が早いということに結局なってしまっていて、そこについては、ちょっとあてが外れたかもしれません。その上で、これからどうすべきかというのは考えていかなければいけないと思っています。
Fyusion で取り組んでいる分野は絶対面白い。でも、僕自身が機械学習のエキスパートになってその分野の人たちと勝負するというのも、ちょっと違う気がする。でも、世界を見ても、この分野に関してクライアントサイドの視点で情報発信している人は多くないし、続けることで学べることも多そうだ……というところで、いろいろ悩んでいます。
idesaku：次の「1歩先」をどうするかという部分で考えていると。
shu223：はい。「さらにその先」のことはまだ見えていませんが、日本やアメリカに限らず色々な国の人たちと仕事をする機会があって、それまでに身につけてきた「iOS」「BLE」「機械学習」「コンピュータビジョン」といったスキルを使いながら、引き続き面白いものを作ることに関われていけたらいいなとは思っています。
ただ、機械学習はまだ入り口に立っただけで仕事ではまったく触れていませんし、機械学習に限らず、Fyusion に入って身につけたいと思った諸々は、まだなにも身につけられていません。「英語がペラペラになる」でも、「機械学習やコンピュータビジョンの経験を積み、実績ができる」でもいいのですが、そうしたものを得ることで、ようやく次のステップに進むことを考えられるのでしょうね。
idesaku：非常に濃いお話を伺っていたら、いつの間にかインタビューの予定時間を大幅に過ぎてしまっていました……。そろそろ、恒例で次にバトンを渡す相手をご紹介いただきたいのですが。
shu223：カヤック時代の先輩、大塚 雅和さんです。
「IRKit」を作っている人で、ハードウェアとアプリ両方の開発から工場への発注まで、全て個人でやっているそうです。カヤックにいたころも Adobe の Flash を Web上で編集したりシェアしたりできるという、世界中の Flasher が大歓迎した「wonderfl」や、今ではカヤックで事業の柱の一つになっている「Lobi」の元になった「ナカマップ」など、その後のカヤックでチームで継続的に運営されていくことになるような重要なサービスの多くがもともとは大塚さんが一人でつくり始めたものだったりしました。
僕は折に触れ大塚さんからビシッとしたアドバイスをもらっていて、例えば「リーダーじゃなくプレイヤーとしてやっていきたいなら開発者コミュニティに影響力を与えられるぐらいにならないといけない。ソースコードを公開したりするのがまだ怖いなら、まずは技術ブログを始めてみたらどうか」と言ってくれたのは大塚さんですし、かつて僕がプロダクトのあるべき姿や全体像を考えるのを面倒くさがって先にコードを書き始めてしまいがちだったときに「実装に逃げるな」と忠告されたことは今でも度々思い出します。
そんな大塚さんは今でも畏れ多くて、一緒に飲んだりすることがあっても遠慮してしまっていろいろ聞けなくて（笑）ぜひロングインタビューで大塚さんの人生観や深い開発者哲学を聞いていただけたらと期待しています。
idesaku：IRKit を開発している方ですか！赤外線リモコンがある家電を Wi-Fi 越しにスマホや PC から操作できるようにする製品ですよね。私の周囲でも話題になりました。他者であることを生かしていろいろ伺っていきたいと思います。今日は長時間にわたってお付き合いいただき本当にありがとうございました。
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
本サイト掲載の全て記事は、フォークウェル編集部が監修しています。編集部では、企画・執筆・編集・入稿の全工程をチェックしています。
