inayamafumitaka’s official diary

東葛飾PM&A研究所/プロジェクトマネジャ保護者会/プロジェクトマネージメント/人材育成・研修/執筆/書評・・・執筆・講演をお受けします。Twitter(@inayamafumitaka)のDMでコンタクトしてください

システム開発に契約知識を

良い問題提起のエントリなので勝手ではありますが、ちょっとフォローを。

 

brevis.exblog.jp

最初の引用。ベンダは一括請負で赤字プロジェクトの対策として契約を分割するようになった、その後です。

ここで問題になるのが、準委任契約のあり方である。一般に、IT開発の最初の要件定義と、最後の総合テストないし運用テストは、準委任契約で行われることが多くなった。最後のテストでは、かかる工数が発注者側の運用環境に依存するし、また既存のレガシーシステムとのインタフェース・テストなども含まれることが多い。だからここを準委任でやること自体は一見、適正なことに思われる。ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。 

 ←要件定義(準委任)→←基本設計〜総合テスト(請負)→←受入テスト(準委任)→

と契約分割するようになった、とあります。これは経産省からも研究会のレポートが出ていますね。

「情報システムの信頼性向上のための取引慣行・契約に関する研究会」

ところが、ここで交わされる準委任契約が、ともするとITベンダー側に非常に都合のいいようにできているという。 

 ここで、そうかなぁ、と思うのです、はい。

で、読み進めると、

 

たとえば、瑕疵担保責任の所在である。実装は一括請負だが、ユーザにとって納品物を受け入れるかどうかは、最後のテストの結果を見て判断することになる。ところがそこは準委任契約だから、成果物に責任はありません、というケースがあるらしい。何かバグが見つかって直す必要があったら、ユーザがお金を払わなければならない。これでは実装の品質が低ければ低いほど、ITベンダーは収入が増えるというおかしなことになる。それに、納期の問題だ。準委任だから、完成義務はない、納期は保証しません、という。 

「というケース」とあるのでそういうケースもあるようです。ただ、これは2社間での契約の問題、という感じが一見しますが、実はエンドユーザ側のプロジェクトマネジメント力の問題を提起しているのではないか、と見ることもできます。

 

先の、工程別契約を見やすいように分割します。

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任)

 エントリのケースを当てはめると

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任) ←ここでバグが出る

受入テストでバグが出ても準委任だから成果物に責任がない、とケースに出てくるベンダは主張されてエンドユーザは困っている、と。

それ、受入テストでのバグの起因となった工程を特定するなどの品質管理の中でコントロールをエンドユーザ側ができていない、ということなのでしょう。

要件定義(準委任)
基本設計〜総合テスト(請負)
受入テスト(準委任) ←ここでバグが出る ←バグの起因はどこか

バグの起因が基本設計〜総合テスト(請負)の中であれば、修正する義務が発生します。これが要件から漏れていたのであれば、エンドユーザ側に起因することになります。

ただ、プロジェクトマネジメント力があるベンダであれば、基本設計〜総合テスト(請負)の各工程の中で、要件からの抜け漏れがないかを次工程に突入する前のcriteriaとしてゲートを設けているはずなので、ある意味、受入テストまで進んでから機能漏れとならないように防止する歯止めをプロセスとしてかけているものです。

 

もうひとつ。準委任における責任に曖昧さが生じるか、です。

もう一つ問題の所在となるのは、System Engineering Service(略称SES)とよばれる契約形態である。これはIT会社の元請けから、下請け会社にSEを配員してもらうために発注するサービスだが、準委任契約の業務委託になっている。しかし、その実態は派遣契約にきわめて近い。IT業界は知っての通り多重下請け構造なので、SESの再委託もある。準委任の準委任という訳だ。どこの誰に責任があるのかさっぱり分からなくなる。

なんとなく、解は書かれているように思えるのですが、

 

ところが、海外企業との実費償還契約というのは厳しいのだ。まず、プロジェクトへの配員は、顧客が経歴書を審査し、きちんとした経験・能力が認めることが条件だ。勝手に協力会社の人間をアサインするなど、もってのほか。また一旦、配員されても、仕事ぶりの質が低いと、欠格として解任(Disqualify)されてしまう。働いた時間に応じて対価が払われるが、毎週タイムシートを顧客に提出し、チェックと承認を受ける必要がある。出張も外出も、顧客の事前の承認がいる。

法律との兼ね合いでどこまでできるかは別として、エンドユーザ側は、プロジェクトとして必要なスキルセットとスキルレベルを満たすリソースを契約条件に示せばいいのではないか、と。

請負なら、ベンダは契約を履行するためにそうするでしょう。請負での曖昧さはベンダとサブコン間のリスクです。
#そうしないと赤字になるので。

ただ遠回りにはプロジェクト全体としてはエンドユーザに影響はしますが、それで履行されてないのであれば、ベンダが問われるだけでは、と。

では、準委任でどうするか、ですが、ここはエンドユーザ側が主体の工程になるので、工程に必要なスキルセットとスキルレベルを持つリソースを提供することをベンダに求めるのかと。

その上で、プロジェクトの工程管理をするだけではないかと思うのです。それをベンダに丸投げしてはいけないという教訓かと。

 

 契約関連は、この本の付録を参照していただけると幸いです。