この記事でわかること
-
開発の土台を整えることが、AI時代の開発をどう加速させるか
-
開発生産性を最大化するために必要な「AI設計の規律」
-
AI時代に市場価値を高めるための「専門性」と「柔軟な思考」のバランス
生成AIの爆発的な進化により、コーディングのハードルは劇的に下がりました。しかし、AIの恩恵を最大限に受けられるかどうかは、それまでに積み上げてきた開発の土台で決まります。
サービスモデル事業向けの収益管理SaaS『Scalebase』を展開するScalebase株式会社は、創業以来、CI・アーキテクチャ・型システムといった開発基盤を地道に整えてきました。AIが台頭した今、その積み重ねが開発のスピードと品質を大きく押し上げています。
本記事では、同社のVPoE・村濱一樹氏とVPoP・坂口恵太氏にインタビュー。地道に整えてきた開発基盤が、AI時代にどうフィットしたのかを聞きました。
坂口 恵太
Scalebase株式会社 執行役員／VP of Product
2016年に株式会社ワークスアプリケーションズに入社。営業およびプリセールスとしてERPシステムの提案支援・要件定義に従事。2020年に株式会社ビットキーに入社し、新規プロダクトの企画・商品化を担当。2021年にアルプ株式会社（現:Scalebase株式会社）に入社しカスタマーサクセスを経て、現在はプロダクトマネジメントを担当。
【X（旧Twitter）】：https://x.com/syaka003?s=20
村濱 一樹
Scalebase株式会社 執行役員／VP of Engineering
2011年に大手通信設備会社にネットワークエンジニアとして入社。その後、ウェブシステム開発会社に転じフルスタック開発や、開発プロセス改善に従事。2015年に独立、SaaSを利用したアジャイル開発を中心に活動するとともに、エンジニアコミュニティにも積極的に参加。2019年にアルプ株式会社（現:Scalebase株式会社）に入社し、開発およびエンジニアリングマネジメントを担当。
【X（旧Twitter）】：https://x.com/muraaaaa_san?s=20
Scalebase株式会社
「あらゆる企業に、フルスイングを。」をミッションに、既存の販売管理システムでは管理が困難であった、サービスモデル事業向けの顧客・見積・契約・請求・売上を一気通貫で効率化する『Scalebase』シリーズを提供している。
目次
地道に整えてきた土台が、AI時代にフィットした
まずは、お二人のこれまでのキャリアと、現在Scalebase社で担っている役割について教えていただけますか。
私は2016年にワークスアプリケーションズに入社し、ERPシステムの営業やプリセールスからキャリアをスタートしました。その後、プロダクト企画・商品化を経て、2021年に当社（当時はアルプ）へ入社しました。カスタマーサクセスを経験した後、現在はVPoPとしてプロダクトマネジメント全般を担当しています。
ビジネスサイドでの豊富な知見があり、現在はプロダクトの意思決定を担うVPoPなんですね。村濱さんはいかがでしょうか。
私は2011年にネットワークエンジニアとしてキャリアを始め、ウェブ開発、そして独立してフリーランスとしてSaaSのアジャイル開発などを行ってきました。
2019年に当社に入社し、現在はVPoEとして12名のエンジニア組織を統括しています。バックエンドはScala 3、フロントエンドはTypeScript/Next.jsという構成で、型システムとCI/CDを中心に据えた開発基盤を整えてきました。
現在は3つの開発チームとSREチームという体制なのですね。以前から開発基盤にかなり力を入れてきたと伺いましたが、どのような考え方でしょうか。
もともとAIを意識していたわけではなく、複雑なドメインを正確に扱うために、DDDに基づくモジュラーモノリス構成で境界を明確にし、型システムで入力値の検証や副作用の分離を徹底してきました。結果的に、AIが既存コードを参照して書くコードの質が高くなりましたし、問題があってもCIで検知できる。地道にやってきたことが、AI時代に効いている実感があります。
AIのために整えたのではなく、もともと整えていたものがAIと相性が良かった、という順番なんですね。
そうです。アーキテクチャの境界をしっかり切ってきたので、AIに書かせたコードの影響範囲も自然と絞れています。逆に境界が曖昧だと、AIが生成したコードが予期しない箇所に影響してしまう。結果として「どこに何があるか分かりやすい」「変更の影響が読みやすい」というコードベースになっていて、新しく入ったメンバーの立ち上がりも早いです。
リリースから7年近くが経ち、Scalebase本体はかなり巨大なコードベースになっています。正直、これだけの規模になると普通は手を入れるのが怖くなる。でも、境界が明確で型に守られているので、大きな変更にも踏み切れますし、AIにリファクタリングを任せることもできる。積み重ねが負債ではなく資産として機能しているのは、土台を整えてきたからだと思います。
ドメイン知識をどうコードで表現するか
Scalebase社が扱う「請求・契約管理」というドメインですが、エンジニアとしての力量が試される非常に難易度の高い領域だと伺いました。
請求ドメインの難しさは、「計算の正確性」と「ビジネスルールの複雑さ」の両立にあります。契約のライフサイクルだけでも9つのステータスがあり、それぞれで許可される操作が異なります。
「有効化待ち」から「有効」への遷移で何が起きるかといったルールをすべて型とコードで表現しなければ、即座に請求漏れなどの障害に繋がります。
プロダクト概要を見ると、見積もりから売上管理まで非常に広い範囲をカバーされていますね。 ユーザー数の増加やプランの多様化によって、さらに管理の複雑性が増していくわけですか。
その通りです。特にお金を扱うプロダクトにおいて、その複雑さを曖昧にするのは致命的です。 また、SaaSの請求では月の途中のプラン変更による日割り計算や過去に遡っての契約修正など、「いつ時点の状態か」という「時間軸」の制御が常に問題になります。
単純なデータの更新では済まない、履歴の管理が必要になるわけですね。
これらを正確に扱うには、単純なCRUD（作成・読み取り・更新・削除）では対応できない「イミュータブル（変更不能）な履歴データ」と「状態復元」の設計が必要になります。
こうした複雑なドメイン知識を、どうやってコードの構造に落とし込んでいるのでしょうか。
まず型でドメインの制約を表現します。「この値は必ず正の数」「このステータスからはこの操作しかできない」といったルールを型レベルで縛る。すると、ルール違反はコンパイル時に弾かれるので、実行時のバグが大幅に減ります。
この考え方自体はどの言語でも応用できますし、AIがコードを生成するときにも型の制約に沿ったコードを出してくれるので、精度が上がります。
AIに書かせても、影響範囲を絞れる開発基盤
AIがコードを一瞬で生成する時代になり、「深い専門性」の価値について議論が分かれています。Scalebase社ではどのようなスタンスでAIと向き合っていますか。
2025年の中頃、会社として明確に「AIシフト」を決断しました。開発ツールへの投資には予算上限を設けず、Claude Code、Devin、Cursor、GitHub Copilot、Geminiなど、複数のツールを用途に応じてフル活用しています。
要件定義からリリースまで、あらゆるフェーズでAIを活用しているんですね。AIに書かせたコードの品質は、どう担保していますか。
まずCIが通らなければマージできない、という大前提があります。その上で、AIが生成したコードをレビューするとき、アーキテクチャの境界を超えていないか、型の使い方が正しいかをチェックします。土台が整っていると、このレビューの観点が明確になるんです。「何を見ればいいか」が分かっているから、AIの出力を素早く判断できます。
開発基盤がしっかりしていると、AI活用のスピードも品質も上がると。
プロダクトマネジメントの観点でも同じです。定型コードやテストの雛形はAIに任せますが、ドメインモデルの境界設計やアーキテクチャ判断は人間が責任を持ちます。AIに任せられる領域が増えた分、人間はより上流の設計に集中できるようになりました。
型に守られているから、大規模なリファクタリングもできる
AIによる高速なコード生成を、現場のエンジニアが安心して受け入れられている理由は何でしょうか。
型システム、自動テスト、CI/CDが整っているのに加えて、DDDで境界が切られた見通しの良いコードベースがあることが大きいです。型に守られていると、大規模なリファクタリングにも踏み切れます。変更の影響範囲がコンパイル時に分かるので、AIに大きな書き換えを任せても、壊れたらすぐ分かる。だから攻めた改善ができるんです。
「壊れたらすぐ分かる」から、攻めた変更ができる。それは心強いですね。
逆に、アーキテクチャが整っていない状態でAIに頼りすぎると、短期的には速くても長期的にはメンテナンス性を損なうリスクがあります。「堅牢だからこそ、速い」。この順番が大事です。
生産性が上がったからこそ、改めて「作る順番」も重要になりそうですね。
私たちは、まずイシューをAIと一緒に作る「仕様駆動」を取り入れています。 AIで生産性が上がるとつい「作りすぎてしまう」罠にハマりやすいのですが、本当に必要なのは「価値を届けること」。 なにをやるかをきっちりIssueに書くことからスタートするんです。
「速く作れる」からこそ、あえて立ち止まって「なぜ作るか」を問う。 要件ヒアリングからコード調査、テンプレート準拠のIssue生成までAIと対話しながら進めるフローは、非常に合理的ですね。
効率化のためにAIを使いつつ、判断の主体は人間であり続ける。何かあったときに戻せる「可逆性」と、すぐ直せる「アジリティ」を型システムとCIで担保した上で、積極的にAIを活用する。この「堅牢さと速さのバランス」を設計できることが、AI時代のエンジニアに求められていると思います。
積み上げてきたものが、AIの出力品質を底上げしている
これまで積み上げてきた開発基盤が、AIの出力品質にも影響しているという話がありました。もう少し具体的に聞かせてください。
AIは既存のコードベースを参照してコードを生成します。つまり、既存コードの設計が良ければAIの出力も良くなるし、悪ければ悪いパターンを踏襲してしまう。私たちのコードベースはDDDで境界が明確で、型で制約が表現されているので、AIがそれに沿った質の高いコードを出してくれます。AIのために整えたわけではないのですが、結果的にAIとの相性が非常に良かったということですね。
意図せず積み上げてきたものが、AI時代に返ってきているんですね。技術選定の基準も変わってきていますか。
変わっています。今は「AIにとって扱いやすいか」「堅牢に書けるか」「エコシステムが充実しているか」の3点を見ています。gRPC（※2）のようにスキーマから型が自動生成される技術は、AIとの相性が非常に良い。AIを前提にした技術選定ができるのも、開発基盤を深く理解しているからこそだと思います。
AIが型情報を利用して高精度なコードを出せるよう、gRPC※のようにスキーマから型が自動生成される技術を戦略的に選ぶ。これも、技術の深層を理解しているからこそできる意思決定です。
※gRPC……Google社が開発した高速な通信規格。設計図から各言語のコードを自動生成できるのが特徴。
実際の指標にも成果が表れているんですね。
これまで整えてきた開発基盤のおかげで、AIに任せられる領域が広がっています。その分、エンジニアの守備範囲も広がっていて、PdMの領域や顧客のもとへ足を運ぶなど、「コードを書く」以外のことに時間を使えるようになった。地道に土台を作ってきたことが、こういう形で活きるとは思っていませんでした。
「書く」から「届ける」へ。AIと共創し、顧客価値に即応する開発組織
最後に、これから専門性を高めようとしているエンジニアや、キャリアに迷うエンジニアの方々へ向けてメッセージをお願いします。
最も大切なのは「変化を楽しむ」ことです。「コードを書く」ことがエンジニアの価値だった時代から、「プロダクトで価値を届ける」ことが求められる時代へ。AIがコードを書いてくれるなら、自分は何をするか。仕様を考える、顧客と話す、チームを動かす。
やれることが広がっているこの変化を「面白い」と感じられるかどうかが、分かれ目だと思います。
AIをパートナーとして迎え、自身の可能性を拡張させていく姿勢こそが、これからのロールモデルになる。お二人の話を伺い、地道に積み上げてきたものが、AI時代に花開くのだと強く感じました。
最終的には、「堅牢な基盤の上で、顧客の声にすぐ応える」開発組織を作りたいですね。AIに任せられるものは積極的に任せ、エンジニアの手が空いた分、「本当にこれで価値が届くか」を考える時間に充てていく。そうして、要望をもらってすぐ形にして喜んでもらえるサイクルを、チームで加速させていくべきだと考えています。
速さだけを追い求めるのではなく、堅牢な開発基盤があるからこそスピードが出せる。そして、「堅牢だからこそ、速い」。この両立を実現することが、Scalebaseが描くこれからのエンジニアリングの姿です。
ライター
