Official

PeopleCert DevOps Fundamentals
January 2021
Syllabus v1.0J

Official

電子メール：info@peoplecert.org, www.peoplecert.org

Copyright © 2021 PeopleCert International Ltd.
すべての著作権は、PeopleCert International Ltd.に帰属します。本資料のいかなる部分も、PeopleCert International Ltd.が書面で許可した場合を除き、いかなる形式、いかなる手段(電子的、コピー、記録、その他)でも複製や送信をすることはできません。本資料の複製、送信、またはいかなる目的であっても使用の許可に関するお問い合わせは、発行元までご連絡く
ださい。

免責事項
本資料は、読者の皆様に役立つ情報を提供することを目的としています。発行元である PeopleCert International Ltd.は、本資料の作成にあたり、あらゆる注意を払っておりますが、本資料に含まれる情報の完全性、正確性、信頼性、適合性、可用性に関して、明示的であれ黙示的であれ、いかなる表明も保証も行うものではありません。また、PeopleCert International
Ltd は、本資料に含まれている情報、指示、またはアドバイスに基づいて、またはその結果として、いかなる損失または損
害（特別、間接的、結果的なものであることを示していますが、これに限定されません）が生じたとしても、何らの責任を負うものではありません。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0J / February 2021

Page 2 of 37

Official

1. はじめに
DevOpsは、開発（Development）と運用（Operations）を組み合わせた語です。その名が示す
とおり、DevOpsはソフトウェア開発（Dev）とITの運用（Ops）を共に進めるソフトウェア開発手法です。DevOpsがめざすのは、システム開発のライフサイクルを短縮しながら、ビジネスの目的に沿ったより良いソフトウェアリリースを、より速く、より安く、高い頻度で提供することです。
そのアプローチは、3つの重要成功要因（CSF）をカバーしています。その3つとは、文化の変化、
プラクティスとプロセスの改善、自動化テクノロジの活用です。
業務に対するDevOpsアプローチは、いろいろな組織で成功を収めてきました。そのため、DevOpsに精通した人材を求める組織の数は増加の一途をたどり、業界を超えて、その人材の獲得競争が起きています。組織が求めているのは、文化を変え、DevOpsの環境で快適に働き、多数のテクノロジやツール（いわゆるツールチェーン）を使いこなして、コーディング、ビルド、テスト、
パッケージング、リリース、構成、モニタリングなどのプロセスをマネジメントできる人材です。
日々進化しているこの状況の中で、PeopleCertはDevOpsの資格を設計しました。この資格は、多くの組織が直面しているスキルギャップを解消し、ビジネス目標の実現をサポートすること、そしてコミュニケーション、標準化、コラボレーション、自動化を向上させて、高品質なソフトウェ
アプロダクトをより良く、より速く、より低コストで提供することを求める市場のニーズを反映したものです。
このニーズを反映するため、PeopleCertのDevOpsの資格は以下のような構成をしています。
•

PeopleCert DevOpsファンダメンタル（Fundamentals）：14～18時間のトレーニング
受験者は、15の基本プラクティスを通して、効果的なDevOpsを提供する方法について実践的なガイダンスを得ることができます。これは、確立されたITSM（ITサービスマネジメント）に
特に関連しています。

•

PeopleCert DevOpsリーダーシップ（Leadership）：14～18時間のトレーニング
受験者は、DevOpsのプラクティスの導入を主導する方法や、より良いコラボレーションとコミュニケーションをめざすための文化の変化を達成する方法について、ガイダンスを得ることが
できます。

•

PeopleCert DevOps エンジニアリング（Engineering）（近日発表）：
受験者は、自動化ツールの使用方法や、これらのツールがどのようにDevOpsの文化とプラクテ
ィスをサポートするかについての実践的なガイダンスを得ることができます。

PeopleCert DevOpsファンダメンタル（以下、ファンダメンタル）認定は、受験者がDevOpsの原則とプラクティスに関する知識とスキルを構築するために必要となる基本的な知識をカバーしています。さらに、PeopleCert DevOpsリーダーシップ（以下、リーダーシップ）認定（次のレベルの資格）は、DevOpsに関するより高度なスキルとプラクティスと知識をカバーしています。
これらのスキルの基礎となる知識体系は、PeopleCertがATO（Accredited Training Organization：認定教育機関）に提供した公式コースウェアで紹介しています。コースのシラバスの主な目的は、DevOpsに携わる人々の認定に必要な基本事項を紹介することです。シラバスは、この資格に関する学習によって得られる成果を文書化し、これらの成果が特定の資格レベルで達成されていることを証明するために、受験者が満たすべき要件を解説しています。
© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 3 of 37

Official

2. PeopleCert DevOps ファンダメンタル認定
2.1.

ファンダメンタル資格（基礎レベル）の目的

基礎レベル資格の目的は、受験者がDevOpsの基本的なスキルについて十分な知識と理解と応用力を持っていること、そしてDevOps環境のメンバーと共に、またはDevOps環境のメンバーの一員として効果的に仕事ができることを確認することです。ファンダメンタル資格は、この上位のリーダーシップ資格の前提条件になっています。

2.2.

対象となる受験者

ファンダメンタルレベルは、PeopleCertが提供するPeopleCert DevOps資格のスキームの初級のレベルとなっており、DevOps環境の有能なメンバーになりたい人を対象としています。受験者には、DevOpsの用語、原則、ツール、プラクティスについてしっかりとした知識と理解を持つこと、および効率的かつ効果的にツールを使いこなす応用力があることを示すことが求められます。
また、この認定は個人として認定を求める受験者にも対応しています。
この認定の資格保有者は、基本的なレベルの知識を持ち、さまざまツールを活用し、DevOpsをしっかりと理解していることを証明されます。
なお、この上位の上級／リーダーシップレベルのスキルと知識は、PeopleCert DevOps資格のス
キームの次のレベルでカバーしています。

3. 学習目標
ファンダメンタルレベルのコースで受験者が学ぶことは、DevOpsの基本的なコンセプト、用語、
原則、DevOpsに使用されるツールです。それと同時に、今日の企業におけるDevOpsの必要性、ス
クラムの方法論、人と文化の意味するものについても学びます。また、組織にDevOpsを適応させるために使用するプラクティス、プロセス、自動化、テクノロジなどについても学習します。
ファンダメンタル認定の資格保有者は、次に示すようなDevOpsの知識と理解と応用力を実証することができます。
•

DevOps の歴史と必要性•

DevOps の主要なコンセプト•

DevOps のビジネスバリュー•「C.A.L.M.S.」「3 つの道」「継続的デリバリ」そして「フルスタック」のスコープの基盤となるコンセプト•

DevOps の文化、変革的リーダーシップ、DevOps の組織構造とチーム編成•

DevOps のプラクティスの進化と、DevOps の 15 の基本プラクティス•

アジャイル型プロジェクトマネジメントとスクラムの方法論•

クラウド技術と仮想化の主要なコンセプト、デプロイメントパイプラインの自動化、および継続的デリバリのアーキテクチャ© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 4 of 37

Official

3.1.

資格スキームレベル

上記の学習目標を通して、受験者は以下に示した分野に関連する知識とスキルを実証します。

主要トピック
DevOps の紹介

アジャイル型プロジェクトマネジメント

DevOps の必要性

スクラム

DevOps の主要な原則と考え方

IT サービスマネジメント（ITSM）

フルスタック – 人と文化

仮想化

フルスタック – プロセスとプラクティス
フルスタック – テクノロジと自動化

4. ファンダメンタル試験
ファンダメンタル認定試験は、受験者が上記のようなDevOpsの基礎知識を理解しているかどうか、
また、現代の企業において、これらの知識をどのように応用してツールやプラクティスを使いこなしていくのかを検証できるように設計されています。
ファンダメンタル認定試験では、学習レベルの違いに関するブルームの目標分類学1（Bloom's
taxonomy）の認知領域における以下の2つのカテゴリに焦点を当てています。

4.1.

•

知る

•

理解する

評価アプローチ

