共通基盤・共有資源管理表のテンプレート
プログラムでは、複数のプロジェクトが同じものを使います。検証環境、マスタデータ、共通の部品、ライセンス、そして設計の標準。誰のものでもないが、全員が使うものが必ず生まれます。
これらに所有者がいないと、2つのことが起きます。誰も手入れをしないので古くなっていくこと。そして、誰かが勝手に変えて他のプロジェクトが止まることです。この記事では、共通基盤・共有資源管理表のテンプレートを紹介します。記入例は、ハルタ工機（架空）の「基幹システム再構築プログラム」です。
■ 1. 背景・よくある課題
よくある状態 | 何が起きるか |
|---|---|
共有するものに所有者がいない | 誰も手入れをせず、古くなっていく |
変更の手続きが決まっていない | 1本のプロジェクトが変えて、他の2本が止まる |
検証環境の予定を各PJが個別に持っている | 直前になって取り合いが表面化する |
テストデータを共有していない | 各PJが別々に作り、結果が比較できない |
ライセンス数を誰も数えていない | ピーク時に足りず、購入が間に合わない |
設計標準が最初のPJに合わせて作られている | 後発のPJが使えず、独自の作り方が生まれる |
■ 2. テンプレート作成の目的
目的 | 具体的にどうなることか |
|---|---|
すべての共有資源に所有者を置く | 手入れと変更の判断をする人を、個人名で決める |
変更の手続きを決める | 誰に事前通知し、誰が承認し、いつ反映するか |
取り合いを事前に見つける | 使用カレンダーで、重なっている期間を可視化する |
数量を管理する | ライセンス・環境・データ量のピークを把握する |
後発プロジェクトを考慮する | 標準は、最初のPJだけでなく全体を見て決める |
■ 3. 何が共有資源になるか
種類 | 例 | ぶつかり方 |
|---|---|---|
環境 | 開発・結合テスト・性能試験・移行リハーサルの各環境 | 同じ期間に複数のPJが使おうとする |
データ | 商品マスタ、取引先マスタ、テストデータ一式 | 1本が変えると、他のテスト結果が変わる |
共通部品 | 認証基盤、帳票出力、ログ基盤、API基盤 | 1本の都合で仕様が変わり、他が追随を迫られる |
ライセンス・アカウント | 開発ツール、テストツール、クラウドの利用枠 | ピーク時に数が足りない |
標準・規約 | 命名規則、設計書の様式、コーディング規約 | 後発PJが使えず、独自のやり方が生まれる |
人（希少スキル） | アーキテクト、業務知識をもつ担当者 | 要員配分計画で扱う（重複を避ける） |
このうち環境とデータが、実務でいちばん問題になります。どちらも「直前まで表面化しない」という性質があるからです。
■ 4. 使用カレンダーで取り合いを見る
環境ごとに、どのプロジェクトがいつ使うかを1枚にします。縦に帯が並んでいるところが、同じ環境を同時に使っている状態です。ハルタ工機の2025年では、3か所でぶつかっていました。
ぶつかっている箇所 | 内容 | 打った手 |
|---|---|---|
開発環境 4〜6月 | C1の改修、C4の構築、C2の構築の3本が重なる | 環境を1つ増設（C4専用。構築2週間・費用180万円） |
開発環境 10月 | C3の着手とC2の構築が重なる | C3の着手を11月へ（依存関係に余裕があったため） |
結合テスト環境 8月 | C1の追加改修とC2の結合テストが重なる | 時間帯で分割（C1は夜間と週末、C2は日中） |
3つめの時間帯で分けるは費用がかからない反面、データが混ざる事故が起きやすい方法です。採用する場合は「作業の前後に必ずデータを退避・復元する」という手順を、環境の利用ルールに書き込んでおいてください。
■ 5. 共有資源管理表の列
列 | 記入する内容 | 書き方のコツ |
|---|---|---|
ID／名称 | R-01、結合テスト環境 | ― |
種類 | 環境／データ／共通部品／ライセンス／標準 | 種類によって管理の仕方が変わる |
所有者 | 個人名（部署名では書かない） | 手入れと変更判断をする人。PgMが任命する |
利用するプロジェクト | C1、C2… と、利用の濃さ | 変更時の通知先になる |
変更の手続き | 事前通知の期間、承認者、反映のタイミング | 「2週間前に通知、推進会議で承認、月末に反映」など |
数量・容量 | ライセンス数、環境数、データ量 | ピーク時の必要数も書く |
調達のリードタイム | 増やすのに何週間かかるか | これを知らないと、気づいてからでは間に合わない |
費用負担 | プログラム共通費か、特定PJの負担か | あいまいだと、後で精算でもめる |
直近の変更 | いつ、誰が、何を変えたか | 不具合の原因調査で必ず参照される |
調達のリードタイムの列を入れておくのがコツです。「検証環境を1つ増やすのに2週間」と分かっていれば、使用カレンダーを見た時点で間に合うかどうかが判断できます。
■ 6. 記入例（架空企業：ハルタ工機）
ID | 名称 | 種類 | 所有者 | 利用PJ | 変更の手続き | 調達LT |
|---|---|---|---|---|---|---|
R-01 | 開発環境（4面） | 環境 | インフラ 大野 | C1〜C4 | 増設はPgM承認。構成変更は2週間前に通知 | 2週間 |
R-02 | 結合テスト環境（2面） | 環境 | インフラ 大野 | C1・C2・C3 | 使用予定は前月末までに登録。重複は推進会議で調整 | 3週間 |
R-03 | 品目マスタ（統合版） | データ | C4のPM 斎藤 | C1〜C3 | 項目追加は1か月前に通知。推進会議で承認 | ― |
R-04 | テストデータ一式（本番同等） | データ | PMO 河本 | C1〜C4 | 四半期に1回、全PJ合意のうえ更新 | 2週間 |
R-05 | 認証・権限の共通部品 | 共通部品 | C4のPM 斎藤 | C1〜C3 | インターフェース変更はCR票を起票 | ― |
R-06 | テスト自動化ツール（40ライセンス） | ライセンス | PMO 河本 | C1・C2 | 追加購入はPgM承認（1件300万円まで） | 4週間 |
R-07 | 設計書の様式・命名規則 | 標準 | PMO 河本 | C1〜C4 | 改定は推進会議で承認。改定後の適用時期を明記 | ― |
R-03（品目マスタ）の所有者が、C4のPMになっている点に注目してください。共有資源の所有者は、それを作っているプロジェクトのPMが兼ねるのが自然です。ただしC4が完了したあとの引き継ぎ先も、この表に書いておく必要があります。
■ 7. 変更の手続き
共有資源の変更は、変えること自体より、いつ誰に伝えるかが問題です。次の3点を決めておきます。
決めること | 目安 | 理由 |
|---|---|---|
事前通知の期間 | データ・共通部品は1か月前／環境の構成変更は2週間前 | 受け取る側が、自分の計画を調整する時間が要る |
承認者 | 影響が1PJなら所有者／複数PJなら推進会議 | 影響範囲によって、決める場を変える |
反映のタイミング | 月末など、決まった日にまとめて反映する | いつでも変わる状態だと、各PJが安心して使えない |
ハルタ工機では、共有資源の変更を「月末の最終営業日」に集約しています。日々変わらないと分かっていれば、各プロジェクトは月初にまとめて確認すればよくなります。
■ 8. 運用ルール
ルール | 内容 | 理由 |
|---|---|---|
すべての資源に個人名の所有者を置く | 部署名では書かない | 部署名だと、誰も手入れをしない |
使用予定は前月末までに登録する | 環境の予約制にする | 直前の取り合いを防ぐ |
反映日を固定する | 変更は月末にまとめて反映 | 各PJが安心して使える状態をつくる |
調達リードタイムを表に書く | 増やすのに何週間かかるか | 間に合うかどうかを、その場で判断できる |
PJ完了時の引き継ぎ先を決める | 所有者だったPJが終わるときの移管先 | 孤児になった資源は、必ず古くなる |
四半期に1回、使用カレンダーを更新する | 各PJの計画変更を反映する | 取り合いは、計画が動くたびに生まれる |
■ 9. よくある失敗と直し方
失敗 | 起きること | 直し方 |
|---|---|---|
所有者が部署名になっている | 誰も手入れをしない | 個人名に変える。PgMが任命する |
使用カレンダーが無い | 直前に取り合いが表面化する | 環境ごとに、四半期単位で予定を登録する |
変更がいつでも入る | 各PJが、いつ壊れるか分からず不安になる | 反映日を月末に固定する |
調達リードタイムを把握していない | 気づいたときには間に合わない | 表に列を作り、所有者が記入する |
標準が最初のPJに最適化されている | 後発PJが使えず、独自のやり方が生まれる | 標準の改定を、後発PJの参加時に1回入れる |
所有PJの完了時に引き継いでいない | 孤児になり、古くなっていく | PJの終結チェックリストに、資源の移管を入れる |
■ 10. 導入効果
観点 | 管理表が無いとき | 管理表を作ったとき |
|---|---|---|
環境の取り合い | 直前に表面化し、片方が待つ | 3か所を事前に発見し、増設・後ろ倒し・時間分割で対処 |
マスタの変更 | 知らないうちに変わり、テストが失敗する | 1か月前に通知され、月末にまとめて反映される |
ライセンス | ピーク時に足りない | 4週間のリードタイムを見て、事前に追加購入 |
共有資源の手入れ | 誰もしない | 所有者が個人名で決まっている |
PJ完了後 | 孤児になる | 終結チェックリストで、移管先が確認される |
■ まとめ
共有資源の管理でやることは、たった2つです。所有者を個人名で決めることと、使用予定を1枚にすること。
まずは検証環境から始めてみてください。環境ごとに、どのプロジェクトがいつ使うかを四半期の粒度で並べる。それだけで、半年先の取り合いが見えてきます。半年前に分かれば、たいていの取り合いは費用をかけずに解けます。