- はじめに
- koufuri+ってどんなプロダクトなの？
- どんな開発プロジェクトだったの？
- プロジェクトの前提条件
- プロジェクトメンバー
- 採用技術
- ざっくりタイムライン
- 取り組んだこと
- ①やっていき技術選定
- ②ユビキタス言語作成
- ③バグバッシュ
- ④チームビルディングの儀式✡️
- ⑤要件が膨らまないようにコントロール
- ⑥ノーレビュー
- おわりに
はじめに
お疲れ様です。エンペイでエンジニアをやっているsuetsuguです。
この記事では先日正式にローンチした弊社のプロダクト「koufuri+」について、
- どんなプロダクトなのか
- どんな開発プロジェクトだったのか
- 開発する中でどういう事を考えて、どういう意思決定をしたのか
などを思い出しながら書いていきたいと思います。タイトな開発期間で新規プロダクトの立ち上げをすることになったエンジニアやPdMなどの方々の参考になれば幸いです🙏
koufuri+ってどんなプロダクトなの？
一言でいうと、このプロダクトは口座振替を利用した集金業務全般をサポートするBtoB SaaSです。詳細なプロダクトのコンセプトや開発背景については、事業責任者のブログをご確認ください。
.png&w=640&q=90)
どんな開発プロジェクトだったの？
プロジェクトの前提条件
2022年6月から9月にかけて開発を行い、10月から限定公開したサービスをいくつかのお客様に使用してもらい、そのフィードバックをもとに製品をブラッシュアップして、この2023年春から本格的に提供開始するような計画でした。
限定公開版の開発においては、QCD(品質、コスト、納期)のうち、D(納期)→Q(品質)→C(コスト)という優先順位を取ることをプロジェクトメンバーで合意してから開発に着手しました。
プロジェクトメンバー
PdMがプロダクトオーナー、エンジニアの中の1名がスクラムマスターを務めました。また、PdM・エンジニアをスクラムチーム、それ以外はステークホルダーという位置づけとしました。
役割 | 詳細 |
事業責任者 | 機能の仕様・ワイヤーフレームのレビュー
営業活動、社外ステークホルダーとの調整 |
PdM | ①機能の仕様・ワイヤーフレーム作成
②顧客の導入支援
9月から2名体制となり、①と②の業務を分担した |
エンジニア | 開発全般を担当
5-9月: フロント1人、バックエンド3人
9-10月: フロント2人、バックエンド2人 |
社内別チームからサポートしてくれた方々 | QAエンジニア: テスト計画立案、実施など
デザイナー: ワイヤーフレーム、ロゴ作成など
インフラエンジニア: 各種環境、CI/CDの構築 |
採用技術
フロントエンドはReact(TypeScript)、バックエンドは基本的なCRUD処理はHasuraに任せて、外部APIを叩くなど複雑な処理をGoで実行するような構成を組みました。
ざっくりタイムライン
時期 | やったことなど |
2022年3〜4月
準備段階 | • 製品コンセプト、ワイヤーフレーム作成
• プロジェクトメンバー選定
• 技術選定 |
5月
チーム本格始動 | • 見積もり、技術検証、DB設計 |
6月〜8月
メイン開発期間🔥 | • もくもくと開発
• サービス名決定(6月)
• 限定公開版の受注も着々と進む |
9月
リリース最終準備 | • 2人目のPdM、2人目のフロントエンドエンジニアがJOIN🎉
• 受注済み施設へのオンボーディング開始 |
10月
リリース🚀 | • 限定公開版の提供開始🎉 |
取り組んだこと
①やっていき技術選定
弊社の既存のプロダクト「enpay」では、Ruby on RailsやVueが採用されていましたが、このプロジェクトでは、プロジェクトメンバーが使える、または使いたい技術を積極的に取り入れることにしました。これにより、React、Go、Hasuraなどが採用されました。プロジェクトメンバーは、ReactやHasuraに関する知見があまりなく、プロダクトに適合するかどうかは試してみないと分からない状態でしたが、プロジェクトメンバーの意志とモチベーションが尊重され、これらの技術が採用されました。
結果として、Hasuraの導入は大きな効果がありました。バックエンドの単純なCRUD処理の実装にかかる工数やDBマイグレーションの仕組みを作る工数を大幅に削減できました。
②ユビキタス言語作成
開発プロジェクトの初期段階でユビキタス言語集を作成し、用語や画面上の表示、意味、プログラム上の表現をまとめました。例えば、このプロダクトを導入している施設については、人によって「org（organization）」や「事業者」などと呼んでいましたが、それぞれが同じものを指していることをメンバー全員が理解できていたのでコミュニケーションの齟齬などが発生しませんでした。
プロダクトのすべての概念をまとめるのは大変ですが、コアとなる概念を5〜10個程度整理しておくだけでも円滑なコミュニケーションができそうです。
③バグバッシュ
特定の機能についてWeb通話や画面共有をしながら1〜2時間みんなでモンキーテストを行う会(バグバッシュ)を不定期開催しました。
QAエンジニアがバグを見つけた場合は1ポイント、それ以外の参加者が見つけた場合は2ポイント獲得できて得点を競い合うようなゆるいルールのみ設けて実施したのですが、ゲーム感覚で楽しくテストができるので嫌な気分になる人も少ないですし、良い意味で意地悪なパターンでのテストが行われるのでかなり効果は高かったように思います(バグが見つからなくても、それはそれで良し)。
④チームビルディングの儀式✡️
定型的なスクラムイベント以外にも、チームビルディングのために要所要所でハラワリ会、期待値合わせ会、振り返り会などのイベントを行いました。
ハラワリ会とは
プロジェクト初期段階で、メンバー間での日頃のコミュニケーションやプロジェクトへの熱意に関するモヤモヤが溜まり、衝突が起きることがあったため、CTOがファシリテーターとなりお互いの思いを共有し建設的な議論で今後の方向性を決める会を行いました。これによりメンバーの行動は劇的に変わらなかったものの、お互いの仕事に対する取り組み方や思いを理解でき、コミュニケーションがいくらか円滑になったように思います。
期待値合わせ会とは
自分がチームに対して貢献したいことと、他の人から期待されていることのギャップを埋めるための会です。各メンバーが自分の得意なことや貢献したいことを共有し、他の人から期待されることを把握することで、お互い納得感を持って作業分担できるようになりました。
/w=1080,quality=90,fit=scale-down)
振り返り会とは
限定版を公開するまでの開発全期間を対象とした大規模レトロスペクティブです。今後の改善というよりは、その時その時の思いや状況をお互いに共有し消化して、健闘を称え合うようなことができました。
/w=1080,quality=90,fit=scale-down)
⑤要件が膨らまないようにコントロール
限定公開版の機能群はMVP(Minimal Viable Product)として顧客に価値を感じてもらえる必要最低限のラインに留めることを重視して、その軸が最後までブレずに維持されました。そのため、「この機能が足りてなかった！」「この機能はやっぱりこういうふうに作り直してくれない？」といった要求が次々と出てきて、いつまでたっても開発が終わらなくなるような悲劇が起こりませんでした。これについては事業責任者やPdMの高精度な要件定義に感謝するしかありません😂
開発スケジュールはタイトでしたが、ゴールラインがブレなかったおかげでエンジニアは深夜残業や休日勤務などの無理をすることなく高いパフォーマンスを出し続けることができたと思います。
⑥ノーレビュー
当初のエンジニア4人の構成は、シニアエンジニアが3名、ジュニアエンジニアが1名でした。そのため、若手を適宜サポートしつつ、他の3人はそれぞれPdMとやり取りしながら担当機能をノーレビューで積極的にマージし、最後にまとめて不具合を解消する方針を取りました。
この方法を取ることでエンジニア間の開発志向による衝突やレビューの待ち時間が発生せず、開発をスピーディーに進めることができました。しかし、コードレビューを行わなかったことが限定公開版リリース後に重大な不具合が発見される原因ともなりました。これは、良い面と悪い面がある諸刃の剣でした😓
おわりに
これまで前職などで新規プロダクト立ち上げに何回かチャレンジしてきましたが、リリースが遅れることが多かったです。今回の成功と大きな違いは、PdMがゴールラインを動かさなかったこと、Hasura導入によってバックエンドの実装工数を削減できたことなどが挙げられます。ただ、今回の成功の再現性はプロダクトの規模やメンバーにも依存するため一概には言えませんが、読者の皆様の参考になる点があれば幸いです。
今後はGitHub CopilotのようなAIコーディング技術が進化し、新規プロダクト開発プロジェクトのやり方も大きく変わっていくような気がしています。また次に新規プロダクトの立ち上げができるようなチャンスに備えて、日々新しい技術のキャッチアップなどを続けていきたいです。
この記事を読んで弊社に興味を持たれた方がいらっしゃれば、以下からエントリーしていただけると嬉しいです。エンジニア以外にも事業開発や営業なども募集しています。カジュアル面談も受け付けていますのでお気軽にご連絡ください。
