業務委託の面談に向けて、経歴を書き出していました。「Dynamics 365の導入・保守 6年」と書いたところで、手が止まります。読み返した相手から「会計側ですか、営業側ですか。要件定義からですか、保守からですか」と聞き返される場面が、目に浮かぶからです。Dynamics 365のフリーランスとして業務委託で受けるなら、経験は「どの業務の、どの工程か」で書き分けます。

1. 経験が一行で終わってしまう理由

同じ製品群にあるERP側とCRM側

Dynamics 365と書いた一行には、違う仕事が二つ入りえます。一つは会計・販売・購買・在庫といった、社内の業務を支える側です。この記事ではERP側と呼びます。もう一つは営業や顧客対応といった、顧客と向き合う業務を支える側で、CRM側と呼びます。この区分は書き手の見立てで、製品の機能の説明はしません。

同じ製品群の名前でも、側が違えば、関わる部門も、話す相手も、決める内容も変わります。たとえばERP側で会計を担ったなら、話す相手は経理部門です。CRM側で営業を担ったなら、話す相手は営業部門です。

ところが「Dynamics 365の導入・保守」と一行にまとめると、どちらの部門と話した経験なのかが消えます。読み手は「会計側ですか、営業側ですか」と聞き返すしかなく、経験の中身を見る前に、確認のやり取りが一往復増えます。

工程が書かれていない経歴

経験をもう一段分けるのが、工程です。要件定義、設定、データ移行、テスト、運用保守が、ここで使う区切りです。同じ6年でも、要件定義の場で業務の流れを決めた人と、運用保守で問い合わせを受け続けた人とでは、参画先に渡せるものが違います。

業務領域を縦に、工程を横に並べると、経験は一枚のマス目になります。自分が担ったマスに印を付けると、「どこにいた人か」が読み手にも伝わります。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

印が1つのマスに集まる人もいれば、複数の工程にまたがる人もいます。どちらも経験として正しく、違うのは書き方だけです。では、この一行を公的な役割の言葉で読み替えると、どう見えるのでしょうか。

2. 公的な役割の定義で経験を読み替える

標準が示す二つの役割の定義

IPAのデジタルスキル標準ver.2.0（2026年4月）は、DX推進スキル標準の類型の一つ「ビジネスアーキテクト」を、ビジネスや業務の変革で実現したい目的を定義したうえで、経営視点で最適なビジネスモデルと業務プロセスを設計する役割として示しています¹。

同じ標準は、類型の一つ「データマネジメント」を、データの安全性・信頼性の確保と継続的な流通の仕組みの設計・実装・運用を行う役割などとして示しています¹。

定義の要約と読み替えの例

下の表の左と中央は、標準の定義の要約です。右の列は標準が述べたものではなく、書き手の読み替えの例です。標準がDynamics 365の経験をこれらの類型に当たると述べているわけではないため、右の列では「近い経験」として並べています。自分の経験を書くときも、「当たる」と言い切らず、定義との距離を添える形にします。

類型	標準の定義（要約）	近い経験の例（書き手の見立て）
ビジネスアーキテクト	ビジネスや業務の変革で実現したい目的を定義し、経営視点で最適なビジネスモデルと業務プロセスを設計する役割	導入の要件定義で、業務の流れを決めた経験
データマネジメント	データの安全性・信頼性の確保と、継続的な流通の仕組みの設計・実装・運用を行う役割など	データ移行・マスタ整備・連携の運用の経験

読み替えの線引き

定義が述べているのは、業務プロセスの設計と、データの仕組みの設計・実装・運用です。導入のなかで画面の設定だけを担った経験を、そのままビジネスアーキテクトの役割と書くことはできません。設計の目的を決める場面にいたかどうか、そこで何を決めたかが、読み替えの分かれ目です。

データマネジメントも同じです。移行やマスタ整備のうち、データの安全性・信頼性や、流れる仕組みに関わった部分だけが、定義に近い経験です。作業をこなしただけの部分まで広げて書くと、読み手が確かめたときに食い違います。

書き方としては、事実を先に書き、定義との近さを後ろに添えます。たとえば「導入の要件定義で、経理部門と業務の流れを決めた。標準でいうビジネスアーキテクトの役割に近い」という順です。標準の全体や、ほかの類型の読み方は、別の記事で扱っています。次は、業務の流れを決めた経験を、調査の数字と並べて書く方法です。

3. 業務プロセスに関わった経験の書き方

調査が示す成果企業の傾向

