システム開発プロジェクトにおいて要件定義は最も重要な工程といっても過言ではないでしょう。なぜなら、要件定義工程の失敗を取り戻すのは非常に難しいためです。ある調査※では要件定義工程の作業ミスをリリース時点で修正するためには、要件定義にかかった労力の200倍を要するという結果もあります。

要件定義はシステム開発プロジェクトの初期工程でありながら、システムの完成形を見据えて実施する必要があります。

この記事では、要件定義工程について、その重要性や具体的な進め方、必要なスキルなどをご紹介します。この記事を読むことで以下のことがわかります。ぜひご覧ください。

• 新規事業における要件定義の重要性
• 要件定義の具体的な進め方
• 要件定義において必要となるスキルや進め方のポイント

※参考：アラン M. デービス著、松原友夫訳「ソフトウェア開発201の鉄則」

要件定義とは？

要件定義とは、システム開発を始める前にシステムに対する要件を整理し、ドキュメント化する作業のことです。

要件定義では、システムに求める要素を要件定義書等のドキュメントとしてまとめ、今後のシステム開発のスタート地点とします。

要件定義はウォーターフォール型のシステム開発における工程の一つですが、アジャイル型でシステム開発を行う場合でも実施すべき工程です。

アジャイル開発では柔軟な方針の転換が可能ですが、事前に方針を決めずにプロジェクトに着手するのは危険です。要件定義を通して事前に構築すべきシステムの方向性を整理することで、プロジェクトの迷走を防ぐことができます。

アジャイル開発における要件定義につきましては、弊社スパイスファクトリーを取材していただいた「ROUTE 06 / 要件定義の最前線：アジャイル開発成功の秘訣」にも掲載されています。本記事と合わせて、読んでいただけたら幸いです。

参考記事：要件定義の最前線：アジャイル開発成功の秘訣

新規事業開発における要件定義の重要性

昨今では、他社との競争優位性確保や細かな市場ニーズへの適応のため、デジタル技術を利用して新規事業開発を進めるケースも増えています。

新規事業開発においてシステムを活用する場合、要件定義のプロセスは非常に重要となります。

要件定義では「どのようなシステムを開発するか」を細かく決めていきます。具体例を挙げると以下のとおりです。

• システムにどのような画面を用意するか
• システムはどのようなデータを持つか
• システムの想定利用者数はどの程度か
• システムにどのようなセキュリティ対策を行うか

新規事業の成功のためにはシステムの品質確保が重要です。たとえば、ユーザーニーズを満足できるだけの機能が無ければ、ユーザーの心は離れてしまいます。

また、せっかくビジネスが軌道に乗ったとしても、システムの想定利用者数を超えてしまえばアクセス集中によりシステムはダウンし、機会損失を生みユーザーの満足度も低下します。

サイバー攻撃により個人情報などが漏えいするリスクも考慮しなければなりません。

新規事業開発における要件定義は、ビジネスの成功という観点で具体的に開発するシステムの内容を決めていく、非常に重要な工程といえるでしょう。

なお、新規事業開発におけるデジタル活用の重要性は以下の記事でも解説しておりますので、併せてご覧ください。

※関連記事：DXを新規事業に取り入れるには？事例に学ぶコストをおさえて小さくはじめる方法

要件定義と要求定義の違い

要件定義とよく似た言葉に、要求定義というものがあります。両者は似ている言葉ですが、明確に異なるものです。

大まかに、発注者が行う「要求定義」と、開発会社が行う「要件定義」と理解するとよいでしょう。

要求定義とは、どのようなシステムを開発したいのかを、依頼側の立場としてまとめることです。自社にエンジニアがいない場合、システムを開発するためには外部の開発会社へ発注を行うことになります。

開発会社に開発したいシステムの内容を伝えるためには、誤解のないようにドキュメントで開発内容を明示してあげる必要があります。そこで、開発したいシステムの内容を要求定義としてドキュメント化します。

一方で、一般的に要件定義は開発会社側が主体となり行います。このとき、要求定義をインプットとして要件定義を行うこととなります。

なお、要件定義の主体は開発会社ですが、発注者側も無関係でよいというわけではありません。自社の希望するシステムを明確に開発会社に伝え、認識齟齬無くシステム開発を進める必要があります。

要件定義と基本設計の違い

ウォーターフォール型開発において、要件定義の次工程となるのが基本設計です。基本設計では要件定義で定めた内容をブレイクダウンし、より細かくシステムの開発内容を定めていきます。

具体的には、以下のような項目を決めていくこととなります。

• 各画面にどのようなボタンや入力フォームを設けるか
• システムのデータベースをどのように設計するか
• 他のシステムとどのように連携を行うか
• どのようなスペックを持ったサーバーやクラウド環境を用意するか

要件定義の進め方

以下では、当社スパイスファクトリーの知見やノウハウも含めながら、要件定義の進め方についてご紹介します。

ステークホルダーの特定

要件定義としてシステムの姿を定めるにあたり、まずは意見を聞くべきステークホルダーを特定します。

最も重要となるステークホルダーは、システムの想定利用者です。利用者の意見を最大限取り入れることで、満足度の高いシステムを作り上げることができます。

それ以外にも、データを連携するシステムの担当者や、システムの結果を間接的に利用する方など、システムに関連する方をもれなく洗い出していきます。

現行システムや業務フローの把握

現行システムが存在する場合、いわゆるAs-Isの整理として、そのシステムが持っている機能や画面、またそのシステムを利用した業務フローの整理を行います。

多くの場合、現行システムが備えている機能は新システムでも必要となるものですので、現行システムの分析は効率的な要件定義のアプローチとなります。

現行システムの資料が不足しており、十分な分析を行えないというケースもあります。この場合、システムを管理する有識者や業務の担当者へのヒアリングを通して、現行システムの姿を把握していきます。

システム像の具現化

要件定義を進める中で、「作りたいシステムが本当に実現できるのか分からない」という懸念を持つケースはよくあります。要件定義ではどうしても文字を中心としてシステム像をまとめますので、特にシステム開発に不慣れな場合はイメージが湧きにくいのも現実です。

当社では、要件定義の成果をできるだけ分かりやすいものとするべく、プロセスの最初からUXデザイナーが伴走します。これにより、イメージしづらいシステム要件を可視化しながら要件定義を進めることができます。

具体的には、UXデザイナーと共に以下のような成果物を作りながら、システム像を具現化していきます。

 

要素	概要
インセプションデッキ	・プロジェクトの目標、範囲、ステークホルダー、リスク、スケジュールなどの主要な要素を示す文書。 ・プロジェクトチームとステークホルダーが共通の理解を持つために使用される。
ユーザーリサーチ	・ターゲットユーザーのニーズ、行動、動機、ペインポイントを理解するための調査活動。 ・インタビュー、アンケート、観察、ユーザビリティテストなどの手法を使用する。
ユーザーストーリーマップ	ユーザーがシステムをどのように利用するかを視覚的に表現する手法。 ・単なる機能の羅列ではなく、具体的なシナリオと目的をセットにして要件を書き出すことで、ユーザーにとって価値のある体験を設計しやすくなる。
ワイヤーフレーム	・システムの主要な画面やインターフェースのレイアウトを示す図。 ・デザインや機能の具体的なイメージを共有しやすくし、初期段階でのフィードバックを得やすくするために使用する。 ・当社では「オブジェクト指向UI（OOUI：Object-Oriented User Interface）」の概念を用いて、インターフェースを直感的かつ効率的に設計する。
Figmaプロトタイプ	・ワイヤーフレームを基に、Figmaなどのツールを使用して作成されるインタラクティブなプロトタイプ。 ・ユーザーや利害関係者が実際に操作しながらフィードバックを提供できる。

要件定義書の作成

これまで整理した要件は、最終的に要件定義書として取りまとめます。要件定義書にはシステムに持たせる機能だけでなく、セキュリティやIT基盤などの専門的な要素も含まれます。

当社では、エンジニア・デザイナー・PMが連携し要件定義に臨み、プロジェクトの方向性や具体的な要件を見える化した上で文書化します。

要件定義に必要な項目

ここでは、要件定義で主に定める項目として、「スコープ」「機能要件」「非機能要件」の3つをご紹介します。

スコープ

スコープとは、プロジェクトが対象とする範囲や目標のことです。スコープを明確に定義することで、プロジェクトの方向性を明確にし、関係者間の認識齟齬を減らします。

スコープは可能な限り図を活用して示すとよいでしょう。対象とする業務やシステムを赤枠などで囲い、対象に含まれない業務やシステムを赤枠から除外することで、誰が見てもプロジェクトの範囲が分かりやすくなります。

その他、スコープに関連して以下のような要素を定めることも重要です。

項目	内容
プロジェクト目標	現在存在する課題や、課題に対してプロジェクトが達成すべき具体的な目標を整理する。
成果物	プロジェクトの完了時に提供する具体的な成果物（ソースコードやドキュメントなど）を整理する。
制約条件	予算、スケジュール、リソースなどの制約条件を明確にする。
前提条件	スケジュールの都合や順守すべき法令など、プロジェクトの実行に影響を与える前提条件を確認する。

機能要件

