実績ゼロから業務システム開発を受けるなら、小さな自作ツールを見せておく

2026年6月8日

朝比奈蒼

この記事のポイント

✓業務システム開発を実績ゼロから受けるための準備を整理します
✓ポートフォリオに向く自作ツールの条件
✓何を作ればよいかの具体案

結論から書きます。業務システム開発を実績ゼロから受けたいなら、学習の記録を並べるより、小さくても動く自作ツールを1つ用意したほうが早いです。しかも、その1つは技術的に凝っている必要がありません。むしろ地味なほうがいい。

「実績ゼロ」で検索する人の多くは、独学やスクールで一通り学び終えた段階にいます。文法は分かる。フレームワークも触った。それなのに応募すると通らない。何が足りないのか分からない。この状態です。

足りていないのは技術力ではありません。発注する側が「この人に自社の業務を任せて大丈夫か」を判断する材料がないだけです。そして、その材料は作品の規模ではなく、作品の性格で決まります。

この記事では、実績ゼロの状態から業務システム開発の案件に近づくために、何を作り、どう見せるかを具体的に整理します。無料で揃えられる範囲も併せて書きます。

実績ゼロで落ちる本当の理由

まず、発注側が何を見ているのかを押さえます。ここを外すと、努力の方向がずれます。

業務システムを外注しようとしている企業は、多くの場合、システムの専門家ではありません。総務や経理の担当者が、通常業務と兼任で発注を担当していることがよくあります。その人が候補者のポートフォリオを見たとき、判断できるのは次の3点くらいです。

1つ目は、自社の困りごとに似た課題を扱った経験があるか。2つ目は、途中で投げ出さずに完成させられるか。3つ目は、こちらの言葉が通じるか。

技術スタックの一覧や、学習期間の長さは、この3点のどれにも答えていません。正直なところ、「Reactを学習しました」と書かれても、発注側には何も伝わっていないのが実情です。

発注側は「完成したもの」しか信用しない

業務システム開発の受託は、成果物に対して対価が発生する仕事です。だから発注側は、成果物を出せる人かどうかを最も気にします。

開発会社の紹介記事でも、実績の厚みが選定理由として語られます。

同社の強みは、業務システム開発に関するその豊富な経験です。会社の設立から20年以上、業種や事業の規模・内容を問わず幅広い開発を手掛けてきました。営業、人事・給与、勤怠などどの会社にも必要なシステムはもちろん、オンライン予約システムや、巡回業務のシステムなど、特定業務に対応した開発実績も数多くあります。出典: hnavi.co.jp

個人がこの規模の実績と正面から比べられたら勝てません。だからこそ、比べられる土俵をずらす必要があります。個人に発注する側が求めているのは、大規模な開発体制ではなく、小さくて具体的な困りごとを、素早く安く解決してくれる相手です。ここに合わせた作品を用意すれば、実績ゼロでも土俵に上がれます。

業務システムに求められているのは、派手さではない

業務システムの導入で語られる成果は、だいたい地味です。

✅ 業務システム開発費用=月額30万プラン×6ヵ月 ✅ 受発注業務がスムーズになり、業務時間が30％削減！ ✅ 社員の負担が減り、残業ゼロに！「働きやすい会社」として定着率も向上。 ✅ データ化により会社の数字が客観視できるようになった。出典: micks.co.jp

ここに書かれているのは、業務時間が30%減った、残業が減った、数字が見えるようになった、という話です。新しい技術を使ったとか、画面が美しいという話ではありません。

つまり、ポートフォリオで見せるべきは「どんな作業がどれだけ楽になるか」であって、技術の高度さではないということです。この視点で作品を選び直すと、通過率が変わってきます。

ポートフォリオに向く自作ツールの4つの条件

では、何を作ればよいのか。条件は4つです。

条件1：実在する業務の課題から始まっている

架空のサービスではなく、実際にある作業の不便さから出発した作品にします。自分のアルバイト先の集計作業、前職での帳票作成、家族が経営している店の在庫管理。身近な範囲で構いません。

