ISACA東京支部調査研究委員会
システム監査手法研究会 アジャイルDevOps分科会
2022年3月

アジャイル開発チェックリスト Ver1.0※文末が「～すること」は必須確認が必要な具体策。但し開発案件に該当しない等、適用しない旨整理することで対象外とすることも可。文末が「～望ましい」は必要に応じて適用。参考情報については、（参考）を文頭に記載。

章立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）
Ⅰ.ITガバナンス
1.方向づけ（Direct）
1.経営陣は、組織や部門等にアジャイル開発手法を受入れる組織風土や教育を推進し、基本方針を明確にして承認していること。
(1)経営陣はアジャイル開発手法の導入にあたり、基本方針を文書化して明確にしたうえで承認し関係者へ周知していること。基本方針は一般的なアジャイル開発手法の原則に従っている必要がある点にも留意すること。なお、経営陣がアジャイル開発
手法を理解していることが手法導入の前提になる。
（参考）例えば、経営陣の中にアジャイル開発の経験者がいる、アジャイル開発手法に関する資格を保持している、又は関連する研修を受講済である等。
(2)アジャイル開発手法を前提とした文化・組織風土の形成を経営陣が中心となり実施していること。
（参考）例えば、組織全体へ、又はプロジェクトに対しメッセ―ジを発信し手法や手法導入を経営陣自らが推進している。プロジェクト等へ経営陣が積極的に関与している等。
(3)経営陣はアジャイル開発手法の概念や枠組みに関する教育や基本方針が、組織（全社・特定部門等）、又はシステム開発プロジェクト等のすべての関係者（外部委託先を含む）に周知されるよう推進すると共に執行部門のマネジメントへこれらを指示していること。
2.経営陣は、開発プロジェクトに対しアジャイル開発手法の適用可否を判定し、承認していること。
(1)アジャイル開発手法による開発プロジェクトを組織として網羅的に把握するための仕組みが整備されていること。
（参考）例えば、開発案件を一覧化して、アジャイル開発手法の案件が特定できること。それらは開発規模や重要性等により、必要に応じて経営陣や取締役会に報告されている等。但し、開発規模や案件の重要性等に応じて、マネジメントレベル(企画フェーズ)で判定のうえ承認するこケースもある(2)開発プロジェクトにアジャイル開発手法を適用する際に、適用可否判定プロセスを設け、規模や重要性等に応じて、経営陣や権限移譲された責任者（適用可否を判断できる経験やスキルがある要員等）が承認していること。
3.経営陣は、アジャイル開発手法を適用するプロジェクトについて、すべて、又は一部を外部委託する場合は必要に応じて契約形態がプロジェクトに適しているかを判定し承認していること。
(1)アジャイル開発手法による開発プロジェクトをすべて、又は一部を外部委託する場合は契約形態が該当プロジェクトに適しているかを経営陣や権限移譲された責任者が判定し、必要に応じて経営陣が承認するプロセスを整備して運用していること。
（参考）契約形態の例として以下が挙げられる。（IPA｢アジャイル開発向け モデル契約案について（2012.5.23）｣より）
例.基本契約個別契約の併用:プロジェクト全体に共通する事項につき、基本契約をまず締結する。その後、小さな単位（機能単位やリリース単位等）ごとに、開発対象と費用がある程度確定したタイミングで個別契約（請負又は準委任）を順次締結する。
4.経営陣は、アジャイル開発手法に基づくプロジェクトにおけるプロダクト・オーナ(以降、「PO」という。)を任命して適切な権限及び責任を与えていること。
(1)POはプロダクトの成果に責任を持つ役割として、1人の個人に割当てること。その人物に要件の優先順位付けや、仕様の決定を行う権限を持たせること。また、POは頻繁に開発者と対話しながらプロダクトの価値を最大化するために作業を行うこと。
なお、開発規模や重要性など案件の状況に応じて、企画フェーズで任命する場合もある。
(2)POの役割及び責任として以下のスキル等が一般的に求められるため満たしていること。
(ｱ)POはプロダクトの業務領域のエキスパートであることが望ましい。
(ｲ)プロダクトに必要な機能を定義し、その機能を順位付けできるスキルを持っていること。
(ｳ)POは開発チームに目的・ゴールを踏まえた機能概要を説明して理解させ、加えてプロダクトビジョンを示すスキルを持っていること。
(3)大規模開発案件等、複数チームに別れて開発し、各チームにPOを配置する場合で1プロジェクトのPOを複数人で構成する場合は、PO同士の合意形成を充分に行い、PO毎に意見が異なり開発チームが混乱することを予防すること。
（参考）1プロジェクトのPOを複数人で構成する場合でも最終的にはPOの1人（最も権限が与えられているPO）が意思決定するケースもある
2.モニタリング（Monitor）
1.経営陣は、アジャイル開発手法に基づくプロジェクトの進捗状況を関係者から吸い上げて経営報告させ必要に応じてガバナンスレベルの指示を行っていること。
(1)アジャイル開発手法を活用したシステム開発はニーズの変化も早い、例えばデイリースクラムやイテレーションレビュー等で発覚した問題点や課題をマネジメントレベルが吸い上げて、経営影響のある問題は経営陣（ガバナンスレベル）まで適宜報告される一連のプロセスを整備して運用していること。開発途中の適切なタイミングで経営層が情報収集して、評価・判断・指示できる仕組みを保持して運用されることが望ましい。
(2)経営陣や取締役会が開発規模や重要性に応じて、実際のプロジェクトの進捗や品質・コスト管理等、実態を把握して確認・検証・指示できるプロセス（現場視察を含む）を整備して、運用していること。
3.評価（Evaluate）
1.経営陣は、アジャイル開発手法に基づくプロジェクトに関する成果を経営レベルで評価する仕組みを保持し、機能させていること。
(1)プロジェクト終了時の結果だけで、アジャイル開発手法に基づくプロジェクトの評価が行われないこと、自社の今後を見据えた評価（プロセスの見直しや改善に繋がる観点等を含む）がなされる仕組みが整備されていること。
2.経営陣は、アジャイル開発手法に基づくプロジェクトのリスク評価を実施する仕組みを保持し、取締役会等で評価結果を承認していること。
(1)アジャイル開発手法を活用したプロジェクトを企画、又は開始するにあたり、開発規模や自社に与える影響を踏まえた重要性等に応じて、アジャイル開発手法や該当プロジェクトの特徴を踏まえた経営（ガバナンス）レベルのリスク評価が行われていること。
(2)予め評価したこれらリスク評価結果は、マネジメントレベルへ伝達されること。
（参考）例えば、開発手法をウォータフォールモデル等の従来型から新たにアジャイル開発手法に変更した場合等、要員スキルや品質確保を起因としたビジネス他への影響、柔軟な変更を前提とした専門家（ソフトウェアの会計処理他、会計専門家
関与等を含む）の活用やコスト管理等、外部リソースの活用の判定とその影響確認等を行っていること。
(3)ガバナンスレベルのリスク評価結果を踏まえて、プロダクト・オーナーはリリース計画を策定していること。
4.監督と監査1.経営陣は、アジャイル開発手法に基づくプロジェクトの可監査性を保証する仕組みを保持して機能させていること。
(1)アジャイル開発手法を活用したシステム開発プロジェクトにおいてもリスク（システムリスクやプロジェクトリスク、情報セキュリティリスク、サイバーセキュリティリスク等）に応じた適時適切な監査が実施できるよう経営陣や取締役会等（ガバナンスレベル）が推進してマネジメントレベルへ周知する等、監査実施を妨げないルールを策定して運用していること。
（参考）アジャイル開発手法を活用したシステム開発プロジェクトにおいても従来型の開発プロジェクト同様に可監査性が求められる。特に判定・合意の記録化については、電子記録（進捗管理ツールや静止画・動画・録音）や監査部門の各種ミー
ティングへの参加による確認等、アジャイル開発手法に合わせた記録化のルールを整備して運用することが望ましい。
項立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）

