このプロセスは、そのサービスや技術がどんなものであろうと、宣伝の開始とは一切関係がない。その仕事に取り掛かる開発チームの気持ちを集中させる狙いがあるとシュミット氏は説明する。

　「自分がこれから構築しようとするものの本質を、普通の人が理解できる一般的な英語で1ページに凝縮できないのであれば、自分が構築するものについて十分に考えがまとまっていないということだ」

　この1ページの文書は、セキュリティに重点を置いたFAQ集と照らし合わせながら作成しなければならない。その目的は、データやプライバシーの保護方法についてユーザーが抱く可能性がある疑問を想定し、前もって対処することにある。

　シュミット氏によれば、これによってAWSユーザーのためのセキュリティが製品の設計段階で「最初の文書」から、確実に盛り込まれる。

　AWSの親会社Amazon.comのイノベーション担当バイスプレジデント、ポール・マイゼナー氏によると、まだ存在しない製品のためにプレスリリースを作成すると、それがいずれ商品化されるという責任感をチームに持たせることができる。

　このプレスリリースに記載した技術はまだ存在していないので、この段階で作成したプレスリリースを発表することはできない。マイゼナー氏はその狙いについてこう説明する。

　「プレスリリースを発表できるところまでこぎ着けるためには、物事を発明しなければならない、現時点ではそれができない、と認めるということだ」

　「これは非常に謙虚な姿勢ではあるが、同時にやる気を引き出す効果もある。それができないことを認め、今はそれができなくてもいずれできるようにする必要があることを確認するのだから」

「ピザ2枚のチーム」のルール

　このプレスリリース作成に当たるチームの規模と構成は、Amazon.comのジェフ・ベゾスCEOが考案した「2枚のピザ」というチームルールのコンセプトが指針になる。「この専属チームのメンバーは同じ部署の人員である必要はない。チャンスや課題に対応するために全社から集められる。だがこれに関わる人数は、2枚の特大アメリカンピザを分け合える数でなければならない」とマイゼナー氏は説明する。

　同氏によると、このアイデアは開発チームが規模に過度に縛られる事態を防ぐ。常に決められた数の人員を保つことに固執すると、イノベーションとは完全に相反する姿勢につながりかねない。

　マイゼナー氏はこんな例えを挙げた。「8人のチームがチャンスや課題に対応していて、数カ月後に人工知能（AI）のエキスパートが必要だと気付く。ちょうどそこに必要な知識を持つ最適な人材がいて、チームに加わる意思もある。ところがそうすると9人になってしまうので、その人物を受け入れることができない」

　2枚のピザルールは、チームが大きくなり過ぎて制御できなくなる事態も防ぐ。大きくなり過ぎるとサブチームができてしまい、メンバー同士のコミュニケーションがうまくいかなくなるリスクが生じる。

開発過程

　シュミット氏によると、製品設計チームが結成され、プレスリリースが完成すると、本格的な製品開発に着手できる。さまざまな節目で弾力性や耐久性、セキュリティ態勢を試すチェックポイントがある。セキュリティのチェックポイントではエンジニアのチームが招かれ、サービスのアクセス管理や暗号化のレベルに関するさまざまな性能テストや試用を行い、そのサービスを通過するデータが全段階で保護されることを確認する。

　それが終わると、セキュリティ態勢に関するストレステストという「楽しい部分」が始まる。ここではアプリケーションのセキュリティが検証される。「これはアプリケーションの正式なセキュリティ検証のプロセスであり、ソフトウェアの開発にありがちなあらゆるミスについて対処されていること、われわれが義務付けている全てのテストが済んでいることの確認にフォーカスする」（シュミット氏）

　この過程は製品の機能のプラス面とマイナス面の両方についてテストし、全て想定通りに機能することを確認する。ブラックボックスとホワイトボックスの両方の手法を使ってそうした検証を行っている。

　「ホワイトボックステストではテストチームがそのサービスのソースコードや設計文書にアクセスできるので、クラッキングするのに最適の立場にある」とシュミット氏は説明する。「ブラックボックステストでは、外部の人間の目でそのサービスを見て、クラッキングを試みる。社内で最高の仕事があるとすれば、これかもしれない。何かを壊そうとすることで報酬がもらえるのだから」

　「攻撃者と同じ気持ちになって行動するので、これはものすごく面白い。自分たちのサービスを非常に批判的な目で見て、攻撃者にチャンスを与えればどれほど大変な騒ぎになるかを考えなければならない」

