実績ゼロでアプリ開発を受けるとき、個人で作ったものをどう見せるか

2026年5月23日

朝比奈蒼

この記事のポイント

✓アプリ開発実績ゼロの状態から仕事を受けるには
✓個人で作ったものを発注側が確認できる形に整えるのが近道です
✓費用をかける価値がある部分までを具体的に整理します

アプリ開発の仕事を受けたいのに実績ゼロで止まっている、という相談は毎年一定量あります。結論から言うと、この壁の正体は腕前ではありません。発注側が「この人に頼んで大丈夫か」を確認する材料が、こちらから提示されていないだけです。個人で作ったものが1つでも手元にあるなら、材料はすでに存在します。問題はその見せ方に集中しています。

この記事では、アプリ開発実績ゼロの人が個人制作をどう並べれば発注側の判断材料になるのかを、置き場所・記録の粒度・題材の選び方・無料で揃う道具まで含めて整理します。案件応募の文面の書き方や、続けるための時間管理は別の話なので、ここでは「見せる材料そのものを作る」ことに絞ります。

実績ゼロという言葉が指しているもの

まず前提を揃えます。実績ゼロには2種類あります。1つは「業務としてアプリを納品したことがない」状態、もう1つは「そもそも動くものを1本も作り切っていない」状態です。前者は見せ方の問題で、後者は制作の問題です。この2つは対処が全く違うのに、同じ言葉でまとめられているために混乱が起きています。

業務経験がないだけで、個人で1本作り切っているなら状況は悪くありません。発注側が実務経験そのものを見ているというより、実務経験を「品質と再現性の代理指標」として使っているからです。代理指標である以上、別の材料で代替できます。逆に、まだ何も完成させていない場合は、見せ方をいくら考えても意味がありません。この場合の最短経路は、小さくても最後まで動く1本を作ることです。

正直なところ、実績ゼロで悩んでいる人の多くは後者に近い状態です。チュートリアルを何本かなぞった、学習サービスの課題は解いた、けれど自分の判断で最初から最後まで組んだものはない。この状態で応募を繰り返しても手応えが出ないのは当然で、見せられるものが実在していないからです。

アプリ開発の発注側が実際に見ている3点

発注側の選定基準は、案件の規模を問わずおおむね共通しています。開発会社選びの解説記事でも、判断軸は次のように整理されています。

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

これは法人の開発会社を選ぶ文脈ですが、個人に発注するときの判断も同じ構造になります。つまり、実績そのものは3つのうちの1つでしかありません。残りの2つ、どんな作り方をするのか、どこからどこまでを引き受けるのかは、実績ゼロでも今日から提示できます。ここを空欄にしたまま実績だけを気にしているのが、多くの人がはまっている状態です。

費用の幅が広いことも、発注側が確認材料を欲しがる理由になっています。

数万円で制作できるものから1,000万円以上になるケースもあり、価格幅が広いため、具体的な費用を知りたい方は実際に開発会社へ問い合わせてみることをおすすめします。出典: moduleapps.com

数万円から1,000万円以上まで開くということは、発注側は「この金額でこの範囲が本当に出てくるのか」を毎回ゼロから見極めなければならないということです。相場が一本に定まっていない領域では、価格の妥当性を判断する材料が制作物そのものしかありません。見せるものを整えることは、値段の話を成立させるための前提条件でもあります。

個人で作ったものを、見せられる形にする4つの層

個人制作を実績として機能させるには、成果物を4つの層に分けて用意します。上から順に手間が増えますが、上の層だけでは足りず、下の層だけでも足りません。

層1: 実際に触れる動くもの

最優先は、相手が自分の端末で触れる状態にすることです。スクリーンショットだけのポートフォリオと、その場で操作できるものとでは、伝わる量が大きく違います。アプリの場合はストア公開が理想ですが、公開していなくても手はあります。

iOSならTestFlightの外部テスト、Androidならクローズドテストのリンク、Webアプリならデモ用URLの常時公開です。ネイティブアプリを作っていても、主要画面だけをWebで再現したデモを別途置いておくと、相手にインストールの手間をかけずに済みます。この「相手の手間をゼロに近づける」という発想が、実績ゼロの段階では特に効きます。判断してもらう前に脱落させないことが目的だからです。

配布形式の選択には注意点もあります。Android向けにファイルを直接渡す方法は、受け取る側にインストールの許可設定を求めることになり、企業の端末では実行できない場合があります。相手に手順を要求する見せ方は、それ自体が減点になりうると考えたほうがいいでしょう。