ファンダメンタル認定で使用する評価アプローチは、「知る」と「理解する」の2つの基本的な分類に焦点を当てています。
「知る」は、事実から理論にわたって、以前に学習した内容を思い出すことと定義されます。これは、認知領域の中で最も低いレベルの学習成果を表すものです。 このような学習成果について、以下のことを知り、それを思い出すことを評価目標としています。
•

共通の および/または 基本的な用語、定義、概念、原則•

具体的なプロセス•

プロセス、手順、プロジェクトマネジメントの方法「理解する」は理解度の中で最も低いレベルであり、その過程での解釈、変換、推定などの要素を含め、教えられた教材の意味を把握する能力を必要とします。 このような学習成果や評価目標は、

1 ブルームの目標分類学では、認知領域における学習を「知る、理解する、応用する、分析する、評価する、創造する」の6つに定義している。これらのレベルを、単純なものから複雑なものへと連続的に積み上げていく。6つ目の学習レベルを達成するには、そこまでの5つのレベルを確実に習得していることが必要とされる。
© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 5 of 37

Official

単に情報を思い出すだけではなく、以下のことも含まれます。
•

事実、概念、原則の理解•

教材の解釈（コード、図、グラフ、文章、ダイヤグラム）•

使用するプロセス、手続き、方法の正当性の理解

評価は、上記の認知領域のカテゴリに対応した評価目標を使用しているため、これらの学習成果が組み込まれています。

4.2.

合格基準とトレーニングの要件

この試験には、公式の受験基準やトレーニング要件はありません。
ファンダメンタル試験の受験は、受験者が基本的なDevOpsの用語、原則、プロセス、プラクティ
ス、ツールについて知識と理解を実証する必要があります。そのため、PeopleCert認定トレーニン
グパートナーによる認定トレーニングを受講することを推奨します。

4.3.

試験の実施形式

ファンダメンタル試験の実施形式の詳細は、以下の表のとおりです。

試験配信

コンピュータ （オンライン監督付きまたは教室）

出題形式

多岐選択問題 40問

各問とも正解を１つ選択します。
試験時間

1時間（60分）

母国語以外で受験する場合や障害を持つ受験者の場合は、30分の
追加時間が認められています。
合格基準

70%（40問中28問正解）

試験監督

あり

在室の監督員またはオンライン監督です。
参考資料の持ち込み禁止

受験する室内に資料はいっさい持ち込めません。
前提条件

なし

成績優秀者対応

N/A

認定の有効期間

無期限

試験問題は、以下の仕様に基づいて定期的に更新される問題テストバンク(QTB：Question
Test Bank)から抽出した問題セットから出題されます。難易度はどの問題セットも同じレベル
で、１つの問題セットの試験の難易度は、他の問題セットの試験の難易度と同じです。受験者が複数回受験した場合でも、同じ問題セットが割り当てられることはありません。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 6 of 37

Official

5.

シラバスの詳細

シラバスは、大項目の分類と、それを細分化したセクションから構成されており、各セクショ
ンには1桁のセクション番号が付いています。合計14時間から18時間の認定トレーニングを受けることを推奨します。
カテゴリ

トピック

スキルセット参照

知識／作業項目

1.0 DevOps

1.1 DevOps

1.1.1 DevOps の定義

1.1.1.1

DevOps を定義し、何が

の紹介

とは?

DevOps で、何がそうでないかを理解します。
1.1.2 DevOps の歴史

1.1.2.1

DevOps の歴史における重要なできごとを挙げます。

1.1.2.2

DevOps ムーブメントの最前線に立つオピニオンリーダー
や重要人物を挙げます。

1.1.2.3

現在、DevOps で成功している業界や企業の事例を挙げます。

1.1.3 DevOps のフルスタ

1.1.3.1

DevOps のフルスタックの 3
つの階層を挙げます。

ック
1.1.3.2

DevOps を、文化とプラクテ
ィスと自動化のフルスタックと考えるアプローチを説明します。

2.0 今こそDevOps

2.1 ビジネス
バリュー

2.1.1 ビジネスバリューの2.1.1.1「ビジネスバリュー」を定義
します。

次元

の提供の
問題
2.1.1.2

価値を創造するうえで、ビジネスと顧客との関係を説明します。

2.1.1.3

コスト、品質、スピードというビジネスバリューの 3 つの次元をまとめます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 7 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

2.1.1.4

今日の IT とそのステークホ
ルダ、パートナー、顧客との関係に影響を与えている重要な問題をまとめます。これらの問題が、DevOps ムーブメ
ントを推進しています。

2.1.1.5

狩野モデルと、ビジネスバリ
ューと IT の関係についてのその考え方を理解します。

2.1.2 変化の外部要因

2.1.2.1

DevOps ムーブメントを推し進める組織の変化の主要な外部要因を 4 つ挙げます。

2.1.2.2

変化の 4 大要因のそれぞれが、ビジネスバリューと ITにどのような影響を与えるかをまとめます。

2.1.3 DevOps の組織上の2.1.3.1

DevOps の組織上のゴールを
挙げます。

ゴール
2.1.3.2「デジタルトランスフォーメーション」を定義します。

2.2 IT バリュ

2.2.1 IT とサイロ

2.2.1.1

組織の文化や階層が時とともに進化し、IT 内にサイロメンーの提供

タリティを生み出してきたこの問題とを説明します。
2.2.1.2

サイロ、システム思考、部分最適化が、IT がビジネスバリ
ューを提供する能力に及ぼす影響をまとめます。

2.2.1.3「サイロメンタリティ」「シス テ ム思 考 」 「混 乱の 壁 」「部分最適化」を定義します。

2.2.2 官僚主義の負の影響

2.2.2.1

官僚主義の負の影響の結果を挙げます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 8 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

2.2.3 複雑なプロセスがム

2.2.3.1

プロセスとプラクティスが時と と もに どの よう に進 化 しダを生み出すて 、 IT 内 に 冗 長 性 、 複 雑性、非効率性を生み出すに至ったのかを説明します。
2.2.4 大きな変化が必要

2.2.4.1

プロセスの冗長性、複雑性、非効率性が、 IT がビジネスバリューを提供する能力に及ぼす影響をまとめます。

2.2.4.2

現在のシステムやツールが、統合と自動化を最適にサポートできない環境はどのように作られたのかを説明します。

2.2.4.3

レガシーなシステムやツールへの依存が、IT がビジネスバ
リューを提供する能力に及ぼす影響をまとめます。

2.2.5 IT の下降スパイラ

2.2.5.1

IT 内で起こりうる下降スパイ
ラルの各ステージをまとめまル

す。
2.2.5.2

レガシーなシステムやツールへの依存が、IT がビジネスバ
リューを提供する能力に及ぼす影響をまとめます。

2.2.6 IT と DevOps

2.2.6.1「技術的負債」を定義します。

2.2.6.2

ビジネスバリューを提供できない場合、ソリューションとしての DevOps の導入に向けて進んでいる IT が、今後どのようになっていくかをまとめます。

2.2.6.3

DevOps の IT のゴールを挙げ、DevOps が IT のバランスをとるように進化するために重要な属性を 2 つ挙げます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 9 of 37

Official

カテゴリ

トピック

3.0 DevOps

3.1 C.A.L.M.

の原則と

S. と 3 つ考え方の道

スキルセット3.1.1 C.A.L.M.S.

参照

知識／作業項目

3.1.1.1「C.A.L.M.S. 」に関連する価値を挙げます。

3.1.2 3 つの道

3.1.2.1

DevOps の 3 つの道を挙げます。

3.1.2.2

第 1 の道：フローと DevOps
にとっての重要性。

3.1.2.3

制約理論についてまとめます。

3.1.2.4

第 2 の道：フィードバックとDevOps にとっての重要性。

3.1.2.5「フィードバックループ」を定義します。

3.1.2.6

第 3 の道：継続的改善とDevOps にとっての重要性。

3.2 デプロイ

3.2.1 デプロイメントパイ

メントパ

プラインを横断すイプライ

