BIエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

BIエンジニアのスキルシートは、作った画面の枚数より、プロジェクトの冒頭に「誰が、何を決めるための画面か」を1行で書き、データモデル・計算・公開・権限・更新のどこを自分が担ったかを分けて示すのが基本です。読み手は、ツールの名前の一致より、「同じ規模と難しさの仕組みを作って運用したことがあるか」を見ています。

全体の構成はスキルシートの基本をご覧ください。案件で見られるスキルの中身はBIエンジニアの案件で求められるスキルで扱っています。ここでは、シートへの書き方に絞って説明します。

プロジェクトの冒頭に「使われ方」を1行で置く

BIのプロジェクト欄では、案件の概要の次に、画面の使われ方を1行で書くと、読み手が難しさをすぐにつかめます。

• 「営業部門の週次会議で、支店ごとの受注の進み具合を確かめ、重点先を決めるための画面」
• 「経営会議の月次資料を、Excelの手作業からBIツールの自動更新に置き換えた」
• 「取引先の店舗担当者が、自分の店舗の在庫と販売の状況だけを毎朝確かめる画面」

使われ方が書いてあると、更新の約束や権限の難しさが説明なしで伝わります。3つめの例のように、社外に見せる・人ごとに見える範囲を変える、という要素があれば、それだけで運用の経験を示せます。

規模は「利用者・データ・画面・頻度」でぼかす

正確な利用者数や売上の規模は、参画先の事業を推測させる情報になります。次の4つを、桁や幅でぼかして書きます。

社名や固有の数字の伏せ方はスキルシートの守秘の記事で解説しています。

担当の欄は5つに分けて書く

BIの仕事は、同じ「ダッシュボード作成」でも、担った範囲で評価が大きく変わります。担当の欄を次の5つに分け、自分が担った項目だけを書くと、範囲が正確に伝わります。

画面の見た目の工夫だけで欄を埋めないことが大切です。構成やデザインの工夫は、使われ方とあわせて1行で書けば十分です。

技術欄はツールの製品を分けて書く

技術欄では、同じツールでも製品やサービスを分けて書くと、どこまで触れたかが伝わります。

• Power BI：Power BI Desktop、Power BIサービス、ゲートウェイ、ページ分割されたレポートなど
• Tableau：Tableau Desktop、Tableau Prep、Tableau Server、Tableau Cloudなど
• データの側：使ったDWH、SQL、変更の管理に使った道具

触れた程度に差がある場合は、「設計から運用まで」「改修のみ」のように添えると、面談での食い違いを防げます。経験した期間が短いツールは、使った時期も添えておくと、読み手が今の機能との差を判断しやすくなります。

資格の書き方

資格欄には、正式な名称、取得した年月、有効な状態を書きます。BIツールの主な認定は、どちらも定期的な更新が必要です。

• Microsoft認定: Power BI データ アナリスト アソシエイト（試験PL-300）は、12か月ごとの更新が必要です（2026年10月時点のMicrosoft Learnによる）
• Salesforce Certified Tableau Data Analystは、有効期間が1年で、年1回のメンテナンスを期限までに終えないと失効します（Trailheadの試験準備モジュールによる）

有効期限を書いておくと、読み手が状態を確かめやすくなります。資格の位置づけはPower BIの認定資格の記事とTableauの認定資格の記事で解説しています。

プロジェクト欄の記入例（架空）

以下は、書き方を示すための架空の記入例です。実在の会社や案件とは関係ありません。

期間：20XX年X月〜20XX年X月（1年）

案件概要：小売業の会社で、店舗の販売管理の帳票をBIツールへ移行

使われ方：本部の営業企画が週次会議で店舗ごとの売上と在庫を確かめ、販促の重点店舗を決めるための画面。店舗の担当者は自分の店舗のデータだけを毎朝確認

規模：利用者は本部と店舗で数百人規模、取り込み元は数システム、ダッシュボード十数本

担当：

• データモデル：店舗・商品・日付の切り口で共通のモデルを設計し、画面ごとに分かれていた取り込みを一本化
• 計算：既存帳票の指標を棚卸しし、定義が部門ごとに違った指標を営業企画と合意したうえでDAXで実装
• 公開と権限：店舗ごとに行レベルのセキュリティを設定。閲覧者の権限で配布し、店舗担当者の立場で見え方を確認
• 更新と運用：始業前の更新を設定し、失敗時の通知と再実行の手順書を作成

技術：Power BI Desktop、Power BIサービス、ゲートウェイ、SQL（DWHのビュー作成）

結果：月次の帳票作成の手作業がなくなり、店舗からの数字の問い合わせが減少（件数は社外秘のため傾向のみ）

移行と運用のプロジェクトの書き方

新しい画面を作ったプロジェクトより、移行や運用のプロジェクトのほうが書きにくいと感じる人は多いはずです。ただ、業務委託の案件では、移行と運用こそ経験者を求める場面が多くあります。

移行のプロジェクト

移す前と後のツール、移した帳票の数の幅に加えて、数字の突き合わせをどう進めたかを書きます。旧帳票の計算の誤りを見つけた、部門ごとに違っていた定義を整理した、といった内容は、移行の難しさを示す材料になります。

運用のプロジェクト

更新の監視、権限の申請への対応、性能の改善など、日々の作業を並べるだけでは評価が伝わりにくくなります。手作業を仕組みに置き換えたこと、問い合わせが減ったこと、遅い画面を直したことなど、運用を変えた点を中心に書きましょう。担当した期間と、運用していた画面やモデルの数の幅を添えると、どの程度の範囲を一人で見ていたかが伝わります。

分析や基盤の経験と並べるとき

分析やデータ基盤の経験もある場合は、プロジェクトごとに中心だった役割を一つ決めて書くと、読み手が混乱しません。分析が中心のプロジェクトの書き方はデータアナリストのスキルシートの記事、基盤が中心のプロジェクトの書き方はデータエンジニアのスキルシートの記事を参考にしてください。案件ごとにシートを見直すときの考え方はスキルシートの更新の記事にまとめています。

よくある質問

画面の枚数は書いたほうがよいですか？

書いてもかまいませんが、枚数だけでは難しさが伝わりません。共通のデータモデルの数、利用者の範囲、見える範囲の分け方とあわせて書くと、規模と運用の重さが伝わります。

改修だけを担当したプロジェクトはどう書けばよいですか？

既存のモデルや画面のどこを、なぜ直したかを書きます。表示が遅い原因を調べて計算式を直した、指標の定義の誤りを見つけて修正した、といった内容は、改修でも十分な実績になります。

求められているツールの経験がない場合はどう書けばよいですか？

使ったことのあるツールでの設計と運用の経験を具体的に書き、求められているツールとの共通点を添えます。データモデルの考え方や権限の設計は、ツールが違っても通じる部分が多くあります。