プロジェクトマネージャーの善管注意義務と失敗しない発注のために
現役PMが以下記事を読んで、感想を書きます
筆者は自社開発の企業経験が長く受託開発の経験はゼロではないですが少ないです。そのためちょっと視座が違うかもしれません
発注側として外注をした経験は結構あるつもりです
判決には大納得
書いている内容を見てまず思ったのは、これでベンダに責任あるって言われたらマジできついなと思ったので良かったなという感じです
一方で発注側のやり方もよく見るやり方なので、発注側もちょっと知識をつけてやり方変えれば回避できたのではという気もしました
PMとしての責任の果たし方
特に学びがあったのはプロジェクトマネジメントにおける善管注意義務についての言及です
Ｘに対して本件仕掛品を送信して具体的な検討を促しており（前記１(7)，(8)），前記２において説示したとおり，かかる懸念及び意見はもっともなものであったと認められる。すなわち，Ｙは，本件ソフトウェアの仕様の作成はＸの役割であるとして，漫然と放置していたわけではなく，打合せを基に本件ソフトウェアの開発を進め，本件仕掛品を基にＸに必要な助言を行った上で，本件ソフトウェアの完成に向けた提案を行っていたと認められるのであり，プロジェクトマネジメント義務を果たしていた
個人的にPMの役割として大きな部分は仕様やスケジュールなど、とにかく合意形成をすることだと思っています
今回引用範囲にもPMとして今何やってて、このあとどうするかの合意形成を推進していたからプロジェクトマネジメント義務を果たしていたと解釈できる気がしました
思っていたよりITプロジェクトの受発注における責任範囲について、司法の見解は受託側に寄っているんだなと思いました
発注側が無邪気にノーリスクを求めすぎ？
Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定しておりません。請負契約というよりは準委任契約をイメージしております。」と答え、Ｘは「2017年2月までに完成することが担保されていれば返金対応はなくても問題ない」
このようなやり取りは昔から散見しますが最近特に増えている気がします
仕様が決まっていない状態で走り出しておいて納期だけは決まっていたり、役務提供である準委任契約でありながら成果物責任を求めたいというケースです
個人的にはこのような外注を活用したアジャイルベースの進め方自体は問題がなく、これから増えるだろうとは思っています。ただ、発注側が請負の責任を求めるのは無理筋だと思っていましたし、今回の判決でもそのように理解できました
請負と準委任の違い
受託側の視点で見ると、請負契約には製造物に対しての責任があります。納期や品質が受入基準に満たなそうな場合、持ち出しで人員追加や残業などで納期を守るアクションを取ったり、品質未達の場合納期後も改修をする必要があったりします
反面準委任は役務の提供で時間での稼働を約束するため契約リスクが低く請負の案件に比べると単価が安くなります
発注側の視点で見ると当然、納期や品質は担保してほしいので請負での契約をしたいと思います。ただし請負での契約をするためには仕様を決め、何を作るか、どういう品質で受け入れるかを細かく決める必要があり費用以外のコストも大きいです
また受託側の心理を考えると期間がバッファモリモリになるか費用も保険的に高く積まれる可能性が高いです
そのため準委任のコストで請負の責任で発注したいと思うのは、良い悪いはともかく自然ではあります
今回の場合、発注側が意図的に有利な契約を結ぼうとしているのか契約に無知なのかは不明です。いずれにしても発注側が仕様や品質基準をまとめないけど発注側がなんとなく想定したアウトプットを納期までに出してもらおうとするとこういう発注をしようとします
仕様未策定から始まる"偽"アジャイル
基本的に小さい規模の開発の場合、仕様をきちんと決めたり請負案件で発生するバッファを考えると内部コスト含めて見合わないケースも多いと思います
そのためまず走り出したい発注側としては、アジャイルという表現をしていなくても準委任契約でアジャイルライクに進めることが増えてきていると思います
ただこれは本来発注側にかなりのITリテラシを求められる進め方だと思っています。機能を落としたりリリース日を変更することもあるため社内の調整コストも本来高いはずです
仕様が決まっていなくても決めながら開発を進められる
途中の仕様変更が容易
納期の予測がたつ
アジャイルについて上記のようないい面をなんとなくで理解していると、この記事のような発注になるんだろうなという感じがします
アジャイルでノーリスクは嘘
システム開発において銀の弾丸はありません。アジャイルで何でも解決できると思っている人がもしかしたらいるかもしれません
アジャイルはウォーターフォールよりも仕様変更時のリスクを抑えるケースが多いですが、０にするわけがないです
アジャイルでも仕様策定は必要です。例えばスクラムではスプリント０として実際に開発に入る前に３スプリント分のタスクと受け入れ条件を整理するなどします。あくまで走りながら仕様策定を小出しにできるだけです
途中の仕様変更をしても手戻りがなくなるわけではないので余分に工数がかかりますし、納期の予測がたつのも最初からたつわけではなく、同じチームで一定期間開発を進めてちゃんと計測している場合だけです
結局発注側は仕様や優先度を決める必要があります。リリースを優先するなら機能を落としたり、機能を優先するならリリースを伸ばしたり、あるいは人員追加のための追加コストを払う必要が出ます
発注側はどうすれば良かったか
発注側がITリテラシーを高める必要があるでしょう
つまり、ある程度の仕様策定ができて大体の工数感がわかって、その上でQCDコントロールができる内部統制がされている必要があるかなと思います
PMを内部で調達する
PMを採用する、あるいは外注先のPMに要件定義などをもっとお願いするしかないでしょう
内部にエンジニアがいる場合PMとしてアサインできれば少しは良いと思います。ただし、仕様策定はエンジニアでできると思いますが、要件定義や要求定義、ベンダーコントロールなどはエンジニアでも経験がない人も多いですし、得意不得意が分かれる分野かと思います
ただし、内部でITやプロジェクトマネジメントが全くわからない状態で外注先のPMを信じ切るのは、よほど取引が長いとか信頼がある外注先じゃない限りぼったくられるリスクもあり得るのは注意が必要です
適当な発注をしない
期の切り替わりで予算消化のために外注人月だけ確保する
仕様や要件は決まっていないけど納期は決まっているから発注だけ急ぐ
筆者の経験でも上層部からこういった依頼が時々有りました。何を作るか具体的に決まっていないのに「発注はしておいたからよろしく」と結構軽く言われたケースがあります。発注側としてこのような案件でPMをするのは正直かなり大変です
これらは内部に開発がある程度わかって内部調整もできるPMがいて初めてなんとかなるやり方です。気をつけましょう
自社のプロジェクトとして適切にリスクやコストを許容する
今回の事例や上記のように、受託側は多少なりともITプロジェクトのプロなので、適当な受注をして自社がリスクを受けないような立ち振舞に発注側に比べて慣れています
受託側に任せればうまくいくと思わずに自社でうまくいくためにどうすればいいのか理解したうえで発注する必要があるでしょう
大体の場合でリスクを許容するかコストを受け入れるかの二択になるのかなとは思います
まとめ
真っ当なPMであれば善管注意義務を果たせないケースはかなり少なそうに見えました
そのため、発注側はITやプロジェクト管理のことを全然わからない状態で発注していい感じにモノができるという期待をするのはかなりリスキーだなと思います
そのような期待を捨てまずは内部できちんとプロジェクト管理や上流工程を実施できる体制や組織づくりを進める必要があるでしょう
お知らせ
twitter しています。良ければフォローしてください
https://twitter.com/esueichi94
思ったこと結構あったので感想として投稿しました。
— esueichi (@esueichi94) October 21, 2024
プロジェクトマネージャーの善管注意義務と失敗しない発注のために｜esueichi @esueichi94 #note #PMの仕事 https://t.co/LjtHloG1KT