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

Kotlin Multiplatformのシステムを発注・外注するなら、共通化できる機能とOSごとに作り分ける機能を先に整理し、PoC・要件定義・契約・保守まで含めて委託範囲を決めることが成功の近道です。

AndroidとiOSの業務アプリを同時に整備したい一方で、「Kotlinだけで両方を作れるのか」「見積金額はどこまで下がるのか」「発注先に何を伝えればよいのか」と悩む担当者は少なくありません。Kotlin Multiplatform（KMP）は、業務ルールや通信、データ処理などを共有しながら、必要に応じて各OSのネイティブ機能を使える技術です。この記事では、発注形態の選択からRFP、要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法までを発注者の視点で解説します。

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

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

Kotlin Multiplatformは、Android・iOS・デスクトップ・Web・サーバーなどでKotlinコードを共有できるオープンソース技術です。発注時に最も大切なのは「一つのコードですべての画面を作る技術」と捉えないことです。共有する範囲を機能単位で設計し、業務データと処理は共通化しつつ、操作感や端末機能はネイティブで実装する構成も選べます。

同じものではありません。KMPは、ドメインルール、認証、APIクライアント、データモデル、入力バリデーション、オフライン同期などのロジックを複数プラットフォームで共有する仕組みです。一方、Compose Multiplatform（CMP）はKotlinでAndroid・iOSなどのUIも共有するためのフレームワークです。KMPを採用しても、AndroidはJetpack Compose、iOSはSwiftUIまたはUIKitという構成を選べます。

発注者にとっては、KMPとCMPを見積書で分けて記載してもらうことが重要です。業務アプリでは、まず共通ロジックを導入し、UIはOSごとに作る方式が段階導入しやすい傾向があります。画面の共通化まで広げる場合は、アクセシビリティ、画面遷移、入力欄、端末の戻る操作、既存デザインシステムとの整合をPoCで確認します。

共通化の効果が出やすいのは、業務ルールやデータを扱う機能です。たとえばログインと権限判定、顧客・商品・在庫のデータモデル、RESTやGraphQL APIとの通信、入力チェック、通知の状態管理、オフライン時の保存と再送処理は、AndroidとiOSで同じ仕様にしやすい領域です。共通コードに集約できれば、片方だけ修正が漏れて業務結果が異なるリスクを抑えられます。

反対に、カメラ、Bluetooth、位置情報、生体認証、プッシュ通知、ファイル共有などはOS固有の差が出やすい領域です。これらを「共通化率を上げる」という理由だけで無理に一つへ寄せると、テストや不具合対応が複雑になる場合があります。RFPでは画面数や機能数だけでなく、「共通ロジック」「Android固有」「iOS固有」「CMPによる共通UI」の4区分で対象を示すと、提案と見積を比較しやすくなります。

発注形態はどのように選べばよいですか？

発注形態は、完成責任を外部に任せたいのか、自社チームと一緒に技術を蓄積したいのかで選びます。KMPのシステムでは、技術検証だけを専門会社へ依頼し、本開発は別の会社へ発注する方法もあります。最初から開発全体を一社へ丸投げするより、PoCで共有範囲と開発体制を確認してから本契約へ進むほうが、発注者の判断材料を増やせます。

一括請負型は、要件定義から設計、開発、テスト、リリースまでの成果物と納期をまとめて管理したい会社に向いています。社内にKMPやiOSの専門人材が少なく、プロジェクト管理の窓口を一本化したい場合にも適しています。ただし、KMP特有の共有範囲やOS固有実装を理解しない会社へ依頼すると、見積上は安くても、後からiOS側の追加工数や保守費が膨らむ可能性があります。

一括で依頼する場合は、成果物の定義を細かくします。ソースコードだけでなく、アーキテクチャ設計書、API仕様書、テスト仕様書、端末検証結果、依存ライブラリ一覧、SBOM、CI/CD設定、ストア申請手順、障害対応手順まで納品対象に含めます。ソースコードの著作権、第三者ライブラリのライセンス、再委託の範囲、検収条件も契約前に確認します。

伴走型やラボ型は、発注者側にもプロダクト責任者や技術担当者がいて、要件を優先順位に応じて変えながら開発したい場合に適しています。KMPの共有範囲は、実際に作ってみると機能ごとに最適解が変わります。月単位でチームを確保し、共通モジュールの設計、既存Androidからの段階移行、iOS連携、テスト自動化を一緒に進める形なら、学習と内製化を同時に進められます。

