AWS JAPAN APN ブログ

AWS ファンデーショナルテクニカルレビュー (FTR) for Service Offerings のチェックリスト解説

AWS ファンデーショナルテクニカルレビュー (FTR) for Service Offerings は、AWS パートナーがお客様の AWS 利用を支援するために提供するサービスオファリング (例: コンサルティングサービス、プロフェッショナルサービス、マネージドサービス) を、プロジェクトの要件定義、セキュリティ、運用プロセスといった、あらかじめ定義されている要件に従って検証するパートナープログラムです。すべての要件を満たしてレビューを通過すると、AWS パートナーソリューションファインダー (PSF) と AWS 社内のセールスディスカバリーツールに掲載されます。それにより、お客様や AWS チームに対する可視性を向上することができます。

従来の FTR はソフトウェアオファリングのみが対象でしたが、2023 年からサービスオファリングに対するレビューも開始されています。FTR for Service Offerings の概要は、「AWS ファンデーショナルテクニカルレビューの対象をサービスオファリングにまで拡大」でご案内しています。ソフトウェアオファリングの FTR については、本ブログ最後のリンクをご参照ください。この記事では、FTR for Service Offerings でチェックされるポイントをご紹介します。

FTR for Service Offerings の要件

FTR for Service Offerings は、サービスパスでセレクトティア以上となっている AWS パートナーが対象です。FTR for Service Offerings で満たすべき要件は、チェックリストに定義されています。チェックリストへのリンクは、AWS パートナーセントラルの FTR for Service Offerings ガイド (ログインが必要) よりご確認ください。

チェックリストは複数のカテゴリから構成され、各カテゴリに 1 つ以上のチェック項目が含まれます。2024 年 4 月 24 日時点の最新版チェックリスト (March 2023 – 1.0) のカテゴリ一覧は以下の通りです。

  1. Service Offering Definition – サービスオファリングの定義
  2. Project Plan Template – プロジェクト計画テンプレート
  3. Technical Expertise – 技術的専門知識
  4. Risk Mitigation – リスクの緩和
  5. Security – セキュリティ
  6. SaaS Components – SaaS コンポーネント
  7. Customer Feedback – お客様のフィードバック

レビューを通過するためには、全ての項目に準拠する必要があります。なお、SaaS Components に関しては、該当する SaaS コンポーネントがない場合、レビュー対象からは外れます。

FTR for Service Offerings の申請方法

申請にあたって必要なドキュメントは、回答を記載したセルフアセスメントシートとプロジェクト計画テンプレートです。セルフアセスメントシートは、チェックリストの要件に準拠していることを示すために、AWS パートナーがセルフアセスメントを行なって記入する Excel 形式のドキュメントです。記載が不十分な場合はレビューを進めることができませんのでご注意ください。プロジェクト計画テンプレートについては、次のセクションで説明する「Project Plan Template – プロジェクト計画テンプレート」をご覧ください。

セルフアセスメントシートは英語で記入いただく必要があります。プロジェクト計画テンプレートなどの添付文書は、日本語で構いません。

申請に必要なドキュメントの準備を終えたら、パートナーセントラルからレビューの申請を行います。レビューの流れについては、前述の FTR for Service Offerings ガイドで詳しく知ることができます。

FTR for Service Offerings で検証される内容

※ 以下は March 2023 – 1.0 のバージョンを元にした解説です。チェックリストは不定期で更新されるため、レビューの際は必ず最新版のチェックリストをご確認ください。

1. Service Offering Definition – サービスオファリングの定義

FTR レビューを申請するサービスオファリングの内容を記載した、お客様向けに公開しているオファリングページの URL を提示してください。

オファリングページには、サービス固有の強みや具体的な利点について記載することをお勧めします。より詳細な情報を提供することにより、お客様は該当サービスが自社のニーズに合っているかを確かめることができ、具体的なイメージを持って導入の意思決定を行うことができます。確認ポイントとして、オファリングページでは下記の点が説明されている必要があります。

  • サービスの詳細とユースケース、AWS に関わる価値提案について (必要に応じてアーキテクチャ図を含めます)
  • ターゲットとする顧客セグメント
  • 顧客エンゲージメントとサービス提供の仕組み

セルフアセスメントシートに、公開ページのどの部分が上記要件に該当するか記載いただくことで、レビューをよりスムーズに進めることができます。

また、AWS パートナーセントラルに作成したオファリングの Offering URL / Offering Description フィールドには、公開ページの URL とオファリングの説明を適切に設定してください。これらのフィールドは、PSF に掲載する際に使用されます。

2. Project Plan Template – プロジェクト計画テンプレート

エンドツーエンドのエンゲージメントプロセス (例: スコープの定義・実装・デリバリー・完了) を含むプロジェクト計画を定義することは、お客様の期待値と認識を合わせるために重要です。プロジェクトを実行するための明確なフレームワークを提供することにより、全てのチームメンバーがプロジェクトの目的とゴールを把握できるようになります。

本項目は、セルフアセスメントシートへの記載ではなく、独立した文書の形式で提示する必要があります。プロジェクト計画テンプレートには、下記の要点すべてを含めてください。

  • プロジェクトの作業範囲、成果物、想定されるタイムライン
  • 各フェーズにおける担当者の役割と責任
  • お客様への引き継ぎプロセス (プロジェクトの完了条件)

