アプリ開発のポートフォリオの作り方｜見る人が知りたいこと

2026年3月17日

丸山桃子

この記事のポイント

✓アプリ開発のポートフォリオを
✓発注者が判断できる形で作る手順を整理
✓見る人が最初に確認する項目

アプリ開発のポートフォリオを作ろうとして、最初に手が止まるのは「何を載せればいいか分からない」という段階だ。作ったアプリのスクリーンショットを並べ、使った言語を書き、GitHubのリンクを貼る。ここまでは誰でもたどり着く。ところが、それを見た発注者から反応がない。理由ははっきりしていて、発注者が知りたいことと、載せている内容がずれているからである。この記事では、アプリ開発のポートフォリオを「見る人が判断できる形」で作るための手順を、掲載項目、見せ方、置き場所、守秘義務との折り合いの順に整理する。

ポートフォリオは作品集ではなく判断材料

美術やデザインの世界では、ポートフォリオは作品集である。良い作品が並んでいれば、それだけで力量が伝わる。アプリ開発でも同じ感覚で作ってしまいがちだが、実務の場面で使われ方が違う。

発注者がポートフォリオを開くとき、頭にあるのは「この人に自分の案件を任せられるか」という一点である。作品の美しさではなく、自分の困りごとを解決してくれそうかどうかを見ている。だから、完成した画面よりも、どういう課題に対して何をどう判断したかのほうが重要になる。

この違いを押さえておくと、載せる内容が変わる。求められているのは、履歴書の技術欄では伝わらない「働き方の中身」である。

ポートフォリオは履歴書や職務経歴書と違って人材価値を判断することに重きを置かれています。そのため、ポートフォリオに記載する内容からも読み取れるように、実際にどのように働いたかをプロジェクト内容、自身の役割について具体的に示すことや成果物を通じて自身の技能スキルについて理解してもらうことが重要です。出典: staff.persol-xtech.co.jp

つまり、判断されているのは成果物そのものではなく、成果物に至るまでの働き方である。ここを理解しないままスクリーンショットを増やしても、評価は変わらない。

見る人は3種類いる

ポートフォリオを開く人は、立場によって見る場所が違う。誰が読むかを想定せずに作ると、どの層にも刺さらない中途半端なものになる。

発注者本人（事業側の担当者）

自社のアプリを作りたい、あるいは改修したい事業会社の担当者である。技術の細部は分からないことが多い。この層が見るのは、似た業種や似た規模の実績があるか、コミュニケーションが成立しそうか、納期を守りそうか、という点だ。専門用語の羅列は逆効果になる。

技術者（相手方の開発責任者）

チームに加わる形の案件では、相手側のエンジニアが確認する。この層は、使っている技術の選定理由、設計の考え方、テストやレビューへの姿勢を見る。ソースコードが公開されていれば読む。ここには具体的な技術の話が必要になる。

仲介する立場の人

エージェントやディレクターなど、案件と人をつなぐ立場の人である。この層は、案件の要件と照らして「該当するかどうか」を素早く判断したい。対応できるOS、経験のある領域、稼働の形といった条件が、探しやすい場所にまとまっていることを求める。

3種類のうち誰に読まれるかは選べない。だから、上から順に「概要が分かる」「実績の中身が分かる」「技術の細部が分かる」という階層構造にしておく。全員が最初のページで判断できるようにし、深く知りたい人だけが下へ進める形が理想である。

最初に見られるのは冒頭のわずかな部分

ポートフォリオを開いた人が、丁寧に全部読むことはまずない。最初の画面で判断され、興味を持たれなければ閉じられる。だから冒頭には、次の4点を短くまとめる。

・何ができる人か（対応領域を一文で）・どのOSとどの技術で作れるか・受けられる仕事の形（設計から作るのか、既存の改修なのか、運用も見るのか）・連絡先

この4点が最初の画面に収まっていれば、仲介者は条件と照らして判断でき、発注者は自分の案件に合うかを判断できる。逆に、いきなり作品のスクリーンショットが並んでいると、読み手は自分で情報を探すことになり、そこで離脱する。

