本記事について

この記事はプロダクトづくりのための挑戦とその成功・失敗談を綴るアドベントカレンダーpowered byプロダクト筋トレAdventCalendar2022 の24日目の記事です。
本日は非エンジニアかつ非デザイナーである私がPMを担当したプロジェクトについて書きます。
しくじりも踏まえて書いていますので、これからPMを始める方、初めて開発プロジェクトに関わる方の参考になればと思います。

誰のための記事?

「セールスやマーケターからPMになった方」
「これからPMを担当するけど何からやっていいかわからない方」
「PM何それ美味しいの？と思っている方」

自己紹介

靴の販売員から真逆のことに挑戦したいと思い、法人向けの営業支援会社へ転職。
コールセンターやMAツールなどの立ち上げに参賀した後、通販のデータサイエンス部署へ転職。
2022年3月より、UXリサーチャーとして流通小売業界の開発部門を担う会社へJOIN。
直近はWebやアプリの体験設計に携わる。

非エンジニア非デザイナーがPMをやってみた話

自己紹介にも記載しましたがお題の通り、私は非エンジニアかつ非デザイナーです。
少しだけプログラミングスクールでコードを書いたことがあるものの、実務ではSQLやpythonを使用する程度です。
そんな私がPMをやることになりました。PMをやってみて気づいたことや学んだことを書きます。

1.背景や目的を詳しく聞いて言語化する
依頼内容をそのまま受け取ってデザイナーがラフを作成したのですが、後から実はあーで、こーでと追加や修正が入りました。
デザイナーは「え？依頼通りなのになんで？」となったのですが、なんで？となった部分を深く掘り下げてい聞いていくと、
本当に実現したいこと、改善したいことは初めの依頼内容と真逆のことだったり、必要なことが抜けていたりしました。
受け身にならず、どういう背景や経緯か、誰の何のための改善なのか深く掘り下げて聞き、言語化し、
認識すり合わせに時間をかけてデザインのリテイクをなくす方が、確実に早くて良いものができます。
プロジェクトに関わる全員が共通認識を持たなくてはならないのだと再認識しました。

2.mustとwantを切り分ける
デザインもFIXし、開発に入るぞーと思ったの束の間、やっぱりこーしたい、あーしたいという要望が入ります。
ラフを教訓に、よくよくその改善要望を聞いてみると9割はあったらいいな、できたらいいなといった希望や夢でできていたりします。
依頼側も悪気はないのですが、要望を全て受け入れてデザイン修正していたら納期はどんどん遅延していきます。
実際にできればあったら良い機能を実装した時、どのくらいの改善インパクトがあるのか依頼側に確認したところ、
100件のうち1件しかない事象のための機能追加でした。今回は代替になる機能があったので、そちらで納得してもらいました。
mustなのか、wantなのか要望を切り分けて整理していくことが大切です。

3.デザインと開発どちらで対応するのか切り分ける
今回、デザイン修正をきめ細かく対応しすぎたことで、開発に渡すフェーズになってもデザインがFIXできず、スケジュールが遅延してしまいました。そんな折、シニアのデザイナーの方にアドバイス頂いたのは、
「開発スケジュール的に間に合わない時はデザインではなく開発のフェーズで対応してもらう」ということでした。
イラストは難しいですが、レイアウトやボタンの追加、テキストの追加はデザインがなくとも開発フェーズで対応可能です。
また、Webやアプリの場合、解決方法が平面的なデザインではなかったという場合もあります。
（レスポンス速度、モーダルの出し方、コンテンツ内容など）
もちろん開発側との交渉や調整は必要ですが、必ずしもデザインを完璧に！という頭でいなくても進められることを学びました。

4.修正、変更によるデザインや開発への影響を考える
依頼側の要望の中には、「このくらいだったらすぐできますよね」「いい感じにしてください」みたいな言われ方をされるものもあります。
そう言われた時、デザイナーやエンジニアの方は「技術的には可能です」と答えるかもしれません。しかし、心の声はきっとこうです。

・でもめっちゃお金かかるよ
・でもめっちゃ時間かかるよ
・でも作っても意味なくね？
・でも正直作りたくないです

こういった依頼は「ギリギリに要件が決まって」「〆切まで時間がなく」「要件があとから二転三転する」という、
地獄のようなコンボで攻めてくる確率が高いため、デザイナーやエンジニアは恐れています。
そんな時、PMは詳細な技術の知識はなくとも、大まかなデザイン・開発のフローやデータの流れを理解し、
その仕様や変更を行うと部分なのか全体なのかどこに影響しそうか、予測を立てることが重要だと考えています。
そして、依頼側にお金と時間が膨大にかかることやどこにどんな影響があるかなどを明確に伝え、依頼側を納得させる力が必要です。

まとめ

PMは、ドキュメンテーション、問題解決、ファシリテーション、交渉・説得など色々なスキルが求められます。
非エンジニア・非デザイナーだからこその経験を活かし、依頼側のビジネスや業務課題を向き合い、
HowではなくWhyに着目し共有することで最短距離で良いものが作れるということも学びました。
今回の学びを次のプロジェクトにも活かしていきたいと思います。

プロダクト筋トレコミュニティでは
プロダクトを作るために必要な知識は技術だけではなく、事業、ユーザー体験、チームのマネジメント、ドメインの知識などと多岐に渡ります。
そして、そのすべてに長けている人はほとんどいません。
「何を学べば良いかわからない」状態から「自分のレベルがわかる」状態へ、そして「弱みや強みを強化していく」状態へ。
プロダクトづくりに関する知識や考える力をつけるための思考の筋トレをプロダクト筋トレと呼んでいます。
社外の仲間と勉強、議論をし、よりよいプロダクトをつくる筋肉を伸ばしていきましょう。(引用：プロダクト筋トレコミュニティサイトより）
興味を持ってくださった方のご参加お待ちしております。
ご参加はこちらから→https://www.productkintore.org/

最後までお読みいただきありがとうございました。