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

MyBatisのシステム開発は、要件整理と技術選定から始め、設計・開発とテストを経て、段階的に稼働させる流れで進みます。

この順で進めると、業務要件とデータに合う運用につながります。MyBatisの役割や費用の目安、見積もりの確認事項も、あわせて取り上げます。

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

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

MyBatisを中央に置き、SQL実行、引数の受け渡し、検索結果のオブジェクト変換を注釈で示した図。
SQLと検索結果をつなぐ役割が見渡せます。

MyBatisは、業務システムのデータアクセス部分を実装するフレームワークです。業務システム全体としては、画面やAPIから業務ルール、DB、認証、監視までを、一つのサービスとして設計します。

採用の判断に加えて、業務範囲、既存データとの接続、性能、セキュリティ、リリース後の保守も、初期段階から整理します。

MyBatisが担当する範囲

MyBatisが担うデータ処理と、システム全体で必要な役割は、分けて把握しておきます。

  • データアクセス:Service層などの業務ルールとRDBの間で、SQLの実行、引数の受け渡し、検索結果のオブジェクト変換を担います。
  • システム構成:各層が役割を分け合う形です。
  • 向いている業務:受発注、販売管理、在庫、顧客、会員・権限など、既存DBを使い、複雑な検索や帳票のSQLを明示的に管理する業務です。

典型的な構成では、画面または外部API、Controller、Service、MapperまたはDAOが連携します。さらに、MyBatisのSqlSessionFactoryやSqlSessionTemplate、RDB、認証・ログ・監視基盤も、役割を分けて考えます。

画面や承認ワークフロー、権限管理は、MyBatis単体には含まれません。バックアップや障害対応も、MyBatis単体の範囲外です。

見積書に「MyBatis対応」とあるときは、Java・Spring実装、DB設計、データ移行、性能試験、監視の担当者を、個別に確認します。

MyBatisが向いている業務システム

MyBatisは、SQLの内容を開発者が細かく制御したいシステムに向いています。次のような案件では、明示的なSQLが設計上の利点になります。

  • 既存DBの活用:Oracle、PostgreSQL、SQL Serverなどを使い続ける案件
  • レガシーDBの刷新:非正規化されたDBを段階的に刷新する案件
  • 複雑なデータ処理:複数テーブルの検索・集計や、DB固有機能、ストアドプロシージャを使う場合

単純なCRUD中心の小規模サービスでは、JPAやHibernateの方が実装量を抑えられる場合もあります。

選定では流行だけで判断せず、検索条件数、データ量、ピーク同時数を含む規模を見ます。そのうえで、既存SQL、DB移行、性能目標を照らします。

MyBatisとJPAを併用する場合は、管理するデータ、トランザクション境界、レビュー担当を、事前に決めておきます。

MyBatisのシステム開発の前半:要件整理と選定

業務フロー、非機能要件、Java・Spring・DBの版を整理してからSQLの記法を選ぶ流れ図。
実装前にそろえる前提と選定順が分かります。

前半では、「何を作るか」と「どの技術構成で作るか」を分けて整理します。要件が曖昧なままMapperや画面を開発すると、業務ルールとSQLの作り直しが生じます。

作り直しは工数と費用の増加につながります。そのため、要件整理を済ませてから技術を選びます。

フェーズ1:要件整理で業務・データ・非機能を定義

業務は画面だけでなく、イベントとデータの流れで確認します。受注管理であれば、受注登録、在庫引当、出荷の各状態について、担当者、権限、更新データを定めます。

請求、返品、取消の状態も、同じ項目で整理します。加えて、検索条件、並び順、ページングも整理します。CSV出力と帳票、外部API、夜間バッチも一覧にすると、Mapperの設計漏れを抑えられます。

開発側の技術者が、Java・Spring・DBの版、テーブル数・件数、1日あたりの更新量を確認します。そのうえで、ピーク同時数、応答時間、RTO・RPOを数値で決めます。

