Swiftの案件と聞くと、新しいアプリをゼロから作る仕事をイメージしがちです。ところが案件情報を見渡すと、公開済みのアプリを端末の変化に合わせ続ける保守の仕事が土台になっています。使う人の年齢層や端末の入れ替わり方をたどると、その比重の理由が見えてきます。この記事では、追従の作業がなぜ中心になるのかと、年間の稼働をどう組み立てるかを整理します。

1. 新規より追従が土台になる

公開後の期間の方がはるかに長く続く

Swiftで書かれたアプリの多くは、公開してからの期間の方がはるかに長く続きます。新しい機能を足す局面よりも、端末やOSの更新にアプリを合わせ続ける局面のほうが、稼働している時間として長くなりやすい構造です。案件を受ける側から見ると、最初の開発フェーズだけを見て契約条件を決めると、その後の追従作業の見立てが甘くなりやすい点に注意が向きます。

追従の作業は、画面を作り直すような目立つ工程ではありません。表示の崩れを直したり、外部のライブラリの更新に合わせて挙動を確かめたりする、地味だが途切れない工程です。ここを軽く見積もると、稼働時間の配分が後になって窮屈になります。

契約の初期段階でこの構造を共有しておくと、稼働期間の見立てのずれを防ぎやすくなります。最初の開発だけを基準に条件を決めると、公開後の稼働がどこかで圧縮されやすくなります。

保守が中心になる案件では、開発当初の設計判断が後々の作業量を左右します。仕様を決める段階で変更の見込みを共有しておくと、追従の作業も進めやすくなります。

保有の割合が積み上がっている基盤

世帯でスマートフォンを保有する割合は90.5%です¹。この数字は、アプリを使う環境がすでに家庭の大半に行き渡っていることを示しています。新しく市場を切り開く段階ではなく、行き渡った環境を維持し続ける段階に、Swiftの案件の重心が移っていると読み取れます。

個人でスマートフォンを保有する割合は80.5%で、しかも増加傾向にあります²。土台がすでに大きいうえに、まだ広がり続けているという二重の事情が、追従の作業を途切れさせにくくしています。基盤が縮む気配がない以上、保守の比重は当面続く前提で考えたほうが実情に近づきます。

基盤の大きさは、案件が続く期間の長さにも表れます。保有割合が高い状態がこの先も続くとすれば、追従の作業を前提にした契約の形が標準になっていく可能性があります。稼働の見通しを立てる際は、この基盤の大きさを起点に考えると整理しやすくなります。

使う人の裾野が広く、しかも増え続けているとなると、次に気になるのはその裾野がどの年齢層まで及んでいるかです。触れる人の幅を確かめておくと、保守の中で気を配る範囲もつかみやすくなります。

図の作成：Remogu編集部。契約が続く期間の進み方に応じて、作業の重心がどちらに寄りやすいかを整理したもので、統計データではありません

2. 触れる人の幅が広い

20代から50代の各年齢階層でほぼ横並びに使っている

スマートフォンの使用は、20〜59歳の各年齢層で9割に達しています⁴。年齢による差がほとんど無いという点が、Swiftの案件で扱う画面の幅を広げています。特定の年齢層だけを想定した作り方では、想定外の使われ方に対応しきれない場面が出てきます。

この横並びの使い方は、画面サイズや操作の好みが年齢層の中でも割れやすいことを意味します。年代で一括りにできない前提に立つと、保守の中で確認するパターンが自然と増えます。

働き盛りの年代がまとまって使っているということは、業務の合間に短く操作する使い方から、腰を据えて長く操作する使い方まで、同じアプリの中に混在する前提で保守を進める必要があるということでもあります。

操作に慣れている度合いも、年齢層の中で揃っているとは限りません。表示速度や反応の軽さへの感じ方に差が出やすく、保守で確認する範囲がさらに広がります。

60代でも使用が広がっている

60〜69歳の年齢層でも、約8割がスマートフォンを使用しています⁵。現役世代だけでなく、その少し上の年代にも使う人の裾野が伸びている状態です。端末の操作に慣れた度合いにも幅があるため、表示の見やすさや操作のわかりやすさへの配慮が、保守の中でも軽視できない項目になります。

