Hanamiのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Hanamiのシステム開発は、業務の境界、責務分担、検証と運用体制を順に固めて、要件に合う形へ進めます。全体は要件整理から定着までの6フェーズに分かれます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Hanamiのシステム開発の全体像

HanamiはRubyでWebアプリや業務システムを構築するフレームワークで、業務ルールを保守しやすい単位に分けて実装するための土台です。受発注、顧客管理、予約、申請、問い合わせ、外部連携などが対象になります。

開発の成否は、Hanamiを採用するかどうかだけでなく、業務の境界、データの責任、運用体制を最初に決められるかで変わります。

業務の増加に耐えやすいモジュール構成

Hanamiは、関心の分離、明示的な業務ロジック、モジュール化を重視する設計です。Hanami公式も、各層の責務を説明しています。

• Action：HTTPの入口
• Operation：成功・失敗を含む業務手続き
• Relation・Repo：データアクセス
• View・Slice：表示と業務領域の境界

たとえば、受注登録では、Actionが入力を受け、Operationが在庫引当や承認可否を判断します。RelationやRepoがデータを扱い、Viewが画面用に整えます。

この構造は、担当者や業務ルールが増えたときに、変更箇所を追いやすくする効果が期待できます。ただし、責務を分ける設計とレビューが欠かせません。

短期の画面試作では、この構造が過剰になる場合もあります。

長期運用する独自業務か、複数領域の境界をまたぐ業務か、Rubyの保守担当を確保できるかを確かめて選びます。

Hanami 3.0の新規開発で増える検証項目

2026年6月の公式発表をもとに、追加機能、互換性、移行時の作業を見ておきます。

• 追加機能：メーラー、国際化、Minitestが加わりました。ログの改善、リクエスト解析、アセット監視も追加されています。
• 実行環境：Ruby 3.3以上が必要です。既存のRuby・Gem、OS、CI環境との互換性を調べます。
• 既存アプリの移行：メール通知や多言語画面は便利になる一方で、Gemの互換性調査とテストの再実行を見積もりに含めます。

公式テストアプリでは、同じHTTPリクエストのスループットが2.3比で約3.7倍でした。

p99レイテンシも20msから4msと報告されています（出典：Hanami 3.0公式発表、Hanakai、2026年）。

ただし、これはテストアプリでの比較値で、自社システムの性能を示すものではありません。実際の応答時間は、DBや外部API、インフラの条件で変わり、クエリやネットワークの状態も影響します。

負荷試験は、採用前に自社の代表シナリオで行います。

Hanamiのシステム開発の進め方と6フェーズ

Hanami開発は、要件整理から定着までの6フェーズに分けて管理できます。

後工程で起きる問題を前工程の成果物に戻して確かめられる状態が大切です。そのため、画面一覧だけで発注せず、業務シナリオやデータ移行を含めて、非機能要件と運用手順まで段階的に合意します。

1. 要件整理フェーズの業務と成果指標

業務要件と成果指標は、業務シナリオや測定可能な目標の形に落とし込んでおきます。

• 業務シナリオ：誰がいつ何を判断し、何を次工程へ渡すかを書き出します。受注なら、受付と在庫確認、承認、出荷依頼、請求の順に、担当者や分岐を表にします。
• 対象と条件：画面数だけでなく、例外処理や部門権限も見ます。業務範囲、利用者・権限、処理件数に加えて、締め時間や既存システムとの境界を定めます。
• 保持期間と指標：データの保持期間を決め、「月末処理を2時間以内」「差し戻し理由を100%記録」のように、測定できる目標を置きます。
• 採用範囲：新規システム全体、APIのみ、特定Sliceのどこまでを採用するかを、既存Railsからの段階移行と比べます。

2. 選定フェーズの技術と開発体制の確認

発注先は、Hanami対応を掲げているかだけでなく、実務の経験で判断します。たとえば、Hanami 3.0とRuby 3.3以上の実務経験や、Action・Operation・Slice・Relation・Repoの設計方針を確かめます。

データ移行やクラウド、監視、リリース後の保守体制も見ておきます。

Hanami導入事例がなければ、RubyやRailsの業務Web実績を隣接実績として評価します。

Hanami案件で追加で検証する内容は、提案書に明記してもらいます。主要業務の縦切りPoCを提案してもらうと安全です。PoCでは、ログインから登録、承認、検索まで動かします。あわせて、Rubyの環境やDB、認証、CI/CDが成り立つかを確かめます。自動テストやログ、監視も対象です。