Ⅱ.ITマネジメント
1.計画(Plan）
1.ユーザーがアジャイル開発のノウハウを持つベンダー企業へ委託する場合、ユーザー企業とベンダー企業双方が契約に基づく権利義務関係について理解し、適切な契約で委託すること。
(1)本管理策は以下の契約モデルを参考に、原則として準委任契約で委託することが望ましい。
（参考）IPA:アジャイル開発版「情報システム・モデル取引・契約書」～ユーザー／ベンダー間の緊密な協働によるシステム開発で、DXを推進～HP上に掲載されている以下の資料を必要に応じて参照にすること。
・アジャイル開発外部委託モデル契約（解説付き）
・契約前チェックリスト
・アジャイル開発外部委託モデル契約書（ひな型）・アジャイル開発進め方の指針(2)ユーザー企業とベンダー企業双方のプロジェクト関係者がスクラムを理解していること
2.ユーザー企業がアジャイル開発のノウハウを持つベンダー企業へ開発業務を委託する場合、ユーザー企業所属のスクラムチームメンバーがベンダー企業所属のスクラムチームメンバーへ作業を依頼する際、契約違反とならないよう必要な対策をとること。
(1)ベンダー企業に委託する場合、ユーザー企業所属のスクラムチームメンバーに対し協働体制上の注意点について、教育や周知を行い業務を実施すること。
（参考）例えば、ユーザー企業側のメンバーが直接ベンダー側のメンバーに対し直接指示をしないこと。ただしベンダー側のメンバーが自主的な判断ができる場合（実施責任者（業務遂行責任者ともいう）が会議に同席する、場合によっては指示された作業を断ることができる仕組みにするなど）を除く。
上記について必要に応じて、Information-technology Promotion Agency, Japan（以降、「IPA」という）が公表する「アジャイル開発外部委託モデル契約」等を参照のうえ必要な対応を行うこと。
3.ステークホルダーとスクラムチームは、スクラムのルールを理解してプロダクトのビジョンを共有し、協働しながら開発を進めることを合意すること。
(1)本管理策、具体策はスクラムを前提にする。スクラムのルールとは「スクラムガイド2020」を指す。以下の概念、定義は「スクラムガイド2020」、「アジャイル型開発におけるプラクティス活用リファレンスガイド（IPA公表）」を参考にスクラムの概念に準拠すること。これら用語は後段で別途説明をする。
・４つのプロセス（スプリント計画ミーティング、デイリースクラム、スプリントレビュー、レトロスペクティブ（それぞれⅢ.開発フェーズ（反復開発）のNo.2、No.4、No.6、No.8を参照）と４つのプロセスを包含するプロセスであるスプリント
・スクラムの作成物（プロダクトバックログ、スプリントバックログ、インクリメント（それぞれⅡ.ITマネジメントのNo.9、No.11、No.13を参照））
・合意されたゴール（プロダクトゴール、スプリントゴール、完成の定義（それぞれⅡ.ITマネジメントのNo.10、No.12、No.14を参照））(2)ステークホルダー（社内におけるプロダクト利用者や開発プロジェクト関係者）によるスクラムへの理解を促すために、スクラムマスター（Ⅱ.ITマネジメントのNo.5を参照）は、ステークホルダーへスクラムルールを教育すること。
4.プロダクトオーナーはスクラムチームが生み出すプロダクトの価値を最大化すること。
(1)経営陣、またはプロダクトの開発規模に応じた権限者がプロダクトオーナーを任命すること。
(2)プロダクトオーナーは、効果的なプロダクトバックログ（プロダクトに追加する要求事項であるストーリーのリスト）管理をすること。
a)スクラムチームとステークホルダーにプロダクトゴール（スクラムチームが目指す将来のプロダクトの状態）を策定し、明示的（このプロダクトを使うとできることは何か、既存のものとの違い、ステークホルダーからの期待は何か、ステークホルダーにとっての利点は何か）に伝えること。
b)プロダクトバックログアイテム（プロダクトバックログの各ユーザーストーリー項目を優先順位づけをしたもの）を作成し、スクラムチームとステークホルダーに明確に（ユーザーストーリーを）伝えること。
c)プロダクトバックログアイテムをビジネスや開発状況に応じた優先順位の高い順に並び替えること。
d)プロダクトバックログに透明性（スクラムチームとステークホルダーが作業の状態が把握できること）があり、見える化され、（スクラムチームとステークホルダーに）理解されるようにすること。
e)a)~d)の作業は、プロダクトオーナーが行うこともできるが、他の人（プロダクトオーナーが編集を許可した者）に委任すること。いずれの場合も、最終的な責任はプロダクトオーナーが持つこと。
(3)組織（プロジェクトの実施主体）はプロダクトオーナーの意思決定を尊重し、プロダクト開発がより円滑に進むよう協力すること。
(4)(2)~(3)の決定は、プロダクトバックログの内容や並び順、およびスプリントレビューで検査可能なインクリメント（リリース判断可能なプロダクト）で見える化（プロダクトのデモンストレーション）すること。
(5)ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーと協議し合意を得ること。
5.スクラムに十分な経験・実績を有するスクラムマスターをプロダクトオーナーが選任すること。

1／5

ISACA東京支部調査研究委員会
システム監査手法研究会 アジャイルDevOps分科会
2022年3月

アジャイル開発チェックリスト Ver1.0※文末が「～すること」は必須確認が必要な具体策。但し開発案件に該当しない等、適用しない旨整理することで対象外とすることも可。文末が「～望ましい」は必要に応じて適用。参考情報については、（参考）を文頭に記載。

章立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）(1)スクラムマスターは、スクラムチームとステークホルダーに対し、以下のことを実施することで、その責任（スクラムチームとステークホルダーがプロダクトゴールを実現すること）を果たすこと。
a)スクラムチームとステークホルダーにスクラムの理論と5つの価値基準、プロセス、作成物（Ⅱ.ITマネジメントのNo.2の（1)を参照）を全員に理解してもらえるよう支援すること。
b)スクラムチームの有効性（プロダクトゴール実現化に向けた活動）を最大化すること。
c)スクラムチームがスクラム内でプラクティスを改善できるようにすること。
(2)スクラムマスターは、以下のようにさまざまな形でスクラムチームを支援すること。
a)自己管理型で機能横断型のチームメンバーをコーチすること。
b)スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できる(スクラムチームがプロダクトゴールに向けて可能な限り進捗できるようすること）よう支援すること。
c)スクラムチームの進捗を妨げる障害物を排除するように働きかけること。
d）すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックス（一定の時間枠）の制限が守られるようにすること。
(3)スクラムマスターは、以下のようにさまざまな形でプロダクトオーナーを支援すること。
a)効果的なプロダクトゴールの定義とプロダクトバックログ管理の方法を探すことを支援すること。
b)明確で簡潔なプロダクトバックログアイテムの必要性について、スクラムチームに理解してもらうこと。
c)複雑な環境においても経験的なプロダクト計画の策定を支援すること。
必要に応じてステークホルダーとのコラボレーション（密に連携する）を促進すること。
(4)スクラムマスターは、以下のようにさまざまな形で組織（プロジェクトの実施主体）を支援すること。
a)組織（プロジェクトの実施主体）へのスクラムの導入を指導・トレーニング・コーチすること。
b)組織（プロジェクトの実施主体）においてスクラムの実施方法を計画・助言すること。
c)複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらうこと。
d)ステークホルダーとスクラムチームの間の障壁を取り除くこと。
(5)スクラムマスターは、スクラムチームのパフォーマンスが最大化するよう、各開発者と話し合い、必要ならば、ステークホルダーと調整し、開発者の調達や交代を要請すること。

