Flutterの案件は、1つの書き方でiOSとAndroidの両方に出せます。この特徴だけを見て、任される範囲が半分になると考える方がいます。実際に見積りをしてみると、画面を作る作業は減っても、確かめる作業は増える傾向があります。この記事では、iOSとAndroidの両方に出す案件を見積る前に、確認しておきたい観点を整理します。

1. iOSとAndroidの両方に出せても、任される範囲は半分にならない

書く作業と確かめる作業は分けて考える

Flutterの案件では、画面を作る作業を1つの書き方でiOSとAndroidの両方に出せます。この点だけを見て、担当する範囲がまるごと半分になると考える方がいます。実際には、減る作業と変わらない作業があります。

減るのは、画面を作る作業です。ボタンや一覧の見た目を、プラットフォームごとに二重で書く必要がなくなります。ここまでは、iOSとAndroidの両方に出せる利点が、そのまま範囲の縮小につながります。

一方で、iOSとAndroidは通知の出し方や、許可を求める画面の挙動が異なります。書く作業が1つにまとまっても、動きを確かめる作業はiOS向けとAndroid向けに分かれたままです。

図の作成：Remogu編集部。作業の分かれ方を整理したもので、統計データではありません

見積りでは確かめる作業のほうを重く見る

利用する側の企業は、システムの品質を最も優先する事項として捉えています⁹。iOSとAndroidの両方の画面が同じ書き方から出ていても、片方でしか確かめていない状態では、この優先事項に応えられません。

確かめる作業を自動でまとめて行う仕組みが整っている案件は限られます。DevOpsやモデルベース開発は、作る側の企業を除くと導入している企業は少ないままです⁴。仕組みが無ければ、確かめる作業は手作業で積み上がります。

書く作業が半分になる点よりも、確かめる作業が二重になりやすい点のほうが、見積りに響きます。次の章では、この判断がどこで行われているかを見ていきます。

2. 新しい書き方を選ぶ判断まで、外部に出ていることがある

外部への委託が最も多い選択肢になっている

新しい書き方を選ぶ判断は、開発を担当する企業の中だけで完結するとは限りません。競争にかかわる事業では、外部への委託による開発を行っている回答率が4割弱で最も多くなっています¹。

つまり、Flutterのような書き方を選ぶかどうかの判断そのものが、依頼元の外にある案件が一定数あります。判断の主体が外に出ているほど、案件の窓口に確認する場面が増えます。

人材不足により内製化が進まない企業が多くなっています²。内製できる体制が無いために委託を選ぶ流れは、書き方を選ぶ判断ごと外部に預ける形につながります。

委託先と内製、それぞれの窓口の違い

新しい書き方を選ぶ判断の置き場所は、委託が中心か内製が中心かによって変わります。iOSとAndroidの両方に出す案件でも、判断の置き場所によって確認する相手が変わります。

外部への委託が中心の事業では、書き方の選定を委託先の判断に委ねる範囲が広がり、変更の窓口も委託先の担当者になります。内製が中心の事業では、社内の技術方針に沿って書き方を選び、窓口も社内に残ります。次の表で、この違いを整理します。

観点	外部への委託が中心の事業	内製が中心の事業
書き方の選定	委託先の判断に委ねる範囲が広くなります	社内の技術方針に沿って選びます
変更の確認先	委託先の担当者が窓口になります	社内の担当者が窓口になります
内製化が進まない背景	外部への委託による開発を行っている事業が4割弱で最も多くなっています1	人材不足により内製化が進まない企業が多くなっています2

どちらの形でも、iOSとAndroidの両方に出すという判断そのものは変わりません。変わるのは、その判断を誰に確認できるかという点です。次の章では、確かめる仕組みの有無について見ていきます。

3. 自動で確かめる仕組みが整っていない前提で考える

仕組みが整っている案件は限られる

確かめる作業を自動でまとめて行う仕組みは、すべての案件に整っているわけではありません。DevOpsやモデルベース開発は、作る側の企業を除くと導入している企業は少ないままです⁴。

