>前回はシステム開発プロジェクトの生産性を高めるためのポイントをいくつかご紹介しました。一括請負の契約を締結したあとは、開発ベンダーとしては生産性を高める、というか、生産性を落とさないことが利益確保のために必要不可欠です。要件定義工程から全てを一括請負契約とした場合、開発途中で「まだ見えていない部分」が見えてくることで、当初の開発スコープでは収まらなくなったり、大きな手戻りが発生して、発注側と受注側の間でトラブルになることがありますよね。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~前回、システム開発がいまだに人月清算(かかった工数だけお金をもらう)であることに対して、「JRの特急は乗車時間が普通電車より短いことで、追加料金を支払う」例を紹介しましたが、なんと『日経コンピュータ2月5日号』の記事に、「速達が普通郵便より高くなるのは当然。伝統的なSIはもう限界ITベンダーが事実上の一括請負でシステムを開発する従来のモデルでは、要件定義の不備や追加開発の費用をめぐるトラブルから逃れられない。ここにきて、ユーザー企業とITベンダーが協調できる仕組みをビルトインしたシステム構築の新たなビジネスモデルへの挑戦が始まっている。銘打って、「オルタナティブSI」という新たなモデルを紹介しています。興味深い記事ですので、詳細は本誌をご覧ください。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~さて、先ほどご紹介した記事とも関連しますが、システム開発を行う場合の発注側と受注側の間の契約形態は、「請負契約」または「準委任契約」を締結するのが一般的です。ご存じの通り、「請負」の方は「システム構築を請負う(成果物提供)」のに対し、「準委任」の方は「システムを構築するための作業を行う(役務提供)」ことになります。したがって、本来は「請負」の場合は人月清算ではないはずですが、実際はシステム開発にかかるであろう工数(人月)を算出した上で見積り額を提示することが多いので、事実上の人月清算になっています。ちなみに、よくいう「一括請負」とは、たとえばシステム開発の要件定義工程~システムテスト工程までの全体を一括して請負契約とする場合を言います。いった、システム開発の各工程単位などに区切って請負契約を行う場合を「多段階契約」と言います。「多段階契約」の場合は、工程ごとに開発範囲や条件を見直しするタイミングがあるため、追加要件などの取扱いについて調整するタイミングが持ちやすいということはあります。実際は発注側、受注側の決算のタイミングなどを考慮して便宜的に多段階契約の形をとっているものの、実質的には最初に見積もった総額にて全体の受発注額を取り決めている場合もあり、そのケースを「事実上の一括請負」と呼びます。明確な追加要件があった場合は「一括請負」の場合も、追加要件分の追加開発を別契約として結んだり、契約内容の変更を行うことで受発注額を追加することもできないことはありません。「一括請負」の場合も、「多段階契約」の場合も、当初工数からの差異の原因が、発注側の要件が変わったことによるのか、受注側の見積りミスや失敗などによるのかの区分けが双方合意できないと、いずれにせよトラブルに発展することになりかねません。】~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~開発するシステムや組織の特性に応じて一概には判断できないのは百も承知ですが、一括請負と準委任とどっちが良いのかディスカッションしてみましょう!まずはここまでの説明で、プロジェクトマネジメント研修を受けてきたばかりの新人P子さんにおたずねします。「えー、あたしまだ契約のことなんてやったことないから、よくわからないわ。自分がお客様の立場だったら、なんでもベンダーさんにお任せした方が楽だし、開発全体にかかる費用も決まっている一括請負の方が楽だと思うわ。システムテストは準委任にする必要がある。―――まあまあ、うまく意見割れましたね。開発ベンダーの立場としては、失敗のリスクを負いたくないという気持ちが強く、準委任の方が良いという意見が強いのでしょうか?では、ここで、準委任契約にした場合の失敗事例を紹介します。<準委任の失敗事例>長年おつきあいのあるお客様のシステム開発(長期間の保守開発)を準委任契約で若いSEに任せていました。そのSEは優秀だったためにお客様にも好評で、最初のうちは良かったのですが、社内の評価も高く、みるみるうちに昇格してしまい、そのSEの人件費はどんどん高くなっていき、ついには契約の人月単価では利益があがらないどころか、仕事をすればするほど赤字が増えていく「逆ザヤ」の状態に陥ってしまいました。開発ベンダーとしては交代のSEを提案しましたがお客様は納得せず、単価交渉も限界があり、発注側と開発ベンダーの関係はぎくしゃくし始めました。そんな状況に先行き不安を感じたそのSEは突然転職を決意、それを機に長年続けてきた保守開発を別のベンダーに切り替えることになってしまったため、開発ベンダーとしてはダブルパンチとなってしまいました。(※2)―――もう一度おたずねします。開発ベンダーとしても準委任だと利益を増やすことはなかなかできないのね。―――おやおや、M男氏も頑固ですねえ!よっぽど一括請負で痛い目を見てきたのでしょうか?確かに日経コンピュータの記事にもあるように、「まだ見えていない部分」があるのに一括請負とするのはプロジェクト失敗の大きな要因になっているのかもしれません。システム開発は一括請負のモデルから脱することができないのでしょうか?私のこれまでの経験から思いつく理由をいくつかあげてみます。<システム開発が一括請負を脱することができない理由(私見)>1.発注側としては、システム開発予算を事前に把握する必要がある。システム開発に限らず投資をする際には、事前にいくらかかるかが把握できないと費用対効果が算出できず、投資可否の判断ができません。事前にいくらかかるか把握できていれば、一括請負としてもなんら問題は無いはずです。発注側としては、開発ベンダーにリスクを転嫁しているという説明をされることもありますが、それでプロジェクトが失敗すれば結局発注側の損失につながるはずなので、それほど短絡的ではないと思われます。2.受注側としては、システム開発売上予測を事前に把握する必要がある。システム開発を主たる事業としている開発ベンダーとしては、そのシステム開発を受注することで、どれだけ売上があがるのか、さらにはどれだけリソースを使うのかなど、売上予測やリソース計画も明確にできなければ、安定した経営ができません。したがって、受注確定時点で売上額が確定するはずの一括請負契約の方がメリットがあると考えられます。プロジェクトの失敗については、原因さえ明確にできれば全ての損失を受注側が負う必要があるわけではないはずなので、失敗への備えさえあれば十分対処できるはずです。3.一括請負でも成功(Win-Win)となるケースも少なからずある!そもそも一括請負という契約形態がプロジェクト失敗の原因であれば、これまで一括請負が主流であったシステム開発というビジネスは成り立っていないはずです。失敗事例がクローズアップされて、一括請負の責任範囲についての議論がされますが、「プロジェクトが失敗した原因」と「失敗した後の対処がうまくいかなかった原因」が混同されているような印象を受けています。私個人の意見としては、契約形態とプロジェクトの失敗の因果関係はそれほど強くはないと考えています。当ブログの全体的な基調として示している「自発性」を開発ベンダーが発揮しやすい一括請負の方がWin-Winの関係を築きやすいと考えています。念のため、当事例はありそうな話ではありますが、フィクションです。】の部分では、以前日本テレビ系列で放送されていたバラエティ番組『どっちの料理ショー』を参考にさせていただきました。「ファイナルアンサー!?」は、『クイズ$ミリオネア』より。■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。(プロジェクトマネージャ、システム監査技術者他)など。社員の声アクセス採用情報ブログ株式会社アイ・ティ・イノベーションは、米国PMI®から公認教育プロバイダー(R.E.P)として認定されております。Inc.)の登録商標です。Provider)です。Knowledge®は、IIBA®の登録商標であり、IIBA®の許可を得た上で使用しています。アイ・ティ・イノベーションまたは各社の商標もしくは登録商標です。