モバイルアプリ開発の継続案件にする｜単発で終わらせない

モバイルアプリ開発の継続案件がほしい、という相談は本当に多い。作って納めて終わり、また次のクライアントを探す。この繰り返しに疲れている人が、契約の相談窓口には毎月のように来ます。

結論から言うと、継続案件になるかどうかは、営業努力より契約の設計で決まります。単発で終わる案件は、たいてい「作ること」だけを対象に契約が組まれています。逆に続く案件は、作った後に必ず発生する作業が、最初から契約の視野に入っています。この記事では、モバイルアプリ開発を継続案件に育てるために、受注後に何をどう決めるのかを、契約の実務として整理します。

モバイルアプリは、そもそも継続を前提にした商材である

まず市場の前提を押さえます。この分野で継続案件が作りやすいのは、営業がうまいからではなく、仕事の性質がそうなっているからです。

作って終わりにできない構造がある

モバイルアプリは、公開した瞬間から劣化が始まります。OSは毎年新しい版が出て、古い記述が動かなくなります。証明書には期限があり、切れれば配信が止まります。外部サービスのAPIは仕様が変わり、追随しなければ機能が落ちます。使っているライブラリに脆弱性が見つかれば、更新が必要になります。

これらは事故ではなく、予定された作業です。つまり、誰かが継続的に手を入れる前提でしか成立しない商材だということです。にもかかわらず、発注側も受注側もその前提を共有しないまま「納品」で区切ってしまうから、単発になります。

需要そのものは伸び続けている

分野としての土台も確認しておきます。

モバイルアプリ開発とは、iPhoneやAndroidなどのスマートデバイスで利用されるアプリケーションの開発を指します。企業がモバイルアプリや携帯コンテンツをマーケティングツールとして活かす動きがあり、IT市場で拡大を続けている分野です。昨今スマートフォンやタブレットの爆発的な普及により、モバイルアプリ開発の求人・案件は年々増加傾向にあります。フリーランスとしてアプリ開発へ参画するにはJava/Objective-C/Swiftといった言語を用いた開発経験が必要であり、経験がなくとも「自分自身でアプリを作成し、リリースしている」「数字を意識しながら改修を重ねた」などの実績があると良いでしょう。 出典: freelance.levtech.jp

ここで注目したいのは、実績として評価される要素に「数字を意識しながら改修を重ねた」が挙がっている点です。これ、知らない人が本当に多いのですが、発注側が見ているのは作る力だけではありません。公開した後に手を入れて良くしていける人かどうかを見ています。継続案件は、その姿勢を最初から示している人のところに集まります。

発注側にも継続したい理由がある

依頼する側も、毎回違う相手に頼みたいわけではありません。新しい相手には、事業の背景も既存システムの事情も一から説明しなければならず、その工数は社内では評価されない負担です。同じ相手に頼めるなら、そのほうが楽なのです。

つまり、継続したい気持ちは双方にあります。にもかかわらず続かないのは、続けるための枠組みが用意されていないからです。用意するのは、たいていの場合こちら側の仕事になります。

契約の型を知らないと、継続案件は作れない

ここからが本題です。法律用語が出てきますが、必ず言い換えを添えます。

請負契約と準委任契約の違い

請負契約は、完成した成果物を引き渡す約束です。つまり、アプリが完成しなければ報酬は発生しません。仕事の結果に責任を負う形です。

準委任契約は、決められた業務を行うことに対する約束です。つまり、成果物の完成ではなく、業務の遂行そのものが対象になります。運用や保守、技術支援はこちらの形が自然です。

新規開発は請負、公開後の運用は準委任。この使い分けを知っているだけで、提案の幅が変わります。運用フェーズを請負で受けると、「どこまでやれば完成なのか」が決まらないまま無限に作業が発生します。逆に新規開発を準委任で受けると、発注側から見て完成の保証がないため、警戒されて話が進みません。

契約不適合責任の期間を確認する

請負で納品した後、不具合が見つかった場合の対応義務を契約不適合責任と呼びます。つまり、納めたものが約束と違っていたときに直す責任です。この期間が契約書に書かれているかどうかを必ず確認します。

期間の定めがないまま「不具合は無償対応」と口頭で合意すると、公開から何年経っても無償の修正依頼が来る状態になります。これは継続案件ではなく、ただの持ち出しです。責任の期間を区切ったうえで、その後の対応は有償の保守として組む。この切り分けが、継続案件の出発点になります。

