セクションナイン の 吉田真吾（@yoshidashingo）です。
第5弾も海外のスピーカーの紹介です。PaaS の老舗 Engine Yard で DevOpsサポートエンジニアをしている Allan Espinosa さんから、サーバーレスを活用していくための組織の話を伺ってみます。
プロフィール
- 名前：Allan Espinosa
- 会社名：Engine Yard
- 役職：DevOps Support Engineer
Allan は Engine Yard で働き、カスタマーが Deis や Docker、Kubernetes を本番環境で利用するためのサポートをしています。以前は世界で最も巨大な CloudFoundry 環境で Chef を使ってデプロイする管理をしていました。Allan は Packt Publishing から Docker High Performance という本も出版しています。この本にはさまざまな実例や、本番環境で Docker を up して run するようなハイレベルな概念について書いてあります。
Quick Chat
---- ようこそ日本にお越しくださいました。日本でのご予定は？
親戚や家族に会うためにすでに1ヶ月ほど日本に滞在しており、ServerlessConfの数日後に日本を発つ予定です。 数年前に実際に日本に住んでいたので、その頃のなつかしい場所も訪ねています。
---- どおりで日本語が上手なわけですね。それでは ServerlessConf Tokyo でのセッション概要を教えてください
サーバーレスな環境にWebアプリケーションをホストしたとしてもオペレーションを忘れていいわけではありません。他の多くの人がサーバーレスな環境におけるオペレーションのしやすさの面で気をつけるべき点を強調されてきました。テクノロジースタックやAPIの抽象レベルが変化しても、カスタマーのためにサービスを稼働し、運用し、保守するための大原則は変わりません。
これらの考え方はサーバーレスなアプリケーションをサポートする組織にも適用されます。つまりたとえば、短期的には組織の形を変えずにサーバーレスなチームを構成することは可能ですが、そのうち技術的負債に支払いを求められるようになり、最後には元どおりになってしまっていることに気づくことでしょう。
このトークでは、私がPlatform-as-a-Serviceソリューションを稼働するバックエンドサービスチームやベンダーとして学んだ教訓を共有します。開発者への価値提案とその他の組織への価値提案はどちらも似ていることから、たくさんの類似点が見いだせることでしょう。コンウェイの法則は未だに健在で、あなたがサーバーレスなアプリケーションの構築・稼働のためのチームを作るときにきっと役に立つことでしょう。
---- ありがとうございます。それではもう少しつっこんで話を聞かせてください。まず、あなたはサーバーレスでオペレーション作業を減らすことはできるが、それでも責任(responsibilities)は自分たちで負う必要がある、つまりサービスマネジメントは忘れてはいけないと解釈しました。合ってますか？またそれはなぜでしょうか？
はい、組織においては、自分たちの顧客に対する責任(responsibilities)と保障(guarantees)が伴います。我々のサービスがダウンしたとしてそれを他人のせいにすることはできません。利用しているFaaSやサーバーレスのプロバイダーがダウンしていたとしても、われわれは顧客の期待に応える責任があります。このマインドセットはどうやってサーバーレスなアプリケーションを構築するかという点に影響します。
---- あなたはバックエンドサービスチームの一員、またベンダーの一員として得た知見を共有してくれるとのことですが、開発者とそれ以外の組織でも共通している点というのはどういうものでしょうか？
たいていの組織はサービス開発チームとバックエンドサービスチームが分離されています。これらの分断の影響で、バックエンドサービスチームが組織に付随したチームではなく顧客とは関係ないベンダーのように振る舞ってしまうことがあります。こうやってバックエンドサービスチームが組織外のものであるかのように振る舞ってしまうことで組織の管理レベルにおいてさまざまな軋轢を生んでしまうことがあるのです。
ベンダーの中には非常に厳格に「これは対応し、これは保障しない」といった明確な範囲を決めているところもあります。また、中にはカスタマーサクセス部門を持つことで、ベンダーがカスタマーのチームの一部であるかのように感じさせてくれるところもあります。
ベンダーやバックエンドサービスチームといかにコミュニケーションを取るかによって、アプリケーションの設計は影響を受けるのです。
---- 組織をもっと素早くてアジャイルな組織に変えるためにおすすめの方法はありますか？
組織の古い構造の中には変化に対する抵抗力があります。ミッションの変更や、組織全員に影響があるような状況の変化（たとえばサービスの閉鎖や企業の倒産など）によって、人々ははじめて新しいアイデアに対してオープンになり始めるのです。これは組織における継続的なプロセスです。
DevOpsや継続的デリバリーの分野には、環境を変えるリスクを和らげながらアジャイルでハイパフォーマンスな組織に変えていくためのたくさんの文化の訓練方法があります。
---- ありがとうございました。お会いできるのを楽しみにしています。
こちらこそ。 カンファレンスでみなさんにお会いできることも楽しみにしています！
まとめ
短いチャットではありましたが、サービスマネジメントにおける責任分解点の話や、組織の構造やコミュニケーション方法がアプリケーションのアーキテクチャに影響を及ぼすという話は、Microservicesの文脈においても耳にすることが多く、サーバーレスにおいても今後議論のひとつとしていきたい内容ですね。
また、実際に開発者に近い立場でサポートをしているAlanさんの知見も非常に興味深いので、当日はさらにさまざまな視点から話を聞きたいと思いますね。
それでは当日をお楽しみに。