層2: 画面と操作が分かる記録

触ってもらう前に、何のアプリなのかが数秒で分かる記録を用意します。静止画のスクリーンショットを並べるだけでなく、30秒前後の操作録画を1本置くのが効率的です。画面遷移、入力、結果表示という一連の流れが動いて見えることで、完成度の印象が変わります。

録画は端末の標準機能で撮れるので追加費用はかかりません。音声ナレーションは不要で、字幕テロップを数枚重ねるだけで十分伝わります。ここに凝りすぎて時間を使うのは本末転倒なので、1本あたり1時間以内で仕上げる前提にしておくといいでしょう。

層3: 設計と判断の記録

ここが実績ゼロの人にとって最大の差別化ポイントです。動くものを出せる人は一定数いますが、「なぜその作りにしたか」を言語化している人は多くありません。

書くべきは、要件をどう決めたか、どのデータ構造を選んだか、どの機能を意図的に作らなかったか、の3点です。特に3点目、作らなかった機能とその理由を書けている人は強い印象を残します。実務のアプリ開発は、限られた予算と期間の中で何を落とすかを決め続ける仕事だからです。全部盛りの個人開発より、割り切りの理由が説明できる小さなアプリのほうが、発注側には安心材料になります。

記録の分量は1本あたり800字程度で構いません。長い技術解説より、判断の跡が残っていることが重要です。

層4: 運用してからの記録

作って終わりではなく、公開後に何が起きたかまで書けると信頼度が一段上がります。不具合が出た、特定の端末で表示が崩れた、想定していない使われ方をされた、といった記録です。

発注側が本当に恐れているのは、納品直後ではなく納品後です。リリースしてから連絡が取れなくなる、不具合を報告しても直らない、という事態を避けたい。運用の記録は、そこに耐えられる相手かどうかの証拠になります。実績ゼロであっても、自作アプリの修正履歴が残っていれば、それは立派な運用実績です。

題材の選び方が、実は最も効く

何を作るかで、同じ労力でも伝わり方が変わります。実績ゼロの段階で選ぶべき題材には、いくつかの条件があります。

第1に、完成が定義できる小ささであること。SNSのようなアプリは終わりがなく、途中で止まったまま「作りかけ」の山になりがちです。第2に、自分か身近な人が実際に使う用途であること。使われることで不具合が出て、修正が生まれ、層4の記録につながります。第3に、狙いたい案件領域と地続きであること。

3点目は見落とされやすい部分です。業務システム寄りの案件を狙うなら、在庫管理や作業記録のような地味な題材のほうが刺さります。ゲーム的な派手さは、業務系の発注者には評価軸として存在しません。逆に、AIを組み込んだ対話機能を作っておくと、AIチャットボット・アプリ開発のお仕事のような領域の案件と話が噛み合います。この分野は問い合わせ対応や社内ヘルプデスクの自動化といった需要が続いており、小さな試作でも会話が成立しやすい題材です。

音や画像の処理を含むアプリを作った場合は、周辺分野の理解があることも一緒に示せます。たとえば効果音やジングルを扱うアプリなら、作曲・編曲・効果音・ジングルのお仕事で扱われるような制作側の事情を把握しているかどうかで、仕様の詰め方が変わってきます。技術だけでなく、その領域の作業がどう進むかを知っていることは、実績の少なさを補う材料になります。

ノーコードやローコードで作ったものは実績になるか

なります。ただし条件が付きます。

ノーコードツールで作ったものを「アプリを開発した」とだけ書くと、コードを書く前提の案件では期待とずれます。使ったツール名を明示し、そのツールでできる範囲とできない範囲を自分の言葉で説明できることがセットです。ここを曖昧にしたまま応募すると、着手後に「想定していたものと違う」となり、双方が損をします。

一方で、ノーコードは題材の数をこなすのに向いています。1本あたりの制作時間が短いので、層1から層4までの流れを何度も練習できます。コードを書く力とは別に、要件を聞いて形にする力を鍛える場としては悪くありません。ツール選びで迷うなら、まず無料枠のあるものを2つか3つ触ってみて、自分が作りたい種類のアプリと相性のいいものに絞るのが効率的です。

比較の観点としては、外部サービスとの連携のしやすさ、データのエクスポート可否、公開後の費用体系の3つを見るといいでしょう。特に3つ目は後から効いてきます。個人開発では無料枠で足りていたのに、案件で使ったら月額費用が発生し、その負担を誰が持つのかで揉めるという流れは珍しくありません。

