見出し画像

はじめてのプロダクトマネジメント(1) ~建築設計との相関~

最近社内で「PdMとして課題の発見・施策の設計」という研修を行いました。この記事は、その研修から得た学びが大きかったので、忘れない内にまとめておこうと思い執筆したものです。

KPIとは?というところから始まり、現状でもPdMについて全然インプットできていないです。なのでほぼ体験ベースで得た学びを書いているので、バッドプラクティスかもしれません、ご了承くださいませ m(_ _)m

また記事内では、企画考案と建築設計の相関について触れてるので、良かったら読んでみてくださいっ

まとめ

この記事の簡単な要約です。これ以降では、これらについて細かく説明しますので、気になるところを読んでみてください m(_ _)m

企画の考え方 について

  1. ロジックツリーをベースとして、枝をどんどん書き出すべし

  2. 全ては仮説であり「学びを得るための検証」であるということ

  3. データを見れるようになりなさい

作業の進め方 について

  1. 止まってはいけない、迷ったら進めてみろ

  2. 早い段階で成果物を作ろう

  3. 壁打ち = 人に聞いてもらうのは大事

  4. 思考は言葉に囚われる

企画の考え方 について

ここでは企画の考え方・作り方 に関して得た学びについてまとめていきます。

ロジックツリーをベースとして、枝をどんどん書き出すべし

ロジックツリーとはディレクトリ構造のような図のことを言います (恐らく)。この書き方をベースに、それぞれ上のレイヤーに属するものに対する解をどんどん書き足していく方法が効率的だと思いました。

書き方としては、以下の2つともを満たしていることが重要だと思います。

  1. 同じレイヤーのものにすること (ゴール or 課題, 解決策 ..etc)

  2. 同じ粒度のものにすること

全ては仮説であり、「学びを得るための検証」であるということ

これはリーンスタートアップにも書かれている内容であり、実際に社内のPdMの方から頂いたFBです。

企画は実際にローンチしないことには結果の正しさは分からない。仮に仮説が不成立でも問題なく、重要なのはその失敗から何を得るか・次はどうするかが大事。

しかし仮説を検証するまでに、考えを深く及ばせていなければ、結果を見ても学びを得ることはできない

データを見れるようになること (SQLやGAなど)

仮説をいくら書き出したとしても、それに対する証跡がなければ説得力が弱いです。仮説に説得力を持たせるためには、データを根拠にすることが大事だと思いました。

そのために、SQLやGAの見方を身につけ、分析できるようになる必要性を感じました。

作業の進め方 について

次に 作業の進め方 に関して得た学びについてまとめていきます。

止まってはいけない、迷ったら進めてみろ

企画考案のために考慮すべき項目は山ほどあります。またそれらは段階的になっています。
KPI ← ゴール ← 課題 ← 解決策 ← 検証方法 のように(自分の知る限り)

その場合に、1個の段階に長時間固執するのは最善ではないように思いました。

例えば、課題に対して解決策を考えると、生まれた解決策から新たな課題が生まれることがありました。定性的な評価を、定量的な評価に落とし込むと、定性的な評価の課題点が明確になることがありました。それぞれの段階を行き来することで、両者が明確になる体験をしました。

なので迷ったら進めてみること、それにより前後の内容が洗練される、と思いました。

早い段階で成果物 (スライド)を作ろう

一度成果物として書き出すと、現状で足りないものが何か見えてきます

今回の場合、1度発表用のスライドにまとめてみることで、抜け漏れが明確になり議論がさらに進みました。(スライドより前の段階でも良いかもしれない)

壁打ち = 人に話を聞いてもらうのは大事

人に聞いてもらうことで、抜け漏れを指摘してもらえます (当然かもですが、、)

思慮の浅さも指摘して頂けますが、それだけでなく想定していなかったところから槍が飛んできて、視野が広がります。なので早い段階で成果物を作って聞いてもらうことは大事かと思いました。

思考は言葉に囚われる

課題を進める上で「体験の質を上げる」ということをゴールとして置いていました。しかし課題 → 解決案 と話が進む上で、「体験の質を上げる」というゴールにどうも辿り着かない流れになりました。

そこで1度ホワイトボードから「体験の質を上げる」という言葉を消しました。すると色々と議論が進み、より詳細のゴールが生まれました。思考が言葉に囚われていたので、言葉を変えてみるのは有効なのではないか、と思いました。

企画考案と建築設計の相関について

ここはほぼ余談です。

自分は学生時代に建築学科で建物の設計をしていました。今回の研修を経て、企画考案と建築設計って実は相関が高いのでは?と感じました。
ここではそう考えた経緯を説明していきます (もしかしたらチンプンカンプンなこと言っているかも...)。

「止まってはいけない、迷ったら進めろ」 との相関性

建築設計では、建物の敷地での配置 → 平面プラン → 断面プラン→ 素材・建具・収まり... とどんどんと設計対象が細分化されていくのが一般的です。これらは相互に関係しており、平面プランを考えることで建物の配置に修正が生じたり、断面プランを考えることで平面プランに修正が生じたりします。

これは今回の企画考案の際にも同様のことを感じました。建築設計時と同様、迷ったらひとまず前に進めることで、対象の前後の段階について内容が洗練されていくのを実感しました。

「早い段階で成果物を作ろう」 との相関性

建築設計の際には模型をいっぱい作ります。1度模型として表すことで模型から足りない部分が見つかるので、設計し直し再度模型を作り直したりします。

この一連の作業ををスタディと言いますが、今回も成果物にすることで色々と抜けを確認することができたので、企画考案の際でもスタディは大事だな、と思いました。

「壁打ち = 人に聞いてもらうのは大事」 との相関性

建築学科の設計の授業では、週に1回ほどのペースで先生に (大体はプロの建築家)に現状の進捗を共有する、エスキスという時間があります。

その際に先生からFBや抜け漏れを指摘していただくことができますが、企画考案の際の壁打ちはまさにエスキスでした。多くの抜け漏れを指摘して頂きました。

上記のように、私には建築設計とPdMの仕事には相関が高いように感じました。最終的に提供する成果物のカタチは違いますが、価値提供という意味では同じと言える、のかも。

おわり

PMの仕事の一部を体験する今回の研修は大変興味深く、学びが多いものでした。

ただこの記事は実は、最後の章である企画考案と建築設計の相関性の高さが興味深く、言語化してみたいと思い、執筆してみたものです。

この記事に書いた内容以外にも、今回の課題で学んだ「チームでの作業の進め方」に関する学びについても、今後記事にできれえばと思ってます。

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

参考

  • https://www.amazon.co.jp/dp/B00F3UTIQY

この記事が気に入ったらサポートをしてみませんか?