なぜ課題起点が大事かというと、発注側が自社の状況に置き換えて読めるからです。「Excelで管理していた在庫を、複数人で同時に見られるようにした」と書いてあれば、同じ悩みを持つ会社の担当者は自分ごととして読みます。

条件2：一人で完結して、実際に動く

チーム開発で一部を担当した、という実績も価値はありますが、実績ゼロの段階では自分が全部やった小さいものを1つ持つほうが強いです。設計から実装、データベースの構造、画面、テストまで通しでやったという事実が、「完成させられる人」であることの証明になります。

そして、必ず動く状態にしてください。ソースコードだけがあって動かない作品は、発注側には評価できません。

条件3：それらしいデータが入っている

これを軽視する人が多いのですが、極めて重要です。空のテーブルと空の一覧画面を見せられても、何も伝わりません。

架空でよいので、実務に近い量と形のデータを入れておきます。取引先が20社、商品が100件、受注履歴が数百件。データが入った状態の一覧画面や集計画面は、それだけで説得力が出ます。検索や絞り込みが実際に効く様子も見せられます。

条件4：小さい

大作を作ろうとして半年止まっている人を、よく見かけます。正直なところ、これはどうかと思います。規模で勝負しても開発会社には勝てませんし、完成しない作品は評価されません。

画面が3枚から5枚、機能が3つか4つ。この程度で十分です。2週間から1か月で完成させて、次に進むほうが結果的に早く前に出られます。

何を作るか、具体的な候補

迷ったら、この中から自分に縁のある業務を選んでください。

作るもの	解決する困りごと	最低限の機能
勤怠の集計ツール	出退勤の記録をExcelで手集計している	打刻の登録、月次集計、CSV出力
簡易在庫管理	在庫表を複数人が別々のファイルで持っている	商品登録、入出庫の記録、在庫一覧
請求書の作成支援	毎月同じ内容を手で転記している	取引先マスタ、明細入力、PDF出力
問い合わせ管理	メールの対応漏れが起きる	起票、担当者の割り当て、状態の管理
Excel取り込み変換	取引先ごとに書式が違う注文書を手で写している	ファイル取り込み、項目の対応付け、変換後の出力
予約の受付と管理	電話とノートで予約を管理している	予約登録、重複の防止、日別の一覧
日報の集計	紙の日報から月次報告を作っている	日報の入力、期間集計、担当者別の表示

この中で最も評価されやすいのは、Excelの取り込み変換だと考えています。理由は単純で、中小企業の現場でいちばん多い困りごとがこれだからです。取引先ごとにフォーマットの違う注文書が届き、それを自社の形式に手作業で写している。この作業を自動化するツールは、そのまま実案件の相談につながることがあります。

業種を絞ると、さらに刺さりやすい

汎用的な在庫管理より、「飲食店向けの発注管理」のように業種を絞ったほうが、読み手の反応は良くなります。業種特有の事情を理解していることが伝わるからです。

自分に土地勘のある業界があるなら、そこを選ぶのが合理的です。前職が介護や福祉の分野なら、その現場の書類仕事を扱うツールにする。制度や助成金の知識がある人は、福祉用具貸与事業所のスキルアップ助成金2026｜人材開発支援助成金の活用法のような制度情報も踏まえて、現場で本当に必要とされる機能を組み立てられます。前職の知識は、実績ゼロの状態を埋める数少ない武器です。

作り始める前に決めておく3つのこと

手を動かす前に、これだけは決めてください。ここが曖昧なまま始めると、たいてい途中で止まります。

1つ目は、対象にする業務を1つに絞ることです。「在庫管理と勤怠管理と請求書発行を全部入れた統合システム」を作ろうとして挫折する例をよく見かけます。業務は1つ、機能は3つか4つ。この制約を先に決めます。

2つ目は、完成の定義です。何ができたら完成とするかを、着手前に文章にしておきます。「商品を登録でき、入出庫を記録でき、現在の在庫が一覧で見られたら完成」というように。定義がないと、いつまでも作り足してしまい、公開のタイミングを逃します。

