料金の考え方

弊社との関わり方は、事業の段階と要件の固まり具合に応じて3つから選べます。

一つの案件の中で組み合わせることも、段階が変わるときに切り替えることも可能です。どれが適しているかはヒアリングのうえでご提案します。社内で先に方針を固めておきたい場合は、契約形態の選び方シートの判断シートが使えます。

二つの契約形態の違いは、対価が何に対して支払われるかにあります。ここを押さえておくと、見積書の金額が何を意味しているのかが読めるようになります。

準委任は「完成しなくてもお金を払う契約」ではありません。何にどれだけの稼働を充てるかを毎月決め、その結果を確認したうえで次を決める進め方です。稼働時間の上限を決めておけば、費用の見通しは立ちます。請負は総額が先に決まる安心感がある一方、検収の基準を契約時に言葉にできていなければ、完成したかどうかの判断そのものが揉めごとになります。範囲が固まっていないのに請負を選ぶと、変更のたびに交渉が必要になり、かえって進みが遅くなります。

どちらが有利ということではなく、仕様がどこまで固まっているかで適する形が変わります。契約書で確認したい条項は契約形態の選び方シートに、ソースコードの権利とリポジトリの移転時期はソースコードの権利の確認事項にまとめています。

一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

作るべきか、どう作るべきか、他社の提案や見積が妥当か。こうした「決める前」の問いに、開発を担当するエンジニアが単発でお答えする関わり方です。まずは30分の無料相談からお受けし、より深い検討が必要な場合に有償のスポット相談をご案内します。

• 向いている段階: プレシードからシリーズA以降まで、すべての段階。特に、社内に技術責任者がいない時期
• 決めること: 相談したいテーマ、判断したい期限、共有できる資料の範囲（企画書や他社見積など。なくても構いません）
• 向かない場合: 継続的な実装や運用が必要な場合。判断の相手ではなく手を動かす体制が必要なら、月額チームか機能単位をご検討ください

相談の結果、弊社への発注が不要と分かることもあります。その場合もその旨を正直にお伝えします。相談の前に論点を絞っておきたい場合は、関係者と決裁の地図やフェーズごとの意思決定リストで「今どの判断が止まっているのか」を書き出してみてください。

月ごとの稼働時間を決め、その範囲で優先順位を毎月見直しながら開発を進める関わり方です。ユーザーの反応を見て方針を変えることが前提のスタートアップ開発では、この形が多くなります。稼働時間の上限を決めておけば、費用の見通しを立てたまま柔軟に進められます。

• 向いている段階: プレシード〜シード。仮説検証のためのMVP開発、リリース直後の改善、内製化に向けた伴走
• 決めること: 月ごとの稼働時間（上限）、定例の頻度、優先順位を決める担当者、予告期間と終了条件
• 向かない場合: 作る範囲と検収条件が最初から明確で、総額を先に確定したい場合。この場合は機能単位のほうが予算管理がしやすくなります

毎月の稼働の使い道を確認する観点は週次デモの確認シートに、リリース後にどこまでを稼働に含めるかの線引きは保守範囲の確認シートにまとめています。

内製化の段階では、弊社の稼働を徐々に減らし、社内チームへの引き継ぎと技術顧問としての伴走に移します。

作る機能の範囲と検収条件を見積時に確定し、総額を決めて開発する関わり方です。決済連携や既存システムの移行のように、要件がはっきりしている作業に向いています。

• 向いている段階: シリーズA以降、または段階を問わず範囲を確定できる個別の作業
• 決めること: 対象機能の範囲、検収条件、納期、範囲外の要望が出たときの扱い（見積の見直し手順）
• 向かない場合: 仮説検証の途中で要件が変わる時期。変更のたびに範囲と費用の合意が必要になり、かえって遅くなります

改善は月額チームで継続しつつ、範囲の明確な大きな機能や移行作業を機能単位で切り出す、という組み合わせが現実的です。契約の考え方はアジャイル開発と契約でも解説しています。検収の基準を先に言葉にしておくために、検収テストの項目シートを契約前にご覧いただくことをおすすめします。何をもって完成とするかが決まっていれば、請負の利点が生きます。

一般的な情報であり、個別の事案は専門家・所管官庁にご確認ください。

弊社の見積りは、次の要素の積み上げで構成されます。

見積書には作業項目ごとの内訳を記載します。どの作業にどれだけの工数がかかるのかが分かるため、範囲を削る・後回しにするといった調整がしやすくなります。見積の段階で、作業項目ごとに「検証に必須」「あると良い」「今回は見送り」を一緒に仕分けし、ご予算内で効果の大きい構成をご提案します。他社の見積を読み解く際の考え方はMVP開発の費用相場にまとめています。

