BIコンサルタントの職務経歴書の書き方｜KPI設計から利用定着まで工程別の例文を解説

相談してみる→

監修リメディ株式会社 ヘッドハンター清 龍一

東京大学を卒業後、株式会社クニエに入社。ヘルスケアチームにて、医療機関向けの業務改革およびDX支援に従事。製薬企業と医療機関の治験リクルートメント領域における新規サービス立ち上げプロジェクトでは、病院現場の業務プロセス整理やシステム要件の検証を担当。また、医療機関を対象とした医療DX推進プロジェクトに参画し、診療記録や問診票・同意書などの電子化を通じて、業務効率化と情報共有基盤の整備を支援。現在はこれまでのバックグラウンドを活かし、プロフェッショナルファームに在籍する / 志望する方向けの転職支援を行う。

ダッシュボードやデータ基盤を作ってきた経験は、KPI設計・データモデル・可視化・利用定着の4工程に分けて書くと、BIコンサル求人の要件に沿った職務経歴書になります。各工程で自分が決めた範囲と、誰の判断や業務が変わったかを書くのが基本です。今回確認したBI・データ活用支援のコンサル職を募集する5社の公式募集要項は、ツールでの構築経験と並べて、顧客との要件定義やデータ整備の設計を求めていました。

本記事は、BIエンジニア・SIer、データエンジニア、事業会社の分析担当、ITコンサル・PMOとしてBIに関わってきた人を対象に、経歴別の書き方から改善例、面接で確認されやすい項目までを扱います。

本記事のポイント

職務経歴書の中心に置くのは、ツール名ではなく「どの指標を誰と決め、作った画面がどう使われ続けたか」です。作った物より使われた場面を先に書くと、読み手はコンサル職として任せられる範囲を判断できます。

項目	内容
中心に書くこと	KPI設計・データモデル・可視化・利用定着の4工程ごとの担当範囲と、業務への影響
根拠にした資料	ブレインパッド、クラスメソッド、ジール、アビームコンサルティング、T4Cの公式募集要項（2026年10月18日確認）
前に出しすぎないこと	ツール名の羅列、ダッシュボードの本数、チームの成果を自分の成果のように書くこと
数値の扱い	自分の実績として説明できる事実だけを書き、ない数値は作らない
次の行動	応募先の募集要項で必須と歓迎を分け、当てはまる案件を工程ごとに並べ替える

自分の経歴に近い行を、次の早見表で確認してください。

現在の経歴	先に書く工程	補う経験	次の行動
BIエンジニア・SIer（ダッシュボード開発）	可視化・データモデル	指標を決めた場面、利用部門との合意	要件定義に関わった案件を冒頭へ移す
データエンジニア（DWH・データ基盤）	データモデル	誰のどの判断に使われたか	下流の利用者と指標を書き足す
事業会社の分析・レポーティング担当	KPI設計・利用定着	社外の顧客への提案や説明	依頼部門と決めた事項を、社内での合意形成として具体的に書く
ITコンサル・PMO	KPI設計（要件定義）	SQLやBIツールでの実装	自分で手を動かした範囲を明記する
業務システムの開発・運用保守	データモデル（DB設計）・運用	BIツールでの構築	導入コンサル候補の募集から確認する

補う経験の列に挙げた経験を書ける案件がないまま応募すると、書類で説明できない要件が残ります。足りない工程を書ける案件が手元にあるかを、応募前に探しておくと書き直しが少なく済みます。

BIコンサルの職務経歴書で見られるポイント

見られるのは、データを扱える技術と、顧客と目的を決めて使われる状態まで持っていく力の両方です。BIツールの開発職と比べると、顧客と決める工程の比重が大きい点が異なります。

確認した5社の募集要項に共通する要件

5社の募集要項を並べると、求める経験は次の6つに分かれます。必須か歓迎かは会社ごとに違うため、区分の列も合わせて見てください。

