価値実現までの時間を短縮：プロセスと並列化

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

クリスマスの時期になると、決まって聞かれる嘆きがあります。屋根の上からも、ちくちくする松の枝の下からも、その声が上がります。

「電球が1つ切れると、全部消えちゃう！」

これは、直列回路でつながれた電飾に悩まされている人の叫びです。なぜそうなるのかという説明は省きますが、電球が1つ切れただけで、回路全体が遮断されてしまいます。

一方、幸運にもライトが並列回路でつながれている場合は、そうではありません。1つの電球が切れても、ほかの電球は明るく点灯し続けます。

これは、価値実現までの時間やアプリケーションとどのような関係があるのでしょうか。実は、大いに関係があります。従来型ITでは、直列回路のように本番環境への移行を進める一方、最新のアプリ開発は並列回路のように絶え間なく稼働しているからです。

プロセス

最近のブログ記事で、PivotalのグローバルフィールドCTOであるJames Urquhart氏は、製品よりもプロセスに重点を置く継続的ITの重要な全体像を示しています。これは「Path to Production」と呼ばれています。

Path to Productionという考え方は、実際にはプロセス、そして従来型ITにおける並列化を重視するものです。この概念は、最新のアプリケーション開発とアーキテクチャの中核を成します。アプリケーションを、それぞれが特定の機能に特化した個別のコンポーネント（マイクロサービスと呼ばれることもあります）に分割することで、自然と並行開発が可能になります。これは、複数の小規模なチームが異なるコンポーネントに同時に取り組むためです。最終的に、アジャイルがアプリケーション開発の速度を高め、価値実現までの時間を短縮する仕組みとして機能するのは、このためです。重要なのは、チームやアプリケーションを小さくすることではありません。アプリケーションの開発とデリバリーにこれらの概念を活用することで実現される並列化こそが重要なのです。

同じアプローチは、Path to Productionにも当てはまります。つまり、アプリケーションのスケーリングを実現し、セキュリティを確保するために必要な本番環境のコンポーネント（サービス）は、より大きなプロセスの一部であり、その一部は並行して開発、提供できます。

その妨げとなっているのが、従来型のITです。直列型のITです。ウォーターフォール型の開発手法が、本番環境にまで持ち込まれています。データがネットワーク内を順番に流れるため、ネットワークも直列の経路として構築されます。ルーターからファイアウォール、負荷分散、アプリケーションサーバー、データベースへと進みます。データは、ネットワークの一端から他端まで予測可能な経路をたどります。そのため、アプリケーションサービスも同様に、データ経路に沿った予測可能な直列プロセスで実装し、提供しています。

そのやり方は、もはや通用しません。

第1の理由は、現在ではデータパスが複数存在するためです。南北方向や東西方向を通るデータパスだけでなく、ほかの方角へ分岐するものもあります。北東方向のクラウドからスクリプトを取得し、南西方向からスプライトやWebフォントを取得し、西南東方向から地図を取得してアプリに埋め込みます。

しかし、今日、本番環境への移行プロセスを並列化する必要があるのは、データパスが分散しているからだけではありません。効率とスピードの追求、すなわち最適化もその理由です。

並列化

今日求められる価値実現までの時間を達成するために必要なスピードを確保するには、並行開発が不可欠です。これはアプリケーション開発だけでなく、コアITにも当てはまります。現在、組織で利用されているアプリケーションサービスの広がりを見ると、並列化によって導入の迅速化を図れる領域が複数あることがわかります。

従来型ITがサイロ化していること自体が問題なのではありません。そもそも、マイクロサービスアーキテクチャを採用すると、特定のアプリケーション機能に特化した小規模なサイロ型チームが数十、数百と生まれます。従来型ITは、すでにサイロの中にさらにサイロがある状態です。問題は、アジャイル開発手法では各サイロ内で並行開発が促進される一方、従来型ITでは依然として、本番環境への移行プロセスが整然とした逐次方式で進められていることです。

問題なのは、チーム間の引き継ぎと、本番環境への移行過程でネットワークトラフィックをミラーリングする方法です。このプロセスは直列的に進めるものではなく、サービスの開発と提供を並行して進められる場合は、そうすべきです。

つまり、早い段階からコラボレーションを促進する、部門横断型のチーム体制が必要です。

あらゆる領域でアジャイルプラクティスをさらに取り入れ、プロセスを並行化することで、組織は本番環境への移行をより迅速かつ効率的に進められます。

プロセスこそがプロダクト

Jamesが示唆しているように、Path to Productionは実質的に1つのプロセスであり、複数のステップで構成されています。シックスシグマのブラックベルトを持つプロセス改善の達人なら誰もが言うように、そのプロセスを高速化するには、非効率な部分を見つけて排除する必要があります。本番環境では、こうした非効率性は、厳格に直列化されたデプロイプロセスの各ステップ間に生じる待ち時間（引き継ぎ）として現れます。

ツールは役立ちます。しかし、最終的に改善するには、プロセスを徹底的に見直し、Path to Productionの一環としてアプリケーションサービスの提供を並列化できる機会を探る必要があります。

文化、特にコラボレーションを重視する文化は不可欠です。文化は行動や実践に大きな影響を及ぼします。チーム構造だけでもパイプラインの自動化は大きく変わり、従来型の単一機能チームは、DevOpsを推進する現代的なチームに後れを取っています。より連携しやすいチーム構造を推進してください。同様に、連携するチーム間では主要な指標について認識を合わせる必要があります。指標を共有することで、NetOpsとセキュリティチームは不利益を被ることなく継続的デプロイメントに取り組めます。現在、NetOpsの約4分の3は「ネットワーク稼働時間」を基準に評価されています。デプロイ頻度は、評価指標としてほとんど考慮されていません。ネットワークの稼働維持が求められているため、そこに注力することになります。指標を共有すれば、NetOpsはビジネスが必要とする、より迅速で頻繁なデプロイに注力できるようになります。

最後に、相互理解が欠かせません。全員が同じチームの一員であり、意外に思われるかもしれませんが、重視していることも同じです。NetOpsもDevOpsと同様に、パイプラインの自動化を非常に重視しています。統合、ツール、スキルセットに関する障壁への対処と克服において、DevOpsはNetOpsより10年先行していることを忘れてはなりません。チーム間で連携し、デリバリーからデプロイまでをカバーするツール（JenkinsやGitHub/GitLabなど）の標準化を推進することで、こうした取り組みを支援できます。

本番環境への道のりは、製品ではなくプロセスです。価値実現までの時間を短縮し、アプリケーションの導入を成功させるには、可能な限り連携しながら並行して進める必要があります。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事