る継続的デリバリ

3.2.1.1「デプロイメントパイプライン」「継続的インテグレーシ
ョ ン 」「 継続 的デ リバ リ 」「継続的テスト」「継続的デンプロイ」を定義します。
3.2.1.2

継続的インテグレーションと継続的デリバリと継続的デプ
ロイの関係を説明します。

3.2.1.3

DevOps における継続的デリバリの重要性を説明します。

3.2.1.4

機能テストと非機能テストを比較対照します。

3.2.1.5

デプロイメントパイプラインを横断する継続的デリバリの利点を挙げます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 10 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

3.3 DevOps

3.3.1 DevOps は人と文化

3.3.1.1

DevOps を実現するカギとなのスコー

る文化の価値、一連のプロセを変えるス、そしてテクノロジについプてまとめます。
3.3.1.2

人と文化の変革者としてのDevOps の重要性をまとめます。

3.3.1.3

DevOps が人と文化を変える
主な方法を挙げます。

3.3.2 DevOps はプロセス

3.3.2.1

プロセスとプラクティスの変
革者としての DevOps の重要とプラクティスを性をまとめます。

変える
3.3.2.2

DevOps がプロセスとプラク
ティスを変革する主な方法を挙げます。

3.3.3 DevOps はテクノロ

3.3.3.1

テクノロジと自動化の変革者としての DevOps の重要性をジと自動化を変えまとめます。

る
3.3.3.2

DevOps がテクノロジと自動化を変革する主な方法を挙げます。

4.0 フルスタ

4.1 DevOps

ック：人

文化の定

と文化

義

4.1.1 組織文化4.1.1.1「組織文化」を定義します。

4.1.2 コラボレーションの4.1.2.1

DevOps 文化におけるコラボ
レーションと共有について理

重要性

解し、効果的なコラボレーシ
ョンの特性を挙げます。
4.1.2.2

病理学的文化と生成的文化を比較対照します。

4.1.2.3

DevOps 文化における、経験と継続的な学習の重要性を説明します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 11 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

4.2 変革的リ

4.2.1 変革的リーダーシッ

4.2.1.1「変革的リーダーシップ」をーダーシ定義します。

プとは ？

ップ
4.2.1.2

変革的リーダーシップの特性を示します。

4.2.2 変革的リーダーシッ

4.2.2.1

変革的リーダーシップの理解
におけるビジョンの重要性をプの原則説明します。
4.2.2.2

変革的リーダーシップの特性を理解します。

4.2.2.3

リーダーシップのスタイルを理解します。

4.2.3 チーム

4.2.3.1

自己組織的チームと伝統的チームの違いを理解し、DevOps にとって自己組織的
チ ー ムの 重要 性を 説明 し ます。

4.2.3.2

内発的動機づけと外発的強化に関する現在の主な研究成果を示します。

4.3 DevOpsの組織構

4.3.1 DevOps の組織モデ

4.3.1.1

DevOps にとっての「コンウェイの法則」の重要性を説明

ル

します。

造とチー
ム編成
4.3.1.2

組織モデルの候補を比較検討
し、DevOps 文化を最もうまくサポートする組織モデルを選びます。

4.3.2 DevOps チームの進4.3.2.1

化

DevOps にとっての自己組織的チームの重要性を説明します。また、タスク指向が
DevOps チーム内のコラボレーションの能力に及ぼす影響を説明します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 12 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

4.3.2.2

DevOps との関連において「チーム」を定義します。

4.3.2.3

DevOps のチーム編成の進化の段階を挙げます。

4.3.3 DevOps は実践的な4.3.3.1

ンとアンチパターンを挙げまスペシャリストをす。

必要とする
4.3.4 プロダクトチームとDevOps チーム編成のパター

4.3.4.1「DevOps エンジニア」を定義します。

プラットフォーム
チームへの変化
4.3.5 機能横断的チームの4.3.5.1

機能横断型チームの属性を挙げます。

構築
4.3.5.2

DevOps チーム内でのゼネラリストと純粋なスペシャリス
トとのバランスをとることの重要性を説明します。

4.3.5.3

役割ごとのサイロ構造のチー
ムと、プロダクトチームとプ
ラットフォームチームとを比較対照します。

5.0 フルスタ

5.1 DevOps

ック：プ

プラクテ

ロセスと

ィスの進

プラクテ

化

5.1.1 DevOps と他の方法

5.1.1.1

IT サービスマネジメント(ITSM：IT Service

論Management)を定義します。

ィス5.1.1.2

ITIL を、採用して適応させるべき ITSM フレームワークとして定義します。

5.1.1.3

ITIL のサービスバリューシス
テムをまとめます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 13 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

5.1.1.4

リーンを、フローを重視した
品質システムとして定義し、その原則を示します。

5.1.1.5

アジャイル宣言の価値についてまとめます。

5.1.1.6

アジャイルソフトウェアの
12 の原則を挙げます。

5.1.1.7

DevOps の 進 化 に と っ て のITSM、ITIL、リーン、アジャイルの重要性を説明します。

5.2 DevOps

5.2.1 顧客の声

5.2.1.1「顧客の声」を定義し、DevOps にとってのその重要の 15 の性を説明します。

基本プラ
クティス
5.2.1.2

有用性と保証のコンセプトを比較対照します。

5.2.1.3「 重 要 品 質 要 因 （ CTQ ：Critical To Quality ）」を定義します。

5.2.2 関係管理

5.2.2.1

関係管理プラクティスの目的をまとめ、DevOps にとってのその重要性を説明します。

5.2.2.2

事業関係マネージャ（BRM： Business

RelationshipManager）の役割についてまとめます。
5.2.3 リーンプロセス最適

5.2.3.1

DevOps にとってのリーンプ
ロセス最適化のプラクティス化の重要性を説明します。
5.2.3.2

リーンの３種類の作業を比較対照します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 14 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

5.2.3.3

リーンが特定するムダの 8 つのカテゴリを挙げます。

5.2.4 バリューストリーム

5.2.4.1

DevOps にとってのバリュー
ストリームマッピングのプラ

マッピング

クティスの重要性を説明します。
5.2.4.2

バリューストリームマッピン
グのプラクティスの主要構成
要素をまとめます。

5.2.5 ナレッジ管理

5.2.5.1

DevOps における「ナレッジ管理」を定義し、DevOps にとってのその重要性を説明します。

5.2.5.2

DIKW モデルに沿って、デー
タと情報とナレッジと知恵の関係をまとめます。

5.2.5.3

DevOps におけるナレッジ管理システムの例を挙げます。

5.2.6 目に見える管理

5.2.6.1

DevOps にとっての目に見える管理のプラクティスの重要性を説明します。

5.2.6.2

目に見える管理が、フローの管理と WIP 制限の実現にどのように役立つかを説明します。

5.2.6.3

カンバンボードの主要属性を挙げます。

5.2.6.4

リーンにおける「プル」を定義します。

5.2.6.5「WIP（Work in Progress：
進行中の作業）制限」を定義します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 15 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

5.2.7 アジャイル型プログ

5.2.7.1

DevOps にとってのアジャイ
ル型プログラムマネジメント

ラムマネジメントとスクラムのプラクティスのとスクラム重要性を説明します。
5.2.7.2「スクラム」を定義します。

5.2.7.3

スクラムの 3 本柱についてまとめます。

5.2.7.4

アジャイルスクラムのプラク
ティスの主要構成要素をまとめます。

5.2.8 シフトレフトテスト

5.2.8.1

DevOps にとってのシフトレ
フトテストのプラクティスの重要性を説明します。

5.2.8.2「シフトレフトテスト」を定義します。

5.2.8.3

品質第一アプローチの利点を説明します。

5.2.8.4「テスト駆動開発」を定義します。

5.2.9 変更コントロール

5.2.9.1

DevOps にとっての変更コントロールのプラクティスの重要性を説明します。

5.2.9.2

ITIL にしたがって管理しなけ
ればならない 3 つの変更の種類を比較対照します。

5.2.9.3

