10Xで5年働いてきて学んだこと

by

@wapa5pow

入社したのが2017年11月だったので今月で5年間になります。いままででこんなに長く同じ会社で働いた事はなく長く働き続けられているのはひとえに10Xで働くのが楽しいからだと思っています。いろんなことがありましたがその時々であったこと学んだことを書いていきます。
10Xがサービスをリリースしていないときのまさに0.1くらいのときからいるのでいろいろ参考になるかもしれません。

そもそも10Xはどんな会社か

/assets/2022-11-08--why-10x-is-fun/history.png

いまはStailerという小売チェーンのECを垂直立ち上げするプラットフォームを作っています。スーパーなどの小売様がStailerを導入することによりWeb・アプリに対応したネットスーパーを立ち上げる事ができます。

Stailerを始める前にタベリーといういまはクローズした献立推薦アプリを作っていました。Stailerはタベリーで提供していた注文機能を切り出してそれぞれの小売様向けのアプリとして提供したものです。ここで初期のアイデアだったタベリーからピボットしています。

それではいろいろ書いていきましょうかね。

よもやま話

数人のスタートアップは自分でサービスを構築する力がつく

サービスをリリースするための一切を、その場にいるメンバーでこなさなければならないので自然といろいろなことをやらなければいけません。最初のサービスのタベリーのときは、自分が入る前に技術スタックはクライアント(リリース時はiOS(Swift)のみ)、サーバ(Go)、インフラ(GKE)というのがざっくり決まっていたのでそれをどのように実現していくか模索しました。

サーバサイドとかインフラはやったことありましたがGo, GKEは初めて扱ったので最初は苦労しました。GKEは当時は資料がすくないので公式ドキュメントをあさりながら自分のやりたいことを実際に別プロジェクトのGKEに構築したり壊したりしてなんども実験していました。うまくいきそうなら実際にプロダクションコードに落としました。その他にCloud Endpointsなど癖のあるものを導入していたのでこれまたドキュメントが少なく結局ソースコードをみて解決するみたいなことが何度もありました。いままでは使っているもののコードをみることはあまりなかったのですがコードまで検索できるようになると隠れたオプションやなぜそうなっているかわかって問題解決がより早くなりました。

クライアントは少しはやったことありましたがiOSがすごく得意なCTOの石川さんがいたので多くのことを教わりながらやっていて贅沢な環境でした。オートレイアウト周り、RxSwift周りなど知ってはいるけどしっかりつかったことがない技術を実装したりレビューされたりしてクライアント力が伸びた実感があります。結構キレッキレなレビューが返ってきてときどき戦慄しながらやってきてほどよい緊張感をもっていました。10Xは最初からエンジニアが機能を実装するためにあらゆることをする文化があります。最初はクライアントの思想や概念がわからず特にUIと処理の書き方・考え方で苦労しましたがやってみればなんとかなるものです。

このころの楽しさというのは、実現させたいサービスに向けて無いパーツを必死に作っている事だったなと思います。早く作りたいのでどんどん調べてどんどん作ってリリースしていました。こういう作りたいサービスがあってそれを0から作られるという環境は結構まれなのでありがたいことです。0から作るといろんな事を決めなければいけなくて、かつ絵に書いた餅を実装しなければいけないので力がつきます。人の性格にもよりますがサービスを作れるようになりたい人はこういうサービスを作るか作らないかのスタートアップで自分で主導してサービスを作れる場所に行くことをおすすめしています。もうひとつよいのは個人開発のサービスを作ってみることですね。いまでもSlackアプリなど作って、その経験を本業で活かしたりしています

どの技術を選ぶかは何を解決したくてその技術で解決できるかが重要

技術自体もなんとなく流行りに乗っていたわけではなくて明確に解決したい問題があってそれを解決できる技術を選んでいました。例えばサーバクライアント間通信はgRPCを選択しましたが、型のないAPIを呼ぶのが辛い問題やサーバを呼ぶためのクライアントのコード実装だるいみたいな問題をgRPCは解決してくれます。安全にリファクタできるしIDEで型チェックをしてくれて生産性が高いのでGoを選んだり各種理由があったりします。まあそのおかげで、選択したもので新たな問題もうまれてきていますがなんとか解決できている気はします。