要件	募集要項での記載	区分
SQLなどでのデータ加工	ブレインパッドは「SQLおよびR/PythonなどOSSを用いたデータ加工・分析の実務経験（2年以上）」。クラスメソッドとT4CもSQLの知識を記載	必須
BIツールでの構築	ブレインパッドはTableau・Power BI等でのダッシュボード構築経験。クラスメソッドはBIまたはデータ準備・加工ツールの実務経験（いずれか1つ以上）	必須（T4Cは歓迎）
顧客との要件定義・説明	ブレインパッドは社外クライアントとの要件定義・課題整理・提案・報告。ジールは基本設計以上の顧客折衝。クラスメソッドは技術的な説明を関係者に分かりやすく伝える力	必須
KPI・目的の定義	ジールは業務内容にデータ活用の目的定義とKPI設計。ブレインパッドは業務内容にKPI・指標体系の設計、尚可にKGI・KPIを設定し改善した経験	業務内容・尚可
データ整備・モデル設計	アビームはデータ活用基盤上のデータモデル設計（データアーキテクト等の枠では必須）。ブレインパッドは複数データソースを統合するデータ整備・設計。クラスメソッドはデータモデリング手法を歓迎	必須・歓迎
利用定着・内製化	クラスメソッドは運用定着までのコンサルティングとユーザー向けトレーニング。ブレインパッドはクライアント社内のデータ活用体制・スキル内製化の支援	業務内容

必須の欄に、技術と並んで顧客との折衝が入っている点に注目してください。ジールは業務内容の中で、要件をまとめるのではなく「何をやるべきかを決めにいく」役割だと明記しています。

KPI設計から利用定着までの4工程で書く

プロジェクト欄は、4工程ごとに「自分が担ったか」「何を決めたか」を1行ずつ書くと、募集要項のどの要件を満たすかが一目で分かります。各工程で書く内容は次のとおりです。

工程	職務経歴書に書くこと
KPI設計	依頼した部門、決めた指標とその定義、合意した相手、指標を使う会議や業務
データモデル	統合したデータの種類、テーブルの粒度、更新の頻度と方法、自分の担当が設計か実装か
可視化	画面の利用者と使う場面、利用者ごとに画面を分けた理由
利用定着	説明会・マニュアル・問い合わせ対応、公開後の改修の受け付け方、使われ方の確かめ方

ダッシュボード開発の経歴で書き漏れやすいのは、最初と最後の工程です。指標を誰と決めたか、公開後に誰が使い続けたかが書いてあれば、意思決定の道具だったことが読み手に伝わります。

データアナリスト・データサイエンティストの書類との違い

分析職の書類が、問いの立て方や分析手法、分析結果が事業判断に与えた影響を中心にするのに対し、BIコンサルの書類の中心は、指標と画面を顧客と決めた過程と、利用部門が自分たちで使える状態にした経緯です。

公的な職業分類でも扱いは分かれます。厚生労働省の職業情報提供サイト（job tag）はデータサイエンティストを独立した職業として載せていますが、ITコンサルタントの職業別名にBIコンサルタントは含まれていません。分析職として応募するか迷う場合は、データアナリストの職務経歴書の書き方と比べて、自分の案件がどちらの書き方に合うかを確かめてください。

ここはリメディの見解ですが、上の表のとおり募集要項がツールでの構築と並べて要件定義やKPI設計を求めている以上、各案件はツール名から書き始めず、誰のどの判断に使われたかと自分が決めた範囲を先に書く方が要件に沿います。

4工程に当てはめてみると、同じ案件でも応募先によって前に出す工程が変わります。手元のどの案件を冒頭に置き、どの工程を書き足すかで迷ったら、応募予定の求人と並べて順番を確かめておくと、提出前の手戻りを減らせます。

経歴別に強調すべき実績

どの実績を前に出すかは、これまでの職種次第です。共通するのは、4工程のうち自分が深く担った工程を先に示し、手薄な工程は別の案件で補うことです。

BIエンジニア・SIerでダッシュボードを開発してきた人

開発した画面の数より、要件定義の場にいたか、データモデルを自分で設計したかを先に書きます。書き出したい項目は次の3つです。

