『DX時代の最強PMOになる方法』著者・甲州潤が教える
エンジニア時代に知りたかった「開発現場の難所」突破のコツ「キャリアアップをしたいエンジニアはPMOという選択肢もアリ」と著書『DX時代の最強PMOになる方法』で伝える甲州潤さん。エンジニアからキャリアをスタートし、現在ではPMOとして多くのIT利活用や経営相談をこなす甲州さんが「今だから言える、エンジニア時代こうしていればよかった」と思うスキルや考え方、プロジェクトの進め方を実体験をもとに紹介していきます!
『DX時代の最強PMOになる方法』著者・甲州潤が教える
エンジニア時代に知りたかった「開発現場の難所」突破のコツ「キャリアアップをしたいエンジニアはPMOという選択肢もアリ」と著書『DX時代の最強PMOになる方法』で伝える甲州潤さん。エンジニアからキャリアをスタートし、現在ではPMOとして多くのIT利活用や経営相談をこなす甲州さんが「今だから言える、エンジニア時代こうしていればよかった」と思うスキルや考え方、プロジェクトの進め方を実体験をもとに紹介していきます!
新入社員として入社し1~3年目までは、メンバー10人未満の規模の小さなチームで仕事をすることが多いと思います。しかし、中には5年目以降、50人以上が関わる仕事に参画する機会も増えてくるでしょう。関わる人や業務の規模が拡大し、これまでと同じように動いていてはうまくいかないことも出てきます。
その際、何を意識し、どのような行動をすればプロジェクトを成功させられるのか。今回は、PMO目線で「大型プロジェクトを成功させる五つのコツ」をお伝えしたいと思います。
株式会社office Root(オフィスルート)
代表取締役社長
甲州 潤(こうしゅうじゅん)
国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』(ビジネス教育出版社)
目次
まず、大型プロジェクトを進めていくうえでお伝えしたいこと、それは「小さなプロジェクトと同じマインドでは乗り切れない」ということです。例えば、メンバー10人以下、3カ月~半年程度の小規模なプロジェクトで考えてみましょう。
このような場合、納期のスケジュールやゴール設定も比較的見通しが立っていますし、メンバー同士は顔を見ながらコミュニケーションを取ることができます。そのため、もしスケジュールの遅延やミスが発生しても、「とりあえずメンバーみんな徹夜して遅れを取り戻そう」とか「PMの負担を多くしてリカバリーするわ」といったいわば”力技で何とかする”といった行動でカバーできてしまうのです。
しかし、大型プロジェクトではそうはいきません。そもそもメンバーが多く役割分担がはっきりしている場合であれば、役割以外のことに関して「○○さん、これ明日すぐにやって」と言っても対応できない場合がほとんどです。また、大型プロジェクトは期間も1年以上と長期に渡るケースが多く、スケジュール遅延が、繰り返し発生することもあります。こうなるとどんなに頑張ってもリカバリーは不可能に近いのです。
このことを知らないまま、「小さなプロジェクトと同じように、力技で何とかなるだろう」と思って取り組むと痛い目にあってしまいます。
余談になりますが、小さなプロジェクトの場合、何かトラブルが起こってメンバーみんなで解決すれば「苦難を乗り越えて成功した!」といういわば「成功の錯覚」を起こしやすい傾向にあります。トラブル続きのいわゆる”炎上プロジェクト”もこれによく似ており、「自分たちは火消しのヒーローである」「火消しこそがプロジェクトの成功」というイメージを持ってしまいがちです。
しかし、これらはあくまで「小さなプロジェクトだからできたこと」であり、そもそもメンバーに適した労力を無視して得た結果は成功とは呼びません。むしろこのような結果を招いた場合は、「失敗である」という意識が大切です。
のっけから厳しいことをいうようですが、大型プロジェクトの場合、毎日の積み重ねを丁寧に行わなわなければ、成功には絶対にたどり着きません。付け焼き刃は通用しないことをぜひ心に留めておいてほしいのです。
長期プロジェクトになればなるほど、さまざまなトラブルが発生します。そのうちの一つが、メンバーの入れ替えや欠員です。例えば、人間関係の悪化、スキル不足などによるメンバーの入れ替え、あるいはコロナやインフルエンザといった病気によって複数のメンバーが休んでしまい、進行がストップすることなどが考えられます。
このような「万が一」のとき、大切なのがリスク管理です。メンバーに不測の事態が発生した場合どうするか。大事なのは事態が起こった時、どんな手立てを誰がとるのかという「”決定の仕方”を決めておく」ことです。
不測のトラブルが発生したら、みんなで解決策を決めるのか、それとも○○さんが決めるのか。あるいはいっそ「社長」がすべての物事を決めるのか。考えておくようにしましょう。
とはいえ「社長が決める」というのは、少々乱暴すぎるので、決定プロセスを明確にできるとよいと思います。例えば、状況把握はPL、PM、方針案作成は◯◯部長、対策推進責任者は◯◯取締役、最終承認者が社長という具合です。
いずれにしても、プロジェクトの進行にはいくつもの不確定要素が存在します。ただし、その要素を細かく分解してリスクに備える必要はありません。「備えすぎ」もまたルールだらけになってしまい、自由に柔軟に動けなくなるからです。ミニマムのリスク管理を行うようにしたいものです。
大型プロジェクトになると、PMOは年齢も経験値も役割分担もまるで違うメンバーをまとめ上げる必要があります。役割分担というと以下のような役割表や体制表をイメージするかたもいらっしゃると思います。
PJオーナー 高橋部長
PM 佐藤さん
PL 鈴木さん
メンバー ○○さん、他多数
もし、これを役割分担と認識している場合は、あなたに大規模プロジェクトの推進は難しいです。このような場合、「役割は定義されていない」に等しいからです。
また、こんな場合ではどうでしょう。
発注者(お客様、事業会社) X社
****社内システム刷新PJ PM 中山さん
A社 アプリ開発ベンダー PM 田中さん
B社 基幹システムベンダー PM 小泉さん
C社 会計システムベンダー PM 林さん
このように3社が入ってプロジェクトを進めていく場合、A〜C社それぞれの役割分担は当然決まっています。しかし、A~C社間の情報共有や進行管理はいったい誰が行うのか、あるいは相互に連動して制作をしなければならないフェーズに差し掛かった時の調整は誰が行うのか?という問題が発生します。こうした具体的な役割を、実際プロジェクトがスタートする前に予め明確にしておきましょう。そうすることで作業時間や工数をロスすることなく作業を進めることができます。
コツ3で、「役割の内容を明確にする」ことに言及しましたが、実は役割分担の中には「見えないもの」が存在します。それが「プロジェクトに対する熱量」です。熱量、というよりも「不安や不満」といったほうが正しいかもしれません。
例えば、Aさんは「アプリ開発に集中したい」と思ってこのプロジェクトに入っています。しかし、本心ではこんなことを考えています。
「このプロジェクトって、予算とか契約は取れてるのかな?」
「そもそもこのアプリって日の目を見るんだろうか?」
「お客様のためになると言われているけど、本当かな?」
さらにトラブルが発生すると、こんなことを考えてしまいます。
「上からはただ作業しろって言われてるけど、どうせリリースされないんでしょ?」
「予算消化でやってるものなんでしょう?」
これらは、自分一人で、あるいは近しい仲間と話すときにだけ語られる本心であってプロジェクトメンバー全体の前では決して出てこないことです。しかし、こういったマインドのまま作業を進めていると、まず間違いなくプロジェクトはうまくいきません。「疑問や不安を持っている状態で仕事をする」ことでパフォーマンスが圧倒的に落ちるからです。
だからこそ、PMOは「メンバーを不安にさせないようにする」「迷わないルールづくりをして、それを仕組み化し浸透させる」あるいは、何か予期しない出来事が起こってもその理由を必ず話して安心させる。細かいですが、こういったことを積み重ねて「本来の業務に集中させる」必要があるのです。
これまでさまざまな大型プロジェクトに携わらせていただきましたが、まさにプロジェクトは「生き物」。一つとして同じプロジェクトはありません。さらに、長期にわたってプロジェクトを行っていると、最初は必要性を感じて作ったものでも、「いらないルール」や「メンバーにマッチしないルール」も発生してきます。
例えば、今までは進行状況を当初作成したテンプレートの項目に沿って記載し管理していたものの、次第に項目の内容が足りなくなり、一つの項目に複数の内容を記載するメンバーが増えてきた。こんなときは、テンプレートの項目や記載方法を見直します。
本来達成すべき目的を見失わず、ルールは都度変更していく、という柔軟性がとくに重要なのです。といってもやみくもに変えるわけではありません。
ルール変更にはこのようなフェーズをたどります。
1.ルールスタート
2.その通りにやらない人たちが出てくる
3.実態に合わないと感じる
4.全体会議
5.ルール変更
この現状に合ったルール変更が大事なのは、業務をスムーズに進めることのほかに、メンバーに「あ、ルールは絶対ではなく柔軟に変わるんだ」「何か問題を感じたら、言ってもいいんだ」というマインドを持ってもらうためでもあります。
もちろん、「言えば何でも通る」わけではありません。とはいえ、いつも毎日正しく頑張っている人をサポートし、本来の業務に集中していただくことがPMOの役割であり、それが大型プロジェクト成功の何よりの近道だと感じています。
今回は、PMO目線で「大型プロジェクトを成功させる五つのコツ」をお伝えしてきました。イメージしやすい五つをご紹介しましたが、当然コツはこれだけではありません(これだけで成功できたら私も嬉しいです)。
大切なのは、現場で業務を行うメンバーのみなさんが正しく頑張れること。私は常にそう思っています。これはPMOに限らず、プロジェクトに関わるすべてのメンバーが持っておきたい意識です。ぜひ、エンジニアのみなさんにも1~5までのコツを心にとめおいていただき、現在のプロジェクト、これから携わるプロジェクトに少しでも活かしていただけたら幸いです。
『DX時代の最強PMOになる方法』
著:甲州潤
▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい
【目次】
第1章 一番稼げるIT人材は誰か
第2章 これからはPMOが1プロジェクトに1人必要
第3章 SEとPMOの仕事は何が違うか
第4章 稼ぐPMOになる7つのステップ
第5章 優秀なPMOとダメなPMOの見抜き方
第6章 PMOが最低限押さえておきたいシステム知識とスキル
第7章 システムは言われた通りに作ってはいけない
第8章 どんな時代でも生き残れる実力をつけよう
>>>詳細はこちら
NEW!
NEW!
NEW!
タグ