«

»

1月 04

013システム要件定義の「システム的部分」のまとめ方の知恵

情報システムの導入を計画しているが、ITに熟達した社員のいない会社にとって、システム要件定義の業務部分は何とかできたとしても、性能、運用、セキュリティなどに関する非機能要件まとめはハードルが高すぎる。2段階作成で乗り切る方法を提案する。

□ よく知らないでする「法外な」要求
例えば、今の情報システムの端末応答時間が遅いと感じることから、新しいシステムの要件定義では、「端末応答時間は1秒以内とする」という定義したとする。これを提案依頼書に含めてITベンダーに提案と見積り依頼をすると、アッと驚くデラックスなシステム構成と見積価格が提示されるかもしれない。現在でも速いときは1秒くらいだから大した違いではないと思ってはいけない。必ず1秒以内にするには、起こりえるあらゆる状況をクリアするような仕組みが必要なのだ。仮にアバウトに、「できればこうしたい」というものを、「定義して」しまうと、受託企業としてはそれが完成の絶対条件となるので注意が必要である。

□ 非機能要件の定義は専門知識が要求される
システム要件定義の内容を大きく分類すると、業務の要件から導いて、どのような機能をシステムで実現したいかを定義する「機能要件」と、それ以外の「非機能要件」に分けられる。機能要件は業務の専門家が「こうあって欲しい」内容をしっかりと定義することでほぼ問題ないが、非機能要件は技術的な内容が多く、情報システムの専門家がいない企業では適切にまとめるのが難しい。

□ 主な非機能要件
システムの非機能要件定義では、主に以下のような内容を定義する必要がある。
1.処理量(利用者数、同時利用者数、データ件数、ピーク時の時間あたり処理量など)の現在値と将来の予測値
2.速度性能(端末応答時間、ファイル転送時間、夜間処理時間など)
3.システム構成(サーバー、ネットワーク、端末はどうするか)
4.情報セキュリティに関する事項
5.既存システムとの関係
6.使用性(使い勝手)
7.運用要件(1日、1週、1ヶ月、1年の稼働時間、ヘルプデスク、障害時の対応、データバックアップ、サーバーバックアップなど)
8.災害時の対応
9.開発言語など、開発に関する要件
10.信頼性に関する要件(1年間のシステム停止許容時間、ハードウェア障害時の復旧時間など)

□ 分らなくても要件定義はしなければならない
この部分は分らないので定義しないという手もあるが、出来上がったシステムで、定義していない部分については、不都合があっても無償では変更してもらえないかもしれない。機能は抜群に良いが、データ件数があるレベルを超えると端末応答時間が極端に遅くなるという例もある。また、個人情報を大量に扱う業務なのに、セキュリティ的に弱いシステムを入れてしまうことありえる。利用上、業務上、経営上の大切な価値と結びつくことがあるので、やはり非機能要件も定義する必要はあるのだ。
非機能要件の定義をまとめられる力のある社員がいれば問題はないだろうが、普段、システムとは余り縁のない人が、上のような項目をまとめるにはどうすればいいのだろうか。

□ 2段階作戦で乗りきる提案
基本的な作戦は、2段階作戦だ。
第一段階は、次のようにおこなう。まずは、少なくともどのような項目を定義したらいいかは調べておく必要がある。上の10項目のようなものだ。そして、「こうあるべき」という要件については、「希望」あるいは「現在の考え方」としてやんわりと記載する。「できれば端末応答時間1秒」という内容を含めても構わない。
提案依頼書にはこのソフトな要件記載を提示して、次のような回答要領を記載する。「貴社が標準的に考えるシステム構成を基本に提案してください。その構成を前提に、これらの要件の実現度合い(できる、できない、留意事項、例外事項など)を御回答ください。」とする。提案の依頼内容を説明する場を設けて、どのあたりは標準的なものでよくて、どのあたりは気にしているかも口頭で補足すると良い。
第二段階は、提案書の説明のときに、この部分の回答については双方、誤解の無いように説明をもとめ、当方の考え方と異なる場合は修正をもとめる。このとき、技術的な言葉を次々と繰り出しきて、こちらの頭で理解できない状態になるようであれば、残念ながらそのITベンダーと当方は将来にわたって付き合っていくのは難しいと判断すべきであろう。

□ 情報セキュリティだけは少しだけしっかりと理解を
ただし、情報セキュリティだけは、日々、脅威が変わってきているので、少し前に開発されたパッケージシステムやITベンダーのプログラム作成基準が最新の脅威に対応できていることは確実にしたい。IPAの「安全なウェブサイト作り方 改訂5版」、「安全なSQLの呼び出し方」、「セキュリティ実装チェックリスト」などに対する対応状況を確認するのもひとつの方法である。
参考URL:http://www.ipa.go.jp/security/vuln/websecurity.htm
(2012.3.7 執筆:山田一彦)