『カオナビ』は、企業内のあらゆる人材データを集約し、それをもとに「人材配置」「評価」「採用管理」といった人事・労務領域のあらゆる課題を解決するHRテクノロジーです。
そんな『カオナビ』の開発を支えるプロダクトデザインチームでは現在、『カオナビ』の開発フローの中でカバーできる範囲を広げていくための検証をしています。
一般的には、「企画に入り込む」「実装まで入り込む」といったフローの拡張を狙う場合が多いかと思いますが、カオナビのプロダクトデザインにおいては「仕様設計の精度を高める」ところまで役割を染み出していくことから始めています。
今回は、なぜ『カオナビ』のプロダクトデザインチームがこのような役割を広げ始めているのか、その中で検証している具体的なワークフローについてまとめます。
『カオナビ』のプロダクトデザインチームでは、AIによって「UIをつくる」こと自体の代替が起こっていくことを予測した上で、どこに役割を広げていくべきかを考えていました。
これからのプロダクトデザイナーは、つくることに加えた「+α」の付加価値を持つ必要があるのはもはや自明でしょう。
一方で、ここで闇雲に「ディスカバリー」「エンジニアリング」といった他職種も担っているところに役割を広げるのが良いのかは、組織や事業の特性にもよるはずです。
そこで私たちは、『カオナビ』の事業特性や、プロダクト開発において何が強みになっているのかを整理していくことから考え始めました。
『カオナビ』のプロダクト開発では、人事・労務という広い領域をカバーするからこその「利用企業の幅広さ」「登場人物の多さ」を考慮する必要があります。
タレントマネジメントシステム『カオナビ』の利用企業は2025年9月時点で4,500社を超えていて、大手からスタートアップまであらゆる規模感の組織に使っていただいています。その中には、人事がいない組織もあれば、いくつもの決裁ルートが必要な組織もあり、企業の数だけ幅広くユースケースがあります。
加えて、人事・労務のワークフローには、多くの登場人物が関わります。
例えば採用管理業務をカバーする『カオナビ採用』の場合、簡単にあげても「採用責任者」「面接担当」「面談担当」「人事担当」など多くの関係者がおり、これらすべての登場人物のやりたいこと・必要な情報を把握しなければプロダクトをつくることができません。
このような特徴を持つ『カオナビ』では、どんな企業にもフィットしたワークフローをつくれる「カスタマイズ性」を強みにしています。
『カオナビ』は、人事労務領域の無数のユースケースに応えるために、20以上の機能を用意しています。さらに、その機能ごとにカスタマイズができる設計を取っています。
一方で、何でもカスタマイズできれば良いというわけではありません。すべての設定をユーザーが自分で変更するのは負担が大きいため、「どこまでカスタマイズできるようにすべきか」ということをユースケースから考える必要があります。
このように事業の特性を考えていくと、『カオナビ』のプロダクトデザイナーは、つくる手前で満たすユースケースに共通認識を持たせていくことにフォーカスするのが良いのではないかと整理できました。
あらかじめ無数のユースケースを想定して、実装を始めてから抜け漏れに気づくようなことを無くしていく。カスタマイズ性を強みにしている『カオナビ』だからこそ、つくり始める前に設計の精度を高めていくことが価値になるはずだと考えています。
この役割のもと、今私たちが実験しているワークフローをいくつかまとめてみます。
『カオナビ採用』というプロダクトの開発では、UIを設計する手前で、機能に関わる「登場人物」と「登場人物ごとのシナリオ」をすべて洗い出しておくような進め方をしています。
『カオナビ採用』をリリースした当初は、人事担当者のみの利用を中心としていたため「管理者」「採用担当者」という2つのロールだけで設計をしていました。
ただ、実際に採用管理に関わる人は、想像以上に多くおられます。例えば、連絡担当、カジュアル面談担当、1次面接担当、2次面接担当、、と複数の関係者がいて、企業によっては見れる情報も人ごとに限定していきたいニーズがあります。
今回のプロジェクトは、「関係者ごとの権限設定」をする機能のアップデートがテーマでした。ただ、権限周りはかなりユースケースが複雑で、いきなりデザインからつくり始めると、仕様がデザインに引っ張られてしまうだろうと懸念していました。
なので、デザインをつくる前に、まずAIと壁打ちしながら登場人物の洗い出しをしました。
細かく分けると10近い登場人物がいることが分かります。それぞれが何がやりたいのかも細かく想定して、シナリオとしてまとめておきました。
ここまで想定した上で、デザインを用意します。デザインとユースケースの抜け漏れがないかもチェックした上で、社内にプロトタイプの共有を行いました。
ここでポイントになるのは、ユースケースを完全に満たすことを目指すのではなく、「満たすユースケースの認識がチームで揃っている」ことを目指すということです。
もしも想定できていなかった使われ方が見つかった時は改善すれば良く、どちらかというとチームとして具体的な使われ方の仮説がない状態でリリースをすることを避けるべきだと考えています。
この機能をつくったプロダクトデザイナーの亀井は採用管理の経験がなかったのですが、このフローを取り入れたことでPdMと会話する前にユースケースの洗い出しが行え、チームで認識を揃えにいくまでのプロセスをリードすることができました。
別の例としては、大規模な「タレントマネジメント」の機能群のどこに機能追加をしていくのかを検討しやすくするための情報設計のフローを検証しています。
『カオナビ』の「タレントマネジメント」の領域では、20以上の機能が提供されています。
それぞれの機能ごとに開発ラインが置かれていて、何か機能追加しようとした時にもコンフリクトが起こらないように細かく想定をする必要があります。
そこで、機能追加を検討しだしたタイミングでAIに相談して、「どこに機能を置くと適切か」を情報設計やデータ構造の観点からアドバイスをもらえるようなフローを試し始めました。
例えば、ある既存機能の改修をしようと決めた後に、自分で影響範囲をすべて調査してから仕様を設計すると膨大な時間がかかってしまいます。
そのため、あらかじめ既存のソースコードを読み込ませたAIを用意しておき、そこにやりたいことをまとめた機能のPRDを渡すだけで、影響範囲を踏まえて「どこに機能を追加するのが適切か」というアイデアを出してくれるようなフローを用意しました。
現状では、AIにやってもらうことは、あくまでシステム上の情報設計の観点からベストなアイデアを返してもらうまでに留めています。
逆に、ユーザーがやりたい操作のイメージなどは、別途登場人物ごとの業務要件がまとまったドキュメントをつくっていて、それを踏まえてデザイナーが判断するようにしています。
開発チームによっては、デザイナーがそもそもの機能改修案をつくるディスカバリーの領域まで入っていくような役割分担まで想定していて、少しずつ開発全体のカバー範囲を広げていくように進めています。
これらのフローはまだ部分的に試験運用をしている段階ですが、PdMやエンジニアと違和感なく仕様を決められ、実装を始めてから手戻りが起こらないような状態が起こりはじめています。
『カオナビ』のプロダクトはとにかく複雑で、開発を進める中で「この場合はどうする？」と迷うこともあります。
そんな時に、ユースケースをもとに「この狙いでこの仕様にすべき」と強く判断できる根拠を用意できると、チームを迷わせない共通認識が生まれます。
現在、AIの進化によって、プロダクトデザイナーとしてどこに強みを持つべきかを考え直す必要が生まれているように思います。
プロダクトデザイナーとして+αが求められる環境で、世の中にも新しい知見が増えていき、どう価値を出していくのかに迷いやすいタイミングだとも思っています。
だからこそ私たちは、「自分たちの事業やプロダクトの特性として、伸ばすべき強みはどこにあるか？」「その中で今の自分たちが染み出せることは何か？」」という問いを持つようにしています。
『カオナビ』が求められているのは、無数のユースケースをカバーできるカスタマイズ性があってこそ。ならば、プロダクトデザイナーとしても、その強みをとにかく強めることにフォーカスすることが価値につながるはずです。
「上流に入る」「事業に踏み込む」「UIを自動生成する」というさまざまな方向性がある中で、私たちは「仕様設計の精度を高める」という、一見地味に見える役割に染み出しています。ですが、これはプロダクトの競争優位をつくるために私たちに今できるベストな動き方だと確信しています。
いわば、「上流とデリバリーの間」と言えるような部分に『カオナビ』のプロダクト開発の肝があると捉えて、これからも「誰にでも使えるシステム」にするべくプロダクトデザインのフローを育てていきます。