実績ゼロからモバイルアプリ開発を受注するとき、練習作をどこまで見せるか

2026年2月18日

前田壮一

この記事のポイント

✓モバイルアプリ開発の実績ゼロから受注を目指す方へ
✓練習作をどこまで見せるべきかを整理しました
✓見せて効く作品と逆効果になる作品の違い

モバイルアプリ開発を実績ゼロから始めて、いざ受注しようとしたときに多くの方がつまずくのが、「練習で作ったものを見せていいのかどうか」という一点です。教材どおりに作ったToDoアプリ、途中で止まっている天気アプリ、コードだけ残っている習作。これらを出すと逆に評価が下がるのではないかと不安になって、結局何も見せられないまま応募だけを繰り返す。皆さんの中にも、心当たりのある方がいるのではないかと思います。

まず、安心してください。実績ゼロの状態で練習作を見せること自体は、まったくマイナスではありません。問題は「何を」「どこまで」「どう見せるか」であって、練習作かどうかではないんです。この記事では、モバイルアプリ開発の実績ゼロから受注に進むために、練習作の選び方と見せ方を具体的に整理します。見せて効くもの、出さないほうがよいもの、そして権利の面で気をつけるべきことまで、順番に扱います。

「実績ゼロ」と言うとき、実際に不足しているのは何か

最初に前提を揃えておきます。実績ゼロという言葉は便利ですが、中身を分解すると、不足しているものは人によってかなり違います。ここを取り違えると、埋める努力の方向がずれます。

多いのは次の3パターンです。1つ目は、業務としての開発経験はあるがモバイル分野が初めてという方。2つ目は、独学で学習は進んでいるが対外的に見せられる成果物がないという方。3つ目は、学習も途中で、動くものがまだ手元にないという方。

このうち、練習作の見せ方が直接効いてくるのは1つ目と2つ目です。3つ目の方は、見せ方を考える前に「小さくても最後まで動くものを1本仕上げる」ほうが先になります。逆に言えば、動くものが1本あれば、実績ゼロの状態はかなりの部分が解消されると考えていただいて構いません。

発注側が見ているのは、実績の量ではなく判断の跡

発注する側の立場になって考えてみます。募集に応募してきた相手が、業務経歴の欄に何も書けない状態だとします。このとき発注者が知りたいのは「この人は経験豊富か」ではありません。そもそも経験豊富な人を求めているなら、募集の条件自体が違うはずです。

知りたいのは、任せた作業を自分で判断しながら進められるかどうかです。仕様に書かれていない部分に出くわしたとき、勝手に決めるのか、確認するのか、確認するなら何を確認するのか。この判断の質は、経歴の長さでは測れません。だからこそ、練習作の中に「なぜそう作ったか」の跡が残っていると、それが判断力の証拠として機能します。

逆に言えば、判断の跡が見えない練習作は、どれだけ数を並べても効きません。教材を写しただけの作品を10本並べるより、自分で決めた設計が1本あるほうが強い。これは、実績ゼロから受注に進む方に、私が最も強くお伝えしたいことです。

費用の幅が広い分野だからこそ、根拠として練習作が使われる

もう1つ、発注側の事情も理解しておくと、練習作の役割が見えやすくなります。アプリ開発は、依頼の規模によって費用が大きく変わる分野です。

アプリ開発会社を選定する際の基準は、開発手法・実績と強み・サービス提供範囲の3点。開発費用は数万円～1,000万円以上と幅広いため、自社の目的から逆算して比較検討する。運用後のサポート体制の確認も不可欠。出典: moduleapps.com

ここに書かれている選定基準は、法人への発注の話ですが、個人に依頼するときも構造は同じです。「実績と強み」「サービス提供範囲」を確認したいという要求は変わりません。そして費用の幅がこれだけ広い以上、発注者は「この人に頼むといくらでどこまでできるのか」を、何らかの材料から推し量る必要があります。業務実績がない相手の場合、その材料になるのが練習作です。

つまり練習作は、自分の腕前を自慢するための展示物ではなく、発注者が見積もりと範囲を判断するための資料だということです。この位置づけを掴んでおくと、何を見せるべきかが自然に決まってきます。

