MVPをメジャーリリースと呼ぶことをやめた

こんにちは。トレタ VPoEの北川です。

先日、「優先順位が口癖になる危機感」という記事を見かけました。 まさに自分が普段行っていることで同様の危機感を抱えていたたので、非常にささる内容でした。

jinjor-labo.hatenablog.com

要約すると、

• 優先度の高いタスクだけをやっていると、優先度の低いタスクを着手する時期は一生訪れない
• 実装したい機能の最優先部分だけを小さくリリースした場合、残りの機能は実装されず常に及第点の品質となる
• 及第点を取ることを目標として常態化してしまうとUXや内部品質が低下し続ける

自分が携わっているプロダクトもtoBのWebアプリケーションなので、普段のプロセスにとてもあてはまります。 本来の機能をすべて実装するにはリリースが数ヶ月先になってしまうが、要望を貰っている顧客向けであれば最小限の部分が実装できた段階で、制約や制限があったとしても説明した上で提供することができます。

例えば、新しい機能を使う場合に「ここの操作は行わないようにしてください」という制約がある場合に、本来はそこを塞ぐ実装も合わせて必要ですが、一般的なユースケースで起きないのであれば優先度は低くなってしまいます。 他にも、初回の登録作業が大変だが一度登録すれば使える新しい機能といった場合、登録作業の操作性向上のタスクも同時に提供するのが本来は望ましいが、こちらも後回しになってしまいがちです。

そして残りの優先度の低いタスクを取りかかる時点では、次の課題を解消するための、これまた最小スコープに絞った高優先度タスクにシフトしてしまいます。

この問題についての自分なりのアンサーとして、MVP(Most Viable Product)のリリースはメジャーリリースとは呼ばず、βリリースと呼ぶことにしました。

正式リリースとβリリースをわける

あくまでも呼び方を変えただけですが、本来提供したい機能・体験が揃ったものを正式リリースと呼び、それに満たずに一部制約や制限を残した先行リリースをβリリースと呼ぶことにしました。 これは、開発チーム以外のセールスチームやCSチームなども含めた社内認識です。

• ユーザーに提供したい機能やUXが揃った状態を、正式リリースv1.0として定義する
• そこから逆算し、MVPとして最低限の機能を有した初回リリースを、β v0.1とする
• 正式リリースまでに刻んでリリースするものは、β v0.2、β v0.3とする

βリリースとして呼ぶことで、初回リリースはあくまでも正式リリースまでの通過点であり、正式リリースするまでのβの状態は不完全なもの、という認識を持たせます。 不完全であるため、βの途中で後回しにすることは許容されません。

ゴールは正式リリースであり、初回リリースよりも正式リリースまでをいかに早くするかを常に考える必要があります。 ただし正式リリースまでは道が長いので、途中で価値のある単位でリリースを行いフィードバックを早く得るようにします。 この考え方はちょうど先日に新しく定めた開発組織のコアバリューにも通ずるな、と感じたところです。

tech.toreta.in

100点を目指さなければ100点はとれない

これは自論ですが、「１位を目指さなければ１位は取れない」、というのが経験則としてあります。

コンペの話になりますが、１位というのは他よりも勝っていなければならないので、自分たちがなんとなく満足する達成度ではせいぜい２位か３位はとれても１位はとれません。満足した時点が基準点であり、そこから他者と比較して一歩勝つために細部を磨き込むことで１位へと押し上げることができます。

到達品質においても同様の考えで、「100点を目指さなければ100点はとれない」。自分たちが最初に立てた目標通りにやると大体の場合は80点ぐらいになります。経験値の高い人なら90点以上をになることもありますが、基本的には目標よりも低い出来になります。そこからもう一段磨き込むことで100点にやっと届きます。

つまり、80点から残りの20点を埋めて100点にする努力をしない限り、100点にはなりません。 ましてや80点を目指してたまたま100点がとれるなんてことは起きないし、80点にも満たない60点くらいになります。

今回のことで言いたかったのは、ひとまず80点とれればいいや、と考えていては100点に届くことはないし、我々は良いプロダクトを作って自信を持って100点のプロダクトをユーザーに届けたいはず。 最初の出来は80点の荒削りであるとしっかりと認識し、100点にするまで手を抜かない。80点から100点に上げるための筋肉を常に鍛えること。

