アプリ開発の実績の見せ方｜出せない仕事をどう伝えるか

アプリ開発の実績を見せるとき、最大の壁は「作ったものの多くが公開できない」ことです。受託した業務用アプリ、下請けとして関わった案件、社内向けのシステム。画面も名前も出せない仕事ほど、技術的には価値があります。この記事では、アプリ開発の実績の見せ方を、出せない仕事の扱い方を中心に整理します。結論から言うと、実績は「作ったもの」ではなく「解いた問題」で組み立てると、公開できない案件でも伝わります。

実績で発注者が確認していること

見せ方を考える前に、相手が何を見ているかを整理します。ここを外すと、労力をかけたポートフォリオが機能しません。

発注者が確認しているのは三つ

発注を検討している人が実績から読み取ろうとしているのは、次の三点です。

ひとつ目は、自分の案件と近いことをやったことがあるか。技術的な近さだけでなく、業種や利用者の近さも含みます。ふたつ目は、どこまで自分でできるか。設計から入れるのか、指示された実装だけなのか。三つ目は、仕事の進め方が合いそうか。文章の書き方、説明の丁寧さ、範囲の説明の仕方から判断されます。

この三つは、いずれも画面のスクリーンショットからは読み取れません。読み取れるのは見た目の傾向だけです。だからこそ、実績は文章で組み立てる必要があります。

画面の一覧だけでは判断材料にならない

作ったアプリの画面を並べただけのポートフォリオは、デザイナーの実績としては機能しますが、開発者の実績としては機能が弱いです。画面から読み取れるのはデザインの質であり、その裏で何を設計したかは見えません。

正直なところ、画面が出せないことを理由にポートフォリオを作らない人が多いのですが、そもそも画面は必須ではありません。必要なのは、課題と担当範囲と判断の記録です。

事例の書かれ方を参考にする

開発会社が公開している導入事例は、書き方の参考になります。何を作ったかだけでなく、どういう狙いでその形にしたのかが書かれているものは説得力があります。

株式会社クラシコムの公式アプリでは、ECサイトと連動したアプリ開発によって顧客体験の向上を実現しました。UXにこだわってビデオミニYouTubeプレイヤーとラジオミニRadioプレイヤーというユニークなコンテンツを搭載し、単なるECアプリではなくメディアアプリとしての立ち位置を確立しています。 出典: sun-asterisk.com

この書き方の要点は、機能の羅列ではなく「何を狙って何を選んだか」が書かれていることです。個人の実績も同じ構造で書けます。

出せない仕事をどう伝えるか

ここが本題です。守秘義務がある案件を、違反せずに実績として使う方法を段階的に整理します。

まず契約書のどこを見るか

最初にやることは、契約書と秘密保持契約の条項を読み直すことです。確認するのは四点あります。

秘密情報の定義。何が秘密情報にあたるのかが書かれています。「開示された情報すべて」となっているのか、「秘密である旨を明示したもの」に限られるのかで、扱える範囲が大きく変わります。

次に、義務の期間。契約終了後も何年か続く形が一般的です。三つ目に、例外の規定。公知の情報や、開示前から自分が持っていた情報は対象外とされているのが通常です。四つ目に、実績公開に関する条項があるかどうか。契約書に「実績としての公表は事前の書面承諾を要する」と書かれていることがあります。

※契約書の解釈に迷う場合は、自己判断で公開せず、発注者に確認するか専門家に相談してください。

公開の許可を取りにいく手順

読んだ結果、公開が禁止されているとは限りません。多くの場合、聞けば許可が出ます。聞かないまま「たぶんダメだろう」と諦めているケースがかなりあります。

聞くタイミングは、納品後の落ち着いた時期が適しています。聞き方は、範囲を限定して具体的に示すのが有効です。「実績として掲載したい」という漠然とした依頼より、「クライアント名は伏せて、業種と担当した機能の概要のみ掲載したい」という具体的な依頼のほうが承諾されやすくなります。

