平面の問題を立体で捉える
ほとんどの問題は、最初は平面的に見えます。
「この機能を作らなければならない」「この画面を直さなければならない」「売上が伸びない」。ひとつの面しか見えなければ、その面だけを解決すれば十分だと思ってしまいます。
しかし、実際にプロダクトの中で生きている問題は、ほとんどの場合いくつもの面を同時に持っています。技術の面、企画の面、デザインの面、運営の面、ブランドの面、そしてAIを活用する面まで。ひとつの問題を平面ではなく立方体のように回して見ること。それが私の問題解決のやり方です。
これは見栄えのいい言葉ではなく、実際の仕事の中で繰り返し確かめてきた方法でもあります。
まず使ってみて、「?」が浮かぶ場所を全部見つける
私が問題を解くとき、最初にするのは自分で使ってみることです。
企画書を読むことも、データを見ることも大事ですが、いちばん正直な情報は実際に体験したときに出てきます。使いながら「なぜここで迷うのか」「なぜこのボタンを押したくないのか」「なぜこの流れは不自然なのか」という問いが生まれる地点を全部集めます。
その次にデータを見ます。自分が引っかかった場所で本当にユーザーも離脱しているのか、それとも自分だけが不便に感じたのかを確認します。そして、良い点は強化し、悪い点は修正したりヘッジしたりします。
ここで言う「ヘッジ」とは、欠点を無条件になくすことではありません。流れの中で必要なハードルなら、その負担を減らす形で設計します。たとえば会員登録がコンバージョンのボトルネックであってもサービスに必須なら、登録そのものをなくすのではなく、登録前にまず中核価値を体験させ、登録する理由を作るというやり方です。
これが私の問題解決の出発点です。ひとつの面だけを直すのではなく、問題全体のコンテキストを把握することから始めます。
10個のアプリを出しながら学んだこと
私はApp in Tossで、10個以上のミニアプリを自ら企画し、開発し、デザインし、運営してきました。最初は、自分が不便だと感じた問題を解くために作りました。自分と似たペインポイントを持つ人を対象にし、仮説が当たったアプリは2か月で20万人が使うサービスになりました。
ここで重要だったのは、機能をうまく作ったことだけではありません。
プッシュ通知ひとつ送るにしても、ユーザーがどんな状況でそのメッセージを受け取るのか、どんな文言が行動につながるのかを継続的に検証しました。トスでは、よく出ているプッシュCTRは3%程度とされ、一定期間4%未満だとプッシュが無効化されます。私のアプリは平均5%台、最高6.8%を記録しました。使いやすいデザイン、検証済みのペインポイント、AIを活用したマーケティング最適化が重なった結果でした。
もちろん、すべてが成功したわけではありません。
友人に応援メッセージを残すローリングペーパーアプリも作りましたが、トスの中でローリングペーパーを書くという行為そのものが、ユーザーにとってハードルが高すぎました。広告転換もユーザー転換も厳しく、結果的に失敗作として残りました。機能は動いていても、企画仮説が間違っていたのです。この経験によって、私は「機能するか」よりも「この文脈でこの行動は自然か」を先に見るようになりました。
もうひとつあります。App in Tossの初期、まだ全体のアプリ数が200にも満たなかった時期に早く入ったアプリがありました。時間がたつにつれてコピーアプリが増え、競争が激しくなり、ユーザーが離れていきました。DAUが10人台まで落ちた時点で、競合アプリの長所と短所を分析し、アプリを最初から組み直しました。その結果、DAUを120まで引き上げ、今も継続的に使いやすさを改善しながら運営しています。
この過程で分かったのは単純です。作ることより、回り続けるようにすることのほうが難しく、そして重要だということです。
デジタルの外でも同じやり方で働く
立体で見るやり方は、デジタルプロダクトだけに通用するものではありません。
以前、カフェのブランディングプロジェクトを担当したことがあります。3か月の短期フリーランスでしたが、最初に診断したとき、最大の問題は明確でした。このカフェには顔がなかったのです。シグネチャーと呼べるメニューがひとつもありませんでした。
既存の販売データを見ると、甘いペストリー類の売れ行きが良かった。そこで、その傾向を地域のヘリテージと結びつけ、シグネチャーブレッドを作ることにしました。そのためには製パンチームとの長い協議が必要でした。外部人材だったので、彼らとの関係を築けていなければ、この方向自体が成立しなかったはずです。実行は素早く回しました。作って、売って、反応を見て、変えて、また売る。そのサイクルを繰り返しました。
同時にデジタル側も並行して動かしました。NAVERマップ最適化、SEO最適化、そして当時の主要顧客層がもっとも多く使っていたInstagramでのパフォーマンスマーケティングです。特にそのカフェは立地が微妙でしたが、それでも車ではなく徒歩で来る来店客の比率を40%まで引き上げました。全体売上は30%伸びました。
このプロジェクトで自分がやったことを、ひとつの職能として定義するのは難しいです。データ分析、メニュー企画、ブランディング、マーケティング、運営改善が、すべてひとつの流れの中にありました。私はそれを自然だと感じました。問題が多面体なら、多方面から同時にアプローチするのが当然だと思っているからです。
AIはツールであり、ワークフローでもある
私はAIを「たまに聞く道具」としてではなく、働き方そのものに組み込んで使っています。
アプリを作るときの私のプロセスはこうです。まず、Spec Drivenで企画仕様書を書きます。その仕様書をもとにClaude CodeとCodexがそれぞれコードを生成し、互いの結果を交差検証します。QAはCodexで行い、そこで出たエラーレポートをClaude Codeで解決します。
さらに、繰り返し発生する作業の基準やパターンを文書化するために skill.md を作りました。Human in the Loop型の半自動化システムです。このやり方によって、アプリひとつを出すまでの時間は3週間から4〜5日まで短縮されました。ときどき人の確認が必要な煩わしさはありますが、現時点の技術ではこの方法がもっとも完成度が高いと考えています。
目的は、ただ速く出すことではありません。スピードがつくと、むしろ品質が落ちる危険もあります。だから今は量より密度を選びます。短縮できた時間を企画とデザインに戻し、よく作られた成果物をポートフォリオとして積み上げる方向にしています。
AIを使うときに私が守っている基準はいくつかあります。
AIに聞く前に、まず問題を構造化します。構造のない問いは、構造のない答えを呼び込みます。初稿は素早く受け取りますが、判断はゆっくり行います。AIが作った文章はもっともらしく見えても、正しいとは限らないからです。技術選定、コスト、ポリシーのように検証が必要な領域は、必ず公式ドキュメントと実際の条件で再確認します。
そして、いちばん重要なのは、AIを使いながら自分の基準を失わないことです。AIを通すと、成果物は平均的にきれいになります。しかしその過程で、自分の問題意識やプロダクトの質感がぼやけることがあります。広く探索しても、最終結果には自分が大事にする基準が残っていなければならない。方向を決めるのは道具ではなく、人です。
六つの面、ひとつの方向
改めて言うと、私は問題を見るとき、六つの面を一緒に回します。
技術的に持続可能か。企画的に本当に解くべき問題を捉えているか。デザイン的にユーザーが考えなくても理解できるか。運営的にリリース後も持ちこたえられるか。ブランドとしてこのプロダクトはどんな印象を自ら作っているか。そして、この流れの中にAIをどう編み込むか。
これは、私が六つすべてにおいて一番うまいという意味ではありません。各面で専門家ほど深くないかもしれません。ただ、私はそれらの面がどうつながっているかを見る感覚には自信があります。そして、そのつながりを実際に動く形にしてきた経験があります。
App in Tossで企画からマーケティングまでひとりで回しながら20万ユーザーを作ったことも、カフェでデータと現場感覚を混ぜてシグネチャーメニューを作り売上を伸ばしたことも、AIワークフローを設計してリリース速度を5倍にしたことも、結局は同じやり方の別の表現です。
マルチプレイヤーとは、あれこれ少しずつできることではありません。ひとつの問題を複数の面から同時に見て、それぞれの面がひとつの方向へ動くよう束ねることです。ワンソース・マルチユース。ひとつの視点から出発して、技術でも、企画でも、デザインでも、運営でも、ブランドでも、AIでも解いていけること。
AXが重要になる時代に、こうしたワークフローが中心に近づいていくのではないでしょうか。
私は正解を早く出す人というより、問題を複数の層で同時に見て、実際に持続可能な答えとして束ねようとする人に近いです。
平面の問題を立体として回してみること。