Jobs To Be Doneに立ち返る：AI開発で迷子にならないための設計フレームワーク
Written by Ava
気づいたら、競合分析機能とポジショニングマップを実装していた …
Ptmindでのメイン開発の傍ら、私が個人で作っていた「デザインガイドライン自動生成ツール」の話です。クライアントのLP制作に着手するとき、競合調査に基づいたデザインガイドラインをAIで素早く生成するツールとして始めました。
でも開発を進めるうちに、ガイドラインそのものを作成する前に、「競合の分析もあった方がいいな」「そのためには、ポジショニングマップで市場での立ち位置も見えた方がいいな」となっていきました。それぞれは筋が通っていたと思います。実際に、製品に実装もしました。
でも、ある時点で立ち止まりました。
「ユーザーが本当に欲しいのは、デザインの意思決定を支える根拠だでは？ 」「色、フォント、ビジュアルの方向性を『なぜこうするか』論理的に説明できることでは？」
競合調査もポジショニングマップも、それ自体は価値があります。でも「このツールでなければできないか？」と問うと、答えはノーでした。
このツールが担うべきジョブは「デザインガイドラインの生成」であって、「市場分析の提供」ではない—その整理ができたとき、両方を外すことに決めました。
この経験から、開発中の判断基準として使うようになったのがJTBD（Jobs To Be Done）というフレームワークです。
なぜ機能は「気づいたら増えている」のか
「あった方がいい」機能は、いくらでも思いつきます。しかも、それぞれには理由があります。競合分析は戦略的文脈を与える。ポジショニングマップは市場の全体像を見せる。どちらも実際に役に立つ機能です。
問題は、「役に立つ」と「このプロダクトに必要」は別の話だということです。
事業として成立させるべきプロダクト開発のフェーズでは、ニーズが上がるたびに手当たり次第に作るわけにはいきません。軸がなければ、「万能なオールインワン製品」ではなく、「機能てんこ盛りの何か」が出来上がります。
また、追加開発の局面では開発負荷が一気に高まります。すでにある体験に何かを足すとき、既存の価値を損なわず相乗効果を狙える形で載せるのは難しく、複雑性が増して製品全体の安定性が揺らぐリスクもあります。
だからこそ、「何を作るか」以前に「何を解く製品か」に立ち返る基準が必要です。
JTBDを書いたら、欲しかった答えが出た
Jobs To Be Done（ジョブ理論） は、ユーザーが「達成したい仕事（Job）」に焦点を当てる考え方です。
核心にある前提はシンプルで、ユーザーは製品を「買う」のではなく、「ジョブを片付ける」ために製品を「雇う」という発想です。
JTBDには、ジョブを言語化するための構文があります。
When [状況] ,
I want to [達成したいこと] ,
So that [得られる結果・価値]LP Design Guideline Generatorのジョブを書くと、こうなります。
When クライアントのLP制作に着手するとき
I want to 競合調査に基づいたデザインガイドラインを素早く作りたい
So that 論理的な根拠を持ったデザイン方針でLP制作を始められるたった3行ですが、これを書いた瞬間に「競合分析機能とポジショニングマップが外れる理由」が言語化できました。ユーザーが片付けたいジョブは「デザインガイドラインを作ること」であって、「競合との位置関係を可視化すること」ではない。
この3行が、開発中のあらゆる判断のフィルターになります。
JTBDで「落選」を決める
ジョブには3つの種類があります。機能的ジョブ（具体的なタスクを完了する）、感情的ジョブ（特定の感情を得る）、社会的ジョブ（他者からどう見られたいか）です。
「ガイドラインを素早く作りたい」は機能的ジョブです。その背後には「根拠のある方針で自信を持って制作に臨みたい」（感情的）や「クライアントにプロフェッショナルな印象を与えたい」（社会的）というジョブもあります。
これらを意識することで、ただ速いだけのツールではなく、「デザインの意思決定を支えるツール」という設計方針が見えてきます。
機能提案を受けたとき、「採用するか」ではなく「このジョブに必要か」で判断する。より正確には、「この機能がなければジョブが完了しないか？」と「この機能は、このプロダクトが担うべきか？」の2軸で考えます。
実装済みだったポジショニングマップは、有用な情報ですが、デザインガイドラインの生成に必須ではありませんでした。競合分析機能は、パイプラインのインプットとして競合データを使う形では残しましたが、「市場分析レポートを出力する機能」としては外しました。
ユーザーが片付けたいジョブは「デザインの根拠を持つこと」であって、「市場での自社ポジションを把握すること」ではないからです。
この判断を支えるのが、言語化されたJTBDという基準です。「あった方がいい気がする」という感覚に抗えるだけの根拠を、JTBDが与えてくれます。
JTBDを実装に変換する
JTBDの価値は理解できました。次は、それをどうコードに繋げるか。
使っているのはパイプライン分解という方法です。JTBDを「Input → Processing → Output」のステップに分解し、前のステップのOutputが次のステップのInputになるように設計します。
JTBD: 「競合調査に基づいたデザインガイドラインを素早く作りたい」
→ パイプラインに分解
Step 1: サイト分析（Input: URL → Output: サイト構造データ）
Step 2: 競合・業界分析（Input: サイト構造データ + 競合URL → Output: 分析レポート）
Step 3: ガイドライン生成（Input: 分析レポート → Output: 3層デザインガイドライン）JTBDで「何を達成したいか」を、パイプラインで「どう実装するか」を定める。逆に言えば、パイプラインに落とし込めない機能は、JTBDとの接続が切れている可能性があります。
開発の途中で方向性がぶれたとき、自分に投げかける問いが3つあります。
「この機能は、誰のどんなJobを解決するか？」 — 答えられなければ、その機能は要らない可能性があります。
「なくてもJobは完了するか？」 — 完了するなら、それはnice-to-haveであり、今やるべきことではありません。
「ユーザーの利用シーンを具体的に描けるか？」 — 「この人がこの画面でこう操作する」レベルまで描けるか。描けないなら、まだ理解が足りていません。
判断に迷う時間が減る
JTBDの最大の効用は、判断に迷う時間を減らすことだと感じています。
競合分析とポジショニングマップを外したとき、悩みませんでした。「ジョブの完了に必須か？」という問いに対して、答えが出ていたからです。
開発中の判断は無数にあります。この機能を入れるか。このUIにするか。このエラーハンドリングは必要か。ひとつひとつは小さな判断でも、基準がなければそのたびに立ち止まることになります。
JTBDがあれば、すべての判断を「このジョブの完了に貢献するか」というひとつの軸で裁けます。フレームワークとは結局、考える量を減らすためのものだと思います。
あなたのプロダクトで、次に機能を足す前にJTBDを書いたことがありますか？
📌 Ptmind、および事業をもっと知りたい方へ
株式会社Ptmind公式サイト：https://www.ptmind.com/jp
Ptengine公式サイト: https://www.ptengine.jp/
VIVAIA JAPAN公式サイト: https://vivaia.jp/
Kocoro公式サイト：https://kocoro.ai/ja/
お問い合わせ、記事へのご質問、取材のご依頼などは、各サービスサイトのお問い合わせフォームからお気軽にお願いいたします！
