開発メンバー全員で新規開発アイテムのディスカバリーに挑戦した話

plain

はじめに

こんにちは。SmartHRプロダクトマネージャーのninomiyaです。

この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。 25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！

今回は私が担当しているプロダクト「人事評価」で「開発メンバー全員で新規開発アイテムのディスカバリーに挑戦した話」を取り上げます。普段PMとしてディスカバリーを進めている方や、チーム全員でディスカバリーをやってみたい方にとって、少しでも参考になることがあれば幸いです。

この記事で使う用語の意味

人事評価とは、従業員の目標設定や評価査定に関わる業務を効率化し、タレントマネジメントに活用できるデータの蓄積ができるプロダクトです。
開発メンバーとはPM、エンジニア、デザイナー、UXライター、QAのことを指します。
ディスカバリーとはユーザーヒアリングや課題の特定、ソリューション検討といった開発着手までに行う探索工程のことを指します。

背景

プロダクトのリリースから2年が経過し、今後のより大きな成長につながる開発アイテムの候補として上がったのが、「評価調整業務に関する機能」を強化することでした。

このアイテムにすぐに着手したかったのですが、評価調整業務は各社各様のやり方があり、腰を据えたディスカバリーが必要でした。

しかし、これまでのやり方は、PMを中心にディスカバリーを行いPRDを作成して、PRDをベースに開発メンバーと仕様を落とし込み開発するという流れで進んでいたため、開発着手までにリードタイムが発生するという問題がありました。
そこで開発チームを巻き込んでディスカバリーをすることを考えましたが、私たちのチームでは全員でディスカバリーを経験したことが無く、混乱を生むかもしれないという不安がありました。

私はチームメンバーに「今までと違ったやり方でカオスになるかもしれないけど、チーム一丸でこの機能を早く提供したい！」と正直に伝えたところ、「カオス乗り越えちゃいますか〜」、「私は好きですよ！」など、想定以上に前向きな反応があり、私が感じていた不安は思い込みであり、必要以上にひとりで抱え込んでいたことに気付かされました。後押ししてくれたチームメンバーには本当に感謝しています。

そんなことがあり、「評価調整業務に関する機能」のディスカバリーにチームで挑戦することになりました。

取り組んだこと

ディスカバリーは以下のステップで進めていきました。それぞれのステップで、チームで行って良かったことを中心に説明します。

ユーザーヒアリング

まずは評価調整業務について理解するために、ユーザーヒアリングを2週間で10社近く行いました。その中で意識したことは以下の４つでした。

ヒアリングにはPMMとPMだけでなく必ず1名は開発メンバーが同席する
ヒアリングに出ていないメンバーは必ず録画を確認する
ヒアリングの日に手分けをして業務フロー図を作成する
振り返りを行い「分かったこと」「分かっていないこと」「疑問」などを挙げて次のヒアリングで深掘りたいことを全員で洗い出す

一次情報に必ず全員が触れることで、各メンバーのユーザー理解度が格段に上がるとともに、チーム内での共通認識ができ、後々のコミュニケーションがスムーズになりました。

業務の分類

ヒアリングをある程度進めていくと、各社各様の「評価調整業務」を行っていることがわかりましたが、ある程度パターンがあることも分かってきたので、分類をしていきメジャーケースを定義しました。

pattern

この作業を行うことによって、メンバー間で議論する際に「評価調整業務」のどのパターンの話をしているのかという共通理解として役立ちました。

解決する課題、しない課題の特定

ヒアリングで新しい発見もなくなってきたので、課題を特定する段階へと移りました。しかし、チームで進めていくとどうしても話が発散してしまい、収束に向かうのが難しい状況に陥りました。

この状態の改善のため、同僚PMと各社に共通する業務を構造化し、解決する課題の範囲とやらない範囲を整理しました。このとき、チームでは多くの企業に共通した課題だけでなく、一部企業に共通する課題（下の図でいうと「枝」）も解こうとしていたために、議論が発散していることに気が付きました。

