はじめに
Synergy!は生まれてから18年目のCRMクラウドサービスです。
Synergy!は昔から提供しているクラシックと呼ばれている旧機能と、その旧機能を再生した新機能に大きく分かれます。
この旧機能から新機能に再生する社内プロジェクトの中で起きた失敗談をご紹介します。
失敗しないに越したことはありませんが、規模の大小はあれど、避けては通れない経験だと思います。
エンジニアはもちろん、PMをされている人も一つの教訓として知っておいて損はないかと思い、記事に取り上げてみました。
石田 一博（イシダ カズヒロ）どんなプロジェクトだったのか
Synergy!のクラシック機能を新しい技術で作り直すプロジェクトにおいて、フォーム機能を開発するチームでPMを担当していました。
このプロジェクトでは機能毎に順次リリースをしていく方式をとっていて、その中の一つ「残席枠管理機能」の開発で今回紹介する失敗が起きました。
残席枠管理機能とは
Synergy!の有料オプションの一つです。（詳しくはこちら）
簡単にいうと、フォームに設定した単一選択型項目（プルダウンやラジオボタン）の選択肢ごとに、受付上限数と受付期限を設定できる機能です。
受付上限数、受付期限を超えた選択肢を、フォームから登録できなくすることで、簡易的な予約管理として利用することができます。
社内のお披露目会で発覚した致命的な問題点
新フォームに残席枠管理機能を搭載するにあたっての方針はざっくり書くと以下でした。
- クラシックフォームの残席枠管理機能を継承する
- クラシックフォームでの課題や、要望への対応を盛り込む
クラシックフォームの残席枠管理の仕様は大きく変えずに、既存機能が持つ課題を解消する、という考え方です。
仕様検討～開発は順調に進み、ステークホルダーへのお披露目*1を迎えました。
お披露目会でのひとコマ
「受付はどうやってキャンセルするの？」
「データベースの登録内容と、フォームの残席枠管理設定を修正することでキャンセルします」
「データベースだけ変えると数が合わなくなるのは運用的に心配...」
その後、技術的なやりとりが続き、最後は
「これじゃ使ってもらえないよ」
結果はボロボロでした。
お披露目会を通じて運用上のクリティカルな問題に気付き、リリース延期、仕様の再検討が必要となりました。
仕切り直し
当然チームも重い雰囲気になりました。これはPMとして責任を感じましたし、すごく落ち込みました。
一方でリリース前にクリティカルな問題に気付けたことはポジティブでした。
気持ちを切り替えて、まずはチームで振り返りを行い、問題点の洗い出しとその対策を議論しました。
「クラシックフォーム踏襲と言いつつ、大きな仕様変更があったよね」
「仕様変更してユースケースを満たせているか確認できてなかったよね」
「運用に耐えうるかユーザビリティテストは必要だったよね」
「もっと早くステークホルダーに共有してフィードバックもらうべきだよね」
などなど。 *2
一番の問題は「新フォームの仕様がユースケースを満たしているか検証できていない」ことでした。そもそも残席枠管理機能のユースケースが言語化されていない、という問題点も見えてきました。
そこで、ユースケースの整理からやり直し、要件を再整理していきました。
その結果、受付数の管理方法を変更することが、運用的にもパフォーマンス的にも適切、という結論になりました。
その後は、ユースケースを満たすために必要なUI検討、ユーザビリティテストを行い、仕様の方向性をステークホルダーと合意し、実装に着手していく、という流れで進めていきました。
機能としても、フォームの作成・公開 ⇒ 受付 ⇒ 受付内容の確認 ⇒ 変更・キャンセル、と一連の業務を実現できる機能に進化しました。
そしてリリースへ
仕切り直し後の開発は順調に進み、動作する状態でのお披露目会を迎えました。
今回はユースケースから見直し、新フォームでも安全に運用できる機能になったという自信はありましたが、それでも前回ボロボロだったお披露目会が脳裏をよぎります。
結果は・・・
好評でした！
「気合が入っていて、とても気が利いていると感じた」
「お客様にも便利そうと言ってもらえそう」
「細部にわたって考慮がされていて良かった」
といったコメントをもらい、（まだリリース前ですが）感無量でした。
その後、結合テスト、総合テストも無事にクリアし、12/13に無事にリリースを迎えることができました。
まとめ
この失敗から得られた主な教訓としては、以下の3点です。
- ユースケースを満たせているか常に意識すること
- 仕様変更の影響を甘く見ないこと
- ステークホルダーにこまめに共有すること
この記事を書きながら「どれも当たり前のことなんだよな、、」と思うのですが、できていなかったのです。
プロダクト開発ではビジネス的にスピードを求められる場面も出てくると思いますが、スピードを優先するあまり、誰も使わない機能になっては本末転倒です。
仕切り直しになればコストも嵩みますし、他のスケジュールも後ろ倒しになって、良いことはひとつもありません。
こうならないためにも、要所要所で「これ、ユースケースを満たせてるかな？」と確認することは大切だと実感しました。
この記事を読まれた方はこの失敗談を生かせてもらえたらなと思います。
当たり前を自然に実践することの難しさ、を痛感した2022年でした。
