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




























大手のグルーブ会社のシステム会社に新卒で入社しました。
そこで2~3年ほど働いてから、開発がしたかったのでSESがメインの会社に就職しました。もうひたすら色々作り上げてきました。
それで今も開発エンジニアとして活動してます。















エンジニアとは?
システムエンジニアは、専門職として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の危険性


















そのせいでエンジニアとお客さんの間にすれ違いができちゃって稼働が高くなる。
もはやエンジニアが聞いた方が早いんじゃないか?とも。















エンジニアからすると現場の声を無視して無茶を言ってる、となるし、お客さんからしても念押しした納期がなぜ守れないんだろう?となる。






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












実際それで炎上して降格されちゃってました。
発言のまとめ
・エンジニアの質問に答えようとしないPMOは無意味なやり取りを繰り広げてしまうおそれがある。
・顧客の要望を正確に伝えられないPMOは、エンジニアと顧客の間の認識齟齬を起こしてしまい、プロジェクトの遂行を停滞させてしまうおそれがある。
PMOには正確な情報伝達ができるという意味でのコミュニケーション能力が必須で、
- エンジニアとの有意義なやり取りができないとプロジェクトの期間中に時間の損失を産み出してしまい、
- 顧客とエンジニアなど現場側の人々のコミュケーションの仲介を円滑にできないとプロジェクトにおいて思わぬトラブルを生じてしまいかねません。
現場の技術的知見が全くないPMOの危険性



これは個人的に一番大きいと思ってます。何ならさっきのコミュ力の問題も技術的な知見がないから上手く理解できてない。
そうなるとPMOが分からないことがたくさん出てきて現場側にもプロジェクト側にも上手く情報の正確な伝達ができずにコミュニケーションが上手くいかないことがあります。
関連記事:【IT業界の闇】開発工程未経験のPMOは終わってます…【ITエンジニア・ITコンサルタント必見】



外部設計書レベルのことは言えるようにならないと上手く話せないだろうなとは思います。






しかもその僕のチャット内容をそのままお客さんに渡すっていう。むしろ僕がお客さんへのメールの添削をする羽目になる。



開発経験が全くなくて 現場を分かってない人は何もできないです。
発言のまとめ
・プロジェクトに関する現場側の技術的知見を一切理解していないPMOはプロジェクトの内容の理解もできず、その結果顧客に対するプロジェクトの報告や現場側の人々に対する顧客の要望の伝達も上手くできない。
PMOにはプロジェクトにおける現場側の技術的知見を概要程度でも知っておくことも必須で、
- 技術的背景への理解がないことでプロジェクトの内容への理解も不足し、顧客と現場側の人々の現状も上手く汲み取れずプロジェクトに関係する人々の間のコミュニケーションが機能しなくなるおそれがある。
プロジェクト上の判断を現場側に全部丸投げするPMOの危険性



ここまで挙げてきたのは僕の実体験です。さっきのメールの添削してたのも、僕がエビデンス作って 「これで送ってください」って。
関連記事:【アクセンチュア】ITコンサルタントの方へ、なんちゃってPMOになっていませんか?【支援型】















最近もありました、要件定義見てみたら「違うところあるんじゃない?」ってなって全然詰まってなかった。
こちら側のQA表が50とかになって。
スケジュール的には押しに押して製造期間というのかコーディングとか単体テストをやれる期間が2週間ぐらいだった。






発言のまとめ
・PMOに技術的知見がないことで、本来システム開発をする立場のエンジニアが顧客へのメールを考える羽目になったという事例もある。
PMOの技術的知見への理解の欠如はプロジェクトの進行に直接的に悪影響を及ぼすこともあり、
- 技術的背景が分からなければプロジェクトに関する判断の大部分をエンジニアに委ねてしまうことになり、エンジニアの元々の業務遂行を妨げてしまいかねません。
請負契約と準委任契約の違いを把握していないPMOの危険性



これは色々炎上案件を経験したことがありまして、誰が悪いんだって話になるんですよ。
悪者探しが始まる中で請負契約と準委任契約の違いが重要になってきます。



民法を参考にお話しします。
請負契約は民法632条を参考にすると、「当事者の一方がある仕事を完成することを約し、相手方がその仕事の成果に対して報酬を支払う」ということになります。
つまり仕事を完遂することに対しての結果として報酬を支払うことを契約とする、ということです。この場合もし仕事が失敗したなら報酬は発生しません。



委任契約は民法643条を参考にすると、「委任は当事者の一方が法律行為をすることを相手方に委任し、相手方がこれを承諾することによってその効力を生ずる」ということになります。