Next.jsとGoを使っていきます

こんにちは、VPoEの北川です。

今回はトレタで現在使用している技術スタックについて紹介します。

創業時から稼働している予約・顧客台帳サービス「トレタ」から現在の注力事業のモバイルオーダーサービス「トレタO/X」までをあらためて振り返ってみると、まるで異なる技術スタックになっているので歴史的な背景などを辿りながら紹介していきます。

技術スタックの変遷

予約・顧客台帳「トレタ」

会社名にもなっている予約・顧客台帳の「トレタ」は創業当時から稼働している築11年ほどのシステムです。

サーバーサイドにはRubyとRubyOnRailsで作られた巨大なコードベースのAPIサーバーがあり、予約台帳のiOSアプリやウェブ予約などのWebアプリケーションなどが利用しています。 長年このモノリシックなシステムを成長させてきたので、以前からトレタを知ってくださっている人にはトレタはRubyの会社と認知されていたと思います。

インフラは主にAWSを使用しており、EKSでのAPIサーバー群を管理を行い、膨大な予約データをMySQLに保管しています。

超直前予約「トレタNow」

上記の図にはないですが、技術スタックの転機となったのが超直前予約サービスアプリ「トレタNow」です。

これからすぐに行きたいお店が予約できるをコンセプトに超直前予約サービスとして2019年にリリースされましたが、残念ながらリリースのすぐ後にコロナの流行により飲食店予約の需要がなくなり、現在もサービスは縮小中です。

トレタNowでは意欲的に新しい技術要素を取り入れており、gRPCの導入やそれにあわせバックエンドにGoを採用しました。 フロントエンドはtoC向けのモバイルアプリとWeb版を提供し、SwiftやAngularの他にAndroid版としてトレタでは初めてKotlinを使用しました。

モノリスからマイクロサービスへ

モバイルオーダー「トレタO/X」

モバイルオーダー「トレタO/X」の開発は2021年ごろからプロトタイプ開発が行われ、2023年に正式リリースを行いました。

トレタO/Xではマイクロサービスを取り入れたことで、バックエンドの構成は多様になりました。

多くはトレタNowからの流れでGoを使用していますが、比較的薄いAPI層はフロントエンドのメンバーも実装がしやすいNode.jsを使用したり、注文データを扱うサービスにはイミュータブル・データベースのDatomicやClojureを使用しています。

インフラもトレタO/XではGCPを主に使うようになりました。予約台帳「トレタ」の様なモノリシックなサーバーの時はKubernatesを使った管理を行っていましたが、マイクロサービスになったことで一つのサービスはなるべく小さく管理コストの低いフルマネージド型であるCloud RunやCloud SQLを選択するようになりました。

フロントエンドでは、この時期からAngularからReact/Next.jsを採用するようになりました。 それまではAngular日本ユーザー会に参加したりとAngularを支持していましたが、トレンドとしてReactとVue.jsの勢いが増してきたことでAngularのエンジニアの採用に苦戦しはじめたのがきっかけでReactを使用するようになっていきました。 そこからReactやNext.jsのめまぐるしい進化もあり、現在ではフロントエンドにReact/Next.jsを使うことが多くなっています。

また、トレタNowで複数デバイス向けにフロントエンドを開発していた苦労から、クロスプラットフォームであるFlutterを採用しました。 ただ、アプリのマーケット申請の省略などの理由で「Flutter on the Web」のみで開発を開始し、ハードウェア連携などネイティブアプリにする必要性も出なかったため現在もWeb版のみで利用しています。

さいごに

やっとタイトル回収に入りますが、トレタO/Xの開発がそれなりに時間が経ちプロダクト方針や市場状況などが変わってきたところでシステムに求められる構成も変わってきました。

新しいマイクロサービスが必要になったり、逆に不要になってきたシステムのクローズや統合、リプレイスなどを行っていくことになります。

その中で選定する技術の基本軸はフロントエンドならReact/Next.js、バックエンドはGo言語に当面の間はなっていきます。

ということで、React/Next.jsを使って新規開発やシステムリプレイスなどをTypeScriptエンジニアやGoエンジニアの採用を行っているので、興味のある方はぜひ話を聞きにきてみてください。 hrmos.co

