受託開発の会社が自社でSaaS事業をやる理由

パーティーハード株式会社は、Webシステムの受託開発やAIソリューションの提供を手がけるソフトウェア開発会社です。受託開発事業を軸に据えながら、自社プロダクトとして金融機関情報のWebAPIを提供する Ginconnect や、HTMLからPDFを生成するSaaS Printgraph を提供しています。

受託開発事業は、開発工数に対する対価を受け取るため、短期間での売上や利益の見通しを立てやすい事業モデルです。一方、自社SaaSの運営には事前の機能開発投資が必要であり、公開後も継続的な改修やインフラの維持費用が発生します。短期的な収益の安定性だけを重視するのであれば、受託開発に専念するほうが財務上の選択肢として自然かもしれません。それでも当社が自社SaaSを運営し続ける理由は、自ら事業の損益責任を負い、プロダクトを改修し続ける過程でしか得られない実践知があるからです。

「作って納品・保守」だけでは見えない壁

受託開発において一般的な「要件定義に基づき仕様書通りに実装して納品する」という進め方には、検証の遅れという構造的な問題が伴います。どれほど精密に要件を詰めて開発を進めても、実際に利用者が日常業務で使い始めるまでは、その機能が現場の課題を解決しているかを確かめられません。結果として、多大な開発費用を投じて実装した機能が、業務の現場ではほとんど開かれない事態も起こり得ます。

納品後の保守運用を請け負う場合であっても、契約範囲が障害対応や定常的なインフラ監視にとどまっていると、事業の改善に踏み込んだ提案は困難になります。システムの稼働率を維持する業務と、利用ログを分析して画面や機能を改修する業務とでは、評価基準も必要な情報も異なるためです。

さらに、サービスを自社で継続運営していなければ直面しにくい課題もあります。運用期間が長くなるにつれて利用者の使い方が変化し、初期の想定とは異なる操作手順が定着する現象です。その変化へ対応するために場当たり的な機能追加を繰り返すと、画面の操作体系が複雑化し、かえって現場の作業効率を損ねてしまいます。このような長期運用に伴う課題は、仕様書に従ってコードを納める立場にいるだけでは実感しにくい領域です。

自社SaaSから得られる「プロダクトを育てる」リアルな視点

自社SaaSの運営では、新規登録数の推移に加え、初期設定時の離脱率や月次の解約率といった事業指標を日常的に追跡しています。開発した機能が狙い通りに使われているかをログや分析ツールで計測し、期待した成果が得られなければ、原因を調査して画面設計や導線を見直す作業を繰り返します。

実際、Printgraph の初期仮説に基づいて実装した機能を、公開後のアクセスログや問い合わせ内容を踏まえて削ぎ落とし、画面の操作フローを簡素化した事例がありました。開発側が有用だと見込んだ入力項目であっても、現場の帳票出力業務では余計な手間に映る場合があります。自社SaaSの開発を通して、機能の実装そのものを目的とせず、その機能が業務負荷の軽減につながっているかを起点に考える姿勢が定着しました。

机上の要件定義だけで最初から過不足のない仕様を確定させることには限界があります。小さく実装して実際の利用状況を確認し、得られた事実から次の改修内容を決める仮説検証のサイクルは、自らプロダクトの損益責任を負う運用の中で身についたものです。

技術面への還元 中長期運用を見据えたアーキテクチャ設計

自社SaaSで得た運用の知見は、受託案件におけるシステムの設計思想や技術選定にも直接反映されています。初期リリースの実装段階から、数年後の機能追加やライブラリ更新を見据えたアーキテクチャを提案できるようになりました。

バックエンドの開発ではPHPを採用し、システムの規模やドメインの複雑さに応じてSymfonyやLaravelを使い分けています。迅速なプロトタイプ構築や管理画面の立ち上げにはエコシステムの充実したLaravelの生産性を活かし、長期的な変更耐性や複雑な業務ルールの分離が求められる基幹連携システムにはSymfonyの疎結合な設計を採用します。受託開発では初期納期の遵守が優先されやすい傾向にありますが、設計の整理を怠ると、運用開始から半年足らずで機能追加の工数が跳ね上がります。当社自身が自社プロダクトで継続的な機能改修を続けているため、どこを疎結合に切り分け、どこを簡潔に保つべきかという判断基準を持っています。

フロントエンドにはNextjsやVueを採用し、画面描画の速度や操作性の向上を図っています。画面遷移の滑らかさや直感的なUI設計は、SaaSの解約率に直接結びつく要素です。ただし、過剰に抽象化された状態管理を導入すると、後々の改修速度を落とす原因になります。NextjsやVueの特性を活かし、表示速度の維持と実装の保守性を両立させる構成を選定しています。

外部ライブラリのメジャーバージョンアップやクラウド基盤の変更に伴う保守負担も、自社プロダクトで継続的に経験しています。事前に更新しやすいディレクトリ構造を保つことや、回帰テストをどの粒度で整備しておくべきかという経験則があるため、クライアントに対しても運用負荷の低い構成を提案できます。

受託案件への還元 クライアントの事業パートナーとしての開発

自社SaaSで培った視点は、受託開発におけるクライアントとの要件定義や仕様策定の進め方にも表れます。発注者から提示された要件をそのまま実装するのではなく、業務効率化や売上向上に寄与するかどうかを検討し、ときには実装を見送る代替案を提示します。

生成AIの普及によって、仕様書どおりにコードを書く作業自体の工数は圧縮されつつあります。開発ツールを導入すれば、定型的なCRUD処理や単機能の実装は短い時間で出力できます。しかし、AIツールに指示を出せる状態になったとしても、「そもそもどの機能を作るべきで、どの機能を削るべきか」という投資対効果の判断は自動化されません。

たとえば、新規事業の立ち上げを控えた顧客からの相談において、要望をすべて実装しようとすると予算やスケジュールが超過するケースがあります。そうした場面では、自社SaaSの立ち上げ経験をもとに、最初の検証に必要な機能の絞り込みを提案します。「この帳票出力機能は初期フェーズでは手動のCSV出力で運用し、月間利用件数が100件を超えた段階で自動化する」といった優先順位づけを行うことで、限られた投資額の中で事業の立ち上げを早められます。

エンジニア自身が解約率やサーバー運用費といった事業数値を把握しているため、プログラムの稼働確認にとどまらず、利用者の定着や作業時間削減につながっているかを意識して実装を進めます。仕様書に書かれた文面の実現に閉じることなく、業務課題の解決を見据えて仕様の調整を行います。

受託開発で多様な業界の業務要件に触れ、新しい技術要素を取り入れる経験は、自社SaaSの機能改善にも活かされています。受託案件と自社プロダクトの間で設計や運用の知見を還流させることが、当社の開発基盤となっています。

事業をともに成長させる開発会社として

受託開発会社が自社SaaSを運営する価値は、売上経路の分散だけにとどまりません。自費を投じてサービスを立ち上げ、ユーザーの反応を見ながら改善を続けた経験が、コードを納品して完了とする姿勢を改めさせます。

パーティーハード株式会社は、自社SaaSの運営で得られた運用設計の勘所と事業指標への感覚を、受託開発のすべての案件に注ぎ込んでいます。新規事業のシステム構築や既存業務システムの刷新を検討される際は、画面やAPIの受託製造にとどまらず、事業の運用段階を見据えた開発チームとしてご相談いただければ幸いです。