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

Hanamiのシステム開発は、業務要件を整理して小さな縦切りの検証を行い、Action・Operation・Sliceなどの責務を分けながら段階的に進める方法が基本です。

「Hanamiで業務システムを作れるのか」「Railsやパッケージと比べて費用はどう決まるのか」「開発会社には何を確認すればよいのか」と迷っている方に向けて、要件整理から稼働後の定着までを実務の判断基準に落とし込んで解説します。2026年に公開されたHanami 3.0の変更点、データ移行・非機能要件・保守契約で見落としやすい項目も含め、発注前に使えるチェックリストとしてまとめます。

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

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

Hanamiは、RubyでWebアプリケーションや業務システムを構築するフレームワークです。フレームワーク自体が業務を完成させるのではなく、受発注・顧客管理・予約・申請・問い合わせ・外部連携などの業務ルールを、保守しやすい単位に分けて実装するための土台です。したがって、開発の成否はHanamiの採用だけでなく、業務の境界、データの責任、運用体制を最初に決められるかで大きく変わります。

Hanamiの特徴は、関心の分離、明示的なビジネスロジック、モジュール化を重視する点です。Hanakai公式では、HTTPの入口をAction、成功と失敗を含む業務手続きをOperation、データアクセスをRelation・Repo、表示をViewとして説明しています。また、顧客管理・受注・請求のようなサブドメインやサブシステムをSliceとして境界づけられます。たとえば受注登録画面のActionが入力を受け、Operationが在庫引当と承認可否を判断し、RelationやRepoがデータを読み書きし、Viewが画面用に整形するという分担です。

この構造は、担当者が増えたり、業務ルールが複雑になったりしたときに、変更箇所を追いやすくする効果が期待できます。一方で、責務を分ける設計とレビューが必要になるため、短期の画面試作だけなら過剰になる場合もあります。採用前に「長期運用する独自業務があるか」「複数の業務領域を境界づけたいか」「Rubyの保守担当を確保できるか」を確認することが大切です。

2026年6月のHanami 3.0公式発表では、メーラー、国際化、Minitest、改善されたログ、リクエストボディ解析、アセット監視などが追加されています。Ruby 3.3以上が必要になるため、既存のRuby、Gem、OS、CI環境が対応するかを最初に調べる必要があります。メール通知や多言語画面を含む業務システムでは便利な変更ですが、既存アプリを移行する場合はGemの互換性とテストの再実行を見積もりに含めます。

公式のテストアプリでは、同じHTTPリクエストのスループットが2.3比で約3.7倍、p99レイテンシが20msから4msになったと報告されています（出典: Hanami 3.0公式発表、Hanakai、2026年）。ただし、これはテストアプリの比較値であり、自社システムの性能を保証する数値ではありません。実際の応答時間はデータベース、外部API、クエリ、ネットワーク、インフラ構成で変わるため、採用判断では自社の代表シナリオで負荷試験を行います。

Hanamiのシステム開発の進め方は？6フェーズで解説

Hanamiのシステム開発は、要件整理、開発会社や技術の選定、設計・開発、テスト、稼働、定着の6フェーズに分けると管理しやすくなります。重要なのは、後工程で見つかる問題を前工程の成果物に戻して確認できる状態にすることです。画面一覧だけで発注せず、業務シナリオ、データ移行、非機能要件、運用手順まで段階的に合意します。

最初に「誰が、いつ、何を判断し、どのデータを次の工程へ渡すか」を業務シナリオで書きます。受注システムなら、注文受付、在庫確認、承認、出荷依頼、請求という流れを、担当者・入力・分岐・完了条件まで表にします。画面数や機能名だけでは、例外処理や部門ごとの権限が抜けやすいためです。

実務上のチェック項目は、対象業務の範囲、利用者と権限、処理件数、締め時間、既存システムとの境界、データ保持期間、成功指標です。たとえば「月末処理を2時間以内に終える」「申請の差し戻し理由を100%記録する」のように測定可能な目標にします。この段階でHanamiを採用する範囲も、新規システム全体、APIのみ、特定のSliceだけ、既存Railsから段階移行する案に分けて比較します。

