アプリ開発のもう一度頼まれる人｜次に繋がる終わり方

アプリ開発で次の依頼が来るかどうかは、作ったものの出来だけでは決まりません。実務で相談を受けていて感じるのは、リピートされる人とされない人の差が、納品の前後の数週間に集中しているということです。これ、知らない人が本当に多いんです。この記事では、アプリ開発でもう一度頼まれる人が終盤に何をしているかを、手順と契約の両面から整理します。

次の依頼が決まるのは納品の直前ではない

終わり方の話に入る前に、前提を整理します。リピートは終盤の努力だけで作られるものではありません。

継続の判断材料は工程の途中で積み上がる

発注者が「またこの人に頼もう」と考えるとき、判断しているのは成果物の出来だけではありません。連絡の速さ、範囲の説明の仕方、問題が起きたときの伝え方。これらは工程の途中で積み上がっていて、納品時にまとめて評価されます。

つまり、終盤で挽回しようとしても限界があります。逆に言えば、途中の進め方が丁寧であれば、終わり方を整えるだけで次に繋がります。この記事で扱うのは、その「整え方」です。

新しい依頼者を探すより、既存の関係を続けるほうが軽い

継続を意識する理由は、単に楽だからではありません。関係が続いている相手との仕事は、前提の説明が不要な分だけ進行が速く、要件の食い違いも起きにくくなります。

一方で、リピーターは既に企業や店舗のサービス・商品に興味を持ち、購買経験があるため、新規顧客ほど集客コストがかかりません。 出典: iridge.jp

これは事業者と顧客の関係についての指摘ですが、発注者と受注者の関係にもそのまま当てはまります。相手の事業を理解している人に頼むほうが、説明の手間が省けるからです。

途中の進め方が終わり方を決める

終盤の整理を効かせるには、その手前の進め方が土台になります。ここで崩れていると、終わり方だけ整えても評価は戻りません。

進捗報告は決まった曜日に、決まった形で出す

報告の内容より、報告が来る予測がつくことのほうが重要です。毎週決まった曜日に、決まった形式で報告が届くと、発注者は社内での説明を予定に組み込めます。

形式は三つの項目で足ります。今週やったこと、来週やること、判断をお願いしたいこと。三つ目を毎回書くのがコツで、判断待ちの項目が可視化されると、発注者側の動きが速くなります。判断が要らない週は「今週はありません」と書きます。

悪い知らせほど早く出す

遅れそうなとき、想定より難しいと分かったとき、外部サービスの仕様が想定と違ったとき。これらを抱え込む人は多いのですが、遅らせるほど選択肢が減ります。

早く出せば、範囲を減らす、優先順位を変える、期限を調整するという選択肢が残ります。直前に出すと、どれも選べません。悪い知らせを早く出す人は、結果として「管理できる人」という評価になります。伝えるときは、事実と、こちらが考えている対応案をセットにします。案があると、相談になります。

決まったことを文書に残し続ける

打ち合わせや連絡のたびに決まったことを短く残し、相手に確認します。この積み重ねが、終盤で効きます。検収の段階で認識の食い違いが出たとき、決まったことの記録があれば、感情の話にならずに済むからです。

記録は完璧な議事録である必要はありません。決まったこと、宿題、保留の三つが分かれていれば十分です。

納品前の一週間でやること

終盤の作業は、実装ではなく整理が中心になります。ここを飛ばすと、納品後に問い合わせが集中します。

検収の基準を先に共有する

納品物を提出する前に、何をもって合格とするかを文書で共有します。基準がないまま提出すると、感想ベースの差し戻しが続きます。

基準は、合意した機能一覧の動作が確認できることに置きます。あわせて、確認していただきたい項目を一覧にして渡します。項目が示されていると、発注者側も何を見ればよいかが分かり、検収が早く終わります。

検収の期間も明示します。提出から何日以内に確認いただくか、期限内に返答がない場合はどう扱うか。この二点を書いておくと、検収が長引いて支払いが遅れる展開を防げます。

残っている課題を隠さず一覧にする

完璧な状態で納品できることは稀です。既知の不具合、制約、未実装の部分がある場合、隠さずに一覧にして渡します。

隠すと、後で発見されたときに信頼を失います。先に出しておけば、それは「把握して管理できている」という評価になります。一覧には、影響の範囲と、対応するかどうかの提案を添えます。対応するなら時期を、しないなら理由を書きます。

引き継ぎ資料を作る

引き継ぎ資料は、次の依頼が来るかどうかを大きく左右します。逆説的ですが、他の人でも引き継げる状態にしておくほど、指名される確率は上がります。

