アジャイル・DevOps＃２　「プロダクトオーナーの難しさ(2/2)」

この記事のきっかけ

そもそもプロダクトオーナーをこの連載のトピックとして取り上げようと思った理由は、プロダクトオーナーをあまりに軽く考えている方が多い気がしているからです。前回、プロダクトオーナーについて、

「要望を出す人でしょ？」

と思っている方が多い、というお話をしました。開発チームに対して「こんなものを作って」 と言えば終わり、と考えている方がとても多い。そのため、プロダクトオーナーがスクラムチームの一員であり、基本的に専任でなければならない、というお話をすると、とても抵抗感を示されます。そういう方々には、前回取り上げた2つの強調点をお話しして、まずプロダクトオーナーの重要性を理解していただきます。

その上で、プロダクトオーナーへの「インプット」と「アウトプット」をお話しします。

プロダクトオーナーへのインプット

プロダクトオーナーは、要望を出す人ではなく、まずは、ユーザーや利害関係者からの要望を聞く人です。単にいろんな人の要望を聞いて、それをまとめて開発チームに伝えればいいのではありません。該当するビジネスとその手段としてのシステムで何をめざすのか、組織全体の戦略上の位置付けは、というような根本を理解し、システムの方向性を決める必要があります。プロジェクトの旗振り役だというお話をしましたね。

ユーザーや利害関係者は、必ずしも全体を理解して要望を出してくれるわけではありません。相矛盾する要望も出てくるでしょう。旗振り役がそれに振り回されて、「えっと、こっち...かな」 「いや、やっぱりこっち」 と迷っていては、効率のよい開発はできません。プロダクトオーナーは開発の「芯」をしっかり持ちつつ、時にはワガママな利害関係者を説得する必要があるでしょう。

難しいのが、この方向性が、プロジェクト期間中必ずしも固定ではないことです。本当に行く先が固定であれば、プロダクトオーナーは最初に船の舵をセットしたら、後は開発チームに任せればいいはずです。しかし、時にビジネスの状況に応じて、方向性の変更を決断しなければいけないこともある。だからこそ、プロダクトオーナーはスクラムチームの一員として、同じ船に乗っていなければいけないのです。

プロダクトオーナーからのアウトプット

プロダクトオーナーのアウトプット先は、開発チームです。プロダクトオーナーはシステムのビジョンや要件を矛盾なくチームに伝える必要があります。この際に、「開発チームへの横入り」 を許してはいけません。

最近、「真の要件は廊下で決まる」 という言葉を聞き、思い当たる節がありすぎて苦笑いせざるをえませんでした。要は、取り入れる要件を決める 「要件変更管理委員会」 に多くの時間をかけるものの、結局はその会議終了後の廊下で開発者に直接ネゴして自分のやりたいことを入れようとする、開発者も知っている人に頼まれると、断りづらい、という状態です。

プロダクトオーナーは、スクラムチームへの要件の入口は自分だけ、ということを明確にし、脇から入る要望／要求／要件を許さないこと。これを許してしまうと、開発チームの隠れた工数がどんどん積み上がっていきます。システムの方向性にも統一感がなく、チームの効率が悪くなります。

全体的な方向性の旗振りだけではなく、開発チームからの細かい仕様の質問に日々答える必要もあります。「この機能ってこれでよいですか」 「画面イメージちょっと確認してください」 等々。アジャイル開発では、ドキュメントで仕様を「固定」しない代わりに口頭でのコミュニケーションが増えます。こういう細かい対応のために、プロダクトオーナーはできるだけ開発チームの近くにいる必要があります。ちょっと席が離れているだけでも、この確認はしづらくなる。確認が後回しになると、開発チームが手待ちの状態になったり、思い込みで開発を進めることになり、前回取り上げた2つのポイントの2つ目「開発の効率」を下げてしまいます。

伝える側の方へ

いかがでしょうか。プロダクトオーナーに対する教育・研修内容というと、ユーザーストーリーの書き方やスクラムの各イベントでの振る舞い方などが出てきますが、それ以前にここ2回でお話ししてきた、WhyやWhatがまずは重要だと考えています。ストーリーやイベントのHowはその後です。プロダクトオーナー候補の方には、システム開発側から 「こういうことをしてください」 という説明をされることが多いと思いますが、まずはWhyやWhatを理解していただきましょう。

率直に申し上げると、いくら研修を受けたからと言って、開発側から見て理想的なユーザーストーリーを最初から書けるプロダクトオーナーは、まずいません。特に初めての方は、スクラムチームで協力してユーザーストーリーを作成する、くらいのつもりでないと、適切な粒度と詳細度にはならないでしょう。そういう協力関係を作るためにも、「プロダクトオーナーがいかに重要で、なぜ重要か」 をスクラムマスターや開発チームがプロダクトオーナーに説明する必要があります。

最後に一点。開発側の方がプロダクトオーナーに説明する際には、特に用語に注意してください。とりわけスプリント、バックログというようなスクラム用語は、相手が知らないことを前提に、ゆっくり／何度も説明してください。馴染みのない用語というのは、それだけで心理的な障壁になります。一度説明してもらった用語を、「分からないからもう一回説明して」 とは、なかなか言いづらい。会話の中で頻繁に出てくる用語でも、直感的な理解にまで至っていないと、理解に時間がかかり、とてもストレスになります。用語にはくれぐれも配慮して説明してください。

真のプロダクトオーナーが旗を振るからこそ、スクラムチームという船は正しい方向に進めます。

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。