【一度は遭遇】現役アプ゚リエンジニアから見たク●PMOの特徴5選【元アクセンチュア】


概要

この記事では、現役アプリエンジニアのジン氏が自身の経験した実例を挙げながら、システム開発に携わるPMOには欠かせない要素を紹介していきます。

太田フランクリン
太田フランクリンです。
みこみこ
みこみこです。
やま
やまです。
ジン
ジンです。
ジン
今日は僕がメインで進行させていただきます。
みこみこ
ジンさんはエンジニアとのことですが、今日のお題は何ですか?
ジン
エンジニアから見たひどいPMO5選です!
みこみこ
管理してる人が適当だと困りますよね、「何とかなる」って言って結局ならないっていう。
ジン
皺寄せは全部エンジニア・現場に来ますからね。
ジン
始めに話を進めていく僕の自己紹介をします。
大手のグルーブ会社のシステム会社に新卒で入社しました。
そこで2~3年ほど働いてから、開発がしたかったのでSESがメインの会社に就職しました。もうひたすら色々作り上げてきました。
それで今も開発エンジニアとして活動してます。
ジン
エンジニアから見たひどいPMOということで、そもそもエンジニアとPMOが関わりあるのかって疑問があると思うんですが、実際のところどうですか?
太田フランクリン
かなりありますね。毎日だったり毎回と言ってもいいぐらい。
やま
僕はPMOじゃないですけどよく関わります。
みこみこ
僕はエンジニア経験から言えば関わってました、開発分かってないPMOはダメだと言ってましたね。口が上手くて出世する人もいるけど、そういう人はボロが出ます。やっぱり現場を知ってないといけない。
ジン
僕も同感ですね。

エンジニアとは?
システムエンジニアは、専門職としてITシステムに関する企画・設計・開発・運用そして保守といった業務に従事します。

システムエンジニアの業務には次に挙げるようなものがありますが、他にも様々な業務があります。

  • 要求分析
    顧客の要望を聞いて、どのようなシステムを提供することが望ましいのかを分析し、それを文書の形にまとめる作業です。
  • 要件定義
    顧客の要求を満たせるように、システムの具体的な機能・性能・品質などを取りまとめ、システム開発の具体的な業務内容やシステム開発で進める作業の範囲を策定する作業です。
  • システム開発
    システムのアーキテクチャ(システムの全体的な構造とその設計方法)の策定や、システムにおけるそれぞれのコンポーネント(システムを構成する個々の要素)の関係などといったことを設計していく作業です。
  • 運用と保守
    システムの正常な動作を目的とする、パフォーマンスモニタリング(システムの性能を監視して問題点に対して早急に対応すること)・トラブルシューティング(システム上の問題の原因の究明やその解決)・バックアップ管理、などを行う作業です。

エンジニアについての別記事はこちらです。

【悲報】フルスタックエンジニアはオワコンです!

PMOとは?
PMOはProject Management Office(プロジェクト・マネジメント・オフィス)という言葉の頭文字を取った略称で、プロジェクトの実行にあたって組織のプロジェクトマネジメントの支援を行う役割を持つ部門を意味します。

PMOは多岐にわたる業務に従事しますが、その内容はPMOの種類によって分かれます。
PMOの種類は3種類あって、支援型PMO・管理型PMO・指揮型PMOがあります。

支援型PMOはプロジェクトのサポート業務を担当し、具体的には議事録やマニュアルなどプロジェクト関連の文書の作成や窓口業務での対外的な応対などを行います。

管理型PMOはプロジェクトの進行状況に関する管理業務を担当し、具体的にはプロジェクト内で用いるツールの指定やプロジェクトの進捗管理やプロジェクトのリスク管理などを行います。

指揮型PMOはPMO全体に関わる管理業務を担当し、具体的にはプロジェクト管理についてのルールの作成および改善やプロジェクト達成を目的とする組織の戦略立案などを行います。

PMOについての別記事はこちらです。

【ITコンサルタント】PMOとは?やりがい・オススメ度を現役PMOに聞いてみた!

【アクセンチュア】ITコンサルタントの方へ、なんちゃってPMOになっていませんか?【支援型】

エンジニアとPMOの比較
エンジニアはプロジェクトの中でも、システムに関して企画・設計・開発・運用などといった直接的な関わり方をします。

PMOはプロジェクトの中で、サポート業務・進捗管理業務・管理業務のルール作成などといった円滑な組織運営を目的とした組織マネジメントを行います。

PMOがプロジェクトの大枠を整備して、エンジニアはその環境の中でシステム開発に直接従事する、というのが理想的かつ本来的な組織のあり方になります。

目次