さらに確率を上げるなら、掲載する文面をこちらで作って添付します。相手は判断するだけで済むので、返答が早くなります。承諾を得たら、必ずメールなど文書で残してください。

許可が出ないときの抽象化の段階

許可が出ない場合、情報を段階的に抽象化します。抽象化には次のような段階があります。

第一段階は、企業名だけを伏せる形です。「大手アパレル企業」「地域密着型の飲食チェーン」といった書き方にします。第二段階は、サービス名と画面を出さず、業種と規模感だけにします。第三段階は、案件そのものを特定させず、技術的な課題と解決方法だけを書きます。「在庫データを扱う業務アプリで、通信が不安定な環境でも入力を継続できる仕組みを設計した」という形です。

第三段階まで抽象化すれば、多くの場合は守秘義務に触れません。それでも技術的な力量は十分に伝わります。むしろ、課題と解決に絞られる分、読み手には分かりやすくなることがあります。

抽象化してよい情報と、してはいけない情報

抽象化すれば何でも書いてよいわけではありません。組み合わせから特定できてしまう情報には注意が必要です。

業種と地域と規模を三つ並べると、業界の人には特定できてしまうことがあります。「関西の中堅アパレル企業で、店舗数がこの規模」といった書き方は危険です。抽象化する際は、要素を一つずつ確認するのではなく、書いた文章全体を読んで特定できないかを確認します。

また、発注者の事業戦略に関わる情報は、抽象化しても書くべきではありません。まだ公表されていない新サービスの構想、社内の課題、組織の事情。これらは技術の話ではないので、実績の説明に必要ありません。

下請けや再委託の立場のとき

元請けの会社を通して参加した案件では、最終的な発注者との直接の契約がありません。この場合、実績として書けるかどうかは元請けとの契約次第です。元請けに確認を取るのが筋であり、最終発注者に直接聞くのは避けます。

書き方としては、「開発会社を通じて参加した業務用アプリの開発で、認証まわりの実装とテストを担当」という形になります。案件を特定せず、自分の担当範囲を明確にする書き方です。

実績1件の書き方の型

抽象化の程度が決まったら、実際の文章に落とします。次の五つの要素で書くと、公開できる情報が少なくても内容が成立します。

課題

その案件で解決しようとした問題を、一文か二文で書きます。「紙で管理していた在庫の記録をアプリ化し、店舗と本部の在庫情報のずれをなくすことが目的」という形です。

ここが書けるかどうかが、実績の質を分けます。課題が書かれていない実績は、指示どおりに作っただけに見えます。課題を書ける人は、目的を理解して作ったと伝わります。

担当範囲

自分が何をやったかを、工程で書きます。要件の整理、画面設計、実装、テスト、リリース作業のうち、どこを担当したか。チームの一員だった場合は、その旨も書きます。

ここを曖昧にする人が多いのですが、後で必ず不利になります。面談で深掘りされたときに説明できないと、信頼を大きく損ないます。担当していない工程を書かないことは、実績の信頼性そのものを支えます。

技術の選択と、その理由

使った技術を並べるだけでなく、なぜそれを選んだかを一言添えます。「両方の端末に対応する必要があり、画面の作り込みより開発期間を優先したため、共通のフレームワークを採用」という形です。

理由が書かれていると、判断ができる人だと伝わります。技術名の羅列は誰でも書けますが、選択の理由は実際にやった人しか書けません。

工夫した点

技術的に難しかった箇所と、その解決方法を書きます。ここが最も差がつく部分です。

書く内容の例としては、通信が不安定な環境での動作をどう担保したか、データの整合性をどう保ったか、利用者の操作の手数をどう減らしたか、といったものです。守秘義務がある案件でも、技術的な工夫は抽象化して書けます。

ユーザーが必要とする体験や機能を具体化することは、アプリ開発の成否を決定づける重要な要素です。ユーザーに好まれるデザインや、意味のある関連機能は、使用者の満足度を大きく高めます。 出典: docodoor.co.jp