理由は、引き継げない作りにすると発注者がリスクを感じるからです。作った本人にしか触れないアプリは、その人が対応できなくなった瞬間に事業が止まります。この不安を抱えた発注者は、次の案件で別の相手を探し始めます。

資料に含めるのは、構成の概要、データの持ち方、外部サービスとの連携先、環境の構築手順、リリースの手順、注意点です。分量は多くなくて構いません。読めば作業を再開できる状態であれば十分です。

納品時に渡すもの

納品は、ファイルを送って終わりではありません。渡すべきものを整理します。

成果物と権利の整理

ソースコード、ビルド済みのファイル、設計資料、テストの結果。何を渡すかは契約で決めた範囲に従います。

あわせて、権利の状態を文書で確認します。今回作った部分の権利がどう扱われるのか、汎用的な部品について使用許諾の形にしているのか。曖昧なまま終わると、次の依頼のときに前提が食い違います。※譲渡の範囲について争いが生じそうな場合は、早い段階で弁護士に相談してください。

アカウントと権限の移管

ストアの開発者アカウント、外部サービスの管理画面、サーバーの権限。誰の名義で、誰が管理するのかを整理して引き渡します。

ここを曖昧にしたまま終わると、後で困るのは双方です。発注者は自分の資産を管理できず、受注側は関係が終わった後も権限を持ち続けることになります。移管の手順と、移管が完了した日付を記録に残してください。

運用の手順書

日常的に発生する操作の手順を、簡単でよいので文書にします。データの確認方法、内容の更新方法、問い合わせが来たときの確認箇所。

この手順書があると、発注者からの細かい問い合わせが減ります。問い合わせが減ることは、関係が薄くなることではありません。むしろ、些細な連絡で消耗しない関係のほうが長く続きます。

納品物の名前と置き場所をそろえる

細かい話に見えますが、渡すファイルの名前と置き場所が整っているかどうかで、受け取る側の印象は変わります。日付や版数が分かる名前になっているか、どれが最新なのかが一目で分かるか。

受け取った側は、数か月後にそのファイルを探すことになります。そのときに迷わない状態で渡しておくと、次に連絡が来たときの話も速く進みます。逆に、名前が不揃いのまま渡すと、後から「どれが正しいのか」という問い合わせが発生します。

相手の社内で説明できる形にする

納品物を受け取る担当者は、社内で報告する立場にあります。技術的に正確でも、社内で説明できない形だと担当者が困ります。

対策として、納品時に一枚だけ、専門用語を使わない概要の資料を添えます。何ができるようになったか、今後どう運用するか、誰に聞けばよいか。この三点が書かれた資料は、担当者が社内で使う道具になります。担当者の立場を助ける人は、次も指名されます。

検収と支払いを気持ちよく終える

お金の話を最後まで曖昧にしておくと、関係そのものが気まずくなります。

支払期日には法律上の定めがある

フリーランス保護新法では、発注者は成果物を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定め、その期日までに報酬を支払う義務があります。つまり、検収が終わらないことを理由に受領から60日を超えて引き延ばすことは認められません。

この知識は、揉めるために使うものではありません。最初に条件を決めるときの根拠として使います。「法律上こうなっているので、この形で条件を整えさせてください」と最初に伝えておけば、後で督促する場面自体がなくなります。

検収中に出てきた要望の扱い

検収の段階で新しい要望が出るのは自然なことです。ここでの対応が、次に繋がるかどうかを分けます。

判断の基準は、合意した機能一覧に書かれた動作を実現するための作業かどうかです。書かれた動作を満たすための修正は、こちらの責任範囲として対応します。書かれていない動作を足すのは仕様変更なので、別途の見積もりとして扱います。

このとき、断る形にしないことが重要です。「今回の範囲ではありませんが、次のフェーズでこう実現できます」という形にすると、要望が次の案件の入口になります。実際、検収時に出た要望が次の発注に繋がる例は多くあります。

請求と、その後の確認

請求書を送ったら、入金予定日を確認します。入金が確認できたら、その旨を短く連絡します。この一往復があるだけで、事務的な印象が変わります。

納品後にやること

納品して連絡が途絶える人は、次に呼ばれません。かといって、営業の連絡を頻繁に送るのも逆効果です。

稼働の状況を一度確認する

納品から少し経ったタイミングで、状況を確認する連絡を入れます。内容は営業ではなく、動作の確認です。「実際にお使いになってみて、動作で気になる点はございませんか」という形にします。

この連絡には二つの意味があります。ひとつは、初期の不具合を早く見つけられること。もうひとつは、相手の中に「気にかけてくれている」という印象が残ることです。

