はじめに
こんにちは。アソビューでプロジェクトマネージャー・プロダクトオーナーをやっております杉浦と申します！ 一昨年よりアソビューにジョインし昨年末無事エンターテインメント向けチケット予約システム、通称座席指定システムをローンチすることができました！🎉🎉🎉
今回はその座席指定システムの新規開発におけるローンチまでのプロジェクト管理および、そのリリース後、座席指定システムをグロースさせるためのプロジェクトにおいて担当することになったプロダクトオーナーとしての仕事について紹介させていただきたいと思っています！
ローンチまでのプロジェクト管理
開発プロセス
座席指定システムは開発開始からローンチに至るまでウォーターフォールで開発していました。プランニングやレトロスペクティブなどスクラムイベントを実施してはおりましたが、ローンチまでには明確なマイルストーンが設定されており、機能開発用のタスクを複数のスプリントに跨り開発しタスクの進捗をスプリントのゴールとして運用しました。ウォーターフォール開発でプロジェクトを進めた経緯は下記が主な理由でした。
- 明確にローンチの期限が定められていた
- ０→１の新規プロダクトの開発であった
- 実装しなければならいない機能が決まっており不確実性の少ないプロジェクトと言えた
- 私を含めアソビューにジョインしたばかりのメンバーが多くスクラムの経験が少なかった
- 開発開始からローンチまでの期間が１年間と比較的長期間プロジェクトであった
- 開発メンバーが２０名以上となる比較的規模の大きなプロジェクトであった
プロジェクトの運用課題
このプロジェクトは無事予定通りにローンチに至りましたが、その後何度か振り返りを行いました。その結果いくつかの課題が浮き彫りになりました。
開発スコープの肥大化
開発開始からローンチまでの期限内に可能な限り機能を詰め込みました。その時点ではユーザーが必要とする必要最低限な機能と認識して開発を進めましたが、後から振り返ると結果的にスコープが大きすぎたことに気付きました。小さなスコープでもっと早くユーザーの評価や判断を得ることができていれば、より有用な機能を提供することができ、より早くプロダクトの価値を高められたように感じました。
変更にかかるコストが大きい
プロジェクトには要件の変更や不備、事業戦略の変更などがつきものです。変更による意思決定や変更を下位工程までの適用するのには時間を要します。その間開発は滞り手待ちや手戻りの発生により可働率が悪化する状況がありました。
実際には多くの不確実性を内包していた
このプロジェクトは不確実性が少ない見立てでしたが実際ローンチしてみると適切な機能であっても、運用オペレーションについての不確実性までカバーできていませんでした。例えば興行領域での慣習によりプラン登録では自工程内で綿密なチェックを行い次工程にミスが混入しない事を前提に設計しましたが実際には状況や利用者により自工程内で発生したミスが検知されず次工程に持ち越されることが何回かありました。こういったオペレーションの前提も実際にユーザーに価値提供して初めてわかりました。
プロジェクトマネジメント
このプロジェクトについては従来通りのプロジェクトマネジメントを実施しました。要件定義やUXの決定、スケジュール管理にタスク管理と業務は多岐に渡ります。全てのメンバーのタスクに関して都度意思決定を行い中央集権的な管理を徹底しました。
1 → 10フェーズへの移行とスクラムの導入
プロダクトはローンチされプロダクト開発も1 → 10のフェーズへ突入しました。1 → 10のフェーズとは市場にリリースしたプロダクトをどんどん成長させより強いプロダクトに成長させるフェーズです。
スクラム
プロダクトローンチまでの開発プロセスの課題を解消すべくスクラムチームを結成し今後のプロダクト開発を行うこととなりました。メンバー全員が本格的なスクラムにチャレンジするのは今回が初めてであったため、スクラムガイドや関連書籍でのインプットや輪読会を行い未知の開発手法に挑みました。あと社内でスクラムの経験が豊富なメンバーに依頼し、アジャイルコーチとしてチームにジョインしてもらいました。
実感した成果
スクラムに移行したことにようる成果としては要件確定からリリースまでのリードタイムが随分短縮できたように思います。これはチームが必要最低限のインプットで自発的に機能するようになったことが大きいと思います。開発マネジメントを基本プロダクトオーナー以外のチームメンバーで管理し、課題があれば全員で解決することでプロダクトの価値をイタレティブにエンハンスできるようになりました。
課題感
メンバーの意識の高さに依存する
一方スクラムに移行していく過程でいくつか課題も感じました。チーム運用が円滑に進められた一つの要因にはメンバーの素養に依存した部分が大きかったと思います。特にスクラムマスターのマネジメント能力が高かったのとそれ以外のメンバーもチームビルディングに対して意識が高くチーム一丸となってスクラム化を推進することができました。この点については我々は運が良かったと思いますがチームのメンバーによってはスクラムは難しい選択にもなり得る可能性があると感じました。
チーム運用が軌道に乗るまである程度時間が必要
スクラムで開発できる体制となるまでには時間が必要でした。１ヶ月間程「スプリント０」なる準備期間を設け徐々にスクラムに移行しましたが今回のように別の開発手法からスクラムに移管するにはチームにある程度スパンの長い開発期間が与えられているシチュエーションが必要と感じました。
プロダクトマネジメント
座席指定システムをグロースするフェーズとなり管理の対象がプロジェクトからプロダクトに変わりました。これまでは座席指定システムを世に生み出すことが私の使命でしたが、座席指定システムの市場価値を最大化することが責務となりました。つまりこれからは座席指定システムを最高のプロダクトにしなければなりません。
プロダクトオーナー
プロダクトオーナーになる
スクラムチームにはプロジェクトマネージャーはいません。プロジェクトはチーム全体で管理します。新チームで最も自分がバリューを発揮できるのがプロダクトオーナーであろうと感じたのでこのチームではプロダクトオーナーをやらせていただくこととしました。
プロダクトオーナーとは
スクラムガイドによるとプロダクトオーナーとは製品開発における方向性を決める責任者を指します。顧客の要望を正確に捉えて、プロダクト（製品）の価値を最大限化させることに責任を持つ職とあります。つまり最高のプロダクトを作ることについての責任者と言えます。
プロダクトオーナーの魅力
プロダクトオーナーについては未だ正直あまりメジャーな職種とは言えません。プロダクトマネージャーと混同されがちですし、ネットでプロダクトオーナーの書籍など探そうとしてもほとんどがプロダクトマネージャー関連の書籍ばかりで、あまり世の中に認知されていない感じは否めません。ただ私はプロダクトオーナーという職種に大変魅力を感じています。また今後もプロダクトオーナーとしてのキャリアを充実させていきたいと思っております。その理由としてはプロダクトオーナーとはプロダクトの価値を最もダイレクトに市場に反映できる職種ではないかと感じているからです。
プロダクトマネージャーとの違い
プロダクトオーナーが戦術的に行動し、プロダクトバックログを管理することで顧客価値を最大化することに集中し、開発チームと密接に連携するのに対して、プロダクトマネージャーは戦略的な役割を担います。プロダクトオーナーはあくまでスクラムチームにおけるデリバリーを中心とした役割です。つまり、スクラムチームの外側にプロダクトマネージャーが内側にプロダクトオーナーが存在すると言えます。
プロジェクトマネージャーとの違い
当たり前ですがプロジェクトを管理するのがプロジェクトマネージャーです。プロジェクトとは具体的には例えば興行領域向けの座席指定システムをレジャー領域でも使えるようにする、とかアソビューに新たに座席指定可能なチケット販売システムを開発する等、特定の目標を達成するためのタスクを集めたものです。一方プロダクトとは特定のグループ (ターゲット市場) のニーズを満たす製品のことです。なのでプロジェクトを管理するプロジェクトマネージャーと、プロダクト管理に責任をもつプロダクトマネージャーやプロダクト開発に責任を持つプロダクトオーナーとは管理対象が異なる役割であると言えます。
プロダクトオーナーの仕事
要求分析・要件定義
ステークホルダー（パートナー、ゲスト、営業、制作、CS、経理）からプロダクトへの要求を抽出しシステム要件を定義します。定義した要件をステークホルダー、開発間ですり合わせ双方納得した内容でプロダクトバックログに落とし込めるようにします。
プロダクトバックログの管理
システム要件をバックログに分割し事業戦略上最も価値が高くなる順番で事項できるように優先順位を定めます。優先順位については事業価値だけではなく、価値を提供できるまでのリードタイムや開発コスト、セキュリティリスクなどを総合的に判断し決定する必要があります。
スプリントゴールの設定
スクラムマスターと相談しスプリントのゴールを設定します。プロダクトオーナーには、メンバー全員が理解できるように、プロダクトビジョンを伝える役目があります。開発に関わるメンバー全員がなぜこのスプリント、このゴールに向かうのかを理解しチームで自走していけることが重要です。
バックログリファインメント
プランニングでプロダクトバックログをスプリントに投入できる状態にします。我々のチームではプロダクトをサブタスクに分解しストーリーポイントの見積もりが可能な状態することをバックログをアクティブスプリントに投入できる状態と定めました。バックログリファインメントまでに要件に不明瞭な部分がなくなるよう関連部署や開発者と調整しプロダクトバックログをサブタスクに落とし込める状態にする必要があります。
ステークホルダーの窓口
関するステークホルダーからの問い合わせに対応します。必要があればミーティングや定例会議を行い要望や課題について共有しプロダクトバックログとして管理します。
おわりに
アソビューでは、我々のミッション「生きるに、遊びを。」の実現によって社会のあたりまえを変えていこうとしています。それを実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを募集しています。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください！
お待ちしております。