6.開発者は各スプリントにおいて、利用可能なインクリメントを作成するために必要な作業をすべてこなすことを確約（コミットメント、達成するために全力を尽くす）すること。
(1)開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。ただし、開発者は常に次の結果に責任をもつこと。
a)スプリントの計画（スプリントバックログ）を作成すること。
b)完成の定義を忠実に守ることにより品質を作り込むこと。
c)スプリントゴールに向けて毎日計画を適応させること。
d)専門家としてお互いに責任をもつこと。
(2)必要な専門知識（事業価値理解、リスク、コンプライアンス等）やソフトスキル（UIデザイン、要件定義、方式設計、等）、技術（ネットワーク、セキュリティ、プロダクト、クラウド等）が揃うよう社内外から開発者を選任すること。
(3)会計専門家等の専門家の関与も必要に応じて予め検討しておくこと。
7.プロダクトオーナーはスクラムチームを編成すること。
(1)スクラムチームは、スクラムマスター1 人、プロダクトオーナー1 人、複数人の開発者で構成されること（複数のスクラムチームに関してはNo.7参照）。スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている（Ⅱ.ITマネジメントのNo.17の(3)を参照）こと。
(2)十分なスクラム経験がないスクラムチームの場合、様々なプラクティスを習得させ自己組織化（コミットメントを達成するためにチームが自己管理をすること）したチームへ成⾧させるため、コーチによるサポートを受けること。
(3)一度にひとつの目的（プロダクトゴール）に集中している専門家が集まった単位であるスクラムチーム内にはサブチームや階層は存在しないことからチームとしての決定はメンバー全員の合意を得ること。
(4)スクラムチームは自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定すること。
(5)スクラムチームは、敏捷性を維持するための十分な小ささと、スプリント内で重要な作業を完了するための十分な大きさがあり、通常は 10 人以下であること。
(6)スクラムチームは、ステークホルダー（Ⅱ.ITマネジメントのNo.3を参照）とのコラボレーション（密に連携する）、プロダクトに関して必要となり得るすべての活動（研究、実験、開発、検証、運用、保守など）することを合意すること。
(7)プロダクトオーナーは編成したスクラムチームについて、ステークホルダーの合意（関係者から異論がないことを確認する）を得て、記録（改ざん防止、日付と関係者氏名の記載は必須）すること。
8.スクラムチームが大きくなりすぎる場合は、同じプロダクトに専念した、複数のまとまりのあるスクラムチームに再編成すること。
(1)複数のスクラムチームは同じプロダクトゴール、プロダクトバックログ、 およびプロダクトオーナーを共有すること。
(2)複数スクラムチームをコンロトールするための体制を構築すること。
（参考）以下a)~c)のような少人数(10人以下）のチームを複数作り、各チームが連携する体制であることが望ましい。
a)ステアリングコミッティ
・構成員:副社⾧または取締役レベルのマネージャー、システムレベルのQA担当者、プロダクトオーナー、ビジネスオーナー(各ステークホルダー）、各スクラムマスター等
・目的:定期的に(毎週）開催する。システム全体のリリースと進捗の把握、スコープの調整、各チームのミッションの達成度やチーム内状況の把握、各ステークホルダーがすべきリリースの準備に必要な情報の提供、リファインメントに伴うステークホルダー間の調整をする。
b)スクラムオブスクラム
・構成員:各スクラムマスター
・目的:毎日開催する。チームごとのデイリースクラム後にデイリースクラムの形式で行う。自チームの昨日の進捗結果と今日の予定、チーム間の影響の調整(依存関係や阻害要因など）、トピックに対する討議の場であり、各種調整を行うなど
c)スクラムチーム（Ⅱ.ITマネジメントのNo.7の(1)を参照）
9.プロダクトバックログは、ビジネスや開発状況に応じた優先順位の高い順番に並べられた、プロダクトの実現に必要なもの(具体策(2)を参照）の一覧となっていること。
(1)プロダクトバックログは、スクラムチームが行う作業の唯一の情報源であること。
(2)プロダクトの実現に必要なものとは、(a)ユーザー要求やシステム要求、(b)アクションアイテム(機能実現に伴う必要な作業）例:ステークホルダーとの調整、法令、社内手続き等(c)その他 例:環境整備(ツールインストール、ビルド環境構築）、リ
リース作業等）であること。
(3)1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニング実施時に選択ができる準備ができていること。
(4)スクラムチームは、リファインメント（Ⅲ.開発フェーズ(反復開発） No.7を参照）の活動を通じ、バックログ項目のレビューと改訂をすること。
(5)開発者は、その作業規模の評価に責任を持つこと。ユーザー価値とビジネスニーズ及び開発チーム能力との総合判断で、開発者は各スプリントで必要なユーザーストーリーを選択し実現し、プロダクトオーナーはその選択を支援すること。
(6)ユーザーストーリーは(a)役割、(b)機能、(c)ビジネス価値、(D）非機能要件や品質等の４つを次のように記述すること。
（参考）「役割(a)として、私は(c)のために(b)ができる、それには(D）が必要である。」 （詳細はⅢ.開発フェーズ（反復開発）のNo.1を参照すること）
10.プロダクトゴールは、スクラムチームの計画のターゲットであり、プロダクトの状態を示すものであること。
(1)プロダクトゴールはプロダクトバックログの中に含まれていること。また、プロダクトバックログの残りの部分（プロダクト開発要件以外）は、プロダクトゴールを達成する「何か（What）」を定義するもの（環境構築やリリース作業、宿題事項、課題、改善等）であること。
(2)プロダクトとは、価値を提供する手段であるために、明確なゴール、ステークホルダー、明確に定義されたユーザーや顧客を持っていること。
（参考）プロダクトにはシステムやアプリケーション以外の抽象的なもの、例えばガイドラインやマニュアルなど発行物等の場合もある(3)プロダクトゴールはスクラムチームの⾧期的な目標であり、スクラムチームは、次の目標に移る前にひとつの目標を達成または中断すること。
11.スプリントバックログは、スプリントゴール、当該スプリント向けに選択されたいくつかのプロダクトバックログアイテム、およびインクリメントを提供するための実行可能な計画で構成すること。
(1)スプリントバックログは、開発者による、開発者のための計画であること。
(2)スプリントバックログは、デイリースクラムで進捗を点検できる程度の詳細さ（Ⅲ.開発フェーズ(反復開発） No.3 (6)を参照）があること。
(3)スプリントバックログは一つのスプリントで開発対象として選ばれたユーザーストーリーを開発・テスト・実装する為に必要なタスクから成ること。
12.スプリントの唯一の目的であるスプリントゴールは、スプリントプランニングで作成し、スプリントバックログへ追加すること。
(1)確約したスプリントゴールを達成するために、開発者が必要とする作業に柔軟性がある（Ⅲ.開発フェーズ(反復開発）No.3イテレーション/スプリントによる開発(1)、(4)、(6)を参照）こと。
(2)スプリントゴールは一貫性と集中を生み出し、個別に動くより協力して作業するようをスクラムチームを促す内容となっていること。
（参考）スプリントゴールとは、一文でスプリントの成果を表したもの。例示として、「顧客がクレジットカードをすぐに使えるようにする」といったものがあげられる。
(3)開発者がスプリント作業するときに、スプリントゴールを念頭に置くようプロダクトオーナーが周知すること（Ⅲ.開発フェーズ(反復開発）No.2. イテレーション/スプリントプランニング(計画)(2)）。
(4)進捗状況に問題を認識したときは、スプリントゴールに影響を与えることがないように、プロダクトオーナーと開発者は交渉してスプリントバックログのスコープを調整すること。
13.インクリメント（プロダクトの増分）は、プロダクトゴールに向けた具体的なマイルストーンであり、すべてのインクリメントに追加されていること。
(1)価値（すべてのインクリメントが連携して機能する状態）を提供するために、インクリメントは利用可能であること。
(2)各インクリメントはそれ以前のすべてのインクリメントに追加され、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証（Ⅲ.開発フェーズ(反復開発）No.5 CI/CD（継続的インテグレーション/継続的デリバリー）(1)を参照）すること。
(3)1回のスプリントで複数のインクリメントが作成可能であることが望ましい。
(4)前回スプリントからの差分であり、スプリントで開発した動作するプロダクトをスプリントレビューで提示することによってこれまでのスプリントでの成果をレビューすること。ただし、スプリント終了前にインクリメントをステークホルダーに配信する場合は、スプリント
終了前にリリースすることをスプリント計画において事前に合意をとること(5)完成の定義（Ⅱ.ITマネジメントのNo.14を参照）を満たさない限り、スプリントの作業結果をインクリメントの一部としないこと。
14.完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述であること。
(1)選択したプロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生すること。
(2)完成の定義はプロセス品質（ツールによる評価とテストによる評価 参考「リグレッションテスト率100%」）とプロダクト品質（成果物の評価 例:「設計書への指摘修正率100%」）、スプリントの実施状況から成ること。
(3)完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となるよう、透明性（開発者以外の人が評価できる基準により、品質の適切性を客観的に評価できる）があること。
(4)プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない、ましてやスプリントレビューでプロダクトを提示することもできない。あとで検討できるように完了の定義を満たさないプロダクトバックログアイテムをプロダクトバックロ
グに戻しておくこと。
(5)インクリメントの完成の定義が組織（プロジェクトの実施主体）の標準の一部（各スクラムで共通化する指標 例:自動化ツールで常の計測可能な指標）となっている場合、すべてのスクラムチームは最低限それに従う必要があること。一方、組織（プロジェクトの実施主体）の標準になっていない場合（各スクラムチーム個別の指標 例:プロダクト固有の指標）はプロダクトに適した完成の定義を作成する必要があること。
(6)開発者は完成の定義に準拠すること。また、プロダクトに関わるスクラムチームが複数ある場合、共通する完成の定義を作成して、それに準拠すること。
15.品質保証部門（規定類をとりまとめる部門）は、スクラムの手法を踏まえた開発規程・ガイドラインを整備して周知の上、開発部門で運用されていること。

2／5

ISACA東京支部調査研究委員会
システム監査手法研究会 アジャイルDevOps分科会
2022年3月

アジャイル開発チェックリスト Ver1.0※文末が「～すること」は必須確認が必要な具体策。但し開発案件に該当しない等、適用しない旨整理することで対象外とすることも可。文末が「～望ましい」は必要に応じて適用。参考情報については、（参考）を文頭に記載。

章立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）(1)スクラムに関する開発標準を定めること。社内に規定類をとりまとめる部門がない、あるいは既存の規定類がない場合は、次に示す方法を参考にして標準の代替とし、スクラムチームで合意すること。
a)委託先のベンダーが持つ標準を利用すること。
b)社外の組織（IPA、アジャイルプロセス協議会、エンタープライズアジャイル勉強会、PMI日本支部など）が提供する資料やガイドライン等、あるいは本システム管理基準を参考にすること。
c)標準は以下の内容について定めること。
ｰプロセス（リリース計画ミーティング、スプリント計画ミーティング、スプリント、デイリースクラム、スプリントレビュー、レトロスペクティブ等）
ｰ役割（プロダクトオーナー、スクラムマスター、開発者、コーチ、各ステークホルダー）ｰプラクティス（テスト自動化、リファクタリング、継続的インテグレーション等）(2)ドキュメント化すべき仕様書（例:基本仕様書、アーキテクチャ設計書、運用マニュアル）を明確にすること。ただし、ドキュメントはプロダクトバックログの拡張として位置づけること。
(3)標準的な規約（コーディング規約、仕様書の形式）を整備すること。
(4)プロダクトバックログの構成（優先順位、プロダクト開発要件（ユーザーストーリー）または プロダクト開発要件以外、見積り、スプリント（予定、実績））を定義すること。
(5)完成の定義（プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述。例:スプリントレビューでの指摘修正率が100%であること インクリメントはユーザーが利用可能であり、スプリントレビューの対象となるスプリントの成果物）を決めること。
(6)現時点でもっとも役に立つツール（開発支援ツールやコミュニケーションツール、CIツール、構成管理ツール等）を最大限に開発者が活用できるよう、組織内のアジャイル開発やツール類の有識者がツール類に関する情報をウォッチし、評価・試用して、その結果を組織（プロジェクトの実施主体）内に共有すること。
(7)(6)のツールを整備した標準的な環境を構築し、各スクラムチームに展開すること。
(8)スクラムの手法を踏まえた開発規定・ガイドラインは、スクラムチームにプロジェクト開始前に周知されていることをプロダクトオーナーは確認すること。

16.プロダクトオーナーは目的（ビジネス要求や利用者のニーズ）、プロダクトビジョン（あるべき姿）、リソースが見える形で関係者と共有すること。
(1)プロダクトオーナーは目的（ゴール）、プロダクトビジョン、リソースを見える化（本管理策では「インセプションデッキ」と呼ぶ）し、社内のステークホルダー（参考）例:ユーザー部門、内部監査部門、リスク管理部門の各責任者）の承認を得ていること。
(2)スクラムチームはインセプションデッキを共有することで、ベクトルを同じ向きにすること。
（参考）インセプションデッキとは、プロジェクトの共通理解（達成したい目標や目的、プロダクトの特徴、プロダクトの魅力、スコープ外とするもの、プロジェクトに関係する人/情報源、利用する技術やアーキテクチャの図示化、リスク、期間、トレードオフする
点、費用やチームメンバー等のリソース）を10の質問により明確にし、ステークホルダーと共有するためのツールである。（アジャイルサムライを参照）(3)プロダクトオーナーは、組織（ステークホルダーが所属する）の状況が大きく変化した場合、インセプションデッキを見直し、ステークホルダーから再度承認を得ること。
17.プロダクトオーナーはプロダクトバックログのドラフト版（優先順位、ユーザーストーリー、見積り、スプリント（予定、実績）で構成される）をリリース計画ミーティングまでに作成（ITマネジメントのNo.15の(4)を参照）すること。
(1)プロダクトオーナーは、プロダクトバックログの内容（ITマネジメントのNo.9の(4)を参照）・可用性（スクラムチーム内の誰でも編集可能な状態である等）・並び順（ユーザーストーリｰの優先順位付け）に責任を持つこと。
(2)プロダクトオーナーは、スクラムチームと一緒にインセプションデッキ（ITマネジメントのNo.16の(2)を参照）を基にプロダクトに必要な事柄のすべて（ITマネジメントのNo.15の(4)を参照）をプロダクトバックログに組み込むこと。
(3)プロダクトオーナーは、ビジネス要求に合わせて、プロダクトオーナーが許可した者がプロダクトバックログを常に編集（項目追加や修正、詳細の追加、見積り、並び替え）し最新化すること。
(4)スクラムマスターは、以下の点を考慮しスプリントレビューの回数（スプリントの⾧さ）をスプリント開始前に決め、プロダクトオーナーと共にリリース計画案を検討すること。
a)プロジェクト期間b)ステークホルダー（スクラムの経験や理解、スクラムチームへの協力、システム開発への理解度、開発システムのスコープへの理解、ステークホルダー間のコミュニケーション、プロダクトオーナーとの関係性、ビジネス環境の変化などの各程度）
c)スクラムチームのリスク許容度（コミュニケーションコスト、開発作業への割り込みなどの各程度）
d)開発者（スキル、技術、スクラムの経験などの各程度）(5)プロダクトバックログドラフト版に従い、リリース計画の立案、リリース計画ミーティングの日程やテーマを決めること。
18.スクラムチームとステークホルダーはリリース計画ミーティングを開催しリリース計画、プロダクトバックログドラフト版、完成の定義、受入条件について合意を得ること。
(1)開発者はベロシティ（スクラムチームのスプリント当たりの開発量、ベロシティ算出方法例を以下に示す）を算出する方法をリリース計画ミーティング前に決定すること。
（参考）以下、ベロシティ算出方法の例a)（同じ開発者メンバー同士で開発している場合）直近のいくつかのスプリントを基に算出するか、過去のスクラムチームの実績値より算出すること。
b)（一部の開発者メンバーが過去と異なることにより）過去の実績値が使えない場合、実際に1回のスプリントを実施してみて、いくつかのプロダクトバックログドラフト版の項目を実現し、参考数値を算出すること。
c)（例えば「開発環境準備の遅延」や「一部メンバーの参画の遅延」により）実際にスプリントを実施できない場合、予測した1スプリント当たりの各メンバーの作業時間から1スプリントでの総作業時間を決め、ユーザーストーリーをタスク分割し、タスクごとの作業時間を見積り、１スプリントで消化できるタスク規模を予想すること。
(2)複数のリリースが計画される場合、プロダクトオーナーはリリースロードマップ(ビジネス上の優先順位に応じた機能の提供時期を明示したもの）を策定すること。
(3)プロダクトオーナーは、開発者とインセプションデッキ（ITマネジメントのNo.16の(2)を参照）を基に話し合い、ステークホルダーからの期待を明確にし、スクラムチーム内で共有すること。
(4)プロダクトオーナー、ステークホルダー、スクラムマスターと開発者他、ユーザーもリリース計画ミーティングへの参加が推奨されること。
(5)スクラムマスターと開発者はプロダクトバックログドラフト版のユーザーストーリーを分析し、ゴールイメージ、リスク、品質特性、ビジネス制約、規模を見積ることで、概要を理解すること。
(6)要求に沿った開発を実現するために、スクラム開発への理解、スクラムチームへの協力、スプリントレビューの重要性とリリースまでのスプリントレビューの回数について、プロダクトオーナーからステークホルダーへ説明し、ステークホルダーからの合意（ステークホルダーの全責任者から異論がないことを必ず確認）を得ること。合意を得たスプリントレビューの回数に基づき、スプリントの⾧さを決定すること。
(7)スクラムマスターと開発者はユーザーストーリーの開発規模とベロシティから、リリースまでのスプリントにユーザーストーリーが収まるかを確認すること。収まらない場合は、プロダクトオーナーとスコープを調整すること。
(8)プロダクトオーナー、スクラムマスターと開発者はリリース計画をレビューすること。
(9)リリース計画は以下の内容を含んでいることが望ましい。
-リリースのテーマ（ユーザー要望に焦点を合わせた提供サービス（システム）の内容）-ユーザーストーリーの優先順位リスト-プロダクトバックログドラフト版の見積り-プロダクトバックログドラフト版のグル-ピング-スプリントの割り当て（開始日と終了日）-完成の定義-受入条件（ステークホルダーの受入完了基準）の定義-アクションアイテム-計画の｢見える化」方法・手段-ドキュメント化の方針-ツール（組織（プロジェクトの実施主体）が管理するCIツール等を紹介、共有）(10)リリース計画ミーティングの結果を反映するようプロダクトオーナーがプロダクトバックログを更新すること。
2.構築（build）
1.プロダクトオーナーとスクラムマスター、開発者は反復開発に必要な準備をすること。
(1)プロダクトオーナーとスクラムマスター、開発者はスプリント実行にあたり、環境(集まる場所とリモート環境、ツールを含む開発環境全体）を整備すること。
(2)プロダクトオーナーとスクラムマスターは、最初のスプリントバックログのドラフト版を作成すること。
(3)スクラムチームのスキルが十分揃っているか、開発者間で話し合い、リリースのテーマが実現できるか検証すること。必要ならば実現化に不要な開発者を外し、必要な開発者を探すことを開発者の合意を得ること。決定した内容をスクラムマスターへ報
告すること。
（参考）合意を得るとは、スクラムメンバー全員から異論がないことを確認する仕組み（期日までに異論がないことを確認するなど）を整備して運用すること指す。
3.実行（Run）
2.｢Ⅲ.開発フェーズ（反復開発）」の管理策を参照。
4.モニター（Monitor）
1.プロダクトオーナーは経営陣へスクラムチームの状況（進捗、問題、リスク等）について報告すること。
(1)スクラムチームの進捗や成果、スプリントで検知した問題やリスクを吸い上げる仕組みが整備され、運用されているか確認すること。
(2)スプリントで検知した問題やリスクは、優先順位付けされたうえで、重要な問題やリスクは適宜経営陣へ報告されていることを確認すること。
(3)経営陣へ報告したスプリントで発生した重要な問題やリスクについて、経営陣からフィードバックされていることを確認すること。
2.スクラムチームは監査の受入態勢が整備され、運用されていること。
(1)監査計画立案時に監査対象となるスクラムプロジェクトと事前に監査時期を合意すること。
(2)スクラムチームは、リリース計画、スプリント計画時にどのタイミングで監査が入っても問題が生じないよう、予め想定しておくこと。
(3)監査で要求する証跡が、成果物としてあることを確認すること。
(4)反復開発開始後監査対象となった場合、スプリント計画等適切な時期にそれらを周知し、次回スプリント計画時にどのタイミングで監査が入っても問題が生じないよう、予め想定しておくこと。
（参考）監査で確認すべき観点の例は以下に示す。
･プロダクトゴール設定プロセスの適切性･スプリントゴール設定プロセスの適切性･スクラムチーム人選プロセスの適切性･完成の定義設定プロセスの適切性参考）「適切性」があるとは、決定事項を承認すべき人が承認している等設定の手続きを証跡（例）チャットのテキストログ等設定の作業過程を可視化したデータ）で確認できることである。
･直近のスプリント進捗状況･各スクラムメンバーの役割とその活動状況
・スプリントレビューによる品質評価
3.複数のスクラムチームから成るプロジェクトの場合、各スクラムチームが共通のプロダクトゴールを達成できるよう連携できる仕組みで運営されていること。

3／5

ISACA東京支部調査研究委員会
システム監査手法研究会 アジャイルDevOps分科会
2022年3月

アジャイル開発チェックリスト Ver1.0※文末が「～すること」は必須確認が必要な具体策。但し開発案件に該当しない等、適用しない旨整理することで対象外とすることも可。文末が「～望ましい」は必要に応じて適用。参考情報については、（参考）を文頭に記載。

章立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）(1)以下の通りスクラムチーム間のリリース計画ミーティングを開催し、各チームの責任範囲を明確にし合意すること。
a)単一チームにおける進行と同じように進め、プロジェクトのリリース計画を決めること。
b)ビジョンを共有し、リリース日程、スプリント日程、マイルストーンを決めること。
c)どのスクラムチームがどのユーザーストーリーに責任を持つのかを決めること。
(2)プロジェクトのリリース計画に従い各スクラムチームは、各スプリントを以下の通り計画し実行すること。
a)リリース日は固定的で変わることなく、すべてのチームメンバーに共有されていること。
b)システムリリースに向けたマイルストーンを、全スクラムチームが遵守すること。
c)各スクラムチームのスプリントは同期しており、同時期にインクリメントをデプロイすること。
d）各スクラムチーム間でシステムレベルでCI(継続的インテグレーション）を適用すること。
(3)各スクラムチームのスクラムマスターは、チーム間に齟齬が生じないよう以下の通り調整をすること。
a)各スクラムチームのインクリメントとシステムのスコープを常に調整すること。
(4)レトロスペクティブは各スクラムチームだけでなく、プロジェクト全体でのレトロスペクティブをすること。

