
アジャイルソフトウェア開発技術者検定(通称:アジャイル検定)を受けてきました。個人的には、圧倒的な根拠のない自信によって100点満点だと思っていましたが87点! 7〜8問間違えた計算になります。この試験、ものすごく癖があるので、受験した経験から傾向と対策を考えてみます。
アジャイル検定の傾向
試験は1時間で60問となりますが、4択から正解をひとつ選ぶ方式なので、サッと解いて、気になるところを見直しても時間には余裕があります。
問題はレベル1試験の場合、
- 基礎知識
- プロジェクト管理
- 開発チームの運営
- 開発技能
からまんべんなく出題されます。書籍で試験対策するなら『アジャイル検定公式テキスト(レベル1対応)』だけで十分です。公式テキストを読むだけで十分なテスト内容でした。
アジャイル検定の対策
基本的に、アジャイル開発はアジャイルマニフェストに行き着くので、アジャイルマニフェストの内容の理解が重要です。
そして、この試験はものすごく癖がある試験です。アジャイル開発経験のある方が公式テキストを読めばすぐに気が付くはずです。
また、自分の試験結果を見る限りですが、間違えた箇所はプロジェクト管理と開発技能の2分野でした。思い返してみると「うーん。これどっちもあってるなぁ」とか「うーん。これどっちもまちがってるなぁ」というものがいくつかありました。
なぜこのような問題があったのかを考えた場合、アジャイル開発ならではの特性の影響があると思います。
具体的に書くと、アジャイル開発は価値観なので「これが正解」というよりも「こういう方向性」になります。だから、状況によって選択肢が変わったりするのですが、検定ですから「答えが2つある」は困ります。よって、いくつか選択肢がある場合でも「これが正解である」と決めつけている部分がこの試験にはあります。
本来、出題者側としては試験で学んだことを現場で役立て欲しいはずですが、決めつけた答えが実際の現場にはマッチしないのではないか?と思う問題もいくつかありました。
それでは、まず「癖のある部分」として試験の用語を解説し、「決めつけた答え」部分は出題分野に合わせて対策を考えていきます。
用語対策
まず、いくつか謎の言葉があったので、これが何なのかを考えてみます。
- 顧客の代表: 多分、「チームの一員である」という雰囲気がちらほらあったので、文脈的にビジネスではなく開発チームの中の役割を指している。ただ、表現がSI特有なので、プロダクトマネージャやプロダクトオーナー(PO)に置き換えると良さそう
- コーチ: 多分、アジャイルコーチを指していて、公式テキストだと「チームリーダー」という言葉も登場するが、スクラムマスターを指している
また、「アジャイルの検定」なので、スクラムの言葉をできるだけ避けようとしているのもこの試験の特徴です。スクラムが言葉で世界を分断した結果、神が怒ってしまったのでしょう。人間はいつまでも愚かです。
よって、以下の用語は、使い慣れた言葉に置き換えると良いでしょう。
- イテレーション = スプリント
- ストーリーを含めた製品要求一覧 = プロダクトバックログ
- 成果物 = インクリメンタル
- イテレーション計画 = スプリントプランニング(計画)
- タスク一覧 = スプリントバックログ
- イテレーションのレビュー会議 = スプリントレビュー
- イテレーションの振り返り = スプリントレトロスペクティブ
- スタンドアップミーティング = デイリースクラム
七面倒臭いですね。その割には「バックログ」という言葉が急に試験に出てきて「なんじゃそりゃ」ってなりました。
決めつけられた答え
個人的に「うまくいけばどんな方法でもいい」と思うので、正解を求めるつもりはないのですが、試験ですからそうもいってもいられません。自分が気になった「決めつけ」は以下です。ここでは反論するつもりはないですが、議論するきっかけになるのではないかと思います。
- 基礎知識
- アジャイルマニフェストと12の原則の意味を覚えておくだけで十分
- プロジェクト管理
- ビジョンはみんなで知っている方がいい
- イテレーションの中でタスク・ストーリー・メンバーの変更はしない
- 要件はストーリーである
- ストーリーは顧客が受入れテスト実施するときの評価基準になる
- スプリントバックログ項目はタスクと同一である
- イテレーションは固定期間、絶対変えない
- イテレーションごとにリリースする
- イテレーション計画は細かく立てない。まとめて立てない。イテレーションごとに立てる
- イテレーション計画は2部制で行う(1部はPOの説明とゴール設定、2部はストーリー選択とタスク洗い出し。2部はPOの参加が任意)
- イテレーション計画第1部でストーリーのリファクタリングを行う
- イテレーションレビューはイテレーションの最後にやる
- ふりかえりはイテレーションの終了後にやるが、必要があればイテレーション中でもやる
- ストーリーはポイントで見積もる
- 設計判断の根拠を示したドキュメントをイテレーション内に作成する
- イテレーション開始前にアーキテクチャ設計のドキュメントを作る
- 運用・保守ドキュメントを作る
- 開発チームの運営
- 全員で責任を持つ
- 全員で一緒に働く
- 誰かが特定のことをしない
- 誰かが属人的にならない
- 少数チーム、大規模なら複数チーム
- アジャイルコーチは、ファシリテーションを行う
- 開発技能
- ペアプロで生産性は下がるが、ペアプロで品質が上がったり教育面に貢献するのでやったほうがいい
- ペアプロの役割や相手は定期的に変えたほうがいい
- リファクタは一度に実施しない。リファクタは適度なタイミングで実施する
- リファクタはいろんなメリットがあるのでやったほうがいい
- リファクタはやめ時を考えること
- CI(常時結合)で失敗したらすぐ治す
- TDDではテストケースを1つずつ増やしていく。まとめて増やさない
*
僕が間違えたのは多分このへん。
- イテレーションは固定期間、絶対変えない ⇒ イテレーション中でも再計画するならストーリーの変更してもいいと思う
- ストーリはポイントで見積もる ⇒ 理想日でも見積もれる
開発技能部分は、リファクタの仕方とかで知らないお作法があった感じ。
試験については、基本の確認であればちょうど良い試験かもしれない。それよりも、アジャイルコーチを呼んで勉強会&ハンズオンとかしたほうがきっと身につくと思う。
リンク: アジャイルソフトウェア開発技術者検定試験