「案件により異なります」だけでは、ご自身で見積りを調整できません。弊社の見積りで工数が増える方向に効く要因と、抑える方向に効く要因を挙げます。ご予算に収まらないときは、この一覧を見ながらどこを動かすかを一緒に決めます。金額そのものは案件の内容と規模により異なるため、ここでは向きだけをお示しします。

工数が増える方向に効く要因

工数を抑える方向に効く要因

範囲をどこで切るかはMVPの範囲を決めるチェックシート、範囲・期日・費用のどれを固定するかは範囲・期日・費用の優先順位シート、非機能要件の水準は非機能要件の確認シートで整理できます。ご予算の上限から逆算する場合はランウェイから逆算する開発予算もご覧ください。

複数社から見積りを取ることは、弊社としても歓迎です。ただし総額だけを並べても比較にはなりません。見積りの差は、多くの場合「値段の差」ではなく「範囲の差」だからです。必要な作業が入っていない見積りは、その時点では安く見えます。

前提を揃えるために、次の順で確認することをおすすめします。

1. 同じ範囲定義を全社に渡したか: 口頭の説明だけでは、各社が想像した範囲が食い違います。作るものと作らないものを箇条書きにした1〜2枚があれば十分です
2. 見積りの形式を揃えて依頼したか: 総額一式の見積りと、作業項目ごとに工数と単価が分かれた見積りは比べられません。内訳を出せるかどうか自体も判断材料になります
3. 総額を作業費・実費・保守に分解したか: 実費は事業の成長に応じて増え続けます。保守費が書かれていない見積りは、ゼロではなく「未定」として記録してください
4. 抜けている作業がないか照合したか: 要件整理、画面設計、テスト、インフラ構築、外部連携、打ち合わせの時間、公開後の不具合対応。これらの記載の有無を各社で突き合わせます
5. 契約形態と支払い条件を揃えて見たか: 請負と準委任では同じ金額でも意味が違います。着手金の比率が高い見積りは、資金繰りへの負担が前倒しになります

そのうえで、各社に同じ質問をして答え方を比べてください。「他社より安い（高い）理由として、どの作業項目の差が大きいと考えますか」「この工数はどのような前提で計算していますか」「想定より時間がかかった場合、費用はどうなりますか」「この範囲から削るとしたら、どこを勧めますか」。金額の根拠を説明できるかは、開発が始まった後に工数の議論ができる相手かどうかにそのまま表れます。

書き込みながら進められる形にしたものが相見積もりの比較シートです。契約前に確認しておきたい観点は開発パートナー選定で確認する15の質問にまとめています。どちらも弊社にお使いいただいて構いません。同じ質問にお答えします。

弊社は生成AIを開発工程に組み込み、設計の下書き、コードの生成とレビュー、テストの作成、既存コードの解析、ドキュメントの整備にかかる時間を短くしています。エンジニアは、要件が正しく満たされているか、ユーザーにとって分かりやすいかの判断に時間を充てます。

その結果、同じ予算でより多くの機能を、同じ機能をより短い期間でご提供できます。ただし、AIの出力は必ず人がレビューし、テストを通してから納品します。品質を落として安くするのではなく、手を動かす時間を減らして品質の確認に集中する、というのが弊社の考え方です。

削減の程度は案件の性質によって異なるため、数値でのお約束はしていません。見積の内訳の中で、AI活用を前提とした工数としてお示しします。

次の情報があると、より正確な見積りをお出しできます。すべてそろっていなくても構いません。分かる範囲でお知らせください。

1. 事業の概要と目的: 誰の、どんな課題を、どう解決する事業か。検証したい仮説
2. 想定するユーザー: 最初のユーザーは誰か、どんな場面で使うか
3. 既存の資産: 既存のプロダクト、コード、デザイン、データ、契約中のサービスがあれば
4. 必要な機能のイメージ: 箇条書きや参考にしているサービスで構いません
5. 希望する時期: リリースしたい時期、資金調達や出展などの節目
6. ご予算感: 上限の目安があれば、その範囲で実現できる構成をご提案します
7. 開発体制の見通し: 社内にエンジニアがいるか、将来の内製化を考えているか

1〜4を1枚にまとめる形式として要件を1枚にまとめるシートを、複数社に同じ内容を渡す場合の書き方として小さく始めるRFPの型をご用意しています。どちらも弊社への提出用ではなく、社内で書くためのものです。

ご相談とお見積りは無料です。お打ち合わせはオンラインで行います。