IPAのDX動向2026は、日本標準産業分類の19業種の企業の経営層またはICT関連事業部門を対象にしたアンケートで、1,799社から有効回答を得ています²。回答したのは企業の側で、フリーランスやエンジニア個人の回答ではありません。

この調査は、DXで成果が出ている企業の特徴として、経営者のデジタル見識が高いこと、経営者・IT部門・業務部門の協調が取れていること、全社レベルでの業務プロセス最適化に取組んでいることなどを挙げています²。傾向の記述であり、協調すれば成果が出ると示したものではありません。

DXに取り組む企業のうち、成果が出ている企業では、業務プロセスの全社最適化が「完了している」と「取組んでいる」の回答率の合計が53.8%でした。成果が出ていない企業では29.5%にとどまっています²。

出典：独立行政法人情報処理推進機構「DX動向2026」（2026年7月）をもとに作成

ただし、この数字はERPやDynamics 365の導入率ではありません。導入が成果につながると示すものでもなく、ここから言えるのは、回答した企業のあいだで取組の回答率に差があった、という範囲までです。

部門をまたいだ経験の書き方

調査が挙げる経営者・IT部門・業務部門の協調は、導入の現場でいえば、システムを作る側と使う側のあいだに立つ仕事に近い場面です。これは書き手の見立てで、調査がフリーランスの仕事をそう位置づけているわけではありません。

書くときは、関わった部門と、決めた範囲を並べます。「経理部門と営業部門の両方と調整した」だけでは範囲が広すぎます。「請求の締め日の扱いを、経理部門と営業部門のあいだで決めた」のように、何を決めたかまで一文に入れると、相手が経験の大きさを測れます。

決めた内容を思い出せないときは、会議の議事録や設計書の変更履歴が手がかりになります。自分の記録に残っている範囲だけを書き、記憶があいまいな部分は書かない、という線引きが安全です。次は、もう一つの定義であるデータの側の経験です。

4. データ移行とマスタ整備の経験の書き方

調査が挙げるデータ整備の課題

DX動向2026は、データ整備・管理・流通の課題として、「人材の確保が難しい」に次いで、「データの標準化が難しい」を36.8%、「管理システムが整備されていない」を32.6%と示しています²。割合は、この設問の対象になった企業の中での値で、1,799社全体に対する割合ではありません。

下の表は、この二つの課題と割合をそのまま並べたものです。企業側の課題を表しており、データ移行の経験者が不足しているとも、仕事が増えたとも示していません。そう読むかどうかは読み手の見立てで、この記事では断定しません。

データ整備・管理・流通の課題	割合
データの標準化が難しい	36.8%
管理システムが整備されていない	32.6%

何をそろえたか、誰と決めたか

取引先、品目、顧客のマスタをそろえた経験は、件数ではなく、何をそろえたかと、誰と決めたかで書けます。これは書き手の見立てです。件数は参画先の守秘に触れやすく、自分の記録にも残っていないことがあるため、数字よりも対象と相手を書くほうが、確かめられる経験になります。

「取引先と顧客の名前の表記をそろえた」「移行するデータの対象と順番を、経理部門と決めた」のように、そろえた対象、決めた内容、相手の部門を一文に入れます。

表2の「標準化が難しい」は、資料が課題の名前として示すだけで、中身までは述べていません。そのため経験を書くときは、自分の現場で何が違っていて、何にそろえたのかを、自分の言葉で書きます。次は、これらの経験を一枚の棚卸しシートにする方法です。

5. 棚卸しシートの作り方

シートに入れる6項目

経験を6つの項目に分けて書き出すと、一行の経歴が、読み手の聞きたいことに先回りして答える形に変わります。6項目は、これまでの節で使った業務領域と工程に、関わった部門、自分が決めたこと、成果物、規模の言い方を足したものです。項目の選び方は書き手の見立てで、資格や標準が定めた様式ではありません。

項目	書き方の例（書き手の見立て）
業務領域	ERP側・CRM側の別と、会計や営業などの業務名
工程	要件定義から運用保守までの、どこを担ったか
関わった部門	経理部門、営業部門など、話し合った相手
自分が決めたこと	範囲と内容を一文で（例：請求の締め日の扱い）
成果物	設計書、移行手順書、テスト仕様書、運用手順書など
規模の言い方	自分の記録で言える範囲だけ

書き出すときの線引き

シートは、関わった案件ごとに1行ずつ作ります。1行の中で、業務領域と工程の組み合わせが一つに定まるようにします。複数の工程にまたがった案件は、工程ごとに行を分けると、図1のマス目に印を付けやすくなります。

