2017.12.21

DevOps Enterprise Summit 2017で発表された、ユーザー企業事例(第2回)

加藤学
SB C&S株式会社
テクニカルフェロー
このエントリーをはてなブックマークに追加

皆さん、こんにちは。前回からDevOps Enterprise Summit 2017 (以下DOES)の様子をレポートしておりますが、今回は、金融業界から北米の2銀行のユースケースを紹介していきたいと思います。

KeyBankの事例

初めにご紹介するのは、KeyBankです。 オハイオ州クリーブランドに本社を構える北米で13番目に大きな銀行です。従業員は20,000人おり、その25%にあたる5,000人がIT関連の仕事に従事しています。

この大規模な組織は、1820年の設立以来、事業拡大や買収などの異なる文化を吸収してきた歴史そのものであり、成長と同時に多くの問題も抱えてきました。システム的な面では、 買収に伴う異なるシステムの統合、開発チームの統合により多くの技術的負債が蓄積していました。オンラインバンキングのトラフィックを例に上げると、1回のログイントランザクション通信の裏では、200ものネットワークホップが発生しており、大きな2つのデータセンターを跨いだ無駄なピンポン通信が7回から13回も起こっていました。さらに、つぎはぎしてきた弊害でそれぞれのデータセンターの随所にSPOF (Single Point of Failure : 単一障害点)が点在していました。その結果、単一のネットワーク障害でも、Catastrophic Event (壊滅的なイベント)へなりかねない状況が続いていました。

これを解決しようと、2015年から運用チームだけではなく、開発チームも一丸になって進めるIT改革プロジェクトが始まりました。社内では、Interdigital 17 (D17)という名前のプロジェクトで呼ばれており、複雑さや根本的におかしいものを見直す活動としてスタートしました。当初は約2年間を想定したプロジェクトで、対象となるシステムは、200万人のユーザに影響を与えるモバイル向けのオンラインバンキングシステムでした。

しかし、D17プロジェクトが開始して直ぐに問題に直面します。自社がFirst Niagara銀行という別の銀行を買収することを決定しました。この時、買収に合わせる形で再度、D17プロジェクトを見直すべきだという話が何度もあったそうです。ただでさえ大変複雑なシステムに、新規の100万人の顧客を持ったNiagaraシステムが相乗りしてくるのです。今までのように、つなぎ合わせれば良いのでしょうか?彼らは技術的負債の返却と将来の成長を加速するために、全てを1から再設計する道を選びました。このD17プロジェクトの中身は、大きく分けて次の4つの変革項目に分かれています。

  1. アーキテクチャ ・・・新規システムはモダンにする、OSSを推進する
  2. 顧客体験 ・・・ テストし易いWidgetベースのUI、Webとネイティブアプリの違いをなくす
  3. 人 ・・・ 新しい言語スキル、柔軟なチーム編成
  4. プロセス ・・・ Agileベースのプロジェクト管理

こういった活動をボトムアップ・アプローチで実施していき、成功体験をCIOへ報告、全体的な取り組みとして広めていく流れとしてこのプロジェクトは進められました。より具体的な例をいくつか紹介していきましょう。

1つ目は、Continuous Delivery (継続的デリバリ)です。彼らにとって、デプロイパイプラインの標準化は重要な点でした。なぜなら700種類以上のアプリケーションと100以上あるプロジェクトチームがあって、それぞれ皆違うことをやっている状況で、最終的なゴールとして可能な限り共通なデリバリ基盤(OSSを始めとしたDevOpsツール群)を用意しておくことが必要でした。


171221_kato_01.png
また、こういったツールの側面だけではなく、チーム間での共通ルールを作成し、信頼性に関するルールを開発者間で共有したりもしています。具体的には、サーキットブレーカーパターンというデザインパターンを用いています。ほとんどの銀行は、FIS、VISA、MasterCardといったサードパーティーと接続していますが、サードパーティー側の障害影響を最小限に抑えるという目的で、NetflixのHystrixフレームワークを使用しています。このような洗練された分散環境のためのフレームワークを利用し、レイテンシとフォールトトレラントを制御することで、外的要因から自社アプリケーションを守ることができるのです。

次に、マニュアルテストに時間がかかっていた例をあげてみましょう。従来は、マニュアルテストがボトルネックになっていましたが、テストを自動化することで、20時間かかっていたテストが、12分以内に短縮されています。


171221_kato_02.png

こちらもツール導入だけではなく、それ以前に開発者の自動テストに取り組む姿勢、マインドセットの変革が必要になります。開発者は、TDD (Test Driven Development : テスト駆動開発 ※1)を始めとしたテクニックを駆使して、自動テストへの取り組みを行っていくことになるでしょう。こういった活動は、個人としてではなく、組織として開発する目的、テストする目的を明確にして継続的に取り組んでいく必要があります。