伝統的な ITIL の変更コントロールと承認プロセスについてまとめます。

5.2.9.4

DevOps 環境において、変更
コントロールをどのように適応させるべきかをまとめます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 16 of 37

Official

カテゴリ

トピック

スキルセット5.2.10 サービス構成管理

参照

知識／作業項目

5.2.10.1

DevOps における「サービス構成管理」を定義し、DevOps にとってのその重要性を説明します。

5.2.10.2「 IAC （ Infrastructure As
Code）」を定義します。

5.2.11 リリース管理とデ

5.2.11.1

DevOps における「リリース管理とデプロイメント管理」

プロイメント管理を定義し、DevOps にとってのその重要性を説明します。
5.2.11.2

DevOps におけるリリース管理とデプロイメント管理の主要技法を挙げます。

5.2.11.3「ブルーグリーンデプロイメ
ント」を定義します。

5.2.12 インシデント管理

5.2.12.1

DevOps にとってのインシデ
ント管理のプラクティスの重要性を説明します。

5.2.12.2

DevOps 環境において、インシデント管理をどのように適応 さ せる べき かを まと め ます。

5.2.12.3

ITIL によるインシデントと問題の定義を比較対照します。

5.2.13 問題管理とカイゼ

5.2.13.1「カイゼン」を定義し、DevOps にとって問題管理とン

カイゼンの重要性を説明します。
5.2.13.2

DevOps 環境において、問題管理をどのように適応させる
べきかをまとめます。

5.2.13.3

DMAIC サイクルのステップをまとめます。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 17 of 37

Official

カテゴリ

トピック

スキルセット5.2.14 継続的改善

参照

知識／作業項目

5.2.14.1

DevOps にとっての継続的改善のプラクティスの重要性を説明します。また、継続的改善段階のプロセスと DevOpsとの関係を説明します。

5.2.14.2

DevOps にとっての標準化の重要性を説明します。

5.2.14.3「継続的改善記録簿（CIR：
Continual

Improvement

Register）」を定義し、継続的改善がどのようにフルスタック全体に方向性を与え、サポートするかを説明します。
5.2.15 耐脆弱性

5.2.15.1「耐脆弱性」を定義し、DevOps にとっての耐脆弱性のプラクティスの重要性を説明します。

5.2.15.2

災害復旧と対障害弾力性と耐脆弱性の違いを理解します。

5.2.15.3

耐脆弱性を実現する方法の例と し て 、 Netflix が Chaos
Monkey と Chaos Kong で使用して成功したプラクティス
をまとめます。

5.2.15.4「カオスエンジニアリング」
を定義します。

6.0 フルスタ

6.1 デプロイ

ック：テ

メントパ

クノロジ

イプライ

と自動化

ンの自動

6.1.1 自動化とフルスタッ

6.1.1.1

DevOps にとっての、ツールと自動化の重要性を説明しま

ク

す。

化
6.1.2 デプロイメントパイ

6.1.2.1

プラインの自動化

ツールチェーンをどのように利用すればデプロイメントパ
イプラインの自動化に役立つかを説明します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 18 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

6.1.3 DevOps ツールチェ

6.1.3.1

DevOps ツールチェーンにおいて、デプロイメントパイプ

ーンのツールラインの各段階で利用できるツールの例を挙げます。
6.1.3.2

DevOps ツールチェーンの代表的な要素を挙げます。

6.1.4 DevOps の自動化の6.1.4.1

自動化と継続的デリバリの導入を行うとき、組織が経るこ段階とになる成熟度の各段階をまとめます。
6.2 クラウド

6.2.1 クラウド技術とクラ技術と仮ウドコンピューテ

想化

ィングの出現6.2.1.1

クラウド技術と仮想化サービ
スと DevOps の関係を説明します。

6.2.1.2

クラウドコンピューティングの基本特性を挙げます。

6.2.1.3

クラウド技術と仮想化サービ
スと DevOps の関係を説明します。

6.2.2 クラウドコンピュー

6.2.2.1

クラウドコンピューティングの 3 つのデプロイモデルを比ティングのデプロ

較対照します。

イモデルとサービスモデル
6.2.2.2

クラウド技術の歴史におけるキープレイヤを挙げます。

6.2.2.3

伝統的なオンプレミスから
SaaS （ SoftwareasaService）に至るクラウドコ
ンピューティングのサービスモデルの進化を説明します。
6.2.2.4「 XaaS （ Everything as aService ） 」 と 「 EaC （Everything as Code）」を定義します。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 19 of 37

Official

カテゴリ

トピック

スキルセット参照

知識／作業項目

6.3 継続的デ

6.3.1 プロダクトチームと6.3.1.1

DevOps チームをどのようにリバリのプラットフォーム

ためのア

チーム

構成すれば、クラウドの原則と役割を採用できるかを説明
します。

ーキテク
チャ
6.3.2 コンテナ化とマイク

6.3.2.1「コンテナ化」を定義します。

ロサービス
6.3.2.2

DevOps にとってのコンテナ化の重要性を説明します。

6.3.2.3

モノリシックアーキテクチャとマイクロサービスアーキテ
クチャを比較対照します。

6.3.2.4

マイクロサービスの利点を挙げます。

6.3.3 API （ Application

6.3.3.1

ション」と「ストラングラー

Programming

アプリケーションパターン」

Interface）

6.

「ストラングラーアプリケー

を定義します。

出題比率
ファンダメンタル試験は、以下の6つのセクションで構成されています。

カテゴリ

内

容

