🐻

新規機能開発で挑んだ、他部署を巻き込むユーザーストーリーベース開発

に公開

はじめに

こんにちは、フロントエンドエンジニアのOkumaです。

今回は、資格学習サービス Shikaku Pass でリリースした新機能「学習プラン生成」の開発プロセスについてお話ししたいと思います。

この機能の開発では、従来の開発フローを見直し、「エンジニアチーム以外のメンバー(マーケティング・コンテンツチーム)を、開発の早い段階から巻き込む」 という進め方を実践しました。

具体的には、ユーザーストーリーを軸にして、開発開始前とQA実施前に密なレビュー・フィードバック会を挟むフローを導入しました。
フロントエンドエンジニアとして、この変化が開発・実装やチーム連携にどのようなメリットをもたらしたのか、実体験を交えてご紹介できればと思います。

背景と課題:なぜプロセスを変えたのか?

新機能「学習プラン生成」とは

今回開発したのは、ユーザーが1日どれくらいの時間資格学習に充てられるのかを最初に入力してもらい、その時間をもとに毎回の学習タスクを提示するというもので、特に「資格学習のために講座を購入したけど、何から進めて良いかわからない」や「学習の区切りをつけて毎回達成していくことによってモチベーションの継続したい」ユーザーのための補助的な機能になっています。

従来の開発スタイルの悩み

これまでの開発では、どちらかというと仕様やUIデザインがある程度固まってからエンジニアに連携されていました。もちろんその中でエンジニアも意見を出したり議論したりする場はありました。しかし、ある程度敷かれたレールの上で開発を行い、実装完了してからビジネスサイドが確認するという、実態としてはウォーターフォールに近い流れだったかと思います。エンジニアとしては実装開始〜実装の完了、そして動作確認やリリースまでの範囲で集中して実装に取り組める点や、実装にかかる工数の割り出しなどは容易でした。

しかし、上記のフローでは以下のような課題を感じていました。

  • 機能の全体的な確認がリリース直前になることが多かったため、より早い段階で認識のすり合わせを行うことができれば、変更が生じた場合でもより柔軟に対応できるのではないかと思っていた。
  • なぜこの機能を実装するのか、必要なのかなど、仕様の背景まで共有ができていると、機能の意図や意味をより深く理解した上で実装に取り組めるだろうと感じた。

そこで今回は、機能の解像度をより高めるため、早い段階から他部署を巻き込んで「ユーザーストーリーベース」での開発フローを試みることにしました。

新しい開発プロセスの全体像

今回導入したフローのポイントは以下の2点です。

  1. 開発前レビュー:ある程度仕様、ワイヤーフレームが出来上がったタイミングでマーケティング・コンテンツチームとユーザーストーリー(ユーザーが何ができて、何を達成できるのか)をすり合わせる。
  2. QA前レビュー:実装完了後、QAに提出する前に「動くもの」ベースで改めて実際に機能を使用した場合の体験を共有し、そのフィードバックをもらう。

技術的な設計に入る前と、テストフェーズに入る前の「2つの関門」を設けたイメージです。

実践編①:開発前の「ユーザーストーリー」すり合わせ

まず開発チームでは次に実装する機能を「学習プラン生成」として、これをプロダクトの全体会議の場では共有していましたが、その詳しい概要までは説明していなかったので、「誰が・なぜ・何をしたいのか」を簡単にまとめ、それを元にマーケティングチーム、コンテンツチームと共有会を実施しました。

フロントエンドとしての関わり方

ここでは、文字ベースだけの議論にならないよう、学習プラン生成機能の全体的なワイヤーフレームを私の方で作成しました。(前期から少しずつFigmaを触るようになってきています)ワイヤーフレームを使って説明することによって「画面上でどういった動きをして、ユーザーにはどういったフィードバックがあるのか」言葉で説明するよりダイレクトに伝えることができたと思います。

これにより、実装に入る前にいくつかの「認識のズレ」を解消することができました。また、コンテンツチームからは想定している一連の学習体験の像を共有してもらい、それに沿ってコンテンツを制作していることも知ることができました(これまで深く知る機会がなく、新しい発見が多かったです)

  • 今回は士業講座をターゲットとしており、学習範囲が広いので学習プランを生成せずに自力で進められるようにプランを作成しないという選択肢もあった方が良いのではないか?
  • 上記に関連して、すでに学習した内容は学習スキップさせることができるようになると良い
  • 学習をスキップしても学習プランの進捗率が進行するようにしたい
  • 節の学習を繰り返して今後は章のテストを実施したい

実践編②:QA前の「動く成果物」でのレビュー

