READMEと構成図で伝える｜データエンジニアのポートフォリオの作り方と載せてはいけないもの
- 最終更新日：2026/10/15
データエンジニアのポートフォリオは、画面の見栄えではなく、データがどこから来てどう変換され、どこで使われるのかを再現できるかで評価されます。デザイナーの作品集のように目で見て分かる成果物が少ない分、何をどう見せるかで差がつきやすい職種でもあります。この記事では、作品の題材の選び方、READMEの書き方を例文と添削で確かめる方法、面接で聞かれる点、載せてはいけないものを順に説明します。
データエンジニアのポートフォリオは動いた証拠と設計の理由で評価される
採用する側が知りたいのは、見た目の派手さではありません。データを取り込み、変換し、保管して、利用者に届けるまでの一連の流れを、この人は自分の手で組み立てられるのかという点です。そのため、作品には次の四つをそろえるのが基本になります。
- 目的と使うデータを説明したREADME
- 全体の流れが分かる構成図
- 実行できるコードと手順
- 出力結果の例
コードは、GitHubなどで公開しておくと、採用担当者がすぐに中身を確認できます。
作品の題材を三つの型から選ぶ
題材に迷ったら、次の三つのどれかに当てはめると決めやすくなります。
公的オープンデータを毎日取り込む型
政府統計の総合窓口であるe-Statが公開するAPIや、気象庁の公開データなど、無料で誰でも使える公的なデータを使います。決まった時刻にデータを取得して、クラウドDWHの無料枠やDuckDBに保管し、dbtなどで集計表を作る流れです。実在のデータを使うと、欠損や形式の違いといった現実的な問題に自然と出会えます。
疑似的なログを流して集計する型
自分でダミーのアクセスログを生成し、一定間隔で取り込んで、直近の件数を集計する構成です。リアルタイム処理の理解を示せますが、設計の難度が上がるため、一つ目の型で土台を作ってから挑むのが現実的です。
手作業の集計を自動化する型
経験者向けの題材で、手作業のExcel集計を、取り込みから出力までの自動処理に置き換える構成です。実務の内容をそのまま載せると守秘義務に触れるため、データも業務内容も架空のものに作り替えて使います。
READMEの書き方を例文と添削で確かめる
同じ作品でも、READMEの書き方次第で伝わる情報量が大きく変わります。架空の例で比べてみましょう。
伝わりにくいREADMEの例
「天気のデータを取ってきて、BigQueryに入れて集計しました。Airflowを使っています。」この説明では、何のために作ったのか、どのデータをどの頻度で取っているのか、失敗したときにどうなるのかが読み取れません。使った道具の名前を並べただけでは、設計の判断を評価してもらえません。
添削後のREADMEの例
「目的は、地域別の日次の降水量を、過去の売上データと並べて見られるようにすることです。気象庁が公開する観測データを毎日朝6時に取得し、生データのまま保管したのち、地域と日付ごとの集計表へ変換します。同じ日の処理を二度実行しても結果が変わらないよう、日付単位で上書きする設計にしました。取得に失敗した場合は、翌日の再実行で欠けた日を補います。」添削のポイントは、目的、データの出どころ、更新の頻度、失敗したときの挙動を、文章の中に入れたことです。
構成図に入れておきたい要素
図には、次の要素を左から右へ並べると見やすくなります。
- データの出どころ
- 取り込み処理
- 生データの保管先
- 変換と集計
- 利用者に見せる出力
- 失敗を知らせる通知
面接で聞かれる点から逆算する
ポートフォリオは、面接で話す材料にもなります。想定される質問に答えられるよう、作品を作りながらメモを残しておくと役立ちます。
なぜその構成を選んだのか
BigQueryを選んだ理由、更新を日次にした理由、データを生のまま残した理由など、選択の根拠を聞かれます。ほかの選択肢と比べたうえでの判断を一言で言えるようにしておきましょう。
二重に実行しても壊れないか
同じ処理を二回流しても結果が同じになる性質を、冪等性と呼びます。再実行が日常的に起こるデータ基盤では重要な考え方で、日付単位での上書きなど、具体的な工夫を説明できると評価されやすくなります。
データ量が増えたらどうなるか
無料枠の範囲でも、データが十倍に増えたときの処理時間や費用の見積もりを聞かれることがあります。実際に計測した数字を持っていると、説得力が出ます。
載せてはいけないもの
現職や前職のコードとデータ
業務で書いたコードや、実際のデータ、社内の仕様書は、公開してはいけません。実績を示したい場合は、構成だけを抜き出し、データを架空に置き換えて、公開してよいか勤務先に確認します。
認証情報やAPIキー
設定ファイルにAPIキーを書いたままリポジトリへ公開してしまう事故は、実際によく起こります。環境変数や秘密情報の管理機能を使い、コミットの対象から外す設定を、公開の前に確かめてください。
手順どおりに動かない作品
READMEの手順をなぞっても動かない作品は、評価を下げます。公開前に、別の環境で一から再現できるか試してください。
GitHubのプロフィールを見られる前提で整える
作品を公開しても、見つけてもらえなければ意味がありません。応募書類にリンクを載せるなら、先頭に固定表示する作品を二つか三つに絞り、説明文を一行ずつ添えます。更新の履歴が数か月前で止まっていても問題はありませんが、READMEの冒頭で、現在の状態と今後の改善予定を書いておくと、放置された作品ではないと伝わります。コミットのメッセージも、何を直したのか分かる言葉で残しておきましょう。
未経験と経験者で見せ方を変える
未経験の方は、作品の完成度に加えて、学んだ順番と、つまずいた箇所をどう乗り越えたかが伝わると、成長の見込みを示せます。経験者は、扱ったデータの規模、処理時間の改善、障害の減少といった成果を、公開してよい範囲の数字で示します。どちらの場合も、全体の進路はデータエンジニアになるにはで整理でき、選考を見据えるなら、あわせてデータエンジニアのキャリアパスで、どの段階で何を求められるのかを見ておくと、載せる内容を絞りやすくなります。
一作品を公開するまでの流れ
- 題材とデータの出どころを決め、目的を一文で書く
- 取り込みから集計までを最小の形で動かす
- READMEと構成図を書き、別の環境で再現を試す
- 認証情報が含まれていないか確認して公開する
最初の一作は小さくて構いません。動いて、説明できる一本があれば、次の改良の足場になります。