章立て

項立て

管理策

Ⅲ.開発フェーズ(反復開発)

具体策（管理策の補足説明、又は任意選択肢）※本章ではアジャイル開発の中で最も代表的な｢スクラム｣を中心に記述する

1. ユーザーストーリー
1.スクラムチームは、実現すべき機能を｢プロダクトバックログ(３Ⅱ.ITマネジメント<1.計画(Plan)(2)参照)｣として文書化する前段階として「ユーザーストーリー(本項(1)参照)」を作成すること(1)「ユーザーストーリー」は、以下4要素から成るユーザーの要望(｢エピック｣)を基に作成すること① 誰が、どのような役割で② 何をしたい③ なぜならどういった価値を生むから④ そのためには、何を必要とする(2)「ユーザーストーリー」は上記｢エピック」を以下「INVEST」の特性を持つ、具体的な動作や操作を参考に分解し作成すること① Independent:独立し、他のユーザーストーリーと重複しない② Negotiable:要求の実現手段を顧客と開発者が交渉できる③ Valuable:ユーザーにとって価値がある④ Estimatable:作業工数見積りが可能である⑤ Small:見積もりや計算がしやすい小ささに分けられる⑥ Testable:結果をテストで確認できる※「図解でわかるアジャイル・プロジェクトマネジメント」 p.160など（参考）「ユーザーストーリー」を基に、プロダクトオーナーが開発の優先順位を付けた「プロダクトバックログ」を作成することになる(｢2. イテレーション/スプリントプランニング(計画)」⇒次項参照 )(3)「ユーザーストーリー」から以下を分析し、イテレーション/スプリントにおいてそれぞれの要素を考慮して｢インクリメント｣(一回のイテレーション/スプリントで開発した動作するアプリケーション。前回イテレーション/スプリントからの差分)を開発すること① 機能要件:利用者(ユーザー)が実現したいこと② 品質特性:ビジネス価値につながる非機能要件③ ビジネス制約:ビジネス価値の足枷になるもの④ 技術制約:利用者が実現したいことの足枷になるもの
2. イテレーション/スプリントプランニング(計画)
1.スクラムチームは、イテレーション/スプリントを開始する前に当該スプリントで実行する作業の計画を立て｢スプリントバックログ」を作成し、併せて｢完成(Done)の基準｣も定義すること(1)｢イテレーション/スプリント計画｣は、スクラムチーム全体の共同作業によって作成されること。必要な場合、チーム外の人をアドバイザーとしてイテレーション/スプリント計画に招待すること(2)「イテレーション/スプリント計画」にかける時間は、1回のイテレーション/スプリントのサイクルが1か月の場合、最大で 8時間が望ましい。イテレーション/スプリントサイクルが短ければ、それに応じてプランニングにかける時間も短くすること。なお、「タイムボック
ス(固定された時間)」の延⾧は原則不可、また何らかの理由で１つのイテレーション/スプリントを中止する権限はプロダクトオーナーにある(3)プロダクトオーナーは、イテレーション/スプリントの開始にあたり当該スプリントで実現する目標をチームメンバーやステークホルダーに提示すること。この時、単に文書を交付するだけではなく繰返し伝え、実践することで共通認識化されることが望ましい※本項以降、「合意する」は、「関係者から明示的な反対表明がない状態」を指す。例えば何かを決める際に、ある提案に対しスクラムチームのメンバーから異論が出ない状態を指す(4)スクラムチームは、プロダクトオーナーが提示した目標をもとに「なぜ(Why)実現する価値があるのか」、および「何を(What)」具体的に実現するか」を明確にし、合意すること(5)開発者は、「完成(Done)の基準」を定義しスクラムチーム内で合意すること。また、あらかじめ開発規程等、組織内に該当するルールが既に定義されている場合はそれに準拠すること。該当ルールが組織内に存在しない場合は、開発チームが｢完成(Done)の基準｣を定義しスクラムチーム内で合意すること。例えば、「スプリントバックログがすべて実装されていること」など(6)開発者は、プロダクトオーナーから提示されたバックログアイテムをもとに当該イテレーション/スプリントで実現する機能を選択し、「スプリントバックログ」を作成のうえ、完成の基準を満たす「インクリメント(動作するアプリケーション)」を作成するための作業を「イテレーション/スプリント計画」とすること(7)どのように作業を進めるか(How)は、開発者だけの裁量とすること。また、当該イテレーション/スプリントで手掛けるバックログアイテムを選択する作業は、開発者が過去の自分たちのパフォーマンス実績や現在の能力(キャパシティ)を勘案した開発速度(ベロシティ＝予め定められたスプリント期間内で達成できる作業量)をもとに、1回のイテレーション/スプリント内で完了可能なものとすること。イテレーション/スプリントを繰り返す中で経験を積み、見積もりの精度を上げていくことが望ましい(8)スクラムチームは、ユーザーストーリーを基に各イテレーション/スプリントにおいて何が満たされたら「受入れ可能」とするかという「受入基準」を設定すること。例えば、「〇〇の機能が実装されていること」など。ただし最終的に受入可否を判断するのはプロ
ダクトオーナーである(9)イテレーション/スプリント計画の適切性を後日監査可能とするため、何らかの記録を残すこと。これらの｢記録(証跡)」は文書に限らず、写真、録画やツールによる電子記録等も必要に応じて可とする等、イテレーション/スプリント開始前、あるいはプロ
ジェクト開始前にステークホルダーや組織で合意することが望ましい(10)本邦ではアジャイル開発も業務委託で行うケースが多いことから、「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元社員とのコミュニケーションは当該実施責任者(業務遂行責任者)を通して行わせること。このようにして、委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと
3. イテレーション/スプリントによる開発
1.イテレーション/スプリントにより、短いサイクルで「インクリメント(1.ユーザーストーリー(3)参照)」をユーザーに届けることを繰り返し、最終的にユーザーの要望を満たすプロダクトを完成すること(1)当該イテレーション/スプリントで実現する目標を達成するために必要なすべての作業は、１つのイテレーション/スプリント内で完了するよう計画すること。スクラムの場合、各スプリント中は開発者の自律性に委ねユーザーとの接触は基本的にないことが前提となるが、XP(Extreme Programming)ではユーザー(スクラムのプロダクトオーナーに相当する役割の者)がイテレーション中も開発者と協働するなどのバリエーションがあることについて、留意すること(2)イテレーション/スプリントによって、プロダクトゴールに対する進捗の点検と適応・調整が一定期間(1週間～1か月)ごとに確実になり、予測可能性を高めること。イテレーション/スプリントの期間を短くすることでより多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることが望ましい(3)各回のイテレーション/スプリントでは、以下に留意すること① イテレーション/スプリントゴールの達成を危険にさらす変更はしないこと② インクリメントの品質を低下させないこと(後述のテスト自動化などにより、早期にバグを取り去ること)③ イテレーション/スプリント進捗に伴い、プロダクトバックログを必要に応じて「リファインメント(7.リファインメント参照)」すること(4)「イテレーション/スプリントバックログ」の内容の変更は日次ミーティング(「デイリースクラム」)で共有を行うこと。プロダクトオーナーや他のステークホルダーが勝手にタスクを追加・変更はしない仕組み、又は変更結果が適宜確認できる仕組みとすること(5)「バーンダウン/バーンアップチャート(実績値と計画の乖離を一目で把握できる図表)」、「累積フロー(作業項目の各種ステータスを表示する図表、ボトルネックの特定に役立つ)」などを利用し、スプリントの進捗をスクラムチームのみならず、ステークホル
ダーからも「見える化」すること(6)タスクは1人の開発者が1日で完了できるサイズ以下にしておくこと。また、開発のために必要なタスクの粒度は「1時間単位」まで分解し、属人性を薄めて品質向上を目指すことが望ましい(7)開発者は、シンプルなコードによるプログラミング(「リファクタリング(繰り返しや冗⾧なコードを削除し、理解しやすくすること)」)を行うことで、将来的なコードの修正を容易にすることが望ましい(参考) ①コードを変更してもシステムの機能に影響が出ないことをテストによって確認する（参考) ②コードのシンプル化は、⾧過ぎるメソッド、巨大なクラス、多すぎる引数などから、問題と感じる箇所に対して行う(8)当該スプリントゴールが実態にそぐわなくなった場合、バックログをリファインメント(「7.リファインメント」参照)し次のスプリントに備えること(9)スクラムチームに委託先社員がいる場合は「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元とのコミュニケ－ションの窓口機能を担わせること。委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと
4. イテレーション/スプリント中のコミュニケーション
1.スクラムチームは、チーム内で緊密なコミュニケーションを行うための仕組みを構築すること。
(1)スクラムチームは、日次ミーティング(「デイリースクラム」)などにより毎日進捗状況をメンバー全員で把握すること(2)デイリースクラムなどの定例ミーティングは短いタイムボックス(15分が目安)で済むように共有する情報を絞り、スプリント期間中は原則毎日、同じ時間・場所(オンラインも含む)で開催すること(3)開発者は、タイムボックス内で当該スプリントのタスクが消化されるまで上記を徹底すること(4)スプリントバックログへのタスクの追加や削除、見積りとその更新は開発者の責任で行い内部で合意すること。なお、内容の変更は定例ミーティングなどの機会を利用してスクラムチーム内で共有すること(5)進捗状況に問題が認識された場合、スクラムチームは定例ミーティングとは別に会議体を設定(「ポストモーティム(緊急会議)」)し、改善策を検討する他、スプリントバックログのスコープを調整すること。そのような問題が起こる前に、開発者はデイリース
クラム以外にもより詳細な議論をするため頻繁に話し合うことが望ましい(6)スクラムマスターは、課題が簡単に解決できないと判断した場合、ステアリングコミッティーなど上位決定機関に報告し、判断を仰ぐこと(7)当該スプリントで実現しなかった機能は「スプリントレビューミーティング(「6.スプリントレビュー」参照)」でステークホルダーと協議し、必要であば次回以降のスプリントで実現させるか等を検討すること(8)デイリースクラムの可監査性を確保するため、作業進捗や問題の所在を後で検証できるよう、何らかの記録(文書、画像、音声など)を残しておくこと

