政府のITプロジェクトは伝統的に評判が良いものではありませんでしたが、DevOpsによりついに政府のITプロジェクトが成功しようとしています。

 

政府のITの歴史における紆余曲折により、数々のプロジェクトで大規模な失敗がもたらされています。一例として、初日にクラッシュして使用不能になった医療保険制度改革の医療交換Webサイト、現在予算が10億ドル膨らみ4年の遅れが生じているアメリカ合衆国市民権・移民局のサービストランスフォーメーションプロジェクト、10億ドルが無駄になった空軍の海外での戦闘支援システム、地方自治体が数千万ドルを費やした後に廃棄された、カリフォルニア州における自動車部門とメディケード部門のITモダナイゼーションプロジェクトなどが挙げられます。

しかし、今は政府のITプロジェクトでも、ビジネスに役立つと証明されているDevOps方法論が採用されています。主に連邦レベルで使用されていますが、州および地方自治体でも採用されています。

DevOpsが有望であるのは、政府のITプロジェクトの規模によるものです。「最近のMeriTalk/Accentureによる、米国連邦政府の152名のITマネージャを対象としたアンケートの回答者のうち、職務上必要な早さで新しいシステムを開発および展開できると考えている人は、わずか13%しかいない。」とアナリストのMichael Coté氏は述べ、次のように続けています。「それを改善することによる影響は、きわめて大きなものになる可能性があります。たとえば、米国の連邦政府は、控えめに見積もっても、ITに年間840億ドルを費やしています。しかも、Standish Groupは、政府のITプロジェクトの94%が失敗すると考えています。これらはきわめて大きな数字であり、わずかな改良だけでも大きな影響を与える可能性があります。」

 

崩壊する連邦政府のITインフラストラクチャ

米国連邦政府がDevOpsに関心を持ち始めている要因は、道路や橋と同じように、その老朽化したITインフラストラクチャが崩壊しようとしているからです。何百万人もの人が利用するアプリケーションは、旧式のメインフレームなどの古いハードウェアで動作するCOBOLなどの言語で書かれています。団塊世代が定年を迎えて政府を退職する「シルバー津波」が襲う中、ハードウェアとソフトウェアを保守できる職員を見つけることはますます困難になっています。さらに、インフラストラクチャが古くなるにつれて、障害が発生しやすくなります。

これらの問題を修復するには費用がかかります。いくつかの調査により、政府のIT予算の85%がこれらのレガシーシステムの保守に費やされていることが判明しています。それにより、新しいアプリケーションの開発やイノベーション全般のための資金が減り、スマートシティのようなイニシアチブにははるかに少ない資金しか投入されていません。

一般に、前世紀からのハードウェアとソフトウェアを使用して新しいバージョンのアプリケーションを最初から開発する取り組みはうまくいっていません。元のシステムに対して行われた30～40年分の応急処置に基づいて新しいシステム全体の仕様を書くのは、複雑すぎます。それらを試みた機関は、総じて見事に失敗しています。

 

どこでDevOpsが有効に機能しているか

いくつかの連邦政府機関は、過去数年間にわたってDevOpsを使用しており、成功を報告し始めています。たとえば、NASAのジェット推進研究所 (JPL) は、古いシステムを新しいテクノロジーに移行しています。ITチームは、老朽化しているミッションクリティカルシステムから始めました。FedScoopのGreg Otto氏によると、130名の人がJPLに訪れて手動でパスワードを入力する必要があったところ、チームはDockerコンテナーでそれを解決しました。

JPLの最高技術責任者であるTom Soderstrom氏が次のように述べたことを Otto氏が紹介しています。「私たちの中の一人が、『私ならできます。アプリケーションをDockerでラップし、GovCloudに移動して、そこから実行するのです。』と言ったのです。現場から離れている人々は、『それはうまくいかない』と言いました。私は答えました。『私たちはすでにそれをやりました。うまくいっています。』」

コンテナーを使い始める方法がわかりませんか? HPEにはそのためのガイドがあります。

 

初心者向けコンテナーを取得

DevOpsの手法とツールの使用は、連邦住宅抵当金庫 (通称ファニーメイ) でも役立ちました。連邦住宅抵当金庫は、米国政府の支援を受けた企業で、住宅ローン貸付業者の主要な財源となります。事前承認された一連の開発ツールを含め、2015年にDevOpsの使用を開始してから、全体的な生産性は平均で30〜40%向上し、コストは30%削減されました。さらに、ファニーメイの全体的な品質は32%向上し、一部のプロジェクトでは最高70%の品質スコアを実現したと、InformationWeekのJohn Edwards氏は述べています。

なぜ品質が向上するのでしょうか? Advanced Technology Academic Research CenterのCEOであるTom Suder氏は、セキュリティやテストなどの重要なコンポーネントが当初から含まれているからだと語っています。Suder氏が言う「何もできない、非常に多くの依存関係を持つ単体システムを持つ代わり」に、開発を小規模で自立した部分に分割するプロセスである、マイクロサービスの使用によって開発が改善されます。

