圧倒的プロダクト力と顧客満足を創るPdMへの道#5（概要設計の不足を振り返る）
製造業向け生産管理SaaSシステム「スマートＦ」を開発・販売・サポートしている株式会社ネクスタでPdMとして日々精進しています。
PdMとして色々と経験し、学び、成長することができていますので、振り返る意味でもnoteを使って発信していきたいと思います！
前回からの続きになっているので、もしよければこちらも参考にしてください。
発信内容
もし参考になるとすれば、以下のような状況の方には参考になるかもしれません。
・PdMに関する本や情報はたくさんあると思いますが、やること多過ぎそうで、結局どんなことしてるんだろう？（実際やることめっちゃ多いですが）
・自社にPdMが居ないので、他社はどんなことをしてるんだろう
・自分のキャリアを考えた時、PdMは一つの選択肢だと思っているので、色んなケースを知っておきたい
リリース後のテスト
以前もお伝えしていますが、スマートＦは毎週バージョンアップしています。
プロダクトミーティングを経て開発エンジニアに渡ったバックログがリリースされて行きます。
とは言え、このスピード感で開発、デプロイするとなるとちゃんと動いているかのテストは必要です。
この記事を作成時点（23年6月）では、ネクスタにはQA部隊がありません。
なので企画グループのもう1人のメンバーが主にテストを実施します。（企画グループは私とその一名の計2名、23年6月時点）
週次のスプリントでデモ環境にアップされた機能を操作して
・概要設計通り動いているか
・他の使い方をした時に動作するか
・いざ使ってみると使いづらいので、こうした方が良い
をバックログ単位で確認します。
スピードと品質はトレードオフなので、やはり100%完璧な状態で全てのバックログがデモアップされることは稀です。
また「他の使い方」がどこまで網羅的か。についても今はテストする人に委ねています。
テストケース作成など試みているのですが、いかんせん週次のテストケース新規作成・更新工数が膨大になり、肝心要のテストが出来ない。という感じです。
（ある程度使い方が固定的かつ利用ユーザーが多い機能はテストケースを作成し、外注することもありますが）
スマートＦの高速なバージョンアップは品質問題ともバランスを取りながら実現しています。
QA部隊ができ、設計の段階から品質も加味した仕組みを立ち上げることでより強力なプロダクトになることは間違いなし！です。
テストできる人の採用は継続的に募集中です
QA部隊ができるまで何もしないわけには行きませんので、ある程度勉強はしているところです
リテイク分析
ネクスタではテストで上手く動作しない、概要設計と違う、などの事態が発生するとテスト担当がリテイク依頼という別のバックログを起案します。
つまりテストしたけど〇〇だったので、こうあるべきと記載されたものです。
QA部隊ができるまで。と手をこまねいていてもどうしようもないので、なぜやり直しが発生したのかを要因分けして週次で確認しています。
主な要因は要件未達（開発起因）、設計不足（PdM起因）、追加機能です。（厳密にはもう少し細かい）
これが大切で、開発は開発チーム単位で振り返りしていますし、私自身もPdM起因のものは全て確認して再発防止を必ず記載しています。
内容は様々ですが、例えば書き漏れ。など小さな要因でその対策は「意識」の問題だったとしても、それを把握しておくことは非常に重要です。
ネクスタの凄いところは、こうした仕組み作りと改善のタネを見過ごさない文化だと思います。
リテイク分析に至るまで
上述したようにテストで発覚した開発へのやり直し依頼（リテイク）ですが、この仕組みも今に至るまで改善がありました。
もともとはリテイク依頼を元のバックログのプロパティに記載していました。
1バックログに対して、1リテイクなら良いのですが、バックログによっては1つのバックログに対して複数のリテイクが含まれていることもありました。
開発からどのリテイクが優先なのかが分かりづらいという課題提起があり、いまは1リテイクごとにバックログを作り直しています。
これによってリテイク要因分析もかなりやりやすくなりました。
この改善は開発から問題提起があった2〜3日後には仕組み修正して実施したと思います。
このスピード感はスマートＦのバージョンアップだけでなくネクスタの中でも発揮されています。
PdM起因の分析
リテイク要因分析をして設計不足（PdM起因）は、私にとっては貴重な失敗履歴です。
少しだけ実例で紹介したいと思います。
事例①：ボタンのショートカットを把握して概要設計する
問題）ある画面に日付を手動で登録できる機能を追加。日付のフォーマットはYYYYMMDDだけで考えていたがYYYY/MM/DDのパターンもあり、/がその画面でショートカットになっていたため、日付を入力出来ない
事例②：複数のユースケースを加味して概要設計する
問題）バーコード読込みする際にバーコードによっては含まれている情報が少ない時があり、新しい機能追加による短縮機能のせいで入力出来ないケースがある
事例③：新機能によるデータ作成が別の画面からは作成出来ない
問題）同じデータを作成するにもスマートＦの場合は複数パターンあり、あるパターンの場合に適用する設計が漏れていた
などなどです。
他にもたくさんあるのですが、ここで伝えたいことは、
こうして自分のミスを振り返る仕組みが必要で、
それがネクスタにはある
ということです。
次回発信内容（予定）
今回はテストからリテイクまで紹介しました。
なかなかプロダクトコンテンツに行き着きませんが次回は発信できそうです。
上述したようにスマートＦの高速な進化を実現するには様々な仕組み作りと改善が不可欠です。
こうした文化はスタートアップの醍醐味なのかもしれません。
PdMに限らずいくつかの職種についても募集中なので、PdM以外でも聞きたいことがあればなんでも質問ください。
特にQA経験者は大歓迎です！
■参考：Wantedlyの紹介記事
■参考：Twitterアカウント