戻る【2022年最新】プロトタイプ開発とは？概要やメリット・デメリットをわかりやすく解説 Hybrid Technologies Co,Ltd
システム開発において、プロトタイプ開発という手法は以前からありましたが、主流にはなっていませんでした。しかし、昨今はコスト削減にもつながるとして注目を集めてきています。ここでは、プロトタイプ開発とは何なのか、その流れや、メリット・デメリットをご紹介します。
プロトタイプ開発とは？
プロトタイプは、「原型機・試作機・試作品」などの意味を持ちます。大量生産を前提として商品を開発する製造業の世界ではとても馴染みのある言葉で、新しい商品を生み出す際はいくつかのプロトタイプを製作したのち、品質を高めていくのが通例です。
システムにおけるプロトタイプという言葉には、プログラムの原型・試作という意味があります。プロトタイプ開発は、一般的なソフトウェア開発の手法の1つで、開発の早い段階でシステムの簡易版をつくり、その試作品を依頼者が評価、テストを繰り返しながら最終的な完成を目指していくことを指します。
プロトタイプ開発が注目されている理由
プロトタイプ開発という手法は、近年登場したものではなく、実は1970年代には既に採用されていたそうです。しかし、システム開発の主流はウォーターフォール開発が定着しており、さほど注目を集めるほどではありませんでした。
これには理由があり、昔はせっかくプロトタイプを制作しても使い捨てとして破棄されており、そのせいで開発コストが高くなっていたことが影響していると考えられています。
しかし現在は、制作したプロトタイプを破棄することなく、修正を加えながらブラッシュアップして活用する「進化型プロトタイピング」が採用されるようになり、開発コストが抑えられることで注目が高まっています。
プロトタイプ開発の流れ
プロトタイプ開発の流れについて見ていきましょう。大まかな流れは、以下の通りです。
- 要件定義、基本設計
- プロトタイプ制作
- レビュー、テスト
- 修正
- 本開発
プロトタイプ開発の要件定義は、厳密には行わず簡易的なものを決めておくのが特徴です。試作のレビュー後に要件を詰めていくこととなるため、この段階ではシステムの目的から機能を具体化する作業となります。
プロトタイプの制作も、レビューまではメイン機能や特別に検討をしていきたい部分のみの実装です。作成したプロトタイプをテストして評価し、フィードバックをもとに修正を行います。修正をした部分は再度レビューを受け、これを繰り返して作り上げていきます。
修正とレビューを繰り返して課題がなくなった段階で、本開発に入ります。本開発では、システムの細部についても整えていき、問題がなければリリースです。もちろん、リリース後に新たな課題や不具合が生じれば、その都度修正を加える必要もあります。
システム開発とは？開発工程と手法ごとのメリット・注意点、外注先の選び方まで紹介！
スパイラル開発とプロトタイプ開発の違い
プロトタイプを活用するという意味では、プロトタイプ開発とスパイラル開発には共通点もあります。しかし、両者は似ているようで異なる部分もあり、違いを知ると目的に沿った方法が見つかりやすくなります。
スパイラル開発は、開発対象のプロダクトを重要な機能ごとに分割して、その分割した機能それぞれに対して設計、開発、テスト、レビューを繰り返す手法のことを指します。
一方、プロトタイプ開発は、改善を前提として大まかなプロトタイプをつくり、修正とレビューを繰り返して本開発に向けていく手法です。つまり、スパイラル開発とは違い、最初の段階からプロダクト全体を網羅するプロトタイプを作るという点が大きな違いと言えるでしょう。
より詳しく見ると、プロトタイプ開発は、プロダクトの方向性を作りながら絞り込んで決めていく手法であるのに対し、スパイラル開発はプロダクトの品質を高めていく手法といった側面が見えてきます。
プロトタイプ開発とスパイラル開発は、両方ともプロジェクトを早期にスタートし、プロダクトの品質を高めていきやすいことがメリットです。一方、開発には時間がかかりコストも膨らみやすい点は、共通するデメリットと言えるでしょう。
プロトタイプ開発のメリット
プロトタイプ開発が注目を集めているのには、いくつかの理由があります。メリットについて見てみましょう。
完成像を早い段階で共有できる
プロトタイプ開発は、早い段階から試作品を作成するため、あまりシステムのことについて詳しくない方でも完成形のイメージを想像しながら進めていくことができます。実際のプロダクトを見て、操作をして、思い描く理想の形にどうやったら近づけることができるのか考えていくことは、何もない状態から考えるよりも簡単です。
また、テストとレビューを繰り返しながら品質を高めていくプロトタイプ開発だからこそ、発注側と開発側が細かなやりとりを通じて同じ認識を持ちやすいというメリットもあります。発注側の意図がうまく伝わらず、大幅な修正を行うなどの無駄が省けるでしょう。
想定外のリスクを回避できる
発注側と開発側が同じ認識で進められるというメリットは、想定外のリスク回避にもつながります。発注側は、プロトタイプ開発の経験や知識がないぶん、どうしても意見が対立することもあるでしょう。しかし、試作品を通してテストやレビューを細かく行うと、本開発の前にたくさんのリスクを想定して対策を行うことも可能で、発注側も理解を深めながら進めていくことができます。
さらに、テストを重ねているうちに、不具合が出る部分や使いにくい部分も見えてきます。改善すべき課題を早い段階で改善することで、本開発での不具合やバグが減少することも期待できます。
システムの品質を確保できる
プロトタイプ開発のテストやレビューを通してアイデアを出したり、1つひとつの課題を改善しながら進めていくことは、プロダクトの品質の高さにもつながります。
細かな仕様が整ったプロダクトを受けとるよりも、段階的にフィードバックをして開発していったシステムの方が、発注側の意図が十分に反映されると考えられます。
プロトタイプ開発のデメリット
メリットの多いプロトタイプ開発にも、デメリットはあります。総合的に判断することが大切です。
大規模なプロジェクトには向いていない
プロトタイプ開発は、関係者が多くなればなるほど難しくなります。ある程度、プロトタイプ開発に携わる人が絞られていれば、コミュニケーションの問題も発生しにくくなりますが、大規模なプロジェクトではそうもいきません。
段階的にテストとレビュー、そしてフィードバックを繰り返すプロトタイプ開発だからこそ、関係者のスケジュール調整や検証は必須です。関係者が多ければ、スケジュールの調整だけでも一苦労するケースもあり、作業効率が悪くなってしまう恐れがあります。
プロジェクトが難航する可能性がある
開発者側の目線に立つと、プロトタイプ開発のメリットはデメリットにもなる場合があります。発注側が段階的に現物を見て要望を出せることは、大きなメリットである反面、要望が細かすぎたり多すぎたりすることも珍しくないでしょう。
ときには、知識がない発注側の無理な依頼や要望に対して、意見が対立してしまうこともあるようです。うまく折り合いがつけば問題なく進められますが、そうでない場合は開発途中で泥沼化し、難航してしまう恐れもあります。
開発会社の負担が大きくなる
プロトタイプ開発は、開発者側の負担が大きい手法です。当然ながら、開発は専門的な知識や技術がある人が集中して作り上げた方が、早くスムーズに完成させることができます。しかし、試作品を段階的にテストして、発注側のフィードバックをもらうとなると、そのぶん工数が増えます。
そもそも、試作品といってもある程度完成品に近いものを作り上げる必要があります。なぜなら、中途半端な試作品は検証するのが大変だからです。その上、フィードバックによって修正していくとなると、回数によっては多大な労力を要します。
フィードバックをもらうまでに時間がかかったり、打ち合わせの日程調整がなかなかできなかったりすると、それだけ時間もかかります。本開発のあとで大幅な修正を行うことを考えると、その負担はどちらが大きいのかはケースバイケースですが、発注側とのやりとりの内容によって負担が増えやすいと考えられます。
プロトタイプ開発を採用するのにおすすめの開発
プロトタイプ開発のメリットとデメリットを見比べても、自社にとって良い方法なのか判断できないこともあるでしょう。そのような場合は、どんな状況にあればプロトタイプ開発が向いているのかも参考にして検討してみてはいかがでしょうか。
新規サービスなど、実現性が不透明なサービスを開発するケース
プロトタイプ開発では、試作品を用いてニーズを検証したり、技術的に実現できるかどうかを確認したりしながら進めていくことができます。そのため、仕様が明確に決まっていないケースや、実現できるかどうか分からない新しいサービスを立ち上げる場合に向いています。
システム開発に慣れておらず、リスクを抑えたいケース
発注側がシステム開発に慣れていない場合、漠然としたイメージだけで依頼しなければなりません。プロトタイプ開発なら、システム開発に慣れていなくても、試作品を通してイメージがしやすく便利です。
完成に近づいたときに「イメージと違う」などの問題が発生するリスクを最小限に抑えることができ、コミュニケーションがうまくとれればスムーズに運ぶことができるでしょう。
ハイブリッドテクノロジーズの提供サービス
ハイブリッドテクノロジーズでは、ビジネスデザイン、UIUXデザイン、設計、実装、テスト、リリース、運用、保守まで一気通貫してサービスを提供しております。500名以上の経験豊富なエンジニアにより、迅速かつ高品質なシステム開発が可能です。 アジャイル開発、ウォーターウォール開発、ハイブリッド開発と言った様々な開発手法に対応しており、契約形態に関しましてもラボ型契約と受託型契約の2つから選択いただけます。お客様の状況や開発内容に応じて、開発手法と契約形態を柔軟にご指定いただけますが、それぞれの開発手法、契約形態の特徴の親和性から、アジャイル開発ではラボ型契約が、ウォーターウォール開発とハイブリッド開発では受託型契約を選択されるクライアント様が多数を占めます。
ラボ型開発について： ラボ型開発 サービス
受託型開発について： 受託開発 サービス
ハイブリッドテクノロジーズが選ばれる理由
弊社ではクライアント企業様及びエンドユーザー様の声を聞き、UIUXを意識したビジネスデザインを行なっております。 テーマを決めて分析し、仮説を立ててビジネスデザインを行い、プロトタイピング、検証、フィードバックを受け、再度分析から始める。 この一連の流れを、アジャイルスクラム開発に精通した500名以上のエンジニアが高速で回していくことにより、最速でより良いものを実現していきます。 ハイブリッドテクノロジーズには市場の声を現実にするための仕組みとメンバーが揃っています。
システム開発の成功事例
システム開発での成功事例をご紹介します。
見守りサービス (株式会社otta)
サービス内容
位置情報履歴を、無料スマホアプリやメールを通じて保護者様に伝えるサービス
サービス上の課題/目指したいサービス
課題
共働き世帯や高齢者の増加など、社会構造の変化により、子どもや高齢者の見守りへのニーズが急速に高まっている。一方で、見守る方々の高齢化や地域コミュニティの変化により担い手は減少方向にあり、この需給ギャップを埋めるには、見守りの仕組みの生産性を大幅に向上させなければならない。
目指したいサービス
IoTを活用した見守りサービスのパイオニア企業として、見守り活動の生産性の飛躍的な向上に貢献するとともに、従来のサービスでは困難であった、多くの方々にご利用いただける料金体系を目指すこと。
クライアントの課題/要望
・追加開発体制のリソースが不足している
・既存ベンダーの開発チームと組み合わせながら、チームを構築したい
・事業状況に応じて柔軟にリソースを調整したい
当社を選択していただいた理由
キャピタル案件であり、HTからの投資次第で開発も頼みたいという理由から
当社ご提案内容
業界ラボ型（ストック）開発＋保守にて提案
toB向け見守り管理システム開発
・今後の基盤変更も意識しながら登園バス管理システムの管理画面を作成し、サービス展開をしていきたい
・今後の開発体制構築も視野に入れつつまずはスモールに体制を構築しつつ今後の足掛かりとしたい
リソース活用し柔軟に対応できることと、javaを中心に進めていたが、よりモダンな言語を基盤に開発を進めたいという要望に対し、得意分野であった。
学習履歴データの可視化システム(放送大学学園)
サービス内容
学習履歴データ可視化システムの開発
サービス上の課題/目指したいサービス
課題
オンライン授業システムのデータベースには多量の学習履歴データが蓄積されており、このデータを学内の担当者が活用できるよう整備し、学生指導のためのヒントとして、あるいは学生に受講を促すための情報源として活用したいという意向があった。
目指したいサービス
・学外に開示する「サービス」ではなく、学内担当者用の「ツール」であること
・コマンドラインで操作可能なツールであること
・追加機能の実装をできるようにすること
クライアントの課題/要望
・社内で開発体制を保持していないこと
・金額をミニマムに抑えながら安定的な運用を実現したい
当社を選択していただいた理由
充分に仕様を満たす提案内容と他社と比較して最も安価な金額で入札提示したため。
当社ご提案内容
学習履歴データベースとBIツールの開発
オンライン授業システムのデータベースに蓄積された学習履歴データを活用するにあたって、実運用されているDBの処理とバッティングしないように、MongoDBに格納する処理にて開発を進めました。またMongoDBにデータを格納する際、他データとの連携も考慮し、汎用的なExperienceAPIに準拠したデータ形式を採用しました。
個人情報の扱いにおいては、開発人員含め、学生の個人情報の漏洩を防ぐため、学生の識別子を匿名化しての実装を実施しました。
DocIT (株式会社ドキットメディカルサービス)
サービス内容
働き口を探す医療従事者と、働き手を求める病院をつなぐマッチングプラットフォーム
サービス上の課題/目指したいサービス
課題
高額な紹介料がネックとなりスポットで人が必要な際に苦心をする病院の課題解決
目指したいサービス
休日や長期出張の空き時間を有効活用したい医師と、長期連休などで一時的に人手が必要となる病院をマッチングすることで医師の働き方の多様化を実現するサービス
クライアントの課題/要望
・サービス構想はあるが、実現させる開発パートナーが必要
・上流工程からの開発サポートが必要
当社を選択していただいた理由
開発にあたってサービス設計から本開発まで、一緒に伴走し考えながら開発してくれるパートナーとして安心感を感じて頂き、当社を選ばれました。
当社ご提案内容
ラボ型（ストック）開発にて提案
1.医療求人の性質を鑑みた機能提案、システム設計・開発
本サービスでは失敗の許されない医療系求人を取り扱うため、求人マッチングをする前に信頼のできる医師・病院であることを確認できることが重要となります。 そこで、実際に求人マッチングした医師・病院による相互レビュー機能を実装することで、信憑性の高いレビュー情報を蓄積することを提案・実現しました。 また、求人マッチング前に病院担当者と直接チャット出来る機能も実装することでレビューでは分からない定性的な情報確認も可能としました。 アジャイルスクラム手法の開発を取り入れることにより、システム開発の進捗報告を実際に動くシステム画面をお見せしながらデモンストレーション形式で毎週行いました。
2.定期的なスプリントを繰り返し、顧客と一緒に品質を高めるプロセスにて進行
実際に動くシステムを毎週見ていただくことで、開発進捗についての安心感やお客様も気がついていなかった新たな改善点がを発見でき、それを修正して再度デモンストレーションを行いました。この一連の流れを回すことで、お客様の求めるものを高い品質でご提供しました。
3.デザインを用いた視覚的なアウトプットで、具体的なシステムイメージを共有
Webサービス開発に初めて挑戦するお客様のため、お客様が思い描くビジネスを実現するためのシステムイメージを具体化していくデザインサポートも担当。求人情報サービスという特性上、さまざまな情報要素が混在する中で、目に見える形でデザインを整理・提案し、お客様からのフィードバックを受け、再提案を繰り返すことで、よりユーザーにとっての最適なWebサービスのための設計・提案・実現を行いました。
THINK, Reviewers (株式会社スパイス ボックス)
サービス内容
独自の「ソーシャルリスニング」手法をもって、企業と生活者の 間に生きたコミュニケーションを構築するサービス
サービス上の課題/目指したいサービス
課題
インフルエンサーの評価指標としてフォロワー数とエンゲージメント数が重要視されているケースが多いが、商品販売施策においては保存数が重視される。保存数を把握した上でインフルエンサーと企業のマッチングを行うプラットフォームが存在していなかったため、新たなサービスとしてスピード感を持ってサービス開発を行いたい。
目指したいサービス
・サービス名「THINK」：Twitter調査における既存システムの安定的かつ継続的な運用を維持しつつ、インフラコストを削減すること。
・サービス名「Reviewers」：インフルエンサーマーケティングで投稿保存数という指標を重要視するインフルエンサーマッチングプラットフォームの新規立ち上げをすること。
クライアントの課題/要望
・開発が発生した際に、都度RubyonRailsの対応人員を増やすのが難しい
・インフラ周りに強いメンバーがいない
・金額をミニマムに抑えながら安定的な運用を実現したい
・追加開発が発生した場合には、知見を維持した状態で取り組める体制がほしい
当社を選択していただいた理由
・開発リソースの柔軟性とインフラなど対応範囲の幅広さが先方ニーズにマッチしていたこと
・定常運用の際にもコストを抑えて対応できること
当社ご提案内容
受託型開発（フロー）にて提案
インフラ知見を持つディレクション人材をアサインメントすることで、インフラ周りの調整や業務対応にスピード感を持って対応できる体制を構築
インフラ/保守/開発を幅広く対応可能、かつ、コストミニマイズなオフショア体制をご提案しました。
ディレクション人材がインフラの知見を持ち、定常作業はベトナム側で行えるようにマニュアル化を行い、コストミニマイズしながらも幅広い知見を活かせる体制提案を行いました。
新規の開発が発生した際に、既存チームの知見を活かしながら適宜開発者を追加して、素早く開発を実行できる体制を実現しました。
まとめ
プロトタイプ開発は、システム開発において注目を集めている手法です。プロジェクトの規模などにより、向き・不向きは分かれるかもしれませんが、場合によっては質の高いプロダクトにつながる可能性も大いにあります。メリットとデメリットをよく理解して、システム開発の際には検討してみてはいかがでしょうか。
