「攻めと守り、一気にやっちゃえ」で、結果大泣きしたことも　akippa社のPdMが語る、ローンチから現在までの生々しい話

テーマは「ローンチから現在までの生々しい話」

井上直登氏：では、トップバッターですね。akippaから、サービスローンチから現在までの生々しい話をさせていただければと思っています。よろしくお願いします。

簡単に自己紹介をいたします。私は井上と申します。（スライドには）いろいろ書いてありますが、akippaでは、プロダクトの開発部門の責任者としてプロダクトマネジメントと、あとはエンジニア、デザイナー、企画チームのマネジメントを行っています。

写真を見てもらうとわかるとおり、釣りが趣味です。毎回こういうイベントでは「釣りトモを募集しています」と言うのですが、誰からも声がかかったことがないので、今日こそは釣りが好きな方がいたら、ぜひ後でお声がけください。一緒に行ければと思っています。

今日のコンテンツです。トップバッターとして、広く浅く、事業フェーズ、ローンチから今までというところを押しなべていろいろ話していこうと思っています。

立ち上げ期に攻めと守りのバランスをどうしていたか、成長期に入ってからどうしていたか、というところを話をしていければと思っています。

「“あいたい”をつなぐ」を大事するakippa社

最初に「akippa」についてお話しさせてください。どういうサービスかというと、使っていない空きスペースを駐車場として簡単に時間貸しできるマーケットプレイスとなっています。

（スライドを示して）下の図でいうと、右側が駐車場を持っているオーナーです。車を停められるスペースがあって、akippaに駐車場を登録すると誰でもオーナーになれます。スペースを日本全国のドライバーに貸して、その収益をレベニューシェアするというビジネスモデルです。

車を持たれていなかったら聞き慣れないかもしれないが、実は（サービスは）めちゃくちゃ広がっています。（スライドを示して）これ、左側が東京駅付近なんですが、こういう立体駐車場が1フロアakippaだったり、あとは、（スライドの）右側が世田谷や高円寺周辺ですが、実は町を歩くと、住宅街の中でもそこら中にakippaがある状態になっています。ご自身が住まわれている駅周辺を一度検索してもらえると意外とあるのをわかっていただけるかなと思います。

駐車場のシェアリングを通じて、akippaが何をやりたいかという、思いの部分を語らせていただければと思います。（akippaは）「“あいたい”をつなぐ」を大事にしています。

コロナ禍を経て、会いたい人になかなか会えないという実感を持たれた方もいると思いますが、akippaは、駐車場シェアリングでいろいろ困りごとをなくして、会いたい人に気軽に会いにいけるとか、そういった世界を作っていこうとやっています。

なので、駐車場シェアリングはあくまで手始めの1つです。自動運転やEVなどモビリティにはいろいろな変化が起こっていますが、そこに合わせてサービスを展開していこうとしている会社だと思ってください。

実際につないできた出会いは、いろいろあります。実家の近くで使っていない駐車場がシェアされて、帰省する回数が増えたなどがありますが、見ていただきたいのはここですね、（スライドの）左下。浅草とスカイツリーの間という最高の立地で、プロポーズがうまくいきましたと。

まさに、こういう体験をどんどんどんどん増やしていきたいと思っています。ちなみに私の奥さんへのプロポーズは成功はしましたが、記憶に残らないぐらい酷いプロポーズだったと言われています。エピソードに興味があればまたの機会に話します。

（会場笑）

立ち上げ期は攻めが10、守りが0

立ち上げ期、どうだったかという話をしますね。左が攻めのバランス、右が守りのバランスです。完全に攻め一辺倒、10：0ぐらいの心持ちというかスタンスでサービスを立ち上げています。

akippaって実はもともと営業会社でした。とはいえ、このまま営業でやっていいのか？　というところがあり、世の中を変えるようなプロダクトを作ろうというところで、社内でakippaの原案を作りました。

ただ、当時は営業会社だったので、社内に企画できたり、システム設計できたりする方がいない状況だったんですね。代表のつてで、協力してくれたエンジニアさんが、自身の経験やスキルセットで最速でリリースできるというもので作ってくれました。

