システムリプレース時 必要作業一覧
システムリプレース時 必要作業一覧：ガイドになります。
完璧という言葉の実現は人生の短さにおいては不可能ですが、べき法則（パレートの法則等）の下では完璧に「近づく」ことは可能です。
システムリプレース時の作業チェック等の参考にしてください。
提供は晁岳メソッドプロジェクトです。
＜現行組織環境調査＞
【目的】業務における既導入システムの運用時の責任分界点を組織の役割・責任及び権限の一覧＝職務分掌規定で明確区化する。
※職務分掌規定は大企業では作成されていることが多いが、中小企業では作成されていないので、以下のドキュメントを調べることで職務分掌を推測する。
・組織図並びに業務担当の構成確認
組織の中で業務と担当の割り振りがどうなっているのかを確認。
・システム機器操作の責任部門と担当者の役割の確認
どの部門がどの機能の操作に責任を持ち、どの人が何の役割（操作だけなのか、判断も行うのか）を担うのかの確認。
※組織上の役割と実際のシステム操作の関係を見ることで業務/システム上の責任分界点の確認をする。
・システム管理者、サーバー管理者、ネットワーク管理者の確認
現行システム管理者の確認。（情シス以外であれば、所属する組織も確認）
※システムの運営を部門と担うメンバーの確認。
＜現行システム調査項目＞
【目的】リプレスに関連するシステムの外形的な影響範囲を明確化する
１）システム関連機器の機器配置、ネットワーク等の現状を確認
・本社、各拠点、各工場等の屋内/屋外のシステム機器のシステム別機器一覧（PC、サーバ、HTT、PAD、プリンタ、HAB、ルーター、モデムetc）
※全システム機器中、対象機器がどれだけあるか、どのシステムが実装されているかの確認（必ず機器に識別子をつけること）。
・機器配置図（PC、サーバ、HTT、PAD、プリンタ、HAB、ルーター、モデムetc）とネットワーク配線図、配電図（ネットワーク配線、電源にも必ず識別子をつけること）
※実際にどこで何が使用されているかを確認し、使用環境（埃の多寡、防爆要否、電磁波ノイズ量）、電気容量を確認。
２）導入システムの一覧、OS、使用言語、外部情報連携、外部接続機器連携を確認
・顧客導入システムの基幹システム、外付けシステム（通信連携サブ等）、連携システム（部門独自システム、野良（ノーコードも含む）システム）一覧とシステム使用機器一覧
※顧客導入システム全体の俯瞰確認と、リプレースの対象システム、関連するシステムが明確にわかるよにする。
・個別機器のOS種別とバージョン、使用システムの一覧
※必ず個別実機ごとに確認。
・使用言語（スクリプト、簡易言語（ノーコード）も含む）と上記システムとの関係を記載した一覧
※リプレースの対象システムとそれに関連するシステムの使用言語の確認。
・DB種別とバージョンの一覧
※リプレースの対象システムとそれに関連するシステムのDBサーバー、DB種別を確認。
・外部情報連携（Web-EDI等）の一覧とフロー図
※I/F方式、連携TBL/ファイルレイアウト、連携タイミングとフロー（言い換えると連携データのダムの部分とゲートの解放タイミング、データの流れの確認）、リランポイント/リラン方式の明確化。
・外部接続機器連携（HTT、PAD等）の一覧
※I/F方式、TBL/ファイルレイアウト、連携タイミングとフロー（言い換えると連携データのダムの部分とゲートの解放タイミング、データの流れの確認）、リランポイント/リラン方式の明確化。
３）リプレス対象になるシステムの現行仕様の確認
・各種設計書、TBL/ファイルレイアウト一覧、コード/区分/フラグ一覧、帳票一覧、画面一覧、システムフロー（サブシステム間連携、機能間連携）、JOBネット、ネットワークフロー
※システムフローとJOBネットでは連携データのダムの部分とゲートの解放タイミング、処理とデータの流れの確認、リランポイント/リラン方式の明確化し、システムと呼応する現行業務を時間軸に沿って業務フロー（BPMNフロー等）化する。
４）リプレス対象になる現行システムのレスポンス等の確認
・各機能のレスポンス、またはターンアラウンドタイムの計測（オンライン、バッチ、I/F連携、プリンタ出力等）と確認
＜実データ調査項目＞
【目的】データの標準化、正規化度合いの実態確認、常時保持データ量と過去データの扱いの確認する
１）データの標準化の確認
・コード、区分、フラグ体系の実態確認
※コード、区分、フラグの意味が切り分けされていない等、1つのコードに複数の意味を持たせているか（一部の桁が区分やフラグになっている、納品先/仕入先といった意味での分離をしておらず、得意先の概念一本で一括管理している等や、商品コードが指す品目は一意か、それとも循環使用されているかといった)の確認。
余談だが、本来は区分、フラグに関してはSP、NULL設定を認めてはいけない。テスト時のデータダンプで空白があった場合、正しいのか、セット漏れか、判別がつかなくなりバグの温床になる。（この意味が分からない人間は平気でバグのある仕組みを生み出すため、適切に対処をしないといけない）
・項目の扱いポリシーの確認
※1つの項目に複数の意味を持たせている(区分やフラグの代わりに、データがセットされている/されていないが、機能自体の振る舞いやデータ連携先を決定する条件になっている)等の確認や、項目内容の曖昧さを許容（NULLとSPは同値と見なす等）しているかの確認を行う。
特に前任担当者が退職し、年間売り上げを後任者が引き継次ぐ場合など、担当別前年度売上対比リスト等のために、実データの過去の指定期間の担当者コード項目の洗い替えを行うという事がおこなわれるようなシステムの場合、洗い替えを行ったことに対して明確なポリシーがあるかの確認が注意が必要。
（集計業務のためにデータを改ざんするようなことが許されるシステムの場合、内部統制上、問題があるため）
２）正規化度合いの確認
・TBLの正規化（１～３次）のどのレベルまでなされているかの確認
※普通は2次正規化まで。3次まで行うとレスポンスが悪くなる場合がある（コード等の有効期間の情報が入るため）。なおレスポンス重視のために1次正規化で止める場合もある。
また、気をつけないといけないのは、通常はコードにホモニムが発生する際、アクティブ期間を管理するが、その対応を行わずに単純に正規化したがゆえに、ホモニムを持つ過去の情報が変わってしまう場合がある。
３）常時保持データ量と過去データの扱いの確認
・通常保持データ量の確認
※各テーブルのデータ量、単位期間（分から期、年まで）あたりのトラン発生量、情報連携時の1バッチ当たりのデータ量の確認。
・過去データの扱い
※マスタ移行と残高移行で良いのか。トラン移行は生きていないデータは捨てるのか、全て移行するのかの確認。なお、実際の移行は別記載の移行手順で対応する。
・退避状態で管理されているデータの有無と利用状況
※過去のTRNを含む、年度分なりのバックアップデータ（加工済みデータを含み）を引き出して分析等に使用しているのか等の確認。
＜現行システム調査項目＞
【目的】AsIsの概要を明確化するため
・上記資料を基に以下の資料を作成しリプレース対象システムのアウトラインの確認
✓主要DB（マスタ、トラン）のER化
✓主要機能（主にオンライン・バッチ更新系）のDFD化
※細部の詳細も必要だが、まずは鳥瞰できないといけない。次に鳥瞰と細部からの積み上げが交わる一線の部分が実業務とのシステムが交わる部分になる。
＜顧客要件確認外の重要事項＞
【目的】AsIs,ToBe共に連携連動するシステムのポリシーを明確にする
・AsIs:連携連動するシステム系の中心になる仕組みがどこなのかを確認し、どの仕組みの部分（会計系、販売系、製造指図系等）に最適化が寄せられているのか確認する。（すべてが独立の場合や無秩序の場合もあるが…）
・ToBe:連携連動するシステム系の中心となる仕組みを決定し、どの機能に最適化を寄せていくのが、顧客要件を実現する上で最適なのか検討を行う。
※部分最適では全体最適はかなえられない。チェーンマネジメントの全体最適であっても最適化を寄せていく軸（人体の心臓がタクトであり生命維持の軸であるように）が必要になる。
多軸のシステムで発生する複雑さはカオスしか生まず、人ではコントロールできない。
・システム間の結合強度を明確にする
既に運用されている先行導入のシステムに対して、強い強度で結合すると、通常、後発システムに飲まれてしまい（先行システムの制約がかかり）後発システム本来の機能上の強みが出せなくなってしまう。
このため、
・各システムを緩い結合でつなぐ方式と（バッチ起動ファイル連携等）
・先行側システムを変えてでも強い強度でつなぐ方式があり（各DB相互参照やQUEを用いた共用DBリアルタイム更新の機能を先行システムにも盛り込む等）
この各々のシステム間の結合強度を明確にする。
＜AsIsとToBeのFIT&GAP＞
【目的】AsIsとToBeの違いを明確にする。
※上記調査で現れたAsIsの実態とこれから検討、製造、導入するToBeの同じ部分と異なる部分を明確にし、RFPを用いて概要設計プロセスに入っていく。
以上です。