アジャイルソフトウェア開発技術者検定Lv.2 不合格体験記｜デザインパターンを理解せずに受けたら落ちた話

アジャイルソフトウェア開発技術者検定Lv.2に不合格になった体験記です。Lv.1合格後の勢いで挑戦したものの、デザインパターンとコーディングの理解不足で大きく失点しました。

資格取得シリーズを見る

公式要項では、アジャイルソフトウェア開発技術者検定試験Lv.2は60分・四肢択一40問・65%以上で合格、受験資格はLv.1合格者です。出題範囲には、モデリング、コーディング、構成管理、テスト、常時結合、デザインパターン、リファクタリング、チームのスキルが含まれます。再受験は、2回目が受験日の翌日から30日目以降、3回目以降が60日目以降です。受験前にはアジャイル認定法試験の公式要項を必ず確認してください。

はじめに

アジャイルソフトウェア開発技術者検定Lv.2を受験しました。

結果は、不合格でした。

Lv.1にはリベンジ合格できたので、Lv.2もその流れで挑戦しましたが、甘くありませんでした。

特に痛かったのは、デザインパターンとコーディングです。

試験結果のレポートを見ると、敗因はかなり明確でした。

「デザインパターンを理解していなかった」「読みやすいコード、保守しやすいコードの判断が弱かった」「テストやリファクタリングも中途半端だった」

このあたりで大きく点を落としました。

この記事では、アジャイルソフトウェア開発技術者検定Lv.2に不合格になった体験をもとに、何が足りなかったのか、次回どう対策するべきかをまとめます。

Lv.2はLv.1とは別物だった

Lv.1は、アジャイル開発の考え方やスクラムの基本を問われる試験という印象でした。

もちろんLv.1も簡単ではありません。ただ、アジャイルの価値観、スクラムの流れ、プロダクトオーナーやスクラムマスターの役割を理解していれば、ある程度戦えました。

一方、Lv.2はかなり実装寄りです。

出題範囲には、モデリング、コーディング、構成管理、テスト、常時結合、デザインパターン、リファクタリング、チームスキルなどが含まれます。

つまり、単にアジャイルの考え方を知っているだけでは足りません。

開発チームのメンバーとして、実際にコードを書き、テストし、リファクタリングし、構成管理し、継続的に結合していく知識が必要になります。

ここを私は甘く見ていました。

公式問題集がないのがつらい

個人的に感じたのは、試験対策がしにくいということです。

公式テキストや学習参考資料はあります。しかし、IPA試験の過去問道場のように、過去問を大量に解いて出題傾向をつかむような勉強はしにくいです。

Lv.1もそうでしたが、公式問題集が充実していれば、難易度はそこまで高くないのではないかと感じます。

ただ、実際には問題がかなりひねられている印象がありました。

単語を覚えていれば解けるというより、「この場面では、どの考え方が一番適切か」「このコードはなぜ読みづらいのか」「この設計では、どのパターンが合っているのか」「このテストの考え方は正しいのか」といった判断が必要になります。

ここが落とし穴でした。

前回の試験結果

前回の結果レポートを見ると、弱点はかなりはっきりしていました。

この結果を見ると、合格できなかった理由は明確です。

モデリングと構成管理は80%取れていました。つまり、すべてができなかったわけではありません。

しかし、コーディングが20%、デザインパターンが25%でした。この2分野で大きく落としたことで、全体の点数が50点前後になったと考えています。

敗因の中心はデザインパターンとコーディング

前回の敗因の中心は、この2つです。

コーディング：20%
デザインパターン：25%

この2つは、Lv.2の中でもかなり重要な分野だと思います。

アジャイル開発では、変化に対応できるコード、読みやすいコード、テストしやすいコード、保守しやすい設計が重要になります。

そのため、デザインパターンやコーディングの考え方が弱いと、Lv.2ではかなり厳しいです。

私は、デザインパターンを名前だけで覚えていました。Factory、Strategy、Observer、Command、Adapter、Decorator、Facade、Proxy。

聞いたことはある。なんとなく知っている。でも、使いどころを説明できるかというと、かなり怪しい。この状態で受けたのが敗因でした。

デザインパターンを理解していなかった

一番の反省は、デザインパターンを理解せずに試験を受けたことです。

デザインパターンは、ただ名前を覚えるだけでは足りません。

どの問題を解決するためのパターンなのか。どのような場面で使うのか。似ているパターンと何が違うのか。保守性や拡張性にどうつながるのか。

ここまで理解する必要があります。

特に、次のようなパターンは押さえる必要があります。

Factory
Strategy
Observer
Command
Adapter
Decorator
Facade
Proxy
Prototype
Template Method
Visitor

試験では、単に「Factoryとは何か」と聞かれるだけではありません。

