プロダクトオーナーがワイヤーフレームを描くということ

　私はスクラムチームのプロダクトオーナー(以下、PO)をしています。日々のプロダクト開発の中でよく思うのが「どこまでがPOのやるべきことで、どこからが開発チーム？」ということです。

　ちなみにこれは「POがやるべきことしかやらない」とかロールにこだわりを持っているわけではなく、自分の立ち居振る舞いとしては「自分がやった方が良さそうなことは自分がやる」と言うスタンスです。

　ちなみにこの言葉は任天堂の故・岩田聡元社長の言葉を拝借してます。

　※　岩田さんの言葉が詰まった書籍の感想はこちら

　話を戻して「POの責任範疇」が気になっている理由は社内でアジャイルのトレーニングや他のチームのPOを支援する時に、何と説明しようかな。と言う点です。

　「自分は自分だよ！」「できる事をやろうよ！」と言うのはその通りではあるのですが、"基本のき"をこれから学ぼうとしている人にはいささか酷な話ですよね。

　それどころか、取り方によっては「なーんだ。別に何かを学ばなくてもいいのか」と捉えられてしまうリスクすらあります。

そこで今までの学びを思い出して行き着いた一つの道がこの画像でした。

　※川口さんのブログから拝借しました。

POの役割は非常に多岐にわたっており、

・ビジネスを推進する

・ビジョンとコンセプトを描く

・開発チームと協働する

などなどたくさんありますし、その表現も人によって異なります。

その中で私が感じたのは

「ビジョンとコンセプトを描いても、それがチームに伝わらなかったら、目指しているプロダクト にならないのでは？」

と言う事です。

そこで先程の画像です。

この画像はJeff Patton氏の「ユーザーストーリーマッピング」で紹介されている画像です。

　実は"インプット"した情報を頭の中で「わかった！」と思っても、それが複雑なものであればあるほど、ずれていることが往々にしてある。

　だからこそ、「わかった！」と思っても一度"アウトプット"して差分を比較し、整えた後に再度"インプット "することで、本当の「共通理解」が生まれる。

と言う事象を表したものです。

　※ 書籍に興味がある方はこちら

ユーザーストーリーマッピング

さて。これはプロダクト開発でも当然起こりうることで、特に私が感じているのは

　POの持つビジョン　と　それを実現するために開発チームがイメージした仕様

でもこの共通認識のズレは日常茶飯事なことなのでは？と思っています。

では、これはどのようにして起こるのかですが、

1. POのイメージを口頭で伝えて、お互いわかった気になってる

2. POに技術的知識がなく、共通言語でのやりとりができてない

3. 信頼関係が成り立っておらず、わかったふりをして会話を終わらせている

など。

2. 3. はPOのスキルセットやチームビルディングの話で普段も語ってきているのですが、今日は1.に言及したいと思っています。

「 POのイメージを口頭で伝えて、お互いわかった気になってる」と言う事象は得てして悪気があってやってることではありません。むしろ、積極的に理解して素早く開発に取り掛かろうとする善意の場合も多いでしょう。

　しかし、それによってすれ違い、手戻りが発生する。そこまでいかなくても、何度も何度も質問や聞き返しを行い、挙げ句の果てには4~5回話してから「図で書くとね・・・」なんてことも。

　いやいや、最初っから図で描こうよ。って話です。

そこで私の中で行っているのが「PO自身がワイヤーフレームを描く」ということです。

　　ワイヤーフレームとはGoogle先生によると

ワイヤーフレームとは 簡単に言えば「何を・どこに・どのように」が記載された「サイト設計図面」です。 つまり、制作するウェブサイトの要素や機能、情報を設計図面のように配置しておき、お客様や制作者と認識を合わせるためのものです

とのこと。(https://liginc.co.jp/web/useful/128790 より)

まさしくこの行為じゃないですか？

「共通認識」を揃えることは顧客とだけでなく、チーム間でも必要です。言い換えると、開発を外注する時にはRFP(Request for Proposal)を描くのに、開発がないせいになると途端に言語に頼り、コミュニケーションに過度な期待を込めている状態なのでは？と思っています。

　そのため、チームとビジョンやコンセプト、そこからプロダクト をすり合わせる時も私は自らワイヤーフレームを描くようにしています。

　デザイナーでもないので正直下手くそだと思います。ただ、図として伝わればいいので、Adobe XDを使ってセコセコとワイヤーフレームを描くようにしています。

　このアウトプットから良い副産物も生まれていて、例えば、営業や決済権限者から

「展示会が入ったから、動くソフトウェアは2スプリント後でもいいんだけど、ポスター作るためにイメージが欲しくて・・・」

(えー・・・見積もり上、数スプリント先って言ってたじゃん・・・)

みたいな時もワイヤーフレームで代行できたりします。

そして、adobe XDが優れているのはそこから、ページ遷移などもできるので、仮説検証時におけるプロトタイプとしても使えます！

　というわけで、POと開発チームの些細なコミュニケーションのズレ、イメージの共有に困っていてついつい「うちの開発チームはセンスがないからな・・・」みたいな事を言っちゃうPOの方やそれ以外の方々。まずは自分でワイヤーフレームを書いてみるのもお勧めします。