自分達の課題感を言語化したら35%が課題ではなかった件

2017年7月13日

グロースハックスタジオ広岡です。
これまで、事業開発とは「ボトルネック(優先事業課題)を解消するために、仮説検証を実行し続けていくサイクル行為」であると伝えてきました。実は事業開発をその背景から理解することによってもう一段階抽象化できると、更に捉えやすくなるので、そこの説明から始めたいと思います。

そもそも事業開発とは「計画を立てて現状をその計画に近づくようにしていくこと」というのはご理解頂けるでしょうか?

 

これを絵に落とすと↓のような感じで表現できます。
そもそも現実がその時間軸で目標に届くかどうかすらやってみないとわからない
事業開発には必ず事業計画が必要です。事業計画とは「現在から目標までの道筋の仮説」のことを指します。
しかし実際に計画通りに行くことなど殆どありません。なぜならば、事業計画とは何らかの成長に関する条件が達成されていくことが前提で作られています。しかし実際には目標までの間に様々な事業課題が発生してしまい、なかなか思ったように進捗していきません。
この事業課題を一つずつ解決していくことこそが事業開発ということになります。
冒頭に戻るのですが、事業開発とは「ボトルネック(優先事業課題)を解消するために、仮説検証を実行し続けていくサイクル行為」と言えるのはこの前提があるからです。

 

そして、このサイクルを考えるにあたり、そのスタートは常にボトルネックが起点になるわけで、その為には「チームが現状理解できている事業課題の把握」がどの程度できるのかがとても重要になります。
THRUSTER(スラスター)では「成果物で課題バックログ」「会議体に課題会議」と事業課題に関する2つの定義をしています。わざわざこの2つを切り出してある理由としては、事業課題を捉えるということがそもそも極めて難しく時間を割き言語化していかなければ出来ないことだからです。
課題バックログ
課題会議
事業課題の種類の実例
では、具体的に事業課題というものはいったい何なのでしょうか?
事業課題を何らかしら表現しようとすると、「●●が無い」「●●が利用されない」「●●がわからない」など、表現の仕方は色々あり非常に定義が曖昧です。
ただこれも責務の時と同じで、書き方というよりは「何を骨格にして記載するのか?」を定義できればある程度共通理解として進めることができるかもしれませんし、他の方に「課題感なんですか?」と聞かれた時に、何を起点にどう考えればいいのかわかるようになるかもしれません。
そこで一回事業課題というものを紐解いて見ようと思います。
紐解きの方法ですが、当社もTHRUSTERを自分達で運用しているので課題バックログを持っています。今回はその中でこれまで言語化された事業課題をジャンル分けしてみました。そうすることで事業課題の特徴みたいなものをつかめるのかなと思った次第です。 

以下がその結果です。カッコ内が全体における事業課題の割合になります。
  • マネジメントの事業課題(13%)
  • 知識の事業課題(9%)
  • 無い(やればいい)に関する事業課題(4%)
  • プロダクトやそのデリバリーに関する事業課題(13%)
  • KPIに関する事業課題(18%)
  • コストに関する事業課題(4%)
  • リスク(備え)に関する事業課題(4%)
  • その他(35%)
ちなみに、これらのカテゴリーはどのような事業で共通して発生するものもありますし、カテゴリーによっては発生しないものも存在するかもしれません。一つの切り口としてこのように分けてみました。
以下各々のカテゴリーの説明になります。

マネジメントの事業課題

マネジメントの事業課題とは、「見える化してボトルネックを見つけて、仮説検証案言語化して実行し、その結果からフィードバックを得るというサイクルの維持における事業課題」や、いわゆる「管理作業における事業課題」です。
例えば「KPIが陳腐化している」「タスクが棚卸されない」といったもの。他にも、財務的事業課題、人事的事業課題などが考えられます。
これらは、自分達でコントロール出来うるものも多く、単に実行すれば解決できる、すなわち仮説とか必要ではない事業課題も多くあります。

知識の事業課題

こちらは「リテラシーが足りない」や「●●に関する知識が不足」といった知識が足りないことに対する事業課題です。
ここは、asis tobeで仮説を表現できるので仮説検証バックログを利用して進めることになります。ただし達成基準の設定は難しいです。

