自分で組織を組成してプロジェクトを完遂して振り返ること①

自分で構築したチームで、比較的大きなプロジェクトを受注してアプリケーションを開発して納品しました。多くの経験が得られたので自分のためにまとめると同時に、誰かのためになればと思ってブログにまとめます。

参考になると思われる人は以下のとおりです。もしかするとこれ以外の方にも参考になるかもしれません。

• 個人でプロジェクトを請け負う場合

• 起業するわけではないが、チームでプロジェクトを請け負う場合

• メンバーに海外出身のメンバーがいる場合

• チームメンバー全員が兼業している場合

契約は準委任契約が望ましい

契約は奉仕する時間に対して報酬をいただく準委任契約が望ましいと思います。実は自分は請負契約を選択しました。そのときの反省から準委任契約が望ましいと思っています。

請負契約と準委任契約の違い

請負契約は成果物の完成に責任を負います。決められた期間の中で完成した成果物を納品します。準委任契約の場合は働いた時間に対して報酬を得ます。

請負契約のメリットは、求められている成果物に対して金額を見積もり、その成果物を納品することで対価を得られます。見積もりにはもちろん根拠は必要ですが、効率的に開発することで利益率が高まる（ように思える）ものです。

一方で準委任契約のメリットは、成果物を納品していない状態でも奉仕に対して対価を得られます。効率性の面に関してはどれだけ頑張っても決められた時給に対して対価が支払われるので評価されません。その代わり、単位時間あたりのアウトプットに自信がある場合は時給を上げる交渉をすることになります。

請負契約の難しさ

こう書いてみると、請負契約の方が良さそうに見えます。請負契約においては求められる成果物に対して、それを具現化して納品して対価を得ます。もちろん納品すればそれで良いのではなく、こちらが納品したものを顧客が確認して＝検収してはじめて対価が支払われます。つまり顧客が成果物に対して納得しないと対価が支払われません。この構図に非常に難しい問題があります。

というのもアプリケーション開発において、まず顧客が作ってほしい成果物を厳密に決められている状況というのはレアです。ほぼ柔らかい状態。それに対して具現化すると、具現化して初めて顧客は発想が膨らんでいきます。そうすると当然変えたいことが出てくる。そうなると当初の求めていた要件からどんどん脱線していきます。作っている側としては当初見積もっていたものよりもコストはどんどん膨らみます。しかし期限は変わりません。必死に作っても期間は限られているから品質はどんどん悪くなります。品質・期間・コストは反比例の関係なので当たり前ですね。ですが、変わらない期限までに、変わる要件に対して、完璧（に見える）品質で納品しないと顧客は検収できないので、それで対価は支払われない。もちろん作っている側は顧客に対して文句を言うでしょう。構造的に作っている側は苦しくなるし、顧客としては作っている側に対して品質が悪いと言って不信感を抱きます。両者ともに喧嘩することになります。構造的欠陥です。

例えばビルの建設のように（ビルを建設する仕事に従事したことがないのでもしかしたら違うのかもしれませんが）、発注するときに作るものが明確になっているものは請負契約がフィットするでしょう。ですが、アプリケーション開発の場合、まずもって作るものが明確になっていることはないように思えます。

アプリケーション開発では準委任契約が望ましい

これを踏まえると、準委任契約が望ましいと思います。準委任契約では奉仕する時間に対して作っている側は対価をいただきます。顧客が作りたいものがいくら変わろうが問題ありません。心理的安全性も高まるでしょう。もちろんここでは、時間に対してサボらないという前提があります。サボってしまうとそれは顧客も発注できない。

ただしここにも難しい点があるのは顧客としては速く作りたいという心理が働きます。またスケジュールを確定させたいという心理も働くでしょう。準委任契約だと納期の確約はしません。作業に対して対価をいただくからですね。この場合は発注前にある程度作りたいものから開発のインプットを粗めにでも良いから作って、目安のスケジュールを引いてあげることが必要なのかもしれません。

まとめ

アプリケーション開発では準委任契約が望ましいと思います。よほど顧客が成熟していてベンダーコントロールができ、すでに要件も固まっていてブレることはないということであれば請負契約でも良いかと思います。ただ作る側としては顧客の成熟度合いは測ることが、長い付き合いがなければ難しいでしょう。やはり準委任契約が良いのではないかと思います。

つづく。