全部を自社開発しない。SaaSと開発を組み合わせる業務改善へ
システム開発会社に相談すると、
「ではシステムを作りましょう」
という話になりがちです。
もちろん、独自システムが最適なケースはあります。
一方で、すでに高品質なSaaSが存在する領域まで、すべてを一から作る必要があるのか。
最近、私たちはこの問いを以前より強く意識するようになりました。
テイルウインドでは今後、「すべてを自社開発する」ことを前提にせず、既存SaaS、生成AI、業務自動化、外部サービス連携、独自開発を組み合わせて業務改善を提案する方向をより明確にしていきます。
AIで開発速度は上がった。しかし、作れる量には限界がある
生成AIやAIエージェントの進化によって、ソフトウェア開発の生産性は大きく変わりました。
私たち自身も、複数のAIエージェントを活用しながら開発を進めています。
実際、ある時期には3つのプロジェクトを並行し、合計12ほどのAIエージェントを動かしながら開発を進めていました。
実装自体は非常に速く進みます。
しかし、そこで改めて分かったことがあります。
AIが増えても、最終的に判断する人間の数は増えない。
ということです。
AIが実装したコードを確認する。
仕様との整合性を見る。
テスト結果を確認する。
CIの失敗原因を追う。
複数の変更がぶつかっていないか確認する。
次に何を実装するか判断する。
AIによって実装量が増えるほど、確認・判断・管理の量も増えていきます。
結果として、一時的に自分自身の処理能力を超えてしまい、体調を崩して休むことになりました。
この経験から、開発について改めて考えるようになりました。
開発のボトルネックはコードを書くことだけではない
AI駆動開発というと、
「どれだけ速くコードを書けるか」
に注目されることが多いように感じます。
しかし、実際のシステム開発には、
- 要件定義
- 設計
- テスト
- レビュー
- セキュリティ
- CI/CD
- 監視
- 障害対応
- ドキュメント
- 問い合わせ対応
- 運用保守
など、実装以外にも多くの工程があります。
AIによって実装速度を上げることはできます。
一方で、これらすべての工程が同じ速度で効率化されるわけではありません。
むしろ実装できる量が増えた結果、品質を担保するための管理コストが増えることもあります。
特に小規模な開発会社では、ここを無視することはできません。
一から作ることが、本当に顧客にとって最適なのか
例えば、予約システムの相談を受けたとします。
基本的な機能だけであれば、
- 予約枠管理
- 予約受付
- 変更・キャンセル
- メール通知
- 管理画面
- カレンダー表示
などを作れば、予約システムとして動かすことはできます。
しかし、実際のサービスとして考えると、
- 複数スタッフへの対応
- 営業時間・休業日の管理
- Googleカレンダー連携
- Outlook連携
- 顧客情報管理
- 通知エラーへの対応
- セキュリティ
- バックアップ
- 障害対応
- 継続的なアップデート
なども必要になります。
この領域には、すでに長期間運用され、多くの企業で利用されているSaaSが存在します。
そうであれば、一から同じ機能を作るよりも、既存サービスを利用した方が、
コスト、品質、導入スピード、保守性
の面で合理的な場合があります。
「自社で作れるか」ではなく「何が最適か」で考える
これまでは、
技術的に作れるなら自社で作る
という発想になりやすい部分がありました。
現在は、
顧客にとって最適な方法は何か
から考えるようにしています。
例えば、業務改善の相談があった場合。
まず業務内容を整理します。
その後、
既存SaaSで解決できるか
すでに適したサービスが存在するなら、それを比較・選定します。
SaaSに少し機能を追加すればよいか
APIやWebhookなどを利用して、他システムと連携します。
小規模なツールを追加すればよいか
既存SaaSでは不足する部分だけを個別に開発します。
独自開発が必要か
業務固有の要件が多い場合は、一からシステムを開発します。
このように、最初から答えを決めないことが重要だと考えています。
SaaS企業とのアライアンスを増やしていく
今後、私たちは実績のあるSaaS事業者やサービス提供企業との連携も増やしていく予定です。
例えば予約管理であれば、予約システムを専門に開発・運用している企業があります。
その企業が長年蓄積してきた、
- 機能
- 運用ノウハウ
- セキュリティ
- サポート体制
- 導入実績
を活用しながら、私たちは顧客側の業務整理や導入支援を担当します。
すべてを自社で抱えるのではなく、
それぞれの領域に強い企業と組みながら、顧客に最適な構成を作る。
という考え方です。
SaaSを紹介するだけではない
ここで目指しているのは、単純なSaaS販売ではありません。
私たちが提供したいのは、
- 現状業務の整理
- 課題整理
- 要件整理
- SaaS比較
- 製品選定
- 初期設定
- データ移行
- 運用設計
- 操作支援
- API連携
- 追加開発
- 導入後の改善
までを含めた支援です。
SaaSを契約しただけでは、業務改善につながらないこともあります。
重要なのは、
どの業務に、どのように組み込むか
です。
ここは、業務整理からシステム開発まで対応できる会社だからこそ価値を出せる領域だと考えています。
SaaSと独自開発は対立するものではない
SaaSと独自開発は、どちらか一方を選ばなければならないわけではありません。
例えば、
予約管理 → 既存SaaS
顧客管理 → 既存CRM
社内独自処理 → 個別開発
データ連携 → API
集計 → 自動化
という構成もできます。
このように既存サービスと独自開発を組み合わせることで、ゼロからすべてを作るよりも、短期間・低コストで業務に合ったシステムを構築できる場合があります。
一方で、
- 特殊な業務フロー
- 長期間の利用を想定
- SaaSでは対応できない要件
- データ管理上の制約
- 独自機能が多い
といった条件では、独自開発の方が適していることもあります。
重要なのは、最初から方法を決めないことです。
技術力は「作るため」だけに使うものではない
既存SaaSを活用すると、
「開発会社として技術力が必要なくなるのでは」
と思われるかもしれません。
私たちは逆だと考えています。
技術が分かるからこそ、
- SaaSで十分なのか
- API連携が可能なのか
- 将来的に拡張できるのか
- セキュリティ上問題がないか
- 足りない部分はどこか
- 独自開発に切り替えるべきか
を判断できます。
つまり、技術力の使い方を、
すべてを自分たちで作るため
だけではなく、
何を作り、何を作らないかを判断するため
にも使っていくということです。
得意なSaaS領域を少しずつ増やす
今後は、すべてのSaaSを網羅しようとは考えていません。
まずは特定の領域について理解を深めます。
例えば、
- 予約・日程調整
- CRM
- 勤怠管理
- ワークフロー
- 問い合わせ管理
などです。
各領域について、
- 主要サービス
- 得意な業種
- 料金
- API
- 導入方法
- 運用上の注意点
- 向いている会社
- 向いていない会社
まで把握する。
さらに、サービス提供企業とも関係を作る。
こうした知見を少しずつ蓄積することで、
「どのサービスを導入すればいいのか分からない」
という段階から相談できる会社を目指します。
システム開発会社から、業務改善のパートナーへ
私たちはこれからもシステム開発を続けます。
AIを活用した開発もさらに進めます。
一方で、
作れるから作る
という判断は減らしていきます。
既存SaaSで十分ならSaaSを使う。
既存ツールを組み合わせれば済むなら、それを使う。
少しだけ足りなければ、その部分だけ作る。
独自システムが必要なら、本格的に開発する。
目指しているのは、
「システムを作ってほしい」という相談に対して、そもそも作る必要があるのかから考えられる会社
です。
AIによって、以前よりも多くのものを作れるようになりました。
だからこそ逆に、
何を作らないかを決めること
がこれまで以上に重要になっていると感じています。
すべてを自社で抱えることではなく、専門企業や優れたサービスとも連携しながら、顧客にとって最適な方法を選ぶ。
それが、これからの私たちの業務改善支援の一つの方向性です。