品質保証

　こうした形のテストは、開発過程で品質を保証する目的で継続的に繰り返される。「コードがまだ最初の数行しかない開発プロセスの初期段階から、製品をリリースした段階、時間が経過した段階に至るまで、われわれはこのテストを行う」とシュミット氏は言い添えた。

　AWSが商品化するクラウドサービスや製品に搭載されているセキュリティツール／機能は、当初社内だけで使う目的で開発され、後に広く公開されたものが多数を占める。

　「特定の種類のセキュリティ問題に対するわれわれのアプローチについて顧客と話していると、『AWSはどうやっているのか』と尋ねられることがある」とシュミット氏は話す。

　AWSの顧客の多くは「何十万台もの」仮想マシンを運用しているが、AWSが運用する仮想マシンは「それよりも桁違いに多い」。標準的な市販のセキュリティツールで常に対応できるとは限らない。

　「一般的なセキュリティツールは利用できない。従って非常に広範かつ横展開できるセキュリティツールを開発しなければならない。結果として、社内で使うために構築したツールを外部に出すことがある」とシュミット氏。

　実例として同氏は、機械学習製品に関して社内で行った開発が「Amazon Macie」というサービスに結び付いたと指摘する。同サービスは、Amazon S3（Simple Storage Service）に保存されているデータを、機械学習を使って発掘、仕分け、分類する。例えば追加的な保護が必要な個人情報や会社の知的財産を洗い出すようにトレーニングできる。

　ユーザーは、ダッシュボードインタフェースを通じてアクセスや移動が行われたデータを追跡できる。Macieはその情報の利用パターンをモニターして、正規の利用であることを確認する。

ベースラインの確立

　Macieを使うためには、ユーザーがS3バケットのコンテンツとログにMacieがアクセスすることを許可しなければならない。Macieは約2週間かけ、このデータを使って通常利用のベースラインを確立する。

　シュミット氏は言う。「Macieはコンテンツを分類して内容を認識し、『これが何かを知っている。何がセンシティブかを知っている。それがどう使われているかを知っている』と言うようになる。そして2週間たつと、『それはこういう使われ方をしている』と言い、『この利用方法は他の全てとは違う』といったことを示唆するようになる」

　このシステムはクラウドに保存された会社のデータのアクセス方法、利用方法について、担当者が情報をかき分けながら反復的に調べなければならない作業の「重い負担」をかなり軽減できる。

　ただしシュミット氏によると、狙いはこのプロセスに関わる人の役割の一切を根絶することではない。なぜなら「人材は、どんなセキュリティチームにとっても最も貴重な単一の財産だからだ」と同氏は言い添えた。

　結局のところ、不審に見えるものがリスクなのかどうかについて「合理的な判断」ができる能力は、人間にしか備わっていない。「ツールを開発して導入するのは、日々の重い負担を担う代わりに、人間が判断する作業ができるようにするためだ。機械学習は真に重要なことに関してはそうした人に重点を置き、それほど重要ではないことは切り捨てる」とシュミット氏。

　Macieは、例えば個人情報を含む可能性があるデータセットの存在をユーザーに知らせ、それにアクセスできる人物全員のリストと、その人物が過去にそのデータをどう使ったかについての情報を提示することによって、この作業を行う。

　「Macieは、この一連のアクセスは異常で、他の全てと違って見えると告げる。それを見た人間は『なぜ違って見えるのか。この人物の職種が異なるためか、あるいは何か想定外のことをしているのか』と考えられる」（シュミット氏）

セキュリティの民主化

　クラウドのセキュリティ対策を追求するAWSの終わりのない探求は、社内で独自に開発したツールや技術をユーザーに使ってもらうだけでなく、インターネット全般にも恩恵をもたらしているとシュミット氏は言う。

　「われわれの大手ユーザーの強い要請で導入したセキュリティの向上は、われわれの無料サービスを使って大学の宿題をやっている学生も利用できるというメリットがある。そのセキュリティの民主化が、インターネット全体にもたらす影響力は真に大きい。これは『上げ潮は全ての船を持ち上げる』という類いの事柄だが、中堅・中小企業（SME）の多くは大企業のようにはセキュリティに投資できない。最も厳重な障壁への対応を目的としたセキュリティの自動化と機械化によって、SMEが同じ恩恵を受けられるようになれば、インターネットがわれわれ全てにとってより良い場所になる」。シュミット氏はそう語った。