AWS の FTR 認定を取得しました… が、 FTR ってなんだろう？ AWS のなかのひとに訊いてみた。
どうも、株式会社デジタルキューブグループ 広報のタカバシです。
デジタルキューブの3つのサービス「Amimoto」「Shifter」「FinanScope」はいずれ もAWS上で稼働しています。AWS には FTR（Foundational Technical Review）というセキュリティ、信頼性、運用に関するリスクを低減するためにレビューをしてもらえる仕組みがあり、3つのサービスすべてがその認定を得ています。
…すっきり理解できましたでしょうか？
この流れ、以前書いた「AWS ってどんなものかご存知ですか？」と同じ感じですね。ということで、FTR とはどんなものなのか、認定されるとどんなメリットがあるのか、AWS の方に教えていただきました。
今回、インタビューをさせていただいたのは Amazon Web Services (AWS) のパートナーソリューションアーキテクト・櫻谷 広人さんです。
パートナーソリューションアーキテクト
櫻谷 広人（さくらや ひろと）さん
FTR について教えてください
── いきなりですが、FTR について教えてください。
FTR とは Foundational Technical Review の略称で、AWS のパートナーが提供するソリューションに対して行う技術認定プログラムです。FTR は特にパートナー企業が作成した AWS ベースのソリューションの品質とセキュリティを評価し、AWS のベストプラクティスに準拠していることを確認するためのものです。
── ベストプラクティス…
はい、FTR はあくまでパートナーの認定プログラムです。ある基準があって、そこまで満たせていれば AWS から認定が与えられるというものです。その基準になっている AWS Well-Architected フレームワークというものがあり、FTR はそのサブセットみたいな位置付けです。
── ウェルアーキテクテッド…
AWS Well-Architected フレームワークとは、 AWS のソリューションアーキテクトが、多くのお客様との経験を通じて共通の問題点を洗い出し、それを解決するための方法論を「運用する際のベストプラクティス」としてまとめて提供しているものです。
ソリューションアーキテクト
顧客やパートナーの技術的ニーズに対応するためのシステムやサービスの設計を支援する専門職。顧客や開発チームとコミュニケーションを図りながら「要件定義と分析」「システム設計」「パフォーマンス監視と最適化」「技術革新の推進」などに関するサポートを行います。
この AWS Well-Architected フレームワークには、優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性の6つの柱があります。エンタープライズのお客様だけでなく、スタートアップから大企業まで、どのような規模の組織にも適用可能です。
── AWS を使っているのであれば、AWS Well-Architected フレームワークに従うことでメリットがあると、そのためのガイドラインだと理解しました。となると、FTR はどういったポジションになるのでしょうか？
FTR に関しては AWS パートナー限定のプログラムになっています。パートナーが AWS 上に作ったソリューションをより良いものにしていき、市場に出したり、共同販売をしていったりするために AWS の認定を与えてプロモーションしていこう、というようなところから始まったものです。
── AWS としてレビューをすることで、パートナーのサービスに信頼性を付加できるし、御社としてもいろんな方にオススメしやすいものになるということですね。
そうですね。目的は2つあります。1つは対外的なプロモーションとして、ISO とか SOC とかと同じような形で、パートナーがアピールできるようなものにする、というものです。
ISO
国際標準化機構（International Organization for Standardization、ISO）が定める各種の国際標準（ISO規格）に基づいて、企業や組織がその基準を満たしていることを証明する認証のことです。ISOは、製品やサービス、システムの品質、安全性、効率性を確保するための国際的に認められた規格を提供しています。
SOC
主にアメリカの公認会計士協会（AICPA）が定めるサービス組織向けの監査基準です。SOCレポートは、サービス組織が顧客に提供するサービスの運用におけるリスク管理と内部統制の有効性を評価するために使用されます。
もう1つの目的は、AWS Well-Architected フレームワークと同じように、純粋にパートナー様のソリューションを良くしようというものです。それには基準があった方がやりやすいだろうというところで、Foundational Technical Review（基礎的な技術レビュー）という名前の通り、最低限ここだけはやらなきゃいけないですよというところを AWS がまとめて、お客様に「まずここから取り組みましょう」という形で提案しやすい、適用しやすいものになっています。
FTR 認定の第一歩は社内調整から？
── 実は弊社のエンジニアに「FTR 認定を受けることに関して、面倒くささとか煩しさみたいなものはなかった？」って聞いてみたんですが、「基本的にはガイドラインがしっかりとしていて、独特のルールみたいなものもないし、導入しやすかった」と話をしていました。
ありがとうございます。ただ、それは稀なケースかもしれません。よくやってくださっているパートナーのケースかもしれません。反発まではいかないですけど、フィードバックいただくことも少なくはないので…
── 「ここまでハードルを上げなくてもいいんじゃないか？」みたいなフィードバックですか？
そういうのもありますね。FTR に含まれる要件って、ほとんどがセキュリティに関するものになるのですが、やはりセキュリティとなると、そこまでは必要ないんじゃないかと判断されるお客様だと、コストが気になるということを言われることもあります。
あとは、 FTR の認定を取りたいと起案したのが、対外的なマーケットに対してアピールをしたいマーケティングの部門だと、開発陣はタスク増やさないでほしいとか… 部門間のモチベーションの違いがあると感じることもあります。
── FTR 認定を受けようとするのは、どのくらいの規模の企業が多いですか？
満遍なくですね。本当に小規模なお客様もいれば、スタートアップ、エンタープライズから、 最近だと、いわゆる ISV のような会社だけじゃなくて、SI と呼ばれるような大手の、SI メインでやってるような会社さんが持ってるソフトウェアソリューションでFTR認定を目指したいというご依頼もありますね。
ISV
Independent Software Vendor ＝ 独立系ソフトウェアベンダー。ハードウェアメーカーやシステムインテグレータとは独立して、自社で開発したソフトウェア製品やサービスを市場に提供する企業のことです。
SI
システムインテグレータ。SI 企業は、異なる技術やソフトウェア、ハードウェアを組み合わせて、一つの機能的なシステムを構築し、クライアントのビジネスニーズに合わせてカスタマイズする役割を担います。
── 大手企業の方が FTR 認定はすんなり取得される感じですか？
お客様の規模での違いはそんなになく、大企業でも大変苦労されることも多いです。 FTR の要件は技術的なところだけではなくて、組織の運用体制のような部分も入っているんです。大きな組織になればなるほど、その運用の部分がなかなか変えづらい、他の部門との連携が必要ってなると苦労されるようです。あとは、すでに完成しているソフトウェアで多くのユーザーがいるとなると、メンテナンス期間を設けたり、アーキテクチャを変えたりするのも、調整が大変になるのだと思われます。
── では、FTR を導入しようとしてわかった意外と躓きがちなポイントは運用体制になりますか？
そうですね。運用体制が1番ですね。例えば IAM の運用や、マルチアカウントの管理で躓くお客様もいらっしゃいます。
IAM
Identity and Access Management。個人やサービスが組織内の情報システムにアクセスする際の身元確認とアクセス権限の管理を行うシステムです。IAM は組織の情報セキュリティを保護し、適切なユーザーが必要な情報やリソースにのみアクセスできるように制御するための重要なツールです。
それこそ大手企業だとたくさんのアカウント持っていて… 例えば、IdP の権限などは、プロダクトを開発した部門ではなくて、情報システム部門が管理していることも多いので、その部分の変更が必要になるとか… 起案したチームだけで解決できない課題で苦労されることが多いかな、という印象です。
IdP
Identity Provider。個人やサービスのデジタルアイデンティティを作成、管理し、認証情報を他のサービス（サービスプロバイダー）に提供する役割を担います。
── FTR 認定を受けようと提案するのは、これまでだとマーケティング部門が多い印象ですか？
はい、マーケティング部門が多いと思います。 プロダクトのプロモーション単体で見てもそうですし、ちょっと事務的な話で言うと、 FTR 認定を取ると AWS のパートナーのステージがひとつ上がるんですが、アライアンスリードの方だったりとか、ビジネスを主導されている方がパートナーのステージを上げるために、というのが多いですね。
── ただ、本来の目的でいえば、そもそも認定を受けなくてもセキュリティや運用コストはしっかり考えておくべきだと思うんですよね。
開発側からしてみれば、別に認定を取らなくても1回レビューをして、どこが危ないかとか、どういう改善点があるかということを洗い出せるだけでもメリットがあると思います。なので、ただレビューを受けて、改善点を洗い出してみる、という使い方もありかなと思います。
FTR 認定は誰が先導すべき？
── そもそも企業の中で、誰が先導してやるべきなのでしょうか？
FTR 認定は、その性質上、組織の様々な部門が連携して進める必要があります。
テクニカルチーム（エンジニアリング部門）： 技術的な詳細とソリューションのアーキテクチャを理解しているため、FTR 認定の要件を満たすための技術的な改善や対策を計画し、実行する主体です。ソフトウェア開発者、クラウドアーキテクト、セキュリティエンジニアなどがこのプロセスに深く関与します。
プロダクト管理部門： 製品のロードマップとビジネス要件を把握しているため、FTR 認定が製品戦略にどのように適合するかを評価し、認定取得のプロセスをプロジェクト管理の観点から推進します。
品質保証部門： FTR 認定に必要な品質基準とプロセスが遵守されているかを監視し、継続的な改善を促す役割を担います。品質保証チームは、認定の基準に合致しているかどうかを確認するためのテストやレビューを行います。
マーケティング部門： FTR 認定を市場での差別化要素として活用し、認定取得のニュースを広報活動や顧客コミュニケーションに組み込みます。認定が商業的な価値を生むための戦略を策定します。
エグゼクティブ（経営層）： 認定の取得が組織全体の目標に合致しているかを監督し、必要なリソースやサポートを提供する役割を担います。戦略的な観点からプロジェクトを支持し、推進します。
認定プロセスの先導者は、これらの部門間のコミュニケーションと協調を促進する役割を果たす必要があります。
── いずれにしても、起案した部署とその他の部門とのギャップがないかも調べつつ、運用体制がどうなっているかも、ある程度把握しておけばスムーズかな、という感じですかね。
そうですね。技術的な面とビジネス戦略を結びつけることも重要なので、各部門が協力し合うことが必要です。
Amazon の Customer Obsession
── ちなみにレビューや認定に費用は発生するんですか？
いえ、かからないです。パートナーであれば無料で何回も受けられます。
── え、無料なんですか！ だったらメリットを考えると取っちゃった方がお得ですね。
お得なんですけど、実際にはまだ知名度がそんなに高くないのか、 知らなかったっていうパートナーの方が多いという印象です。
そもそも、我々は AWS をご利用いただいてる、AWS 環境で動いてるソフトウェアを、お客様やエンドユーザー様に安心して問題なく使っていただく、というのが目的です。そのためにセキュリティや運用面がちゃんとしているソフトウェアなんですよ、というのをお客様にお示ししたいと考えています。
そのひとつとして、FTR をパスすれば、弊社が提供している AWS Partner Solution Finder に掲載することができます。その結果、パートナーのサービスの訴求をしつつ、お客様に対する品揃えも増やしていきたいと考えています。
── ちなみに、FTR 認定の要件はどれぐらいの頻度でアップデートされるんですか？
定期的に決まってるわけではないんですけど、今は半年に1回ぐらいですかね。
── 弊社のサービスは3つ、FinanScope、Amimoto、Shifter が FTR 認定を受けて、Amimoto、Shifter に関しては2年の期限（現在は3年に延長）がきて更新もしているんですが、基本的には1回認定されたところは更新する感じですか？
FinanScope
IPO（新規株式公開）やM&A（合併・買収）に必要なタスクを一元管理するクラウドサービスです。このサービスは、企業が必要な作業をいつ、どのように進めるべきかを明確にし、アドバイザーやプロジェクトチームとの情報共有を一元管理することで、プロジェクトの進行をサポートします。2024年4月に FTR 認定を獲得。
Amimoto
WordPress サイト向けのホスティングサービスを提供するプラットフォームです。特に AWS 上での運用を最適化することに焦点を当てており、高速なパフォーマンスとスケーラビリティを実現しています。2023年10月に FTR 認定を更新。
Shifter
WordPress サイトを静的サイトに変換し、AWS を通じて高速かつ安全に配信するサービスです。WordPress のサイトを一度に静的 HTML ファイルに変換し、Amazon S3 に保存後、Amazon CloudFront を通じて配信します。これにより、サーバーレスアーキテクチャの利点を活かして、サイトのセキュリティとスピードを大幅に向上させることができます。2023年10月に FTR 認定を更新。
そうですね。更新はどのパートナーさんもやってくださっています。ただ、1社で何個も続けて認定を受けるというのは、まだそんなに多くはないですね。プロダクトごとにチームが分かれていると、他のチームに波及していかないこともあります。
ひとつのサービスで FTR の認定を取って、ちゃんとその 効果を感じてくれたりとか、「やる意味あるよね」って思ってくれて、他の製品でも取ろうという動きをしてくれる人がいるか、とかも関わってきますね。
エグゼクティブの人が「FTR、いいよね」という感じで社内で広めてくれたり、SRE のチームが、「うちは FTR を基準にしてこのプロダクトを作りましょう。 この基準を満たしてないとリリース判定しません」というような指示を出した、ということで広がったということはこれまでにありました。
SRE
Site Reliability Engineering。ソフトウェアエンジニアリングの原則を適用して大規模システムの信頼性、可用性、効率を向上させることを目的としたエンジニアリングの分野です。SRE チームの主な任務は、システムの安定性と高性能を保つこと、そしてシステムの故障時に迅速かつ効果的に問題を解決することです。
── 社内で基準があるというのはいいですよね。引き継ぎなどがあってもわかりやすいですし、安心もできますし。エンドユーザーのメリットや安心を考えたところから始まってるっていうのが、 AWS っぽいのかなと思いましたし、そのためにその認定された側のメリットも用意しつつ、どんどんアップデートしていってるという印象を受けました。
確かに Customer Obsession の AWS らしいところかなと思いますね。
Customer Obsession
顧客の要望とニーズを最優先に考え、それに基づいて行動を決定し、サービスや製品を改善していく文化や姿勢を指します。この概念は特に Amazon で強調されており、同社の企業理念として広く知られています。
── 今日はありがとうございました。引き続き、よろしくお願いします！
レビューを受けることで、チェックリストの履歴やドキュメントが残り、結果的に持続可能性も上がるというのはもちろん、元々の発想は AWS の Customer Obsession に繋がってる、というのは素敵だなと思いました。
ということで、最後に復習です。
FTR
Foundational Technical Review。「AWS のパートナーが提供するソリューション」に対して行われる認定プロセスです。FTR プログラムの目的は、パートナー企業が作成した AWS ベースのソリューションの品質とセキュリティを評価し、AWS のベストプラクティスに準拠していることを確認し、認定することです。これにより、パートナーは自社のソリューションが AWS の推奨する最良のアーキテクチャを採用していることをアピールでき、市場での信頼性を高めることができます。
FTR について、すっきりとまではいかなくても、ふんわりとは理解できましたでしょうか？ AWS でサービスやソリューションを提供しているのであれば、ぜひプログラムについて調べてみていただければと思います。
また、申請したいなと思った方は以下の AWS APN ブログに申請方法などが記載されていますので参考にしてみてください。
それでは、また。