保守契約で決めるべき5項目

保守を継続案件にするなら、次の5つを文章にします。対象範囲、対応時間、連絡方法、月あたりの作業量の上限、範囲外の扱いです。

対象範囲では、何が保守に含まれるかを書きます。「OSの新バージョンへの動作確認と軽微な修正」は含み、「新機能の追加」は含まない、という形です。対応時間は、平日の営業時間内なのか、緊急時の連絡を受けるのかを決めます。ここを決めずに始めると、深夜の連絡に応じる義務があるかのような運用になります。

作業量の上限は、月あたりの時間数で示すのが扱いやすい方法です。上限を超えた分は別途とすることで、双方が予測できる関係になります。※この線引きは相手を疑って作るものではなく、判断に迷う時間をなくすために作るものです。

フリーランス保護新法が継続案件に与えた影響

2024年11月1日に施行された特定受託事業者に係る取引の適正化等に関する法律、いわゆるフリーランス保護新法は、継続案件の実務を大きく変えました。知らないまま損をしている人が本当に多い法律です。

取引条件の明示が義務になった

発注者は、業務委託をした際に、給付の内容、報酬の額、支払期日などを書面または電磁的方法で明示しなければなりません。つまり、口頭だけの発注は法律上認められなくなったということです。

これは受注側にとって強い後ろ盾になります。「条件を書面でいただけますか」と言うことが、以前は角の立つ要求でしたが、今は法律が求めている手続きです。継続案件では条件が曖昧なまま作業だけが増えがちなので、この明示を毎回求める運用にしておくと、範囲の膨張を防げます。

報酬は受領日から60日以内

発注者は、給付を受領した日から起算して60日以内のできる限り短い期間内に支払期日を定め、支払わなければなりません。つまり、「検収が終わってから」を理由に支払いを引き延ばすことはできないということです。

継続案件では、毎月の作業に対する支払いが遅れると資金繰りに直結します。支払期日を契約書に明記し、この法律の基準に沿っているかを確認しておきます。

6か月以上の契約には中途解除の予告が必要

継続的な業務委託、具体的には6か月以上の期間で行う業務委託については、契約を中途解除する場合や更新しない場合、原則として30日前までに予告しなければなりません。つまり、明日から来なくていい、という打ち切り方は認められないということです。

これは継続案件を組むうえで重要な意味を持ちます。6か月以上の契約にしておけば、突然の打ち切りに対する備えが法律上用意されるということだからです。3か月ごとの更新にするか、6か月以上の期間で組むかは、この違いを踏まえて選びます。

※個別の契約が法律の適用対象かどうかは、発注者の従業員の有無など条件によって変わります。判断に迷うケースでは、弁護士や所轄の窓口に相談してください。制度の内容は公正取引委員会や厚生労働省が案内しています。

継続の価値を、作業ではなく予防で示す

保守契約でよく起きるのが、「何もしていないのに払っている」と思われる状態です。トラブルが起きない月ほど、価値が見えにくくなる構造があります。

未然に防いだことを記録する

OSの新しい版が出る前に検証して問題がないことを確認した、外部サービスの仕様変更の通知を受けて事前に対応した、期限が近い証明書を更新した。これらはすべて、やらなければ障害になっていた作業です。

やったことを書かなければ、何も起きなかった月として記憶されます。月次の報告には、対応した作業と併せて「今月確認して問題がなかった項目」を並べます。確認そのものが作業だと伝わる形にします。

数字で追える指標を持つ

アプリの状態を示す指標を決めて、毎月報告に入れます。クラッシュの発生率、起動にかかる時間、主要な画面の表示速度。数値の推移があると、維持されていることが見える形になります。

指標は増やしすぎないほうが続きます。3つ程度に絞り、同じ形式で毎月出すのが実務的です。形式が毎回変わると、比較できずに意味を失います。

次にやるべきことを毎回1つ挙げる

報告の最後に、次の改善候補を1つ書きます。すぐに着手しなくても構いません。継続的に改善案が出てくる相手は、単なる維持要員ではなく、事業を一緒に考える相手として扱われるようになります。

この積み重ねが、保守契約から新規開発の依頼につながる導線になります。継続案件は保守で終わるものではなく、次の開発の入口として機能させるのが本来の形です。

単発案件を継続案件に変える手順

すでに単発で受けている案件を、継続の形に持っていく手順を整理します。タイミングと言い方が重要です。

1つ目に、運用で必要になる作業の一覧を作る

