RPA・業務自動化のポートフォリオの作り方｜見る人が知りたいこと

2026年5月25日

長谷川奈津

この記事のポイント

✓RPA・業務自動化のポートフォリオの作り方を
✓掲載する題材の選び方から一件あたりの構成
✓更新の仕方まで解説します

RPA・業務自動化のポートフォリオを作ろうとして手が止まる理由は、ほぼ共通しています。作ったものを載せられない、載せられる形に直す方法が分からない、そもそも何を書けば読んでもらえるのか分からない。結論を先に書くと、この分野のポートフォリオで見られているのは作品の量ではなく、一件あたりの説明の質です。対象業務をどう選び、どこで人の判断を残し、止まったときにどうする設計にしたか。この三点が一件ごとに書かれていれば、掲載件数が少なくても通ります。この記事では、題材の選び方から一件あたりの構成、公開の形式、更新の仕方までを順に整理します。

ポートフォリオを見る人は何を判断しようとしているか

作り方に入る前に、読む側の目的を押さえます。RPA・業務自動化のポートフォリオを開く人は、大きく三通りです。事業会社で自動化の担当をしている人、開発会社で人を探している人、そして仲介の担当者。それぞれ見る場所が違います。

事業会社の担当者は、自社の業務を任せられるかを見ています。技術用語の正しさよりも、業務の話が通じるかどうかを気にします。開発会社の担当者は、実装の質と、チームで作業したときに手戻りが出ないかを見ます。命名や文書の書き方に目が行きます。仲介の担当者は、要点が短時間で拾えるかどうかを見ます。読み込む時間がないため、最初の画面で判断されます。

三者に共通しているのは、「この人に任せたときに、自分が困らないか」という一点です。ポートフォリオは作品集ではなく、リスクの少なさを示す資料だと考えると、載せるべき内容が定まります。

見る人が実際に確かめている五項目

現場で選考に関わっている人の話を集めると、確認されている項目はほぼ次の五つに整理できます。

一つ目は、対象業務を自分で選べるかどうか。言われた業務をそのまま作る人ではなく、向かない業務を止められる人が求められています。二つ目は、例外への備え。想定外のデータが来たときにどうするかを設計に組み込んでいるか。三つ目は、止まったときの復旧。異常時に誰がどう気づき、どう戻すかを決めているか。四つ目は、引き渡しの資料。他人が読める形で残せるか。五つ目は、業務理解の姿勢。担当者から暗黙のルールを引き出せるか。

この五項目に答える形で一件を書けば、ポートフォリオとして成立します。逆に、使えるツール名と作った本数だけが並んだ資料は、この五項目のどれにも答えていません。

掲載する題材をどう選ぶか

多くの人が最初に詰まるのが、載せる題材です。実務で作ったものは守秘義務があって出せない、自作のものは業務っぽくない。この二つの壁を越える方法を整理します。

実務の案件を載せる場合

契約書の秘密保持条項と権利帰属を先に確認します。秘密情報の定義が「本業務に関して知り得た一切の情報」となっている契約では、業務内容そのものが秘密情報にあたります。この場合でも、抽象化すれば掲載できる余地があることが多い。業種は大分類まで、企業規模は幅で、システムは種別で、業務は一般名詞で書く粒度なら、特定は困難です。

実名で書きたい場合は、依頼元に書面で許諾を求めます。掲載先、記載する範囲、掲載期間の三点を書いて送ります。口頭の了承は、担当者が異動した時点で消えます。これ、知らない人が本当に多いのですが、後から「聞いていない」と言われたときに証拠が残っていないと、契約違反を問われる立場に立たされます。※契約書の解釈に迷う場合や、すでに掲載してしまって指摘を受けている場合は、弁護士など専門家への相談を検討してください。

自作の題材を選ぶ条件

自作の題材には三つの条件があります。誰にでも業務内容が想像できること、処理の分岐が二つ以上あること、元データが公開情報または自分のデータで用意できることです。

分岐の数が重要です。単純に一つのファイルを開いて別の場所へ書き写すだけの処理は、技術的には動きますが、判断の説明ができません。条件によって処理を分ける、対象外のデータを別の一覧に出す、前回の実行結果と突き合わせる。こうした分岐があると、設計判断を書く余地が生まれます。