1本の掲載に必ず入れる項目

実績を1本載せるとき、次の項目をそろえる。順番も、この順にすると読みやすい。

何を解決したか

そのアプリが誰のどんな困りごとを解決するために作られたのかを、一文で書く。技術の説明ではなく、事業や利用者の課題として書く。読み手はここで「自分の課題と近いか」を判断する。

自分が担当した範囲

もっとも重要な項目である。チームで作ったものなのか、ひとりで全部作ったのか。設計から入ったのか、実装だけだったのか。デザインは誰が作ったのか。ここを曖昧にすると、相手は実力を測れず、結果として過小評価する。

「担当：iOS版のアプリ全般（設計、実装、ストア申請）。サーバー側は別の担当者、デザインは依頼者側の指定」といった書き方で、自分の線引きをはっきりさせる。範囲が狭いことを恥じる必要はない。曖昧なほうが評価を下げる。

技術構成

言語、フレームワーク、使用したライブラリ、通信の方式、データの保存先、CI/CDの構成を並べる。ここは技術者向けの項目なので、正確さを優先する。バージョンまで書けるなら書いておく。

制約条件

期間、人数、対応が必要だったOSのバージョン、既存システムとの接続の有無、予算以外の縛り。この項目があるかないかで、読み手の印象が大きく変わる。制約の中で成立させた経験は、実務では高く評価される。

判断したこと

技術選定や設計で迷った点と、なぜその選択をしたかを書く。たとえば、ネイティブとクロスプラットフォームのどちらを選んだか、その理由は何か。ここが書けている人は少なく、書けていると強く印象に残る。判断の記録は、他人には真似できない固有の内容だからである。

結果

リリースできたか、どう使われているか、公開後に何を改善したか。数字が出せない場合でも、「リリース後に届いた要望をもとに検索機能を追加した」といった事実で構わない。運用まで見ていることが伝わる。

見せられない部分の扱い

守秘義務でソースコードや画面を出せない場合は、「機密保持のため画面は掲載していません」と明記したうえで、担当範囲と技術構成だけを書く。隠していることを明示するほうが、曖昧にぼかすより信頼される。

見せられる作品がないときの作り方

受注実績がない、あるいは実績がすべて非公開という場合、ゼロから作る必要がある。ここでよく起きる失敗は、チュートリアルをなぞっただけのアプリを載せてしまうことだ。同じ教材から作られたものは読み手が見慣れており、判断材料にならない。

作るなら、次の条件を満たすものを選ぶ。

自分か身近な人が実際に困っていることを解決するもの。 課題が実在すると、仕様を自分で決める必要が生まれ、そこに判断が発生する。判断があるから書くことができる。

外部のAPIやデータと連携するもの。 通信の失敗、認証、レスポンスの遅延といった、実務で必ず出てくる課題に触れられる。ローカルで完結するアプリでは、この経験が積めない。

実際に公開まで持っていくもの。 ストアの審査を通す経験は、それ自体が実務の一部である。審査で何を指摘され、どう直したかは、ポートフォリオに書ける貴重な内容になる。

継続して手を入れているもの。 一度作って放置したものより、更新履歴が続いているもののほうが、運用への姿勢が伝わる。

作ったものを載せるときは、その動機まで書く。「この作業に毎日時間を取られていたので自動化した」という背景があるだけで、単なる練習作品ではなく、課題解決の記録として読める。

守秘義務との折り合い

受注した案件は、多くが秘密保持契約の対象になっている。ここを軽く扱うと、業界内で信用を失う。公開する前に、必ず次を確認する。

・契約書に、実績の公開に関する条項があるか・依頼者名を出してよいか・画面のスクリーンショットを出してよいか・ソースコードの一部でも公開してよいか

条項が見当たらない場合でも、勝手に判断せず、依頼者に一言確認する。「実績として掲載したいのですが、どこまでなら公開してよいでしょうか」と聞けば、たいていは範囲を示してもらえる。この確認をしたという事実自体が、次の依頼者への信頼材料になる。

