業務システム開発のポートフォリオの作り方｜見る人が知りたいこと

業務システム開発のポートフォリオを作ろうとして、最初の一行で手が止まる人はとても多い。理由ははっきりしています。業務システムは、作ったものをそのまま見せられないからです。顧客の受発注データ、社員の人事情報、取引先の名称。画面キャプチャを一枚貼るだけで守秘義務違反になりかねない領域で、どうやって実績を示すのか。結論から言うと、業務システム開発のポートフォリオは「作品集」ではなく「判断の記録」として作るのが正解です。何を見せるかではなく、どんな条件でどう判断したかを書く。この記事では、公開可否の確認手順、抽象化のレベルの決め方、掲載する実績がないときの題材選び、そして発注者が実際に読んでいる項目まで、受注につながる形に落とし込んで整理します。

業務システム開発のポートフォリオがWeb制作と決定的に違う点

ポートフォリオという言葉から多くの人が想像するのは、デザイナーの作品集です。美しい画面が並び、スクロールするだけで力量が伝わる形式。業務システム開発では、この形式がほとんど機能しません。理由を3つに分けて整理します。

成果物の大半が非公開である

業務システムは特定の企業の内部で動きます。在庫管理、勤怠、原価計算、受発注、顧客管理。どれも社外に出ない前提で設計されているため、画面もデータも公開できません。契約書に秘密保持条項が入っていることがほとんどで、開発者が独断で公開できる範囲は極めて狭い。

ここを軽く見て、退職後や契約終了後に管理画面のキャプチャをそのまま掲載してしまう例が実際にあります。発注者側の担当者がそれを見つけたとき、起きるのは「技術力の評価」ではなく「この人に任せたら自社の情報も出るのでは」という警戒です。ポートフォリオが逆に受注を減らす結果になる。正直なところ、この失敗は取り返しがつきません。

評価軸が見た目ではなく業務の理解にある

Webサイト制作なら、配色やタイポグラフィ、レスポンシブの完成度が一目で伝わります。業務システムでは、画面が地味であることがむしろ正しい場合が多い。1日に何百件も入力する現場では、装飾よりもタブキーだけで入力が完結することのほうが価値が高いからです。

つまり、発注者が見ているのは「きれいに作れるか」ではありません。「うちの業務を理解して、現場が使える形に落とせるか」です。この評価軸に合わせるなら、掲載すべきなのは完成画面よりも、要件が曖昧だった状態からどう整理したかという過程になります。

判断の理由を言語化する必要がある

業務システムには、技術的に正しくても業務的に間違っている選択が存在します。正規化を徹底したテーブル設計が、月次の集計処理を極端に遅くしてしまう。理想的な権限管理を実装した結果、現場の派遣スタッフが必要な画面に入れなくなる。こうした場面でどちらを取るかは、技術の知識ではなく業務の理解で決まります。

ポートフォリオで差がつくのは、まさにこの部分です。「Reactを使いました」ではなく「入力頻度が高い画面だけをSPAにして、月1回しか使わない管理画面はサーバーサイドレンダリングのままにしました。理由は保守を引き継ぐ社内担当者がJavaScriptに不慣れだったためです」と書けるかどうか。後者は、他の応募者が真似できない情報です。

発注者がポートフォリオで確かめている4つのこと

業務システム開発の依頼者は、多くの場合、情報システム部門の担当者か、社内でシステム導入を任された事業部門の管理職です。彼らが応募書類を読むときに探しているのは、次の4点に集約されます。

要件が曖昧な状態からどう詰めたか

業務システムの依頼は、ほぼ例外なく曖昧な状態で始まります。「今エクセルでやっている在庫管理をシステム化したい」という一文が要件のすべて、ということも珍しくありません。発注者自身も、何を作ればよいのか整理できていない。

だからこそ、ヒアリングの進め方が評価対象になります。誰に何を聞いたのか。現場に何回入ったのか。エクセルの現物を何種類見せてもらったのか。関数が壊れているシートを見つけて、そこから業務の実態を掘り起こしたのか。こうした経緯を書けば、依頼者は「この人なら自分たちの曖昧な要望を形にしてくれる」と判断できます。

データ設計に対する考え方

