この記事は クラウドワークスアドベントカレンダー2019 18日目の記事です。
フロントエンドグループ・トリュフチームの @eighty8 です。
私たちのチームでは、crowdworks.jp におけるデザインガイドラインの作成と、UIコンポーネントカタログの実装をメインで行なっており、既存のUIを大きく崩さずレガシーなデザインやHTML構造を刷新していくことを目指しています！（いずれはデザインシステムに発展させていきたい！ ）
チーム発足から一年弱が経過しましたが、このたび待望だったプロダクトオーナー（以降PO）も加わり、プロジェクトを推し進める上で大きな原動力となっています！
クラウドワークスにおけるPOの役割
【POのミッション】 ・プロダクトや担当機能のROI最大化 ・ミッション遂行に向けたチーム管理 ・施策の優先順位の決定／意思決定 【業務内容】 ・開発テーマ設定／KPI設定 ・開発のプロセスに責任を持ち、機能企画からリリース・運用を推進 ・実行／実装にむけた工数およびスケジュール管理 ・KPIモニタリング、データ分析 ・ユーザーインタビュー等による定性調査／分析 ・スクラムチームの運営／改善
この記事では、PO不在のチーム発足当初からPOが加わるまでの間にあった問題と、加わった後でどのようにチームが変化したかを書いていきたいと思います。
チームの紹介
トリュフというチームについて軽く触れておきます。
2018年10月に crowdworks.jp のフロントエンドを専任に請け負うチームとして発足しました。
ただし、モダンなフロントエンド環境の上で React や Vue などのフレームワークを駆使し、ゴリゴリ開発していくといったチームではなく、まずは、長い間蓄積されてきたHTMLやCSS、JavaScript（CoffeeScript）といったフロントエンド周りの技術的負債を解消し、価値ある機能をユーザーに素早く届けられる仕組みを作ること（持続可能な状態）を目的としたチームです。
当時の状況
2018年10月（チーム発足）から2019年9月までのチーム編成はこんな感でした。
- エンジニア: 2〜3名
- デザイナー: 2名
エンジニア、デザイナー、それぞれ場をリードする役割はいるものの、プロダクトの方向性を決めたり、プロダクトの価値を検討したり、多方面のステークホルダーと調整したりする役割はいませんでした。
要は、舵取り役がいないといった感じです。
なので、当時はメンバーのデザイナーにお願いして、PO兼任という形でその役割を担ってもらっていました。
POが加入するまえ
ここからが本題。
PO不在で挙げられる問題は大きく3つあったと思っています。
- 掛け持ちによる過度な負担
- チームが迷走状態に陥る
- リリース計画が立てられない
掛け持ちによる過度な負担
チーム発足当初は施策の検討フェーズということもあり、兼任することの負担はほとんどなかったように感じます。
ただ、施策が具体化していく過程で、徐々にメンバーが手を動かし始めていったときに、POを兼任しているということがボトルネックになってきました。
具体的には
といったことが、デザイナーの業務に積まれるので、本来割くべきところに時間が割けない状態になっていました。
当たり前ですが、デザイナーはデザインすることが本業であり（エンジニアだったら実装に落とし込むこと）、そこに最大限のパフォーマンスを発揮しなければなりませんが、兼任ともなると本業に掛けられる工数が減ってくるので、その分パフォーマンスにも大きく影響してきます。
それをカバーしようと無理に稼働を増やした結果、体調不良やモチベーションの低下を起こすこともたびたび出てきていました。
チームが迷走状態に陥る
期の始まりに、チーム目標やゴール設定、達成プロセスなどをメンバー全員で議論し合意決定するので、向いている方向や、やるべきことの認識はみんな一緒のはずです。（最初のうちは...）
ところが、時間の経過と共にメンバー間での認識にずれが生じ、その結果、目的がずれ、プロセスがずれ、気が付くとそれぞれ別の方向に進んでいた。。。ということが起きるようになっていました。（たびたび起これば修正コストも高くつきます）
加えて、何を優先してやるべきなのか？ の整理が追いつかず、今やらなくてもいいこと、決めなくてもいいことに対して時間を費やしてしまったり、とある課題を解決するための議論が別の議論に発展していき、
結局このミーティングって何を解決するための時間だったんだっけ？？？
となってしまうことも...
全体的にこんな感じです。
- 進んではまた戻るの繰り返し。
- 議論が議論を呼んで答えが出ない。
- ゴールは見えているものの近づいてる感じがしない。
常に全体を俯瞰し、舵切りできる役割が必要だと痛感しました。
リリース計画が立てられない
プロジェクトが終盤に差し掛かると、具体的にプラットフォームへの適用を検討し始め、リリース計画を立てていきます。
ところが、既存のコンポーネントを新しいコンポーネントに置き換えていこうとする中で、いくつか大きい問題にぶち当たりました。
他のチームの施策とバッティングしないか
- 他のチームがどの画面を触っているのか？
- 今後どの画面を触る予定があるのか？
- 計画しているところが被った場合にどう調整するか？
新しいコンポーネントに置き換えた際の数字的影響はどうか
- ○○率に影響を与えないか？
- リスクの共有は だれが・どこに・どう 伝えるのか？
- 数字が下がった場合のリカバリープランは何があるのか？
どの画面から着手していけばいいのか
- ヘッダー、フッターといったグローバルなものから着手するとして、メインのコンテンツはどこから？
- ビジネス観点からインパクトがありそうな画面（たとえば仕事検索とか）？
- それとも影響範囲が小さいマイページの一部の設定画面？
- MFI*1も考えるとログイン前画面からがよい？
これらの問題はプラットフォーム全体に関わってくるので、チーム単独で判断することはできません。
各ステークホルダーとの密な連携が必要になってきます。（兼任としてのPOはいるものの、この辺りの問題について深く考え調整する余裕はない）
また、ビジネス指標（主にKPI）にも影響を与えかねないので、その責任を持つというのも難があります。
この問題がチームにとって一番頭を悩ませる部分でもあり、リリース計画が難航した原因でもありました。
POが加入してから
そんなこんなで、チーム状況としてはかなり停滞感がありましたが、今まで挙げた問題に対する課題定義を行ったことで、ようやくトリュフチームにも専任のPOが着くことになりました！
前途の問題もPOが加わったことで解決していきました。
- 専任のPOがいることで掛け持ちによる負担はなくなった
- POが中心となって舵取りを行うことで迷いがなくなった
- 実行可能なリリース計画が立てられるようになった
専任のPOがいることで掛け持ちによる負担はなくなった
今まで兼任していたデザイナーは デザインを考えデザインに落とし込むこと に集中できるようになったため、本来のパフォーマンスを発揮できるようになりました。
また、エンジニアとデザイナーがスムーズに連携できるようになり、施策のスピードも上がっていきました。
POが中心となって舵取りを行うことで迷いがなくなった
POが加入した時期はちょうど期の移り変わりということもあり、あらためてチームのキックオフを行い以下を決定していきました。
- 目標の再設定
- ビジネス的価値を届けるための適切なゴール設定
- 明確なプロセス定義
実際のワークは以下の通り。
インセプションデッキの「我々はなぜここにいるのか」を検討
ゴール設定、やらないこと などを検討
ビジネス的価値を届けるための適切なゴール設定 をしたことで、チームが向かうべきゴールが明確になり、時間が経過してもメンバー各々の目線がずれることがなくなりました。（あったとしてもすぐに気付け軌道修正できる状態になった）
また、混沌としたバックログを整理し、それぞれのタスクに優先順位を設けることで、いまやること、やらないことの線引きができるようになり、無駄な作業や議論に時間をロスすることがほとんどなくなりました。
実行可能なリリース計画が立てられるようになった
各ステークホルダーとの調整事は全面的にPOに任せることができ、そのおかげで、自分たちだけでは到底解決できない諸々の問題もクリアされていきました。
- 他のチームの施策とバッティングしないか
- 各PO陣との連携により解消
- 新しいコンポーネントに置き換えた際の数字的影響はどうか
- マーケティング側との連携により解消
- どの画面から着手していけばいいのか
- ビジネス価値が提供できる画面2つに絞る
結果、無事にリリース計画が立てられるようになり、あとはその計画を実行に移すだけの状態にまでもっていくことができました！
もしPOがいなかったら、未だにここで足踏みしていたかもしれません。。。
まとめ
チームにPOが加わり変化したこと
- チームの誰かの負担がなくなった
- チームが進むべき方向に進めるようになった
- チーム外との関係性が濃くなった
- チームが活気付いた
- プロジェクトが加速した
そして、何よりも PO中心にチームがまとまり雰囲気が良くなった ことが大きな変化だと感じています！
