HMRC Digitalに見る公的機関のDevOps採用

ロンドンのDevOps Enterprise Summit 2016で行われた講演の中で，最も反響の大きかったもののひとつに，英国の歳入関税機関(Revenue and Customs agency)によるDevOpsと継続的デリバリ原則の導入の話題があった。彼らはそれまでの官僚的文化を脱却し，ディジタル税サービスの頻繁なデリバリへの移行，段階的な成功と失敗の容認による学習と適用を実現した。

InfoQは，発表者のひとりであるLyndsay Prewer氏に，今回の変革に着手した理由，現在の同機関の状況，これまでに経験した主な課題などについて詳しく聞くことにした。

InfoQ: あなたの現在の役割について，もう少し教えてください。

Prewer: 私はEqual ExpertsのデリバリリーダとしてHMRC Digitalとともに，HMRCのディジタルサービスのセキュリティを改善し，アクセスを容易化するための機能を提供する製品チームのリーダを務めています。そのような立場で，いくつかのチームの作業のコーディネーションや，それらのチームが小規模かつ定期的なサービスを提供する上での支援といった仕事を多く手掛けています。

InfoQ: DevOpsをいつ，どのように知ったのですか？

Prewer: 現在の仕事をする前に，ある民間団体で，年１回のリリースを毎週リリースにするための支援をしたのです。これは継続的デリバリ文化を確立する上で大きな一歩になりましたが，さらに長い道のりが残っていました。開発と運用は別々のグループのままで，それぞれにリーダがいました。次の進展を図る上では，これが大きな障害になっていたのです。ちょうどその頃，始めてDevOpsについて知りました。Phoenix Projectの記事を読んだのも同じ時期です。私たちの継続的デリバリを改善する上で，DevOps文化を確立することが重要だと気付いたのですが，同時にそれが非常に大変なことであるとも分かりました。

InfoQ: HMRC Digitalでは，DevOpsをどのように始めたのでしょう？最初のステップはどのようなもので，それはなぜでしたか？

Prewer: HMRC Digitalが始まる前のHMRCは，ITをすべてアウトソースしていていました。契約の性質としても，ドキュメントの重視，長いリードタイム，数少ないリリース，定期的な変更フリーズといった，ヘビーウェイトなデリバリプロセスの傾向があったのです。HMRC Digitalが立案された時，ひとつのチームが小規模なITソリューションの提供に集中する，定期的で段階的な開発が始められました。HMRCにはこの種の経験と文化がなかったので，立ち上げのために専門家が，他の組織から呼ばれたのです。HMRCがビジネス知識と方向性を，Government Digital Serviceがユーザニーズに基づくフレームワーク(と官僚的な形式主義を切り抜けるための支援)を，Equal Expertsを始めとするコンサルタントが，アジャイルとリーン，DevOpsプラクティスを用いた反復的ソリューションの設計と構築，デリバリに必要なスキルと経験を，それぞれ提供しました。

InfoQ: 草の根運動が中心だったのですか？あるいはDevOpsの必要性に対して，トップダウンの理解があったのでしょうか？

Prewer: HMRCは変化の必要性は知っていましたが，その方法が分からなかったのです。参加した専門家たちは，組織的変革を成功させるために，新たなアプローチが価値をもたらすことを証明する必要があると考えました。そのため創立チームはアジャイルやリーン，DevOpsのプラクティスを使って，小さな変更を早く，頻繁に，運用に乗せたのです。このよい例が，最初のオンライン税額控除更新サービスで，わずか８週間で開発されました。これを使って，たくさんのユーザが税額控除をオンラインで済ませることが可能になって，不便でコストのかかる電話や紙面のチャネルを使う必要がなくなりました。これはほんの一例ですが，他にも多くのデリバリの成功によって，HMRC Digitalに対してHMRCがさらに投資を行なうための信頼感を起こさせたのです。

活動の基本は，DevOps能力の強化を通じて製品チームが自律性と所有権を持つことを可能にする，PaaS(Platform-as-a-Service)の構築にありました。新たな製品チームがプラットフォームに参加した場合，彼らにはまず，自動ビルドとデプロイメントパイプラインというメリットが与えられます。さらに彼らの構築するサービスにおいて，さまざまなプラットフォームサービス(認証，監査，監視，警告など)を活用することができます。このことはチームを自由にすると同時に，彼らの構築したサービスの運用に彼ら自身が責任を持つ - Amazonの ”you build it, you run it” の原則に従うことになるのです。

InfoQ: HMRC Digitalでは現在，どのようなDevOpsイニシアティブが行われているのでしょう？組織変更は実施されたのでしょうか？

Prewer: 自己評価税申告書の提出期限である1月31日のHMRCのオンライントラフィックは，年を追う毎に指数級数的に増加しています。今年の自己申告のピークに備えてHMRC Digitalでは，第２のクラウドプロバイダを追加して，自分たちのプラットフォームのマルチアクティブ化を実現しました。第２プロバイダは2015年10月に選択されて12月から運用開始されていますが，製品チームと彼らのサービスに与える影響は最小限になっています。重要な要因であるスピードと成功に加えて，これほど重大なインフラストラクチャ変更の影響が最小限であった理由は，HMRC DigitalのPaaSと，製品チームの自律性にあります。50の製品チームがありますが，プラットフォームをサポートするWebOpsチームは2つだけです。プラットフォームインフラストラクチャを監視するのはWebOpsのみで，製品チームはそれぞれ自分たちのサービスに専念しています。

