[レポート]Achieving developer productivity in the cloud at Capital One (sponsored by Accenture)#PRT270 #reinvent

本エントリはAWS re:Invent 2022のセッション PRT270 Achieving developer productivity in the cloud at Capital One (sponsored by Accenture)のレポートです。

AWS re:Invent 2022

#AWS

おおはしりきたけ

2022.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、おおはしりきたけです。re:Invent 2022に参加しております。Achieving developer productivity in the cloud at Capital One (sponsored by Accenture)というセッションに参加してきました。

参加した、セッションの概要は以下となります。

登壇者

登壇者：
- Gautam Chugh, South Cloud First Lead, Accenture
- Mark Mathewson, Executive Vice President, Capital One
Session level：200 - Intermediate
Session type：Breakout Session

セッション概要

技術系のリーダーであれば、誰もがソフトウェアエンジニアリングの組織全体の生産性を向上させたいと考えています。しかし、特に業界の進化のスピードとクラウドでの作業の複雑さを考えると、これまで生産性向上は非常に困難な課題でした。このセッションでは、Capital OneとAccentureのクラウド専門家が、AWSとクラウドネイティブ機能を活用した生産性、コミュニケーション、コラボレーションに焦点を当て、クラウドの旅について説明します。ソフトウェア開発をビジネス目標に合わせることで組織全体の生産性を向上させ、最終的に新しい顧客機能の開発を加速させる方法について、テクノロジー・リーダーが学びます。本講演は、AWSパートナーであるアクセンチュアの提供によるものです。

セッション内容

登壇者自己紹介

自己紹介

Gautam Chugh氏
- アクセンチュアでマネージメント、ディレクターをやっている
- バージニア州在住
- 南地区のクラウドビジネスの責任者
- 二人の息子さんと21年来の奥様がいる
Mark Mathewson氏
- キャピタル・ワン・フィナンシャル・コーポレーションは、アメリカ合衆国・バージニア州・McLeanに本部を置く金融持株会社
- 技術業界には25年以上働いており。キャピタルワンでは9年間エンジニアリングを担当している
- スケールの大きなアーキテクチャの構築に関して常に私を魅了してきたことの1つは、本当に素晴らしいことだった

Capital Oneの歩みについて

今回は、開発者の生産性についていくつか質問したいと思いますが、その前にCapital Oneの歩みについてお話をします。私たちは本当にユニークなカルチャーを持っています。私がいつも私たちのカルチャーについて話すとき、私たちは銀行や創業者について話しているのではありません。そのため、このカルチャーはとてもユニークで、より起業家的な感じがします。創業者は、どうすればこのビジネスを成長させられるか、業界がどうなっていくのか、どうすればこのビジネスを変革できるのか、毎日情熱を持って取り組んでいます。私たちの文化でユニークだと思うのは、テクノロジーが基礎になっているということです。今、私たちはこの業界のことをよくそう言っています。しかし、年を重ねるにつれて、次世代のためにオーダーメイドのソフトウェアをどう作るかを考えることは、非常にパワフルなことなのです。

クラウド利用とエンジニア文化について

AWSとの提携により、米国の管理サービスベースの組織で初めてクラウドデータセンターに進出したこと、2020年で100％というのはよく知られていると思うんです。しかし、現実には、生産性について、何が変わったかといえば、クラウドへの移行だけではありません。計算機やストレージを他社のものにした場合、明らかに多くの新しいサービスを利用できるようになり、それが競争力につながっています。しかし、生産性の向上という点では、私たちが何をしようとしているのかが重要なのです。先ほども言いましたが、歴史的に銀行業はアウトソーシングされたテクノロジーが多く、プラットフォーム自体も、テクノロジーを構築するためのサードパーティの労働組合も、すべてアウトソーシングされたものだったと思います。そこで私たちは、ソフトウェア・エンジニアリング企業として自らを再構築することにしたのです。このことが、生産性に対する考え方の変化を促したのだと思います。つまり、誰もがエンジニアなのです。世の中には、必ずしもそのような職種を想定していない職能群もあることは確かでしょう。しかし、ほとんどの場合、私たちはエンジニアをベースとした文化であり、これはまったく新しいものです。そのため、価値を提供するためには、生産性を高めることを最優先に考えなければなりません。以前はバイヤーが多かったのですが、今では何でも作ってしまおうというのが第一の考え方です。ですから、スタックの上下にあるものなら、ほとんど何でも作ることができます。最初に考えるのは、自分たちで作るべきかどうかということです。そして、自分たちで作るのであれば、それを効果的にスケールアップするために必要な人材がいるはずです。これが、私たちの考え方の基本的な違いです。もうひとつは、生産性を向上させるという点です。エンジニアは、クラウド上で多くのエンジニアが新しい機能やツールにアクセスできるようになると、それを利用したいと思うようになります。エンジニアは、そのようなツールにアクセスすることを要求しています。ちなみに、非日常的なツールは非常に高い水準にあります。みんな、ここに座ってずっとニュースを見ているわけですが、自分の環境に戻ることを望んでいます。自分の環境に戻りたいのです。そのためには、生産性が重要です。でも、どうやってツールを手に入れ、それを使って安全に建築を始められるようにするのか。このような考え方によって、開発資産を確保するための価値提案は大きく変わってきました。