費用をかける場所と、無料で足りる場所

実績ゼロの段階で費用をかける価値があるのは、次の2つに限られます。

1つはストア登録料です。iOS向けの開発者プログラムは年間費用が発生し、Androidは初回登録時に費用がかかります。ストアに実際に並んでいる状態は、それ自体が確認材料として強いので、狙う領域がモバイルアプリなら投資の意味があります。ただし、Web系の案件を狙うなら不要です。

もう1つは独自ドメインです。ポートフォリオの置き場所が無料サービスのサブドメインのままでも実害はありませんが、連絡先メールをドメインと揃えられる点で、年間2,000円前後の支出には見合います。

それ以外はほぼ無料で揃います。ソースコードの公開場所、静的サイトの公開、簡易なデータベース、エラー監視まで、個人利用の範囲なら無料枠で足ります。有料の学習教材やスクールに先にお金を投じるより、作ったものを置く場所を整えるほうが、実績ゼロの解消には直結します。

制作物の見せ方そのものについては、職種が違っても考え方は共通する部分が多く、Webライターのポートフォリオの作り方｜案件獲得率が上がるテンプレート付き【2026年版】では、掲載順序や実績の書き方といった構成面が整理されています。アプリ開発に置き換えて読むと、並べ方の参考になります。

ポートフォリオページに書く項目の並べ方

具体的な項目を挙げます。1本あたり次の順で書くと、読み手が判断しやすい並びになります。

最初にアプリ名と1行説明。次に対応プラットフォームと使用技術。その次に、制作期間と自分が担当した範囲。ここまでで相手は「規模感」を掴みます。続けて、解決しようとした課題、実装で工夫した点、意図的に作らなかった機能。最後に、動くものへのリンクと操作録画を置きます。

制作期間は正直に書きます。3ヶ月かかったものを1ヶ月と書いても、着手後の進行で見抜かれます。むしろ、時間がかかった理由が明確なら、それは見積もりの精度が上がっている証拠として読まれます。

担当範囲の明示も重要です。学習教材のコードをベースにしたなら、そう書いたうえで自分が追加した部分を書く。この誠実さは、実務が始まってからの信頼に効きます。

書類としての体裁を整える力そのものが評価される場面もあります。仕様書や報告書の書き方に自信がないなら、ビジネス文書検定のような体系で基本の型を確認しておくと、提案資料の読みやすさが安定します。技術力の証明とは別に、伝える力の裏付けとして機能する場面があります。

やりがちな失敗のパターン

実績ゼロの状態でつまずきやすいポイントを挙げておきます。

1つ目は、完璧を目指して公開しないことです。デザインが気に入らない、機能が足りない、と手を入れ続けて公開しないまま数ヶ月が過ぎる。この状態は、外から見れば実績ゼロのままです。粗くても公開して、そこから直したほうが層4の記録も貯まります。

2つ目は、技術の羅列で終わることです。使用言語やフレームワークの名前を並べただけのページは、判断材料になりません。何を作ったかが先で、何で作ったかは後です。

3つ目は、リンク切れです。デモ用のサービスが無料枠の期限で停止していたり、動画が非公開になっていたりする。これは印象を大きく損ないます。月に1度は自分でリンクを踏んで確認する運用にしておくと安全です。

4つ目は、案件の相場観を持たずに応募することです。自分の作業がどの程度の金額帯に相当するのかを知らないまま単価を提示すると、安すぎて後で苦しくなるか、高すぎて土俵に乗らないかのどちらかになります。ソフトウェア作成者の年収・単価相場では職種別の水準がまとめられているので、提示額を決める前に一度見ておくと基準ができます。単価の考え方については、Webライターが文字単価を上げる方法｜1円→5円にステップアップする戦略【2026年版】で扱われている段階的な引き上げの発想が、職種を越えて応用できます。

ソースコードを公開するとき、どこが見られているか

コードを公開する場合、読まれるのは実装の巧拙だけではありません。むしろ、次の3点のほうが先に見られる傾向があります。

1つ目は、説明ファイルが整っているかどうかです。リポジトリを開いて最初に表示される説明に、何のアプリか、どう動かすか、必要な環境は何かが書かれていないと、それ以上読み進めてもらえません。ここは技術的な難易度がゼロなのに、抜けている人が多い部分です。動かし方の手順を上から順に実行して、初見の人が起動できるかを一度確認しておくと確実です。

