IPAの非機能要求グレードを活用したAWSの要件定義支援

AWSと共通基盤の責任分担、開発チームとの調整事項を整理。IPAの非機能要求グレードを活用し、設計の前提と継続検討事項をまとめた非機能・運用要件定義書を作成しました。

AWSと既存の共通基盤を利用するWebシステムの非機能要件定義を支援しました。IPAの非機能要求グレードを活用し、クラウドの責任分担や開発チームとの調整事項を整理。後工程で参照できるよう、設計の前提と継続して検討する事項を非機能・運用要件定義書にまとめました。

対象： 既存の共通基盤を利用するAWS上のWebシステム

支援領域： 非機能要件の整理、開発チーム・基盤担当との調整、合意形成に向けた資料作成、非機能・運用要件定義書の作成

背景と課題

本案件では、IPAの非機能要求グレードを用いて検討を進める方針が決まっていました。ただし、物理設備やハードウェアに関する項目を、そのままAWS上のシステムへ適用することはできません。AWSが管理する範囲、既存の共通基盤が提供する機能、今回のシステム側で決める事項を整理する必要がありました。

また、性能、認証、外部連携、リリース方式は、インフラだけでは決められません。業務やアプリケーションの前提を開発チームとそろえ、複数の関係者が判断できる材料を用意する必要がありました。

Markshipは、検討項目の精査から提案シートの作成、業務・開発・基盤担当との調整、定義書への反映までを支援しました。各項目の採否理由と確認先を整理し、関係者が要求水準や対応方針を判断できる形に具体化しました。

IPAの非機能要求グレードは、検討項目と要求レベルを使い、発注者と開発者の認識をそろえるためのツールです。モデルシステムを選び、重要項目から要求レベルを確認していきます。

IPAによる重要項目のレベル決定の例。目標復旧時間を12時間以内から6時間以内へ、要求に応じて調整している。

出典：IPA「非機能要求グレード紹介ページ」掲載図「2.重要項目のレベル決定」（© IPA）。

本案件でも重要項目を起点に、システムに必要な検討項目を精査しました。標準の項目やレベルをそのまま採用するのではなく、AWSと既存基盤の仕様、業務・開発側の要求に照らして検討しました。

AWS・共通基盤・今回のシステムの前提を確認し、Markshipが不足・調整事項を洗い出して担当と方針をすり合わせ、要件へ反映する図

AWSの管理範囲と利用側の責任は、利用サービスによって異なります。ハードウェア関連の項目はAWSの提供範囲を踏まえて扱いを整理し、冗長化、バックアップ、復旧方針など、システムとして必要な事項は個別に検討しました。

既存の共通基盤についても、提供機能と利用条件、基盤担当と利用側の作業を確認しました。パッチ適用やログ管理など、複数の範囲に関わる事項は担当と対応方針をすり合わせました。標準の重要項目に含まれなくても、構成・運用に影響するパッチ適用ポリシーなどは検討対象に加えています。

重要項目を外す場合も、項目を追加する場合も理由を記載しました。関係者が、何を検討対象とし、どの前提で判断したのかを確認できるようにするためです。

認証方式、通知・メール送信、コンテンツ配信、バッチ実行方式などは、開発側の検討内容とAWS構成への影響を整理しました。開発チームの要望と共通基盤の提供範囲を照合し、接続方法やリリース時の承認など、個別に協議すべき事項も洗い出しています。

性能についても、応答時間の目標だけでは構成や費用を判断できません。同時アクセス数やデータ量など、業務・開発側に確認する前提を明確にしました。

検討対象を整理し、提案シートの作成・更新と業務担当・開発チーム・共通基盤担当への確認・協議を往復して、合意した内容を定義書へ反映する流れ

要件シートには、関係者が検討できる提案ベースの内容を先に用意しました。業務担当者への確認、開発チームとの仕様調整、共通基盤の制約確認を進め、その結果を提案内容に反映しました。

協議は可用性、性能・拡張性、運用・保守性、セキュリティのテーマに分けて計画し、確認先と回答期限を整理しました。シートの記入完了を待たず、資料の更新と確認・合意形成を並行させる段取りとしました。

残った未決事項は、構成・費用・運用体制への影響を基準に分類しました。要件定義で決める内容と設計で詰める内容を分け、分類の理由も添えています。

判断の区分	項目の例	判断の理由
要件定義で確定する	サービス提供時間、同時アクセス数	構成・費用・運用体制の前提となるため
基本方針を先に決める	パッチ適用、リリース方針	対応や承認の考え方をそろえ、詳細手順は設計で具体化するため
設計で具体化する	診断ツール、監視項目の詳細	技術構成の確定後に具体化するため