上流工程〜そしてスクラムへ！　スクラムにおける上流工程のあり方

こんにちは！こちらの記事は、アソビューAdvent Calendar 2023の21日目(A面)です。

はじめに
要求分析
ユーザーストーリーマッピング
ユースケース分析
要件定義
設計・開発
スクラム
まとめ
We're hiring！

はじめに

アソビューでプロジェクトマネージャーをしている杉浦と申します。現在、この度弊社では興行領域にチャレンジすべく座席指定可能なSaas型のチケット販売システムの開発を行なっております！

私自身興行領域のプロダクトに携わった経験がなく初めは何を作ればいいのかもわからない状態でした。しかし多くの方々の協力の元なんとかプロジェクトを立ち上げることができました。これもひとえに開発にご協力いただいた関係部署のお陰だと感じています。今回はプロジェクト立ち上げから上流工程〜プロダクト開発までの長い道のりを振り返ってみたいと思います。

要求分析

私がアソビュー入社後に与えられたタスクは座席指定システムの構築！でした。私はこれまで生産管理システムや在庫管理システムの開発に長年プロジェクトマネージャーとして携わってきましたし会計システムや勤怠管理システムの経験もあります。しかし座席指定システムなんて名前も聞いたことがありませんでした。この時頭に浮かんだのは新幹線の座席予約システムのイメージでした。

私が運が良かったのはアソビューには様々な業界で成果を発揮されていた方々が多く在籍しておりその中でも元々エンタメ業界の営業で活躍されていた方（以降エンタメマスターと呼ぶ）がいました。その方が開発初期の段階から積極的に協力してくれました。そのおかげで興行領域で戦えるプロダクトを作り上げることができました。当然ですが新幹線の座席予約システムではアイスショーのチケットは販売できません。

ユーザーストーリーマッピング

まずユーザーストーリーマッピングを行いました。私は興行の素人ですので私が心の中でこうだったらいいなと思い浮かべた行動をエンタメマスターにぶつけました。すると予想以上に多くのレスポンスがもらえて１つ行動からいくつものストーリーをマッピングできました。あと私の想像の及ばない行動も補完してもらった結果これまで私の頭の中にあった新幹線の予約システムが刷新され、作るべきプロダクトの解像度が飛躍的に上昇しました。

ユースケース分析

完成したユーザーストーリーマッピングからユースケースを洗い出し、ユースケース図を作成しました。ここから先はシステム開発の領域、ここまで来られればこっちのものです。長年繰り返してきた上流工程なのでやることはある程度見えています。先立って作成したユースケース図からユースケースシナリオを抽出しエンタメマスターと色々すり合わせ要件定義を行いました。この工程は楽しかったです。まだ現実的な納期のストレスはないし技術的な制約も今後の話です。この時点では夢いっぱいのプロダクトが頭の中を駆け巡っていました。パッケージデザインは概ね下記のような感じです。

複雑な座席図を誰でも簡単に作れてすぐにWebチケットを販売できるアプリ

要件定義

これまでのユーザーストーリーマッピングやユースケースによる分析で興行向けチケット販売の課題が概ね分かってきました。それは会場図の登録や配券先の設定にコストがかかりすぎる点です。配券というのは主催者がプレイガイドに販売を委託することで、配券先の設定とはプレイガイド販売を依頼する座席を決めることです。特にこの配券業務は１座席でも間違うとダブルブッキングを誘発するとても神経を使う作業です。最低２名以上でのチェックが必要となります。ところが多くの興行主催者はこの配券業務を紙に印刷した座席表に色鉛筆で色を塗って管理していたそうです。まずこの運用をデジタル化すれば大幅な業務改善に繋がると感じました。

会場図については既存のスタジアムやアリーナなどの会場図の画像をアップロードすることとしました。本当は画像アップロード時にAIよる画像解析を行い会場の各エリアを自動生成したかったんですがこれは会場図によりエリアの記載があったりなかったりするので取りやめました。

座席図の作成についてはエクセルのシェイプのようなオブジェクトをマウスのドラッグ＆ドロップで配置し、ベンチや円卓などの色々な座席を自由に配置したいと思っていました。通路や出入り口が描かれている画像をデザインツール等で作成しアップロードし画像の上にシェイプを配置していきます。アップロードした画像と配置した座席と合わせてゲストの購入画面に表示するのです。

設計・開発

アソビューではスクラムが推奨されており社内の多くのプロジェクトで採用されています。私たちのチームもスクラムのフォーマットに則りプロジェクトを進めました。私自身これまでスクラムの経験は無く新しいチャレンジです。私はここ１０年ほどプロジェクトマネージメントを行ってきましたがスクラムには踏み切れていませんでした。しかし、かといって完全なウォーターフォールで開発していたかと言えばそうではありません。

７割程度のある程度詳細な要件を固めこれを複数回イテレーションし完成させて行く

といった手法をとっており、結局今回もこれに近い感じで進めることにしました。如何にしてより良いプロダクトを開発するかが重要なのであり開発の手法もその一つに過ぎません。スクラムを行うこと自体が目的とならないようにとここだけは注意してプロジェクトを進めていきたいと思っています。

スクラム

スクラムを行ってみて個人的に難しさを感じたのはスプリント毎に動くソフトウェアを提供し続けることでした。まず動くソフトウェアを提供するにはモデルの分析やUI/UXのデザイン、開発基盤のアーキテクチャ策定など前段に用意しなければならない工程が数多くあります。実際に初めて動くソフトウェアが提供できるようになったのは数スプリント経過してからでした。スプリントの成果物として動くソフトウェアの提供先は本来プロダクトオーナーやカスタマーでなければならないと思います。ただ今回は組織上明確にプロダクトオーナーを定めることが難しく成果物は軒並みQA含めた開発メンバー内への提供となります。その結果本来プロダクトオーナーから得るべき有益なフィードバックを得るのが大変難しいと感じました。最終的にシステムの正解は利用者が握っています。今後はこのフィードバックのあり方に重きをおいてプロジェクトを進めていきたいと思っております。

まとめ

スクラムガイドには

プロダクトバックログ

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。

とあります。システム要求を分析し喧喧諤諤と意見をぶつけ合い難産してやっとできた要件定義については何の記載もありません。リファインメントやスプリントプランニングで少しずつ分析するのが正しいスクラムの進め方なのかもしれません。しかし実際の現場ではUIの実装を開始するにはデザインが必要ですしデータベースの物理設計をするにもデータモデルが必要だったりします。もちろんそれらの源泉となる要件定義も必要でしょう。これは必ずしも同時に進められるものではなくやはりスクラムにおいてもある程度の仕込みが必要なんじゃないかというのが現在の私の考えです。ユーザーストーリーマッピングにしてもユースケース分析にしてもそれは一つの手法に過ぎません。顧客の課題を正確に捉えITソリューション用いてその課題を如何にして解決するかについては時間と労力をかけて行うべきと今でも思っています。私は今後もスクラムと向き合いたいと思っています。開発手法のベストエフォートは状況により変わってくると思いますので都度最良の選択できるよう心がけたいと思います。