edamiki

この整理によって解決する課題が明確になり、やらないことに対する議論の発散を防ぐことに繋がりました。検討に煮詰まった時は、誰かに壁打ちをお願いすることが大事です。

有識者にヒアリング

チームの中では議論も収束に向っているものの、我々が解決しようとしている課題の方向性がこれで良いのか？という不安がつきまとっていました。そこで、SmartHRとお付き合いのある人事コンサルの方のお時間をいただき、考えている課題仮説についての意見をもらいました。
それによって、我々が課題と思っていることと、人事コンサルの方が課題と思っていることに大きなズレがないことが分かりました。また、各社各様の業務1つ1つに対応するのは難しいことがわかり、「枝」の解決に向かうことが良い手ではないと理解しました。このヒアリングによって、我々が立てた課題仮説は正しいのか？という不安から、間違ってはいないという確信に変わりました。

ソリューション検討〜開発

この段階になると、チームで動いていくメリットもなくなってきたため、役割ごとに分業していくようになりました。 PMは解決する課題に対するソリューションの要件を作成し、エンジニアは技術的な仕様の検討、デザイナーはデザインプロトタイプの作成といった、これまでのプロダクト開発の流れで進んでいきました。

ここで今までと違うと感じたのは、仕様を検討するときの議論です。「この動作についてどうしたらよいですか？」という議論の仕方ではなく、「この動作だとユースケースを満たせないので、こうした方が良いと思います」という議論の仕方ができるようになりました。チームでディスカバリーをやったことで、各メンバーがユーザー目線で会話ができるようになったのが、こういった効果を生んだのだと思います。

まとめ

上の文章を見るととてもきれいに進んだように思えますが、本当はもっと具体化と抽象化の繰り返しを行い、迷いながら泥臭く進んでいきました。だからこそ得たものも大きかったと思います。この経験を通して「獲得したこと」と「次に活かしたいこと」をまとめます。

獲得したこと

チームで課題に対して向き合う流れができたこと
一つ一つの工程で得た技術的な知見もありますが、エンジニアも主体的にユーザーヒアリングに参加することが当たり前になったり、誰かが立てた仮説を受け入れるのではなくて、チームで仮説を立てられるようになったり、こういった習慣ができたことが一番大きいと思います。
不確実性に対するチーム耐性ができたこと
「今までやったことのない課題に全員で立ち向かう」というスタンスが作れたことは大きく、困難に出くわしたときに乗り越えられるチーム力がつきました。

次に活かしたいこと

学習効果が高い分、このやり方をするには工数を使う覚悟が必要
今回は課題仮説の検討から開発まで、不確実性の高いものをチームで早く進めるという目的では一定の効果がありました。しかし、課題がすでに明確であるものについては不向きであると思います。
議論の収束の見切りを付けることが大切
関わるメンバーが多い分、議論の収束が難しくなります。同じ話を2回し始めたら、議論が煮詰まっている証拠なので、PMが積極的に意思決定をしていき、議論を収束させていく必要があります。
チーム外の有識者を早めに見つけていつでも相談できるようにすること
チームで議論をすると煮詰まってきて前に進まなくなるときがあります。悩めば悩むほどチームの士気も下がっていきます。そんな時のために、相談する相手を見つけておくと良いです。

最後に

面談などをしていると「SmartHRって完成しているんじゃないの？」とか「体系的にプロダクト開発しているイメージがある」といったことをよく耳にしますが、まだまだやることは山積みです。ここで書いたように、不安もありつつ試行錯誤しながら泥臭くやっています。ですが、SmatHRには困難な課題に対してチーム全体で解決していく土壌があることと、相談できるPMたちがいる稀有な環境であることは自信をもって言えます。そんなSmartHRに興味を持ってもらえたら幸いです。