こんにちは、プロダクト戦略部の土屋です。普段はFAANS（アパレル店舗で働くショップスタッフ向けの業務支援ツール）のプロダクトマネジメントを担当しています。
「新しいことをやりたいけれど、既存タスクで手一杯」プロダクト開発の現場では、こうした状況は珍しくありません。特に、特定の領域や役割にタスクが偏りやすい構造的な課題を抱えた組織では、新しいチャレンジが後回しになってしまうケースも多いのではないでしょうか。
この記事では、チーム内のリソースの偏りという組織的な課題に対して、私たちが取り組んだ「PoC専用開発レーン」の設計と運用についてご紹介します。設計思想から開発フローまで具体的な内容をお伝えできればと思います。
FAANSの開発チームについて
FAANSの開発チームは、バックエンド、フロントエンド（Web/iOS/Android）、デザイン、プロダクトマネジメントの各専門領域で構成されています。PdMが要件定義と優先順位の調整を図り、デザイナーがUI/UXを設計、エンジニアが実装を担当するという、比較的オーソドックスな体制です。
具体的な開発フローとしては、まずPdMが事業側からの要望やユーザー課題を整理し、デザイナーと連携しながらUI/UXを固めていきます。デザインデータが完成次第、バックエンド・フロントエンドの各エンジニアと連携しながら仕様の細部を固めつつ実装に進みます。開発が完了したらQAによるテストを経てリリースするという流れで日々の開発が行われています。
もちろん、各エンジニアチームには通常の機能開発以外にも、技術負債の解消やライブラリのアップデート、パフォーマンス改善といった保守運用系のタスクが常にあります。また、デザインチームについては、FAANSだけでなく複数のプロダクトやプロジェクトを掛け持ちしているので、タイミングによってはリソースの確保に事前調整が必要になります。
そんな事情もあり、普段の開発では「バックエンド・フロントエンド・デザインのタイミングが揃わないとなかなか動き出せない」というのが暗黙の前提になっていました。
直面していた課題
直面していた課題を振り返ると、バックエンドの領域にタスクが継続的に集中している状況がありました。バックエンドはソフトウェア開発の屋台骨ともいえる存在であり、優先度の高い機能改修や緊急性の高い対応が日常的に発生していました。そうした背景もあり、バックエンドチームは常に目の前のタスクに追われ、新しい取り組みに十分な工数を割く余裕がなかなか生まれない状態になっていました。デザインチームについても、複数案件の並行対応や人数的な制約があり、スピード感をもって新しい挑戦に取り組むことが難しい場面も少なくありません。
一方で、フロントエンドチームには時期によって余力のあるメンバーが出てくることもあり、FAANS開発チーム全体としてはリソースに偏りが生じていました。
その結果、新しい取り組みをしたくても「バックエンドが動けない」「デザインが動けない」といった理由から後回しになるケースが常態化しつつありました。競争環境が変化し続ける中で、検証やチャレンジのタイミングが遅れることは大きなリスクにもつながります。
こうした背景があり「フロントエンド側の余力を戦略的に活用し、バックエンドやデザインに依存しない形で何か開発が進められないか」という問いが生まれてきました。この課題意識を起点に、PoC専用の開発レーンを設ける構想へとつながっていきました。
| チーム | 現状の課題と状況 |
|---|---|
| バックエンド | 優先度の高いタスクが多く、新規開発のリソース確保が難しい |
| デザイン | 複数案件の並行対応や人数的な制約がありリソース確保に調整が必要 |
| フロントエンド | タイミングによっては一部メンバーに余裕があり、比較的自由に動きやすい |
PoC専用開発レーンの設計
これまでの課題を踏まえると、バックエンドやデザインのリソースが空くのを待つ前提では、新しい取り組みの検証スピードを上げられません。アイデアを素早く試し、学習サイクルを回すためには、既存の開発フローとは独立した仕組みが必要でした。
そこで通常の開発ラインとは切り離し、PoCに特化した専用レーンを新たに設けることにしました。既存フローの中にPoCを組み込むと、本番開発との優先順位の競合が避けられず、緊急度の高いタスクが入るたびにPoCは先送りされてしまいます。専用のレーンを用意することで、本番開発への影響を抑えつつ、検証を並行して進められる体制を整えました。
このレーンでは、スコープを「フロントエンドのみで完結するプロトタイプ」に限定しています。モックやスタブを活用し、バックエンドが未整備でも動作する仕組みを用意することで、依存の大きい領域を待たずに検証を進められるようにしました。本来バックエンドが担う処理も、「フロントエンド側でどこまで代替できるか」という観点で柔軟に検証しています。
また、デザインの領域においても、UIの品質や体験の一貫性を損なわないよう、既存のデザインルールをベースにする最低限の設計指針を設けています。加えて、作業の効率化と初期検討の加速を目的に、AIツールの活用も推奨しています。こうした工夫により、限られた体制でも一定の品質を担保しながら、スピーディに検証を進められるように設計しています。
PoCで想定しているケースとしては、UIレベルでの新機能の仮説検証、フェイクデータを用いたUXインタラクションの確認、AI関連機能のプロトタイピングなどです。体制はPMとフロントエンドエンジニアのみというシンプルな構成にし、チーム内から「試したい機能」や「気になっている仮説」を広く募集する運用としています。
PoCの意義を定義する
PoCを導入するにあたり、まず「一般的なPoCの理解」と「チームとして実施するPoC」を明確に区別するところから始めました。名前は同じでも、前提としている目的やゴールが微妙に異なり、その認識がずれると期待値の齟齬が生まれます。この差分をチームで揃え、エンジニアリングの境界をクリアにするところから着手しました。
1. 一般的なPoCの理解
一般的には、PoCは次のように捉えられがちです。
本番実装に向けた“前段階”
→ 小さく作って、最終的にそのままプロダクションに向かう前提で考えられることが多い。ある程度完成度の高い検証物を作るもの
→ 動くものを作り、そこでユーザーの反応や技術的な実現性を検証するイメージ。本番実装に“進むため”の判断材料
→ 基本的には「GO」することを前提としたマイルストーン扱いになりやすい。
こうした一般像だと、「どの程度作る必要があるのか」「どのレベルの完成度が必要か」が曖昧なまま進み、工程が重くなるケースが多いことが課題です。
2. チームで定義したPoC
これに対して、私たちはPoCの役割をより軽量で判断特化に寄せて定義し直しました。
本番実装を“やるかどうか”を判断する活動
→ PoCは「やる／やらない／いつやるか」を決めるための材料集め。“作らないことで得られる利益”も検証対象
→「これはやらないほうがいい」と低コスト・短時間で判断できることもPoCの成果。検証物は捨てるつもりで最小限必要なものだけを作る
→ 動くものは必要最小でOK。目的は決定の前倒し。正解より“判断の質”を重視
→ 結果「今回は採用しない」に至った場合も“成功”と捉える。
| 1. 一般的なPoCの理解 | 2. チームで定義したPoC | |
|---|---|---|
| 目的・位置づけ | 本番実装に向けた「前段階」 | 実装要否の「判断材料」 |
| 前提スタンス | 本番化が前提 | やらないのも重要な成果 |
| アウトプット | 完成度の高い動くモノ | 判断ができる最小限の動くもの |
| 重視すること | 技術検証、ユーザー反応 | 早期の意思決定・判断の質 |
重要なのは、“作ること”そのものではなく、“判断に必要な材料を短期間で揃えること”です。この考え方をエンジニアと共有し、PoCでは「検証物は捨てるつもりで、判断に必要な最小限だけを作る」という原則をチーム内で統一しました。
「最小限って、どこまで？」という議論も当然ありましたが、最終的には“振る舞いだけ掴めれば十分。作りすぎはむしろ困る”という、普段の開発ではまず出てこないPoCらしい落とし所に落ち着きました。PoCで求められる完成度は、体験の“手触り”を得られるかどうかであり、本番品質を追い始めると、スピードの面でも検証の本筋から外れてしまうことがあります。
仮に検証の結果として「今回は採用しない」という判断に至ったとしても、それは失敗ではなく、「低コストで正しい選択ができた」という意味で成功と捉えています。事実、本格的な実装へ踏み込む前に見極めができれば、時間・工数ともに大きく節約できるため「やらない」という判断は大きな価値のひとつです。
また、この価値観をチームで共有しておくことで、PoCが“前向きに失敗できる場”として機能し、アイデアを出す側も過度に結果を恐れずより多くの選択肢を素早く試せるようになります。
こうした方針により、PoCは「やる・やらない・いつやるか」といった意思決定を前倒しし、本番開発の優先順位づけにも役立つ仕組みとして設計しました。
具体的な開発フロー
PoC開発は大きく4つのフェーズで進める設計にしています。
最初のフェーズは「企画・要件定義」です。PdMがPoCの目的、検証したい仮説、検証観点、完了基準を定義します。ここで大事なのは、「何を検証するのか」をあらかじめ明確にしておくことです。PoCにおいてはある程度の曖昧さを許容して動き出すことがポイントではありますが、最低限何が知りたいのかはクリアにしておく必要があります。
なお、PoCのアイデア自体はエンジニアと一緒に検討しており、「こんな機能があったらいいな」「これ試してみたい」といった声を広く募集しています。現場で感じる課題やユーザーの声に近いところからアイデアが生まれることもあれば、技術ドリブンで試してみたいという動機から始まることもあります。どの入口からの提案であっても歓迎できるよう、気軽にアイデアを出せる雰囲気を大切にしています。
次のフェーズは「事前準備・スコープ設計」です。本当に検討する価値があるかを精査した上で、各プラットフォーム（Web/iOS/Android）の担当を割り当てます。技術的に検証の必要な項目があれば明文化し、大まかなスケジュールを引いておきます。
3つ目のフェーズが「開発・仮説検証」です。ここでUI実装、モック接続、動作確認を進めていきます。限られた工数の中で最大限の学びを得ることが目的なので、完璧を目指すよりも「触って確認できる状態」を優先します。できあがったUIの共有方法は各プラットフォームの担当におまかせして、柔軟かつライトに進められるよう設計しています。
最後のフェーズは「レビュー・評価」です。関係者を集めて実際に操作しながらレビューし、この機能をどうしていくか最終的に判断します。同時に、今回の検証で得られたナレッジや課題、気づきも洗い出して記録に残していきます。
得られた成果
PoC開発を進める中で、これまで手をつけづらかったUX改善にも取り組めました。検証だけで終わらず、実際にリリースされている機能もあり、この取り組みで生まれたアイデアがプロダクト品質の向上に寄与しています。
通常の開発では、KPIに直結する機能や顧客要望への対応が優先されやすく、ユーザー体験を整えるための改善はどうしても後回しになりがちです。PoCでは、優先度は高くないものの価値のあるテーマにも一定の時間とリソースを充てられており、細かな体験改善や将来のプロダクトにつながるアイデアの検討が進んでいます。こうした取り組みを通じて、中長期的な価値に寄与する領域にも少しずつ着手できている実感があります。
また、PoCによってプロトタイプという形で実際に手を動かす中で、チーム全体があらためてUXの重要性や改善の余地を実感できたことも、今後の開発方針に影響を与える大きな収穫でした。PoCは、単なる機能検証の場ではなく、自由度の高さを活かしてプロダクトの“未来の選択肢”を広げるための戦略的な取り組みとして、今後も活用していきたいと考えています。
実施して出てきた課題
PoCを始めてみると、うれしい誤算として多くのアイデアが寄せられました。ただ、数が増えるほど「どれから検証すべきか」という優先順位づけが難しくなる課題も見えてきました。さらに、寄せられる案の中にはPoCというより通常の機能改修に近いものも混ざっていて、本来の “意思決定のための検証” という意図からズレる場面も出てきました。
そもそもPoCは、開発フローの設計も含め、やりながら整えていく側面が強く、扱うテーマも抽象度が高い取り組みです。そのため、進行中に生まれる小さな曖昧さが積み重なり、PoCとして扱う範囲の線引きが見えにくくなりやすい性質があります。こうした境界の揺らぎは、優先順位の判断をより難しくする要因にもなっていました。
この課題については、いまもベストプラクティスを探っている段階です。どこまで曖昧さを残し、どこから整理していくべきかを、進めやすさや開発スピードとのバランスをとりながら検討しています。
一例として、検証テーマの粒度や、PoCで扱う論点の範囲を最初に軽く決めておくだけでも、後の判断や優先順位づけが格段にしやすくなります。ただ、初期段階で基準を固めすぎてしまうと、PoCの強みである柔軟な探索の余地をかえって狭めてしまう恐れもあります。こうしたトレードオフを踏まえ、実務で運用しやすい落とし所を模索している状況です。
PoC開発をより扱いやすく、価値につながりやすい形へ育てていくためにも、試行錯誤を続けながら、少しずつより良い仕組みに寄せていきたいと考えています。
まとめ
この記事ではFAANS開発チームで取り組むPoC開発についてご紹介しました。
この取り組みはまだ発展途上ですが、チームとして小さな改善を積み重ねる中で、着実に機能し始めています。重要なのは、一度仕組みを作って終わりにするのではなく、実際の検証プロセスから得られた気づきを元に柔軟にアップデートし続けることです。早く試し、早く学び、的確に「やる／やらない」を判断できる体制は、長期的な競争力にも直結します。
今後もチーム全体で学びを共有しながら、PoCがより価値を生む仕組みになるよう改善を続けていきたいと考えています。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからご応募ください。