機能要件では、システム化の対象となる業務と、業務で利用するためのシステム機能を整理していきます。

業務フロー

システム導入前後の業務の流れを図示し、各プロセスを具体的に記述します。これにより、システムがどの業務をどのようにサポートするかが明確になります。

フローで業務を表すことで、関係者間の認識を統一しやすくなり、業務の改善点も明確になります。

機能一覧

システムに用意すべき機能を全て洗い出し、各機能の用途や必要性、処理内容をまとめます。重要度や優先順位も併記すると、より効果的な整理が可能です。

機能一覧にまとめた内容がそのまま実現されるシステムとなりますので、要件定義書の中でも重要度の高い項目といえます。

画面一覧

システム内で使用される全ての画面をリストアップし、それぞれの画面の目的や操作方法を詳述します。併せて、画面遷移図としてそれぞれの画面の遷移の流れを図示するとよいでしょう。

画面はユーザーが実際に操作するものであり、ユーザー体験を向上させるためにも重要です。UXの観点を意識して必要な画面を精査するべきです。

帳票一覧

システムから出力される帳票を全て記載し、各帳票の内容や使用される場面を整理します。併せて、帳票のフォーマットや項目も明示します。

特に法令対応が必要なシステムでは、出力する帳票は法令が求める要素を網羅しているか、フォーマットは問題ないかなども意識します。

データ項目

システムで使用されるデータ項目を全てリストアップし、各項目の名称、データ型、制約条件を明記します。

データを洗い出すことで、システム開発中や運用時にデータの一貫性を保ちやすくなります。

また、併せてシステム内のデータベース構造を視覚的に表現したER図を作成します。ER図は、データベース設計の基礎となり、効率的にデータを扱うために必須の資料です。

システム間インターフェース

開発するシステムが他のシステムと連携する場合、その連携する方法を記述します。具体的には、データの送受信方法や形式、頻度を整理します。

インターフェース仕様は、異なるシステム間で協調して処理を行うための文書です。必ず双方のシステム担当者間で打ち合わせを行い、認識齟齬が無いように整理します。

非機能要件

システムを作る上では、機能以外にもセキュリティ対策内容や用意するIT基盤なども定めなければなりません。これらは非機能要件として定義します。

操作環境

ユーザーがシステムを使用するためのハードウェアやソフトウェアの仕様を定義します。具体的には、対応するオペレーティングシステムやブラウザ、画面サイズ、デバイスなどを定める必要があります。

性能要件

システムが処理を実行する際の応答時間や処理能力を明確にします。

たとえば、平均応答時間として画面操作後のレスポンスタイムを定めるほか、最大負荷時の応答時間、スループット、同時接続ユーザー数を定義します。

性能はユーザーの満足度に直結するため、ピーク時でも安定した動作が保証される必要があります。一方で、過剰なスペックを持ったシステムは費用対効果の面で課題となりますので、適切な規模感での設定がポイントです。

可用性要件

可用性とは、システムが利用可能である時間の割合を指します。一般的に、可用性は稼働率として表現されます。

たとえば「99.9%の稼働率」であれば、一年の間に約9時間程度システムが停止することを許容することとなります。

99.99%、99.999%と高い可用性を設定すればそのぶんシステムが停止する時間帯は減りますが、高い可用性を実現するためには重厚なITインフラが必要です。

性能と同様に、業務要件を踏まえた適切な水準での設定がポイントとなります。

運用保守要件

運用保守要件として、システムの日々の運用や保守管理において必要となる要素を定めます。

具体的には、システムの監視方法やログ管理、障害対応、ソフトウェアの更新、パッチ適用などが含まれます。

運用保守を容易にするために、管理者がシステムを簡単に操作できる管理ツールやドキュメントの整備も重要です。

セキュリティ要件

セキュリティ要件では、データの機密性や完全性を守り、システムを安定的に稼働させるために必要となる対策を定義します。

ユーザー認証やデータの暗号化、侵入検知と防止方法、セキュリティパッチの適用、定期的なセキュリティ監査などが一般的に定められる要件です。

昨今のサイバー攻撃動向を踏まえると、セキュリティの確保は非常に重要です。見落としがちですが、要件定義においてしっかりと議論すべきポイントでしょう。

要件定義に必要な要素・スキル

要件定義には様々なスキルが必要となります。ここでは、特に重要なスキルについてご紹介します。

コミュニケーション能力

要件定義においては、発注者側・開発会社側問わず、的確なコミュニケーションを行うことが重要となります。

システム開発は専門的なスキルが求められる一方で、発注者側の方は必ずしもシステムを専門にされていない方も多いのが現実です。双方が異なるスキルや認識を持っている中で、認識齟齬なくシステムの開発内容を定めなければなりません。

コミュニケーションにおいては、可能な限り認識齟齬をなくすべく、ドキュメントベースでの確認を基本とします。

ITや業界に関する知識と経験

システム開発においては、ITに関する知識はもちろん、業務や業界に関する知識も重要な要素となります。

業務や業界に関しては、一般的に発注者側の方が詳しく知っています。開発会社側も、発注者側の持っている知識や経験をできるだけ吸収し、認識齟齬なく要件定義を進める必要があります。

実現可能なシステム設計

特に開発会社側では、要件定義を通してコスト的・技術的に実現可能なシステムとなるように調整しなければなりません。

通常、発注者側ではシステムにかけられる予算や期間は決まっているものです。あまりにも過大な要件や、技術的に実現できない要件については、適宜その理由を説明しつつ、コントロールする必要があります。

これには前述したコミュニケーション能力の他、発注者側のニーズをどのようにシステムで実現するか、変換するスキルが求められます。

要件定義を進める上でのポイントを解説

以下では、要件定義を進める上でのポイントをご紹介します。

RFPの作成

特に発注者側として重要となるのが、RFPを作成して開発内容を明確にしたうえで、開発会社を選定し、要件定義に着手するプロセスです。

RFPとはRequest for Proposalの略であり、日本語では提案依頼書となります。RFPは発注者側が作成し、開発会社に対して構築したいシステムの内容を伝え、開発内容の提案や費用の見積もりを依頼するものです。

システム開発を行う際には、開発会社を公平かつ適切に評価・選定するために、RFPを作成し、コンペティションを実施することをおすすめします。

RFPには前述した要求定義で整理した内容を記載します。RFPという形で明確に開発会社にシステムのイメージを伝えることで、要件定義へとスムーズに移行することができます。

※関連記事：【サンプル付】RFPとは？テンプレートと書き方ガイドで完全解説

適切なスコープ定義

よくあるのが、要件定義段階で壮大な絵を書いてしまい、実現のために多額のコストと期間がかかってしまうという失敗です。過大な要件を求めず、自社のビジネスにおいて重要であり優先度の高い要素を盛り込んでいくことを心がけます。

このためには、スコープ定義として今回のシステム開発で何を実現し、また何を実現しないかの仕分け作業が必要です。優先度が低い機能については、2次開発に回すなどの調整を行います。

なお、特に重要度の高い機能を先行して構築したい場合、PoC開発やMVP開発といったアプローチが有効です。

それぞれ、PoC開発はビジネスアイディアなどの仮説検証を行うことを目的とし、MVP開発はプロダクトが市場にフィットするかを確認することを目的とします。

PoC開発とMVP開発については以下の記事で解説しておりますので、ご興味のある方はぜひご覧ください。

※関連記事：MVP開発とは？アジャイル開発との違い、実施プロセスや注意点を解説
※関連記事：PoCとは。ビジネスにおけるPoC活用メリットや進め方を徹底解説

役割分担の明確化

要件定義を開発会社に丸投げしてしまうのは、非常に危険です。最終的に想定していたシステムが開発されず、プロジェクトが失敗する原因となります。

一方で、発注者側のみで要件定義を進めすぎるのも危険です。要件定義にはシステムに求める可用性や信頼性、セキュリティといった専門的なスキルが求められる要素も含まれます。

よって、発注者側、開発会社側の双方がうまく役割を分担し、それぞれのスキルや知識を合わせて進めていくことがポイントです。双方の役割分担については、要件定義のキックオフ時点で星取表を用いて明確化しておくことをおすすめします。

明確なドキュメントの作成

要件定義において作成する要件定義書は、システム開発におけるバイブルとして、以降の工程において参照され続けます。一般的に、システム開発においては後工程になればなるほど参加人数が増えていきます。

新たに参加した方が要件定義書を読んだときに、その内容が伝わらなければなりません。

要件定義書はできるだけ分かりやすく、第三者に伝わる内容にしなければなりません。

要件定義に成功した事例紹介

株式会社エクスメディオ | 医師向けコミュニティ「ヒポクラ 血液内科 Pro」のデザインリニューアル

AIを活用した医師同士のコミュニケーション・プラットフォームを運営する株式会社エクスメディオ様では「ヒポクラ 血液内科 Pro」として血液内科領域の医師専用の会員制コミュニティサービスを提供されています。当社では、同サービスの利用ユーザーの増加を目的としたデザインのリニューアルを支援させていただきました。

本プロジェクトでは、アクティブユーザーを増やすべく、医師が気軽に質問・回答でき、かつそれを習慣化してもらうことを重視した改善を実施。ユーザーへのインタビューを通して要件を整理し、仕様書として整理しました。

