RFPに記述すべき非機能要件とは | システム導入検討のエッセンス（３）

イントロダクション

前回は主にRFIに記述すべき内容と気を付けるべきことをお話ししました。
最後は現行業務の整理はRFI・RFPで記載すべき内容とリンクするというところまでお話しました。

今回はRFPに記載すべき内容から、特に非機能要件に着目していこうと思います。

非機能要件は調達時に要件を漏らしがちで、運用が開始してから問題になったり、逆にオーバースペックな要件を提示して費用を圧迫したりする危険性があります。
業務部門にあまり注目されない部分だからこそ、情シスがきちんとコントロールしなければいけません。

非機能要件とは何か

RFPに記載すべき内容と機能要件

RFPに記載すべき内容を並べると以下のようになります。
項目の順序や、どの項目に記載されるべきか等は文献や情報によってやや異なりますが、要素としては概ね以下のような内容になります。

1	提案依頼の主旨	提出期限、提出方法、提出を依頼する資料等、主に提案提出自体についての決まり事を連絡します。
2	調達の背景、狙い	経営的な背景、解決したい課題、そこから導かれる今回の調達の目的を説明します。
3	導入計画	最終的に達成されるべき要件（ゴール）、導入の対象となる範囲（スコープ）、導入に係る期間（スケジュール）、納品されるべき成果物（アウトプット）等、調達全体の計画を通知します。
4	契約条件	契約形態（完成開発／業務委託）や支払方法、検収条件の他、秘密保持契約、瑕疵担保責任、再委託に関する取決、損害賠償等、契約に関わる事項を通知します。
5	プロジェクト管理要件	ユーザー側とベンダー側の責任と役割、プロジェクトの体制（責任者、リーダー、メンバ等）、作業場所等のプロジェクト体制についての要件を通知します。定例報告の有無や会議体、連絡方法や文書管理規程等まで記載する場合もあります。
6	機能要件
7	非機能要件

この中で実際に動作するシステムについての要件は「機能要件」と「非機能要件」になります。

機能要件は、読んで字のごとく機能についての要件です。
特定のシステムについての要件にならないような例を挙げてみます。

<機能要件の例>

【画面操作系の機能】
・○○の処理が行えること
・ワークフローが設定できること
・処理中の内容を一覧表示できること

【サーバ処理系の機能】
・締め処理等の一括処理が行えること
・連携ファイルの出力／取込が行えること

それでは「非機能要件」とは何でしょうか。

非機能要件＝直接的な業務要件以外の要件

非機能要件を一言で言ってしまえば「機能要件以外の全ての要件」です。
それではあまりに乱暴なので、具体的な例でお話してみます。

例えばログイン認証機能は非機能要件にあたります。

別にログイン認証が無くてもデータの入力ができれば業務は行えます。
しかし本来操作すべきでない人が操作できてしまうと、データの正しさが保障できなくなります。
許可された人が、許可された方法で利用することで、システム全体の保全を図ることができるのです。

非機能要件は業務部門にとってはあまり興味が無いものが多いですが、システムを効果的に利用するためには非常に重要な要件になります。
ユーザー側でここを考えられるのは主に情シスです。

要件を漏らさないためにも、検討すべき非機能要件のカテゴリを紹介します。

非機能要件の６つの要素

非機能要件は検討すべき６つの要素があります。

可用性

可用性とは「システムが継続して稼働できる能力」のことです。
どんなにすばらしいシステムであっても、使えなければ意味がありません。
具体的に記載すべき事項は以下の通りです。
これらの要件についてSLAを締結することを求める場合もあります。

運用時間	何時から何時まで動作しなければいけないか。停止時間はどの程度許容するか。
バックアップ	どの程度の頻度で、何世代まで管理するか。バックアップ保管先はどうするのか。
耐障害性	機器の二重化などの冗長性確保や障害発生時の復旧目標について。システム監視やアラート通知による予防措置も含まれる。

性能・拡張性

機能は業務要件を充足しているけれど、画面が表示されるのに毎回数十秒待たされるようなシステムでは生産性も悪化しますし、使い勝手がいいとはいえません。
また大金はたいてシステムを導入したのに、データ増加量やシステム負荷を見誤り、早々に機器増強をすることになってはいけません。
導入工程に性能評価や縮退テストを行うことを求める場合もあります。

レスポンス	通常時、繁忙時、縮退時に求めるシステムのレスポンス。画面描画に係る時間やバッチ処理の許容時間を定める。
スケールアップ・スケールイン	利用量増加に伴うシステム拡張の余地を定める。キャパシティプランニング。

移行性

移行されるのはシステムのデータだけではありません。
運用全体が移行するのですから、そのための準備も含めた移行に関する要件を定義します。
教育や研修についてはユーザー側で行うことで費用を抑える方法もあります。

データ移行計画	現行システムからのデータ移行範囲、並行運用、移行リハーサルの実施等を定める。
教育・研修計画	システム移行に伴うユーザー教育コンテンツやマニュアルの作成等の要件を定める。

セキュリティ

ログイン認証は当たり前のように思いがちですが、これも一つの要件です。
前回例に出したような個人情報の取り扱いのような場合、セキュリティ要件は必須になります。

権限制御	操作者によるアクセス範囲の制限を設ける。ログイン認証等を含む。
システム監視	ログイン情報、操作情報等の保持・閲覧に関する要件を定める。

システム環境・エコ

オンプレミスであれば自社のサーバー室のキャパシティも要件になります。
データセンタ利用の場合、データセンタに求める要件も含まれます。
グリーン購入法により推奨されているエコ調達や、消費電力低減によるランニングコストの低減も考慮すべき事項になります。

設置環境	耐震／免震、重量や温度、騒音などの要件。
エコ	CO2排出量や消費電力の低減についての要件。

中締め

「できていて当たり前」なことなど無い

非機能要件で定義すべき内容を網羅しようとしたら、それだけでかなりの分量になっていまいました。
逆に言えばシステムを安定して稼働させるためにはこれだけのことを考慮しなければいけないということになります。

導入したシステムに対して「これくらいできてて当たり前なのになんでできないんだ！」と簡単に言う人もいますが、こちらから要求していないものは当たり前にできるとは限りません。

昨今インターネットでは様々なサービスが無料で提供されています。
SE時代のお客さんに「無料で使えるAmazonやGoogleにできていることが、大金払ってる御社に何でできないんだ！」と言われたことがあります。
心情的には理解できますが、提供している価値に大きな違いがあります。

AmazonやGoogleは便利かもしれませんが、不具合が起きても復旧時間を保障してくれません。直感的に使いやすいようにUIが工夫されている反面、懇切丁寧な操作マニュアルや研修が準備されているわけではありません。興味のある人、使いたい人は自力で調べますが、そうでない人に手を差し伸べるほど親切ではありません。

対象としているスコープも、提供しているサービスも、収益構造も違うものを「システムだから」というだけの共通点だけで引き合いに出すのは、高級輸入食器を買おうとして「100円ショップで売ってる皿でさえ電子レンジ調理に使えるのになんでできないんだ！同じ皿だろ！」と言っているのようなものです。

100円ショップの皿で賓客をもてなすつもりならそれでもいいですが、恐らくそんなことはしないでしょう。形状が似ていても、提供されている価値がまるで違うのです。
もし電子レンジ調理に使いたいのであれば、要件に明確に盛り込んでおかなければいけないのです。