なにか大きな意思決定をするときはロジックやロジックの開示が大事

作るだけでなく機能を結構クローズしてました。とある機能をクローズするときもCEOの矢本さんがしっかり考えてどうしてそのように考えたかを共有しているので納得感がありました。10Xは最初からドキュメントに残す文化がありました(Design Docのような技術的なものはあまり残していなかったのでそこは反省があります)。情報がオープンにされ、判断する価値基準が示されているなら、ほとんどの人が同じように論理的に考えれば同じ結論にいくので自分としては納得感がありました。急な意思決定で問題になるのは私は聞いてないなど情報をもらってないパターンが多いと思います。トップが決定したことをなぜ決定したか論理的に文章で説明できかつ開示することにより多くのハレーションが防げている気がします

最初のメンバのやり方が脈々と他のメンバに波及する

エンジニア中心ですがメンバもちょっとづつ入ってきてチーム感がでてきました。機能別に担当エンジニアが作るという方式だったので他と干渉することなくもくもくスタイルでどんどん開発します。このスタイルは最初からそうなっておりとくに誰かが口をはさむでもなくそのままスタイルが引き継がれていきました。この機能別に個人が作るというのはいい面も悪い面もありました。

いい面としてはとりあえず早くできます。10Xメンバは機能をつくるためにクライアントもサーバもやるという雰囲気でした。ときには分担しますが１つの機能を非常にすくない人数でつくっていきます。

悪い面としては実装知識が、実装するメンバに偏ります。その機能はその人しかしらないということが起きます。そうすると質問や障害対応がその人に集中してだんだん疲弊してきます。
さらに、実装のクオリティが実装する人に依存してしまいます。うんうんうなりながらどのような実装をしようか考えるのですが1人の知識なんてものはたかがしれているし考えている時は視野がせまくなっていたりします。

じゃあどうするとよかったかという話ですが、機能の仕様をもとにDesign Docを書きそこからタスクに落とします。そのタスクをチームのメンバが全員消化するという形にすると知識が横展開できてよかったのではないかと思います。多数の目と手で実装を行うことは非常に意義があると今は感じています。

新しいメンバは改革の源

こうやってかつてのやり方で開発していたものに対してこれおかしいのではといえるのは新しい視点をもっている新規メンバのちからが大きいです。先程の1つの機能を1人で開発するというやり方に対し、新しいメンバからの提案によりDesign Docが導入されたり、既存のメンバでも風を感じスクラム開発が導入されたりとチーム開発が定着していきました。

既存のメンバは常にいまのやり方が正しいのか、他のチーム・会社ではどのようなやり方をしているのか。いまのやり方のメリット・デメリットはなにかなど考えていかなければなりません。

逆に新規メンバはそのチーム・会社のやり方に染まるのではなくどうしてそのやり方をやっているのか、もっといいやり方はあるのかなど新しい視点を持ち込まなければなりません。新規メンバはどうしても、郷に入っては郷に従え的な感じになってしまいますがフラットな視点できにせずどんどん提案していくとチーム・会社全体がよくなると思っています。

サービスはなくなっても技術はなくならない

2020年中頃にStailerに集中してタベリーがクローズすることが決まります。Stailerを始める時点でどのような技術スタックにするか決めたのですがフロントエンドはFlutter/Dart、サーバサイドもDart、インフラ(GKE)になりました。クライアントでFlutter/Dartにしたのはこれから作るStailerはiOS/Androidで大きくネイティブの機能を使う開発は多くはないので共通コードにしたほうが開発速度が早くなる、プロトタイプ時に十分iOS/AndroidのUIにたえれる実装ができることが検証できたなどが理由でした。サーバでDartを使う選択肢になったのはチームがクライアントもサーバもやるメンバが多かったこともあり共通の言語にしたほうが生産性が高い、型がついている、サーバサイドDartは未知の事がたくさんあるがいまいるチームメンバならのりこえられるだろうということが理由でした。ここらへんのことは10Xのブログ記事で書いてあります。

