受託開発15年目。「納品して終わり」をやめたら、保守が事業の柱になった
技術の話というより、小さな開発の現場でどう生き延びるかの話です。
同じ消耗戦の中にいる誰かの、降り方の参考になれば。
受託開発の仕事を始めて15年になります。
最初の10年は、いま振り返ると同じ1年を10回繰り返していました。
案件を取る。作る。納品する。検収が終わる。そして、また次の案件を探す。
この繰り返しのつらさは、経験者ならすぐ分かると思います。
納品した瞬間に売上がゼロに戻る。来月の仕事は、来月にならないと分からない。
それでいて、納品済みのシステムから「ちょっと直してほしいんだけど」の電話は鳴り続ける。
無償で対応すれば時間が溶け、有償だと言えば関係がぎくしゃくする。どちらを選んでも消耗します。
転機は、ある障害対応の夜だった
数年前、納品から2年たったシステムで障害が起きました。
契約はとっくに終わっている。でも先方は困っている。結局、夜中まで対応しました。
作業を終えて気づいたのは、自分がそのシステムのことを世界でいちばん知っている、という当たり前の事実です。
データの構造も、あの妙な仕様の理由も、どこが弱いかも、全部頭に入っている。
この知識には値段がついていないだけで、価値がないわけではない。むしろ逆で、これこそが売り物なんじゃないか。
保守を「おまけ」から「商品」に設計し直した
それから、納品後の関わり方を商品として作り直しました。
やったことは、特別なことではありません。
まず、見積の段階で保守プランを本体と並べて提示するようにしました。
納品後に「保守どうしますか」と聞くのではなく、最初から「作って終わりではなく、育てていく前提」で話をする。
ここで大事なのは、保守の中身を「障害対応」ではなく「定期的な点検と小さな改善」として定義したことです。
壊れたときだけ呼ばれる関係は、お互いに不幸なので。
次に、月次の報告を必ず出すようにしました。
何もなかった月も「何もなかったことを確認した」と報告する。
保守費用がいちばん切られやすいのは「何をしてくれているのか見えないとき」で、逆に見えてさえいれば、切られることはほとんどありません。
そして、保守で気づいた改善点を小さな追加開発として提案する。
新規案件の営業をしなくても、既存のお客さんの中に次の仕事の種はいくらでも埋まっていました。
数字の話と、副作用の話
いまは、月の売上の半分強を保守と月額の契約が占めています。
月初の時点で今月の売上の底が読める。この安心感は、単価の高い単発案件では絶対に買えません。
予想していなかった副作用もふたつありました。
ひとつは、コードの書き方が変わったこと。5年後の自分が保守する前提で書くようになると、ドキュメントの残し方も設計も自然と変わります。
自社CMSにプラグイン機構を後付けしたのも、元をたどれば「保守しやすさは自分の利益」になったからです。
もうひとつは、断る力がついたこと。
目先の売上のために相性の悪い案件を取る必要がなくなると、仕事の平均品質が上がります。
これが回り回って紹介につながるので、営業活動は15年目のいまがいちばん少ない。
「作って終わり」は、作る側も終わらせている
納品して終わりのモデルは、システムを使い捨てにするだけでなく、作り手の経験も使い捨てにしていたんだと思います。
同じシステムと長く付き合うほど知識は複利で効いてくるのに、それを毎回リセットしていた。
週末のキャンプで「不便は道具と仕組みで解決する」と言っているのと、たぶん根っこは同じです。
消耗を根性でしのぐのをやめて、仕組みを変える。
15年かかりましたが、ようやく仕事でもそれができるようになってきました。
仕組みで解決する性分がキャンプでどうなるかはサイトについてでどうぞ。