要件に「高可用性」とだけ書かれていると、冗長化やバックアップの見積もりを比べられません。

成果物には、業務フローや画面・API一覧、データ項目、権限を含めます。さらに、外部連携と非機能要件、移行方針、受け入れ条件も、文書にしておきます。

業務の流れやデータ項目に加えて、完了の条件や復旧の確認、納品と保守の範囲も、要件の段階で決めておきます。次の4点は、後から決めると作業範囲が広がりやすい項目です。

  1. 業務上の完了条件と利用者ロール
  2. データ保持期間と監査ログの対象
  3. バックアップ復元テスト
  4. 納品物と保守範囲

現場担当者と経営側の優先順位も、この段階でそろえておくと、作業範囲が後から広がるのを防ぐことにつながります。

フェーズ2:MyBatisと周辺技術の選定

要件整理のあとは、採用範囲やバージョン、SQLの定義方法を決めます。選定では、互換性と運用条件を、次の観点でそろえます。

  • 互換性:Java・Spring Boot・MyBatis・DBドライバの組み合わせを確かめる
  • Starterの版:利用するSpring BootとJavaに合う版を選ぶ
  • 既存Java 8環境:最新版へ移行できるかを先に検証する
  • SQLの記法:SQLの複雑さや条件管理に合う記法
  • 記法の管理:原則やレビュー方法を設計書に残す

Spring Bootを使う新規開発では、Starterの対応表を確認し、各製品の互換性マトリクスを作ります。

Starter 4.0はSpring Boot 4.0以降が対象で、Java 17以降が必要です(出典: MyBatis-Spring-Boot-Starter公式ドキュメント、2026年確認)。Starter 3.0はSpring Boot 3.2〜3.5が対象です。

Java 8環境から最新版へ移行できない場合は、対応する系統を固定します。

複雑なSQLやレビュー重視ならXML Mapper、単純な処理や小規模検索ならアノテーションが候補です。

条件を型安全に管理する領域では、Dynamic SQLが候補になります。記法が乱立しないよう、命名規約、SQLレビュー単位、生成コードの扱いも設計書に残します。

MyBatis Dynamic SQL 2.0.0は2026年3月11日に公開され、最低Javaは17へ上がりました。既存DSLに影響する変更も案内されています(出典: MyBatis Dynamic SQL公式変更履歴、2026年)。

そのため、刷新時は依存ライブラリを一括で更新せず、小さな検証環境で代表的なMapperとトランザクションを動かします。ページングとバッチも確かめてから、本番計画を作ります。

ポイント

要件整理を済ませてから技術を選ぶことで、Mapperや画面の作り直しを避けられます。判断に迷うときは、性能目標などの数値が決まっているかを先に見ます。

MyBatisのシステム開発の設計・開発とテスト

設計開発では、業務ルールやデータモデルを、APIやMapper、テストデータと対応づけます。また、実装速度だけでなく、品質も扱います。

納品品質には、SQLの可読性や再利用性、性能、障害時の調査しやすさを含めます。

フェーズ3:設計・開発でMapperと業務責任を分離

設計では、業務ルールとデータアクセスを分けて定義します。さらに、トランザクションとSQL検証も、別々の項目として定義します。

  • 責任分担:Service層に業務ルール、Mapperにデータアクセスを置く形
  • トランザクション:業務操作の範囲を定め、Service層で管理する
  • SQL設計:条件や順序、性能要件を記録し、代表SQLを検証する
  • 値の安全な扱い:値のバインドを基本とし、例外の利用には制限を設ける
  • 識別子の検証:画面入力をSQLへ直接渡さず、固定値へ変換する

Mapperに承認や在庫引当の判断を詰め込むと、SQLの変更が業務ロジックへ波及します。一方で、Serviceから個別のSQLを大量に呼ぶと、境界やエラー処理が曖昧になります。

そのため、登録・更新・取消を一つの業務操作として完了させる範囲を決めます。検索・結合条件と並び順、ページングを記録し、インデックスとロック方式も、あわせて残します。

