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

MyBatisのシステム開発は、MyBatisをデータアクセス層に採用し、業務要件・SQL・データベース・運用を一体で設計して段階的に稼働させる進め方が基本です。

「MyBatisのシステム」と検索している方の中には、MyBatisを導入すれば受発注や在庫管理の機能が完成すると考えている方もいます。しかし、MyBatisはJavaアプリケーションとリレーショナルデータベースをつなぐ永続化フレームワークであり、業務システムそのものではありません。この記事では、要件整理、技術選定、設計開発、テスト、稼働、定着の6段階に分けて、発注者が確認すべき判断基準、費用相場、見積もりの見方まで解説します。

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

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

MyBatisを使う業務システムの全体構成

MyBatisのシステム開発では、画面やAPI、業務ルール、データベース、認証、監視を一つのサービスとして設計し、そのうちデータアクセス部分をMyBatisで実装します。MyBatisの採用判断だけでなく、業務の対象範囲、既存データとの接続、性能、セキュリティ、リリース後の保守まで初期段階から整理することが重要です。

MyBatisは業務システムのどこを担当しますか?

MyBatisは、Service層などに定義された業務ルールとRDBの間で、SQLの実行、引数の受け渡し、検索結果のオブジェクト変換を担当します。典型的な構成は、画面または外部API、Controller、Service、MapperまたはDAO、MyBatisのSqlSessionFactory・SqlSessionTemplate、RDB、認証・ログ・監視基盤という分担です。受発注、販売管理、在庫、顧客、会員・権限など、既存DBを活用しながら複雑な検索や帳票を作る業務では、SQLを明示的に管理できることが強みになります。

一方で、MyBatis単体に画面、承認ワークフロー、権限管理、バックアップ、障害対応が含まれるわけではありません。見積書に「MyBatis対応」と書かれていても、JavaやSpringの実装、DB設計、データ移行、性能試験、監視を誰が担当するのかを別々に確認する必要があります。

MyBatisが向いている業務システムはどのようなものですか?

MyBatisは、SQLの内容を開発者が細かく制御したいシステムに向いています。既存のOracle、PostgreSQL、SQL Serverなどを使い続ける案件、非正規化されたレガシーDBを段階的に刷新する案件、複数テーブルを結合する検索や集計、DB固有の機能、ストアドプロシージャを利用する案件では、明示的なSQLが設計上の利点になります。単純なCRUD中心の小規模サービスでは、JPAやHibernateを選ぶ方が実装量を抑えられる場合もあります。

選定では、フレームワークの流行だけで判断しないことが大切です。検索画面の条件数、データ量、ピーク時の同時利用者数、既存SQLの再利用可否、DB移行の有無、性能目標を並べ、MyBatisの明示性が事業上のメリットになるかを評価します。MyBatisとJPAを同じシステム内で併用する場合は、どのデータをどちらが管理するか、トランザクション境界とレビュー担当を事前に決めておく必要があります。

MyBatisのシステムはどのように進めますか?前半の要件整理と選定

業務要件と技術選定を整理する場面

MyBatisのシステム開発を前半で成功させるには、最初に「何を作るか」と「どの技術構成で作るか」を分けて整理します。要件が曖昧なままMapperや画面の開発を始めると、後から業務ルールとSQLの作り直しが発生し、工数と費用が膨らみます。

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

要件整理では、対象業務を画面単位だけでなく、業務イベントとデータの流れで確認します。たとえば受注管理なら、受注登録、在庫引当、出荷、請求、返品、取消の各状態を洗い出し、誰が、いつ、どの権限で、どのデータを更新できるかを定義します。検索条件、並び順、ページング、CSV出力、帳票、外部API、夜間バッチも一覧にしておくと、Mapperの設計漏れを抑えられます。

技術者と早い段階で確認したい項目は、現行JavaとSpringのバージョン、DB製品とバージョン、テーブル数、主要テーブルの件数、1日あたりの更新量、ピーク同時数、許容レスポンスタイム、障害時の復旧時間と復旧時点です。RTOとRPOを数値で決めないまま「高可用性」とだけ記載すると、冗長化やバックアップの見積もりが比較できません。

要件整理の成果物は、業務フロー、画面・API一覧、データ項目定義、権限一覧、外部連携一覧、非機能要件、移行方針、受け入れ条件です。チェックリストとしては、(1)業務上の完了条件、(2)利用者ロール、(3)データ保持期間、(4)監査ログの対象、(5)バックアップ復元テスト、(6)納品物と保守範囲を確認します。この段階で現場担当者と経営側の優先順位をそろえることが、後のスコープクリープ防止につながります。