利用者にとって何がよくなったかという視点で書くと、技術に詳しくない発注者にも伝わります。

結果

数字が出せるなら出しますが、出せないことも多いです。出せない場合は、定性的な変化で書きます。「入力の手順が減り、店舗側の作業が現場で完結するようになった」という形です。

数字を書く場合は、必ず出典と測定条件を添えます。条件のない数字は、読む人に疑われるだけです。

見せる場所ごとの整え方

同じ実績でも、置く場所によって形を変える必要があります。

ポートフォリオサイト

自分のサイトに置く場合、一覧と詳細の二層にします。一覧では課題と担当範囲を一行ずつ、詳細で五要素をすべて書きます。

並べる順番は、時系列ではなく「取りたい案件に近い順」にします。業務用アプリの案件を取りたいなら業務用の実績を上に置きます。実績は履歴書ではないので、時系列に従う必要はありません。

提案書に載せる実績

提案書では、その案件と近い実績だけを二件から三件に絞ります。多く載せるほど印象が薄まります。絞ったうえで、「今回の案件と共通する点」を明記します。

共通点は技術だけでなく、利用者の性質や運用の制約でも構いません。「操作に不慣れな層が使う前提で画面を設計した経験」という共通点は、技術の一致より強く効くことがあります。

プロフィール欄

文字数の限られた欄では、実績の詳細は書けません。ここでは、担当できる工程と、扱ってきた領域を書きます。「業務用アプリの要件整理から実装、テストまで。在庫管理と店舗運営の領域が中心」という形です。

公開できるコードを用意する

守秘義務のある案件のコードは当然出せませんが、自分で作った小さなツールや部品なら公開できます。コードの書き方、命名、テストの有無、説明文の丁寧さは、実績の説明よりも直接的に力量を示します。

大きなアプリを作る必要はありません。実務で使えそうな小さな部品を、説明文つきで公開するほうが効果的です。

実績が少ないときの見せ方

これから始める段階では、実績そのものが足りません。この場合の組み立て方を整理します。

自作アプリは「課題設定」で差をつける

練習用に作ったアプリを実績として出す場合、機能の多さではなく課題設定で見せます。「身の回りの誰かの困りごとを解決するために作った」という形にすると、目的から設計する力が伝わります。

作ったアプリを公開まで持っていくことにも意味があります。ストアの審査を通す作業を経験しているかどうかは、発注者にとって分かりやすい判断材料です。

既存アプリの改善提案

実際に使われているアプリを分析し、改善案をまとめた資料も実績として使えます。この場合、批判ではなく改善の提案として書きます。ただし、特定の企業を名指しで批判する形にすると印象が悪くなるので、扱いには注意が必要です。

技術検証の記録

新しい技術を試した記録を、手順と結果として残しておくのも有効です。試したこと、うまくいかなかったこと、その原因。この形式の記録は、実務での問題解決の進め方を示します。

学習の過程そのものは実績にしない

受講した講座、読んだ本、写経した内容。これらは学習の記録であって実績ではありません。実績の欄に並べると、実務経験がないことが強調されてしまいます。学習内容は、実績ではなく対応できる領域の説明の中で触れる程度にとどめます。

過去の案件を棚卸しする手順

出せる実績が少ないと感じている人の多くは、実際には材料を持っています。持っている材料が整理されていないだけです。棚卸しの手順を具体的に示します。

案件を工程で分解する

まず、これまで関わった案件をすべて書き出します。公開できるかどうかは、この段階では考えません。次に、それぞれの案件について、要件の整理、画面設計、データの設計、実装、テスト、リリース、運用の七つの工程のうち、自分が触れた工程に印を付けます。

この作業をすると、意外な偏りが見えます。実装しかやっていないと思っていた人が、実はデータの設計に深く関わっていた、というケースはよくあります。逆に、幅広くやってきたつもりで、テストとリリースをほとんど経験していないと分かることもあります。

印の付いた工程が、そのまま「担当できる工程」として書ける内容になります。印のない工程は、書かないことで誠実さを示せます。