実装が一通り完了してQAに回す前に、再度マーケティングチームとコンテンツチームに実際に機能が動く状態でレビューしていただきました。また、同じ場ではないですがエンジニアチームのみんなにも全体を通した気になるポイントや改善点も聞くことができました。今は、エンジニアチームの全員が同じ機能開発に関わっているわけではなく、機能の詳細な動きや表示内容などは理解していないため意外と新鮮な意見をもらうことが多かったです!

バグ探しではなく「体験」ベースでの確認

このレビューの目的はバグを見つけることではありません。「意図したストーリー通りにユーザーが体験できるか」の確認です。

実際に動く画面を使って説明することで、静止画のワイヤーフレームやデザインではわからなかった「操作感」や「情報の内容」について最初に想定されていたものと機能としてのズレがないかを確認することできたと思います。

  • 実際に受験する試験日の設定ができると良い。またそれに沿って学習プランをいつまでにどのくらい進められるかがユーザーが把握できると助かる。
  • 学習プランの作成前に簡単なアセスメント(実力診断)を用意し、ユーザーのレベルによって学習を始める節を変化させる
  • 学習プランの全体像、あとどれくらいで完了できるのか、試験までに学習を終えられるのかが視覚的に理解できる
  • 学習プランを作成している途中のローディングUIをリッチにして、よりユーザーのために最適なプランを作成しているように見せる

エンジニアチームのレビューでは、現行の機能の細かい表現やUIの違和感などの指摘が多かった反面、マーケティング・コンテンツチームはこの学習プラン生成機能に今後追加していきたい機能の提案などがメインでした。チームによって機能を見ている視点がだいぶ違うなと実感しました。

フロントエンドエンジニアとして感じたメリット

このプロセスを通して、エンジニア視点(特にフロントエンド)で以下のメリットを感じました。

1.「何を、どのように作るべきか」が明確になり、迷いが減った

開発前にユーザーストーリーベースで合意が取れていたため、実装の途中で「これって、本当にこの挙動で問題ないのか」という迷いはありませんでした。また、私自身でFigmaのワイヤーフレームを作成したことで細かい仕様の把握や実際の体験フローを思い描きながら開発を進められました。以前だと「この場合はどういった動きをすれば良いんだっけ?」と迷い、PdMによく質問していましたが、今回は振り返るとすでに頭の中にその流れが明確にあったように思います。

2.機能開発全体を通して「一緒に作り上げる」感覚へ

ある程度固まった仕様通りに作るだけでなく、他部署と一緒に「ユーザーにとっての正解」「サービスとしてのあるべき姿」を探るプロセスに参加できたことで、開発への納得感とモチベーションが上がったと思います。

  • マーケティングチームは日々ユーザーの動きを追っているため、特にユーザーに寄り添った視点での意見を聞くことができたと思います。
  • コンテンツチームからは当初から描いている学習体験のフローについて詳しく聞くことができ、サービスの機能を通じてユーザーにどのように学習を進めてほしいかを聞くことができました。

これらの意見を踏まえて今回はごく簡単な機能となっていますが、今後追加していきたい機能がいろいろと出てきました。

今後の課題と展望

もちろん、すべてが上手く進められたわけではありません。
今回新しい開発プロセスに取り組んだわけですから、課題点もいくつか見つかりました。

  • リリースまでのスケジュールを正確に立てる。
    • 今までは実装開始から実装完了までの工数のみを考えればよかったが、今回はワイヤーフレームの作成〜リリース完了までの範囲を考えてスケジュールを立てる必要があった。開発スケジュールの考慮に必要な項目が増えた。
    • フロントエンドのマークアップが先に進んでしまい、APIの繋ぎ込みを少し待つ形になってしまった。
  • 多少の手戻りが発生した。
    • かっちりと仕様を確定させないまま進めてしまった部分もあり、途中で一度実装したものを修正する必要があった。先にマークアップを進めたが、後から議論の結果UIが変わったなどもあった。

今回の反省も活かして、今後はより無駄のないようこの開発プロセスをブラッシュアップしていきたいと思います。

おわりに

今回の「学習プラン生成」機能の開発を通して、ワイヤーフレーム作成〜レビュー会の実施、リリースの完了まで今までより責任感を持って進められたと思います。
コードを書く前のコミュニケーションに時間を割くことは、一見遠回りに見えますが、結果として手戻りを防ぎ、より質の高いプロダクトを最速で届ける近道になると思います。
ユーザーストーリーベースの開発や、他部署を巻き込んだレビューフローに興味がある方の参考になれば幸いです。

エンジニア募集中

Gakken LEAPは日々、教育のアップデートに取り組んでいます。
興味をお持ちいただいた方は、採用サイトをチェックしてみてください。

Gakken LEAP Developers

Discussion