モバイルアプリ開発の受ける相手を見きわめる｜断ってよい依頼

2026年5月11日

長谷川奈津

この記事のポイント

✓モバイルアプリ開発のクライアントの選び方を
✓受注前に見きわめる基準として整理しました
✓初回のやり取りで分かる兆候

モバイルアプリ開発のクライアントの選び方を考えるとき、多くの人は「良い相手をどう探すか」から入ります。実務で効くのは逆の発想です。受けてはいけない依頼の形をあらかじめ知っておき、当てはまったら受けない。この引き算のほうが、結果として稼働も精神も守られます。この記事では、初回のやり取りだけで判断できる兆候、断ってよい依頼の類型、法律上おさえておくべき取引条件、そして角を立てない断り方までを順に整理します。

相手を見きわめる作業が、なぜ開発の質を決めるのか

アプリの受託は、Webサイトの制作より契約期間が長く、リリース後の関係も続きます。相手を間違えたときの損失が、他の受託よりも大きくなります。

アプリは事業の主要な接点になった

依頼者がアプリに求める期待値は、この10年で大きく変わりました。かつては「あると便利なもの」でしたが、いまは顧客との主要な接点そのものです。

モバイルアプリ開発会社の選び方とは、自社のアプリ要件・運用体制・予算制約に対して、開発委託先を「見積根拠の透明性」「実績領域の一致」「リリース後の運用保守体制」の3軸で評価し、複数社の比較を通じて発注先を確定する一連の選定プロセスである。総務省「令和7年版情報通信白書」によると、スマートフォンの世帯保有率は90.5%に達しており（2024年調査）、個人のインターネット接続端末としてのスマートフォン利用率は74.4%で、パソコンの46.8%を上回るチャネルとなっている。アプリは事業の主要接点となるため、開発会社の選定ミスはユーザー獲得機会の損失に直結する。出典: lassic.co.jp

依頼する側が「選定ミスは損失に直結する」と考えているということは、受ける側にも同じ緊張感があるという意味です。選定は一方通行ではありません。発注者が開発会社を選ぶのと同じ真剣さで、受ける側も相手を選ぶ必要があります。

見きわめは失礼ではない

条件を確認すると関係が悪くなるのではないか、と考えて何も聞かないまま受けてしまう人がいます。これは逆です。条件を先に確認する相手のほうが、依頼する側にとっても安心材料になります。社内の説明資料に落とせるからです。

質問をして機嫌が悪くなる相手は、その後の工程でも同じ反応をします。初回の質問は、相手の性質を測る安全な機会でもあります。

初回のやり取りだけで分かること

契約前の数回のメールや面談には、その後の数ヶ月が凝縮されています。見るべき点は限られています。

目的を語るか、画面を語るか

実現したいことを「誰の、どんな困りごとを、どう解決したいか」で説明できる相手は、途中の判断が速く、修正も少なくなります。作ったものを見て意見が変わっても、判断の軸が目的にあるため、議論が収束します。

一方、他社のアプリを見せて「これと同じものを作ってほしい」とだけ伝えてくる相手は、目的が言語化されていません。この状態で着手すると、動くものを見てから初めて要望が生まれ、要望が出るたびに設計が揺れます。悪い相手というわけではありませんが、要件を整理する工程を別に見積もる必要がある案件です。

予算と納期をどう出してくるか

予算を一切示さず「見積もりを出してください」とだけ言う相手には、注意が要ります。金額を言わないのは駆け引きの場合もありますが、社内で予算が確保できていない場合も多いためです。予算が未確定のまま提案作業だけ進むと、その作業がそのまま無償になります。

納期についても同じです。理由の説明がある納期と、理由のない納期は別物です。「展示会が◯月にあるため」のように背景がある納期は調整の余地があります。背景が説明されない納期は、後から動く可能性が高く、動いた分の負担は受ける側に来ます。

連絡の仕方と速度

契約前の返信が遅い相手は、契約後も遅くなります。開発中に確認の返事を待つ時間は、そのまま納期を押します。しかも、待たされた分の遅れは受ける側の責任として扱われがちです。

見るべきなのは速度そのものではなく、遅れたときに一言あるかどうかです。「確認に時間がかかっています」の一報がある相手は、開発中も同じように動きます。

断ってよい依頼の類型