ユーザーである医師の心理的安全性が高まり、結果としてリニューアル前より気軽な内容の投稿が増え、質問の回答も増加させることができました。

※事例ページ：株式会社エクスメディオ | 医師向けコミュニティ「ヒポクラ 血液内科 Pro」のデザインリニューアル

株式会社トムス・エンタテインメント | アニメーションの制作管理システム「ProGrace」の開発

当社では、アニメーション制作を営む株式会社トムス・エンタテインメント様が主に社内で活用するアニメーションの制作管理システム「ProGrace」の新規開発を担当いたしました。

開発にあたっては、実際にシステムを利用する制作進行担当の方にデモやレビュー、ミーティングに参加していただき、現場目線の意見を取り入れた要件の整理を行いました。整理にあたってはワイヤーフレームなども活用し、システムの開発につなげていきました。

※事例ページ：株式会社トムス・エンタテインメント | アニメーションの制作管理システム「ProGrace」の開発

帝人株式会社 / 在宅医療支援機構株式会社 | 訪問看護専門総合転職支援サービス「NsPace Career」の開発

在宅医療が重要視される社会環境も踏まえ、帝人株式会社様および在宅医療支援機構株式会社様では、訪問看護を専門とする看護師向け総合転職支援サービス「NsPace Career」を提供しています。

本プロジェクトにおいて、当社はUXデザインや機能実装、運用保守まで包括的な支援を実施しました。

要件の整理にあたっては、実際に看護師へヒアリングを実施し、必要な機能を検討いたしました。また、デザイナーとエンジニアによる「ペアデザイン」により、デザイン作成段階でエンジニアによる社内レビューを行い、技術的に実現性の高いデザインカンプを作成する取り組みも実施しました。

※事例ページ：帝人株式会社 / 在宅医療支援機構株式会社 | 訪問看護専門総合転職支援サービス「NsPace Career」の開発

まとめ

今回は、要件定義の重要性や進め方など、要件定義に関して詳しく解説しました。ご紹介した通り、特に新規事業開発において要件定義は非常に重要となります。

また、要件定義を進める上では、ITのみならず、UI/UXデザインのスキルも持った開発会社の選定もポイントです。

当社、スパイスファクトリーは、システム開発に精通した多数の人材を抱え、プロジェクトマネージャーやエンジニア、デザイナーなどオールインワンで皆様のシステム開発をサポートします。要件定義工程から開発、リリース後の運用まで対応が可能です。

新規事業開発やシステム開発をご検討されている方は、ぜひお声がけください。

RFP（提案依頼書）は、システム開発や導入において発注したい企業が、ベンダーに依頼内容や要件を提示する資料です。

しかし、どのようにRFPを作ればよいか分からず悩んでいる方も多いのではないでしょうか。

本記事では、RFPの概要やRFPを作成すべき理由に加え、RFP作成時の重要ポイントと押さえるべき項目について徹底解説していきます。

まず、RFPの要点を1枚にまとめると次のとおりです。

項目	RFP（提案依頼書）の要点
正式名称	Request for Proposal（提案依頼書）
目的	各社共通の条件で提案書・見積を取得し、自社に最適な委託先を選定する
作成者	発注側の企業（システムを開発・導入したい側）
提出先	提案を依頼したい開発会社・ベンダー（3〜5社程度が目安）
盛り込む項目	プロジェクト概要・対象範囲・予算・スケジュール・要件・納品物など15項目（本記事で解説）
似た文書との違い	RFI（情報提供依頼書）は提案依頼前の情報収集、RFQ（見積依頼書）は仕様確定後の見積依頼

また、初めてRFPを作成する担当者の方向けに、本記事で紹介する15項目を網羅したRFP（提案依頼書）のテンプレートを無料でご用意しています。ぜひ、作成時にご活用ください。

RFPテンプレート（無料）をダウンロード

システム開発に必須なRFP（提案依頼書）とは？

RFP（提案依頼書）とは？

RFP（Request for Proposal：提案依頼書）とは、発注側が開発会社に対して提案して欲しいことをまとめた文書のことです。

RFPという形で要望や依頼事項を整理して記載することで、各社共通の条件で提案書と見積を取得できます。これにより、提案内容の比較検討もしやすくなります。

RFP（提案依頼書）の目的

RFPは、自社の要件にあった提案を受けることを目的としています。前述のとおり、RFPとは提案してほしいことをまとめた文書です。

提案に必要な情報をあらかじめ提出しておくことで、自社で欲している内容で提案してもらえることができ、その提案内容を基に候補先の評価や比較がしやすくなります。

一方で、RFPを作成しないと提案依頼先により提案範囲や見積条件がバラバラとなります。これでは、各社を平等に比較することは難しいです。

さらに、こちらの依頼内容が正確に伝わらず納品物が想定外のものとなってしまうリスクや、要望が伝えきれず漏れてしまうといった問題も生じます。

このような事態を防ぎ、最適な委託先を選定してプロジェクトを成功させるためにも、RFPが必要となります。

RFI（情報提供依頼書）との違い

RFI（情報提供依頼書）は、しばしばRFPと混同されることがありますが、両者は異なるものです。

RFPとの違いは、目的や利用されるフェーズが異なる点にあります。

RFIは、日本語では情報提供依頼書と呼ばれています。

提案を依頼する前の段階で候補先に問い合わせをする際に、システム開発の目的や要求事項を説明したうえで、対応可否や各社の技術力などに関する情報を提供してもらうための文書です。

RFIの目的は、RFIによって収集する会社の情報を基に、コンペに呼ぶ会社を選定することとなります。

また、似た文書としてRFQ（Request for Quotation：見積依頼書）もあります。RFQは仕様が確定している前提で、その仕様に基づく価格の見積を依頼する文書です。3つの文書の違いを整理すると次のようになります。

文書	日本語名	目的	利用されるフェーズ
RFI	情報提供依頼書	候補会社の情報を集め、コンペに呼ぶ会社を絞り込む	提案依頼の前（情報収集）
RFP	提案依頼書	要件に合った提案と見積を取得し、委託先を選定する	委託先の選定
RFQ	見積依頼書	確定した仕様に基づく価格見積を取得する	仕様の確定後

RFPやRFIが使用される大きな流れについては、以下のブログ記事で詳しく説明しています。
関連記事：【テンプレ付】失敗しないホームページ制作会社の選び方 比較ポイントと流れを徹底解説（新しいタブで開きます）

要件定義書との違い

要件定義書とRFP（提案依頼書）の違いは、文書の作成者と利用されるフェーズが異なる点にあります。

要件定義書は、発注側ではなく開発側となるパートナーや開発会社が作成します。

この文書は、成果物に関して、現状の課題やプロジェクトの目的、要件、詳細な条件、対応内容などを文書化したもので、開発側が発注側とプロジェクトについての理解を合わせることを目的としています。

発注側の要望を正しく理解し、要件を文書に落とし込むことは、発注側の要望を開発側社内で認識を併せることができるほか、発注側と開発側の認識の齟齬や曖昧さをなくすことにつながります。

また、要件定義書の制作は、開発側が独自の視点で進行してしまい結果的に発注側の要望を適切に反映できていない、といった事態を回避することができます。

要件定義書より前段階でRFPのやり取りが行われることで、パートナーや開発会社はRFPを参考に要件定義書を制作できるため、意思疎通がスムーズとなりスピーディな進行を実現できます。

RFPを作成するメリット

システム開発を委託する場合、RFPを作成することには多くのメリットがあります。

RFPの作成やRFPによる委託先の選定には手間もかかりますが、これらのメリットを踏まえるとRFPの作成はできる限り行うべきだといえるでしょう。

以下では、RFP作成にどのようなメリットがあるのか、詳しくご紹介します。

要件の明確化による認識齟齬の防止

システム開発において最も重要なことの一つは、発注側と開発側の間で「何を作るのか」についての認識を一致させることです。

RFPを作成することで、システムの目的や要件を明文化し、両者の認識の食い違いを未然に防ぐことができます。

口頭でのやり取りだけでは、必要な情報が正確に伝わらないリスクがあります。RFPによって要件を文書化することで、必要な情報をもれなく開発会社に伝えることができます。

システム開発においては「言った・言わない」といった水掛け論が起きることもあります。RFP作成はこのようなトラブルの防止にも効果的です。

最適な開発会社の選定

同じRFPを複数の開発会社に提示することで、各社の提案を同一条件下で比較できます。これにより、公平に開発会社を選定することができるようになります。

RFPにて共通の評価基準を設定することで、提案の評価プロセスが透明化され、客観的な選定が可能になる点もメリットです。

開発会社の選定において感情や人間関係に左右されない合理的な決定を下しやすくなり、開発会社の決定における社内の合意を形成しやすくなります。

よくあるのが、社内のパワーバランスや、いわゆる「声が大きい人」により委託先が決定されてしまうケースです。このような委託先の決定では、必ずしも最適な委託先を選ぶことはできません。

RFPにより基準を明確にすることで、このような偏った判断による委託先の選定を防ぐこともできます。

相見積によるコスト最適化