生産性向上について

Capital Oneでは、12,000人の社員がいます。その中でもほとんどのエンジニアは、かなり大きなエンジニアリング能力を有していることになります。そして、SDの成長と変化のスピードはすごいものがあります。ですから、もし新しい人が入ってきたら、初日から価値を提供する方法を理解させるために、どのように彼らを取り込むか考えてみてください。なぜなら、毎年新しいエンジニアの集団が入れ替わっていく中で、それを行う必要があるからです。これは常に起こることです。そのため、生産性の向上にはより大きなプレッシャーがかかります。もうひとつは、製品規制への圧力です。私たちの業態は、高度に規制された産業です。日常生活の中で、共有責任モデルは、彼らがセキュリティを提供し、私たちは製品の中にセキュリティレベルのデータを提供する、と言っています。ですから、規制当局にとって、これはまったく新しいことであり、理解し、維持しようとする努力が必要なのです。そして、毎日、すべてのエンジニアが、新しいセキュリティ基準で安全性を構築する方法を理解する必要があるのは、楽しいことです。前のセグメントと同じように、全体的な生産性に大きな負担を強いています。最後に、生産性に大きなプレッシャーを与える要因として、エンジニアの才能の民主化も挙げられます。投資する資金を持っているビジネスリーダーは、エンジニアをどのように使って実際に構築するかを現地でコントロールしたいと考えています。つまり、常に進化し続ける企業体をどのように管理し、目的地に到達するための戦略を立て、創造力を発揮して実際のビジネス製品やデータベースに真の価値を付加したいと考えるエンジニアをどのように鼓舞するかという、根本的な課題があるのだと私は考えています。

生産性の測定について

生産性の測定エンジニアは、生産環境の変化を測定するために、測定しやすいものを使おうとしますが、実はそれらはあまり役に立ちません。生産的な成果とは何かということを本当に考えるとき、私たちは多くの時間を費やします。ですから、私たちは多くの時間を費やして、エンジニアの経験をどのように評価するかということを考えるようになりました。これは私にとって非常に重要なことで、一日の終わりに、彼らが生産的になれるかどうか、彼らが経験したことから成果を得られるかどうかを確認します。そこで、開発者のNPSに注目しました。Net Promoter Scoreは、Capital Oneの内部でさまざまなことを測定する方法ですが、これは本当に難しい指標です。この指標は本当に難しいもので、正確でなければなりません。なぜなら、不満足な人や中立的な人がいると、それがスコアの足を引っ張るからです。そのため、すべてのプラットフォームが必要なのです。エンジニアの生産性を高めるために使用されるプラットフォームは、基本的にNPSを測定し、良いサービスが提供されているかどうかを判断します。また、様々なエコシステムで仕事をこなす能力について、エンジニアがどのように感じているかを調べました。また、品質とスピードの指標や、品質とスピードの指標の束もあります。私たちは、本番環境での稼働率を変えたいと考えています。製品やサービスを見ていて、そういうものを解決する時期が来たとき。また、エンジニアが生産に投入する製品の品質が、実際にどのように変化しているかを把握するのにも役立ちます。このように、私たちがトレーニング開発で使っているレバーのいくつかは、明らかに重要なものです。自動化されたアーキテクチャとガバナンスが本当に重要であることは、これから説明します。私たちは、エンジニアの生産性だけでなく安全性を確保するために、学習方法とガードレールの設定に多くのエネルギーを注いでいます。そして、開発者エクスペリエンスもまた、別の次元の話です。最終的に開発者が実際に生産的な体験をできるようにし続けることを確認するのです。そして最後に、アライメントです。面白いことに、開発者に生産性を感じさせたり、ツールやレンダリングを自動化したりすることはできますが、彼らが実際に取り組んでいることは、ビジネスプロフェッショナルと技術戦略の優先順位が異なるために、バケツから漏れてしまうことになるのです。そこで私たちは、OKRとレバレッジについてよく考えます。