フェーズ2:MyBatisと周辺技術の選定を行います

要件を整理したら、MyBatisを採用する範囲とバージョンを決めます。新規開発でSpring Bootを使う場合は、MyBatis-Spring-Boot-Starterの対応表を確認し、Java、Spring Boot、MyBatis、DBドライバを一組の互換性マトリクスにします。MyBatis公式ドキュメントでは、Starter 4.0はSpring Boot 4.0以降とJava 17以降、Starter 3.0はSpring Boot 3.2〜3.5とJava 17以降が対象です(出典: MyBatis-Spring-Boot-Starter公式ドキュメント、2026年確認)。既存のJava 8環境では、最新版へ移行できるかを先に検証し、できない場合は対応系統を固定します。

SQLの定義方法は、XML Mapper、アノテーション、Dynamic SQLの使い分けを決めます。複雑なSQLやレビューを重視するならXML Mapper、単純な処理や小規模な検索ならアノテーション、条件の組み立てを型安全に管理したい領域ではDynamic SQLが候補です。ただし、チーム内で記法が乱立すると保守性が落ちるため、原則となる記法、命名規約、SQLのレビュー単位、生成コードの扱いを設計書に残します。

2026年3月11日にはMyBatis Dynamic SQL 2.0.0が公開され、最低Javaバージョンが17へ引き上げられ、既存DSLに影響する変更も案内されています(出典: MyBatis Dynamic SQL公式変更履歴、2026年)。既存システムの刷新では、依存ライブラリを一括更新せず、互換性確認用の小さな検証環境で代表的なMapper、トランザクション、ページング、バッチを動かしてから本番計画を作ることが安全です。

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

Mapperとデータベースを設計する場面

設計開発では、画面を作りながらSQLを足すのではなく、業務ルール、データモデル、API、Mapper、テストデータを対応づけます。実装の速さだけでなく、SQLの可読性、再利用性、性能、障害時の調査しやすさを納品品質として扱うことが重要です。

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

設計では、Service層に業務ルール、Mapperにデータアクセスの責任を持たせます。Mapperへ承認可否や在庫引当の判断を詰め込みすぎると、SQLの変更が業務ロジックに波及しやすくなります。反対に、Serviceから大量の個別SQLを直接呼び出すだけでも、トランザクション境界やエラー処理が不明確になります。登録・更新・取消が一つの業務操作として完了すべき範囲を決め、Service層でトランザクションを管理します。

SQL設計では、検索条件、結合条件、並び順、ページング、インデックス、ロック方式を一つずつ記録します。開発中の正常系だけでなく、データが0件の場合、重複登録、同時更新、タイムゾーン、文字コード、最大件数、タイムアウトを検証対象にします。代表的なSQLはExplainの実行計画を確認し、目標件数と本番相当データ量で性能を測ることが大切です。

安全性については、MyBatisだから安全とは考えません。値の埋め込みは#{}によるバインドを基本とし、${}や文字列連結を使う場合は、用途を限定したうえで許可リストとテストを設けます。ソート列名やテーブル名はバインド変数にできない場合があるため、画面から受け取った値をそのままSQLへ渡さず、アプリケーション側の固定値へ変換します。OWASPはパラメータ化クエリ、許可リスト入力検証、最小権限を主要な対策として示しています(出典: OWASP SQL Injection Prevention Cheat Sheet、2026年確認)。

フェーズ4:テストでSQL・データ・性能を実環境に近づけます

テストは、画面が表示されるかだけで終わらせません。Mapperの単体テストでは、引数の組み合わせ、NULL、境界値、動的SQLの条件分岐を確認し、結合テストではServiceからDBまでのトランザクション、ロールバック、例外処理を確認します。特に<foreach><choose>を使う検索は条件の組み合わせが増えるため、代表ケースを決めて自動テストへ組み込みます。

データ移行がある場合は、移行前後の件数、主キー、金額合計、ステータス、日付、文字化けの有無を照合します。新旧システムを並行稼働するなら、同じ取引を二重登録しない仕組みと、差分を確認する担当者を決めます。外部連携では、相手側の停止、遅延、重複送信、再送、部分成功を想定し、リトライとエラー通知の条件を受け入れテストに含めます。

