アジャイル開発と監査について
所属する組織でアジャイル開発のプロジェクトが立ち上がったとき、プロジェクトを監督する部門ではどのようにプロジェクトをモニタリングすれば良いかわからず、随分と模索したと聞いたのは今から5年以上前のことだ。
自分はその前からウォーターフォールの皮を被ったアジャイル開発という名のカンバンやアジャイル開発でのいくつかのプラクティスを『プロジェクトの立て直しの目的』で導入した経験があった。そういった背景もあり、アジャイル開発プロジェクトでのモニタリングの勘所はわかっていた（つもり）なので、模索している時間があったらアジャイル開発（のどの手法を取るかを確認した上で）の情報収集をして仮説でプロジェクトのモニタリングモデルを作り、プロジェクトチームと話せばいいのに、と思っていた。
経験知があるなら助けてあげればいいじゃないと思うかもしれないが、何か助けるだけのリソースを持ち合わせていなかったのだろう。
プロジェクト型の事業を主たる事業とするのであれば、その事業をモニタリングし、事業の健全性をコントロールすることを経営から求められる。経営者は、そうした要求にはリソースを割り当て、報告を求め、経営者として判断を行う。
さらに第三者の観点で監査を取り入れ、外部のステークホルダに対する説明をできる状態にする。ここで監査人が必要となる。
組織内でのモニタリングやレポーティングを主管とする部門は内部監査にあたり、監査法人が行う場合は外部監査に当たる。
アジャイル開発はかれこれ導入されて20年近く経つが、IT業界のメインストリームに流入し始め、認知されたのはここ数年というのがいわゆるSIer界隈なのではないだろうか。こうした認知に引き摺られて、外部監査もアジャイル開発に対する監査を行う必要が出てくるが、従来のスコープ固定、金額固定、スケジュール固定と変更管理によるプロジェクトマネジメントと乱暴に言えば対極にある（とするとアジャイル界隈の方は言いたいことがあるかもしれないがそれはご容赦いただくとして）アジャイル開発に対する監査ニーズは現場で案件が発生しないと発生しないため、現場より遅れてやってくる。
インターネットで調べてみるとセキュリティ団体が1年と少し前にアジャイル開発と監査について勉強会を開いていたようだ。
そのあと、内部監査に関する公認会計士の方が視点として書かれている。
www.marunouchi-internal-audit.com
読んでみると、視点として書かれていることに多少もやもや感が残る。
リスク①：アジャイル開発では、管理用の資料がウォータフォール開発に比べ少なく・上書きされてしまう資料が多いことが特徴です。また開発チームごとに進捗管理手法が異なっており、遅延（トラブル）が発生した場合の状況が開発チーム以外の者には分かりにくい。
アジャイル開発では管理用資料がウォーターフォール開発に比べ少ないとは何をエビデンスとしていっているのだろう。まるでウォーターフォール開発の管理用史料が多いみたいじゃないか。
プロジェクトマネジメントを管理する上で、管理用資料の多少との相関関係はあるのだろうか。自分としては認めにくいと考える。なぜなら、スコープ、予算（予実）、品質、スケジュール（予実）の4点をコントロールするに十分な情報を必要とするメッシュで持っていればよく、その形態は問われないと考えるからである。この辺りは、外部の監査人としてはエビデンスベースでしか監査をせざるを得ないからと推測する。
あと、『上書きされてしまう』の意味を理解できなかった（すっと入ってこなかった）のだが、対応で結びつけることができた。物理カンバンを指しているだろう。
さらに、トラブったら開発手法なんて関係は一切ない。ウォーターフォールの方が失敗することは以前のエントリにも書いている。
リスク②：アジャイル開発そのものに、発注側、開発する側ともに慣れていないことが多く、結果的に予算超過となりやすい。
予算超過は、何かしらの原因があってプロジェクトがオーバーランした事象でしかない。不慣れも不慣れだと認識して開発も発注者側も計画を立てればよいのであって、不慣れが原因ではなく、不慣れであることに対する対策がないことが原因ではないだろうか。
対応①：開発チームが、進捗管理・トラブルの把握に用いている手法（WBS？・システム？・ホワイトボード？・付箋？）を把握し、報告用の資料・入手の頻度についてプロジェクトマネージャーとなるべく早い時期に合意する。
監査人は内外に関わらず、プロジェクトのステークホルダになりうるが、プロジェクトチームの邪魔をしていいわけではない。プロジェクトチームのプロジェクトマネジメント 、システム開発手法、導入するツール＆テクニックをヒヤリングし、経営が必要とする管理メッシュと一致するところを探さなければならない。
それを合意と言うのならそうかもしれない。プロジェクトチームのプロジェクトマネジメントのメッシュが経営が必要とするレポーティングにあっていなければ、である。ただこれはマネージャが言えばいいことであって、監査人であれば、メッシュがおかしいと問題提起することが仕事ではなかろうか。
対応②：発注側の仕様の変更依頼、変更が当初の開発スケジュール・予算に与える影響について把握できるような資料を依頼する。
これも、監査のための資料を作らせることを前提としているが、アジャイル開発のスピード、プロシージャの理解を深められた方が監査をする側もされる側も協力し合えると思える書きっぷりである。
なぜかは、対応①の最後の経営に対するレポーティングのメッシュの問題に起因するためである。
対応③：上書きされてしまうことも多いため、監査する側でも入手した資料の保管する。
物理で付箋を捨ててしまうことを指しているなら、それは監査人はプロジェクトチームとある時期一緒に過ごす必要があるのではないだろうか。
デジタルであればプロジェクトの情報を物理削除するような面倒なことを運用でするとは思えない。ちょっと的外れな気がしているのだが何か別の心配からエビデンスの確保をいっているのだろうか。
アジャイル開発と監査は別に難しいことはない。ウォーターフォールでされ、プロジェクト毎にお作法も管理メッシュもマネジメントも違う。
開発の明確なスピードの違いはあるが、手段は違ってもやっていることは変わらないのである。
いずれにしろ、アジャイル開発のプロジェクトチームも監査人も何をしたいのか双方が会話をすることで双方のやりたいことを邪魔をせず、協力し合えるし、協力しなければならない。
どちらもお仕事だからね。
