アドプラットフォーム事業でプロダクトマネージャーをしているmochiです。
TanzuLabs（以下Labs）様と一緒にJANetのモダナイゼーションを行いました。
はじまる前はプロダクトマネージャーとして何を学べるのか不安な気持ちが強かったものの、多くのことを学べた日々でした。
今回は、その中でユーザーストーリーを元にしたコミュニケーションの話をします。
組織の理想
アドプラットフォーム事業の中で理想として掲げていたのは、ただ生産性が高い組織ではなく、生産性に加えて高い価値を出せる組織を目指しています。
言われたものをただ作るのではなく、本質的な価値を模索してソリューションをアップデートしながら開発を進めることが大事になります。
また、プロダクトチームはエンジニア、デザイナー、プロダクトマネージャーの3つの役割で構成されており、ロールを跨いだコミュニケーションが価値をアップデートする為のキーになっています。
現場で起きていたこと
所属しているアドテクノロジーDivでは、アジャイルで開発を進めています。
複数のプロダクトチームが存在しており、組織で統一された内容でアジャイルを進めているのではなく各チームそれぞれにオリジナルの要素が加わっている状態です。
ユーザーストーリーに関しても例外ではなく、それぞれのチームでオリジナルのテンプレートを元に管理されていき、ただ作業を管理するものになっていました。
作業内容もエンジニア、デザイナーが対応する作業が中心の為に、プロダクトマネージャーが進捗を追いにくくブラックボックスな状況が出来上がります。
また、開発までの流れはプロダクトマネージャーとデザイナーが中心で進み、作る内容が決まったら開発のフェーズでエンジニア側が開発を進める分業のウォーターフォールに近い状態になっていました。
ユーザーストーリーから組織の理想に近づける
Labsと一緒にモダナイゼーションを行う中で、いざ開発の段階へ進んだタイミングでユーザーストーリーを書きました。
実際に下記の記事を書いているWataruさんと一緒に進めていきます。
記事にも書いてある通り、ユーザーストーリーに書く内容で大事なポイントが２つ。
- 「Why」なぜこれをやるのか
- 「Acceptance Criteria」何を作るのかを明確にした受け入れ基準
タスク管理となっていた自社のユーザーストーリーとは異なり、「Why」に向きあうことになっています。
Why
As ペルソナは
I want 〜したい
So that そうすることで、〜からだ
「Why」を書いていると、気づくことがあります。
改めてこの機能って何の為に必要なんだっけ？を考えさせられるからです。
開発に入る前の段階で様々な不確実性の解消と戦っていると、「ユーザーが欲しいって言ったから」「一応これも付けておこう」と、つい開発に入れてしまうものもあると思います。
ここで振り返ることで、この機能や項目は誰がどうやって何の為に使うんだっけ？を考えて価値あるものを作る、無駄なものを作らないことに繋がります。
もうひとつのポイントである「Acceptance Criteria」は、プロダクトマネージャーだけで完結は出来ません。
Acceptance Criteria
Given 〜の場合
When 〜の時
Then 〜なる
「Why」は、なぜこれを作るのかに焦点をあてていますが、「Acceptance Criteria」は「Why」を達成するために何を作るのかに焦点が当たる部分です。
その為に、プロダクトマネージャーが出した「Acceptance Criteria」の通りに作れば良いというものではなく、こういった方が作りやすいであったり、ユーザーが使いやすいであったり価値をアップデートする会話が必要になります。
このユーザーストーリーを元にした会話の重要性が今の組織をアップデートするヒントに繋がると気づきました。
プロダクトチームに展開してみた
学びを浸透してくプランとしては別のプロダクトチームに入りながら確実に定着させていくということを心がけていましたが、嬉しいことにチームAから積極的にユーザーストーリーの話を聞きにきてくれました。
展開した内容としては、Labsと共にやってきた事を説明し、実際にこれから開発するプロダクトに対してサンプル的にユーザーストーリーを書いてみました。
このタイミングの展開では、Labsを経験したプロダクトマネージャー自分１人で説明しましたが、手応えは、、、、あまり無かったです。
エンジニア視点の質問に対して、うまく答えていなかったからです。
プロダクトマネージャーだけで進めるのではなく、エンジニアと一緒に浸透を進めることで両者の視点から学んだことをマージして進めないと浸透が難しいと感じました。
今度は、チームBに展開する際にエンジニア１名プロダクトマネージャー１名で浸透を進めました。
ユーザーストーリーを作る前の段階から一緒に入り、いざユーザーストーリーを書くタイミングでLabsと進めていた書き方で進めていきました。
初めての形式で最初は慣れないものの、やっていく度にやり方を習得している様子が見えました。
そして、Acceptance Criteriaをエンジニアとディスカッションしていく動きが出てきたところがとても大きいです。
今までプロダクトマネージャーは、ソリューションの深掘りはせずにエンジニア側に任せていた部分が多かったですが、そこの対話を増やすことでお互いに開発物に対して認識の齟齬がなくなっていったと感じています。
大事にした点として、ユーザーストーリーの粒度に正解は無く、チームでの合意を作る為のツールだということです。
チームで合意する為に、各ロールを跨いでたくさん会話をして、価値をアップデートさせていく。
その過程がすごく大事なことであることを知ってもらえれば、自ずと価値をアップデートできるように進んでいけると思っています。
最後に
新しい文化の定着には労力がかかり、１人で動くことで壁にぶつかることが多いです。
周囲を巻き込みながら特に違うロールの理解者と共に動くことでチームへの浸透はスムーズになるはずです。
教科書通りにやることで6割ぐらいはすぐに定着するものの、そこから教科書通りにいかないことに対してどのような動きをするか迷うはずです。
その残りの伸び代を引き伸ばす為に、どれだけ一緒のチームで学んだ感覚を伝えていけるかが大切だと認識しています。
また、ユーザーストーリーの書き方を統一し、展開した効果として下記を目指しています。
- 価値あるものを作る、無駄なものを作らない為に、Whyが書けないものは価値があるのか？を考える
- Whyは変わらないが価値を実現する手段は変わる事はあり、エンジニア側と価値をアップデートさせるコミュニケーションを活性化する
改めて生産性に加えて高い価値を出せる組織を目指して、より良い文化定着を促進していきます。
