はじめに
みなさん、経営陣からこのような相談が来ることはありませんか？
- この課題を解決するためにシステム化しよう
- 進め方についてエンジニアの意見を聞きたい
- あわよくば、内製した仕組みを商品として売りたい
私も、業務効率化を名目に「まず自社開発から始めたい」という相談を、これまでに何度か受けてきました。よくあるパターンは次のとおりです。
- 特定の手作業に工数が集中している
- 同業他社が使っているSaaSがあるが、ランニングコストが気になる
- 自社で作れば安く済むのでは、という期待がある
- 将来的には他社にも提供したい、という構想もある
このようなケースに対してすぐに開発を始めてしまうと、
- 本来狙っていた効果が得られない
- 開発費用を回収できない
- 外販するために作り直す
というようなリスクがあります。
今回はそういったことにならないために私が経営陣の方と会話・提案する際の観点を共有したいと思います。
この記事を読んで得られること
- 効率化目的と商品化目的で、設計判断がどう変わるか
- いきなり自社開発に入る前に、既製サービスで検証する理由
- 相談段階で整理すべき「3段階の進め方」
- 自社開発 と 既製サービスの比較を誤らないための確認事項
本記事は、複数の相談で共通していた論点を整理したものです。特定の会社・プロジェクト・サービスを前提とした内容ではありません。
相談の典型パターン
相談を分解すると、だいたい次の構図に収まります。
- 現状の課題：手作業・転記・確認作業に時間がかかっている
- 想定する解：WebツールやSaaSの導入、もしくは自社開発
- コスト感：既製サービスは月額または年額で数十万円規模
- 社内の意向：まず自社で試作 → うまくいけば商品化も視野
技術選定の相談に見えて、実は投資判断の相談でもあります。「自社開発の方が安いのでは」という発想は自然ですが、開発・保守・引き継ぎまで含めると、必ずしもそうとは限りません。
観点1：効率化がメインか、サービス展開がメインか
ここは、今後の施策すべてに関わる分岐点です。
| 最終ゴール | 優先すること | 設計上の違い |
|---|---|---|
| 自社業務の効率化 | 工数削減・ミス削減 | 自社の業務フローに合えば十分 |
| 将来的な商品化 | 再現性・拡張性・保守性 | マルチテナント、権限、課金設計が必要 |
効率化が主目的なら、自社の運用に合うかが最優先です。商品化まで見据えるなら、最初から「他社の環境でも動くか」を意識した設計が必要になり、初期コストは跳ね上がります。
相談の段階では、両方を同時に追うと判断がブレやすい。私は、まず初期段階は自社効率化と明示してから進めることを提案しています。商品化はそれ以降の選択肢として残す、という整理です。
観点2：まず既存のサービスを使えないか
既に市場に類似サービスがあるなら、いきなり自社開発に入る必要はありません。最終的に使わなくても、次の目的で試す価値があります。
- 本当に工数が減るか
- 現場の負担・問い合わせ・エラーがどう変わるか
- 自社開発に移る場合、何が足りないのかが具体的に分かる
費用感の比較
既製サービスを1年間使った場合のコストは、だいたい数十万円規模です。自社開発を数ヶ月かけて立ち上げ、保守担当が変わるたびに引き継ぎコストが発生する——という前提と比べると、効果検証のための投資としては現実的なラインになることが多いです。
金額の比較だけでなく、「検証期間中に何を学べるか」も含めて判断します。
検証期間に計測しておく指標
既製サービスを使う期間は、単なる「お試し」ではなくデータを取る期間にします。
- 対象業務にかかる時間
- 修正・差し戻しの回数
- 問い合わせ件数
- ツール利用率
- 業務上のエラー件数
これらを計測しておけば、「投資に見合う効果があったか」の判断材料になります。将来的に商品化する場合も、「自社でどの程度の改善効果があったか」という実績データとして説明に使えます。
既製で十分な場合も、失敗ではない
検証の結果、既製サービスで十分な効果が得られ、費用対効果も見合うなら、そのまま運用するのが合理的です。「自社開発しなかった＝負け」ではありません。目的は効率化であり、手段は開発に限りません。
一方、機能不足・ランニングコスト・自社独自の運用への非適合が見えてきたタイミングで自社開発へ移行する方が、投資判断として進めやすいです。要件が曖昧なまま開発を始めるより、はるかに安全です。
3段階の進め方
相談への返答として、私はだいたい次の3段階を提案します。
① 現状のボトルネックを整理する
ツール導入以前に、本当の詰まりどころを特定します。
- 工数がかかっているポイントはどこか
- システム化でしか解決できない課題なのか
- テンプレート化・マクロ・既存機能の活用で改善できる余地はないか
全部をシステム化で解決しようとしないことも重要です。低コストで改善できる部分を先に潰すと、自社開発が必要な範囲が小さくなります。
② 既製サービスで一定期間検証する
上記の指標を計測しながら、既製サービスを一定期間運用します。この段階では技術選定やアーキテクチャ設計には入りません。効果と要件の発見が目的です。
③ 効果が確認できた段階で、最小構成から自社開発する
自社開発に移るのは、この段階です。必要な機能・不要な機能・既存システムとの連携方法が、検証データに基づいて見えているはずです。ここで初めて技術選定やAPI設計を議論するのが、無駄な開発を避ける近道です。
エンジニアが確認すべき追加質問
相談を受けたら、技術スタックの前に導入条件を確認します。よく使う質問は次のとおりです。
既製サービスは、比較的そのまま導入できるのか。それとも、別途サイト改修やカスタマイズが前提なのか。
この一点で、自社開発との比較が大きく変わります。
| 既製サービスの性質 | 実質コスト | 自社開発との比較 |
|---|---|---|
| タグ埋め込みで動くSaaS | 利用料 + 初期設定 | 開発より安く試せる |
| 既存システム改修が前提 | 利用料 + 改修工数 | 自社開発との差が縮まる |
| データ形式が自社と非互換 | 利用料 + 運用の手作業 | 自社開発の必然性が上がる |
「月額いくら」と聞こえても、既存システム側の改修費用が別途かかるなら、トータルコストは一気に変わります。
アンチパターン
「自社開発の方が安い」で始める
初期開発費だけで比較すると、自社開発が安く見えがちです。保守、障害対応、担当者変更時の引き継ぎ、セキュリティ更新——運用コストを含めると、判断は逆転することがあります。
効率化と商品化を最初から同時に設計する
「ついでに売れるように作っておこう」は、要件と工数を膨らませます。初期段階は自社効率化に集中し、商品化は効果が出てから検討する方が、チームの負担も少ないです。
技術選定の相談に、技術選定だけで答える
フレームワークやライブラリの名前だけ返すと、相談者の本当の問い（進めていいのか、いくらかかるのか）に答えていません。エンジニアの価値は、手段の前に判断軸を渡すことにあります。
まとめ
「効率化したい、システム化しよう」という相談は、技術の話に見えて、実は目的・投資・段階の話です。
整理の要点は次の3点です。
- 最終ゴールを先に決める
- 既製サービスで検証し、データを取る
- 効果と要件が見えてから、最小構成で自社開発する
引き継ぎ先が不明なプロジェクトほど、いきなり作り始めない判断が、未来の自分と仲間を助けます。エンジニアは、最初からコードを書く人ではなく、進め方を整理する人として関われる場面が多い。
そういう相談の典型例が、本記事のテーマです。
本記事で一番伝えたいのは、システムを作ることではなく、要求を整理することです。エンジニアは「どう作るか」を考える機会が多い職種です。一方で、実務では「本当に作るべきか」「まず何を検証すべきか」を整理する場面も少なくありません。要求定義の段階で判断軸を共有できることも、エンジニアとして価値を発揮できるポイントの一つだと考えています。そして、これらを整理することで、結果として、その後の設計や実装もより目的に沿ったものになります。