公開できない場合の書き方には型がある。「金融系の事業会社向け、社内利用の業務アプリ」のように、業種と用途だけを書き、企業名を伏せる。画面はダミーデータに差し替えたものを自作するか、構成図だけを載せる。伏せていることを明記したうえで、担当範囲と技術構成を丁寧に書けば、判断材料としては十分に機能する。

置き場所をどう選ぶか

ポートフォリオをどこに置くかは、読み手の3種類を思い出して決める。

自前のWebサイト。 もっとも自由度が高く、アプリ開発者であれば作れること自体が示せる。デザインを凝る必要はない。読みやすさと、更新しやすさを優先する。独自ドメインで運用しておくと、メールアドレスもそろえられる。

ソースコードの公開場所。 技術者向けには必須に近い。ただし、リポジトリを並べただけでは読まれない。それぞれのリポジトリの説明文に、何を解決するものかと自分の担当範囲を書いておく。コミットの粒度やコミットメッセージも見られていると考えたほうがよい。

文書共有サービス。 手早く作れるのが利点で、更新も楽である。ただし、閲覧権限の設定を間違えると非公開のはずの情報が出てしまう。公開範囲は必ず確認する。

PDF。 相手から求められたときに送る形として用意しておく。企業によっては、社内で回覧するためにファイルの形を求められる。Webサイトの内容をそのまま書き出せる状態にしておくと手間がない。

どれか一つに絞る必要はない。中心となる置き場所を一つ決め、他はそこへ誘導する形にすると、更新の手間が分散しない。

画面と動画の見せ方

アプリの場合、静止画だけでは動きが伝わらない。次の3種類を用意すると、読み手の理解が早い。

主要画面のスクリーンショット。 端末の枠にはめた画像にすると、実機の見え方が伝わる。載せる枚数は絞る。全画面を並べるより、代表的な数枚のほうが読まれる。

操作の様子を撮った短い動画。 画面収録で構わない。長さは30秒程度に収める。起動から主要な機能を使うまでの流れを、無音で見せる。

構成図。 アプリ、サーバー、外部サービスの関係を1枚の図にする。技術者はここを見て設計の考え方を判断する。手書きを撮影したものでも、伝われば問題ない。

視覚的な要素の効果については、次のように整理されている。

ポートフォリオを作成する最大のメリットは、自分の実績や能力を相手にアピールすることができる点です。過去に参画したプロジェクトの内容や自身の担った役割、使用したツールなどを明示することができます。さらに、実際に作成したアプリケーションやサービスなどがあれば、画像やデモ映像を盛り込むことで文字では伝えられない要素を具体的に視覚的に訴えかけることができます。

画像や動画は、文章の代わりではなく、文章を補うものとして置く。画像だけを並べて説明がない状態は、読み手に解釈の負担を押しつけることになる。

文章の書き方で差がつく

技術者のポートフォリオで意外に差がつくのが、文章である。同じ実績でも、書き方によって伝わり方がまったく変わる。

主語と担当範囲を明確にする。「開発しました」ではなく「iOS版の設計と実装を担当しました」と書く。誰が何をしたかが分かる文にする。

専門用語には短い補足を添える。技術者以外も読むため、「オフラインでも使えるようにローカルにデータを保持する仕組み」といった説明を一言入れておくと、事業側の担当者にも伝わる。

長い一文にしない。一文に複数の情報を詰め込むと、読み手が理解に時間を使う。句点で区切り、一文一情報を守る。

誇張しない。「大幅に改善」「劇的に高速化」といった形容は、根拠がないと軽く見える。具体的に何をどう変えたかを書くほうが、結果として強く伝わる。

文書の書き方そのものに不安がある場合は、業務文書の型を体系的に学べるビジネス文書検定の学習範囲が参考になる。提案書や報告書の構成を押さえておくと、ポートフォリオだけでなく、受注後のやり取りでも役に立つ。