業務システムの寿命は長く、10年以上動き続ける例も普通にあります。画面は後から作り直せますが、データ構造は簡単には変えられません。既に本番データが積み上がっているからです。

そのため、ER図の考え方、マスタとトランザクションの分け方、履歴の持たせ方、論理削除と物理削除の使い分けといった設計判断は、発注者が最も知りたい部分の1つです。ここで実際のテーブル名を出す必要はありません。「取引先マスタの改称に履歴が必要だったため、有効期間を持つ形にした」という説明だけで十分に伝わります。

運用と保守を想定しているか

作って納めて終わり、という開発は業務システムではほとんどありません。締め日の処理、年度替わりのマスタ更新、担当者の異動に伴う権限変更、法改正への対応。運用が始まってからの作業のほうが長く続きます。

ポートフォリオに運用設計の記述があると、依頼者の見る目が変わります。障害時の連絡経路をどう決めたか、バックアップの世代をいくつ残したか、社内担当者へどうやって引き継いだか。マニュアルを作ったのなら、その目次だけでも掲載する価値があります。

情報の扱いに対する姿勢

そして最も見られているのが、情報の扱い方そのものです。ポートフォリオの書きぶりが、そのまま「この人は自社の情報をどう扱うか」の予告になります。

企業名を伏せているか。数値を丸めているか。画面キャプチャのダミーデータが実在の人名になっていないか。こうした細部が、技術力よりも先に読まれています。守秘義務を守りながら実績を示せている時点で、それ自体が1つの実績です。

守秘義務を守りながら実績を載せる手順

ここからは具体的な手順です。次の3ステップを、掲載したい案件ごとに必ず通します。

公開可否を先に確認する

まず契約書を読み返します。秘密保持条項に「本業務を通じて知り得た情報」とだけ書かれている場合、開発物の存在自体が秘密情報に含まれる解釈もあり得ます。実績公開の可否が明記されていないなら、発注者へ確認します。

確認の連絡は短く、具体的にします。「実績としてポートフォリオへの掲載を検討しています。企業名は伏せ、業種と規模感のみを記載し、画面のキャプチャは使用しません。この範囲であれば掲載してよろしいでしょうか」という形です。掲載範囲を先に狭く提示すると、承諾が得られる確率が上がります。範囲を決めずに「載せてよいですか」とだけ聞くと、判断コストを相手に丸投げすることになり、断られやすい。

なお、退職した企業の社内システムについては、退職時の誓約書も併せて確認します。在職中の業務内容全般に守秘義務が及ぶ内容になっていることが多いためです。

抽象化のレベルを3段階で決める

承諾が取れない、あるいは確認先が既に存在しない場合でも、書けることは残ります。抽象化のレベルを3段階に分けて考えると整理しやすくなります。

第1段階は、企業名だけを伏せる形です。「従業員100名規模の食品卸売業」のように業種と規模を残します。承諾が取れているときはこの粒度が最も伝わります。

第2段階は、業種を上位カテゴリに置き換える形です。「食品卸売業」を「BtoBの卸売業」とします。業界内で特定されそうな案件では、この段階まで抽象化します。

第3段階は、業務課題だけを残して業種を消す形です。「複数拠点の在庫を日次で突き合わせる必要があり、拠点ごとに運用ルールが異なっていた」という書き方になります。特定は不可能ですが、課題の難しさは十分伝わります。

どの段階でも共通して守るのは、固有名詞を出さないことと、実データの数値を出さないことです。取扱高や社員数を正確に書く必要はありません。「三桁の拠点」「二桁の同時利用者」といった桁の情報で足ります。

許諾の記録を残す

承諾を得たら、メールの本文を保存します。口頭やチャットの承諾だけだと、担当者が異動したあとで話が食い違います。相手の会社名、担当者名、日付、承諾された掲載範囲の4点が残る形にしておきます。

この記録は、次の依頼者から「実績の掲載許可は取っているのか」と聞かれたときにも使えます。聞かれること自体が珍しくない質問です。

掲載できる実績がないときの題材の選び方

実務経験がまだない場合、あるいは公開許諾がどれも取れなかった場合は、自分で作った題材を載せることになります。ここで選択を誤ると、学習用の課題を提出したようにしか見えません。

