ユーザー企業から特に性能要求がなく，性能条件の取り交わしを行わずに，性能について自主目標で開発してしまうと，納入後に品質問題が発覚し，基本設計に遡って開発の大幅な修正を要することになる。情報システム部がしっかりしていればこのようなことはあまりない。しかし，想定プロジェクトのように情報システム部が弱かったり，利用部門から直接口頭で受けたりするケースは増えている。
「これくらいの性能は当たり前」とユーザー側が無意識に考えていることがある。無意識に考えていることは，開発サイドには伝わりにくい。ベンダー側も要求仕様に書かれていること以上の実装は行わない。ユーザーが考える「当たり前性能」を引き出し，要求仕様の“抜け”を開発前に埋めておく必要がある。
プロトタイプで体感してもらう
当たり前性能は，処理の内容によっても異なる。レスポンスが売り上げを左右するECサイトと，社員が時々使うだけの人事システムとでは性能に対する考え方が全く異なる。それらによってアーキテクチャや運用の手順が変わってくる。
性能要件は本来，要求仕様に盛り込むべきなのだが，ユーザーのスキル・レベルによっては引き出せないこともある。その場合，ベンダーとしては2つの対策を取る。
一つは，過去の類似システムを参考にしたり利用者の立場に立ったりして，性能目標の案を自ら設定する。システムの評価に必要な性能項目と参考値を設定し，ユーザーに提案する。その内容は，提案書に盛り込む。
 図9●性能要件の例 項目と目標値をユーザー，ベンダー双方で誤解のない表現で明記する [画像のクリックで拡大表示] |
 図10●プロトタイプによる性能確認 [画像のクリックで拡大表示] |
性能要件の達成は，ソフト以外の要素であるハードやネットワークに大きな影響を受ける。そこで自社のみでは達成できない目標があるため，以下の内容を明確にしておく（図9）。
1．性能目標達成の責任範囲を明確にする。例えばインターネットに接続して検索するシステムでは「機器Aの検索開始からインターネット接続前の機器Bのデータ受信時間が○○秒以内」など。
2．使用するハードやネットワークのスペックや特性を充分に理解して，達成するための条件を明確にする。例えば，ネットワークのトラフィックが増大する時間帯と通常時では検索時間が異なるため，一般的には最繁時の条件と値を明確にしておく。
性能要件が不明確な場合の2つめの対策は，可能な限りプロトタイプを作成すること。プロトタイプにはダミー・データを入れておき，本番システムになるべく近い性能が出るように調整する。プロトタイプの代わりに，過去に開発した類似システムでもよい。開発フェーズに入る前に，利用者に使ってもらい合意を得る（図10）。
必達要求と目標を分ける
性能要件は，システム構成やネットワーク環境，ユーザーのデータ量などを考慮して，システムとしてめざす「努力性能目標（高い目標）」と「必達性能目標（システムの運用上支障のない最低限達成すべき値）」を設定する。必達性能目標は，ユーザーの合意を得てユーザーと文書で取り交わす。努力性能目標は，納入後のトラブルを避ける意味で，明文化はしない方が無難だ。
要求の折り合いがつかない場合，安易な約束はしない。ユーザーと改めて，システム環境，ハード，ネットワーク構成，データベースなどあらゆる観点で実現のための歩み寄り交渉を行う。初期段階での変更ならコスト，納期への影響が少なく，ユーザー側も譲歩しやすい。
【参考文献】
●「プロジェクトマネジメント学会誌」（通巻16号）
ソフトウェア開発プロジェクトにおける実践的初期リスク手法の提案
●日経コンピュータ「プロジェクトマネジメント大全」
第3部第1章 模範的対策を網羅した「実践ガイド」
|
町田 仁司 |