面談で聞かれることを先に書いておく

ポートフォリオを見た相手は、興味を持つと面談を申し込んでくる。そこで聞かれる質問は、案件が変わってもだいたい同じである。よく出るのは次の質問だ。

・その案件で一番苦労した点は何か・仕様が途中で変わったとき、どう対応したか・不具合が出たときの調べ方はどうしているか・テストはどこまでやるか・他のメンバーとどう分担したか・自分が担当していない部分について、どこまで把握していたか

これらの答えを、あらかじめポートフォリオの各実績に書いておく。面談の時間を節約できるだけでなく、書いてあること自体が「聞かれる前に用意している人」という評価につながる。

特に「苦労した点」と「その解決方法」は、書いてある人が少ない。うまくいった話ばかりが並んでいると、読み手は現実味を感じない。詰まったところと、そこをどう抜けたかが書いてあるほうが、実際に手を動かした人の記録として読める。失敗の記録は弱みではなく、同じ問題に二度目で当たったときの速さの裏づけになる。

書き方としては、事実だけを短く書く。「特定の端末でだけ起きる表示崩れが出た。原因は端末側の画面比率の扱いで、レイアウトの指定方法を変えて解決した」といった程度でよい。長い反省文は必要ない。

スマートフォンでの見え方を先に確認する

見落とされやすいのが、ポートフォリオ自体の表示である。発注者は移動中にスマートフォンで開くことが多い。パソコンの画面で整えたつもりでも、狭い画面では読めない状態になっていることがある。

確認したいのは次の点だ。横に長い表がはみ出していないか。構成図の文字が小さすぎて読めなくなっていないか。画像の読み込みで待たされていないか。連絡先のボタンが押せる大きさになっているか。

アプリ開発者のポートフォリオが、スマートフォンで崩れているという状態は、それだけで評価を下げる。作れる人が自分のサイトを整えていない、という印象になるからである。公開する前に、実際に手元の端末で開いて、上から下まで一度読み通しておく。

読み込みの速さも同じ理由で見られている。画像は表示に必要な大きさまで縮小してから置き、枚数を絞る。動画は自動再生にせず、押したときだけ再生される形にしておくと、通信量を気にする相手にも配慮できる。

経歴の書き方でつまずかないために

実績の一覧とは別に、経歴の欄も置いておく。ここで気をつけたいのは、時系列を並べるだけにしないことだ。

書くのは、どの領域で何年やってきたかではなく、何ができるようになったかの推移である。「業務アプリの改修から入り、その後は設計から任されるようになった」「個人開発から始め、チーム開発でのレビューを経験した」といった形で、担当範囲の変化が見えるようにする。

会社員として働いた期間がある場合、社名を出せないことがある。その場合は「受託開発の企業で、業務アプリの開発を担当」といった書き方にする。社名がなくても、規模と領域が分かれば判断材料になる。

空白の期間がある場合も、隠さずに書く。学習に充てた、家庭の事情があった、別の職種にいた。理由を一行書いておけば、それ以上は聞かれない。空白を飛ばして書くと、日付の計算で必ず気づかれ、かえって説明が必要になる。

更新をどう続けるか

ポートフォリオは、作って終わりにすると急速に価値を失う。最終更新が古いままだと、活動していない人に見える。

続けるための実務的な工夫は、案件が終わった直後に書くことである。時間が経つと、判断の理由も制約条件も思い出せなくなる。納品の直後、記憶が新しいうちに、担当範囲と技術構成、判断した点をメモしておく。公開の許可が下りるまでは非公開の下書きに置いておき、許可が出たら公開する。

すべての案件を載せる必要はない。載せるのは、これから受けたい仕事に近いものだけでよい。むしろ、方向性の違う実績が並んでいると、何ができる人なのかが伝わりにくくなる。受けたい仕事が変わったら、掲載を入れ替える。

稼働の条件と受け方を明記する

