Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. Quality cannot be inspected into a product or service; it must be built into it.
—W. Edwards Deming
学習を始めますか?
検索ツールを使用して現在の提供内容を探索するか、特定のコースについて詳しく学びましょう。
作り込み品質
作り込み品質は、ビジネス分野およびテクノロジー分野でアジャイルチームのアウトプットが、顧客バリューを創造するプロセス全体で適切な品質基準を満たすことを確認するための一連のプラクティスです。
詳細
ビジネスアジリティを支えるために、企業は市場の変化に対して継続的に対応しなければなりません。 ビジネスバリューを直接推進する作業成果物の品質は、チームがソリューションを提供する速度を直接決定します。 分野によって作業成果物は異なりますが、ソフトウェア、ハードウェアの設計、スクリプト、コンフィグレーション、画像、マーケティング資料、契約、その他の要素が含まれる可能性があります。 標準に従う安定した基盤上に構築されたプロダクトは、変更や適応が容易です。 大規模ソリューションにとって作り込み品質はさらに重要であり、些細な欠陥や誤った前提の累積が受け入れられない結果を生む可能性があります。
品質を作り込むには、継続的なトレーニングとコミットメントが必要です。 その投資を正当化するベネフィットには、以下が含まれます。
- 顧客の満足度の更なる向上
- ベロシティとデリバリーの予測精度の向上
- システムパフォーマンスの向上
- コンプライアンス要件を革新的にスケールしながら満たす能力の向上
作り込み品質は、SAFe原則6: 途切れることのないバリューフローを実現するで説明されているバリューフローの速度とリンクしています。 早期な問題の発見と是正措置は、学習をタイムラインの左にシフトすることによって実現します。 改善されたコラボレーション、ワークフローの自動化、より頻繁なデリバリー、そしてより迅速な顧客からのフィードバックは、より速い学習プロセスに貢献します。
SAFeは、5つの主要な分野に作り込み品質を適用します。 各分野には、普遍的に適用可能な一般的な実践から一つまたは数個の分野に特化したものまで、品質のプラクティスがあります。
図1は、SAFeにおける作り込み品質の考え方のまとめです。
この記事の残りの部分では、図1のコンポーネントについて詳しく説明します。
作り込み品質の分野
作り込み品質の実践は、それが適用される分野によって異なります。顧客バリューを創造するための作り込み品質アプローチの背後にある意図は同じであるにもかかわらず、実際の実践はその環境とコンテキストの複雑さを反映します。以下は、SAFeにおける作り込み品質の分野です。
ビジネス機能
ビジネス機能には、マーケティング、セールス、HR、ファイナンス、サプライチェーンマネジメント等IT以外の分野が含まれます。 ルーチン操作と共に、各機能には成功のために特定の品質のアウトプットを必要とする複雑な取組も含まれます。 例えば、新しいマーケティングキャンペーンを作成したり、新しい人事ポリシーを確立することは、一定の品質の期待を伴います。
ソフトウェアアプリケーション
ソフトウェアは、ビジネスアジリティ、ビジネスの拡張性、そしてデジタル時代における更なる競争力向上のための重要な要素です。 しかし、そのような機会を掴むためには、ソリューションを提供する際に予測可能な品質を維持することが必要です。
ITシステム
ITインフラストラクチャは、今日の企業ソリューション環境の広大なエコシステムを支えています。 ソリューションが複雑になればなるほど、それを支えるためのITシステムもより洗練されなければなりません。 企業の信頼性の高い運営を支えるために、ITシステムは高い品質基準を必要とし、したがって、適切な品質のプラクティスが必要です。
ハードウェア
コンピューター技術で使用される場合、ハードウェアは通常、ケーブル、モニター、集積回路、およびコンピューターシステムの他の有形の要素を指します。 しかし一般的にハードウェアは、具体的な物理的特性(重さ、大きさ、質感)を持つデバイスを指します。 例としては、モーター、ギア、ツール、シャーシ、ケース、そして単純または複雑なメカニズムがあります。 変更のコストが大幅に大きいため、ハードウェアシステムには品質に対するユニークなアプローチが必要です。
サイバーフィジカルシステム
サイバーフィジカルシステムは、複数の物理的要素がソフトウェアアルゴリズムによって制御される複雑なシステムです。 例としては、ロボット、航空機、自動車があります。 これらは世界で最も複雑なシステムの一部で、しばしば複雑な電気的、機械的、光学的、流体的、感覚的、および他のサブシステムを含んでいます。 その複雑さと故障の大きな影響は、そのようなシステムにおける品質の重要性を強調しています。
基本的なアジャイル品質プラクティス
基本的なアジャイル品質プラクティスは、どの分野の作業成果物にも適用できます。 これらはその価値を証明し、ナレッジワーカーがアーティファクト、作業成果物、システム、そして自分自身と顧客にベネフィットを提供するサービスの品質属性を理解し改善するための共通の出発点を提供しています。 以下のセクションでは、5つの SAFeの 基本的なアジャイル品質プラクティスを説明します。
学習のシフトレフト
すべての開発作業には、開発が進行しチームが新しい事実を学ぶにつれて表面化する多数の未知の要素が含まれています。 プロセスの後半で学習が行われると、根本的な問題がソリューションに大きな影響を与え、大幅なやり直しと遅延が生じます。 しかし、学習がかなり早く行われるか、または左にシフトされると、問題はより早く明らかになり、最小の影響で是正措置を取ることができます(図2)。
「学習のシフトレフト」は、単に一部のアクションがタイムライン上で早く行われるだけでなく、基本的なプロセスの一部の構造が変更されることも意味します。 例えば、テストファーストのアプローチは、従来のテストからの転換を必要とします。 望まれているソリューションの機能が実装される前に、可能な限りテストを行います。
ペアリングとピアレビュー
ペアワークは、2人のナレッジワーカーがリアルタイムで同じ資産に取り組むプラクティスです。 多くの場合、一方がドライバーとして直接作業成果物を進め、他方がナビゲーターとしての評価とフィードバックをリアルタイムに提供します。 チームメンバーは頻繁に役割を交代します。 作業成果物は、各メンバーの共有知識、視点、そしてベストプラクティスを含むため、ペアリングはより高い品質を生み出し、維持します。 チームメイトが互いから学び合うことで、全体のチームのスキルセットが向上し、広がります。 さらにピアレビューは、一人のチームメンバーが他のメンバーの作業成果物を調査することで、品質の問題を見つけるのに役立ちます。 たとえば、ソフトウェアを取り巻く多くのガバナンスプロセスは、コンプライアンス活動としてピアレビューを義務付けています。
共同オーナーシップとT字型のスキル
共同オーナーシップは、個々のチームメンバーが関連する資産を更新するための必要なスキルと権限を持つ品質のプラクティスです。 このアプローチは、チーム間の依存関係を減らし、個々のチームメンバーやチームがバリューのデリバリーの迅速なフローを阻害しないことを保証します。 作業成果物が一つのチームや個人に所有されないため、どの個人でも機能を追加したり、エラーを修正したり、デザインを改善したり、リファクタリングしたりすることができます。 共同オーナーシップは、一貫性を奨励する品質基準によって支えられ、すべての人が各コンポーネントの品質を理解し、維持することを可能にします。 「T字型のスキル」によって、共同オーナーシップはさらに可能になります。 T字型のスキルは、一つの領域で深い経験を持つと同時に他の領域でも広範なスキルを持つ個人を特徴付けます。また、T字型のスキルは他人とうまく働く能力をも表しています。
アーティファクト標準と完了の定義
組織が作成および維持する資産は、ビジネスに対するそのバリューを確保するのに役立つ基準を遵守しなければなりません。 これらの基準は、アーティファクトがどのように作られているか、またはそれらが示さなければならない特性を反映するかもしれません。 標準はしばしな特定の組織とソリューションコンテキストに固有であり、徐々に浮かび上がり、頻繁に検証され、複数のフィードバックサイクルによって修正されます。 アーティファクト標準を生産的に維持するためには、チームはその存在の動機を理解しなければなりません。 アーティファクトの設計プラクティスと自動化の効果的な使用は、標準を促進するのに役立ちます。 生産的なアーティファクト標準を施行することは、完了の定義(DoD)を適用することを含みます。これは作業成果物が完全で正確であることを保証するための重要な方法です。 各チーム、トレイン、そして企業は、自分たちのニーズに合った完了の定義を構築するべきです。
ワークフローの自動化
ワークフローには、多くの手動ステップが含まれる傾向があります。 一人の作業者から別の作業者への引き継ぎ、興味のある資産の検索、そして標準に対する資産の手動検査などがその例です。 事実、これらすべての手動ステップではエラーが発生しやすく、プロセスの遅延を引き起こします。 これらのタスクの多くは、チームがアクティビティをサポートするより自動化されたパイプラインに投資する時間を取ると自動化できます。 自動化は、実行コストの削減と本質的な標準への準拠により、大幅な利益を提供します。 もちろん、これはインクリメンタルに行うことができ、しばしばカンバンシステムを設置してから自動化できるステップを記録することから始まります。 項目が状態を変更された際の自動通知を設定することが最初のステップであることもあります。 さらに簡単に言えば、多くのそのようなシステムは、作業者がシステムを確認して、その状態に基づいて自分が対応可能な作業が何かを確認する真のプルシステムとして設計されています。 この場合、引き継ぎは自動的で、作業成果物の状態を知るためだけの別のコミュニケーションは必要ありません。
ビジネス品質標準
上のセクションでは、すべてのビジネス分野に適用できる5つの基本的なアジャイル品質プラクティスについて説明しています。ビジネス運営のほぼすべての側面―会計と財務、法務、営業、開発、人事、マーケティング、運用、生産など―は、内部または外部から課される品質基準の対象となり、これらはしばしばコンプライアンス要件にリンクしています。 各ビジネス機能は特定のアウトプットを生み出し、そのコンテキストに関連する品質基準を満たさなければなりません。
ビジネス機能が何であれ、俊敏で品質を達成するためのステップには次のものが含まれます。
- アジャイルチームの組織、トレーニング受講、イテレーション実行
- 機能のための標準とコンプライアンスポリシーの定義
- ワークフローのアーティファクトとアクティビティの完了の定義(DoD)についての合意
- 基本的なアジャイル品質プラクティスの実装
- 測定と学び。 特定の機能にさらに特化したアジャイルの品質プラクティスの導入
- たゆまぬ改善
アジャイルソフトウェア開発品質プラクティス
ソフトウェアは、作り込み品質を適用するための最も豊かで最も定義された領域かもしれません。 ソフトウェアは非常に複雑で無形であるため、必要に迫られたためです。 ソフトウェアは触れることも見ることもできないので、伝統的な検査、測定、テストのアプローチは不十分です。 品質が本質的に組み込まれていない場合、それが存在する可能性はほとんどありません。この新たな課題に対処するために、上記のような新しい品質プラクティスが多く生まれました。それらは品質を確保しながら速く進むことに情熱を注ぐ エクストリームプログラミング(XP)からインスピレーションを得ています。自分たちの価値を証明し、今では他の分野の品質プラクティスに影響を与え始めています。 以下のプラクティスはソフトウェア開発によく適用され、そのコンテキストでそれらを説明しますが、他の分野にも適用できます。
継続的な統合
大規模なバリューを構築するには、ナレッジワーカーがシステムをインクリメントに構築する必要があり、結果として頻繁に小さな変更が生じます。矛盾やエラーを継続的に確認し、システムの残りの部分と統合することで互換性と前向きな進捗状況を確保する必要があります。 継続的な統合 (CI)は、開発者に迅速なフィードバックを提供します(図3)。 各変更はすばやく構築され、統合され、その後、複数のレベルでテストされます。 CIは、テストと変更の移行を異なる環境で自動化し、テストが不合格になったときに開発者に通知するプロセスです。
継続的な統合は、チーム内外で非常に重要であり、すべてのコードベースの問題を迅速に特定し解決することを促進します。
テストファーストの実践
アジャイルチームは高品質なビジネスケイパビリティを迅速に開発しリリースするため、迅速なフローベースのシステムで運用します。 アジャイルチームは、統合プロセスの一部として、テストの大部分を最後に行うのではなく、早期に多くのテストを定義し頻繁に実行します。 テスト駆動開発(TDD)を使用してコードの小さな単位に対してテストを定義し、ストーリー、フィーチャー、およびケイパビリティの受け入れ基準に対してはビヘイビア駆動開発(BDD)を使用してテストを定義し、フィーチャーまたはケイパビリティのベネフィット仮説に対してはリーンUXを使用してテストを定義します(図4)。 品質を作り込むことで、アジャイル開発の頻繁な変更が新たなエラーを引き起こさないようにし、迅速で信頼性の高い実行を可能にします。
リファクタリング
絶えず変化するテクノロジーと進化するビジネスのオブジェクティブは、ビジネスバリューを維持し、継続的に増加させることを難しくします。 しかし、未来への2つの道が存在します。
- 最終的には保守不能な「使い捨て」状態に向けて、既存のコードベースに新機能を追加し続ける
- 現在のビジネスバリューだけでなく、将来のビジネスバリューを効率的に提供するための基盤を構築するために、システムを継続的にリファクタリングする
外部の動作を変えずにコードの領域の内部構造や操作を改善するリファクタリングの方が、優れた方法です。 継続的なリファクタリングにより、企業がソフトウェア資産に投資した寿命を大幅に延ばすことができ、ユーザーは今後数年にわたりバリューフローからベネフィットを得ることができます。しかし、リファクタリングには時間がかかり、費用対効果 (ROI)は即時には得られませんので、時間と労力の許容範囲をキャパシティプランニングの考慮事項に含める必要があります。 詳しくは、リファクタリングに関する詳細ガイダンス記事をご覧ください。
継続的デリバリー
継続的デリバリーは、顧客が必要とする時にいつでもバリューをリリースする能力を提供します。 これは、継続的デリバリーパイプライン(CDP)によって達成され、4つの側面(継続的な探索、継続的な統合、継続的なデプロイメント、そしてリリースオンデマンド)が含まれています。 CDPは、組織が現在のパイプラインを新しい構造にマップし、たゆまぬ改善を用いて顧客にバリューを提供することを可能にします。 ステップ内部およびステップ間、さらには顧客と企業間でのフィードバックループが改善を推進します。 内部のフィードバックループは、よくプロセスの改善に焦点を当てています。外部のループは、よくソリューションの改善に焦点を当てています。 これらの改善が集合的にシナジーを生み出し、企業が「正しいものを、正しい方法で」構築し、頻繁に市場にバリューを提供することを確実にします。 さらに、SAFe DevOpsは、迅速かつ信頼性の高いバリューのデリバリー機構を確立するための重要なプラクティス分野をその特徴としています。
継続的デリバリーは、SAFeチームのリリースオンデマンドを可能にします。 しかし品質を伴ってリリースするには、必要な品質が作り込まれていることを確認するための特定のスケーラブルな完了の定義が必要です。 図5はその例を示しています。
セキュリティプラクティスを支援するため、チームは各リリースに対して商用およびオープンソースのコンポーネントと依存関係を記述するソフトウェア部品表(SBOM)を生成し、脆弱性がないことを確認します。
アジャイルアーキテクチャ
アジャイルアーキテクチャは、システムの活動的で進化的な設計とアーキテクチャを支えるバリュー、実践、そしてコラボレーションのセットです。 それはDevOpsのマインドセットを受け入れ、システムのアーキテクチャを継続的に進化させながら、同時に現在のユーザーのニーズをサポートします。
アジャイルアーキテクチャは、コラボレーション、創発的なデザイン、意図的なアーキテクチャ、そしてデザインのシンプルさを通じてアジャイル開発プラクティスを支えます。 また、テスト可能性、デプロイ可能性、変更可能性のための設計も可能にします。 ラピッドプロトタイピング、セットベースデザイン、ドメインモデリング、そして分散型イノベーションは、それぞれがアジャイルアーキテクチャを支えています。
アーキテクチャランウェイの基本的な概念により、アジャイルチームとトレインは基礎となるアーキテクチャの仮定を段階的に検証しながら、将来のビジネスケイパビリティとフィーチャーを効果的に実現することができます。
ITシステム品質プラクティス
すべての現代の企業は、ビジネスの成功のために適切に機能するITシステムに依存しています。 ITによって駆動されるビジネスワークフローが増えるにつれて、ITシステムの信頼性、拡張性、安全性、およびセキュリティを確保することがますます重要になっています。 これらのシステムに品質を作り込むための堅牢なアプローチが必要です。 IT特有の品質プラクティスの例を以下で説明します。
IaC (コードとしてのインフラストラクチャ)
ITエコシステムの品質を確保する上での重要な課題の一つは、コンフィグレーションを一貫して定義し、維持することです。 環境パラメーターが数百や数千にも及び、コンフィグレーションが同期を失い、企業のソリューションの状況のさまざまな部分で問題を引き起こすことがよくあります。 「IaC (コードとしてのインフラストラクチャ)」はこれらのコンフィグレーションをプログラムで制御するアプローチであり、コンフィグレーションを一貫性と統合性を持って定義、調達、保守する際に自動化のベネフィットを最大限に得ることができます。 コンテナ化は、IaC (コードとしてのインフラストラクチャ)の優れたイネーブラーであり、実行環境のさまざまな側面にプログラミングインターフェースを適用することを可能にします。 さらに、「不変のインフラストラクチャ」を使用するというアプローチでは、ITコンポーネントは必要に応じていつでも再構築され、本番環境で変更されるのではなく、組織は環境へのすべての変更を明示的に制御し、変更されたコンポーネントを再デプロイすることで正式に再定義します。
非機能要件とSLA
ITインフラストラクチャは、ビジネス運営に不可欠なシステムをサポートするために、実行環境に特定の品質を提供しなければなりません。 これらの品質属性には、セキュリティ、信頼性、パフォーマンス、保守性、拡張性(非機能要件またはNFR)などが含まれます。 さらに、平均故障間隔(MTBF)や平均修復時間(MTTR)などの関連するサービスレベルアグリーメント(SLA)を確保する必要があります。 SAFeでは、NFRとSLAは早期および継続的なテストとタイムリーな是正措置によりインクリメンタルに達成されます。 システムがそのNFRとSLAを満たすことを確認するには、計測と積極的なアーキテクチャランウェイの構築と使用が必要です。
遠隔測定とモニタリング
予期しない負荷、セキュリティ攻撃、ハードウェア、ソフトウェア、ネットワークの障害への対応は、サービスのダウングレードや削除からサービスキャパシティの追加まで、さまざまな選択肢を必要とします。 遠隔測定とログのケイパビリティは、組織が自身のアーキテクチャとオペレーティングシステムを理解し、意図した負荷と使用パターンに合わせて微調整することを可能にします。 効果的な監視には、CDPを通じてデプロイされたすべてのフィーチャーに対してフルスタックの遠隔測定がアクティブであることが必要です。 モニタリングにより、システムのパフォーマンスに関する問題を予測したり本番環境で迅速に対処したりできます。
サイバーセキュリティ標準
不正アクセス、使用、開示、または破壊から保護するために、IT環境はますます厳格な品質基準を満たす必要があります。 包括的なサイバーセキュリティを達成するためのアクティビティの範囲には、以下が含まれます。
- テクノロジーの活用(データ暗号化、効率化されたアイデンティティ管理など)
- 頻繁なテストと検証(監査、侵入テストなど)
- 従業員のためのトレーニングと適切な習慣付け
- すべての新しい資産のさまざまな脆弱性のテスト
- 影響を受けるコンポーネントに関する既存ソリューションのSBOM (ソフトウェア部品表)に対する頻繁で新しい脆弱性アラートのレビューおよびパッチまたはホットフィックスの提供
ガバナンスの自動化
DevOpsや関連する方法、プラクティス、ツールの最近の進歩は、ITチームがガバナンスを自動化するための新たな機会を提供します。 自動化されたガバナンスは、面倒でエラーが起きやすい手動のアクティビティを置き換え、特にセキュリティ、コンプライアンス、および監査のニーズに対応します。 このトピックについての詳細は、参照資料[2] : Investments Unlimited, A Novel about DevOps, Audit Compliance, and Thriving in the Digital Age をご覧ください。
構成管理、監査、セキュリティテスト(構築とデプロイメントの両方で)の自動化、そして不変のインフラストラクチャは、システムの脆弱性を引き起こす可能性のある人間のエラーを減らすのに役立ちます。
アジャイルハードウェアエンジニアリング品質プラクティス
時間とともに変更のコストが増加しハードウェアの品質問題の影響は大きいので、ハードウェアシステムとコンポーネントの品質を確保することは複雑です。これには、壊滅的な現場での故障、大量の製造製品のリコール、高額な現場での交換や修理が含まれます。このリスクは、組織に対して、エンジニアリングされたハードウェアシステムとサブシステムを開発する際に、作り込み品質のプラクティスを効果的に適用するように圧力をかけます。 以下に説明するように、組織がハードウェアシステムの品質を確保するために使用するいくつかのテクニックがあります。
モデリングとシミュレーション
アジャイルの目標は、できるだけ早く構築し、学習することです。 仮想環境でのモデリングとシミュレーション、そしてプロトタイプ環境での迅速なモデリングは、図6に示すように学習のシフトレフトを支援します。
電気および機械のコンピューター支援設計(CAD)およびMBSE(下記参照)で使用されるデジタルモデルの解析とシミュレーションは、変更を迅速かつ経済的にテストできます。 デジタルツインは、運用システムから遠隔測定で収集したデータと複数の仮想モデルを組み合わせてモデルを改善し、将来のシステムの動作をより正確に予測します。 図6のフィードバックループは、他の環境からのデータがデジタル環境を検証し、改善する方法を示しています。 一部の航空宇宙および自動車プロダクトでは、認証のためにモデルシミュレーションを使用しており、変更の時間とコストを大幅に削減しています。
ラピッドプロトタイピング
仮想環境では、すべての問題を明らかにすることはできません。 物理的なプロトタイプは、実際の「曲げられた金属」のハードウェアに対する低コストの代替品です。 物理的な環境でのみ利用可能な、高精度のフィードバックを提供します。 プロトタイプのプラクティスには以下のようなものがあります。
- 木材などの低忠実度のモックアップ
- 電気部品の試作ボード
- 3Dプリントされた機械部品と電気部品(PCB、ワイヤーハーネス)
迅速な実験とプロトタイピングのコストを下げるために積層造形がますます使用されるようになってきました。 「積層造形は、コンピューター補助設計(CAD)ソフトウェアまたは3Dオブジェクトスキャナーのデータを使用して、ハードウェアに材料を層ごとに正確な幾何学的形状に堆積させます。その名前が示す通り、積層造形は物体を作るために材料を追加します。 対照的に、従来の方法でオブジェクトを作成するときは、フライス加工、機械加工、彫刻、成形、その他の手段を通じて材料を取り除くことがしばしば必要です。」[3]
「プリント」するための機器と知識を持つ多くの組織は、機械部品や電気部品を1日で製造し、出荷することができます。 そして、積層造形で作られた部品が現在、生産に取り入れられるようになってきています。
サイバーフィジカルシステムの品質実践
サイバーフィジカルシステムでは、組織がハードウェアコンポーネントとその動作を制御するソフトウェアを効果的に扱うことが必要とされます。 さらに、そのようなシステムは直接現実世界で動作するため、品質問題の影響は大きく、しばしば規制のコンプライアンスに従う必要があります。
モデルベースシステムエンジニアリング
モデルベースシステムエンジニアリング (MBSE)は、開発中のシステムを定義、設計、文書化するための一連の関連デジタルモデルを開発するプラクティスです。 これらのモデルは、伝統的なドキュメントへの依存を大幅に削減または排除しながら、システムの側面を探索、更新およびステークホルダーに伝達する効率的な方法を提供します。 モデルを用いてシステムの特性を早期にテストし検証することで、プロパティと行動の迅速な学習が促進され、要件と設計決定に対するフィードバックが迅速にできます。
頻繁なエンドツーエンド統合
ソフトウェア分野では、継続的な統合は継続的デリバリーの鼓動です。それはシステム全体で変更を確認し、仮定を検証するフォーシングファンクションです。 アジャイルチームは、開発者のすべての変更を構築し、統合し、テストする自動化とインフラストラクチャに投資し、エラーについての即時のフィードバックを提供します。
大規模なサイバーフィジカルシステムは、以下の理由から、継続的に統合することがはるかに困難です。
- 長いリードタイムの項目は利用できないかもしれない
- 統合は組織の垣根を越えて広がる
- 自動化がエンド・ツー・エンドで行われることはほとんどない
- 物理学の法則は一定の制限を定めている
代わりに、頻繁なエンドツーエンドの統合は、統合のトランザクションコストと遅延した知識およびフィードバックの経済的なトレードオフに対処します(図7)。
目標は、PIごとに少なくとも1つの完全なソリューション統合を伴う部分統合を頻繁に行うことです。
詳しく学ぶ
[1] https://en.wikipedia.org/wiki/Software_supply_chain
[2]Beal, Helen and Bill Bensing , Jason Cox , Michael Edenzon , John Willis. Investments Unlimited: A Novel about Devops, Security, Audit Compliance, and Thriving in the Digital Age, IT Revolution Press, 2022
[3] https://www.ge.com/additive/additive-manufacturing
最終更新: 2022年1月18日