先日こんな記事があがっていました。
今まで下請けだった中小のSIerがクライアントと直接取引が出来るようになってきたということだそうです。私も昔は何社かSIerにいて下請けっぽい仕事をしてたので、下請けのつらさはよく分かります。下請けという以外にも受託開発の世界ってなんでこんな訳の分からないルールでやってるんだろう、これって本当にお客さんが喜んでいるんだろうかという疑問をずっと持っていました。
その後私はSIerではなく自社サービスをやっている会社をいくつか経験した後に、実際に自分で起業し、開発の仕事を指名でいくつかもらえるようになりました。そういった経緯もあって、あの時思っていた疑問点を解消したかったし、もっと内製化されたWeb系企業のような形で受託開発が出来ないかと思い、受託開発のルールを少しずつ変えていったところ、ものすごく受託開発というものが楽しくなっていきましたし、お客さんも喜んでくれるようになりました。
ということで今回はうちの会社でやっている楽しく受託開発が出来るルールについて公開したいと思います。
月額制
最近流行ってきてますよね。「納品のない〜」に代表されるいわゆる月額制の受託開発です。やっぱり受託開発で一番歪んでいる部分って見積りして納品するという部分だと思うんです。特にうちみたいにWebサービス専門で新規サービスの立ち上げに特化してたりすると、何が正解か分からないので完成形も見えないですし、柔軟に変更を加えていかないとローンチ後のビジネススピードにもついていけないですよね。なので月額制です。とはいえふわっと持ち帰りで月額というのも分かりづらかったり、お客さんの納得感も必要なので工数の可視化の為にスクラムポイントを月額のポイントという形にして、細かく見積り、納品の形を取っていたりもします。納品物がプルリクエストって感じです笑
ちなみにだいたい週次くらいで打ち合わせとリリースを行っています。
営業は置かない
これもSIerあるあるですよね。ブランコの絵で有名な「顧客が本当に必要だったもの」でも書かれているように、営業が間に入ることでお客さんとの意識が大きくずれていきます。私もこれは何回か経験したというのもあったので、うちでは営業は置かないようにしています。エンジニアがコンサル的に入り、入口から開発までを全て担当するので、出来ないこと、設計や実装ボリューム、諸々のリスクについてもその場で全て答えることが出来るので、お客さんとの意識の乖離はほとんどおきません。お客さんも安心して任せてくれるので非常にやりやすくなりました。内製化された体制でもディレクターとエンジニアの間に営業が入るってことは当然ないので、当たり前の話だと思うんですよね。
ちゃんと断る
以前にも「それ、開発しないほうがいいですよ」で触れましたが、やりたくないではなくお客さんの為にならないことはちゃんと断るようにしています。昔やっていた受託開発でのモヤモヤポイントで、機能を増やすことで工数が増えて受託の売上も増えるっていう構造ってお客さんに取ってみたらいい迷惑ですよね。そういった感じで会社の利益を取るためにお客さんの不利益になることをしていくと、結果契約を切られたり信頼を失いますし、中長期での売上を失うことになります。ですので、例え今は会社の利益にならなかったとしてもお客さんの為にならないことはちゃんと断るようにしています。以下断ることがある例です(場合にもよることがあるので100%ではないです)。
- 使われない機能追加
- 予算に合わない大きな開発計画
- 安く買い叩こうとする発注内容
- コンペ(信頼いただいてから仕事をするので競争はしません)
- 常駐(エンジニアの質を担保するため。お客さん先に丸投げすることはありません)
- 納品型
- 下請け
受託開発が楽しい
上記だけではないですが、その他細かくルールを変えることで、今までの受託開発でモヤッとしていたポイントを解消し、お客さんとチームとして同じ方向を向けるようになったので受託開発というものがすごく楽しく出来るようになりました。もちろんサービス開発なので無理目なスケジュールもあったり、突発的な対応もあるので、決して楽ではなく大変な部分もありますが、新しいビジネスや価値を自分が納得した形で作れるという部分で辛くても前向きに頑張れる形にはなったのかなと思います。