最新情報をお届けします！
ゼロイチのスタートアップでは、早くPDCAをまわし、プロダクト開発することが重要。iOSエンジニアとして多くの実績を残してきたソフトウェアエンジニア 石川 洋資さん。開発速度を重視した「戦略」こそがプロダクト成功のカギだと語る。
以前、CAREER HACKで取材した献立アプリ「タベリー」。開発プロセスにおいて、こういった話が聞けた。
「3ヶ月で300回以上のiOSのプロダクト改善を実行した」
1週間に約25回のビルドを行なう計算だ。一体どうやって高速開発を実現したのか。「タベリー」運用元の10X CTOの石川洋資さんは開発速度を出すための「戦略」が鍵だと語る。「タベリー」立ち上げ時の開発戦略に迫った。
[プロフィール]石川 洋資 (@_ishkawa) | 10X inc. Co-Founder, CTO
面白法人カヤック、LINEでの複数の新規事業開発を経て、メルカリ/ソウゾウへ。 メルカリ/ソウゾウではプリンシパルエンジニアを務める。オープンソースプロジェクトへの参加や執筆活動も行っており、2017/2には「Swift実践入門」を出版。
「大学卒業後、カヤック、LINE、メルカリで新規事業の立ち上げを経験した後に、メルカリの同僚だった矢本さんと会社をつくることに。モノをどのようにつくるかも重要だが、それ以前に何をつくるかが重要だと痛感していたところで、一緒に答えに辿り着けそうな人に誘ってもらえたのが起業を決意したきっかけ」
プロダクトが人の役に立つものになるかどうかは、実際に人が使ってみるまでわからない。そんな状況を考慮して、「タベリー」開発チームは実際のアプリと同等のクオリティのプロトタイプでユーザビリティテストを行うことに決めた。
「ぼくらは今までにない新しいものをつくろうとしていたので、とにかく早くユーザビリティテストに持っていくことが重要だと考えていました。なので、立ち上げ時にはUIを早くつくることにフォーカスしました。そして、本物に近いフィードバックを得るために、プロトタイプを実際のアプリとしてつくることを選びました」
石川さんは、ユーザビリティテストから得たフィードバックを高速に反映するため、iOSアプリのUIの開発に専念。サーバーサイドの開発には一切手をつけなかったという。300回という膨大な回数の作り直しは、こうした戦略的なリソース配分によって実現された。
「普通はサーバーサイドで行うようなロジックも、すべてiOSアプリ側に寄せて開発していました。データベースも画像もすべてiOSアプリに組み込んでいました。なので、アプリのサイズは200MBくらいになっていて...(笑)代わりに、読み込み時間ゼロの高速なアプリで検証ができるという思わぬメリットもありました」
iOSアプリとサーバーのプログラムの更新頻度
iOSアプリの開発が落ち着いたタイミングでサーバーに着手していることがわかる
また、「早くユーザビリティテストに辿り着くことが重要」という認識がチーム全員で揃っていたからこそ、このような戦略が取れた。
300回の作り直しを経てリリースされたタベリーは、現在は週1回のアップデートで継続的に改善がされている。1週間というリリースサイクルは、小回りを効かせることを意図したものだ。
「1週間もあればそこそこ大きな機能も入れられますし、開発進行の不確実性も手頃なサイズに抑えられます。タベリーは、まだまだあるべきプロダクト像を模索している段階なので、早くユーザーに届けて細かくフィードバックを受けなければならないんです」
ユーザーから得られたフィードバックは、ユーザビリティテストから得られた定性的なものもあれば、データ分析から得られた定量的なものもある。どのような形であれ、事実を突きつけられることがプロダクトの前進に繋がるのだと石川さんは言う。
「1度頭で『こうだ！』と思ったことって、なかなか変えられないんです。ところが、ユーザビリティテストやデータ分析によって、そうではないという事実を突きつけられると、途端に考えが変えられるんですよね。そうすると、新たな視点を持って次のことに取り組める。これを繰り返せば、あるべきプロダクトの形に近づけると思います」
こうして得られたフィードバックは、プロダクトをどう変えるべきかの示唆を与えてくれるだけでなく、開発チームの士気や開発効率にも良い影響を与えてくれる。
「プロダクトの変更のきっかけとなった事実をチームの全員が知っていると、これはやるしかないなという気持ちになれます。何かを決めるときには同じ前提に立って議論が進められるので効率が良いです。逆に、それを知らなければ、変更の必然性がわからずに、面倒だと感じてしまうこともあるかもしれません」
コミュニケーションの円滑さも開発のスピードに影響する。タベリー開発チームのSlackがこれだ。
基本的には、#general だけを使用。channelをここまで絞っているのには、必要性が生じるまではシンプルさを保ちたいとの意図があるようだ。1つのchannelだけで足りているのは、チームのコミュニケーションの仕方に合わせた結果なのだとか。
「まだまだ議論がすごく重要な段階なので、Slackの利用は最小限にしています。1つメッセージを送った時に何が伝わっていて何が伝わっていないかを察するのって難しいじゃないですか。そういうところで生まれる小さな誤解も今はなるべく避けたい。みんながいる時間に対面で話すことにしています。」
もちろん、チームのコミュニケーションの姿が変われば、channelの構成もそれに合わせて変わっていくだろう。
対面のコミュニケーションを重視したのは、チームが向かうべきゴールを共有することを第一として、コミュニケーションの取り方を模索した結果なのだと石川さんは言う。
「言語化できていない曖昧な感覚ってあるじゃないですか。例えば、この仕様良いんだけど良くないんだよみたいな。そういう感覚はチームで言語化して共有すべきだと思います。しかしそれには細かく軌道修正しながら議論を進める必要があって、チャット上でやるのはかなり難しいと感じています。そういう事情もあって、今は対面で話すことを重視しています。」
続いて、技術選定について。ゼロイチのスタートアップであることを踏まえて、以下の2点を重視した。
・少人数チームでも作り切れること
・大幅な変更が続いても耐えられること
プログラミング言語の選択や外部システムの導入など、様々な選択をしたが、中でも大きな決断となったのは「gRPC」の採用だ。gRPCとはGoogleが開発する通信フレームワークで、HTTP/2を活用したハイパフォーマンス性や、Protocol Buffersによる各言語のコードの自動生成が特徴だ。石川さんはProtocol Buffersによるコードの自動生成に着目した。
「サーバーとiOSとAndroidとWebの4つでやりとりされるデータの定義を一元化したい、と言うのが最初の動機でした」
また、検討を進める中で、他の問題の解消にも役立つことに気づいた。
「スタートアップなので、プロダクトが成功するまでは大きな変更がずっと続くわけじゃないですか。それに追随するのはコストも掛かりますし、その過程でミスも起きると思います。こうした変更のデメリットを、コードの自動生成とコンパイル時の検証という仕組みで緩和できるというのが、最大の動機になりました」
プロダクトの仕様変更は、開発の遅れやプログラムの不具合の原因にもなりかねない。しかし、ゼロイチのスタートアップが成功するプロダクトをつくるために仕様変更は必要なこと。仕様変更を受け入れやすい基盤を選んだことは、プロダクトの将来を左右する意思決定となったに違いない。
gRPCはまだまだ新しい技術であり、事例もまだそれほど多くはないため、導入に手間取って初期コストが高くついてしまうという懸念もあった。しかし、初期コストを多めに払ってでも中長期のコストを小さくしたかったというのが、石川さんが採用に踏み切った理由だ。
「こういう大きな決断は新規プロダクトじゃないとできないこと。だからこそ大胆に決断をしました」
最後に伺えたのが、こういったゼロイチでのプロダクト開発に向いているエンジニアについて。石川さんいわく課題解決志向をもつエンジニアであるかどうかが1つの目安となる。
「向いているのはプロダクトを作りたいという想いを持っている人。プロダクトが実現するものが1番重要だと捉え、あらゆる手段を実行できる人は強いなと思います。個人的には、コードを書くことは手段のひとつだと捉えています」
この話をすると、きれいなコードと開発速度をどちらを優先するか論になりがちだが、そうではないという。
「きれいなコードか、開発速度か。決して二元論ではありません。きれいなコードを書くことは、開発速度をだすための手段。長期的に開発速度を保つことやミスを防ぐために、きれいなコードをうまく活用する。どう活用していくかがプロダクト開発の戦略です」
また、1つのスキルに特化したエンジニアより、幅広いスキルを持ち合わせたエンジニアのほうが活躍の可能性が高いと考える。
「スキルが1つしかないと、どうしてもそのなかで最適解を導き出そうとしてしまう。スキルの幅が広ければ、あらゆる選択肢の中からプロダクトにとって最も良い方法を選べます。理想は、それぞれのエンジニアが問題解決のためのあらゆる手立てを自ら組み立てられるチーム。小規模で筋肉質な組織を作っていきたいです」
文 ＝ 大塚康平
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