性能試験では、平均値だけでなくP95やP99のレスポンスタイム、DB接続プール、CPU、メモリ、ロック待ち、スロークエリを確認します。高負荷時にアプリケーションを増やしても、DBのインデックスや接続数がボトルネックなら改善しません。受け入れ条件には、想定同時数、ピーク時間帯、許容時間、障害時の復旧手順、監査ログの出力、バックアップからの復元結果を明記します。

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

業務システムをリリースして現場へ定着させる場面

テストを通過した後は、稼働判定、リリース、初期運用、現場定着を一続きの工程として計画します。稼働日にシステムを切り替えるだけでは、利用者が使いこなせず、旧運用へ戻ったり、開発会社への問い合わせが集中したりします。

フェーズ5:稼働判定と段階リリースを行います

稼働判定では、機能テストの合格だけでなく、移行データの照合、性能試験、脆弱性診断、権限試験、バックアップ復元、監視通知、問い合わせ窓口を確認します。リスクが高い場合は、全社同時切り替えではなく、部門や業務を分けた段階リリース、限定ユーザーでのパイロット、旧システムとの並行稼働を選びます。切り戻しの条件と最終判断者を決めておくことが重要です。

リリース当日の作業は、実施担当、開始・終了時刻、DBバックアップ、アプリ停止、データ移行、接続先変更、動作確認、利用者通知、切り戻しを手順書にします。作業手順は一度読み合わせを行い、担当者が不在でも実施できる粒度にします。障害が起きた場合は、画面のエラーだけでなく、アプリログ、SQLログ、DBメトリクス、外部連携ログを追えるようにします。

フェーズ6:運用保守と現場定着を仕組み化します

定着のためには、利用者向け操作説明だけでなく、業務変更時の判断ルールを用意します。マスタ登録者、承認者、問い合わせ一次窓口、SQLや権限を変更できる管理者を分け、誰が何を判断するかを運用設計書へ記録します。操作マニュアルは完成品を配布するだけでなく、実際の業務シナリオに沿った短い手順とFAQにすると利用されやすくなります。

保守契約では、障害対応の受付時間、一次回答と復旧の目標、軽微な改修の範囲、Java・Spring・MyBatis・DBドライバの脆弱性対応、OSやコンテナ更新、SQL性能監視、バックアップ復元テスト、法改正対応を分けて確認します。初期開発費だけを比べると、リリース後の更新や性能改善が別料金になり、予算を立てにくくなるためです。

月次では、問い合わせ件数、処理時間、エラー件数、遅いSQL、権限変更、バックアップ結果を確認します。四半期ごとに、インデックスの有効性、不要データの増加、依存ライブラリの更新、利用率の低い画面、現場の改善要望を見直します。運用データを次の改善へつなげることで、MyBatisのシステムを作って終わりにせず、業務成果へ結び付けられます。

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

システム開発費用の内訳を確認する場面

MyBatis自体はオープンソースのフレームワークであり、MyBatisのライセンスを購入すれば業務システムが使える製品ではありません。費用の中心は、要件定義、Java・Spring開発、SQL・DB設計、テスト、移行、インフラ、監視、教育、保守です。以下は、リサーチノートに記載された2026年基準の業務システム開発相場を、MyBatisをデータアクセス層に使う案件へ当てはめた推定レンジです。MyBatis固有の公開定価ではないため、個別見積もりの代わりにはなりません。

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

既存システムへMapperを追加する小規模改修は、認証やインフラを再利用する前提で100万〜500万円程度、期間は1〜3か月程度が一つの目安です。部門向けの小規模業務システムは300万〜1,000万円程度、期間は2〜6か月程度です。ログイン、権限、マスタ、一覧・検索・登録、帳票、基本監視を含む場合の推定であり、画面数や連携数によって変わります。

複数部門の受発注・在庫・顧客などを扱い、外部連携、バッチ、既存DB連携、移行、性能試験を含む中規模案件は1,000万〜5,000万円程度、期間は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や要件一覧がない状態で「MyBatisのシステムを作りたい」とだけ伝えると、各社が異なる範囲を想定し、価格差の理由が分からなくなります。

要件と成果物を見積書の前提に書きます

発注前に渡す資料には、現行システム構成、業務フロー、画面・API一覧、連携先、主要テーブル、データ件数、権限ロール、ピーク同時数、性能目標、移行対象、希望時期を含めます。まだ決められない事項は未確定として残し、調査・PoC・要件定義に必要な工数を別見積もりにします。未確定事項を無料の実装作業として扱うと、後の追加費用や納期遅延につながります。