3つ目は、期限です。3週間なら3週間と決めて、その日が来たら未完成の機能は削って公開します。業務システム開発の実務でも、期限に合わせて範囲を調整する判断は日常的に発生します。その練習だと思ってください。

設計の痕跡を残しておく

これは差がつく部分なので、強調しておきます。

多くの人が、コードと画面だけを見せます。しかし業務システム開発で本当に評価されるのは、その前段にある設計です。だから、設計の過程を残して一緒に見せてください。

具体的には、次の3つで足ります。1つ目は、扱うデータの構造を図か表にしたもの。どんなテーブルがあり、どう関係しているか。2つ目は、画面の一覧と、どこからどこへ移動するかの流れ。3つ目は、決めたこととその理由を書いたメモ。「在庫数をマイナスにできる仕様にした。棚卸しのタイミングで実在庫と帳簿がずれる運用があるため」といった判断の記録です。

これらがあると、発注側は「この人は要件を整理できる」と判断できます。実装だけができる人と、業務を構造に落とせる人では、任せられる範囲が違います。設計の痕跡は、その差を示す唯一の材料です。

作品の見せ方

作っただけでは伝わりません。見せ方で評価が変わります。

説明文に書く5項目

作品の紹介ページやREADMEには、次の5つを順番に書きます。

1つ目は、誰のどんな作業を対象にしたか。「月末に2時間かけて行っていた勤怠の集計作業」のように、具体的に書きます。

2つ目は、その作業の何が問題だったか。転記ミスが起きる、担当者しかやり方を知らない、集計に時間がかかる。困りごとを言語化します。

3つ目は、どう解決したか。ここで初めて機能の説明が出てきます。

4つ目は、使った技術と、その選択理由。「学習中だから」ではなく、「取り込むファイルの形式が変わりやすいので、変換のルールを設定ファイルで持たせた」のように、判断の理由を書きます。この一文があるだけで、印象がまったく変わります。

5つ目は、うまくいかなかった点と、どう対処したか。ここを書くと信頼度が上がります。隠す人が多いぶん、書く人が目立ちます。

デモを見られる状態にしておく

動かせない作品は、見てもらえません。可能なら、ブラウザでそのまま触れる状態にしておきます。

無料の範囲で公開できるホスティングサービスは複数あります。データベースが必要な業務システムでも、小規模なら無料枠に収まることが多いです。費用をかけずに公開できるなら、そうしない理由はありません。

デモにはログインを必須にしないでください。あるいは、閲覧用のアカウントを説明文に書いておきます。パスワードを聞かないと見られない作品は、そこで離脱されます。

画面のキャプチャと短い操作動画を添える

デモを触ってもらえるのが最善ですが、忙しい発注者は触りません。だから静止画と動画を用意します。

キャプチャは、データが入った状態の画面を選びます。空の画面は載せないでください。動画は60秒以内で、一連の操作が終わるところまで。音声は不要です。

コードの見せ方

コードを公開するなら、読みやすさが評価対象になります。処理の意図を書いたコメント、意味の分かる変数名、フォルダ構成の整理。技術力の高さより、他人が読めるかどうかを見られています。

業務システムは、作った本人以外が保守することを前提にした仕事です。読みやすいコードを書ける人であることは、そのまま受注の理由になります。

業務システムらしさが出る、小さな作り込み

同じ規模の作品でも、次の要素が入っていると評価が変わります。どれも実装量は小さいのに、業務を分かっている人だと伝わる部分です。

1つ目は、権限の区別です。管理者と一般利用者で見える範囲が違う。実務のシステムには必ずある要素で、これがあるだけで「業務向け」に見えます。

2つ目は、操作の記録です。誰がいつ何を変更したかを残しておく。業務システムでは、後から経緯を追えることが求められます。

3つ目は、CSVの入出力です。既存のExcel運用と共存する必要があるため、実務では必須に近い機能です。文字コードの扱いまで考慮してあると、なお良いです。

