Adam FitzGerald（Head of World Wide Developer Marketing, Amazon Web Services,Inc.）さんより
アマゾンのイノベーションを支える次の４つの要素について、どのようにそれを機能させ、どのような効果があるのかについてお話されました。
- 文化
- 組織
- アーキテクチャ
- メカニズム
これらの中で、とりわけ文化とメカニズムは、イノベーションに対して指数関数的に大きな影響を与えるとのことです。
そして、イノベーションは決して「目標」などといったものではなく、日常のしごとの中に組み込まれる継続的なプロセスである、ということでした。
イノベーションをどのように企業の核にするのか。
今朝はairbnbの話がありました。それ相当のスピードでAWS上で急成長した事例です。airbnbはイノベーションはビジネスの中核をなすと位置づけました。
文化は将来のイノベーションの基板である。したがって会社の文化を壊したら将来の製品を作る機会を壊すことと同じである
これは大変興味深いイノベーションについての言及です。
AWSではイノベーションを大切なものと位置づけている。文化社風だけがイノベーションを生むのではなくその他の要素も関わります。
アマゾンでの社風、それがどのようにイノベーションにつながっていくのか、それについて触れましょう
またその他の要素にも触れます。Culture,Organization,Archtecture,Mecanizm(文化、組織、アーキテクチャ、メカニズム-業務の流れとしてイノベーションを強化する仕組み）について、AWSの中での事例を紹介します。
A Rapid Pace of Inovation
AWSは素晴らしいスピードでイノベーションを展開しています。
新しいサービスの展開速度は加速しています。それは戦略的な我々の意思に則ってスピードを持ってイノベーションを展開しています。
社風
Work Backwords from the Customer
ではそのアマゾンにおける社風についてお話しましょう。
お客様は何に感心を持ち何を求めているのかを理解しソリューションを提供する。単にリリースをしてお客様を蚊帳の外において作業するのではない。お客様有りきで開発していく。
実際の開発が始まる前にシンプルなドキュメント、すなわちプレスリリースを書くところから始める。これから何を始めるのかを描いたプレスリリース。
これから何を投資し、お客様は何を解決しようとしているのか、ユーザーの観点から書いていく。ユースケースから書いていく。
そのプレスリリースに続いて書くのがFAQ。社内・社外両方の視点から、プレスリリースに対して生じうるFAQを書く。
それからユーザードキュメントを書く。そこからソフトウェア開発をしていく基準が書かれている。ユーザーの観点からということを忘れずに、書き上げる。どんな要求要件になるのか考えて書き上げていきます。
そして、こういう機能が必要だ、このような特性が必要だということを明確化していく。
そこから実用最小限のプロダクトを定義していく。
そういった社風がある。お客様に執着しそこから次のサービスにつなげる文化がある。
AWSにおける要件というのは、すべてのサービスが疎結合であり、全てにAPIが提供されている必要がある。それらはドキュメントに明確に記載されている必要がある。
お客様との契約はAPIである。技術を使っている人たちへの契約はAPI。APIの場合柔軟性を担保しそのサービスの中身はエンドユーザーがカスタムすることが出来る、デベロッパーに提供されるもので、お客様が何に使うかを100％理解しているわけではなく想定して作ることになる。
アーキテクチャとして組織がどのように機能するかはここから始まっていく。
組織
アマゾンエンジニアの哲学がある。二枚のピザで全員が満足できなければ行けない。つまり少人数でなければならない。
API契約に焦点を当ててサービスのインタラクションが担保できれば、何に使用されるかが明確になる。イテレーションをなども繰り返し共有することが必要になる。
それぞれのチームが成功に作られたスイス時計のようです。それぞれ独立して意思決定を行う。それで良いのです。APIによってユーザーへの契約は定義されている。多くのワークフロー、レプリケーションなどが必要な中で、他のサービスとそれらのサービスが提供するAPIを通して遣り取りをする。サービスは全てプラットフォーム上に存在しているものの積み上げであり、そこからお客様への新しいサービスが生まれる。
疎結合の自律的なチームが疎結合の自律的なサービスを作り出す。そうすることで既存のサービスから新しいサービスが作られていく。
AWSはITインフラのブロックを作り出す仕事といえるでしょう。そのブロックを組み合わせていくことで素晴らしいサービスを作ることが出来ます。
AWSプラットフォームを使うことのメリットは、ご自身で組み合わせるビルディングブロックが選べるということだと思います。
アーキテクチャ
アジャイル開発のメソッドを用いているのでアーキテクチャが必要です。アジャイルの開発では頻繁なリリースが必要になります。イテレーションが早くなければなりません。サービスのリリースができるだけ頻繁にできることが、個別のイテレーションの品質より大事なのです。
あるいはイテレーション間でなにか起きてしまったら、あるいはその長さがながければ、開発が止まってしまうことも考えられます。そこで頻繁なリリースが重要になります。
継続的なインテグレーション、継続的なデプロイメントが必要になります。
APIを通してインタラクションがとれらることになりますが、リリースの際にAPIと整合性がとれている必要があります。
それから何かをプットアウトするとき、それが再現可能であり、自動でなければなりません。人間がボタンを押すだけということです。
それによって私達は地域を超えたAWSのデプロイが可能になっています。そのことが新たなサービスを迅速に提供できる理由になっています。
アジャイル開発にはビジネス上の価値があります。リリースの頻度が上がることは、リリースごとのリスクが最小限になり、改善、新しいリリースが早くなります。
従来型ではリリースは大型で頻度も低いです。そうすると何かに問題があった場合のリスクが高まります。それと同時にその問題を解決する速度が落ちてしまいます。
ビジネス上の観点からもリーンな方法のほうが価値が大きいのです。
アジャイルを採用することでAWS上ではどのような価値が得られたかということですが、アジャイルリリース手法を取ることでソフトウェアに起因する障害を75％抑えることが出来ました。
実際に障害が何分残ったかも90％削減されました。
ソフトウェアを頻繁にリリースしており、統合・リリースを自動化しています。そうすることで障害の発生は非常にまれになっています。既存のソフトウェアに障害が起きる可能性は0.001％以下になっています。
メカニズム
次にビジネス上のメカニズムについてお話しましょう。
イノベーションをどのように支えるか。毎週水曜日にWeeklyビジネスレビューを行っている。
各チーム全員が一同に会します。そしてこのビジネスレビューにおいていったいサービスの状況はどうなのかステータスを確認します。何人のお客様が使っているのか、大規模なお客様は、トレンドやサービスのニーズがあるのか、リクエストにどれだけの改善提案がされているのか、数百枚のレポートを毎週処理します。
これを聞くとスマートなIT出ないように聞こえますが、このWBRは重要な役割を果たしています。
実際にエンジニアチームが製品をリリースする何らかの障壁になっているかといったことを見ていきます。価格なのかプロセスそのもの化、動機付けか、マーケティングチームとの摩擦なのか、障壁になっている要素は何かというのをWBRで見ていきます。
これはローンチロードマップですが、リリース計画が書かれていて、各プロジェクトオーナーがスケジュールを把握しており、共有されています。ローンチプロセスは実はすべて自動化されています。反復・自動で可能なのか、サービスチームがローンチプロセスに準拠することが必要です。
エンドユーザーの影響はどのようかといったことを全てあアクしておりチケットで管理されている。
すべて現状を把握しブログでポスティングされている。
的確なリージョンに展開されるのかを確認してく。反復可能か自動化されているのかは大事であり、イノベーティブなサービスを提供していくにあたって重要な事である。
毎週の会議で経営幹部の目標の見直しも行われる。優先順位付けされて目標が管理されており、どこでどのような判断がくだされるべきかも明確化されている。ただそれでがんじがらめになることは避けなければならない。まずは優先順位設定が大事でいつリリースされるべきか、リソースを配分されるのはどれかということであるが、環境が変わったら見なおすことが大切である。
スピードが十分か、ペースはあっているか、ビジネスリソースを駆使して、もっとも重要な要素は何かを毎週見直す、それがAWSチームのWBRです。
ちいさなチームであれば素早いリリースが出来ます。しかし事業が拡大していくと各サービス感の依存関係が出てきます。単一の作業が、ひとつの大きなまとまり、大きく絡み合った毛糸玉のような事になります。成長するチームが巨大化しても、イノベーションを生み出すことを忘れてはなりません。
自立した、2枚のピザで全員がお腹いっぱいになるような規模、意思決定の権限を持っている、そういった状況を企業が拡大しても維持することがだk時。そういった独立したトシキがスピードとイノベーションを維持していくといえるでしょう。
おさらい
カルチャー
カルチャーが大事だというお話をしました。お客さまのこだわりです。採用でもイノベーションへの背景、お客様へのこだわりを持っていることを重要視します。それも大事なことです。
組織
自立した意思決定が出来るか、といったことがイノベーションのためには需要です。
アーキテクチャ
アーキテクチャでもそれによってイノベーションが加速されます。契約ベースのアーキテクチャを取るということ、また継続的インテグレーションやデプロイを取るということ、そういうアーキテクチャーがイノベーションを可能にします。
メカニズム
さらにビジネスがイノベーションの足かせになっていはいけません。再現性をもたせ、自動書かせる、ビジネスがエンジニアチームの速度のじゃまになってはいけないということです。
どのリソースをどのように配布するのか、サービスがどのように使われるのかということも重要です。
数学的な見方でこれらの要素を評価すると…
私は数学科なので少し数学を使ってご説明します。
今お話した4つの要素はすべてが平等に重要というわけではありません。
組織、サービスデリバリーをサポートするアーキテクチャは、イノベーションに対して1次関数的な効果を持ちます。
カルチャーとメカニズムは指数関数的にイノベーション速度に影響します。
イノベーションを褒め、正しいとする文化が必要です。組織の構造を改善して、例えば20％改善すれば、イノベーションも20％改善されますが、２０％ビジネスメカニズムを改善すれば、イノベーション速度には大きな影響があるのです。
ということで数学的に説明してみました。こんなふうに話すとオタクっぽくなりますが。
いちばんの投資の部分はカルチャーの部分だと思います。長期的に見ても一番リターンが多いのはカルチャーです。
必ずしもイノベーションは目標ではありません。これは継続的なプロセスです。ビジネスとしてプロセスの中に作りこまれなくてはなりません。だから例えばWBRはAWSにとって非常に重要なのです。
これを代弁するのが
Jeff Bezos
アマゾンは3つの大きなアイディアを有して18年間こだわり続けてきた。カスタマーファースト、発明せよ、忍耐強くあれ。
まずお客様を考えれば何を作るべきかという契約が定義されます。お客さまのニーズに誰よりもや約対応して価値を提供できるでしょう。多くのお客様が価値を実感してくだされば長く使っていただけるでしょう。
皆さんは私達のパートナーとして私達のサービスを定義してください、みなさんが何をしたいかということが私達にとっての重要なインプットとなります。