実在する業務の不便を題材にする

避けたいのは、チュートリアルでよくあるタスク管理アプリやブログシステムです。それ自体が悪いのではなく、業務システムの評価軸である「業務の理解」を示せないからです。

代わりに選ぶのは、実在する業務の不便です。身近な例だと、飲食店のシフト作成、小規模な塾の月謝管理、地域のスポーツクラブの会費と出欠管理、個人事業主の外注先への支払い管理。いずれも紙かエクセルで運用されている領域で、実際に運用している人に話を聞ける可能性があります。

そもそも職務経歴書は、過去経験した職務や地位・事業内容を時系列で並べて一覧化したもので履歴書の保管的役割を果たします。 対して、ポートフォリオは単なる経歴や経験の羅列だけでなく、成果物の作品集であり、文字だけでは伝わりづらい技能スキルを伝えるものです。

この整理はそのまま業務システムにも当てはまります。経歴の羅列では伝わらない技能を示すのがポートフォリオの役割だとすれば、自作の題材であっても「誰のどんな不便をどう解いたか」が書けていれば目的は果たせます。逆に、実務経験があっても課題の説明がなければ、単なる経歴の羅列に戻ってしまう。

ヒアリングの記録まで残す

自作の題材で強いポートフォリオになるかどうかは、ヒアリングの記録があるかで決まります。運用している人に30分話を聞くだけでも、現物のエクセルには現れない制約が出てきます。

たとえば塾の月謝管理なら、兄弟割引の適用条件、月の途中入会の日割り、教材費と月謝を分けて請求する必要があるかどうか。こうした条件はシステムの構造を左右しますが、外から想像しても出てきません。聞き取った内容と、それを受けてどう設計したかを併記すれば、実務案件と同じ形の記述になります。

作り込む範囲を絞る

自作の題材を全機能そろえようとすると、まず完成しません。範囲を絞ります。中核となる業務フローを1本だけ通し、それ以外は「未実装」と明記する形で構いません。

むしろ、なぜその1本を選んだのかを書けることが評価につながります。「日々の入力頻度が最も高く、ミスが起きたときの影響が大きいため、月謝の請求データ生成を最初に実装した」という判断は、実務でも同じように求められます。

ポートフォリオの構成と各項目の書き方

構成は、読み手が上から順に読まなくても必要な情報にたどり着ける形にします。採用や外注の選定では、1件あたりの閲覧時間が短いためです。

全体の並び

先頭に、対応できる業務領域と技術領域を箇条書きで置きます。次に代表的な案件を3件前後、詳しく書きます。その後ろに、それ以外の案件を一覧形式で並べます。最後に、稼働可能な時間帯とコミュニケーション手段を書きます。

先頭のサマリーは、読み手が「そもそも自社の依頼と合うか」を判断するための情報です。ここが曖昧だと、詳細まで読まれません。

1案件あたりの記載項目

案件ごとに書く項目は次の通りです。

• 業種と規模の抽象表現
• 依頼時点で発注者が抱えていた課題
• 担当した工程（要件定義、設計、実装、テスト、運用のどこか）
• チームの構成と自分の役割
• 技術構成と、その構成を選んだ理由
• 実装上で難しかった点と、どう解決したか
• 納品後にどう運用へ引き継いだか

このうち、他の応募者と差がつくのは3つ目、5つ目、7つ目です。担当工程を曖昧にせず、要件定義から入ったのか、決まった仕様の実装だけを担ったのかを明示します。上流を担当した経験は、業務システムでは特に評価されます。

技術スタックの書き方

技術名を羅列するだけでは、使ったことがある事実しか伝わりません。バージョンと選定理由を添えます。

「PostgreSQLを採用。既存の会計ソフトがCSVで出力する形式に日付と数値の混在があり、取り込み時の型変換をSQL側で完結させたかったため」というように、業務条件と技術選定を接続します。この書き方ができていると、依頼者は「自社の既存環境も考慮してくれる」と読み取ります。

なお、API連携の経験は明示しておく価値があります。業務システムの依頼では、会計、勤怠、EC、名刺管理といった既存サービスとの連携が必要になる場面が多いためです。

画面キャプチャの扱い