実際の設計やコードの状況があり、「この場面で適切な考え方はどれか」「この設計上の問題を改善するにはどのパターンが近いか」「このクラスの責務分担はどう考えるべきか」という形で問われる可能性があります。

私はそこまで準備できていませんでした。

デザインパターンの覚え方

次回に向けて、まずはデザインパターンをざっくりイメージで覚え直します。

最初は難しい説明よりも、短い言葉で使いどころを思い出せるようにします。

Factory = 作る
Strategy = 選ぶ
Observer = 知らせる
Command = 命令
Adapter = 変換
Decorator = 包む
Facade = 窓口
Proxy = 代理
Prototype = コピー
Template Method = 手順
Visitor = 訪問

このレベルでまず覚えます。そのうえで、実際のコードや設計例に当てはめて理解します。

たとえば、Strategyであれば、処理のアルゴリズムを切り替えたい場面。Observerであれば、ある状態変化を複数のオブジェクトに通知したい場面。Adapterであれば、既存のインターフェースを別の形に合わせたい場面。Facadeであれば、複雑な処理を簡単な窓口にまとめたい場面です。

このように、名前と使いどころをセットで理解する必要があります。

コーディングはC言語の文法だけではない

次に弱かったのが、コーディングです。

ここはC言語の文法を細かく問うというより、読みやすいコード、保守しやすいコードの判断が重要だと感じました。

出やすい弱点は、次のような内容です。

変数名が分かりにくい
一時変数の使い方
コメント/docコメント
カプセル化
凝集度
アクセス修飾子
テストしにくいコード
複雑な式の分割

つまり、試験で問われるのは、「このコードは動くか」だけではありません。

「このコードは読みやすいか」「意図が伝わるか」「変更しやすいか」「テストしやすいか」「責務が分かれているか」「コメントに頼りすぎていないか」といった観点です。

私はここを十分に整理できていませんでした。

読みやすいコードの判断基準

次回に向けて、コーディング分野では次の考え方を徹底します。

短いコードより、意図が分かるコード
全行コメントより、意味ある命名
複雑な式は一時変数で分ける
直接触らせず、カプセル化する
テストしやすい単位に分ける

特に、コメントについては注意が必要です。コメントが多ければ良いコードというわけではありません。

本当に良いコードは、変数名、関数名、クラス名、処理の分割によって、意図が伝わります。

もちろん、コメントが不要という意味ではありません。なぜその処理をしているのか、業務上の制約は何か、仕様上の注意点は何か。こうした内容はコメントに残す価値があります。

しかし、コードを読めばわかることをすべてコメントで説明するのは、逆に読みづらくなります。Lv.2では、こうした現場感覚が問われていると感じました。

テストも伸ばしどころだった

テスト分野は40%でした。完全に壊滅ではありませんが、合格ラインを考えると弱いです。

特に、次の内容は固める必要があります。

単体テスト
結合テスト
システムテスト
受け入れテスト
C0 / C1 / C2
カバレッジ100%の意味
テストダブル
Mock / Stub / Spy / Fake / Dummy
ブラックボックステスト
ホワイトボックステスト
セキュリティテスト

テストも、用語暗記だけでは足りません。

たとえば、カバレッジ100%だから品質が完璧というわけではありません。テストを通ったからバグがないというわけでもありません。

MockとStubの違いも、なんとなく覚えているだけだと選択肢で迷います。

アジャイル開発では、テストは後工程でまとめて行うものではなく、開発と一体で進めるものです。TDD、継続的インテグレーション、自動テスト、リファクタリングとセットで理解する必要があります。

リファクタリングと常時結合もあと一歩

リファクタリングと常時結合は、それぞれ50%でした。ここはあと一歩です。

リファクタリングでは、コードの不吉な匂い、重複コード、長すぎるメソッド、責務の分散、依存関係などを理解する必要があります。

リファクタリングは、単にコードを短くすることではありません。外部から見た振る舞いを変えずに、内部構造を改善することです。この定義を曖昧にしていると、試験で迷います。

常時結合、つまりCIについても同じです。CIは単にツールを導入することではありません。

ビルド、テスト、静的解析、デプロイなどを自動化し、早く問題に気づける状態を作ることが重要です。

何のためにCIを行うのか。誰のために自動化するのか。結果から何を読み取るのか。ここまで理解する必要があります。

モデリングと構成管理は維持する

一方で、モデリングと構成管理は80%取れていました。ここは維持でよいと思います。

モデリングでは、オブジェクト指向設計、継承、インターフェース、ポリモーフィズム、疎結合などが重要です。

構成管理では、Git、ブランチ、マージ、プルリクエスト、レビュー、コンテナ技術などが問われます。

この2つは、実務で触れている部分もあり、比較的対応できました。ただし、油断はできません。

