Hanamiのシステム開発の発注/外注/依頼/委託方法について

Hanamiのシステム開発を発注・外注するなら、フレームワーク名だけで会社を選ばず、業務要件・非機能要件・保守範囲・契約上の責任を先に固めることが成功の近道です。

HanamiはRubyでWebアプリケーションや業務システムを構築できるフレームワークですが、公開されているHanami専門会社や価格表は限られます。この記事では、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の探し方、見積書の比較方法まで、Hanamiのシステムを外注する前に確認すべきポイントを順番に解説します。

▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド

Hanamiのシステムを発注する前に知っておきたい全体像

Hanamiのシステム発注では、「Hanamiで作れるか」だけを確認しても適切な見積にはつながりません。画面やAPIの数に加えて、業務ルール、権限、既存データ、外部サービスとの連携、運用体制まで決めて初めて、各社の提案を同じ条件で比較できます。

Hanamiは、受発注、顧客・会員管理、予約、社内申請、問い合わせ管理などの画面付き業務システムに使えます。RESTやJSONのAPI、管理画面、バッチ、外部サービスとのデータ連携も設計対象になります。公式ドキュメントでは、HTTPの入口を担うAction、業務手続きを表現するOperation、表示を担うView、データアクセスを分けるRelationやRepository、業務領域を分けるSliceという考え方が示されています。

たとえば受注業務なら、顧客管理・受注・請求をSliceとして境界づけ、注文受付をAction、承認と在庫引当をOperation、検索や保存をRelation・Repositoryに分ける構成を検討できます。発注者は技術用語を暗記する必要はありませんが、「業務領域をどう分け、どこにルールを置くのか」は提案段階で説明してもらうと、将来の保守性を見極めやすくなります。

2026年6月に公開されたHanami 3.0では、メーラー、国際化、Minitest、ログやアセットの改善などが追加されています（出典: Hanakai公式ブログ、2026年）。同じ「Hanami対応」でも、Hanami 1系や2系の経験と、Hanami 3.0をRuby 3.3以降で運用する経験は分けて確認する必要があります。

問い合わせ時には、Hanamiのバージョン、Rubyのバージョン、利用するDBや認証方式、CI/CD、監視の構成を質問します。Hanami 3.0の導入を想定する場合は、既存のRuby・Gem・OSとの互換性をPoCで検証し、公式発表にあるベンチマーク値を自社の業務シナリオへそのまま当てはめない姿勢も重要です。

Hanami自体はオープンソースのフレームワークのため、ライセンス料が開発費の中心になるわけではありません。費用を左右するのは、要件定義、画面数、権限、帳票、外部API、データ移行、テスト、インフラ、保守です。Rubyの経験者が必要になる一方、Hanami固有の設計調査や社内教育が増える場合もあるため、Railsより必ず安い、または高いとは断定できません。

Hanamiのシステム発注形態はどのように選びますか？

結論から言うと、業務や仕様が固まっていない段階で本開発を一括発注するより、要件整理や小規模PoCを先に委託し、その結果に応じて開発契約へ進む方法が安全です。社内の技術力と業務知識、納期の固定度、変更の多さを見ながら、スクラッチ開発、SaaS・パッケージ併用、内製と外注の混成を比較します。

独自の承認フロー、複雑な料金計算、在庫引当、顧客ごとの例外処理などが事業上の強みなら、Hanamiで業務ロジックを明示的に実装する意義があります。将来、受注・請求・在庫の各領域を別々に改修したい場合も、Sliceなどで境界を設計できるHanamiの特徴を活かしやすくなります。

ただし、画面を作ること自体が目的にならないようにします。受注時間の短縮、入力ミスの削減、月次締めの早期化など、導入後に測る成果指標を先に決め、発注先にはその指標に寄与する業務フローを提案してもらいます。

勤怠、会計、電子契約、チャットなど標準化された業務はSaaSやパッケージを使い、独自性の高い受注画面や社内APIだけをHanamiで作る構成も有力です。すべてをスクラッチ開発するより初期範囲を絞りやすく、既製サービスのアップデートも活用できます。

一方で、SaaS側のAPI制限、データの保管場所、ユーザー課金、解約時のデータ返却、障害時の責任分界を確認します。外部サービスを組み込む場合は、連携が止まったときの再送、重複登録防止、手動復旧の手順までRFPに書くと、見積の抜けを抑えられます。