題材として使いやすいのは、公開されている統計データを定期的に取得して整形し、条件に合う行を抽出して通知する処理です。省庁や公的機関が公開している資料は、利用条件を確認したうえで題材にできます。総務省や経済産業省の統計ページは、形式が安定しているため題材に向いています。

実務に近い題材の作り方

もう一段実務に寄せたい場合は、身近な事務作業を題材にします。家族が営む事業の在庫表、地域団体の名簿管理、自分の請求書発行。実在の業務なので例外が必ず出てきます。「同じ商品名なのに表記ゆれがある」「担当者によって日付の書き方が違う」といった現実の汚れが、そのまま説明の材料になります。関係者の許諾を取り、データは架空のものに差し替えて公開します。

リモートで担える業務の幅は、思われているより広い範囲に及びます。

リモートワーク可能なRPA職種は、実は幅広く存在します。「開発経験がないと無理…」と思い込まずに、まずは自分のスキルや得意分野に合った職種を探してみましょう。ここでは、RPAを軸にした2つの分野【業務自動化系】【業務改善・DX推進系】を紹介します。出典: relasic.jp

開発だけが仕事ではないという指摘は、ポートフォリオの作り方にも直結します。業務改善の提案、対象業務の洗い出し、手順の標準化。これらを担った経験があるなら、実装のない案件でもポートフォリオに載せる価値があります。実際、依頼元が困っているのは実装より前の段階であることが多い。

一件あたりの書き方

ポートフォリオの質は、一件あたりの構成で決まります。次の八項目を順に並べる形が、実務上もっとも読まれます。

1. 一行の要約

最初に、何を自動化したのかを一行で書きます。「複数システムをまたぐ入金の突合を自動化し、月末集中だった作業を日次処理に変えた」といった具合です。読む人は最初の一行で読み進めるかを決めるので、ここに技術の話を入れません。

2. 背景と課題

その業務が、自動化前にどういう状態だったかを書きます。誰が、どのくらいの頻度で、何に困っていたか。ここが具体的だと、業務を理解して仕事をする人だと伝わります。「担当者が三つのシステムを行き来しながら目視で照合しており、月末に処理が集中していた」という記述は、依頼元の担当者が自分の会社に置き換えて読めます。

3. 対象業務を選んだ理由

複数の候補があった中で、なぜその業務を先に選んだのかを書きます。判断の軸は、処理件数の多さ、手順の固定度、入力元の安定性、失敗したときの影響範囲の四つです。この四つで説明できると、業務選定の経験があると受け取られます。自作の題材でも、この項目は書けます。

4. 処理の構成

自動化前と自動化後の流れを、図または箇条で示します。システム名は一般名詞に置き換え、部署名は役割で書きます。ここで示したいのは、いくつのシステムをまたぐか、分岐がどこにあるか、人の判断がどこに残っているかの三点です。

5. 人の判断を残した箇所と、その理由

もっとも評価される項目です。すべてを自動化しないという判断ができる人は多くありません。「金額が一定の水準を超える明細は自動処理せず、一覧に出して担当者が確認する形にした」といった記述には、必ず理由を添えます。理由があると、設計思想として読まれます。

6. 例外への対応

想定した例外と、それぞれの扱いを書きます。対応した例外だけでなく、対応しなかった例外とその理由も書きます。「月に一度も発生しない条件については、処理せず一覧に出す扱いとした」という記述は、判断の線引きができることの証明になります。

7. 異常時の設計

止まったときに誰がどう気づき、どう復旧するかを書きます。通知の宛先、途中まで処理したデータの扱い、手作業に戻す手順。この項目が書かれているポートフォリオは、実務経験の質が一段高く見えます。

8. 残した資料

運用手順書、障害時の対応表、設定値の一覧。何を渡したかを書きます。中身は出せなくても、項目立てだけなら出せます。項目を見るだけで、どこまで考えて仕事をする人かが伝わります。

公開の形式を選ぶ

内容が決まったら、置き場所を決めます。形式によって向き不向きがあります。

個人のサイトや文書公開サービス

