リーンやPoCと相性のよい「納品のない受託開発」をもっと知ってほしい件
こんにちは。
年末に通っているジムの忘年会で今年の成果発表として上半身脱ぐことになった株式会社UZUMAKI代表の(@ToraDady)です。
ジムのオーナーはK1の左右田選手なんで、プレッシャーが半端ない今日このごろ。
仕事より筋肉の仕上がりが気になってる時期ですが、早めの今年の振り返りとして、納品のない受託開発について個人的な考察をしてみたいなと思います。
この記事を書こうと思ったきっかけは、世の中にはSler的な受託開発会社は多いですが、納品のない受託開発(いいかえると、仕事の完成に対してコミットしない)をする会社がまだまだ少なく、もっと世の中に知ってもらいたいなという気持ちが出てきたからです。
ですので、この記事は、
に答える内容になってます。
そもそも納品のない受託開発とは
結論から先にいうと、納品のない受託開発と従来の受託開発の違いは、シンプルにいえば開発という行為にお金を払うか納品物にお金を払うかの違いです。
この言葉は、株式会社ソニックガーデンの代表倉貫さんが提唱したものです。
↑ 公式サイトから引用
従来のSlerとの違いを法的に説明すると、クライアントとの開発の契約について、請負契約で受けるか、準委任契約で受けるかの違いにあります。
つまり、準委任契約でクライアントと契約をするのが納品のない受託開発といえます。また、準委任契約という観点からは、ラボ型開発も納品のない受託開発と同じカテゴリーに入ります。※(この記事ではラボ型開発の詳細には言及していません)
請負契約と受託開発の違い
従来のSlerは、請負契約として開発について完成させて納品することに対してお金をもらいます。請負契約を明記した民法632条には、
と書いています。ですので、「仕事の完成を定義するために」何を作って欲しいのかという仕様が契約時に明確になっていないといけないです。また、受託会社は、仕事の完成を約束している以上、完成できていなかったときの瑕疵担保責任(民法634条)、つまり、瑕疵(ソフトウェアのバグ)を納品後も納める責任が発生します。
一方で、納品のない受託開発をする会社は、準委任契約として開発する行為に対してお金をもらいます。
少し条文がむずかしいですが、準委任契約は、委任の定義を法律行為(弁護士などが行う業務)以外に準用するとしており、
要は、開発するという行為に対して報酬を支払う契約であることを明記しています。※法律でない行為に開発業務が含まれます
準委任契約は、フリーランスのエンジニアに企業から仕事を発注する場合、SES契約(中身は準委任契約と同義)として仕事を受けることはよく見受けられますが、法人にクライアント企業が仕事を発注する場合、まだまだ請負契約で仕事を発注するケースが多いです。
納品のない受託開発のメリット
必要なものを小さく作ることができる
お金を少なく始めることができるということです。準委任契約なので、作りたいプロダクトの仕様が完全に決まっていなくても、費用対効果の高いところから作り出していくことで、余計なお金をかけず作っていくことができます。制作の当初目論んでいたユーザー層がズレていたとかの仮説検証を、製作期間を短く作ることで余計なお金と時間をかけず行うことができます。
仕様変更に別途お金がかからない
請負契約だと、最初に見積もった要件定義に縛られるので発注側も受注側も仕様の範囲内かそうでないかに心血を注ぐことになります。見積もった要件定義に漏れがないことはまずないですし、双方に過失があるケースがほとんどです。これを受託側が受け入れるとデスマーチが始まり、バグの多い成果物を納品->瑕疵担保責任で関係性悪化という負のスパイラルが発生します。準委任契約だと、仕様の変更は契約の範囲内なので、良好な関係を維持しつつ目の前の課題に取り組めます。
まるっと仕事を依頼できる
請負契約と違い、依頼することがふわっとしていても委任契約自体は成立します。逆にいうと、ふわっとしてても依頼したくなる魅力のある会社じゃないと成り立ちません。具体的には、iOSアプリ制作したいということであれば、プロジェクトマネジメント、クライアント側の開発、サーバー側の開発、デザイン制作ができる会社が多いです。
フリーランスの寄せ集めではない
新規サービスを開発するにあたり、SES契約でフリーランスエンジニアを集めてサービスをつくることも多いです。フリーランスで優秀なエンジニアは多いですが、プロジェクトはチームでつくるものなので、メンバー間の関係性構築には時間がかかりますし、相性の問題は出てきます。この点、納品のない受託開発会社であればメンバーの関係性がゼロからのスタートではないので、コミュニケーションコストが低いです。
発注側からみた納品のない受託開発のデメリット
予算の稟議を申請しづらい
これは、発注側としては当然出てくる話です。担当者からすると予算を確保した上で取組むのが当たり前な世界なので、「いくらかかるのか?」「やってみないとわかりません」だと、とても稟議が降りません。この点は思うところがあるので別記事で深堀りしたいと思います。
いつ完成するかが明確に決まらない
納品がない以上、明確に終了というものが定義しにくいものです。とは、いっても、プロダクトをいつリリースするかは存在しますが、状況によってリリース時期は前後します。この不確実性をどこまで許容できるか、また、許容すること以上のメリットが明確にあるといえるかが肝になってきます。
どういう仕事が相性がいい?
PoC系
PoC(Proof of Concept)は日本語で言うところの概念検証。
ここではPoC"系"と言うように広く捉え、MVP(Minimum Viable Product)の作成や、技術的に可能か検証する技術検証やプロトタイプの作成を指します。閃いたビジネスアイディアが本当に顧客がいるのか?いち早く市場に投入して仮説検証する必要があります。またそのビジネスアイディアがそもそも技術的に実現可能なのか短期間に調査・検証するのにも向いています。
リーンスタートアップ系
大手企業の新規開発事業部が新しいことをする場合、コストをそれほどかけずに最低限のサービスをつくり、顧客に提供してその反応をみてサービスを継続するかどうかも含めて改善しながら開発をするスタイルとの相性がよいです。
リファクタリング系
成熟したプロジェクトは、長年の積み重ねの中でコードの負債が溜まってます。納品のない受託開発である以上、行為に対して責任を負います。この点が、とりあえず動けばOK的な見えるものへの結果責任ではなく、見えない問題点(追加開発しずらい、だれも触りたくないスパゲッティコード)への取り組みに力を発揮します。
逆に、相性が悪いのは
ウォーターフォール系
大規模なシステム開発だと仕様を厳格に定義して分担して作業しないといけない場合は、相性悪いです。求められるスキルが、何をつくるのかという不確実性を排除された環境下だと、そもそもこれ作る必要性ありますか?的な意識はいらないからです。求められているのは、正確に早く、大量の人員で作業を進めることです。納品のない受託開発会社は、メンバーの個性を生かした属人的な組織形態なので大規模で人員の質と数が重要なケースでは力を発揮しにくいです。
マルチベンダー案件系
強みであるまるっと任せれる事の裏返しですが、他のベンダーと協業して受ける案件(例えばクライアントアプリとサーバーサイドが別会社)だと、プロジェクトにおいてベンダー間のコミュニケーションがゼロからのスタートなので、うまくいかないケースが多いです。
納品のない受託開発している会社ってどう調べたらいいの?
私自身も、この記事を書いていて、一体どれだけ世の中に納品のない受託開発(法的な定義だとラボ型開発を含む)をしている会社があるのかが疑問になってきました。
ですので、弊社CTOの今佑介にGithubに納品のない受託開発会社やラボ型開発会社をピックアップしてもらいました。
↓
この記事を読んで、うちの会社も準委任でクライアントと契約して仕事しているという方がいらっしゃれば、GithubのレポジトリにPull Requestを送っていただければ幸いです。
↓
Githubのレポジトリはこちらです
お知らせ
XではUZUMAKIの新しい働き方や日常の様子を紹介!ぜひフォローをお願いします!
https://twitter.com/uzumaki_inc
TechBlogではUZUMAKIの技術情報を紹介!
UZUMAKIではRailsエンジニアを絶賛募集中です。
ご興味を持っていただいた方は、ぜひ応募よろしくお願いします!
新しい働き方についての発信をしていきますので、よろしければサポートお願いいたします!