発注先の比較では、Hanami対応という看板だけで判断しません。Hanami 3.0とRuby 3.3以上の実務経験、Action・Operation・Slice・Relation・Repoの設計方針、データ移行の経験、クラウドと監視の体制、リリース後の保守担当を確認します。Hanamiの公開導入事例が見つからない場合は、RubyやRailsの業務Web実績を隣接実績として評価し、Hanami案件で何を追加検証するのかを提案書に書いてもらいます。

選定時には、主要業務の縦切りPoCを提案してもらうと安全です。ログインから登録・承認・検索までを一つの業務シナリオとして動かし、Rubyのバージョン、DB、認証、CI/CD、自動テスト、ログ、監視が成立するかを確認します。質問としては「担当者は本番保守まで同じチームか」「設計書とテスト仕様書のサンプルを見せられるか」「障害時の連絡時間と復旧目標は何か」を用意します。

設計では、業務をSliceの境界に分け、HTTPの入口をAction、業務手続きをOperation、DBアクセスをRelation・Repo、表示をViewに割り当てます。たとえば受注と請求を別Sliceにし、請求額の計算や与信確認をOperationに置くと、画面からもバッチからも同じ業務ルールを呼び出しやすくなります。Actionやテンプレートに業務判断を直書きしないことが、後のテストと保守のチェックポイントです。

開発は、最初から全機能を並行して作るより、主要な一業務を縦に通す方法が向いています。入力、バリデーション、権限、DB登録、通知、エラー表示、監査ログまで動かし、発注者が画面と業務結果を確認します。設計成果物には、画面・API一覧、データモデル、権限マトリクス、外部連携仕様、エラー方針、バックアップ方針、未決事項の一覧を含め、変更履歴を残します。

テストは単体テストだけで完了にしません。Operationの成功・失敗、権限ごとの表示、重複登録、通信失敗、外部APIのタイムアウト、締め処理、データ移行後の件数を確認する必要があります。テスト計画では、単体、結合、総合、受入、回帰、負荷、脆弱性確認の担当者と合格条件を先に決めます。

非機能要件は、同時利用者数、平常時とピーク時の応答時間、稼働率、RPO・RTO、バックアップ保持期間、ログ保管期間、障害連絡時間を数値化します。個人情報を扱う場合は、権限分離、二要素認証、通信と保存データの暗号化、監査ログ、脆弱性対応の期限を確認します。個人情報保護委員会は、安全管理措置を事業規模やデータの性質・量に応じて必要かつ適切に講じる考え方を示しています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年改正）です。

本番稼働のリスクは、アプリの完成度だけでなくデータ移行と現場の切り替えにあります。顧客、商品、組織、権限、過去取引などのマスタを対象に、移行サンプル、名寄せ、欠損・重複の扱い、移行後の件数照合を早い時期に試します。発注者側でデータを整備する作業がある場合は、担当部署、期限、品質基準を契約書やプロジェクト計画に書きます。

切り替え方式は、一斉移行、部門ごとの段階移行、旧システムとの並行稼働から選びます。選択の基準は、停止できる時間、データ連携の複雑さ、現場教育の範囲、問題発生時に戻せるかです。リリース判定会では、重大障害がないこと、受入テストが完了していること、バックアップから復元できること、問い合わせ窓口と緊急連絡網が機能することを確認します。

稼働後は、操作説明を一度行って終わりにせず、利用状況と問い合わせを見ながら定着を進めます。業務ごとの操作手順、管理者向けの障害対応、アカウント発行・削除、バックアップ確認、月次のログレビューを運用手順書にします。利用率、入力漏れ、処理時間、差し戻し率などの指標を毎月確認すると、開発した機能が業務成果につながっているか判断しやすくなります。

保守契約では、問い合わせ対応と追加開発を分け、Ruby・Gem・Hanamiの更新、脆弱性対応、障害復旧、性能改善、法改正対応の責任範囲を明記します。ソースコードだけでなく、Gemfile.lock、CI/CD定義、インフラコード、テスト仕様、設計書、運用手順、監視設定を納品物に含めることも重要です。これらが揃えば、将来の担当者交代や開発会社変更の際にも、判断材料を失いにくくなります。

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