4つ目は、入力の誤りへの対応です。数値の欄に文字が入った、必須項目が空のまま送信された。こうしたときに、何が悪いのかが分かるメッセージを出す。業務システムを使うのは専門家ではないので、ここの丁寧さがそのまま品質として見られます。

5つ目は、削除の扱いです。実務では、消したデータを後から確認したい場面があります。物理的に消さず、無効の印を付けて残す設計にしておくと、業務の現実を理解していることが伝わります。

やりがちな失敗

失敗1：教材の完成品をそのまま出す

学習教材で作ったアプリを、そのままポートフォリオにするケースが多くあります。見る側は同じものを何度も見ているので、すぐ分かります。悪くはありませんが、他の候補者との差にはなりません。教材を土台にするなら、機能を足すか、扱う業務を自分の身近なものに置き換えてください。

失敗2：技術の話ばかりで、業務の話がない

「認証にJWTを採用し、状態管理には最新のライブラリを使いました」という説明だけが並ぶ作品。技術者同士なら伝わりますが、発注者には伝わりません。冒頭は必ず業務の言葉で書き、技術の話は後半に置きます。

失敗3：作りかけを大量に並べる

10個の未完成より、1個の完成です。数を並べると、かえって「完成させられない人」に見えます。並べるのは、自信を持って動かせるものだけにしてください。

失敗4：文章が読みにくい

見落とされがちですが、説明文の日本語そのものが評価されています。誤字が多い、結論が最後まで出てこない、主語がない。こういう文章を書く人は、仕様書も読みにくいだろうと推測されます。

ポートフォリオの文章の組み立て方は、職種が違っても参考になる部分が多くあります。Webライターのポートフォリオの作り方｜案件獲得率が上がるテンプレート付き【2026年版】では、実績が少ない状態でどう見せるかの型が整理されています。文書そのものの型を身につけたいなら、ビジネス文書検定の学習範囲が実務にそのまま使えます。

失敗5：デモのデータが古いまま放置されている

公開したあと、そのままにしてしまう例も多くあります。日付の入ったデータが数年前で止まっていると、動いていない作品に見えます。

年に一度でよいので、データの日付を更新し、リンク切れがないかを確認してください。動作しない作品が置かれていると、あるだけで逆効果になります。見せるものを増やすより、見せているものが常に動く状態を保つほうが、はるかに効きます。

費用をかけずに揃える

実績ゼロの段階で、環境に大きなお金をかける必要はありません。

開発に使うエディタもバージョン管理も、無料のもので十分です。ソースコードの公開先も無料枠があります。ホスティングも、小規模なら無料の範囲で足ります。ドメインを取るかどうかは好みですが、必須ではありません。

有料の講座やスクールに追加投資する前に、まず1つ完成させることをおすすめします。作品が1つあれば、次に何を学ぶべきかが自分で見えてきます。学ぶ順番が分からないまま講座を重ねるより、はるかに効率が良くなります。

技術の裏付けを資格で補いたい場合は、目的を絞って選んでください。ネットワークやインフラの要件が絡む案件に関わるつもりなら、CCNA（シスコ技術者認定）の学習範囲が実務と直結します。ただし、資格が作品の代わりになることはありません。順番としては、作品が先です。資格の学習に何か月もかける前に、動くものを1つ公開したほうが、案件との距離は確実に縮まります。

1か月で1つ仕上げる進め方

期限を決めても、何をいつやるかが見えていないと動けません。4週間で1本仕上げる場合の目安を置いておきます。

週	やること	終わっている状態
1週目	対象業務の整理、データ構造の設計、画面一覧の作成	何を作るかが図と表で説明できる
2週目	登録と一覧の実装、テストデータの投入	データが入った画面が動く
3週目	集計や出力など、業務上の価値がある機能の実装	手作業が実際に減る状態になっている
4週目	説明文の作成、キャプチャと動画、公開設定	第三者がURLを開いて触れる