業種ではなく制約で分類し直す

案件を業種で分類すると、「アパレル、飲食、医療」といった並びになります。この分類は、同じ業種の案件を探すときにしか役立ちません。

代わりに、制約で分類します。通信が不安定な環境で使われるもの、大量のデータを扱うもの、操作に不慣れな人が使うもの、外部システムと連携するもの、リリースの期限が動かせなかったもの。この分類にすると、業種が違っても「同じ難しさを経験している」と示せます。

制約での分類は、守秘義務との相性もよいです。業種を伏せても、制約は書けるからです。「大量のデータを扱う業務アプリで、一覧表示の速度を保つために表示の仕組みを設計した」という書き方は、案件を特定させません。

使えなかった案件からも材料を取る

途中で中止になった案件、要件が固まらず提案だけで終わった案件。これらも材料になります。中止になった理由が自分の責任でないなら、そこで作った設計や検証の内容は経験として書けます。

書き方には注意が必要で、「案件が流れた」という事実は書きません。書くのは、そこで検証した技術と、そこから得た判断の材料です。

面談で実績を説明するときの答え方

書いた実績は、面談や打ち合わせで必ず深掘りされます。書き方と話し方はセットで準備します。

よく深掘りされる三つの質問

ひとつ目は、「その部分は具体的にどうやって実装したか」です。技術的な詳細を聞かれます。答えられないと、実際には担当していないと判断されます。

ふたつ目は、「なぜその方法を選んだか」です。他の選択肢を検討したかを見られています。「他の方法も検討したが、この条件ではこちらが適していた」と答えられると評価が上がります。

三つ目は、「うまくいかなかったことは何か」です。ここで「特にありません」と答えるのは、最も印象が悪い回答です。問題が起きなかった開発は存在しないので、そう答えると経験が浅いか、正直でないかのどちらかに見えます。

分からないことを聞かれたときの答え方

担当外の工程について聞かれた場合、知らないことを認めたうえで、隣接する経験を答えます。「その部分は別の担当者が対応していたので詳しくは分かりませんが、連携する側として次の点は把握しています」という形です。

知ったかぶりは、その場では通っても後で必ず露呈します。範囲を正確に言える人は、実際の仕事でも範囲を管理できると見なされます。

実績の説明は結論から入る

説明が長い人は、経緯から話し始めます。聞き手は結論を待つことになり、途中で興味を失います。「この案件では在庫の一覧表示の速度が課題で、表示の仕組みを変えて解決しました」と結論から入り、細部は質問に応じて足します。

やってはいけない見せ方

最後に、避けるべき書き方を整理します。

担当範囲を曖昧にする

「大手企業のアプリ開発に参画」という書き方は、何をやったかが分かりません。深掘りされたときに答えられないと、他の実績まで疑われます。

チームの成果を個人の成果として書く

チームで作ったものを、自分ひとりで作ったかのように書くのは避けます。業界は狭く、事実と違うことは伝わります。チームでの担当箇所を正確に書いたほうが、結果として信頼されます。

出典のない数字を書く

「利用者が大幅に増加」といった表現は、根拠がないと読み流されます。数字を書くなら測定の条件を、書けないなら定性的な表現にとどめます。

守秘義務に触れる情報を出す

これは信頼の問題であると同時に、契約違反です。過去の案件の情報を出す人は、今回の案件の情報も出すと見なされます。実績を増やすために守秘義務を破るのは、長期的には損失にしかなりません。

実績の見出しは検索されそうな言葉で付ける

実績の一件ごとに見出しを付けるとき、案件名やサービス名ではなく、課題を表す言葉を使います。「在庫管理アプリの一覧表示を高速化した事例」という見出しは、同じ悩みを持つ人が探す言葉に近くなります。

案件名は伏せる必要があることが多いので、この付け方は守秘義務との相性もよいです。見出しに課題が書かれていると、一覧をざっと見た人が自分に関係のある実績を見つけやすくなります。

一件あたりの分量をそろえる