公開許諾が取れていない案件では、キャプチャを使いません。代わりに、画面遷移図や機能一覧の図を自分で描き起こします。実物ではないため守秘義務に触れず、設計の意図は伝わります。

自作の題材ではキャプチャを使えますが、ダミーデータに注意します。実在しそうな企業名や、知人の氏名をそのまま入れているケースが散見されます。ダミーは明らかに架空と分かる表記に統一します。

公開の形式をどれにするか

形式は、依頼者の環境と、更新のしやすさで選びます。

Webページとして公開する形式は、URLを1本渡すだけで済むのが利点です。検索から見つけてもらえる可能性も生まれます。一方で、非公開にしたい情報を扱う案件を載せにくく、閲覧者を限定できません。

PDFで作る形式は、送付先を限定できるのが利点です。守秘義務のある案件を、承諾済みの範囲でだけ相手に渡せます。欠点は、更新のたびに送り直しが必要になることと、ファイルサイズが大きくなりがちなことです。

GitHubなどのソースコード公開は、自作の題材で力を発揮します。コミット履歴が残るため、設計を途中で見直した経緯まで読み取れます。ただし、業務案件のコードは絶対に置きません。

実務では、Webページで概要を公開し、詳細版のPDFを依頼者ごとに渡す二段構えが扱いやすい形です。案件を選ぶ立場の依頼者は、まず概要で候補を絞り、その後に詳しい資料を求めるためです。

選ばれない書き方に共通する注意点

書類が通らない例には、いくつか共通するパターンがあります。

1つ目は、担当範囲が書かれていないことです。「大規模基幹システムの開発に参画」とだけ書かれていると、設計を担ったのか、テストだけを担ったのか分かりません。読み手は判断できない情報を評価に使えないため、実質的に無いのと同じ扱いになります。

2つ目は、技術名だけが並んでいることです。使用言語とフレームワークの一覧は、書類の冒頭に置く分には有効ですが、それだけでは他の応募者と区別がつきません。

3つ目は、成果を誇張していることです。業務システムの依頼者は現場の数字を知っているため、根拠のない改善効果はすぐに見破られます。改善の数値を書くなら、測り方も併記します。測っていないなら書かない。

4つ目は、更新が止まっていることです。最終更新が数年前のまま放置されていると、現在の稼働状況が読めません。案件が増えていなくても、学習した内容や検証した技術を追記して更新日を動かしておきます。

5つ目は、誤字脱字と表記ゆれです。業務システムの現場では、仕様書やテスト仕様書を書く場面が多く、文書の正確さがそのまま実務能力として見られます。ポートフォリオはその見本になってしまいます。

エクセル運用からの移行案件で書くべきこと

業務システム開発の依頼で最も件数が多い類型の1つが、エクセルで回っている業務の置き換えです。この経験がある場合、書き方を工夫すると評価が大きく変わります。

現物のエクセルをどう読み解いたか

エクセル運用の現場には、必ず「その人しか知らない仕様」があります。特定のセルに手入力された調整値、条件付き書式で色を付けているだけの承認フラグ、シート名の末尾に付いた日付が実は版管理になっている、といった状態です。

これらは仕様書に書かれていません。ファイルを開いて数式をたどり、担当者に「この列は何のために足しているのか」と聞いて初めて分かります。ポートフォリオには、この読み解きの過程を書きます。「請求金額の列に、数式ではなく直接入力された値が混在していたため、過去分を洗い出したうえで例外処理の要否を確認した」といった記述は、実際に手を動かした人にしか書けません。

移行時のデータをどう扱ったか

置き換えで最も難しいのは、機能の実装ではなくデータの移行です。過去数年分のシートに、表記ゆれ、全角と半角の混在、実在しない日付、結合セルが混ざっている。これをどう正規化したかは、そのまま実務能力の証明になります。

移行の方針も書きます。全期間を移行したのか、直近だけを移行して過去分は参照専用にしたのか。後者を選んだのなら、その判断理由を添えます。「決算に必要な範囲だけを移行し、それ以前はファイルのまま保管する方針とした。移行コストと参照頻度が見合わなかったため」という説明は、費用感覚があることの証明になります。

現場に受け入れられたか

