初めまして。
HRBrainでタレントマネジメント領域のプロダクトマネージャーをしている近藤です。
今日はアドベントカレンダー10日目の記事です！
私自身、ロジカルに物事を捉えて進めるというところは苦手意識がある人間なのですが、今回はそんな右脳派人間である私のHRtech的な「構造化する」やり方について、独自の視点からお届け出来ればと思います。
過去の完全右脳記事はこちら🧠
こんな人に読んで欲しい
- 構造化して考えることが苦手
- 構造化することが求められるPdM/UXデザイナー・UIデザイナー
- HRtech領域のPdMって何考えてるん？に興味がある
- プロダクトマネジメントの基本を知りたい
もしかしたらそれ構造化って言わなくない？みたいなご意見があるかもしれませんが、自分なりの構造化の仕方を言語化した内容なので大目に見ながら読んで頂ければと思います。
HRBrainについて
本題に入る前に弊社の事業について簡単に説明をさせてください。
HRBrainは、企業の人事の方々向けにマルチプロダクトでサービスを展開している会社です。
普通のBtoBとちょっと違う点としては、売り先とメインユーザーは人事（または経営）の方なのですが、エンドユーザーとして『部門責任者や従業員』の方も入ってくるので、BtoBtoCの側面もあるということです。
提供しているサービスによってターゲットが変わってくるのが面白い点ですね。
これは人事のみ、これは人事と責任者、これは人事と責任者と従業員、などなど。一言で人事と言っても労務担当の方、人材開発の方、などそういった違いも。
更に言うと、人事・経営・部門責任者・従業員、全員が使うサービスだったとしても、機能によっての出し分け（人事が扱うデータは秘匿性の高いものが多かったりするため）などもあり、色んな視点から物事を考える必要があります。
このようにサービスを展開している中で、プロダクトの数も増え、従業員の数や役割なども増えきており、社内的にも適切なコミュニケーションが求められてくるようになりました。
プロダクト開発における『構造化』とは
本題に移っていきますが、その様なサービスや社内環境であるからこそ、全体像の把握とその構造化がとても大事だと考えています。
そして極論から入りますが、私にとっての『構造化する』こととは、
『散りばめられたパーツを面と立体で捉え、全体像と詳細を可視化・言語化すること』
です。
右脳っぽいですね。笑
最初：まだパーツがバラバラ。中身もようわからん状態
では上記の構造化をするに当たって何をすべきなのか？というところなのですが、それは以下だと考えています。
- 好奇心と興味を持って適切な問いを立てること
- 常に問いに対して仮説を持つこと
そしてそれらを行っていく上で持っているべきマインドセットとしては、
- 『素直になるな、全てポジティブに疑ってかかれ』
- 『360度全方位から観察・考察せよ』
が大事だと思っています。
説明していきましょう。
『好奇心と興味を持って適切な問いを立てること』と、『素直になるな、全てポジティブに疑ってかかれ』とは？
まず大小問わず何か一つの解くべき課題が目の前に出てきた時に、目の前にあるだけの情報から 『オッケー🙆♀️とにかくやります！』 となっている方がいたら、あなたはちょっと素直すぎるかもしれません。
もちろん表面的には一旦飲み込んで 『オッケー！』 という事は対人関係を保つためにもとっても大事なことなので、一言目はそれで良いかもしれません。
ただ、課題に対して自分なりの答えや仮説を持ち合わせていない場合は構造的に考えられていない！良いチャンス！と思って、自らのタスクとして向き合う際に以下のような要素を問いとして立ててみます。
- 誰が欲しがっているのか
- なぜ欲しがっているのか
- 誰が使えるまたは使えないのか
- 現状としての実態はどうなっているのか
- その実態になっている歴史的背景等はあるか
- 既に行なっている場合の業務は
- どんな想いでそこに向き合っているのか
- 本当はどうしたいのか
- 裏にある最終的なゴールは他にあるか
- 関係者・ステークホルダーは誰なのか
- 今どれくらいの時間がかかっているのか
- どんなデータをどう取り扱っているのか
- 求めているものがないとどれくらい大変なのか
- 本当にその機能が必要か？
etc...
全部説明できたらもはやあなたは人事マスターです🏆
まさに、興味と好奇心を持って深く知るべく、問いを立ててドリルダウンしていきます。
問いを立てるべき先の順番としては以下。
- 自分
- ネット
- 社内の有識者（人事、CS、Sales etc）
- ドメインエキスパート
- 既存/商談中顧客
ドリルダウンしていくうちに、散らばっていたパーツ毎に、実は思っても見なかった歴史的背景（慣習）や社内制度、他システムとの関連性、影響度合いなどが見えてきたりします。（これが楽しい。）
ここでは一旦開発的な観点はスコープアウトし、顧客の理想状態を徹底的に定義する方に振り切って考えるのが良いと思ってます。
なのでこんな感じでまず整理が可能。
あと結構大事なのは最後の問いで、
『必要なのは分かるけど、本当に必要なんだっけ？その方法じゃないと本当にいけないんだっけ？実はもっと課題となるような点は他にないんだっけ？』
と言った、そもそもを疑うことを辞めてはいけない、と考えています。
これが ポジティブに疑ってかかる 、ということですね。
この問いは顧客に向けてではなく、基本は常に自身に向けて問い続けてみてください。
さて、これらによって何ができるかというと、
散りばめられたパーツを面と立体で捉え、全体像と詳細を可視化・言語化すること と言っていた構造化としての重要なピンである
『全体像』の可視化と言語化
ができるようになってきます。
ただ、実はまだこれでは本当に概要としての理解しかできていない状態です。
では更にここからプロダクト開発に落としていくにはどこに問いを立てて構造化していくべきなのか？それは顧客課題としており重なっているこのあたりを更に 仮説を持って ドリルダウンしていくことで可能になっていきます。
『常に問いに対して仮説を持つこと』と、『360度全方位から観察・考察せよ』とは？
更に詳細な業務や実態に対して問いを立てていく際に合わせて必要な観点が、 自分なりの仮説を持つこと だと考えています。
今までお話しさせてもらっていたように、様々な問いからある程度の理解と仮説立てができる状態になっているかと思います。
スコープアウトにしている開発側に向けてどう接続していくか、というお話にもなるのですが、次は業務ベースでどんなサービス・機能として設計していくのが良いのか、をドリルダウンして作っていきます。
まずは理想はありつつも、ファクトベースで 今顧客が実際に何をどう行っているのか を洗い出します。
今まで拾い集めた情報から、こうであろう仮説も持ちながら一旦洗い出してみます。
するとこんなユーザーストーリーが出来上がりました。しかしこれが出来上がった段階でもやはり疑問は出てきます。
ですので、出てきたこれらの疑問（問い）一つ一つに対して、自分なりの仮説を持ちます。
さあここまで来れば、あとは仮説検証をとにかくぶん回していくフェーズに入ってきています。実際にこの仮説をもとに、いろんな先に検証しに行きましょう。
検証する際の観点として大事なのが、
『360度全方位から観察・考察せよ』
ということです。
さて問いをドリルダウンしていき、改めてまとめると、なんとこんな形であることがわかりました。
平面じゃない・・・！
どの業務に負担が大きいのか、解決すべきペインはどこなのか、見えてきましたね。
また、冒頭でお話しした通り、人事周りの業務はその業務ごとに「見える」「見えない」「編集したい」などの細かい権限を付与したい、といったことがあるため、業務として縦のつながりも意識しながら一つ一つの要件を深ぼる必要があることがわかりました。
一つの要件が、他にどのような影響を与えるのか？
それによって誰にどんな価値が提供できるのか？
逆に悪い影響を与えることにならないか？
見えちゃいけない情報が見えてしまうことにならないか？
こんなところを、複数のペルソナ視点から観察・考察する必要があるのです。
まとめ
こう言った仮説検証を繰り返して、ただのグレーの四角だったところから、こんな立体状態まで持ってくることができました。
このプロセスそのものが私的にはプロダクト開発における構造化そのものだと考えています。
色々な試行錯誤を通して今の私がベストだと考えているやり方として今回お話をさせていただきましたが、ちょうどこんなことを記事にしようと思っていた時にクリティカルシンキングという考え方を知り、割と近いやり方なのかな〜と思っています。
改めて、プロダクト開発における『構造化』とは、
『散りばめられたパーツを面と立体で捉え、全体像と詳細を可視化・言語化すること』
であり、適切な問いと仮説の検証サイクルを回すことによって、全体を多面的に評価・定義することだと考えています。
しっかり言語化することも忘れずにやっていきましょう。
さいごに
PdM/デザイナー/エンジニア絶賛募集中でございます！！！
参考文献