もっとも汎用性が高い形です。案件ごとにページを分け、一覧から入れるようにします。利点は、読む人が必要な件だけを読めることと、更新が容易なことです。注意点は、検索で誰でも見られる状態になるため、掲載内容の抽象度を高めに保つ必要があることです。実名の許諾が取れていない案件は、業種と規模だけの記述に留めます。

提出用の資料ファイル

応募のたびに送る形です。相手を限定できるので、サイトより一段具体的に書けます。ただし、一度送ったファイルは相手の手元に残り続けます。転送される可能性も考えて、守秘義務に触れる情報は入れません。ファイル名に自分の氏名と更新日を入れておくと、相手の整理も楽になります。

動くものを見せる形

自作の題材であれば、実際に動く様子を録画して公開できます。処理の全体を長く撮る必要はありません。開始から終了まで、要点だけを短くまとめたもので十分です。実務の案件は、この形では出せません。

実装そのものを公開する形

汎用的な処理を、架空のデータ構造で書き直して公開する方法があります。開発会社が読む場合は、この形が最も効きます。読みやすい命名、処理の分割、設定値の外出し、エラー処理の書き方。実装の質は、ここで判断されます。逆に、事業会社の担当者はこの形を読めないので、他の形式と併用します。

やりがちな失敗

失敗1：ツール名の羅列で終わる

扱える製品名を並べただけの資料は、同じ製品名を並べた他の候補者と区別がつきません。製品名は前提条件であって、実績ではありません。製品ごとに「その製品で解決した業務の型」を一行添えると、はじめて中身が伝わります。

失敗2：技術の説明に紙面を使いすぎる

処理の実装方法を細かく書いても、事業会社の担当者はその良し悪しを判断できません。業務の課題、選定の理由、運用の設計を先に置き、実装は後半に回します。読む人が誰かによって、読まれる場所が違うことを前提に構成します。

失敗3：効果の数字に根拠がない

削減時間を大きく見せたくなりますが、面談で測り方を聞かれた瞬間に崩れます。どう測ったか、対象期間はいつか、比較の前提は何か。答えられない数字は載せません。数字が出せないときは、構造の変化で書けば十分に伝わります。

失敗4：件数を増やすことに集中する

似た内容の案件を十件並べるより、性質の異なる三件を丁寧に書くほうが強い。件数の多さは、読む人にとって負担でしかありません。分野の違う三件、たとえば経理まわりの処理、複数システムをまたぐ照合、外部サイトからのデータ取得を並べると、対応範囲の広さが伝わります。

失敗5：守秘義務を理由に何も書かない

「守秘義務のため詳細は記載できません」とだけ書かれたポートフォリオは、何も作っていない人の資料と区別がつきません。書けない部分を明示したうえで、書ける部分を先回りして出します。抽象化した構造、設計判断の記録、自作の再現版。この三つがあれば、守秘義務を守ったまま中身を示せます。

実務経験がない段階での組み立て方

未経験からこの分野に入る場合の順序を示します。

まず、題材を三つ決めます。性質が違うものを選ぶのが要点です。表計算ソフトのデータを整形して別の形式に出す処理、Webサイトから定期的に情報を取得して蓄積する処理、複数のファイルを突き合わせて差分を出す処理。この三種類があると、対応範囲の広さが示せます。

次に、それぞれについて設計書を先に書きます。実装から入ると、後から理由を思い出せません。要件、対象データ、処理の流れ、例外の扱い、テスト観点、既知の制約。この六項目を先に書いてから作ると、ポートフォリオの本文がそのまま出来上がります。

作ったら、必ず自分で壊してみます。元データを空にする、想定外の文字を混ぜる、途中で中断する。壊れ方を確認して、その対処を設計に反映します。この工程を経た人と経ていない人では、例外への備えの記述がまったく違います。

そのうえで、実際にどんな依頼が発生しているかを確認しておくと、題材の選び方がずれません。業務内容と求められる技能はRPA・業務自動化ツールのお仕事に整理されています。周辺のデータ活用や情報管理まで含めて範囲を考えるなら、AI・マーケティング・セキュリティのお仕事も合わせて見ておくと、伸ばす方向を決めやすくなります。

資料そのものの読みやすさが評価される

