PMO導入でプロジェクトが成功した「3つの事例」
はじめに
これまで5回に渡って「PMO」という職業について解説してきました。今回は、実際にプロジェクトに入ったPMOが具体的にどのような動きをして、それによりプロジェクトにどのような影響をもたらしたのか、3つの事例で分かりやすく解説します。
【事例1】「作業者のストレス軽減」に着目し、エクセルで業務効率150％UP!
プロジェクトの概要
「経理部の日常作業が多く、財務諸表など必要なデータがすぐ得られないため早急な経営判断ができない」と、企業の経営層から相談を受けて始まったプロジェクトです。
「業務プロセスに手作業が混在し、ミスが発生しやすい」「月末月初の残業が常態化している」との声もあり早急な対応が求められる中、私はプロジェクト内PMO(※1)として参画しました。同社からは次の2つの要望がありました。
- 膨大な取引データの処理に追われる経理部門の事務処理時間を短縮化したい
- 将来的に事務作業を担当する人員を経理分析に注力させたい
これらの実現がプロジェクトのゴールとなります。そこで、私は次のような施策を打ち出すことにしました。
(*1)：事業部内の1つのプロジェクトを管理するPMO。詳細は前回の記事を参照。主な実施施策
1. 経理部門のヒアリング、会計システムの現状把握を行い、業務プロセスの改善案、新ツールの仕様を決定
現行では月間数千件のデータ処理に3営業日を要していました。しかも、伝票を手書きして手入力する作業があるため「手書き伝票を作成する人」「会計システムに入力する人」「入力内容と伝票を照合する人」の少なくとも3人分のリソースが必要で、4人の従業員が手分けして作業にあたっていたのです。
ここで着目したのが「銀行取引データの活用」です。ネットバンキングから取得できるものですが、今まで通帳からデータを拾っていたため未使用でした。このデータを既存の会計システムに取り込めるよう、普段から従業員が使い慣れているエクセルで変換ツールを作成することにしました。
2. 有効性検証のため並行稼働を実施した上でツール導入
一定期間、現行作業とツールを活用した作業を並行して行い、有効性を比較。前者では手入力のミスが多発する一方、後者ではミスがなくツールの精度や正確性を証明できる結果となり、ツールの本格導入につながりました。
【引用】office Rootブログ「今が最高のプレゼント」
改善後の変化
- 作業スピードが150％アップ
3営業日を要していた入力作業は半日で完了できるようになり、翌営業日には財務諸表が出来上がる状態になりました。 - 工数は95％削減
4人の従業員が月24時間ずつかけて行っていた伝票入力や手書き伝票の作成(4人×24時間＝96時間)は、1人の従業員が4時間作業するだけで完了できるようになりました。 - 正確性が格段に向上
伝票の手書きや入力といった「手作業」を照合する作業もなくなり、基本的にミスが起こらない環境ができました。
ポイント
日常的に手作業が多い職場は、デジタルツールに弱い人も一定数いるものです。ツールは全従業員が操作しやすいエクセルで作成し、複雑なマクロを組み込まない仕組みにしました。なお「段階的に業務をシフトしていく」ことも心がけたことで、社員のみなさんが足並みをそろえて効率化に取り組んでもらえることになったのです。(1)(2)の課題解決だけでなく「どうすれば、作業者がストレスなく業務を進められるか」にも着目したことがこのプロジェクトのポイントで、お客様にも良い評価をいただくことができました。
【事例2】「情報の集約」で、システムの品質やチーム間の連携も向上!
プロジェクトの概要
自社が開発・運用するパッケージシステムに障害が多発し、全社的な改善要求を求められていたシステムベンダー企業の事例です。社内には、同システムを導入するお客様ごとに20以上のプロジェクトチームが走っており、同一の障害が発生、もしくは今後発生する可能性がありました。しかしチーム間は連携が取れておらず、情報共有ができていない状況。プロジェクトチームはお客様の連絡を受けてから各々で修正やカスタマイズの対応を実施しており、コストが増加していました。
このプロジェクトが目指すゴールは、
- 各チームで起きている障害情報や対応内容をすべてのチームで共有できるツールを作成するとともに、チーム間の連携を高めるプロセスを構築する
私はプロジェクト内PMOとして品質管理部門の運営事務局に入り、対応を進めていくことになりました。
主な実施施策
1. 情報を運営事務局に集まるようにした
プロジェクトチーム同士の情報共有を円滑にするため、各チームで障害情報や対応内容を入力すると運営事務局の情報管理台帳に自動的に反映されるツールをエクセルで作成しました(その後、BTS：BugTrackingSystemへ移行)。
【引用】office Rootブログ「今が最高のプレゼント」
もし、PMO(運営事務局)がいない場合、どこかのチームのPMが情報の取りまとめを担うケースはよくあると思います。「売上が高い○○チームが仕切ってください」とトップから支持される場合もあるでしょう(優秀な人が最も売上の高いチームにアサインされる傾向にあるため)。
すると、仕切りを任されたPMは自分のチームに加え、他の19チームのことまで考えなくてはならず、業務負担が大きくなります。そのPMが重要なプロジェクトを担当している場合、過度な負担で手が回らなくなると会社的にも痛手となってしまいます。
また、内部から選出されると「規模が大きいチームの情報を優先しよう」「あのチームは売上が低いから」など濃淡をつけて物事を判断しがちな面もあります。しかし、売上が少ない、規模が小さいチームからの報告も非常に重要な情報である可能性は十分にあります。そうした情報を見逃してしまうと、この先で重大なトラブルに発展しかねません。
今回、情報を運営事務局に集めたことにより、情報の重要性をシステム視点で公平に判断することにつながりました。全体を横断的に管理できるため、全チームへ「今後こういう障害が起きるかもしれない。起きたときはこのような対応を」と注意喚起し、大きなトラブルを未然に防ぐねらいもありました。情報共有されていれば、障害が発生してもどのチームもスムーズに対応でき、お客様にも安心いただけます。何より、取りまとめを専門部署が担うことで、どのチームのPMも本来業務に集中できたことが大きなメリットとなったのです。
2.プロジェクトチームのリーダーとの接点を増やし、プロセス定着を図った
もともと社内には裁量権を与えられた各チームのリーダーが独自にプロジェクト運用を行う文化が根付いており、運営事務局など他部門からの意見は、なかなか受け入れられない雰囲気もありました。
そこで私は足を使い、各リーダーと意識的に接点を持つことを心掛けました。例えば、チームを回って私たちの活動や新しいプロセスを認知してもらう機会をつくる、リーダーが参加する会議で少し時間をもらい、お互いの情報を共有する時間を設ける、といった感じです。すると、徐々にリーダーから進捗状況などを積極的に話しかけてもらえたり、会議やエクセルツール内での情報共有が活発化したりと、良い方向へ動き始めました。
改善後の変化
- システム品質が向上
チーム間の情報共有によって障害発生の未然防止が可能となり、システムの品質が向上し、お客様からの信頼性も高まりました。 - 改修コストが大幅に減少
他チームの対処方法を共有できるためトラブルの際も一から改修にあたる必要がなく、システム改修コストは大幅に減少しました。 - チーム間の連携強化
これまで希薄だったチーム同士の連携が強化され、自分のチーム、他のチームのためにも情報共有が大切なのだという意識が向上しました。
ポイント
情報共有の場を、あえてリーダー会議の一部として始めたのは、新たに会議を設けると「自分は参加するべき?」と躊躇する人がいたり、日程調整が難しかったりするからです。既存の会議のついでなら参加のハードルはグッと下がります。ちなみに、最初は5分程度だったこの場も、議論の活発化により10分、20分と長くなり、最終的に「システム品質改善会議」という単体の会議に発展。チーム間でより多くの情報が共有されるようになりました。
【事例3】「体系化」と「定量化」の推進で、円滑なプロジェクト運営を実現
プロジェクトの概要
最後は、ある企業のシステム開発部へ「部門PMO(※2)」として参画した事例です。開発部は各業務部門の依頼を受けてシステム用件定義などを作成し、ベンダーが開発を行います。部内には30前後のプロジェクトが同時に走っていましたが、開発規定などITガバナンスは整備できているものの、現場レベルでは以下のような効率の悪い運営が見られました。
- プロジェクトの管理・実施手法や計画書や課題管理表などが統一されておらず、プロジェクト開始のたびに一から考えるなど時間の無駄が発生している
- システムの品質判断する情報が十分になく、お客様が知りたい「必要人員数」「工数」「コスト」など精度の高い情報が提供できないため、なかなか話が進まない
このプロジェクトでは、主にこの2つの課題を解決すべく、始動しました。
【引用】office Rootブログ「今が最高のプレゼント」
主な実施施策
1. 開発プロセスの体系化
プロジェクトやシステム、人によってバラつきがあった管理・実施手法やドキュメントの書式を統一し、体系的に整理しました。例えば「この枠を埋めるだけ」「この場所にこの図を描くだけ」という分かりやすいフォーマットを作り、誰でも悩まずすぐにプロジェクトをスタートできるようにしました。各プロジェクトのメンバーは、本題のシステム開発に注力できます。
2. プロジェクトの定量化
これまでは現場リーダーの肌感覚を重視する企業体質があり、システムの評価基準や必要なリソースなどが正確に把握されていない現状がありました。そこで、プロジェクトの定量基準を過去の開発プロジェクトから作成。開発規模(step数)や開発期間、開発工数などを定義し、過去案件などと比較したベンチマークデータを構築しました。
1年ほど経てば最低でも30プロジェクト分のデータは出揃うので、お客様に「この機能の改修なら、これくらいの工数やコストが必要です」といった具体的な概算や、step数やグレードなどに応じたメニュー表の掲示が可能になりました。また、定量基準はプロジェクト完了ごとに随時見直しを行い、その都度、適正な基準を設けることができたのです。
改善後の変化
- 効率的なプロジェクト運営が可能に
新規プロジェクトでも、メンバーが入れ替わっても、体系化されたプロセス通りに進めていくことでITガバナンスに沿った効率的かつスピーディなプロジェクト運営が可能になりました。 - 定量的な情報をもとにした提案、意思決定が可能に
現場の肌感覚ではなく、データから導き出される定量的な情報をもとに、精度の高い見積りの提案、プロジェクト計画や意思決定が可能となり、取引をスムーズに進められるようになりました。
ポイント
特に初めて開発するシステムの場合、「開発したことがないから情報がない」企業と「情報がないと承認できない」お客様で、延々と噛み合わないやりとりが起こりがちです。プロジェクトの定量化によって、この無駄な時間が解消されたとともに、プロジェクトにおける問題の早期発見や対策などもしやすくなりました。
おわりに
第6回の今回は、プロジェクトにおけるPMOの導入事例を3つ紹介しました。世の中にはPMO不在のプロジェクトも数多くありますが、PMOを置くメリットは「PMやメンバーが本来業務に集中できること」に尽きると思っています。私が実施した施策は、内部から人をあてがって行うこともできます。しかし、それでは本来業務に100％の力を注ぐことはできないでしょう。仮にその方が優秀でどちらも完璧にこなしてしまうと、今度は「みんなこれができるはず」とハイレベルな評価基準ができてしまう懸念もあります。
私は常々、PMOとしてプロジェクトに参画する際は、プロジェクト全体、そして会社全体の底上げを考えて取り組んでいます。優秀な人、そうでない人も「みんなができる仕組みを作ること」こそ、PMOの仕事の真髄だと思うのです。
例えば、みなさんもよくご存じの交通ルール。赤信号は、みんなが「停まる」と知っています。ただ赤信号のライトが切れていたり、信号機が見えない場所にあったりすると「信号が光っていなくて分かりませんでした」「見えなかったので進みました」という人が1人や2人現れます。
そんな人が出ないために、信号を目立つよう光らせる、見えやすい位置に移動するといった整備を行い、みんなが必ず交通ルールを守れる環境を作る。これが、PMOの仕事だと私は捉えています。
ベンチャー企業など小規模な会社であれば、PMOがいなくても何とかなるかもしれません。しかし大企業やこれから大きく成長したい企業には必須のポジションであり、今後さらに需要は高まっていくでしょう。
さて、今回で＜基礎編＞は終了となります。次回からは＜知識編＞として、PMOに求められる具体的な知識やスキルについて、解説していきます。どうぞお楽しみに!