0件や重複、同時更新の場合を試します。タイムゾーンと文字コード、最大件数、タイムアウトも試します。性能は、Explainと本番相当のデータで測ります。

値の埋め込みは#{}でバインドします。${}や文字列連結は用途を限定し、許可リストとテストを設けます。

ソート列名やテーブル名は、バインドできない場合があります。そのため、画面入力をそのままSQLへ渡さず、アプリケーション側の固定値へ変換します。

OWASPも、パラメータ化クエリや許可リスト入力検証、最小権限を主要な対策として示しています(出典: OWASP SQL Injection Prevention Cheat Sheet、2026年確認)。

フェーズ4:テストによるSQL・データ・性能の検証

テストでは、画面表示だけでなく、データ処理や移行、外部連携も確認します。性能と復旧の条件も、あわせて確かめます。

  • Mapper・結合テスト:入力条件と、ServiceからDBまでの処理を確認する
  • 動的SQL:<foreach>や<choose>を使う検索は条件が増えるため、代表ケースを決めて自動テストに組み込みます。
  • データ移行:移行前後で、件数・主キー・金額合計、ステータス・日付・文字化けを照合します。並行稼働時は、二重登録防止と差分確認の担当を決めます。
  • 外部連携:停止・遅延・重複送信、再送・部分成功を想定し、リトライとエラー通知の条件を受け入れテストに含めます。
  • 性能と受け入れ:性能指標、復旧、監査の条件を確かめる

Mapper単体テストでは、引数の組み合わせやNULL、境界値を試します。結合テストでは、トランザクション、ロールバック、例外処理を確認します。

性能試験では、平均だけでなくP95とP99を見ます。加えて、DB接続プールやCPU、メモリを見ます。ロック待ちやスロークエリも、確認します。

受け入れ条件には、想定同時数やピーク時間、許容時間を含めます。そのほか、復旧手順や監査ログ、バックアップ復元も含めます。

アプリを増やしても、DBのインデックスや接続数がボトルネックなら、性能は改善しません。

ポイント

SQLの前提と業務操作の範囲が設計段階で決まっているかが、テストの進めやすさを左右します。迷ったら、この2点を文書で確かめます。

MyBatisのシステム開発の稼働と定着

テスト後は、稼働判定から現場定着までを一続きで計画します。切り替えるだけでは、利用者が使いこなせず、旧運用への回帰や開発会社への問い合わせ集中が起こりえます。

フェーズ5:稼働判定と段階リリース

稼働判定では、機能テストに加えて、移行データ照合と性能試験を確認します。脆弱性診断や権限試験も、確認の対象です。

バックアップ復元と監視通知、問い合わせ窓口も、確認が必要です。リスクが高い場合は、次の方法を選びます。

  • 段階リリース:部門や業務ごとに分けた切り替え
  • パイロット:限定ユーザーによる先行稼働
  • 並行稼働:旧システムと新システムを同時に動かす形

切り戻しの条件と最終判断者も、あらかじめ決めておきます。当日の手順書には、担当者と開始・終了時刻を記載します。さらに、この手順書には、DBバックアップとアプリ停止、データ移行と接続先変更の作業も記載します。

作業手順は一度読み合わせを行い、動作確認と利用者通知、切り戻しも含めます。そのうえで、担当者が不在でも実施できる粒度にします。

障害時には、画面だけでなく、アプリログやSQLログを追えるようにします。加えて、DBメトリクスと外部連携ログも、調べられる状態にします。

フェーズ6:運用保守と現場定着の仕組み化

現場の役割、保守契約、定期確認を決めておくと、利用者向けの説明と業務変更の判断を支えられます。

  • 運用体制:担当者と判断範囲
  • 利用者支援:操作マニュアルは、実業務に沿った短い手順とFAQにします
  • 保守契約:受付・復旧目標と保守対象
  • 運用対象:SQL性能監視、バックアップ復元テスト、法改正対応。初期費用の見積もりでは、更新や性能改善の追加料金は見えにくくなります。
  • 月次確認:問い合わせ件数・処理時間・エラー件数、遅いSQL・権限変更・バックアップ結果を見る