実績ごとに分量が大きく違うと、短いものが手抜きに見えます。書ける情報の量に差があっても、五要素をすべて埋める形にすれば分量は自然にそろいます。書けない要素がある場合は、その理由を短く添えます。

実績の見せ方は職種によって重心が変わる

同じアプリ開発でも、担当する領域によって前に出すべき情報が違います。重心を間違えると、伝えたい力量が伝わりません。

画面まわりを担当する場合

利用者が触れる部分を担当するなら、見た目より操作の設計を語ります。どのような利用者を想定し、操作の手数をどう減らしたか。画面を出せない場合でも、操作の流れは言葉で説明できます。

「初回の入力項目を減らすために、後から補える情報は登録後に回した」という説明は、画面がなくても設計の考え方が伝わります。

データや基盤を担当する場合

外から見えない部分を担当している人ほど、実績が伝わりにくくなります。この場合は、扱った規模と制約を書きます。どのくらいの量のデータを扱ったか、どのような更新の頻度だったか、どの程度の同時利用を想定したか。

具体的な数値を出せない場合でも、「日次で更新される在庫データを複数店舗分扱う構成」という書き方で規模感は伝わります。

全体を取りまとめる立場の場合

要件の整理や進行の管理を担当したなら、成果物ではなく判断を書きます。どの機能を後回しにしたか、なぜその判断をしたか、その結果どうなったか。

この立場の実績は、技術の話にすると薄く見えます。判断の話にすると、他の人が真似できない内容になります。

実績を見た人が次に動ける状態にする

実績を整えても、そこから相談に進む導線がなければ機会を逃します。読んだ人が次に何をすればよいかを、実績のすぐ近くに置きます。

対応できる範囲と、対応できない範囲を書く

実績の下に、受けられる仕事の範囲を書きます。担当できる工程、扱える領域、対応できる進め方。あわせて、受けていない仕事も書きます。「デザインの制作は行っていません」「常駐は対応していません」といった記載です。

受けない範囲を書くと機会が減るように見えますが、実際には合わない相談が減るだけです。合わない相談への対応は時間を消費し、断ったときに関係も残りません。最初に書いておくほうが、双方にとって効率的です。

相談の入口を分かりやすくする

問い合わせの手段を一つに絞り、実績のページから直接たどり着けるようにします。複数の連絡手段を並べると、どれを使うべきか迷わせます。

問い合わせのときに書いてほしい項目を添えておくと、最初のやり取りが短くなります。目的、対応したい端末、希望時期、体制。この四つが最初の連絡に含まれていれば、返信の段階から具体的な話ができます。

更新日を明示する

実績のページに最終更新日を書きます。何年も更新されていないページは、いま活動しているのかが分からず、相談をためらわせます。逆に、更新日が新しいだけで、稼働している人だという信号になります。

更新の頻度が高くなくても構いません。案件が終わるたびに一件足す形で十分です。

実績を更新し続ける仕組みにする

実績は、必要になってから作ると内容が薄くなります。案件が終わったタイミングで記録を取る習慣にします。

案件終了時に記録を残す

納品が終わった時点で、課題、担当範囲、技術の選択理由、工夫した点、結果の五つをメモに残します。記憶が新しいうちに書くと、細部が残ります。半年後に書こうとすると、機能名しか思い出せません。

このメモは公開用ではないので、実名や詳細を含んで構いません。公開する段階で抽象化します。

公開の可否を契約時に決めておく

最も効率がよいのは、契約の段階で実績公開の条件を決めてしまうことです。「クライアント名を伏せた形での実績掲載を可とする」という一文を、契約時に相談します。後から聞くより、最初に決めておくほうが承諾されやすい傾向があります。

断られた場合も、その事実が記録として残ります。後で誤って公開してしまう事故を防げます。

市場から見た実績の見せ方

実績の整理は、案件の探し方と直結します。

