御用聞きSIからコンサルティングにシフトしたいだけなんでしょう
ITベンダーが事実上の一括請負でシステムを開発する従来のモデルでは、要件定義の不備や追加開発の費用をめぐるトラブルから逃れられない。ここにきて、ユーザー企業とITベンダーが協調できる仕組みをビルトインしたシステム構築の新たなビジネスモデルへの挑戦が始まっている。
伝統的なSIはもう限界
はじめに
また日経ITProか、って感じですねぇ。はてぶのコメントに書いたことが全部、って感じですが、ワタシが感じることが異常なのか、それとも一から十まで全部「一括請負にしているのか」って疑いたくなるほどの記事の書きっぷりの方が異常なのか。
契約の種類
日本での契約は、話をしやすくするためにシステム開発に限定しますが、請負契約か準委任契約の２つに二分されます。請負契約においては、いわゆる瑕疵担保責任を追うのでプロジェクトがうまくいかなくなると発注側が履行を求めて話しがこんがらがります。
それは棚に上げて、ざっくり２つの契約形態があると覚えておけばいいです。
請負契約 民法 第632条
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
準委任契約 民法 第643条
委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
請負人の担保責任 民法 第634条
１．仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。
２．注文者は、瑕疵の修補に代えて、又はその修補とともに、損害賠償の請求をすることができる。この場合においては、第533条の規定を準用する
ちなみに、海外では他の契約形態があります。PMBOKを読むとそうしたことを知ることができるのでよいですよ。
見積もれないものは請け負えない
２つの契約のどちらかで業務委託を受けるわけです。何が何でも請負契約というわけではないです。例えば、システムエンジニアが目の敵にするコンサルは請負なんてしません。準委任契約の形態をとります。
なぜなら、完成しなければならない成果物が見積もり時に要件として発注側から提示されないので「見積もれない」からです。
当たり前のことですが、何を作ればいいのわからないものは完成責任を負う業務は受託できません。逆に言えば、何を作るかを技術仕様と範囲として提示できるのであれば、請け負えます。そして、その技術仕様と範囲は見積もり仕様として費用と一緒に提示されるのです。
この大前提がわかっていないことに問題があるのでは、と思いますけど。
準委任は責任を負わないわけではない
じゃあ、全部準委任で契約したら完成責任を負わなくて期間満了か工数の到達でバイバイできるかといえば、それほど優しくはないです。
それができるのは、善管注意義務を果たしているときだけです。また、頭の良い業務委託者なら、提出物（準委任契約では成果物とは呼ばない）にアウトプットを要求することもあります。
ITの専門家としての善管注意義務を担う必要があるので、それはそれできちんと仕事をしないといけないわけです。
作らないのではなく、ノウハウを買ってもらうコンサルティング
月額契約型サービス「納品のないSI」
固定料金でシステムを構築する「定額パッケージSI」
自動生成ツールを使う「自動生成SI」
クラウドでITインフラを構築する「クラウドインフラSI」
ユーザー企業自らシステムを外販する「コミュニティSI」
「一括請負はお互い不幸」から「作らないSI」へ
オルタナティヴSIをまとめてくれているのでそれを引用しますが、これらに共通していることは、一から作るのでなくて利用方法のノウハウをパッケージ化してその価値を買ってもらう商売をしている、ってことじゃないかな。
そういう点で見直すと、御用聞きSIからコンサルティングにシフトしたいと言っているのでしょう。
で、ですね。自社開発のサービスでない場合、AWSとか外部サービスを使うとき請負は適当ではないんですよ。だって、サービスの仕様って何かあったらごめんね、っていう契約が多いですから。そうでなければ安くできないですから。それを包括したサービスをするとき、請負なんてありえないんです。そうしたことまでスキームを考えれば自然と準委任契約になるんですよ。