出題比率 (%）

1.0

DevOps の紹介

5.0%

2.0

今こそ必要な DevOps

10.0%

3.0

DevOps の原則と考え方

15.0%© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 20 of 37

Official

4.0

フルスタック ― 人と文化

20.0%

5.0

フルスタック ― プロセスとプラクティス

30.0%

6.0

フルスタック ― テクノロジと自動化

20.0%

計

100.0%© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 21 of 37

Official

7. 参考情報1.

Basiri, Ali, Lorin Hochstein, Abhijit Thosar, and Casey Rosenthal. “Chaos Engineering

Upgraded,” The Netflix Tech Blog, September 24, 2015. Accessed May 22, 2018.
https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa
2.

Bass, Len; Weber, Ingo; Zhu, Liming (2015). DevOps: A Software Architect's Perspective.
ISBN 978-0134049847.

3.

Baukes, Mike. “The Best DevOps Resources Online,” UpGuard (blog), April 4, 2017.
Accessed May 8, 2018. https://www.upguard.com/blog/devops-resources-online

4.

Beedle, Mike, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith,Andrew Hunt, Ron Jeffries, et al., n.d. “Manifesto for Agile Software Development.”

agilemanifesto. Accessed May 9, 2018. http://agilemanifesto.org/
5.

Bhargava, Rajat. “Is DevOps a Title?” DevOps.com (blog), March 20, 2014. Accessed May
8, 2018. https://devops.com/is-devops-a-title/

6.

Birrell, N.D., Ould, M.A. “A Practical Handbook for Software Development” . Cambridge,
UK: Cambridge University Press, 1985. I(SBN 0-521-25462-0).

7.

Brown, Kyle G. “Apply the Strangler Application Pattern to Microservices Applications.”IBM.

February

13,

2017.

Accessed

May

28,

2018.

https://www.ibm.com/developerworks/cloud/library/cl-strangler-application-patternmicroservices-apps-trs/index.html
8.

Cannon, David. ITIL Service Strategy. London: TSO (The Stationery Office), 2011.

9.

Carr, Nicholas, W.W Norton and Company, n.d . “Book Review: The Big Switch: Rewiring

the World, From Edison to Google.” Review of The Big Switch: Rewiring the World, From
EdisontoGoogle,byMike

e-Zine.

Evans.

AccessedMay

9,

2018.http://www.cambashi.com/contentmgr/showdetails.php/id/1865/page/3
10.

Caum, Carl. “Continuous Delivery Vs. Continuous Deployment: What's the Diff?” Puppet(blog), August 30, 2013. Accessed May 8, 2018.

11.

Ceresani, Necco. “9 Companies You Wouldn’t Expect To Be Using DevOps,” XebiaLabs(blog),

September

11,

2015.

Accessed

May

8,

2018.

https://blog.xebialabs.com/2015/09/11/9-companies-you-wouldnt-expect-to-beusing-devops/
12.

Cockcroft,

Adrian,Microservices.YouTube,

MesosCon.

Keynote:44:06.

Cloud
AugustTrends,DevOps,
26,

and
2015.

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 22 of 37

Officialhttps://www.youtube.com/watch?v=c0wSmr-u5vQ
13.

Cohn, Mike. “Two Types of Authority Leaders Must Give to Self-Organizing Teams,”

Mountain Goat Software (blog), August 15, 2017. Accessed May 8, 2018.
https://www.mountaingoatsoftware.com/blog/two-types-of-authority-leaders-mustgive-to-self-organizing-teams
14.

Conway,Melvin.

“Conway’s

Law.”

Accessed

June

25,

2019.

http://www.melconway.com/Home/Conways_Law.html
15.

Davis, Jennifer and Ryn Daniels.

(2016).

Effective DevOps: Building a Culture ofCollaboration, Affinity, and Tooling at Scale. Sebastopol, CA: O'Reilly Media. ISBN 978149192630).
邦訳『Effective DevOps ― 4本柱による持続可能な組織文化の育て方』オライリージャパン（2018/3/24） 978-4873118352

16.

DevOps Enterprise Forum 2016, n.d. “Evaluating Organizational Models With a DevOps

Lens.”IT

Revolution.

Accessed

May

2,

2018.

http://itrevolution.com/devops_enterprise_forum_guidance/
17.

Earnshaw, Aliza. “Why I Hired a DevOps Engineer: Bess Sadler of Stanford University,”

Puppet (blog), July 30, 2013. Accessed May 8, 2018. https://puppet.com/blog/why-ihired-a-devops-engineer-bess-sadler-of-stanford-university
18.

Edwards, Damon. (2013-07-23).

Platform".

"Integrating DevOps tools into a Service Delivery

http://dev2ops.org/2012/07/integrating-devops-tools-into-a-service-delivery-platform-video/
19.

Floyd, David. “Who Killed Sears? 50 Years on the Road to Ruin.” Investopedia. Last
modified

April

23,

2018.

Accessed

May

9,

2018.

https://www.investopedia.com/news/downfall-of-sears/
20.

Forsgren, Nicole, Gene Kim, Jez Humble, Alanna Brown, and Nigel Kersten. “2017 State of

DevOps Report. See the Difference DevOps Makes—and How to Get There.” Puppet.
2017. Accessed May 8, 2018. https://puppet.com/resources/whitepaper/state-ofdevops-report
21.

Fowler, Martin. “How to Break a Monolith into Microservices.” MARTINFOWLER.COM.
April 24, 2018. Accessed May 28, 2018. https://martinfowler.com/articles/breakmonolith-into-microservices.html

22.

Fowler, Martin. “InfrastructureAsCode.” MARTINFOWLER.COM. March 1, 2016.
Accessed May 22, 2018. https://martinfowler.com/bliki/InfrastructureAsCode.html© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 23 of 37

Official

23.

Gilbert, Clark, and Joseph L. Bower. “Disruptive Change When Trying Harder Is Part of
the Problem.” Harvard Business Review. May 2002. Accessed May 9, 2018.
https://hbr.org/2002/05/disruptive-change-when-trying-harder-is-part-of-theproblem

24.

Gleeson, Brent, and Megan Rozo. “The Silo Mentality: How to Break Down the Barriers.”
Forbes.

October2,

2013.

Accessed

May

9,

2018.

https://www.forbes.com/sites/brentgleeson/2013/10/02/the-silo-mentality-how-tobreak-down-the-barriers/#5783e43a8c7e
25.

Goldratt, Eliyahu, and Jeff Cox. The Goal: A Process of Ongoing Improvement .
Massachusetts: The North River Press, 2004.
邦訳『ザ・ゴール ― 企業の究極の目的とは何か』ダイヤモンド社 (2001/5/18) 978-4478420409

26.

Gruver, Gary, Tommy Mouser and Gene Kim (foreword).

(2015).

Leading theTransformation: Applying Agile and DevOps Principles at Scale. IT Revolution Press. ISBN
978-1942788010.
邦訳『変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】』技術評論社(2017/1/25) 978-4774186634

27.

Hackman, J. Richard. “The Psychology of Self-Management in Organizations.” In

Psychology and Work: Productivity, Change, and Employment, by Pallack M.S. and Perloff
R.O. Washington, DC: American Psychological Association, 1986.
28.

Harvey, Cynthia (2017-09-01). "10 Ways DevOps is Changing the Enterprise".
https://www.datamation.com/data-center/slideshows/10-ways-devops-is-changingenterprise-it.html

29.

Hassan, Qusay F. “Demystifying Cloud Computing.” CrossTalk, Jan/Feb 2011. Accessed
May

9,

2018.

https://static1.1.sqspcdn.com/static/f/702523/10181434/1294788395300/201101Hassan.pdf
30.

Humble, Jez, and David Farley. “Continuous Delivery: Anatomy of the Deployment

Pipeline.”

informIT.

September

7,

2010.

Accessed

May

8,

2018.

http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2
31.

Humble, Jez, Joanne Molesky, and Barry O’Reilly. Lean Enterprise—How High Performance
Organizations Innovate at Scale. California: O’Reilly Media, Inc., 2015.
邦訳『リーンエンタープライズ ― イノベーションを実現する創発的な組織づくり』オライリージャ
パン (2016/10/15) 978-4873117744© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 24 of 37

Official

32.

Humble, Jez, n.d. “What Is Continuous Delivery?” Continuous Delivery. Accessed May 28,
2018. https://continuousdelivery.com/

33.

Hunter, Tim. “A Personal Reinterpretation of the Three Ways.” IT Revolution. July 10,
2013. Accessed May 8, 2018. https://itrevolution.com/a-personal-reinterpretation-ofthe-three-ways/

34.

Jesuthasan, Ravin, and John Boudreau. “Thinking Through How Automation Will AffectYour Workforce.” Harvard Business Review. April 20, 2017. Accessed May 9, 2018.
https://hbr.org/2017/04/thinking-through-how-automation-will-affect-your-workforce

35.

Kim, Gene and Kevin Behr (2018). The Phoenix Project: A Novel about IT, DevOps, andHelping Your Business Win 5th Anniversary Edition. IT Revolution Press. ISBN 978194278829).
邦訳『The DevOps 逆転だ!』日経BP(2014/8/12) 978-4822285357

36.

Kim, Gene, Patrick Debois, Hohn Willis, Jez Humble (2016). The DevOps Handbook: How
to Create World-Class Agility, Reliability, and Security in Technology Organizations.
Portland, OR: IT Revolution Press. ISBN 978-1942788003.
邦 訳 『 The DevOps ハ ン ド ブ ッ ク 理 論 ・ 原 則 ・ 実 践 の す べ て 』 日 経 BP (2017/6/22) 9784822285487

37.

Kim, Gene. “The Three Ways: The Principles Underpinning DevOps.” IT Revolution .
August 22, 2012. Accessed May 8, 2018. https://itrevolution.com/the-three-waysprinciples-underpinning-devops/

38.

Kumar, Ajoy. “How ‘Everything as Code’ Changes Everything?” WordPress (blog). March
9,

2016.

Accessed

May

28,

2018.

https://cloudmatters.wordpress.com/2016/03/09/how-everything-as-code-changeseverything/
39.

Kumar, Ajoy. “Infrastructure and How ’Everything as Code’ Changes Everything.” BMC(blog).

August17,

2016.

Accessed

May

28,

2018.

https://www.bmc.com/blogs/infrastructure-everything-code-changes-everything/
40.

Loukides, Mike (2012-06-07). "What is DevOps?” http://radar.oreilly.com/2012/06/whatis-devops.html