社内に業務知識があるなら、企画・優先順位・受入テストは自社が持ち、Hanamiの設計・実装・インフラを外注する役割分担が現実的です。2026年のJUAS「企業IT動向調査2026」でも、システム開発は内製と外部委託の使い分けを目指す企業が多いと整理されています（出典: 一般社団法人日本情報システム・ユーザー協会、2026年）。

発注時は、定例会議への参加、設計レビューの方法、ソースコードの説明、運用引き継ぎの回数を成果物や作業範囲に入れます。単に納品を受けるのではなく、社内担当者が半年後に小さな改修を判断できる状態を目標にすると、ベンダーロックインを下げられます。

RFPと要件整理はどのように進めますか？

RFPは、発注者が解決したい課題と希望するシステムの条件を候補会社へ伝える文書です。機能一覧だけでは会社ごとに解釈が変わるため、現状業務、目的、対象ユーザー、データ、非機能、納期、予算の考え方、提案に求める内容を一つの資料にまとめます。

最初に「誰が、いつ、何を入力し、誰が承認し、次にどのデータを渡すか」を業務シナリオとして整理します。受注なら、見積登録、承認、在庫確認、出荷指示、請求確定のように業務の流れを書き、例外としてキャンセル、返品、権限不足、連携失敗を加えます。

この作業を行うと、単純なCRUD画面に見えていた機能が、承認条件や履歴管理を含む業務ロジックだと分かります。RFPには必須機能と将来機能を分け、今回のリリースで実現する範囲を明記します。優先度が曖昧なまま見積を求めると、会社ごとの想定範囲がずれて比較できなくなります。

非機能要件には、同時利用者数、応答時間、稼働時間、バックアップ、障害復旧、ログ保管、データ所在地、認証、権限、監査ログ、脆弱性対応を含めます。「速く」「安全に」ではなく、通常時の応答時間、ピーク時の同時接続、目標復旧時間RTO、許容できるデータ損失RPOなど、検証できる形にします。

個人情報を扱う場合は、アプリの機能だけでなく、アクセス制御、操作記録、バックアップの暗号化、委託先と再委託先の監督をRFPと契約へ反映します。個人情報保護委員会のガイドラインでも、委託先の取扱状況を定期的に把握し、再委託先について事前報告・承認や監査を検討することが示されています（出典: 個人情報保護委員会、通則編ガイドライン）。

既存の顧客、商品、組織、権限、受注履歴を移行する場合は、移行元の項目一覧、欠損や重複の扱い、名寄せルール、移行対象期間、検証方法を決めます。移行データの整理を発注者と受注者のどちらが担うかも明記します。ここが曖昧だと、開発会社の工数だけでは解消できない問題が納品前に集中します。

受入条件には、主要シナリオの合格基準、テストデータ、重大障害の定義、残課題の扱い、検収期限を入れます。性能なら同時利用者数と目標応答時間、セキュリティなら対象範囲と指摘の修正期限を指定します。RFPの段階でここまで整理できるほど、見積の根拠と契約後の責任分界が明確になります。

Hanamiのシステム開発ではどの契約形態を選びますか？

契約形態は、仕様の確定度と変更の多さで選びます。要件定義や調査は準委任型、完成物と受入基準が明確な工程は請負型、優先順位を変えながら継続開発する場合はアジャイル型の準委任を検討します。名称だけで判断せず、成果物、作業時間、検収、変更手続き、責任範囲を契約書と個別契約で確認します。

業務の現状調査、RFPの補完、画面モック、データ調査、PoCは、作業を通じて前提が変わりやすい工程です。作業時間と進捗をもとに進める準委任型にし、毎週の成果物レビューと次工程へ進む判断を設定すると、曖昧な要件を抱えたまま大きな請負契約へ進むリスクを抑えられます。

ただし準委任だから成果物が不要になるわけではありません。業務フロー、要件一覧、画面遷移、データモデル、非機能要件、PoC結果、未決事項を納品物として定義し、作業時間だけでなく次の判断に使える記録を残します。

仕様、納期、検収基準が合意できる基本設計や特定機能の開発は、請負型で完成物と責任を明確にしやすくなります。HanamiのSlice単位や主要業務の縦切り単位で範囲を区切り、機能一覧だけでなく、エラー処理、権限、ログ、テスト、ドキュメントを含めて完成と定義します。

