当社は受託開発を生業としています。それでも多くの企業への率直な助言は「まず既製品を検討してください」です。受託開発が費用に見合うのは、特定の状況に限られます。
既製品が正解であることが多い理由
市販の会計パッケージは数千社に使われ、あなたが遭遇することのない数千の不具合がすでに修正されており、その開発費は全顧客で分担されています。自社で作れば数千万円かかるものを、年間数万円で使えます。
金額より重要な点があります。既製品は来週から使えます。受託開発は最初の実利用者が触るまでに3か月から9か月かかります。その間も事業は動かし続けなければなりません。
本当に受託開発が必要な4つの兆候
1. 業務プロセス自体が競争優位になっている
受注処理のやり方が競合より30%速いのに、既製ソフトがそのソフト自身の手順を強制してくるなら、お金を払って優位性を捨てたことになります。これが自社開発を選ぶ最も強い理由です。
逆に、プロセスが独自なのは単なる経緯によるもので何の利点も生んでいないのであれば、標準に合わせざるを得なくなることは、悪いことではなく良いことです。
2. すでにパッケージ製品の限界に達している
最も分かりやすい兆候は、社員が公式のシステムを使いながら、システムで扱えない部分を別の表計算ファイルで管理していることです。その表計算のほうが実質的な正の情報源になり、ソフトウェアは転記先でしかなくなったとき、代替を検討する時期です。
3. 人数に比例してライセンス費が不合理に膨らむ
ユーザー単位課金の製品は多くあります。20人なら妥当です。300人になると、年額が自社開発の一括費用を超えることがあります。その分岐点がどこにあるのかを、到達してからではなく、事前に計算してください。
4. 本当の問題は5つのシステムが連携していないこと
問題が「システムがない」ことではなく「5つのシステムが分断されている」ことである場合、作るべきは6つ目のシステムではなく、それらをつなぐ層であることがほとんどです。
最もよくある損失の形は、すでにあるものを作り直すこと
受託開発の失敗は、技術力の問題ではなく、すでに存在してより良く動いているものを作り直したことに起因する場合が多くあります。認証、権限管理、メール送信、帳票出力、決済、ファイル保管。いずれも成熟した安価なサービスとして手に入ります。
実務的な基準として、自社の事業に固有の部分だけを作り、それ以外はライブラリやサービスを使ってください。健全なプロジェクトでは、コードの20〜30%が本来の業務ロジックで、残りは既存部品の組み立てです。
契約前に決めておくべき3つの問い
ソースコードは誰のものか
これは率直に確認し、契約書に明記してください。ベンダーがコードを保持する場合、恒久的に囲い込まれます。保守費としていくら提示されても払うほかありません。他社が触れないからです。TRIUNITECHはソースコードを100%納品します。どのベンダーに対しても同じ条件を求めることをお勧めします。
納品後は誰が運用するのか
ソフトウェアは建物と違い、工事が終われば完成というものではありません。セキュリティパッチ、OS変更に伴う更新、後から現れる不具合の修正が必要です。3年間の運用費は、通常、初期構築費の40〜60%になります。提案書がこの点に触れていないなら、その提案書は不完全です。
関係が終わるとき何が起きるか
データは書き出せるのか、その形式は何か。別のチームが引き継げるだけの資料があるのか。関係が良好なうちに確認してください。悪化してからでは遅すぎます。
最も安く、最も省略されがちな一手
開発に入る前に、ノーコードツールで2週間だけ試作してください。表計算ソフトでもAirtableでも構いません。試作が課題の80%を解決してしまうなら、そもそもソフトウェア開発は不要かもしれません。試作によって本当に難しい部分が浮かび上がったなら、間違った方向に数か月歩く手間を省いたことになります。
開発するなら、段階に分ける
システム全体で9か月の契約を一括で結ばないでください。6〜8週間の区切りに分割し、各区切りの終わりに実際に使えるものが出来上がるようにします。これで三つのものが得られます。進捗率の報告ではなく目に見える成果、要件の理解が誤っていたと分かったときに方向を変えられること、そしてベンダーの成果が不十分なときに、プロジェクト全体ではなく一区切り分の損失で止められることです。
インフラ構築とソフトウェア開発の実務経験に基づいて執筆しています。スポンサーや製品の宣伝は含みません。