標準化は、イノベーションを阻害するものと見なされることがあります。多種多様な選択肢を捨て、より限られた選択肢を採用するよう強いられるのは、確かに窮屈に感じられます。その理由は、標準化というと、ISO 8076.905Eのような堅苦しい正式名称を持ち、チェックリストや監査担当者、監督委員会を伴う規制遵守基準を連想しがちだからかもしれません。
実際のところ、企業組織による言語、プロトコル、フレームワークの選択を規定する標準はほとんどありません（実のところ、私が思い当たるものは1つもありません）。企業における標準化を促すのは、人材の確保しやすさ、持続可能性、そしてソフトウェアやシステムの（多くの場合、かなり長期にわたる）ライフサイクル全体の総所有コストといった、より実務的な要因です。
調査によると、過去20年間におけるソフトウェアの平均寿命は約6～8年です。興味深いことに、コード行数（LOC）で測定したプログラムの規模が大きいほど、寿命も長くなる傾向があります。LOCが100万行を超えるシステムやソフトウェアの寿命は10年を超え、12～14年に及ぶと見られます。これは関係ないと思われるかもしれませんが、結局のところ、ネットワーク自動化システムもソフトウェアであり、システムであることを認識する必要があります。開発部門が提供するソフトウェアと同様に、適切な配慮、運用、保守が必要です。本番環境のパイプラインをコードとして扱うのであれば、その自動化されたパイプラインのかなりの部分がコードそのものになることを受け入れなければなりません。
したがって、そのソフトウェアやシステムが存続する間に、複数の世代の運用担当者や開発者が、更新、保守、運用、変更のデプロイを担うことは間違いありません。
そして、これはまさに標準化を推進する核心を突くものです。特にNetOpsが、ネットワークおよびアプリケーションサービスのインフラストラクチャの展開と運用を自動化し、オーケストレーションするシステムの開発と保守に本格的に取り組むうえで重要です。
サイロは農場だけに
自分（または自分のチーム）がPythonを選ぶ一方で、別のチームがPowerShellを選ぶと、スキルを共有できない運用上のサイロを事実上作ることになります。ネットワーク自動化の現状 2018によると、NetOpsが直面する最大の課題はスキル不足（49%が回答）でした。そのため、複数の言語やツールセットを導入して、さらなる障壁を生み出すのは賢明とはいえません。同様に、地域で人材を確保できない言語やツールセットを選ぶことも得策ではありません。他の組織や近隣の大学がPythonを教えているにもかかわらずPowerShellを選べば、そのシステムを扱うために必要なスキルを持つ人材の確保が難しくなります。
組織が単一の言語に標準化することはまれですが、少数の言語に絞って標準化する傾向はあります。NetOpsは、開発部門やDevOpsの標準を参考にすることで、人材プールをさらに拡大できます。
価値実現までの時間が重要
多くのNetOps組織は、継続的な運用を求めるDevOpsやビジネス部門の要求に応えるうえで、すでに後れを取っています。残念ながら、NetOpsとネットワーク自動化を取り巻く環境は異種混在であり、あらかじめ用意された統合機能はほとんどありません。State of Network Automation調査では、この「統合の欠如」が自動化における課題として2番目に多く挙げられ、NetOps担当者の47%が同意していることがわかりました。
可能な範囲でツールセットやインフラストラクチャ（アプリケーションサービスなど）を標準化することで、組織全体の統合作業に伴う負担を軽減できます。あるチームが開発したものを他のチームが活用すれば、別の自動化プロジェクトで価値を実現するまでの時間を短縮できます。再利用は、価値実現までの時間を短縮するうえで重要な要素です。開発者がオープンソースを好む傾向や、現在のアプリケーションの80～90%がサードパーティ製またはオープンソースのコンポーネントで構成されていることからも、再利用の広がりがうかがえます。これにより、開発が迅速化し、価値実現までの時間が短縮されます。同じ原則は、既存の統合を活用することでネットワーク自動化にも適用できます。
標準化のメリットを得るために、運用領域を横断して共有と再利用を促進する文化を醸成します。
イノベーションの促進
標準化は、一部で当初考えられていたようにイノベーションを妨げるものではなく、むしろその促進要因となり得ます。運用領域を横断してソフトウェアとシステムを標準化し、共有することで、多様な知見と経験を結集し、新たな要件やシステムの策定に協力できる、より強固な体制を構築できます。また、長期化することもあるオンボーディングを経ずに、新しい機能の検討、アイデア創出、実装に貢献できる人材を組織内に蓄積できます。
標準化により、使い慣れた環境を活用できるため、実装も迅速化します。同じ言語、ライブラリ、ツールセットを使い続けるほど、習熟度が高まります。その結果、生産性が向上し、既存の仕組みを一から作り直す時間を減らして、新たな機能で差別化し、価値を付加する方法の検討により多くの時間を充てられます。
標準化はチャンス
標準化は、特に使い慣れた言語やツールセットがチームで採用されなくなった場合、当初は窮屈に感じられるかもしれません。しかし、標準化を自動化システムとソフトウェアの強固な基盤を構築する機会と捉えることで、ビジネスにメリットをもたらすとともに、NetOpsが継続的デプロイのツールチェーン全体で新たな価値を生み出す機会が広がります。
ただし、標準化そのものを目的にしてはいけません。既存のスキルセットと、地域で確保できる人材を考慮してください。大学や他の企業を調査し、自動化と運用に関するスキルセットや人材の現状を把握することで、特定の言語やツールセットを採用する組織が自社だけにならないようにします。
長期的に最良の成果を得るには、標準化をセキュリティと同じように扱い、実装が完了するまで後回しにしてはいけません。自動化の取り組みの早い段階から標準化を進めることで、運用面やアーキテクチャ面の負債が重荷となり、後からの標準化が困難になる事態を回避できます。
標準化もセキュリティと同様、早めに取り組むことが重要です。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。