この記事は最終更新から時間が経過しているため、最新の情報と内容が異なる可能性があります。

こんにちは、GraciaのUXチーム・PdMの中野です。

以前、CTOの林より Graciaの開発体制についてと言う記事が公開されましたが、今回はプロダクト開発部におけるUXチームの動き方、また現在の開発体制に至るまでの変遷についてお話ししていこうかなと思います。

UXチームとは

f:id:gracia_tanp:20210624180222p:plain

プロダクト部から見た開発体制

Graciaで開発するシステムには大きく「EC」「WMS（倉庫管理システム）」「会計システム」の3種があり、それぞれのシステム毎に開発チームを形成しています。そして、僕が所属するチームは上記の「UX PdM（UXチーム）」に当たりますが、このチームでは主に、お客様が使うECの開発・改善を行なっています。

[プロジェクト例]

会員ランクのリニューアル
eギフト機能のリニューアル
検索機能の強化
サブスクリプションサービスのリリース

昨年までの開発体制

Graciaには組織規模上PMやPMMといった担当者は設けておらず、PdMが各部との連携、特にエンジニアやデザイナーとの連携を強く持つことで円滑にプロジェクトを進行させる役割を一手に担っています。昨年頃までのGraciaはプロジェクト進行に関する経験を持ったメンバーも少なく、PdMはエンジニアやデザイナーが所属するプロダクト部とは切り分けられたグループとして独立的に配置されていました。

経験豊富な方が多い組織であればそれでも上手く調整できたのかもしれませんが、Graciaではこの配置により「実際に手を動かすエンジニア・デザイナーが関わっていない状態で仕様やスケジュールが決められている」という身も蓋もない状態に陥っていました。また、各グループが合意するロードマップがない中でそれぞれのグループがバラバラの目標を持っており、それぞれが自グループの目標達成のために施策を起案するため、度々不毛な議論が発生するような問題も起きていました。

先日公開されたWMS開発エンジニア・今井さんのインタビュー記事でも言及されていましたが、どの部署も「既に決まっているものを渡される」状態では軌道修正の余地が無く、渡された人たちは納得感のないまま手を進めなくてはなりません。プロダクト部内でも次第にこの認識は強まり、まずはPdMとエンジニア・デザイナーがお互いに連携しなければならない意識を根付かせる目的でPdMをプロダクト部の中に配置、またプロダクトに関するロードマップはプロダクト部全体で合意を得る体制に移行していくこととなりました。

プロダクトロードマップの作成

上記の通りこれまでGraciaにはプロダクトロードマップのような、会社全体の事業計画から逆算した達成すべき指標のようなものは存在していませんでした。これはロードマップが無くとも目の前に着手しなければならないタスク・着手したい細かなタスクが散財し、どのタスクを着手してもある程度前に進む立ち上げのフェーズであったからこそ成立していたもので、社内では四半期ごとに大枠の施策を決め、週単位で優先順位を決めて着手していくような流れとなっていました。しかしながら、全員の力を集約して1つのプロダクトをより良い方向に導きたいと思った時、改めて「全員が1つの目標に向かえる体制」とはどういうものなのかを考えなければならない状況に直面し、共通言語となるゴール設定の必要性が浮き彫りになりました。

こうして、社内ではCTOとPdMを筆頭に事業計画に紐付くプロダクトロードマップを作成し、PdMがエンジニア・デザイナーを始めとするメンバーの疑問を解消できるような役割としても機能するよう体制を変更することになりました。

現在Graciaのプロダクトロードマップは年間施策を想定して作成されていますが、区分としては下記の3つに切り分けられています。

CX施策：社内で設定した、あるべきサービス像から下ろした顧客体験の改善施策
新規施策：新規機能・新規サービス等、新たに仕込んでいく施策
グロース施策：ABテスト等の短期PDCA施策

施策を視覚的にも整理することで、短期的な売上に現れづらい施策の優先度が落とされることもなく、適切なリソース配分が実現できるようにもなりました。

f:id:gracia_tanp:20210625160709p:plain

また、作成されたロードマップは社内全体の共通言語となるため、安易に路線が揺らがないよう守るべきものとして作成していますが、一方で市場やお客様の反応は柔軟に取り入れていけるよう、社内でコミュニケーションを取りながらアップデートも継続的に行っています。

UXチームの開発の流れについて

取り組むべき施策が確定した後の流れとしては、大枠一般的なフローを踏襲しています。

要件定義・仕様の確定
スプリントミーティング
デザイン（UI・クリエイティブ）
詳細設計・実装

要件定義・仕様の確定

要件や仕様についてはある程度のフォーマットが用意されており、起案した部門でドラフトを作成、作成されたドキュメントを元に各部で評価を行い、実現可能性・コストパフォーマンス・ユーザビリティへの影響等について意見を出し合っています。プロダクト部への依頼の粒度やドキュメントの精度を人によってバラけさせないこと、後から意思決定の背景を辿れるよう記録に残すことの大切さも痛感していたため、共通して必要な要素はフォーマット化することや、センシティブ情報以外は正社員であれば誰でもアクセスできる場所に残しておくことは重視しています。因みにGraciaでは既にesaを利用していたため、ツール利用のための学習コストを最低限に抑えてスタートすることを優先し要件定義書・仕様書もesaで作成しています。

現状、共有が必要なケース・共有が必要な担当者を個々の想像力の範囲で決めてしまうような課題があったりしますが、「早い段階で周囲を巻き込む必要がある」という意識は徐々に根付いてきたのではないかなと思います。

スプリントミーティング

週一で実施しているスプリントミーティングでは主に下記のような項目をアジェンダとして設定しています。

主要KPIの確認
施策の振り返り
ABテストの結果確認、直近リリースした機能の数値確認、ネクストアクションの決定等。
今週の振り返り
開発に関わるあらゆる事象の振り返り、体制を改善してくための議論等。
次週の取り組みについて
次週取り組むタスクの優先順位決め、担当者のアサイン等。

デザイン

UIやクリエイティブは非デザイナーとも連携した上で調整を行っていくため、ブラウザで確認が可能なFigmaを利用しています。デザインに関してはメンバーとリアルタイムにセッションすることで繊細な意図やニュアンスを汲み取れることもあり、状況に応じて口頭でのコミュニケーションも大切にしています。

詳細設計・実装

定義された要件・仕様を元に詳細の設計・実装を行い、エンジニア内でのレビュー、検証環境へのリリース・動作確認を経て本番環境へリリースしています。動作確認にはPdMやマーケティングメンバーも参加しています。

また、プロジェクト全体の進捗に対して遅れがないか、共有が必要な担当者に必要な情報が均一に行き渡っているかを担保することは、現状のGraciaの体制の中ではPdMの主要な役割の一つです。大きなプロジェクトは別途オーナーが立てられることもありますが、社内の適切な範囲のメンバーにリアルタイムで情報を渡すパイプとなることを常に意識し、開発が円滑に進むよう尽力しています。