成果物は、要件定義書、基本・詳細設計書、ER図、API仕様、Mapper一覧、SQLレビュー記録、テスト仕様書、移行手順書、リリース手順書、運用設計書、ソースコード、ビルド手順、監視設定、教育資料まで確認します。ソースコードだけでなく、SQLの意図や性能上の前提が残っていなければ、担当者交代後の保守で時間がかかります。

複数社を同じ質問で比較します

候補会社には同じRFPを渡し、MyBatisの経験年数だけでなく、担当者が本番運用まで経験しているかを確認します。質問例は、既存Java 8からJava 17へ移行した実績、Spring BootとMyBatisの対応バージョン、XML MapperとDynamic SQLの選定方針、DBチューニングの担当者、性能試験のデータ量、移行リハーサルの回数、障害時の体制です。

比較表には、要件定義、設計、実装、テスト、移行、リリース、教育、保守の金額と人月を並べます。準委任なら作業時間と体制、請負なら納品条件と変更管理を確認します。リサーチノートでは、請負契約のリスクを価格へ反映するため、準委任の単純な人月計算に対し1.3〜1.5倍程度の係数が上乗せされる場合があると整理されています。契約方式の違いを考慮せずに単価だけを比べないことが大切です。

リスクと追加費用の条件を確認します

注意すべき見積もりは、画面数だけで価格を決め、SQLの複雑さ、データ移行、外部連携、性能試験、権限、監査ログ、運用を「一式」としているものです。安い場合は、要件定義、テスト、ドキュメント、リリース後サポートが含まれていない可能性があります。逆に高い場合も、高額な理由がPM、DB専門家、セキュリティ試験、冗長化、移行リハーサルのどれなのかを確認すれば判断できます。

変更管理では、追加要求の単価、承認者、影響調査の扱い、納期変更の条件、仕様凍結の時期を決めます。特にMyBatis案件では、画面の条件追加がSQL、インデックス、APIレスポンス、テストデータへ連鎖することがあります。変更を受け付ける前に、性能・セキュリティ・移行への影響を見積もる手続きを設けることが安全です。

セキュリティでは、SQLインジェクション、過剰権限、個人情報の参照範囲、監査ログ、エラーメッセージ、脆弱性診断の実施者と時期を契約へ入れます。IPAは、SQL文の組み立てにプレースホルダを使い、データベースアカウントへ必要最小限の権限を与え、DBエラーを利用者へ直接表示しないことを示しています(出典: IPA「安全なウェブサイトの作り方 1.1 SQLインジェクション」、2026年確認)。MyBatisの設定だけでなく、運用権限と監視まで含めて見積もることが必要です。

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

MyBatisのシステム開発に関する相談場面

ここでは、MyBatisのシステム開発を検討する発注者から寄せられやすい質問へ回答します。技術の可否だけでなく、費用、期間、発注時の確認事項まで判断できるように整理します。

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、MyBatis-Spring-Boot-Starter、MyBatis Dynamic SQL、DBドライバ、アプリケーションサーバー、ビルドツールの対応関係を確認し、代表的なMapperと外部連携を検証します。Java 17を最低要件とするライブラリへ上げられない場合は、既存系統を保守しながら段階移行する計画も選択肢になります。

まとめ

MyBatisのシステム開発を成功へ進めるまとめ

MyBatisのシステム開発は、MyBatisを導入するだけの作業ではなく、業務システムの要件、Java・Spring、SQL、DB、移行、テスト、運用をつなぐプロジェクトです。特に、要件整理の段階でデータ量、性能、権限、監査、RTO・RPO、移行範囲を決めておくと、Mapperの作り直しや見積もりの追加費用を抑えやすくなります。

進め方は、(1)要件整理、(2)MyBatisと周辺技術の選定、(3)Service・Mapper・DBの設計開発、(4)機能・データ・性能・セキュリティのテスト、(5)段階的な稼働、(6)保守と現場定着の6段階です。費用は小規模改修で100万〜500万円程度、中規模で1,000万〜5,000万円程度など幅があるため、総額ではなく工程、工数、成果物、保守範囲を同じ条件で比較してください。

開発会社を選ぶときは、「MyBatisに対応できるか」だけでなく、既存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を創業。