非機能要件の中の拡張性の説明です。
拡張性には、インフラの拡張性とアプリケーションの拡張性の２つの観点があります。本番稼働後に、どれだけ容易に拡張できる作りにしておくかという要件です。
１．インフラの拡張性
インフラの拡張性では、サーバーごとにどのくらいの期間でスケールアウトやスケールアップをできるようにするかを合意します。
一般的には、WebAPサーバーはスケールアウト、DBサーバーはスケールアップでリソースを増強します。
いずれの場合でも、リソース増強の判断をしてからどのくらいの期間で増強が完了するのか、作業実施時のサービス提供時間はどれくらいかを合意します。
上記のような期間でベンダーと合意をした場合、基盤のテストの中でスケールアウトを行い、１日で作業が完了するかを確認します。もちろん事前に手順書やスクリプトも作成しておくので、本番でスケールアウトが発生した場合には、それらをブラッシュアップして使用することも想定します。
またスケールアップの場合、増設するCPUやメモリー、DISKの上限があるので、それらも明らかにしておきます。
DBサーバーは基本的にはスケールアップでリソース増強しますが、リソースには上限があるため、一定以上のリソース増強の場合にはスケールアウトにする必要があります。DBサーバーのスケールアウトは製品によっては対応できない場合もあるので、将来的にスケールアウトを想定するのであれば、それに対応した製品にする必要があります。
２．アプリケーションの拡張性
アプリケーションの拡張性は非機能要件の中で、保守性と１、２位を争うほど厄介な要件です。
ありがちなのは「将来、M&Aで同業他社を吸収した場合でも、速やかに同業他社の要件を追加できるようにする」とか「将来、テナントのPOSを利用しても買い上げ分析ができるようにしておく」といった将来のビジネスモデルの変更の可能性を拡張性要件に盛り込むケースです。
気持ちは分かりますが、システムは魔法の箱ではないので、このような漠然とした拡張性の要件は実現できません。
今までも、変化の激しいビジネス環境に、速やかにシステム対応できるようにするために、オブジェクト指向だとか、SOA、最近だとマイクロサービスといったような考えが出てきていますが、いずれもビジネスモデルの変化に対応できるような魔法の手法ではありません。
基本的には大部分のアプリケーションは、データベースが要となり、データベースの変更がシステムを変更するスピードの足かせになります。
端的に言えば、主要なテーブルのKeyが変わらなければ、比較的に速やかに対応しやすいですが、テーブルのKeyが変わるような変更は、かなりの費用と時間をかけることになります。
またスモールスタートをして、徐々に機能を増やして大きくしていくような考えも、はじめから拡張後のシステムをイメージして作っておかなければ、簡単には拡張は出来ません。
アプリケーションの拡張性は、拡張後の要件が明確で、すぐにでも拡張後のアプリケーションを構築できるくらいでなければ、実現は困難であることが多いので、その辺りを過剰に期待せずに要件定義を実施する必要があります。
【振り返り】
拡張性の説明は以上で終了となります。次回は運用保守の説明をしていきたいと思います。
①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ／アクセシビリティ
⑧システム環境