初期不具合の対応範囲を明確にしておく

納品後に見つかった不具合の対応は、どこまでが無償かを事前に決めておきます。合意した仕様どおりに動かない場合の修正は、契約不適合として受注側の責任範囲です。一方、OSの更新に伴う対応や、新しい機能の追加は別の作業です。

この線引きを納品時に文書で共有しておくと、後の対応が揉めません。線引きがないと、すべての連絡が「直してほしい」という要求に見えてしまいます。

改善の提案は観察から始める

しばらく運用が続いたら、改善の提案ができるようになります。ただし、提案は思いつきではなく観察から始めます。

観察の材料は、利用の状況、問い合わせの内容、運用で手間になっている作業です。「この操作で問い合わせが多いようでしたら、画面をこう変える方法があります」という形の提案は、押し売りになりません。

段階的に育てる前提で終わる

一度で完成させようとせず、段階的に育てる前提で組み立てると、終わり方が自然に次へ繋がります。

最初から全部を作らない設計

必要最小限の機能で出し、運用しながら追加していく進め方は、発注者にとってもリスクが小さくなります。

ハイブリッド型アプリ開発サービスの代表である「ModuleApps 2.0」では、最低限の機能から始めてみて、運用しながら機能を追加したり、カスタマイズしたり……という動き方も可能なため、アプリを初めて導入するという方にもおすすめです。 出典: moduleapps.com

この進め方を最初の打ち合わせで提案しておくと、一回目の納品が「区切り」であって「終わり」ではなくなります。次のフェーズの話が自然に出ます。

次のフェーズの設計図を置いていく

納品時に、今回入れなかった機能と、それを入れる場合の考え方をまとめた資料を渡します。金額は書かず、内容と順番だけを整理したものです。

この資料は、発注者が社内で次の予算を取るときの材料になります。予算が取れたときに真っ先に相談が来るのは、この資料を作った人です。

検証しながら進める形を提案する

画面や操作が重要なアプリでは、作り込む前に触れる形を用意して確認する進め方が有効です。

プロトタイプ開発は、早い段階で試作品を作成し、実際に触りながら検証を進める手法です。完成形を文章や資料だけで共有するのではなく、画面や動きを確認しながら認識をそろえられるのが特徴です。 出典: i3design.jp

この進め方を経験した発注者は、次の案件でも同じ形を求めます。進め方そのものが、指名の理由になります。

保守を提案するタイミングと形

継続の最も分かりやすい形が保守契約です。ただし、提案の時期を間違えると押し売りに見えます。

提案するのは開発の見積もりの段階

保守の話は、納品後ではなく開発の見積もりを出す段階で触れておきます。開発の見積書に「保守は含みません」と明記し、別の見積もりとして保守の案を添えます。

この順番にすると、納品後の提案が「約束していた話の続き」になります。納品後に初めて保守の話を出すと、後出しに見えてしまいます。

受け方は三通りある

月額で一定の対応を受ける形、時間単位で発生した分だけ受ける形、都度見積もる形。この三つを提示し、発注者に選んでもらいます。

選択肢を出すと、発注者は「どれにするか」を考えます。ひとつの案だけを出すと、「やるかやらないか」を考えます。前者のほうが決まります。

何を含むかを具体的に書く

保守の内容が抽象的だと、範囲が無限になります。含む内容を具体的に列挙します。障害が起きたときの調査と対応、OSの更新に伴う確認、外部サービスの仕様変更への対応、簡単な内容の更新。

あわせて、含まない内容も書きます。新機能の追加、画面の大幅な変更、他システムとの新規連携。この二つを並べると、範囲の認識が揃います。

終わり方の確認項目

ここまでの内容を、実際に納品するときに確認できる形にまとめます。順に潰していけば、抜けは大きく減ります。

成果物と権利にかかわる項目

渡す成果物が契約で決めた範囲と一致しているか。ソースコード、ビルド済みのファイル、設計資料、テストの結果のうち、何を渡すかが明確になっているか。権利の扱いが文書で確認できているか。汎用的な部品の扱いが整理されているか。

これらは後から蒸し返されると厄介な論点です。納品の時点で文書にしておけば、次の案件でも同じ前提で進められます。

運用にかかわる項目

アカウントと権限の移管が終わっているか。移管の完了日が記録されているか。運用の手順書が渡されているか。既知の課題が一覧になっていて、それぞれ対応方針が書かれているか。

とくに権限の移管は、忘れられやすいのに影響が大きい項目です。移管しないまま関係が終わると、双方に不利益が残ります。

契約と支払いにかかわる項目

