Kotlinでのアプリ開発を外注するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義とRFP（提案依頼書）です。とくにKotlinは「Android公式言語だが単体ではiOSアプリが作れない」「Java資産との相互運用や移行をどう扱うか」「iOS両対応にKotlin Multiplatform（KMP）を使うか、Swiftで別途作るか」といった、技術選定そのものを要件として整理する必要がある言語です。これを曖昧にしたままベンダーに丸投げすると、見積りが横並びで比較できず、完成後に「iOSが想定どおり動かない」「採用したくても書ける人がいない」といった事態に陥ります。技術選定を含む要件をいかにRFPに落とし込めるかが、現場に使われるアプリになるか、無駄な投資に終わるかの分かれ目になります。
本記事は、Kotlinでのアプリ開発のRFP・要件定義書・提案依頼書を、発注企業の視点から具体的に解説する「要件定義特化」の記事です。技術選定（ネイティブKotlin／KMP／クロスプラットフォーム、Android／iOS優先）を要件に落とす方法、Must/Wantの仕分けと社内合意、内製化を見据えた採用市場の考慮、RFPに盛り込む項目、そして見積りの妥当性を判断する軸まで、発注実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まずKotlin開発の完全ガイドから読むことをおすすめします。
技術選定を要件に落とすプロセス
Kotlin開発の要件定義が一般的なアプリ開発と異なるのは、技術選定そのものが重要な要件になる点です。「Kotlinで作る」と決めても、Android専用なのか、iOS両対応なのか、両対応ならKMPかSwift別実装か、既存Java資産をどう扱うかで、必要な工数も体制もまったく変わります。これらを曖昧にしたままRFPを出すと、ベンダーごとに前提が異なる提案が返り、比較できません。技術選定を要件として明文化することが、出発点です。
Android／iOS優先を要件で決める
Kotlin採用の前提として、まず「どのOSを優先するか」を要件で決めます。日本はiOSのシェアが高く、世界全体ではAndroidが高いという一般論はありますが、重要なのは自社のターゲット層です。たとえば若年女性層が中心ならiOS先行、物流・製造の業務端末ならAndroid先行、というように、ターゲット属性に基づいて優先順位を決めるべきです。Kotlinが主役になるのはAndroid優先の場合で、Android端末を業務で使う現場アプリや、Androidユーザーが多いサービスでは、Kotlinネイティブが第一候補になります。
片側のOSを先行リリースし、検証してから他方を作るという段階的な進め方も、要件として明記すべき判断です。たとえばAndroidをKotlinで先行リリースし、市場の反応を見てからiOS対応を決める、という計画です。この場合、要件定義の段階で「将来iOS対応する可能性があるか」を明示しておくことが重要です。後からiOS対応を決めると、KMPで共通化できたはずのロジックをすべて作り直すことになりかねません。将来のOS展開まで見据えて、初期の技術構成を要件に落とすことが、後戻りを防ぎます。
KMP／Swift別実装とJava資産の扱いを定義する
iOS両対応が必要な場合、KMPでロジックを共通化するか、iOSはSwiftで別途作るかを要件で定義します。KMPはロジックの二重開発を避けられますが、まだ新しい技術で対応ライブラリや知見が発展途上です。Swift別実装は各OSで最適化できますが、ロジックを二重に作る分のコストがかかります。どちらを選ぶかは、ロジックの複雑さ、両OSの仕様一致の必要性、そして後述の採用市場まで含めて判断し、RFPに「KMPを用いてロジックを共通化する」あるいは「iOSはSwiftで個別実装する」と明記します。
既存のAndroidアプリをJavaで運用している場合は、Java資産の扱いも要件の柱です。KotlinとJavaは100%相互運用できるため、全面書き換えではなく、新規機能からKotlin化し既存Javaを段階的に移行する方針を要件として示せます。「既存のJavaコードベースを活かし、段階的にKotlinへ移行する」「コアロジックは当面Javaを維持する」といった移行方針をRFPに書くことで、ベンダーは現実的な移行計画を含めて見積もれます。移行範囲が曖昧だと、見積りが過大になったり、逆に移行リスクが見落とされたりします。技術選定・OS優先・Java移行という3点を要件に落とすことが、Kotlin開発のRFPの核心です。具体的な機能の中身については『Kotlinの必要機能や標準機能の一覧について』もあわせてご覧ください。
Must/Wantの仕分けと社内合意形成
技術選定と並んで要件定義の難所になるのが、機能のMust/Want仕分けと、それをめぐる社内合意です。アプリ開発では、現場は「あれもこれも欲しい」と多機能を求め、経営層は「コストを抑えて早く出したい」と短期・低コストを求めます。この板挟みを要件定義の段階で解消できないと、開発の途中で要件が膨らみ、予算もスケジュールも破綻します。
機能をMust／Want／将来に仕分ける
機能要件は、ただ列挙するのではなく、Must（これがないと成立しない必須）、Want（あれば価値が上がる）、将来（後から追加でよい）の3段階に仕分けます。この仕分けの基準は「事業目的に直結するか」です。アプリの存在意義となるコア機能はMust、ユーザー満足を高める付加機能はWant、思いつき段階のアイデアは将来、と分類します。機能別の開発費（会員登録・ログイン30〜80万円、決済80〜200万円、リアルタイムチャット150〜400万円：出典ripla）を踏まえれば、何をMustにするかが予算を直接左右することが分かります。
この仕分けがあると、見積りが予算を超えた場合に、Wantや将来の機能を初期リリースから外す判断が冷静にできます。すべてをMustにしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。Kotlinの場合、まずAndroidのMust機能でMVP（最小限の価値を検証する版）を作り、効果を見ながらWantやiOS対応を追加する段階的なリリース計画が現実的です。MVPの範囲を要件で明確にすることが、予算管理と早期の市場検証を両立させます。機能の優先度付けは、要件定義書の中でも投資判断に直結する部分です。
現場と経営層の板挟みを合意で解消する
Must/Wantの仕分けは、技術論ではなく社内政治の問題でもあります。現場の多機能志向と経営層のコスト志向は、どちらも正しい立場であり、これを調整するのが要件定義の隠れた本丸です。有効なのは、機能ごとに「この機能は事業目的のどれに貢献し、いくらかかるか」を可視化し、関係者全員が同じ土俵で優先順位を議論できるようにすることです。感情論や声の大きさで決めるのではなく、目的への貢献度とコストという共通の物差しで合意を形成します。
合意形成のもう一つの鍵は、「最初から完璧を目指さない」という共通理解です。MVPで小さくリリースし、ユーザーの反応というデータをもとに次の機能を決める、というアジャイルな考え方を関係者で共有できれば、現場の「全部欲しい」も経営層の「安く早く」も、段階的リリースという形で両立できます。要件定義の段階でこの合意を取り付けておくことが、開発途中の手戻りや揉め事を防ぎます。riplaは元事業会社（ラクスル/LINEヤフー）出身の知見をもとに、この現場と経営層の板挟みを解消する要件整理を支援しています。要件定義は、技術と社内合意の両輪で進めることが成功の条件です。
内製化・採用市場と非機能要件の整理
要件定義で見落とされがちなのが、「作った後、誰が保守し、内製化できるのか」という観点です。アプリは作って終わりではなく、長期的に運用・改修されます。その担い手を確保できるか、つまり採用市場を要件に織り込むことが、Kotlin選定の隠れた重要ポイントです。あわせて、性能・セキュリティといった非機能要件も整理します。
内製化を見据えた採用市場を要件に織り込む
将来的に内製化を目指すなら、技術選定は採用市場と一体で考えるべきです。riplaの一次データでは、エンジニアの採用難易度は「React Native ＞ Swift/Kotlin ＞ Flutter ＞ KMP」の順で、左ほど採用しやすいとされています。Kotlinは比較的採用しやすい部類で、年収相場も約873万円（2022年、Swiftの約868万円とほぼ同水準：出典ripla）と、Androidエンジニアの市場が成熟しているため、内製化の担い手を確保しやすい言語です。これはKotlinを採用する大きな実務的メリットです。
一方で注意したいのが、KMPの採用難易度の高さです。KMPは採用ランキングで最も採用しにくい位置にあり、KMPを担当するエンジニアが退職した場合のリカバリーが経営リスクになりえます。iOS両対応のためにKMPを選ぶ場合は、「その技術を担える人材を継続的に確保できるか」を要件定義の段階で見極める必要があります。採用市場を無視して技術を選ぶと、「作れたが保守できない」「退職で開発が止まる」という事態を招きます。要件定義書に「内製保守を見据え、採用可能性の高い技術構成を優先する」といった方針を明記することが、長期の持続性を担保します。
性能・セキュリティの非機能要件を定義する
非機能要件では、性能・セキュリティ・保守性を定義します。性能要件は、Kotlinネイティブを選ぶ理由とも直結します。たとえば「カメラ起動は何秒以内」「リスト表示は滑らかに」といった性能目標を要件にすれば、ネイティブのKotlinが適しているのか、クロスプラットフォームでも足りるのかを客観的に判断できます。容量やカメラ起動の性能差（ネイティブ6.6MB対Flutter16.8MB、カメラ5.85ms対247.87ms：出典ripla）を踏まえ、自社のアプリにとって妥協できない性能を要件として明記します。
セキュリティは、扱うデータの機密性に応じて要件化します。決済情報や個人情報、業務データを扱うアプリでは、通信の暗号化、生体認証、不正アクセス対策などを要件に盛り込みます。Kotlinはネイティブ言語なので、OSが提供するセキュリティ機構を直接使える強みがあります。さらに保守性の観点では、null安全やコルーチンといった言語機能が長期保守の負担を下げることを踏まえ、コードの可読性や保守体制も要件に含めます。機能要件と同じ熱量で非機能要件を詰めることが、リリース後の「遅い」「落ちる」「漏れる」というトラブルを防ぎます。
RFPに盛り込む項目と見積り妥当性の判断
要件がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。とくにKotlin開発は技術選定の幅が広いため、RFPで土俵を揃えることが、見積りの妥当性判断の大前提になります。
RFPに必ず盛り込むべき項目
Kotlin開発のRFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKGI、対象OS（Android／iOSの優先順位）、技術要件（ネイティブKotlin／KMP／Swift別実装、Java資産の移行方針）、機能要件（Must／Want／将来の分類付き）、非機能要件（性能・セキュリティ・保守性）、予算とスケジュールの目安、開発・運用の体制要求、そして内製保守や採用市場に関する方針です。とくにKotlin開発では、技術要件と対象OSを具体的に書くことが、提案の前提を揃える要になります。
とくに見落とされがちなのが、体制要求と契約・法務面です。コンペにエース級の担当者が出てきても、実開発は技術力の低い下請けが行い、リリース後に障害が多発した、という失敗は実際に起きています。これを避けるには、RFPで体制図の提出を求め、誰が実際にKotlinを書くのか、PMは誰かを明記させることが有効です。さらに、契約解除やベンダー変更に備え、ソースコードの著作権の帰属、検収基準、SLA（サービス品質保証）といった法務面の条件もRFPで提示しておくと、後の自衛策になります。プレゼンの上手さではなく、実開発体制の実態を確認できる項目をRFPに盛り込むことが、ベンダー選定の防衛策です。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、発注先別の単価相場を知ることが第一歩です。人月単価は、フリーランス60〜80万円、中小開発会社80〜120万円、大手SIer150〜300万円と大きく異なります。この差は技術力の差というより、中間マージンや組織維持費の差です。同じKotlinアプリでも、誰に発注するかで総額が数倍変わるため、見積りは「金額の絶対値」ではなく「人月数×単価」の構造で読み解く必要があります。A社1,500万円とB社800万円の差が、工数の差なのか単価の差なのかを見極めます。
次に、見積りの内訳を精査します。「開発一式」「テスト・デバッグ費」が一式でまとめられている場合は、内訳の開示を求めます。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件が発生したときの単価ルールも事前に取り決められます。要件定義書とRFPが詳細であるほど、ベンダーは精緻な見積りを出さざるを得ず、「開発一式」のブラックボックスを解明しやすくなります。なお、AI駆動開発と分割発注で市場相場700〜1,500万円規模を500万円に圧縮した事例もあり、コスト最適化の選択肢を提案できるかも、ベンダー評価の一つの軸になります。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と、見積り内訳を明示する進め方を重視しています。
まとめ
Kotlin開発の要件定義・RFP・提案依頼書は、機能の列挙だけでなく、技術選定（ネイティブKotlin／KMP／Swift別実装、Android／iOS優先、Java資産の移行方針）を要件として明記することが核心です。そのうえで、機能をMust／Want／将来に仕分けてMVPの範囲を定め、現場と経営層の板挟みを社内合意で解消し、内製化を見据えて採用市場（Kotlinは採用しやすく年収約873万円、KMPは採用難：出典ripla）まで織り込む。これらをRFPに技術要件・体制要求・契約条件まで明記すれば、ベンダーの提案を横並びで比較でき、人月単価（フリーランス60〜80万・中小80〜120万・SIer150〜300万：出典ripla）に照らして見積りの妥当性も判断できます。
要件定義の質は、そのままプロジェクトの成否に直結します。事業目的と現場の事情を正確に映し、技術選定まで含めた要件こそが、現場に使われ、長く保守できるアプリを生みます。riplaはフルスクラッチ受託と国内開発、元事業会社出身の知見を組み合わせ、技術選定からMust/Wantの仕分け、RFP作成までを発注企業と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。