スマートな実装で、後戻りが少ない開発を。DeNA、クックパッド出身エンジニアの知見が凝縮されたPLAYLIFE

プロフィール

ライブドア、DeNA、クックパッドなど、所謂メガベンチャーで、サーバーサイドやインフラを中心にサービス開発に携わる。

2017年に水産流通のプラットフォームを開発・提供している株式会社フーディソンに入社し、CTOとして同社の技術を統括。

同時に2018年より、PLAYLIFEの技術顧問として技術領域における指導やエンジニア教育などを担当している。

ゼロに近いフェーズに興味があった。コミットしているうちに愛着が湧いた

PLAYLIFEとの出会いは、DeNA時代の同僚に「遊びにきなよ」とラフに誘われて太一さん（CEO佐藤太一）の家にお邪魔した時でした。

その場で太一さんから「手伝って！」と声をかけてもらったことがきっかけです。

自分のキャリアの中で、大きな企業の中で新しいサービスを開発するということは何度かあったのですが、組織として0に近い状態から開発したことはありませんでした。「一度は０に近いフェーズでやってみたいな」と興味を持っているところだったので、「少しくらいならやってみようかな」と思い、最初はインフラ周りをお手伝いすることになりました。

その時はそんなに長く携わるつもりもなかったのですが、インフラ周りを整備したあともズルズルと引きずられて、気づいたらサービス部分の実装もかなり書き換えることになってしまいました。完全に太一さんにうまいことしてやられましたね。（笑）

というのは半分冗談ですが、コミットしているうちにサービスへの愛着も湧き、PLAYLIFEが今後どうなっていくか、それと太一さんのこれからの動向に興味があって携わっていますね。

「可能な限り後戻りをなくす」得てきた技術的知見をPLAYLIFEへ

PLAYLIFEで今までどのような方針で開発してきたかと言いますと、開発リソースが限られていることがわかっていたので、なるべく後戻りしなくていいように作ってきました。

仕様の決まっているサービスを作るだけなら比較的簡単なんですが、過去の経験から、サービスはスケールするときに技術的な負債が発生しやすい。とくにPLAYLIFEのようなメディア系のサービスは、アクセス数が膨大になるので問題が起きやすい。僕は大規模なシステムから小さいものまで幅広く開発してきた経験があるので、規模に応じてインフラ設計やコードのあるべき姿というのがある程度わかるのは強みです。スケールするときにどう手を入れるかを意識して作っていたので、コードの基礎的な部分はそのまま使えています。

また、ビジネス的な要求も先読みしています。ビジネス側の方が、例えば「週１回しか使いません」という機能でも、どうせいつか毎日使うことになるんですよね（笑）なので、ある程度の可能性を考えて、新しい機能やコードが挿入されたときに破綻しないように考えた開発をしてきました。

現在の役割としては、技術的な助言や方針を示したり、コードレビュー、エンジニア教育などです。他社での経験から得られた知見をPLAYLIFEに移していくことで、問題を先回りして解決しています。

実際にオフィスに来るのは週1ですが、Slackで定期的にコミュニケーションしていますね。

PLAYLIFEの技術方針は「新しい価値作り」と「技術的負債を作らない」こと

エンジニアとして、新しい価値を作ることが大事だと思っています。そのために新しい価値に挑戦していきたいですね。コモディティ化していないことでも積極的に取り入れたり。そのほうが、中で働いている人も楽しいですしね。

現実的な話をすると、PLAYLIFEを軸としたサービスの展開を考えてプラットフォーム化を考えています。PLAYLIFEで持ってる情報を別のサービスでも使えるように、アカウント情報やアクティビティを内部的なAPIとして使えるようにしたり。

また、引き続き技術的負債をなるべく作らないようにしていくことも重要視しています。例えばPLAYLIFEはRailsで書いているんですが、ちゃんと最新のバージョンに追従しています。意外とこういうのって後回しになりがちじゃないですか。でも、全体で見た時に結局非効率になってしまいがちなので、全体最適を意識して投資してますね。

ただ、人が少ないために開発力が十分でないので、まだまだやりたいことができていない状況です。例えば深層学習の画像処理を用いて、ユーザーの投稿した画像から情報を抽出したいですし、テストももう少し充実させたいですね。