マイクロサービスの使用により、IT部門と開発部門は、開発過程で機能が徐々に変化して使いにくくなることを確実に把握できるようになります。契約要件を満たせず、予算が残っていないのに大量の欠陥があることがわかります。さらにDevOpsにより、政府機関は、複数のベンダー間で作業をより容易に分割することが可能です。Suder氏は、「彼らは常にコンペを開催しており、最良の仕事をしているベンダーを使うことができます。」と語り、次のように補足しています。「あるベンダーがいるとして、彼らが後れを取った場合、それ以上は仕事を依頼せず、より良い仕事をしているか、またはより多くのリソースを持っているベンダーに多くの仕事を割り当てます。それによってリスクが限定されるのです。」

 

グローバルに考え、ローカルにDevOpsを利用する

政府によるDevOpsの利用に関して、重点を置いているのは連邦レベルですが、州や地方自治体でも同様に利用されています。たとえば、コロラド州は、DevOpsを実装しようとしています。州のプログラムマネージャであり、DevOpsの専門家でもあるMilo Knezevic氏は、コロラド州のITスタッフはDevOpsの最大のコンポーネントは文化的変化だということを学んだ、と言います。DevOpsは、コロラド州のITスタッフが、共有とコラボレーションを可能にし、効率を高め、リソース集約的な手作業での手順を自動化するためのプロセスとツールを作成するのに役立つと同氏は述べています。

コロラド州だけではありません。220名の州の意思決定者と地方自治体のIT部門に対してアンケート調査を行った、最近のPonemon Instituteの研究である『Challenges and Trends in State and Local IT Operations: United States』によれば、回答者の38%が、次年度にDevOpsへの支出を増やすつもりであることが判明しています。また、34%がすでにDevOpsを採用していると答えており、43%は将来のどこかでDevOpsを採用する予定であると答えました。さらに、43%の人が、DevOpsはIT機能をよりシンプルにしていると感じています。

これらの機関は、小規模なアプリケーションにDevOpsを使用しているだけではありません。Ponemonによるアンケートの回答者のうち、77%がミッションクリティカルシステムでDevOpsを使用する予定であり、71%はDevOpsを人事やERPなどのバックオフィス業務で使用することを想定しています。

 

プロセスシフト

他のどの業界とも同じように、政府でDevOps方法論を実装するには、新たな考え方が必要です。政府のITプロジェクトをアジャイルな条件 (小さな改善の継続的な反復)で考えることと、ゼロからスタートする大規模な実装として考えることでは、考え方が異なります。アジャイルとDevOpsはどちらも、段階的な改善、自動化、継続的なフィードバックに依存するプロセスを採用しています。

従来の開発プロセスでは、ウォーターフォール方法論が使用されます。「大規模なRFP (提案依頼) はすたれ、ニーズ分析が一般的になります。プロジェクトは、数ヶ月単位で、最大1年間で進められます。「あなたが『これができました』と言っても、政府の職員は『これは本当に私が望んでいたものではない』と言うのです。」とSunde氏は言います。「多くの場合、政府のプロジェクトは失敗しますが、失敗の原因はコミュニケーションの欠如にあります。」と補足しています。

DevOpsの方法論を実装する上での1つの障壁は、政府の調達システムです。調達システムは、従来、DevOpsで求められている継続的な開発プロセスとは反対に、単一のプロジェクトに対して多額の資金を与えるよう作られています。「システム取得に対する従来の政府のアプローチはウォーターフォールモデルである」と、カーネギーメロン大学ソフトウェアエンジニアリング研究所の技術マネージャであるHasan Yasar氏は、DevOpsブログで述べ、さらに続けて言います。「残念ながら、このモデルは厳格な要求仕様の策定から始まることが多く、スケジュール、技術目標、全体的なプロジェクトコストの点で失敗へとプロジェクトを向かわせます。」

「この画面のほうがいいかもしれないと言われても、それをどのようにRFPに盛り込みますか?」 とSuder氏は尋ね、「どこまでやるのか、何を達成しようとするのかについて、大量の時間を割り当てる必要があります。」とコメントしています。

事実、政府のいくつかの調達仕様書通りに従うと、IT部門は、ソフトウェアが完成するまでそれをテストできない、とDevOpsへの移行を行っているアメリカ合衆国市民権・移民局のCIOであるMark Schwartz氏は言います。数分でできるような、Webページにいくつか変更を加えるだけでも、1年かかっただろうと、Schwartz氏は語っています。

結局、政府やその他の組織でDevOpsが果たす役割は、DevOpsがもたらす文化的変化だと、運輸保安庁のDevOpsプログラムマネージャであるJennifer Hoover氏は、最近のMeriTalkイベントで述べています。「DevOpsは本当に実体とかけ離れた名前です。」とJennifer Hoover氏は語り、次のように続けています。「本当なら、DevOpsにはすべての業務分野を含めるべきです。DevOpsは本質的に人に関わるものであり、文化に関わるものです。その中心にあるのがDevOpsです。IT部門は、それを定義するため、機関全体にわたっての知識取得とコミュニケーションを必要としています。」

 

リーダーとしての知恵

• DevOpsは単なる技術的な問題ではありません。文化的なものでもあります。変更管理手順を確認して、DevOpsが必要とする考え方で変化を起こすための時間と場所を人々に確保してください。
• 同様に、バックオフィス工程を確認してください。新しいプロセスを採用することは、それに対する対価を支払う仕組みがなければ役に立たないでしょう。
• テストやセキュリティといった重要な側面が最初から含まれるようにして、DevOpsのマイクロサービスコンポーネントを活用してください。