2つ目は、変更履歴の粒度です。全ファイルをまとめて1回で登録した履歴と、機能単位で分けて記録された履歴とでは、実務での進め方の想像しやすさが違います。1回の記録に複数の目的を混ぜないこと、記録の説明文を「更新」だけで済ませないことの2点を守るだけで、履歴は読める資料に変わります。実務のアプリ開発では、不具合が出たときにどの変更が原因かを追う作業が必ず発生するため、履歴を意識して残せる人は現場での扱いやすさが違います。

3つ目は、動作確認の仕組みがあるかどうかです。網羅的な自動テストまでは求められませんが、主要な処理に対して確認用のコードが数本あるだけで印象が変わります。テストがゼロのリポジトリと、少数でもテストが動くリポジトリでは、納品後の修正を任せられるかどうかの見立てが変わるからです。

なお、コードを公開しない選択も普通にあります。学習教材のコードを多く含む場合や、後述する権利関係が整理できていない場合は、無理に公開せず、層2と層3の記録だけを見せるほうが安全です。

公開する前に外しておくべきもの

見せる作業と同じくらい重要なのが、見せてはいけないものを外す作業です。ここを飛ばすと、実績を作るつもりが信用を落とす結果になります。

最初に確認すべきは接続情報です。外部サービスの認証キーや、データベースへの接続文字列がコードに直接書かれたまま公開されている例は、個人開発では珍しくありません。設定ファイルを公開対象から除外する仕組みを使い、公開前に全ファイルを検索して該当する文字列が残っていないかを確認します。一度公開してしまうと履歴に残るため、削除しただけでは対処になりません。該当するキーは失効させて発行し直すのが正しい手順です。

次に素材の権利関係です。アイコン、フォント、効果音、画像には、それぞれ利用条件があります。個人の学習目的では許諾されていても、仕事の提案材料として公開すると条件から外れる場合があります。使用した素材の入手元と条件を一覧にしておくと、後から確認するときに手間がかかりません。この整理をしておくこと自体が、権利まわりに配慮できる相手だという材料になります。

3つ目は個人情報です。テスト用に自分や家族の実データを入れたまま画面を録画してしまう事故が起きやすい部分です。氏名、住所、電話番号、メールアドレスは、公開用の記録を撮る前にすべて架空の値に置き換えます。「山田太郎様」「株式会社〇〇」のようなテンプレート的な値にしておけば、見る側も例示だと理解できます。

もし過去に業務委託で関わった案件がある場合は、守秘義務の範囲を必ず確認します。契約書に秘密保持の条項があるなら、案件名や画面を出すことはできません。この場合でも、担当した技術領域と作業の種類だけを抽象的に書くことは可能なケースが多いので、まず契約書を読み直すところから始めます。

整える前と整えた後で、伝わり方はどう変わるか

同じ制作物でも、記録の有無で読まれ方が変わります。違いを整理すると次のようになります。

項目	整える前	整えた後
最初に伝わること	使用技術の名前	何を解決するアプリか
確認の手間	相手が環境を用意する必要がある	リンクを開けば触れる
品質の根拠	見た目の印象のみ	設計判断と修正履歴
納品後の不安	判断材料がない	運用時の対応記録がある
金額の話	相場の当てはめ	作業範囲からの積み上げ

表の右側は、いずれも制作物を追加で作らなくても実現できます。すでに作ったものに対して、記録を書き、置き場所を整え、確認できる状態にするだけです。実績ゼロという状態の多くは、この作業が未着手なだけだと考えて差し支えありません。

特に最下段は見落とされがちです。作業範囲を分解して書けるようになると、見積もりが「なんとなくこのくらい」から「この作業が何時間、この作業が何時間」に変わります。発注側にとっても、削れる部分と削れない部分が見えるので、予算に合わせた調整の相談がしやすくなります。

資格や学習歴は実績の代わりになるか

部分的にはなります。ただし、動くものの代わりにはなりません。

資格が効くのは、発注側が実務経験を確認できない場面で、最低限の知識水準を示す用途です。ネットワークやインフラの理解が必要な案件では、CCNA（シスコ技術者認定）のような認定が、サーバー側の話が通じる相手だという合図になります。アプリ単体の制作案件では影響は限定的ですが、システム連携を伴う案件では判断材料の1つになります。