成果物の欄には、資料の名前を書きます。中身は書きません。設計書や移行手順書の名前を挙げれば、どの工程で何を作ったかは伝わります。一方、画面や項目の細かな中身まで書くと、参画先の守秘に触れるおそれが出ます。

規模の欄は、自分の記録で言える範囲だけにします。メンバーの人数や期間が記録に残っていなければ、空欄で構いません。思い出で数字を埋めると、面談で細かく聞かれたときに答えが食い違います。次は、書けない部分をどう言い換えるかです。

6. 秘密保持で書けないことの言い換え

名前と数字を出さない書き方

顧客名や具体的な数値は、参画先との契約で外に出せないことがあります。それでも経験は伝えられます。名前を消した分だけ、別の言葉で補えば足ります。これは書き手の見立てです。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

顧客名は、業種に置き換えます。拠点名は、拠点があったかどうかと、その数の有無だけにします。システム名は、「会計」「営業管理」のような業務領域の言葉に置き換えます。いずれも、第1節で分けた業務領域と工程の言葉に戻る形です。

たとえば「大手メーカーの基幹システム」と書く代わりに、「製造業の会計領域で、データ移行の手順を決めた」と書きます。誰の仕事かは伏せたまま、どの業務のどの工程かが読み手に届きます。

守秘の範囲を確かめる先

何が秘密保持の対象かは、過去の契約ごとに違います。この記事では、どこまで書けるかの判断には踏み込みません。書く前に、過去の契約書の秘密保持の条項を読み返し、迷う項目は書かないでおくのが安全です。

書かないと決めた部分があっても、経験の価値が消えるわけではありません。業務領域と工程が書いてあれば、相手は次の質問を選べます。次は、この棚卸しを参画先との最初の会話にどうつなげるかです。

7. 棚卸しを参画先との最初の会話につなげる

伝える順番

シートができたら、面談では、書いた順番のまま話します。まず業務領域を言い、次に工程を言います。続けてデータに関わった経験を話し、最後に部門との調整を話します。聞き手は、最初の一言で「どの人か」をつかみ、あとの話を同じ枠の中に置けます。この順番は書き手の見立てです。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

この記事で使った資料の位置づけ

標準は、ビジネスアーキテクトとデータマネジメントの役割の定義を示していました¹。調査は、DXで成果が出ている企業の傾向と、データ整備の課題を示していました²。どちらも、Dynamics 365の経験そのものを評価する資料ではありません。経験を読み替えて書くのは、あくまで自分の作業で、資料はその手がかりです。

棚卸しのあとに残るのは、「どの業務の、どの工程か」という物差しです。冒頭の一行に戻ります。「Dynamics 365の導入・保守 6年」と書いたとき、聞き返されて詰まった手は、この物差しを持っていれば止まりません。Dynamics 365の経験は、どの業務の、どの工程かで書きます。

書き出した経験を、実際に求められている案件と突き合わせる段階になったら、Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の業務領域と工程に合う条件を見てみるところから始められます。

8. よくある質問

ERP側だけ、またはCRM側だけの経験でもフリーランスの仕事は受けられますか

書き手の見立てでは、片側だけでも受けられないとは言えません。ただし、片側の経験は、業務と工程を具体的に書くほど伝わります。たとえば「ERP側の会計領域で、データ移行の手順を決めた」と書けば、経験の幅ではなく、深さが読み手に届きます。もう片方の経験がないことを、あとから補う書き方をする必要はありません。

ほかの業務パッケージの経験もあるとき、どう書けばよいですか

製品名で分けず、業務領域と工程のマス目に重ねて書く方法があります。たとえばSAPなど別の業務パッケージで会計領域を担ったなら、図1のマス目の同じ位置に印を付けます。製品が違っても、同じ業務領域と工程に印が重なるなら、経験は一つの形でまとめられます。これは書き手の見立てで、製品どうしを比べる話ではありません。

保守だけを担当してきた場合、何を棚卸しすればよいですか

保守の仕事を工程として分けて書きます。問い合わせの受け方、不具合の切り分け、改修の判断、月次や年次の処理の支え方が、その手がかりです。いずれも書き手の見立てで、保守の範囲や期間をどう取り決めるかは、別の記事で扱っています。まずは、自分が担った場面を一つずつ、業務領域と組み合わせて書き出してみてください。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「デジタルスキル標準」（2026年4月・2026年10月確認）
＊2 独立行政法人情報処理推進機構「DX動向2026」（2026年7月・2026年10月確認）