• 要件定義に参加した案件で、利用部門の誰と何を決めたか
• データモデルやデータ連携の設計で、自分が担った範囲（設計か実装か）
• リリース後の改修依頼から分かった、実際によく使われた指標

受託開発では、要件が固まった後の実装だけを担当した案件も多いはずです。その場合は上流を担ったように書かず、実装中に指標の矛盾を見つけて提案したといった実際の行動を書く方が、面接でも説明できます。

データエンジニアとしてDWHやデータ基盤を作ってきた人

データモデルの工程は強く書ける一方、作った基盤を誰がどの判断に使ったかが抜けやすい経歴です。アビームコンサルティングのデータマネジメント・ガバナンスの募集では、データ活用基盤上のデータモデル設計と、BIやダッシュボードでの業務改善の経験が、同じ枠の必須要件に並んでいます。

基盤の案件を書くときは、下流で使われた画面や指標まで1行足してください。応募ルートそのものを検討する段階なら、データエンジニアからデータ/AIコンサルへの転職ルートで、応募要件と経験の照らし合わせ方を確認できます。

事業会社で分析・レポーティングを担ってきた人

KPI設計と利用定着は書きやすい反面、社外の顧客を相手にした経験が少ない点が課題です。ジールのテクノロジーコンサルタントの募集は、コンサルティングファームまたはSIerでのデータ活用支援・提案経験（3年以上）を必須にしており、社内の経験だけでは届きにくい求人もあります。

ただ、社内の依頼部門との仕事も、要望を聞き、優先順位を提案し、合意を取って作るという流れは顧客折衝と共通しています。部門名、相手の役職、決めた事項を具体的に書けば、提案の経験として伝わります。

ITコンサル・PMOとして要件定義を担ってきた人

要件定義や合意形成は書けるため、SQLやBIツールで自分が手を動かした範囲を明記することが補強の中心です。ブレインパッドの募集は、抽出〜加工〜可視化を完結できるスキルを必須に挙げています。

BI以外のITコンサル求人にも併願するなら、ITコンサルの職務経歴書の書き方も参考に、案件の並べ方を応募先ごとに変えてください。

書類選考で評価されにくい書き方

評価されにくいのは、作ったものは分かっても、誰の判断をどう変えたかが読み取れない書き方です。よくある4つの例と、直し方を示します。

ツール名と作った画面の数だけを並べる

「Tableauで営業向けダッシュボードを多数作成」という書き方では、ツールを使えることは分かっても、指標を誰と決めたか、どの会議で使われたかが分かりません。クラスメソッドのようにBIツールの実務経験を必須に置く会社でも、業務内容には要件に基づく設計や運用定着が含まれています。

「可視化した」で終わり、誰がどう使ったかがない

「売上データを可視化し、業務効率化に貢献」で終わると、可視化の後に何が起きたかが抜けます。会議の資料が画面の共有に変わった、店舗が自分で数字を確認するようになったなど、使った人の行動の変化まで書くと成果として伝わります。

チームの成果と自分の担当が区別できない

大きな案件ほど、「全社のデータ活用基盤を構築」のようにチーム全体の成果だけが書かれがちです。体制と自分の役割（設計担当、実装担当、利用部門との窓口など）を分けて書くと、深掘りされても説明がぶれません。

顧客名や社外秘の数値をそのまま書く

顧客名は「大手製造業」「全国チェーンの小売業」のように業界と規模に置き換え、売上などの社外秘の数値は割合や変化の向きで示します。どこまで書けるかは契約や社内規程で異なるため、迷う数値は載せない判断も必要です。

公式募集要項から逆算する成果指標

成果指標は、募集要項の要件ごとに「何を書けば満たしたと分かるか」から逆に決めます。下の表は、要件と書く項目、避けたい表現を1行ずつ対応させたものです。