RFPにより同じ条件で複数の開発会社に見積を取ることで、コストの最適化が期待できます。複数の提案内容を見比べることで、妥当なコスト感を判断しやすくなります。

また、システム開発において問題となるのは、過剰な見積だけではありません。過小な見積もリスクとなる可能性があります。「期待していた機能が実装されなかった」「品質が悪いシステムができあがった」という事態にもなりかねません。

あまりにも低額の見積があった場合は、注意すべきです。

RFPにより相見積もりを取得することで、過剰でも過小でもない、適切なコスト水準を把握しやすくなります。

妥当なプロジェクト計画の作成

RFPでは、プロジェクトのスケジュールや予算・人員といったリソースなども定義します。

これらの情報を開発会社へとインプットすることで、開発会社は現実的な開発計画を立てることができます。

また、自社の想定スケジュールやリソース確保状況が適切かどうかを確認する機会にもなります。

システム開発のプロフェッショナルである開発会社からのフィードバックを通じて、必要に応じてスケジュール・リソースを見直し、妥当なプロジェクト計画へと見直すことができます。

さらに、RFPにて予算を提示することで、プロジェクトのコストが過大となることも防げます。

開発会社は提示された予算内で最大限の提案を行いますが、もし予算とシステム化のスコープがアンマッチであれば、RFPを通して現実的なスコープに調整することができます。

組織内の合意形成

RFPの作成は、合意形成のためのプロセスとしても機能します。

RFPを作成するためには、「どのような目的で」「どのような機能を持ったシステムを」「どのような予算・スケジュールで」開発するかを決めていく必要があります。

これらを関連する組織内の様々な部門や利害関係者と共に整理していくことで、システム開発に対する共通理解を形成できます。

システム開発プロジェクトの開始前に共通理解を形成することで、プロジェクトの立ち上げも円滑に進みます。

ナレッジの蓄積

作成したRFPは、組織内にナレッジとして蓄積されます。RFPに基づき実施したプロジェクト結果と併せて情報を蓄積することで、次回以降のプロジェクトにおいて活用できます。

たとえば、RFP段階で設定していた基準により開発会社を選定したものの、実際のプロジェクトがうまくいかなかった場合は、RFPにおける選定基準を改善すべきだといえます。

次回以降のシステム開発プロジェクトにおいては、より適切な基準を設定したうえで、開発会社を選定できるでしょう。

このように、RFPの作成からプロジェクトの終結までをナレッジ化することで、自社のシステム開発プロジェクトをより高い水準のものとできます。

RFP作成前に押さえるべき5つのポイント

RFP作成には事前の準備が肝要です。以下では、RFP作成に入る前に確認すべき5つのポイントを紹介します。

①目的の明確化

RFPを作成するためには、ビジネス要件を明確にする必要があります。

ビジネス要件とは、プロジェクト実施の目的や背景、予算やスケジュール等のことを指します。

この中でも、目的を明確にすることは最も重要です。よくあるシステム開発の目的としては、「業務効率化」「新事業参入」「リスク削減」などが挙げられます。

目的の分類	目的の具体例
業務効率化	これまで人手で実施していた作業を削減するため、システムを導入したい
新事業参入	新規事業を開始するにあたり、必要となるシステムを構築したい
リスク削減	内部不正のリスクを下げるため、システムにより、内部統制を強化したい

目的を明確化することは、プロジェクト進行中に起こりがちな「手段の目的化」を防ぐことにもつながります。

よくあるのが、プロジェクトが進行するにつれてシステムの導入自体が目的にすり替わってしまうケースです。あくまでもシステムは手段にすぎません。

システム導入によって何を実現したいのか、目的を明確化したうえでプロジェクト中に方向性をブレさせないことが重要です。

②システムの提供価値の定義

システムを構築する上では、ユーザーに対してどのような価値を提供する成果物なのか定義するべきです。

上述で記載した「目的」を実現するためには、システムで具体的にどのような価値を提供しなければならないのかを整理しましょう。

その際、ビジネスの全体像においてシステムがどのような役割を果たし、何に貢献するものなのかという観点が重要です。具体的な例としては以下の通りです。

＜提供価値の具体例＞

• ユーザーが欲している情報に素早くたどり着ける
• ユーザーが欲しい製品をわかりやすいUIによって直感的に探せる
• 100件の大量作業をすぐに完了できる

提供価値は必ずしも一つに限定する必要はありません。
ここで定めた提供価値が具体的な要件を洗い出す際の指針となるため、RFP作成においては重要なポイントといえます。

③制約条件の確認

ビジネス要件を整理する上では、事前にプロジェクトの制約事項を確認しておかなければなりません。

どのようなプロジェクトでも確実に抑えておくべき制約条件は「予算」「スケジュール」の2つです。予算とスケジュールによって、実施できるプロジェクト規模が決まります。

スケジュールの設定においては、システム開発後に必要となる作業期間も考慮しましょう。

社内での受入テストや運用体制の構築、社外向けシステムであればプレスリリースの準備など、様々なタスクが発生します。

これらのタスクに必要な期間も考慮して、最終的な期限に間に合うようにシステムの完成期限を設定します。
スケジュール期限は各社が依頼を受けられるかどうかを判断する重要な情報となりますので、プロジェクトの途中で変更することがないように注意深く設定しなければなりません。

④構築後の運用設計

上述したとおり、プロジェクトにおける「手段の目的化」は陥りやすいリスクとなっています。

たとえば、システムの開発が進むにつれて、単純な見た目など目的を達成するために無関係な要素へのこだわりが強くなり 、運用に影響するというような事態も起きがちです。

そうならないためにも、制作後どのように運用していくのかをRFP作成前に明確化します。
もし明確化が難しい場合、開発会社に必要な運用体制についても提案してもらうことも有効です。

⑤選定基準のすり合わせ

最後に、委託先の選定基準について社内で認識合わせをしておきましょう。選定基準を明確化しておくことで、選定時に論点が分散することを避けられます。

選定基準は会社事情やプロジェクトの目的から掘り下げて決定することが一般的です。
たとえば、以下のような観点のうちどれを重要視するかを検討します。

＜評価項目の例＞

• ビジネス理解
• 提案力
• 機能要件の充足度合い
• エンジニアリング力
• デザイン力
• 実績（自社と同規模または大手企業の実績、同業種の実績 ）
• コミュニケーション体制
• 価格

委託先の決定方法は様々ですが、観点ごとに採点形式で決める方法もあります。

その場合、重要視する観点を高めに配点し、そうではない要素を低めに設定する方法も一案です。

自社にあった選定基準を設定し、定量的に判断できる準備を整えましょう。

RFPで絶対におさえるべき項目15選。テンプレートでサンプル例を参照しながら確認しよう

ここでは、実際にRFPを制作するにあたり絶対に押さえるべき15の項目をご紹介します。
ぜひ以下から RFP のテンプレートをダウンロードし、サンプル例を参照しながらポイントを確認してみてください。

RFPテンプレート（無料）をダウンロード

プロジェクト概要

RFPにまず必要なのが、プロジェクトの概要です。システム開発の目的をより深く理解してもらうためには、プロジェクトの背景や目的について提案依頼先に理解してもらうことが大切です。

１．表紙・表題

最初に目にする表紙・冒頭には、RFPの件名が分かるように「〇〇プロジェクト提案依頼書」といった表題を付けましょう。加えて会社名及び担当者名も記載し、連絡先も明確にします。

以降は、簡単な概要説明を兼ねたあいさつ文を記載します。詳細については後ほど伝えるため、冒頭では今回の依頼の全体像を簡潔にまとめましょう。

２．背景・目的・課題・ゴール

今回の依頼に至る背景や自社が抱えている課題について記載します。

プロジェクトを実施する理由となるのが背景であり、プロジェクトの目的を達成するために解決が必要となるのが課題です。

これらを提案依頼先に理解してもらうことで、より自社にニーズに沿った提案となることが期待できます。

事業・組織の問題意識や環境の変化に伴う改善ニーズなど、認識している課題についてはできるだけ幅広く言及しましょう。課題が複数ある場合、省略する必要はありません。

複数の課題は箇条書きや表などを利用することで伝わりやすくなります。背景や課題で提示した内容を、プロジェクトでどう解決に導きたいのかを明記しましょう。

プロジェクト対象範囲

RFPでは、プロジェクトの対象範囲を明確にすることも必要です。対象範囲が明確でないと、各社の提案を同じ基準で比較できません。

対象範囲を明確化するためには、同時に対象範囲外となる部分も明確にする必要があります。
さらに、必須ではないものの追加で提案してもらいたい要件がある場合は、オプション提案としてまとめます。

３．現行システム・新システムの範囲

まず、今回の提案依頼の対象範囲を具体的に明示します。
現行システムがある場合は、現行システムの概要をAs-Isとして、また新システムの範囲についてTo-Beとして記載します。

これらは図として示すとわかりやすいでしょう。赤枠などでシステムの対象範囲を明確化することで、誰が読んでも対象範囲が分かりやすくなります。

４．利用ユーザー

システムの利用者について記載します。各利用者がどのようなユースケースでシステムを利用するか、また各利用者の人数はどの程度であるかを記載することで、利用者ごとのシステムの使い方と利用規模が明確になります。

