DevOps革命が壁にぶつかっていませんか？

多くの企業では、ソフトウェアの作成、プロビジョニング、デプロイメントが分離されています。しかし、よいニュースもあります。最新のDevOpsは、全ての人が達成可能なのです。この旅は長く続くものであり、成熟に向けてカーブを上り続ければよいのです。

多くの企業では、10人に1人の開発者が、既に書かれているコードのデプロイメントに全時間を割いています。つまり、中堅企業では、デプロイメントのための人員だけで年間約600万ドルを費やしていることになります。
 

これは問題です。過去10年間、開発者は質の高いコードを素早く書くプロセスに完全に会得してきたからです。そしてインフラチームは、素早くプロビジョニングすることに成功しています。しかし、まだデプロイに専念する人が1人いたり、各開発者がいわゆる「デリバリー関連の苦労」に時間の20～30パーセントを費やしたりしているのが現状です。これは、全てを結びつける成熟したDevOpsの実装がないためです。

これらの企業では、ソフトウェアの作成、プロビジョニング、デプロイメントが分離されています。しかしMeta、Amazon、Googleといったトップ企業でそうであるように、これらは密接に絡み合っているべきなのです。

しかし、よいニュースもあります。最新のDevOpsは、誰にでも達成可能なのです。遅すぎるということはなく、どんな実装も救えます。旅は長く続くものであり、成熟へのカーブを上り続けるだけでいいのです。

DevOps地獄に陥ったとしても、進み続けよう

ほとんどの企業で、DevOpsは大きな期待をもって展開されています。DevOpsは、スピード、スケーラビリティー、セキュリティー、競合他社に勝るイノベーションといった期待に応えなければならないのです。しかし、どこかで迷いが生じます。

時間を節約し、開発者を満足させ、セキュリティーを確保するプラクティスは全て、実際にはより多くの仕事を作り出すために共謀しているといっていいでしょう。

「おそらく、人々はツールに重点を置き、カルチャーを軽視した結果、古いカルチャーがはびこり、ワークフローがウォーターフォールみたいに、さまざまなデメリットと共に、怪しく見えるようになったのではないでしょうか。」

あるいは、責任の所在と直接的な説明責任に関するDevOpsの考え方が、古い階層的なコマンド＆コントロール文化に衝突して、負けたのかもしれません。現在、人々は命令を待ち、応答があるまで行動を起こしません。メトリクスに関する合意の欠如が、開発者とDevOpsを対立させたのかもしれません。開発者はリリースで評価され、DevOpsは壊れないことで評価されるなら、対立が起こるに違いないでしょう。

ここで重要なことがあります。これらは、DevOpsのデプロイが失敗した兆候ではありません。不完全なDevOpsデプロイの兆候なのです。中途半端で、まだ効果が見えていないということかもしれません。そして、それほど多くの追加的な労力をかけずに、その効果を得ることができるのです。

時間を節約したいのであれば、適切な専用ソフトウェアツールを使用することで、目的を達成することができます。

職人的こだわりのあるツールは、より迅速なトランスフォーメーションを支援します

「人、プロセス、技術」というニーモニックでは、まさにこの順番が重要であることは間違いありません。しかし、テクノロジーがプロセスを制定し、人々を教育する場合はどうでしょうか。

もしあなたの組織が、正しいガードレール、プラクティス、セーフガードを既に内包した最先端のDevOpsツールの導入に注力しているならば、何年にもわたる苦しい実験を飛び越えることができます。ちょうど、情報ネットワークの構築に遅れた国が、銅線をスキップして光ファイバーに一直線に飛びついたのと同じように。

