プロダクト開発の流れとは？重要なポイントや選ばれるプロダクトの条件も紹介！

プログラミングを覚えてこれからプロダクト開発をしたい方や新規事業開発に興味のある方にとって、プロダクト開発の流れは最初に気になるポイントでしょう。

近年はノーコードやライブラリ、API、開発統合環境（テキストエディター）などの充実によって開発への参入障壁が急激に下がりつつあり、プロダクト開発に携わりたいと考える人は増えています。

そこで本稿では、これからプロダクト開発を検討している人が持つ、以下のようなお悩みを解決します。

• プロダクト開発の流れを知りたい
• システム開発とプロダクト開発の違いを知りたい
• プロダクト開発を成功させるために重要なポイントを知りたい

ぜひ、これからの取り組みの参考にしてください。

プロダクト開発とシステム開発の違い

プロダクト開発の流れや詳細を説明する前に前提として、混同されやすいプロダクト開発とシステム開発の違いを簡単に解説します。

プロダクト開発	目的を実現できる適切なものを開発
システム開発	既に定まっている要件を形にする開発

プロダクト開発は、目的達成のために紆余曲折しながら開発していくのに対し、システム開発は作成物の要件やゴールが決まっています。

いずれも同じような意味に思われるかもしれませんが、これは大きな違いです。イメージとしては、開発の受託案件はシステム開発、自社の新規事業・サービス開発はプロダクト開発です。

システム開発（受託案件）の場合は、あらかじめゴールを形にする方法が提示されており、新規事業・サービス開発（プロダクト開発）の場合は、ゴールは決まっていても形にする方法が提示されていません。

つまり、プロダクト開発はゴールに到達するまでのプロセスから自分たちで思考・設計する必要があります。

プロダクト開発の基本的な流れ

一般的なプロダクト開発の流れは以下の通りです。

上図の戦略検討〜本番リリースと確認までの7フェーズを、それぞれ順に詳しく解説していきます。

1.戦略検討

まず、以下のような前提条件となる目標や戦略を決めます。登る山を決め、誰と、いつ、どこから出発して、いつまでに登り終えるかを決めるイメージです。

• プロダクトによって成し遂げたい目標
• プロダクト開発に割けるリソース（ヒト・モノ・カネ、時間）
• ロードマップ

開発職は営業職とは異なり、直接的に利益を上げることが難しい職種です。

そのため「エンジニアは数字を追わなくて良いから羨ましい」と思われることが多いですが、実際はその逆であり、ROIにシビアなエンジニアが多いです。

それは、当該プロダクトによって生み出したい利益（ゴール）と、その利益創出にかかるコスト（リソース）を死守しなければ、戦略が破綻するからです。

2.開発項目の洗い出し

次に開発項目を洗い出します（※新規プロダクトの場合は、要件定義後に行われます）。

プロダクト開発では「あったらいいな」という機能が無限のように生まれてきます。これは、開発者自身のアイディアもありますが、営業職やユーザーから意見をもらって開発項目が増える場合も多いです。

限られたリソースの中ですべての「あったらいいな」を実現することはできないため、それらを開発項目としてリスト化し、それぞれに優先順位をつけて、目標への寄与度が高いものから着手するようスケジューリングを行います。

ペルソナ(*1)の策定もこのフェーズで行います。

*1：ペルソナとは、当該プラダクトの仮想ユーザーです。年齢・性別などの一般的な情報だけでなく、デモグラフィック情報・サイコグラフィック情報と呼ばれるさまざまな人物情報を仮想ユーザーに当てはめます。

3.要件設計＆UIデザイン

次に機能別に要件定義を行います。要件定義ではユーザーの本質的な課題を抽出し、その課題をどのような機能で解決するかを設計します。

場合によってはこのタイミングでデザイン（UI）の設計も行います。デザインが課題解決に寄与することがあるためです。

このフェーズでよくある間違いは、課題ではなく問題を抽出してしまうことです。

たとえば「CVRが低いので導線ボタンを増やしたい」という要望をユーザーから受けた場合、問題解決的な発想をすると「CVRを高めるために導線ボタンを増やす」です。

しかし、プロダクト開発においては課題解決をしなければいけません。

したがって上記ユーザーの要望は「CV数を最大化する」という本質的な課題を捉え、「CVRを高めることが本当に課題か」「CVRに大きな影響を与えているポイントは本当に導線の数か」などを検討し、機能要件に落とし込む必要があります。

4.設計

設計フェーズでは、要件定義で固まった機能の仕様をどのようにシステムとして実現させるかを設計します。

具体的には、最終的なアウトプットデータに必要なインプットデータの洗い出しや、データの保存形式、アプリとデータベース間の連携方法などを決めます。

アジャイル型開発の場合は設計書を作成しませんが、ウォータフォール型開発の場合は設計書を作成することが一般的です。いずれも良し悪しがあるので、企業の開発方針によってどちらを選択するかが分かれます。なお、近年はアジャイル型開発が多いです。

設計内容はステークホルダーへの確認が終わってから確定します。たとえば、画面設計や帳票設計は直接ユーザーの操作性に関わるため、設計案がある程度固まったらユーザーレビューを行うことが多いです。

5.実装・レビュー

設計が完了したら、プログラミングを進めます。

実装されたソースコードは、プロジェクトの技術責任者やメンターがレビューします。レビューの目的は「実装の品質担保」「情報の共有」の大きく2つです。

一度書いたソースコードは何度もいろいろな人に読まれることになるため、読みやすく書くことが非常に大切です。読みにくいソースコードは、コード解析に時間がかかるなど保守・運用フェーズや改修時に大きなコストになります。

