01. 当サイトでは「制作プロセス」を整理
このページでは、TFキリンのMVP開発で大切にしている制作プロセスを整理します。
単にアプリやWebプロダクトを作るだけではなく、課題を見つけ、企画として整理し、UIに落とし込み、MVPとして触れる状態にし、検証結果から次の改善へつなげるまでを一連の流れとして扱っています。
このページで伝えたいこと
企画・UI・MVP・検証・改善を分断せず、ひとつのプロダクトづくりの流れとして考え、実際の制作物に落とし込んでいることです。
02. 制作プロセス全体像
制作では、最初から完成版を目指すのではなく、まずは課題と仮説を整理し、最小構成で体験を形にすることを重視しています。
課題発見・ユーザー理解 ↓ 企画・PRD・要件整理 ↓ UI/UX・情報設計 ↓ MVP実装・モック化 ↓ 検証・操作感の確認 ↓ 改善・次フェーズ設計 ↓ PROJECT記事として整理
この流れにすることで、アイデア段階の曖昧な構想を、採用担当者やプロジェクト関係者にも伝わりやすい「見える成果物」に変換していきます。
03. 企画・課題整理
最初に行うのは、「何を作るか」ではなく、「なぜ作るのか」を整理することです。
ユーザーがどのような場面で困っているのか、既存の方法では何が足りないのか、どの課題を解決すれば体験価値につながるのかを確認します。
この段階で整理すること
- 解決したい課題
- 想定ユーザー
- 利用シーン
- ユーザーが困るタイミング
- 既存サービスや競合の特徴
- 最初に検証すべき仮説
意識していること
自分が作りたい機能から考えるのではなく、ユーザーが困っている場面から逆算して、必要な体験や機能を絞り込むことを大切にしています。
04. 企画・PRD・要件整理
課題を整理した後は、プロダクトとしてどのような価値を提供するのかをPRDとしてまとめます。
PRDでは、背景、課題、想定ユーザー、提供価値、主要機能、体験フロー、UI/UX設計意図、技術設計の考え方までを整理します。
PRDで明確にすること
- このプロダクトを作る理由
- 誰のどの課題を解決するのか
- どのような体験価値を提供するのか
- MVPで扱う範囲と、後回しにする範囲
- 将来的に拡張したい機能
- 記事として第三者に伝わる構成
たとえばGoal Mapでは、資格取得や受験、就職活動など、期限のある目標に対して「ゴールから逆算して現在地を把握する」体験を中心にPRDを整理しました。
TFキリンのMVP開発05. UI/UX・情報設計
企画や要件を整理した後は、ユーザーが迷わず使える画面構成へ落とし込みます。
ここでは、見た目のデザインだけではなく、何をどの順番で見せるか、どの操作を最小限にするか、どの情報を常に見える状態にするかを考えます。
UI/UX設計で見るポイント
- 最初に何を入力すればよいかが分かるか
- ユーザーの現在地が把握しやすいか
- 次に取るべき行動が判断しやすいか
- 画面遷移が複雑になりすぎていないか
- 情報量が多すぎて、重要な情報が埋もれていないか
- MVP段階で検証したい体験に集中できているか
UI設計の考え方
機能をすべて並べるのではなく、ユーザーが「今どこにいて、次に何をすればよいか」を理解しやすい画面にすることを重視しています。
06. MVP実装・プロトタイプ化
MVPでは、完成版に必要なすべての機能を入れるのではなく、検証したい体験に必要な最小構成へ絞ります。
実装できる範囲、モックで検証する範囲、構想として残す範囲を分けることで、検証の目的がぼやけないようにします。
MVPで意識すること
- 最小構成で体験が成立するか
- ユーザーが操作の流れを理解できるか
- 主要な画面遷移に無理がないか
- 検証したい仮説に対して、必要十分な機能になっているか
- 将来的な拡張を妨げない構造になっているか
満腹ポンでは、子ども向けゲームとして「ユーザー vs COM」のローカル対戦に範囲を絞り、短時間で遊びが成立するかをMVP要件として整理しました。
満腹ポン｜グルメじゃんけん開発メモ
07. 検証・操作感の確認
MVPやモックを作成した後は、実際に触れる状態にして、操作感や導線、仕様の妥当性を確認します。
検証では、作ったものが予定通り動くかだけでなく、ユーザーが迷わず使えるか、想定していた体験価値が伝わるかを見ます。
個人制作やポートフォリオ上では、モックやMVPを通じて体験の成立性を確認する範囲が中心になります。一方で、実際の業務では、実装後にQAテストや受け入れ確認、チーム内でのリファインメント、仕様調整、優先順位の見直しなどが入る想定です。
業務で追加される確認・調整
- QAテストによる不具合確認
- 仕様通りに動作しているかの受け入れ確認
- デザイナー、エンジニア、PdM、関係者とのリファインメント
- 実装難易度や工数を踏まえたスコープ調整
- リリース前後の改善優先度の整理
検証で確認すること
- 初見でも目的が伝わるか
- 操作の手順が自然か
- 画面遷移に迷いがないか
- 入力や確認の負担が大きすぎないか
- 想定していた課題解決につながっているか
- 次に改善すべき箇所が見えているか
優良ドライバーチェッカーでは、JINS-MEMEやSDLを活用し、運転中の確認行動や注意力を可視化する体験をMVPとして検証しました。
08. 改善・次フェーズ設計
検証後は、うまくいった点だけでなく、使いにくかった点、実装が難しかった点、次に確認すべき点を整理します。
ポートフォリオとしては、完成結果だけでなく、課題を見つけて改善につなげる過程も重要な実践記録になります。
業務で進める場合は、個人判断だけで改善内容を決めるのではなく、QAで見つかった不具合、チームからのフィードバック、リファインメントで整理された論点を踏まえて、次スプリントや次フェーズで対応する範囲を決める流れを想定しています。
改善時に整理すること
- 検証で分かったこと
- 想定と違っていたこと
- ユーザーにとって分かりにくい箇所
- 削るべき機能、追加すべき機能
- 次フェーズで検証すること
- 本格実装する場合の優先順位
改善の考え方
最初から正解を作るのではなく、触れる形にしてから検証し、見えた課題をもとに仕様やUIを更新していくことを前提にしています。
09. 事例で見る一連の流れ
この制作プロセスは、各PROJECT記事の中でも具体的に整理しています。PRD記事とMVP検証記事を分けて読むことで、「なぜ作るのか」と「どこまで検証したのか」を確認しやすくしています。
Goal Map（学習進捗管理アプリ）
優良ドライバーチェッカー（安全運転支援アプリ）
満腹ポン（子ども向けカジュアルゲーム）
10. 対応領域とスキルのつながり
制作プロセスでは、企画、設計、デザイン、実装、検証の各領域を横断して扱います。
それぞれの工程を分断せずに見ることで、単なる画面制作ではなく、プロダクトとしての成立可能性を確認しながら進めることができます。
対応領域
- 企画：課題設定、ユーザー整理、競合分析、提供価値の定義
- PRD：背景、目的、主要機能、体験フロー、フェーズ設計の整理
- UI/UX：情報設計、画面遷移、操作導線、見やすさの調整
- MVP：最小機能への絞り込み、モック作成、プロトタイプ化
- 検証：操作感、導線、仕様の妥当性、改善点の整理
- 記事化：制作背景、判断理由、学び、次の改善方針の言語化
11. PROJECTへの導線
各プロジェクトの詳細は、PROJECT一覧やカテゴリ別の記事から確認できます。
採用担当者やプロジェクト関係者には、まずこのPROCESSページで制作の流れを確認し、その後にPROJECT記事で具体的な実践内容を見てもらう導線を想定しています。
12. まとめ
TFキリンのMVP開発では、企画・UI・MVP・検証・改善を一連の制作プロセスとして扱っています。
アイデアを出すだけでなく、ユーザー課題を整理し、PRDとして要件化し、UIに落とし込み、MVPとして触れる状態にして、検証と改善へつなげることを重視しています。
今後も、各PROJECT記事では「何を作ったか」だけでなく、「なぜ作ったか」「どこまで検証したか」「次にどう改善するか」が伝わるように整理していきます。