アジャイル開発は、一部を含めると全体の2〜4割程度の企業が導入しています⁵。導入している企業が一定数はあるものの、まだ全体には広がっていません。次の図で、この割合を示します。

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」をもとに作成

iOSとAndroidの両方に出す案件を見積るときは、この仕組みが整っている前提を置かないほうが安全です。整っていない場合は、確かめる作業を手作業で行う分の時間を見込みます。

仕組みの有無で、確認の進め方が変わる

確かめる仕組みの有無は、確認の進め方だけでなく、確認にかかる時間にも影響します。iOSとAndroidの両方に出す案件では、この差が見積りに直接響きます。

整っている場合は自動でまとめて確かめられますが、整っていない場合は手作業で個別に確かめることになります。次の表で、この違いを整理します。

観点	整っている場合	整っていない場合
変更後の確認	自動でまとめて確かめられます	手作業で個別に確かめます
導入している企業の状況	アジャイル開発は、一部を含めると全体の2〜4割程度の企業が導入しています5	DevOpsやモデルベース開発は、作る側の企業を除くと導入している企業は少ないままです4
確かめる回数への影響	回数を抑えやすくなります	回数が増えやすくなります

手作業で個別に確かめる進め方は、iOSとAndroidの両方を別々に確認する分だけ、時間がかかります。次の章では、この確かめる回数そのものを見積りの条件に入れる考え方を見ていきます。

4. 確かめる回数を、見積りの条件に入れる

確かめる回数は、品質を優先する姿勢から来る

利用する側の企業は、システムの品質を最も優先する事項として捉えています⁹。iOSとAndroidの両方に出す案件でも、この優先事項は変わりません。iOSとAndroidの両方の画面を、それぞれ確かめる作業が必要になります。

モジュール性やデータモデルを意識した設計に取り組む企業は、依然として少ないままです⁸。設計の段階で共通化が進んでいない案件ほど、確かめる作業は個別に積み重なります。

書く作業を1つにまとめるFlutterの利点は、確かめる作業の回数までは減らしません。次の図で、仕組みがある場合とない場合の違いを示します。

図の作成：Remogu編集部。確認の工程数の違いを整理したもので、統計データではありません

回数を条件として、見積りに含める

確かめる回数は、案件を受ける段階で確認しておきたい条件です。回数が多い前提であれば、その分の時間を見積りに含めます。回数が少ない前提であれば、見積りは短くなります。

見積りを立てるときは、確かめる仕組みが整っているかどうかを、依頼元に確認する場面を作ります。仕組みが整っていない案件ほど、確かめる回数を条件として明記しておくと、後から作業が膨らみにくくなります。

iOSとAndroidの両方に出す案件では、書く作業の見積りよりも、確かめる回数の見積りのほうが、後の負担を左右します。次の章では、内製化を進める案件との違いを見ていきます。

5. 内製化を進める案件と、外部に委託する案件の住み分け

内製化を進める企業は約半数に上る

約半数の企業が、開発の内製化を進めています⁶。内製化を進める案件では、開発の主体が依頼元の社内に残り、確認の窓口も社内に置かれる場面が増えます。

内製化の課題として、人材の確保と新技術への対応を挙げる企業が多くなっています⁷。Flutterのような新しい書き方への対応を、社内だけでまかなえない場面で、外部への委託が選ばれます。

内製化を進める案件と、外部への委託を選ぶ案件は、どちらも一定数あります。次の表で、進め方の違いを整理します。

観点	内製化を進める案件	外部に委託する案件
開発の主体	依頼元の社内が中心になります	案件を任される側が中心になります
内製化の状況	約半数の企業が、開発の内製化を進めています6	内製化を選ばない事業も一定数あります
課題として挙がる点	人材の確保と新技術への対応を挙げる企業が多くなっています7	委託先の選定と確認の体制が課題になりやすくなります

住み分けを見積りに反映する

内製化を進める案件では、依頼元の技術方針に沿って進めることになります。確認のやり取りも、社内の担当者との間で完結しやすくなります。

