ホーム > ブログ > 工藤 武久の記事一覧 > 【第47回】どっちの契約でショー!「一括請負」vs「準委任」

【第47回】どっちの契約でショー!「一括請負」vs「準委任」

Pocket

ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

前回はシステム開発プロジェクトの生産性を高めるためのポイントをいくつかご紹介しました。一括請負の契約を締結したあとは、開発ベンダーとしては生産性を高める、というか、生産性を落とさないことが利益確保のために必要不可欠です。

要件定義工程から全てを一括請負契約とした場合、開発途中で「まだ見えていない部分」が見えてくることで、当初の開発スコープでは収まらなくなったり、大きな手戻りが発生して、発注側と受注側の間でトラブルになることがありますよね。。。

 

【 「オルタナティブSI」って? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
前回、システム開発がいまだに人月清算(かかった工数だけお金をもらう)であることに対して、「JRの特急は乗車時間が普通電車より短いことで、追加料金を支払う」例を紹介しましたが、なんと『日経コンピュータ2月5日号』の記事に、「速達が普通郵便より高くなるのは当然。」という言葉が紹介されていました!

この記事の内容は、

伝統的なSIはもう限界
ITベンダーが事実上の一括請負でシステムを開発する従来のモデルでは、要件定義の不備や追加開発の費用をめぐるトラブルから逃れられない。ここにきて、ユーザー企業とITベンダーが協調できる仕組みをビルトインしたシステム構築の新たなビジネスモデルへの挑戦が始まっている。

と銘打って、「オルタナティブSI」という新たなモデルを紹介しています。とても興味深い記事ですので、詳細は本誌をご覧ください。(※1)

 

【 システム開発の契約形態 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
さて、先ほどご紹介した記事とも関連しますが、システム開発を行う場合の発注側と受注側の間の契約形態は、「請負契約」または「準委任契約」を締結するのが一般的です。ご存じの通り、「請負」の方は「システム構築を請負う(成果物提供)」のに対し、「準委任」の方は「システムを構築するための作業を行う(役務提供)」ことになります。したがって、本来は「請負」の場合は人月清算ではないはずですが、実際はシステム開発にかかるであろう工数(人月)を算出した上で見積り額を提示することが多いので、事実上の人月清算になっています。

ちなみに、よくいう「一括請負」とは、たとえばシステム開発の要件定義工程~システムテスト工程までの全体を一括して請負契約とする場合を言います。これに対して、要件定義、外部設計、内部設計・・・といった、システム開発の各工程単位などに区切って請負契約を行う場合を「多段階契約」と言います。「多段階契約」の場合は、工程ごとに開発範囲や条件を見直しするタイミングがあるため、追加要件などの取扱いについて調整するタイミングが持ちやすいということはあります。

しかし、実際は発注側、受注側の決算のタイミングなどを考慮して便宜的に多段階契約の形をとっているものの、実質的には最初に見積もった総額にて全体の受発注額を取り決めている場合もあり、そのケースを「事実上の一括請負」と呼びます。

なお、明確な追加要件があった場合は「一括請負」の場合も、追加要件分の追加開発を別契約として結んだり、契約内容の変更を行うことで受発注額を追加することもできないことはありません。なので、「一括請負」の場合も、「多段階契約」の場合も、当初工数からの差異の原因が、発注側の要件が変わったことによるのか、受注側の見積りミスや失敗などによるのかの区分けが双方合意できないと、いずれにせよトラブルに発展することになりかねません。

 

【 一括請負と準委任はどっちがお得? 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
開発するシステムや組織の特性に応じて一概には判断できないのは百も承知ですが、一括請負と準委任とどっちが良いのかディスカッションしてみましょう!まずはここまでの説明で、プロジェクトマネジメント研修を受けてきたばかりの新人P子さんにおたずねします。

―――「今のお気持ちは?どっち!?」

<新人P子さん> : 「えー、あたしまだ契約のことなんてやったことないから、よくわからないわ。でも、自分がお客様の立場だったら、なんでもベンダーさんにお任せした方が楽だし、開発全体にかかる費用も決まっている一括請負の方が楽だと思うわ。」

<ベテランPMのM男氏> : 「何を言っとるんじゃ!契約がどっちか選べるんだったら、全部準委任にしてくれた方が楽に決まっとる!どうせ大規模なシステム開発の一寸先は闇なんだから、一括請負契約を結んだらおしまいじゃ!全てが準委任にできなくても、要件定義、外部設計やシステムテストは準委任にする必要がある。それにインフラ構築とか、移行関連タスクとか、開発に付随するタスクを少しでもたくさん洗い上げて、それぞれ準委任契約として、リスクヘッジする必要があるものなんじゃよ!」

 

―――まあまあ、うまく意見割れましたね。どうやら開発ベンダーの立場としては、失敗のリスクを負いたくないという気持ちが強く、準委任の方が良いという意見が強いのでしょうか?では、ここで、準委任契約にした場合の失敗事例を紹介します。

<準委任の失敗事例>
長年おつきあいのあるお客様のシステム開発(長期間の保守開発)を準委任契約で若いSEに任せていました。そのSEは優秀だったためにお客様にも好評で、最初のうちは良かったのですが、社内の評価も高く、みるみるうちに昇格してしまい、そのSEの人件費はどんどん高くなっていき、ついには契約の人月単価では利益があがらないどころか、仕事をすればするほど赤字が増えていく「逆ザヤ」の状態に陥ってしまいました。