1.正確なコミュニケーションを図る能力がないPMOの危険性

ジン
今回の本題のひどいPMOの特徴に入っていきます。まずは当たり前すぎる話ですけど、コミュ力が低い
みこみこ
コミュニケーション能力が低いと言う時に、どんなことをコミュニケーション能力と言うんでしょうか?
やま
定義ですね。
ジン
例えば質問に答えてくれない人。「○○ですか?」と聞いても欲しい答えが返ってこない。
太田フランクリン
はぐらかしてくる人もいますよね。「ちょっと分からないねー」って、何も的を得ない会話が延々と続いてく。
ジン
それと、PMOがお客さんとお話ししますよね。それで帰ってきてお客さんとのお話通りのことを言ってるつもりでも実は違う内容を話しちゃってたりする場合もあります。伝言ゲームに失敗しちゃってる。
そのせいでエンジニアとお客さんの間にすれ違いができちゃって稼働が高くなる。
もはやエンジニアが聞いた方が早いんじゃないか?とも。
太田フランクリン
PMOとしては個人的に一番心がけてるところですね。お客さんの要望をしっかりと受け取って伝える。ここを間違えると工数が激増しますからかなり大切です!
太田フランクリン
例えば同じ単語でも違う解釈をする人がいたりします。
やま
誤解の起きないように分かりにくい単語は使わなくていいんですよね。
みこみこ
社会人のコミュニケーション能力は正確な意思伝達ができることですね。
ジン
エンジニア・現場側の現状を把握して報告できてない。一方でプロジェクト側の現状も現場に上手く落とし込めてない。稼働が上がっちゃいます。
エンジニアからすると現場の声を無視して無茶を言ってる、となるし、お客さんからしても念押しした納期がなぜ守れないんだろう?となる。
ジン
そういうわけで現場側とプロジェクト側の両方のコミュニケーションが必要なんです。
ジン
認識齟齬で困った事例を挙げてみると、クライアントとPMOの間ではQA表をやり取りしてるんですよ。そのQA表を更新するってことをクライアントは言ったってなって、でも現場側てなくてPMOも認識してなかった。終盤になると「クローズしてないQA表がある」って積み残しがあることが分かって、設計書からやり直す羽目になるってことがありました。

プロジェクトにおいて、品質に関係するタスク・チェックポイントをまとめておき管理するためのツールをQA表といいます。

太田フランクリン
PKOが課題の棚卸しを忘れてしまうと後になるほど手戻りが大きくなる。
やま
言った言わないって問題はよくありますよね。
ジン
その対策としてQA表を使ってるのにそこを見落としちゃってる。
みこみこ
何とかなるでしょ」じゃダメなんですね。昔プレゼンスキルが高くて見せ方も上手だった人がいたんですけど、結局現場分かってなくて「いけるでしょ」って毎回僕に言ってましたねその人。
実際それで炎上して降格されちゃってました。

発言のまとめ

・エンジニアの質問に答えようとしないPMOは無意味なやり取りを繰り広げてしまうおそれがある。

・顧客の要望を正確に伝えられないPMOは、エンジニアと顧客の間の認識齟齬を起こしてしまい、プロジェクトの遂行を停滞させてしまうおそれがある。

PMOには正確な情報伝達ができるという意味でのコミュニケーション能力が必須で、

  • エンジニアとの有意義なやり取りができないとプロジェクトの期間中に時間の損失を産み出してしまい、
  • 顧客とエンジニアなど現場側の人々のコミュケーションの仲介を円滑にできないとプロジェクトにおいて思わぬトラブルを生じてしまいかねません。

現場の技術的知見が全くないPMOの危険性

ジン
二つ目です、現場の技術的知見が全くない。
これは個人的に一番大きいと思ってます。何ならさっきのコミュ力の問題も技術的な知見がないから上手く理解できてない。
そうなるとPMOが分からないことがたくさん出てきて現場側にもプロジェクト側にも上手く情報の正確な伝達ができずにコミュニケーションが上手くいかないことがあります。

関連記事:【IT業界の闇】開発工程未経験のPMOは終わってます…【ITエンジニア・ITコンサルタント必見】

ジン
僕みたいな現場のエンジニアからすると、システムのロジック全部分かってとは言わないけど、何をしてるのかっていう話はできるようになる必要があると思います。
外部設計書レベルのことは言えるようにならないと上手く話せないだろうなとは思います。
太田フランクリン
一回エンジニアからの信頼を失ったPMOはやっていけません。
ジン
よく分からないからQA表を出してって僕が求めたらそれに対して詳細な説明を個別チャットで要求されたり…「書いた通りだよ!?」と。
しかもその僕のチャット内容をそのままお客さんに渡すっていう。むしろ僕がお客さんへのメールの添削をする羽目になる。
みこみこ
めちゃくちゃあるケースですね。
開発経験が全くなくて 現場を分かってない人は何もできないです。

