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](https://pmonrails.com/)です。 PM on Railsは、単なる作業一覧ではありません。お客さんが実現したいことから、利用者が何をしたいのか、どんな場面でどう動けば正しいのか、何を作るのか、何を確認すれば完成なのかまでをつなげて管理する仕組みです。 今回は、集めた情報を次の順番で整理しました。 1. お客さんが実現したいこと 2. 誰が何をできる必要があるか 3. 通常時にどう動くか 4. 入力ミス、権限不足、通信失敗などが起きたらどうするか 5. 上限、期限、0件などの境目でどう動くか 6. 何を作る必要があるか 7. 何を確認できれば完成とするか この再整理にかかった実作業が、3日強です。 3日強で開発を60％まで進めた、という意味ではありません。3日強でやったのは、開発する人とAIが迷わず動ける状態へ戻すことです。 ここを分けないと、さすがに話が変わってきます。 ## PM on Railsから、Cursorエージェントへ仕事を流しました 要件を整理した後は、PM on Railsに登録された作業を、人間の開発担当とCursorエージェントへ流しました。 Cursorエージェントは、開発用のAIです。指示されたファイルだけを直すのではなく、コード全体を読み、必要な処理がすでにあるかを探し、なければ実装し、テスト結果まで返します。 実際の流れは、だいたい次の形です。 1. PM on Railsで、残っている作業や仕様の食い違いを確認する 2. Cursorエージェントへ、対象のコードを読ませる 3. すでに実装済みなら、対応する作業へ結びつける 4. 未実装なら、必要な画面や処理を作る 5. 自動テストを行い、結果を確認する 6. 私が設計、仕様、操作性、安全性を確認する 7. 必要なら、お客さんへ確認し、回答をPM on Railsへ戻す SlackからPM on Railsへ「残っている作業は何か」と聞き、そのまま作業を作ったり、お客さんの回答を記録したりもしています。作業一覧を見るために別の場所へ移動し、内容をコピーし、また別の場所へ貼り直す回数を減らしました。 私は何もしていないわけではありません。決済のように設計判断が重い部分は、自分で設計し、実装することもあります。 ただ、私が全部の画面と処理を順番に書いているわけでもないです。私が主に見ているのは、決済、曖昧な仕様、全体設計、デザイン、安全性、最後の確認です。 つまり、判断が必要なところへ人間の時間を使い、調査、実装、繰り返し確認できる部分を人とAIへ分けています。 ## 安くなる理由は、単価ではなく時間の使い方です システム開発の費用は、かなりの部分が人の時間で決まります。 実装だけではありません。資料を探す、仕様を読み直す、分からない点を整理する、作業へ分ける、コードの場所を探す、すでに作られているか確認する、テストする、結果を報告する。全部、人の時間です。 従来は、この途中で何度も情報を受け渡します。要件を考える人、作業へ分ける人、実装する人、確認する人が別なら、そのたびに読み直しと説明が発生します。 今回の進め方では、PM on Railsに「なぜ作るか」から「何を確認するか」までを残し、Cursorエージェントが同じ情報を参照してコードを読みます。人間は、AIが判断してはいけない部分と、最終的な品質確認へ集中します。 人の単価を下げたのではありません。人が同じ説明を繰り返す時間、コードを探す時間、作った後に大きく戻る時間を減らしました。 だから、顧客の開発費を大きく抑えても、開発会社側に採算が残ります。 これでも元が取れているなら、安売りというより、作り方の差だと思う。 ## 約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個の確認が実行されています。決済の二重処理、権限、データの整合性、通知、削除、入力確認など、以前の調査で問題になった部分も確認対象へ入れました。 画面についても、機能ごとの確認結果を画像で残し、お客さんが実際の動きを見て指摘できる状態にしています。 お客さんからは、運営管理画面について「操作性、デザインともにすでに前回を超えているのがわかります」と言っていただきました。 まだ完成前なので、これで品質を証明し終えたとは思っていません。ただ、少なくとも「安く速くした代わりに、確認を減らした」という進め方ではないです。 速く作り、同時に確認できる範囲も増やす。ここまで揃って、初めて価格を下げられます。 ## AIでコードを書いたことより、工程をつないだことが大きい 生成AIを使った開発というと、コードを速く書いた話になりがちです。 でも、今回一番効いたのは、コードを書く部分だけではありません。 散らばった資料を読み、矛盾を見つけ、お客さんへ聞く内容を分け、具体的な利用場面へ変え、作業を作り、コードを調べ、実装し、テスト結果を戻す。この流れを一つにつないだことが大きいです。 PM on Railsだけでも足りません。作業をきれいに並べても、実装する人が毎回ゼロから読み直せば時間はかかります。 Cursorエージェントだけでも足りません。何を作れば正しいかが曖昧なままなら、間違ったものを速く作ります。 人間だけでも、この速度では回しにくい。 PM on Railsで正解と進捗をつなぎ、Cursorエージェントがコードを読んで実行し、人間が設計と品質を判断する。この組み合わせで、初めて全体の時間が縮みました。 結局、AIに人間の仕事を全部渡したのではなく、人間がやるべき仕事を絞ったんだと思います。 ## この案件が完成したら、お客さんにインタビューします この案件は、2026年8月31日時点では開発途中です。この記事も、完成事例ではなく中間報告です。 完成したら、お客さんへあらためてインタビューしようと思っています。 以前の開発と比べて何が変わったのか。PM on Railsを使った確認や進捗共有はどうだったか。実際に使ってみて、操作性や品質をどう感じたか。費用と速度に納得感があったか。こちらの進め方で分かりにくかったことはなかったか。 良かった話だけでなく、足りなかった点も聞く予定です。 自分たちが「速くできた」「安くできた」と言うだけでは、事例としては片側しかありません。最終的には、お客さんがどう感じ、実際の運用で何が変わったかまで確認したいです。 完成後にインタビュー内容を公開できる範囲でまとめ、この続きとして追記します。 --- ※本記事は2026年8月31日時点の情報です。案件を特定できる社名、サービス名、設計情報は伏せています。金額は税別です。進捗率はPM on Railsに登録された作業件数を基準にしており、工数による重み付けはしていません。 止まった開発や、仕様が散らばった既存システムの再構築で困っている方は、[Beekleへご相談ください](/contact?source=blog-system-rebuild-cost)。