41.

Mann, Andi. “Four Key Vectors for Closing the DevOps Feedback Loop,” DevOps.com(blog), September 29, 2014. Accessed May 8, 2018. https://devops.com/four-keyvectors-closing-devops-feedback-loop/

42.

Mayer, Chris. “S Is for Sharing Tells the Father of DevOps, Patrick Debois,” JAXenter.

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 25 of 37

Official

October 17, 2012. Accessed May 8, 2018. https://jaxenter.com/s-is-for-sharing-tellsthe-father-of-devops-patrick-debois-105077.html
43.

Mello Jr., John P., n.d. “The Best DevOps Conferences of 2018.” TechBeacon. Accessed
May 8, 2018. https://techbeacon.com/best-devops-conferences-2018

44.

Meyer, Bertrand. “Practice to Perfect: The Quality First Model.” EiffelSoft , (1997): 102–
106.

Accessed

May

22,

2018.

http://se.inf.ethz.ch/~meyer/publications/computer/quality_first.pdf
45.

Middelburg, Jan-Willem. Service Automation Framework. Netherlands: Van Haren
Publishers, 2016.

46.

Mirchandani, Sanjay. The State of DevOps in 2017: Transformational Leadership Is Key.
By

Chris

Cancialosi.

Forbes,

June

19,

2017.

Accessed

May

8,

2018.

https://www.forbes.com/sites/chriscancialosi/2017/06/19/the-state-of-devops-in2017-transformational-leadership-is-key/#7cb8b17c63dc
47.

Mueller, Ernest. “What Is DevOps?” the agile admin (blog), July 24, 2017. Accessed May
8, 2018. https://theagileadmin.com/what-is-devops/

48.

Newman, Lily Hay. “How Netflix DDoS’d Itself to Help Protect the Entire Internet.”

WIRED.

Last

modified

July

28,

2017.

Accessed

May

22,

2018.

https://www.wired.com/story/netflix-ddos-attack/49.

Null, Christopher, n.d. “10 Companies Killing It at Devops.” TechBeacon. Accessed May
8, 2018. https://techbeacon.com/10-companies-killing-it-devops

50.

Null, Christopher, n.d. “Infrastructure as Code: The Engine at the Heart of DevOps.”
TechBeacon. Accessed May 22, 2018. https://techbeacon.com/infrastructure-codeengine-heart-devops

51.

Nygard, Michael. “The New Normal: Embracing Failure With Netflix, The Chaos Monkey,

and Chaos Kong.” cognitect (blog), March 24, 2016. Accessed May 22, 2018.
http://blog.cognitect.com/blog/2016/3/24/the-new-normal-embracing-failure-withnetflix-the-chaos-monkey-and-chaos-kong
52.

O’ Reilly FREE media/e-books available @ https://www.oreilly.com/webops/free/53.

Panko, Riley. “The Elusive Definition of DevOps,” DevOps.com (blog), February 14, 2017.
Accessed May 8, 2018. https://devops.com/elusive-definition-devops/

54.

Rafferty, Alannah Eileen, and Mark Griffin. “Dimensions of Transformational Leadership:

Conceptual and Empirical Extensions.” The Leadership Quarterly 15, no. 3 (2004): 329–
354.
© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 26 of 37

Official

55.

Rivington, Mark. “Secrets to Collaboration in DevOps.” DevOps.com. April 7, 2014.
Accessed May 8, 2018. https://devops.com/secrets-collaboration-devops/

56.

Schien, Edgar H. Humble Inquiry: The Gentle Art of Asking Instead of Telling. California:
Berrett-Koehler Publishers, Inc., 2013.

57.

Schien, Edgar H. The Corporate Culture Survival Guide. California: Jossey-Bass, 2009.

58.

Schouten, Edwin. “Cloud Computing Defined: Characteristics and Service Levels.” IBM(blog). January 31, 2014. Accessed May 28, 2018. https://www.ibm.com/blogs/cloudcomputing/2014/01/31/cloud-computing-defined-characteristics-service-levels/

59.

Schwaber,

Ken

&

Jeff

Sutherland,“SCRUM

Guide”,

http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-GuideUS.pdf#zoom=100, 2016.
60.

Shafer, Andrew Clay, n.d. “Eating Sushi With Andrew Clay Shafer.” Produced by Arrested
DevOps.

Podcast,MP3

audio,

41:10.

Accessed

May

9,

2018.

https://www.arresteddevops.com/eating-sushi-with-andrew-clay-shafer/
61.

Skelton, Matthew. “What Team Structure Is Right for DevOps to Flourish?” Matthew

Skelton(blog),

October

22,

2013.

Accessed

May

8,

2018.

https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-fordevops-to-flourish/
62.

Steinberg, Scott. “Twenty Surprising Mobile Stats for 2016: The Smartphone Takeover.”Mobile Business Insights. June 29, 2016. Accessed May 28, 2018.
63.

Taylor, Twain. “The Top 10 Thought Leaders in DevOps,” Sweetcode (blog), May 8, 2017.
Accessed May 8, 2018. https://sweetcode.io/top-10-thought-leaders-devops/

64.

Thompson, Lee. “Q&A: Lee Thompson, Former Chief Technologist of E*TRADE

Financial.” By Damon Edwards. dev2ops, September 28, 2009. Accessed May 9, 2018.
http://dev2ops.org/2009/09/qa-lee-thompson-former-chief-technologist-of-etradefinancial/.
65.

Vehent, Julien. (2018). Securing DevOps: Security in the Cloud. Manning Publications.
ISBN 978-1617294136.

66.

Walls, Mandy. (2013). Building a DevOps Culture. O'Reilly Media. ISBN 978-1-44936893-7

67.

Watkins, Michael D. “What Is Organizational Culture? And Why Should We Care?” Harvard

Business Review. May 15, 2013. Accessed May 8, 2018. https://hbr.org/2013/05/whatis-organizational-culture.
© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 27 of 37

Official

68.

Westrum, R. “A Typology of Organisational Cultures.” Qual Saf Health Care 13, suppl. II(2004): ii22–ii27.

69.

Wilsenach, Rouan, n.d. “3 DevOps Techniques for Stress-Free Release Management.”

TechBeacon. Accessed May 22, 2018. https://techbeacon.com/3-devops-techniquesstress-free-release-management
70.

Womack, James P., and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealthin Your Corporation. New York: Free Press, 2003.
71.

AXELOS Limited. ITIL® Foundation ITIL 4 Edition. TSO, 2019.

72.

“2016

State

of

DevOpsReport.”Puppet.

Accessed

May

28,

2018.

https://puppet.com/resources/whitepaper/2016-state-of-devops-report
73.

“Amazon.”Wikipedia.

AccessedMay

9,

2018.https://en.wikipedia.org/wiki/Amazon_(company)
74.

“Fordism.” Wikipedia. Accessed May 9, 2018. https://en.wikipedia.org/wiki/Fordism

75.

“Internet

Usage Statistics.” Internet World Stats. Accessed May 28, 2018.

http://www.internetworldstats.com/stats.htm
76.

“Kano

Model.”

Wikipedia.

Accessed

May

9,

2018.

25,

2018.

https://en.wikipedia.org/wiki/Kano_model
77.

“Microservices.”

Wikipedia.

AccessedMay

https://en.wikipedia.org/wiki/Microservices
78.

“Principles of Chaos Engineering.” principlesofchaos. Last updated May 2018. Accessed
May 22, 2018. http://principlesofchaos.org/

79.

“Scientific Management.” The Economist. February 9, 2009. Accessed May 9,
2018.https://www.economist.com/node/13092819

80.

“The Netflix Simian Army.” The Netflix Tech Blog, July 19, 2011. Accessed May 22, 2018.
https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116

81.

“The

World

Is

Flat.”

Wikipedia.

Accessed

May

9,

2018.

https://en.wikipedia.org/wiki/The_World_Is_Flat
82.

“What

Is

the

Kano

Model?”

kanomodel.com.

Accessed

May

9,

2018.

