hero_picture
Cover Image for AWS Service Delivery Program(SDP) 認定はすごいという雑記

AWS Service Delivery Program(SDP) 認定はすごいという雑記

2023/09/06

クラウド事業部の原口です。

先日(2023年8月25日)、弊社は AWS Graviton におけるサービスデリバリープログラム(SDP)認定を取得いたしました。

日本初!AWS Graviton SDP の認定を取得しました

このSDP取得のハードルは結構高いものでしたが、いったいどのような過程を経て取得へ至ったのか。AWSパートナー企業選定の一つの指針となるかと思いますので、そのあたりをご紹介させていただければと思います。

そもそもSDPとは何か

SDP (Service Delivery Program / サービスデリバリープログラム)とは、特定のAWSのサービスをお客様に提供する上で深い技術的知識、経験、および実際に成功を収めている AWS パートナーをAWSが認定するプログラムとなっています。

AWSのサービスは現在200以上も存在しているので、当然AWSパートナーによって得意なサービスが異なります。ざっくばらんに言うとSDPは「このAWSパートナーは特にこのサービスが得意です」とAWSが認定してくれるプログラムです。

申請の流れ

  • AWS パートナーセレクトティア以上のパートナーとして認定される
  • AWSサービスデリバリー認定を選択し、各認定に関連付けられている要件を満たす
  • 申請する

SDP認定は認定サービスの知識「のみ」を審査しているわけでは無い!

AWSパートナーの弊社としては是非ともSDPを取得し、対外的なアピールやケイパビリティを強めたいと考えます。
そのため弊社でもすぐに「SDP取得しよう!」という機運が高まりました。

が!しかし!!甘かった!!!

実際のSDP要件を見るとそんな半端な気持ちで取れるものでは無い事がわかります。
SDP取得のための具体的な作業だけで見ると結果的に弊社は3,4ヶ月の期間で取得できましたが、実際に「取得挑戦しよう」と思えるまでになるには2年近くの時間がかかってしまいました。

「顧客からの高度な要求レベルの検証」「実際にAWS パートナーがそのサービスを成功させる支援を行っている実績があるか」「ベストプラクティスに従ってお客様独自のユースケースをサポートしているか」など、いくつかの要素について厳しい審査があります。

これらの要素への対応も「してまーす!」みたいな回答ではダメだと思われましたので、シーズではそれぞれの要素について以下のような体系だてた回答を心がけました。このようにしなさいというわけではなく、シーズではこのように回答したという例となります。

1・シーズは〇〇(例えば暗号化)についてこのようなポリシーでやっているという事SOP文章で説明
2・その考えの元、この実績ではこのように実装している
3・実装しているエビデンスとして資料を添付

詳細な要件などの情報はお出しできないのですがAWSの特定サービスに対する知識だけではなく、AWSパートナー企業としての組織的な能力こそが測られている、と感じました。

実際のところ、弊社の場合はSDP取得を通じて、AWSベストプラクティスへの深い理解、組織改善、標準化へのヒントや気づきとなった部分も多くありました。

SDP概要だけを見ると「特定のAWSサービスだけに特化しているのねー」という風に見えるかもしれませんが、AWSを使ったシステム構築における全般的なリテラシーを有している企業である事も同時に審査されています。例えばCloudFrontのSDPを取得している企業がEC2やRDSに知見が無いわけでは決して無く、高いレベルでのAWSでのサービス提供を行なってる上で、特にCloudFrontへの深い知見を持っている、と捉えるのが正しい認識ではないかと思います。

SDP取得企業はAWS公式サイトにて公開されていますので、AWSパートナーを選ぶ際の一つの指針として「(いずれのサービスであったとしても)何らかのSDPを取得しているか」というのは非常に信頼度の高いものになっているのではないかと思います。

パートナーのハイライトに「AWS サービス認定」があるAWSパートナーはSDPを取得しています。
パートナーのハイライトに「AWS サービス認定」があるAWSパートナーはSDPを取得しています。

何が言いたいかと言うと、SDP認定はすごい、という事です。
いや、取得できたから言うわけでは無いですが

取得を決意するまでの2年間

SDPを取得できるだろう!と思えるまでに何をしてきたか。

要件を確認した際に一番のハードルと思ったのは、全ての要件を満たす実績の存在です。それぞれの項目についての弊社の技術的知識や能力に不足は無いと考えていましたが、それらを全て含む実績の存在がなければ達成できないなー、うん、そういう実績が出来たらSDPに挑戦しよう!と半ば諦めた考えでおりました。

ただ、このSDP要件は頭の片隅には常に残っていて、「なぜこの案件ではAWSベストプラクティスを採用できなかったのか」といった事を深く考えるようになりました。このような思考は(今にして思うと)実際の提案や打ち合わせの場でも出ていたように思います。具体的には、「こうあればベストだけど、こういった原因で、この現実解となっている」という事をお客様とディスカッションし、認識を合わせていく事で自然とAWSベストプラクティスがお客様の中に浸透していったように思います。

徐々にAWSベストプラクティスがお客様との共通認識となっていく事で、SDP要件に合う案件が来るのを待つのではなく、AWSパートナーとしてお客様との信頼関係を築きリーダーシップを発揮する事で、要件に合った案件になっていくのだ、という事に気づきました。

そのようなAWSパートナーとしてのステージに上がるまでにかかった期間が2年だったのかなと思います。

SDPのチェックリスト要件は年2回くらいのサイクルで見直されるようなので、取得後も注視していきたいな、と思っています。

まとめ

  • シーズはAWS Graviton SDPを取得
  • SDPは取得ハードルの高い認定なので、SDP取得したAWSパートナーは認定サービスだけではなくAWSを使ったシステム構築において全般的に高いリテラシーを有している
  • SDP要件に合う案件は、待っていれば来るものではなく、AWSパートナーとしてのあるべき姿を体現する事で、そのような案件になっていく

これからも精進します。