受託開発の「納品して終わり」をやめると、保守が事業の柱になる

受託開発の仕事は、放っておくと同じ1年の繰り返しになりがちです。
毎回、同じ流れをなぞるからです。
案件を取る。作る。納品する。検収が終わる。そして、また次の案件を探す。

この繰り返しのつらさは、経験者ならすぐ分かると思います。
納品した瞬間に売上がゼロに戻る。来月の仕事は、来月にならないと分からない。
それでいて、納品済みのシステムから「ちょっと直してほしいんだけど」の電話は鳴り続ける。
無償で対応すれば時間が溶け、有償だと言えば関係がぎくしゃくする。どちらを選んでも消耗します。

納品後のシステムを、いちばん知っているのは誰か

たとえば、納品から2年たったシステムで障害が起きたとします。
契約はとっくに終わっている。でも先方は困っている。結局、夜中まで対応することになりがちです。

そこで見落とされがちなのが、作った側がそのシステムのことを世界でいちばん知っている、という当たり前の事実です。
データの構造も、あの妙な仕様の理由も、どこが弱いかも、全部頭に入っている。
この知識には値段がついていないだけで、価値がないわけではない。むしろ逆で、これこそが売り物なんじゃないか。

保守を「おまけ」から「商品」に設計し直す

そこで、納品後の関わり方を商品として作り直す、という考え方があります。
やることは、特別なことではありません。

まず、見積の段階で保守プランを本体と並べて提示する。
納品後に「保守どうしますか」と聞くのではなく、最初から「作って終わりではなく、育てていく前提」で話をする。
ここで大事なのは、保守の中身を「障害対応」ではなく「定期的な点検と小さな改善」として定義することです。
壊れたときだけ呼ばれる関係は、お互いに不幸なので。

次に、月次の報告を必ず出す。
何もなかった月も「何もなかったことを確認した」と報告する。
保守費用がいちばん切られやすいのは「何をしてくれているのか見えないとき」で、逆に見えてさえいれば、ずっと切られにくくなると思います。

そして、保守で気づいた改善点を小さな追加開発として提案する。
新規案件の営業をしなくても、既存のお客さんの中に次の仕事の種が埋まっていることが多いと思います。

安定の話と、副作用の話

保守と月額の契約が積み上がると、売上の土台ができます。
月初の時点で今月の売上の底が読める。この安心感は、単価の高い単発案件ではなかなか得られません。

副作用もふたつあります。
ひとつは、コードの書き方が変わること。5年後の自分が保守する前提で書くようになると、ドキュメントの残し方も設計も自然と変わります。
自社CMSにプラグイン機構を後付けした設計メモも、根っこは同じ「保守しやすさ」の話です。

もうひとつは、断る力がつくこと。
目先の売上のために相性の悪い案件を取る必要がなくなると、仕事の平均品質が上がります。
これが回り回って、紹介につながることもあります。

「作って終わり」は、作る側も終わらせている

納品して終わりのモデルは、システムを使い捨てにするだけでなく、作り手の経験も使い捨てにしていたんだと思います。
同じシステムと長く付き合うほど知識は複利で効いてくるのに、それを毎回リセットしてしまう。

週末のキャンプで「不便は道具と仕組みで解決する」と言っているのと、たぶん根っこは同じです。
消耗を根性でしのぐのをやめて、仕組みを変える。
キャンプと同じ考え方は、仕事でもそのまま使えると僕は思います。

仕組みで解決する性分がキャンプでどうなるかはサイトについてでどうぞ。