アジャイルが，いよいよ高度系に。PMBOKv6の件もあるので，来春はPMでもアジャイルが出題されるな。ただ，テキストのページ数はあんまり増やせないので，Web連動で情報提供をしていきたい。
と，そんなことより。システム監査。
//過去問題との関係性//
アジャイルをテーマにした問題は初。開発手法なのでプロジェクト分野の監査かな。
設問イではリスクと（必要な）コントロールが，設問ウでは監査手続きが問われているので，その点に関してはオーソドックスなパターンの問題。
//設問ア//
ここは，設問イのリスク，コントロールをある程度限定する部分なので，採用する理由と開発の内容に関しては，必ず設問イのリスク・コントロールとワンセットで考える必要がある。きちんと連携できているかどうかが重要になる。
//設問イ//
設問イで，リスクと（必要な）コントロールが問われているので，ここでは監査人が必要だと思っているリスクとコントロールを書く。但し，一般論ではなく，設問アでアジャイル開発採用する理由及びアジャイル開発の内容に応じたリスクとコントロールを書く。設問イの最初に「設問アで述べた」とあるから。
加えて，①アジャイル特有のもので，②それはウォータフォール型開発とは異なるもので，③設問ウの監査手続きの，“体制”，“スキル”，“開発環境などの整備状況”につながるものなので，それをベースに考える。③があるので「アジャイルに向いたシステムか否か？」のような…体制・スキル・開発環境以外のリスクやコントロールに関しては適当ではない（ただ減点されるかどうかは不明。そんなに制度の良い論文は多くないはずなので）。
一般論だと次のようなものが考えられるので，そこから設問アに合致する内容で絞り込めばいい。繰り返しになるが，一般論であったとしても設問アと関連付けて書くこと。これ重要。
まずは体制面だけど，アジャイルの場合は…ビジネス要件の取り込みを繰り返すわけだから，開発者側だけの体制ではダメで，常時ビジネス要件に対し決定権を持つ人とペアで動く必要がある。ユーザも開発チームの一員としてウォータフォール以上に主体的に参画しないといけない。その体制でないとビジネス要件の取り込みができない。そのあたりのリスクと，コントロールを書く。
他にも，運用担当者やＵＩ担当者，仕様書を書く人など，必要に応じて，その役割持った人材をチームに入れることもある。要するにプロジェクトの特性に応じた体制になっていないといけない。
後は…アジャイル開発そのものの経験者の有無。チーム全員が経験者じゃないといけないわけではないけど，指導しながら進めていける経験者が十分かどうかも体制面で書ける。
場所でもいいかな。体制に含まれるかな。コミュニケーションを随時取っていくので，地理的に分散した体制では十分なコミュニケーションが取れない場合もある。それが何かしらの方法でコントロールされている必要がある。
後は…範囲が決まっていない中，ある意味性善説で開発を繰り返すので経営者や利用者の理解も必要だという点でもいいか。
開発環境などの整備状況に関しては，アジャイル特有の管理ツール（プロジェクトマネジメントツール）を使っているかどうかです。
次にスキル。スキルは，アジャイル開発に関するスキル，開発環境の利用経験，コミュニケーションスキル，設計，開発，テスト，リリースなどオールマイティなスキルが必要になります。要するに，セル生産方式のように，メンバに求められるスキルセットが広範囲になりがちで，その分，個人差も大きくなりがちなので，そうなると計画通りに行かないので。
最後に開発環境。アジャイルに特化したマネジメントツールや，テスト工数がどうしても多くなりがちで，繰り返し類似のテストをすることも少なくないので，テストツールの導入について言及してもいいだろう。
そんなところか。
//設問ウ//
ここは例年通りの監査手続きが問われている。監査証拠と確認すべきポイントを要求されている。但し，これらは要求されなくても監査手続きの表現として書くように準備しておく必要がある。
加えて，平成25年以来…具体的に監査項目が指定されている。体制，スキル，開発環境だ。これらの“整備状況”を“開発着手前”に確かめるとなっている。
で，設問イが監査人の考えるリスクとコントロールなので，当事者が誰か？プロジェクトマネージャやスクラムマスター等の責任者を明確にし，監査証拠としてはい体制図以外，スキルや開発環境などの整備状況はドキュメントがあるのか，ないのかを明確にして，それに応じた監査手続きを書けばいいだろう。監査証拠を含めないといけないことから，実際の当事者がどのようなコントロールをしているのか（そこで利用されているドキュメント等の存在）は書いた方がいいだろう。
とはいうものの…おそらくここで，実際にどういうコントロールが行われているのかを書かずに，唐突に監査証拠を書いたとしても，そういう論文が大多数だと思うので，そこは許容範囲だと思う。
但し，監査人がその内容をみて「アジャイルに適しているかどうか？」を判断するのではなく，アジャイル開発経験者や品質管理部門，PMOなどのレビューの議事録や承認印があるかどうかの方がいい。
数としては…監査項目ごとにコントロールが機能しているかどうかなので，予防牽制，誤謬適示，修正回復の３点もしくは２点（予防と事後）ずつで書けば，６～９になり，字数も1000字くらいにはなるだろう。
//感想//
PMBOKｖ６がアジャイル対応が目玉の一つなので，平成31年春にはアジャイルが高度系でも来るだろうと思っていたけど，監査で最初に来るとは思いもしなかった。１年早い。
したがって…アジャイル開発経験者は書きやすいだろうけど，未経験者は避けた方がいい。しかし問２が「設問ウが監査手続き」のパターンではないので，アジャイル開発未経験者でもこっちを選ぶ人は多かったはず。
さらにアジャイル開発経験者が，しっかりと設問イでアと関連付けるとともに自分の意見とし，設問ウで監査手続きの表現にできているとは限らない。
したがって，アジャイル開発のリスクやコントロール，監査手続きが少々ピント外れでもＡ評価になると思われる。かなり合格論文のレベルは低いと見た。
（以上）