1,100万円超が投じられたシステムを、340万円で作り直しても採算が残る理由
2026年4月、正式公開を予定していた、あるシステムを止めました。
公開前日の調査で、決済、権限、エラー処理、個人情報の扱い、自動テストなどに重大な問題が見つかったからです。数か所を直せば公開できる状態ではありませんでした。
先方から共有された以前の開発費は、約1,100万〜1,200万円でした。今回、Beekleが受けた再構築本体は340万円、追加開発64万円を含めても404万円です。いずれも税別です。
半額ではなく、だいたい3分の1です。
事情があったので、かなり抑えた金額で受けました。でも、これでも採算は残っています。
なんでそんなことができるのか。
人を安くしたからではなく、開発の進め方そのものを変えたからです。
何でも3分の1で作れるという話ではありません
以前の開発と今回の再構築では、契約範囲も前提条件も完全には同じではありません。今回は、既存の画面設計、過去の資料、コードなど、使えるものは使っています。先方の事情を踏まえた特別な条件でもあります。
そのため、「1,000万円かかるシステムなら、何でも340万円で作れます」と言うつもりはありません。そこまで単純な話ではないです。
ただし、同じサービスを正式公開できる状態へ持っていくために、以前の開発費が約1,100万〜1,200万円、今回の再構築本体が340万円という数字は事実です。
以前の開発費と比べると、本体価格は約69〜72％低くなっています。追加開発を含めた404万円で比べても、約63〜66％低い金額です。
安売りして赤字になっているわけでもありません。価格を下げても採算が残る作り方へ変えました。
3日強で、開発できる状態へ戻しました
再構築を始める前に、既存のコード、画面設計、過去の仕様書、会議の記録、お客さんからの回答、実際に動いている画面を集めました。
問題は、情報がないことではありませんでした。情報はかなりある。でも、置かれている場所が違い、内容も少しずつ違っていました。
画面にはあるのに資料へ書かれていない。資料ごとに数字が違う。実装されているけれど、なぜそうしたのか分からない。後から決まった内容が、以前の仕様へ戻っていない。
この状態で実装だけ速くすると、違うものが速く完成します。普通にまずい。
そこで使ったのが、私たちが開発しているPM on Railsです。
PM on Railsは、単なる作業一覧ではありません。お客さんが実現したいことから、利用者が何をしたいのか、どんな場面でどう動けば正しいのか、何を作るのか、何を確認すれば完成なのかまでをつなげて管理する仕組みです。
今回は、集めた情報を次の順番で整理しました。
- お客さんが実現したいこと
- 誰が何をできる必要があるか
- 通常時にどう動くか
- 入力ミス、権限不足、通信失敗などが起きたらどうするか
- 上限、期限、0件などの境目でどう動くか
- 何を作る必要があるか
- 何を確認できれば完成とするか
この再整理にかかった実作業が、3日強です。
3日強で開発を60％まで進めた、という意味ではありません。3日強でやったのは、開発する人とAIが迷わず動ける状態へ戻すことです。
ここを混ぜると、さすがに話が変わってきます。
PM on RailsからCursorへ仕事を流しました
要件を整理した後は、PM on Railsに登録された作業を、人間の開発担当とCursorエージェントへ流しました。
Cursorエージェントは、開発用のAIです。指定されたファイルだけを直すのではなく、コード全体を読み、必要な処理がすでにあるかを探し、なければ実装し、テスト結果まで返します。
実際の流れは、だいたい次の形です。
- PM on Railsで、残っている作業や仕様の食い違いを確認する
- Cursorへ、対象のコードを読ませる
- すでに実装済みなら、対応する作業へ結びつける
- 未実装なら、必要な画面や処理を作る
- 自動テストを行い、結果を確認する
- 人間が仕様、操作性、安全性を確認する
- 必要なら、お客さんへ確認し、回答をPM on Railsへ戻す
実際、私がやっていたことのかなりの部分は、SlackでPM on RailsとCursorへ質問や指示を出すことでした。
「回答者以外で、やりやすそうな残作業はある？」
「この作業はもう実装されていないか、コードを読んで確認して」
「画面がないなら、先に画面と処理を作って。後から設計書へ戻す」
このような会話から、そのまま調査や実装へ進めています。
PM on Railsが要件と進捗を持っているので、作業一覧を人間が毎回読み直さなくても現在地を聞けます。Cursorはそのままコードを読み、実装済みかを確認し、必要なら実装へ進みます。
かなりの部分が、Slack上の会話で進みました。
もちろん、返答が常に正しいわけではありません。実装済みの機能を未完了として扱うこともあります。その場合は、「本当に満たしていないのか、コードを確認して」と戻します。
完全自動ではない。でも、資料、作業表、コードを人間が何度も往復する量はかなり減っています。
安くなる理由は、単価ではなく時間の使い方です
システム開発の費用は、かなりの部分が人の時間で決まります。
実装だけではありません。資料を探す、仕様を読み直す、分からない点を整理する、作業へ分ける、コードの場所を探す、すでに作られているか確認する、テストする、結果を報告する。全部、人の時間です。
従来は、この途中で何度も情報を受け渡します。要件を考える人、作業へ分ける人、実装する人、確認する人が別なら、そのたびに読み直しと説明が発生します。
今回の進め方では、PM on Railsに「なぜ作るか」から「何を確認するか」までを残し、Cursorが同じ情報を使ってコードを読みます。人間は、確認や判断が必要な部分へ集中します。
人の単価を下げたのではありません。同じ説明を繰り返す時間、コードを探す時間、作った後に大きく戻る時間を減らしました。
だから、顧客の開発費を大きく抑えても、開発会社側に採算が残ります。
これでも元が取れているなら、安売りというより、作り方の差だと思う。
約2週間で、全作業の59％まで進みました
開発を本格的に進めてから約2週間後の2026年8月31日時点で、PM on Railsには1,414件の作業が登録され、そのうち830件が完了しています。
見ている数字 | 件数 | 進捗 |
|---|---|---|
全作業 | 830 / 1,414件 | 59％ |
8月25日〜9月7日の開発サイクル | 276 / 310件 | 89％ |
見出しでは分かりやすく「約60％」と言えますが、正確には全作業の件数ベースで59％です。
この数字には注意点もあります。1時間で終わる作業も、数日かかる作業も、件数では同じ1件です。59％だから、残り期間が41％という意味ではありません。
また、要件を細かく確認するほど、最初は見えていなかった作業も追加されます。進めるほど母数が増えるので、進捗率だけ見ると少し損をします。
でも、見えていない作業を隠したまま「ほぼ完成です」と言うより、その方がいい。
何が終わり、何が確認中で、何が未確定なのかを説明できることの方が大事です。
速いだけでは、同じ問題を繰り返します
今回、速さだけを優先したわけではありません。
現在レビュー中の大きな変更では、自動テスト604件が通り、その中で5,811個の確認が実行されています。決済の二重処理、権限、データの整合性、通知、削除、入力確認など、以前の調査で問題になった部分も確認対象へ入れました。
画面についても、機能ごとの確認結果を画像で残し、お客さんが実際の動きを見て指摘できる状態にしています。
お客さんからは、運営管理画面について「操作性、デザインともにすでに前回を超えているのがわかります」と言っていただきました。
まだ完成前なので、これで品質を証明し終えたとは思っていません。ただ、少なくとも「安く速くした代わりに、確認を減らした」という進め方ではないです。
速く作り、同時に確認できる範囲も増やす。ここまで揃って、初めて価格を下げられます。
普通のエンジニアでも速くなる。強い人が使うと、さらに伸びる
この仕組みは、一部のエースだけに効くものではありません。同じ59％まで進められるとは言えませんが、要求、具体的な利用場面、作業、確認結果がつながるだけでも、普通のエンジニアは見落としと手戻りを減らせます。
未確定の仕様を、決まったものとして実装しにくくなる。残っている作業を探しやすくなる。実装済みかどうかを、コードを読んで確認できる。作った後も、何を確認すれば完成かが残る。
それだけでも、一定の速度向上と失敗防止は狙えます。
ただ、使う人によって上限は変わります。AIの返答の違和感に気づく。何を先に進めるか決める。どこをお客さんへ確認するか切り分ける。経験のあるエンジニアほど、この判断が速いので、同じ仕組みでもさらに多くの作業を回せます。
普通のエンジニアでも底上げされる。エースが使うと、たぶんとんでもない速度になる。そういう道具に近い気がします。
だから今回の進捗を、私個人の能力だけで説明するのも違います。実際、私はかなりSlackを打っていただけです。
仕組みが失敗を防ぎ、AIが実行を速め、人間は必要な確認と判断を返す。この組み合わせが効いた、というのが一番正確だと思います。
この案件が完成したら、お客さんにインタビューします
この案件は、2026年8月31日時点では開発途中です。この記事も、完成事例ではなく中間報告です。
完成したら、お客さんへあらためてインタビューしようと思っています。
以前の開発と比べて何が変わったのか。PM on Railsを使った確認や進捗共有はどうだったか。実際に使ってみて、操作性や品質をどう感じたか。費用と速度に納得感があったか。こちらの進め方で分かりにくかったことはなかったか。
良かった話だけでなく、足りなかった点も聞く予定です。
自分たちが「速くできた」「安くできた」と言うだけでは、事例としては片側しかありません。最終的には、お客さんがどう感じ、実際の運用で何が変わったかまで確認したいです。
完成後にインタビュー内容を公開できる範囲でまとめ、この続きとして追記します。
※本記事は2026年8月31日時点の情報です。案件を特定できる社名、サービス名、契約書、設計情報は掲載していません。金額は税別です。進捗率はPM on Railsに登録された作業件数を基準にしており、工数による重み付けはしていません。
止まった開発や、仕様が散らばった既存システムの再構築で困っている方は、Beekleへご相談ください。