概要
この記事では、現役アプリエンジニアのジン氏が自身の経験した実例を挙げながら、システム開発に携わるPMOには欠かせない要素を紹介していきます。
太田フランクリン
みこみこ
やま
ジンジンみこみこジンみこみこジンジン大手のグルーブ会社のシステム会社に新卒で入社しました。
そこで2～3年ほど働いてから、開発がしたかったのでSESがメインの会社に就職しました。もうひたすら色々作り上げてきました。
それで今も開発エンジニアとして活動してます。
ジン太田フランクリンやまみこみこジン記事の前提としてエンジニアと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条には、
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
と記してあります。
つまり請負契約の当事者は、
- 受注者として完成するべき仕事に取り組む人物
- 発注者として契約相手が仕事を完成した場合に報酬を支払う人物
の二通りに分かれます。
請負契約における報酬の発生条件は、仕事が完成し成果物が出来上がることです。
具体的には受注者が発注者に成果物の引き渡しを行う際に発生します。
請負契約において、受注者は契約通り仕事を完成する義務を負います。
もし受注者が仕事を完成できなかった場合、受注者には発注者に対する債務不履行責任が発生することになります。
債務不履行責任が発生した場合、受注者は発注者に対する損害賠償を行わなければならないことがあります。
また受注者が引き渡した成果物の内容に問題がある場合、受注者は発注者に対して契約不適合責任を負います。
民法562条では契約不適合責任について、
引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。
と定めてあります。
請負契約の場合、発注者は
- 受注者に成果物の問題点を修正させること
- 受注者に成果物の不足点を補わせること
- 受注者に支払う報酬を減額すること
- 受注者に対して損害賠償請求を行うこと
が可能となります。
請負契約では発注者は受注者が仕事を完成するまでの間に契約を解除できます。
その場合、発注者は受注者に損害賠償をしなければなりません。
委任契約・準委任契約とは？
民法643条には、
委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
と記してあります。
つまり委任契約の当事者は、
- 契約相手に法律行為の委託を行う人物
- 契約相手の委託を承諾した上で法律行為を代行する人物
の二通りに分かれます。
法律行為とは、当事者の意思表示によって法律効果(法律に基づく権利や義務の発生)をもたらす行為です。
委任契約は無償であることが前提となっていて、報酬を発生させたい場合はまた別に特約を加える必要があります。
そしてこの委任契約に関連する形で、民法656条は、
この節の規定は、法律行為でない事務の委託について準用する。
と記してあります。
これが準委任契約であり、その当事者は
- 発注者として契約相手に事務の委託を行う人物
- 受注者として契約相手の委託を承諾した上で事務を代行する人物
の二通りに分かれます。
準委任契約は成果完成型と履行割合型の二種類に分かれていて、
成果完成型では、
- 受注者が委託された事務を代行することによって成果が生まれることが報酬の発生条件となり、
- 具体的には受注者が成果物の引き渡しを行う際に報酬が発生します。
履行割合型では、
- 受注者が労働力・労働時間を割いて委託された事務に従事することが報酬の発生条件となり、
- 具体的には委託された行為を完了した際に報酬が発生します。
準委任契約に関してはどちらの場合も仕事を完成する義務はありません。
準委任契約の債務不履行責任は善管注意義務(職業・地位に応じて通常の範囲で注意を払う義務)に対する違反によって成立し、報酬が発生する条件を達成できなかったことは関係しません。
準委任契約においては発注者と受注者のどちらも任意のタイミングで契約を解除することができます。
一方の当事者が相手に不利な形で契約解除を行う場合は相手に対して損害賠償をしなければなりません。
ジン例えばPMOと現場側が別々の会社だった場合、PMOが直接指揮命令するっていうのは契約的にアウトなんですが、実際の現場ではめちゃくちゃあります。結構グレーな感じでみんなやってます。
太田フランクリンジン結果は僕も少し注意されるくらいでした。あくまで「開発責任者を通して」やるべきだと。
実は開発者とPMOの仲が悪かったせいで、エンジニアにもそのしわ寄せが来てたってことでした。
そういうところも全く分からない人と仕事するのはちょっと辛いなと思ってしまいます。
みこみこだから派遣の方がやりやすいってことで派遣契約に持ち込もうとする人もいます。
ただ派遣は派遣する人に免許が必要ですから、派遣免許のない多くのIT企業はSESで済まそうとする。そうなると指揮命令権が現場になくて、いざこざが起こるケースも出てくると…。
この辺りはなあなあで済ませてるところが大きくて、いずれ厚生労働省が本気で規制する気になったら取り締まりがかなり厳しくなると思います。
発言のまとめ
・プロジェクトが炎上した際に原因は誰にあったかを突き止める場合があり、その際に請負契約と準委任契約の違いが問題になる。
・請負契約と成果完成型の準委任契約では程度は違うものの契約違反の際にはどちらもペナルティが発生する。
プロジェクトが残念ながら炎上した場合には、
- 原因究明の際にプロジェクト自体が請負契約か準委任契約かという違いが問題になることがあり、
- 請負契約や成果完成型の準委任契約ではプロジェクト未達成が契約違反にあたり、ペナルティが発生してしまいます。
クライアントの言いなりになっているPMOの危険性
ジンよくいるんですよね、クライアントや別部署の無茶な要求を全部飲んじゃうイエスマンみたいな人。それで結局無茶なスケジュールやタスクを求められることがたくさんあります。
みこみこジン発言のまとめ
・たとえ無茶なものでもクライアントや別部署の要求を全て飲んでしまうPMOは、無茶なスケジュールやタスクを設けて組織運営のバランスを乱すおそれがある。
クライアントや別部署の要求することを何でも承諾してしまうPMOは、
- プロジェクトにおいて人的・物的・時間的資源などのバランスを乱してしまうような結果を招きかねません。
みんなの意見
【地獄からの復活82】主導権争いをしたかったわけではない。「現場発」の改革を進め、「現場目線」を根付かせたい。PMOも現場のため。現場が強くなることがクライアントの利益。履き違えてもらっては困る。同時に、我々のなかにある「お客様言いなり主義」を払拭したかった。#pmo0310
— 高野 和之 (@kazu_takano_j) March 25, 2010
コメント