https://www.kanomodel.com/.

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 28 of 37

Official

8. 用語集 (50音順)
用語

定義

3つの道

DevOpsの三大原則であるフロー、フィードバック、継続的な経験と学習をさす。

C.A.L.M.S

DevOps の 価 値 観 を 示 す 、 文 化 （ Culture ） 、 自 動 化 （ Automation ） 、 リ ー ン（Lean）、測定（Measurement）、共有（Sharing）の頭文字をとったもの。

DevOps

ITIL、リーン、アジャイルなどの既存のITベストプラクティスを、自動化と継続的デリバリをサポートし、コラボレーションと学習の文化を奨励する開発および運用
アプローチへと進化させることを表現するために作られた語。ITがこれまで以上により良く、より速く、より安くビジネスバリューを提供できるようにすることをめざす。

DMAICサイクル

定義（Define）、測定（Measure）、分析（Analyze）、改善（Improve）、管理（Control）の5段階による継続的改善の指針を提供するモデル。

ITIL®

IT サービスマネジメントに関するベストプラクティスガイダンス。

アジャイル型プロジ
ェクトマネジメント

プロジェクトマネジメントにあたって適応性のあるアプローチをとり、プロジェク
トの初期に作成される要求が、プロジェクトが進むにつれ変化し、進化していくことを想定する。こうした変化に対応し、変化を組み込んでいくために、継続的なイ
テレーションを使用する。

アジャイル原則

アジャイル宣言を構成する12の原則。

アジャイル宣言プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画にしたがうことよりも変化への対応を、価値とする。*

インシデントITIL® によれば、サービスの計画外の中断、またはサービスに影響を与えていない
サービスコンポーネントの障害。†

インシデント管理

通常のサービス運用を可能な限り迅速に復旧することで、インシデントの悪影響を最小限に抑えるITIL®のプラクティス。†

開発チーム

各スプリントの終わりに、「完了」し、リリース判断可能なプロダクトのインクリ
メントのデリバリ作業を行う専門家で構成されるアジャイルのスクラムチーム。‖

カンバン

カンバンは、1940 年代にリーン生産方式の初期段階の１つの進化形態として登場
し、組立ラインの作業員が部品やその他の作業の需要を下流のパートナーに通知するための方法を提供した。これにより、透明性が高まりコミュニケーションが促進され、プロセスの標準化につながった。

基軸価値観

前進し意思決定を行う際に、羅針盤が常に指し示すべき場所。シンプルでわかりやすい方法で確立され、明確でまとめやすいものでなければならない。

技術的負債

最善のソリューションではなく、安易なソリューションを絶えず実装していった末にできてくる、複雑なワークアラウンドや手戻りが積み重なったもの。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 29 of 37

Official

用語

定義

機能テスト

ユニットテスト、APIテスト、統合テスト、システムテストなど、プロダクトが動作するために必要な機能のテスト。

継続的インテグレー
ション

1日を通して、すべての開発者の作業結果を共有のメインライン（コードリポジト
リやメインコードトランク）にマージするプラクティス。継続的インテグレーショ
ンは、自動化された継続的デリバリプロセスの中で、主にビルド段階をカバーする。通常の場合、開発環境内でのコードの統合、ビルド、テストに利用される。

継続的改善

製品およびサービスの効果的な管理に関与するすべての要素の継続的な識別と、改善を通して、変化していくビジネスニーズに組織のプラクティスとサービスを整合させるITIL®のプラクティス。†

継続的テストデプロイメントパイプラインの各段階で自動テストを実行し、各段階で即座にフィードバックを返すことにより、リスクを軽減する。自動化された継続的テストは、
継続的インテグレーションと継続的デリバリの重要なコンポーネントである。これ
により、コードと環境が適切に動作し、デプロイ可能な状態を維持できるようになる。

継続的デプロイメン
ト（展開）継続的デリバリのコンセプトを拡張したもので、自動テストに合格したすべての変更が自動的に本番に投入される。継続的デリバリで以前は手作業で実施されていたステップを自動化し、1日に複数回のデプロイメントを可能にする。

継続的デリバリ

実行可能な成果物を本番に合わせた環境に投入し、問題を検出するための自動テストを実施することで、本番までのライフサイクルを通して、コードを常に迅速かつ安全にデプロイできるように設計された一連のプラクティス。

コンウェイの法則「システムを設計する組織は、その組織によく似た構造の設計をする」。‡

コンテナ化

ランタイム環境全体を1つのパッケージつまり「コンテナ」にバンドルすることで、アプリケーションプラットフォームとその依存性、OSディストリビューショ
ンや基礎となるインフラの違いを抽象化できるようにすること。

サービス構成管理

サービスの構成とそれをサポートする構成アイテムに関する正確で信頼できる情報を、必要なときに必要なところで利用できるようにする ITIL®のプラクティス。†

サービス指向アーキ
テクチャ (SOA)

機能をサービスという別個の単位に分けて考えるアーキテクチャ。開発者がネットワークを介してサービスにアクセスできるようにして、ユーザがそれを組み合わせて再利用することによりアプリケーションを作り出すことができるようにする。これらのサービスとその利用者は、相互通信により、明確に定義された共有フォーマットでデータを渡したり、複数のサービス間のアクティビティを連携したりする。

サービスマネジメン
ト

顧客にとっての価値をサービスの形で実現する、組織の専門能力の集まり。†

サービスレベルアグ
リーメント (SLA)

ITIL® によれば、主要なサービスの目標と責任、サービスに期待される保証と有用性を定義するための、IT サービスプロバイダと企業の間で結ばれる合意文書。†

サービスレベル管理

サービスパフォーマンスの明確な目標値を事業に基づいて設定し、その目標値に対して、サービスの提供を適切に評価、モニタリング、管理できるようにする ITIL®
のプラクティス。†

災害復旧

最悪のシナリオに対応し、インシデントやサービス停止から重要なシステムを守るための手段。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 30 of 37

Official

用語定義

サイロメンタリティ

チームや部門が、共通のタスクを共有してはいても他のグループとは別個に活動することにより、機能とのつながりを独占したり、技術的なナレッジをチームや部門
内でのみ共有したりするような場合に生み出される。

システム思考機能を、境界によって定義され、部分の合計を超える、より大きなシステムの相互に関連し相互に依存する一部分として理解すること。

自動化

電子機器のような高度に自動化された手段によってプロセスを操作または制御し、人間の介入を最小限に抑える技術、手法、またはシステム。

シフトレフト

開発プロセスの早期に前倒しで品質を作りこむことにより、課題を早期に検出して解決し、欠陥やエラーが本番稼働に影響を与えないようにする。

重要品質要因(CTQ)

リーンの原則によれば、優先順位をつけて重点的に取り組むべき価値をもつ項目。

出荷判断可能なプロ
ダクトインクリメン
ト

機能要件と非機能要件の両方について合意された受け入れ基準にしたがい完了したスプリントバックログ項目で構成されるスクラム成果物。

処理時間

実際にプロダクトやサービスを作るのにかかった時間の合計。

スクラム

さまざまなプロセス、ツール、技法を利用できる適応性をもつアジャイルプロセスのフレームワーク。反復的な方法を採用することによりプロダクトの開発効率を高め、その結果として、可能な限り最高の品質をもつ成果物のリリース頻度を上げることが可能になる。

スクラムスプリント

スクラムの中心的なコンセプト。1ヶ月以内のタイムボックスで、「完了」し、使用可能で、リリース判断可能なプロダクトのインクリメントを作成する。‖

スクラムマスター

スクラムの役割の1つで、スクラムの理解度を上げて適切に実行されるようにする。スクラムチームに、スクラムの理論やプラクティスやルールを確実に順守させることにより、この役割を果たす。‖

ストラングラーアプ
リケーション

モノリシックアプリケーションを「絞め殺す」つまり置き換えるために使用されるマイクロサービスアプリケーション。「ストラングラーアプリケーションパター
ン」も参照。

