「『納品』をなくせばうまくいく」を読んだ

「納品」をなくすとはどういうことか

ソフトウェア開発を業者に発注する場合、一般的には「一括請負」が主流です。
お客様が必要とするソフトウェアについてヒアリングし、納期と金額のお見積もりを行い、受注が決まったら要件定義〜開発まで行って、動作検証をして納品。
業界の方でなくても、ソフトウェアやシステム関連の発注を行ったことがある方はご存知かと思います。

本書では、上記の流れで行われるソフトウェア開発の欠点を示し、それを解決するために考えられた新しい開発会社のビジネスモデルを解説しています。
それが「納品のない受託開発」。

「納品」がないとはどういうことか。
それは、ソフトウェアを「納品」して終わりにするのではなく、使い始めてからも改良していくということです。
こうしてみると、納期までの完成リスクを開発会社が負う必要がなくなるので、過大なバッファを避けることができます。

また、従来の開発手法では後工程で形になってきて、はじめてお客様がソフトウェアを触ってみることができました。
なので、触ってみて「少し違う」と思った場合の変更や、運用し始めて気がつく変更にも柔軟に対応することが難しいという欠点、そして「形になるまで分からない」というリスクが存在していました。
「納品」がなければ「完成したので終了です」という仕切りがなくなり、気になる点の改良や、運用し始めてからの気づきも随時反映していくことができるようになります。
これは、「納品」というゴールを目指して開発する開発会社と、事業を進めていくためにソフトウェアを使っていきたいというお客様のミスマッチを解消する仕組みです。

「一括請負」と「納品のない受託開発」の比較

「納品のない受託開発」は良い点がたくさんありますが、開発するソフトウェアの種類によっては「一括請負」の方が適している場合もあります。
2つのビジネスモデルの使い分けを確認するために、それぞれのメリット、デメリットを挙げてみようと思います。

「一括請負」のメリット

• 納期を決めて、そこへ向けて一気に開発を進めることができる
• ソフトウェアが手に入る時期が見える
• 工程が明確に分かれているので、多くの人的リソースを導入してもマネジメントでき、大規模な開発にも対応可能
• 多くの人による念入りな動作チェックが入る

「一括請負」のデメリット

• 開発会社が「完成リスク」を負うため、余分なバッファ分のコストがかかる
• ある程度後ろの工程になるまでお客様はソフトウェアの形を見ることができない
• 納品したら一度終わりになるので、運用後の改良はまた別途やり取りが必要
• 多くの人的リソースがかかる場合が多く、コストが高くつきやすい

「納品のない受託開発」のメリット

• プログラミングを早い時期から行うので、ソフトウェアの現状を把握しやすい
• お客様の事業に合わせて改善していくことができる
• 開発会社による余分なコストが発生しない
• お客様の会社でシステムエンジニアを雇う必要がなくなり、人件費、雇うリスクを抑えることができる

「納品のない受託開発」のデメリット

• 「改善」のサイクルを回していくことが重要なため、大規模な開発には不向き
• 開発会社とお客様の「相性」がある程度合っている必要がある

比較してみると、「一括請負」は必要なソフトウェアが決まっていて、一定の納期で作り上げていく中規模〜大規模なシステム開発において有効なものだと分かります。

対する「納品のない受託開発」は、作りながら／運用しながら改善していくプロセスが続くため、「こんなシステムを使いながら事業を進めていきたい」といった、事業に合わせて改善を反映していくようなシステムが求められます。そのため、改善のサイクルがスムーズに回る必要があるため、比較的小規模な開発に向いているものだと考えられます。

個人的に事業の中で取り入れていきたいこと

僕自身はWEB制作を行っています。
通常のWEBサイトの制作に加えて、WEB上で動作するシステムの開発も請け負っています。
この立場で読んでみると、システム開発においてはまさに本書の内容は合点がいくものでした。
手探りをしながらではありますが、「納品しない受託開発」を取り入れていけたらと思います。

そして、少しアレンジしつつではありますが、WEBサイトの運用についても同じように出来るかと考えています。
本書の中で「お客様の顧問エンジニア」という表現が出てきますが、WEBサイトの運用についても同様なことができる可能性を感じています。
WEBサイト自体は企業が「所持」している必要があると思いますが、常に改善しく点はWEBサイトにおいても同様です。

WEBサイトを「形だけ作ったけど、更新する人がいないから放置…」という企業は結構多いです。
個人的には「まだまだ出来ることがあるのに勿体ない」というのが本音です。
そこで、「顧問WEB担当者」（語呂が少しダサい。笑）というポジションとして運用をサポートしていく、という形に可能性を感じています。

システム開発においては、正直に本書の内容に沿って動いてみたいと考えています。
最初は、ずっと継続して改善していくにしても、改善する内容と作業量がずっと一定ということはないので、何もない時期はどうするのかという疑問がありました。
しかし、ソフトウェアを「所持」ではなく「利用する」というスタンスであれば、辻褄が合うのかと思います。

最後に

本書で書かれているビジネスモデルは非常に合理的で、必要としている人が多いものだと感じています。
WEBに携わる技術者の方は、こういう働き方があるという一つの事例になるはずです。

しかし、個人的には「自社にあうシステムを導入したいけど、どうしたらいいか分からない。」と考えている方にこそ、本書を読む価値がある読者なのではないかと思います。
理由は、著者の会社に発注した企業の実例が、社名を含めて紹介されているためです。
そこでは、他の「一括請負」を行う開発会社との違いが明確に書かれています。
結果として、「システム開発への発注」という少し分かりにくい部分について知ることができ、これから開発会社を探すにあたっての一つの指標になります。