Skip to main content

English

Japan

イントラネット安定稼動実現に向けたコンサルティング

~システム性能、信頼性、セキュリティ、運用性検討の際の合意形成に向けて~

シニアコンサルタント 佐藤秀之

2007年9月26日(水曜日)

私たちは、ある大手地方銀行のイントラネットの開発・運用を請け負っているA社に対して、イントラネットを安定稼動させるための「処方薬」を提供しました。

商談はA社取締役の“嘆き”から始まりました。それは、「銀行の現行のイントラネットは導入当初より障害が多発している。近々、全面再構築する予定だが、前回と同じ進め方をしては何も変わらない。」というものでした。

私たちは、まず「症状」の深刻さを、過去の全障害を分析することで把握し、その上で「症状」が起きている根本原因(問題を作りこんでいるプロセス)を COBIT(*1)等を活用しながら調査しました。

根本原因は、システム要件定義工程における非機能要件(*2)の検討にありま した。非機能要件が曖昧であったため、実現手段の選択を誤り、「未然防止できたはずの障害」を多く作りこむ結果となっていました(全体の約3割はこれに該当)。

この問題に対する「処方薬」として、私たちは、システム要件定義工程において検討すべき重要な非機能要件(今回の対象は、性能・拡張性、信頼性、セキュリティ、運用)約100項目とそれら要件を実現するためのアーキテクチャー要件(例えば、信頼性要件であれば、二重化方式などのこと)の一覧を作成しました。また、イントラネットの各サービス機能(電子メール、ポータル、認証 などといった単位)における非機能要件の閾値基準を導くための評価方法を定めました。簡単に言うと、例えば、「電子メールサービスの稼働率は何%とすべきか」を決めるための考え方です。

コンサルティング終了後、お客様の取締役からは「これで銀行に対して、システム構成や運用レベルを何故そうすべきなのか論理的に説明することができるようになり、(安定稼動に向けた必要投資の)交渉が円滑化される。将来的には銀行とのSLA(*3)の締結も視野に入れて活用していきたい。」という声を頂きました。

今回の成果は、イントラネットのみならず、業務系システムの非機能要件、アーキテクチャー要件を検討する際にも応用できると考えていますので、システム構成の検討や、検討内容の利害関係者間での合意形成でお困りの場合などは是非お声を掛けていただければと思います。

(*1) COBIT:Control Objectives for Information and related Technology の略。米情報システムコントロール協会(ISACA: Information Systems Audit and Control Association )が提唱するITガバナンスの成熟度を測るフレームワーク。

(*2) 非機能要件:富士通では「性能・拡張性」「信頼性」「セキュリティ」「保守・移植性」「ユーザビリティ」「運用」の分類で定義。

(*3) SLA : Service Level Agreement

【関連サービス】:情報戦略

【関連サービス】:金融