ロール	ユースケース	人数（想定）
予算管理担当者	・予算編成登録 ・予算編成承認依頼 ・予算消化状況のモニタリング ・各マスタの管理	5名程度
各部担当者	・予算申請 ・予算承認可否の確認 ・予算進捗管理	190名程度
予算管理責任者	・予算承認	2名程度

５．委託範囲

具体的に開発会社に委託を行いたい作業について記載します。

通常であれば、以下のとおり要件定義～リリースまでの一連の作業を委託することとなりますが、例えば「ユーザー教育も行ってほしい」「運用設計もサポートしてほしい」などの要望があれば追記します。

＜記載項目の例＞

• 要件定義
• 設計・開発
• テスト
• データ移行
• リリース
• セキュリティ対策
• 運用保守・アフターサポート
• 必要に応じた改善施策の提案・実施
• プロジェクトスケジュールの作成と管理
• プロジェクト体制の提案と構築

６．対象外範囲・特記事項

提案において対象外となる範囲も明確にしておきましょう。

自社で開発を担当したい部分がある場合や、既存システムからのデータ抽出など現行の開発会社などに委託する必要がある範囲などは、事前に対象外であることを記載します。

また、サーバーOSやミドルウェア、OSのバージョンなど、自社のインフラ環境に指定がある場合には特記事項として記載します。

今回の提案対象範囲外のシステムなどと連携する必要がある場合は、必要性を記載したうえで連携方法や条件などを提案に含めてもらうようにします。

７．オプション提案範囲

必須で対象範囲とはしないものの、追加で提案してほしい要素についてはオプション提案範囲としてまとめます。

たとえば、業務に必須ではないもののあると便利な機能については、コスト見合いで開発するか検討することもできますので、いったん提案を頂くことも検討できるでしょう。

オプション提案は各社により差が付きやすい要素といえます。各社の力量や考え方が見える部分ですので、委託先を選定する際の一つのポイントとなるでしょう。

予算・スケジュール

提案にあたって重要なのが、予算とスケジュールです。各社は予算とスケジュールを前提に提案可否や提案内容を検討しますので、できるだけ詳細に記載しましょう。

８．プロジェクト予算

想定予算を明記せず提案に任せるのも一案ですが、開発会社によって金額がバラバラだと同条件での比較が難しくなります。

予算の上限を設定し、各提案の条件を同じにしましょう。その際、金額だけではなく項目も明確にしておくべきです。

以下のようにイニシャルコストとランニングコストを明記してもらうことで、システムのライフサイクルコストでの評価が可能となります。

■イニシャルコスト

• アプリ開発費用
• 基盤構築費用
• ライセンス費用
• インフラ費用（ハードウェア・ソフトウェアなど）
• その他

■ランニングコスト

• 運用保守作業費用
• SaaS利用料・ライセンス保守費用
• インフラ保守費用

その一方で、予算を絶対条件にすると最小限の提案となりやすいという側面もあります。

質の良い提案を集めるためには、理由の明記を条件としたうえで、予算を超過した提案を認めることも検討しましょう。

９．プロジェクトスケジュール

プロジェクトの想定スケジュールを記載します。いつ頃のリリースを見込んでいるのか、どのようなマイルストーンを想定しているのか、できるだけ詳しく記載しましょう。

作業項目やマイルストーンが多い場合は、横軸に時間軸、縦軸に作業項目を記載した表と矢羽根を用いてまとめると視覚的に分かりやすいでしょう。

10．選定スケジュール

提案依頼から委託先選定までのスケジュールも記載します。提案の締め切り日だけでなく、選考日やプレゼンの日程、結果通知の日程も記載しましょう。

また、スムーズに進めるために質問受付期間や回答日を明記することをおすすめします。これにより、提案依頼先もスケジュールを立てやすくなります。

要件

ここでは、システムを開発するにあたっての要件を提示します。

発注側が要件を明確に提示しなければ、完成形が全く希望に合っていないという事態にもなりえます。
要件は可能な限り詳細に提示することで双方のズレを防ぐことができます。

11．機能要件

まず、機能要件としてシステムに必要な機能を定義しましょう。

たとえば予算管理システムであれば、予算編成機能やモニタリング機能、マスタ管理機能などが必要です。

各社は記載内容に応じて提案を行うため、複数人で洗い出しを行うなど要件に漏れがないように気をつけてください。

もちろん、機能の詳細は委託先決定後にすり合わせが必要ですが、RFPの段階で可能な限り機能を盛り込むようにしましょう。

RFPに記載されていない機能を後から追加すると、場合によっては発注金額の増加やスケジュールの変更といった事態にもなります。

抽象的でも構わないので、まずは希望を記載することが重要です。

12．非機能要件

機能要件と同様に非機能要件も明記しましょう。

非機能要件とは機能以外のすべての要件のことであり、具体的には求めるレスポンス速度やOS・ブラウザ等の動作環境、バージョンアップ・バックアップの必要性などが挙げられます。

非機能要件は、機能要件よりも記載項目が多くなります。提案依頼先に伝わりやすくなるように、IPA（独立行政法人情報処理推進機構）が定義する「非機能要求グレード※」に基づき、以下の項目に分けて記載することをおすすめします。

• 可用性
• 性能・拡張性
• 運用・保守性
• 移行性
• セキュリティ
• システム環境・エコロジー

※参考：独立行政法人情報処理推進機構「システム構築の上流工程強化（非機能要求グレード）（新しいタブで開きます）

非機能要件を記載するためには専門的な知識が必要であるため、知識のあるメンバーや提案依頼先などに聞いてみるとよいでしょう。

納品物

ここでは、最終的な成果物となる納品物を提示します。

13．納品物

RFPには、成果物として納品してほしいものについても記載します。システムのプログラム一式はもちろんですが、要件定義書や設計書、各種テスト結果なども納品物として指定しておくことをおすすめします。

これらの納品物を受領しておくと、将来的にシステムのリニューアルを実施する際に役に立ちます。

提案依頼内容

RFPの最後には、提案に関する必要な情報をまとめて記載します。提出物や提出期限などもここで改めて定義します。

14．提出日・提案物

下表の通り提案の提出に関する情報をまとめます。

特に、提案書のデータ形式やフォーマットを指定しておくと、選定時に比較しやすくなります。

また、提案書の内容に関しては、具体的な制作案だけでなくプロジェクトのチーム体制やスケジュールなども記載してもらいます。

その他、比較検討に必要だと思うことを盛り込みましょう。たとえば提案書のフォーマット（章立て）を決めてしまうのもひとつの方法です。

項目	記載例
提出期限	202X年XX月XX日（水）17:00まで
提出フォーマット	PPT形式とする
提出先	XXXXX株式会社○○部△△チーム 田中 xxxxxxxxxxx@xxxx.xx.xx 佐藤 xxxxxxxxxxx@xxxx.xx.xx
提出物	提案書：章ごとの提案概要、提案詳細、体制図、スケジュールを記載すること 見積書：フォーマットに沿って内訳に記載すること

15．契約条件・対応窓口

システム開発を行うためには、委託先に自社の機密情報を開示する必要があります。

また、著作権の取り決めなども重要な観点です。これらの契約条件についてもRFPに記載します。

加えて、質問の受付先など窓口を決めたうえで、記載します。提案書と見積書の提出先を変えたいケースでは担当窓口が複数に分かれます。

それぞれの担当窓口と対応範囲を明確にしておきましょう。電話やメールといった連絡手段もあわせて記載します。

開発会社の視点：提案の質が上がるRFPの特徴

スパイスファクトリーは、受託開発会社としてRFPを「受け取る側」でもあります。数多くの提案依頼に応えてきた経験から、各社から質の高い提案を引き出せるRFPには共通する特徴があると感じています。

• 背景と課題が率直に書かれている — 現行システムへの不満や過去にうまくいかなかった経緯まで書かれていると、提案は「機能の羅列」ではなく課題解決の筋道になります
• 予算レンジと優先順位が示されている — 予算内で最大の価値を出すスコープ設計を、各社が本気で検討できるようになります
• 選定基準と配点が公開されている — 提案側は評価観点に沿って情報を出せるため、発注側にとっても比較・評価が格段にしやすくなります

逆に、機能一覧だけが並んだRFPでは各社の提案が同質化しやすく、価格以外の比較が難しくなります。本記事の15項目とテンプレートは、この「提案の質が上がるRFP」を最短で用意するための構成になっています。

RFPに関するよくある質問（FAQ）

RFPは何ページくらいの分量が適切ですか？

中小規模のシステム開発では10〜20ページ程度が一般的な目安です。ただし分量そのものより、本記事の15項目が漏れなく書かれていることが重要です。まずは1〜2ページの骨子を作り、社内の合意を取りながら肉付けしていく進め方をおすすめします。

RFPとRFQの違いは何ですか？

RFQ（見積依頼書）は、仕様が確定している前提で価格の見積を依頼する文書です。RFPは仕様を確定させる前に、要件に対する提案そのものを依頼します。詳しくは本記事のRFI・RFP・RFQ比較表をご覧ください。

予算は正直に書くべきですか？