システムが完成しても、現場がエクセルを使い続ける例は珍しくありません。入力の手数が増えた、慣れた画面と違う、といった理由です。この壁を越えた経験があるなら、必ず書きます。

具体的には、並行運用の期間をどれくらい設けたか、操作説明をどの形式で行ったか、初期の問い合わせにどう対応したか。導入の定着まで面倒を見た経験は、開発力とは別の評価軸で高く見られます。

工程ごとに書き分ける項目

担当した工程によって、書くべき内容は変わります。工程別に整理しておきます。

要件定義を担当した場合

誰と何回打ち合わせたか、どんな資料を作ったか、決まらなかった論点をどう処理したかを書きます。特に重要なのが最後の項目です。業務システムの要件定義では、社内で意見が割れて決まらない論点が必ず出ます。決めきれない部分を「後続フェーズで再検討」として先送りしたのか、暫定仕様を置いて動かしたのか。この判断の記録があると、上流工程の経験が本物であることが伝わります。

設計を担当した場合

画面設計とデータ設計を分けて書きます。画面設計では、入力の手数を減らすために何をしたかが評価されます。データ設計では、将来の変更を見越してどこに余地を残したかを書きます。組織改編で部署コードが変わる、税率が変わる、取引先が統合される。業務システムで実際に起きる変更に、どう備えたかという視点です。

実装とテストを担当した場合

実装だけを担当した場合でも、書ける情報はあります。仕様の不備を見つけて指摘したか、テストデータをどう用意したか、境界値をどこに設定したか。特にテスト設計は軽視されがちですが、業務システムでは金額の計算誤りが直接損害につながるため、テストの丁寧さが評価対象になります。

書き上げたあとに必ずやること

原稿ができたら、公開する前に2つの確認をします。

1つ目は、第三者に読んでもらうことです。できれば業務システムに詳しくない人が望ましい。専門用語が説明なしに使われている箇所、主語が抜けている文、どの工程を担当したのか分からない記述が、他人の目ですぐ見つかります。発注側の担当者は必ずしも技術者ではないため、非技術者に伝わるかどうかは重要な指標です。

2つ目は、守秘義務の観点でもう一度読み返すことです。書いているうちに具体性を求めて、うっかり特定できる情報を入れてしまうことがあります。業種、地域、規模、システム名、独特の業務フロー。この4つ以上が揃うと、業界内では特定される可能性が出ます。書き終えた翌日に、時間を置いて読み返すのが安全です。

発注側の情報から読み取れる、掲載内容の優先順位

在宅ワークの仲介サイトに掲載される案件の説明文を継続的に見ていくと、業務システム開発の依頼で繰り返し登場する条件が見えてきます。既存システムからの移行、エクセル運用の置き換え、外部サービスとの連携、そして納品後の保守対応の可否。この4つは、業種を問わず高い頻度で現れます。

つまり、ポートフォリオに載せるべき実績の優先順位も、この4つに寄せるのが合理的です。新規開発の華やかな案件より、既存の仕組みを引き継いで直した経験のほうが、依頼者の関心に一致する場面が多い。どういう業務がシステム開発として発注されているかは、Web・業務システム開発のお仕事で扱われている業務範囲を見ると具体的に把握できます。ここで並んでいる作業内容と、自分のポートフォリオの記述が噛み合っているかを照らし合わせると、書き足すべき項目が見つかります。

近年は、業務システムに機械学習の推論やチャットボットを組み込む依頼も増えています。開発と運用の両方に関わる領域として、AI・マーケティング・セキュリティのお仕事の分類も確認しておくと、隣接領域として書ける経験が見つかることがあります。セキュリティ要件の整理や権限設計は、業務システム開発と地続きの仕事です。

自分の経験がどの職種区分に近いのかを客観的に把握したいときは、公的統計をもとにしたソフトウェア作成者の年収・単価相場のような職種データを参照すると、業界全体での位置づけが整理しやすくなります。ポートフォリオの冒頭に書く自己紹介の粒度を決める材料になります。

資格の扱いについても触れておきます。業務システム開発では資格が必須になる場面は少ないものの、インフラ側の要件が絡む案件では基礎知識の裏付けとして機能します。ネットワーク構成の理解を示す材料としてCCNA（シスコ技術者認定）を挙げる書き方は、オンプレミス環境の案件で効きます。また、仕様書や報告書の品質を示す観点ではビジネス文書検定のような文書系の資格が、意外なところで評価されることがあります。業務システムの現場は、コードよりも文書を読み書きする時間のほうが長いためです。