実績の掲載に力を入れる一方で、抜けやすいのが「どう仕事を受けられるか」の記載である。読み手が実績を気に入っても、条件が合わなければ連絡は来ない。逆に、条件が書いてあれば、合わない相手からの問い合わせが減り、対応の手間が下がる。

書いておきたいのは次の項目だ。

・稼働できる曜日と時間帯・打ち合わせに出られる時間の範囲・対応できる連絡手段・遠方でも受けられるか、対面が必要な案件は可能か・引き受けられる仕事の形（設計から、実装のみ、既存アプリの改修、運用と保守）・現在の受付状況（新規を受け付けているかどうか）

特に最後の受付状況は重要である。忙しくて受けられない時期に問い合わせが来ると、断る手間が発生し、相手にも無駄足を踏ませる。「現在は新規の相談を受け付けています」「〇月以降であれば相談可能です」と書いておくだけで、双方の時間が節約できる。

条件を書くと仕事の幅が狭まると考える人がいるが、実際は逆になることが多い。条件が明示されている相手のほうが、依頼する側は段取りを組みやすい。条件が書かれていないと、問い合わせる前に「そもそも受けてもらえるのか」という確認から始まり、その一手間で見送られる。

やりがちな失敗

技術の一覧だけを並べる。 使える言語やフレームワークの名前を羅列しただけでは、どの程度使えるのかが伝わらない。どの案件でどう使ったかとセットにする。

担当範囲を書かない。 チーム開発の成果を、あたかも一人でやったように見せる書き方は、面談で必ず崩れる。信用を失う代償のほうが大きい。

リンクが切れている。 公開を終了したアプリのストアリンクや、削除したリポジトリへのリンクが残っていると、確認する側の手が止まる。定期的に全リンクを開いて確認する。

連絡先が見つからない。 興味を持った相手が連絡できないという事態は、実際によく起きる。最初の画面と最後の画面の両方に連絡先を置く。

読み込みが遅い。 画像を圧縮せずに大量に置くと、開くまでに時間がかかる。スマートフォンから見る相手も多いため、表示の速さは無視できない。

開発以外の記録も判断材料になる

アプリを作った実績だけがポートフォリオの中身ではない。実務で依頼者が評価するのは、開発の前後にある動きでもある。次のようなものは、載せておくと効く。

要件を整理した資料。 依頼者の話を聞いて、機能の一覧や画面の遷移に落とし込んだ資料は、そのまま思考の記録になる。企業名や具体的な内容を伏せ、構成だけを見せる形でも十分に伝わる。

技術の選定を比較した記録。 複数の選択肢を並べ、条件ごとに評価して選んだ過程を残す。結論だけでなく、何を基準に比べたかが読み手には価値がある。

運用のための手順書。 リリースの手順、障害時の対応、環境の構築方法をまとめた文書は、引き継ぎを想定して動ける人だという証明になる。

不具合の調査記録。 現象、切り分けの手順、原因、対処の順に整理したものを1本置いておく。調べ方の型を持っているかどうかは、実務で最も差が出る部分である。

これらは見た目が地味で、載せる人が少ない。だからこそ、置いてあると目に留まる。派手な画面のスクリーンショットより、こうした記録のほうが「任せたあとが楽そうだ」という判断につながる。

20年この市場を見てきて分かること

在宅ワークと業務委託の市場を長く運営してきた立場から見ると、依頼が集まる人のポートフォリオには共通点がある。作品の数が多いわけでも、技術が最先端なわけでもない。共通しているのは、「この人に頼むと、こちらが何を考えなくて済むか」が読み取れることだ。

制約の中でどう判断したかが書いてある。公開できない部分は正直に書いてある。運用まで見た形跡がある。この3つがそろっていると、依頼する側は「任せたあとの手間が少なそうだ」と感じる。発注者が本当に恐れているのは技術力の不足ではなく、途中で止まることや、細かい確認が延々と発生することである。

もうひとつ、長く続く人は、ポートフォリオを営業の道具としてだけでなく、自分の記録として使っている。案件が終わるたびに、何を判断したかを書き残していく。それが積み上がると、次の案件で似た判断をするときの土台になる。書くこと自体が、実務の質を上げている。

