過去のブログでもRFI（情報提供依頼書）とRFP（提案依頼書）について触れていますが、今回は、それらの中の重要な要素である機能要件を取り上げてみたいと思います。
特にRFPでは新しいシステムで実現したい機能をベンダーに伝える重要な部分になりますが、そもそも機能要件とは何かということや、ベンダーに伝わりにくい要件の事例などをご説明していきます。
RFIとRFPとは
まず、初めてRFI（情報提供依頼書）やRFP（提案依頼書）という言葉を知った方に向けて、簡単に双方の内容をご説明します。
・RFIとは
RFI（Request For Information）とは、システムの選定を行う際、システムベンダーに欲しいシステムの概要を伝え、取り扱っているシステムに関する情報提供をお願いする依頼書のことです。
詳細は過去のブログ「システム選定の第一歩～RFIの作成とその効果」をご覧ください。
・RFPとは
RFP（Request For Proposal）とは、システム等を発注するにあたり、取り扱っているベンダーへ提案を依頼するための資料のことです。
詳細は過去のブログ「なぜRFPを作成するのか？RFP作成の効果と留意点」をご覧ください。
機能要件の概要
機能要件は、RFIやRFPの要求事項の一部として作成します。
一般的には一覧形式にして作成し、システムの種類ごとに欲しい機能を表現していきます。
会計システムを検討しているのであれば、次のような内容が機能要件となります。
「振替伝票の入力ができること」
「手入力または外部から取り込んだ伝票データは、修正および削除ができること」
「勘定科目の追加や修正は、経理の限られたユーザーだけが可能であること」
「決算整理仕訳は通常の仕訳とは別に入力が可能なこと」
「画面表示のできる帳票は、Excel形式およびPDF形式による出力も可能であること」
機能要件はあくまでも新システムで実現したい『機能』について記述します。
システムで扱うデータの種類、処理の内容、画面表示、出力帳票など、業務において、そのシステムで何ができなくてはいけないのかをまとめていくのです。
ベンダーに伝わりにくい機能要件の事例
上記のような内容がベンダーにうまく伝わればよいのですが、曖昧な記述や説明不足などが多い場合は、ベンダーに理解されず、誤解の果てに的外れな回答をされてしまうことになります。
以下にいくつか、改善を要する表現の事例をご紹介します。
転ばぬ先の杖として、ご参考にしていただければと思います。
・「ISO（社内用語）を実現できること」と書いてある。
社内でのみ通じる言葉や略語がそのまま使われていることがあります。
日常的に社内で使っているので、あまり疑いなく書いてしまったということなのでしょうが、社外の人間、ましてや業界の違う人（ITベンダー）からしますと、暗号や符丁に近い言葉です。
どうしても使わざるを得ない場合には、該当業務の補足資料や用語集をつけるなど、ベンダーに正しく理解してもらう資料を併せて作成することをお勧めします。
・「条件に応じたアラート設定ができること」と書いてある。
一見、なるほどと納得してしまいそうになりますが、どの業務でどのような場面におけるアラートを設定できれば要件を満たせるのか、読み手が特定できず、自分たちの都合に合わせた解釈をされてしまう可能性があります。
書き手の気持ちを察すると、システムの基本として全体的に設定できる仕組みを望んでいるのかもしれませんが、それがもっと伝わる記載にするべきと思います。
・「帳票印刷を可能な限り減らしたい」と書いてある。
資源の無駄遣いが叫ばれる昨今、その方針には大賛成です。
しかし、どの程度の削減ができればよいのでしょうか。この思いにたどり着いた背景に加え、何をどのようにしたいのか、業務領域や対象の帳票などを記載して、より良い提案を引き出す工夫が、もう一押し必要であると考えます。
・「セキュリテイ管理機能」と書いてある。
これはもう探り合いの極致でしょう。残念ながら、どのような回答を期待しているのか伝わってきません。
友人や恋人と食事をしようとしたときに、相手から「今日は何でもいいよ」と言われたときに近い状況です。
ベンダーは様々な回答をしてくれるかもしれませんが、書き手が期待した内容になるとは限りません。
求めていることに近い回答を得たいのであれば、より具体的に表現するか、せめて方向性くらいは伝えておくようにするべきだと思います。
機能要件の作成ポイント
機能要件を書くコツは、この文章で相手に伝わるか、他の意味に捉えられないかをよく考えることです。
5W1Hを遵守してとまでは言いませんが、できるだけ近づけるような書き方を意識することで、相手に伝わりやすい内容になっていくと思います。
また、一つの要件項目の中に複数の要素を入れると、後々、正確な評価ができなくなる可能性が生じます。
「受注伝票を入力し、入力後は一覧表として出力できること」
としますと、入力はできるが一覧表を出せない場合、その要件は○なのか×なのか判断に迷うことになります。
たまに要素がとても多く複雑で、密度の濃い要件を見かけることもありますが、それに応じて回答も複雑になります。
読み解くベンダーも苦労をすれば、回答された側も訳が分からなくなる、そのような状況に陥ることは避けるべきであると思います。
とは言え、いきなり機能要件を上手にかける方は多くはいません。そもそもシステム選定をすること自体が数年に一度あるかないかの出来事です。
さらに基幹システムと呼ばれる大掛かりなものを選ぶことになれば、情報システム部門の方でも滅多にはない経験となります。
まずは上記のことを意識して、丁寧に記述し、曖昧な表現を避けることを心掛けていただければと思います。
それでもなお意図が伝わらない場合は、ベンダーから質問をされるはずですので、それに真摯に答えてあげてください。
やり取りを重ねることでお互いの考えの溝を埋めていくことが可能です。
まとめ
・機能要件とは
☑ システム単位に欲しい機能を表現する。
☑ 新システムで実現したい『機能』について記述する。
・機能要件記述の留意点
☑ システムで何を実現したいのか、可能な限り具体的に書く。
☑ 5W1Hに近い書き方を心掛けると、ベンダーに伝わりやすい。
☑ 一つの項目には複数の要件を書かない。