アプリ開発の仕事がどう募集されているかは、AIチャットボット・アプリ開発のお仕事で全体像が確認できます。募集内容を読むと、求められている担当範囲が案件ごとに違うことが分かります。自分の実績のうち、どれを前に出すべきかは募集の書き方から逆算できます。

隣接領域として、AI・マーケティング・セキュリティのお仕事では、データの扱いや分析に関わる業務がどう切り出されているかが分かります。アプリの実績にデータ設計の話を含められると、この領域の相談も受けられるようになります。

職種の位置づけはソフトウェア作成者の年収・単価相場で統計的な分布が確認できます。自分の担当工程がどの領域に当たるかを言語化しておくと、実績の説明にも一貫性が出ます。技術の裏づけを示す材料としては、CCNA（シスコ技術者認定）のような認定が、通信や基盤に関わる案件で効くことがあります。

20年この市場を見てきた運営者の立場から言えば、実績の見せ方で差がつくのは技術の高度さではありません。差がつくのは、担当範囲を正確に書けているかどうかです。できないことを書かない人ほど、結果的に依頼が続きます。発注者は、できることの多さより、書いてあることが信用できるかを見ています。

もうひとつ、運営者として見てきた限りでは、中間マージンの乗らない手数料0%の直接取引をしている人ほど、実績の記録を丁寧に残しています。仲介を挟まない分、実績の説明がそのまま受注の判断材料になるからです。手取りが厚くなる構造は金額の話に見えますが、実際には「自分の記録を自分の資産にできる」という質の違いを生んでいます。仲介経由の評価は、その場を離れると持ち出せません。

海外の案件に広げる場合も、実績の書き方は共通です。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法では、海外プラットフォームでの実績の示し方が整理されています。言語が変わっても、課題と担当範囲を書くという構造は変わりません。

出せない仕事は、出せないまま伝えられます。必要なのは画面ではなく、解いた問題の記録です。

よくある質問

Q. 守秘義務がある案件を実績として書くことはできますか？

契約書の秘密情報の定義と実績公開に関する条項を確認したうえで、抽象化すれば書ける場合が多いです。企業名を伏せる、業種と規模感だけにする、技術的な課題と解決方法だけを書く、という段階があります。書いた文章全体を読み返し、業種と地域と規模の組み合わせから特定できないかを確認してください。判断に迷う場合は自己判断せず、発注者に確認するのが安全です。

Q. 実績公開の許可はどのように依頼すればよいですか？

納品後の落ち着いた時期に、範囲を限定して具体的に依頼します。漠然と掲載したいと伝えるより、企業名は伏せて業種と担当機能の概要のみ掲載したい、という形のほうが承諾されやすくなります。掲載する文面をこちらで作って添付すると、相手は判断するだけで済むため返答が早くなります。承諾を得たら必ずメールなど文書で記録を残してください。

Q. 実績が一件もない場合は何を見せればよいですか？

自作アプリを課題設定つきで見せるのが基本です。機能の多さではなく、誰のどの困りごとを解決するために作ったかを書きます。ストアで公開まで進めた経験があると、審査の流れを知っている証明になります。加えて、小さなツールのコードを説明文つきで公開する方法も有効です。受講歴や読書歴は学習の記録であり、実績欄には並べないでください。

Q. チームで開発した案件はどう書くのが適切ですか？

チームでの参加であることを明記し、自分が担当した工程を正確に書きます。要件の整理、画面設計、実装、テスト、リリース作業のどこを担当したかを具体的に示してください。全体の成果を個人の成果のように書くと、面談で深掘りされたときに説明できず、他の実績まで疑われます。範囲を正確に書くほうが、結果として信頼につながります。

Q. 実績はいつ記録しておくべきですか？

案件の納品が終わった時点です。課題、担当範囲、技術の選択理由、工夫した点、結果の五つを、記憶が新しいうちにメモに残します。半年後に書こうとすると機能名しか思い出せません。このメモは公開用ではないので実名を含めて構わず、公開する段階で抽象化します。さらに、契約の段階で実績公開の可否を決めておくと後の手間が減ります。