準委任契約は何を言ってるかというと、「この作業をするということに対して報酬を支払う契約」です。






成果完成型は請負契約と似てるんですけど、成果を達成できなかった場合のリスクがあります。ただ請負よりは軽くなります。
履行割合型は僕らエンジニアのSESの形態と全く一緒です。
請負契約とは?
民法632条には、
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
と記してあります。
つまり請負契約の当事者は、
- 完成するべき仕事に取り組む人物
- 契約相手が仕事を完成した場合に報酬を支払う人物
の二通りに分かれます。
請負契約において仕事が完成しなかった場合、仕事を完成するべきだった人物は債務不履行責任を負うことになります。
債務不履行責任が発生した場合、仕事を完成できなかった人物は契約相手に対する損害賠償を行うことがあります。
委任契約・準委任契約とは?
民法643条には、
委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
と記してあります。
つまり委任契約の当事者は、
- 契約相手に法律行為の委託を行う人物
- 契約相手の委託を承諾した上で法律行為を代行する人物
の二通りに分かれます。
法律行為とは、当事者の意思表示によって法律効果(法律に基づく権利や義務の発生)をもたらす行為です。
委任契約は無償であることが前提となっていて、報酬を発生させたい場合はまた別に特約を加える必要があります。
そしてこの委任契約に関連する形で、民法656条は、
この節の規定は、法律行為でない事務の委託について準用する。
と記してあります。
これが準委任契約であり、その当事者は
- 契約相手に事務の委託を行う人物
- 契約相手の委託を承諾した上で事務を代行する人物
の二通りに分かれます。
準委任契約は成果完成型と履行割合型の二種類に分かれていて、
- 成果完成型では契約相手の事務を代行する人物が成果物を納品することで報酬が発生し、
- 履行割合型では労働力・労働時間を割いて委託された事務に従事することで報酬が発生します。
準委任契約に関してはどちらの場合も仕事を完成する義務はありません。
準委任契約の債務不履行責任は善管注意義務(職業・地位に応じて通常の範囲で注意を払う義務)に対する違反によって成立し、報酬が発生する条件を達成できなかったことは関係しません。
この点で成果完成型の準委任契約は、仕事を完成する義務を前提とした請負契約とは異質な形の契約です。



例えばPMOと現場側が別々の会社だった場合、PMOが直接指揮命令するっていうのは契約的にアウトなんですが、実際の現場ではめちゃくちゃあります。結構グレーな感じでみんなやってます。






結果は僕も少し注意されるくらいでした。あくまで「開発責任者を通して」やるべきだと。
実は開発者とPMOの仲が悪かったせいで、エンジニアにもそのしわ寄せが来てたってことでした。
そういうところも全く分からない人と仕事するのはちょっと辛いなと思ってしまいます。



だから派遣の方がやりやすいってことで派遣契約に持ち込もうとする人もいます。
ただ派遣は派遣する人に免許が必要ですから、派遣免許のない多くのIT企業はSESで済まそうとする。そうなると指揮命令権が現場になくて、いざこざが起こるケースも出てくると…。
この辺りはなあなあで済ませてるところが大きくて、いずれ厚生労働省が本気で規制する気になったら取り締まりがかなり厳しくなると思います。
発言のまとめ
・プロジェクトが炎上した際に原因は誰にあったかを突き止める場合があり、その際に請負契約と準委任契約の違いが問題になる。
・請負契約と成果完成型の準委任契約では程度は違うものの契約違反の際にはどちらもペナルティが発生する。
プロジェクトが残念ながら炎上した場合には、
- 原因究明の際にプロジェクト自体が請負契約か準委任契約かという違いが問題になることがあり、
- 請負契約や成果完成型の準委任契約ではプロジェクト未達成が契約違反にあたり、ペナルティが発生してしまいます。
クライアントの言いなりになっているPMOの危険性



よくいるんですよね、クライアントや別部署の無茶な要求を全部飲んじゃうイエスマンみたいな人。それで結局無茶なスケジュールやタスクを求められることがたくさんあります。






発言のまとめ
・たとえ無茶なものでもクライアントや別部署の要求を全て飲んでしまうPMOは、無茶なスケジュールやタスクを設けて組織運営のバランスを乱すおそれがある。
クライアントや別部署の要求することを何でも承諾してしまうPMOは、
- プロジェクトにおいて人的・物的・時間的資源などのバランスを乱してしまうような結果を招きかねません。
コメント