発言のまとめ

・プロジェクトに関する現場側の技術的知見を一切理解していないPMOはプロジェクトの内容の理解もできず、その結果顧客に対するプロジェクトの報告や現場側の人々に対する顧客の要望の伝達も上手くできない。

PMOにはプロジェクトにおける現場側の技術的知見を概要程度でも知っておくことも必須で、

  • 技術的背景への理解がないことでプロジェクトの内容への理解も不足し、顧客と現場側の人々の現状も上手く汲み取れずプロジェクトに関係する人々の間のコミュニケーションが機能しなくなるおそれがある。

プロジェクト上の判断を現場側に全部丸投げするPMOの危険性

ジン
三つ目いきたいと思います、全部丸投げ。
ここまで挙げてきたのは僕の実体験です。さっきのメールの添削してたのも、僕がエビデンス作って 「これで送ってください」って。

関連記事:【アクセンチュア】ITコンサルタントの方へ、なんちゃってPMOになっていませんか?【支援型】

みこみこ
何年目ぐらいの方でした?
ジン
プロパーだから正確には分かんないですが一応4~5年ぐらいはやってるんじゃないかなと。
やま
もはやPMOに対してPMOの役割果たしてますよね。
みこみこ
大きなプロジェクトだとPMOのPMOがいる場合もあるみたいですけど、その人はいらないPMOですね。
ジン
PMOならシステムの概要は話せるようになってほしいです。全然知識なかったらお客さんと要件定義なんてできないんじゃないの?と。
最近もありました、要件定義見てみたら「違うところあるんじゃない?」ってなって全然詰まってなかった。
こちら側のQA表が50とかになって。
スケジュール的には押しに押して製造期間というのかコーディングとか単体テストをやれる期間が2週間ぐらいだった。

太田フランクリン
リリースは決まってるからスケジュールを前に詰めよう、と…。
ジン
技術的なバックアップは全くしてない感じありました。

発言のまとめ

・PMOに技術的知見がないことで、本来システム開発をする立場のエンジニアが顧客へのメールを考える羽目になったという事例もある。

PMOの技術的知見への理解の欠如はプロジェクトの進行に直接的に悪影響を及ぼすこともあり、

  • 技術的背景が分からなければプロジェクトに関する判断の大部分をエンジニアに委ねてしまうことになり、エンジニアの元々の業務遂行を妨げてしまいかねません。

請負契約と準委任契約の違いを把握していないPMOの危険性

ジン
続いて、請負契約と準委任契約の違いを把握してないPMO。
これは色々炎上案件を経験したことがありまして、誰が悪いんだって話になるんですよ。
悪者探しが始まる中で請負契約と準委任契約の違いが重要になってきます。
ジン
そもそも請負契約と準委任契約とは何か?
民法を参考にお話しします。
請負契約は民法632条を参考にすると、「当事者の一方がある仕事を完成することを約し、相手方がその仕事の成果に対して報酬を支払う」ということになります。
つまり仕事を完遂することに対しての結果として報酬を支払うことを契約とする、ということです。この場合もし仕事が失敗したなら報酬は発生しません。
ジン
準委任契約もありますが、その前に委任契約というものがあります。
委任契約は民法643条を参考にすると、「委任は当事者の一方が法律行為をすることを相手方に委任し、相手方がこれを承諾することによってその効力を生ずる」ということになります。
ジン
準委任契約は「法律行為でない事務の委託について準用すること」です。民法656条を参考にするとそういうことになります。
準委任契約は何を言ってるかというと、「この作業をするということに対して報酬を支払う契約」です。
太田フランクリン
結果に対する確実性が高い場合は請負契約の方がコスパが高いように思います。
ジン
準委任契約にも二種類あって、成果完成型の準委任契約と履行割合型の準委任契約です。
成果完成型は請負契約と似てるんですけど、成果を達成できなかった場合のリスクがあります。ただ請負よりは軽くなります。
履行割合型は僕らエンジニアのSESの形態と全く一緒です。

請負契約とは?

民法632条には、
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
と記してあります。

つまり請負契約の当事者は、

  • 完成するべき仕事に取り組む人物
  • 契約相手が仕事を完成した場合に報酬を支払う人物

の二通りに分かれます。

請負契約において仕事が完成しなかった場合、仕事を完成するべきだった人物は債務不履行責任を負うことになります。

債務不履行責任が発生した場合、仕事を完成できなかった人物は契約相手に対する損害賠償を行うことがあります。