検収の基準と期間が共有されているか。請求書を出す時期と、入金の予定日が確認できているか。保守について、含む内容と含まない内容が書かれているか。次のフェーズの考え方をまとめた資料を渡したか。

この四つが揃っていると、納品後の連絡が事務的なやり取りだけで済みます。事務が静かな関係ほど、次の相談がしやすくなります。

連絡にかかわる項目

納品後に一度確認の連絡を入れる予定を、自分の予定表に入れているか。この一項目を入れておくだけで、連絡が途絶える事態を防げます。

リピートされない人の共通点

相談を受けていて繰り返し見る、関係が続かない典型を整理します。

連絡が遅い

技術力が高くても、返信が遅い人は次に呼ばれません。発注者側は社内に報告する必要があり、返信がないと報告ができないからです。

すぐに答えられない場合でも、「確認して明日までにご連絡します」という一報を入れるだけで印象は変わります。

範囲の話をしない

範囲を決めずに何でも受ける人は、一見すると親切に見えます。しかし実際には、途中で無理が出て品質が落ちるか、途中で止まるかのどちらかになります。

範囲を明確に話す人のほうが、結果として長く続きます。これ、知らない人が本当に多いんです。断ることが関係を悪くするのではなく、できないことを引き受けて果たせないことが関係を壊します。

引き継げない作りにする

本人しか触れない作りにしておけば依頼が続く、という考え方は逆効果です。発注者はその状態をリスクと捉え、次の案件で分散を考えます。

引き継げる状態にしたうえで、それでも頼まれる人が本当に強い立場にあります。

値引きで関係を繋ごうとする

次も呼んでもらうために金額を下げる、という発想は逆効果です。下げた金額が次回の基準になり、以降ずっとその水準で扱われます。しかも、金額で選ばれた関係は、より安い相手が現れた時点で終わります。

繋ぐべきなのは金額ではなく、進め方です。範囲の説明、報告の形、引き継ぎの整備。これらは他の相手が簡単に真似できないので、比較されにくくなります。

相手の事業に興味を示さない

技術の話だけをして、相手の事業に一切触れない人は、道具として扱われます。道具は代替されます。

事業の状況や、アプリを使う現場の様子に関心を持ち、質問する人は、相談相手として扱われます。この違いは、次の案件の相談が来るかどうかに直結します。難しいことをする必要はなく、打ち合わせの中で「その業務は今どうなっていますか」と聞くだけで十分です。

終わった後に連絡が途絶える

納品して以降まったく連絡がないと、発注者の記憶から外れます。頻繁な営業は不要ですが、節目に一度連絡を入れる程度の接点は保ちます。

関係を続けるための連絡の作法

終わり方を整えても、連絡の仕方が雑だと積み上げたものが崩れます。地味ですが効きます。

返信は結論から書く

長い前置きのあるメールは、読む側の負担になります。結論を最初の一行に置き、理由と補足を後に続けます。判断をお願いしたい項目がある場合は、本文の最後ではなく冒頭に近い位置に置きます。

期限のある依頼には日付を書く

「お手すきのときに」と書くと、相手は動きません。悪気があるわけではなく、期限のない依頼は予定に入らないからです。「この作業を進めるために、来週水曜までにご確認いただけますと助かります」という形で、理由と日付をセットにします。

相手の担当者が変わったときの対応

継続的な関係では、担当者の異動が必ず起きます。新しい担当者が来たときに、これまでの経緯をまとめた資料を渡せるかどうかで、その後が決まります。

新任の担当者は、状況が分からないまま引き継ぎます。そこに経緯の資料が届くと、その人にとって最初の助けになります。この段階で信頼を得ておくと、関係は継続します。逆に、前任者との関係だけに頼っていた人は、ここで切れます。

継続の土台になる契約の整え方

最後に、法務の観点から継続を支える仕組みを整理します。

条件の明示は義務であり、味方でもある

フリーランス保護新法では、発注者は業務の内容や報酬額、支払期日などを書面または電磁的方法で明示する義務を負います。つまり、条件を文書でくださいと求めるのは、遠慮すべき要求ではありません。

条件が文書で残っていると、次の案件の交渉が速くなります。前回の条件を基準にできるからです。取引条件に関する制度の考え方は、公正取引委員会の公表資料でも整理されています。

開発と保守は別の契約にする

ひとつの契約に開発と保守を混ぜると、どこまでが完成でどこからが運用かが分からなくなります。契約を分けておくと、開発が完了したことが明確になり、保守の対価も発生の根拠が明確になります。

権利の帰属を最初に決める