次に挙げる形に当てはまる依頼は、受けない判断をしてよいものです。断ることは、能力不足でも礼儀知らずでもありません。

取引条件を書面にしたがらない

これがもっとも重要な兆候です。フリーランスとして業務委託を受ける場合、発注者には取引条件を書面や電子メールなどで明示する義務があります。委託する業務の内容、報酬の額、支払期日といった項目です。

条件を書くよう求めたときに、「そこまで堅くしなくても」「うちは今までそういうのなしでやってきた」と返ってくる場合、その後のトラブルで守るものが何もない状態になります。この段階で受けない判断をするほうが、後で回収不能な作業を抱えるより損失が小さくなります。

支払期日が極端に遅い、または決まっていない

業務委託の報酬は、成果物を受け取った日から一定期間内に支払う必要があります。具体的には、受領日から起算して60日以内のできる限り短い期間内に支払期日を定めることが求められます。

「支払いは検収が完了してから」とだけ書かれていて、検収の期限が定められていない契約は、実質的に支払期日が存在しない契約です。検収の期限を明記してもらうよう求め、応じない場合は受けない判断の材料になります。個別の契約条件が法令に照らして問題があるかどうか判断に迷う場合は、弁護士に相談してください。

「まずは無償で試作を」と求める

提案の一環として簡単な画面案を出すことはあります。動くものを作る作業は別です。無償の試作を求める依頼は、選定の手間を受注候補に負担させる構造になっています。

しかも、この手の依頼は複数の候補に同時に出されていることが多く、作った試作がそのまま別の会社の参考資料になることもあります。試作が必要なら有償の別契約にする、と提案して反応を見ます。

決裁者が最後まで出てこない

窓口の担当者だけと話が進み、承認する人が誰なのか分からないまま設計が進む案件は、終盤で作り直しが起きます。初回に「最終的に承認されるのはどなたですか」と一度聞くだけで判別できます。

答えが曖昧な場合、その担当者自身も社内の合意を取れていない可能性があります。この状態の案件を受けるなら、要所ごとに承認をもらう工程を契約に組み込む必要があります。

権利の全部譲渡と無制限の保証がセットになっている

契約書に、成果物の著作権を全部譲渡する条項と、期間の定めのない無償修正の条項が両方入っている場合は要注意です。譲渡そのものは珍しくありませんが、譲渡したうえで永続的な無償対応の義務まで負うのは均衡を欠きます。

最低限、契約不適合責任の期間を明記してもらいます。期間の定めがないまま「不具合は無償で対応する」とだけ書かれた契約は、何年先でも義務が残ると読まれかねません。

やり直しや報酬の減額を前提とした言い回しがある

「気に入らなければ作り直してもらう」「品質次第で報酬を調整する」といった表現が契約前から出てくる場合、判断の基準が相手の主観に置かれています。

受領した成果物を正当な理由なく受け取らない、あらかじめ定めた報酬を減額する、必要のないやり直しをさせる。これらは発注者の禁止行為として整理されている類型です。契約前からその方向の言葉が出るなら、受けない判断が妥当です。

要望の量に対して条件が明らかに釣り合わない

要望の量と予算が釣り合っていない案件では、どこかを削る判断が必要になります。問題は、その判断を受ける側に丸投げされる点です。削れば「聞いていた話と違う」と言われ、削らなければ持ち出しになります。

受けるなら、着手前に「今回の範囲」と「次の段階に回す範囲」を分けた一覧を作り、相手の承諾を得ます。この一覧作りに応じない相手は、後から範囲が膨らむ相手です。職種としての立ち位置や求められる役割を整理しておきたい場合は、ソフトウェア作成者の年収・単価相場で、市場のなかでの位置づけを確認しておくと判断の目安になります。

法令の観点でおさえておく三つの柱

条件を判断するための最低限の知識は、次の三つです。難しい話ではありません。

一つ目は、取引条件の明示です。何を、いつまでに、いくらで、いつ支払うか。この四つが文字で残っていない取引は、後から何も証明できません。口頭で合意しても、必ずメールで確認の一往復を残します。

二つ目は、支払期日です。成果物を受け取った日を起点に期日を定める必要があります。「翌々月末払い」のような社内慣行が期日の範囲を超えていないかは、着手前に確認する価値があります。