一方で、作業時間に対して支払う契約では、発注者が優先順位を決め、受入基準を管理する必要があります。月額の安さだけを比較せず、Kotlin・Swift・CI/CD・セキュリティを含むチーム構成、月間の稼働時間、担当者の交代条件、成果物の引き渡し方法を確認します。PoCだけ伴走型にして、本開発は請負または準委任へ切り替える組み合わせも現実的です。

RFPと要件整理では何を決めておくべきですか？

RFPは、技術名を伝える資料ではなく、解決したい業務課題と発注条件を揃えて伝える資料です。KMPを採用したい理由が「AndroidとiOSで業務ルールを揃えたい」「既存アプリを段階移行したい」「開発と保守の重複を抑えたい」なら、その目的を冒頭に書きます。KMP採用を前提にしつつも、ネイティブや別のクロスプラットフォーム技術を含めて提案してよいと記載すれば、技術ありきの比較を避けられます。

まず、利用者、利用場所、利用端末、業務の開始条件と完了条件を整理します。営業担当が訪問先で使うのか、倉庫でバーコードを読むのか、工場で通信圏外に入力するのかで、設計も見積も大きく変わります。認証、権限、顧客・商品・在庫・案件・作業実績、承認、帳票、ファイル、通知などの機能を、必須・できれば必要・将来対応に分けます。

特にKMPのシステムでは、オフライン要件を曖昧にしないことが重要です。「電波が弱くても使える」だけでは不十分で、端末に何を保存するか、保存期間、暗号化、再送のタイミング、同じデータを複数端末で更新した場合の競合ルール、失敗時に利用者へ何を表示するかまで決めます。カメラやBluetoothを使う場合は、対象端末、権限拒否時の代替操作、バックグラウンド動作の要否もRFPへ記載します。

業務システムの費用と納期は、画面数だけでは決まりません。同時利用者数、応答時間、対応OSと端末、稼働時間、バックアップ、RTO・RPO、監査ログ、脆弱性対応、障害通知、データ保持期間、管理者の操作範囲を決める必要があります。個人情報、営業情報、位置情報を扱うなら、端末保存の有無、暗号化、認証強度、端末紛失時のリモート削除、退職者のアカウント停止、委託先のアクセス記録も要件に含めます。

セキュリティの確認には、OWASP MASVSのストレージ、暗号、認証、ネットワーク、プラットフォーム、プライバシーなどの観点をチェックリストとして利用できます。KMPだから安全になるわけではなく、共通コードとOS固有コードの両方をテストすることが必要です。RFPでは、脆弱性診断の実施者、修正期限、ログの保管場所、インシデント発生時の連絡時間を明記します。

契約形態は請負と準委任のどちらがよいですか？

契約形態は、要件の確定度と発注者が担う管理の範囲で選びます。KMPでは、技術検証と本開発で適した契約が異なる場合があります。契約書の名称だけで判断せず、作業範囲、成果物、検収、報告、知的財産、再委託、瑕疵対応、変更管理を確認してください。法務・会計上の最終判断は、自社の専門部署や専門家にも確認します。

請負契約は、合意した成果物を決められた条件で完成させる工程に使いやすい契約です。画面仕様、API、データ移行、テスト項目、対応端末、検収条件を確定できる本開発やリリース作業に向いています。KMPの本開発を請負にする場合は、「共通化率」という抽象的な指標ではなく、commonMainに含めるモジュール、Android・iOS固有の実装、テストの合格条件を成果物として定義します。

請負で注意したいのは、要件変更の扱いです。iOSの実機検証で新たな制約が分かったり、オフラインの競合ルールが変更されたりすると、当初見積の範囲を超えることがあります。変更依頼の受付方法、追加見積の単価、納期の再計画、軽微変更の上限を先に合意しておくと、後から「無償対応か追加請求か」で揉めにくくなります。

準委任契約は、専門家が一定期間の業務を遂行することを委託する形で、要件定義、PoC、アーキテクチャ検討、既存アプリの移行調査、内製化支援に使いやすい契約です。KMPでは、どの層を共有すべきか、Swiftとの相互運用をどう設計するか、CIでAndroidとiOSをどう検証するかなど、調査結果で方針が変わる工程があります。こうした不確実性の高い工程を準委任にすると、検討を止めずに進められます。

ただし、準委任では作業時間を管理するだけでなく、毎週の成果、判断事項、リスク、次週の計画を報告してもらいます。担当者の経験だけに頼らず、設計書、検証コード、判断記録、課題一覧を残すことが重要です。PoCの終了条件を「動いた」ではなく、主要端末でのビルド時間、APIエラー時の挙動、認証、共有範囲、保守性などの判定項目で定めます。

Kotlin Multiplatformのシステム発注費用・相場はいくらですか？