作ったものの権利をどう扱うかは、継続の前提です。曖昧なまま二回目、三回目と進むと、どこかで揉めます。今回の案件で作った部分は譲渡し、汎用的な部品は使用許諾にする、といった整理を最初に文書化します。

法律はあなたの味方です。ただし、味方になってもらうには記録が要ります。継続する関係ほど、記録の価値は大きくなります。

市場から見た終わり方の重み

継続を意識した終わり方は、案件の探し方そのものにも影響します。

アプリ開発の仕事がどのような形で募集されているかは、AIチャットボット・アプリ開発のお仕事で全体像が確認できます。募集の中には、開発だけでなく運用まで含めた形のものがあり、そうした案件は最初から継続を前提にしています。隣接する領域として、AI・マーケティング・セキュリティのお仕事では、運用の中で発生する分析や情報管理の業務がどう切り出されているかが分かります。

職種としての位置づけは、ソフトウェア作成者の年収・単価相場で統計にもとづく分布が確認できます。自分がどの工程まで担えるかを説明できると、保守の提案にも根拠が出ます。基盤や通信に関わる案件では、CCNA（シスコ技術者認定）のような認定が、運用の相談を受けるときの裏づけになります。

20年この市場を見てきた運営者の立場から言えば、長く続く人ほど、単発の作業ではなく「この人に任せると楽だ」という関係づくりに時間を使っています。速く作ることや安く作ることで選ばれた関係は、より速い人やより安い人が現れた時点で終わります。一方、範囲の説明が丁寧で、引き継げる資料が残り、連絡が途切れない人は、価格で比較されにくくなります。

もうひとつ、運営者として見てきた限りでは、中間マージンの乗らない手数料0%の直接取引をしている人ほど、終盤の整理に時間をかけています。手取りが厚い分、引き継ぎ資料の作成や納品後の確認といった、直接は請求しにくい作業に時間を割けるからです。仲介を挟んで手取りが薄くなると、その時間が真っ先に削られます。削られた結果、関係が続かず、また新しい依頼者を探すことになります。この差は金額の大小ではなく、関係を育てる余力があるかどうかの違いです。

年齢を重ねてから独立する場合も、この考え方は変わりません。定年後のフリーランス独立｜退職金を活かした起業プランと注意点では、独立後に安定した取引を作るための考え方が整理されています。新規の獲得より既存の継続に軸を置く進め方は、体力の配分という意味でも合理的です。

もう一度頼まれるかどうかは、作ったものの出来より終わり方で決まります。終わり方は、契約と記録と連絡という、地味な作業の積み重ねです。

よくある質問

Q. 納品後の不具合はどこまで無償で対応すべきですか？

合意した仕様どおりに動かない場合の修正は、契約不適合として受注側の責任範囲です。一方、OSの更新に伴う対応や新しい機能の追加は別の作業として扱います。この線引きを納品時に文書で共有しておくと、後の対応が揉めません。線引きがないと、リリース後のすべての連絡が無償の修正依頼として扱われやすくなります。

Q. 保守契約はいつ提案するのがよいですか？

開発の見積もりを出す段階です。開発の見積書に保守を含まない旨を明記し、別の見積もりとして保守の案を添えます。この順番にすると、納品後の提案が最初から予定されていた話の続きになります。納品後に初めて保守の話を出すと後出しに見え、押し売りの印象を与えます。受け方は月額、時間単位、都度見積もりの三通りを提示してください。

Q. 引き継ぎ資料を作ると、次の依頼が来なくなりませんか？

逆です。本人しか触れない作りは発注者にとってリスクであり、次の案件で別の相手を探す動機になります。引き継げる状態にしたうえで指名される人が、最も強い立場にあります。資料には構成の概要、データの持ち方、外部連携先、環境構築の手順、リリース手順、注意点を含めてください。分量より、読めば作業を再開できることが重要です。

Q. 検収が終わらず入金されない場合はどうなりますか？

フリーランス保護新法では、発注者は成果物を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定め、その期日までに支払う義務があります。検収の遅れを理由に受領から60日を超えて引き延ばすことは認められません。この知識は督促のためではなく、最初に条件を決める際の根拠として使ってください。争いが大きい場合は弁護士への相談をおすすめします。

Q. 納品後、どのくらいの頻度で連絡を取るべきですか？

頻繁な営業連絡は不要ですが、完全に途絶えると記憶から外れます。納品から少し経った時点で動作の確認として一度連絡を入れ、その後は節目ごとに接点を保つ程度で十分です。連絡の内容は営業ではなく、実際に使ってみて気になる点がないかという確認にします。改善の提案をする場合も、思いつきではなく運用の観察を根拠にしてください。