PLM の DevOps:レースは始まった

Bruce Bookbinder  18 Aug 2021

ビジネスプロセスを最適化および変換するための新しい方法を探し続けるにつれて、IT 部門にはかつてないほどの依頼・要求が発生しています。既存のシステムへの微調整から、新機能実装のための大規模なプロジェクト、新機能に対応するためのソフトウェアのマイナーおよびメジャーアップグレード、または単に組織の日常的な変更管理業務など、そのかたちは様々です。変更の規模や内容に関係なく、IT部門は「課題に立ち向かい」、これらの新しい要件を迅速かつ効率的に管理して、進化する組織に対応することが期待されています。「今日のIT部門はどれだけ速く実行できるか」というゲームでは、システム開発エンジンはオーバードライブ状態にあり、ビジネスのコストを増やすことなく需要を満たすために新しいアプローチとテクノロジーが必要です。

ご列席の皆様、スターティンググリッドに並んで、DevOpsエンジンを起動してください。

テクノロジーではなく文化

DevOpsについて最初に理解することは、ソフトウェア開発(Dev)とIT運用(Ops)を統合して、組織内のソフトウェア開発と配信プロセスを改善する文化の変化を指すということです。 文化自体は、開発プロセスの速度と品質を向上させるための基本的な構造を提供します。DevOpsカルチャーの目的は、運用領域と開発チームが、設計からサポートまでのソフトウェア開発ライフサイクル全体にわたって積極的に提携し、それらの間のプロセスを自動化および統合する一連の無駄のないアジャイルプラクティスを使用することです。

この哲学の明らかな利点は、ITプレーヤー間のコミュニケーション、統合、およびコラボレーションの増加により、問題が発生したときに、プロセスまたはコーディングの問題の規模が問題の修正に時間のかかる苦労に拡大する前に、問題の特定と解決が可能になることです。重要なITプレーヤー—開発者、テスター、運用、インフラストラクチャリソースは、同じプロセスと一連のツール内で作業し、自動化された統合された方法でコードをテストおよび展開して、「迅速なフィードバックループ」とテレメトリを作成し、意思決定を迅速化します。

DevOps 対 アジャイル

DevOps について最初に学んだ人々は、DevOpsとアジャイルの間で混乱する可能性があります。それらは同じものですか?彼らは一緒に働いていますか?違いは何ですか?

DevOpsとアジャイルはどちらも、強化されたコラボレーションを通じてソフトウェア開発の速度と品質を向上させることに重点を置いていますが、それぞれがプロセスの異なるコンポーネントに重点を置いています。アジャイル手法は、顧客のビジネス要件とIT開発およびテストチームの間のギャップを埋めます。一方、DevOpsカルチャーは、IT開発チームとテストチームを運用領域と結び付けて、これらの領域全体でツールを標準化し、統合と自動化を通じてプロセスを最適化して、配信を改善します。アジャイル手法を利用している企業は、DevOpsカルチャーも採用することで、エンドツーエンドのソフトウェア開発プロセスの速度と品質をさらに向上させることができます。DevOpsにより、ITはアジャイルのペースの速いスプリントと連携して機能し、配信のボトルネックを減らすことができます。

テクノロジーの必要性

企業がDevOpsカルチャーの採用を決定した後、企業内の適切なツールとプロセスを通じてそれを実装する方法に注意が向けられます。コードベース、パイプライン、アーティファクトを管理するための適切なソフトウェアを決定し、これらのツールを緊密に統合してシームレスに機能させる方法を決定するには、かなりの労力とビジネスからの賛同が必要です。さらに、これらのプロセスの自動化と制御を実装して、すべての機能が複数の開発、テスト、および実稼働環境で機能するようにすることは困難な場合があります。環境の自動化コンポーネントがなければ、DevOpsプロセスは今日の迅速で継続的なリリースサイクルに追いつくことができません。

考慮すべき興味深いユースケースは、自動テストです。自動テストソフトウェアはしばらくの間利用可能でしたが、その採用は遅れています。採用が遅いのは、手動で複雑な実行、プロセス、およびテストスクリプトの維持により、全体的な価値提案が弱くなっているためです。DevOpsにより、これらのツールは多くの新しい注目を集めています。自動テストアプリケーションはDevOps環境に直接統合されており、コードベースが保存されるたびに自動的に実行されるように構成されています。テストは、プロセス所有者の手作業なしで、頻繁に(多くの場合は毎日でも)実行されます。結果の例外レポートを確認することで、バグが大規模な開発プロセスに影響を与える前に、バグをすばやく見つけることができます。この典型的なユースケースは、DevOpsカルチャーを実装し、適切なツールを提供する方法を示しています。

PLM向けのDevOps

多くの企業はDevOpsカルチャーを採用することの価値を明確に理解できますが、アプローチの実装は難しい場合があります。DevOps環境は、緊密な統合、自動化、および管理を必要とする複数の機能と製品で構成されているため、最初の実装は非常に複雑になる可能性があります。

PLMドメインでは、開発環境を強化するための包括的なDevOpsソリューションを提供しているソフトウェアベンダーはほとんどありません。これは、PLMソリューションをそのまま使用する企業には受け入れられるかもしれませんが、これは一般的ではありません。PLMのお客様は、ほとんどの場合、特定の要件を満たすためにソリューションをカスタマイズする必要があります。ほとんどのPLMソフトウェアは簡単にカスタマイズできず、変更を管理するためにかなりのテストが必要なため、DevOps環境の追加は変更プロセスを容易にするために特に価値があります。

Aras DevOps

では、PLMシステムの所有者はどのようにしてDevOpsカルチャーを採用するプロセスを開始し、必要なツールを実装できるでしょうか。

PLM用のDevOps製品がないことの1つの注目すべき例外は、Aras DevOpsです。Arasプラットフォームはカスタマイズをサポートするように構築されているが、環境をアップグレードする顧客の能力に影響を与えることはないため、これはArasユーザーにとって理にかなっています。Arasのすべての顧客は、特定の複雑な要件を満たすために、PLM環境をカスタマイズしたり、プラットフォーム上に独自のアプリケーションを構築したりしています。

Arasは数年前にDevOpsカルチャーを採用し、クラウドベースのDevOps環境を実現しました。これは、ソフトウェアのリリースを容易にするための最先端のツールとプロセスを統合および自動化するものです。現在、ターンキー環境でArasのお客様が同じDevOpsソリューションを利用できます。クラウド環境により、ユーザーは世界中のどこからでもユビキタスアクセスとコラボレーションが可能になります。

PLMのDevOpsレースでは、Arasが一気にゴールラインまでの到達を支援します。

Arasでは、カスタマイズをサポートするだけでなく、それを推奨しています。そのため、Aras DevOpsはエンタープライズSaaSサブスクリプションに含まれています詳細については Aras DevOps のカタログ、または Aras.com 内の Enterprise Saas のページをご参照ください