契約から「納品のない受託開発」の仕組みを考える

先日のSEA関西のパネルは多くの質疑応答をこなして、「納品のない受託開発」が何であるかは理解できました。しかし、2時間では時間が足りず、あまり深い議論ができませんでした（司会の私の責任です。すみません）。

人の話を理解するだけでなく、そこにある原理が自分の知識体系に組み込まれなければ、応用ができません。ワークショップの様に実践することでわかることもあると思いますが、それは体感にすぎません。いわば言われた通りのコーディングで、本格的に動かすまで正しいかどうかもわかりません。

やっぱり、あーでもない、こうでもない、と色々考えないとわかりません。そこで役に立つのはコードリーディングです。様々なスタイルや似て非なる色々なコードを読むうちに、どんなコードがわかり易いとか、保守性が高いとか、どうしてこう考えたのだろうとか、考えることができます。

そこで「納品のない受託開発」の仕組みを契約の側面から考えてみます。

請負開発

コトバンクによれば「依頼を受けた者(請負人)がある仕事を完成することを約束し、その注文者がその仕事に対して報酬を支払う契約を「請負契約」といいます。」とされていて、完成物を引き渡す、いわゆる納品までが開発期間になります。

あらかじめゴールを決めて契約するのですから、ゴールの解釈が広くなると発注側（顧客)が得に、ゴールの解釈が狭くなると開発側が得になり、利害が対立します。そこで、受注側(開発)は新たな提案はもちろんのこと、なるべく仕様変更を受け入れず、より簡単な実装にして利益を増やそうとする「ディフェンシブな開発」(kuranukiの日記)が行われがちになります。

もちろん、継続案件があれば開発側は目先の利益だけを考えることができずに、良心的な対応をするでしょう。とはいえ、予想外の問題が発生すると利益を確保しないといけないので、責任の所在について顧客と開発側が対立してしまうことになります。

準委任契約と時間精算

そこで、リスクの高いプロジェクトや、見積もりが困難なプロジェクトの上流では、準委任契約によるシステムエンジニアリングサービス(SES)が行われます。

この場合も、発注側は同じ金額なら多くの時間を作業してもらった方が得ですし、受注側は作業時間が少ない方が得になり、やはり利害が対立してしまいます。

そこで、標準的な作業時間を幅を持たせて決めておき、その幅を超えれば時間単位で精算する方法がとられます。

請負契約の場合は瑕疵担保責任があるので、一定期間は開発側の責による障害を解決しないといけません。しかし、準委任契約では瑕疵担保責任はなく、リスクは発注側が持つことになります。

その点は開発側が有利なのですが、準委任契約は多くの場合は期間契約ですので、顧客の要望が満たされなければ契約を中断することができます。

納品のない受託開発

納品のない受託開発は月額固定の費用で、顧客との合意を取りながら開発を行います。納品のない受託開発を既存の契約に近い表現を探すと、時間精算のない準委任契約、常駐のない準委任契約といえるでしょう。

時間精算のない準委任契約をソフトウェア開発で探すとコンサルタント契約が挙げられます。時間でなく訪問回数に応じて費用を精算するもので、時間精算を緩くしたものと考えて良いものです。しかし、常駐こそしていないものの拘束されることで費用が発生していますので、費用の合理性があるものの成果に応じた報酬とは言い切れません（成功報酬契約も可能ですが、顧客が成功をコントロールできるので、うまくいかない場合もあるそうです）。

一方の常駐のない準委任契約をさがすと、リモートでの運用契約があります。運用にはこれまで常駐するものが多く、時間や日、あるは常駐人数などで契約していました。しかし最近は、クラウド上の監視対象のサーバ数によって契約する形態があります。

ここで納品のない受託開発と比較すると、一定の成果を期待して定額を払うところは似ていますが、リモートの運用では成果が明確であるのに対して、納品のない受託開発では決まっておらず、常に合意を得ながら進めていく点が異なります。

ここで、時間精算のある準委任契約を思い出してください。時間精算によって機能を詰め込もうとする顧客に制限を加えていたのですが、納品のない受託開発では抑えが利きません。これを解決する秘密は、以下の3点だと思います。

• 顧客のビジネスに入り込んでいるので、本当に求めているものや必要なものを知っている
• 力技に頼らない代替手段を提案できる技術力がある
• 対等の関係になれるような仕事を選んでいる

これらを実現することで、顧客との約束を時間ではなく成果とでるのでしょう。そして技術力によって時間を生み出して、技術者が技術者として勉強し、より高度な技術を提供できるような環境を整えるられるのだと思います。

価値創造契約

ここで、同じように月額定額のアジャイル開発でありながら、苦戦しているらしい 永和システムマネジメント さんの価値創造契約と比べてみます。

顧客の価値という点を考えると、価値創造契約はソフトウェアおよびその利用（サービス）を価値としていて、契約終了と共に利用ができなくなります。一方の納品のない受託開発はより顧客のビジネスに関わっていて、戦略的なソフトウェアの実現（開発作業）を価値としている点が大きく違います（開発作業を請け負うのでソフトウェアは顧客のものです）。

ソフトウェアの利用ができなくなる点は大きいと思いますが、ソフトウェアは長期に使うものですので、それだけで苦戦の説明になりません。それ以外に、なにかボタンの掛け違えの様なものがあるのではないでしょうか。それぞれのビジネスモデルがどのように構築されたか、そのプロセスが大きく関わっているように思います。

ビジネス構築のプロセス

納品のない受託開発のはじまりは顧客からの要望だったそうです。手探りですすめながら「いける」という感触を得て、始められた様です。リーンスタートアップのようにコアなモデルからボトムアップに発展させることで、確実な仕組みを手に入れられたのでしょう。

これに対して価値創造契約は社内コンテストのアイデアを元に、すすめられたそうです。アイデアからビジネスに持っていったので、トップダウン的な明確さがある反面、顧客のニーズにあわせて方向転換がやりにくいという弊害があるのかもしれません。

これは、営業のpushとpullにも繋がります。倉貫さんの知名度と人脈をベースに、要望を受けて仕事を選びながらビジネスをする納品のない受託開発に対し、物量的なアウトバウンドな営業を必要とする価値創造契約が苦戦するのは無理もないと思います。pullを上回るような強力な価値の提供が必要だと思います。

おわりに

「納品のない受託開発」は少し難しいビジネスモデルです。倉貫さんにとっては納品は大きなキーワードだったかもしれませんが、契約の視点では大きなポイントではなく、開発の考え方や組織づくりに効果があるからです。

また、書籍を読んで一通りのお話を聞くとなるほどと思うのですが、それを前提が異なる普通の職場に活かすことは難しいでしょう。

そこで、実践されてきたプロセスに注目すると、それがリーンスタートアップの実践であることが見えてきます。最もコアな価値を提供できるMVPの実践から、必要に応じてピボット（方向転換）して、ビジネスを組み立てられているのです。

日々の仕事の中で気付くビジネスの問題、それをどう組み立てて実践するか、参加者のそれぞれに宿題をいただいたように思います。