年齢層による違いを見落とすと、一部の年代でだけ不具合が起きているように見える現象にもつながります。年齢層を分けて確認する視点を保守の手順にあらかじめ組み込んでおくと、原因の切り分けにかかる時間を抑えられます。

年齢層ごとの使用割合を並べてみると、極端な谷が見当たりません。以下の比較で、その幅を確認します。

年齢層	スマートフォンの使用状況	保守で意識する範囲
20〜59歳	各年齢層で9割が使用4	短い操作から長い操作まで幅広い使われ方が混在する
60〜69歳	約8割が使用5	文字の大きさや操作のわかりやすさへの配慮が求められやすい

年齢層をまたいで使われているという構造は、Swiftの案件を受ける側にとって、対象を絞り込みにくいことの裏返しでもあります。次に見ていくのは、この幅の広さが端末の入れ替わり方にどうつながっているかです。

出典：総務省「通信利用動向調査の結果」（2025年5月）をもとに作成

3. 古い端末を切り捨てにくい構造

旧型の携帯電話は減っているが、なくなってはいない

スマートフォン以外の携帯電話を保有する割合は16.8%で、減少傾向にあります³。数字だけを見ると、対応の優先度を下げてよいように感じられますが、なくなっていない以上、対応を完全にやめる判断は取りにくい状況です。

保守の現場では、使う人が少数派になった端末や環境をどこまで支え続けるかという線引きが、契約のたびに議論になります。減少傾向という事実は、線引きを緩めてよい根拠にはなっても、対応をやめてよい根拠にはなりにくい点に注意が向きます。

残された少数派の環境にどこまで手をかけるかは、契約の範囲としてあらかじめ決めておきたい項目です。曖昧なままにしておくと、後から対応の解釈がずれる原因になり、稼働の見立てにも影響します。

この傾向は急に反転するものではないため、当面は少数派の環境への配慮を残したまま、優先度だけを段階的に下げていく進め方が現実的です。

パソコンとの差が、画面設計の基準を動かしている

スマートフォンの利用率はパソコンを27.6ポイント上回っています¹⁰。この差は、画面をどちらの環境を基準に組み立てるかという判断に直結します。パソコンでの見え方を優先して調整すると、実際に使われている環境とずれた確認になりかねません。

出典：総務省「令和7年版 情報通信白書（デジタル活用の動向）」（2025年7月）をもとに作成

以下の比較で、端末ごとに何を優先して確認しているかを整理します。

端末の種類	保有・利用の傾向	保守で意識する点
スマートフォン以外の携帯電話	保有割合16.8%で減少傾向3	対応の優先度は下げつつ、配慮は残す
パソコン	スマートフォンに27.6ポイントの差をつけられている10	画面設計の基準をスマートフォン側に置く

古い端末を残す判断とパソコンより先にスマートフォンを見る判断は、どちらも切り捨てにくさから来ています。次に確かめるのは、この配慮を積み重ねる作業が年間のどこに集中しているかです。

4. 追従の作業は年間のどこに来るか

作業のタイミングは事前に読みにくい

DevOpsやモデルベース開発は、作る側の企業を除くと導入している事業者が少ない状況です⁸。開発の進め方を仕組みで管理する土台が薄いままだと、追従の作業がいつ発生するかを事前に読み切るのが難しくなります。

仕組みが整っていない現場では、更新への対応が気づいたときに動く形になりやすく、稼働の予定を立てにくい状態が続きます。受ける側としては、この読みにくさを前提に、稼働の枠にあらかじめ余裕を持たせておく判断が必要になります。

読みにくさをそのままにしておくと、繁忙期が重なったときに対応が後手に回ります。契約の段階で、想定外の追従作業が発生した場合の扱いを合わせておくと、この読みにくさをある程度吸収できます。

稼働の予定が立てにくい状態が続くと、他の案件との調整も難しくなります。余裕を見込んだ稼働の枠は、複数の案件を並行して受ける際の土台にもなります。