そして、中間に事業者が入らない直接の取引では、依頼者はポートフォリオを見て直接判断し、そのまま連絡してくる。間に人が入らないぶん、書いてある内容がそのまま判断材料になる。手数料0%の直接取引では、依頼者が払う金額が中間で目減りしないため、同じ予算でより深い関わり方を頼める。その入口になるのがポートフォリオである。誰かが要約して伝えてくれるわけではないぶん、自分で正確に書いておく必要がある。

領域を広げるときの見せ方

アプリ開発の周辺には、隣接する領域がいくつもある。ポートフォリオを更新するとき、どの方向へ広げるかで載せる内容も変わる。

AIを組み込んだ機能の実装は、既存のアプリ開発から地続きで広げやすい領域である。この分野で求められる業務の中身はAIチャットボット・アプリ開発のお仕事にまとまっている。対話機能を組み込んだ実績が1本あるだけで、相談される内容が変わってくる。

マーケティングやセキュリティと組み合わせる道もある。AI・マーケティング・セキュリティのお仕事では、開発の前後にある分析や運用まで含めた業務の範囲を確認できる。計測の設計まで担当した実績は、事業側の担当者に強く響く。

画面の設計や使い勝手の改善まで踏み込みたい場合は、UI/UXデザインのフリーランスになるには？必要スキルと案件相場が参考になる。実装だけでなく画面設計から関われると、ポートフォリオに書ける「判断したこと」が一段深くなる。

ブロックチェーンや分散型の技術を扱う領域に関心があるなら、Web3 フリーランスの年収と案件獲得術！2026年最新ガイドで必要なスキルの輪郭がつかめる。新しい領域は実績のある人が少ないため、動くものを1本作って公開しておくだけで、目に留まりやすい。

自分の技術がどのあたりの水準に位置するかを客観的に確かめておきたいときは、職業分類にもとづいて整理されたソフトウェア作成者の年収・単価相場も合わせて見ておくとよい。ポートフォリオで打ち出す領域を決めるときの判断材料になる。

ポートフォリオは、完成させるものではなく、更新し続けるものである。今日の時点で書けることを書き、案件が終わるたびに足していく。その積み重ねが、次の依頼を連れてくる。

よくある質問

Q. 実務経験がなくてもポートフォリオは作れますか？

作れる。ただしチュートリアルをなぞっただけのアプリは読み手が見慣れており、判断材料にならない。自分か身近な人が実際に困っていることを解決するもの、外部のAPIと連携するもの、ストアの審査まで通したものを選ぶ。仕様を自分で決める必要があるため、そこに判断が生まれ、書ける内容ができる。作った動機まで添えると、練習作品ではなく課題解決の記録として読まれる。

Q. 守秘義務がある案件はどう載せればよいですか？

まず契約書に実績公開の条項があるかを確認し、なければ依頼者に「どこまで公開してよいか」を直接聞く。公開できない場合は、企業名を伏せて業種と用途だけを書き、画面はダミーデータで作り直すか構成図に置き換える。伏せていることを明記したうえで、担当範囲と技術構成を丁寧に書けば判断材料としては十分に機能する。

Q. 掲載する実績は何本くらいがよいですか？

本数より、これから受けたい仕事に近いかどうかで選ぶ。方向性の違う実績が並ぶと、何ができる人なのかが伝わりにくくなる。受けたい領域に近いものを厳選し、1本ずつ担当範囲と制約条件、判断した理由まで書き込む。浅い実績を多く並べるより、深く書かれた数本のほうが、読み手は判断しやすい。

Q. ソースコードは公開したほうがよいですか？

相手側の技術者が確認する案件では有効に働く。ただしリポジトリを並べるだけでは読まれないため、それぞれの説明文に何を解決するものかと自分の担当範囲を書いておく。コミットの粒度やメッセージの書き方も見られていると考えたほうがよい。受注案件のコードは契約上公開できないことがほとんどなので、自作したものに限る。