三つ目は、禁止されている行為の類型です。受領を正当な理由なく拒む、あらかじめ定めた報酬を減額する、返品する、著しく低い報酬を不当に定める、必要のないやり直しをさせる。これらは発注者側の行為として問題になり得る類型として整理されています。相手が悪意を持っているとは限らず、単に知らないだけの場合も多いため、まずは条件を確認する形で伝えるのが実務的です。

契約や条件の整理は、開発以外の受託でも共通します。業務の設計や運用の支援を含む案件では、要件が固まりきらないまま進みやすいため、同じ論点がより強く出ます。仕事の性質はAIコンサル・業務活用支援のお仕事でも整理されており、範囲の切り方の考え方は共通しています。

初回に聞くべき質問

見きわめは、質問の設計でほぼ決まります。次の項目を初回に聞くだけで、その後の展開が読めるようになります。

このアプリで解決したい困りごとは何か。誰が使うか。iOSとAndroidの両方が必要か、片方でよいか。既存のシステムと連携する必要があるか。デザインはどこまで用意があるか。承認するのは誰か。希望の時期と、その理由。予算の枠。リリース後の運用は誰がやる想定か。

多いように見えますが、面談で自然に聞ける範囲です。答えが揃わない項目があるなら、それは要件整理の工程が必要だという意味であり、その工程を別に見積もる根拠になります。答えを言いたがらない項目があるなら、そこが後で揉める箇所です。

案件の全体像や工程ごとの関わり方を整理しておきたい場合は、アプリケーション開発のお仕事で、開発の受注がどのような流れで進むかを確認しておくと、質問の抜けが減ります。

断り方の実務

見きわめた結果、受けないと決めたときの伝え方には作法があります。

理由は一つだけ、事実で書く

断る理由を並べると、相手はそれぞれに反論します。「では納期は延ばします」「では条件を変えます」と交渉が始まり、結局受けることになります。

理由は一つに絞り、事実として書きます。「現在お請けしている案件の関係で、ご希望の時期に十分な時間を確保できないため」で足ります。相手の落ち度を理由にする必要はありません。条件が合わないという事実だけを伝えます。

代替案を出すかどうかを決めておく

断ったあとに別の提案を出すかは、案件によって分けます。条件が合わないだけで相手そのものに問題がないなら、時期をずらす提案や範囲を絞る提案には意味があります。

一方、条件を書面にしない、支払期日が定まらないといった構造的な問題がある相手には、代替案を出しません。代替案は「条件を調整すれば受ける」という合図になり、交渉が続いてしまいます。

やり取りを残す

断った経緯は残しておきます。同じ相手から半年後に再度依頼が来ることは珍しくなく、そのときに前回の条件を参照できると判断が速くなります。

また、断ったあとに「もう作業を始めているはずだ」と主張されるような事態に備える意味もあります。着手していないことを示せる記録は、それ自体が防御になります。

依頼者の立場ごとに、見るべき点が変わる

同じ「アプリを作りたい」でも、依頼してくる人の立場によって危険の出方が違います。相手の立場を最初に把握しておくと、確認すべき点を絞れます。

情報システム部門からの依頼

社内でシステムを管理している部署からの依頼は、要件の書き方が整っていることが多く、進行も安定します。確認すべきなのは、実際に使う事業部門との関係です。情報システム部門が窓口で、要望は事業部門から来るという構造の場合、両者の合意が取れていないと途中で方針が変わります。

聞くべきことは一つです。「今回の要件は、実際に使われる部署と合意済みでしょうか」。合意済みなら安心して進められます。まだなら、合意を取る場を工程に入れてもらいます。

事業部門からの直接の依頼

現場の部署から直接来る依頼は、目的が明確で判断も速い反面、社内の手続きが抜けていることがあります。予算の確保、セキュリティ部門の確認、法務の確認。これらが後から出てくると、着手済みの作業が止まります。

確認するのは、社内で必要な承認がどこまで済んでいるかです。まだ済んでいない場合、契約の締結を待ってから着手する段取りにします。口頭の依頼で先に手を動かすと、承認が下りなかったときに作業が丸ごと消えます。

代理店や元請けを経由した依頼

間に会社が入る案件では、実際の依頼者の要望が伝言で届きます。伝言の過程で条件が変わることがあり、最終的な承認者との距離も遠くなります。