事前に読み切れない前提に立つと、契約の更新時期や見直しのタイミングも合わせて相談しやすくなります。読みにくさを個人の見通しの甘さとして扱わず、構造として共有しておくことが大切です。

外部サービスへの不安が、確認の手間を増やす

外部のサービスについて、保守や運用に不安を抱える事業者が多い状況です⁷。自社で完結しない部分が絡む案件ほど、更新の影響がどこまで及ぶかを確かめる工程が増えます。

この不安は、外部サービス側の変更を受ける側が把握しきれないまま案件を進めてしまうことから来ています。連携している範囲を洗い出しておくことが、影響範囲を見誤らないための土台になります。

確認する範囲が広がるほど、記録を残しておく重要性も増します。何を確かめて何が変わらなかったかを残しておくと、次の更新のときに同じ確認を繰り返さずに済みます。

タイミングが読みにくいことと、外部への不安が重なると、確認の作業は自然と積み上がります。次に見るのは、その確認が現場で実際にどこまで自動化されているかです。

5. 自動で確認が回っていない現場

自動化はまだ限られた事業者のものである

DevOpsやモデルベース開発の導入は、作る側の企業を除くと少ない状況です⁸。確認の工程を仕組みで回す土台が薄い現場では、更新のたびに人が手を動かして確かめる部分が残ります。

確認が人手に残っている現場ほど、更新の対応が担当者の経験に依存しやすくなります。受ける側の立場では、その経験をどう積み上げるかが、次の案件を選ぶときの材料にもなります。

自動化が進んでいない状態は、悪いことばかりではありません。人が確かめる分だけ、細かい違和感に気づける場面もあります。ただし、その分だけ稼働の時間を確保しておく必要があります。

確認の手順が言語化されていない現場では、担当者が変わるたびに同じ確認をやり直す場面も出てきます。受ける側が手順を整理しておくこと自体が、案件の中での役割になることもあります。

確認の頻度も、自動化の有無によって変わります。手作業の比重が大きい現場ほど、更新のたびに時間を要しやすく、稼働の配分にもその分の余裕を織り込んでおく必要があります。

リスク管理と業務継続の整備状況にも差がある

ITのリスク管理と業務継続計画は、全体の5〜6割程度の企業が整備しています⁹。裏を返せば、整備が進んでいない現場も一定数残っているということです。

整備の有無によって、更新への対応が計画的に進むか、その都度の対応になるかが変わります。以下の比較で、整備状況ごとに何が変わるかを整理します。

観点	現場で挙がっている傾向	案件で確認したい内容
自動化・モデルベース開発	作る側の企業を除くと導入は少ない8	確認作業が人手に残っていないか
リスク管理・業務継続計画	全体の5〜6割程度が整備9	整備の有無で稼働の内容がどう変わるか

自動化と整備の状況は、案件によって大きく違います。契約の前にどちらの状態に近いかを確かめておくと、稼働の見立てがぶれにくくなります。次に見るのは、こうした状況の背景にある守りの前提です。

6. 守りの前提として挙がっているもの

リモートワークの環境を狙う動きが挙がっている

リモートワークの環境や仕組みを狙った攻撃は、情報セキュリティの脅威の一覧で8位に挙げられています⁶。案件の多くがオンラインでのやり取りを前提にする以上、この動きは受ける側にとっても他人事ではありません。

端末や利用環境を自分で選べる分、守りの水準も自分の判断に委ねられる部分が大きくなります。クライアントと協議しながら、最低限そろえておく環境の条件を確認しておくと、後から慌てずに済みます。

脅威の一覧に挙がっているという事実は、対策を怠ってよい理由にはなりません。むしろ、案件を受ける前に確認しておきたい項目として扱うほうが実情に合っています。

守りの前提を確かめる際は、端末や利用環境の管理方法だけでなく、連絡や共有の手段についても合わせておくと安心です。想定外の事態が起きたときの連絡経路まで決めておくと、対応が早くなります。

守りの前提を早めに把握しておくと、稼働の配分を決める段階での手戻りも減らせます。契約の後になって条件を確認し直す手間を、事前の一手間で防げます。