納品の時点で、今後発生する作業を一覧にして渡します。証明書の更新時期、OSの新バージョンが出る時期、外部サービスの契約更新、依存ライブラリの更新方針。期限のあるものには日付を入れます。

この一覧は営業資料ではなく、引き継ぎのための実務文書です。渡された側は、これらを誰が担当するのかを考えざるを得なくなります。社内に担当できる人がいなければ、自然に相談が来ます。

2つ目に、保守の枠を提案する

一覧を渡した流れで、「これらをまとめて対応する形もあります」と提案します。提案のタイミングは納品直後が最適です。時間が経ってから持ち出すと、営業の連絡として受け取られ、通りにくくなります。

提案書には、上で挙げた5項目を書きます。金額の話より先に、何をやって何をやらないかを示すほうが、相手は判断しやすくなります。

3つ目に、最初の期間を短く設定する

いきなり長期の契約を求めると、相手の社内で稟議が通りません。まず3か月の試行期間を置き、その間の実績を見てから継続の判断をしてもらう形にすると、承認のハードルが下がります。

試行期間中は、毎月の報告を丁寧に出します。何に時間を使い、どんな問題を未然に防いだかを記録として残せば、更新の判断材料になります。目に見えない予防作業は、報告しなければ「何もしていない」と評価されます。

4つ目に、更新の条件をあらかじめ決める

契約書に自動更新の条項を入れるかどうかを決めます。自動更新にする場合は、更新しない場合の通知期限を書きます。ここを決めておかないと、更新の話をするたびに気まずい交渉が発生します。

工程全体を通した役割を確認しておきたい場合は、アプリケーション開発のお仕事で開発から運用までの流れを押さえておくと、保守契約の範囲を書くときの語彙が増えます。

知的財産と秘密保持の条項は、継続だからこそ効いてくる

単発の案件では意識せずに通り過ぎる条項も、関係が長くなると効き方が変わります。相談が多いのはこの2つです。

著作権の譲渡範囲を確認する

受託開発の契約では、成果物の著作権を発注者に譲渡する条項が入るのが一般的です。つまり、納めたコードは自分のものではなくなります。ここまでは通常の話です。

問題になるのは、汎用的に使い回している部品まで譲渡対象に含まれてしまう場合です。自作のライブラリや共通処理を案件ごとに再利用している人は少なくありませんが、丸ごと譲渡してしまうと、次の案件で自分の作ったものが使えなくなる可能性があります。

対策は、契約書に「受注者が従前から有していた著作物は譲渡の対象外とし、発注者に使用を許諾する」という趣旨の一文を入れることです。これ、知らない人が本当に多いのですが、申し出れば通ることがほとんどです。発注側が欲しいのは使える状態であって、独占ではないからです。

秘密保持の期間と対象を見る

秘密保持の条項では、期間の定めがあるかを確認します。期間の定めがなく永久に続く形になっている契約も見かけますが、実務上は数年で区切るのが一般的です。

継続案件では、この条項が実績の公開範囲にも影響します。「業務を受託した事実」まで秘密情報に含まれていると、社名どころか業種も出せなくなります。関係が良好なうちに、実績としてどこまで公開してよいかを書面で確認しておくと、後の営業活動が楽になります。

競業避止の条項に注意する

同業他社の仕事を受けられなくする条項が入っていることがあります。範囲と期間が過度に広い場合、こちらの事業活動そのものが制限されます。

継続案件では、この制限が長期にわたって効き続けます。契約前に範囲を確認し、広すぎる場合は限定してもらう交渉をします。※制限の有効性は個別の事情によって判断が分かれるため、実際に問題が生じたときは弁護士に相談してください。

既存アプリの引き継ぎ案件を、継続に育てる

新規開発だけが入口ではありません。他社が作ったアプリの保守を引き継ぐ案件は、最初から継続を前提にできる点で、実は狙い目です。

引き継ぎ時に必ず確認する項目

引き継ぎ案件では、受け取る前の確認が最も重要です。ソースコードが揃っているか、ビルドできる状態か、証明書やストアのアカウントにアクセスできるか、外部サービスの契約と管理権限が誰にあるか。ここが欠けていると、着手した瞬間に動けなくなります。

とくに証明書とストアのアカウントは、前の開発会社が管理したままになっていることがあります。関係が良好でない状態で移管を求めると、話が進まないまま時間だけが過ぎます。移管の完了を作業開始の条件として契約書に書いておくのが安全です。