HanamiはOSSフレームワークのため、採用しただけで開発費が決まるわけではありません。費用は、要件定義、画面とAPIの数、権限、ワークフロー、外部連携、データ移行、テスト、インフラ、保守体制の工数で決まります。Hanami固有の公開料金表はないため、以下は2025年時点の国内Webシステムの人月単価情報と業務システムの規模感を組み合わせた、2026年時点の発注計画用の推定レンジです。

小規模なPoC・MVPで、ログイン、数画面の登録・検索、簡易管理画面、少数のAPIに絞る場合は、300万〜800万円程度、期間は3〜5か月が一つの推定レンジです。ユーザー・権限、申請・承認、帳票、メール、外部APIを含む標準的な業務Webシステムは、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%程度と仮置きすると、会社ごとの違いを確認しやすくなります。これは固定の正解ではなく、比較表を作るための配分例です。UIデザイン、PM、QA、インフラ、セキュリティ、マニュアル作成がどの工程に含まれるかを確認し、別途費用を見落とさないようにします。

ランニング費用は、クラウド利用料、監視、バックアップ、脆弱性対応、Ruby・Gem・Hanamiの更新、問い合わせ対応、追加改修に分けます。保守費は初期開発費の年15〜25%程度が一般的な目安として紹介されており、初期費用1,000万円なら年150万〜250万円程度を最初の検討レンジにできます（出典: 株式会社ripla、2026年参照）。24時間監視、SLA、セキュリティ診断、休日対応を含める場合は上振れするため、時間帯と対応期限を契約に書きます。

標準化できる経費申請や勤怠などはSaaSやパッケージを使い、独自のワークフローやAPI連携だけをHanamiで作ると、スクラッチ範囲を抑えられる場合があります。競争力のある業務ロジックや既存データを活かす必要があるなら、Hanamiのスクラッチ開発が候補になります。既存Railsからの移行では、一括書き換えよりも業務境界やAPI単位で段階移行する方が、比較と撤退判断をしやすくなります。

クラウド構成は、Puma、コンテナ、RDB、オブジェクトストレージ、CDN、監視などを組み合わせます。安価に見える構成でも、冗長化、バックアップ、ログ保管、データ転送、検証環境を含めると費用は変わります。月額のクラウド費用と開発会社の運用費を分け、平常時・繁忙期・障害時の想定を分けて試算することがポイントです。

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

良い見積もりは、合計金額だけでなく、何を作り、何を作らず、誰が、いつまでに、どの品質で納品するかが分かります。Hanami案件では、フレームワークの経験だけでなく、業務システムの設計・移行・保守を一つの計画にできるかを見ます。次の3つの観点を、RFPや見積依頼書にあらかじめ入れておくと比較が安定します。

見積依頼の資料には、業務フロー、利用者と権限、画面・API一覧、外部連携先、データ移行対象、非機能要件、希望時期、受入条件を含めます。特に「検索できる」ではなく、検索項目、件数、権限による表示差、CSV出力、応答時間まで書きます。未確定の項目は無理に決めず、調査・PoC・要件定義の対象として別枠にします。

成果物は、要件定義書、画面・API仕様、データモデル、Sliceの境界方針、ソースコード、テストコード、テスト結果、移行手順、運用手順、監視・バックアップ設定、教育資料に分けます。納品物の一覧がない見積もりは、同じ金額でも作業範囲が比較できません。発注者のレビュー回数、承認期限、データ提供の責任も、双方の前提条件として記載します。

最低でも、同じRFPを使って複数社に依頼し、要件定義、開発、移行、テスト、保守を同じ項目で並べます。比較表には、会社ごとの人月、担当者の経験、体制、開発方式、技術検証の範囲、除外事項、追加変更の単価、保守の時間帯を入れます。安い見積もりでも、テストや移行を発注者側に移しているだけなら、後で費用と負担が増える可能性があります。

Hanamiの直接実績とRuby・Railsの隣接実績は区別して確認します。問い合わせでは「Hanami 3.0とRuby 3.3以上に対応できるか」「Action・Operation・Sliceの設計例を説明できるか」「既存RailsやSaaSとの併用を提案できるか」「本番後のGem更新と脆弱性対応を誰が担うか」を聞きます。Ruby Associationが公開するRuby活用事例には、STORES、IVRy、タイミー、Shippioなどが掲載されていますが、Rubyの本番活用例とHanamiの導入事例は同じ意味ではありません（出典: Rubyアソシエーション「Ruby活用事例」、参照2026年）です。

