結論：Hanamiのシステム開発費用は、機能を絞ったMVPで300万〜800万円、
標準的な業務Webシステムで800万〜2,000万円、中〜大規模で2,000万〜5,000万円以上がひとつの目安です。
ただし、これはHanami専用の定価ではなく、Rubyで業務システムを構築する場合の工数と体制から算出した推定レンジです。
「Hanamiのシステム」を検討するときは、フレームワークが無料であることだけを見て、
安く作れると判断しないことが大切です。この記事では、費用相場、見積もりの内訳、価格が変動する要因、
開発費を抑える進め方、発注時の確認項目を、2026年時点のHanami 3.0の情報と国内のRuby開発単価を踏まえて解説します。
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
Hanamiのシステム開発とは？費用を見る前に押さえたい全体像
Hanamiは、Rubyで保守性の高いWebアプリケーションを作るためのフレームワークです。
Railsのように多くの機能を一体で提供する考え方とは異なり、関心の分離、明示的な業務ロジック、
モジュール化を重視しています。そのため、費用を考えるときは「Hanamiを使う料金」
ではなく、業務をどの単位で設計し、どの範囲を開発するかを見る必要があります。
Hanamiの構造が開発費に影響する理由
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanamiでは、HTTPリクエストの入口をAction、登録・承認・在庫引当などの業務手続きをOperation、表示をView。
データアクセスをRelation・Repo・Structとして分けて考えます。
さらに、顧客管理や受注、請求、APIなどをSliceという境界で分けられます。
公式ガイドでも、Sliceは独自のコンテナや設定を持ち。
他のSliceとコンポーネントを入出力できる単位として説明されています（出典：Hanakai公式「App / Slices」、確認日：2026年8月）。
この構造は、業務ルールを整理して長期保守しやすくする一方、最初に業務境界を決める設計工数が必要です。
単純なお問い合わせフォームなら構造設計の負担は小さいですが、受注から請求まで複数部門をまたぐ場合は。どの処理をどのSliceやOperationに置くかを検討する時間が増えます。
保守性を高めるための設計が、初期見積もりの上流工程として費用に反映されます。
Hanamiで作りやすいシステムの範囲
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanamiは、社内向けの申請・承認システム、顧客や会員の管理、受発注・在庫管理、予約管理、問い合わせ管理。外部サービスと連携するAPIなどで採用を検討しやすい技術です。
画面を持つ業務Webシステムだけでなく、JSON API、バッチ、メール送信、管理画面を組み合わせることもできます。
Rubyの開発会社が公開する相場情報でも、RubyはMVP、中規模以下のWebサービス、社内業務ツール。
APIバックエンドなどが適した用途として挙げられています（出典：Incubation Base株式会社「Rubyでのシステム開発」、2026年確認）。
一方で、数百万人規模の同時接続、極端に短い応答時間、複雑なリアルタイム処理などでは、Rubyだけで要件を満たすとは限りません。
Hanami 3.0の公式ベンチマークでは、テストアプリの同一HTTPリクエストで2.3比約3.7倍のスループット。
p99レイテンシ20msから4msという結果が示されていますが。
これはあくまでテスト環境の値です（出典：Hanakai公式「Hanami 3.0: In full bloom」、2026年6月30日）。
実システムでは、データベース、外部API、インフラ、クエリ設計を含めた負荷試験が必要です。
Hanamiのシステム開発はどのように進めますか？
Hanamiの開発は、画面一覧を先に作るより、業務シナリオとデータの流れを整理してから小さく実装する進め方が適しています。
特に、Hanami 3.0やRuby 3.3、認証、データベース、CI/CD、監視が自社の条件で成立するかを早期に確認すると、
後からの作り直しを防ぎやすくなります。
企画・要件定義では業務と非機能要件を決めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
最初に、誰が、いつ、どの情報を入力し、どの条件で承認し、次の担当者へ何を渡すのかを業務シナリオで整理します。
ログイン、権限、検索、帳票、通知、インポート、エクスポートといった機能だけでなく、同時利用者数、目標応答時間、稼働時間、障害時の復旧時間。バックアップ期間、監査ログの保管期間も決める必要があります。
この工程で非機能要件が曖昧なままだと、開発後にセキュリティ診断、監視、二要素認証、データ保持、権限の追加が発生し、費用と納期が膨らみます。
Hanamiはこれらを自動的に満たす製品ではないため、フレームワークの機能と、アプリケーション・クラウド・運用ルールで設計する要件を分けて合意します。
PoCと基本設計で技術の成立性を確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanamiの採用経験が社内や発注先に少ない場合は、いきなり全機能を作らず、ログインから主要業務の登録、承認、検索までをつなぐ縦切りのPoCを作ります。
ここでAction、Operation、View、Relation・Repoの責務、認証方式、外部API、エラーハンドリング、自動テスト。デプロイ方法を確認します。
Hanami 3.0はRuby 3.3以上を必要とするため、既存のRuby、Gem、OS。
CI環境が対応できるかもPoCで確認します（出典：Hanakai公式「Hanami 3.0: In full bloom」、2026年6月30日）。
PoCの費用は本開発の見積もりに含める場合と、技術検証として別契約にする場合があります。PoCを省くと初期費用は下がりますが、未知の依存関係が本開発中に見つかるリスクが上がります。
開発・テスト・リリースで品質を作り込みます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
設計が決まったら、優先度の高い業務から実装し、単体テスト、結合テスト、総合テストを積み上げます。
HanamiのOperationで成功と失敗の分岐を明示し、ActionにはHTTP処理を集中させると、業務ルールのテストや変更がしやすくなります。
管理画面、API、バッチを同時に作る場合でも、共通の認証・権限・監査ログの扱いを先に決めておくことが重要です。
リリース前には、受入テスト、データ移行リハーサル、バックアップからの復元、監視通知、障害時の連絡経路を確認します。
開発会社からソースコードだけでなく、Gemfile.lock、CI/CD定義、インフラ設定、テスト仕様、運用手順を納品してもらうと。
HanamiやRubyのバージョンアップを自社または別会社へ引き継ぎやすくなります。
Hanamiの開発費用相場は？規模別の価格帯
Hanamiのシステム開発費用は、規模、画面数、業務ルール、外部連携、データ移行、
品質要件によって大きく変わります。以下の金額は税別の推定レンジであり、Hanamiの公式料金表や特定会社の確定見積もりではありません。
要件が固まっていない段階では、価格帯と期間を幅で捉え、見積もりの前提条件を確認してください。
小規模PoC・MVPは300万〜800万円が目安です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
ログイン、数画面の登録・編集・検索、簡易管理画面、少数のAPI連携に絞る場合は、300万〜800万円程度が初期検討の目安です。
期間は3〜5か月程度を想定しますが、デザインを既存UIに合わせるか、権限を細かく分けるか、運用環境をどこまで整えるかで変動します。
この価格帯では、最初から全社の業務を再現するのではなく、最も効果が大きい一つの業務シナリオを選びます。
例えば、申請・承認・検索・CSV出力までを一つの縦切りで実装し、利用者の反応を見て次の機能を追加します。
データ移行や複雑な帳票、24時間監視を同時に含めると、800万円を超える可能性があります。
標準的な業務Webシステムは800万〜2,000万円が目安です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
ユーザー・組織・権限管理、申請・承認、複数条件の検索、帳票、メール通知、外部APIを1〜3本程度含む標準的な業務Webシステムでは。800万〜2,000万円程度が目安です。
期間は6〜10か月程度を見込みますが、部門数や承認経路、既存データの品質によって前後します。
Rubyエンジニアの市場単価について、公開情報では初級が月50万〜70万円、中級が月70万〜100万円。
上級が月100万〜130万円以上という目安が示されています（出典：Incubation Base株式会社「Rubyでのシステム開発」、2026年確認）。
一方、要件定義から品質管理まで含む開発会社の新規開発単価として。
月100万〜150万円前後を公開している例もあります（出典：BPS株式会社「Ruby on Rails開発・保守・引き継ぎ」、2026年確認）。
中〜大規模の連携型システムは2,000万〜5,000万円以上です
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
複数部門をまたぐワークフロー、会計・在庫・基幹システムとの連携、大量のデータ移行、監査ログ、SSO、二要素認証。
厳格なバックアップや障害復旧を含む場合は、2,000万〜5,000万円以上になる可能性があります。
期間は10〜18か月以上を見込み、要件定義、移行設計、受入テスト、教育まで含めて計画します。この規模では、機能数だけでなく、関係者の意思決定にかかる時間も費用を左右します。
部門ごとに異なる業務ルールを統合し、既存システムのデータを名寄せし、移行後の責任分界を決めるには、開発者以外の業務担当者の参加も必要です。
価格を一つに固定せず、対象範囲、除外範囲、追加変更の扱いを契約書に明記します。
Hanamiの見積金額を構成する費用の内訳
見積書は「開発一式」だけでなく、工程と成果物に分けて確認します。政府のデジタル関連の標準ガイドラインでも、
システム開発の人件費は基本的に工数と単価の掛け算で積算すると説明されています（出典：デジタル庁「標準ガイドライン実践ガイドブック」
、2025年6月）。Hanamiの費用も、技術名の違いより、この積算の前提をどれだけ明確にできるかが重要です。
企画・要件定義・基本設計の費用
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
要件定義では、業務フロー、画面・API一覧、権限、データ項目、外部連携、非機能要件、運用体制を整理します。
基本設計では、Sliceの分け方、ActionとOperationの責務、データモデル、認証、ログ、エラー処理、インフラ構成を決めます。
目安として、要件定義・基本設計を総額の10〜20%程度と仮置きすると、提案の比較がしやすくなりますが、案件の不確実性が高いほどこの比率は上がります。
既存資料が整っていない場合は、ヒアリングや業務観察、現行データの調査が増えます。反対に、画面一覧や業務フロー、権限表、サンプルデータを発注者側で準備できれば、開発会社が確認する時間を減らせます。
ただし、資料を作ること自体が目的にならないよう、主要な業務シナリオを実際に操作できる形で合意することが大切です。
製造・単体テスト・結合テストの費用
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
製造費には、画面やAPIの実装、データベースの処理、認証・権限、メール、帳票、バッチ、外部サービス連携が含まれます。
製造と単体テストを総額の30〜40%、結合・総合テストを15〜20%程度と仮置きする考え方がありますが。品質要件が高い業務システムではテストの比率を下げないことが重要です。
HanamiのOperationやRelation・Repoを分離して実装すると、業務ルールやデータアクセスを単体で検証しやすくなります。
テストを後回しにすると、仕様変更のたびに手作業で全画面を確認する必要が生まれ、保守費用が増えます。初期見積もりの段階で、テストコードの範囲、テストデータ、受入テストの担当者、品質基準を明記します。
移行・インフラ・セキュリティの費用
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
既存システムから顧客、商品、組織、権限、履歴を移す場合は、データ抽出、変換、名寄せ、欠損補完、移行リハーサル、検証を見積もります。
移行・導入費は総額の5〜10%程度を仮置きできますが、古いデータの品質が悪い場合や複数システムを統合する場合は、それ以上になる可能性があります。
インフラでは、アプリケーション実行環境、RDB、オブジェクトストレージ、監視、バックアップ、ログ保管、CDN、CI/CDを整えます。
小規模な構成では月額数千円〜数万円程度から始められる場合がありますが、可用性、データ量、アクセス数、監視時間、SLAによって変わります。
脆弱性診断、WAF、SSO、二要素認証、監査ログを追加する場合も、初期費用とランニング費用を分けて記載します。
保守・運用のランニングコスト
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
公開後は、クラウド利用料だけでなく、障害監視、バックアップ確認、脆弱性対応、Ruby・Gem・Hanamiの更新、問い合わせ、軽微な改修。定期的な性能確認が発生します。
スクラッチ開発の保守費用は、初期開発費の年15〜20%程度を第一候補として置く方法があります。
初期費用が1,000万円なら年150万〜200万円程度ですが、24時間監視や厳格なSLA、追加開発を含める場合は上振れします。
見積書では「保守費用」とだけ書かず、月に含まれる稼働時間、対応時間帯、障害の優先度、脆弱性情報への対応、バージョンアップの範囲、追加改修の単価を確認します。
Hanami 3.0ではRuby 3.3以上が必要になるため、既存環境からの更新が保守契約に含まれるかどうかは、長期費用を左右する確認項目です。
Hanamiのシステム開発費用が変動する要因
同じHanamiを採用しても、案件ごとの費用が大きく異なるのは、技術名ではなく業務の複雑さと品質の要求が違うからです。
特に、画面数だけでは見えにくい権限、例外処理、データ連携、移行、非機能要件が、見積もりの差を生みます。
画面数より権限とワークフローが費用を左右します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
一覧・登録・編集の画面が少なくても、役職、部門、取引先、拠点、金額によって見えるデータや承認経路が変わると、実装とテストが増えます。
申請を差し戻す、代理承認する、期限を過ぎたら通知する、承認後の変更を禁止する、といった例外処理も費用に反映されます。見積もりを依頼するときは、画面一覧だけでなく、権限マトリクスと業務フローを渡します。
承認者が一人なのか、条件で複数に分かれるのか、履歴を何年間残すのかを示すだけでも、会社ごとの見積もり条件を揃えやすくなります。
外部連携とデータ移行が増えるほど費用は上がります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
会計、販売管理、在庫、決済、本人確認、メール配信などと連携する場合は、APIの仕様調査、認証、エラー時の再送、タイムアウト、データ形式の変換。相手側のテスト環境が必要です。
連携本数が1本増えるだけでなく、連携先ごとの例外処理と運用監視が増えるため、単純に画面1枚分の費用とは比較できません。データ移行では、件数よりもデータの正確さが重要です。
顧客名の表記揺れ、重複、欠損、古いコード、削除済みデータの扱いを決めずに着手すると、移行リハーサルが増えます。
新旧システムを一定期間並行稼働させる場合は、二重入力の防止や差分連携も必要になるため、期間と費用に余裕を持たせます。
非機能要件とHanami・Rubyの経験者確保
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
同時利用者数、応答時間、稼働率、RPO・RTO、監査ログ、個人情報の保護、脆弱性対応を厳しく設定すると、アプリケーションだけでなくクラウド構成、監視。テスト、運用手順の費用が増えます。
Rubyエンジニアの人数や経験、Hanami 3.0の対応可否も、体制の組み方と単価に影響します。
Hanamiの公開導入事例が少ない場合は、RubyやRailsの実績をHanamiの実績と混同しないことが大切です。
候補会社には、Hanamiのバージョン、Ruby 3.3以上の対応、Action・Operation・Sliceの設計経験、テストと保守の担当者を確認します。
経験が不足する場合は、PoCやアーキテクチャレビューを別途設けることで、リスクを見積もりに反映できます。
Hanamiのシステム開発費を抑えるコスト最適化のポイント
費用を下げるときは、単価の安い会社を探すだけでは不十分です。後から作り直す機能を減らし、
開発者が迷わない情報を先に揃え、保守しやすい設計を初期から選ぶことが、総保有コストの抑制につながります。
MVPで業務価値の高い範囲に絞ります
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
すべての帳票、細かな検索条件、例外的な承認経路を初回リリースに含めると、費用も期間も膨らみます。まずは、売上や処理時間、入力ミス、問い合わせ数など、改善したい指標に直結する業務を選びます。
標準的なマスタ管理や通知は既存サービスを使い、独自性の高い業務ロジックだけをHanamiで作る構成も費用を抑えやすい方法です。
例えば、勤怠、請求書発行、メール配信、ファイル保管をすべて自作せず、SaaSやクラウドサービスとAPI連携し。独自の申請・承認・顧客別ルールをHanamiで構築します。
外部サービスの月額費用や連携費用は発生しますが、初期開発と法令・セキュリティ対応の負担を分散できる場合があります。
縦切りのPoCで不確実性を先に減らします
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
ログインだけ、データベースだけといった技術単位の試作ではなく、利用者が業務を最初から最後まで完了できる縦切りのPoCを作ります。
認証、入力、業務ルール、データ保存、検索、通知、デプロイを一つにつなげると、Hanamiと周辺サービスの相性、テストの難所、運用上の不足が早く見つかります。
PoCで確認すべき項目は、画面が表示されることだけではありません。
実際のデータ量で検索速度を測り、失敗した外部APIを再実行できるか、権限のない利用者がデータへ到達できないか、バックアップから復旧できるかを確認します。
PoCの成果物と本開発へ流用できる範囲を、見積もり前に合意します。
自動テストと運用を標準化して保守費を抑えます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
業務ロジックをOperationに集め、データアクセスをRelation・Repoに分け、Sliceの境界を明確にすると。担当者が変わってもコードを追いやすくなります。
CIでテストを自動実行し、依存Gemの更新、脆弱性検知、ログ確認、バックアップ検証を定期作業に組み込むことで。障害やバージョンアップの突発費用を抑えやすくなります。
安くするためにテストやドキュメントを削ると、納品後の調査費用や引き継ぎ費用が増えます。最低限、構成図、業務ルール一覧、権限表、API仕様、データ移行手順、テスト結果、デプロイ手順を納品物に含めます。
これらを標準化すると、次のSliceや追加機能の見積もりも行いやすくなります。
Hanamiの見積もりを取る際のポイント
見積もりを比較するときは、合計金額の安さだけで決めず、同じ前提条件で工程、体制、
成果物、除外範囲を比べます。Hanamiの経験が少ない会社でも、Rubyの設計・テスト・保守経験が豊富で、
PoCを通じて不足を説明できる場合があります。反対に、Hanami対応を掲げていても、
担当者やバージョンが不明な場合は確認が必要です。
見積もり前に業務フローと前提資料を揃えます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
発注前には、目的と成果指標、対象利用者、業務フロー、画面・API一覧、権限、データ項目、外部連携、移行対象、希望時期、予算上限を整理します。
すべてを完璧に決める必要はありませんが、「必須」「できれば」「将来検討」を分けるだけで、提案会社が同じ範囲で見積もりやすくなります。
特に、既存システムのサンプルデータ、API仕様書、現在の帳票、権限表、障害履歴があると、調査工数を抑えられます。
提供できない資料がある場合は、開発会社に現状調査を依頼する作業として、見積もりへ別項目で含めてもらいます。
複数社を同じ条件で比較します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
比較先には、Hanami 3.0とRuby 3.3以上の経験者をアサインできるか、Action・Operation・Sliceの設計例を説明できるか。テストとコードレビューを誰が担当するかを尋ねます。
RubyやRailsの実績は参考になりますが、そのままHanamiの本番実績を意味しないため、技術の近さと担当者の実経験を分けて評価します。
見積もりでは、PM・リードエンジニア・開発者・QA・デザイナー・インフラ担当の人数と期間、各工程の工数、レビューや会議の時間、再見積もりの条件を確認します。
総額が低くても、要件定義、受入支援、移行、運用設計が除外されていれば、後から追加費用が発生するためです。
契約・納品・保守のリスクを先に確認します
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
請負型か準委任型か、仕様変更をどのように扱うか、検収の条件、遅延時の連絡、第三者サービスの障害責任、ソースコードや設定の権利、再委託の範囲を確認します。
特に、HanamiやGemの更新を誰が担当するか、脆弱性が見つかった場合の対応時間と費用を契約書に書いておくと、運用開始後の認識違いを防げます。
データ移行や本番切り替えは、開発会社だけでは完了しません。
発注者側が用意するマスタデータ、業務担当者の受入テスト、社内教育、旧システム停止の判断者を決めます。役割分担が見積書に記載されているかを確認し、発注者側の作業を含めた総額とスケジュールで判断します。
Hanamiのシステム開発費用に関するよくある質問
最後に、Hanamiの費用について発注前によく寄せられる質問へ回答します。価格だけでなく、
Hanamiを採用する妥当性、開発期間、保守費用まで含めて判断すると、自社に合わない安さや、
必要以上に大きな構成を選ぶリスクを減らせます。
Hanamiを使うとRailsより開発費用は安くなりますか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanamiを採用しただけで、Railsより必ず安くなるとはいえません。
フレームワーク自体は無料ですが、Hanamiの設計や周辺Gemを理解した人材の確保、テスト、認証、運用設計の工数が費用に含まれるためです。
業務境界が明確で長期保守を重視する案件ではHanamiの構造が効果を発揮しやすく、標準機能を早く揃えたい案件ではRailsやSaaSとの比較が必要です。
Hanamiのシステム開発にはどのくらいの期間がかかりますか？
小規模PoCやMVPは3〜5か月、標準的な業務Webシステムは6〜10か月、中〜大規模の連携型システムは10〜18か月以上が目安です。
要件定義の準備状況、意思決定の速さ、データ移行、外部API、受入テストの体制で変動します。
期間を短くする場合も、テストや移行リハーサルを省略せず、初回リリースの機能範囲を絞る方法が安全です。
Hanamiの保守費用は毎月どのくらい見込めばよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
保守費用は、初期開発費の年15〜20%程度を仮の目安にし、監視、バックアップ、脆弱性対応、Ruby・Gem・Hanami更新、問い合わせ。軽微な改修をどこまで含めるかで調整します。
例えば初期開発が1,000万円なら年150万〜200万円程度が一つの検討レンジですが、24時間対応やSLA、追加開発を含む場合は上振れします。クラウド利用料も別に見積もる必要があります。
Hanamiの開発会社には何を確認すればよいですか？
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanami 3.0とRuby 3.3以上の経験、Action・Operation・Sliceの設計方針、テストとコードレビューの体制。データ移行の実績、クラウドと監視の対応範囲を確認します。
加えて、設計書・テスト仕様・ソースコード・CI/CD・インフラコードの納品範囲、脆弱性対応、バージョンアップ、担当者交代時の引き継ぎも質問します。
RubyやRailsの実績をHanamiの直接実績と分けて説明できる会社は、提案の前提が明確です。
まとめ
Hanamiのシステム開発費用は、MVPで300万〜800万円、標準的な業務Webシステムで800万〜2,000万円、
中〜大規模で2,000万〜5,000万円以上が推定レンジです。金額はHanamiのライセンス料金ではなく、
要件定義、設計、製造、テスト、移行、インフラ、セキュリティ、保守に必要な工数と体制で決まります。
費用ではなく業務価値と将来の保守まで比較します
発注前は、必須機能と将来機能を分け、主要業務を縦切りでPoCし、権限、外部連携、
データ移行、非機能要件を見積もりへ反映します。複数社を同じ条件で比べ、Hanami 3.0やRuby 3.3以上への対応、
テスト、納品物、保守・バージョンアップの責任範囲を確認することが、初期費用と長期コストの両方を適正化するポイントです。
最初は要件整理と小さな検証から始めます
- 確認対象：この見出しで扱う範囲と前提を整理します。
- 比較の観点：初期・継続・追加の要素を分けて確認します。
- 判断の基準：自社の要件と運用体制に照らして検討します。
Hanamiの採用を迷っている場合は、全体開発の確定見積もりを急がず、業務フロー、サンプルデータ、非機能要件を整理したうえで。PoCまたは要件定義から相談します。
自社の独自業務をHanamiで作り、標準機能や周辺サービスはSaaS・クラウドと組み合わせる設計も含めて比較すると、費用と保守性のバランスを取りやすくなります。
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。