募集要項で求められる経験	職務経歴書で書く項目	成果指標の例	避けたい表現	改善の方向
社外クライアントとの要件定義・課題整理（ブレインパッド必須）	相手の部門・役職、論点、合意した内容	合意できた指標、要件の手戻りの減り方	「顧客折衝を担当」	誰と何を決めたかを1文で書く
KPI・指標体系の設計（ブレインパッド・ジールの業務内容）	指標の定義、もとの課題、使う会議	会議資料の作成時間、判断までにかかる日数	「KPIを可視化」	定義を決めた経緯を書く
データモデル設計（アビーム必須、クラスメソッド歓迎）	統合したデータの種類、モデルの考え方、更新方法	集計の手作業の削減、データ更新の頻度	「DWHを構築」	設計と実装の担当範囲を分ける
BIツールでのダッシュボード構築（ブレインパッド・クラスメソッド必須）	利用者、使う場面、画面の構成	利用者の数、継続して見られている画面	「ダッシュボードを多数作成」	利用者と場面から書く
運用定着・トレーニング（クラスメソッドの業務内容）	説明会、マニュアル、問い合わせ対応、改修の流れ	自分たちで画面を直せる利用部門の広がり	「導入を支援」	公開後に何をしたかを書く
データ活用の内製化支援（ブレインパッドの業務内容）	引き継いだ相手、教えた内容	利用部門だけで回せるようになった範囲	「教育を実施」	誰が何をできるようになったかを書く

成果指標の列は一例で、すべてを埋める必要はありません。案件で実際に測っていた指標があれば、それを優先して書きます。

数値で示せない成果の書き方

利用状況を記録していなかった案件では、無理に数値を作らず、変化を事実で書きます。たとえば「週次の営業会議の資料を、手作業の表計算から画面の共有に切り替えた」「利用部門が自分で条件を変えて数字を確かめるようになった」といった書き方です。

数値も事実も自分の実績に置き換えて書き、面接で説明できない数字は盛らないことが前提です。事実で書けば十分に伝わる案件は多くあります。

企業タイプ別の見せ方

応募先のタイプによって、職務経歴書の冒頭に置く案件を入れ替えます。今回確認した募集を例に、重点の違いを並べました。

企業タイプ	確認した募集	募集要項に出ている重点	冒頭に置く案件	補足として書く経験
データ活用に特化した会社	ブレインパッド	現状把握から体制整備までの一貫支援、KPI設計	KPIを決めて改善まで回した案件	データ加工の実務年数、データ整備
総合系コンサルティングファーム	アビームコンサルティング	データ基盤・データモデル・ガバナンス、運用定着	基盤から活用まで構想した案件	IT全般の実務経験
データ基盤のコンサル・インテグレーター	ジール	目的定義・KPI設計・ロードマップ、クラウド基盤	目的の定義から実装までを主導した案件	クラウドでの開発・PM
BIツールの導入パートナー	クラスメソッド	可視化・変換・モデリングから運用定着、トレーニング	設計から定着まで担った導入案件	関連資格、クラウドDWHの経験
業務システム・BIツールの導入コンサル	T4C	DB設計からユーザトレーニング・運用保守までの導入工程	導入工程のどこを担ったか	開発・運用保守の経験

アビームコンサルティングの募集では、BIの職務とは別にIT全般の実務年数も問われます。同社は、デジタルテクノロジーに関連する業務経験3年以上を事業部門共通の必須要件に置いています。

ここはリメディの見解ですが、表の重点の列が会社ごとに違う以上、同じ職務経歴書を全社に出すより、冒頭の職務要約と最初の案件だけでも入れ替えた方が、各社の重点に合った書類になります。

未経験・隣接経験者の補強方法

BIの実務がまったくない状態では、今回確認した募集要項の多くで必須要件を満たしにくいのが実情です。ブレインパッドとクラスメソッドは、BIツールの実務経験を必須に置いています。

