You: 5/1から以下の案件に参画します。システムを素早く理解する為には具体的にどうすればよいか？具体的な手順を知りたいです。 例えば、 まず確認すべき事項は何か？またそれをどうやって確認するか？ まず確認すべきドキュメントの種類は何か？ まず構築すべき人間関係は何か？ キャッチアップの手順を具体的にステップバイステップで教えてください。 ============================= 案件名：【移行設計】OAシステム基盤 移行設計及び運用設計支援 案件内容： 概要： ・官公庁向けの、クライアントPC、SaaS 型グループウェア、メール、Web 閲覧、拠点内のLAN、拠点間のWAN 等を含むユーザ数10,000 超の職員向け大規模OA 基盤を新システムに移行するPJ。 ・移行に伴った移行設計及び運用設計をスコープとして行い、運用設計チームの要員募集。 ＜移行設計チームの業務＞ ・要件定義 　-現行システム調査 　-システム化計画の把握 　-システム基本設計への移行観点での提言 　-移行要件作成 ・移行計画書作成 　-移行全体方針 　-移行全体スケジュール（ステップ定義） 　-各機能移行方針 ・移行設計書（案）作成 　-各機能の移行作業一覧 　-各機能の移行詳細（案）（作業内容、対象機器、スケジュール、移行判定基準、作業影響、コンテプラン等） ・移行手順書一覧（案）作成 ＜想定業務＞ ・現行システムから次期システムへの各機能のシステム移行設計を、現行システムの現状と次期システムの設計を把握したうえで、各技術チームのリーダーとの円滑なコミュニケーションにより調整し、実施する。 ・現行システムに存在するアカウント、オンプレミスのファイルサーバ上のファイルデータ、クライアントPC上のローカルデータのデータ移行設計を実施する。 スキル(必須)：すべて満たす必要はなし ①Active Directory環境のOAシステムの設計構築の経験 ②クラウドサービスを含んだシステムの設計構築の経験 ③メンバー数3名以上のチームリーダー経験 ④と対面でのコミュニケーションが問題なくできること ※資料の説明や質疑応答を直接ご担当いただくため ⑤包括的な指示で自主的に移行設計を進められること スキル(尚可)： ※①-⑤のうち、いずれか1つは必須とする ①Microsoft365の設計構築の経験 ②経路設計やセキュリティ機能を含むメール機能の設計構築の経験 ③WANを含むネットワーク設計構築の経験 ④外部プロキシの設計構築の経験 ⑤オンプレファイルサーバからクラウドストレージへのデータ移行について、ツール選 定、移行設計・実施の経験 ⑥官公庁向けのプロジェクトの設計・構築・運用の経験 ============================= ChatGPT: 以下のステップをより正確にご提案するために、いくつか確認させてください。 2. ご自身の役割は「移行設計チーム」の中でも特にどの領域（例：AD設計、データ移行設計、計画書作成、調整業務など）を想定されていますか？ 4. 参画初期に閲覧・把握できるドキュメントの種類（設計書、運用資料、台帳など）に制約はありますか？ 6. システムの構成要素のうち、特に早めに把握しておきたい領域（例：クライアント管理、ネットワーク設計、SaaS移行など）はありますか？ ご回答いただければ、キャッチアップの具体的ステップを順序立ててご提案します！ You: 現時点で担当領域は明確化していませんが、サーバ構築が得意なことは伝えてありますし、担当する業務は＜想定業務＞と書いてあるところの内容であると思います。また、参画初期のドキュメントがどのようなものが存在するか？についても現場に入らないと不明です。早めに把握しておきたい領域は、現行システムの全ての範囲です。その範囲は、案件の「概要」にある要素も含んでいますし、一般的なITシステム全般の領域と考えてください。 ChatGPT: 了解しました。それでは、移行設計プロジェクトに初期参画する際に、現行システム全体を素早くキャッチアップするための具体的なステップバイステップ手順をまとめてリサーチします。 現時点では担当領域が未確定なため、システム全体に関する理解を深めることを主軸に、最初に確認すべき事項、ドキュメント、人間関係の構築など、実践的な視点からご提案します。完了次第、わかりやすくお伝えしますね。 Research completed in 14m· 11 件の情報源 移行設計プロジェクト参画時のシステム理解手順 # 官公庁OAシステム移行プロジェクト参画: 初期キャッチアップ手順 大規模な官公庁向けOA（オフィスオートメーション）システム基盤の現行→次期移行プロジェクトに新規参画する際、**短期間でシステム全体を把握すること** が求められます。本ガイドでは、参画初期段階で効率よくキャッチアップするための具体的な手順を、以下の3つの観点から整理します。 2. まず確認すべき事項（現行構成、移行対象、依存関係など）とその確認方法 4. 初期に読むべきドキュメントの種類と入手方法 6. 最初に築くべき人間関係（関係者と質問内容の例） ## 1. まず確認すべき事項と確認方法 プロジェクト参画直後は、現行システムと新システムに関する基本情報を速やかに把握することが重要です。まず以下の項目を優先的に確認しましょう。確認時にはドキュメント参照だけでなく、必要に応じて担当者へのヒアリングも行います。** 了解しました。それでは、移行設計プロジェクトに初期参画する際に、現行システム全体を素早くキャッチアップするための具体的なステップバイステップ手順をまとめてリサーチします。 現時点では担当領域が未確定なため、システム全体に関する理解を深めることを主軸に、最初に確認すべき事項、ドキュメント、人間関係の構築など、実践的な視点からご提案します。完了次第、わかりやすくお伝えしますね。 Research completed in 14m· 11 件の情報源 移行設計プロジェクト参画時のシステム理解手順 # 官公庁OAシステム移行プロジェクト参画: 初期キャッチアップ手順 大規模な官公庁向けOA（オフィスオートメーション）システム基盤の現行→次期移行プロジェクトに新規参画する際、**短期間でシステム全体を把握すること** が求められます。本ガイドでは、参画初期段階で効率よくキャッチアップするための具体的な手順を、以下の3つの観点から整理します。 2. まず確認すべき事項（現行構成、移行対象、依存関係など）とその確認方法 4. 初期に読むべきドキュメントの種類と入手方法 6. 最初に築くべき人間関係（関係者と質問内容の例） ## 1. まず確認すべき事項と確認方法 プロジェクト参画直後は、現行システムと新システムに関する基本情報を速やかに把握することが重要です。まず以下の項目を優先的に確認しましょう。確認時にはドキュメント参照だけでなく、必要に応じて担当者へのヒアリングも行います。特に現行システムの詳細は担当者への聞き取りも積極的に行い、ドキュメントにない運用上の注意点まで洗い出すことが重要です[proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=,%E2%80%A2%20%E3%81%93%E3%82%8C%E3%81%BE%E3%81%A7%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81%E3%81%AA%E3%81%A9) [proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E8%AA%BF%E6%9F%BB%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AF%E3%80%81%E5%BF%85%E3%81%9A%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E9%81%8B%E7%94%A8%E3%81%AB%E8%A9%B3%E3%81%97%E3%81%84%E6%8B%85%E5%BD%93%E8%80%85%E3%82%82%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%AB%E5%8A%A0%E3%81%88%E3%80%81%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E4%BB%95%E6%A7%98%E3%82%84%E9%81%8B%E7%94%A8%E7%8A%B6%E6%B3%81%E3%81%AA%E3%81%A9%E3%82%92%E7%B6%B2%E7%BE%85%E7%9A%84%E3%81%AB%E6%B4%97%E3%81%84%E5%87%BA%E3%81%99%E3%81%93%E3%81%A8%E3%81%8C%E9%87%8D%E8%A6%81%E3%81%A7%E3%81%99%E3%80%82) 。** - **現行システムと新システムの全体像** : 現行のクライアントPC環境、グループウェア/メールシステム、Web閲覧環境、ネットワーク構成を俯瞰します。次期システムでそれらがどう変わるのか、大枠のアーキテクチャ差分も確認します。可能であれば、**既存メンバーからアーキテクチャや設計方針についてブリーフィングを受ける** と理解が早まります[backlog.com](https://backlog.com/ja/blog/reflections-and-lessons-learned-by-participating-in-large-scale-replacement-with-play-framework/#:~:text=%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8D%E5%A7%8B%E3%82%81%E3%82%8B%E5%89%8D%E3%81%AB%E3%80%81%E6%97%A2%E5%AD%98%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%8B%E3%82%89%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%82%84%E8%A8%AD%E8%A8%88%E6%80%9D%E6%83%B3%E3%80%81%E7%A7%BB%E6%A4%8D%E3%82%92%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA%E6%B5%81%E3%82%8C%E3%81%A7%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%84%E3%81%A6%E3%81%84%E3%81%8F%E3%81%8B%E3%80%81%E8%BB%BD%E3%81%8F%E3%83%AC%E3%82%AF%E3%83%81%E3%83%A3%E3%83%BC%E3%82%92%E5%8F%97%E3%81%91%E3%81%A6%E3%80%81%E5%AE%9F%E8%A3%85%E3%82%92%E9%96%8B%E5%A7%8B%E3%81%97%E3%81%BE%E3%81%97%20%E3%81%9F%E3%80%82) 。 - **移行の対象範囲（スコープ）** : 今回移行の対象となるシステムや機能の範囲を明確にします。例えば、全職員PCのOS更改や機種交換、グループウェア/メールの更替、ネットワーク機器の刷新など、**どこまでが移行対象でどこからが対象外か** を把握します。プロジェクト計画書や要件定義書でスコープを確認し、不明点はPMに質問して明確化します。 - **関連システムとの依存関係** : OAシステムが他に連携しているシステムやサービスがあれば、その関係性を洗い出します（例：認証基盤、職員情報DB、人事給与システムとの連携など）。これらの**依存関係** により移行に影響が出ないか確認が必要です。現行システムの構成図やインタフェース一覧を確認し、各関連システムの担当者にヒアリングして依存箇所を把握します。 - **制約条件・前提事項** : 移行にあたっての制約や前提も初期に確認しておきます。例えば、本番システムを**何時間まで停止可能か** （許容ダウンタイム）、移行作業は夜間・休日に限定されるか、セキュリティポリシー上の制約（クラウド利用の可否、データ持ち出し禁止事項など）、さらに納期や予算上の制約などです。これらは要件定義書やセキュリティガイドライン、契約書に記載されているため目を通し、必要に応じPMに補足確認します。 - **現行システムの課題点** : 現行環境でユーザや運用部門が感じている不満や問題点も把握しておきましょう。例えば「メール容量が不足している」「PCの起動に時間がかかる」「ネットワークが頻繁に遅延する」等、**移行によって改善すべきポイント** です。現行運用担当者へのヒアリングや、過去の障害・問い合わせ履歴を確認し、些細な懸念事項も含め洗い出します[proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=,%E2%80%A2%20%E3%81%93%E3%82%8C%E3%81%BE%E3%81%A7%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81%E3%81%AA%E3%81%A9) 。こうした課題を知っておくと、移行設計時に重点検討すべき箇所が見えてきます。 - **自身の役割・担当範囲** : 配属チーム内での自分の役割と責任範囲も早めに確認します。移行設計チームで**どの領域（機能移行設計、データ移行、テスト計画作成など）を担当するのか** 、また期待される成果物（作成すべき資料）とそのスケジュールを上長に確認しましょう。役割が曖昧なままだと情報収集に漏れが出るため、早期にリーダーとの打ち合わせを行い、担当を明確化します。 **✔️ 初期確認項目チェックリスト:** （参加後できるだけ早く下記を確認） - 現行システムおよび新システムの構成図を入手し概要を把握した - プロジェクトのスコープ（対象システム・除外範囲）を明確に確認した - 他システムとのインタフェース/依存関係を洗い出して共有した - ダウンタイム制約やセキュリティ要件などの前提条件を確認した - 現行システムの問題点・リスク要因を関係者からヒアリングした - 自身の担当領域と役割についてチームリーダーと合意した ## 2. 初期に読むべきドキュメントと入手方法 プロジェクト開始時には、関連するドキュメントを可能な限り収集して熟読することが肝要です。以下は、特に初期段階で目を通すべき主な資料とその入手方法です。**新旧システム双方の資料を確認し、現行から何がどう変わるのかを把握しましょう。** - **現行システムの構成・設計資料** : 現行環境の全体構成を示す資料（システム構成図、ネットワーク図、サーバ/クライアント台数一覧、PC標準仕様書など）は最優先で入手します。これらは現行システムを提供・運用している部署やベンダーが持っているはずなので、プロジェクトの共有フォルダやナレッジベースから探すか、担当者に依頼して提供してもらいます。もし公式なドキュメントが見当たらなければ、担当者へのヒアリング内容から**簡易な現行構成図を自作** してみるのも有効です。 - **次期システムの設計書一式** : 新システムの基本設計書や方式設計書、アーキテクチャ図、ネットワーク設計書、セキュリティ設計書等を入手して読み込みます。新環境で採用するプラットフォームや主要技術（例：SaaSグループウェア製品名、メール移行先サービス、PC OSバージョン、クラウド利用有無など）および設計方針を理解します。設計リーダーやPMに依頼し、最新版の設計ドキュメント一式へのアクセス権をもらいましょう。 - **移行方針・移行計画に関する資料** : 可能であれば**移行方針書や移行計画書** がないか確認します。移行の全体スケジュール、移行対象の一覧、移行方式（例：一斉切替か段階移行か）、使用するツール（データ移行ツールや配布管理ソフト等）、想定されるリスクと対処策、移行時の体制などが整理されているはずです[proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=%E9%A0%85%E7%9B%AE%20%E5%86%85%E5%AE%B9%20%E7%A7%BB%E8%A1%8C%E6%A6%82%E8%A6%81%E3%83%BB%E6%96%B9%E9%87%9D%20%E5%85%A8%E4%BD%93%E7%9A%84%E3%81%AA%E7%A7%BB%E8%A1%8C%E6%96%B9%E9%87%9D%E3%82%84%E5%89%8D%E6%8F%90%E6%9D%A1%E4%BB%B6%E3%81%AA%E3%81%A9%20%E7%A7%BB%E8%A1%8C%E3%82%B9%E3%82%B1%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB,%E3%83%87%E3%83%BC%E3%82%BF%E7%A7%BB%E8%A1%8C%E3%81%AA%E3%81%A9%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E3%83%84%E3%83%BC%E3%83%AB%20%E7%A7%BB%E8%A1%8C%E3%81%AB%E3%82%88%E3%82%8B%E5%BD%B1%E9%9F%BF%E3%83%BB%E5%AF%BE%E5%87%A6%20%E8%80%83%E3%81%88%E3%82%89%E3%82%8C%E3%82%8B%E7%A7%BB%E8%A1%8C%E6%99%82%E3%81%AE%E3%83%AA%E3%82%B9%E3%82%AF%E3%81%A8%E5%AF%BE%E5%87%A6%E6%96%B9%E6%B3%95%20%E7%A7%BB%E8%A1%8C%E4%BD%93%E5%88%B6%20%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E7%A7%BB%E8%A1%8C%E3%82%92%E6%8E%A8%E9%80%B2%E3%81%99%E3%82%8B%E7%A4%BE%E5%86%85%E3%81%AE%E4%BA%BA%E5%93%A1%E4%BD%93%E5%88%B6) 。まだ正式な計画書が無い場合でも、提案書やキックオフ資料に移行方針が記載されていれば目を通します。これらの資料はPMまたは移行担当リーダーが保有しているため、依頼して共有してもらいます。 - **要件定義書・RFP** : 官公庁案件であれば調達時の仕様書（RFP）や要件定義書が存在するはずです。**新システムで満たすべき要件** が網羅された重要資料であり、現行から追加・削除される機能、サービスレベル（SLA）要件、セキュリティ要件などを把握できます。プロジェクト開始時にクライアントから共有を受けている可能性が高いので、未入手であればPM経由で提供してもらいます。 - **運用設計書・手順書** : 移行後の運用を見据え、運用面の設計や手順に関するドキュメントも確認します。例えば、現行システムの運用フロー図や定常作業手順書、運用体制図、および新システムの運用設計方針書（例：クラウドサービス運用の場合の役割分担や監視設計）があれば入手します。運用設計担当者や現行運用チームから提供してもらい、**移行後の運用イメージ** を掴んでおきましょう。 - **データ移行関連資料** : データ移行が発生する場合、現行データの種類・規模を示す資料も重要です。例えば、ユーザアカウント/メールボックス一覧・容量、ファイルサーバのデータ容量、データベースのレコード件数などの情報や、データ移行仕様書があれば確認します。移行対象データの**抽出方法や移行先でのマッピング** を理解するためです。資料がなければ現行システムのDB管理者等に依頼し、主要データの項目リストやサンプルデータを提供してもらいます。 - **プロジェクト計画書・体制図** : プロジェクト全体計画や体制が記載された資料にも目を通します。全体のスケジュール感、各フェーズの目的、主要マイルストーン、そしてチーム体制（関係者一覧）が把握でき、後述する関係者とのコンタクト計画にも役立ちます。PMOが管理するプロジェクト計画書や組織図があれば共有してもらいましょう。 - **会議議事録・決定事項ログ** : 過去の主要会議の議事録やプロジェクト内の決定事項ログがあれば参照します。特に設計上の重要な決定や前提事項（例：「メールシステムはクラウドサービス○○を採用」「PCはOSのみアップグレードし端末は継続利用」等）を把握できます。プロジェクトの共有フォルダやチケット管理システム上で公開されていないか確認し、過去の経緯を把握しましょう。 **✔️ ドキュメント入手チェックリスト:** （入手でき次第内容を把握する） - 現行システムの構成図・設計書類を入手した - 次期システムの基本設計書・方式設計書を入手した - 移行方針書・移行計画書（スケジュール含む）を入手した - 要件定義書（またはRFP仕様書）を入手した - 現行運用フロー/手順書、および新運用設計書を入手した - 移行対象データの一覧・移行仕様書を入手した - プロジェクト全体計画書・体制図を入手した - 主要会議の議事録や決定事項ログを確認した ## 3. 最初に築くべき人間関係とヒアリングポイント 大規模プロジェクトには多くの関係者が存在するため、早期に**誰がどの役割を担っているか** を把握し、それぞれと適切にコミュニケーションを取ることが重要です[blog.mmmcorp.co.jp](https://blog.mmmcorp.co.jp/2018/09/27/join-new-project/#:~:text=,%E7%AA%93%E5%8F%A3%E3%81%AB%E3%81%84%E3%82%8B%E4%BA%BA%E3%81%AF%E3%81%A9%E3%81%86%E3%81%84%E3%81%86%E5%BD%B9%E5%89%B2%E3%81%A7%E3%80%81%E3%81%A9%E3%81%86%E3%81%84%E3%81%A3%E3%81%9F%E4%BA%BA%E3%81%8B) 。まずプロジェクトの組織図やメンバー表を確認し、主要な担当者を洗い出しましょう。その上で、以下のキーパーソンとの関係構築に注力します。単に挨拶するだけでなく、**積極的に情報提供を受けるためのヒアリング** を実施しましょう。 - **プロジェクトマネージャー（PM）** : プロジェクト全体を統括する責任者です。スケジュール・予算・品質管理を担っており、全体像やリスクも把握しています。PMとは信頼関係を築き、定期的に進捗や課題を報告・相談できるようにします。**聞くべき内容** として、プロジェクト全体の主要マイルストーンや成功の判断基準、自分の担当に対する期待事項を確認しましょう（例：「プロジェクトの重要なマイルストーンと期限はいつですか？」「私の担当領域で特に重視すべき点は何でしょうか？」）。 - **移行設計チームリーダー / 基盤アーキテクト** : 移行設計全般の取りまとめや、新システムの技術的方針を決定しているキーパーソンです。チームリーダーから、新旧システムの差分や設計上のポイントについて**直接ブリーフィングを受ける機会** を作りましょう[backlog.com](https://backlog.com/ja/blog/reflections-and-lessons-learned-by-participating-in-large-scale-replacement-with-play-framework/#:~:text=%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8D%E5%A7%8B%E3%82%81%E3%82%8B%E5%89%8D%E3%81%AB%E3%80%81%E6%97%A2%E5%AD%98%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%8B%E3%82%89%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%82%84%E8%A8%AD%E8%A8%88%E6%80%9D%E6%83%B3%E3%80%81%E7%A7%BB%E6%A4%8D%E3%82%92%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA%E6%B5%81%E3%82%8C%E3%81%A7%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%84%E3%81%A6%E3%81%84%E3%81%8F%E3%81%8B%E3%80%81%E8%BB%BD%E3%81%8F%E3%83%AC%E3%82%AF%E3%83%81%E3%83%A3%E3%83%BC%E3%82%92%E5%8F%97%E3%81%91%E3%81%A6%E3%80%81%E5%AE%9F%E8%A3%85%E3%82%92%E9%96%8B%E5%A7%8B%E3%81%97%E3%81%BE%E3%81%97%20%E3%81%9F%E3%80%82) 。現在検討中の課題や、これまで議論に上がった論点なども共有してもらえると背景知識が深まります（質問例：「現行環境から大きく変更になる部分はどこですか？」「現在懸念されている技術課題はありますか？」）。 - **現行システム運用担当リーダー** : 現行OAシステムの運用責任者です。現行環境の細かな仕様や利用実態、過去のトラブル事例に通じており、移行における**知見の宝庫** となる存在です[proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E8%AA%BF%E6%9F%BB%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AF%E3%80%81%E5%BF%85%E3%81%9A%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E9%81%8B%E7%94%A8%E3%81%AB%E8%A9%B3%E3%81%97%E3%81%84%E6%8B%85%E5%BD%93%E8%80%85%E3%82%82%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%AB%E5%8A%A0%E3%81%88%E3%80%81%E7%8F%BE%E8%A1%8C%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E4%BB%95%E6%A7%98%E3%82%84%E9%81%8B%E7%94%A8%E7%8A%B6%E6%B3%81%E3%81%AA%E3%81%A9%E3%82%92%E7%B6%B2%E7%BE%85%E7%9A%84%E3%81%AB%E6%B4%97%E3%81%84%E5%87%BA%E3%81%99%E3%81%93%E3%81%A8%E3%81%8C%E9%87%8D%E8%A6%81%E3%81%A7%E3%81%99%E3%80%82) 。早い段階で面談し、現行システムの詳細（ユーザの利用状況、定期バッチ処理の内容[proactive.jp](https://proactive.jp/resources/columns/system-migration/#:~:text=,%E2%80%A2%20%E3%81%93%E3%82%8C%E3%81%BE%E3%81%A7%E3%81%AE%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81%E3%81%AA%E3%81%A9) 、監視・バックアップ手順など）を教えてもらいましょう。また、**現行から新環境に変わることで懸念している点** や、移行実施日に向けて準備すべきことをヒアリングします（例：「現行運用で頻発している問い合わせや課題は何ですか？」「データ移行で特に注意が必要な情報はありますか？」）。運用担当者との連携により、ドキュメントにはない現場感覚の情報を得られます。 - **各技術領域の担当者（サブシステムリーダー）** : OA基盤に含まれる各要素（クライアントPC、メール、グループウェア、ネットワーク、セキュリティ等）のリーダー級担当者とも順次コンタクトを取りましょう。これら専門担当者から、それぞれの領域における**設計内容や移行手順** を概要レベルで共有してもらいます。特に自分の担当領域と関連が深い部分（例：ネットワーク変更がクライアントPCやSaaS利用に与える影響など）は詳細を質問します。各担当者には「現在懸念している課題は何か」「他チームに共有すべき注意点はあるか」を尋ね、**全体最適の視点** で情報を集約しましょう。 - **クライアント側責任者（発注者代表）** : 官公庁側でプロジェクト推進を担当している責任者（例えば情報システム部門の課長級など）がいれば、この方との信頼関係構築も大切です。システム導入後のビジョンや成功判断の基準、組織として特に重視しているポイントをヒアリングしましょう（例：「新システムで最も改善したい点は何でしょうか？」「移行期間中の業務影響について懸念していることはありますか？」）。クライアントの価値基準を理解しておくことで、移行設計の優先順位付けに役立てることができます。 - **チーム内の同僚メンバー** : 移行設計チーム内の他メンバーとも円滑な関係を築きます。日々の作業で協力し合う仲間ですので、早めに雑談も交えつつ打ち解けておきましょう。困ったときに**気軽に質問・相談できる雰囲気** を作ることが大事です。定期ミーティングやチャットで積極的に発言・質問したり、自分の調べたことを共有する姿勢を見せると、チームに貢献しながら信頼を得ることができます。 - **情報共有チャネルへの参加** : プロジェクトで使用している**コミュニケーションツールや情報共有基盤** には必ず参加しましょう[blog.mmmcorp.co.jp](https://blog.mmmcorp.co.jp/2018/09/27/join-new-project/#:~:text=%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%84%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E7%AE%A1%E7%90%86%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%84%E3%82%8A%E5%8F%96%E3%82%8A%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%9F%E3%82%8A%E3%81%97%E3%81%AA%E3%81%8C%E3%82%89%E3%80%81%E4%BB%A5%E4%B8%8B%E3%81%AE%E7%82%B9%E3%82%92%E6%8A%8A%E6%8F%A1%E3%81%97%E3%81%A6%E3%81%84%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82) 。例えばプロジェクトのSlack/Teamsチャンネル、メーリングリスト、Backlog/JIRAなどの課題管理ツール、共有ドライブなどです。これらを閲覧することで、過去のやり取りから誰が何の担当かや直近の課題状況を把握できます[blog.mmmcorp.co.jp](https://blog.mmmcorp.co.jp/2018/09/27/join-new-project/#:~:text=%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%84%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E7%AE%A1%E7%90%86%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%84%E3%82%8A%E5%8F%96%E3%82%8A%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%9F%E3%82%8A%E3%81%97%E3%81%AA%E3%81%8C%E3%82%89%E3%80%81%E4%BB%A5%E4%B8%8B%E3%81%AE%E7%82%B9%E3%82%92%E6%8A%8A%E6%8F%A1%E3%81%97%E3%81%A6%E3%81%84%E3%81%8D%E3%81%BE%E3%81%99%E3%80%82) 。新人だからと遠慮せず、気になった点はチャット上で質問したりコメントしたりして存在感を示しましょう。 **✔️ 関係構築チェックポイント:** （初期1〜2週間で下記を実施） - PMと面談しプロジェクト全体像や自身の役割について確認した - 移行設計リーダーから新旧システム差分や設計方針の説明を受けた - 現行運用担当者から現行システムの詳細と懸念点をヒアリングした - 各サブシステムの担当者と順次コンタクトを取り情報交換した - クライアント側の責任者とコミュニケーションを開始した - プロジェクトのチャット／課題管理／共有フォルダに参加し過去情報を参照した 以上のステップを踏むことで、参画初期に必要な情報を網羅的にキャッチアップできます。最初は情報量に圧倒されるかもしれませんが、**「全体像の把握 → 詳細情報の読込 → キーパーソンへの確認」**というサイクルを繰り返すことで徐々に理解が深まるでしょう。上記チェックリストも活用し、漏れのないよう準備を進めてください。 ![Favicon](https://www.google.com/s2/favicons?domain=https://blog.mmmcorp.co.jp&sz=32) ![Favicon](https://www.google.com/s2/favicons?domain=https://backlog.com&sz=32) ![Favicon](https://www.google.com/s2/favicons?domain=https://proactive.jp&sz=32) 情報源