次回も80%を維持できるように、復習は必要です。特にGitやブランチ戦略は、現場でもよく使う内容なので、試験対策だけでなく実務にもつながります。

次回の合格戦略

次回は、すべての分野を均等に勉強するより、弱点を重点的に潰す方針で進めます。

優先順位は次の通りです。

1. デザインパターン
2. コーディング
3. テスト
4. リファクタリング
5. CI/CD・構成管理は維持

特に、デザインパターンとコーディングは最優先です。ここが前回の最大の失点源でした。

この2分野を60%以上まで引き上げるだけで、全体の点数はかなり改善できるはずです。

次回の目標

次回は、次のような点数を目標にします。

Lv.2の合格基準を考えると、全分野で完璧を目指す必要はありません。ただし、20%台の分野があるとかなり厳しいです。

苦手分野を50〜60%まで引き上げ、得意分野を維持する。この方針で再挑戦したいと思います。

ChatGPTを使った次回対策

次回は、ChatGPTも積極的に使います。特に、デザインパターンとコーディングは、AIとの相性が良いです。

たとえば、次のように使えます。

Factory、Strategy、Observer、Commandの違いを、
アジャイルソフトウェア開発技術者検定Lv.2向けに整理してください。

このコードが読みにくい理由を説明してください。
読みやすく、テストしやすいコードに改善してください。

Mock、Stub、Spy、Fake、Dummyの違いを、
試験で迷わないように整理してください。

デザインパターンの四択問題を10問作ってください。
不正解の選択肢がなぜ違うのかも説明してください。

リファクタリングの観点で、
このコードの不吉な匂いを指摘してください。

AIに答えを聞くだけではなく、自分の考えをぶつける使い方をしたいです。

「私はこの選択肢が正しいと思ったが、なぜ違うのか」「この設計にはどのデザインパターンが近いのか」「このコメントは必要なのか、それとも命名で表現すべきなのか」

このように壁打ちすることで、理解を深められます。

公式問題集がない試験ほど、弱点分析が重要

アジャイルソフトウェア開発技術者検定Lv.2は、公式問題集だけを回して合格するような試験ではありません。

そのため、試験結果レポートを見て、自分の弱点を分析することが重要です。

私の場合、弱点は明確でした。コーディング。デザインパターン。テスト。この3つです。

逆に、モデリングと構成管理はある程度取れていました。つまり、次回は苦手分野を重点的に対策すれば、合格に近づけるはずです。

不合格になったこと自体は悔しいです。ただ、スコアレポートから次に何をやるべきかが見えたのは収穫でした。

これからLv.2を受ける人へ

これからアジャイルソフトウェア開発技術者検定Lv.2を受ける人には、次のことを伝えたいです。

Lv.1の延長だと思って受けると危険です。Lv.2は、開発チームメンバーとしての実践寄りの知識が問われます。

特に、デザインパターン、コーディング、テスト、リファクタリングはしっかり対策した方がよいです。

デザインパターンは、名前だけでなく使いどころまで理解する。コーディングは、読みやすく保守しやすいコードの判断基準を持つ。テストは、カバレッジやテストダブルを曖昧にしない。リファクタリングは、外部仕様を変えずに内部構造を改善することだと理解する。CI/CDは、ツール名ではなく、何のために自動化するのかを押さえる。

このあたりを固める必要があります。特に、デザインパターンを理解せずに受けるのは危険です。私がそうでした。

まとめ

アジャイルソフトウェア開発技術者検定Lv.2を受験しましたが、不合格でした。

敗因は明確です。デザインパターンとコーディングで大きく点を落としたことです。

結果レポートでは、コーディング20%、デザインパターン25%でした。一方で、モデリングと構成管理は80%取れていました。

つまり、全体的に何もできなかったわけではなく、弱点分野で大きく失点したことが原因です。

デザインパターンは、名前だけ覚えていても足りません。Factory、Strategy、Observer、Command、Adapter、Decorator、Facade、Proxyなどを、どのような場面で使うのかまで理解する必要があります。

コーディングも、文法だけではなく、読みやすいコード、保守しやすいコード、テストしやすいコードの判断が必要です。

次回は、デザインパターン、コーディング、テストを重点的に対策します。目標は、20〜40%だった弱点分野を60%以上に引き上げることです。

アジャイルソフトウェア開発技術者検定Lv.2は、Lv.1よりかなり実践寄りです。一度落ちたことで、自分の弱点がはっきりしました。

次は、デザインパターンとコーディングをしっかり理解して、リベンジ合格を目指します。

受験前の注意

試験時間、出題形式、合格基準、受験資格、出題範囲、再受験ルールは変更される可能性があります。

受験する際は、必ず公式サイトや試験配信会社の最新情報を確認してください。