プロジェクト計画テンプレートは、パートナーがお客様にどのようにアプローチするかといった一般的な内容ではなく、個々のサービスオファリングのレベルで作成されていることがポイントになります。標準化したテンプレートを用いることで、高品質で一貫したサービスを提供できるようになります。テンプレートの例については、AWS パートナーセントラルのキャリブレーションガイド (英語) をご覧ください。

3. Technical Expertise – 技術的専門知識

お客様を効果的にサポートするためには、十分なトレーニングを受けた人材を確保するプロセスが必要になります。サービスオファリングの提供に必要となる AWS の専門知識やドメイン知識、担当者に求められる認定資格などを明確にすることがポイントです。次に、これらのスキルを身につけるためのトレーニング計画を策定します。標準化されたプロセスでスキルギャップの分析を行うことで、チームメンバーのスキルを把握し、必要に応じて育成の支援をすることができます。必要となる技術的専門知識、資格、トレーニング計画の 3 点すべてを記載してください。

AWS パートナー向けに様々なトレーニングが提供されていますので、「初級者から上級者まで！AWS パートナー向け特別トレーニングの活用方法」もぜひご覧ください。

4. Risk Mitigation – リスクの緩和

サービスオファリングに関連する潜在的なリスクを特定、軽減するためのプロセスを定義します。標準化したプロセスを確立することで、リスクを最小限に抑えて、お客様への影響を低減することができます。コンプライアンス、技術的な制約、サードパーティーに依存するリソースなど、発生しうるリスクをどのように特定し、対策を講じているかを記載してください。

AWS 上のワークロードに関するレビューには、AWS Well-Architected フレームワークを利用することをお勧めします。AWS Well-Architected フレームワークでは、6 つの柱 (運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、サステナビリティ) に基づいて、改善すべき点を特定する手段を提供しています。NIST、PCI DSS、HIPAA など、何らかのコンプライアンス要件があるワークロードについては、関連するホワイトペーパーを参照するようにしてください。

5. Security – セキュリティ

AWS アカウントを適切で安全に管理するためには、標準的な推奨事項を定めることが重要になります。AWS パートナーは、信頼されるアドバイザーとして、IAM セキュリティのベストプラクティスについてお客様をガイドし、実装の支援を行うことが期待されます。このカテゴリには、「安全な AWS アカウントのガバナンス」と「AWS アカウントへのセキュアなアクセス」の 2 つの項目が含まれています。

最初に「安全な AWS アカウントのガバナンス」についてです。お客様とのエンゲージメントの全てに AWS アカウントの作成が求められるわけではありませんが、お客様が支援を必要とする場合に備えて、アカウントの作成と保護に関する標準プロセスを用意します。基本的なステップとして、標準プロセスには以下の 3 点を含めます。

  • AWS アカウントの連絡先を適切に設定する
  • AWS アカウントのルートユーザーで多要素認証 (MFA) を有効化する
  • 保護された Amazon S3 バケットに AWS CloudTrail ログを配信する

この他にも、セキュリティのベストプラクティスには様々なものがありますので、アカウント保護のガイダンスも参考にしてください。定義したプロセスの説明、もしくは SOP (標準手順作業書) を提示する必要があります。

次に「AWS アカウントへのセキュアなアクセス」です。AWS IAM ユーザーなど長期的なセキュリティ認証情報ではなく、IAM ロールといった一時的な認証情報を使用して、お客様の AWS アカウントにアクセスするプロセスを定義します。実際に作業する担当者が困らないように、具体的な手順が定められていることがポイントになります。AWS マネジメントコンソールへのアクセスと、AWS CLI などを用いたプログラムによるアクセスの両方について、定義したプロセスを記載してください。

6. SaaS Components – SaaS コンポーネント

サービスオファリングの一部として、AWS パートナーが Software as a Service (SaaS) デリバリーモデルで運用しているコンポーネントは、ソフトウェアオファリングの FTR を通過している必要があります。該当する SaaS コンポーネントがない場合は、その旨を明記してください。Not Applicable (該当なし) として、本項目の要件を満たすことができます。

7. Customer Feedback – お客様のフィードバック

お客様からのフィードバックを収集するメカニズムを定義します。得られたフィードバックを社内で共有して、サービスオファリングの改善につなげる体制を整えることがポイントです。1 回限りのフィードバックの収集ではなく、プロジェクトのマイルストーン毎など、一定の区切りごとに継続的に行うことも重要になります。お客様のフィードバックを得るためのチャネルや方法、対象項目について記載してください。

まとめ

FTR を取得する本質的な目的は、お客様のニーズをより適切に満たせるように、レビューを通してサービスオファリングを改善することです。AWS パートナーは、チェックリストの内容に沿って、現在のサービス提供内容をベストプラクティスと比較することで、そのギャップを把握することができます。ギャップが見つかった場合は、アクションプランを策定して、改善への取り組みを始めることができます。本記事でご紹介した FTR for Service Offerings の推奨事項が、継続的な改善サイクルを始めるための、最初のステップになれば幸いです。

関連ブログ記事：