機械学習（ML）によってテストが決定されれば、開発者はどのテストを実行すべきかを知る必要はありません。(そして、自動的に重要度の高い順に並べ替えられ、より早くエラーを発見できるのです）。また、デプロイメントパイプラインの構築方法について推測したり、ストレスを感じたりする必要もありません。既にセットアップされているのですから。この慣習では、人々にとって唯一の方法がベストな方法となるのです。

このようにして、まだ人によるテストのウォーターフォールに陥っている企業は、ゼロタッチ、ゼロトラストのデプロイメントに移行できるのです。

これが、クラウドのコストがかさみ、クラウドガバナンスチームを雇用せざるを得なかった企業が、その人材と時間を再利用できるようにする方法です。未使用のリソースを停止させるために世界中の人に頼るのではなく、システムに組み込まれているのです（参照：Policy As Code）。これにより、コストへの影響を評価するために製品出荷を一時停止する必要がなくなり、より高度な最適化へと移行することができます。

ソフトウェアツールは、デプロイメントの全てではなく、失敗した部分のみをロールバックすることができる方法です。そうすることで、より迅速に修正を行うことができ、また、学んだことを再びパイプラインに反映させられるのです。

多くの古い組織が、独自の内部ツールを開発することでこれを試みています。しかし、コンウェイの法則によると、そのツールは内部の未熟なプロセスを反映したものに過ぎません。さらに、これらのツールはしばしば限定的でチーム固有のものであり、部門間の調整や拡張をさらに困難にするだけです。一方、ベストプラクティスに精通し、トップのDevOpsチームからの一貫したフィードバックによって充実した組織によって構築された標準ツールまたはツールスイートは、より効果的である傾向があります。

適切なツールを導入しても、強い人材と文化が必要です。それを避けて通ることはできません。しかし、このツールは、より速く、より自信を持って仕事をするために、全ての人を強化するのに役立ちます。さらに、よりよい開発者体験（DX）を生み出すことで、さらに優秀な開発者を集め、DevOpsの成熟度を高め続けることができるという好循環が生まれます。

DevOpsの成熟度曲線

そこで、成熟度曲線に行き着きます。Cloud Native Computing Foundation (CNCF) は Cloud Native Maturity Model を開発し、私たちはそれを軽く採用し、 DevOps の成熟に取り組んでいます。CNCFプロジェクトはオープンソースであり、完全に正式とは言いにくいものですが、素晴らしい基盤を持っていると考えています。私たちの曲線は、同じ5レベルのフレームワークを使用しています。

「コンウェイの法則」によれば、ソフトウェアツールは内部の未熟なプロセスを反映したものでしかあり得ません。

企業は、成熟度曲線が上昇するにつれて、DevOpsのビジョンをより多く達成するようになります。低次の段階では、長年の開発チームと運用チームをつなぐ仲介役として、一時的にDevOpsチームが存在するだけかもしれません。高次では、そのDevOpsチームは完全な組織となり、おそらくある日、その目的が達成され、DevOpsが存在する方法となったときになくなっていくでしょう。

完全に実装されたDevOpsは、もはや物事を遅らせたり、複雑化させたりすることはありません。物事をスピードアップし、簡素化します。システムは、アクセスを制限し、パイプラインをテンプレート化することで建設的なガードレールを提供し、開発者は、自分たちができることは全てコンプライアンスに準拠しており、テストされていて、安全であると知りながら、より速く動けるようになります。そして、他の全チームは、間違ったものが本番稼働した場合、自動的にロールバックされ、部分的にでも対処されると信頼できます。(何が壊れているのか分からないような未熟な環境とは対照的です）。

あなたへの質問ですが、現在のあなたの状況はどうでしょうか？そして、この曲線は次に何を推奨しているのでしょうか？

DevOpsの可能性を最大限に引き出す

成熟度が上がれば、ビジネスの効率も上がります。アイデアから生産までのパイプライン」によって、アップデートや機能をより早く立ち上げることができ、その結果、ビジネスの競争力が高まります。

アップデートの実行がより早く、より安くなれば、ビジネスの誰もがより自由に市場に対応できます。テスト、反応、競合に打ち勝つための対応ができるのです。100万ユーザーへのスケールアップや、競合他社よりも早いアプリのリリースなど、会社の目標に開発を容易に結びられます。また、採用にも素晴らしい影響を与えます。

優れたDevOpsは、優れた開発者体験と同義です。DevOpsがボトルネックにならず、10人に1人の社員が他人のコードのデプロイに全時間を費やす必要がなくなれば、技術者にとって魅力的な雇用主となります。そして、それが持続的な好循環となるのです。

ですから、もしあなたがDevOps革命があなたの会社で壁にぶつかっていると感じているなら、それは失敗したからではないことを知っておいてください。失敗していないのです。ただ、未完成なものに過ぎないのです。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。