そろそろ請負契約がハッピーに繋がらないことを業界の共通理解にしたい

1年前の記事ですが、パソナテキーラの佐藤潤氏による下記の投稿があります。

【社長のつぶやき】請負開発やめました (パソナテキーラ)

内容として共感できます。当該記事はそんなに長くありませんので、ぜひ読んでいただければと思いますが、端的に言うと、受託のシステム開発において、請負契約を止めて準委任契約に移行した、という話です。

請負契約とはやるべき仕事が明確であること

請負契約というのは、ざっくりと言えば、契約時点で請け負う内容を取り決めて契約を締結するものです。請け負う内容＝仕事内容が確定しているので、当然予算も確定します。これだけやるので、これだけくださいね、という明朗会計な仕組みです。

この仕組みの採用をなぜ止めたのかというと、契約時点で請け負うべき内容が不明確であるにも関わらず、予算が確定しているからです。これでは請負契約の前提が成立していません。

予算という重要にして厄介な制約

ではなぜ、請負契約の前提が成立していないのに、請負契約を求められるのか？というと、「慣行」といえばそれまでなのですが、発注主側の予算が既に確保済みだったり、社内稟議のためのフローが複雑で、新たな予算獲得へのハードルが高いなどの要因から、「予算上限を確定させたい」というニーズのために請負契約が求められるのではないかと思います。この際、請負内容が確定しているかどうかはあまり検討対象になっていません。

本来、請負契約は、予算上限を確定するためのものではなく、あくまで請負内容を確定させるための契約です。予算が確定するのはその副次的な産物のはずですが、なぜか逆転して予算確定のために使われていることが多いように思います。

実は何も決まっていないことを知る

こんにちのデジマ案件における困難さについては以前少し書きましたが、プロジェクトの大義はあっても具体的に何を行うのか？については多くの場合、決まっていません。発注主側からすると決まっているように錯覚している場合もたまにありますが、それは要求レベルの話であり、要件や仕様までは確定していません。仕様はプロジェクトを進めながら決めていくべきものではないか、という意見もあると思いますが、色を赤くするのか、青くするのかというレベルの仕様であればそれで構いません。しかし、実際の現場で起こるのは、工数差が数倍以上になるような仕様のブレです。仕様がブレるのは受託側の要件や仕様の詰めが甘いからではないか？という指摘があると思います。それはその通りで、受託側も要件や仕様を詰め切ることができていません。

要件・仕様を決めることの困難さ

ただ、長年この仕事をしてきて思うのは、1-2ヶ月程度の要件定義でそこまで仕様を決めきることはほぼ不可能に近く、実際は仕様書を策定して、発注主側と合意するところまで持っていって初めて請負内容が確定できる状態に到達します。「プロならできて当然ではないか」という言葉は甘んじて受けるとして、「プロだからこそ、精度の高いプロジェクト運営を行うために必要な仕事をしなければならない」と思います。そのためにやるべきことを発注主側と詰めていくための時間と工程が必要です。

プロジェクトの成功が双方の願い

こう書くと、受託側の身を守るための話ではないか、という意見もあるかと思うのですが、そんなことはなく、発注主側・受託側の双方にとって大切な話です。よほどの悪徳企業でない限りは、プロジェクトを成功させたい、そしてその先にあるビジネスを成功させたい、そう思って仕事をしていると思います。そのためには、なぜその仕事をするのか、そのために何が必要か？を考えることはとても基本的なことです。お金を払えば答えが出てくるような魔法は残念ながらないのです。完全なパッケージ商品ならあるかも知れませんが、今どき、まったくカスタマイズ無しで利用できるソリューションパッケージも少ないので、そこには地道な「詰める」という作業が必要です。

そもそも仕様凍結は難しい

また、別の観点で、デジマ業界において、仕様を6ヶ月〜12ヶ月凍結する、ということは現実的ではありません。これが金融機関のシステムであったり、基幹システムなら話はわかるのですが、6ヶ月もあればビジネス状況も変化することもまた当然であり、その意味からも請負契約がデジタルマーケティングの現状に合っていないと言えます。

それらを全部丸くまとめてしまってはじめから請負契約でやろう、というのはどう楽観的に見積もっても、トラブル必至の選択です。仮に何も起こらずにプロジェクトが終わったのなら、誰かが超人的な努力を人知れず行ったか、はたまた成功となる基準を持たないプロジェクトだったかのどちらかではないでしょうか。通常は、どこかで問題が起き、その解決のために双方の貴重な時間が消費されていきます。

お互いが智恵を出しあうチームワークこそ成功の要

そうではなく、たどり着くべきゴールを決め、そのために必要なことの取捨選択を行い、本当に必要な仕様を取り決めていく、そのために双方の時間と労力を使っていく。デジマ業界のプロジェクトは、お金を払えば答えが出てくる自動販売機ではなく、双方が相当の努力を力を合わせて行うことでやっと成立できるチームプレイなのです。その考え方をプロジェクトの冒頭から持てたチームは、きっと成功に一歩も二歩も近づけると思います。

発注主側は受託側が用意するカタログ的なサービスに惑わされず、一緒に働くチームを見極めてください。受託側はそういうチームワークを発揮できる組織をぜひ作りましょう。そして意味なく最初から請負契約を結ぶことは避けましょう。僕としてはそういうチームワークが有効に機能できるプロジェクトを多く作れるような仕組みをつくって行きたいと考えています。