事業コンセプトをどう実現していくか
先に挙げた2つのシステムをもう少し深堀りしていこう。
前回紹介した「非機能要求グレード」の6大項目を思い出してほしい。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
次のステップは、洗い出した事業コンセプトで実現すべきこと、および情報システムとしてどうあるべきかについて検討していくのだが、その際、この6大項目を意識しながら作業を進めていくと、より具体的な情報システムの姿が見えてくるようになる。
ここでのポイントは、先の作業で明らかにした情報システムで実現すべきレベルを、さらに定量化された言葉で表現し、具体的な数値を可能な限り盛り込んでおくことだ。なお、ここでは、システム基盤として実現する非機能要求に限定し、カッコ内には6大項目のどの項目に当たるかを示しておく。
通信事業者の携帯電話システム
- いつでも…システム構成にホットスタンバイもしくはクラスタ構成を採用する（システム構成）。別のデータセンターにディザスタリカバリシステムを用意し、事業継続性を高める（可用性）
- どこでも…サービスエリアの人口カバー率を向上すべく、基地局の拠点数を増やしたり、地域的な広がりを考慮した設置にする（たとえば地下鉄の駅構内に）（システム環境・エコロジー）
- 確実に…通常時の10倍のユーザーからアクセスがあってもつながるようにする（性能・拡張性）。セキュリティ対策として伝送路の暗号化を行う（セキュリティ）
- だれでも…サポート窓口（サービスデスク）を設置し、24時間メールで問い合わせの受付と、9〜17時の間は電話での問い合わせを受け付ける（運用・保守性）。古い携帯向けと新しい携帯向けのサービスを継続するため、古い機器の保守契約期間を延長する（運用・保守性)）
チケット販売システム
- いつでも…深夜2〜4時の保守時間を除き、サービスを提供する（可用性）。大量のアクセスがあっても目標性能に対し、99%の遵守率で捌けるように、クラウドでリソースを柔軟に増やす（性能・拡張性）
- だれでも…購入画面を日本語以外にも英語と中国語の多言語対応にする（システム環境・エコロジー）
- 安心して…個人情報を管理するので、蓄積データを暗号化する（セキュリティ）
- コストを安く…誰でも保守できるように、保守マニュアルの整備を行い、保守作業自動化のためのツールや仕組みを導入する（運用・保守性）
同じ“いつでも”であっても、通信事業者の携帯電話システムとチケット販売システムであっては実現すべきレベルが大きく異なる。その違いを“具体的な言葉／数値”で表現し、あいまいさを回避することを心がければ、発注者と受注者が描くシステムの完成図が近いものになりやすい。発注者と受注者で同じ認識を共有できれば、システム開発が成功裏に終わる可能性もずっと高くなるのだ。この作業も基本的にユーザー企業側の主導で決定していくべきだが、場合によってはコンサル的な立場で開発ベンダー側に参加してもらい、具体的な数値などについて助言をもらうとよいだろう。
