2021/7/1に、当社初のtoC向け事業サービス「en-chant（エンチャント）」をリリースしました。
en-chantは、ファンの日常生活をスポーツチームの応援につなげることができる、新しい応援の形のサービスです。en-chantではファンがプロジェクトに参加することで、ファンの代わりにスポンサーからチームへ応援金が渡る仕組みを提供しています。
私はen-chantの開発リーダーとしてジョインし、サービスコンセプトから要件定義/設計への落とし込みや、開発チームのマネジメントを主に行いました。この記事では、初めて新規事業の開発に携わった私が、感じたこと、気づいたことについて書いていきます。
土屋 江里佳（ツチヤ エリカ）当社のメインサービス「Synergy!」の開発に携わったことのない稀な存在。
趣味は休日に動物園や水族館に行くこと。
開発スケジュール
en-chantの開発にあたり、いつ頃どのようなことをしたのかをざっくり図で表してみました。
en-chantのプロジェクトは2020年8月ごろからスタートし、はじめはビジネスサイドの2名でサービスの企画検討を行いました（企画のエピソードはこちらをぜひご一読ください）。ある程度企画が固まった2020年11月ごろに私がジョインし、2021年1月にエンジニア2名がジョインしました。
図中（2月後半ごろ）の「セキュリティ基準・個人情報取扱基準の見直し」について補足しておくと、当社はこれまでtoBサービスのみを提供してきたため、今回のen-chantの開発を機に、toC観点で基準等を見直し整理しました。
全体の工期は約11ヶ月、そのうちサービスの企画が3ヶ月、調査や設計、検証等が6ヶ月、実装とテストが2ヶ月弱というスケジュールになりました。
ここから、en-chant開発を通じて得た学びをいくつかピックアップしていきます。
学んだこと、感じたこと
プロジェクトの用語とターゲット
サービスの企画段階で大まかに実現したいことが決まっていたため、要件定義も設計も早めにまとまりそうだと思っていました。しかし、メンバー間でミーティングを続けても、どこか腹落ちしないようなことが増えてきました。具体的には次のようなことが起きていました。
- 同じ言葉でも、メンバーによって意味合いが微妙に違っている。「自分はこんなつもりで話していました」というコミュニケーションが発生している。
- メンバーによって、想定するユーザーの行動に違いがある。例えば、ある機能を組み込むことを考えているときに、エンジニアのAさんは「この画面遷移でユーザーは迷いなく操作できるだろう」と考える一方で、ビジネスサイドのBさんは「ユーザーがこの画面に到達したときに次のアクションで迷ってしまうだろう」と考えている。
- よくよく話し合って結論を出しても、日が経つとこの設計で本当にいいのか疑問に思う。意見がブレやすい。
1つ目の対策として、単語とその意味をドキュメントで明記し、プロジェクトチーム内の共通言語として使うことを徹底するようにしました。単語の意味が些末な違いだったとしても、認識齟齬が起きるきっかけになってしまいます。コミュニケーションでつまずきがあったものの、早い段階でその機会を減らすことができたのでとてもよかったです。
2つ目と3つ目は複数の要因があると思うのですが、主な原因はターゲットとなるユーザー像の作り込みが甘かったことだと考えています。
今回の開発ではUXリサーチ会社の選定が必要になり、その分ユーザーインタビューの実施が後ろ倒しになったため、自分たちの想像だけで作成した簡易的なペルソナに後づけで情報を加える形になりました。要件定義や設計の議論をする段階でインタビューが終わっていれば、事実に基づく情報を使ってユーザーの特徴を固められていたかもしれません。
また、スケジュールの都合上、今回はユーザーインタビューを3人の方に実施しました。結果、ターゲットとなるユーザーの傾向が大まかに見られたものの、もう少し多くの人にインタビューを実施していれば、よりはっきりとした特徴をつかめていたかもしれません。
今回の開発を通じてtoCとtoBサービスの違いを感じたのですが、toBサービスは具体的な利用用途が決まっていることが多くユーザー像が固めやすい一方で、toCサービスの場合は利用ユーザーの対象がtoBよりも広く、ターゲット像がブレやすいと感じました。ターゲットの特徴をより深掘りして、全員で共通認識をもてるように心がけたいです。
初期リリースのスコープ
設計完了まで遅れていたものの、2月半ばの時点で主要な機能は固まってきていたので、ワイヤーフレームの作成などと並行してプロトタイプを作成していました。 プロトタイプが形になり、実際に動いているモノを見ると嬉しいし、アイディアが沸きやすくなります。POからも「あの機能も追加できる？」など要望が上がってきやすくなり、開発も（もちろん内容によりますが）できると回答していると、じわじわ機能要件が膨らんでいきました。
結果、追加する機能が大きくなりすぎ、2021年5月時点でこのままだと初期リリース日の7月1日に間に合わないことが発覚しました。
そこで、初期リリースの時点でen-chantというサービスがどうなっていれば良いか、改めてプロジェクトメンバー内で話し合い、その時点で不要な機能は追加機能としてリリースすることにしました。結果、無事に初期リリースを迎えることができましたが、ギリギリの調整になってしまったため、初期リリースのスコープを明確にしておくべきでした。
チームビルディング
en-chantではチームビルディングとして次の2点を実施していました。
（1） 週に一度、チームメンバー全員でOKR*1を確認する。
自分のしていることが目標に貢献するのか見直すきっかけになりました。開発だけでなく、ビジネス側の目標も確認することで、チームの全体の指針にブレが生じにくくなりました。
（2）朝会や週定例は短い雑談をする。
業務のみの会話はどうしても硬いコミュニケーションになってしまいます。少しの雑談でも話やすい「場」ができ、心理的安全性を高めることができました。
逆に、研修やワークショップといった交流は行いませんでした。メンバーがほぼ同じ部署で、元々ある程度交流があったためです。
開発する上で意見の衝突はもちろんありましたが、全体を通じて建設的な議論ができたと思います。また、リリース後にチーム全体で振り返りを行ったのですが、「あれはよかった」や「次はこうしたい」など、お互いへの称賛や次のトライを前向きに検討できていたので、働きやすい関係が築けていたかなと思いました。
社内の横のつながり
en-chantを開発するにあたり、専従メンバーの5人だけではなく、部署の垣根を超え30人以上の方に協力していただきました。協力いただいた内容は次の通りです。
- UI/UXデザイン
- ロゴ/ブランドデザイン
- HTML/CSSコーディング
- ユーザーテスト
- 社内インタビュー
- レポーティング
- 規約/特許関連の整理
- 問い合わせ/オペレーション/請求関連の設計
- テスト
- PMO
- Synergy!の設定 ※en-chantでは当社のサービス「Synergy!」を利用しています。
- お客様紹介
新規事業開発をはじめてみると、思いがけないタスクが出てきたりと想像以上にやることが多く、専従メンバーだけでは2021/7/1のリリースには間に合わなかったと思います。協力していただいた社内の方にはとても感謝しています。
初期リリースが終わって
私がen-chantの開発にジョインしてからリリースまで約8ヶ月ありましたが、本当にあっという間に時間が過ぎていきました。毎日の変化が大きい新規事業の開発は忙しかったですが、メンバーや環境に恵まれたこともあり忙しさを楽しみつつ取り組むことができました。
また、ここまで反省を含めて色々と書きましたが、決してネガティブな気持ちはなく、「あ、今のこの状態は黄色信号だぞ！」と気付けるタイミングを体験できたのは、とても良い経験になりました。
もし、同じような状況で新規開発があったとして、「今よりもうまくできるか？」と質問されれば、自信を持って「はい」と答えることができます。スキル的にもまだまだですし、勉強しないといけないことはたくさんありますが...（笑）
これからはen-chantがより大きく育つよう、尽力していきたいと思います！
一緒にen-chantを盛り上げませんか？
現在、私たちのチームではUXデザイナーを募集しています。この記事を読んでen-chantに興味を持ってくださった方は、ぜひ↓の記事もご一読ください。
一緒にen-chantをより良く、より大きくできる仲間を募集しています！
*1:目標の設定・管理方法のひとつ。en-chantではチームで定めた目標（Objectives）に向けて、ビジネスと開発それぞれの観点で主要な結果（Key Results）を達成できるように動いていました。