見ていただくと分かる通り、実装に使うのは2週間だけです。設計に1週間、見せ方に1週間かけています。実績ゼロの人ほど実装に時間を全部使いがちですが、評価されるのは前後の1週間ずつのほうです。

3週目の「業務上の価値がある機能」が、この作品の核になります。登録と一覧だけでは、Excelで足りてしまいます。月次で自動集計する、条件に合うものを抽出して出力する、入力の誤りを検知する。手作業が減る機能が1つ入って初めて、業務システムと呼べるものになります。

誰かに触ってもらう

完成したら、公開する前に誰かに触ってもらってください。技術者でない人がよいです。家族でも、前職の同僚でも構いません。

説明なしで操作してもらうと、自分では気づかない詰まりが見つかります。ボタンの言葉が分からない、次に何をすればよいか分からない、エラーの意味が伝わらない。業務システムを使うのは専門家ではないので、この視点でのフィードバックは実務でもそのまま役立ちます。

指摘されたことを直した記録を説明文に書いておくと、それ自体が評価の材料になります。他人の指摘を受けて直せる人だと分かるからです。

実績ゼロから最初の1件へ

作品ができたら、次は案件です。ここでも順番があります。

最初から大きな案件を狙わないほうが通りやすくなります。既存システムの軽微な改修、Excelマクロの置き換え、データの整形作業。こうした小さな案件は競合が少なく、実績ゼロでも受注の可能性があります。

そして1件終えたら、その内容を許可の範囲で作品集に追記します。守秘義務があるので、クライアント名や画面そのものは出せないことが多いですが、「どんな業務の、どんな作業を、どう改善したか」は書けることがあります。契約時に、実績として公開してよい範囲を確認しておくとよいでしょう。

どんな仕事が実際に発注されているかを見ておくと、狙う案件の粒度が掴めます。Web・業務システム開発のお仕事で仕事の中身を確認し、周辺の領域まで視野に入れるならAI・マーケティング・セキュリティのお仕事も見ておくと、提案できる幅が広がります。開発から離れた分野で収入源を分散する選択肢としては、作曲・編曲・効果音・ジングルのお仕事のような領域もあります。

報酬の水準は、職種別の統計で把握しておいてください。ソフトウェア作成者の年収・単価相場で開発職の相場を確認できます。実績が増えてきたときの単価の上げ方については、職種は違いますがWebライターが文字単価を上げる方法｜1円→5円にステップアップする戦略【2026年版】の考え方が応用できます。上げるタイミングと根拠の作り方は、業種を問わず共通しています。

独自データから見た、実績ゼロを抜ける人の共通点

在宅ワークとフリーランスの市場を20年見てきた立場から言えば、実績ゼロの状態を短期間で抜ける人には共通点があります。技術の習熟度ではありません。「相手の業務を自分の言葉で説明できる」ことです。

作品の説明を読むと、すぐ分かります。技術の一覧を並べる人と、その業務が誰の何を楽にするのかを書ける人。後者は、実案件でも要件の食い違いが少なく、結果として継続の依頼につながっています。発注側から見れば、自分たちの仕事を理解してくれる相手のほうが、話が早いからです。

もう一点。長く続く人は、単発の作業を積み上げるのではなく、「この人に任せると楽だ」という関係を作ることに時間を使っています。業務システムは作って終わりではなく、法改正や業務の変更のたびに手が入ります。最初の1件を丁寧に終えた人は、その次の相談が来ます。実績ゼロを抜けるというのは、案件を10件こなすことではなく、次を頼まれる関係を1つ作ることだと考えたほうが実態に近いです。

中間マージンが乗らない直接の取引では、同じ予算でも依頼側はより多くを頼めて、受け手の手取りは厚くなります。手数料0%で取引できる形は、双方が得をするから続きます。実績ゼロの段階では選べる経路が限られますが、1件目を終えた後に、この構造を意識して経路を選び直すと、同じ作業量でも手元に残る額が変わってきます。

まずは、小さくても動くツールを1つ。それが実績ゼロを抜ける最短の道です。