※1:
Kent BeckがXP(エクストリーミングプログラミング)の一部として開発したもの。Microsoft ResearchのNachi NagappanやIBMのMichael Maximilienによると、TDDを実践しているのチームのバグ密度はそうでないチームと比べて60〜90%低いが、開発時間は、15%〜35%長くなるだけだと言っています。はじめにテストを書くことにより、やりたいを明確にするメリットがりますし、CI(Continuous Integration : 継続的インテグレーション)のベースになります。これは、自動化において重要なテストコードを残すことにもなります。手戻りした時にユニットテストレベルでテストコードが残っているのといないのとでは大きな違いがでてきます。

最後は組織の話です。 小さなチームの成功体験を広めていくにあたり、Confidence Gap(立場によるプライドの違い)が弊害になります。例えば運用チームの方は、制御と信頼性に重点を置いたスタイルにならざるを得ませんし、今回発表したチームのようにイノベーティブ、変化に価値観を持つ人達もいます。KeyBankでは多様な人財確保に力をいれていくそうですが、今後は単純にアプリケーションコードを書くのに加えて、そのアプリがどのようにインフラにデプロイされて、さらには広いエコシステムの中でどのように動作するのかを理解するFull End-to-End エンジニアの採用により、こういったギャップを埋められると信じています。

また、KeyBankは、組織単位で実施する例として、Hellowalletという会社を戦略的に買収しましたが、この理由は高度なUXデザイナーやエンジニアの人材確保面という視点が大きいとのことです。このような、アクハイヤー(Acqui-hire)と呼ばれるような組織単位で必要になる外部リソースを買収という形で得ていく方法も選択肢の一つだと感じました。

Capital Oneの事例

先程紹介しましたKeyBankのように100歳を超えている銀行が事例発表している一方、Capital Oneは、設立20年に満たない若い銀行です。また彼ら自身も銀行の中ではスタートアップであると言っています。日本では知らない方も多いと思いますが、北米ではメジャーな金融サービスとして知名度があります。今回の発表で特徴的だったのは、ソフトウエア開発に関わるDNAをデジタル戦略として強調していた点です。彼らのDNAの柱となるのは、以下4つです。

  1. 自分たちのソフトは自分たちで作る
  2. パブリッククラウドを使う
  3. マイクロサービス化を推進する
  4. OSSを推進する

自社で利用するソフトウエアは買うのではなく、顧客のニーズに合わせて自分たちで作るというスタンスは、多かれ少なかれユーザ企業がチャレンジしていることだと思います。Capital Oneは、こういった活動を通して、自分たちで作ったツールはオープンソースとして公開していますし、これら以外にも合計で25のプロジェクト、109名の開発者が日々自分たちのソフトウエアを良くしようと開発を行っています。また、パブリッククラウドも含めた資源の管理をどのように行っていくかという点でも自分たちで考え、実装しています。GitHubのURLを共有しますので、ご興味のある方は以下の代表的なツールを是非ご覧になってみてください。
https://github.com/capitalone

  • Hygiene ・・・ DevOpsダッシュボード
  • cloud custodian・・・AWSを管理するためのYAMLで記載するルールエンジン
  • hydrograph・・・グラフィカルなETLツール

また、こういった自分たちで作った技術をベースに新しい形のバンキングサービスを模索しています。例えば、パブリッククラウド上で動くオンラインバンキングシステム、Amazon Alexa を使ったスキルを開発し、従来のオンラインバンキングからスピーカによる対話をベースにした残高紹介や支払いなどを提供したり、ENOと呼ばれるChatbotなど新しいインターフェースの開発を精力的に行っています。デジタル変革、ビジネス=ソフトウエアのように言われていますが、まさにそれを自分たち開発者が実践しているという熱い思い、自信のようなものを感じた発表でした。

おわりに(次回予告)

今回は、2つの銀行の事例を紹介いたしましたが、他にもAmerican Express、Barclaysなど大手金融サービスの事例も発表されていました。組織の中で変化を起こしていくことは難しく、最低でも5年くらいの年月が必要だと思います。しかし、彼らの力強いプレゼンテーションを見ていると、職能上の枠を超えた動きをして、さらにはビジネス上の目的を成し遂げるという、情熱を持ったリーダーと企業文化が成功への重要なキーになることも改めて感じました。

次回は、異なる業界の事例紹介をしていきたいと思いますので、お楽しみに!

DOESのより詳細な内容はこちらを参照ください

この記事の著者:加藤学

SB C&S株式会社
テクニカルフェロー

エンタープライズ領域での開発から運用監視までの幅広い業務経験を活かし、事業開発やマーケティングチームと一緒になってビジネスの立ち上げを行っている。日本とアメリカ、特にシリコンバレーへ滞在し、新規プロダクトの発掘調査や国内外の新規パートナーリクルーティング、技術戦略、ポートフォリオの策定など、技術をバックグラウンドにしたさまざまな活動を行っている。最近では、DevOpsを始めとした開発者向けビジネスの立ち上げを行い、プロジェクトの責任者として慌ただしい日々を送っている。


DevOps Hubのアカウントをフォローして
更新情報を受け取る

  • Like on Feedly
    follow us in feedly

関連記事

このエントリーをはてなブックマークに追加

お問い合わせ

DevOpsに関することなら
お気軽にご相談ください。

Facebook、TwitterでDevOpsに関する
情報配信を行っています。