外部への委託が中心の案件では、委託先の選定や確認の体制そのものが課題になります。案件を受ける側は、この体制がどこまで整っているかを、見積りの前に確認しておきます。

内製化を進める案件か、外部への委託が中心の案件かによって、確認する相手も、確かめる作業の分担も変わります。次の章では、スマートフォンでの使われ方という前提を見ていきます。

6. スマートフォンでの使われ方を、確かめる範囲に反映する

スマートフォンでの利用が中心になっている

端末別に見ると、スマートフォンがパソコンを27.6ポイント上回っています¹⁰。iOSとAndroidの両方に出す案件でも、確かめる作業の中心はスマートフォンでの動きになります。

パソコンでの表示を後回しにするという意味ではありません。スマートフォンでの通知や画面回転、入力の挙動を優先して確かめるという意味です。確かめる順番にも影響します。

使われ方の前提を先に置いておくと、iOSとAndroidの両方で何を優先して確かめるかが決めやすくなります。

生成AIの活用が難しい業務も残っている

生成AIを活用できそうな業務がないという課題が挙げられています³。確かめる作業のすべてを自動化や生成AIで置き換えられるわけではなく、手作業で確認する範囲は残ります。

Flutterの案件で確かめる作業は、iOSとAndroidの両方の挙動を人が見て判断する場面が多く残ります。仕組みが整っている案件でも、最終的な確認は人の手で行われます。

使われ方の前提と、自動化が難しい範囲を合わせて見ておくと、確かめる作業の見積りがぶれにくくなります。次の章では、見積りを進める順番を整理します。

Remoguでは、案件の90%以上がフルリモート可能です。iOSとAndroidの両方に出す案件でも、場所を選ばずに確かめる作業を進められる案件があります。

7. iOSとAndroidの両方に出す案件を見積る順番

確かめる仕組みと内製かどうかを、先に確認する

見積りを立てるときは、まず確かめる仕組みが整っているかどうかを確認します。整っていない場合は、確かめる作業を手作業で行う分の時間を見込みます。

次に、内製化を進める案件か、外部への委託が中心の案件かを確認します。窓口や課題の置き場所が変わるため、確認する相手が変わります。

使われ方の前提を置いてから、回数を見積る

スマートフォンでの使われ方が中心であることを前提に置き、iOSとAndroidの両方で優先して確かめる範囲を決めます。

最後に、確かめる回数を条件として見積りに含めます。回数の前提を先に置いておくと、後から作業が膨らみにくくなります。次の図で、この4つの段階を整理します。

図の作成：Remogu編集部。見積りを進める際に確認する順番を整理したもので、統計データではありません

Flutterの案件は、iOSとAndroidの両方を1人で担当することになりますか

担当する範囲は、案件の体制によって変わります。書く作業と確かめる作業を1人で担当する案件もあれば、確かめる作業を分担する案件もあります。参画前に、担当する範囲を確認しておくと、見積りのずれを防げます。

確かめる仕組みが無い案件では、どのくらい作業が増えますか

増える作業の量は、案件ごとに異なります。iOSとAndroidの両方を別々に確認する工程が増えることは共通しているため、具体的な回数を依頼元に確認しておくと、見積りが立てやすくなります。

内製化を進める依頼元と、外部に委託する依頼元では、進め方に違いがありますか

内製化を進める依頼元では、確認の窓口が社内に残ります。外部への委託が中心の依頼元では、委託先の選定や確認の体制が課題になりやすく、その体制を先に確認しておくと進めやすくなります。

見積りを立てるときに、最初に確認しておきたいことは何ですか

最初に確認しておきたいのは、確かめる仕組みが整っているかどうかです。整っていない場合は、iOSとAndroidの両方を確かめる回数が増える前提で見積りを組みます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「DX動向2025」外に出る仕事（2025年6月・2026年8月確認）
＊2 IPA「DX動向2025」内製の壁（2025年6月・2026年8月確認）
＊3 IPA「DX動向2025」使いどころの不明（2025年6月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」混在する現実（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」内製化の広がり（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊10 総務省「通信利用動向調査の結果」主戦場（2025年5月・2026年8月確認）