練習作は「どこまで見せるか」で評価が反転する

同じ作品でも、見せ方ひとつで印象が正反対になります。ここでは、実際に評価が下がりやすいパターンから見ていきます。

教材の写経を、そのままの形で出さない

学習の過程で、書籍や動画教材のとおりに手を動かして作ったアプリがあると思います。これ自体は学習として正しい進め方です。ただ、その状態のまま「作品です」と提示すると、見る側にはすぐ分かります。画面構成、変数名、サンプルデータの中身まで教材と同じだからです。

では捨てるのかというと、そうではありません。写経した作品に、自分で決めた変更を加えるだけで性格が変わります。データの保存先を変える、エラー時の表示を作り直す、画面を1つ足す。そして、その変更を選んだ理由を説明できるようにしておく。ここまでやれば、それは練習作ではなく自分の作品になります。

私も学習を始めた時期に、教材のとおりに作った画面をそのまま提示して、まったく反応が返ってこなかったことがあります。あとから振り返ると、見せていたのは「教材を最後まで進められました」という情報だけで、相手が知りたいこととは別物でした。手を動かした量は無駄になりませんでしたが、見せ方を変えるまで、その量は伝わらないままでした。

数を並べず、1本を深く見せる

実績ゼロの不安があると、どうしても数で埋めたくなります。しかし、見る側の時間は限られています。5本の未完成品を並べられると、確認するのに時間がかかり、しかもどれも判断材料にならないという最悪の形になります。

現実的なのは、主作を1本決めて、そこに説明を集中させる構成です。残りの作品は一覧に名前だけ載せておけば十分です。主作については、何を作ったか、なぜそう設計したか、どこで詰まってどう解いたか、次に手を入れるならどこかまで書きます。1本で語れる情報量は、皆さんが思っているよりずっと多いです。

未完成であることを隠さない

未完成の部分があるのは、実は問題になりません。問題になるのは、未完成であることを伏せて完成品のように出すことです。触られればすぐ分かりますし、その時点で説明の信頼性が全部落ちます。

「オフライン時の挙動は未対応です。理由は、この作品では通信部分の設計を確認したかったためです」と書いてあれば、それは欠陥ではなく設計判断になります。正直に書くほうが、結果的に評価が上がる。リスクを隠さないというのは、開発の仕事全体に通じる姿勢です。

見せ方の設計は、3つのレイヤーに分けて考える

練習作の見せ方は、感覚で決めずに構造で決めたほうが失敗しません。具体的には、動くもの、コード、説明文の3層に分けます。

レイヤー1：動くもの

まず、相手が実際に触れる形が必要です。ストアで公開しているならURLを渡すのが最も早い。公開していない場合は、テスト配信の仕組みを使うか、操作を録画した短い動画を用意します。

動画の場合、長さは1分から2分程度に抑えてください。起動から主要な操作までを一続きで見せる形が理想です。編集で細かくカットすると、逆に「切れ目で何かを隠しているのでは」と受け取られることがあります。実際の速度のまま見せるほうが誠実に伝わります。

エミュレータの画面ではなく、実機で撮ったものを用意できると印象が変わります。実機で動いているという事実は、それ自体が1つの情報だからです。

レイヤー2：コード

コードを公開するかどうかは、迷う方が多いところです。結論から言えば、公開できるなら公開したほうが有利です。ただし、条件があります。読める状態にしておくことです。

コミット履歴が「fix」「update」だけで埋まっていたり、コメントアウトされた古いコードが大量に残っていたりすると、公開はマイナスに働きます。逆に、機能ごとに変更がまとまっていて、フォルダ構成に一貫性があれば、それだけで「一緒に作業しやすそうだ」と感じてもらえます。

全部を公開する必要もありません。中核となる部分だけを切り出した小さなリポジトリを別に用意する方法もあります。見せる範囲を自分で決められるのは、練習作の利点です。

レイヤー3：説明文

3層のうち、最も差がつくのがここです。動くものとコードだけを渡して、あとは相手に読み取ってもらう形だと、多くの場合は伝わりません。

書く内容は決まっています。何を解決するアプリなのか。想定した利用者は誰か。使った技術と、その技術を選んだ理由。実装で最も悩んだ点と、どう解いたか。現時点で対応していないこと。この5項目を、それぞれ数行ずつ書けば十分です。

