【システム開発ビジネスサイド】基本所作※順次追加

共通

セッション準備

• 目的とゴールのセット

  • 目的のカテゴライズ

    • 共有 / 確認 / 議論 / 判断

• セッション終了時のラップアップ

  • 決定事項とアクション（Todo/Issue）

進捗管理

• マイルストーンと基準の明確化

• マイルストーンと基準に対するリスク

• リスクの対応方針と対応期日、スケジュール

要件定義

開発

変更管理（対応の判断）

• 要件定義・設計のどのアウトプットに対する変更か

  • 業務要件、システム要件、基本設計、詳細設計

• 変更はビジネス経営にどのようなメリットがあるか

• （システム変更の場合）本来あるべき業務運用はなにか、それを踏まえた上でなおシステム変更は必要か

  • 特殊なビジネスや、成り行きの特殊業務運用のためにシステム変更するのはRoIが見合わない。まずはあるべき業務運用を行うべき

• どのシステムに対する変更か、変更箇所はそのシステムであるべきか

  • 本来別のシステムに対する変更であるべきだが、システム制約により他のシステムへ変更要望が発生している場合、本来のシステムで変更はできないのか検討しつくす必要がある（システムごとの役割分担に立ち返る）

• それらは標準か（どのビジネス範囲で展開かのうか）固有か

  • 固有であれば、展開による投資メリットのない費用となる。その上で、変更の要否を判断

変更管理（対応のスケジュール）

• スケジュールと実績

  • 業務要件、システム要件

  • 基本設計、詳細設計

  • 開発

  • IT、UT

  • SIT

  • UAT

  • ドキュメントの更新（要件定義書、設計書）

  • 本番リリースのチケット発行期限

  • 本番リリース判定

  • 本番リリース

  • リリース後検証、クローズ

• これを毎日、2日一回のペースで業務・システム担当で確認

SIT・UAT

問題管理

• 事象はなにか

• 原因はなにか

  • どのアウトプットの問題か※

    • 企画→業務要件→システム要件→基本設計→詳細設計→開発

  • 他に同様の問題が発生しているリスクはないか

• 業務への影響はどの程度か

  • マイルストーンの基準に対する影響はなにか
    ※マイルストーンに関係ない場合、プロジェクト外の問題として管理

• どのマイルストーンまでに対応が必要か

  • スケジュールへの影響は

• 暫定対応はなにか

  • マイルストーンの基準をクリアするために必要な暫定対応

  • システム変更ではなく業務運用での回避策

• 恒久対応はなにか

  • 本来のあるべき形にするための対応

• どのようなスケジュールで実施するか

• 問題の真因はなにか

  • ※における発生原因のなぜなぜ

  • どのテストで検知すべきか、検知できていなかったのであればそれはなぜか