現在の経験	応募の現実性	先に作る実績	職務経歴書の書き方
完全未経験（データを扱う業務なし）	低い	現職でSQLやBIツールを使う業務を担う	業務の中で作った集計や画面を事実で書く
隣接経験（業務システムの開発・運用保守、社内の集計業務）	中程度	BIツールの導入や移行に関わる	担った工程を工程名で書く
経験者寄り（BIの構築実務あり）	高い	要件定義や定着の経験を足す	4工程に分けて書く

完全未経験の場合

まず現職の中で、データを集計して誰かの判断に使ってもらう仕事を引き受けるところから始めます。業務で作った実物があれば、職務経歴書に事実として書けます。学習だけの成果を、実務と同じ書き方で載せるのは避けてください。

業務システムの開発・運用保守から目指す場合

T4Cの見える化（BIツール）導入コンサルタント候補の募集は、業務系システムの開発・運用保守の実務経験と初歩的なSQLの知識を必須にし、BIツールの導入経験は歓迎に置いています。業務内容に並ぶのは、DB設計からユーザトレーニング、データ移行、運用保守までの工程です。

ここはリメディの見解ですが、開発・運用保守の出身者は、上の工程のうち自分が担ったものを工程名のまま書けば、こうした導入コンサル候補の業務内容とそのまま対応します。DB設計やデータ移行、利用者への説明を経験していれば、BIの導入でも同じ工程として書けます。

資格は歓迎要件として書く

クラスメソッドは歓迎経験にTableau Certified Data Analystなどの関連資格を、アビームコンサルティングは歓迎資格にベンダー認定資格やCDMPを挙げています。どちらも歓迎の欄の記載なので、実務経験を補う材料として書き、資格だけで要件を満たしたようには書きません。

職務要約とプロジェクト欄の書き方と改善例

職務要約で4工程のどこを担ってきたかを先に示し、プロジェクト欄でその根拠を案件ごとに書きます。要約と案件の内容をそろえると、読み手は要約に書いた強みを案件の記述で確かめられます。

書類の構成と各欄の役割

• 職務要約：担ってきた工程と、主な業界・案件の種類を数行で示す
• 職務経歴（プロジェクト）：案件ごとに体制、役割、工程別の担当、成果を書く
• 活かせる知識・スキル：SQL、BIツール、DWH、クラウドを、使った期間と用途とともに並べる
• 自己PR：4工程のうち最も強い工程と、応募先で担いたい役割を結びつけて書く

職務要約の改善例

Before：SIerにてBIツールを用いたダッシュボード開発に従事。TableauやPower BIを使用し、多くの案件を担当。

After：SIerで、小売・製造業向けのBI導入案件を担当。要件定義では利用部門と売上・在庫の指標の定義を決め、基幹システムのデータを統合するモデルの設計から、公開後の利用者向け説明会までを担ってきた。

Afterは、工程の名前と相手を入れただけで、誇張した成果は足していません。何を任せられる人かが要約の段階で伝わる点が違いです。

プロジェクト欄の改善例

Before：小売業向け売上ダッシュボード構築。データ連携と画面開発を担当し、業務効率化に貢献。

After：次のように工程ごとに分けて書きます。

• 案件：全国チェーンの小売業における、店舗別の売上・在庫ダッシュボードの導入
• 体制と役割：自社チームのうち、データモデルの設計と利用部門との窓口を担当
• KPI設計：営業企画と、週次会議で使う指標の定義と店舗の比べ方を決めた
• データモデル：POSと在庫のデータを統合するテーブルを設計し、更新を日次にした
• 可視化：店長が自店を確認する画面と、本部が店舗を比べる画面を分けて設計した
• 利用定着：店長向けの説明会とマニュアルを作り、公開後の改修依頼を受け付けた
• 成果：会議資料の作成時間や利用者数など、自分の実績として説明できる事実を書く

例の業界や工程は架空の構成例です。成果の行は自分の実績に置き換え、担っていない工程は空けたまま、別の案件で補ってください。

改善例の型を参考に、職務要約と最初の案件だけでも先に書き出してみてください。4工程のうち書けない工程がどこかが分かります。手元の経歴を入力しながら下書きを作るなら、作成ツールで書き始めることもできます。

面接で深掘りされる項目