説明文の質は、そのまま業務中のやり取りの質として読まれます。不具合の報告や仕様の確認を、この人はどう書いてくるだろうか。発注者は無意識にそこを見ています。技術文書の書き方を体系的に押さえておくと、この部分で差がつきます。文書作成の基礎を確認する手段としては、ビジネス文書検定のような枠組みが参考になります。開発者にとっては遠回りに見えるかもしれませんが、伝わらない資料を書き続けるほうが、はるかに時間を失います。

ストアに公開するか、公開せずに見せるか

実績ゼロの方から特によく出る質問が、練習作をストアに出すべきかどうかです。判断の材料を整理します。

公開する側の利点は明確です。審査を通したという事実が残ること、相手がその場でダウンロードして触れること、そして公開後の運用まで一通り経験できること。この3つは、公開しない限り手に入りません。特に、審査で指摘を受けて修正した経験は、面談で具体的に話せる材料になります。

一方で、公開には手間と費用がかかります。開発者アカウントの登録、プライバシーポリシーの用意、アイコンやスクリーンショットの作成、審査への対応。学習の途中でこれを全部やろうとすると、肝心の開発が止まります。

現実的な進め方としては、練習作のうち1本だけを公開用に決めて、残りは配布ビルドや動画で見せるという分け方です。全部を公開する必要はありませんし、逆に1本も公開しないままだと、審査の経験がずっと得られません。1本だけ通す、というのが負担と効果の釣り合う地点だと考えています。

なお、公開したアプリの利用者数が伸びなくても気にする必要はありません。発注者が見ているのは人気ではなく、公開まで到達したという事実です。ここを誤解して「ダウンロードが少ないから見せられない」と隠してしまう方がいますが、それは非常にもったいない判断です。

練習作に入れておくと効く5つの要素

どうせ作るなら、実務で必ず問われる論点を含めておくと、そのまま説明材料になります。技術的に高度である必要はありません。

1つ目は、通信の失敗時の扱いです。APIが返ってこないとき、画面に何を出して、再試行をどう提供するか。これは実務のほぼ全案件で問われます。

2つ目は、データの保持です。アプリを閉じて開き直したときに、状態が復元されるか。端末を回転させたときに入力内容が消えないか。

3つ目は、権限の扱いです。カメラや位置情報を使う場合、許可されなかったときの動線を用意しているか。ここは審査でも見られる部分です。

4つ目は、複数端末での表示です。画面サイズが違う端末で崩れないか。実機を複数持っていなくても、シミュレータで確認した記録があれば説明できます。

5つ目は、更新のしやすさです。文言や設定値がコードのあちこちに散らばっていないか。後から他人が触ることを想定した作りになっているかは、保守案件を狙う場合に特に効きます。

この5つを押さえた小さなアプリは、規模が小さくても「実務を分かっている人が作ったもの」として読まれます。アプリ開発の仕事が実際にどういう形で依頼されるかは、アプリケーション開発のお仕事にまとまっているので、作る内容を決める前に一度目を通しておくと、含めるべき要素の見当がつきやすくなります。

見せてはいけないものもある

ここは慎重に扱ってください。練習作だと思っていたものが、実は見せられない性質のものだったというケースがあります。

勤務先の業務で作ったコードは、原則として持ち出せません。個人の練習として書き直したつもりでも、設計や画面構成が業務のものと一致していれば問題になり得ます。前職で扱った題材を練習作にする場合は、業務で得た情報が混ざっていないかを確認してください。

既存サービスの模倣も注意が必要です。学習目的で有名アプリの画面を再現するのは一般的な練習方法ですが、そのままロゴや商標を使って公開すると別の問題になります。見せる場合は、自分で用意した名称とデザインに置き換えておくのが安全です。

実在の個人情報をテストデータに使うのも避けてください。知人の名前や連絡先をそのまま入れたまま公開してしまう事故は、実際に起きています。テストデータは、明らかに架空と分かる形にしておきます。

判断に迷う場合は、公開前に一度立ち止まって確認する。これだけで、後から取り返しのつかない事態はほぼ防げます。

