日本語
CI/CD (continuous integration / continuous delivery [or deployment]), DevOps, NetDevOps or SecDevOpsとしてご存知の方も多いと思いますが、これらはすべて企業が製品やサービスをより早く市場に投入し、市場での競争力を維持するために高い品質を保証するために採用しているテレコムイノベーションパイプラインに関連した話です。CI/CDの実現は大半の組織にとって最優先事項であり、競争上の優位性を決定付ける要因となっています。
通信業界のイノベーションパイプラインにおけるCTの位置づけ
CI/CDは目的である一方プロセスでもあり、プロセスを間違えば弱点にも特長にもなります。下の図では継続的テスト（CT）が呼び出されていますが、この図が間違っているのは実際にはCTはすべてのプロセスのステップに統合されているということです。そしてプロセスチェーンのどこかでCTに障害が発生するとCI/CDが保証されないことを意味します。最適なCI/CDは導入するすべての組織の目標ですが、どのように達成するかを詳しくご説明していきます。組織は実際にどのようにしてCTを達成するのでしょうか。
Jカーブ効果を考慮する
導入する組織は計画段階からステークホルダーとの間で期待値を設定する必要があります。組織のリーダーの中には早く成果を出したいと思っている人もいるかもしれません（確かにそうです！）。しかし、その期待はJカーブ効果（すべてが計画通りに進んでもDevOpsの効率化によって最適化されたラボ管理とテストの自動化のメリットが得られるまでに、生産性が著しく（しかし一時的に）低下すること）を理解した上で、正しい視点でとらえる必要があります。
その理由はテストと保証に関わるテストラボのインフラ全体を大幅に再構築する必要があり、それが決して小さな仕事ではないからです（Optimal Lab as a Service Automationにおける進化の段階に関するブログを参照）。これは大海原の真ん中で石油タンカーの舵を切るようなものだと考えてみてください。船長が決断し1分以内に伝達されたとしても実際の航海の実行は海の状況やコース調整の極端さに応じてコースを再調整するため、30分またはそれ以上かかることがあります。
これはラボの最適化だけでなく、テストや保証の自動化でも同じことが言えます。しかし外洋航海とは異なり組織には秘密兵器があります： 物理および仮想ラボ管理、テスト自動化、およびDevOpsのベストプラクティスなど、あらゆる分野の専門知識を持つエキスパートパートナーを迎え入れ、迅速に軌道修正し確実なものにすることができるのです。このアプローチについては後ほど詳しく説明します。
CTを分解する
CI/CDを採用する際、最初から関係者が固有の課題を認識する必要があります。つまり、Jカーブ効果とは別にソリューション導入の失敗につながるリスクが組織内にはあるということです。この種のソリューションに不可欠な要素である、人・プロセス・技術に集約され、すべて継続的に互いに影響し合います。潜在的な問題点の一例は以下の通りです。
人：開発部門出身のエンジニアはQAテストが信頼できないと感じることが多いそうです。テスト自動化を構築するQAエンジニアのほとんどは経験豊富なソフトウェア開発者ではないので、テストコードを将来の要件に対応できるように拡張することまで考慮していません。最悪の場合手動のアドホックテスト（再現性がない）に逆戻りしてしまいます。一方ソフトウェアエンジニアはQAエンジニアが知らない技術トレンドや優先順位に取り組んでいます。このように、テストにおけるサイロ化された誤った取り組みが、時間のかかる手作業による修正作業を引き起こし、CTの利点を損なわせてしまうことが多々あります。
プロセス：CTは一夜にして実現するものではなく、一度実現したらそれを支える技術を維持しなければなりません。予算が逼迫した場合、これはしばしば真っ先に放棄されるものの1つです。そうなるとCTが阻害され、CI/CDプロセス全体に影響を及ぼします。長期的な計画、ソリューションの持続的なメンテナンスのための予算とリソースの適切な配分は最適なCT能力を継続的に成功させるために考慮されるべきです。
技術：大きな組織内のグループ、たとえばQA部門が特定のテスト自動化に対応するために善意でDIY（Do it yourself）ラボとテスト自動化ソリューションを作成することがよくあります。しかし、異なる要件を持つ組織内のより多くの関係者に対応するためにソリューションの機能を拡張する必要がある場合、そのソリューションは拡張することができません。その結果、組織全体でCTを達成することは不可能となります。
CTを達成するための正しい戦略的アプローチの採用
本格的な導入を統合する場合でも、テスト目標を達成するためにマネージドソリューションによるラボとテストオートメーションのパートナーを選択する場合でも、フレームワークと成功に必要な要素を理解していることは大切です。多くの組織がソリューションコンポーネントに求める要件は通常、テストと保証における包括的な利点を目標としています。
CTの成功には3つのソリューション領域があり、これらはすべてシームレスに相互作用します。
1. ラボオートメーションの基礎
Lab as a Service (LaaS) ソリューションは地域間のラボとテストベッドの統合と自動化、および自動化によるラボのワークフローの最適化を実現する機能を提供する必要があります。また、共有リソースの使用スケジュール、テスト環境の迅速なモデル化とインスタンス化、ラボポリシーの確立、テストの自動実行、結果とリソース使用率の分析的可視化など、すべてをWebインタフェースで実行できることが必要です。LaaS は迅速な導入と ROI を可能にする企業向け設計で、高いスケーラビリティを備えている必要があります。
2. テスト自動化の目的
LaaSと密接に統合されたTaaS（Test as a Service）ソリューションは、ライフサイクルに渡る最も広範なドメインテストを活用できるものである必要があります。また、開発者とQA、プロバイダーとベンダーの間のコラボレーションを効率化する必要があります。環境を考慮したテストケースの管理、実行、分析などのインテリジェントな機能を備え、テストを公開、スケジュール、共有できる使い勝手の良いソリューションである必要もあります。TaaSソリューションはインテリジェントにテストを展開し、テスト時間を最小限に抑えラボから本番環境までのテスト実行を合理化するシステムを提供する必要があります。TaaSプラットフォームはユーザーがテストケースを作成、自動化、拡張できるようにし、これらのニーズすべてに対応できるようにする必要があります。24時間365日どこからでもテストが可能です。
3. DevOpsの必要性
物理インフラを統合、集中管理、仮想化し、スケーラブルなTaaS自動化ソリューションによって効率を最大化したらCT達成のための次の段階として、DevOpsとアジャイルの原則を活用します。これらはテストラボと開発・運用を統合することでソリューションの品質を高める、データ管理の改善と自動化の実践を採用しています（DevOps）。これにより再現可能な環境を通じてナレッジを容易に分散することができます。DevOpsの実践は統合された開発－QAワークフローの加速による生産性の向上を実現します。基本的にDevOpsはテストを最適化し、CTを可能にするためにすべてを統合します。
DevOpsはテストを最適化し、CTを可能にするためにすべてを統合します。
永続的なCTを実現するために必要な熟練度の広さと深さ
ソリューションのライフサイクルを通じて、またLaaS、TaaS、DevOpsに至るまで、そのランドスケープ全体を通じてソリューションは新たな要件に対応し続けなければなりません。しかし組織によっては、必要な規模で検証するために必要なインフラや専門知識を得るための時間や予算がない場合もあります。そのためテストへのアプローチを見直しその専門知識を持つソリューションパートナーを利用するケースもあります。これらのパートナーは幅広いライブラリからターンキーテストケースを提供し、社内チームだけでなくサービスプロバイダーやベンダーにもまたがるシームレスな作業を迅速かつ間違いなく達成できるよう、コラボレーション環境の構築方法に関する知識を提供します。
テストおよびラボ自動化ソリューションのパートナーは次のようなすべての新しいテクノロジーに関する深い専門知識を持っている必要があります。5G、5G コア、クラウドインフラ、セキュア SD-WAN、SDN、NFV、Open RAN、セキュリティ、Wi-Fi6/E などあらゆる最新テクノロジーに関する深い専門知識を備えている必要があります。彼らはDevOpsのベストプラクティスに後押しされたLaaSとTaaSの枠組みの中で、最先端のテストを提供することができるはずです。さらに、21世紀のテストラボの要件に対応し、サービス指向アーキテクチャをサポートする次世代技術プラットフォームを提供することも必要です。ソリューションパートナーと組むことで自社に足りない部分を埋めることの利点を理解している企業・組織は市場での競争優位を獲得するために重要な取り組みを実現しています。
ホワイトペーパー「The Criticality of Continuous Test for CI/CD Success（CI/CD成功のための継続的テストの重要性）」をご覧ください
