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