請負型で注意したいのは、契約後の追加要望が無償対応と誤解されることです。仕様変更の判定者、追加見積の計算方法、納期への影響、変更承認の期限を変更管理表で運用し、口頭の依頼をそのまま開発へ流さないルールを作ります。

契約では、ソースコード、設計書、テスト仕様書、Gemfile.lock、CI/CD定義、インフラコード、監視設定、バックアップ手順、アカウント情報の管理方法を納品範囲に含めます。第三者ライブラリのライセンス表示や、OSSに対する修正の扱いも確認します。

保守契約には、問い合わせ対応時間、障害の優先度、目標初動時間、復旧方法、Hanami・Ruby・Gemの更新、脆弱性情報への対応、追加改修の単価を分けて書きます。開発会社が再委託する場合は、再委託先の範囲とデータアクセスの有無も確認します。

発注後のHanami開発はどのように進めますか？

発注後は、要件定義、設計、実装、テスト、移行、リリース、保守を一つの連続した工程として管理します。各工程の終わりに成果物レビューと次へ進む判断を置き、Hanamiのコード構成だけでなく、業務が実際に回るかを発注者と開発会社で確認します。

要件定義では、業務シナリオを機能要件へ落とし、Hanamiをシステム全体に使うのか、APIや特定のSliceだけに使うのかを決めます。認証、権限、DB、外部API、ファイル保存、ログ、監視、CI/CDを設計し、開発会社からAction・Operation・View・Relation・Repositoryの責務分担を説明してもらいます。

最初から全機能を作るのではなく、ログインから主要業務の登録・承認・検索までを通す縦切りのPoCを実施します。Hanami 3.0、Ruby 3.3、DB、認証、デプロイ、監視を一度に検証できるため、技術選定の不確実性を早めに見つけられます。

実装では、HTTPの受付をActionに、登録・承認・決済・在庫引当などの手続きをOperationに寄せ、画面表示やDBアクセスへ業務ルールを混在させない設計を目指します。Sliceを業務領域の境界として扱う場合は、領域をまたぐデータ連携の方法と責任者も設計書へ記録します。

自動テストは、単体テストだけでなく、主要業務シナリオ、権限エラー、外部APIの失敗、二重送信、データ不整合を対象にします。Hanami 3.0ではMinitestも選択肢になっていますが、採用するテストフレームワークより、何を合格とするかを先に決めることが大切です。

本番前には、移行リハーサル、権限確認、バックアップからの復旧、負荷試験、脆弱性チェック、障害連絡の訓練を行います。移行対象の件数、変換エラー、処理時間、照合結果を記録し、リリース当日に初めてデータ問題が見つからないようにします。

リリース後は、アクセスログ、エラー率、応答時間、ジョブ失敗、外部連携の滞留を監視し、月次で改善課題を確認します。HanamiやRubyの更新を先送りすると、依存GemやOSのサポート終了が将来の大型改修につながるため、更新検証の頻度と費用を保守契約に含めます。

Hanamiのシステム発注費用と相場はいくらですか？

Hanami固有の公開価格相場は確認できないため、以下は国内のRuby・Web業務システムに近い案件から整理した推定レンジです。Hanamiを採用しただけで価格が決まるわけではなく、要件、画面数、連携数、データ移行、セキュリティ、テスト、保守体制によって大きく変わります。

小規模PoCやMVPは、ログイン、数画面のCRUD、簡易管理画面、少数のAPIを範囲として、300万〜800万円程度が一つの検討レンジです。標準的な業務Webシステムで、ユーザー・権限、申請・承認、検索・帳票、メール、外部APIを含める場合は、800万〜2,000万円程度が目安になります。

複数部門、複雑なワークフロー、基幹・会計・在庫連携、データ移行、監査を含む中〜大規模案件は、2,000万〜5,000万円以上となる可能性があります。これらはHanami専用の実績値ではなく、リサーチノートに基づく類似業務システムの推定です。実際の金額はRFPとPoC後の見積で確定します。