• 保守体制：本番保守まで同じチームが担うか。
• 成果物：設計書とテスト仕様書のサンプルを見られるか。
• 障害対応：連絡時間と復旧目標は何か。

3. 設計・開発フェーズの責務とデータの分割

責務分担、縦切り開発、確認する成果物は、次のとおりそろえます。

• 責務分担：受注と請求などの業務をSliceに分け、Action、Operation、Relation・Repo、Viewに責務を割り当てます。
• 業務ロジック：請求額や与信確認をOperationに置くと、画面とバッチで共有できます。Actionやテンプレートに判断を直接書かない形にします。
• 縦切り開発：主要業務を通して動かし、入力と検証、権限、DB登録を確かめます。通知やエラー表示、監査ログまで含めます。
• 確認と成果物：発注者は画面と業務結果を見て確かめます。成果物には画面・API一覧やデータモデル、権限表を入れ、連携仕様やエラー・バックアップ方針も含めます。
• 変更管理：未決事項を一覧にし、変更の履歴を残します。

4. テストフェーズの業務・性能・安全性の確認

テスト計画では、業務、非機能要件、安全管理それぞれの確認項目と合格条件を定めます。

• 業務テスト：Operationの成否と権限別の表示を確かめます。重複登録や通信失敗、外部APIのタイムアウト、締め処理、移行後の件数も対象です。
• テスト体制：単体から脆弱性確認までの各テストについて、担当者と合格条件を先に決めます。
• 非機能要件：同時利用者数、応答時間（平常時とピーク時）、稼働率、RPO・RTOを数値にします。バックアップ・ログの保管期間と障害連絡時間も数値にします。
• 個人情報：権限分離と二要素認証、通信・保存データの暗号化、監査ログを確かめます。脆弱性対応の期限も決めておきます。

個人情報保護委員会は、事業規模やデータの性質・量に応じた安全管理措置を示しています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年改正）。

5. 稼働フェーズの移行と切り替えの管理

データ移行と現場の切り替えは、本番稼働の前に次のとおり確認します。

• 移行対象：顧客、商品、組織、権限、過去取引などのサンプルを、早い段階で試します。
• データ品質：名寄せや欠損・重複の扱い、移行後の件数を照合します。発注者が整備する場合は、担当部署と期限、品質基準を計画や契約に記載します。
• 切り替え方式：一斉移行、部門ごとの段階移行、旧システムとの並行稼働から選びます。その判断は、停止可能時間や連携、教育範囲、問題時に戻せるかで行います。
• リリース判定：重大障害がないか、受入テストが完了しているか、復元を確認できるかを確かめます。問い合わせ窓口と緊急連絡網が機能するかも見ます。

6. 定着フェーズの運用と改善の仕組み

定着と保守では、運用手順、成果指標、契約範囲、引き継ぎ資料を整えておきます。

• 運用手順：業務ごとの操作、障害対応、アカウント管理、バックアップ、月次のログレビューを書き残します。
• 利用状況：利用率や入力漏れ、処理時間、差し戻し率を毎月見て、業務成果とのつながりを確かめます。
• 保守契約：問い合わせと追加開発を分けたうえで、Ruby・Gem・Hanamiの更新や脆弱性、復旧、性能、法改正の責任範囲を明記します。
• 納品物：Gemfile.lockやCI/CD、インフラコードを含めます。テスト仕様や設計書、手順、監視設定も含めます。

資料がそろっていれば、担当者や開発会社が変わるときにも、判断材料を残しやすくなります。

Hanamiのシステム開発の費用相場と内訳

HanamiはOSSのため、採用しただけでは開発費は決まりません。費用を左右するのは、要件定義から保守までの工数です。その工数は、画面・API数や権限、ワークフロー、連携の範囲で変わります。移行やテスト、インフラ、保守の分も含まれます。

Hanami固有の公開料金表がないため、次に示すのは、2025年時点の国内Webシステム人月単価と規模感を組み合わせた、2026年時点の発注計画用の推定レンジです。

規模別の費用の幅（300万円台〜5,000万円以上）

規模別の費用と期間は、含める機能や連携の範囲で変わります。

• 小規模PoC・MVP：ログイン、数画面の登録・検索、簡易管理画面、少数APIに絞る場合は、300万〜800万円程度、3〜5か月を一つの推定レンジとして見ます。
• 標準業務Web：ユーザー・権限、申請・承認、帳票、メール、外部APIを含む場合は、800万〜2,000万円程度、6〜10か月が目安です。
• 複数部門・連携型：複雑な業務や基幹・会計・在庫連携、移行、監査要件を含むと、2,000万〜5,000万円以上、10〜18か月以上の場合があります。