見落とされがちですが、ポートフォリオは文書としての質そのものが評価対象です。誤字が多い、項目立てがそろっていない、専門用語の定義が途中で変わる。こうした資料を出す人は、納品する運用手順書も同じ品質だろうと推測されます。

とくに気をつけたいのが、用語の統一です。同じものを「ロボット」「ボット」「シナリオ」「ワークフロー」と呼び分けていると、読む側は混乱します。最初に一つ決めて、最後まで通します。略語も同様で、初出で読み方を補足し、以降は統一します。

読み手が誰かによって、使う言葉も変えます。事業会社の担当者に向けた資料では、業務の言葉で書きます。開発会社に向けた資料では、技術の言葉を使って構いません。同じ内容でも語彙を入れ替えるだけで、伝わり方が変わります。文書作成の基礎を体系的に確認したい場合はビジネス文書検定の出題範囲が実務的な目安になります。

もう一つ、実行環境やセキュリティに関する記述の正確さも見られます。ロボットが社内ネットワークや複数システムを横断する以上、認証情報の扱い、ログの保存、実行端末の管理といった話題は避けて通れません。この記述が曖昧だと、実務での判断も曖昧だろうと受け取られます。基礎を押さえるうえではCCNA（シスコ技術者認定）の学習範囲が土台になります。

使ったツール別に書き分ける

同じ内容でも、使った道具によって書ける範囲と書くべき内容が変わります。

デスクトップ型の商用RPA製品を使った案件では、作ったワークフローの定義ファイルが依頼元の資産になっていることがほとんどです。ライセンス条項で第三者への開示が制限されている場合もあるため、実装そのものは出せません。この場合は、抽象化した処理の構成と設計判断の記録が主役になります。製品名を書けるかどうかは契約次第ですが、製品名までは書けるケースが比較的多いので、確認する価値があります。

業務システムに標準で付いている自動化機能や、表計算ソフトのマクロ、スクリプト言語で組んだ処理の場合は、汎用的な部分を自分の題材に書き直して公開しやすい傾向があります。処理の考え方を示す最小限のものを、架空のデータ構造で組み直して置いておくと、技術面の説明が一気に楽になります。

クラウド型の自動化サービスを使った案件では、接続先の組み合わせ自体が依頼元の内情を示すことがあります。「表計算ソフトとチャットツールを連携させた」までは書けても、業種と組み合わせると推測できてしまう場合は、連携先を種別で書きます。この判断は自分でつけるしかないので、迷ったら抽象度を一段上げます。

どの道具を使う場合でも、選んだ理由を書いておくと評価が上がります。無償のツールと有償の製品、システム付属の機能。それぞれに向き不向きがあり、その業務でなぜそれを選んだのかを説明できる人は、道具に振り回されない相手として見られます。

面談でポートフォリオをどう使うか

作った資料は、送って終わりではありません。面談での使い方まで設計しておくと、効果が倍になります。

相手の業務に引きつけて話す

面談の前に、相手の業種で発生しやすい定型業務を三つ想定しておきます。そのうえで、ポートフォリオの中から構造が近い案件を選び、「御社ですと、この案件と似た形になると思います」と接続します。この一言があると、資料が自分の話ではなく相手の話に変わります。

掲載していない判断も話せるようにする

資料に書いた内容は、聞かれる前提で準備します。とくに「なぜその設計にしたのか」「他の選択肢は検討したのか」は必ず聞かれます。書いていない検討過程まで答えられると、資料の内容が本物だと伝わります。逆に、書いてあることを聞かれて答えられないと、その資料全体の信憑性が疑われます。

資料の弱い部分を自分から言う

対応しなかった例外、性能の限界、想定していなかった事態。こうした弱い部分を自分から話せる人は信用されます。隠していて後から発覚するより、先に出したほうが評価は高い。この姿勢は、そのまま納品後の報告の仕方を想像させます。

更新と使い分け

作って終わりにすると、半年で古くなります。

案件が一件終わるたびに、一件ぶんを追記する習慣にします。終わった直後は記憶が新しく、判断の理由をすぐ書けます。数か月たつと、なぜその設計にしたのかを自分でも思い出せません。終了時の作業として、ポートフォリオへの追記を組み込んでおきます。

