スマートキャンプでエンジニアをやっております永井です。
若葉の緑が目にしみる季節となりましたが、皆さまいかがお過ごしでしょうか。
この度4/20にSaaS特化型Q&Aサイト「BOXIL SaaS質問箱」のβ版を公開しました。
SaaSの選定をはじめ、そもそも何をすれば良いか分からずお困りの方はご質問の投稿お待ちしております。
いきなり宣伝からはじめてしまいましたが、今回はこのプロダクトの開発で色々試したことがあるので、それを「開発前編」と「開発中編」に分けてご紹介します。
私は今回のPJではPMと開発を半々でやっていました。ちなみにPMっぽいことははじめての経験です。
開発前編
初期
開発初期段階の状態はこのような状態でした。
- 開発陣（エンジニア, デザイナー）が参画時は要件がある程度決まった状態
- POが作成したワイヤーフレームは作成済み
- 納期はざっくりと指定（2ヶ月位）
- まずMVP(Minimum Viable Product)を出すため後回しにする機能を見極める必要がある
問題点
問題としてまず上がったのが、「このPJでやりたいことの背景を開発陣が知らなさすぎる」というものでした。
当初MVPをまず作るべく、削れそうな部分を話し合っていましたが削って良いところかの判断がつきません。ワイヤーフレームというUIベースでのお話がメインとなっていたので、ミクロ視点での話になることも多く、「なんでこれやってんだっけ」という状態になることもしばしばありました。
すでに見た目の草案も出来上がっているため、デザイン作業を進めるときにもワイヤーフレームに引っ張られ、デザイナーがデザイナーとしての本領発揮ができないことも考えられました。
やったこと
このままではかなり受け身な状態で開発が進み、成果物がぶれ手戻りや修正などにより納期に間に合わない可能性がありました。
そこでメンバーと相談の末このサービスはどういったもので、どうやって大きくなっていくか、またそのために必要な要素は何かをあらためて開発に携わる人全員で話すことにしました。
その時実施したのが「グロースサイクル図の作成」と「OOUIの図の作成」です。
グロースサイクル図の作成
グロースサイクルとはプロダクトの成長を定義した循環モデルのことです。
詳しくは以下記事を参照してください。
解説のために（大分）簡略化したサンプルを用意しました。
色々端折っていますが、質問が増える→回答が増える→見る人が増える→質問が増える→……という事を繰り返してサービスを大きくしていこうね、という考えを図示したものです。いわばこのサイクルがサービスの芯の部分となります。
これを皆で話しながら作ることで、その後のMVPの策定や優先順位付けがとても楽になりました。上の図でいうと「これは質問が増える施策からは離れてるので、MVPからは外しても良さそうですよね」みたいな話ができます。
OOUI
OOUIとはざっくり言うとオブジェクト（もの、名詞）を中心にUIを設計する考え方です。
詳しくは弊社デザイナーの柿澤の記事を参照ください。
サービスの要素をオブジェクトで分解することはエンジニアがクラス図を考えるときと似ているため、デザインをエンジニアも含めて皆で考えるという新鮮なことができました。
サンプルとして、BOXIL SaaS質問箱におけるモデルの一部をお見せしますが、オブジェクト・プロパティ・アクションとほぼクラス図のような定義だと伝わるかと思います。
その後のUIデザイン自体はデザイナーにお任せしましたが、どういう要素があってどのような背景からこの遷移になったのか、という事が共通認識として得られたのでその後の開発に良い影響を与えたと思います。
あとは純粋にパズルみたいで楽しいです。今回ご紹介したBOXIL SaaS質問箱の場合、「質問への回答はどういう遷移、見せ方が良いか」みたいな話ができるのは新鮮でした。
開発編
開発は基本的にはスクラム開発をベースに進めました。エンジニアは私ともう二人（フロント, サーバー1名ずつ）の計三名です。
色々試したことを列挙するので、参考になれば幸いです。
朝会
週3で30分程開発陣以外も含めたチーム全体でのオンライン朝会を開きました。
主に進捗報告と仕様の相談が目的でしたが、初対面のメンバーもいてなおかつテレワークだったため良い交流の場としても機能していたように思います。
タスク管理
タスク管理はAsanaを使い、ストーリーベースで管理しました。「○○のAPIを作る」より「ユーザーが質問投稿できる」というチケットの方がメンバーに共有しやすく、POへの共有・確認もしやすいと考えたためです。
ユーザーストーリーについては以下の記事で詳しく解説しています。
朝会で口頭のみで話したことは極力チケットに残すようにし、漏れないように務めました。「とりあえずAsanaを見ておけばOK」という状態に近づけました。
見積もり
見積もりはTシャツのサイズ（S,M,L）を使用しました。これは数値での厳密な見積もりより素早く共通認識を取るためです。結成したてのチームで見積もりの精度も未知数だったため、まずはざっくりと見積もることで勝手を知る狙いもありました。
ざっくりと付けられる割には、想定したサイズがメンバー感で異なることで話が進展したりと想定以上に機能したように思います。
Tシャツ見積もりについては以下を参照ください。
ブランチ戦略
今回の開発環境は1つのレポジトリで管理されている環境（モノレポ）に追加で作る要領で開発を進めました。
モノレポ環境に大きな機能（あるいは新ページ）を開発する際によくあるのが「超特大ブランチ出現問題」だと思います。経験上コンフリクトの解決などの手間が増えあまり良い開発体験にならないと思ったので、できた機能からリリースブランチにマージ後にリリースする方針にしました。権限で分岐し、一般公開はしないようにしてこれを実現しました。
詳しくはこちらの記事で解説されています。
このおかげでリリース日も最後の非公開の設定を外した小さなPRをマージしてデプロイするだけで済んだので、リリース作業中に祈る時間も最小限に抑え、余裕をもってリリースできたと思います。（多少は祈った）
結果
結果としては無事にリリースができましたし、背景からサービスを理解することで自分ごととして捉えやすく、モチベも高く作業に当たることができました。作っている中でアイデアも湧くこともあったので、今後も改修していく所存です。
振り返り
振り返ってみると、プロダクト開発においては一発逆転ホームランのような手は無い、ということを体験したように思います。
開発者が俯瞰することや、情報をしっかり管理すること、密なコミュニケーションなど地味だけど良さそうなことを地道にやった結果、開発がある程度上手く回ったのかなと感じました。
紹介しておいてなんですが、OOUIやグロースサイクル図, Asanaなどはあくまでもツールで、大事なのはその辺りの目的を見失わないことなのかなと思っています。
スクラム開発も上手く回すこと自体が目的になってしまうこともしばしばあったので、以後気をつけたいと思いました。
また不具合修正が少し押したり、属人化を回避しきれなかったりと課題も少なからずあるので、これらの経験も活かして地道に改善していきたいなと思ってます。