上限または想定レンジの提示をおすすめします。予算が示されていると、各社は現実的なスコープで提案でき、同条件での比較がしやすくなります。最小限の提案に偏ることが心配な場合は、「理由を明記すれば予算超過の提案も可」とする方法が有効です。

何社くらいに提案を依頼するのがよいですか？

3〜5社程度が目安です。多すぎると評価の負荷が高くなるうえ、競争率の低下を見込んだ各社の提案の質もかえって下がりやすくなります。候補が多い場合は、RFI（情報提供依頼書）で先に絞り込みましょう。

RFPの作成にはどのくらい時間がかかりますか？

社内の合意形成を含めると2週間〜1カ月程度を見込むのが現実的です。テンプレートを使って項目を埋める形で進めると、ゼロから書き起こすよりも大幅に短縮できます。

RFPの無料テンプレートをDLして、実際に制作してみよう

本記事では、システム開発のRFPとは何か、その作成目的や作成方法についてお伝えしました。

RFPを明確に作成すれば、各社からの提案はより優れたものになります。
理想のシステム開発を可能とする会社を見つけるためにも、RFPを作りこむことが重要です。

当社では、システムを開発したいと考えている方に向けて、本記事で紹介した15の観点を網羅したRFPのテンプレート（サンプル例）をご用意しています。テンプレートは以下からダウンロードできますので、お困りの際はご利用ください。

RFPテンプレート（無料）をダウンロード

スパイスファクトリーではユーザー起点のシステム開発やサイト制作に尽力しています。
システムを新しく構築したいけれど、どこに頼めばいいかわからないというようなお悩みがある方は、お気軽にお問い合わせください。

また、スパイスファクトリーではRFPの作成段階からのご相談も承っています。

RFPの作成に悩まれている方も、ぜひお問い合わせからお気軽にご相談ください。

PoC・プロトタイピング開発サービスを見る

PoC・プロトタイピング開発サービスを見る
PoC（Proof of Concept：概念実証）としてアイデアを検証する取り組みは、多くの企業において定着化しつつあるのではないでしょうか。一方で、PoC をともに実施する会社をどのように選ぶべきか、悩まれている方もいらっしゃると思います。
そこでこの記事では、PoC の依頼先を検討されている方に向けて、会社選びのポイントや事前にやるべきことについてご紹介します。

当社では、経験豊富なエンジニアとデザイナーがワンチームとなってサービス企画のアイデア出しからプロトタイプ開発、検証後の本開発までを一気通貫でご支援しております。
詳しいサービスについてはPoC・プロトタイピング開発サービスからご確認ください。

PoCの概要

まず、PoC とは具体的にどのようなものなのか、改めて整理します。

PoCとは

PoC とはビジネスアイデアなどの実証を目的とした、試作開発や検証のことを指します。アイデアを具体化するためには一定の投資が必要となるため、できる限り失敗は避けなければなりません。そこで、PoC により想定している仮説の正しさや、技術的な実現可否を検証します。これにより、アイデアの妥当性を低リスク・低コストで確認できます。
PoC の詳細については、こちらの記事（新しいタブで開きます）もご覧ください。

https://spice-factory.co.jp/design/what_is_poc/

PoCの種類

PoCには大きく分けて2つの種類が存在します。

①既存のサービスの課題を改善するためのPoC

ひとつは、既存サービスの課題を改善するための PoC です。たとえば「ユーザビリティを向上させる」ことを目的として PoC を実施するようなケースがこれに該当します。
この場合、まずヒアリングなどにより現状のサービス課題を分析し、その結果に基づき本番に近い形でプロトタイプ（新しいタブで開きます）を構築します。プロトタイプを評価することで、想定している方針で課題の改善ができるかを検証できます。

②0→1でサービスを開発するにあたり、アイデアを検証するためのPoC

もうひとつは、新サービスの開発を行うケースです。PoC により正式な事業化判断の前に市場ニーズや技術的な実現性を測ることで、事前にサービスの成否やリスクを予測できます。
このケースでは、事業化の成否やリスク測定がPoCの目的となります。よって、具体的な機能要件まで踏み込まない形でプロトタイプを構築することも多いです。

PoCの費用

サービス内容や開発期間にもよりますが、一般的にPoCの予算相場は数百万円程度となります。すでに構築しているものをカスタマイズして開発する場合は、費用が安くなる場合もありますし、0から開発を行う場合は、これより高くなる場合もあります。
一般的なPoC費用についてはこちらの記事（新しいタブで開きます）もご覧ください。

https://spice-factory.co.jp/design/poc_planning/

PoC費用の変動要素となるポイントは以下の2つです。

成果物の種類

ひとつは成果物の種類です。ペーパーレベルで成果物を作る方法、デザインツールを利用して動作するプロトタイプを作る方法、システムとしてプロトタイプを実装する方法など、プロトタイプにはいくつかの種類があります。
PoC の目的によってどのレベルまでの成果物を作るべきかは異なります。たとえば、手戻りを避けるためにもアイデアの初期検証段階ではペーパープロトタイプを、アイデアが固まってきたらサービスの機能やニーズの検証としてデザインツールを用いてプロトタイプを制作。リアルな挙動や動作により実現可能性を図る必要性がある場合はシステムで実装するプロトタイプを選択するなど、目的から落とし込んで適切な成果物を決定していきます。

成果物のスコープ

もうひとつは成果物のスコープです。当然ながら、多くの機能を対象とした PoC を行う場合は費用が上がります。
また、検証規模も費用の変動要素です。インタビューの対象者を増やして多くの情報を収集したり、検証回数を増やしたりすると、その分費用がかかります。

PoC実施を外部に依頼すべきケースとは

PoC の実施に当たり、外部リソースを活用するか社内で対応すべきか悩まれる方は多いのではないでしょうか。ここでは、外部リソースへの依頼可否を判断する観点をご紹介します。

本当にPoCを外部に依頼すべき？

PoC は自社で行うことも可能です。たとえば、業務フローを再検討したうえで、実際に業務に適用してみて検証を行うような PoC であれば、自社のみで十分実施できます。
このように、自社リソースだけで PoC のサイクルを回せる場合は、必ずしも他社リソースを利用する必要はありません。

外部に依頼すべきケース

一方で、PoC の対象がシステムやアプリである場合は、外部リソースの活用も検討すべきです。特に、自社にエンジニアやデザイナーがいない場合は、プロトタイプ制作フェーズでは専門知識のあるプロに作ってもらった方がベターです。
また、第三者視点で課題の発見をしたい場合、外部の視点を入れるという選択肢もあります。新規サービス開発など、0→1 で検証する際などは、多様な視点を取り入れることが重要です。
その他、以下のようなケースに当てはまる場合は、社外への依頼を検討すべきといえるでしょう。

• アイデアはあるがシステム実装も含めて詳細化の方法が整理できていない
• 投資判断がつきにくく、外部の意見を入れたい
• システムの機能追加が適切か分からない
• 機能を追加した際にうまくユーザーが利用できるか不安がある

PoC・プロトタイピング開発サービスを見る

会社選びの前に整理すべきポイント

PoC の成否は会社選びの時点でほぼ決まるといっても過言ではありません。「とりあえず会社を選ぶ」というスタンスは非常に危険です。
まずは、自社でプロジェクトに関する理解度を上げ、会社に求める要件を洗い出すべきです。具体的には以下を整理します。

課題の整理

課題の整理は最初に着手すべきポイントです。通常、PoCの目的や目標は課題から導かれます。担当者の意見はもちろん、なるべく多くのステークホルダーにヒアリングすることで多角的に情報を集めることができます。
洗い出した課題から、重要度・緊急度などの観点で優先度を定め、どの課題が最も解決すべきものかを整理します。

目的・目標の決定

課題を踏まえ、PoC の目的や目標を定義します。たとえば、PoCの目的がビジネスコンセプトの定義か、実装を通したサービスのニーズ検証なのかで PoC の方向性は大きく異なります。目的や目標はプロジェクトの大方針となるので、社内で十分に議論したうえで決定すべきポイントです。

期限・予算の整理

これらの目標を達成するため、いつまでにどれくらいのコストをかけられるか、期限や予算を決定します。これらは会社の選定にあたって候補先の各社から必ず聞かれるポイントです。また、期限・予算により検証できる範囲も変わります。

本番開発を見通した会社選定

PoC に成功した場合、PoC を実施した会社にそのまま本番開発も依頼することで、コスト削減やスピード感を持った対応ができます。よって、PoC の依頼を行う際には本番開発の可否まで見通したうえで依頼すべきです。本番開発を実施するためには、十分なエンジニアが在籍していることや開発経験の豊富さなどが選定条件となります。
加えて、PoCフェーズからエンジニアが参加することで、実現可能性を考慮したプロトタイプの制作や検証が可能です。これにより、その後の円滑な開発につなげやすくなります。

役割分担の明確化

役割分担の整理は、PoC に限らず外部リソースを利用する際の必須事項です。役割分担により、PoC 実施にかかる費用や体制が変わってきます。
たとえば、自社にエンジニアが在籍しているものの、デザイナーはいない場合、デザイナーリソースのみ外部に委託することも検討できます。この場合、エンジニアリソース分の外部委託費用が削減できますが、社内でアサインすべきメンバー調整など体制の構築も必要です。