KMP専用の公的な国内費用統計は確認できないため、以下は2026年時点の国内モバイルアプリやBtoBアプリの公開相場を基にした、KMPの業務システム発注における目安です。費用は画面数だけでなく、既存APIの状態、オフライン対応、端末検証、データ移行、セキュリティ、運用監視、共有範囲で変わります。したがって、金額は定価ではなく、前提付きのレンジとして扱います。

技術検証や共有モジュールのPoCは、認証、API接続、1機能、AndroidとiOSのビルド・テストを対象にするなら、100万〜300万円程度が一つの目安です。5〜15画面ほどの小規模な社内業務アプリで、ログイン、一覧・登録、簡易管理画面を含める場合は、500万〜1,000万円程度を見込みます。実際の金額は、既存のAPIを使えるか、新規にバックエンドを作るかで変わります。

20〜50機能、複数API、権限、通知、オフライン、端末検証を含む中規模の業務システム連携アプリは、1,500万〜3,000万円程度が目安です。複数拠点・複数システムとの連携、データ移行、監査、SLA、24時間運用まで含む大規模案件は、3,000万〜8,000万円以上になる可能性があります。これらのレンジは、株式会社ripla「BtoBアプリ開発の進め方」で示される規模別相場と、2026年のSIA株式会社の業務システム連携アプリの相場を参考にした推定です（出典: 株式会社ripla、SIA株式会社、2026年）。

既存AndroidアプリをKMPへ段階移行する場合は、共有効果の高い認証・通信・ドメイン層から着手するなら、300万〜1,500万円程度を目安に調査・移行範囲を検討します。すべての画面を一度に作り直す費用ではなく、既存コードの品質、テストの有無、依存ライブラリ、Swift側の実装状況を確認したうえで見積を取り直す前提です。

見積書は「KMPアプリ開発一式」ではなく、要件定義、基本設計、共通コード、Android固有、iOS固有、CMPのUI、バックエンド・API、管理画面、データ移行、テスト、CI/CD、ストア申請、導入支援、保守に分けてもらいます。KMPによって二重実装を減らせる可能性はありますが、要件定義、バックエンド、実機テスト、運用監視、ストア審査が消えるわけではありません。共通化で減る工数と、KMPのビルド基盤や相互運用で増える初期工数を分けて見る必要があります。

費用配分の目安として、要件定義10〜15%、基本設計15〜20%、開発30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%という考え方があります。これは案件の標準比率ではなく、見積の抜けを探すための確認軸です（出典: 業務システムの費用配分に関するNotebookLMリサーチノート、2026年）。また、年間保守は初期開発費の15〜20%程度が公開相場の一つですが、OSアップデート、脆弱性対応、障害対応時間、軽微改修、サーバー費用が含まれるかで大きく変わります（出典: SIA株式会社、2026年）。

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

委託先は、KMPという技術名だけで選ばないことが大切です。KMPの本番利用経験、AndroidとiOSの両方を含む体制、ネイティブUIとCMPの使い分け、業務システム連携、オフライン、端末固有機能、セキュリティ、リリース後の保守を同じ基準で比較します。公開事例があっても、自社の要件と似た規模・利用環境とは限らないため、担当エンジニアへの質問で実績の中身を確認します。

まず、「この案件でcommonMainへ置く機能と、Android・iOSへ残す機能は何か」「Compose Multiplatformを使う画面と、ネイティブUIにする画面はどこか」と質問します。次に、Swift側で必要な作業、iOS固有APIの実装、主要端末の検証方法、CIでのビルド、ライブラリの更新方針、Xcode・Gradle・Kotlinの互換性確認を聞きます。JetBrainsは2025年8月のロードマップで、Swift Exportの改善、互換性マトリクス、Kotlin MultiplatformのIDE体験向上を掲げ、2026年にSwiftとKotlinの相互運用に必要な安定化を目指す方針を示しています。発注時点で採用するバージョンと、更新を誰が判断するかを契約に落とし込みます。

業務面では、現場ヒアリングの進め方、マスタデータの整理、既存APIの調査、データ移行、利用者教育、問い合わせ対応も確認します。KMPの経験があっても、現場業務を理解していなければ、誤った入力や二重管理を速くするだけになりかねません。提案書に、利用者の業務フロー、例外処理、導入後の定着支援まで書かれているかを見ます。

複数社へ同じRFPを渡し、総額だけでなく前提条件を揃えて比較します。たとえば、A社はAPIが既存で利用できる前提、B社はAPI新規開発を含む前提、C社はオフラインを将来対応としている場合、金額をそのまま並べても判断できません。各社に、含む範囲、含まない範囲、追加費用になる条件、想定端末、テスト環境、必要な発注者側の作業を明記してもらいます。

