【システム開発ビジネスサイド】基本所作※順次追加
共通
セッション準備
目的とゴールのセット
目的のカテゴライズ
共有 / 確認 / 議論 / 判断
セッション終了時のラップアップ
決定事項とアクション（Todo/Issue）
進捗管理
マイルストーンと基準の明確化
マイルストーンと基準に対するリスク
リスクの対応方針と対応期日、スケジュール
要件定義
開発
変更管理（対応の判断）
要件定義・設計のどのアウトプットに対する変更か
業務要件、システム要件、基本設計、詳細設計
変更はビジネス経営にどのようなメリットがあるか
（システム変更の場合）本来あるべき業務運用はなにか、それを踏まえた上でなおシステム変更は必要か
特殊なビジネスや、成り行きの特殊業務運用のためにシステム変更するのはRoIが見合わない。まずはあるべき業務運用を行うべき
どのシステムに対する変更か、変更箇所はそのシステムであるべきか
本来別のシステムに対する変更であるべきだが、システム制約により他のシステムへ変更要望が発生している場合、本来のシステムで変更はできないのか検討しつくす必要がある（システムごとの役割分担に立ち返る）
それらは標準か（どのビジネス範囲で展開かのうか）固有か
固有であれば、展開による投資メリットのない費用となる。その上で、変更の要否を判断
変更管理（対応のスケジュール）
スケジュールと実績
業務要件、システム要件
基本設計、詳細設計
開発
IT、UT
SIT
UAT
ドキュメントの更新（要件定義書、設計書）
本番リリースのチケット発行期限
本番リリース判定
本番リリース
リリース後検証、クローズ
これを毎日、2日一回のペースで業務・システム担当で確認
SIT・UAT
問題管理
事象はなにか
原因はなにか
どのアウトプットの問題か※
企画→業務要件→システム要件→基本設計→詳細設計→開発
他に同様の問題が発生しているリスクはないか
業務への影響はどの程度か
マイルストーンの基準に対する影響はなにか
※マイルストーンに関係ない場合、プロジェクト外の問題として管理
どのマイルストーンまでに対応が必要か
スケジュールへの影響は
暫定対応はなにか
マイルストーンの基準をクリアするために必要な暫定対応
システム変更ではなく業務運用での回避策
恒久対応はなにか
本来のあるべき形にするための対応
どのようなスケジュールで実施するか
問題の真因はなにか
※における発生原因のなぜなぜ
どのテストで検知すべきか、検知できていなかったのであればそれはなぜか