自分の頭の整理のための記事です。
プロダクトを改善しようと考えたとき、どんなことを考えるでしょうか？
「顧客課題を解決することが大事だ！」という考えが浸透した昨今ではありますが、「課題から考えることが必ずしも正しいとも言えないのかな？」と考えることがありました。 頭によぎったので書いてみます。
課題主導と技術主導の定義
今回、「課題主導」と「技術主導」という言葉を使って考えています。 自分で勝手に決めた用語なので、用語の定義から考えを書いていきます。
課題主導
まずは課題主導について
〇〇の指標が悪くなってるから、この指標を改善したい
というアプローチで始める考え方です。 やや乱暴に書くと「マイナスをプラスにする」感じですね。
問題設定の考え方としては
- 理想: (過去の実績や一般的な基準と比較して)指標が予想通りの推移をしている
- 現実: (過去の実績や一般的な基準と比較して)予想より指標が悪い
- 問題(ギャップ): 過去の実績や一般的な基準と比較したとき、現在の指標が悪い
みたいな感じでしょうか。よくある、ありがちな考え方ですね。
具体例
具体例としては、
- 売上が減少している
- コストが増大している
- 新規ユーザー数が減少している
- ユーザーの継続率が減少している
- 離脱ユーザー数が増加している
- 有料課金ユーザーの割合が減少している
などなど、その他にもたくさんあると思います。
一つ補足しておくと、必ずしも指標がマイナスになっているとは限りません。
〇〇の指標が悪くなってる
という状況にも、下記のようにいくつかパターンがあります。
- 一般的にAという指標はXX程度になるものだが、実際にはYYにしかなっていない(一般的な指標と比較して悪いギャップ)
- 過去の実績を踏まえると、今月の指標はXX程度になるはずだが、実際にはYYにしかなっていない（指標が悪いわけではないが、もっと行くはずというギャップ）
これらに共通することとしては、指標に対して期待・理想の状態があってその値と乖離を埋めようとする考え方です。
メリット・デメリット
- メリット
- ビジネスの側面から考えるので、改善幅がはっきりする
- 関係各所に説明がしやすい
- デメリット
- 人間が考えた理想とのギャップをもとに考えるので、常識の範疇を飛び出しにくい
基本的に、ビジネス的な指標から逆算して考えるので、課題主導では直接的・間接的にビジネス指標のモニタリングから始まりまるはずです。 良くも悪くも、ビジネス的な視点から考える点が特徴と言えるのかもしれませんね。 (感覚的な話から始まることもありますが、この考えで進めるためにはどこかで必ず指標を確認するタイミングがやってくるはずです)
技術主導
課題主導で考えるのが一般的かと思っていたんですが、「別のアプローチもあるんじゃね？」と考え、技術主導について書いてみます。
技術主導は
この機能に関して、ここをこうしたらもっと良くなるはず
という考え方で始める施策です。 これも乱暴に書くと「+1を+10にする」イメージですね。
課題主導と明らかに違うのは、各種指標を眺めているだけでは絶対に思いつかない点です。 なぜなら、特に悪いところに手を入れようとするわけではないからです。
このアプローチの起点は、「技術的にこれくらいできるはず」という技術者目線です。
具体例
具体例としては
- webサイトのレスポンスタイムを更に10%短くできるはず(速いことは良いこと)
- アプリ使用時のメモリ消費量を15%小さくできるはず(効率的なのは良いこと)
- 機械学習モデルの精度が更に20%向上できるはず(正確なのは良いこと)
みたいなケースが該当するかと思います。 技術者目線で「良くなる」というのが感覚的にわかるケースですね。
メリット・デメリット
- メリット
- ビジネスの側面からは思いつかないアプローチができる
- 改善幅が見積もれないからこそ、普通にやってたらできないホームランが発生することがある
- ビジネスの側面からは思いつかないアプローチができる
- デメリット
- ビジネス的なインパクトの見積もりが難しい
- 関係各所への説明は超難しい
注目すべきなのは、「ビジネス的なインパクトの見積もりが難しい」ってところでしょうか。 「良いか悪いかで言えば良いが、ビジネス的なインパクトがどれだけになるか見積もりが困難」ということになりがちなので、基本的に組織として良い顔はされにくいかもしれません。
ここまで書くと、よく揶揄される職人的な思考のアプローチに近い気がしますね。 「ビジネス上どれくらいインパクトが出るの？」と聞かれると、回答にこまる場面もありそうです。 説明できないことはお仕事でやりにくいですしね。（意思決定者がそのへんに理解があれば話は別ですが）
一方で、こういう現場主導で改善を行うことは、普通の課題主導な考え方ではできない施策が走ったりするので、たまにホームランにつながるかもしれません。「神は細部に宿る」とも言いますしね。
(「あそこのサービス、なんか知らないけどサービスが快適過ぎて他のサービスを使う気にならないんだよね」となる競争優位性につながることがある)
結局どっちが良いの？
個人的にはどっちも大事だと思ってます。 どちらも目指すゴールは「ユーザー体験を良くしたい」というところだと思うので、どちらも正解だと思います
「どっちも良い」だと何も言ってないのと同じので、別の視点でも考えてみます。
今、課題主導で考えた施策と技術主導で考えた施策があったとします。 着手できるのは一度に1つだとすると、どっちを先に手をつけますか？
きっといろんな考え方があると思います。ざっと考えただけでも下記の考え方が思いつきます。
- 見込みリターンが大きい方
- 確実性が高い方
- 投資対効果が良い方
- 人的、その他リソースの制約が厳しく、効率よく成果を出していきたいときなど
これに関しては組織の考え方やその時置かれている状況にもよるので、状況に応じて考えたほうが良さそうですね。 ただ、いついかなるときも課題主導の考え方が正ということにはならなそうだと思っています。 そのへんを踏まえて、どの施策を行うかを考えていったら良いと思います。
感想
以上、雑記でした。
「「課題主導」と「技術主導」ってどっちのケースもありうるよなー」と思ったので、頭の整理がてら書いてみただけです。
こういうの、実はグラデーションで進めて行けると良いのかもしれませんね。
- 課題主導: ビジネス的に改善の見込みがあるもの
- プロジェクトとして進める。事前に見込んだ改善幅を達成できるように進める。
- 技術主導: 技術的に改善の見込みがあるもの
- 日頃からコツコツ進める。日の目を見ることはあまりないけど、ビジネス的にマイナスインパクトが無いことを確認しつつ、細部にこだわる。
こんな塩梅で、技術主導については縁の下の力持ち的な意味で進めたら良いのでは？と考えてしまいました。 これやるの大変そうですけどね。笑
いい感じで整理できてるかな？よくわかんないけど満足です。