PoC実施を依頼する会社を選ぶポイント

次に、自社にマッチしたパートナー企業の選定に必要なポイントを紹介します。

料金・期間

想定する予算内に収まるかは選定の大きな軸となります。委託先候補に対する最初のヒアリングで予算感を相談してみることをおすすめします。
また、事前に想定していた実施期間についても、現実的なものであるか委託先候補に確認してみるとよいでしょう。特に、システムの実装には想定していたよりも長い期間が必要となるケースもあります。

実績と業界・業務知識

実績は各社の力量を測る大きなポイントとなります。特に、自社と同じ業界や類似するサービスに関する実績の有無が重要です。委託先に事業やサービスへの理解があれば、プロジェクトはスムーズに進みやすくなります。
PoC は単にモノづくりを行うのではなく、ビジネスの成長や成功を目的として行われるものです。ビジネスに資するPoCを実現するためには、業界やサービス、ターゲットなどの理解度が重要となるでしょう。

対応可能範囲

各社がどこまでの作業範囲に対応できるかも確認すべきポイントです。たとえば、デザイナーは一般的にデザインツールを用いて動作するプロトタイプの作成は可能ですが、実際にシステムとして動作する実装済みのプロトタイプの制作は難しくなります。実際の動きをプロトタイプで検証したい場合や、その後の実装までサポートしてほしい場合には、エンジニアリング力を持った会社を選ぶべきでしょう。
弊社では、PoC の目的に応じてデザイナー・エンジニア・マーケターなどからチームを構成します。これにより、たとえば figma などのデザインツールベースでプロトタイプを作成しつつ、動作を確認したい箇所については一部 html や CSS を使用して実装するような対応も可能です。
また、各社のスキルがプロジェクト目的に合っているかも確認します。たとえばユーザーニーズの把握が重要となるプロジェクトの場合、UX知見を活かしたユーザーインタビュー、ユーザビリティテストなどの経験がある会社を選定します。

弊社の実績

以下では、PoCプロジェクトのイメージをお伝えするために、弊社の事例を2つご紹介します。

本田技研工業株式会社様の事例

まず紹介するのは、本田技研工業株式会社様の事例です。当社では、同社の新規事業の構想段階における市場ニーズの把握を目的とした PoCプロジェクトを支援しました。本事例では、プロトタイプ開発とリサーチまでトータル2ヵ月で進行。ユーザーの導線まで作りこんだプロトタイプにより、想定ターゲットから具体的なフィードバックを収集するなど、検証精度の向上に寄与する取り組みを行いました。
本事例の詳細については以下をご覧ください。

事例：本田技研工業株式会社様｜PoC支援（新しいタブで開きます）

株式会社NTTデータ関西様の事例

もうひとつ紹介するのは、株式会社NTTデータ関西様の事例です。同社では、マイナンバーカードの交付予約・管理サービスである「e-TUMO MYNUM」を展開されていますが、本サービスは比較的古くに開発されたものであることから、UI/UX 面に課題がありました。
そこで当社では、UI/UX改善策の提案とプロトタイプの構築を実施。同社内での評価会などを通してプロトタイプを紹介し UI/UX改善の価値を伝えるなど課題解決に向けたアクションを実践しました。
本事例の詳細については以下をご覧ください。

事例：株式会社NTTデータ関西| 個人番号カード 交付予約・管理サービス「e-TUMO MYNUM」のUI・UX改善（新しいタブで開きます）

自社での対応が難しければPoCのプロから支援を受ける検討を

この記事では、PoC の依頼前の整理事項や、依頼先となる会社選びのポイントなどについてご紹介しました。
スパイスファクトリーでは、PoC から本開発までの一気通貫支援や、最短2か月での PoC 実施が可能です。弊社の詳しいサービス内容はPoC・プロトタイピング開発サービスをご覧ください。
PoCやシステム開発、新規ソフトウェアの開発についてお悩みがありましたら、ぜひお問い合わせください。

https://spice-factory.co.jp/service/prototype/

無料相談はこちらから 

RFP（提案依頼書）テンプレート（無料）をダウンロード

こんにちは。サイト制作や EC構築から、UI/UX、ブランディングなどを強みとするスパイスファクトリー株式会社です。
ホームページは、もはやユーザーと企業を結ぶ玄関口、会社の顔とも言える存在であり、時代の流れやトレンドに応じてリニューアルをする必要があります。
しかし、ホームページのリニューアルをする必要性を感じているものの、制作会社をどのような基準で選べばよいかわからず困っている企業の web担当者様は多いのではないでしょうか？
そこで今回は、企業の web担当者向けに、ホームページリニューアルを依頼する際の制作会社を選定する流れや選ぶ際に懸念すべきポイントについてお伝えします。

ホームページ制作会社を選定するまでの流れ

最初に、制作会社を決定するまでの流れをご紹介します。
選定するまでに正しいステップを踏むと、以下の画像のような流れになります。（画像右側の社数はイメージです。）

企業規模や予算によって全てのステップを踏めるか否かは異なるかと思いますが、丁寧に正しいプロセスを踏むことでベンダー選定の失敗を回避することにつながります。
この項では、各プロセスの詳細説明を通して具体的な進め方やイメージを掴んでいただきたいと思います。

①ホームページの制作目的や要求事項の整理

ホームページ制作の前提事項として、制作する目的や要求事項などの整理を実施します。
このフェーズでの決定事項が、後述する RFP を形作る土台となります。

まずは、ホームページの制作目的を定義します。企業ブランディングの強化や問い合わせのさらなる獲得など、なぜホームページを制作するのかを明確化することで、以降のブレを減らすことができます。併せて、決定した目的から逆算してターゲットを決めることも重要です。

また、ホームページに求める要求事項についても整理します。
たとえば企業ブランディングを目的としたコーポレートサイトの制作であれば、自社のコーポレートカラーに合わせたデザインや自社の実績を紹介するコンテンツなどが必要となるでしょう。

こういったホームページに対する要望は、担当部門のみならず、社内の複数部署からもニーズがあることが多いです。そのため、社内の各関係部門にホームページに求めることや要望などをヒアリングする必要もあります。

②依頼先候補のピックアップ

目的と要求事項が整理できたら、依頼先の候補となる制作会社を探します。
この段階では、10社程度を目安として候補をピックアップするとよいでしょう。数が少ないと良い会社に巡り合える可能性が下がりますが、あまり多くの会社にアプローチすると対応が困難となります。
既に取引のある制作会社に加え、Web上の評判などを参考にしつつ候補を探します。

③RFIの提出

RFI（Request For Information）とは、日本語で「情報依頼書」と呼ばれる書類です。
依頼先候補に対して問い合わせを行い、ホームページ制作の目的や要求事項を説明の上、対応可否や各社の技術力の確認などを行います。
このフェーズのゴールは、RFI の情報を基にコンペに呼ぶ会社を選定することとなります。
後述する RFP と比較してあまり一般的ではない RFI ですが、RFI を提出することには以下のようなメリットがあります。

• 自社の要件に合う企業をスクリーニングできる
• RFP を配布する前に各社の情報を収集することで、制作会社選定のミスマッチを防げる
• 予算面からみて非現実的な要求がないかなど、ホームページの要求事項をブラッシュアップしできる

RFI は、会社を選定する際のチェックリストとしても活用することができます。当社では、実際の使用を目的とした RFI のテンプレートをご用意しています。テンプレートはこちらからダウンロードできますので、お困りの際はご利用ください。

RFP（提案依頼書）テンプレート（無料）をダウンロード

④RFPの提出

RFP（Request For Proposal）とは、簡単に言うと発注側がベンダーに対して提案して欲しいことをまとめた文書のことです。要望や依頼事項を整理して記載することで、各社共通の条件で提案書と見積を取得できます。
RFP は、上述の「①ホームページの制作目的や要求事項の整理」でまとめた内容や、RFI によりブラッシュアップした要求事項をもとに制作します。

あまり多くの会社に依頼をすると対応が困難となるため、RFI を通して 5社ほどに絞り込んだうえで RFP を提出するとよいでしょう。
具体的に、RFP には以下のような項目を記載します。

• システム化の概要（背景、目的、スケジュール、予算など）
• 必要な画面や機能の一覧
• 非機能要件（データ量や想定アクセス数、求めるセキュリティレベル、可用性、バックアップの必要性など）

また、RFP の提出にあたっては、事前に評価項目を定めておくことをおすすめします。要求事項が満たされているか、技術力やデザイン力があるかなど、評価観点を洗い出し、どの項目を重視するかを決めます。場合により、各観点（デザイン・プロジェクトマネジメントなど）に点数をつけ、数値で評価する方法も有効でしょう。
当社では、ホームページを制作したいと考えている方に向けて、RFP のテンプレートをご用意しています。テンプレートはこちらからダウンロードできますので、お困りの際はご利用ください。

https://spice-factory.co.jp/web/tips-template-rfp

⑤オリエンテーションの開催とRFPの配布