無い(やればいい)に関する事業課題

これは結構シンプルです。本来あるべきだけどそれが無いといったもの、例えば「トラッキングタグ方法が決まってない」、「顧客課題の仮説がない」、「タグが入ってない」といったようなもの。
こちらも、自分達次第であってあとは「やるだけ」のものです。

プロダクトやそのデリバリーに関する事業課題

プロダクトやサービスの製造上における事業課題です。案件獲得に対して供給が合わない状態の時にフォーカスされやすい事業課題。こちらはものによってはKPIで表現できますので、仮説検証の言語化の後タスク化されるものが多くあります。

KPIに関する事業課題

KPIメトリックス上における事業課題です。プロダクトやサービスをリリースしている状態でなくても、「フィードバックを受けるのに必要なアーリーアダプターが足りない」と言ったものもここに含まれます。
この事業課題については、相手(顧客)のいる話なので自分達だけでは解決できません。よって仮説が絶対必要で、その書き方は「セグメントAはセグメントBになる、αという条件を満たした場合」といった、まさにasis tobeそのもので言語化ができます。
ここを検証していく中でフィードバックがKPIメトリクスそのものに流れると、マネジメントの課題に上げた「KPIが陳腐化してる」といった事業課題に変化したりします。
仮説検証での事業開発の主役はまさにこの事業課題群となり、課題バックログの中でこのKPIに関する事業課題か否かというのを把握していくことはボトルネックを把握する上でとても重要になります。

コストに関する課題

効率化されてないことによりコストが掛かっている事業課題です。
ここはマネジメントの事業課題に含まれると考えることもできます。

リスクに関する課題

こちらもマネジメントの課題に含ませることができるものが多いかもしれませんが、例えばデータバックアップに関するリスクがあるといったようなものです。

その他

その他とは、「事業課題と感じたので言語化してみたものの、実は仮説を事業課題っぽく言語化しただけのもの」「手段を目的化してしまっているもの」といった事業課題とは認定しづらいものです。例えば、「カスタマージャーニーマップがない」という事業課題を立案されていたのですが、そもそもカスタマージャーニーマップって「ユーザー行動仮説を可視化したもの」なので、本来は「ユーザー行動仮説が言語化されてない」というようなものが課題で、打ち手が「カスタマージャーニーマップを作る」というような関係のモノをイメージしてください。

そしてこれが実は一番多く35%程あります。

まとめ

まず、事業課題は「KPIに関する事業課題」「その他の事業課題」に大きく分けて考えることができます。基本的に事業が成長するということは最終的にKPIに定量データとして表わすことが出来ますので、本質は「KPIに関する事業課題」の解消が事業開発のメインになります。
そして、このKPIに関する事業課題を仮説検証した結果から得た学び(示唆)によっては、その他の事業課題に変化していったりします。
また、35%もの事業課題とは言えない何かを課題感として感じているというのも、かなり重要なポイントだと思います。物事には色々な事象が絡まっており、その奥行きを理解するにはそれなりの時間が掛かると言えるのではないでしょうか?
事業は事業課題ドリブンで進めないと、本当に無駄なリソースを使い続けることになります。是非自分達のボトルネックを議論する時間を準備して常に事業課題はどんなものがあるのか、その中でどれが優先順位が高いかといった部分を意識して進めて頂ければと思います。

以下宣伝です

弊社では、事業を効率よく健全に進捗させるための方法としてTHRUSTER(スラスター)を考案し、言語化しています。資料は無料で配布していますので、ご興味のある方は、こちらのサイトよりDLしてみてください。

また、THRUSTERをベースにしたプロダクトマネジメント勉強会も開催しています。
次回は7月19日になりますので、ご興味ある方は以下より内容ご確認ください。


https://ghs.connpass.com/event/60301/

—————————————————————————————
ビジネスの成長スピードを速くする GHSの「ビジネスマネジメントサービス」提供中

https://www.ghs.tokyo

THRUSTERを使ったプロダクトマネジメントの勉強会も随時実施中