2019
4/03
第22話:RFPの非機能要求は情シス/IT部門が合意に責任を持つ
- RFP/RFI
- コラム
- 情シス論
執筆者
情シスコンサルタント
田村 昇平
ユーザー部門の甘い囁き
「システムや技術的な部分は全てお任せします」
情シス/IT部門の立場でRFP作成を支援していると、必ずユーザー部門から言われる言葉です。
その後には、大抵こう続きます。
「我々は業務のプロだが、システムは素人なので」
「聞いても分からないので、全部決めてほしい」
「その方がお互い時間を取られず楽でしょ?」
情シスとして頼られることは嬉しいのですが、ユーザーの「甘い誘惑」にのって、情シスが一方的にシステム周りを定義してしまってよいのでしょうか?
非機能も必ず合意する
RFPには、大きく「機能要求」と「非機能要求」に分けられます。
ざっくり言えば、「機能要求」は、業務として必要な機能、「非機能要求」は、業務以外の全てです。
一般的に「非機能要求」には以下が挙げられます。
- 移行要求
- ユーザー教育
- システムインタフェース要求
- 運用/保守要求
- 性能要求
- セキュリティ要求
- バックアップ要求
当然ながら、ユーザーは「機能要求」に強い関心があります。放っておいても、ユーザー主導で整理は進みます。
一方で、「非機能要求」はびっくりするほど、ユーザーは関心がありません。
しかし、この「非機能要求」こそ、システムを「安全・安心・安定」して使うためには必要であり、業務にも強く影響する部分です。
「非機能要求」をおろそかにすると、次のようなリスクが高くなります。
- システムが遅くて全く使えない
- 過去データが見られなくて、業務に大きな支障が出る
- データが暗号化されていなくて、情報が流出している懸念がある
- システム障害が発生して、丸一日使えなくなった
- ライセンス料が急に2倍になった
- カスタマイズをベンダーに拒否された
- サービスが突然終了になって、業務が継続できなくなった
これらリスクが後に顕在化した場合、ユーザーが関与していなければどうなるでしょうか?
情シスが、一方的に責任を追及されてしまいます。
そうならないために、「非機能要求」もきちんとユーザーと合意した上で、RFPに定義しておく必要があります。
お互い楽だからと、情シスが勝手に定義していいわけではないのです。
非機能は情シスの専門領域
「非機能要求」は、項目も多く、それなりに会議を必要とします。
時間を費やすにつれ、ユーザーは不機嫌となり、会議欠席や流会をしようとするケースが多くなるかもしれません。
そこを踏ん張り、一時的に嫌われてでもきちんとユーザーと合意していく姿勢が、情シスには問われます。
「非機能要求」は、情シスの専門性として意識するべきです。ここは、絶対にユーザー部門では定義できない領域だからです。
「機能要求」はユーザー部門、「非機能要求」は情シスがそれぞれリードすることで、お互いが対等な立場で、強みを補完し合えるチームになっていきます。
その積み重ねが、長期的に情シスの信頼性向上にも繋がります。
貴社では、情報システム部門/IT部門が責任をもって「非機能要求」の合意を進めていますでしょうか?
コラム更新情報をメールでお知らせします。
執筆者プロフィール
情シスコンサルタント 田村 昇平
IT部門の育成・強化を専門とするコンサルタント。
ITプロジェクトの企画から導入・保守までの全工程に精通し、そのノウハウを著書「システム発注から導入までを成功させる90の鉄則」(技術評論社)で公開している。
>>著書の詳細は、こちらをご覧ください。