2025年時点の参考値として、プロジェクトマネージャーは月70万〜130万円、シニアエンジニアは月80万〜120万円、中堅エンジニアは月50万〜70万円程度という人月単価が紹介されています（出典: 株式会社ripla、2025年時点の参考値）。これは官公庁案件を含む一般的な人月単価の参考であり、Hanami案件の確定単価ではありません。

見積書では、単価だけでなく、PM、設計、実装、QA、デザイナー、インフラの各工数を確認します。要件定義・基本設計を総額の10〜20%、製造・単体テストを30〜40%、結合・総合テストを15〜20%、移行・導入を5〜10%程度と仮置きすると、極端に設計やテストが少ない見積を見つけやすくなります。ただしこの比率も案件の性質によるため、会社ごとの前提説明を求めます。

ランニングコストには、クラウド利用料、監視、バックアップ、障害対応、脆弱性対応、Ruby・Gem・Hanamiの更新、問い合わせ、追加改修が含まれます。スクラッチ開発の保守は初期費用の年15〜20%程度を第一候補に置く考え方がありますが、24時間監視やSLA、セキュリティ診断を含めるかで変わるため、固定の相場として断定しません。

初期費用1,000万円の案件を例にしても、保守の検討レンジは年150万〜200万円程度から始まり、対応時間や改修範囲を加えると上振れします。開発見積に保守が含まれているのか、クラウド契約は発注者名義か、障害時の追加費用があるのかを分けて確認すると、導入後の予算を組みやすくなります。

Hanamiの委託先選定と見積比較で確認すべきポイント

Hanami対応を掲げる会社が少ないからといって、検索結果の最上位をそのまま発注先にする必要はありません。Hanamiの直接経験、Ruby・Railsの業務システム実績、設計・テスト・保守の体制を分けて確認し、提案の具体性と自社との相性を総合的に評価します。

候補会社には、「Hanami 3.0とRuby 3.3の本番経験があるか」「Hanami 2系以前の経験か」「Action・Operation・Sliceの設計例を説明できるか」「担当予定者が実際に設計・実装するか」を確認します。公開事例がRubyやRailsだけの場合は、Hanamiの導入事例と混同せず、業務Webを長期運用した周辺証拠として評価します。

特に重要なのは、会社の営業担当ではなく、担当エンジニアやアーキテクトから設計理由を説明してもらうことです。サンプルコードの提示だけでなく、認証、権限、エラー処理、ログ、テスト、DB移行、運用の考え方まで話せるかを見ます。

相見積もりでは、同じRFP、同じ画面一覧、同じ外部連携数、同じ移行対象、同じ非機能要件を渡します。比較軸は総額だけでなく、対象範囲、除外項目、工程別工数、納品物、前提条件、追加変更の単価、保守費用、リリース後の支援です。

見積が安い場合は、要件定義、QA、セキュリティ、移行、監視、ドキュメントが抜けていないかを確認します。逆に高い見積もりでも、PoC、負荷試験、運用設計、教育、手厚い保守が含まれている可能性があります。各社へ「この金額で含む作業と含まない作業」を同じ形式で回答してもらうと、価格差の理由を説明できます。

候補会社へは、Hanamiのバージョン対応、担当者の経験、PoCの進め方、アジャイルと請負の使い分け、設計書とテスト仕様の納品範囲、ソースコードの管理場所、再委託の有無、保守の受付時間、脆弱性対応の方法を質問します。回答を口頭だけで終わらせず、提案書や見積の前提へ反映します。

発注者側の責任も確認します。業務担当者の参加時間、データ提供の期限、受入テストの担当、意思決定者、アカウント発行、社内規程の確認が遅れると、開発会社だけでは納期を守れません。双方の作業をWBSへ入れ、遅延時の連絡と判断のルールを合意します。

Hanamiのシステム発注で起きやすい失敗と対策

Hanamiの発注で起こりやすい失敗は、フレームワークの選択を先に決め、業務要件や保守体制を後回しにすることです。Hanamiを採用する理由を、関心の分離、長期保守、独自ロジック、APIの軽量性など自社の課題と結びつけ、RailsやSaaSとの比較結果も記録します。

Hanamiを扱える人が限られるからこそ、特定の担当者しか分からない構成にしないことが大切です。コードレビュー、設計書の更新、テスト自動化、リポジトリ管理、運用手順の文書化を納品条件にし、月次で社内担当者へ説明する場を設けます。