一見攻めているクライアント・サーバサイドどちらもDartという構成ですが実はそれ以外の構成はほとんどタベリーのときと同じ技術スタックです。GKEやgRPC、GCPで使用しているサービスなどほとんど変わりません。すべて攻めるのではなく一部必要なところだけ攻めたことにより大きな不確実性を生むことなくサービスをリリースできました。サービスは閉じてもそれまで積み上げた技術はなくならなかったのです。

採用技術を決める前にプロトタイプを行う

技術スタックを決めるということは一方通行の道だったりします。完全な一方通行ではないにせよ引き返したり違う道にいったりするのに大きな時間や人的リソースがいります。このような大きな決断をする前に10Xではプロトタイプを作っていました。Flutterに決めるときはFlutterで実際のiOSの画面を組んでみて動くかどうか確認したり、サーバサイドDartではクライアントと繋げれるか確認するために軽いサーバを作ったり、Firestoreと繋げれるライブラリを実装して使えるレベルかどうか確認してたりしました。ここらへんは馬力のあるCTOが大きく役割を果たしました。なにかの技術スタックを決める前に広く試してみるのはその後の不確実性をへらすためのいい一歩です。

BtoBのすすめかた

Stailerはネットスーパーが立ち上げれます。ネットスーパーを立ち上げるということはお客様の注文から店舗で商品をピッキング・パッキングして配送してお届けするという一連の作業がStailerでできるということです。筆者はいままでtoCのアプリしか経験がなかったのですがこの作業をシステムで実装するにあたり様々な違いを知ります。toBの場合、理想とする業務フローを描いてそれをシステムと現場の動作に落としていきます。実際につくったら現場に行き考えて作ったシステムが現場で使えるか見ます。現場では必ずギャップがあるのでそれを再度システムで解決したり運用で解決したりするのか検討します。想像して作っただけではぜんぜん使えるレベルにはならなくて密に現場に入り込みます。ここらへんがtoCとまったく違っていました。

もうひとつはシステムを高いレベルで安定稼働させないといけないということです。語弊があるかもしれませんがtoCのときは多少動かないところがあってもなんとかはなるのですがtoBの場合は現場がとまって損害がでるので安定稼働がとても大切です。

一連の開発を通じてtoBのやり方を学び意識が相当かわりました。

採用は面白い

筆者は10Xで採用にもかかわっています。採用は候補者の入社までの体験を作っていくプロセスだと思っています。採用というと候補者を会社が選択するというイメージがあるかもしれませんがそうではなく、候補者と会社のお互いのマッチングを確かめる場です。

会社は採用したい人物がどのような人なら採用したいかを定義し、それに合うかどうかを確認するプロセスを組みます。
候補者はそのプロセスの中でその会社は働きたい会社なのかを見極めます。会社はプロセス自体にその見極めるための材料を提供できるようにします。

もう1つ要素があって面接官である社内メンバへのプロセスの周知の大切さです。いくらプロセスを整えてもメンバが内容を熟知していないと上手に回っていきません。

採用は採用した人がさらなる新しい人を呼び寄せる効果もあります。あの人が入ったから興味をもったとか、入ってもいいと思ったとか何回も聞きました。
会社のステージによっても入ってくれる人が違います。人にはリスク許容度みたいのがあって小さい会社なら入らないけどやや安定したところなら自分のちからを発揮できると思ってくれる人がいます。小さいころには声をかけて断られたけど継続的にかけていくことにより再度つながったりします。ここらへん人間模様で楽しいですね。

もはや採用は1つのプロダクトくらいの大変さと面白みがあります。

いろいろ出てくる弊害

まあこんなかんなで採用もすすみメンバも増えるわけですがいままでのやり方というものに弊害が出てきます。