これらはHanami専用の実績価格ではなく、要件ごとに置いた推定です。金額は、Ruby経験者の確保や既存Gemの調査、発注者側のデータ整備で上下します。テスト設計やセキュリティレビューの工数も影響します。

riplaの費用解説では、PM・アーキテクトは月80万〜130万円程度、実装エンジニアは月30万〜100万円程度です（出典：株式会社ripla「官公庁のシステム開発の見積相場や費用/コスト/値段について」、参照2026年）。

公共案件向けの目安は、Hanami案件の価格とはみなさず、工数の比較に使います。

見積書の工程と工数の内訳

見積書を比べるときは、初期工程の配分例とランニング費用の内訳を分けて見ます。

• 要件定義・基本設計：全体の10〜20%程度。
• 製造・単体テスト：全体の30〜40%程度。
• 結合・総合テスト：15〜20%。移行・導入は5〜10%程度。
• ランニング費用：クラウド利用料や監視、バックアップ、脆弱性対応に分けて見ます。Ruby・Gem・Hanamiの更新と、問い合わせ、追加改修も別に見ます。

工程配分は固定の正解ではなく、比べるための目安です。特に、UIやPM、QA、インフラ、セキュリティ、マニュアル作成が、どの工程に含まれるかは確認します。

保守費は初期開発費の年15〜25%程度が一般的な目安として紹介されています。たとえば、初期費用が1,000万円なら、年150万〜250万円程度を最初の検討レンジにできます（出典：株式会社ripla、2026年参照）。

24時間監視やSLA、診断、休日対応を加えると費用は上振れします。そのため、対応時間帯と期限は契約に記載しておきます。

パッケージ・クラウド・スクラッチの組み合わせ

業務の標準化範囲や既存資産、運用条件に合わせて構成を選びます。

• SaaS・パッケージ：経費申請や勤怠のように標準化できる業務に使い、独自ワークフローやAPIだけをHanamiで作ると、範囲を抑えられる場合があります。
• スクラッチ：競争力のある業務ロジックや既存データを活かす場合は、Hanamiが候補になります。
• Railsからの移行：一括で書き換えるより、業務境界やAPI単位で段階的に移すほうが、比較と撤退の判断を進めやすいです。
• クラウド構成：Puma、コンテナ、RDB、オブジェクトストレージ、CDN、監視から組み立てます。
• 費用試算：月額のクラウド費と運用費を分けて、平常時、繁忙期、障害時をそれぞれ試算します。

安く見える構成でも、冗長化やバックアップ、ログ保管、データ転送、検証環境を含めると費用は変わります。

Hanamiのシステム開発で見積もりを取るポイント

良い見積もりは、合計金額だけでなく、作るものと作らないもの、担当、納期、品質が分かる形になっています。また、Hanamiの経験に加えて、設計・移行・保守を計画できるかも見ます。

次の観点をRFPや見積依頼書に含めると、提案を比べやすくなります。

要件と成果物の粒度の統一

見積依頼では、要件と検索条件、成果物、発注者側の前提を、同じ粒度でそろえます。

• 依頼資料：業務フロー、利用者・権限、画面・API、連携先を入れます。移行対象や非機能要件、希望時期、受入条件も入れます。
• 検索要件：「検索できる」だけでなく、項目や件数、権限差、CSV出力、応答時間まで記載します。
• 未確定事項：無理に決めず、調査、PoC、要件定義のどれに当たるかで分けます。
• 成果物と前提：納品物と発注者側の条件を、見積書に記載します。

成果物には、要件定義書や画面・API仕様、データモデル、Slice方針、コードを含めます。テストや移行・運用手順、監視・バックアップ設定、教育資料も列挙します。

レビュー回数や承認期限、データ提供の責任も記載しておきます。特に、納品物の一覧がないと、金額が同じでも作業範囲を比べられません。

複数社の前提条件による比較

複数社に同じRFPを渡し、金額の前提と技術実績をそろえて比べます。安価に見える提案でも、テストや移行を発注者側へ移している場合があります。

• 比較範囲：要件定義から保守までを、同じ項目で比べます。
• 見積条件：人月、経験、体制、方式を並べます。検証範囲、除外事項、変更単価、保守時間帯も並べます。
• 技術実績：HanamiとRuby・Railsの実績を分けて、Hanami 3.0・Ruby 3.3以上への対応、設計例、Rails・SaaSとの併用を尋ねます。
• 保守担当：Gem更新と脆弱性対応を、誰が担うかを確かめます。

