はじめに
プロダクト開発のチーム構成について語られるとき、スクラムの教科書的な話になりがちです。でも実際のところ、スタートアップや受託開発の現場では、PO（プロダクトオーナー）・デザイナー・エンジニアの3人という最小構成で開発を回すことが少なくありません。
自分たちも Purpom Media Lab でプロダクト開発をする中で、この最小構成でいかに質を保つかを試行錯誤してきました。
少人数だからこそ、誰が何を担い、どういう順番で進めるかを明確にしておかないと、あっという間にカオスになります。逆に、フローと役割分担が整っていれば、少人数でも驚くほどスムーズに開発が進みます。
この記事では、3人チームで実践している開発フローと、その中で大事にしている考え方を共有します。
良いプロダクト開発とは
まず前提として、自分たちが考える「良いプロダクト開発」を定義しておきます。
顧客が課題を気持ちよく解決できること。
これに尽きます。技術的に優れているとか、コードがきれいとか、それも大事ですが、最終的に顧客が「これで課題が解決できた」と思えなければ意味がありません。
その上で、優先すべきことを順番に並べるとこうなります。
| 優先度 | 内容 |
|---|---|
| 1 | 課題が解決できていること |
| 2 | 使い方がわかりやすいこと |
| 3 | 適切な工期でできていること |
| 4 | 機能拡張ができる状態になっていること |
| 5 | 不具合なくストレスなく使えること |
1と2が満たされていなければ、どんなに堅牢なシステムでもプロダクトとしては失敗です。
大前提となる4つのルール
この開発フローの根底にあるルールは4つです。
- 顧客目線で必要なことをまとめる -- 技術目線やビジネス目線ではなく、まず顧客から始める
- デザインドリブンで仕様を作る -- 仕様書を書いてからデザインするのではなく、デザインが仕様になる
- 実装はデザイン・仕様に近づける -- 「技術的に難しいから」で体験を妥協しない
- 実装できて期日を守れるかはエンジニアの責務 -- エンジニアは「できない」ではなく「どうすればできるか」を考える
特に2番目のデザインドリブンが重要です。多くの開発現場では、テキストベースの仕様書を書いてからデザインに落とし込む流れが一般的ですが、それだと体験の抜け漏れが起きやすい。デザイン（= 画面やフロー）を作る過程で仕様が固まっていく方が、結果的に品質が高くなります。
3つの役割と責務
PO（プロダクトオーナー）
PO は「何を作るか」を決める人です。
- 顧客・課題・価値を定義する -- 誰の、どんな課題を、どう解決するのかを言語化する
- ユースケースを作る -- 課題をユーザーが体験するシナリオに落とし込む
- 顧客説明を行う -- 作ったものが正しいかを顧客と確認する
デザイナー
デザイナーは「どう使うか」を設計する人です。
- 体験を設計する -- ユースケースから具体的な体験フローを描く
- アクター / アクション / タッチポイントを整理する -- 誰が、何をして、どこで操作するかを構造化する
- UI を作る -- 体験を画面に落とし込む
エンジニア
エンジニアは「どう実現するか」を担う人です。
- 実装可能か判断する -- デザインされた体験が技術的に実現できるかを検証する
- 代替案を提示する -- 実現が難しい場合に、体験を損なわない別の方法を提案する
- 見積と実装を行う -- 工数を見積もり、期日に間に合うように実装する
ポイントは、役割の境界が明確であることです。PO が実装方法に口を出したり、エンジニアが顧客課題を勝手に解釈したりすると、チームが小さいだけに混乱が大きくなります。
開発フロー：10のステップ
全体のフローは以下の通りです。
課題定義 → ユースケース化 → プロダクト・イメージ設計 → 顧客説明
→ UIデザイン → 技術フィージビリティチェック → 仕様・デザイン調整
→ 工数見積・アサイン → 実装 → 試験
一つずつ見ていきます。
Step 0. 課題定義
| Actor | PO |
| Action | 顧客・課題・解決方針を整理 |
| Touchpoint | Notion / Linear |
すべての出発点です。PO が「誰の、どんな課題を、どういう方向性で解決するか」を整理します。
ここで重要なのは、解決方法ではなく課題にフォーカスすることです。「こういう機能が欲しい」ではなく「顧客はこういう場面でこういう困りごとを抱えている」という形で定義します。
Step 1. ユースケース化
| Actor | PO |
| Action | 課題をユースケースに分解 |
| Touchpoint | Notion / Linear |
課題をユースケース（シナリオ）に分解します。ユースケースは3つの役割を持ちます。
- 顧客がやりたいことの仕様書 -- 何を実現するかの定義
- デザインのインプット -- デザイナーが体験を設計する際の入力情報
- テストケースの元 -- 試験時に「この通り動くか」を確認する基準
一つのユースケースが具体的なシナリオになっていることが大事です。「ユーザーが商品を検索できる」ではなく「ユーザーがカテゴリとキーワードで商品を絞り込み、結果一覧から詳細を確認できる」ぐらいの粒度があると、後工程がスムーズに進みます。
Step 2. プロダクト・イメージ設計
| Actor | デザイナー |
| Action | アクターの洗い出し、各アクターのアクション定義、タッチポイントの設計 |
| Touchpoint | FigJam / Figma |
ここからデザイナーが主役です。ユースケースをもとに、以下を整理します。
- アクターを洗い出す -- このプロダクトに関わる人は誰か
- 各アクターのアクションを書く -- それぞれが何をするか
- 各アクションのタッチポイントを書く -- どこでその操作が行われるか
FigJam のようなホワイトボードツールでフロー図として可視化すると、チーム全員の認識が揃いやすくなります。
Step 3. 顧客説明
| Actor | PO |
| Action | 体験フローを説明 |
| Touchpoint | Slides / Figma |
Step 2 で設計した体験フローを、顧客に説明します。実装に入る前に顧客と認識を合わせることで、「作ったけど違った」を防ぎます。
ここでのポイントは、画面デザインではなくフロー（体験の流れ）を説明すること。画面を見せると「ボタンの色が」「文言が」といった細かい話に引きずられがちです。
Step 4. UIデザイン
| Actor | デザイナー |
| Action | 画面作成、状態設計 |
| Touchpoint | Figma |
顧客の合意が取れたら、UIデザインに入ります。ここでは画面の見た目だけでなく、状態設計（ローディング中、エラー時、データが空の時など）も含めてデザインします。
状態設計がないままエンジニアが実装に入ると、「このケースどうするの？」という質問が実装中に大量に発生して、手戻りの原因になります。
Step 5. 技術フィージビリティチェック
| Actor | エンジニア |
| Action | 実装可能か確認、懸念点をコメント |
| Touchpoint | Figma コメント / Slack |
ここでエンジニアが登場します。UIデザインを見て、技術的な実現可能性を確認します。
具体的には、こんな観点でチェックします。
- 1画面を作るのに10以上のクエリが必要 → パフォーマンスに影響、工期 +X日
- テーブル設計をやり直す必要がある → 工期 +X日
- ユースケースやユーザージャーニーに矛盾がある → 仕様の見直しが必要
このフィードバックは Figma のコメント機能で直接デザインに紐づけて残すのがおすすめです。「この画面のここが技術的に厳しい」という文脈がデザインと一緒に残るので、後で見返しやすくなります。
Step 6. 仕様・デザイン調整
| Actor | PO / デザイナー / エンジニア |
| Action | 実装難易度と体験のバランス調整 |
| Touchpoint | MTG / Figma |
3者全員が集まって、技術的な制約と体験のバランスを調整します。
- 工期オーバーになりそうな部分の優先度を判断
- 体験を損なわない代替案の検討
- 複雑な仕様が出てきた場合の仕様書作成の判断
ここが3人チームの真価を発揮するフェーズです。大きなチームだと調整に時間がかかりますが、3人なら短いミーティングで素早く意思決定できます。
Step 7. 工数見積・アサイン
| Actor | エンジニア |
| Action | イシュー分解、工数見積 |
| Touchpoint | Linear |
仕様が確定したら、エンジニアがイシューに分解して工数を見積もります。Linear のようなプロジェクト管理ツールでイシューを管理し、スプリント単位でアサインしていきます。
Step 8. 実装
| Actor | エンジニア |
| Action | 実装 |
| Touchpoint | Code / Claude Code |
いよいよ実装です。ここまでのステップで仕様とデザインが固まっているので、エンジニアは「何を作るか」に迷わず、「どう作るか」に集中できます。
最近は Claude Code のような AI ツールも活用して、実装のスピードを上げています。
Step 9. 試験
| Actor | PO / デザイナー |
| Action | 体験通りか確認 |
| Touchpoint | 動作確認 / Linear |
実装が完了したら、PO とデザイナーが体験通りに動くかを確認します。エンジニアが自分でテストするのではなく、仕様を定義した人が確認するのがポイントです。
Step 1 で作ったユースケースがそのままテストケースになるので、「何を確認すればいいかわからない」ということが起きにくくなります。
技術チェックが入る3つのタイミング
フロー全体を通して、エンジニアの技術チェックが入るタイミングは3箇所あります。
[Step 4] UI完成時 ──→ フィージビリティチェック
[Step 7] 見積時 ──→ 工数の妥当性確認
[実装中] 問題発生時 ──→ 仕様・デザインへのフィードバック
技術チェックが UI デザインの後にあるのが、このフローの特徴です。先に体験を設計し、技術はそれに合わせるという順番を徹底しています。
迷った時の判断基準
開発中に「今どこにいるかわからない」と感じたら、この2つの基準で立ち戻ります。
画面の話をしていたら → 一段階戻って「アクション」を考える
「このボタンを押したらどうなる？」という議論が始まったら、まだアクション（ユーザーが何をしたいか）が整理しきれていないサインです。画面ではなく、行動に立ち返りましょう。
実装の話が出たら → デザインと体験が固まっているか確認
「このAPIどう設計する？」「DBスキーマどうする？」という話が先行していたら、まだデザインが固まっていない可能性があります。実装の前にデザインと体験のフローが確定しているか確認しましょう。
フロー全体を図で整理
各ステップの Actor と Touchpoint を一覧にすると、全体像が見えてきます。
| Step | フェーズ | Actor | Touchpoint |
|---|---|---|---|
| 0 | 課題定義 | PO | Notion / Linear |
| 1 | ユースケース化 | PO | Notion / Linear |
| 2 | プロダクト・イメージ設計 | デザイナー | FigJam / Figma |
| 3 | 顧客説明 | PO | Slides / Figma |
| 4 | UIデザイン | デザイナー | Figma |
| 5 | 技術フィージビリティチェック | エンジニア | Figma コメント / Slack |
| 6 | 仕様・デザイン調整 | PO / デザイナー / エンジニア | MTG / Figma |
| 7 | 工数見積・アサイン | エンジニア | Linear |
| 8 | 実装 | エンジニア | Code / Claude Code |
| 9 | 試験 | PO / デザイナー | 動作確認 / Linear |
PO が前半（Step 0-3）をリードし、デザイナーが中盤（Step 2, 4）で体験を形にし、エンジニアが後半（Step 5, 7-8）で実現する。Step 6 の調整で全員が集まる。この流れが自然なリレーになっています。
まとめ
- 良いプロダクト開発とは「顧客が課題を気持ちよく解決できること」
- デザインドリブンで仕様を作り、技術はそれに合わせる
- PO は「何を」、デザイナーは「どう使うか」、エンジニアは「どう実現するか」を担う
- 技術チェックは UI 完成後に入れる。先に体験を固めてから技術で実現する
- 迷ったら「アクション」に立ち返る。画面や実装の話に引きずられない
- 3人チームだからこそ、フローと役割分担を明確にすることで、質とスピードを両立できる
最小構成のチームでも、フローが整っていれば質の高いプロダクトは作れます。むしろ少人数だからこそ、意思決定が早く、フィードバックループが短く、全員がプロダクトの全体像を把握できる。これは大きなチームにはない強みです。
一緒に働きませんか？
Purpom Media Lab では、一緒にプロダクト開発を行うエンジニアを募集しています！
興味のある方は 会社サイト をご覧いただくか、@coa00 までお気軽にDMください。