はじめまして、田籠聡(@tagomoris)です。現在はフリーランスのソフトウェアエンジニアとしていくつかの会社で技術顧問をしつつ、個人的なプロジェクトの開発をしたりしています。これまでのキャリアとしてはISPやSIerで働いたのち、livedoor(およびその後のLINE)や、Treasure Dataといった会社で働いてきました。また、みなさんがご存じかもしれないものだと、ISUCONというイベントを始めたり、データ分析基盤関連の技術やFluentdをはじめとしたOSSプロダクトの開発に関わったりしています。
自分のキャリアを振り返ると、これまでいろいろと面白いプロダクトやサービスに関われてきました。一方で、自分にとって面白いプロダクト・面白い開発とは何かということが、経験を積むにつれて変化してきたとも思います。この記事では、何を面白いと思うか? どうやって面白いものに関わり続けていくか? について最近の自分が考えていることを紹介します。
- 手を動かしてみたら面白さがついてきた
- 誰も手掛けてない面白そうな課題は境界線上にあった
- 見つけた課題をできるだけ面白く解決するために
- ICとしての楽しさと、ままならなさ
- 「面白いものを自分で作る」をもう一度
手を動かしてみたら面白さがついてきた
これまで働いた会社でのポジションを考えると、どれもかなり異なっています。最初のISPでは業務系システムのプログラマー、SIerではプロジェクトマネージャー兼営業兼コンサルティング、livedoorとLINEではインフラ系ソフトウェアエンジニア、そしてTreasure Dataでは分散データ処理基盤のソフトウェアエンジニアでした。
このうちSIerでのポジション1以外では、マネージメント職を避けてきた面があります。特に2015年前に入社して2021年夏まで働いたTreasure Dataでは、それを徹底していました。最近ではgfxさんの記事でも紹介されていた、IC(Individual Contributor)というキャリアです。
この間にやってきたことは公でないものも含めて数多くありますが、振り返ってみると幸運にも、誰も手掛けていないような面白い仕事をいくつもやれてきたように思います。特にこの10年くらいは、自分にとって面白い仕事がしたいという意識が強かったなという自覚もあります。
しかし思い出してみると、手をつける前から一般的にも面白そうだと分かっている仕事はそう多くはありませんでした。ISUCONを思い付いてkazeburoさんと一緒に始めたときにも、第1回を終えるまでは「これ本当に面白いのかな?」が正直な気持ちでした2。
大量のWebアクセスログを相手にしたデータ分析基盤を作り、その技術の詳細を公開しはじめたときも、自分にとって面白く役に立つ以上に、世の中でかなり注目してもらえたことは意外でした。確かに、今までにない機能や仕組みもその中にありましたが、今までにないのは需要があまりなかったからかと思っていたためです。実際に作ってみたら、そして他の人でもすぐ実行できる状態になっていたら、多くの人が「役立つ」「面白い」と思ってくれて、同様のツールや仕組みが広く利用されるようになりました。
誰も手掛けてない面白そうな課題は境界線上にあった
「面白い仕事がしたい」ということは、おそらく多くのソフトウェアエンジニアにとって共通した望みでしょう。しかし、どうやって面白い仕事になりうる課題を見つけるか? 面白くなりそうな課題に手を付けるのか? その方法について、あまり共通の理解はないように思います。
自分を振り返ってみると、面白い仕事の多くは複数のバックグラウンドの境界線上にあったように思います。例えば、ISUCONの開催はITインフラ関連技術なしに成立しませんが、同時にWeb関連技術を用いたプログラミングもかなり要求されます3。そして「完璧なイベント運営を目指さない」とでもいうか、当時の「有志による勉強会の手作り感」をそのまま持ち込めたからこそ始めることができ、受け入れてもらえたのではないかと思います4。現在のISUCONは非常によくオーガナイズされていますが、最初からその形で実現しなければならなかったとしたらおそらく開始することはできなかったでしょう。
データ分析基盤についても同様です。最初にlivedoorのシステムの裏側でログ収集基盤を作り始めたのは、ITインフラ関連の要求があってのことでした。そこにデータ分析の機能を積極的に追加していったのは、Webアプリケーションの運用において、そしてWebサービス改善のデータ分析にビジネスサイドからの要求があることを知っていたからです。
自分にはキャリアの初期に営業やコンサルティングの経験があり、何を開発するべきか考えるときに、この経験が複数の視点をもたらしてくれました。こういった考え方はTreasure Dataで働くようになり、営業やセールスエンジニアの同僚たちと議論しながらサービス開発をしていく上でも非常に役立ちました。
考えてみれば、複数の専門性の境界上にある課題を手掛けられる人は多くありません。これは当然のことです。そして境界線上にあるものほど、さまざまなことを考える必要があり、広い範囲に影響のある面白い課題である可能性が高いのです。これもまた当然ではないでしょうか。
見つけた課題をできるだけ面白く解決するために
面白い課題を見つけたあとに重要なのは、それを面白い方法で解決することでしょう。もちろん仕事を楽しんでやりたいし、面白い方法で解決できれば、さらにその次に何をするかにもつながります。そのために自分が重要だと思うことはまず技術、そしてコミュニケーションです。
常に「今はできてないけど、できるはず」なことを目指す
技術面で一番大事なことは、当然ですが、とにかく実現したい機能をきちんと実装することです。それ以外の周辺部分については、自分は要素技術ではあまり凝ったことをせず、性能的にもセキュリティ面でも手堅い方法だけを選ぶことが多いです。目的(最終的に解決したい課題)が十分に面白いなら、過程の細部に凝らなくても、全体的に面白い実装になります。そもそも新しい課題を解決しようとしているときには、それ以外のことは極力自分で実装しないようにするなど、主目的の課題に注力したいものです。
他方、実装の主目的について重要なのは、「今はできていないが、理屈としてはできるはず」を常に目指すことだと思います。今できないことをやることは絶対に必要です。そうしなければ、自分にできることが増えませんし、それどころか世間の技術の進歩やトレンドの移り変わりによって、できることの割合が減る一方になるからです。これにより、仕事をしながら技術力を上げていく、ということになります。
また「今できないこと」が、自分だけでなく他人にとってもできないことであれば、それを最初に「できる」ようにしたのは自分ということになります。これは文句なく面白い仕事になるでしょう。
一方で「できるはず」ということは、ある程度の不確実性(失敗の可能性)もあるということです。その大小は実装規模や、課題の難易度によっても上下するでしょう。時には失敗することもありますが、その失敗の経験を生かせるような組織になっていれば、チームとして前進を続けることができます5。ある程度の失敗は最初から折り込んでおくのが正しいアプローチでしょうし、個人としても「失敗したね、まあしょうがない、次に生かそう」くらいで、あまり深刻になり過ぎないことも必要かと思います6。
コミュニケーションをためらわない
課題を解決するときに技術の次に重視しているのは、意識して他者とのコミュニケーションをとることです。「技術の次に」と書きましたが、技術は好きでやっている部分も大きく、意識しなくても熱中できる7ため、最も意識していることといえるかもしれません。
例えば技術力がついてくると、技術の分野や開発した機能によっては「周囲で自分が一番詳しい」という状況になることも珍しくありません。ある程度のシニアな技術者であれば、ある物事については世界で一番詳しいということもありえます。特にさまざまな分野の境界線上にある課題は、そもそも注目している人も多くなかったりしますから、問題意識を持っているのも自分だけということもありえます。
このとき非常に大事なのは「今作っているものの目的や利点を明確に理解して、他人と共有する」ことです。これが、ここで言うコミュニケーションです8。
会社員であれば、今の自分がある課題について働いているのはなぜかを、同僚やマネージャー、あるいはビジネス上で関連する営業などの人々にも説明する必要があるはずです。しかも、その課題について周囲で一番詳しいのが自分となれば、説明を誰かに任せることもできません。
これは社員としての活動に限らず、例えばISUCONのようなイベントを開催したいのであれば、どこが面白いのか? なぜやりたいのか? どのような人が対象となるのか? などを多くの人に説明しなくてはいけないでしょう。OSSを作る場合でも、そのソフトウェアの意義を説明することは極めて重要です9。
うまくコミュニケーションするために大切なこと
プログラマをやっていると、コミュニケーションは特に面倒だと感じることもあります。しかしコミュニケーションは、うまくやれれば自分の周囲に仲間や支援者を増やしてくれますし、そういった人たちから新たなアイデアなどをもらうこともあります。
コミュニケーションは口頭の会話でのみ行われるものではありません。Slackなどのチャット、ドキュメントやブログといったテキストも大きな役割を果たします。有効であれば、使える限りさまざまな方法をとるべきでしょう。また表現や用語の選択においても、技術者同士での会話やソースコードの他、ビジネス領域(経営者や営業、人事、サポートなど)の人と会話するときの表現を持っていると便利です10。もちろん外資系の会社や世界的なOSSならば、ここに英語も加わってきます。
どの方法や言語であっても、一番大事なのは「自分は何かを伝えようとしている」ことをまず示すことです。伝えたいことがあるなら、とにかく何かを話すなり書くなりすれば、周囲の人はきっとその内容を理解しようとしてくれるはずです。
ICとしての楽しさと、ままならなさ
ここまで書いてきたことを自分でも大事にして、これまであれこれと仕事や、仕事以外の活動をしてきました。特に仕事の多くは、いわゆるICとしてのものでした。しかし、最近はちょっと違う心境にもなっています。数年前に「マネージメントはやりたくない、開発者としてずっと生きたい」と思って以来、ICとして動いてきたのですが、これにままならない点というか、自分にとって理想的なことばかりでもないことが増えてきた状況なのです。
思えば前職でも、スタートアップとして比較的初期の頃に入社したため、会社全体もエンジニアチームも人数が少なく、一人一人の裁量がかなり大きな状態でした。次に何をやるか? どのようにやるか? あれとこれの優先度はどちらか? ビジネスに対してアイデアをどう沿わせていくか? などを完全に自分の裁量で考えていました11。そのために、営業やマーケティング、サポートなどさまざまな職種の人とも日常的に会話していました。これは自分にとって理想的ともいえる、とても楽しい環境でした。
しかし年月が過ぎ、ありがたいことにビジネスが成功して会社が大きくなってくると、状況がやや変わってきます12。技術を支えるチームと顧客に向いたチームの間にさらに別のチーム(プロダクトマネジメント)ができ、技術とビジネスの関係やロードマップの策定、優先度の設定などをする専門職が増えました。自分の担当分野でも、どう作るかの裁量はありますが、何をどの優先度で作るかを自分だけで決めるわけにはいかなくなりました。エンジニアリングの要素も細分化され、それぞれ別のチームが担うことになり、自分の担当以外のシステムには気軽に手を出せる状況でもなくなりました13。
このような状況の変化に、自分は割とうまく対応できた方だったと思います。ポジションとしてはプリンシパルソフトウェアエンジニア(Principal Software Engineer)になり、チームを越えたミーティングにもよく呼ばれるようになりました。自チームの他のメンバーにどのような影響を与えるか? 自チーム全体で達成する大きな成功のためどう働くか? さらに他チームの成功にどう協力するか? そういったことを考えることが当然のように求められました。仕事全体におけるコミュニケーションの割合はどうやっても増えますし、いま自分がやりたい仕事をいったん置いてでも他のことをやる、ということもかなり増えました。
結果として、これがICとして自分が望んだものだったか? を考えることも多くなり、最終的にはそのポジションは6年半近くの在籍の後、退職しました。ビジネスの成功に伴う状況の変化自体は、自分が最初から望んだものでした。それは分かっていましたが、ICであっても状況によって働きかたがさまざまに異なるということがきちんと分かっていなかったということでしょう。それでも会社やサービスの成長、そしてそれに伴うさまざまなものを自分の目で実際に見られたことは、非常に大きな経験になりました。
「面白いものを自分で作る」をもう一度
退職前後には自分が求めるものもはっきりせず、いろいろなことを考えました。それから時間もいくらか過ぎ、考えも落ち着いてきました。今は「面白いもの、自分が欲しいものを、自分で作りたいように、作る」と決めて、その準備を始めているところです。
それが成功するか失敗するかは全く分からないし、理性的に考えれば失敗する可能性の方がはるかに高いことは分かっていますが、それでも成功したら面白そうだという考えが頭から消えてくれなかったので、これはもうやってみるしかないかなと覚悟を決めました。少なくとも、世の中に自分が面白いと思うものをひとつ出せるところまではやってみるつもりです。
自分のキャリアは、場面場面では順風満帆なばかりでもありませんでしたし、局面ごとの選択に一貫性もありませんでした。それでもここまでやってこられたのは、さまざまなことを面白がってやってこられたからかなと思っていますし、これからもそうありたいと強く思っています。
編集:はてな編集部
- 余談ですが、自分は一時期プログラマーとして生きるには向いていないんじゃないかと思って大手SIerのグループに入り営業やプロマネなどをやっていたのがこの頃です。思えばこのキャリアも今の自分をつくるのに不可欠だったと思えるので人生はどうなるか分かりません。↩
- ISUCONについてはその後に回を重ね、参加者側になることを経験してようやくその面白さを確信できたというのが、自分にとっての感覚でした。初めて参加者になったとき「みんなこんなに面白いことをやってたのか!」と本気で思いました。↩
- この両立は今となっては普通のことですが、2011年当時はITインフラとWebアプリケーションは別々の専門性だと広く理解されていたように思います。↩
- これはもちろん当時から今に至るまで運営面を担っている櫛井(@941)さんや、他の協力してくれた同僚たちがいてこそのことでした。↩
- 余談ですが、自分も数年前に非常に大きな失敗をしました。この失敗はもちろん自分にとってもチームにとっても痛手でしたが、同時にその時のアプローチにあった問題を浮き彫りにしてくれたものでもありました。その後には同様のゴールに対して異なったアプローチがとられ、失敗の経験を生かすことができたと思っています。↩
- これは受託型の業務をやっているとなかなか受け入れにくいことでもありますが、小さな失敗と改善を繰り返すことで大きな失敗を避けるという方法論はその分野にも適用できる、というのはよく紹介されていることでもあります。↩
- むしろ技術に熱中し過ぎて、コミュニケーションなどを放置しがちな方が問題になりやすいですね。↩
- なお「プログラマならコードで伝えられる」ということもよく聞きますが、実のところそれが通じるのはごく小さな範囲、あるいは限定された問題についてのみで、プログラマの仕事においても例外的なことだと思います。実装に何カ月もかかるような問題にとりかかっている間は、人に知らせないことは不可能ですし、そもそもチームとして取り組む大きな問題を最初に説明するのにコードなど書けません。課題や解決手法がビジネスに及ぼす影響などについても同様です。↩
- OSSリポジトリを作るときには、READMEの先頭に「なぜそのソフトウェア/プロジェクトを作ったのか」を書くべき、というのはよく言われるアドバイスです。↩
- これはもちろん文字通りの日本語ですが、技術者間での会話とは異なる語彙を使って技術的な話を分からない人に説明できるようにしておきたい、ということです。この能力は突き詰めればひとつの専門職となりますが、そうでなくてもある程度は誰にでも必要とされる技能でもあります。また自分の場合は特に話す相手によって、内面というか気分的なものを切り替えるように意識しています。↩
- もちろん、自社および顧客のビジネスがうまくいくこと、そのために働くという部分は大前提として存在します。それを自然に受け入れることができない人は、スタートアップで働くのは難しいでしょう。↩
- このビジネス上の成功は大いに喜ぶべきことで、これを目指して自分も同僚も働いていました。そもそも自分が望んで得た状況だったのです。↩
- これも当然のことです。それぞれのチームにはそれぞれの計画や将来像があり、それを理解していない他チームの人が言うことを簡単に受け入れていたらすべてが混乱します。↩