NPSスコアやイネーブルメントスコアなどは、実際に公に共有されているものです。私たちは四半期ごとにこのスコアを見ます。私たちは四半期ごとにそれを見ていますし、定期的にそれにこだわっています。すべての開発者ツール・プラットフォームの所有者は、NPSを実際に測定し、かなり広範囲に公表することが義務付けられています。プラットフォームは、建設的なフィードバックや学習としてシステムに戻ってきますが、プラットフォームのオーナーは、次の機能セットやリズムにそれを取り入れる必要があるのです。つまり、完全に透明なのです。これは、私たちが実践し、進化させ続けていることです。効果的に行うのは非常に難しいのでテストと学習を続け、透明性を確保し計測することが重要です。

開発者環境について

もっとも重要なのは、自動化と単純化です。環境をシンプルにするために、データベースや少ないツールセット、標準的なゴールデン・イメージに頼るという話を何度もしました。しかし、企業レベルでは、買収やレガシー・プラットフォーム、長い時間をかけて構築されたシステムなど、非常に複雑な問題を抱えていることが、この問題を難しく、興味深いものにしています。そのため、単純化するだけでも大変な作業で、単純化が大きな役割を果たします。そして、自動化がもう一つの役割で、単純化した後は、自動化が可能になります。私たちは、おそらく2～3年かけて単一の開発パイプラインに統合し、多くの生産性を実現しました。しかし、複雑なレガシー環境全体にそれを適用するのは、非常に困難なことでした。文字通り、何百、何千もの独立したアクセス・クラウド用のパイプラインを、全員のパイプライン全体に義務付けられた1つのパイプラインに落とし込むのです。このタイプ1は、製品ではありません。12,000人の開発者が利用できるようにするためには、標準に準拠した製品でなければなりません。使いやすくなければなりません。そのパイプラインからサポートを受けるのも簡単です。直感的に理解できるエラーメッセージも必要です。彼らが効率的に仕事をするために必要なものは、すべて揃っていなければなりません。しかし、そうではありません。パイプラインによる自動化は、エクスペリエンスを向上させ、同時に効果的なガバナンスを実現するための基本的な要素であり、バランスを取るための一つの方法です。

このように、共通のパイプラインができたので、それを私たちのエンジンに変換することができます。私たちが取り組んだ最も困難なことの一つは、このエンジン全体にわたる脆弱性管理です。実際、私たちは常に最新の情報を調べています。自動化された脆弱性管理のために、私たちは能力パイプラインを構築しました。これらのインスタンスのセットには、あらゆるソフトウェアやインフラのコピーが入ったゴールデンイメージが継続的に入っています。これは、ブラウザ開発者が RTE の大部分をエンジン関連の活動に費やしていることを如実に示しています。これは脆弱性なのか？どうすればリフレッシュできるのか？私たちは現在、非常に似たような機能、継続的なインフラストラクチャの構築に取り組んでいますが、これは私たちの次の最も困難な課題となっています。脆弱性は、私たちエンジニアにとって非常に大きな痛手となります。

サーバーレスアーキテクチャについて