学習歴については、修了証よりも、そこで何を作ったかが問われます。カリキュラムを終えたこと自体は評価対象になりにくく、課題として作ったものを自分なりに改造した記録があるかどうかで差が出ます。

案件の規模ごとに、どこまで見せれば足りるか

見せる材料の量は、狙う案件の規模で変えて構いません。すべての案件に同じ厚さの資料を出す必要はありません。

小規模の修正案件、たとえば既存アプリの画面文言の変更や軽微な不具合対応であれば、層1と層2で足ります。動くものが1本あり、操作の様子が分かれば、発注側は「触れる人だ」と判断できます。この規模で設計思想の長文を出しても、読まれずに終わることが多いでしょう。

中規模の新規制作、画面数が数枚から十数枚あるような案件では、層3が効いてきます。要件をどう固めたか、どこを削ったかを書いた記録があると、発注側は自分の案件に置き換えて進行を想像できます。ここで差がつくので、狙いたい規模がこの帯なら、記録の作成に時間を使う価値があります。

長期の保守を含む案件では、層4が判断を左右します。不具合をどう見つけ、どう直したかの記録がある人と、作りっぱなしの人とでは、任せられる範囲が変わります。保守込みの案件は継続性があるため、実績ゼロの段階から狙うなら、運用記録を最優先で整えるのが合理的です。

つまり、どの層に力を入れるかは、自分が受けたい仕事の形から逆算して決めます。全部を同時に完璧にしようとすると、また公開が遅れます。まずは狙う帯を1つ決めて、そこに必要な層から埋めていくほうが早く前に進みます。

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

在宅ワークと業務委託の市場を長く運営してきた立場から見ると、実績ゼロから抜ける人と抜けられない人の差は、技術の習得速度ではないところに現れます。

抜ける人は、作ったものを人に見せる回数が多い。完成前でも触ってもらい、反応をもらい、直す。この往復の回数が、そのまま説明のうまさに変わっていきます。逆に、抜けられない人は完成まで誰にも見せません。結果として、他人が何を分かりにくいと感じるのかを知らないまま完成させてしまい、ポートフォリオも自分にしか分からない書き方になります。

もう1つ、長く仕事が続く人に共通しているのは、単発の制作ではなく「この人に頼むと楽だ」という状態を作りにいっていることです。連絡が返ってくる、確認事項が整理されている、変更の相談に理由を添えて答える。この積み重ねは技術力の指標ではありませんが、次の依頼を呼ぶ要因としては技術力より強く働きます。実績ゼロの段階でも、この振る舞いは今日から実践できます。

そして構造の話をすると、仲介の中間マージンが乗らない直接取引では、同じ予算でも依頼側はより多くを頼めて、受け手の手取りは厚くなります。手数料0%という条件は、金額の大小の話に見えて、実際には「同じ仕事で残る額が違う」という質の話です。運営者として見てきた限りでは、手取りが厚い側で実績を積んだ人のほうが、単価交渉の場面で無理な値下げに応じずに済んでいます。

見せ方を整えることが、次の案件の設計になる

ここまで書いてきた4つの層は、単にポートフォリオを飾るための作業ではありません。層3の設計記録は見積もりの根拠になり、層4の運用記録は保守範囲を決める材料になります。つまり、実績ゼロを埋める作業と、案件を安全に進めるための準備は同じ作業です。

案件の探し方についても、領域を絞って情報を集めたほうが噛み合いが良くなります。AI活用やセキュリティ周辺の需要動向は、AI・マーケティング・セキュリティのお仕事で扱われている業務の広がりを見ると掴みやすく、自分の制作物をどの文脈に置けば読まれるかの判断がしやすくなります。文章での説明力を高めたい場合は、著述家，記者，編集者の年収・単価相場のような周辺職種の相場を見ておくと、ドキュメント作成を含む案件で自分の作業量をどう値付けするかの参考になります。

実績ゼロは、時間が解決する問題ではありません。作ったものを置き、判断の跡を書き、触れる状態にしておく。この3つが揃った時点で、実績ゼロという言葉は当てはまらなくなります。

よくある質問

Q. ストアに公開していないアプリでも実績として見せられますか？

見せられます。iOSならTestFlightの外部テスト、Androidならクローズドテストのリンクで相手に触ってもらえます。それも難しい場合は、主要画面をWebで再現したデモと30秒程度の操作録画を用意すれば、判断材料としては十分に機能します。相手にインストールの手間や設定変更を求めない形にすることが重要です。