業務委託との長く続く良い関係性

こんにちは。トレタでVPoEをしている北川です。

この度、クレスウェア株式会社の奥野賢太郎氏がトレタの技術顧問に就任しました。

corp.toreta.in

トレタに在籍している人にとっては奥野さんが技術顧問になったという話は「今更！？」と感じる人もいるかもしれません。

それだけ奥野さんはトレタで業務委託として長く携わってもらっていますし、実務以上に技術面の啓発や開発カルチャー作りに今までも貢献していただいていました。

今回のことで奥野さんとの関わりが大きく変わることもありませんが、これからトレタの開発組織を強化し、発信を活発にしてく上で、奥野さんとの協力をより一層強くするために今回の発表をさせていただきました。

---

自分と奥野さんとの関わりも5年以上経つので積もる話もたくさんありますが、あまり内輪話を記事にしても仕方がないので、もう少し一般化して「長く活躍いただいている業務委託の特徴」について、自分なりに思う事をこの記事に書こうと思います。

Noを言ってくれる

業務委託と社員の間にはどうしても委託先と委託元という関係性が発生するので、意識しないようにしても接し方に影響がでてしまいます。社員の中でも上司と部下であれば起きますが、業務委託の場合はより色濃い気がします。

その中でも対等の立場で議論が行えて、場合によっては指摘したりNoと言ってくれる方はとても貴重な存在です。 年をとると怒ってくれる人がいなくなる、という話に近い感じがします。

例えば、複雑な設計をしすぎた仕様を提示すると「それYAGNIじゃないですか？」とよく言われます。 将来的な事を詰め込んだり欲張った設計を自分はしがちですが、「パフォーマンス悪くなりますよ」「QAに負担かかりすぎますよ」だったりと論理的、多角的な視点で現実的な指摘をいただけます。

総じて言うと、強い「オピニオン」を持っているという特徴があると思います。それは経験に裏づけされたものかと思いますが、確固たる思想をもち思想が合わない場合には率直に意見をしてくれます。

細かいことでいうと、先日もコードベース上でシングルクオートにするかダブルクオートにするかでプチ議論になりました。 些細なことに見えますがこれは意外と大事な事で、一般会話においても質問に対して「なんでもいいよ」と答える人とは議論が成り立たないわけです（夫婦間でよく怒られるやつ）。 細かいことでも一貫して自らの意見を持ちぶつけてくれる、というのがプロの特徴の一つなのかと思います。

創造性と情熱

対等な議論ができる、というのは関係性がしっかり構築されていないと実際のところ難しいです。 そのため関係性が浅い業務委託の方の場合は、どうしても依頼したことのみを動く人になってしまいがちです。

「世界最高のチーム」 *1 という本の中に、仕事において人に求められる能力の段階として「能力のピラミッド」*2が紹介されており、レベル4の主体性より上に引き上げるためには「心理的安全性」が必要と書かれています。

社内で活躍しているメンバーは社員や業務委託であるか問わず、主体性（課題を見つけすぐに行動する）や創造性（より良いアーキテクチャー、ライブラリへの意識を常に持ち取り入れる）を持ち合わせています。情熱を持ちあわせた強強の人までいくと、経営視点でのサービスの発展性やプロダクト成長の方向性についていっしょに議論ができます。

直近でも今後やりたいプロダクト成長を踏まてNext.jsでPagesRouterからAppRouterへ切り替えたり、デザインシステムの導入を見越してTailwindCSSの導入を行いました。どちらも最初にメンバーから提案をいただき、迅速に対応いただきました。

新しく入るメンバー含め全員が同じような主体性や創造力をもって仕事するために「心理的安全性」を作れるかは、開発文化の醸成を行なっていくVPoEになった自分のこれからの任務だと考えています。そしてそれをサポートいただく強力なパートナーとして、今回の技術顧問の発表を行なったという背景です。

さいごに

トレタではエンジニア採用を積極的に行なっています。

奥野さんとガッツリとモブプロしたり、手厳しいレビューを受けて揉まれたいエンジニアはぜひ応募してみてください！ hrmos.co

*1:「世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法」 ピョートル・フェリークス・グジバ (著)

*2:「経営は何をすべきか」ゲイリー・ハメル(著)