スポンサーリンク
【国際資格を目指すならアビタス】私もここで教鞭をとっています。
ここ最近、システム監査の世界でもアジャイル開発についての議論が盛んに行われるようになってきました。
現在でも多くのシステム開発は、ウォーターフォール開発が用いられています。
ウォーターフォール開発は、「フィージビリティスタディ」「要件定義」「設計・選定」「開発・構成化」「導入」「導入後のレビュー」という6つのステップに分け、前のフェーズが完了してから次のフェーズに移行する、原則次のフェーズに移行したら前のフェーズに戻らないことを特徴としています。
ウォーターフォール開発は、発注側のニーズがある程度確定している場合に有効である場合が多く、元請け、1次下請け、2次下請けという多重構造となっている日本のソフトウェア開発業界にも発注管理がしやすことから多く場合で採用されています。
ただ、昨今、発注側のニーズが変わることが多くなり、また短納期で品質が高いことがもとめられることからアジャイル開発が採用される事例が増加しています。
アジャイル開発の特徴として、作業単位を分け少人数の複数のチームがウォーターフォール開発の「設計」「開発」「導入（品質検査）」を「短期間」で「反復」するところにあります。
アジャイル開発は、もともとトヨタ生産方式がモデルとされ、発注側とのニーズについての密接なすり合わせが必要で、開発側にも高い開発スキル・コミュニケーションスキルが必要となります。
アジャイル開発の理念をつかむうえでは、「アジャイルソフトウェア開発宣言」が参考になります（考え方自体は、ウォーターフォール手法を採用している場合にも必要な視点ですが、アジャイル開発では価値の創造を強調しています）。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
では、アジャイル開発されているソフトウェアを監査（内部監査がメインとなります）する際には、どこを注意しなければいけないでしょうか。
リスク①：アジャイル開発では、管理用の資料がウォータフォール開発に比べ少なく・上書きされてしまう資料が多いことが特徴です。また開発チームごとに進捗管理手法が異なっており、遅延（トラブル）が発生した場合の状況が開発チーム以外の者には分かりにくい。
リスク②：アジャイル開発そのものに、発注側、開発する側ともに慣れていないことが多く、結果的に予算超過となりやすい。
アジャイル開発については、きめ細かな進捗管理が重要となるため内部監査が重要な役割を担うことになります。
対応①：開発チームが、進捗管理・トラブルの把握に用いている手法（WBS？・システム？・ホワイトボード？・付箋？）を把握し、報告用の資料・入手の頻度についてプロジェクトマネージャーとなるべく早い時期に合意する。
対応②：発注側の仕様の変更依頼、変更が当初の開発スケジュール・予算に与える影響について把握できるような資料を依頼する。