6.テスト・品質保証

実装したプログラムが正常に動作するかテストを行います。

テスト方法は企業によってさまざまですが、単体テスト、結合テスト、耐久テスト、ユーザーテストの4つは基本的に行われます。

「実装・レビュー」フェーズで一度ソースコードはレビューされているものの、レビューを100%正確に行うことは不可能です。実データを利用したテストや結合テストでしか気付き得ないことは多いため、念入りにテストが行われます。

7.本番リリースと確認

テスト完了後、プロダクトを本番環境にリリースします。リリース後はすぐに開発メンバーが本番環境での動作に問題がないか確認します。

リリース前は、テスト環境と呼ばれる本番環境以外のところで開発が進められています。

そのため、本番環境とテスト環境がまったく同じということは少なく、本番環境にリリースして初めて問題に気づくというケースも少なくありません。

もし、本番環境での動作に問題があった場合は、すぐにリリース前の状態に戻し、問題箇所の特定と修正、テストが完了してから再度本番環境にリリースします。

なお、本番環境へのリリースは最もアクティブユーザーが少ない時間帯で行われることが多く、具体的には深夜0~4時頃が選ばれやすいです。

プロダクト開発で重要なポイント

プロダクト開発では忘れてはならない重要なポイントをご紹介します。

作り込みすぎないこと

新規プロダクトの場合は作り込みすぎないことが重要です。

新規プロダクトが本当にユーザーに刺さるか検証する意味でも、完璧を目指すのではなく60%程度の完成度で一度リリースする方が建設的です。

不完璧だからこそユーザーニーズが分かるというメリットがある上、100%まで作り上げてユーザーに刺さらなかった場合と比較して、損失を抑えられるというリスクヘッジもできるからです。

細かくテストすること

近年主流となっているアジャイル型開発では、厳密な仕様書や設計書がないため品質を担保するためには細かいテストを行うしかありません。

結合テストやユーザーテストだけを行うのではなく、リソースが許す限り細かい単体テストを実施しましょう。

特に想定通りに分岐処理が実行されていること、想定通りの例外処理が実現できていることは、徹底的に確認することをおすすめします。考えられるテストパターンを洗い出しましょう。

失敗を恐れないこと

プロダクト開発は、スタートアップ企業でもどんなに豊富な知識やノウハウを持っている企業であっても、まったく新しいものを開発することになるため失敗は起きてしまうものです。

しかし、完璧な商品を開発したいという気持ちばかりが先行し、完成までに時間がかかり過ぎてしまってはリリースが後ろ倒しになった分だけ機会損失となります。

プロダクトのビジョンが決まっているにもかかわらず、仕様に大きな変更が加わった場合には相応の不安が伴いますが、失敗を恐れずに行うマインドが必要不可欠です。

最終的にはリリース後ユーザーの反応を見て、失敗を客観的に分析することになるため、要件を満たしていれば一先ずは良しとする心構えが大切です。

選ばれるプロダクトの条件

選ばれるプロダクトになるための必須条件をご紹介します。

ユーザーが使ってみたいと思える

どんなプロダクトでも普及率を伸ばす必要があるため、大前提として「使ってみたい」と思ってもらう必要があります。

そのためには、ユーザーが使ってみたいと思えるプロダクトが持つ特徴を整理し、自社プロダクトにそれを反映させると良いでしょう。

なお、気をてらった見せ方は認知には有効ですが、普及するかどうかは後述の2点に左右されます。

• 「どんなユーザーを想定しているのか？」の定義、ペルソナ設計
• カスタマージャーニーの完成度

プロダクトを必要とするユーザーが明確になっており、そのユーザーの一連の流れを理解していなければ、使ってみたい・使い続けたいと思うことはないでしょう。

ユーザー課題を解決している

プロダクト開発において最も重要と言えるポイントは、「ユーザー課題を解決すること」です。

プロダクトを利用するのはあくまでもユーザーであって、プロダクトの開発者ではありません。決して、開発者の思い込みで機能要件を定義しないように注意しましょう。

また、ユーザーが欲しいのはドリルではなく、穴であることを理解することが大事です。どんなドリルでもユーザーが欲している穴を作れないドリルは必要とされません。

ユーザーが使いやすい

プロダクトは、操作の簡易性や使いやすさが担保されていなければ、よほどの理由がない限りユーザーに選ばれることはありません。

ドリルの例で言えば、たとえ穴を開けられたとしても、持ち手部分がすぐに折れてしまうドリルを欲しいと思う人はいないでしょう。

• 英語の読めない日本人が想定ユーザーなら、ファーストビューに英語は使わない
• ボタンがクリッカブル（押せる）かどうかが瞬時に理解できる
• ユーザーのインフラ系ツールと簡単に連携できる

上記のようなユーザーへの細かい配慮が、ユーザーの定着率を高めます。

まとめ

普段プロダクト開発に携わっていない人は、本稿を読んでプロダクト開発者の業務が実装以外のところで大量にあることに驚いたことでしょう。

実装はほんの一部であり、選ばれるプロダクトを開発するためにどうユーザーニーズを満たすかという設計部分に大半の工数を割いています。

これからプロダクト開発のスキルを磨いて、多くの人に使ってもらえるプロダクトを開発したいという方は、ぜひ弊社Liberty Nationをご活用ください。

弊社ではフリーランスや副業を行っている開発者とプロダクト開発要員を欲している企業のマッチングを支援しています。リモートワークや短日勤務などご希望の働き方に対応した案件をご紹介可能ですので、興味がある方は以下のバナーよりぜひご登録ください。