マスタ登録者と承認者、問い合わせ窓口を定めます。また、SQLや権限を変える管理者も決め、判断範囲を運用設計書に記録します。

障害受付時間や一次回答・復旧目標、軽微な改修の範囲を確認します。

Java・Spring・MyBatis・DBドライバの脆弱性対応に加えて、OSやコンテナの更新も確認します。

四半期ごとに、インデックスや不要データを見直します。依存ライブラリや、利用率の低い画面、現場の要望も対象です。

運用データを改善へつなげることで、システムを業務成果に結び付けられます。

MyBatisのシステム開発の費用相場とコストの内訳

費用配分の目安として、要件定義、設計・環境構築、実装、テストの割合を横棒で比較した図。
実装の割合が最も大きい内訳です。

MyBatisはOSSで、ライセンスを購入して終わる業務システム製品ではありません。費用の中心は、要件定義、Java・Spring開発、SQL・DB設計です。

テストや移行、インフラにも費用がかかります。監視、教育、保守の費用も、見込んでおく必要があります。

2026年基準の業務システム開発の相場を、MyBatisをデータアクセス層に使う案件へ当てはめた推定です。MyBatis固有の公開定価ではなく、個別見積もりの代わりにもなりません。

規模別の費用と期間の目安

費用と期間は、案件の規模や対象範囲で変わります。そのため、相場の推定幅と前提条件を、あわせて見ます。

  • 小規模改修:既存システムへのMapper追加などは100万〜500万円程度、認証・インフラ再利用を前提に1〜3か月程度です。
  • 部門向け小規模:300万〜1,000万円程度、2〜6か月程度です。ログイン・権限・マスタ、一覧・検索・登録、帳票・基本監視を含み、画面数や連携数で変わります。
  • 中規模:複数部門を扱う場合は1,000万〜5,000万円程度です。
  • 全社基幹など:高可用性や段階移行を含む場合は5,000万円以上です。
  • 人月単価:単価だけでなく、工程ごとの担当工数で比べます。

中規模の受発注・在庫・顧客案件には、外部連携やバッチ、既存DB連携が含まれます。移行や性能試験も含まれ、期間は6〜12か月程度です。

全社基幹の案件で、高可用性・複数拠点、監査・災害対策、段階移行を含めると、5,000万〜2億円以上、12〜24か月以上になることがあります。出典は、NotebookLMリサーチノート『MyBatisのシステム』に収録された2026年基準の業務システム開発Q&Aです。

人月単価は、中小開発会社で80万〜120万円、大手SIerで150万〜200万円程度です。担当工数は、要件定義・設計・実装・テストと、PM・DB調整・移行の分を、それぞれ確認します。

デジタル庁も、大きな一式工数のままでは費用の妥当性を判断しにくいと説明しています(出典: デジタル庁「標準ガイドライン実践ガイドブック」、2025年)。

初期費用以外に見落としやすいコスト

初期開発費に加えて、環境、追加作業、保守の範囲を分けて見積もると、比べやすくなります。

  • 費用配分:要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度がたたき台です。案件によって変わる推定値です。
  • 追加作業:データ移行、セキュリティ・性能試験、教育、リリース支援、文書を、実装費と分けて示してもらう
  • クラウド:アプリ開発費と利用料を分け、利用料はRDBやコンテナ、ログ・監視・バックアップ、通信・検証環境ごとに示す
  • オンプレミス:機器・ライセンス・保守・回線費
  • 保守・運用:金額と対応範囲をあわせた見積もり

オンプレミスでは、サーバーやOS、DBライセンスの費用が対象になります。バックアップ装置や保守契約、閉域網も、費用に含めます。

