![見出し画像](https://assets.st-note.com/production/uploads/images/83631741/rectangle_large_type_2_8f87f958f36b69753bffbdd2ab725b89.png?width=1200)
PMとして意識していること3選
こんにちは、株式会社Relicの北川です!
今回はPMとして意識していることをまとめてみようと思います。
いつもに比べるとカジュアルに内容になっていますので、リラックスしてご覧ください!
はじめに
Relicでは今月からIXマネジメントグループが設立されて私はその所属になるのですが、主にPdMやPjMなどが集うグループとなっております。
IXはイノベーターエクスペリエンスのことで、日本語で言うと「事業家体験」となり、Relicが提唱する概念のことです(商標登録済み)。
アイディアを着想してから、事業を創出し、成長・拡大させる間における事業化/起業家視点での体験のことを指します。
このグループになる前身時代から新しいグループになってからも、プロジェクトごとのPM観点での振り返りを行なっており、その当時私が担当していたプロジェクトの振り返りで「PMとして気をつけていること」を洗い出したことをまとめております。
意外と自分でも気付けていない、無意識的に行っていることや意識的に行っていることなどがありましたので、お話しできればと思います!
1.機能の実装優先順位
新規プロダクトを作成する際の機能の実装優先順位決めで、そのプロジェクトの良し悪しが分かるぐらい重要な要素かと思います。
一般的に難しいものと不確実性が高いものを優先して実装を進めて行くことが多いかと思いますが、これらに加えてこのプロダクトにとって最も重要なものを優先して対応するようにしています。
![](https://assets.st-note.com/img/1659099071357-k5PoUio1rc.png?width=1200)
このプロダクトにとって最も重要なものとは、このプロダクトのウリになるもの、このプロダクトたらしめるものとして考えています。
これらの機能を早期に実装し、検証を繰り返すことで技術的な不安や事業的な不安を取り除いたり、検証の際に不安が残るのであれば思い切ってオミットすることも検討できますのでおすすめです!
言葉を選ばずに言うと、難しいもの、不確実性が高いもの、重要なもの、以外は多少課題があっても対処がしやすいので、あまりパワーをかけなくてもなんとかなります!
2.詳細な要件・仕様の認識合わせ
お客様からのご相談やご依頼と、社内開発メンバーからの質問や提案の窓口になるのはどんなときでもPMの私にすることにしています。
詳細の把握をすることでお客様へのご提案やメンバーへの展開時に、既存の仕組みと共存できるのか、あるいは既存の仕組みを流用できるのか、を検討することができるので、プロジェクトマネジメントしやすくなります。
例えば、ユーザー情報に応じて表示する項目を決めるレコメンド部分と、CMSで作成するコンテンツの関連コンテンツに表示する部分も同じレコメンドエンジンを使用することができるか、などを検討しています。
また、社内開発メンバーから出た要件・仕様に関する質問は、お客様から返答後は社内開発メンバーの担当者以外にも把握してもらうためチーム全体に周知することにしています。
社内開発メンバーの別の担当者から、その要件・仕様だとハレーションや仕様バグなどが起きるかどうかを確認するのが目的です。
さらに、要件・仕様の変更履歴を、なぜ変更したのかが分かるように時系列で管理しています。
ある仕様が別の仕様とバッティングしていて仕様バグになってしまうものやものによっては、せっかく作っても発生しえない状態ができてしまいユーザー価値がなくなってしまうものもあるので、仕様の状態を一目で分かるようにするのが目的です。
要件・仕様は変わるものとして割り切って、大きく変えられない箇所を見極めてその部分から実装しています。
大きく変えられない箇所についてはお客様と合意しておくと良いでしょう。
この方法で管理するとあまり手戻りがないです。仮に手戻りがあってもこの要件・仕様管理方法を行えば影響範囲が絞り込みやすいのでおすすめです!
3.社内のラフなコミュニケーション環境の醸成
リモートワーク環境においてもちょっとでも気になる場合はSlackのハドルで相談する文化を醸成しています。
テキストチャットも良いのですが、オフラインのときのように隣の席の人に話しかける感覚で気軽に相談することを良しとすると、そこかしこでハドルが行われるのでプロジェクトの進みが良いと思います。
またハドルをしているところには、誰でもいつでもハドル参加OKな文化にしています。
加えて「今少しハドルよろしいでしょうか?」という前置きもなくハドルを開始して良いということにして、オフラインでリアルに話しかけた時のようなスピード感になります。
とはいってもなかなかそうはなりにくいので、まずは私が上記を実践してモデルになるようにしていくと、それが普通なことにようになっていき、そのうち私がいないところでも、ハドルが行われるようになっていきます。
また最終的には人対人であることを意識することが大事だと思います。
社内開発メンバーに「指示」という言葉は使わないようにしています。
「指示」という言葉には、受動的なイメージがあるのでそうさせないように能動的な言動に導いたり、「指示」には上下関係があるように見えますが、PMはただの役割なのでそう見せないように、こちらもやはり能動性を導いていきます。
またお客様対社内開発メンバーにならないようにコントロールしています。
お客様もステークホルダーがいて大変なんだよなどということを社内開発メンバーには周知していきます。
最後に社内開発メンバーが私と話すことが苦にならないようにしています。
私と話しても解決しないかもしれませんが、話すこと自体が苦にならないことが重要と思っています。
話して解決したらラッキーですし、アドバイスや私ならこう考えるということをたくさん発信することが大事だと思います。
その結果それが良いことであるという風になり、連鎖していきコミュニケーションの量が増え、プロジェクトの進行が良くなると思います。
まとめ
カジュアルにまとめるつもりがいつもぐらいになってしまいましたが、私がPMとして意識している3つのことをまとめました。
この他に自分でも気付いていないこともあるかもしれませんので、その場合はまた別の機会にまとめてみたいと思います。
PMをこれからやってみようと思う方やPMをどうやれば良いか悩んでいる方に参考になれれば嬉しいです!
最後に
Relicではオンライン勉強会を定期的に開催しております。
過去の勉強会は下記リンク先にまとまっていますので、ご覧頂ければ幸いです!
またRelicではさまざまな職種について積極的に採用しています。
新規事業に興味のある方は是非ご連絡ください!
それでは次の投稿でまたお会いしましょう!
この記事が気に入ったらサポートをしてみませんか?