なので、リリース後も検証をいろいろやっていたのですが、スピードが最優先の開発で、保守性や可用性はほとんど考えずに……と言うとだいぶ失礼ですが、そういったところを後回しにスピード優先でやっていくというアプローチをしていました。

結果、どうだったかというと、良かったんじゃないかなと思っています。スタートタイミングはやはり成功するか失敗するかはわからないので、確率的には失敗する可能性のほうがやはり高いです。そういったところでは、攻め一辺倒で良かったんじゃないかなというのが1つあります。

2つ目ですが、どういう設計にしていくのかというところに議論に時間を使うよりも、とにかくリリースしていく、検証していくことを最優先にしていくというエンジニアの判断は正しかったと思っています。

メルカリさんも言われていますが、技術負債という言い方ではなく、技術資産だよねというスタンスです。やはり、後から入ってきてそういったものを「何だよ、このクソコード」と思っちゃうエンジニアさんもいると思いますが、そこはリスペクトをしつつ、どう良くできるかという思考で話していくべきかなと思っています。

成長期初期は攻めが5、守りも5　チャレンジがお蔵入りしたことも

ここから、成長期、ある程度軌道に乗ってきた後のakippaの攻めと守りのバランスの話をさせてください。成長期、前期・中期・今みたいな感じで3つのステップに分けて話をしていきますね。

成長期の初期は、守り・攻め、半々ぐらいのバランスでやっていました。

環境がいろいろ変わって、「IVS」で優勝して、資金調達して、ステークホルダーが増えたり、その資金でいろいろな人が入ってきたり、事業においても軌道に乗ってやるべきことが明確になってきたりなど、良い変化がありました。

浮かび上がってきたイシューとしては、よりスマートな計画や開発の必要性が高まってきました。あとは、いろいろな人が入ってくる中で、サービスやシステム仕様の課題も浮き彫りになってきました。ほかにも、次の成長ステージに向けたもっと大きなチャレンジを求められるところもありました。

結果、何をやったかというと、攻めと守りをバランス良く一気にやっちゃえという感じで、思い切ってサービス全般をリニューアルするというチャレンジをしちゃいました。

結果、どうだったかというと、大泣きの大泣きぐらいになってしまいました。途中まで進めていましたが、結果、ペンディングというお蔵入りにしています。半年弱くらいかけたんじゃないですかね。エンジニアさん総動員でやったのですが、泣く泣くお蔵入りにしています。

なんでかというと、まず理想が高すぎました。目指すゴールの難易度がシンプルに高かったかなと思っています。改善したいことをやはり詰め込みすぎました。あと、システム設計的にも新しいチャレンジを盛り込みすぎてハードルが上がったところがありました。

ほかに、現状理解も非常に甘かったです。私を含む中途入社組を中心に、ドメイン知識もまだまだ甘いまま要件や設計を考えたりするのは、けっこう無茶だったかなと思っています。

あと、正直チームも未熟でした。お互いのことをきちんと知っている状況ではなかったので、開発速度や、お互いの良さって何だったっけ？　とか、そういったところの理解も甘く、ハードなプロジェクトを組んでしまった結果、挫折してしまったところがあります。

ただ、当時、別の方が止めようという判断をしたのですが、その判断自体は英断だったかなとは思っています。

成長期中期は攻めが3、守りが7　現実路線で開発を進めた

そこから中期ですね、真ん中ぐらいで何をやっていたか。ローンチしてから6年、7年、8年ぐらいに何をしていたかという話を次にしていきます。

この期間は、攻めがだいたい3、守りが7ぐらいの割合でやっていました。

リニューアルの反省ですが、先ほど言ったような課題があって、そこからどういう路線でやっていたかというと、現実路線でいきましょうと（なりました）。

少しずつ新しくしていこうという方針が1つと、開発を進めていく中でも、少しずつシステムを理解していこうというアプローチでやっていました。

あと、採用も強化して、攻めも守りもきちんとバランス良くできるようにという感じで、体制も一気に増やそうとチャレンジしたのがこの期間です。

いろいろやりました。うちが今使っているのはPHPとLaravelなんですが、当時はZendというものを使っていたので、そのフレームワークを移行しました。、あと、モバイルアプリも外注会社に作ってもらっていましたが、内製化して、それをきちんとリファクタリングしてたり、テストコードを必須化したり、こういったことをやっていました。