確認すべきは三点です。実際の依頼者と直接やり取りできるか。仕様の最終判断は誰がするか。支払いの条件は元請けとの契約で決まるのか、その先の条件に連動するのか。三点目は特に重要で、「先方から入金があり次第お支払いします」という条件は、支払期日の定めとして機能しません。

個人や小規模の事業者からの依頼

熱意があり、判断も速い相手が多い一方、開発の相場観と工程の理解が薄い場合があります。悪意ではなく、単に経験がないためです。

この場合は、断るより先に、範囲と工程を丁寧に説明する価値があります。作れるものと作れないもの、時期ごとに何が終わるか、リリース後に何が必要か。説明したうえで理解が得られるなら、良い相手になります。説明しても「とにかく安く早く」しか返ってこないなら、条件が合わない相手です。

技術面で先に確かめておく条件

条件の見きわめは、契約の話だけではありません。技術面で先に確認しておかないと、見積もりそのものが成立しない項目があります。

一つ目は、既存の資産の状態です。すでにアプリがあり、その改修を依頼される場合、ソースコードが手元にあるか、ビルドが通るか、どのバージョンのライブラリを使っているかで作業量が何倍にも変わります。前の開発者との関係が切れていて、コードもアカウントも揃わない状態の案件は少なくありません。着手前に、コードの受け渡しとビルドの確認までを一つの工程として区切っておきます。

二つ目は、ストアのアカウントです。配信に使うアカウントを依頼者が保有しているか、これから作るのか。法人での登録には手続きの時間がかかります。証明書の発行や更新の権限を誰が持つかも、リリース直前に問題になりやすい箇所です。

三つ目は、連携する外部のシステムです。既存の基幹システムやサービスと通信する要件がある場合、その仕様書が存在するか、担当者と話せるかを確認します。仕様書がなく、担当も不明という状態で見積もりを出すと、調査だけで想定の工数を使い切ります。

これらを確認したいと伝えたときに、資料を出す準備がある相手なら進められます。「動けば何でもいい」としか返ってこない相手は、後から要件を出してくる相手です。技術の維持や運用の設計を含めて提案する力は、こうした場面でそのまま条件交渉の材料になります。基礎を体系的に持っていることを示す手段としては、CCNA（シスコ技術者認定）のような認定が、運用まで含めた提案の説得力を補強します。

過去の発注のしかたを聞く

もっとも情報量が多い質問は、過去にどう発注してきたかを聞くことです。

以前にアプリを作ったことがあるか。あるなら、どこに頼んだか。うまくいった点と、うまくいかなかった点は何か。この三つを聞くだけで、相手の期待値と、こちらが同じ地雷を踏む可能性が見えます。

答えのなかに「前の会社は途中で連絡が取れなくなった」「納品されたものが動かなかった」という話が出た場合、その原因が本当に相手側にあったのかを、話の流れから推し量ります。過去のすべての取引先に問題があったと語る相手には、共通の原因がある可能性を考えます。

逆に、「前回は自分たちの要件の出し方が遅くて迷惑をかけた」と話す相手は、進め方を改善する意思がある相手です。この一言が出るかどうかで、その後の協力の度合いが大きく変わります。

契約の形で変わる責任の重さ

条件を見きわめるときは、契約の形も一緒に見ます。同じ金額でも、負う責任がまったく違うためです。

成果物の完成を約束する形の契約では、決めたものが完成しなければ責任を問われます。要件が固まっている案件には向きますが、要件が曖昧なまま結ぶと、どこまで作れば完成なのかが不明確なまま責任だけを負うことになります。

一方、作業そのものを提供する形の契約では、決められた進め方に沿って作業する義務を負います。要件が動く案件や、調査が中心の工程に向いています。

危険なのは、要件が固まっていない案件を、完成を約束する形の契約で受けることです。完成の定義がないまま完成の責任だけを負う構造になります。要件整理の工程は作業を提供する形で受け、要件が固まってから開発の契約を結ぶ。この二段構えにするだけで、負う責任は大きく変わります。

契約の形を提案する時点で相手の反応も見えます。段階を分ける提案に応じる相手は、進め方を一緒に考えられる相手です。「面倒だから最初から全部込みで」と言う相手は、後の変更も全部込みだと考えている可能性があります。

提案の段階で条件を出しておく

