シェア
はてブ
こんにちは！@giginetです。主にiOS分野の基盤開発を行うエンジニアをしています。
この度、僕のキャリアについて語る機会をいただきました。 他の記事を見渡すと、著名なコミッターや、各社のCTOなど、そうそうたる面々が寄稿されており、僕の話などで良いのかなと恐縮しつつ、筆を執らせていただきます。
こんにちは、giginetです
改めまして、@giginetと申します。 2015年に新卒としてクックパッド株式会社に入社後、モバイル基盤部という全社のモバイル開発を横断的に見るチームで6年間、レシピアプリの開発の主導などで、iOSエンジニアとしてのキャリアを積みました。
今年7月よりLINE株式会社、ディベロッパーエクスペリエンス（DX）開発チームに所属しています。 要は、iOS開発者が快適にアプリ開発を行うお手伝いをする仕事です。
また、iOS領域では、株式会社マネーフォワード、チャット小説アプリ「peep」を提供するtaskey株式会社の技術顧問をしています。
OSSでは、いくつかのiOS開発ツールのコミッターを努めています。 iOSのビルドやデプロイを自動化するタスクランナーfastlaneを始め、パッケージマネージャーとしてデファクトスタンダードであったCarthageや、Xcodeプロジェクトを宣言的に生成できるツールXcodeGenなどが代表です。
▲ろくろを回す著者
ゲーマーな僕が開発基盤エンジニアになるまで
今日はキャリアの話と言うことで、ここまでの遍歴について自分語りをしてみようと思います。
運良くプログラミングに出逢えた幼少期
僕のエンジニアとしての原体験は、コンピューターゲームへの強い興味にありました。9歳の時に手に取った『RPGツクール』で、フラグや変数の概念を理解し、複雑なスクリプトを組めた感動が強く残っています。思えばこのときからエンジニアとしての素養はあったのでしょう。
その後12歳頃、個人サイト製作のためにHTML、JavaScriptを、当時主流だったCGI開発のためにPerlを学びました。ゲームへの興味は依然として強く、若干12歳でゲームボーイのチートコードの探索などを行っていました。当時はそうした情報を扱う本が街の書店で平然と売られていました。牧歌的な時代ですね。
その後、自分でゲームを作りたい思いが強くなり、なんとなくC++の本を購入するも、延々と黒い画面で帳簿の計算をするサンプルが続いていました。一体どうやって画面を出すんだ、早く神ゲーを作らせてくれ！と悩んだものです。
そんな中、出会ったのが当時一世を風靡したFlashでした。何もしなくても画面が出る！ゲームも作れる！ガラケーでも動く！当時としては先進的だった環境にのめり込んでいきました。2004年ぐらいのことです。 アルゴリズムなんて言葉も知らなかったものの、自力でぷよぷよやローグライクを実装したり。この頃の試行錯誤は確かに血肉となっているように思います。
あらゆる領域に挑戦した大学時代
大学に入学し、プログラミングサークルに加入します。高校時代まで田舎町で育った僕は「パソコンばっかりやっていないで勉強しろ」と言われ続けてばかり。地元では周りに同志なんていなかったけれど、大学時代に初めてプログラミングを教えあえる仲間ができました。
この時代はたくさんのことに取り組みました。ざっと簡単に述べると：
- Web開発
- 当時バージョン3が出たばかりのRuby on RailsやDjango、Springなどでサークルのサイト製作やアルバイトのシステム開発をしました
- 競技プログラミング
- ICPCやGoogle Code Jamなどで腕を鍛えました。当時はAtCoderもまだなかった！
- モバイル開発
- iOS 4やAndroid Froyoなどが出始めたモバイルアプリ黎明期。当時最先端の技術でした
- 有名ベンチャーのインターンシップ
- はてなインターンに参加して、はてなブログの立ち上げや、はてなブックマークアプリの開発を行いました。クックパッドのインターンにも参加しました
その中でも、学部と院の6年間は、ゲーム開発の志を共にする仲間に恵まれ、インディーゲーム開発に没頭していきました。
当時はUnityが流行り始めており、今に続くインディーゲームブームの先駆け。世の中にはモバイルのカジュアルゲームが溢れていました。 鳥を飛ばしたり、数字を動かしたりするだけのモバイルゲームが当たって一夜にして億万長者。そんな夢を見て、何本もゲームを開発しました。
幾度ものゲーム開発の中で気付いたのは、自分自身のクリエイター的素養のなさでした。自分のゲーム開発のモチベーションは、作ることのプロセスや、実装に重きが置かれていて、具体的に何か表現したいものを持ち得ていたわけではなく、自力でのゲーム開発に限界を感じていました。絵が描けるわけでも、お話が作れるわけでもありませんし。
作品の開発を通して、次第にゲームエンジンや、開発基盤の整備、開発上の課題解決といったところに強く興味が惹かれていきました。当時、チームでのゲーム開発には常に課題がありました。例えば、以下のようなものです。
- 如何にレベルデザイナーがエンジニアの手を借りずに試行錯誤できるか
- 如何にメンバーが遊び倒してゲームを面白くできるか
- 如何にゲームのデバッグの手間を減らせるか
あるゲームの開発の際、エンジニアが手を加えずともゲーム開発を進められるように、スクリプトエンジンを開発しました。 当時採用していた、cocos2d-xというC++のゲームエンジンをLuaスクリプトで拡張できるようにして、レベルデザイン用のDSLを開発したのです。レベルデザイナーには、敵のパラメータやセリフをLuaで記述してもらいました。
これにより、高速なレベルデザインやテストプレイが実現。 他にもCI/CD的な仕組みの構築も行いました。Jenkinsを設置し、スクリプトの静的解析でシナリオを書く人のシンタックスエラーによるクラッシュを検知するようにしたり、コミットの度に開発チームにビルドを配布したり。 自分で言うのもなんだけど、2013年ごろとしてはかなりモダンな取り組みだったと思います。
▲当時作った神ゲーはまだストアでも配信中。若くなければ作れなかった
この頃から開発基盤エンジニアへの憧れを抱くようになりました。今思うと、これらは現在取り組んでいる開発基盤の課題に通じる部分が多いですね。
そこから、cocos2d-xに深くのめり込んでいき、ゲームエンジン自体にもcontributeするようになりました。 その結果「cocos2d-xではじめるスマートフォンゲーム開発」という書籍を出版するに至ります。
入社、キャリアの迷い、そして
2015年に大学院を卒業し、クックパッドに入社。ゲーム領域に行かないことに周りから驚かれ、個人的にも大変悩んだ記憶があります。
理由はいろいろありますが、当時主流だったソーシャルゲームに興味が沸かなかったこと、ゲーム系とWeb系の労働環境の隔たりという部分が大きな要因でした。 このとき異なる道を歩んでいれば、また別の人生があったかもしれません。
クックパッドでの最初の1年は、ビジネス領域のサービス開発に従事し、その後、モバイル基盤チームに移籍。以来6年間、全社横断的なiOSアプリの基盤開発をしてきました。
この間は非常に多くのことに取り組みました。 新規アプリ開発を推進していくための共通基盤を作ったり、リリースフローを改善・自動化したり、巨大なアプリの新しいアーキテクチャを広め、開発効率を爆上げしたり。
ここではとても語り尽くせないため、くわしくは先日投稿した退職エントリを見てみてください。
クックパッド株式会社を退職して、LINE株式会社に入社しました - 5.1さらうどん
気付けば日本有数の規模を持つモバイルアプリの開発で大きな裁量を持ち、チームを牽引していく立場になったことにやりがいを感じていました。
▲退職時の成果発表のまとめ、思えばいろいろやりきった！（@v4vfxvkwdmさん作）
僕はこうして開発基盤エンジニアになった
新卒の頃は、進むべきキャリアなんてわからないまま。しかし、今の僕は開発者を支援すること、自身のプロダクトで課題解決をすることに大きなやりがいを感じています。
ここからは「どのようにして、僕が開発基盤エンジニアのキャリアを突きつめることができたのか」を振り返ってみます。開発基盤エンジニアの仕事に興味のある方々の参考になると嬉しいです。
なぜあなたの基盤は使われないのか
･･････早速ですが特に煽りではありません。
開発基盤エンジニアを志す方のありがちな失敗として「ライブラリを作ってみたけど使われない」ということがあると思います。
かくいう僕も、キャリアを開始した当初は「ぼくのかんがえた最強のライブラリ」を意気揚々と開発するも、いざリリースしてみると全然他のエンジニアに使ってもらえないし、自分も使わなくなってしまった。そんな苦い経験があります。
ご自慢のライブラリが広まらない理由は、作ってみたけど使えない、なかなか使ってもらえない、メンテされなくなって外されてしまったなど、様々でしょう。
これらはひとえに「課題を解決できていない」ことに尽きると思います。
使われる開発基盤を作るために
開発基盤エンジニアとして成果を出すには、日々のプロダクト開発で湧き出す課題を適切に解決していく必要があります。 そのためには役に立つものを産み出す工夫、使ってもらう工夫を絶えず続けなければいけません。 あまり大層なことを言えたものではないのですが、僕が実践している基盤改善の心構えについてお伝えします。
課題を見つけよう
日常の開発で「同じコードばかり書いている」「同じことをレビューで指摘している」「間違いやすい・わかりづらい」「面倒くさい」。そのような不満があれば基盤改善のチャンスです。常に改善のネタを探してみてください。
開発者との対話も重要です。プロダクト開発をしている人と日々コミュニケーションを取り、そうした不満を汲み上げましょう。
アイディアと技術で問題解決
ネタが見つかったら、解決方法を考えてみましょう。日常的に興味を持っていた新しい言語機能や、OSSを生かすチャンスかもしれません。他領域・他言語の文化や知見が役立つこともあります。 日々のインプットが肝要です。
当然、具現化には問題領域の切り出し方や、使いやすいインターフェイスの構築方法など、技法的・センスによるところはあります。そのようなスキルを向上させるにはたくさん開発し、絶えず学び続けるしかありません。
作ったら使ってもらおう
完成後は他のエンジニアに使われる工夫をしましょう。
プロダクトにその技術を導入してドッグフーディングをしてください。 READMEを書くのはもちろん、開発者が自分と近いところにいる場合は説明会を開くなど、使ってもらえるように動きましょう。
作っただけで終わってしまうのは、画竜点睛を欠いており勿体ないです。 導入のしやすさ、利用しやすい文法、間違いづらいインターフェイスの提供など、DXの追求も重要です。
情報発信も忘れてはいけません。登壇や技術ブログの執筆など、自分の作ったものを知ってもらう工夫をしましょう。しつこいぐらいにスターを要求してみても良いのではないでしょうか？
日々是改善
最後にリリース後の改善が必要です。自ら使っていても問題点は見えてきますし、ユーザーである他の開発者との対話を重視しましょう。次の課題発見にも役立ちます。
事業上の課題発見、アイディアと技術による解決、使われる工夫、フィードバックを受けて継続的に改善。このサイクルこそが、DevOpsを上手く推進していく秘訣だと考えています。
これらを実践することで、徐々に僕は開発基盤エンジニアとして、一定の成果を上げることができるようになりました。 前述のゲーム開発時の基盤改善や、これまでのビルド速度の改善といったクックパッドでの取り組みも、結果的にプロダクト開発の生産性向上に寄与しました。 両方ともその根底には、開発と価値検証のサイクルを高速化したいという問題意識があったからに他なりません。
実はここまで述べたことは、一般的なサービス・プロダクト開発の手法と大きな違いはありません。 開発基盤というのは、通常のプロダクト開発と比べ、プロダクトの性質・対象ユーザーが違うだけに過ぎないのです。PDCAの話はもう耳タコですよね。
得意なことを仕事にしよう！
自分のキャリアの話に戻ると、自分が開発基盤エンジニアを選んだのは、単にこの領域が性に合っていたからに過ぎません。 よく「どうやって基盤改善のアイディアを出すのですか？」と問われることがあるのですが、自分でもよくわからず再現性がありません。単にたまたまアイディアを絶えず出し続けられる領域が開発基盤だっただけです。
ともあれ、自分が楽しんで取り組めることと出会うことができ、それが世の中から必要とされたのは大変幸運なことでした。
結局は、苦手なことではなく、感覚的にやりたいこと・得意なことをし続けた結果今があります。月並みな結論ではありますが、やはり得意な領域を見つけ、そこを楽しみ続けるのが、キャリアアップのための唯一の方法ではないかと考えます。
エンジニアとしてスキルアップしていくために
ここまで、僕がどうやって開発基盤エンジニアになったのか。どのようにプレゼンスを高めていったのかをお話ししました。
ここからは、エンジニアとしてのスキルアップのために、自分が実践している心構えについて、2つの原則をご紹介します。
インプットに強制力を持たせる
まず、1つめは、自分の学習機会に強制力を持たせることです。自らの学習やスキル習得を強制的に行える工夫をしましょう。 手っ取り早いのが、勉強会やカンファレンスへの登壇です。
通常、カンファレンスへの登壇は「何らかの成果が出てから」と考えることが多いと思いますが、逆に成果を作るために登壇することを実践しています。
例えば、習得したい事柄があったり、開発してみたいもののアイディアがあれば、とりあえずCfPを出してみましょう。中身は通ってから考えれば良いのです。これを登壇駆動と呼んでいます。
他人に向けて発信するというのは大きなプレッシャーになります。間違った情報を発信したらどうしよう、不理解で突っ込まれたらどうしようと、とてつもない不安に襲われるものです。 「間違ったことを言わないように勉強しよう」。その圧こそがもっとも良質なスキル習得の好機となると確信しています。 登壇にはさらに素晴らしいことに、締め切りまで付いてきます。
人間は（少なくとも僕は）怠惰な生き物なので、このぐらいの強制力がなければプロダクトを完成させたり、新しく知識をキャッチアップしたりすることが難しいです。
他にも技術書執筆や、寄稿、Advent Calendarなどの締め切りを伴うアウトプットも良いと思います。
勉強会は他人に教えてもらう場ではなく、自分が強制的に勉強する機会だと捉えてみましょう。
1つの成果にレバレッジを利かせる
もう一つ強く意識していることは、1つの成果をなるべく最大化させるという点です。 何かを成し遂げたとき、少ない手間で他の成果も出せないか工夫してみましょう。
例えば業務上で、何かを開発したり、新しい仕組みを導入できたりしたとき、その成果を他にも応用できないか考えてみましょう。
一般的に以下のようなことが挙げられると思います。
- 自分のやった仕事の知見を成果発表する（カンファレンス、勉強会、技術ブログ）
- 別のチームで使えるように汎化する、切り出してライブラリ化する
- OSSとして公開する
- 副業先などに導入する
ここまでやって1つの成果をさらに最大化することができます。
いくつか例をご紹介します。
僕の公開しているCrossroadというディープリンクのルーティングライブラリは、元々は「クックパッド」アプリの内部の課題解決のための一実装にすぎませんでした。 この仕組みが大規模なアプリでワークすることがわかり、小さなライブラリとして、汎化して切り出すことにして、OSSとしました。 その際に、技術ブログを書いたり、登壇したりしたことで、結果として☆400程度を獲得するOSSとなっています。 また、クックパッドの他のアプリはもちろん、技術顧問先にも導入して同様の課題を解決できましたし、「ニコニコ動画」といった有名アプリにも採用されるようになりました。
これは、1つの成果の最大化が綺麗に成功した好例と言えます。
僕がfastlaneやXcodeGenのコミッターになったのも、元は業務での継続的デリバリーや、開発体験改善から始まっています。 業務でOSSを利用するだけではなく、利用例を発信したり、利用時に困ったことをPull Requestして修正したりと、1つの成果が派生したことが、自らのプレゼンス向上に繋がりました。
このように、仕事、副業、趣味、対外活動、OSS、全ての活動領域が相互に作用し合うことで、好循環を生み出すことができています。
技術顧問の働きかた ~ゼロから始める異世界生活~
ところで、最近は本業の他に何社かの技術顧問を勤めております。これまで述べてきた考え方は、技術顧問として働く上でも大きく役立っています。
技術顧問と聞くと「何をやっているかわからない」と思われる方も多い印象です。 また、世の中には「技術顧問をやって楽して副収入！」などと喧伝する広告が溢れ、残念ながら、いかがわしいイメージをもたれてしまっている側面もあると思います。
僕自身も「何やってんの？」と良く聞かれるのですが、各組織が持つ課題は千差万別で、求められている動き方もさまざま。僕は2社での技術顧問として以下のような働きをしています。
taskey株式会社 ~スタートアップでの技術顧問~
チャット小説アプリ「peep」を運営するtaskeyさんはスタートアップであり、小規模なチームでアプリ開発を行っています。
多くのモバイル開発の現場において、開発者の確保は難しいものです。taskeyさんも、人材に限りがある中での、コード品質の改善やレビュー負荷が課題となっていました。 そこにリードエンジニアとのディスカッションや基盤開発を通して、開発体制の改善に寄与しました。 具体的には、レビュー負荷を下げるための開発ルールの導入や、どこからどのように負債を改善していくかについて議論し、徐々に品質の改善が進んでいます。
株式会社マネーフォワード ~成熟した組織での技術顧問~
一方で、マネーフォワードさんは国内有数のメガベンチャー。社内のエンジニアコミュニティの盛り上げや、メンバーの技術習得のお手伝いなどを目的としています。 また、メンバーにカンファレンスへの登壇を促すなど、Developer Relationに近い領域でもお手伝いしています。 最近の技術顧問の活動の中で、とても良い成功体験だったのが、マネーフォワードさんのメンバー向けに行った、OSS体験ワークショップでした。
iOSエンジニア向けOSS Forwardワークショップを開催しました | Money Forward Money Forward Engineers' Blog
予め用意したiOS領域のOSSにあるissueを参加者に解決してもらい、PRを送ってもらうことで、OSSの課題発見から貢献までをコンパクトに体験してもらうことを目的としました。 これによって、メンバーは初めてcontributeする経験を積め、会社は宣伝になり、OSSコミュニティはissueが片付き、そして僕は成果になって嬉しいと、四方良しの結果になったと思います。
▲Money Forwardさんで行った「iOS OSS体験ワークショップ」。技術顧問として理想的な活動ができたと思います。（Money Forward Engineers’ Blogより）
転生したらスタートアップだった件
技術顧問の活動を一言で表現すると「ダンプカーに撥ねられない異世界転生」という言葉がしっくり来ています。 自ら転職して、他の組織に行くのはそれ相応のリスクテイクが必要ですが、技術顧問という立場で開発の現場に身を置かせてもらうことで、様々な企業が抱える課題を体感できました。
（当然、やはりジョインしてみないとわからないことは多いでしょうし、体感できたと言うのはおこがましいという気持ちもあるのですが）
副業先それぞれにマッチした解決策を考えていくことは、僕のキャリアにも大きくプラスになっています。
また、技術顧問の役割は、「インプットに強制力を持たせる」「1つの成果にレバレッジを利かせる」という上記の2つの原則を実現するのに大きく役に立っています。
前述のワークショップのような機会を顧問先で持つことで、強制的に準備をする必要が生まれ、自らの学習機会にもなりました。 他にも、本業で解決した課題を顧問先にも紹介したり、逆に顧問先から上がってきた質問を調べ、本業に生かすなど、相乗効果が生まれています。
何より自分が楽しんで仕事できる上に、お客さんにも感謝される。こんなによいことはなかなかありません（ちゃんと感謝されていますよね？）。
さらに大きな組織で戦いは続く
冒頭に述べたとおり、1ヶ月ほど前からLINE株式会社での新たなキャリアをスタートしました。
ここまでのキャリア選択は、クックパッド、LINEと大手・メガベンチャー志向が強いです。 これは、僕が得意とする開発基盤という領域が成熟した組織でこそ強く求められているという側面があるためです。基盤開発は、大きな組織であればあるほどスケールメリットが得られます。
例えば、クックパッドにいたときに行っていたログ基盤の改善や、マルチモジュールの推進、これからLINEで取り組んでいくビルドキャッシュの導入やビルド高速化といった課題は、大きなコードベースがある環境だからこそ必要とされるものです。組織によってはオーバーエンジニアリングに陥ってしまう恐れがあります。
大規模なアプリを快適に開発できるような環境作りのためには、他の誰も取り組んでいない手法を突きつめていく必要があります。そのような新たな技術課題に専念できる環境こそが、大きな組織ならではの魅力だと感じています。
まだ入社して間もないですが、入社から3週間（※執筆時）の間に感じたことは、まだまだ解決できる課題は山積みであることです。
今後は、これまでクックパッドで達成してきたことをLINEというさらに大きな組織に展開していくことや、はたまた全く新たな事業課題に挑戦していくことになると思います。
さらに大きな組織で自分の存在感を出せるか。まだ見ぬ開発手法を考案し、世の中の開発者の力になれるか。今からとても楽しみにしています。
本稿が少しでも皆さまのキャリアの道標になりましたら幸いです。
三木 康暉（みき・こうき）
LINE株式会社ディベロッパーエクスペリエンス開発チーム iOSエンジニア。北海道函館市出身。1990年生まれ。北海道大学院を卒業後、クックパッド株式会社に新卒で入社。2022年7月より現職。
株式会社マネーフォワードなどでiOS領域での技術顧問を務める。
著書に『cocos2d-xではじめるスマートフォンゲーム開発』(技術評論社)など。