初回は調査だけを切り出す

引き継いだコードの状態は、開けてみるまで分かりません。この段階で保守の金額を確定させると、想定を超える負債を無償で背負うことになります。

対応としては、最初に調査だけを独立した契約として受けます。数週間かけて構成を把握し、リスクと必要な作業を報告する。その報告をもとに、保守の条件を決める流れにします。この進め方は発注側にとっても合理的で、提案すれば通りやすい形です。

現状を可視化して渡す

調査の結果は、技術用語を使わない形で報告します。「このライブラリは開発が止まっており、次のOS更新で動かなくなる可能性があります」「テストが書かれていないため、修正のたびに手動確認が必要です」といった書き方です。

この報告は、発注側が社内で予算を取るための材料になります。材料を作れる人は、その後の作業も任される流れになります。改修の必要性を説明できるかどうかが、継続案件になるかどうかの分かれ目です。

継続案件でトラブルになりやすい場面

相談の現場で繰り返し見るトラブルを挙げます。どれも事前の一文で防げるものばかりです。

保守の範囲が少しずつ広がる

最も多いのがこれです。最初は軽微な修正だけだったはずが、いつのまにか新機能の追加まで含まれている。断りにくい空気ができあがっていて、言い出せないまま作業だけが増えていく。

防ぐには、範囲外の依頼が来た時点で、その場で「これは別途のお見積もりになります」と伝える運用にします。一度受けてしまうと、次から断る理由がなくなります。最初の1回で線を引くのが、結局いちばん角が立ちません。

緊急対応の扱いが決まっていない

アプリが起動しなくなった、決済が通らない、といった障害は、時間を選ばずに起こります。夜間や休日の対応をどう扱うかを決めていないと、無償で駆けつける前提ができあがります。

対応時間を契約に書き、時間外の対応は別料金とするか、そもそも対応しないかを明示します。決めていないことは、いつも受注側が引き受ける形になります。

担当者が変わって経緯が失われる

継続案件で怖いのは、発注側の担当者の異動です。新しい担当者は、なぜこの契約があるのかを知りません。「外注費を見直せ」と言われた際に、真っ先に削減候補に挙がります。

対策は、毎月の報告を文書で残しておくことです。何を防ぎ、何を維持しているかの記録があれば、新しい担当者にも説明できます。口頭の信頼関係は、人が変われば消えます。

契約書がないまま長期化する

口頭の合意で数年続いている案件は、いまだにあります。うまくいっている間は問題になりませんが、揉めた瞬間に何も証明できません。前述のとおり、取引条件の明示は法律上の義務でもあります。

書面を求めることは、相手を疑う行為ではありません。※既存の関係で書面がない場合も、「法律の要件を満たすため」という理由で切り出せば、角を立てずに整えられます。契約書や報告書の基本的な書式を確認しておきたい場合は、ビジネス文書検定で扱われる文書構成の考え方が実務でも使えます。

稟議を通す側の事情を理解する

継続の提案が通らない理由の多くは、内容ではなく社内手続きにあります。担当者が納得していても、社内で説明できなければ予算は付きません。

決裁のタイミングに合わせる

多くの企業では、予算の枠が期ごとに決まっています。期の途中で新しい支出を追加するのは手続きが重く、通りにくくなります。提案を出すなら、次の期の予算を検討する時期に合わせるほうが確実です。

担当者に「予算はいつ頃決まりますか」と聞けば、たいてい教えてもらえます。この一言を聞いているかどうかで、提案の通過率が変わります。

担当者が上司に説明できる資料を渡す

提案書は、担当者が読むためのものではなく、担当者が上司に見せるためのものです。技術的な妥当性より、やらなかった場合に何が起きるかを書きます。「証明書が切れると配信が停止し、新規のインストールができなくなります」という書き方は、決裁者にも意味が伝わります。

逆に、フレームワークの選定理由やコードの品質の話は、決裁の場では判断材料になりません。相手の社内で流通する言葉に翻訳するのが、提案の実務です。

比較できる形にする

内製する場合、他社に頼む場合、何もしない場合。この3つと並べた形で提示すると、判断がしやすくなります。自分の提案だけを出すと、比較対象がないため「検討します」で止まります。

正直なところ、この手間を惜しんで提案が流れる例をよく見ます。提案の中身は良いのに、社内で動かせる形になっていない。継続案件は、相手の社内政治まで含めて設計するものだと考えたほうが実態に合います。