提案を受けたい企業の候補が決まったら、一般的にはオリエンテーションを実施して、候補となる各社にRFPの内容を説明します。
オリエンテーションは、提案を依頼したい会社を対象に同時開催することもあります。各社合同で実施することで情報を公平に提供しつつ、実施側の負荷を下げます。ただし、日程が合わないケースなどでは、個別対応を実施することもあります。

オリエンテーションにて RFP を配布した後、各社は提案の準備を行います。各社から質問があるケースも想定されるため、あらかじめ質問の締め切り期日と回答方法を決めておきます。各社から挙がった質問であっても、全ての会社に対して質問内容と回答を共有することで、各社が持っている情報を公平にすることができます。
繰り返しになりますが、この項でのポイントは提案を受ける企業に対して公平に情報を共有することです。公平な情報を提供することは各社への情報格差を無くすだけでなく、同じ条件下で提案を受けることで各社の実力を公平に評価することができます。

⑥提案書の受領

各社から提案書を収集します。

同時期に収集するために、RFP には提案書の提出期限も記載しておきましょう。前項と同様、同じ日にオリエンテーションを実施し、同じ日に提案書を受領することで同条件下で公平なパートナー選定ができることがポイントです。

提案書が集まったら、あらかじめ定めた評価項目に沿ってプレゼンテーションに進む会社を選定します。この時点で 3社〜4社程度まで絞り込むとよいでしょう。

⑦プレゼンテーション

一般的には、提案書のみで各社を評価するのではなく、プレゼンテーションを通して最終的な評価を実施します。
プレゼンテーションは、基本的に各社からの説明時間と自社メンバーからの質問時間で構成します。できるだけ質問時間を多くとることで、各社の技術力や信頼度を測りやすくなるでしょう。
プレゼンテーションは 1度のみ開催することもありますし、現場レベルで 1次プレゼンを行い会社を絞り込んだのちに、幹部層も含めて 2次プレゼンを実施することもあります。

⑧依頼先の選定

RFP の内容を受け、依頼先を絞り込みます。依頼先の選定においては、あらかじめ定めた評価基準に沿って、各社の提案内容を比較します。技術力やコスト面に加え、要件に対する実現可能性、社風、プロジェクトの体制などを踏まえ、最も優れた制作会社を選びます。

選定における制作会社の比較ポイント

次に、制作会社の選定における比較ポイントを紹介します。

同じ業界の実績があるか

制作会社選定においては、実績が重要です。特に、同業他社の制作実績があると、スムーズに制作が進みます。
同業種の実績があるということは、その業界の商習慣やビジネスモデルを理解していると考えられるため、自社と制作会社の間で齟齬なく意思疎通でき、コミュニケーションコストが抑えられることや、自社で把握していなかったところに対しても制作会社からアドバイスがもらえる等が期待できます。
そのため、まずは実績面の確認を行うとよいでしょう。

対応できる制作規模

制作会社によっては、大規模な制作に対応できないケースもあります。
制作するページ数の整理などを通して、制作規模がどのくらいになるのかを把握しつつ、候補にあがっている依頼先が対応できるか確認しましょう。
また、複雑なシステムを必要とするホームページを制作したい場合にも、依頼に対応できる技術力を持った制作会社を選ばなくてはなりません。

費用

制作会社によって費用はピンキリです。特に技術を必要とする複雑なホームページ、拡張性の高いホームページ制作を依頼する場合には費用が高くなりやすいといえます。
自社で決定した予算と実現したい内容を踏まえ、その土俵に上がる会社のなかで選定すべきでしょう。

対応範囲

ホームページ制作の目的を踏まえ、どこまでのスキルセットを持ち合わせた会社であるかを見ることが重要です。たとえば、企業ブランディングを強化したい場合や、公開後のホームページの集客の支援を検討している場合は、ブランディングディレクターやマーケターが在籍している制作会社が好ましいでしょう。
また、制作後の運用面も重要です。運用フェーズでどこまで対応してもらえるかも確認しましょう。ホームページ公開後の情報更新や、軽微な改修などの運用保守までしっかりサポートしてくれるかなどをチェックします。

デザイン力

ホームページは企業や製品・サービスの顔となりますので、デザイン性が重要です。制作会社のデザイン力を確認する上では、チーム体制や意見の吸い上げ、UIとUXの両者の視点から対応できるかなどの観点で確認するとよいでしょう。

当社を例にとると、「ペアデザイン」と呼ばれるエンジニアとデザイナーがペアとなる体制を採用しています。このような体制により、迅速かつクオリティの高いホームページ制作が可能となります。

https://spice-factory.co.jp/design/pairing_design_engineering-designer

また、自分たちの意見をうまく吸い上げてくれるかもポイントです。ワークショップの開催や綿密なミーティングなど、意見吸い上げのための取り組みを行ってくれる会社を選ぶとよいでしょう。

加えて、UIデザインのスキルのみならずユーザーテストなど実施を通したユーザビリティ改善にも対応できるかを確認します。
ホームページ制作においては、一度固めたユーザビリティ設計を机上の空論にしないためにも、適宜ユーザーテストを実施し、軌道修正を行うことが大切です。

RFP（提案依頼書）テンプレート（無料）をダウンロード

よくある3つのケース別：選定において重要視すべきポイント

ここでは、ケース別に、特に重要視すべきポイントについてお伝えしていきます。ここでは、よくあるニーズや状況を踏まえ 3つのケースに絞って具体的に説明します。

プロジェクトマネジメントも含めてお任せしたい

ホームページの目的や目標の整理など、プロジェクトマネジメントも含めて制作会社に依頼したいケースもあるかと思います。会社によっては、ホームページの制作のみを業務範囲とし、プロジェクトマネジメントは請け負わないというケースもあります。各社が対応できる業務範囲について、あらかじめ確認することをおすすめします。
成果物の品質はもちろんのこと、適切なコミュニケーションもプロジェクトを成功させるためには重要です。実際に、プロジェクトマネジメントの教本ともいえる PMBOK においても、成果物の品質と同じレベルでコミュニケーションの品質を重視しています。プロジェクトマネジメントを依頼する場合は、PM となる方のコミュニケーション能力にも注目してみるとよいでしょう。

デザイン性が高いホームページにしたい

「最新のデザインを用いたかっこいいホームページを作りたい」と、担当者のだれもが願っています。
しかし、広義な意味でのデザインには、表層的な見た目だけでなく、利用者にとっての利便性やホームページを使うことによる満足度も含まれることを忘れてはいけません。
見た目のデザイン性が高いことは重要ですが、情報が整理されていなかったり、導線が整備されていないなどユーザビリティ面で配慮が欠けているとユーザーが離脱してしまったり企業イメージが悪くなることもあります。
ユーザビリティに強い制作会社を選ぶ際のポイントは「UXデザイナーがいるか」と「UX の実績があるか」の 2点です。UXデザイナーがプロジェクトに参画することで、ユーザビリティテストやアンケートの計画・実施などを通したユーザー体験を向上させるアクションを取ることができるでしょう。
このように、表面的な外観のデザインはもちろん、その内部に設計されているユーザビリティ、いわゆる UI と UX の2軸で高いデザイン性を獲得できるかを確認する必要があります。
また、実績から類似のホームページのデザイン経験があるか、過去に制作したホームページはデザイン性やユーザー体験が優れているかをチェックすることで、制作会社やデザイナーの実力を把握することができます。
※関連記事：ユーザビリティテストの手法・工程とは？事例を基にご紹介
https://spice-factory.co.jp/design/usability-test/（新しいタブで開きます）

CMSを導入し自社で運用できるホームページを作りたい

ホームページ導入後の運用作業は、思いのほか負荷がかかります。また、数名の担当者が属人的に運用を行っているケースや、運用を別会社に委託しているため更新に手間がかかるといった声もよく聞かれます。
このような課題を解決し、自社で簡単にホームページを運用できる体制を作りたいと考えている場合、ホームページ運用に関して知見のある制作会社を選びましょう。以下の観点をチェックすることで、制作会社の力量が見えてきます。

• 制作会社に CMS の開発者が在籍しているか
• 依頼したいホームページと類似する案件の実績があるか
• 開発したい CMS の機能をよく理解しているか

特にコーポレートサイトであれば、開発する機能はほぼ定型的なものです。「コーポレートサイトの型」を知っているかも確認ポイントです。
また、どの CMS ツールを導入するか悩んでいる場合は、複数の CMS を対応している会社に多角的に提案してもらうことをおすすめします。

最適なホームページ制作会社の選定によりプロジェクト成功へ

本記事ではホームページ制作会社の選び方について詳細に解説させていただきました。

RFP（提案依頼書）テンプレート（無料）をダウンロード記事中でご紹介した通り、ホームページ制作会社を選ぶポイントとしては、以下の 4点が重要です。

• 対応できる制作規模
• 費用
• 対応範囲
• デザイン力

また、当社では、高度な開発力や UI/UXデザイン、ブランディング、マーケティングと幅広い知見を活かしたホームページ制作を強みとしています。ホームページの新規制作やリニューアルをご検討の場合は、ぜひお問い合わせ下さい。
弊社のホームページ制作サービスに関しましては以下URL からご確認いただけます。

Webサイト制作サービスを見る

https://spice-factory.co.jp/service/web-corporate/

無料相談はこちらから