比較表を作るときは、共通ロジックの工数、Android固有工数、iOS固有工数、バックエンド、QA、PM、セキュリティ、移行、保守を横並びにします。特に、極端に安い見積は、iOSの実機テスト、データ移行、CI/CD、ストア申請、障害対応が別料金になっていないか確認します。逆に高い見積は、要件に対して過剰なCMP共通UIや不要な基盤整備が含まれていないかを質問し、機能単位で削るのではなく、目的に対する優先順位で調整します。

初めてKMPを導入する場合や、既存Androidから移行する場合は、PoCを見積に含めることをおすすめします。対象は、認証、API、ローカルDB、オフライン再送、iOSへの公開API、カメラや通知など、自社でリスクが高い機能から選びます。成果物はサンプル画面だけでなく、採用・不採用の判断、性能、ビルド手順、想定される保守負荷、残課題を含む技術報告書にします。

本開発は、認証や通信など共通化効果の高い機能から段階的に進め、AndroidとiOSを同じCIでビルドし、機能単位でリリースします。品質指標として、共通コードのテストカバレッジ、OS別の不具合件数、ビルド時間、クラッシュ率、業務完了時間、問い合わせ件数を追跡します。共通化率を高めることではなく、二重実装の削減と業務品質の向上を測ることが大切です。

よくある質問（FAQ）

Kotlin Multiplatformのシステムを外注する際は、技術の採否だけでなく、発注条件、費用の前提、保守体制を確認することが重要です。ここでは、発注前によく寄せられる質問に直接回答します。

必ず安くなるわけではありません。業務ルールや通信処理を共有できれば二重実装・二重保守を減らせる可能性がありますが、KMPの導入初期にはPoC、ビルド基盤、iOS相互運用、実機テストの費用が発生します。費用は共通化率ではなく、要件定義から保守までの総保有コストで比較します。

依頼はできますが、iOS固有機能を扱う案件ではSwiftまたはSwiftUI・UIKitの知識を持つ担当者が体制に含まれているか確認してください。KMPの共通コードだけで完結しない認証、通知、カメラ、Bluetooth、ストア申請、アクセシビリティなどは、iOS側の判断が必要です。担当者の所属形態よりも、設計レビューから実機検証、障害対応までiOSの責任者が関与するかを見ます。

移行できます。すべてを作り直すのではなく、認証、データモデル、通信、業務ルールなど共有効果の高い層から段階的に移行する方法が一般的です。既存コードのテスト不足、Android固有APIへの依存、ライブラリの互換性、iOS側に必要なAPI設計を調査してから、移行対象と見送る対象を決めます。

保守契約では、Kotlin、KMP、CMP、Xcode、Android Studio、Gradle、依存ライブラリ、対応OSの更新担当を確認します。あわせて、脆弱性対応の期限、クラッシュや通信障害の一次切り分け、端末紛失時の対応、ストア審査のリジェクト対応、軽微改修の月間上限、障害時の連絡時間と復旧目標を定めます。初期開発費の15〜20%程度という公開目安があっても、含まれるサービス範囲を比較しなければ適正価格は判断できません。

まとめ

発注前には、対象業務、利用者、対応端末、オフラインの有無、既存システムとの連携、共通化したい処理、納品後の運用担当を一枚にまとめます。これだけでも、委託先から返ってくる提案の前提を揃えやすくなります。

最初の行動は、社内の現場担当者と業務フローを確認し、候補会社へRFPとPoCの相談を同時に出すことです。技術の説明だけでなく、見積の前提、契約形態、保守責任、引き渡し条件まで質問し、自社が継続的に運用できる提案かを見極めます。

Kotlin Multiplatformのシステムを発注・外注するときは、まず業務課題と利用環境を整理し、共通ロジック、Android固有、iOS固有、共通UIの範囲を機能単位で定義します。技術検証や不確実性の高い要件整理は準委任、成果物と検収条件を決められる本開発は請負というように、工程ごとに契約形態を使い分けると進めやすくなります。

費用はKMPの定価ではなく、PoC、小規模、中規模、大規模、既存移行の前提付きレンジで把握します。見積書は共通コード、OS固有実装、バックエンド、QA、移行、CI/CD、保守に分け、安さだけでなく、iOS実機検証、セキュリティ、バージョン更新、ソースコードと設計書の引き渡しまで含めて比較してください。発注先を決める前に、RFPとPoCで「何を共通化し、何を残すか」を合意できれば、KMPの強みを活かしながら自社に合ったシステム開発へ進められます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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