山本　慎一郎

先日、アジャイル開発に対する監査「アジャイル監査」のセミナーに参加しました。

従来からあるプロジェクト監査は、従来型であるウォーターフォールモデルには適合するものの、近年のアジャイル開発には適用しにくいのではないかというのが主なテーマでした。
ちょっと専門用語が多すぎですね。
簡単に説明しておきます。

まず、従来の開発プロジェクトというのは、はじめに要件定義を全部やって、次に設計を全部やって、それからプログラミングを全部やって……と、ひとつひとつの作業をすべて完成させてから行っていました。
これがウォーターフォールモデルです。
そして、各作業がすべて終わった段階でプロジェクト監査を行うことで、次の作業に移る前に、プロジェクトが適切にコントロールされているかを確認していました。

一方、アジャイル開発というのは、作りながら完成度を高めていく手法です。
決まっている部分から要件を整理して、設計して、プログラミングをする。
それを何度も繰り返すことで、最終的に完成を目指します。

この繰り返しの単位を「イテレーション」と呼びますが、特徴的なのはこの「イテレーション」の期間が非常に短いという点です。
従来のウォーターフォールの場合、各作業は１ヶ月以上、長いものでは半年以上の期間をかけて行うことが主流でした。
これに比べて、アジャイル開発のイテレーションは非常に短く、大体２週間程度、短いものでは１週間です。

さて、ではアジャイル開発では、従来からあるプロジェクト監査が適用しにくいというのはどういうことでしょうか。
問題は色々あるのですが、特に注目したいのは以下の３点です。

• 監査、フィードバックのタイミング
• 監査内容（手続、証跡等）の柔軟性
• アジャイル手法に関する理解

ひとつめは、監査、フィードバックのタイミングです。
ウォーターフォールでは、各作業の完了時がちょうど区切りの良いタイミングでした。
大体、数ヶ月に１回。
監査にかかる負担も考えると、比較的許容されやすい頻度だと思います。

一方のアジャイル開発では、「イテレーション」の区切りは１～２週間に１回訪れます。
つまり、数ヶ月に１回どころか、１ヶ月に数回、監査を行うことになります。
これは、監査をする側もされる側も、かなりの負担になる可能性が予見されます。

ふたつめは、監査内容（手続、証跡等）の柔軟性です。
アジャイル開発は、その特徴として、顧客の要望などを迅速かつ柔軟に汲み取り開発に反映させられるという点があります。

これを踏まえると、当然、監査の手続きや取得すべき監査証跡も、要望の変化に応じて変わっていくことになります。
そうすると、プロジェクトの当初に想定してた監査計画から大幅に変わることになり、計画が陳腐化してしまう可能性が高くなります。
すなわち、従来のような、しっかりと計画を立てて決められたタイミングでじっくり監査を行うという手法が通用しなくなります。

みっつめは、アジャイル手法に関する理解です。
アジャイルの考えを取り入れた活動では、従来のウォーターフォールでは愚策とされていたことが推奨されていたりします。
従って、これまでの経験や知識だけでは、最適な監査活動を行うことができません。
座学や講習など、何らかの形で「アジャイル」という手法について理解を深めておく必要があります。

これらの課題に対して、セミナーでは、アジャイル開発に適合するためには、監査の活動もまたアジャイルでなければならないというような結論でした。
すなわち、監査も「イテレーション」のような短い期間で繰り返し行い、開発側へのフィードバックもそれに応じた短い間隔で行われるべきというお話です。

なるほど。
開発がアジャイルになるのなら、監査もアジャイルにしてしまえば、うまく適合するのではないかという方法論ですね。
確かに効果的なように思えます。

一方で、セミナーでも質問が上がっていましたが、監査側があまりにも開発側に寄り添いすぎると、監査人の基本要件である「独立性」が損なわれてしまいます。
開発側の状況を鑑みて監査の指摘が甘くなってしまうようでは、本末転倒です。

結局のところ、現段階ではまだアジャイル開発に対する監査のベストプラクティスというのは出てきていないようでした。
また、監査の現場も開発の現場と同様、理想と現実の乖離が大きいようなので、その点も考えなければならないと感じました。

中々どうして、うまくはいかないものですね。

それでは、新たな監査のカタチに考えを巡らせる、山本慎一郎でした。