見きわめは、相手を観察するだけの作業ではありません。こちらから条件を先に出すことでも、相手の性質が分かります。

提案書や見積書には、金額とあわせて次を書きます。前提となる条件。含まれる範囲と含まれない範囲。修正対応の考え方。検収の期限。支払いの条件。相手の作業として必要なこと。

最後の項目は忘れられがちですが重要です。素材の提供、確認の返答、アカウントの発行、審査に必要な情報の準備。これらが遅れると納期は動きます。相手の作業として明記しておけば、遅れの原因を後から整理できます。

この提案を出したときの反応が、そのまま判定になります。条件を読んで質問してくる相手は、契約後も条件を守ります。条件に触れず金額だけを値切ってくる相手は、契約後も条件を見ません。

受けたあとに危険が見えたときの対処

見きわめは完璧にはなりません。着手後に問題が見えることもあります。そのときに大切なのは、早い段階で記録に残すことです。

範囲外の依頼が来たら、その場で「これは当初の範囲外にあたるため、別途お見積もりになります」と書いて送ります。作業をするかどうかは後で決めればよく、まず範囲外であることを記録します。この一文を送らずに対応してしまうと、次から同じ依頼が範囲内として扱われます。

確認の返答が遅れて作業が止まっているなら、止まっている事実を都度共有します。「◯日時点で回答待ちのため、この工程は着手できていません」という記録があれば、納期の話になったときに事実で説明できます。

支払いの遅れが起きたら、催促は感情ではなく条件で行います。契約で定めた期日と、その日を過ぎている事実だけを書いて送る。それでも動かない場合は、外部の相談窓口や専門家に相談する段階に入ります。悩んでいる期間が長いほど選択肢が減るため、期日を過ぎた時点で動くのが実務的です。

受けてよい相手に共通するサイン

断る基準ばかりを並べましたが、良い相手の見分け方も明確です。

条件を聞かれたときに、すぐ書面で返してくる。分からないことを「分からない」と言う。社内の事情を説明する。納期の理由を話す。過去の失敗を隠さない。承認者を最初に紹介する。

これらは規模や業種と関係ありません。小さな会社でも個人事業主でも、この動きをする相手との仕事は最後まで進みます。逆に、大きな組織でもこれらが欠けていれば、途中で止まります。

長期の関係を築ける相手を見分ける観点は、国内の案件に限りません。海外の依頼者と取引する場合は、商習慣の違いを前提に条件確認の手順を組む必要があります。契約前に何を確認するかは、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法でも実務の観点から整理されています。

現場を見てきた立場からの観察

在宅とフリーランスの仕事の市場を20年見てきた運営者の立場から言えば、案件が続く人と続かない人の差は、営業力よりも「断った経験の量」に出ています。断ったことがない人は、受けてはいけない依頼の形を知らないまま、毎回同じ種類の消耗を繰り返します。

もう一つ、長く続く人に共通しているのは、相手を評価するときに金額を最後に見ていることです。先に見ているのは、条件を文字にできるか、判断する人が誰か、遅れたときに連絡が来るか。この三点が揃っている相手なら、多少条件が厳しくても案件は完了します。逆に、この三点が欠けた相手とは、条件が良く見えても最後まで進みません。

仲介の手数料が乗らない直接の取引では、同じ予算で依頼する側はより多くを頼めて、受ける側は手取りが厚くなります。手数料0%という条件が効いてくるのは、金額の多寡そのものよりも、その余白を「条件を詰める時間」に回せる点にあります。値切られた分を仕様の飲み込みで埋める必要がなくなるため、断る判断もしやすくなります。

法律は、条件をきちんと文字にした人の側に立ちます。書面を求めること、支払期日を確認すること、範囲を一覧にすること。どれも相手を疑う行為ではなく、両方が同じ前提で進むための手続きです。

よくある質問

Q. 初回の打ち合わせで、どこまで踏み込んで条件を聞いてよいですか？

目的、利用者、対応するOS、既存システムとの連携、デザインの用意、承認者、希望時期とその理由、予算の枠、リリース後の運用体制まで聞いて問題ありません。これらは発注する側にとっても社内説明に必要な項目です。質問して機嫌が悪くなる相手は、開発中も同じ反応をするため、初回は相手の性質を測る機会にもなります。