Hanamiのシステム開発は、要件整理、PoC（概念実証）、契約確認の順に進めると、適合性と保守性を確かめながら発注できます。特に、仕様が固まらないまま本開発を一括で頼むと、見積の前提がそろわず、比べられなくなります。
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Hanamiのシステムを発注する前の全体像
各社の見積条件をそろえるには、画面数やAPI数に加えて、業務ルールと権限を決めておく必要があります。さらに、既存データや外部連携、運用体制まで定めると、各社が同じ前提で見積を出せます。
Hanamiで作れるシステムの範囲
Hanamiは、受発注や顧客・会員管理、社内申請などの業務システムに使えます。また、予約や問い合わせ管理にも使えます。さらに、RESTやJSONのAPI、管理画面、バッチ、外部サービス連携も設計の対象になります。
Hanamiの公式ドキュメントでは、入口の処理から表示、データ保存までを要素ごとに役割分担しています。その分担は、次の2組で整理できます。
- Action・Operation・View：HTTPの入口、業務手続き、表示
- Relation・Repository・Slice：データアクセスと業務領域の分割を担います。
受注業務なら、顧客管理、受注、請求をSliceで分ける構成を検討できます。たとえば、注文受付はAction、承認と在庫引当はOperation、検索や保存はRelation・Repositoryが担う形です。
技術用語を覚えなくても、提案時に業務領域とルールの置き場所を確認すれば、将来の保守性を判断できます。
Hanami 3.0の対応可否
2026年6月に公開されたHanami 3.0では、メーラー、国際化、Minitest、ログやアセットの改善などが追加されています（出典: Hanakai公式ブログ、2026年）。
Hanami 1系・2系での経験と、Ruby 3.3以降でHanami 3.0を運用した経験は、別々に確かめます。また、問い合わせの際は、HanamiとRubyの版、DB、認証、CI/CD、監視の構成を尋ねます。
Hanami 3.0を想定するなら、既存のRuby・Gem・OSとの互換性をPoCで検証します。ただし、公式発表のベンチマーク値も、自社業務にそのまま当てはまるとは限りません。
Hanamiだから安いとは限らない理由
Hanamiはオープンソースのため、費用の中心がライセンス料になるわけではありません。費用は、要件定義や画面、権限、帳票の作り込みで変わります。さらに、外部APIやデータ移行、テスト、インフラ、保守の範囲も費用を左右します。
Ruby経験者を確保する必要があるうえに、Hanami固有の設計調査や社内教育が増える場合もあります。そのため、Railsより必ず安い、または高いとは断定できません。
Hanamiのシステム発注形態の選び方
仕様が固まっていない段階では、本開発を一括で発注せず、要件整理や小規模PoCを先に委託する方法が安全です。その結果を見てから、開発契約へ進みます。
社内の技術力や業務知識、納期の固定度、変更の多さを踏まえて、スクラッチ開発、SaaS・パッケージとの併用、内製と外注の混成を比べます。
独自業務が強みのときのスクラッチ開発
独自の承認フローや複雑な料金計算が事業の強みなら、Hanamiで業務ロジックを明示的に実装する意義があります。また、在庫引当や顧客ごとの例外処理も、業務ロジックとして書き起こせます。
受注、請求、在庫をそれぞれ別々に改修したい場合も、Sliceなどで境界を設計できるHanamiの特徴が活かせます。あわせて、導入後に測る成果指標も先に決めておきます。
たとえば、受注時間の短縮や入力ミスの削減、月次締めの早期化を指標にします。そのうえで、発注先には、その達成に寄与する業務フローを提案してもらいます。
SaaS・パッケージとHanamiの組み合わせ
勤怠や会計、電子契約などの標準化された業務のほか、チャットにもSaaSやパッケージを使えます。一方、独自性の高い受注画面や社内APIだけをHanamiで作る構成も、有力な選択肢になります。
この構成は、スクラッチ開発より初期範囲を絞りやすく、既製サービスのアップデートも活用できます。ただし、API制限やデータ保管場所、ユーザー課金を確かめる必要があります。解約時のデータ返却も確認します。
障害時に、どこまでを誰が受け持つかも決めておきます。特に、連携が止まったときの再送、重複登録の防止、手動での復旧手順をRFPに書いておくと、見積の抜けを抑えられます。
内製と外注の混成と社内への知識の残し方
社内に業務知識があるなら、企画や優先順位、受入テストは自社が担い、Hanamiの設計や実装、インフラを外注する分担が現実的です。
JUAS「企業IT動向調査2026」では、内製と外部委託を使い分けることを目指す企業が多いと整理されています（出典: 一般社団法人日本情報システム・ユーザー協会、2026年）。
定例会議や設計レビューの回数を、成果物や作業範囲に含めます。さらに、ソースコードの説明と運用引き継ぎも、回数を決めて作業範囲に入れます。社内担当者が半年後に小さな改修を判断できる状態を目標にすると、ベンダーロックインを下げられます。
RFPと要件整理の進め方
RFPは、発注者が解決したい課題と希望条件を候補会社へ伝える文書です。機能一覧だけを渡すと、会社ごとに解釈が変わってしまいます。
そのため、RFPには、現状の業務と目的、対象ユーザーを書きます。さらに、データや非機能の条件、納期と予算の考え方、提案に求める内容も整理します。
画面一覧より業務シナリオを起点にした書き方
業務シナリオでは、誰がいつ何を入力し、誰が承認し、次にどのデータを渡すかを整理します。たとえば受注なら、見積登録を起点に、承認、在庫確認、出荷指示、請求確定までを一続きで書きます。
例外として、キャンセルや返品を書き、権限不足や連携失敗も加えます。さらに、登録や更新だけに見える画面の機能も、承認条件や履歴管理を含む業務ロジックとして整理できます。
優先度が曖昧だと、会社ごとの想定範囲がずれ、見積を比べられません。そこで、RFPでは必須機能と将来機能を分け、今回のリリース範囲を明記します。
数値で示す非機能要件
非機能要件は、性能・稼働、継続性、セキュリティに分けると整理しやすくなります。
- 性能・稼働：同時利用者数、応答時間、稼働時間
- 継続性：バックアップ、障害復旧、ログ保管
- セキュリティ：データ所在地、認証、権限、監査ログ、脆弱性対応
「速く」「安全に」と書くより、通常時の応答時間やピーク時の同時接続など、検証できる形で示します。また、目標復旧時間（RTO）と許容できるデータ損失（RPO）も、明確にしておきます。
個人情報を扱う場合は、アクセス制御や操作記録、バックアップの暗号化をRFPと契約に反映します。委託先と再委託先の監督も、契約に入れておく必要があります。
個人情報保護委員会のガイドラインでは、委託先の取扱状況を定期的に把握することや、再委託先への事前報告・承認、監査の検討が示されています（出典: 個人情報保護委員会、通則編ガイドライン）。
発注前に決めるデータ移行と受入条件
移行では、次の対象と分担を発注前に決めておきます。
- 対象データ：顧客、商品、組織、権限、受注履歴
- データの扱い：移行元項目、欠損・重複、名寄せ、対象期間
- 検証と分担：確かめ方と、発注者・受注者それぞれのデータ整理担当
ここが曖昧なままだと、開発会社の工数を増やしても解消しきれない問題が、納品前に集中して表れます。そこで、受入条件には、主要シナリオの合格基準とテストデータ、重大障害の定義を含めます。
さらに、残課題の扱いと検収期限も決めておきます。性能については同時利用者数と目標応答時間を、セキュリティについては対象範囲と指摘の修正期限を指定します。
RFPでここまで整理できれば、見積の根拠と、契約後にどこまでを誰が負うかが明確になります。
Hanamiのシステム開発の契約形態の選び方
契約形態は、仕様の確定度と変更の多さで選びます。契約書と個別契約では、成果物と作業時間、検収を確認します。さらに、変更手続きと責任範囲も押さえておきます。
要件定義での準委任型の活用
要件定義や調査では、作業の途中で前提が変わりやすいため、準委任型を検討します。契約形態は、工程ごとの性質に合わせて選びます。
- 準委任型：業務調査、RFP補完、画面モック、データ調査、PoC
- 請負型：完成物と受入基準が明確な工程
- アジャイル型の準委任：優先順位を変えながら続ける開発
準委任型では、作業時間と進捗を確かめながら、毎週の成果物をレビューします。そこに次工程へ進む判断を置くと、曖昧な要件のまま大きな請負契約へ進むリスクを抑えられます。
準委任型でも、成果物は欠かせません。具体的には、業務フローや要件一覧、画面遷移を納品物に定めます。さらに、データモデルや非機能要件、PoC結果、未決事項も加えて、次の判断に使える記録を残します。
完成条件が明確な工程と請負型
仕様、納期、検収基準に合意できる基本設計や特定機能の開発は、請負型で完成物と責任を明確にできます。
- 開発範囲：HanamiのSlice単位か、主要業務の縦切り単位で区切ります。
- 完成条件：機能、エラー処理、権限、ログ、テスト、ドキュメントの定義。
- 変更管理：判定者と追加見積の方法、納期への影響、承認期限を、変更の記録表で運用し、追加要望が無償対応と誤解されないようにします。
発注側では、口頭での依頼をそのまま開発に流さないルールも作っておきます。
ソースコードと運用資産の帰属の明記
納品範囲には、ソースコードや設計書、テスト仕様書を含めます。Gemfile.lockやCI/CD定義、インフラコードも対象に入れます。さらに、監視設定やバックアップ手順、アカウント情報の管理方法も決めておきます。
また、第三者ライブラリのライセンス表示と、OSSへの修正の扱いも確認します。保守契約では、問い合わせ時間と障害優先度を分けて書きます。目標初動時間や復旧方法も、別の項目として書き出します。
Hanami・Ruby・Gemの更新と脆弱性対応、追加改修の単価を定めておきます。再委託がある場合は、その範囲と、データにアクセスするかどうかを確認します。
発注後のHanami開発の進め方
要件定義から保守までを、連続した工程として管理します。そのうえで、各工程の終わりに成果物をレビューして、次へ進むかどうかを判断します。
Hanamiのコード構成を見るだけでなく、業務が実際に回るかも、発注者と開発会社で確かめます。
要件定義とアーキテクチャ設計の固め方
設計とPoCでは、次の範囲を順に確かめます。
- 適用範囲：Hanamiを全体に使うか、APIや特定Sliceに使うかを決めます。
- 構成設計：認証、権限、DB、外部APIを設計します。ファイル保存、ログ、監視、CI/CDも対象で、各要素の責務を確認します。
- 縦切りPoC：ログインから主要業務の登録・承認・検索までを通し、Hanami 3.0、Ruby 3.3、DB、認証、デプロイ、監視を検証します。
開発会社には、Action・Operation・View・Relation・Repositoryの責務分担も説明してもらいます。
全機能を一度に作らず、少しずつ検証すると、技術選定の不確実性を早めに見つけられます。
設計・実装での業務ルールとテスト対象
設計・実装では、業務ルールをどこに置くかと、テストの対象をそろえておきます。単体テストに加えて、次も対象にします。
- 責務分担：HTTP受付はAction、登録・承認・決済・在庫引当はOperationに寄せます。
- 領域連携：Sliceを業務境界にする場合、領域間のデータ連携方法と責任者を記録します。
- 自動テスト：主要業務、権限エラー、外部API失敗、二重送信、データ不整合。
なお、Hanami 3.0ではMinitestも選択肢になります。テストフレームワークを選ぶ前に、何を合格とするかを先に決めます。
移行・リリース・保守の本番前の準備
移行から本番後まで、発注者と開発会社が次の確認を続けます。
- 本番前：移行リハーサル、権限確認、バックアップからの復旧、負荷・脆弱性試験、障害連絡訓練を実施します。
- 移行記録：対象件数、変換エラー、処理時間、照合結果を残します。
- リリース後：アクセスログ、エラー率、応答時間、ジョブ失敗、連携滞留を監視し、月次で改善課題を洗い出します。
HanamiやRubyの更新を先送りすると、依存するGemやOSのサポート終了が、大型改修につながることがあります。そこで、更新検証の頻度と費用を保守契約に含めておきます。
Hanamiのシステム発注費用と相場の目安
Hanami固有の公開価格相場は、確認できません。そのため、国内のRuby・Web業務システムに近い案件から整理した推定レンジを示します。
価格は、Hanamiを採用したかどうかよりも、要件や画面数、連携数で大きく変わります。さらに、データ移行やセキュリティ、テスト、保守体制も、費用に響きます。
規模別の費用レンジと予算の起点
規模と機能範囲に合わせて、類似業務システムの推定レンジを予算の起点にします。
- 小規模PoC・MVP：300万〜800万円程度
- 標準的な業務Web：800万〜2,000万円程度
- 中〜大規模案件：2,000万〜5,000万円以上となる可能性があります
小規模はログインと数画面のCRUD、簡易管理画面、少数のAPIを想定します。標準規模では、ユーザー・権限や申請・承認、検索・帳票を含みます。さらに、メールや外部APIも対象に入ります。
中〜大規模は、複数部門や複雑なワークフローを含む場合です。基幹・会計・在庫との連携、データ移行、監査も、その範囲に入ります。
この金額は、リサーチノートに基づく類似業務システムの推定で、Hanami専用の実績値ではありません。実額は、RFPとPoC後の見積で確定します。
人月単価と工数で見る見積の読み方
2025年時点の参考人月単価は、PMが月70万〜130万円、シニアエンジニアが月80万〜120万円、中堅エンジニアが月50万〜70万円です（出典: 株式会社ripla、2025年時点の参考値）。
これは官公庁案件を含む一般的な参考単価であり、Hanami案件の確定単価ではありません。そのため、見積では単価に加えて、各工程や職種の工数を確かめます。
工程ごとの配分も比べると、設計や検証に必要な工数が見積に反映されているかを判断できます。
- 要件定義・基本設計：総額の10〜20%
- 製造・単体テスト：30〜40%
- 結合・総合テスト：15〜20%
- 移行・導入：5〜10%程度
この比率は、案件の性質によって変わります。ただし、設計やテストが極端に少ない見積に気づく参考にして、各社に前提の説明を求めます。
保守費用とクラウド費用の切り分け方
ランニングコストは、次の費用を初期費用とは分けて見積もります。
- 基盤：クラウド利用料、監視、バックアップ
- 運用保守：障害・脆弱性対応、問い合わせ
- 更新・改修：Ruby・Gem・Hanamiの更新、追加改修
スクラッチ開発の保守は、初期費用の年15〜20%程度を第一候補に置く考え方があります。ただし、24時間監視やSLA、セキュリティ診断の有無で変わるため、固定の相場とは限りません。
初期費用が1,000万円なら、保守の検討レンジは年150万〜200万円程度から始まります。そこに、対応時間や改修範囲を加えると上振れします。
開発見積に保守が含まれるか、クラウド契約が発注者名義か、障害時に追加費用が出るかを、分けて確認します。
Hanamiの委託先選定と見積比較で確認すべきポイント
Hanami対応を掲げる会社が少ない場合でも、検索の上位だけで選ぶ必要はありません。直接経験、Ruby・Railsの業務実績、設計・テスト・保守体制は、分けて確認します。
提案の具体性と、自社との相性も評価します。
Hanamiの直接経験と隣接実績の区別
候補会社には、Hanami 3.0とRuby 3.3の本番経験や、Hanami 2系以前の経験について尋ねます。さらに、Action・Operation・Sliceの設計例も聞きます。担当予定者が設計・実装するかも確認します。
公開事例がRubyやRailsだけの場合は、Hanamiの導入事例と混同せず、業務Webを長期運用した周辺の証拠として評価します。
設計理由は、エンジニアやアーキテクトに直接聞くと確かめられます。認証や権限、エラー処理、ログを説明できるかを見ます。さらに、テスト、DB移行、運用まで説明できるかも確かめます。
同じ前提をそろえた見積の比較
相見積もりでは、同じRFPと画面一覧、外部連携数、移行対象、非機能要件を各社に渡します。そのうえで、総額に加えて、対象範囲や除外項目、工程別工数、納品物、前提条件を比べます。
また、追加変更の単価や保守費用、リリース後の支援も比較します。安い見積は、要件定義やQA、セキュリティ、移行、監視、ドキュメントの抜けを確認します。
一方、高い見積には、PoC、負荷試験、運用設計、教育、手厚い保守が含まれる場合があります。そのため、各社には、含む作業と含まない作業を同じ形式で回答してもらいます。
契約前にそろえる発注先への質問
Hanamiの版や担当者の経験、PoC、アジャイルと請負の使い分けを質問します。さらに、設計書やテスト仕様の納品範囲、コード管理場所、再委託、保守受付時間、脆弱性対応も確認します。
回答は口頭で済ませず、提案書や見積の前提に反映します。また、発注者側の業務担当者の参加時間、データ提供期限、受入テスト担当、意思決定者も押さえます。
アカウント発行や社内規程の確認が遅れると、納期を守れなくなるおそれがあります。そのため、双方の作業をWBSに入れ、遅延時の連絡と判断ルールを合意しておきます。
Hanamiのシステム発注で起きやすい失敗と対策
起こりやすい失敗は、フレームワークを先に決めて、業務要件や保守体制を後回しにしてしまうことです。Hanamiを採用する理由は、自社の課題と結びつけて考えます。
関心の分離や長期保守、独自ロジック、APIの軽量性などを検討します。そのうえで、RailsやSaaSとの比較結果も記録しておきます。
担当者依存とベンダーロックインの防止
Hanamiを扱える人は限られるため、特定の担当者しか分からない構成は避けます。そこで、コードレビュー、設計書の更新、テスト自動化、リポジトリ管理を納品条件に含めます。
運用手順は文書にまとめ、月次で社内担当者へ説明する場も設けます。さらに、クラウドやコード、ドメイン、外部APIの契約名義も決めておきます。
発注者が管理者権限を持ち、開発会社には必要な範囲だけ付与します。こうしておくと、契約終了や再委託のときに移管しやすくなります。
Hanamiだけに頼らないセキュリティ対策
セキュリティは、アプリと基盤の両面から対策を考えます。そのうえで、確認担当を契約で定めます。
- アプリ：認証、二要素認証、権限、監査ログ、秘密情報、脆弱性対応
- 基盤：バックアップと障害復旧を設計します。
- 運用：アプリ、クラウド、端末、組織ごとに確認担当と時期を決めます。
個人情報を扱う場合は、委託先のアクセス範囲や再委託の承認、ログ確認を定期的に見直します。さらに、退職者のアカウント削除や、バックアップの保管と廃棄も対象です。
診断を行う場合は、対象URLや認証状態、実施時期を決めたうえで、報告書と修正確認までを見積に含めます。
最初のリリース範囲の絞り込み
機能を盛り込みすぎると、予算と納期が膨らみ、利用者の反応を確かめないまま本番を迎えることになります。そこで、最初は頻度が高く、効果を測りやすい業務を縦切りにします。
周辺機能は、優先順位を付けて次期へ送ります。ただし、将来の拡張を妨げないよう、データ設計と権限設計は初期に検討します。
PoCで主要業務と技術基盤を確かめます。さらに、利用率や処理時間、入力ミス、問い合わせ件数などを測り、次の投資判断につなげます。
よくある質問（FAQ）
Hanamiの発注では、会社の探し方、費用、Railsとの違い、保守の継続について質問されます。外注前に確認したい疑問に、順に答えます。
Hanami専門の開発会社が見つからない場合はどうしますか？
公開導入実績が少ない場合は、候補を広げます。たとえば、Ruby・Railsの業務Web開発や保守、AWSなどのクラウド、データ移行の実績がある会社も対象にします。
Hanami 3.0とRuby 3.3の経験、担当者、PoC、SliceやOperationの設計方針を尋ねます。直接経験と隣接経験は、分けて評価します。
Hanamiのシステム開発費用を安くできますか？
費用を抑えたい場合は、SaaS・パッケージとの併用や、初回リリース範囲の絞り込みを検討します。ただし、Hanamiを選ぶこと自体で、費用が下がるとは限りません。
既存業務の標準化や要件定義の前倒し、内製と外注の分担によっても、不要な開発工数を減らせます。
RailsからHanamiへ移行して発注できますか？
移行は可能ですが、一括で書き換える前に、APIや業務境界の単位で段階的に移せるかを調査します。既存のGemやRuby、DB、認証を確認します。バッチや外部連携、テスト資産も、あわせて見ます。
データを二重に管理する期間と、切り戻しの方法をPoCで検証します。その結果をもとに、本移行の費用と納期を見積もります。
発注前に契約書で特に確認すべきことは何ですか？
まず、成果物と検収、変更管理、コードや設計書の納品を確認します。次に、知的財産やOSS、再委託、個人情報の扱いを見ます。さらに、障害対応や保守、契約終了時の移管も確認します。
また、法務や情報セキュリティの担当者にも、レビューを依頼します。発注者側のデータ提供と受入テストの責任も、契約や計画に記載します。
まとめ
発注時は、見積の総額だけでなく、業務シナリオや非機能要件、移行、契約、保守を一つの計画にまとめます。
Hanami 3.0やRuby 3.3への対応、Slice・Action・Operationなどの設計方針も、確認材料になります。
発注前に実施することの整理
発注前の流れは、方式比較、要件整理、契約選定、見積比較の順です。工程に合う契約を選ぶと、変更への対応や完成条件を明確にできます。
- SaaS・パッケージ、Hanamiのスクラッチ、内製と外注の混成を比べます。
- 業務シナリオとRFPを作り、機能、非機能、移行、受入条件をそろえます。
- 要件定義やPoCは準委任型、完成条件が明確な工程は請負型などを選びます。
見積比較での価格の理由と納品後の確認
費用はHanami固有の定価ではなく、要件と工数で決まります。推定レンジを起点に、各社の前提や除外、工程別工数を比べます。さらに、保守やセキュリティ、移管条件も比べます。
- 小規模PoC・MVP：300万〜800万円程度
- 標準業務Web：800万〜2,000万円程度
- 中〜大規模案件：2,000万〜5,000万円以上となる可能性があります
また、技術選定だけでなく、事業成果と運用定着まで説明できる会社を選びます。業務の優先順位や判断者、データ、リスクを共有しておくと、無理のない範囲から改善を続けやすくなります。
▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。