結果は、良かったところも悪かったところもありつつも、課題がたくさんあったかなと思っています。

まず、ポジティブなところとしては、一定の前進が見られました。開発の品質やレベルは、この期間で非常に上がって、しっかりとしたコードを書けたり、開発ができるというチームになれたというところは、何ものにも代え難い成果だったかなと思っています。

一方で、事業はまだまだどんどん成長させたいという僕らの気持ちもありますし、外部からの要請もありますし、そういったところで成長にも一定リソースを割かないといけない中では、思うように技術負債と向き合えず、まだまだ解消できていない問題もあります。

後でお話ししますが、Laravelへの移行も道半ばで止まってしまっていますし、やり切れなかった思いが非常にあります。

ほかには、自社サービスをやっている会社には、「こういう自社サービスをやりたいんです」と自社サービス開発に期待を抱いて入社するエンジニアの方がいると思うのですが、そういう期待を抱いているエンジニアからすると、「なんか技術負債の割合、多くない？」みたいな話になって、やりたいことと、やるべきことの間にギャップができてしまったということが振り返っての反省です。

成長期現在は攻めが6、守りが4　事業環境・開発環境でポジティブな変化

今、どうなったかという話をさせてください。今は6：4ぐらいの、攻め・守りのバランスぐらいでやっています。

状況は、非常にポジティブに動いてきているなと個人的には思っています。まず、経営レベルで、うちの代表の金谷（金谷元気氏）が、「note」などで発信してくれているのですが、もっとプロダクトに投資して伸ばしていこうと、社内外に非常に発信してくれています。

そういったところで予算もつけて、意思決定もプロダクト起点でやってというところが進んでいるので、経営環境、事業環境が非常に変わってきたというところが1つ。

あとは、プロダクトのロードマップですね。今までは、積み上げで、「このタスクやらな」とか「ここ直さな」という感じで、目の前のタスクを積み上げてやっていく開発だったのですが、そうではなくて、僕らがどういうプロダクトを将来作りたいのか、そこからの逆算で開発していくようにできたのが今ですね。

あとは、チームも今は非常にいい状態です。バリュー、カルチャーをきちんと共有できて、心理的安全性の高いチームになってきたかなと思っています。

こういった状況に至って、ようやく技術負債にどう取り組んでいくかという地盤ができてきたかなと思っています。

チームも変えました。akippaは、ドライバーがいて、オーナーがいて、いろいろなステークホルダーがいるプロダクトで、今まではakippaというプロダクトに対して、akippaというチームしかなかったのですが、そこを分けました。

攻めと守りという感じで、ドライバー向け、オーナー向けというプロダクトごとにチームを編成して、それぞれにPdM、エンジニア、デザイナーがいるというチーム構成にしています。それぞれがきちんとユーザーに向き合って、意思決定ができる優先度が議論できる環境に変えています。

また、守りの部分も、今までは攻め重視になると守りがおろそかになる感じだったのですが、もうリソースを（守りに）割ってしまって、守りを固めるチームという感じで専任の人たちをアサインしていて、ようやく向き合える状態になってきたかなと思っています。

残された課題と今後の取り組み

ただ、具体的なHowの部分はぜんぜんまだ議論できておらず、古いフレームワークからまだ移行できていなかったり、OSのバージョンアップがちょっとおろそかになってしまっていたり、テストコードがない実装領域がまだまだ残ってしまっていたりなど、あるあるだと思いますが、こういったところがけっこう残っているんですよね。

実は今日の朝も、このへんの領域のせいでシステムトラブルが起こってしまったぐらい、やはり喫緊の課題ではあるので、「どうしていく？」という話があります。

あとは、アーキテクチャそのものから見直そうという話もしています。モノリシックなアーキテクチャで今までやってきたのですが、「マイクロサービス化したほうがいいの？」みたいな、そういった議論もし始めています。

ただ、これらをどういう体制、どういう人たちでいつから始めていくのがいいのかというところは、ちょっと悩んでいるポイントでもあるので、この後のパネルディスカッションの中で、経験豊富な各社CTOの方々にぜひ聞ければと思っています。