提案依頼

機能要求を書く −提案依頼書(RFP)−

システムの開発を外部企業に委託する際に書く提案依頼書(RFP)。本記事では開発するシステムに実装したい機能要求の書き方を紹介します。

機能要求ってなんだろうか

機能要求のイメージ

はじめに機能要求がなんであるかを考えてみたいと思います。

機能要求とは新システムに備わってほしい業務面の特性です。対になる用語として非機能要求があります。非機能要求は新システムに備わってほしいシステム面の特性です。

もう少し詳しく説明するために、機能要求を機能と要求に分けて見てみましょう。

機能

機能とは業務面の特性です。

業務というとビジネス用途のみに聞こえますがここでは消費者が使う場合も含みます。システムの主たるユーザーがシステムにおいて成し遂げたいことを業務要求といいます。

参考:業務要求を書く

たとえば上記の業務要求では購買部における「見積もりを取る」業務について書きました。見積もりを取る業務のうち、

「見積もり依頼書の内容を確認する」

を機能として定義してみましょう。

たとえば、

  • 過去に届いた見積もり依頼書を一覧画面で表示できる
  • 開始日付と終了日付で見積もり依頼書を絞り込める
  • ひとつの見積もり依頼書を選択すると内容を参照できる

といった機能を定義できます。

一覧画面、絞り込み、選択などはシステムに実装された特性です。見積もり依頼書の内容を確認する業務要求を実現するための機能といえます。

業務要求は機能要求と非機能要求に分解できる

要求

要求とは願いや希望です。

してほしいということを伝えるために要求という表現をつかいます。

よく要件と要求の違いについて比較することがありますが、要件は依頼元と開発者で合意済みのものを指します。

一方で要求は依頼元の一方的な願い、希望です。

参考:システム開発における要求と要件の違いとは

提案依頼書を作成、送付する段階では依頼元と開発者で合意されていませんから、ここでは要求という言葉をつかっています。

機能要求を伝えることのメリットとデメリット

機能要求のメリットとデメリット

提案依頼書を通じて機能要求を伝えることはメリットとデメリットの両方があります。

メリット

機能要求を伝えることのメリットには下記があります。

  • 開発会社が商品選定をしやすくなる
  • 開発会社が見積もりをしやすくなる
  • 見積もりの精度があがる
  • 実装の制約を教えてもらえる(できないことが分かる)

実装したい機能が明確になることで、外部企業は提供する商品(システム)をより精緻にえらぶことができます。

またシステムが精緻になることで見積もりがしやすくなり、精度があがります。

また具体的な商品が選定されることで、実現できないこと、すなわち制約を明らかにすることができます。

デメリット

一方でデメリットもあります。

  • 非効率な機能を書いてしまう
  • 提案の幅を狭める(余地が狭まる)
  • 見積もりが高くなる可能性がある

業務要求をみたすためには、いくつかの機能の選択肢があります。

複数の選択肢があるなかで、特定の機能に限定して要求を書いてしまうと、実はもっと効率の良い機能がある可能性があるのです。

外部企業は記載された機能要求を正として考えますので、非効率な機能にもとづいて提案が展開されてしまいます。

外部企業が代替の機能に気づく可能性が低下し、提案の幅を狭めてしまうことになります。また、過大な機能要求にもとづいて提案がなされる場合には、見積もりが高くなる可能性があります。

このように、依頼側が機能を特定して要求すると、よりよい機能の代替があるにもかかわらず提案が進んでしまうデメリットがあります。

機能要求の書き方

機能要求の書き方のイメージ

こちらで紹介した購買部における「見積もりを取る」業務要求を例にとって機能要求を書いてみましょう。

上記から「見積もり依頼書の内容を確認する」についてみてみましょう。

見積もり依頼書の内容を確認するためにたとえば下記のような機能要求が考えられます。

  • 過去に受信した見積もり依頼書をひとつの画面で一覧で確認できる(直近10件くらいを見らられると良い)
  • 過去に受信した見積もり依頼書の送信者名、所属部署、送信日時、見積もりタイトルを画面で確認できる
  • 見積り依頼書の一覧画面で、複数の見積もり依頼書を選択してPDF形式でダウンロードできる
  • 見積もり一覧画面からひとつの見積もり依頼書を選択すると、見積もり依頼書の内容をプレビュー表示できる
  • 見積もり依頼書のプレビュー画面で、見積もり依頼書を参照しながらコメントを入力できる

機能要求はなるべくシステム、おもに画面に向かった操作をイメージできるように記述します。

また、機能要求は業務要求と異なり、システム固有の表現があらわれます。

たとえば「画面」や「PDF形式」「ダウンロード」「選択」「プレビュー」「入力」です。これらはシステム固有のことばであり、機能要求だからこそ記述できる内容です

さらに文末を「〜できる」で結ぶことで、システムに実装させたい意図を表現できます。

フォーマット

機能要求のフォーマットのイメージ

機能要求を記載するフォーマットは汎用的なツールとしてはスプレッドシート(ExcelやGoogleスプレッドシートあたり)が良いと思います。

またWordやGoogleドキュメントでも記述可能ですが、スプレッドシートと比較すると一覧性に少し欠けるかもしれません。

内容(スプレッドシートでいう列)には下記の項目を記述しておくとよいです。

  1. 機能分類(大・中・小)
  2. 機能分類番号
  3. 機能要求番号
  4. 機能要求番号枝番
  5. 機能タイトル
  6. 機能概要
  7. 制約
  8. 機能をつかう端末
  9. 想定ユーザー
  10. 関連する業務要求
  11. 参考資料番号
  12. 補足事項

サンプル

機能要求のサンプルのイメージ

機能要求のサンプルはこちらです。

まとめ

機能要求とは新システムに備わってほしい業務面の特性でした。

業務要求と機能要求の関係性を理解して、業務上実装したい機能を正確に伝える一助になれば幸いです。