シンプルに考えれば、次世代ドライブのメリットだと思います。私たちは最終的に、マネージドサーバーインフラを一切避けたかったのです。つまり、抽象化のレベルを継続的に考えるなら、私たちはクラウドの管理されたデータセンターに移行しました。私たちは、エネルギーインフラの一つを全く管理する必要のないサーバーレス機能に移行したいと考えています。すでに我々の環境では、Lambdaの利用やECSを使ったPharmingの利用が認められています。これだけでも、当社のエンジニアにとって好ましい開発手法になりつつあります。現時点では、サーバーレスアプリケーションは全体の2％程度で、100％レトロフィットされているわけではありません。しかし、私たちは、サーバーレスアーキテクチャを奨励していますし、チームも実際に、何時間も生産性を上げられるということで、とても興奮しています。ですから、間違いなく実現し始めています。

サードパーティとの統合やCOTS製品など、サーバーレスを実現できない環境もあります。また、サーバーレスを実現できない環境もあります。バッチ式のインフラストラクチャでは、サーバーレスが好ましいとか正しい答えとは言えないものもあります。しかし、ほとんどの場合、サーバーレス化は自己強化につながることが分かっています。

生産性を上げるために必要なものはなにか？

企業内では、先ほどの話に戻りますが、ソフトウェア・エンジニアに移行しつつあることが認識され始めているようです。ソフトウェア・エンジニアが占める割合と、そのエンジニアがどのように言及するかによって、優秀な人材にとって大きな課題が生まれます。待機状態は非常に高くつくので、これらのチームへのコンテンツの流れを最適化させるという自分たちの役割が、実は非常に重要であることを認識し始めたのだと思います。先ほども言いましたが、メディアの機動性を高めるために、開発者がどれだけ速く開発し、本番環境に変更を加えることができるかにアウトプットの指標を合わせても、それが企業にとって最も価値の高いビジネス成果に100%合致しているかどうかを確認することはできません。そこで、私たちは企業との話し合いに多くの時間を費やしました。先ほど、OKRの方法論を用いて、次に高い価値を持つものは何かということを確認しました。そして、最も価値の高い技術の1つと、その価値をどのように交換するのか。この時点では、サーバーレスにするためにバックボーンを改修することと、実際に収益の同期を生み出す新しいビジネス製品を立ち上げることのどちらが重要なのでしょうか。OKRを活用してようやく実現できたのは、ビジネス部門とテクノロジー部門を横断して足並みを揃えることです。

最先端の人材を育成し、満足させるための工夫

私たちが、実際に望んでいた人材モデルから逆算することから始めなければならなかったと思うからです。モデル化するのは難しいのですが、私たちは、フィンテック企業が提供する正確な分量に追いつけるようなモデル、つまり、よりコネクターに近い存在になりたいと考えました。クリエイティブ・ビルダーは、AWSやAmazonのネイティブ・スキルに精通した人材を持っていることが分かっています。そして、そのような開発人材を惹きつけるための環境をどのように作るかを決めました。彼らは、自分が作業しているという感覚を持ちたくなかったのです。もっと革新的で、もっと起業家的な組織で働くことを望んでいたのです。そこで私たちは、インフラや施設だけでなく、そうした組織がアップグレードするような環境を作ることに時間をかけました。また、教育にも多くの時間を費やしました。私たちは、社内にトレーニング組織を作りました。私たちはそれを「テック・カレッジ」と呼んでいます。テック・カレッジは、エンジニアが実際に学習し、テストするための何度も何度も行われるワークショップです。

テクノロジーとは何かというと、実は内部的には永遠に続く組織なのです。ですから、私たちは135の異なるクラス、いくつかの異なる分野に分かれています。他の多くのクラスは、率直に言って、クラウドの内部で働く特定の方法について、どのようにスピードアップするか、またはスキルを伸ばすかに焦点を合わせています。最も人気のあるクラスは、AWSの認定クラスで、認定を受けようとするエンジニアは全員、100％認定を受けるという目標を立てています。実際に3万人以上がレッスンを受けており、これは技術者組織とは比べものにならないほど素晴らしいことです。これは、技術系の組織とはまったく異なるもので、技術系にあるフラットなものから学び、成長しようという意欲とシンボル、エネルギーを示しています。もっと広い範囲から。私たちのチームには希望するチームがあり、製品チームやその他のチームには、彼らが手にするものを実際に管理している人たちがいます。

最終的に、私が思うに、一人ひとりにとって超重要なのは、彼らが潜在能力を発揮して働いてきたことを実現する能力なのです。私たちがこの時点で実際に行った投資によって、私たちに付加価値を与えてくれるのです。