はじめに
Google Cloud のシステム構築案件の中で非機能要件定義を行いました。
インフラの非機能要件定義のベースとして、IPA の非機能要求グレードを使って項目を選定していくことが多いかと思います。その中で、クラウドネイティブな要件を定義するには、少し物足りないと感じることが多くありました。
それもそのはずで、非機能要求グレードは2018年版が最終更新であり、オンプレミス環境を前提とした項目も多く含まれています。
そこで、Google Cloud のベストプラクティス集である Well-Architected Framework を活用し、非機能要求グレードを補完する形で、非機能要件定義書の項目選定を行いました。
本記事では、その際に用いた具体的なアプローチと成果物の一部をご紹介します。
Google Cloud で非機能要求グレードを使って非機能要件定義を行う際の課題
非機能要求グレードとは
非機能要求グレードは、IPA (情報処理推進機構) が公開している、非機能要件を網羅的かつ具体的にするためのフレームワークです。要件の抜け漏れを防ぎ、関係者間の認識を合わせる上で非常に有用なツールです。
しかし、前述の通り、クラウドが主流となった現在のシステム構築においては、いくつかの課題があります。
- 非機能要求グレート策定事業の状況
- 2018年版から更新されておらず、FinOpsやサーバレス、AI/MLといった新しい技術トレンドに関する観点が不足している
- オンプレミス的な要素
- 物理的なハードウェアやデータセンターを前提としたような項目も含まれており、クラウド環境ではそのまま適用しにくい
これらの課題から、非機能要求グレードだけをベースにすると、クラウドのメリットを最大限に引き出すための要件定義が難しいと感じました。
Well-Architected Frameworkの採用
そこで、Google Cloud の Well-Architected Framework を活用しようと思いました。
Well-Architected Framework は、Google Cloud 上で信頼性、安全性、効率性に優れたシステムを設計・運用するためのベストプラクティスを体系的にまとめたものです。以下の5つの柱で構成されています。
- オペレーショナル エクセレンス：クラウド ワークロードを効率的にデプロイ、運用、モニタリング、管理
- セキュリティ、プライバシー、コンプライアンス：クラウド内のデータとワークロードのセキュリティを最大化し、プライバシーを考慮した設計を行い、規制要件と標準に対応
- 信頼性：クラウドで復元性と高可用性を備えたワークロードを設計し、運用
- 費用の最適化：投資のビジネス価値を最大化
- パフォーマンスの最適化：パフォーマンスが最適化されるようにクラウドリソースを設計、調整
この Well-Architected Framework は、まさにクラウドネイティブなシステムにおける非機能要件に活用できるものであり、非機能要求グレードの行間を埋めるための最適なガイドラインになると考えました。
対応フロー
ここからは、実践した具体的な対応付けのフローをステップごとにご紹介します。
Step 1：準備とデータ入力
まず、分析の土台となる情報を収集します。今回は NotebookLM を活用しました。
- ソース1：IPA が公開している「非機能要求グレード2018」の項目一覧
- ソース2：Google Cloud が公開している Well-Architected Framework の各柱に関する公式ドキュメント (PDF を出力)
これらを NotebookLM にソースとして読み込ませ、分析の準備を整えます。各資料はこちらからダウンロード可能です。
Step 2：NotebookLM による一次マッピング
NotebookLM に対し、以下のような指示を出して、Well-Architected Framework の項目を非機能要求グレードの体系にマッピングさせます。
「Well-Architected Frameworkの各項目を、非機能要求グレードの小項目/メトリクスと見立ててください。それらを、非機能要求グレードの大項目と中項目に分類し、各項目の概要と共に表形式で出力してください。」
これにより、Well-Architected Framework の膨大なベストプラクティスが、非機能要求グレードのフォーマットに沿って整理された、分析の叩き台となる対応表が生成されます。
イメージは以下のとおりです。
- 非機能要求グレードの構成
- 大項目 > 中項目 > 小項目 > メトリクス
- 例) 可用性 > 継続性 > 運用スケジュール > 運用時間 (通常)
- Well-Architected Framework の構成
- 柱 > 基本原則 > 項目
- 例) オペレーショナル エクセレンス > CloudOps を使用して運用体制とパフォーマンスを確保する > SLO と SLA を定義する
- この場合、「CloudOps を使用して運用体制とパフォーマンスを確保する > SLO と SLA を定義する」を非機能要求グレードの大項目と中項目の配下の適したところに小項目とメトリクスとしてマッピングする形になります。
Step 3：NotebookLM による重複の分析と分類
次に、生成された対応表をインプットさせ、非機能要求グレードの既存の項目との重複の有無を分析させます。ここも NotebookLM を活用しました。
「生成した対応表の各項目について、既存の非機能要求グレードの小項目/メトリクスと意味が重複しているか否かを判断し、結果を追記してください。」
NotebookLM は、ソースとして読み込ませた両ドキュメントの内容を比較し、Well-Architected Framework の各項目が、従来の非機能要求グレードのどの項目に相当するか、あるいはどの項目にも当てはまらない新しい概念 (＝重複なし) であるかを判定してくれます。このAIによる客観的な分類が、後の要件定義の精度を高める上で非常に役立ちました。
Step 4：出力結果の確認と要件定義書へのマージ
最後に、分類結果をもとに実際の非機能要件定義書に反映させます。出力結果に誤りがある場合もあるため、ここは人の目で判断し、本当に追加すべきかを最終チェックします。
- 「重複なし」項目：プロジェクトの特性を考慮し、必要と判断した項目を、非機能要件定義書の新たな項目として追加します
- 「重複あり」項目：項目追加の必要あありませんが、必要に応じて Well-Architected Framework の記述を参考に、メトリクスや考慮事項をよりクラウドに即した内容で更新します
このプロセスを経ることで、非機能要求グレードの伝統的なフレームワークにクラウドネイティブな観点を取り込んで非機能要件定義書の項目を作成することができます。
成果物のイメージ
Step 3 で作成した対応表です。この後、ここから項目の選定を行います。
重複なしとなった項目の中には、コンプライアンスのモニタリング、CI/CDパイプライン導入やパイプライン内での認証、サーバーレスアーキテクチャの実装、セキュリティ境界の設定、ゼロトラスト実装、FinOps 実装等がありました。
おわりに
今回は、非機能要求グレードをベースに、Google Cloud の Well-Architected Framework を組み合わせて非機能要件定義書にクラウドネイティブな項目を追加するアプローチをご紹介しました。
この方法を取ることで、従来の非機能要求グレードの項目も活かしながら以下のメリットを享受できます。
- クラウドネイティブな要件の抜け漏れを防げる
- 顧客やステークホルダーに対して、クラウドを採用するメリットを具体的に説明できる
- 従来の非機能要求グレードのフレームワークに慣れたメンバーにも理解しやすい形で新しい概念を導入できる
Google Cloud 上で非機能要件定義を担当される方の参考になれば幸いです。