〇 記述が難しい「技術要求」、分からなければ見えを張らずベンダーに聞く。
RFP（提案依頼書）に記載する要求は大きく3つに分類できる。「業務要求」「技術要求」「運用要求」の3つである。
業務要求は機能要求という言い方で呼ばれることもある。エンドユーザーがシステムを利用して業務を行う上でシステムに必要な機能などを指すからだ。例えば顧客情報システムであれば、顧客名や住所などを登録できること、それらが検索できる機能を持つことなどが業務要求である。
同じように技術要求と運用要求を合わせて非機能要求とも呼ばれる。特に一般的には非機能要求は技術系の要求を意味することが多いようだ。機能要求という言い方はまだしも、この非機能要求という用語はいまひとつ実態を表していないように思う。それゆえ筆者は技術要求・運用要求という表現を用いている（図1）。今回は技術要求を取り上げてみたい。
技術要求とは？
技術要求の主だったものの意味と例を以下にまとめてみた。
1. インフラ要求：システムが特定のハードウエアやソフトウエア、ネットワークなどの環境で動作することを要求する。
- サーバーはクラウドであること
- クラウドを利用する場合、リージョンは日本国内であること
- 一般的なインターネットから接続できること
2. パフォーマンス：システムが一定の処理速度や応答時間を達成することを要求する。
- ユーザーの操作に対するレスポンスタイム（通常の画面遷移など）は原則3秒以内とする
- 複雑な検索や大容量データの出力などは上記の対象外とする
3. キャパシティー：システムが複数のユーザーに対して同時に利用可能であり、適切なスケーリングをサポートすることを要求する。
- ユーザー総数は1000人、想定同時ユーザー数は100人程度が上記レスポンスタイムで利用できること
- 予想される年10％のデータ容量の増加に最低5年間対応できること
4. 可用性：システムが高い可用性を持ち、長時間の停止やシステムの障害が発生しないことを要求する。
- システムの稼働率は99.9％であること
5. セキュリティ：システムが適切なセキュリティ対策を備えており、機密性やデータの保護を確保することを要求する。
- 保存されるデータは暗号化されること
- 適切なアクセス権の設定ができること（システム管理者、業務担当者、閲覧のみのユーザーなどを想定）
- コンピュータウイルス対策が継続的に取られること
6. 拡張性：システムが将来的な拡張や変更に対応できる柔軟性を持つことを要求する。
- 将来の機能追加や変更を想定し、高い拡張性を持つこと
- 今回のフェーズでは対象外だが、将来的に外部のオンライン決済サービスと連携できること
7. ユーザビリティー：システムが使いやすく直感的であり、ユーザーが容易に操作できることを要求する。
- 事務ミスの防止のための工夫がなされたユーザーインターフェースであること
- 不特定多数の利用者が想定されるため、直感的で分かりやすい画面デザインであること
8. 障害対策：システム障害発生時の対策が適切に取られることを要求する。
- ミッションクリティカルなシステムであるため、ホットスタンバイ構成であること
- ホットスタンバイの必要はないが、ダウンタイム4時間以内に復旧できること
- バックアップの対象は全てのデータ、ログ、必要なドキュメント、プログラムを対象とすること
これらは一般的な技術要求（非機能要求）の例だが、プロジェクトやシステムの要件によってもちろん要求内容は異なる（図2）。
技術要求は中途半端やオーバースペックに陥りがち。
技術要求は、システム調達の3本柱の1つであり、RFPには記載が必須の事項である。ところが、実際の調達プロジェクトで技術要求が中途半端に記載されていたり、逆にどう見てもオーバースペックになっていたりするケースがしばしば見受けられる。そうなってしまう主な原因は2つあると考える。
1つは、RFP作成や要件定義の作業は、業務要求（機能要求）の洗い出しから始めるため、どのような機能を実装するかによって、必要な技術的性能が変わってくる。技術要求はどうしても作業手順的に後回しになりやすいのだ。調達プロジェクトのスケジュールが押してきた場合など、十分な検討がされなくなってしまう。
もう1つの原因は、誰が技術要求を洗い出し、整理するのか担当がはっきりしないことだ。技術要求の性質からして本来は、情報システム部門が機能要求をきちんと理解した上で、技術要求を仕切るべきである。だが、ユーザー部門がシステム開発予算を持ち、情シス部門がゲスト的に参加するような調達プロジェクトも増えてきている。そのような調達では情シス部門が業務要求を深く理解する時間も機会もない。
また特にITの世界は技術の変化や進化が日進月歩であるため、情シス部門がそれをすべてキャッチアップするのは困難になってきているのも現実である。それゆえ、記載が難しい。
さらに厄介なことがある。頑張っていろいろと調べて、詳細に技術要求を記述したとしよう。ベンダーはRFPに詳細に記載があればあるほど、それを順守し、提案に反映させてくる。なので、もしその技術要求が後から適切でないことが分かった場合、すべて発注者側の責任となる。
また、聞きかじりで十分に技術や効果を理解せずにオーバースペックな要求を書いてしまうと、確かに要求は満たすかもしれないが、とんでもない金額の見積もりが出てきてしまう。街乗りの小型車で十分なのに、高性能スポーツカーを買っても使いこなせないのと同じようなことになる。
分からなくて困ったときは？
それではどうしたらよいのだろうか？ もし予算があればコンサルタントを雇えばよい。予算もなく、自社で十分に技術要求を決められないのであれば、ベンダーと議論すればよい。RFPを書く前にRFI（情報提供依頼書）を用いて、ベンダーと情報交換するのだ。
その際に「当社はシステム要員が質・量とも不足しており、技術面ではベンダーさんの提案を期待したい」と伝えよう。見えを張るより正直に、技術要求の具体化・詳細化が社内ではできないことを理解してもらい、RFPに「適切に提案してほしい」と書いた方が良い提案を得られることはよくある。技術系の情報は、通常ベンダーの方が鮮度の良い情報を持っている。またベンダーの提案なので、追加や変更が後から発生した際もベンダーが主体的に対応や再提案をしてくるからだ。
ユーザーが技術的に分からなくて困っていることに真摯に向き合い、プロとして適切助言や提案をしてくるベンダーであれば、システム構築を任せても安心だろう。逆に、ユーザーの無知につけこんでオーバースペックな提案・見積もりをしてくるベンダーも中にはいるだろう。見抜き方の1つとして「素人でも分かるように説明してほしい」と要望してみよう。たいていの場合そのリクエストにまともに応えられず、IT業界用語だらけに意味不明の説明に終始することが多い。
そのようなベンダーかどうかは、RFIで何社かと話をすれば、おのずと違いが分かってくる。分からないことを知るには、きちんとコミュニケーションを取る。それは技術要求にもまったく当てはまる。