委任契約・準委任契約とは?

民法643条には、
委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
と記してあります。

つまり委任契約の当事者は、

  • 契約相手に法律行為の委託を行う人物
  • 契約相手の委託を承諾した上で法律行為を代行する人物

の二通りに分かれます。

法律行為とは、当事者の意思表示によって法律効果(法律に基づく権利や義務の発生)をもたらす行為です。

委任契約は無償であることが前提となっていて、報酬を発生させたい場合はまた別に特約を加える必要があります。

そしてこの委任契約に関連する形で、民法656条は、
この節の規定は、法律行為でない事務の委託について準用する。
と記してあります。
これが準委任契約であり、その当事者は

  • 契約相手に事務の委託を行う人物
  • 契約相手の委託を承諾した上で事務を代行する人物

の二通りに分かれます。

準委任契約は成果完成型と履行割合型の二種類に分かれていて、

  • 成果完成型では契約相手の事務を代行する人物が成果物を納品することで報酬が発生し、
  • 履行割合型では労働力・労働時間を割いて委託された事務に従事することで報酬が発生します。

準委任契約に関してはどちらの場合も仕事を完成する義務はありません。
準委任契約の債務不履行責任は善管注意義務(職業・地位に応じて通常の範囲で注意を払う義務)に対する違反によって成立し、報酬が発生する条件を達成できなかったことは関係しません。

この点で成果完成型の準委任契約は、仕事を完成する義務を前提とした請負契約とは異質な形の契約です。

ジン
あとこれにプラスして指揮命令件というのも結構シビアなんですよ。
例えばPMOと現場側が別々の会社だった場合、PMOが直接指揮命令するっていうのは契約的にアウトなんですが、実際の現場ではめちゃくちゃあります。結構グレーな感じでみんなやってます。
太田フランクリン
僕もPMOやってますが業務割り当てはOKなんです、指揮命令はダメですが業務割り当てなら問題ありません。
ジン
僕も一回「請負適正化の観点からそういうことはやめてください」「あった場合は報告してください」って言われて、報告したら面倒なことになりました。
結果は僕も少し注意されるくらいでした。あくまで「開発責任者を通して」やるべきだと。
実は開発者とPMOの仲が悪かったせいで、エンジニアにもそのしわ寄せが来てたってことでした。
そういうところも全く分からない人と仕事するのはちょっと辛いなと思ってしまいます。

みこみこ
指揮命令権について補足すると、派遣の場合は直接やってもいいんです。でも準委任契約だとダメです。
だから派遣の方がやりやすいってことで派遣契約に持ち込もうとする人もいます。
ただ派遣は派遣する人に免許が必要ですから、派遣免許のない多くのIT企業はSESで済まそうとする。そうなると指揮命令権が現場になくて、いざこざが起こるケースも出てくると…。
この辺りはなあなあで済ませてるところが大きくて、いずれ厚生労働省が本気で規制する気になったら取り締まりがかなり厳しくなると思います。

発言のまとめ
・プロジェクトが炎上した際に原因は誰にあったかを突き止める場合があり、その際に請負契約と準委任契約の違いが問題になる。

・請負契約と成果完成型の準委任契約では程度は違うものの契約違反の際にはどちらもペナルティが発生する。

プロジェクトが残念ながら炎上した場合には、

  • 原因究明の際にプロジェクト自体が請負契約か準委任契約かという違いが問題になることがあり、
  • 請負契約や成果完成型の準委任契約ではプロジェクト未達成が契約違反にあたり、ペナルティが発生してしまいます。

クライアントの言いなりになっているPMOの危険性

ジン
次はクライアントの言いなりになってるPMO。エンジニアの言い分なんか知ったことかと言わんばかりの人です。
よくいるんですよね、クライアントや別部署の無茶な要求を全部飲んじゃうイエスマンみたいな人。それで結局無茶なスケジュールやタスクを求められることがたくさんあります。
みこみこ
エンジニアに頼めば何とかしてくれるだろう」って考えなんでしょうね。見積もりが甘めな営業の方が割とよくやる印象です。
ジン
無理なものは無理なんですよね、技術的な事情や要員のレベルだったり納期やコストも全部理解してバランス取るのが大事だよねっていう話です。

発言のまとめ

・たとえ無茶なものでもクライアントや別部署の要求を全て飲んでしまうPMOは、無茶なスケジュールやタスクを設けて組織運営のバランスを乱すおそれがある。

クライアントや別部署の要求することを何でも承諾してしまうPMOは、

  • プロジェクトにおいて人的・物的・時間的資源などのバランスを乱してしまうような結果を招きかねません。

みんなの意見

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次