隣接する働き方の実態を知りたい場合は、UI/UXデザインのフリーランスになるには？必要スキルと案件相場のように、周辺職種の独立事情をまとめた記事も参考になります。業務システムの画面設計では、デザイナーと分担する場面が出てくるためです。

運営者として見てきた、ポートフォリオが効く場面

在宅ワークの市場を20年見てきた立場から言えば、ポートフォリオが最も効くのは、初回の依頼を取る場面ではありません。2回目以降の依頼を、別の発注者から取る場面です。

初回は、価格や納期、あるいは知人の紹介で決まることが多い。ところが2回目以降になると、依頼者は「前回と同じ品質で頼めるか」を判断材料にします。このとき、前回の仕事の進め方が言語化されているかどうかで、話の通り方が変わります。ポートフォリオを書く作業は、自分の仕事の進め方を棚卸しする作業でもあるため、書いた本人の説明力が上がる。実際、長く続いている開発者ほど、案件が終わるたびに記録を書き足しています。

もう1つ、運営者として見てきた限りでは、業務システム開発は仲介手数料の影響を強く受ける領域です。開発期間が長く、金額が大きくなりやすいため、割合で引かれる手数料の絶対額も膨らみます。中間マージンが乗らない直接取引なら、依頼者は同じ予算でより多くの工程を頼め、開発者の手取りは厚くなる。手数料0%の構造が効くのは、単発の小さな作業より、こうした長期の開発案件のほうです。

その意味でも、ポートフォリオは「一度きりの応募書類」ではなく、継続的な関係をつくるための資料として設計するのが合理的です。案件ごとの記録を丁寧に残し、承諾の範囲内で公開し、更新を止めない。地味ですが、業務システム開発という長い付き合いが前提の領域では、この積み重ねがそのまま信用になります。

よくある質問

Q. 業務システムの画面キャプチャは、企業名を消せば載せてよいですか？

企業名を消しても、画面構成そのものが秘密情報に当たる可能性があります。まず契約書の秘密保持条項を確認し、可能なら発注者に掲載範囲を具体的に示して承諾を得てください。承諾が取れない場合は、実物の代わりに画面遷移図や機能一覧を自分で描き起こす方法が安全です。図であれば設計意図は伝わり、守秘義務にも触れません。

Q. 実務経験がない場合、どんな題材を作れば評価されますか？

チュートリアルでよくあるタスク管理やブログではなく、実在する業務の不便を題材にしてください。飲食店のシフト作成、塾の月謝管理、地域クラブの会費管理などが扱いやすい題材です。重要なのは完成度より、運用している人に話を聞いた記録があることです。聞き取った制約と、それを受けた設計判断を併記すると実務案件と同じ形になります。

Q. ポートフォリオに載せる案件は何件くらいが適切ですか？

詳しく書く案件は3件前後に絞り、それ以外は一覧形式で並べる構成が読まれやすい形です。選定する側は1件あたりに長い時間をかけられないため、件数を増やすより、担当工程と技術選定の理由を具体的に書いたほうが効果があります。冒頭に対応できる業務領域のサマリーを置き、詳細は後ろに回してください。

Q. 技術スタックはどこまで詳しく書くべきですか？

言語やフレームワークの名前だけでは、使ったことがある事実しか伝わりません。バージョンと、その構成を選んだ業務上の理由を添えてください。既存の会計ソフトの出力形式に合わせた、保守を引き継ぐ社内担当者の習熟度に合わせた、といった説明があると、依頼者は自社環境への配慮ができる人だと判断できます。

Q. 公開形式はWebとPDFのどちらがよいですか？

概要をWebページで公開し、詳細版をPDFで個別に渡す二段構えが扱いやすい形です。Webは URL を渡すだけで済み検索からも見つかりますが、閲覧者を限定できません。PDFは送付先を限定できるため、承諾済みの範囲でのみ守秘性の高い内容を渡せます。業務案件のソースコードは、どの形式でも公開しないでください。