こんにちは。Project VBAの世界へようこそ。
普段、Excelマクロなどで自動化に親しんでいる方でも、Microsoft Project、特にProject ServerやProject Onlineという「サーバー環境」を相手にした途端、一筋縄ではいかない壁にぶつかることがあります。
その最たるものが、今回解説する「チェックアウト・チェックイン」の制御です。
ローカルのファイル（.mpp）をいじるのとは違い、サーバー上のプロジェクトは「誰が今編集権を持っているか」という排他制御を厳密に行う必要があります。ここを疎かにすると、マクロが途中で止まるだけでなく、サーバー上に「開けないゴーストプロジェクト」を残してしまうことにもなりかねません。
今日は、マクロの記録を卒業し、プロフェッショナルな「サーバー連携VBA」を構築するための極意を伝授します。ここをクリアすれば、Project VBAの基本、そして真髄はバッチリですよ。
—
1. なぜ「チェックアウト」の制御が重要なのか？
Project Online/Server環境では、一つのプロジェクトを複数のメンバーが参照します。そのため、以下のルールが徹底されています。
1. 参照（リードオンリー）: 誰でも開けるが、保存はできない。
2. 編集（チェックアウト）: 一人だけが「編集キー」を握り、保存・更新ができる。
VBAで自動処理を行う際、この「編集キー（チェックアウト）」をプログラム側で明示的に取得し、処理が終わったら確実に「返却（チェックイン）」しなければなりません。
もしコードが途中でエラーを吐いて止まり、チェックイン処理が漏れてしまったら……？ そのプロジェクトはあなた（のマクロ）が掴んだまま「ロック」され、他のユーザーが編集できなくなってしまいます。これが運用現場で最も恐れられるトラブルの一つです。
—
2. チェックアウト制御の基本フロー
サーバー上のプロジェクトを安全に操作するための黄金律は、以下の4ステップです。
1. 状態確認: そのプロジェクトは今、誰かにチェックアウトされていないか？
2. チェックアウト付きオープン: 編集権を確保して開く。
3. 主処理: タスクの追加やベースラインの設定。
4. 保存・チェックイン・クローズ: 編集権を返し、ファイルを閉じる。
【図解】制御のライフサイクル
[開始]
↓
[サーバーへ確認] ── (誰かが使用中?) ─→ [エラー通知/待機]
↓ (空いている)
[チェックアウトして開く] <--- ここで「編集権」を確保
↓
[マクロによる自動編集]
↓
[保存(Save)]
↓
[チェックイン(Checkin)] <--- ここで「編集権」を解放
↓
[終了]
---
3. 実践：エラーを回避する堅牢なVBAコード
それでは、実務でそのまま使えるレベルのコードを見てみましょう。
ポイントは、「もしエラーが起きても、必ずチェックインを試みる」というエラーハンドリングの構造にあります。
Option Explicit
”’
”’
Sub SecureServerProjectUpdate()
Dim targetProjectName As String
targetProjectName = “<>ProjectName” ‘ サーバー上のプロジェクト名は “<>名前” 形式
On Error GoTo ErrorHandler
‘ 1. プロジェクトをチェックアウト状態で開く
‘ Checkout:=True が最大のポイントです。
‘ これにより、他の人が編集中の場合はエラーを返してくれます。
Application.FileOpenEx Name:=targetProjectName, ReadOnly:=False, Checkout:=True
Dim pj As Project
Set pj = Application.ActiveProject
‘ 念のため、チェックアウトに成功しているか内部プロパティで確認
If Not pj.IsCheckedOut Then
MsgBox “チェックアウトに失敗しました。他のユーザーが編集中かもしれません。”, vbExclamation
Exit Sub
End If
‘ — [主処理ここから] —
‘ 例：ベースラインの保存（0番を全タスクに対して設定）
BaselineSave All:=True, Copy:=0, Into:=0
‘ — [主処理ここまで] —
‘ 2. 保存
FileSave
‘ 3. チェックインとクローズ
‘ Save:=Trueにすることで、最終的な変更を確実にサーバーへ反映します。
‘ CheckIn:=True が編集権を解放する魔法の言葉です。
FileCloseEx Save:=pjSaveYes, CheckIn:=True
MsgBox “処理が正常に完了し、チェックインされました。”, vbInformation
Exit Sub
ErrorHandler:
‘ エラーが発生した場合のリカバリ処理
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
‘ プロジェクトが開いている状態なら、編集権を残さないよう強制チェックインを試みる
On Error Resume Next
If Not ActiveProject Is Nothing Then
‘ 変更を破棄してでもチェックインを優先し、ロックを防ぐアプローチ
FileCloseEx Save:=pjDoNotSave, CheckIn:=True
End If
On Error GoTo 0
End Sub
—
4. プロが教える「陥りやすい罠」と対策
① `FileOpenEx` での競合
他のユーザーが既にプロジェクトをチェックアウトしている場合、`FileOpenEx` は実行時エラーを発生させます。
対策: 上記のコードのように `On Error GoTo ErrorHandler` で捕捉するか、事前に `Application.IsCheckedOut` 関数（※Project ServerのAPI経由）で状態を確認するロジックを組むのが上級者への道です。
② 「保存」と「チェックイン」は別物
`FileSave` をしただけでは、サーバー上の下書き（Draft）に書き込まれるだけで、他のユーザーには変更が見えません。`CheckIn:=True` を実行して初めて、公開（Published）領域への反映準備が整います。
対策: 処理の最後には必ず `FileCloseEx` の `CheckIn` 引数を意識しましょう。
③ ゴースト・セッションの回避
ネットワークの瞬断などで、VBAが「開いているつもり」なのにサーバーとの接続が切れることがあります。
対策: ライフサイクルを短く保つこと。マクロを動かす直前に開き、終わったら即座に閉じる。これだけでトラブルの8割は防げます。
—
5. まとめ：Project VBAを掌握するために
Project VBAの神髄は、単なる「操作の自動化」ではなく、「サーバーリソースの正しい管理」にあります。
- マクロの記録は、操作の綴りを知るには良いですが、エラー処理までは教えてくれません。
- プロのコードは、常に「失敗した時にどう後始末するか」がデザインされています。
今回学んだ「チェックアウトの明示的な制御」と「エラー時の強制復帰」をマスターすれば、あなたのマクロは現場で信頼される本物のツールへと進化します。
一歩ずつ、確実に。このコードをベースに、自分のプロジェクトに合わせたカスタマイズを楽しんでくださいね。もし分からないことがあれば、いつでもまた聞きに来てください。応援しています！
