この記事は Gunosy Advent Calendar 2019 の18日目の記事です。
前回の記事は@mageyuki さんの ワークフロー基盤としてのEKSクラスター運用のポイントとEKS on Fargate検証 - Gunosy Tech Blog です。
はじめに
こんにちは。広告技術部でエンジニアをやっている @mocyuto です。 最近は荷物運び*1 と丸い輪っかの筋トレ*2を交互と行っています。
今回はGunosyのように自社で新しいサービスを作る上で考えて実践していることを共有したいと思います。
特にエンジニアサイドとしてどのような視点で考えているのかを以下の軸で話そうと思います。
- どうやって作るか
- どこまで作り込むか
どうやって作るか
みなさんは新しくサービスを設計する上でどこまで考えているでしょうか？
リーン・スタートアップなどはご存知だと思います。 リーンキャンバスだったり、MVPだったりの単語がよく聞かれますが、本質は「仮説構築 → 実験 → 学び → 意思決定」のサイクルを回し、顧客がほしいものへとプロダクトを育て上げていくプロセスです。
Gunosyでも（明示的にリーンとは言っていませんが）上記のようなサイクルを回して開発を行っています。
では具体的にプロダクト開発を始める上でどのようなことを行っているかを紹介します。
インセプションデッキ
まずプロダクトの開発に入る前にチームでインセプションデッキを作ります。 インセプションデッキとは、プロダクトの核となるものは何なのかをチーム内で共有するドキュメントになります。
インセプションデッキを作成することで、機能開発の優先順位や作らないものの決定がしやすくなります。
テンプレートとしては、アジャイルサムライのインセプションデッキを使っています。
よくありがちなのが、「こういうものを作ろう！」と口頭だけの共有で終わってしまう場合ですが、人間の記憶は案外簡単にネジ曲がってしまうので、認識のズレがかんたんに発生してしまいます。 しかし、このようにインセプションデッキを作ることによって、明示的に共通の認識を作ることができます。
社内のGoogleDriveを「インセプションデッキ」と検索すると、いろんなチームのインセプションデッキを見ることができ参考になります。
フェーズ分け
特に新規のプロダクトでは顕著だと思いますが、どこまで作るかという問題に悩まされると思います。 そこでよく用いるのがフェーズ分けです。 「一旦ここまで作ろう！」というフェーズを作成し、そこまでをやりきって次のフェーズに取り掛かるというやり方です。
このやり方は最終的なゴールを設定し、そのゴールに到達するまでのマイルストーンを引くことで、そのゴールにずれていないかというのを確認しながら動けます。 フェーズが終わるたびに振り返り、終わったフェーズが間違っていないか、次のフェーズの方向性が間違っていないかを確認することで軌道修正していきます。 アジャイル開発と相性がいいやり方です。
どうやってフェーズ分けをするかは「どこまで作り込むか？」の章で記載します。
工数見積
新規プロジェクトの場合は、始める前に工数見積を行うことが多いです。
まず前提として、普段のチーム開発で回しているスプリントではタスクのポイント見積もりを行っています。
ポイント見積もりを行っている理由としては、チーム内でタスクに対する工数の見積もりを共通化するためです。 ポイント見積もりを導入し始めたときは見積もり自体になかなか時間がかかっていましたが、現在はチームでの認識があってきているためスピードはかなり上がっています。
また現在チームでは、多少の偏りはあれどチーム内で管理しているプロダクトはみんなで実装するという方針をとっているため、だいたいのタスクにおいてチームみんながポイントを予想することができています。
このタスクに対して定量的なポイントを割り当て、実際にこのプロジェクトがどれくらいかかるのかをざっくり算出します。 もちろん、市場環境の変化や技術的な困難などでずれ込むことはあるのですが、最初に見積もったポイントからどれくらいずれているかを把握しながら開発を進めることができます。
このように開発することで大きな遅延もなく開発ができています。
どこまで作り込むか
新規プロダクトの場合、どこまで作り込むかもやはり新規サービスを作る上で悩むポイントだと思います。 なぜなら、開発スピードと機能の完成度はトレードオフだからです。
ではどこを判断の起点にするのでしょうか？
すでにインセプションデッキを作られ、チーム内の認識は統一しゴールは明確になっています。
どこまで作り込むのかを決める基準は、どこまで作ったら顧客に開放するのか？という観点になると思います。
フェーズ分けをする際に、顧客に提供する段階のフェーズは以下の観点で分けています。
- 仮説を検証できるか
- 障害、セキュリティに耐えうるか
- 技術的チャレンジをいれるかどうか
仮説を検証できるか？
よく一旦出してみようよという誘惑があると思いますが、果たしてそれは一旦出してしまっていいのでしょうか？ 物理の商品ではなく、Webサービスの場合すぐに修正ができるため、そのようなことをしがちだと思います。 しかし、「プロダクトを出す＝顧客に価値を与え、使ってもらう」ことが重要であり、それに繋がらないのであれば、あまり意味がありません。
ウォータフォールのように完全な完成状態で出すのでなければ、
- まず何を検証するのか？
- その検証項目は検証できる状況にあるのか？
という点がクリアになっている状態で世の中に出すべきだと思っており、そのような視点で開発を行っています。
ではどうやって仮説検証をしているかというのは、以下の記事を見てもらえればと思います。 tech.gunosy.io
障害、セキュリティに耐えうるか
障害の対応のしやすさ、セキュリティ上の問題はサービスの土台になるため、なかなか変更ができません。 なので、フェーズを分けてリリースするにしても必ず
- どこが障害ポイントなのか
- 障害が発生したときどう対応するのか？
を洗い出し、その課題を考えて潰してから作っています。
技術的挑戦
いくらプロダクトを早く出すと言っても、やはりエンジニアとして技術的挑戦がないと面白さがなくなってしまうので、技術的挑戦はいれるようにしています。 もちろん技術的挑戦に関しては、チームメンバーのモチベーションありきで導入しているため、メンバーの興味が強いところに新規技術を投入することが多いです。
技術的挑戦に関して上記のポイント見積もりでもやはりあやふやになってしまうので、何でもかんでも盛り込むのではなく、
- 挑戦を１〜２個にする
- 既存の技術で作りつつ、少し時間が空いたタイミングで新規技術を混ぜ込む
などの方法で進めています。
また、前年のAdventCalendarで弊社CTOが語っているように、ただ使ってみたいからという理由よりは、合理的な理由をちゃんと説明できるか？を重視しています。
まとめ
今回は新しくサービスを立ち上げる際に考え実践していることを書きました。
本などを読めば、このような実践方法は書いてあると思いますが、実際に行動に移すことはできているでしょうか？
新しくサービスを作ること自体、なかなか経験しづらいことではあります。しかし、立ち上げだけでなく、新しい機能を作るという場合でも同じような仮説をベースに計画を立て、仮説検証のイテレーションを回しています。
Gunosyでは文化として、仮説検証が根付いています。 このように新しいサービスを一緒に立ち上げてくれる人、もしくはもっといい形でサービスを立ち上げたい人、募集中です。
