Dynamics 365コンサルのスキルシートの書き方｜面談で評価される実績の見せ方

Dynamics 365コンサルのスキルシートは、プロジェクトごとに「領域（ERP系かCRM系か）」「モジュール」「役割」「工程」をそろえ、標準機能と業務の差をどう判断したかまで書くと伝わります。Dynamics 365の案件は、この組み合わせで募集されることが多く、読み手はまず組み合わせが合うかを確かめるからです。

この記事では、Dynamics 365ならではの書き方のポイントを、架空の記入例とあわせて紹介します。全体の構成はスキルシートの書き方の基本、求められるスキルはDynamics 365コンサルのスキルの記事で解説しています。

「Dynamics 365経験◯年」では中身が伝わらない

スキル一覧に「Dynamics 365（5年）」とだけ書かれたシートはよく見かけます。しかし、Dynamics 365はERP系とCRM系で中身がまったく違う製品群です。同じ5年でも、Financeで会計の設定を続けてきたのか、Customer Serviceで問い合わせの振り分けを設計してきたのか、X++で拡張を開発してきたのかで、合う案件はまったく変わります。

スキル一覧は、次のように組み合わせが見える形で書くと、読み手が案件の条件と照らし合わせやすくなります。

製品名は、Dynamics AXやDynamics CRMなど以前の名称で使っていた時期があれば、そのことも分けて書いておくと、経験の時期と現在の製品とのつながりが伝わります。

モジュールは機能の単位まで書く

「Financeを担当」だけでは、どこまで見たのかが伝わりません。Financeの機能コンサル向け資格では、総勘定元帳、現金・銀行、税、債権、債務、経費、予算、固定資産、原価計算、連結などが範囲として挙げられています（Microsoft Learn、2026年10月時点）。このくらいの単位で、自分が設計から担ったものと、設定を引き継いで保守したものを分けて書くと、深さが伝わります。

「判断した点」の欄を作る

Dynamics 365の案件では、要望をすべて開発で実現するのではなく、標準の機能に業務を合わせる判断が評価されやすくなります。開発が増えるほど、定期的な更新のたびの確認が重くなるためです。Finance and Operations系のアプリは年4回のサービス更新があり、顧客は年に最低2回の更新を適用する必要があるとされています（Microsoft Learn「サービス更新の可用性」、2026年10月時点）。

この判断は、プロジェクト欄の中に「判断した点」として独立させて書くと目に留まりやすくなります。

記入例1（架空）：ERP系の導入

工程：新規導入（要件定義〜本番稼働、約12か月）
案件概要：部品商社向け Finance・Supply Chain Managementの導入。旧会計システムと表計算での在庫管理からの置き換え
規模：国内2法人、利用者は百名規模、外部の受注システムと連携
役割：機能コンサル（会計領域の主担当、チーム8名のうち1名）
担当内容：経理部門への聞き取り、勘定科目と転記の設計、債権・債務の業務設定、期首残高の移行計画と照合
判断した点：法人ごとに分かれていた支払の承認の流れを、標準のワークフローに合わせて一本化する案を出し、開発の要望を取り下げてもらった
成果：会計まわりの拡張開発を最小限に抑え、稼働後の更新時の確認項目を減らした

記入例2（架空）：CRM系の移行

工程：旧製品からの移行（要件整理〜本番切り替え、約6か月）
案件概要：機器メーカーのサポート部門向け Customer Service への移行
規模：オペレーターは数十名規模、受付の窓口は電話とメール
役割：機能コンサル兼移行担当
担当内容：問い合わせの分類と振り分けのルールの整理、対応期限（SLA）の設定、過去のケースの移行範囲の決定と照合
判断した点：過去のケースをすべて移す案に対し、参照の頻度を業務部門と確かめ、直近分だけを移して古い分は参照用に残す形にした
成果：移行の作業量と切り替え当日の時間を抑えた

これらは書き方を示すための架空の例です。業種、規模、判断の内容は、ご自身の経験に置き換えてください。

規模は丸めた数で書く

Dynamics 365の設計の難しさは、規模によって変わります。法人や拠点の数、通貨の数、利用者の数、連携の数、移行したデータの量などを、丸めた数で書きます。

• 法人・拠点の数（国内のみか、海外を含むか）
• 利用者の規模（数十名、数百名など）
• 連携している外部システムの数
• 移行したデータの規模（件数の桁がわかる程度）

取引先の名前、売上や在庫の金額、ライセンスの契約数などは、社外に出せない情報にあたることがあります。どこまで書いてよいかはスキルシートに書いてよいこと・いけないことをご覧ください。

業務部門の経験と資格の書き方

経理、物流、営業、コールセンターなどの業務部門で働いた経験は、Dynamics 365の案件では業務知識の裏づけになります。IT以外の職歴も省かずに書き、どの業務をどの立場で担っていたかを一行添えると、要件定義を任せられる人かどうかの判断材料になります。

認定資格は、正式な名称と取得年月を書き、現在も有効かどうかを正確に記します。Microsoftの役割別の資格には、12か月ごとの更新が必要なものがあり、提供を終えた資格もあります。資格の状態は、Microsoft Learnの資格のページで確かめてから書きましょう。資格の位置づけはDynamics 365コンサルのスキルの記事で解説しています。

要約の欄の書き方

シートの冒頭の要約では、主軸の領域と役割を一文目に置きます。たとえば「ERP系（Finance）の機能コンサルとして会計領域の導入と保守を担当。販売・購買との連携の設計経験あり」のように書くと、読み手が最初の数秒で合う案件を思い浮かべられます。ERP系とCRM系の両方の経験がある場合も、主軸を一つに決め、もう一方は「連携の設計を担当」のように補足の形で書くと、軸がぶれません。

ほかの製品の書き方と見比べたい方は、SAP FI/COのスキルシートの記事やSalesforceのスキルシートの記事も参考になります。

よくある質問

保守の経験しかありません。どう書けばよいですか？

保守でも、扱った依頼の種類と、自分で設計から行った変更を分けて書けば十分な判断材料になります。サービス更新やリリースウェーブのたびの影響確認とテストを担った経験は、保守の案件で評価されやすいため、手順を自分で作ったかどうかまで書いておきましょう。

開発者の場合、何を書けばよいですか？

使った言語と基盤（ERP系のX++、CRM系のDataverse上の拡張など）、作ったものの種類（業務ロジック、帳票、連携）、テストとリリースの方法を書きます。あわせて、なぜ標準機能や設定では足りなかったのかを一言添えると、機能コンサルと組んで動ける人であることが伝わります。

以前の製品名で経験した内容も書いてよいですか？

書いてかまいません。Dynamics AXやDynamics CRMなどで経験した時期と、現在のDynamics 365での経験を分けて書くと、現役で使えるスキルが伝わります。旧製品からの移行に関わった経験は、移行の案件で評価されることがあります。