変化に対応するデザイン

デザイン作業の一環として、ソリューションの要素について、特定の状況下で頻繁または緊急に変更が必要となる要素を特定します。 このタイプの要素はベストプラクティスとして、多くの場合、従来のソフトウェア開発ライフサイクルの外でメンテナンスされていました。 要素を特定すれば、チームでは、迅速かつコスト効率の高い方法で確実に変更が適用されるように、アプローチをデザインして利用できます。

たとえば、中小企業向けローンのリクエストを収集および処理するアプリケーションについて考えてみましょう。 このアプリケーションに、頻繁または緊急に変更が発生する要素と、それほど頻繁でない要素が含まれていると考えられます。

チームおよびステークホルダーとともに、アプリケーションの要素のうち、頻繁または緊急に変更が必要となる要素を特定します。

変更が必要となる要素を特定するために、以下の点を検討します。

• 変更が頻繁に生じたり緊急に変更が必要となったりする、ビジネスベースのデシジョンポイントがプロセスに存在するかどうか。 たとえば、承認や価格設定を実行する自動化されたルールなど。
• 特定の事項で、頻繁に変更が生じる、または緊急の変更が必要となっていないか。 たとえば、説明や価格などの製品詳細など。  
• コンテンツの変更が頻繁または緊急に必要となる画面がないか。 コンテンツをハードコードするのではなく、データ駆動型にできないか。 たとえば、アンケート式の質問や、ベストプラクティスのチェックリストなど。

アプリケーション開発を進めるにつれて、新しい要件やデザインごとに、変更の可能性がないかを検討します。

チームと連携し、必要に応じてアプリケーションの領域を頻繁または緊急に変更できるようにする、包括的なアプローチを策定します。

次の画像で+アイコンをクリックすると、多くの場合頻繁または緊急な変更に対応するために利用される技術的なデザインアプローチの説明が表示されます。 

頻繁または緊急の変更を実現するには、技術的なデザインに加えて、以下のステップが不可欠です。

1. デシジョンテーブルなどの、アプリケーションで使用されている主要なビジネスモデルまたはデシジョンモデルについて、対象分野のエキスパートを啓蒙する。
2. 自動テストを活用することで、信頼性を高めてリスクを軽減しながら、変更の検証にかかる時間を短縮する。
3. 変更の適用方法と検証方法について、詳細を検討する。
   1. 本番環境に直接変更を適用する場合があります。 
   2. 本番環境に変更を適用する前に、開発環境やQA環境で変更を適用して検証することが必要となる場合もあります。
4. アプローチの承認を取得するために、組織内の該当するシステム変更責任者やリリース管理責任者を関与させます。

次の問題に答えて、理解度をチェックしましょう。