前述もしましたが1人1機能で実装していたので素早くリリースできたのはいいのですが知識が人に偏ってきます。

またStailerという大きな1つの機能としてサーバのコードを実装してきたので機能ごとにコードがいい感じに分かれているわけではありません。これによって例えば注文の機能をちょっと修正しようとしただけなのに様々なところにコードが絡み合っていて確認コストが大きくなり開発速度が遅くなってしまいます。QAを外部でやったりしてお金を投資すれば最初はなんとかなりますがそのままいくとどんどんまた複雑になるのでどこかでメスを入れる必要があります。それはドメインの境界をきって機能ごとにコードベースを分けていく道だったりします。10Xではまだ途中ですが初期に考えておけばもうちょっと違ったかなと思っています（ただ、初期は初期で非常にやることがあったのでこの動きができるかどうか、必要と認識しているかどうかは難しいところではあります）。

振り返ってやれることがあるとすればサービスをいろいろ作るときにドメイン境界を意識した設計をチームで話し合いまずDesign Docベースで共有することでしょうか。実装はコストが高いですがDesign Docはそこまで高くないのでそれでいける気もしますがちょうちょい仕組み化して解決したいところです(実際に開発ライフサイクルという形で改善が社内で走っています)。

組織もプロダクト同様に進化する

会社として大きくなると組織も進化する必要があります。数人でやっていたときといまのように100人ほどになってきたときでは組織のあり方も相当違います。大きな人数でも耐えられる組織としての箱と、組織が正しい方向へ向かうための目標や評価制度が大事になってきます。10Xでも大きくかわったばかりなのでどうなるかは今後次第です。1つ言えるのは変化に向かい続けて自身や組織を最適化し続ける必要があるということです。

最初からいるメンバと新しく入るメンバの気持ちの違い

会社に最初からいるのと新しく入るのではメンタルモデルが大きく違う事に気づきました。はじめからいるといままでのすべての流れをしっているので事を動かしやすいです。メンバとの関係もできているので気軽に話しかけれるしそれまで書いているドキュメントをみていれば考えていることもだいたいわかったりします。

一方で、自分が以前いた会社に入社したときはどうだったろうと考えると会社の仕組みがわからないし、知っている人はいないし、技術的なこともわからないしなんだか非常に認知負荷がたかかったです。あと後からはいったのだから郷に従え的な感じでとりあえずルールや会社に馴染もうとしていたのを思い出します。

既存メンバが、新規メンバが入ってやりやすくするためできることとしては、会社やサービスを知るオンボードをしっかり整えたり、新規メンバが馴染みやすくなるように整えたり、既存の仕組みになんでも発言できる雰囲気を整えたりいろいろな事ができると思います(10Xはある程度整えてはいると思いますがまだまだ改善余地ありです)。

新規メンバは既存の仕組みがおかしいと思ったり改善できると思ったら遠慮せず行動するのが会社やサービスのためになるのではと思っています。現に以前の既存メンバが外部からアドバイスを得られればうまくいったかもみたいなところはたくさんあるので忌憚なき意見を！という気持ちです。

これから目指しているところ

Stailerはまだまだ実装するべきことが多くこれからが楽しみです。Stailerがカバーできる機能を広げつつ、その機能をスケールする形で実装でき、Stailerを使ってくれる小売様へ価値が提供でき、お客様に喜んでもらえるようにしたいと思っています。

抽象度高すぎですがようするに気持ちよく開発したいということです。何か開発するときに既存のこんがらがった実装に悩まされないように適切に境界を区切ったり面倒なことを素早くできたりそもそもやらなくていいように仕組み化したりしていきたいですね。

10Xに興味をもってくれた方へ

FlutterKaigiで弊社の開発の歴史をかたってくれる発表があります。社内発表で事前に聞いたのですがすごく面白かったので興味ある方はぜひ。

以下の発表も10Xのメンバなのでぜひぜひ。

ぜひ10Xに応募してみたいという方はこちらから。

長々とありがとうございました。