ストラングラーアプ
リケーションパター
ンストラングラーアプリケーションのマイクロサービスを段階的に導入していくことにより、機能の特定の部分をシームレスに置き換えていき、徐々にモノリシックア
プリケーションを「絞め殺す」つまり置き換えていくこと。

スプリント

スクラムの中心的なコンセプト。1 ヶ月以内のタイムボックスで、「完了」し、使用可能で、リリース判断可能なプロダクトのインクリメントを作成する。‖

スプリント計画

スプリントで行う作業を計画するスクラムイベント。この計画は、スクラムチーム
全体の共同作業で作成される。‖

スプリント実行

スプリント計画の後に始まり、スプリントレビューとレトロスペクティブの時間をスプリント全体から差し引いた時点で終了するスクラムイベント。実行に入ると、スプリントバックログ中の項目が「作業中」となり、「完了の定義」に従って完了するまで作業が行われる。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 31 of 37

Official

用語定義

スプリントバックロ
グ

スプリント用に選択されたプロダクトバックログ項目の集まりに加えて、プロダク
トインクリメントをデリバリし、スプリントゴールを実現するための計画から構成されるスクラムの成果物。‖

スプリントレトロス
ペクティブ（振り返り）

スクラムチームが自分たちを振り返り、次のスプリントで実行するための改善計画を作成する機会を提供するスクラムイベント。‖

スプリントレビュー

スプリントの最後に実施されるスクラムイベントで、インクリメントを検査し、必要に応じてプロダクトバックログを調整する。‖

制約理論

複雑なシステムやプロセスにおいては、その中で最大の阻害要因となっているボト
ルネックや制約が全体の効率や働きを定めるとする。制約理論は、組織が、システ
ム全体を制約し、組織全体のスピードを制限している、最も遅く、最も非効率な領域を識別し、その領域に重点的に取り組むのに役立つ。

組織文化

組織内で学習し共有する前提や価値のパターン。組織内で働く人が、組織内の行動パターンを観察することにより、時間をかけて身につけていく。

対障害弾力性

あらゆる種類のインシデントやサービス停止に対応するだけでなく、それが発生しても機能を継続するための手段。

耐脆弱性

あらゆる種類のインシデントやサービス停止に対応し、それが発生しても機能を継続するだけでなく、それを学習と適応の機会として活用するための手段。

デイリースクラム

開発チームがアクティビティを同期させ、次の24時間の計画を作成するための15分間のスクラムのイベント。‖

デジタルトランスフォーメーション

すべての組織活動、プロセス、スキル、文化的な態度を含めた大幅な変革。

テスト駆動開発(TDD)

プログラムを書く前にテストシナリオを準備しておくことにより、プログラマの目
標をそのテストに合格できるプログラムを書くことにするプラクティス。

デプロイメント（展開）管理

新規または変更されたハードウェア、ソフトウェア、文書、プロセス、その他のサービスコンポーネントを稼働環境に移動させるITIL®のプラクティス。†

デプロイメントパイ
プライン

現在のデリバリのプロセスを段階的にモデル化することにより、エンドツーエンドのデリバリで、ボトルネック、自動化の機会、コラボレーションの機会がないか検討することができる。

トータルサイクルタ
イム

プロセスの開始から終了までの合計時間。

ナレッジ管理組織全体の情報とナレッジを効果的、効率的、便利に使用できる状態を維持し、改善していくための ITIL®のプラクティス。†

バリューストリーム

エンドツーエンドでビジネスバリューを提供する IT の全体像を示す。リーダーシッ
プとガバナンスには、バリューストリームにおける自身の位置づけだけでなく、ス
トリーム全体を理解することが、不可欠である。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 32 of 37

Official

用語定義

非機能テスト

パフォーマンステスト、セキュリティテスト、コンプライアンステスト、キャパシ
ティテストなど、特定の結果を生み出すテストではない、システムの動作を確認するテスト。

ビジネスバリュー

サービスが顧客の期待に応えるレベル、またはそれを超えるレベル。

フィードバック

アウトプットを同じ部分へのインプットとして使用することにより、因果関係のつながりをもつループが形成される。

付加価値を生まない
作業

リーンによれば、排除するべきプロセス中の作業。

付加価値を生まない
必要作業

リーンによれば、最小化するべきプロセス中の作業。付加価値は生み出さないが、実施しなければならない作業。

付加価値を生む作業

リーンによれば、最適化するべきプロセス中の作業。顧客が実際に経験して、その価値を認めている作業でなければならない。顧客は、その作業に対して喜んで支払
いをする。

部分最適化

個人やチームにとって最良の結果を生み出すために構成され、構築された環境。部
分的な効率性を達成することも重要だが、サイロ内で部分的に最適化されたプロセ
ス設計がどのような問題を引き起こす可能性があるかを理解しておく必要がある。

フルスタック

重要成功要因である、適切な人による適切な文化の創造、適切なプロセスとプラク
ティスの導入、その文化とプラクティスにテクノロジと自動化を加えて合理化と加速化を図る、という DevOps の実践における 3 つの重要な側面を表わす。

フロー

人や情報やプロダクトがプロセスの中をどのように動くか。

プルシステム

顧客の需要に基づいてプロセスを発生させてプロダクトやサービスを引き出すシステム。対照的に、需要予測に基づいてプロセスを発生させてプロダクトやサービスを押し出すのがプッシュシステムである。プルシステムにより、プロセスのムダが削減される。

プロセス

特定の目的を達成するために設計され構造化された一連の活動。1 つまたは複数の定義されたインプットを、定義されたアウトプットに変換する。

プロダクトオーナー

スクラムの役割の 1 つで、プロダクトバックログの作成と維持を担当する。顧客と常にコミュニケーションをとり、チームとコラボレーションを行う。‖

プロダクトバックロ
グ

プロダクトに必要とされる可能性のあるすべてのものを順番に並べたリストからなるスクラムの成果物。プロダクトに変更を加えるための要件は、ここからしか発生しない。‖

変革的リーダーシップ

組織文化を生成的なものに変化させ、優先順位と目標の共有を推し進めて、
DevOpsをサポートするリーダーシップのスタイル。

変更コントロール製品およびサービスの変更の成功数を最大にするために、変更を進めることを許可し、変更スケジュールを管理するITIL® のプラクティス。これにより、リスクが確
実に適切に評価されるようにする。†

マイクロサービスア
ーキテクチャ
（MSA）

1つの機能を1つのサービスに関連付け、ノード間でサービスを分散させながら規模を拡大していくアーキテクチャ。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 33 of 37

Official

用語

定義

問題

ITIL®によれば、1つまたは複数のインシデントの原因または潜在的な原因。†

問題管理

インシデントの実際の原因と潜在的原因を識別し、ワークアラウンドと既知のエラーを管理することで、インシデントの発生可能性と発生した場合の影響を低減する
ITIL®のプラクティス。†

ユーザストーリ

ソフトウェアシステムの1つまたは複数の機能を非形式的な自然言語で記述したもの。ユーザストーリは、システムのエンドユーザやユーザの視点から書かれること
が多い。

有用性

サービスの機能要件。有用性は、目的に適したサービスの要件、「サービスは何を行うことになっているか」を表わす。

リードタイムインプットからアウトプットまでの時間。インプットを受け取った時点から開始さ
れる。

リーン

フローを重視した品質システム。顧客価値の向上、ムダの排除、継続的改善をめざす。

リーンカイゼン

問題を解決するための構造化されたアプローチ。フローとプロセスを段階的に改善することを目的としたもので、組織内のあらゆる階層の人に、できるだけ、簡単か
つ迅速に実行できる小さなアイデアを探すように奨励する態度や考え方を示す。カイゼンは、組織の日常の文化の一部であるべきだとする。

リリース管理新規および変更されたサービスや機能を使用できるようにする ITIL®のプラクティス。†© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 34 of 37

Official© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 35 of 37

Official-

このページは空白です。

© 2021 PeopleCert | All rights reserved
シラバス / PeopleCert DevOps ファンダメンタル | Version 01.0 / September 2019

Page 36 of 37

Official