4／5

ISACA東京支部調査研究委員会
システム監査手法研究会 アジャイルDevOps分科会
2022年3月

アジャイル開発チェックリスト Ver1.0※文末が「～すること」は必須確認が必要な具体策。但し開発案件に該当しない等、適用しない旨整理することで対象外とすることも可。文末が「～望ましい」は必要に応じて適用。参考情報については、（参考）を文頭に記載。

章立て

項立て

管理策

具体策（管理策の補足説明、又は任意選択肢）(9)スクラムチームに委託先社員がいる場合は「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元とのコミュニケ－ションの窓口機能を担わせること。委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと

5. CI/CD(継続的インテグレーション/継続的デリバリー)
1.スクラムチームは、自動化ツール導入などによりインクリメントの品質を保ち、ソースコードファイルを継続的に統合(インテグレーション)からデリバリー/デプロイまでできる枠組みを作ること(1)継続的インテグレーション/継続的デリバリーを効率的に行うため、自動化ツールの導入を検討すること(参考）① 自動化ツールは、以下のa)～c)まで自動的に行う機能を持つことが望ましいa) 開発者がコードをリボジトリ(ソースコードやファイルなどを一元的に管理する格納場所)に反映する毎にソースコードを逐次統合(インテグレーション)するb) 複数のソースコードファイルを実行可能形式にまとめる(ビルド)c) テストし、アプリケーションを動かす環境に配置する(デプロイ)(参考）② 複数の開発者が並行してコードを作成するため、テストするプログラムはその時点の最新バージョンである必要がある。この点からも自動化ツールを導入することが望ましい(参考）③ テスト自動化ツール導入により、プログラムを少しでも修正しリポジトリに入れたら自動的にテストが始まるように設定しておくことが望ましい(参考）④ ただし、結合テスト以降の自動化は難しくなることに留意すること(2)継続インテグレーションで失敗したテストが存在する場合は、すぐに対処し常にすべてのテストが成功する状態を保つこと。継続的にインテグレーション、ビルド、テストを実施することで問題を早期に発見できる仕組みとなっていることが望ましい(3)結合テスト(単体で動作するようになったソフトウェアのコンポーネントを組み合わせ、実際に動作する状態に近くして挙動を確認するテスト)以降の自動化のハードルは高くなるが、開発からリリースまで自動化するデプロイメントパイプラインを作り、不良を後続のステージに流さない工夫をすることが望ましい。「ユーザビリティテスト」、「ショーケース」(ユーザーに対するデモ)、「探索的テスト」(予めテストケースを設定しないテスト)など、ビジネス面のテストは自動化できないものがある点に留意すること
6. イテレーション/スプリントレビュー
1.スクラムチームは、毎回イテレーション/スプリントの終了時に｢イテレーション/スプリントレビューミーティング｣を開催し、プロダクトゴールに対する進捗について話し合うこと(1)イテレーション/スプリントの⾧さに応じてレビューのタイムボックスを決めること。なお、イテレーション/スプリント期間が短ければレビューの時間も短くすること。
（参考）例えば、1スプリントが1か月の場合は4時間、2週間の場合は2時間程度と予め決めておくことが望ましい(2)スクラムチームとステークホルダーは、スプリントで何が達成され、何が変化したかについて、確認すること。この情報に基づいて、参加者は次にやるべきことに協力して取組むこと(3)スクラムチームはスプリントレビューでステークホルダーに対し「プロダクトインクリメント」(当該イテレーション/スプリントで開発した動作するアプリケーション、前回イテレーション/スプリントからの差分)のデモを行い、ステークホルダーからインクリメントに対するフィードバックを受けること。そのためスクラムチームは当該スプリントのタイムボックス内で必要なテストを済ませておくこと(4)レビューミーティングで参加者は以下を行うこと① 出来上がったインクリメントがユーザーストーリーに沿っていることの点検② インクリメントが当該イテレーション/スプリントのバックログをすべて消化していることの点検③ インクリメントのデモを確認後、当該イテレーション/スプリント終了可否に関する検討(5)プロダクトオーナーは、イテレーション/スプリントレビューの議論と結果を踏まえ、インクリメントの受入れ可否について最終決定し、ステークホルダーが合意した記録を残すること(6)スクラムチームに委託先社員がいる場合は「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元とのコミュニケ－ションの窓口機能を担わせること。委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと
7. リファインメント
1.スクラムチームは、イテレーション/スプリントレビューの結果を踏まえ、プロダクトバックログの内容を変更、改めて優先順位付けの見直す「リファインメント」を行うこと(1)リファインメントはプロダクトオーナーが主催し、スクラムマスター、開発者との対話を通し内容をレビューすること(2)プロダクトオーナーは、プロダクトバックログに対し詳細の追加、再見積り、優先順位の並び替えや、プロダクトバックログアイテムの受入れ要件(アクセプタンスクライテリア)を洗練させ、改訂を行うこと(3)リファインメントがイテレーション/スプリントレビューを踏まえて行われたことが第三者に分かるように、新旧プロダクトバックログ比較などの記録を残すことが望ましい(4)こうしたリファインメントによってプロダクトバックログの内容の透明性を高めることが望ましい(5)スクラムチームに委託先社員がいる場合は「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元とのコミュニケ－ションの窓口機能を担わせること。委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと
8. イテレーション/スプリントレトロスペクティブ
1.スクラムチームは、イテレーション/スプリントレビュー後に別途当該スプリントを振返り次回イテレーション/スプリントにつなげる「レトロスペクティブミーティング」を開催し、品質と効果を高め開発プロセスを改善する方法を計画すること(1)レトロスペクティブ(振返り)では、当該イテレーション/スプリントで何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたか(または解決されなかったか)、どうやったら次のイテレーション/スプリントでよりうまくできるかを議論し、改善策を特定して共有し、次回イテレーション/スプリントに生かすこと(2)イテレーション/スプリントが1か月の場合、レトロスペクティブは最大3時間を目安とすることが望ましい。イテレーション/スプリントの期間が短ければ、それに応じてレトロスペクティブの時間も短くする点に留意すること(3)スクラムチームは、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のイテレーション/スプリントがどのように進んだかを点検し、記録を残すこと(4)スクラムチームは、終了したイテレーション/スプリントを振り返る議論を通して次回イテレーション/スプリントの有効性改善に役立てること。影響の大きな改善はできるだけ早く対処すべく次のスプリントバックログに追加すること(5)レトロスペクティブミーティングを以て1回のイテレーション/スプリントが終了し、間を置かず次のイテレーション/スプリントに向けた計画ミーティングを開くこと(これらを踏まえて「2. イテレーション/スプリントプランニング」に戻り、次のイテレーション/スプリントを開始する）(6)イテレーション/スプリントを繰返し、すべてのプロダクトバックログがプロダクトインクリメントの中で実装されステークホルダーに受入れられたとき、当該スクラムは終了する仕組みとすること(7)一回のイテレーション/スプリントが終了する度に、①関係者間のコミュニケーションの円滑化、②認識齟齬の防止、③進捗状況の共有、などのために必要なドキュメント類を整備すること。こうしたドキュメント類は、すべてのプロダクトバックログを実装し当該スクラムが終了するまで改訂を続けることから、バージョン管理を徹底すること。また、運用部門、セキュリティ部門、リスク管理部門、監査部門など、多くの関係者も利用することから、利用者の特性に応じ容易に理解可能な内容・表現とすること。その際、分かり易いソースコードで記述したり、画像を活用したりすることが望ましい(8)スクラムチームに委託先社員がいる場合は「偽装請負」と見做されるリスクを回避するため、委託先社員から「実施責任者(業務遂行責任者ともいう)」を選任しスクラムチームに入れ、委託元とのコミュニケ－ションの窓口機能を担わせること。委託先社員が委託元の言いなりではなく「自律性」があることを示すエビデンスを残すこと
参考文献:
1. ｢アジャイル型開発におけるプラクティス活用リファレンスガイド｣(IPA;2013年3月)
2. ｢アジャイルソフトウェア開発宣言の読みとき方｣(IPA;2018年4月)
3. ｢アジャイル開発の進め方｣(IPA;2018年4月)
4. ｢アジャイル開発向けモデル契約案について｣(IPA;2012年5月)
5. ｢スクラムガイド｣(Scrum.org and Scrum Inc.;2016年7月 & 2020年11月)
6. ｢アジャイル実践ガイド｣(PMI;2017年）
7. ｢ディシプリンド・アジャイル・デリバリｰエンタ-プライズ・アジャイル実践ガイド｣(Object Oriented SELECTION)
8. ｢アジャイル開発の本質とスケールアップ変化に強い大規模開発を成功させる14のベストプラクティス｣(IT Architects’ Archive; 2010年2月)
9. ｢SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises｣(English Edition）
10. ｢アジャイルソフトウェア開発向けUML適用ガイドラインVer1.1 ｣(UMLモデリング推進協議会; 2016年6月）
11. ｢アジャイル開発における品質保証｣(日本科学技術連盟;公表年不明）
12. ｢アジャイルサムライ｣(オーム社;2011年7月)
13. ｢アジャイル開発への道案内｣
14. ｢大規模スクラム｣
15. ｢図解で分かるアジャイル・プロジェクトマネジメント｣(SCC; 2016年6月)
16. ｢アジャイル開発外部委託モデル契約｣ (IPA; 2021年10月6日更新)
17. ｢チーム改革のスイッチ」(ManasLink; 2020年6月)
18. ｢スクラム現場ガイド」(マイナビ;2016年2月)
19. ｢情報システム監査実践マニュアル｣(NPO法人日本システム監査人協会、第3版)
20. ｢品質重視のアジャイル開発｣(日科技連;2020年9月)
21. ｢SCRUMBOOTCAMP THEBOOK」(日経印刷;2020年5月)
22. ｢アジャイル開発のプロジェクトマネジメントと品質マネジメント58のQ＆Aで学ぶ」(日科技連;2020年3月)
23. ｢エンタープライズアジャイルの可能性と実現への提言[アンチパターンとその克服事例]｣((インプレスR&D; 2019年4月)
24. ｢アジャイルソフトウェア開発マネジメント｣(富士通FSTユニット; 2020年7月)
25. ｢継続的デリバリー ～ 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化｣(ドワンゴ; 2017年7月)
26. ｢アジャイル開発の教本｣(インプレス; 2020年月)

5／5