業務改革に必要な非機能要件の取り込み


業務改革を目的としたシステムの再構築を行う際に絶対に忘れてはならないのが、非機能要件要件定義の段階から十分精査して取り込むことです。非機能要件とは、システムに搭載すべき業務フローや仕様など、システム開発に必要な機能要求以外のその他すべての要件を指します。

可用性や、性能、拡張性、保守運用を考慮した機能についての要件は、ユーザからは明確に要求できず、システム部門が主体となって検討すべき項目が多いです。中でも、BCP(事業継続計画)や、セキュリティポリシーに基づいた要件の再確認は重要です。その理由は、近年のウイルス感染症に対するテレワークへの対応や、巧妙化するサイバー攻撃などによって、従来のシステムを開発した時とは環境が大きく違っているためです。レガシーシステムの多くは、社内の閉ざされたネットワーク環境で稼働する業務が多いのですが、再構築後に望まれるシステムの多くは、クラウド等を使ったどこからでもアクセス可能な環境が主流となってきています。こうなると、以前の常識では通用しない場合も多々あり、再構築に使用される環境であらたなリスク分析を行い、その対応策を検討し、要求事項に盛り込む必要があります。

たとえば、メインフレーム環境で稼働していたCOBOLプログラムを、JavaのWEBシステムで再構築する場合、単純に言語コンバージョンによってリライトするだけでは、そもそもCOBOLプログラムでは、SQLインジェクション攻撃に対応するためのコーデイングがされていません。この場合、WEB環境向けのセキュリティ対策は、別途追加する必要があります。そして更に、セキュリティインシデント情報を常に入手して運用開始後も対応できる仕組みを作ることが、レガシーシステムの弱点を克服する第一歩となります。つまり、セキュリティは、バックアップなどの事業継続対応策と同様に、保守・運用と連動して考えることがポイントです。リスク分析と対応策の検討は、要件定義の時だけでなく、運用が開始され業務システムの稼働が継続されていく中でも、適宜行われるようにリスクマネジメントが必要です。

取り込むべき非機能要求には、移行のしやすさや、エコロジーなど社会的な環境変化に対応するための要求がありますが、いずれにせよ、環境は目まぐるしく大きく変化していきます。たとえ、要件定義の時に盛り込めなくても、運用が開始されてからでも、柔軟に変化に対応できるシステムの仕組み作りがカギとなりそうです。


非機能要件の取り込みは、運用開始後にも対応できる仕組みが必要


要件定義, セキュリティ, 保守・運用