アジャイルソフトウェア開発技術者検定Lv.2試験受験の為のまとめです。
自身の学習の為にまとめましたが、今後同試験を受験する方の参考になれば幸いです。

アジャイル検定とは

アジャイル開発のスキルを客観的な尺度で分析・判定するのが、アジャイルソフトウエア開発技術者検定試験です。

アジャイル検定Lv2出題範囲

試験要項(Lv.2試験）：出題範囲

カテゴリ	内容
1.モデリング	オブジェクト指向設計：継承、インターフェース、ポリモーフィズム、疎結合、Dependency Injection
2.コーディング	・コーディングルール：ツールによる確認(checkstyle) ・ペアプログラミング・リーダビリティ(コードの読みやすさ) ・テストコード(Mock、Testing frameworkなど) ・静的解析ツール(SonarQube) ・ドキュメンテーション
3.構成管理	・チーム開発：SCM(ソースの変更管理システム)、分散型(git)、集中型(Subversion、CVS 等) ・ブランチ戦略：ブランチとマージ、レビュー・受入(プルリクエスト) ・コンテナ技術
4.テスト	・TDD:Junit(モックを使ったテスト、テスト結果レポートの見方、網羅率C0,C1,C2) ・品質管理のためのテスト(パフォーマンステスト、結合テスト、総合テスト・システムテスト) ・ユーザー受入テスト、ブラックボックステスト、ホワイトボックステスト
5.常時結合	・自動化の導入：何時動かして結果から何を読み取るか、自動化の導入効果、何を自動化するか(ビルド⇒テスト⇒デプロイ等) ・何のため、誰のために、常時結合(CI)をおこなうのか
6.デザインパターン	・デザインパターンを使うことのメリット・ロバート・C.マーチン「アジャイルソフトウェア開発の奥義」(アジャイルな設計、単一責務、Open/Closedの法則)、GoFのデザインパターン、DI(Dependency Injection) ・オブジェクト指向開発の考え方(継承、カプセル化、ポリモーフィズムなど) ・デザインパターンを使うことのメリット(各パターンの利用法、メリット) ・システムアーキテクチャ設計(拡張性、保守性) ・UML(Unified Modeling Language)
7.リファクタリング	・マーティン・ファウラー「リファクタリング」(コードの不吉な匂い等) ・オブジェクト指向設計原則(Principles Of Object Oriented Design)
8.チームのスキル	・スプリント計画・自己組織化されたチーム：メンバーの行動規範(コミュニケーション、自立と協調) ・レトロスペクティブ(振り返り)

※アジャイル検定Lv1については、対策書籍がある為そちらに従い学習すればOK。
http://agilecert.org/test/edu/

各出題範囲に対するまとめと参考リンク

1.モデリング

オブジェクト指向設計：継承、インターフェース、ポリモーフィズム、疎結合、Dependency Injection

オブジェクト指向設計の基本原則（SOLIDの原則）

S：SRP、単一責任の原則

1つのクラスに1つの役割(機能)
クラスを変更する理由が2つ以上存在してはならない

O：OCP、オープン・クローズドの原則

クラスは拡張に対して開いていて、修正に対して閉じていなければならない
クラスに対して「拡張が出来る」「修正する場合はそのクラスだけ修正すればいい」
クラスはオブジェクトではなくインターフェースに依存せよ

L：LSP、リスコフの置換原則

基本クラスを使っている場所で基本クラスの代わりにサブクラスを使っても問題なく動かなければならない

I：ISP、インタフェース分離の原則

クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。

D：DIP、依存性逆転の原則

上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。

ポリモーフィズム

ポリモーフィズムとは、プログラミング言語の持つ性質の一つで、ある関数やメソッドなどが、引数や返り値の数やデータ型などの異なる複数の実装を持ち、呼び出し時に使い分けるようにできること。

<参考>
オブジェクト指向が5000%理解できる記事
https://qiita.com/itherojp/items/b2f8e39d7cc23ad505f9

オブジェクト指向が5000%理解できる記事(実践編)
https://qiita.com/itherojp/items/fab2a6637f681221f687

開発者が知っておくべきSOLIDの原則
https://postd.cc/solid-principles-every-developer-should-know/

オブジェクト指向設計原則とは
https://qiita.com/UWControl/items/98671f53120ae47ff93a

オブジェクト指向のメリットとは？例に例えてわかりやすく解説！
https://jpazamu.com/object/#index_id0

カプセル化とはなにか？超わかりやすく解説します！
https://jpazamu.com/encapsulation/

ポリモーフィズムとはなにか？超わかりやすく解説します！
https://jpazamu.com/polymorphism/

猿でも分かる! Dependency Injection: 依存性の注入
https://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f

2.コーディング

コーディングルール：ツールによる確認(checkstyle)
ペアプログラミング
リーダビリティ(コードの読みやすさ)
テストコード(Mock、Testing frameworkなど)
静的解析ツール(SonarQube)
ドキュメンテーション

コーディングルール：ツールによる確認(checkstyle)

Checkstyleは、ソフトウェア開発において使われる静的コード解析ツールの1つであり、Javaのソースコードに対してコーディングルールへの準拠を確認する。

ペアプログラミング

ペアプログラミングとは1台のPCで2人のプログラマーが共同で開発を行う手法
2人で行うといっても両方プログラムを行うのではなく各自には「ドライバー」「ナビゲーター」という役割がある
ドライバーとナビゲーターという役割はプログラム開発の小さな区切りや一定時間（30分、1時間など）で交代するのが望ましい。
役割だけではなく2人のペア自体も同様に一定期間で交代する。

リーダビリティ(コードの読みやすさ)

一般的な名前を利用する。
英語として読めるようなメソッド名や変数名をつける。
可能な限り短く記述する。（書かない努力をする/実装しない努力をする/構造化する）

テストコード(Mock、Testing frameworkなど)

mockとは、一言でいうとテストに必要な部品の値を擬似的に設定するもの。

静的解析ツール(SonarQube)

SonarQubeはオープンソースの品質管理プラットフォーム
以下のような機能を持っており、プラグインが豊富で多くのプログラミング言語をサポートしている。
- 重複コードの検出
- サイクロマチック数の計測
- 脆弱性のあるコードの検出
- バグを誘発しそうなコードの検出
- 指摘されたissueの管理

ドキュメンテーション

ドキュメントが重要な理由
- 1.対話の質を上げるためのドキュメント
- 2.抽象度を上げるためのドキュメント
- 3.利害関係を調整するためのドキュメント
- 4.計画を可視化するためのドキュメント

<参考>
ペアプログラミングとは？メリットとデメリットをまとめてみた
https://blog.codecamp.jp/programming-pair-advantage-disadvantage

ソースコードの可読性を上げるためのTips
https://qiita.com/icoxfog417/items/f737d6c84b733f649461

なぜ読みやすいコードが必要なのか - コードの可読性を高める手法をサンプルで学ぶ
https://eh-career.com/engineerhub/entry/2019/09/24/103000

mockを使おう！
https://qiita.com/Fudeko/items/301f8a80963dfcaafb80

SonarQubeでソースコードの静的解析とレビューを自動化してみる(前編)
https://dev.classmethod.jp/articles/sonarqube-source-analytics-1/

変更に強いドキュメントの心得~アジャイルでのドキュメントとの付き合い方~
https://www.isoroot.jp/blog/1592/

3.構成管理

チーム開発：SCM(ソースの変更管理システム)、分散型(git)、集中型(Subversion、CVS 等)
ブランチ戦略：ブランチとマージ、レビュー・受入(プルリクエスト)
コンテナ技術

チーム開発：SCM(ソースの変更管理システム)、分散型(git)、集中型(Subversion、CVS 等)

Gitは分散型バージョン管理システム(Distributed Version Control System)
Subversionは集中型バージョン管理システム(Centrlized Version Control System)
Subversionはサーバーにインストールした”リモートリポジトリ”だけが、ソースコードのバージョンを管理している。
Gitは開発者自身のローカルPCに”ローカルリポジトリ”を持つ。

ブランチ戦略：ブランチとマージ、レビュー・受入(プルリクエスト)

開発フローは以下の通り。
- [ 開発者 ] 作業対象のソースを clone または pull する。
- [ 開発者 ] 作業用のブランチを作成する。
- [ 開発者 ] 機能追加、改修といった開発作業を行う。
- [ 開発者 ] 作業が完了したら push する。
- [ 開発者 ] プルリクエストを作成する。
- [ レビュー・マージ担当者 ] 通知されたプルリクエストから変更を確認しレビューする。
- [ レビュー・マージ担当者 ] レビュー結果を判断し、必要ならば開発者にフィードバックする。
- [ レビュー・マージ担当者 ] レビューの結果、問題がない場合はマージする。
- [ レビュー・マージ担当者 ] レビューの結果、対応自体が不要となるなど、プルリクエスト自体が必要ない場合はクローズする。

コンテナ技術

コンテナ技術は、実行環境を他のプロセスから隔離し、その中でアプリを動作させる技術。
コンテナ技術を用いれば、異なるサーバであっても、簡単に同一構成の開発環境や本番環境を構築できる。

<参考>
GitとSubversionの構造的な違い
https://www.ricksoft.jp/blog/archives/9483/

プルリクエストを使った開発プロセス
https://backlog.com/ja/git-tutorial/pull-request/03/

「コンテナって何？　どう使える？」――ソフトウェア開発の課題を解決するコンテナ技術
https://www.atmarkit.co.jp/ait/articles/1901/29/news005.html

4.テスト

TDD:Junit(モックを使ったテスト、テスト結果レポートの見方、網羅率C0,C1,C2)
品質管理のためのテスト(パフォーマンステスト、結合テスト、総合テスト・システムテスト)
ユーザー受入テスト、ブラックボックステスト、ホワイトボックステスト

TDD:Junit(モックを使ったテスト、テスト結果レポートの見方、網羅率C0,C1,C2)

テスト駆動開発（Test-Driven Development: TDD）とは、テストファーストなプログラムの開発手法。
プログラムの実装前にテストコードを書き（テストファースト）、そのテストコードに適合するように実装とリファクタリングを進めていく。
テスト駆動開発は、「レッド」「グリーン」「リファクタリング」という順序で進められる。
モックオブジェクト（Mock Object）とは、ソフトウェアテスト時、特にテスト駆動開発、ビヘイビア駆動開発における代用の下位モジュールスタブの一種。
スタブと比較して、検査対象のモジュールがその下位モジュールを正しく利用しているかどうかを検証するのに使われる。
命令網羅 (statement coverage) (C0)：それぞれの"命令文"が少なくとも1回は実行されるようにテストを設計。
分岐網羅 (branch coverage) (C1)：それぞれの"判定条件における真偽"が少なくとも1回は実行されるようにテストを設計。
条件網羅 (condition coverage) (C2)：それぞれの"条件文における真偽"が少なくとも1回は実行されるようにテストを設計。
複合条件網羅 (multiple condition coverage) (MCC)：それぞれの"条件における真偽の組み合わせ"がすべて実行されるようにテストを設計。

品質管理のためのテスト(パフォーマンステスト、結合テスト、総合テスト・システムテスト)

性能テスト（Performance Test）とは、システムのデータ処理速度や一度に処理可能なデータ量がユーザー利用に即した仕様になっているかを確認するテスト。
結合テストとは、複数のプログラムやモジュールを同時に稼働して行う動作テストで、モジュール同士を結合した際に意図した通りに動作するかどうかを検証。
結合テストの主な種類
- インタフェーステスト：個々の機能が正しく連携するかどうかを検証
- 業務シナリオテスト：実際の業務を想定した検証（イレギュラーケースも含める）
- 負荷テスト：システムリソースの限界まで操作し、意図しないシステムのパフォーマンス低下や停止が発生しないかを検証する検証
システムテストは、開発したシステムが期待通りに動作するか、構築したシステムが仕様書通りの機能や性能要件を満たしているかについて検証。

ユーザー受入テスト、ブラックボックステスト、ホワイトボックステスト

受け入れテスト(UAT)は、システム開発を開発ベンダーに外注して納品された時に、発注者の本来の目的や意図通りに稼働するかどうかを検証すること。
- 運用受け入れテスト
  - 運用時に対応できるかどうかを検証する。バックアップ、ユーザー管理、セキュリティ、災害時の復旧などの観点でテストが行われる。
- マニュアルテスト
  - システム運用に関するマニュアルの文章が、正しいかどうかを検証する。
- 契約による受け入れテスト
  - 契約書に記述された、品質や納期などの項目が満たされているかどうかを検証する。
- 規定による受け入れテスト
  - 法律、規制、安全基準などに反していないかどうかを検証する。
- ベータテスト
  - 既にサービスを利用しているユーザーなどに試用してもらい、使用感の評価や不具合の検出をしてもらう。
  - 開発者の関係者、人数制限付きの限定的なクローズドベータテストや、公開するオープンベータテストがある。
ホワイトボックステストとは、システム内部の構造を理解した上で、それらが意図した通りに動作しているかを確認するテスト方法。
- 内部構造を理解していることが必要なので、主に開発者が行う。
ブラックボックステストとは、システム内部の構造を考慮することなく、外部から見た仕様を検証するテスト方法。
- 内部構造には着目しないので、開発者ではない第三者がテストを行う。

<参考>
テスト駆動開発（TDD）とは？TDDの進め方をステップ毎に解説！
https://www.qbook.jp/column/20181009_713.html

テスト駆動開発って何だろう
https://dev.classmethod.jp/articles/what-tdd/

JUnitでモックを利用したテストコード（EasyMock中心）
https://qiita.com/YutaSaito1991/items/b6b0cbbedfc4f5822b87

ホワイトボックステストにおけるカバレッジ（C0/C1/C2/MCC）について
https://qiita.com/bremen/items/8b6542467d2a0066e5af

Webシステムの性能テスト（パフォーマンステスト）とは？負荷テストなど目的に応じた3つの種類
https://www.qbook.jp/column/20181128_648.html

単体テスト・結合テスト・総合テストの違い、観点や注意点を簡単に説明する
https://pm-rasinban.com/ut-it-st

結合テストでシステムの連携を検証！主な種類と実施方式の違い
https://hnavi.co.jp/knowledge/blog/integration_testing/

システムテストとは？開発段階のテストの流れと主な種類
https://hnavi.co.jp/knowledge/blog/system_test/

受け入れテスト(UAT)について
https://webrage.jp/techblog/uat/

みんな知ってるホワイトボックステスト、ブラックボックステスト。でもグレーボックステストとは…？
https://hldc.co.jp/blog/2018/05/25/1387/

5.常時結合

自動化の導入：何時動かして結果から何を読み取るか、自動化の導入効果、何を自動化するか(ビルド⇒テスト⇒デプロイ等)
何のため、誰のために、常時結合(CI)をおこなうのか

自動化の導入：何時動かして結果から何を読み取るか、自動化の導入効果、何を自動化するか(ビルド⇒テスト⇒デプロイ等)

アジャイル/DevOpsは短い開発サイクルを繰り返すため、品質保証も短期間、高頻度での実施が求められる。
そのため品質保証の生産性の改善活動がアジャイル/DevOpsの重要な要素の一つとなる。
自動化を通し,テスト実行やテストレポートなどのテスト工程をソフトウェア化することで,品質保証が素早く実行可能になる。

何のため、誰のために、常時結合(CI)をおこなうのか

継続的インテグレーション（常時結合）の仕組みのおかげで、以下のことが可能になる。
- 常時結合し動作確認を行う事で、常に動くヘルシーなソフトウェアを維持できる
- ソフトウェアが壊れていないことが心理的な安心感を与え、エンジニアはインクリメンタルな開発に専念できる
- 同じコードを多くのエンジニア、チームが触ることを可能にする
- 共通のコードを通して、コミュニケーション・コラボレーションが促進される

<参考>
スケールするなら継続的インテグレーション（常時結合）は必須である
https://rihoublog.com/2019/01/19/

アジャイルとDevOpsの品質保証と信頼性
http://kokotatata.hatenablog.com/entry/2020/06/01/163652

6.デザインパターン

デザインパターンを使うことのメリット
ロバート・C.マーチン「アジャイルソフトウェア開発の奥義」(アジャイルな設計、単一責務、Open/Closedの法則)、GoFのデザインパターン、DI(Dependency Injection)
オブジェクト指向開発の考え方(継承、カプセル化、ポリモーフィズムなど)
デザインパターンを使うことのメリット(各パターンの利用法、メリット)
システムアーキテクチャ設計(拡張性、保守性)
UML(Unified Modeling Language)

デザインパターンを使うことのメリット

デザインパターンとは、JavaやRubyなどのオブジェクト指向の言語で使われる設計パターン
よく出会う問題とそれにうまく対処するための設計。
メリット
- 再利用性の高い柔軟な設計ができる
- 技術者どうしの意思疎通が容易になる

※以下参考リンク先で、各デザインパターン（23種類）の概要を理解しておく必要あり。

<参考>
今さら聞けない！デザインパターンとは
https://techacademy.jp/magazine/9195

GoFのデザインパターンまとめ
https://qiita.com/i-tanaka730/items/c63c6c22abd1477e0ba0

デザインパターンの基本
https://www.techscore.com/tech/DesignPattern/foundation/foundation1.html/

システムアーキテクチャ設計で考えることを整理してみた
https://qiita.com/tomtom55/items/220507baf0ddfb17ffe5

ソフトウェアにおける保守性と拡張性の定義
https://www.itmedia.co.jp/im/articles/0512/16/news108.html

TECHSCORE(テックスコア)：デザインパターン
https://www.techscore.com/tech/DesignPattern/index.html/

7.リファクタリング

マーティン・ファウラー「リファクタリング」(コードの不吉な匂い等)
オブジェクト指向設計原則(Principles Of Object Oriented Design)
リファクタリングとは、ソフトウェアの外部的振る舞いを保ちつつ、理解や修正が簡単になるように、内部構造を改善すること。
リファクタリングの目的
- ソフトウェア設計を向上させる
- ソフトウェア設計の劣化を防ぐ
- ソフトウェアを理解しやすくする
- バグを見つけ出す
- より早くプログラミングできる
リファクタリングのタイミング
- プログラムに改善の余地を見つけたとき
- 機能など、プログラムを追加するさい

<参考>
リファクタリングとは何か？
http://objectclub.jp/technicaldoc/refactoring/refact-what

リファクタリングとは？メリットやデメリット、注意点を解説します
https://ec-orange.jp/ec-media/?p=24443

コードの不吉な臭い・バージョン2
https://ryo511.info/archives/4706

コードの不吉な臭
https://qiita.com/NagaokaKenichi/items/22972e6ba698c7f2978a

8.チームのスキル

スプリント計画
自己組織化されたチーム：メンバーの行動規範(コミュニケーション、自立と協調)
レトロスペクティブ(振り返り)

スプリント計画

スプリント計画は、スプリントを開始するスクラムにおけるイベント。
スプリント計画の目的は、スプリントの実行内容や作業の達成方法を定義すること。

自己組織化されたチーム：メンバーの行動規範(コミュニケーション、自立と協調)

自己組織化はチームが形成され、ある問題と制約が与えられたら、どのようにその問題を解決するかをチームが自分たちで決めるということ。
自己組織化されたチームは目的に対する最適な方法/プロセスを自分たちで決める。
外から決められることはない。自分たちで目的達成のために必要なことを見つけ出す。
自己組織化されたチームを開発する為に・・・（Galina Kostetskaya氏）
- 思わず引き込まれるようなミッションを与える
- 情報の流れの境界を明確にし、組織のユニットやリソースを整える。
- そのような境界を自分たちで管理する権限を与える
- 一定期間に安定を与える

レトロスペクティブ(振り返り)

レトロスペクティブ（retrospective）とは、「チーム自体」やチーム活動の「プロセス」を振り返る活動。
チームのメンバー全員で本音で話し合い、チームの問題点や良いところを探し、次の活動の改善や継続的に取り組む事項について合意する。
振り返りには二つのカテゴリがある
- チームの成果に対する振り返り -> スプリントレビュー
- チーム自体やチームの活動プロセスに対する振り返り -> レトロスペクティブ

<参考>
ATLASSIAN - スプリント計画
https://www.atlassian.com/ja/agile/scrum/sprint-planning

自己組織化されたアジャイルチームを確立する
https://www.infoq.com/jp/news/2015/03/establishing-self-organized-team/

IPA - アジャイルソフトウェア開発宣言の読みとき方
https://www.ipa.go.jp/files/000065601.pdf

アジャイル開発とスクラム②：レトロスペクティブ完全版
https://qiita.com/Ishio/items/8443b32f3a0c202e6bbb

受験後の感想

65点取得でぎりぎり合格しました。（テスト/リファクタリングの正答率が圧倒的に低かったです。。）
アジャイル検定Lv1の回答の選択は1つのみでしたが、Lv2に関しては、「適切なものを全て選択せよ」といった正答数が指定されていない問題が多く、Lv1よりも難易度は高かったです。
正答数が指定されていない且つ、解釈の仕方によっては正解にも不正解にも捉えられるのでは？と思える選択肢があり、かなり苦戦しました。（私の理解レベルが低かったのもあるかもしれません。）
また、私はインフラエンジニアであり、普段デザインパターンを業務で意識する機会が少なく、内容を理解するのに苦労しました。（デザインパターンを問う出題も相応にあり、対策は必須です。）
アジャイル開発は今後より主流になっていくと思うので、引き続き勉強していこうと思います。

アジャイル検定Lv2試験対策まとめ