見出し画像

圧倒的プロダクト力と顧客満足を創るPdMへの道#2_概要設計:要件の深堀

製造業向け生産管理SaaSシステム「スマートF」を開発・販売・サポートしている株式会社ネクスタでPdMとして日々精進しています。

PdMとして色々と経験し、学び、成長することができていますので、振り返る意味でもnoteを使って発信していきたいと思います!

前回からの続きになっているので、もしよければこちらも参考にしてください。


発信内容


もし参考になるとすれば、以下のような状況の方には参考になるかもしれません。

・PdMに関する本や情報はたくさんあると思いますが、やること多過ぎそうで、結局どんなことしてるんだろう?(実際やることめっちゃ多いですが)
・自社にPdMが居ないので、他社はどんなことをしてるんだろう
・自分のキャリアを考えた時、PdMは一つの選択肢だと思っているので、色んなケースを知っておきたい

バックログ管理ツール導入


いきなりですが、管理ツールの紹介をしておきます。
営業、CS、開発、企画がどれだけ情報を蓄積し共有するかが大事なのはどの会社でも変わりません。

私がネクスタにジョインしたての時はRedmineを使ってバックログ(ユーザーや社内からの改善・追加要望依頼)を管理し、そのバックログから開発が開発用チケットを作り管理していました。
この運用に特に大きな問題ではなかったのですが、ちょうどその頃Notionが有名になってきており、多くの情報と関連付ける事ができる点やその使いやすさからネクスタでもNotionを導入しました。

色々議論して最終的にざっくりですが

・Notion
 バックログ作成、優先度管理、状態管理、概要設計
・Redmine
 開発チケット作成、チケット管理、開発工数管理

という具合に分けて運用することになりました。

プロセスは色々苦労ありましたが、結論は大成功だったと思います。

主な理由は

①バックログ起点で種々情報に紐づける事ができる
②使いやすいので、管理項目(プロパティ)の追加/削除をかなり流動的にできる
③ビューで部門ごとに管理すべき項目を整理できる

という点が大きいかな、と思います。
次のタイミング辺りで発信しようと思っていますが、特にPdMはプロダクトコンテンツを創り・メンテすることも重要な責務ですので①の効果は大きいです。

概要設計 その一:要件の深掘り


ネクスタのPdMの最も重要な役割はバックログに対する概要設計です。
従来は開発エンジニアが概要設計→詳細設計→開発を担っていました。
ここに課題があったことは前回も紹介しましたが、重要なので再掲します。

・CS担当者がその時の課題に応じて個々に期待動作を記載するため、他の機能との整合が取れていないことがある
・新機能によって既存ユーザーに影響が出ることがある(今もある)
・開発の各チームで概要設計するので、機能別でUIUXに差が出る
・そもそもその期待動作がなぜ必要か、汎用的な機能になっているかを熟慮する機構がない

そこでPdMが

・なぜこの機能追加が必要か
・たくさんあるバックログとのバランス(実際溢れかえっている)
・既存機能で代替できる運用提案はないか
・既存ユーザーの使い方に影響しないか
・(スマートFの強みでもある)汎用的な機能にするにはどうあるべきか

を理解して、どんな機能であるべきかを考えることが概要設計です。

そしてこれが本当に難しい!!

まず概要設計で最も重要なことは【要件】です。

なぜユーザーはこの機能を必要としているのか?を考えることです。
私自身もまだ要件の深掘りが甘いと認識しています…

ついつい要件に、「この機能にこんな仕様を足して欲しい」という内容を記載しがちです。
(実際社内から上がってくるバックログはこれが多い)
でもこれはなぜか?が含まれていないです。

例えば
・ユーザーは多品種少量生産でマスタを毎回作っている(1日50品種)
・基本的にはパターンがあるが仕様が都度異なるのでその仕様はマスタ作成時に同時に更新が必要
・頻繁ではないがリピートがあるので、マスタは登録して管理しておきたい
という背景があれば

要件は
・マスタを毎回作るのが手間なので、類似品を検索できてマスターコピーしたい

となるはずです。
要件とその背景が正しく理解できれば、

今ある機能で運用できないか?
他のユーザーにも使ってもらえるようにするにはどうすれば良いか

を考えやすくなります。

これがマスターのコピーができないのでコピーできるようにする

と言われても、他のユーザーからはなぜ同じ声が上がってこないのだろう?と疑問が湧き機能実装自体は出来ますが、もしかしたら他のユーザーには使えないものになってしまうかもしれません。

この要件の深掘りが本当に難しい!(再掲)

概要設計 そのニ:要件理解が難しい理由


その一で述べたようにユーザーがなぜその機能が必要かを簡潔に述べた、要件の深掘りはスマートFのプロダクト力向上のためにPdMとして絶対必要なスキルになります。

ただしその要件深掘りのためには

・ユーザーがどんな使い方をしているか
・ユーザーが課題を感じるのはどんなシーンか

を理解する必要があります。

ここで生産管理システムそのものの特徴が影響してきます。
一部の特徴ではありますが、

  • 生産管理システムはユーザー独自の運用ルールが根付いている生産現場に使われる

  • 製造業と言ってもその業種・業態には相当なバリエーションがある

そしてこれらの特徴をパッケージソフトとして提供するスマートFは

  • かなり多くの機能を有している

  • 同じデータを作るにもユーザーの生産パターンに応じて様々な方法がある

  • 設定でそれらを切り替えることができるため設定の理解が必要

プロダクト理解がとても難しいものになっています。

つまり要件深掘りの前提条件として「プロダクト理解」と「ユーザー理解」が必要となり、さらにかなり深いレベルまで把握する必要があります。

PdMはもっとも大変なポジションなど言われていますが、それは管掌する範囲が広いからです。

もちろんそれもありますが、ネクスタにおいてはプロダクト力が会社の強みに直結するので、この概要設計の奥深さも大変さの要因です。

でもだからこそ、

成長を感じることができるし、やりがいの源にもなります!

どうやって要件の深掘りをしていくかについてはやはり有名なJTBD(Job to be Done)が参考になります。
ユーザーケースをちゃんと考えて解決したジョブは何かを考えるに尽きます
私は以下のnoteをよく見返すようにしています。(私もまだまだまだまだ修行中です)

次回の発信内容(予定)


今回はネクスタのPdMの業務の一つである概要設計について説明しました。
かなり大変大変!難しい難しい!とばかり書いてしまっていますが、実はものすごくやりがいがあり、大変だけど楽しいんです。

次回は改めてスマートFの強みの紹介と概要設計への取組み姿勢について紹介していきたいと思います。

ネクスタではPdMを募集していますので、これを読んで少ーーしでも興味を持ってくれた方は自分の経歴など一切気にせずコメントやDMください!
基本何でもお答えします!

■参考:Wantedlyの紹介記事

■参考:Twitterアカウント


いいなと思ったら応援しよう!