概要 
- S社：飲食チェーン店を中心の事業
- 介護ビジネスなどへ進出してビジネスを拡大した
- これまでのシステム開発はウォーターフォール型開発 ⇒ 営業支援システムをアジャイル開発で短期間でつくりたい
アジャイル開発：イテレーションについて
要件定義以降、以下� 銑い魴�り返す。（この繰り返し１セットをイテレーションとよぶ）
繰り返す回数は６回。
�ヽ�発ＴとユーザＴは、↓
ユーザＴの要求を検討し、今回のイテレーションで開発する機能の検討と要件の確定をする
��開発Ｔは、確定した要件について↓
機能設計、製造、単体テスト、レビューを行う
��ユーザTは、確定した要件が実現されているか確認のため、↓
テストを行う
�ご浜�ＴとユーザＴは、↓
テスト結果を確認し成果物と進捗状況を確認する
�，砲發匹�(⇒ と、その前に？？？をする)
ドキュメントの作成有無について
- アジャイル開発において要件が頻繁に更新されるのでその都度ドキュメント修正は効率が悪い。
指摘事項��
計画段階で作成しておくべきドキュメントまでも作成しないことはリスクがある
- 計画段階で作成するドキュメント ＝ システム化目的、必要な要件、スコープが記載されているもの
つまり、上記が明確でないと
スコープ外の要求まで取り込んでしまい、開発内容が当初の目的やスコープから逸脱するリスクがある
指摘事項��
保守運用段階のドキュメントが不足すると障害対応へのリスクにつながる
- 運用保守段階のドキュメント ＝ システム構成などのドキュメント
これがないと
障害発生時に調査に工数がかかり、障害への迅速な対応ができないリスクにつながる
イテレーションに組み込むコントロール
- 開発ツールやコミュニケーション方法については、随時修正を加えながらすすめる
各イテレーションの最後におこなうべき指摘事項
各イテレーションの最後に見直しとして進め方を評価し次回に反映するというフェーズを追加すべき
役割分担と要件確定に関するリスク
今回の体制
- ＰＭ：システム部Ｔ氏 ⇒ プロセスオーナとして組み込む要件の優先順位をつける
- ユーザＴ ⇒ システムに組み込みたい要求を提示。確定した要件が実現されているかテストする
指摘事項
アジャイル開発では、
⇒ 営業支援システムの業務内容に詳しいものがプロセスオーナとなり、要件や優先順位をきめるべき
↓
プロセスオーナが要件の最終確定を行うのが原則である。
⇒ 営業支援システムの業務内容に詳しいものがプロセスオーナとなり、要件や優先順位をきめるべき
↓
システム部がプロセスオーナだと、業務要件やその優先順位を的確に判断し意思決定できないリスクが発生する
開発スキルに必要な技術不足へのコントロール
（１）開発開始段階でのチェックポイント
- 開発Ｔがアジャイル開発の経験メンバが少ない。
- ツールの使用にもなれていない
一般に開発に必要な技術が不足している場合のコントロールとしては
「その技術に対する教育をおこなうこと」
となる
↓
したがって、監査では
開発の開始段階で、ツールの使用方法を参加メンバに周知する場が設けられているかを監査項目としてあげておく。
（２）開発途中段階でのチェックポイント
上述のコントロールが「有効に機能しているか」を確認することが重要となる。
↓
ツールを利用して、適切な管理ができているかを確認する
↓
↓
ツールを利用して、適切な管理ができているかを確認する
↓
事前に決められたルール（ツール、コミュニケーション方法）にしたがって、
成果物が作成されているかどうかを確認する
最新コメント