「PMOって何やってるの?」と聞かれて、明確に答えられる人は意外と少ないんですよね。求人票には「進捗管理」「課題管理」と書いてあるけれど、それが実際の現場でどう動いているのか。私は現在も現役PMOとして毎日プロジェクトの現場にいます。今日は私が朝9時から夕方6時まで、実際に何をしているのかを時系列で語ります。
PMOの1日は「見えないものを可視化する」ことから始まる
PMOの仕事を一言で表すなら、「プロジェクトの見えない部分を見えるようにする」ことです。でも教科書的な定義を語っても、現場感は伝わりません。まずは私の実際の1日を見てもらうのが一番早いと思います。
朝9時:メールとチャットの嵐を整理する
私の朝は、前日夜から翌朝までに溜まったメールとSlackの確認から始まります。開発チームは夜型の人も多いので、深夜2時に「明日の作業、ちょっと遅れそうです」みたいなメッセージが入っていることもあります。
ここで大事なのは、単にメッセージを読むだけではないということです。私がやっているのは「どのメッセージが今日対応すべき火種なのか」を見極めることなんです。100通のメールがあったとして、本当に今日中に対処すべきものは5通くらい。その5通を見逃さないために、私は件名と送信者の組み合わせでパターン認識しています。
私が現役PMOとして、ある中堅企業の100名規模プロジェクトに参画している現在、典型的な1日のスケジュールを紹介します。朝7時、メールチェックと夜間のベンダーからの報告整理から始まります。9時から朝会(15分)で当日の進捗確認と課題の早期発見。10時から12時は課題管理表・リスク管理表の更新、PMとの調整。昼食時はメンバー数人と雑談を兼ねて情報収集(これが意外と重要)。13時から15時はステークホルダー会議のファシリテーションと議事録の整理。15時から17時は翌週の作業計画策定とベンダーコントロール。17時から18時で振り返りと明日への引き継ぎ。夜は緊急時のみ対応。教科書には載らない、現場のリアルなPMOの1日です。
この朝の30分で、私はその日のリスクの9割を把握しています。PMOは後追いではなく、先回りする仕事だと実感する瞬間です。
朝9時半:進捗管理表の更新とズレの検出
メールチェックが終わったら、すぐに進捗管理表の更新です。私の場合、Excelベースの進捗表とBacklogのガントチャートの両方を見ています。開発チームはBacklogで作業を記録し、私はそれをExcelに転記して、顧客向けの報告資料を作る流れです。
この作業で見ているのは「予定と実績のズレ」です。例えば、先週金曜日に「80%完了」だったタスクが、月曜日の朝も「80%完了」のままだったら、これは何かが起きています。週末に作業が進まなかった理由があるはずで、そこを朝会で確認する必要があります。
進捗率が動いていないタスクには、Excelのセルに黄色でマーキングします。この「色付けルール」は私が勝手に決めたものですが、朝会でPMに共有するときに一目で分かるので重宝しています。黄色が3日続いたら赤に変えて、PMと個別に対策会議を設定します。
朝10時:定例の朝会でリスクを引き出す
毎朝10時から15分間、開発チーム全体での朝会があります。私の役割は司会ではなく「リスクの嗅覚センサー」です。各メンバーが「今日やること」を報告する中で、私は以下のキーワードに耳を澄ませています。
- 「たぶん」「おそらく」→不確実性の兆候
- 「ちょっと」「少し」→遅れの婉曲表現
- 「調べてみます」→実は分かっていない可能性
- 「相談したいことが」→すでに問題が発生している
朝会が終わった直後に、気になった発言をしたメンバーに個別に声をかけます。「さっきの『たぶん』って、何が不確定なの?」と聞くと、実は前提条件が変わっていたとか、テスト環境がまだ準備できていないとか、具体的な問題が出てくるんです。
この「朝会後の5分間」が、私にとって最も価値の高い時間です。ここで火種を消せるかどうかが、その日のプロジェクトの安定性を左右します。
午前中:課題管理表の更新と優先度調整
朝会で拾った問題は、すぐに課題管理表に登録します。私が使っているのはExcelの課題管理台帳で、以下の項目を記録しています。
- 課題ID(連番)
- 発生日
- 課題内容(50文字程度の要約)
- 影響度(大中小)
- 緊急度(高中低)
- 担当者
- 期限
- ステータス(未着手、対応中、完了、保留)
- 備考(経緯や関連情報)
この表で大事なのは「影響度と緊急度のマトリクス」です。私は毎日、課題を4象限に分類しています。影響度大×緊急度高は即対応、影響度小×緊急度低は後回し。このルールを決めておかないと、声の大きい人の課題ばかりが優先されてしまうんです。
午前中のうちに、前日までの課題のステータスを全件確認します。期限が過ぎているのに「対応中」のままの課題があれば、担当者にSlackで「今日中に完了見込みですか?」と聞きます。このリマインドをサボると、課題管理表が形骸化します。
なぜPMOの仕事はこんなに細かいのか
ここまで読んで「PMOって細かい作業ばっかりじゃん」と思った人もいるかもしれません。実際その通りで、PMOの仕事の8割は地味な確認作業です。でもこの地味な作業をサボると、プロジェクトは一気に崩壊します。
情報の非対称性がプロジェクトを壊す
私が30年間見てきて分かったのは、プロジェクトが失敗する最大の原因は「技術力不足」ではなく「情報の非対称性」だということです。開発チームは問題を知っているのに、PMは知らない。PMは顧客の要望変更を知っているのに、開発チームは知らない。この情報のズレが積み重なって、ある日突然「納期に間に合わない」という事態になります。
PMOの存在意義は、この情報の非対称性を解消することです。朝のメールチェックも、進捗表の更新も、朝会での質問も、全ては「誰が何を知っていて、誰が何を知らないか」を把握するための行動なんです。
小さなズレを放置すると大きな火事になる
もう1つ、現場にいて実感するのは「小さなズレは必ず大きくなる」という法則です。金曜日に1日遅れたタスクは、月曜日には3日遅れになり、水曜日には1週間遅れになります。遅れは加速するんです。
だからPMOは毎日、同じことを繰り返します。進捗を確認し、課題をリストアップし、リスクを先読みする。この反復作業が、プロジェクトを安定させる唯一の方法だと私は信じています。「もっと効率的にできないか」とよく言われますが、効率化を求めて確認頻度を減らした瞬間に、プロジェクトは見えなくなります。
PMOは翻訳者である
PMOのもう1つの役割は「翻訳者」です。技術者の言葉を顧客の言葉に、顧客の要望を技術者の言葉に翻訳します。午後の仕事を語る前に、この翻訳業務について触れておきます。
例えば、開発チームが「データベースのインデックス設計を見直す必要があります」と言ったとき、顧客にそのまま伝えても理解されません。私は「検索速度が遅くなるリスクがあるので、事前に対策します。作業工数は2日です」と翻訳します。逆に、顧客が「もっと使いやすくしてほしい」と言ったとき、開発チームには「具体的にどの画面のどの操作を改善するか、要件を明確にしてください」と翻訳します。
この翻訳作業がないと、技術者と顧客は永遠に話が噛み合いません。PMOが間に入ることで、両者の認識がようやく一致するんです。
午後:調整と会議と突発対応の連続
午前中は比較的ルーチンワークが多いのですが、午後は予定外のことが次々に起きます。ここからは午後の典型的な業務を紹介します。
午後1時:週次の進捗報告会議
毎週月曜日の午後1時から、顧客を交えた進捗報告会議があります。私の役割は、会議資料の準備とファシリテーションです。会議資料は前日の金曜日に8割方作っておき、月曜日の午前中に最新の数字に更新します。
資料の構成はシンプルです。1ページ目に全体スケジュールのガントチャート、2ページ目に今週の完了タスクと次週の予定タスク、3ページ目に課題一覧とリスク一覧。この3ページだけで、プロジェクトの現状が伝わるように設計しています。
会議中、私は議事録を取りながら、顧客の発言で重要なものにマーキングしていきます。「ここは仕様変更の可能性がある」「この要望は追加工数が発生する」といった発言を見逃さないことが大事です。会議が終わったら30分以内に議事録を共有し、アクションアイテムを課題管理表に追加します。
午後2時半:突発の問い合わせ対応
午後になると、突発の問い合わせが増えます。「この仕様ってどうなってましたっけ?」「テスト環境にアクセスできないんですけど」「顧客から電話があって、納期の確認をされたんですが」といった内容です。
こういう問い合わせに即答できるかどうかが、PMOの価値を決めます。私は過去の議事録、仕様書、課題管理表、進捗表をすべて頭に入れているので、大抵のことは30秒以内に答えられます。答えられないことは「10分待ってください」と言って、該当する資料を探し出します。
この即応力を維持するために、私は情報を一元管理しています。プロジェクトフォルダの構造を統一し、ファイル名のルールを決め、常に最新版がどこにあるか分かるようにしています。「あの資料どこだっけ?」と探す時間は、プロジェクトにとって無駄以外の何物でもありません。
午後3時:リスクの先読みと対策検討
午後3時頃、少し落ち着いたタイミングで、私はリスク管理表を見直します。リスク管理表には、まだ顕在化していないけれど起こり得る問題をリストアップしています。
例えば「テストデータの準備が遅れる可能性」「外部APIの仕様変更リスク」「キーマンの休暇による作業遅延」といった内容です。これらのリスクに対して、発生確率と影響度を評価し、優先度の高いものには事前対策を打ちます。
この「先読み」がPMOの腕の見せ所です。問題が起きてから対応するのは誰にでもできます。問題が起きる前に手を打つことが、PMOの本当の価値なんです。
午後4時:ステークホルダー調整
午後4時以降は、ステークホルダーとの個別調整が入ることが多いです。顧客の窓口担当者、協力会社のリーダー、社内の営業担当など、プロジェクトに関わる人たちとの調整です。
この調整業務で私が意識しているのは「Win-Winの着地点を探す」ことです。顧客は早く納品してほしい、開発チームは品質を担保したい、営業は予算を守りたい。全員の要望を100%満たすことは不可能なので、80%ずつ満足できる落としどころを探します。
この交渉力は、30年の経験で磨かれたものです。若い頃は「顧客の言うことが絶対」だと思っていましたが、今は「顧客の本当の目的は何か」を見極めるようになりました。表面的な要求の裏にある真のニーズを理解すれば、別の解決策が見えてきます。
夕方5時半:その日の振り返りと翌日の準備
定時の30分前、私はその日の振り返りをします。課題管理表を見て、今日完了予定だったものが本当に完了しているか確認します。未完了のものがあれば、その理由を把握し、翌日のアクションを決めます。
それから、翌日の会議予定を確認し、必要な資料を準備します。翌日の朝会で確認すべきポイントをメモに書き出し、デスクの上に置いておきます。このメモがあるだけで、翌朝のスタートダッシュが全然違います。
最後に、開発チームに「今日はお疲れ様でした。明日もよろしくお願いします」とSlackで一言送ります。この一言が、チームの士気を保つのに意外と効くんです。PMOは管理者である前に、チームの一員だと私は思っています。
現代のPMOが使うべきツールと選び方
ここまで私の1日を語ってきましたが、「これ全部手作業でやってるの?」と思った人もいるでしょう。実際、私はExcelとSlackを中心に、いくつかのツールを組み合わせて仕事をしています。ここでは、私が実際に使っているツールと、選び方のポイントを紹介します。
Backlogで開発タスクを一元管理
私が現場で使っているタスク管理ツールはBacklogです。選んだ理由は、日本の開発現場に合っているからです。海外製のツールは高機能ですが、日本語のサポートが弱かったり、UIが直感的でなかったりします。Backlogは日本企業が作っているので、日本の開発チームが求める機能がちゃんと揃っています。
具体的には、ガントチャート、カンバンボード、Wiki、ファイル共有が1つのツールに統合されています。開発チームはカンバンボードで日々のタスクを動かし、私はガントチャートで全体スケジュールを把握します。Wikiには仕様書や議事録を蓄積し、いつでも検索できるようにしています。
私がBacklogで特に気に入っているのは、課題の親子関係を設定できることです。大きなタスクを親課題として登録し、その下に子課題をぶら下げることで、階層的な管理ができます。これによって、「機能Aの開発」という大きなタスクの中に「設計」「実装」「テスト」という子タスクを作り、それぞれの進捗を追えるんです。
Slackでリアルタイムコミュニケーション
メールは公式な連絡に使い、日常的なやり取りはSlackで行っています。Slackの良さは、チャンネルを分けることで情報の整理ができることです。私のプロジェクトでは、全体連絡用、開発チーム内部用、顧客とのやり取り用など、チャンネルを目的別に分けています。
Slackで私が毎日使っているのは「リマインダー機能」です。朝会の5分前にリマインダーを設定しておくと、Slackが自動で通知してくれます。これで「会議忘れてた!」ということがなくなりました。あとは、重要なメッセージにスター(星マーク)をつけておいて、後で見返せるようにしています。
ただし、Slackにも弱点があります。それはフロー型のツールなので、情報が流れて消えてしまうことです。重要な決定事項や仕様変更は、Slackでやり取りした後、必ずBacklogのWikiに転記するルールにしています。この二段構えが、情報の散逸を防ぐコツです。
Excelは今でも現役の最強ツール
最後に、今でも私が最も使っているツールはExcelです。「Excelなんて古い」と言われることもありますが、現場では今でもExcelが最強だと私は思っています。理由は、誰でも使えて、自由にカスタマイズできて、軽いからです。
私は進捗管理表、課題管理表、リスク管理表の3つをExcelで作っています。これらの表には条件付き書式で色を付け、ピボットテーブルで集計し、グラフで可視化しています。このカスタマイズ性は、専用ツールでは得られないものです。
ただし、Excelを使う上で絶対に守っているルールがあります。それは「最新版を明確にする」ことです。ファイル名に日付を入れる、最新版は決まったフォルダに置く、古いバージョンはアーカイブフォルダに移す。この運用ルールがないと、Excelは情報の墓場になります。
ツール選びで大事なのは「現場が使い続けられるか」
ツール選びで私が最も重視するのは「現場が使い続けられるか」です。高機能なツールを導入しても、3ヶ月後に誰も使っていなければ意味がありません。私が見てきた失敗プロジェクトの多くは、ツールが複雑すぎて、入力が面倒で、結局Excelに戻ってしまったケースです。
だから私は、新しいツールを導入するときは必ず「これ、毎日更新できる?」と自問します。BacklogもSlackも、毎日触っても苦にならないシンプルさがあります。この「苦にならない」という感覚が、ツール選びの最重要ポイントだと30年の経験から断言できます。
30年現場にいた私が思うこと:PMOは黒子だが不可欠な存在
PMOの仕事は地味です。華々しい成果が出るわけではないし、表彰されることもありません。プロジェクトが成功したときに褒められるのはPMであり、開発チームであり、PMOが評価されることはほとんどありません。
でも私は、この黒子の役割に誇りを持っています。なぜなら、PMOがいなければプロジェクトは回らないと知っているからです。進捗を追う人がいなければ、遅れは放置されます。課題を管理する人がいなければ、問題は忘れられます。リスクを先読みする人がいなければ、炎上は必然です。
PMOは「見えないインフラ」である
私がPMOの仕事をインフラに例えるのは、そういう理由です。水道や電気と同じで、普段は誰も気にしないけれど、止まった瞬間に困ります。PMOも同じで、いる間は空気のような存在ですが、いなくなった瞬間にプロジェクトは混乱します。
30年前、私がプログラマーだった頃は、PMOという職種は存在しませんでした。PMが全てを管理し、開発者も自分で進捗を報告していました。でもプロジェクトの規模が大きくなり、関係者が増え、技術が複雑になるにつれて、専門の管理者が必要になったんです。PMOは時代が生んだ必然的な役割だと私は思っています。
若手に伝えたいこと:PMOは「調整力」を磨く最高の修行場
もしあなたが若手SEで、PMOになることを検討しているなら、私は背中を押したいと思います。PMOは技術力だけでは評価されない世界ですが、その代わりに「調整力」「先読み力」「翻訳力」という、マネージャーに必須のスキルが磨かれます。
私自身、SE時代は技術一辺倒でしたが、PMOになってから視野が広がりました。技術の外に、人の感情があり、組織の論理があり、ビジネスの制約があることを学びました。この視野の広さが、後にPMになったときに活きました。PMOは、マネージャーへのキャリアパスとして最適な修行場だと私は思っています。
明日からできる小さなアクション:自分の1日を時系列で書き出してみる
最後に、あなたに1つだけ試してほしいことがあります。それは、今日の自分の仕事を時系列で書き出してみることです。9時に何をして、10時に何をして、どこに時間を使ったか。書き出してみると、意外と「何をしていたか分からない時間」が多いことに気づくはずです。
PMOの仕事は、この「見えない時間」を見えるようにすることです。自分の時間の使い方が見えるようになれば、他人の時間の使い方も見えるようになります。そしてプロジェクト全体の時間の使い方も見えるようになります。この「可視化する力」が、PMOの本質だと私は信じています。
プロジェクトは生き物です。毎日変化し、予想外のことが起きます。でもその変化を毎日追い続けることで、プロジェクトは安定します。PMOはその安定を支える、地味だけれど不可欠な存在です。もしあなたがPMOの道を選ぶなら、私は応援しています。一緒に現場を守りましょう。
コメント