InfoQ: HMRC Digitalとして，さらに大きな組織にDevOpsを広める予定はありますか(あるいはすでに活動していますか)？

Prewer: HMRC DigitalのPaaSには，優れた監視警告ツール(ELK stack, Sensu, PagerDuty)が備えられています。しかしツールは使われなくては，それだけでは何の意味もありません。50チームを相手に最善の設定方法やチールの使い方のトレーニングを行なうのは，非常に難しいことです。この問題の解決には，次のようなアプローチを行いました。

1. マイクロサービスとチームをマップするサービスカタログ。

2. それぞれのチームとそのマイクロサービスに対する，管理ツールと警告ツールのセットアップの自動化。

3. さまざまなチームがこれらのツールを使って，サービスのサポート向上，さらにはユーザのサポート向上を実現している様子を紹介するための，社内ブログへの定期的な記事公開と発表会形式のセッション。

最初の２ステップは，各チームそれぞれのマイクロサービス用に事前定義されたkibanaとgrafanaのダッシュボードに，簡単にアクセスするためのものです。チームが独自のダッシュボードを作ることも可能です。

また，指定されたエラーしきい値に達すると，各マイクロサービスの担当チームに対して，自動的に警告が送信されます。しきい値はマイクロサービスごとに指定が可能で，チームがそれぞれのニーズに合わせてカスタマイズすることができます。

InfoQ: HMRC DigitalでDevOpsイニシアティブが直面した，文化的あるいは技術的な課題は，他にどのようなものがありましたか？

Prewer: HMRC Digitalは300以上のマイクロサービスが稼働するプラットフォームを所有し，運用システムに対して1日に数回のデプロイを実施しています。これらすべてが，数ヶ月というリリースサイクル，ビジネスイベントのピークを回避するための変更のフリーズ，長期にわたるエンド・ツー・エンドのテストスケジュールなどといった，従来システムと同じ状況下で実施されているのです。

ディジタルサービスをレガシシステムのバックエンドに接続する必要から，２つの文化のあつれきを経験することも何度もありました。それでも過去３年間の私たちの活動を通じて，一緒に働くためのより良い方法を学ぶことで，このあつれきを軽減することができています。頻繁に変更されるシステムに合わせて，数ヶ月だったリリースサイクルを短縮しました。変更のフリーズは当たり前ではなくなりましたし，スタブやコントラクトを使用することで，エンド・ツー・エンドテストの必要性も少なくなっています。

InfoQ: “2016 State of DevOps Report”では，DevOpsと継続的デリバリのプラクティスへの投資がより早く，より信頼性の高いビジネス価値の提供につながることが示唆されています。これは事実だと思いますか？そうであれば，これまでにあなたの組織の中で，その主張を裏付けるような具体的な例がありましたか？

Prewer: 100%同意します。私たちは当初から，反復的な方法でサービスの設計やデリバリを行なってきました。可能な限り最小のものを運用して，そこから段階的に拡張するようにしています。よい例が“Tax Account Router”です。これは2016年1月のビジネスイベントのピーク(自己申告の期限)に先立って，2015年11月に導入されたマイクロサービスで，自己申告を行なうすべてのユーザを，そのタイプ(企業，個人，代理人など)に応じて適切なランディングページに誘導することを目的とするものです。

運用開始した最初のバージョン(チーム開始から６週間)は，実際にユーザを誘導することはできませんでした – 誘導する必要のあるユーザの数の計測値を生成するだけだったのです。これによって実際のユーザに影響を与えることなく，動作を検証することができました。次にルーティングを加えましたが，範囲を限定していたので，影響を最小限に抑えながら検証することができました。これはリリースごとに小さな変更を加えて，リスクと無駄を最小限に抑えた一例です。これが可能だったのは，私たちのビルドとデプロイメントのパイプラインが，コードの変更を数時間で運用に反映することが可能だからです。これはごく普通のプラクティスや手続きに従ったものであって，決して手抜きをした訳ではありません！

InfoQ: 最後の質問ですが，HMRC DigitalのDevOpsを推進する上で，どのような課題や障害がありますか？

Prewer: DevOpsによってHMRC Digitalは，自身のディジタルサービスを，運用レベルで日々改善できるようになりました。これはビジネスとしてもユーザにとっても素晴らしいことですが，提供するサービスのニュアンスに関して，HMRCの他の部分との同期をどのように維持するか，という課題も提示しています。

HMRC Digitalは，ビジネスと開発と運用のノウハウを集結させて，焦点を絞った小規模なチームを形成することによって，サービスデリバリについて大きな進歩を遂げました。次のステップは，HMRCの広範な組織内において，統合とフィードバックを改善していくことです。