応募先によって、並べる順序を変えます。経理まわりの自動化を求めている相手には、その案件を先頭に置きます。順序を変えるだけで、読み手が最初の画面で見る内容が変わります。全件を書き直す必要はなく、並べ替えるだけで十分です。

古い案件は削るか、下に移します。使わなくなった製品での事例が先頭にあると、現在の技能が古く見えます。掲載を続ける判断基準は、その案件で示せる設計判断が今も通用するかどうかです。

最初の画面に何を置くか

読む人が最初に見る場所の設計が、全体の成否を分けます。仲介の担当者は数十件の資料をさばいており、読み込む時間がありません。事業会社の担当者も、最初の数行で読み進めるかを決めます。

置くべきは三つです。担える工程の範囲、扱える業務の型、そして連絡が取れる条件。「業務ヒアリングから要件定義、実装、テスト、運用手順書の作成まで一貫して担当」という一行は、技術の羅列より強い。工程の範囲が広い人は、間に人を挟まずに済むため、依頼側の負担が小さくなります。

業務の型は、製品名ではなく処理の性質で書きます。複数システムをまたぐ突合、大量データの一括処理、定時起動と結果通知、外部サイトからの情報取得。この書き方だと、自社の業務が当てはまるかどうかを読む人が自分で判断できます。

連絡が取れる条件は、意外に効きます。平日の日中に連絡が取れる、初回の返信は当日中を目安にしている。こうした情報は、稼働後の保守を任せる相手を探している依頼元にとって、技術力と同じくらい重要な判断材料です。

一方で、最初の画面に置かないほうがよいものもあります。経歴の羅列、学習に使った教材の一覧、資格の取得年月だけの記載。これらは後半に置きます。読む人が知りたいのは、過去に何を学んだかではなく、いま何を任せられるかです。

市場を長く見てきた立場からの観察

20年この市場を見てきた立場から言えば、依頼が続く人のポートフォリオには、必ず「やらなかったこと」が書かれています。全部を自動化しなかった理由、対応しなかった例外、断った依頼。書ける人が少ない項目であり、しかも読む側がもっとも知りたい項目です。できることを並べる資料は多いのに、線を引ける人だと示す資料は驚くほど少ない。

運営者として見てきた限りでは、ポートフォリオの厚みは、契約の形にも影響されます。間に何社も入る形では、業務の背景を聞けないまま作業だけが流れてくることが多く、判断の記録が残りません。依頼者と直接つながる形では、ヒアリングから関われるぶん、書ける材料が自然にたまります。中間マージンが乗らない手数料0%の形は、同じ予算で依頼者はより多く頼めて、受け手は手取りが厚くなる。金額の差に見えて、実際には「書ける経験がたまるかどうか」という質の違いを生んでいます。

自分の立ち位置を客観的に測りたい場合は、公的統計にもとづく職種別の水準が物差しになります。開発工程を担う人材の水準はソフトウェア作成者の年収・単価相場で、手順書や報告資料の作成が主体となる工程は著述家，記者，編集者の年収・単価相場で確認できます。RPA・業務自動化の実務は両方の性質をまたいでおり、ポートフォリオでどちらを厚く見せるかによって、届く案件の性質が変わります。

ポートフォリオを組み立てる手順のまとめ方

最後に、作業の順序に落とします。

第一に、過去の案件を洗い出し、契約書の秘密保持条項と権利帰属を一件ずつ確認します。第二に、実名で載せられるものは書面で許諾を取り、取れないものは抽象度を落とします。第三に、実務経験が足りない場合は、性質の違う自作の題材を三つ決め、設計書を先に書いてから作ります。第四に、一件あたり八項目、要約、背景、選定理由、処理の構成、人の判断を残した箇所、例外の扱い、異常時の設計、残した資料の順で書きます。第五に、公開の形式を決め、事業会社向けと開発会社向けで語彙を変えた版を用意します。第六に、案件が終わるたびに一件ぶんを追記し、応募先に応じて順序を入れ替えます。

RPA・業務自動化のポートフォリオは、作品の展示ではなく、判断の記録です。この考え方に切り替えた時点で、書ける内容は一気に増えます。