【仕事】今更ながら、システム再構築を成功に導くユーザガイド の雑なススメ
今日は終日在宅勤務でした。
子供が冬休みで嫁がパートだった為に子供達と僕だけで家にいましたが、良し悪しですね。僕が家にいると遊んでもらえると思うようですが、さすがに仕事中に大手を振って遊ぶわけにもいかないです。ただ、下の娘は仕事中であることを理解できず、なぜか家にいるのに遊んでもらえないと思っているようです。在宅勤務の良し悪しですね。
今日はERP導入調査用資料のサンプルを作成していました。
漢字連続で小難しく書いていますが、
・業務一覧
・業務フロー
・帳票一覧
のサンプルを作っていました。
前職でERP導入を経験していましたが、提案依頼(RFP提示)前に必要な情報って結構多いんですよね。自分たちだけで作らない場合も多いと思いますが、コンサル会社に依頼する場合にも以下が含まれているかチェックしたほうがいいです。手抜きRFP作られちゃいますから。
実際に色々必要になりますが、あえて最小限でと考えるのであれば以下です。
・現状業務一覧
・現状業務フロー
・現状帳票一覧・サンプル
・現状機能一覧・サンプル
・現状外部インターフェース一覧
・現行システム規模資料（マスタ・データ量等）
・新業務一覧
・新業務フロー
・新システム機能要求事項
・新システム非機能要件一覧
お腹いっぱいになる、ふざけないで、との声が聞こえそうですが、
これらがいずれか不足した状態で要件定義を進めた場合、要件定義時にベンダーよりヒアリングが行われる為、お互いに工数が多く必要になってしまいます。そして工期も長くなったり、後工程にしわ寄せが来ます。嫌ですよね。
前までは導入する側でしたが、今後は依頼する立場になるので、依頼前にしっかりと整備しようと思います。
ちなみに参考情報として、IPAから出ている関連資料では、以下が参考になるかなと思います。
システム再構築を成功に導くユーザガイド
https://www.ipa.go.jp/files/000057294.pdf
相当膨大な資料ですが、システム導入を検討するのであれば是非一度見ておくことをお勧めします。SIerに以前勤務していましたが、すべてこの通りに実施は難しいものの、全く的外れでも無いかなと思います。
それでは、今日はこの辺りで。
一応、以下は事前調査部分の引用です。今すぐ調査を予定している人は是非ご参考にまで。
インプット情報
調査や分析に必要な情報は、現行システムで使用している運用、設計ドキュメントおよび ソースコードや定義体などの資産である。この情報だけではわからない場合は、有識者への ヒアリングを実施し補完する。
具体的な内容は以下の通り。
・現行システムの運用、保守情報（稼動ログ、保守における環境やアプリケーションの変更状況など）
・現行システムのドキュメント（業務フロー、機能仕様書、インターフェース仕様書やデータモデル図、CRUD 図、運用手順書など）
・現行システムの資産（ソースコード、画面・帳票定義体、運用・環境定義、外部接続定義情報など）
・ドキュメントや資産調査だけでは現状の把握が難しい場合は、有識者（業務有識者や実運用者、エンドユーザなど）へのヒアリング
アウトプット情報
調査・分析で得るべき項目の代表例を、調査観点ごとに以下に示す。これらの調査結果は、 再構築手法（特にハードウェア更改以外のリホスト、リライト、リビルド）の決定、および 再構築計画の策定に必要な情報となる。
(1) 資産
再構築にあたって、現行システムの構成や規模を把握し、アプリケーションの保守性および再利用範囲を見極めるための基礎情報。
・現行システムの巨大化、肥大化の度合い（資産規模、言語の種別、定義体数など）
・新システム構成検討に必要な項目（現行システム構成、適用ミドルウェア、データベース管理システム、文字コード体系、外字の使用有無など）
・アプリケーションの保守や維持における特性（複雑度や類似度）
・再利用や移行対象の候補となる資産（商用システムでの稼動、または未稼動の区分）
(2) 業務知識の保有状況
業務知識の断片化、細分化の状況や度合いを調査、分析する。また、再構築手法の選択において、再構築対象となる基幹システムの業務仕様の掌握度合いや連携する他システムへの影響調査、業務継続性を判断できる有識者の関与度合いを判断する際に必要となる情報である。
① 有識者
有識者については、スキルの深さ（質的な面）と業務エリアなどの習熟範囲、カバー範囲（量的な面）の2つの側面がある。
・再構築時に必要な有識者（業務仕様、基盤、システム運用・保守担当）の状況
・運用検証や合否判定ができる体制や要員検討のための、保有スキルセット
②ドキュメント
・ブラックボックス化の度合い（設計ドキュメントが最新になっているかなど）
・運用検証のシナリオ作成のために必要なドキュメント（業務フロー、機能仕様書など）の有無
(3) 処理方式
リホストなど再構築手法によっては、再構築後も現行と同じシステム機能が必要となるため、現行システムでどのような処理方式が存在するのか、明確にする必要がある。これらを明確にするため現行システムがどのような処理方式で動作しているのか調査を実施する。
① 再構築手法によって、移行方法や新システムでの処理方法が変わる項目の例
・新システムで検討が必要な項目の候補（アプリケーションの動作環境、オンライン処理方式、バッチ処理方式、データベースアクセスの方法、帳票の出力方法な ど）
② 手法の選択にかかわらず新システムへ引き継ぐ必要のある項目の例
・再構築時に対外的な調整や検証が必要な外部接続先の種類や連携方法（メッセージ連携、ファイル転送方法、文字コード変換の有無と種類など）
・印刷位置の踏襲が必要な規定帳票やメールシーラなどの指定帳票の有無。
(4) 非機能要件
再構築手法の選択によって、新しいOSやプラットフォームにより基盤を再構築する場合、新旧システムの構成の違いから、運用や性能、信頼性は現行システムと全て同じに なるとは限らない。 従って、業務の運用に支障がないように現行システムから引き継ぐ範囲や内容を明確にする必要がある。このため、下記のような非機能要件を観点とした現状調査を行う。
・現行から新システムへ引き継ぐ情報を整理するための現行運用項目（運用時間帯、運用スケジュール定義、バックアップ、リカバリ方法など）
・現行から新システムへ引き継ぐ範囲を明確にするための可用性、信頼性項目（現行システムの冗長構成や多重化の対象有無、稼動率、停止時間など）
・新システムの性能評価のための比較元情報（現行システムの性能情報）
(5) 業務データ
再構築手法の選択により、システム切り替えやデータ移行が発生する場合のために、業務データ量やデータ仕様を調査し、把握する必要がある。
・新システムの設備量や拡張性の諸元になる、データ容量やデータ伸長率
・データ移行時に考慮すべき、データ構造やテーブル数、データレイアウト
(6) 保守状況 再構築後の保守環境や再構築スケジュールの検討に必要な現行システムの保守状況の 調査を行う。
・再構築による投資効果を評価するための現行システムの運営コストやアプリケーションの保守コスト
・再構築の際に考慮が必要になる凍結可否や凍結時期の検討のための現行システムのアプリケーション保守状況（変更時期、頻度など）
・移行元アプリケーションの保守状況や品質状況を確認するための、これから着手する予定の案件やインシデントの発生状況など