費用が膨らみやすいのは、開発途中の仕様変更、データの品質不足、外部APIの仕様差、権限設計のやり直し、受入担当者の不足です。変更管理では、追加・削除・延期の依頼を記録し、影響する画面、データ、テスト、納期、金額を承認してから着手します。定額契約でも、要件の範囲と変更の扱いが曖昧なら、予算管理は難しくなります。

セキュリティでは、フレームワークが用意する機能だけに依存しません。個人情報保護委員会は、技術的対策に加えて、従業者への研修や注意喚起、被害を最小化する仕組みも考慮するよう案内しています。Hanami側の認証・認可、クラウドのネットワーク、秘密情報管理、ログ監視、運用者の権限、委託先との連絡手順を一つの安全管理計画にまとめます。

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

最後に、発注前に検索されやすい疑問へ直接回答します。Hanamiの採用可否は、フレームワークの好みではなく、業務の独自性、保守期間、チームのRuby経験、既存資産、必要な非機能要件を合わせて判断します。

作れます。画面付きの業務Webシステム、REST・JSON API、社内管理画面、バッチ、外部サービス連携などを構築できます。Hanami公式も、フルスタックWebアプリ、軽量API、ストリーム処理など用途に応じて構成を選べると説明しています。受発注、顧客、予約、申請のように独自ルールが増える業務では、責務を分けて保守しやすくする設計が向いています。

一律には言えません。HanamiもRailsもフレームワーク自体のライセンス費用ではなく、要件定義、設計、実装、テスト、移行、運用に必要な工数で費用が決まります。Hanamiのモジュール設計で将来の変更を扱いやすくできる一方、社内や発注先に経験が少なければ、PoCや設計検証の工数が必要になります。初期費用だけでなく、5年程度の保守・改修・教育を含めた総保有コストで比較します。

Ruby 3.3以上、既存Gem、DB、認証、CI/CD、デプロイ先、監視の互換性を最初に確認します。Hanami 3.0ではメール、i18n、Minitest、構造化ログなどが追加されていますが、既存の2.3系から移行する場合は、変更点を洗い出して自動テストを通します。新規開発でも、ログインから主要業務の登録・承認・検索までを縦切りで作り、負荷と障害時の挙動を確認してから本開発へ進みます。

保守の対象を、問い合わせ、障害対応、脆弱性対応、依存Gemの更新、インフラ監視、バックアップ確認、性能改善、追加開発に分けて確認します。特に、緊急度ごとの一次回答時間、復旧目標、休日対応、再委託の有無、ソースコードやインフラ設定の引き渡し条件を契約書に記載します。担当者が変わっても運用できるよう、設計書、テスト、変更履歴、手順書を継続的に更新してもらうことが大切です。

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

Hanamiのシステム開発は、フレームワークを選んでから機能を並べるのではなく、業務の境界と成果指標を整理し、要件整理→選定→設計開発→テスト→稼働→定着の順に検証を積み重ねる進め方が適しています。Action、Operation、Relation・Repo、View、Sliceの責務を明確にすると、業務ルールと画面・データの結び付きを追いやすくなります。

発注前は、独自業務ロジックの範囲、SaaSやパッケージとの分担、Hanami 3.0とRuby 3.3以上の互換性、縦切りPoCの合格条件、データ移行の責任、権限・監査ログ・バックアップ、負荷試験のシナリオを確認します。見積もりは300万〜800万円程度のMVP、800万〜2,000万円程度の標準業務システム、2,000万〜5,000万円以上の連携型という推定レンジを出発点にし、画面数ではなく工数と成果物で比較します。

まずは、最も価値が高く、例外処理も含む主要業務を一つ選び、ログインから登録・承認・検索までの小さな検証を依頼します。そこで技術だけでなく、現場が使えるか、データが移せるか、障害を追えるか、将来の保守担当が理解できるかを確かめます。Hanamiを採用するか、RailsやSaaSと組み合わせるかは、検証結果と5年程度の運用計画をもとに決めると、初期費用だけに引きずられにくくなります。

▼全体ガイドの記事
・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を創業。