クラウド、ソースコード、ドメイン、外部APIの契約名義を誰にするかも決めます。発注者が管理者権限を保有し、開発会社には必要な範囲だけを付与する構成にすると、契約終了や再委託時の移管が容易になります。

認証、二要素認証、権限、監査ログ、秘密情報管理、脆弱性対応、バックアップ、障害復旧は、フレームワークを導入するだけで完成しません。アプリケーション、クラウド、端末、組織の運用ルールを分けて設計し、誰がいつ何を確認するかを契約へ落とし込みます。

個人情報を扱う場合は、委託先のアクセス範囲、再委託の承認、ログの確認、退職者のアカウント削除、バックアップの保管と廃棄を定期的に見直します。セキュリティ診断を実施する場合は、対象URL、認証状態、実施時期、報告書、修正確認までを見積へ含めます。

機能を盛り込みすぎると、予算と納期だけが膨らみ、利用者の反応を確認できないまま本番を迎えます。最初のリリースは、最も頻度が高く効果を測りやすい業務の縦切りにし、周辺機能は優先順位を付けて次期へ送ります。

ただし、後回しにする機能でも、将来の拡張を妨げるデータ設計や権限設計は初期に検討します。PoCで主要な業務と技術基盤を確かめ、リリース後の利用率、処理時間、入力ミス、問い合わせ件数などを測定して、次の投資判断につなげます。

よくある質問（FAQ）

Hanamiの発注では、技術の適合性だけでなく、会社の見つけ方、費用、Railsとの違い、保守の継続性について質問されます。ここでは、外注前に特に確認しておきたい疑問へ直接回答します。

Hanamiの公開導入実績が少ない場合は、Ruby・Railsの業務Web開発、保守、AWSなどのクラウド、データ移行の実績を持つ会社まで候補を広げます。そのうえで、Hanami 3.0とRuby 3.3の経験、担当者、PoC、SliceやOperationの設計方針を問い合わせ、直接経験と隣接経験を分けて評価します。

フレームワークをHanamiにするだけで費用が下がるとは限りません。SaaS・パッケージとの併用、最初のリリース範囲の絞り込み、既存業務の標準化、要件定義の前倒し、内製と外注の役割分担によって、不要な開発工数を減らす方法を検討します。

移行は可能ですが、既存システムを一括で書き換える前に、APIや業務境界単位で段階移行できるかを調査します。既存Gem、Ruby、DB、認証、バッチ、外部連携、テスト資産を確認し、データの二重管理期間と切り戻し方法をPoCで検証してから、本移行の費用と納期を見積もります。

成果物と検収、変更管理、ソースコードや設計書の納品、知的財産、OSSの扱い、再委託、個人情報の安全管理、障害対応、保守、契約終了時の移管を確認します。法務や情報セキュリティの担当者にもレビューしてもらい、発注者側のデータ提供や受入テストの責任も契約・計画へ記載します。

まとめ

Hanamiのシステムを発注・外注するときは、フレームワークの知名度や見積総額だけで決めず、業務シナリオ、非機能要件、移行、契約、保守を一つの計画として整理します。Hanami 3.0やRuby 3.3の対応可否、Slice・Action・Operationなどの設計方針は、候補会社の技術力と将来の保守性を確認する材料になります。

まず、SaaS・パッケージ、Hanamiでのスクラッチ、内製と外注の混成を比較します。次に、業務シナリオとRFPを作り、必須機能、非機能、移行、受入条件をそろえます。そのうえで、要件定義やPoCは変更に対応しやすい契約、完成条件が明確な工程は請負型など、工程に合う契約を選びます。

費用はHanami固有の定価ではなく、要件と工数から決まります。300万〜800万円程度のPoC・MVP、800万〜2,000万円程度の標準業務Webシステム、2,000万〜5,000万円以上の連携型という推定レンジを出発点にし、各社の前提、除外、工程別工数、保守、セキュリティ、移管条件を同じ基準で比較します。

Hanamiのシステム開発を相談する際は、技術選定だけでなく、事業成果と運用定着まで説明できる会社を選びます。発注者と開発会社が業務の優先順位、判断者、データ、リスクを共有できれば、無理のない範囲から開発を始め、長く改善できるシステムに育てやすくなります。

▼全体ガイドの記事
・Hanamiのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。