それ、課題じゃないですよ

「アクティブ数が増えない」
「コンバージョン率が悪い」
「リリースした〇〇が使われない」
「オンボーディングがうまくできていない」

デジタルプロダクトの改善する際に取り上げられるフレーズたち。これらのフレーズが多くの会話やアイデア発散の起点となることがあります。しかし、これらはすべて課題ではなく、症状です。「アクティブ数が増えない」のは、開発陣の行動やステークホルダーの判断の結果（症状）であり、課題そのものではありません。真の課題を特定するためには、「なぜアクティブ数が増えなかったのか？」という深掘りする問いかけが必要となります。

単に「アクティブ数が増えない」という症状だけを見て対策を立てるのは、医者が具体的な診断をせずに治療を始めるのと似ています。このアプローチで一時的な改善が見られることもあるかもしれませんが、真の原因を突き止めずにアプローチをすると、その結果から学ぶことは少ないでしょう。あえて言うなら、「多くの施策を試して努力した結果、たまたまた上手くいった」くらいでしょうか。

症状に対して様々なアプローチを試すことは、表面的には迅速に行動しているように映るかもしれません。もし、その行動がチームの意思決定で「スピードを最優先」という前提のもとでなされているのであれば、それは一定の意味で正しい選択と言えます。しかし、デジタルプロダクトの開発においては、持続的な成長の仕組み作りも欠かせません。そのような文脈で、学びの少ない行動を継続することは、中長期的に見た時にプロダクトやチームにとって致命的なトレードオフをしている可能性が高いです。

大規模な組織では、スタートアップのような「さっと試してリリースしてみる」手法が取りづらいのが現実です。誰もがスピードを損ねたくないとはいえ、遠くまで行く（大きく成長）するには、多様な専門家の知見や経験が必要不可欠となります。そして、それぞれの専門家が自身のスキルや知識を最大限に活用できるような、学びがある環境作りも欠かせません。

組織の大きさや性質に関わらず、学びを組み込まない活動は、単に「症状に向けてさまざまなアイデアを試す」という反射的な行動に過ぎないと言えるでしょう。このような反射的な行動は、課題の根本原因を見逃すリスクが高いです。

症状を深掘りし、その背後にある実際の課題や原因を明確にすることで、より意味のある行動やアプローチを取ることが可能となります。そして、たとえそのアプローチが成功しなかったとしても、「なぜ成功しなかったのか」「何が不足していたのか」といった洞察を得ることができ、それが次のステップや改善の方向性に繋がる貴重な学びとなります。

デザイナーに限らず、課題としっかり向き合いたいと考えてはいるものの、そもそも「課題」という言葉の解釈が異なることがあります。人によっては症状を課題と呼んでいることがあり、こうした言葉の解釈のズレを置き去りにすると、進め方に対する意見の食い違いが発生します。同じ言葉でも違う解釈になってしまうのであれば、「症状」と「課題」と言葉を別々にしたほうが良いのではと思い、使い分けています。

では、症状ではなく課題の深掘りをどのようにするか。「リサーチしましょう！」と提案すれば解決するほど単純な話ではありません。ポッドキャストで取り上げたましたが、課題について学ぶタイミング、ソリューションを期待されている環境下における期待調整など、体制やプロセス設計と向き合うことになります。

そのあたりは気が向いたらまた書きます。