整備の有無が、任される範囲を左右する

ITのリスク管理と業務継続計画は、全体の5〜6割程度の企業が整備しています⁹。整備が進んでいる事業者ほど、確認の手順があらかじめ決まっており、任される範囲も明確になりやすい傾向があります。

反対に、整備がこれからの事業者では、確認の手順そのものを一緒に組み立てる場面も出てきます。どちらの状況であっても、守りの前提がどこまで整っているかを早い段階で把握しておくことが、稼働の見通しにつながります。

守りの前提を確かめる作業は、追従の保守と切り離せません。最後に、ここまでの内容を踏まえて、年間の稼働をどう決めていくかを整理します。

7. 年間の稼働の置き方を決める順番

見積もりと体制の確認を先に済ませる

外部のサービスについて保守や運用に不安を抱える事業者が多い状況です⁷。この不安を放置したまま契約を進めると、想定外の確認作業が後から積み上がります。まず、連携している外部サービスの範囲を洗い出すところから始めます。

次に、DevOpsやモデルベース開発のような仕組みが、どこまで導入されているかを確認します⁸。仕組みが薄い現場ほど、人が確かめる作業の分を稼働の枠にあらかじめ組み込んでおく必要があります。

図の作成：Remogu編集部。年間の稼働を組み立てる際に確認したい順番を整理したもので、統計データではありません

確認した内容を稼働の配分に落とす

見積もりと体制の確認が終わったら、その内容を年間の稼働の配分に反映します。追従の作業が集中しやすい時期があらかじめわかっていれば、その時期の稼働を厚めに確保しておけます。

Remoguでは、案件の90%以上がフルリモート可能です。場所を選ばずに稼働できる分、確認や連絡のタイミングを事前にすり合わせておくことが、離れた場所からでも進めやすい保守につながります。

稼働の配分を決める作業は、一度で終わるものではありません。案件の状況が変われば、確認した内容を見直す機会も出てきます。

契約前の確認を丁寧に行うほど、稼働を開始してからの調整がスムーズになります。最初に手間をかけておくことが、後の稼働のしやすさにつながります。

確認する順番を決めておけば、案件ごとに条件を比べる基準がぶれません。自分の稼働に合う条件かどうかを見極めるところから、次の一歩を考えてみます。

Swiftの案件は新規開発より保守が多いのですか

案件全体を見渡すと、公開済みのアプリを端末の変化に合わせ続ける保守の比重が大きくなりやすい構造です。スマートフォンを保有する世帯の割合は90.5%に達しており¹、新しく市場を広げる段階よりも、行き渡った環境を維持する段階に重心が移っています。

古い端末への対応はどこまで必要ですか

スマートフォン以外の携帯電話を保有する割合は16.8%で、減少傾向にあります³。なくなっていない以上、対応を完全にやめる判断は取りにくく、優先度を段階的に下げながら配慮を残す進め方が現実的です。

追従の作業に、どれくらいの稼働を見ておけばよいですか

具体的な時間の目安は案件によって異なりますが、DevOpsのような仕組みの導入が作る側の企業を除くと少ない状況にあるため⁸、確認の作業が人手に残りやすくなります。契約前に体制を確認し、その分の余裕を稼働の配分に組み込んでおくと見通しが立てやすくなります。

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

出典・参考情報

＊1 総務省「通信利用動向調査の結果」世帯の保有（2025年5月・2026年8月確認）
＊2 総務省「通信利用動向調査の結果」個人の保有（2025年5月・2026年8月確認）
＊3 総務省「通信利用動向調査の結果」残っている端末（2025年5月・2026年8月確認）
＊4 総務省「通信利用動向調査の結果」働く層の利用（2025年5月・2026年8月確認）
＊5 総務省「通信利用動向調査の結果」上の年齢層（2025年5月・2026年8月確認）
＊6 IPA「情報セキュリティ10大脅威 2026」働く場所の穴（2026年1月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）
＊10 総務省「令和7年版 情報通信白書（デジタル活用の動向）」使う道具の偏り（2025年7月・2026年8月確認）