Ruby活用事例には、STORESやIVRy、タイミー、Shippioなどが掲載されています。ただし、Rubyの本番活用例は、Hanami導入事例と同じ意味ではありません（出典：Rubyアソシエーション「Ruby活用事例」、参照2026年）。

変更・移行・保守のリスクと契約前の対応

仕様変更や移行、セキュリティに関する条件は、契約の前に明確にしておきます。

• 費用増加の要因：仕様変更、データ品質、外部API差、権限設計のやり直し、受入担当者の不足が挙げられます。
• 変更管理：追加や削除、延期を記録します。画面やデータ、テスト、納期、金額への影響を承認してから着手します。
• 契約範囲：定額契約でも、範囲や変更方法が曖昧だと予算の管理は難しくなります。
• 安全管理：技術対策に加え、人の面の対策や被害を抑える仕組みも検討します。
• 管理計画：認証・認可やネットワーク、秘密情報、ログ監視、運用者権限、委託先連絡を、一つの計画にまとめます。

個人情報保護委員会も、従業者への研修や注意喚起を含めた取り組みを案内しています。

Hanamiのシステム開発でよくある質問

Hanamiを採用するかは、業務の独自性や保守期間、Ruby経験、既存資産、非機能要件を合わせて判断します。

Hanamiで業務システムを作れますか？

作れます。画面付きの業務Webや、REST・JSON API、社内管理画面、バッチ、外部サービス連携を構築できます。Hanami公式も、フルスタックのWebアプリや軽量API、ストリーム処理など、用途に応じた構成を説明しています。

特に、受発注や顧客、予約、申請など独自ルールが増える業務では、責務を分けた保守しやすい設計が向いています。

HanamiはRailsより安く開発できますか？

一律には言えません。両者とも、ライセンス費ではなく、要件定義から運用までの工数で費用が決まります。

Hanamiのモジュール設計は、将来の変更を扱いやすくします。一方で、経験が少ない場合は、PoCや設計検証の工数が必要になります。

比べるときは、初期費用に加えて、5年程度の保守・改修・教育を含む総保有コストで見ます。

Hanami 3.0の開発で最初に確認することは何ですか？

Ruby 3.3以上と既存Gem、DBとの互換性を確認します。認証やCI/CD、デプロイ先、監視についても確かめます。

Hanami 3.0では、メールやi18n、Minitest、構造化ログなどが追加されました。2.3系から移行する場合は、変更点を洗い出し、自動テストを通します。

新規開発でも、主要業務を縦切りで作ります。そのうえで、負荷と障害時の挙動を確かめてから本開発へ進みます。

Hanamiの保守を開発会社に依頼するときの注意点は何ですか？

保守範囲は、項目ごとに分けて確認します。問い合わせや障害、脆弱性、Gem更新が対象です。監視やバックアップ、性能改善、追加開発も含めます。

緊急度別の一次回答時間や復旧目標、休日対応、再委託、ソースやインフラ設定の引き渡し条件を、契約に記載します。

担当者が変わっても運用が続くよう、設計書やテスト、変更履歴、手順書を継続的に更新してもらいます。

Hanamiのシステム開発のまとめ

Hanami開発では、フレームワークを選んでから機能を並べるのではなく、業務の境界と成果指標を先に整理します。要件整理から定着まで、検証を重ねていきます。

Action、Operation、Relation・Repo、View、Sliceの責務を明確にします。

採用判断のチェック項目

独自業務の範囲、SaaSとの分担、Hanami 3.0・Ruby 3.3以上の互換性、縦切りPoCの条件を確かめます。

移行責任や権限・監査ログ・バックアップ、負荷試験も確認します。なお、推定費用は、MVPが300万〜800万円程度、標準業務システムが800万〜2,000万円程度、連携型が2,000万〜5,000万円以上です。比べるときは、画面数ではなく工数と成果物で見ます。

最初の一歩は主要業務の縦切り検証

主要業務を一つ選び、縦切り検証で技術と実務の両面を確かめます。

• 検証する流れ：価値が高く例外処理もある業務を選び、ログインから登録、承認、検索まで動かします。
• 確認する点：現場で使えるか、データを移せるか、障害を追えるか、将来の保守担当が理解できるかを見ます。

Hanami、Rails、SaaSの組み合わせは、検証結果と5年程度の運用計画をもとに決めます。そうすると、初期費用だけに引きずられにくくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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