開発ベンダーとしては交代のSEを提案しましたがお客様は納得せず、単価交渉も限界があり、発注側と開発ベンダーの関係はぎくしゃくし始めました。そんな状況に先行き不安を感じたそのSEは突然転職を決意、それを機に長年続けてきた保守開発を別のベンダーに切り替えることになってしまったため、開発ベンダーとしてはダブルパンチとなってしまいました。(※2)

―――もう一度おたずねします。「今のお気持ちは?どっち!?」

<新人P子さん> : 「へー、そうなんだ。開発ベンダーとしても準委任だと利益を増やすことはなかなかできないのね。やっぱり、スキルアップや生産性向上にも前向きに取り組みやすいし、一括請負の方が良いと思うわ!」

<ベテランPMのM男氏> : 「そりゃおかしいやろ!そもそも準委任契約だから、いくら客の要望だからって、SEの指名なんてできっこないだろ?今の例は特殊なケースであって、少しぐらい逆ザヤのSEがいたって、準委任契約で安定した売上が確保できる方が、プロジェクトの失敗で大赤字となるよりはビジネスとして正解じゃ!」

 

―――おやおや、M男氏も頑固ですねえ!よっぽど一括請負で痛い目を見てきたのでしょうか?確かに日経コンピュータの記事にもあるように、「まだ見えていない部分」があるのに一括請負とするのはプロジェクト失敗の大きな要因になっているのかもしれません。

でも、では、なぜ、システム開発は一括請負のモデルから脱することができないのでしょうか?私のこれまでの経験から思いつく理由をいくつかあげてみます。

<システム開発が一括請負を脱することができない理由(私見)>

1.発注側としては、システム開発予算を事前に把握する必要がある。
システム開発に限らず投資をする際には、事前にいくらかかるかが把握できないと費用対効果が算出できず、投資可否の判断ができません。事前にいくらかかるか把握できていれば、一括請負としてもなんら問題は無いはずです。
発注側としては、開発ベンダーにリスクを転嫁しているという説明をされることもありますが、それでプロジェクトが失敗すれば結局発注側の損失につながるはずなので、それほど短絡的ではないと思われます。

2.受注側としては、システム開発売上予測を事前に把握する必要がある。
システム開発を主たる事業としている開発ベンダーとしては、そのシステム開発を受注することで、どれだけ売上があがるのか、さらにはどれだけリソースを使うのかなど、売上予測やリソース計画も明確にできなければ、安定した経営ができません。したがって、受注確定時点で売上額が確定するはずの一括請負契約の方がメリットがあると考えられます。
プロジェクトの失敗については、原因さえ明確にできれば全ての損失を受注側が負う必要があるわけではないはずなので、失敗への備えさえあれば十分対処できるはずです。

3.一括請負でも成功(Win-Win)となるケースも少なからずある!
そもそも一括請負という契約形態がプロジェクト失敗の原因であれば、これまで一括請負が主流であったシステム開発というビジネスは成り立っていないはずです。とかく失敗事例がクローズアップされて、一括請負の責任範囲についての議論がされますが、「プロジェクトが失敗した原因」と「失敗した後の対処がうまくいかなかった原因」が混同されているような印象を受けています。
私個人の意見としては、契約形態とプロジェクトの失敗の因果関係はそれほど強くはないと考えています。むしろ、当ブログの全体的な基調として示している「自発性」を開発ベンダーが発揮しやすい一括請負の方がWin-Winの関係を築きやすいと考えています。(※3)

「プロジェクト失敗の原因を契約形態のせいにするのはやめておこう!」

―――「ファイナルアンサー!?」「今度のご契約は、どっち!?」(※4)

・・・

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
応援してくださる方は、クリックよろしくお願いします!
◆ 人気ブログランキング
◆ にほんブログ村
~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

※1 『日経コンピュータ』2015年2月5日号、日経BP社より
・P022 特集「オルタナティブSI 未来を開く五つの鍵」

※2 念のため、当事例はありそうな話ではありますが、フィクションです。

※3 自発性については、当ブログの以下の回参照
【第7回】フルトヴェングラーのプロジェクトマネジメント
【第10回】落合「オレ流野球」はCMMIレベル5か?

※4 今回のブログタイトル、および、【 一括請負と準委任はどっちがお得? 】の部分では、以前日本テレビ系列で放送されていたバラエティ番組『どっちの料理ショー』を参考にさせていただきました。「ファイナルアンサー!?」は、『クイズ$ミリオネア』より。
・「どっちの料理ショー」『フリー百科事典 ウィキペディア日本語版』
2015年2月4日 (水) 13:32 utc http://ja.wikipedia.org/wiki/どっちの料理ショー
・「クイズ$ミリオネア」『フリー百科事典 ウィキペディア日本語版』
2015年1月27日 (火) 05:12 utc http://ja.wikipedia.org/wiki/クイズ$ミリオネア

Pocket

目次

Profileプロフィール

工藤 武久
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事

PMI®公認教育プロバイダー(R.E.P:Registered Education Provider) 株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。
PMI Registered Education ProviderロゴおよびPMBOK®Guideは、PMI®(Project Management Institute, Inc.)の登録商標です。
IIBA®認定教育プロバイダー(E.E.P:Endorsed Education Provider) 株式会社アイ・ティ・イノベーションは、IIBA®(International Institute of Business Analysis)の認定教育プロバイダー(E.E.P:Endorsed Education Provider)です。
IIBA®BABOK®およびBusiness Analysis Body of Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。