実績ゼロの期間を短くするための進め方

最後に、実績ゼロという状態から抜ける現実的な順番を書いておきます。焦って全部を同時にやろうとすると続きません。

最初の1カ月は、作るものを1本に決めて完成させることだけに集中します。この段階では見せ方を考えなくて構いません。完成しないものは見せようがないからです。

次の2週間で、説明文を書きます。先に挙げた5項目を埋める作業です。書いていくと、自分でも説明できない部分が必ず出てきます。そこが、次に学ぶべき箇所です。

その後、ストア公開を1本だけ進めます。審査で指摘が来たら、内容と対応をメモに残しておきます。このメモが、後の面談でそのまま話せる材料になります。

ここまで揃った段階で、応募を始めます。順番を逆にして、材料がないまま応募を続けると、断られる経験だけが積み上がって気力が削られます。皆さんに一番避けてほしいのは、その消耗です。

単価や条件の相場観も、応募を始める前に持っておくと落ち着いて交渉できます。職種ごとの報酬水準はソフトウェア作成者の年収・単価相場で確認できます。実績が薄い時期は相場より低い提示を受けることがありますが、相場を知らずに受けるのと、知った上で最初の1件と割り切って受けるのとでは、その後の交渉のしやすさがまったく違います。

また、ネットワーク周りの基礎知識を体系的に持っていることを示したい場合は、CCNA（シスコ技術者認定）のような資格が補助的な説明材料になります。アプリ側の開発者が通信の仕組みを理解していると、不具合の切り分けで話が早いため、保守寄りの案件では評価につながることがあります。

面談で練習作について聞かれることは、だいたい決まっている

作品を提出した後には、ほぼ必ず質問が来ます。ここで詰まると、せっかくの作品が活きません。逆に言えば、来る質問は事前に想定できます。実績ゼロの段階では、この準備が特に効きます。

「なぜこの技術を選んだのですか」

最も多い質問がこれです。ここで「学習していた教材がその言語だったから」と答えると、話が終わってしまいます。事実としてはそのとおりでも、それは技術選定の理由になっていないからです。

答え方の型としては、比較した対象を1つ挙げて、選んだ側の利点を1つ、選ばなかった側の欠点を1つ述べる形が安全です。「iOSとAndroidの両方で動かしたかったので、単一のコードベースで済む方式を選びました。ネイティブの機能に深く踏み込む場合は不利になりますが、今回の機能範囲では問題にならないと判断しました」といった形です。

重要なのは、正解を答えることではありません。トレードオフを認識した上で選んだかどうかが見られています。皆さんが選んだ技術がどれであっても、この形で答えられれば評価は下がりません。

「一番苦労したのはどこですか」

これも定番です。ここで「特にありません」と答えるのは、実は最も印象が悪い答え方です。作れば必ずどこかで詰まるはずで、詰まらなかったということは、規模が小さすぎるか、深く考えていないかのどちらかだと受け取られます。

答えるときは、現象、調べた過程、解決策の3つを揃えます。「一覧をスクロールすると表示が引っかかる現象が出ました。計測したところ、行の描画のたびに画像を再生成していることが分かったので、生成結果を保持する形に変えました」といった具合です。原因の特定にどう至ったかまで話せると、不具合対応の力があると判断されます。

「次に手を入れるとしたらどこですか」

この質問は、作品を客観視できているかを見ています。完成したものを完璧だと言い張る人より、改善余地を具体的に挙げられる人のほうが、業務でも安心して任せられます。

準備としては、作品を作り終えた直後に「現時点で未対応のこと」を箇条書きでメモしておくのが確実です。時間が経つと忘れます。このメモがあれば、質問された瞬間に具体的な答えを返せます。

「業務の経験がない点をどう補いますか」

実績ゼロの応募では、必ずこの趣旨の確認が入ります。ここで謝罪から入る必要はありません。補い方を具体的に示せば十分です。

有効なのは、確認の頻度と方法を提案することです。「仕様に迷ったら自己判断で進めず、その日のうちに質問をまとめて送ります」「週の初めに、その週に着手する範囲を1通のメールで共有します」といった運用の提案は、経験不足に対する現実的な対策として受け取られます。発注者が恐れているのは、経験のなさそのものではなく、経験がないまま黙って進められることだからです。