書類に書いた工程ごとに、判断の理由を話せるよう準備しておくと、深掘りされても書類と話がずれません。下の表の質問は募集要項の要件から想定した例で、各社が公表している質問ではありません。

書類に書いた項目	確認されやすいこと	準備しておく材料
KPI設計	その指標を選んだ理由と、検討した別の候補	指標の定義、会議で決まった経緯
データモデル	粒度や更新頻度の決め方、データの品質で困った点	モデルの概要（社外秘を除いたもの）
可視化	利用者ごとに画面を分けた理由	画面構成のメモ
利用定着	使われなかった機能と、その後の対応	説明会の資料、改修の記録
チームでの役割	自分が決めたことと、上長や顧客が決めたこと	体制図

書類と面接で話がずれやすい点

ずれやすいのは、書類で「設計を担当」と書いた範囲と、面接で話す自分の作業の範囲です。たとえば書類にデータモデルの設計と書いたのに、面接で語れるのが既存の設計に沿った実装だけだと、書類全体の信頼が下がります。

提出前に、各案件の工程ごとに「自分が決めたこと」「指示を受けて作ったこと」を書き分けたメモを作っておくと、面接で聞かれても同じ言葉で説明できます。利用定着の工程では、使われなかった画面をどう直したか、あるいは廃止したかまで話せると、作った後まで責任を持っていたことが伝わります。

選考方法は応募先ごとに確認する

選考の形式は、会社や募集ごとにまちまちです。たとえばT4CのBIコンサルタントの募集要項は、選考方法を面接2回と適性検査（CAB）と記載しています。選考方法の欄は応募先ごとに確認し、適性検査や課題の有無を把握しておきましょう。

年収交渉につながる実績の書き方

交渉の材料になるのは、担当した工程の広さと、判断を任された範囲です。指定された画面を作った人と、KPIの定義から利用定着までを担った人とでは、入社後に任せられる役割が違います。

KPIの定義から利用定着までを担ったと書類で示せていれば、提示された職位や役割と比べて条件を相談する根拠になります。

逆に、職務経歴書が画面の開発だけで終わっていると、応募先が想定する役割も実装中心になりやすく、上流を担ってきた人でも条件の話がしにくくなります。KPIの定義や利用部門との合意を担った案件があるなら、年収の話をする前の段階で、書類の冒頭に移しておいてください。

提示条件を比べるときは、給与に含まれるものも確認してください。ブレインパッドの募集要項は固定残業代を含む給与として、ジールの募集要項は業績連動賞与を含む年収として記載しています。みなし残業時間と賞与の算定方法を確かめてから比べると、見かけの差に惑わされません。

BIコンサルの職務経歴書を相談すべきケース

応募先が決まっていて、必須要件ごとに書ける案件があるなら、まず自分で進めてよい段階です。迷いが残るのは、要件と案件の対応がつかないときです。

自分で進めてよいケース	相談すると早いケース
応募先の募集要項がはっきりしており、必須要件を満たす案件がある	必須要件のうち、書ける案件がない項目がある
4工程のうち複数を自分の担当として書ける	担った工程が実装だけで、上流や定着の経験をどう書くか迷う
顧客名や数値の書き方に迷いがない	社外秘の扱いが分からない案件が中心になっている
応募する職種を1つに絞っている	BIコンサル・データアナリスト・ITコンサルを併願したい

依頼部門と指標を決め、画面が会議や業務で使われるまで関わってきた人は、BIコンサルの職務経歴書で強みを示しやすい経歴です。一方、分析手法やモデルの精度を高めることを仕事の中心にしたい人は、分析職として書類を組み立てた方が希望と合います。その場合はデータサイエンティストとAIコンサルの違いも確認してください。

「相談すると早いケース」に当てはまる項目が多いなら、書類を書き上げる前に応募先の候補を絞った方が、書き直しは減ります。コンサル領域を担当するエージェントから相談相手を選べば、併願の組み方と書類の方向性を一緒に確かめられます。

よくある質問