キャリアのスタートはグラフィックデザイナー
沢田俊介氏：それでは、「クリエイターとしてのPdM」ということで、少しだけお話しさせてください。
私は、グラフィックデザイナーとしてキャリアをスタートしています。UIデザイナーやソフトウェアエンジニアなどいろいろと経験があるので、それらを活かして今はプロダクトマネージャーとして活動しています。
業務以外にも、教育プラットフォーム「Udemy」でプログラミングやエンジニアリングの講座を公開していたり、この間はデザインツールである「Figma」の本を書きました。
今回お話しする私の「プロダクトマネージャー」は、狭義のプロダクトマネージャーであるということを最初にお伝えしておきます。
広い意味でのプロダクトマネージャーというのは、プロダクトのビジョンやミッションなど、経営的な目線で考えることもありますが、ここで私が言っているプロダクトマネージャーは、よりプロダクトそのものを作るというプロダクトマネージャーです。かなり狭い範囲のプロダクトマネージャーであるということを先に申し上げておきます。
プロダクトマネージャーに必要なこと3つ
プロダクトマネージャーに必要なことは3つあると思っています。まず、開発のコアメンバーであるということですね。プロダクトチームの外にいて仕様を渡すだけの人というかたちではなく、実際に手を動かしてワイヤーを描いたり、仕様を書いたり、デザインしたり、というかたちでプロダクトをどんどん作っていく。そういう必要があると思っています。
2点目、広めの知識とオーナーシップについて。これは当たり前かもしれませんが、「ビジネスとUXと技術をつなぐ」という点で、広い知識とオーナーシップが必要です。プロダクトへの愛着とおっしゃっていた方もいましたが、そういった意識が必要であるということです。
最後に、あくまでプロダクトの責任者であるという意識も必要だと思っています。これは、いわゆる管理職ではないという意味です。メンバーの評価もしませんし人事権もないので、あくまでプロダクトの責任者であるという意識が必要かなと思っています。
理想的なPdM像
私が思う理想的なPdM像ですが、制作者がそのままPdMになるのが一番いいと思っています。というのも、プロダクトマネージャーがいないチームがやはり一番いいんじゃないかなと思っているからです。
プロダクトマネージャーを自分がやっていて何を言っているんだという感じですが、メンバーそれぞれが自主的に動いてリーダーシップを持ってやっている、それが一番よいチームだと思っています。
ただ、そうは言っても、誰かがリーダーシップを取っていかないと前に進まないチームもあるので、そういう時に必要になってくるという意味で、制作者がそのままPdMになるのはすごくいいかなと思っています。
2点目として、サービスのリリースと運用経験はかなり重要だと思っています。個人プロジェクトでもいいのですが、なにかしらを自分の手で作って、それをリリースして運用する経験というのは、非常に役に立つと思っています。
GNUS（ヌース）における業務
先ほどのセッションで「GNUS（ヌース）」という言葉が出ましたが、GNUSという組織、具体的な業務をどのように行っているかをお話しします。
まずは要求整理ですね。クライアントがいろいろ言ってくることを整理整頓する項目があります。その次にデザインとプロトタイピングがありますが、私のバックグラウンドが少し特殊でデザイン出身なので、この時点でデザインとプロトタイピングを作って、先方と認識合わせをします。
そのあとに仕様書。アジャイルの方針で開発をする場合「ユーザーストーリーだけあれば良いよね」となりがちですが、それだと何をどう作っていいのか議論が進まないことがあるので、私がデザインやワイヤーフレームを描くこともあるし、APIに関してもかなり突っ込んで仕様を決めていくこともあります。
このとおり作ってくれと言うわけではなく、それを基にチームで話し合うという位置づけで、仕様書は作っています。
そのあと、実装、受け入れテストをして、リリースの準備。そんなかたちですね。
スライド（具体的な業務（GNUS））
予算管理と交渉は業務外
やらないことについて。予算の管理と交渉はやりません。GNUSには、エンゲージメントマネージャーがいて、その方がクライアントと直で予算の管理をします。スケジュールはプロジェクトマネージャーにお願いすることが多いです。
先ほどとちょっと重複しますが、（プロダクトマネージャーは）あくまでプロダクトの責任者なので、メンバーの評価など管理職的なことはやりません。
PdM業務の中で大切にしていること3つ
ここから、業務の中で大切にしていることを少しお話しします。私は、顧客が本当に欲しいものというのを常に意識しています。
クライアントからいろいろ言われるわけですが、オリエン（オリエンテーション）を鵜呑みにしないということです。実際に「これが欲しい、あれが欲しい」と言われるわけですが、最終的にできるものがそれと全く違うものであることが多いです。
「クライアントは、ものができるまで自分が何が欲しいと思っているかわからない」ということを前提にして、いろいろ質問をして、本当の問題は何か？ を突き詰めることを大切にしています。
2点目は、クリエイターとして検証を高速に行うということですね。みなさんの中にはエンジニアが多いので、エンジニアとしてのバックグラウンドを活かして、なにかしら動くものを作って高速に検証を行う。
この場合、検証というのは、クライアントとのテストだったり、ユーザーテストだったりといろいろありますが、とにかく共通認識をここですぐに作ってしまうというのを大切にしています。
3番目に大切にしていること。3段階のフィードバックというものがあって、クライアントから来る要求が左側にあります。
最初に私がPdMとしていろいろとフィードバックを返します。実はこっちのほうがいいんじゃないですか？ とか、この問題解決をしたいならやり方はこうじゃないんですか？ とか、ここでいろいろフィードバックを返します。
そのあとに、デザインや要件が決まって実際に仕様を作って、チームに共有します。
先ほども言いましたが、ここで完全に決め切るわけではありません。こんなかたちで作りたいんだけど、どうか？ とチームに相談します。するといろいろとチームから意見が出てくるのでそれをまた要求に反映していきます。
最後に、実装とあります。ここが一番ボリュームが小さくなるべきですが、いろいろと実装をしていくと、こっちのインタラクションのほうがいいんじゃないかとか、考慮漏れがあったりするので、ここでもフィードバックを要求に返していくということをやっています。
最後に、内側からの「こうしたい」と書きましたが、真ん中のチームからのフィードバックを私はとても大切にしています。
PdMのフィードバックのボリュームが一番大きいのはそのとおりで、実装が一番小さいというのが理想的ですが、仕様がこう決まっているからこう作らなければならないという考えをメンバーが持たないように気をつけています。
ユーザーのためを思ったら実はこっちのほうがいいんじゃないかとか、この仕様は破綻しているとか、そういう意見をどんどん出してもらって手を挙げてもらう雰囲気を作って、できるだけそれを要求に反映していくということを大切にしています。
なので、もちろん、スケジュールに収まればという前提がありますが、1度決まったものでもひっくり返して要求に返していくということもどんどんやっています。
なぜフリーランスを選んだのか？
ここからは、フリーランスという形態について。先ほどのセッションでお三方が「フリーランスは部外者という感じに思われませんか？」という問いに対して「そんなことはないよ」とおっしゃっていましたが、そのとおりだなと思っています。
プロダクトへのコミットとコミュニケーションができていれば、逆に組織の中心になると思っています。フリーランスは、あくまで雇用形態であり、あまり関係ないんじゃないかなと思っています。
「じゃあ、なんでフリーランスをやっているんですか？」という問いがあると思いますが、単純にこれはすごく現実的な話、単価と手残りが大きくなりやすいからです。クライアントには固定費ではなく流動費のように捉えてもらえますし、保険や経費などが一切かからないので、単純に単価が上がりやすい傾向があります。
また、法人化、個人事業主など、いろいろと節税の方法があると思います。なので、手残りが大きくなりやすいというのはそのとおりだと思っています。
2点目として、自分のプロジェクトの時間の確保ですね。最初にあったUdemyでの講座や、本を書く時間を私はすごく大切にしているので、そういった時間も確保する。例えば稼働を50パーセントから80パーセントに抑えて、残りの時間で自分のプロジェクトをやりたいというモチベーションがあるのでフリーランスを選んでいます。
一方で、私の友人には、帰属意識というか仲間という感じがなくなるので、正社員に戻る人もいました。私もこれはすごくわかります。フリーランスとしては少し寂しい感じもあります。
クリエイターとしてのPdMとフリーランスとしてのPdMというお話をさせていただきました。ありがとうございます。