運営者として見てきた、続く案件の共通点

在宅ワークと業務委託の市場を20年見てきた立場から言えば、継続案件を安定して持っている人は、契約の話を早い段階で持ち出すことをためらっていません。関係ができてから話そうとする人ほど、いつまでも単発のままです。

理由ははっきりしています。条件を決めない状態は、発注側にとっても不安だからです。どこまで頼めるのか分からない相手には、大きな仕事を任せられません。範囲と条件を先に示す人は、任せる側から見て安心できる相手になります。

もうひとつ、報酬の構造についても触れておきます。仲介手数料が乗らない直接の取引では、依頼する側は同じ予算でより多くの工程を頼めますし、受ける側は手元に残る金額が厚くなります。手数料0%の取引が長期の関係で効いてくるのは、この差が毎月積み重なるからです。運営者として見てきた限りでは、継続案件を複数持っている人ほど、仲介を挟まない直接の関係に移行しています。契約書を自分で整えられることが、その移行を支えています。

職種としての位置づけや、どの工程まで担当できると評価が変わるかは、ソフトウェア作成者の年収・単価相場で市場全体の傾向を確認しておくと、契約範囲を決めるときの判断材料になります。周辺領域まで受けられる体制を作りたい場合は、AI・マーケティング・セキュリティのお仕事で近接する需要の形を見ておくと、保守の枠に含められる作業の幅が広がります。

継続案件を複数持つための設計

最後に、案件を1本に依存しない形について書きます。継続案件は安定をもたらしますが、1社に集中すると別のリスクが生まれます。

1社の売上比率が高くなりすぎると、その契約が終わったときの打撃が大きくなります。また、実質的に指揮命令を受ける働き方になっている場合、業務委託ではなく雇用に近いと判断される可能性が出てきます。※契約の形と実態が乖離していると、後から問題になることがあります。判断に迷う場合は専門家に相談してください。

複数の継続案件を持つには、対応時間が重ならない組み方をします。常時の即応を約束する契約は1本までにして、他は月次の定例作業を中心にする、といった設計です。すべてに即応を約束すると、どこかで破綻します。

長い目で働き方を組み立てるなら、年齢や生活の変化を織り込んだ設計も必要になります。定年後のフリーランス独立｜退職金を活かした起業プランと注意点では、長期の視点で仕事の形を選ぶ考え方が整理されています。継続案件は、収入を安定させる手段であると同時に、働き方を自分で設計するための土台でもあります。契約は、その設計図にあたるものです。法律も契約書も、使い方を知っていれば自分を守る味方になります。

よくある質問

Q. 新規開発と保守で、契約の形は変えるべきですか？

変えるのが実務的です。完成した成果物を引き渡す新規開発は請負契約、公開後の運用や技術支援は準委任契約が自然な形です。運用を請負で受けると完成の定義が決まらず作業が際限なく発生し、新規開発を準委任で受けると発注側が完成の保証を得られず話が進みにくくなります。

Q. 保守契約には何を書けばよいですか？

対象範囲、対応時間、連絡方法、月あたりの作業量の上限、範囲外の扱いの5項目です。「OSの新バージョンへの動作確認と軽微な修正は含む、新機能の追加は含まない」のように、含むものと含まないものを両方書きます。上限を時間数で示すと、双方が予測できる関係になります。

Q. フリーランス保護新法で、継続案件の何が変わりましたか？

取引条件を書面または電磁的方法で明示することが発注者の義務になり、報酬は給付の受領日から60日以内に支払う必要があります。また6か月以上の継続的な業務委託では、中途解除や不更新の際に原則30日前までの予告が必要です。個別の適用可否は条件によるため、迷う場合は専門家に相談してください。

Q. 単発の案件を継続に変えるタイミングはいつですか？

納品直後が最適です。今後発生する運用作業の一覧を渡し、その流れで「まとめて対応する形もあります」と提案します。時間が経ってから持ち出すと営業の連絡として受け取られます。最初は3か月程度の試行期間から始めると、相手の社内で承認が通りやすくなります。

Q. 保守の範囲が広がってしまったときはどうしますか？

範囲外の依頼が来た時点で、その場で別途見積もりになると伝えます。一度受けてしまうと次から断る理由がなくなり、無償の作業が定着します。既存の関係で線引きが崩れている場合は、契約更新のタイミングで範囲を書き直すのが自然です。書面で範囲を示せば、担当者が変わっても引き継がれます。