MyBatisの採用でライセンス費を抑えられても、DB設計や性能検証は必要です。

保守・運用費は、初期開発費の年15〜25%、または小規模案件で月15万〜80万円程度を仮置きする考え方があります。

費用は、脆弱性対応だけを含むか、問い合わせや軽微改修まで含むかで変わります。SQL調整や監視、夜間障害対応まで含むかでも、差が出ます。

見積書では、月額だけでなく、対応時間と対象範囲を確認してください。

ポイント

費用は初期開発費だけで比べると、保守や移行、性能試験の費用が抜けます。見積もりは、工程ごとの金額と含まれる範囲をそろえて比べるのが目安です。

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

見積もりは、総額の安さだけで比べず、同じ前提の工数と成果物を並べて見ます。RFPや要件一覧がないと、各社の想定範囲が異なり、価格差の理由も分かりません。

見積書の前提となる要件と成果物

見積条件には、前提資料、未確定事項、納品後に引き継ぐ成果物を明記します。前提資料には、権限ロールやピーク同時数、性能目標、移行対象、希望時期も含めます。

  • 発注資料:現行構成、業務フロー、画面・API一覧、連携先、主要テーブル、データ件数を含めます
  • 未確定事項:決められない内容は未確定と記し、調査・PoC・要件定義の工数を別見積もりにします
  • 成果物:要件定義書、基本・詳細設計書、ER図、API仕様、Mapper一覧を確認します
  • 引き継ぎ資料:ソースコード、ビルド手順、監視設定、教育資料も対象です

未確定のまま無料の実装として扱うと、追加費用や遅延につながります。

成果物には、SQLレビュー記録やテスト仕様書、移行・リリース手順書、運用設計書も含めます。

SQLの意図や性能前提が残らないと、担当が替わったあとの保守に時間がかかります。

複数社の同じ質問による比較

候補会社には同じRFPを渡し、MyBatisの経験年数だけでなく、本番運用の経験も確認します。見積範囲と契約方式も、同じ条件で比べます。

工程は、要件定義から設計、実装、テストまでと、移行、リリース、教育、保守に分けて、金額と人月を並べます。

  • 技術・運用の質問:担当者の経験と本番対応力を確かめる
  • 見積比較:準委任では作業時間と体制、請負では納品条件と変更管理を確認する
  • 契約方式:契約ごとのリスク差を考慮して比べる

具体的には、Java 8から17への移行実績や、Spring BootとMyBatisの対応版、XML MapperとDynamic SQLの選定方針を尋ねます。

DB調整の担当者と性能試験のデータ量も尋ねます。移行リハーサルの回数や、障害時の体制も確認します。

請負では、準委任の単純な人月計算に対して、リスク分として1.3〜1.5倍程度が上乗せされる場合があります。この倍率はリサーチノートによる目安です。契約方式の違いを踏まえ、単価だけでなく総額と条件で比べてください。

リスクと追加費用の条件

画面数だけで価格を決め、SQLの複雑さなどを一式にまとめた見積もりには、注意が必要です。

一式計上や変更条件の曖昧さは追加費用に関わるため、見積もりと契約で次の点を確認します。

  • 見積範囲:一式計上の対象と、価格に含まれる作業
  • 価格の理由:高額な場合、PM、DB専門家、セキュリティ試験、冗長化、移行リハーサルのどれが理由かを確かめる
  • 変更管理:追加変更の条件と、影響確認の手順
  • セキュリティ:診断や運用対策を、契約と見積もりに含める

確認対象は、SQLの複雑さや移行、外部連携です。加えて、性能試験や権限、監査ログ、運用も見ます。

金額が低い見積もりでは、要件定義やテスト、文書、リリース後の支援が含まれない場合があります。

追加要求の単価と承認者は、あらかじめ決めておきます。影響調査や納期変更、仕様凍結時期も、あわせて決めます。

たとえば、画面条件を追加すると、SQLやインデックス、APIレスポンス、テストデータにまで波及する場合があります。

