こんにちは、アドプラットフォーム事業でPdM（プロダクトマネージャー）をやっています、ヒロセです！
PdMといっても歴は半年以上1年未満、頭の上に殻がのったヒヨコを思い浮かべていただけると助かります。実際そんな光景は見たことないけど、ヒヨコってどんな風に生まれるんでしょうかね？
さて、そんなひよっこPdMの私から、「知識も経験もない新米PdMがスクラム開発をやるためにやってよかったこと」をお伝えします。
結論、下記3点です。
- チーム全員で知識を共有しよう
- スクラムの基礎をちゃんと学ぼう
- ポンコツであれ
……ですが、この結論にたどり着くまでにめちゃくちゃ失敗したので、ちょっとその話からさせてください。
背景と問題
私が所属するアドプラットフォーム事業では、自社プロダクトをより良いものにするために組織を小さく分割し、いくつものプロダクトチームが発足しました。 私もそのうち1つのチームのPdMとなり、自分を含めて8名のチームで開発を行うことになりました。
チームのメンバー構成はこんな感じ。
さて、開発やるぞ！と意気込んだのもつかの間。
スタート時点で3つの 「ない」 に直面しました。
- 開発するプロダクトのドメイン知識がない
- スクラムをやったことがない
- メンバー同士の関係値がない
びっくりするぐらい、何もない！
私はこれまで別プロダクトのディレクターだったので、今回開発するプロダクトについてのドメイン知識はほとんどなく、現場感もわからない。スクラムが何なのかもよく知らない。
チームは若手～中堅メインで、中には中途採用で社歴半年にも満たないメンバーもおり、ほぼ全員初めましての状態。
さあ、波乱の幕開けです。
やらかした失敗
3つの「ない」を抱えて走り出したチームは、まさにカオスという言葉がぴったりの完全手探り状態。当然、たくさんの失敗をしました。具体的にどんな失敗をしたのか、簡単にご紹介します。
1．開発するプロダクトのドメイン知識がない＝要件定義に時間がかかり、開発のリードタイムが伸びた
幸いにも開発するもの自体はある程度決まっていたため、要件定義から始めることにしました。
本来ならPdMがおおまかに決めるべきところですが、ドメイン知識がないゆえに 「この機能はあったほうがいいのだろうか」「ここは現場でどう運用されているのだろうか」 と疑問・モヤモヤが噴出。
MVPを決めるための判断基準を一切持てなかった結果、社内ドキュメント漁りや現場からの意見集めに多くの時間を費やし、要件定義が数スプリントにわたって延びてしまいました。
結果、開発期間と同じくらい要件定義に時間がかかり、リリースまで約2か月を要してしまったのでした。
2．スクラムをやったことがない＝ウォーターフォールに陥った
スプリント？ プロダクトバックログ？ ストーリーポイント？
単純に1週間サイクルで開発するだけとちゃいますのん？ と、スクラムの本質を一切知らないPdMでした。
それゆえ、スクラムの本質である 「小さくつくり、早く改善する」 を体現できませんでした。毎週スクラムイベントを繰り返してアジャイルっぽいことをしているものの、振り返ってみればウォーターフォールに近かったと言わざるを得ません。
ウォーターフォール化の要因は、 「要件定義に時間をかけ、大きすぎるMVPを定義してしまった」 ことにありました。 開発着手前にガチガチに要件定義をしようとしすぎて、 「価値があるか判断できる最低限の機能」 の範囲が広がってしまったのです。
結果、開発着手が遅れ、ステークホルダーに動くアウトプットを見せるタイミングが遅くなってしまいました。
3．メンバー同士の関係値がない＝どこまで意見していいか探りあってしまう
チームメンバーはみな私よりもずっと社会経験のある方ばかりなので、初めましてであっても問題なくコミュニケーションはとれていました。
一方で、「これを言っても大丈夫だろうか」「質問したいが、自分の知識や調査不足かもしれない」と遠慮する場面もちらほら。
みんな大人で、配慮ができる素晴らしい人たちだからこそ、不必要な遠慮をなくして建設的な議論をするために、チームビルディングをゼロからやる必要があると感じました。
3つの「ない」に対して取り組んだこと
先述のとおりたくさんの失敗をしましたが、同じくらいたくさんのトライもしました。（ようやくタイトルの内容です、お待たせいたしました。）
やってみてよかったトライを3つご紹介します。
1．チーム全員で知識を共有しよう
ドメイン知識不足に対するトライとして、 「とにかくチーム全員で知識をシェアする・同じ定義を持つ」 を徹底しました。
具体的な行動としては以下です。
- PdMだけではなく、エンジニアやデザイナーもステークホルダーとの会議に常に同席し、チーム全員で状況を把握する
- ユビキタス言語を策定し、いつでも見返せるドキュメントに集約する
特にユビキタス言語をドキュメントにまとめたことで、チーム内で使用する言葉の定義に迷うことがなくなったり、「そもそもこれって～」系の質問が減ってコミュニケーションしやすくなりました。
（ちなみに、ユビキタス言語の策定を提案してくれたのは中途入社されたエンジニアのDさんでした。こういうのを率先してトライしてくれるエンジニアってかっこいいですよね。）
こうしていつもチーム全員で動くのは非効率的に見えますが、結果的には効率が良かった気がします。PdMだけがステークホルダーと話をしてエンジニアとデザイナーに要件を伝えようとすると、経験の浅い新米PdMではエンジニアやデザイナーが求める粒度・表現で伝えられず、再確認や認識のズレが起こりやすいからです。
成熟したチームは別ですが、新たに発足したチームではまず全員でステークホルダーの話を聞き、同じ理解レベルを持つのは重要だな～と感じました。
2．スクラムの基礎をちゃんと学ぼう
めちゃくちゃ当たり前のことですみません。 でも、PdMこそスクラムの本質や意義を理解する姿勢を常に持つべきです。「小さくつくり、早く改善する」を体現するのはエンジニアだけではなくPdMの責任でもあるからです。
スクラムイベント自体はスクラムマスターが管理進行してくれますが、 「このスプリントでどんな価値をつくり、ステークホルダーからどんなフィードバックをもらうか」 を決めるのがPdMの仕事です。
偉そうに言っていますが、私がそれに気づいたのは10スプリントくらいやってからでした。スクラムってまじで難しいですね……。
PdMとしてスクラムを理解するときには、スクラムをただの会議用アジェンダにするのではなく、マインドをスクラム（アジャイル）モードにするよう意識するのが大事かなと思います。それができるのが社内でのRSGT動画視聴＆勉強会でした。
RSGT動画とは：スクラムに関する大賢人みたいな人たちが、現場の経験からいろんな話をしてくれる動画シリーズです（ちゃんとした説明はこちらからどうぞ）
これらを社内のスクラムマスターやエンジニア、PdMたちで視聴して、付箋を出しながらわいわい意見交換する機会があったので、自然とスクラムについて自分の中に落とし込むきっかけになりました。
3．ポンコツであれ
良いアウトプットをつくるためには、ロールを超えて意見しあえる雰囲気づくりが超重要です。
ときにはデザイナーがつくったUIに対してエンジニアやPdMがフィードバックをしなければいけないし、PdMが出した要件に対してエンジニアやデザイナーは突っ込みを入れなければなりません。
弊チームはみんな大人で配慮のできるメンバーばかりだからこそ、気遣いの壁を取り除く必要がありました。そこで実施したのが 「ドラッカー風エクササイズ B面」 です。これがすごく良かったのでご紹介させてください。
メンバー間の期待値をあわせるフレームワークとして有名なドラッカー風エクササイズですが、実は「B面」なるものがあるんですね。
まず通常のドラッカー風エクササイズでは、以下のようなポジティブな質問に答えるのが一般的です。
- 自分の得意なこと
- 仕事のやり方
しかし、B面では逆です。
- 自分の苦手なこと
- 自分がされるとモチベが下がること
- 過去の失敗
こうした、あえてネガティブな質問に答えていくのです。
自分の弱みや不得手を開示することで、期待値のハードルを良い意味で下げられます。そうすると「みんな完璧じゃないし、お互いに支えあってこ！」という意識づくりに繋がるんですね。
実際にチームで実施したドラッカー風エクササイズB面の様子はこんな感じ。
BとついているのがB面の質問です。
たとえば「むかしチームメンバーの期待に応えられなかった事件はある？」という質問に対し、私は「新卒1年目でタスクや責任を一人で抱えすぎて休職したことがある」と素直に回答しました。こうしたキャリア上のバックグラウンドを開示することも、チームメンバーの仕事ぶりを理解する一助になります。
ただし、B面を使う際の注意点が1つあります。
ネガティブな開示と一緒に「学び」や「宣言」を伝えることを忘れない、です。
- 「抱え込みすぎて休職したことがあります」＋「だからこそ自分にできないことは周りを頼るし、感謝しながら常にアップデートする姿勢を大切にしています」
- 「要件の問題を黙認して開発し、負債になってしまったことがあります」＋「だからこそ、売れない機能だと思ったら遠慮なく意見します」
こうしたネガティブな自己開示＋ポジティブな姿勢の宣言をセットで出し合うことで、良いプロダクトをつくるために会話しよう、という雰囲気がつくりやすくなります。
もちろん、自分の失敗を共有するのはすごく勇気がいります。
しかし、「この人が言うならそうしよう」や「この人が出したアウトプットだから間違いない」みたいな盲目的な進行を防ぐためにも、重要なマインドではないかと思います。
私はこれを自戒を込めて「 ポンコツであれ」 という教訓にしています（心の中で）。プロダクトチームよ、ポンコツであれ！
まとめ
長くなりましたが、知識も経験もない新米PdMがスクラム開発をやるコツとして下記3点をご紹介しました！
- チーム全員で知識を共有しよう
- スクラムの基礎をちゃんと学ぼう
- ポンコツであれ
特に経験の浅い新米PdMは、自分一人で何とかしようとせず、適切にチームを頼り、些細な悩みも可視化してチームへ共有する習慣をつけると良いと思います。
チームの意思決定役として、ついつい「自分が決めなければ…！」と力んでしまいますが、 「基本的にポンコツだけどやるときはやる！」 くらいのスタンスで及第点ではなかろうか…というのが、新米ポンコツPdMとしての所感です（こんなPdMを支えてくれるチームの皆さん、本当にいつもありがとう）。
もちろん、常にあやふやなことしか言えないのはチームの方向性がブレてしまいよろしくないので、しっかり悩みを共有・相談したうえで 「じゃあ、これでいきましょう！」 と最後にはっきりと判断を言葉にする姿勢は貫くよう、改めて意識したいところです。
良いプロダクトは良いチームから。引き続きチームを大切にしてがんばります～！