練習作の次に置く、小さな中間ステップ

練習作を整えたら、いきなり大きな案件に応募するのではなく、間に小さな段を置くと進みが安定します。実績ゼロから受注までの距離を、一気に飛ばそうとしないという考え方です。

身近な依頼を、条件を決めた上で受ける

知人や前職の関係者から「こういうものが作れないか」と相談を受けることがあります。これは中間ステップとして扱いやすい形です。ただし、無償で引き受けるのはおすすめしません。金額の多寡ではなく、条件を決めて受けるという経験そのものが必要だからです。

範囲、納期、修正の回数、費用の負担範囲。この4つを最初に文面で決めて進めるだけで、業務としての進め方が身につきます。無償だと、この4つがすべて曖昧なまま進みやすく、結果として時間だけを失います。

公開されているプロジェクトへの貢献を1件作る

もう1つの中間ステップが、公開されているプロジェクトへの小さな貢献です。翻訳の修正、ドキュメントの誤りの指摘、小さな不具合の修正など、規模は問いません。

ここで得られるのは、他人が書いたコードに手を入れて、レビューを受けて、指摘に対応するという一連の経験です。実務の改修案件でやることと構造が同じなので、経験として直接使えます。応募時にも「他者のコードに変更を加えてレビューを通した経験があります」と言えるのは、実績ゼロの状態では大きな差になります。

受けられる範囲を、先に文章にしておく

中間ステップを踏むときに、自分が受けられる範囲を先に決めておくと、無理な依頼を抱え込まずに済みます。対応できるOS、用意できる実機、稼働できる時間帯、対応しない領域。これらを短い文章にまとめておいて、相談が来たらそのまま共有します。

実績が薄い時期ほど、断ると次がないと感じて何でも引き受けたくなります。ただ、受けた後に対応できないと分かるほうが、信頼としては大きく損なわれます。範囲を先に示すのは、自分を守ると同時に相手を守る行為でもあります。

私自身、独立して間もない時期に、対応できるかどうか曖昧なまま引き受けて、後から範囲の食い違いで苦労したことがあります。技術的に難しかったわけではなく、単に「どこまでやるか」を決めずに始めたことが原因でした。それ以降は、着手前に範囲を1通の文面にして送るようにしています。手間は10分ほどですが、後の数日を守ってくれます。

20年この市場を見てきた立場からの観察

運営者として長くフリーランスと発注者の双方を見てきた立場から言えば、実績ゼロから継続受注に進んだ人には、共通する行動があります。作品を見せた後の対応が速く、そして丁寧なことです。

練習作について質問が来たとき、その日のうちに具体的に答えられる人は、次の段階に進みます。逆に、返信に何日もかかったり、質問への答えがずれていたりすると、作品の出来がよくても話は止まります。発注者は、作品を通して「一緒に仕事をしたときの手触り」を確認しているからです。

もう1つ、運営者として見てきた限りでは、実績の見せ方を工夫している人ほど、単発の依頼を継続の相談に変えています。ここには構造的な理由もあります。中間マージンが乗らない直接取引では、同じ予算でも発注者はより多くを頼め、受け手は同じ作業でも手取りが厚くなります。手数料0%という条件は、金額の話というより、双方に「もう少し踏み込んで関わる余地」が残るという意味を持ちます。実績がまだ薄い時期に、その余地を使って小さな追加依頼を積み重ねられるかどうかは、その後の展開を大きく変えます。

作品づくりそのものの考え方は、他の職種でも通じる部分があります。文章の仕事におけるポートフォリオの組み立て方はWebライターのポートフォリオの作り方｜案件獲得率が上がるテンプレート付き【2026年版】にまとまっていて、見せる順番や説明の付け方は開発分野でもそのまま応用できます。実績が積み上がってきた後の単価の上げ方についてはWebライターが文字単価を上げる方法｜1円→5円にステップアップする戦略【2026年版】の考え方が参考になります。

実績ゼロは、状態であって評価ではありません。手元にある練習作を、判断の跡が見える形に整え直すところから始めれば、皆さんが思っているより早く、その状態からは抜けられます。