受け付け前に、性能・セキュリティ・移行への影響を見積もります。契約には、SQLインジェクションや過剰権限、個人情報の参照範囲、監査ログ、エラーメッセージを含めます。

脆弱性診断の実施者と時期も決めます。また、IPAは、プレースホルダや最小権限、DBエラーを利用者へ直接表示しないことを示しています(出典: IPA「安全なウェブサイトの作り方 1.1 SQLインジェクション」、2026年確認)。

MyBatisの設定に加えて、運用権限と監視も見積もります。

ポイント

総額だけで判断すると、範囲の違いに気づかないまま契約しがちです。工数と成果物を同じ前提で並べ、価格差の理由を説明してもらえるかを見ます。

MyBatisのシステム開発でよくある質問(FAQ)

発注者から寄せられやすい質問に答えます。技術の可否や費用、期間を中心に、発注時の確認事項も扱います。

MyBatisとJPAはどちらを選べばよいですか?

単純なCRUDやエンティティ中心の処理ではJPA、複雑な検索や既存DB、細かなSQL性能制御ではMyBatisが合う場合があります。

選定では知名度より、データモデルやSQLの複雑さ、DB方言を基にします。チーム経験や性能目標も、判断材料に加えます。併用時は、同じテーブルを両方が更新する範囲と、トランザクション管理を明確にします。

MyBatisのシステム開発にはいくらかかりますか?

既存システムのMapper追加や小規模改修は100万〜500万円程度、部門向け小規模システムは300万〜1,000万円程度が推定レンジです。

外部連携、移行、性能試験を含む中規模は1,000万〜5,000万円程度、全社基幹や高可用性を含む大規模は5,000万〜2億円以上となることがあります。

ただし、MyBatis固有の価格ではなく、業務システム開発の相場を前提に当てはめた目安です。

MyBatisに対応できる開発会社は何を基準に選べばよいですか?

候補会社は、次の観点で確認します。

  • 技術と実績:Java・MyBatisの対応表と、同規模の本番運用実績
  • 開発・運用経験:SQLレビュー、DBチューニング、移行、性能試験、セキュリティ、保守の経験
  • 担当者への質問:自社要件をMapperとServiceへ分ける方法、遅いSQLの調査、障害時の判断者を具体的に聞く
  • 実績の裏取り:公開実績を参考にし、契約前にRFPと提案内容で確かめる

古いJava 8のシステムをJava 17へ移行できますか?

移行できる可能性はありますが、Javaだけの更新で完了するとは限りません。

Spring BootやStarter、MyBatis Dynamic SQLの対応関係を確認します。DBドライバやアプリサーバー、ビルドツールも、確認の対象です。

代表的なMapperと外部連携を検証します。ただし、Java 17が最低要件のライブラリへ上げられない場合は、既存系統を保守しながら段階移行する案もあります。

まとめ

MyBatisの開発は、業務要件とJava・Spring、SQL、DBをつなぎ、移行、テスト、運用まで続くプロジェクトです。ただし、フレームワークの導入は、その一部にすぎません。

要件整理の段階で、データ量や性能、権限、監査を決めます。RTO・RPOと移行範囲も決めておくと、Mapperの再作成や追加費用を抑えられます。

開発は6段階で、要件整理と技術選定から始まり、保守と現場定着で終わります。途中では、Service・Mapper・DBの設計開発を行い、機能・データ・性能・セキュリティのテストを重ねたうえで、段階稼働に進みます。

費用は小規模改修で100万〜500万円程度、中規模で1,000万〜5,000万円程度など幅があります。工程、工数、成果物、保守範囲を同じ条件で比べます。

会社選びでは、既存DBの理解やSQL性能改善、移行を設計できるかを確認します。さらに、セキュリティや障害対応、利用者の定着まで設計できるかも見ます。

業務と技術課題を整理したRFPを用意し、複数社から提案と見積もりを受けることが、納得できる開発への近道です。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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