
結論:採用担当が知りたいのは 「Kaggleのスコア」ではなく「現場で本当に回るか」。だからこそ、要件が言語化され、再現できる実装があり、最後は意思決定に直結するレポートで締める——この3点を1つの物語として見せましょう。
この記事で身に付く力
- “業務再現”型ポートフォリオの設計術:要件→実装→レポートを一貫させる
- 再現性の高いプロジェクト構成:requirements/Docker/seed/ログまで
- 意思決定に効くレポート作成:1枚で伝わる骨子と図の型
背景:採用担当の“もやもや”は3つ
面接でよく聞くのは次の3点。「何を解決したのかが伝わらない」「動かせる状態になっていない」「スコアだけで意思決定の示唆がない」。これを解消するために、本記事では“要件→実装→レポート”の順で丸ごとコピペ可能なテンプレを配布します。
ふみとの体験談
データ/マーケティングサイエンティストとして10年で100件以上の案件を伴走しました。刺さる作品に共通するのは、要件がビジネス語で書かれていること、設計→コード→レポートが1対1で対応していること、そして再現性(Docker/requirements/seed/ログ)です。この記事はそのまま写経できるレベルに落とし込みました。
“要件→実装→レポート”のテンプレ(配布)
0) テーマ候補(まずは1本を深堀り)
- 社内定例の自動化:CSV整形→Excel2シート+メール送付
- 価格モニタ+可視化:API/HTMLで商品価格を取得→週次ダッシュボード
- 需要予測(小売):店舗×SKUの日次売上を予測→在庫補充の指標
- 異常検知(売上/勤怠):閾値+統計/機械学習でアラート
- RFM/CLV分析(マーケ):顧客セグメント化→施策示唆
1) リポジトリ構成(コピペ可)
proj-portfolio/
README.md
LICENSE
data/
raw/ # 入手したまま(触らない)
interim/ # 中間(Parquet)
processed/ # 最終(モデル入力/出力)
notebooks/
01_eda.ipynb
02_features.ipynb
03_model.ipynb
04_report.ipynb
src/
__init__.py
etl.py # 読み込み/前処理(純粋関数)
features.py # 特徴量化
model.py # 学習/推論
viz.py # 図作成(1意思決定=1関数)
io_utils.py # 原子置換/読書き
tests/
test_etl.py
test_features.py
requirements.txt
Dockerfile
docker-compose.yml(任意)
フォルダの意味は[内部リンク:ファイル操作]/[内部リンク:自動化]で詳述。キーワードは原子置換とidempotent。
2) README台本(雛形)
# 需要予測ミニプロジェクト(店舗×SKU)
目的: 発注判断のばらつきを減らすため、翌週の日次売上を予測し、在庫切れと過剰在庫を低減する。
データ: sales.csv(date, store, sku, qty, price), calendar.csv(holiday, weather, promo)
再現手順:
1. pip install -r requirements.txt(または docker compose up)
2. python -m src.etl で中間Parquet作成
3. python -m src.model で学習→processed/preds.csvを出力
4. notebooks/04_report.ipynb を実行→PDF化
成果物: report.pdf(意思決定の提案つき)、preds.csv、図(PNG)
ライセンス: CC BY-SA 4.0(データはダミー)
再現性はREADMEの1画面で完結。[内部リンク:Docker超入門]の箱配布ならさらに安心です。
3) 要件定義テンプレ(1ページ)
- 現状:在庫切れ/過剰在庫が月X件、店長の勘に依存。
- 目的:翌週の店舗×SKUの日次売上を予測し、安全在庫の算出に使う。
- 指標:MAE/MAPEで誤差を測定、前ルール(移動平均)比で△%改善を目標。
- 制約:学習30分以内/推論1店舗3秒以内/欠損が多い。
- 出力:preds.csv(store, sku, date, pred)、週次Excelレポート。
- 意思決定:
発注点 = 需要予測 × リードタイム − 安全在庫
4) 実装テンプレ(抜粋コード)
from pathlib import Path
import pandas as pd
RAW = Path("data/raw/sales.csv")
OUT = Path("data/interim/sales.parquet")
NA = ["", "NA", "-", "--"]
def read_sales(p: Path) -> pd.DataFrame:
return pd.read_csv(p, parse_dates=["date"], dtype={"store":"string","sku":"string","qty":"int32"}, na_values=NA)
def clean_sales(df: pd.DataFrame) -> pd.DataFrame:
df = df[df.qty >= 0].copy()
df["dow"] = df["date"].dt.dayofweek
return df
if __name__ == "__main__":
df = clean_sales(read_sales(RAW))
df.to_parquet(OUT, compression="zstd")
import pandas as pd
def make_features(df: pd.DataFrame) -> pd.DataFrame:
g = df.sort_values("date").groupby(["store","sku"])
for w in (7, 14, 28):
df[f"qty_ma{w}"] = g.qty.transform(lambda s: s.rolling(w, min_periods=3).mean())
df["promo_flag"] = (df.get("promo", 0) > 0).astype("int8")
return df
import pandas as pd
from sklearn.model_selection import TimeSeriesSplit
from sklearn.metrics import mean_absolute_error
from lightgbm import LGBMRegressor
IN = "data/interim/sales.parquet"
OUT = "data/processed/preds.csv"
if __name__ == "__main__":
df = pd.read_parquet(IN).pipe(make_features)
cols = [c for c in df.columns if c.startswith("qty_ma") or c in ["dow","promo_flag"]]
X, y = df[cols], df["qty"]
tscv = TimeSeriesSplit(n_splits=5)
maes = []
for tr, va in tscv.split(X):
m = LGBMRegressor(n_estimators=400, learning_rate=0.05)
m.fit(X.iloc[tr], y.iloc[tr])
p = m.predict(X.iloc[va])
maes.append(mean_absolute_error(y.iloc[va], p))
print({"MAE": sum(maes)/len(maes)})
# 本番推論は最新週で
df["pred"] = m.predict(X)
df[["store","sku","date","pred"]].to_csv(OUT, index=False)
関数の純度/境界は[内部リンク:関数とスコープ]、例外/ログは[内部リンク:例外処理とログ設計]で強化。
5) Notebook台本(章立て)
- 00_setup:目的/データ辞書/手順(2分)
- 01_eda:粒度・欠損・外れ値の確認、品質チェックリスト(行数/重複/日付連続性)
- 02_features:特徴量の根拠とリーク防止、重要度の可視化
- 03_model:ベースライン→チューニング、交差検証の図、ビジネス指標への翻訳
- 04_report:意思決定図(例:発注点の決め方)、改善インパクトの試算、次の一歩
6) 図の型(実務で刺さる4枚)
- 粒度×期間のヒートマップ(店×曜日×売上) → [内部リンク:可視化入門]
- 特徴量と重要度Top10(棒)
- 誤差分布の箱ひげ(店別)
- 意思決定フロー(発注点の式とサンプル計算)
7) レポートの骨子(1枚で伝える)
- 結論:発注点の更新で欠品率△x%、過剰在庫△y%見込み
- 根拠:予測MAEがベースライン比△z%改善
- 運用:[内部リンク:自動化]で週次自動更新/[内部リンク:例外処理]で異常通知
- リスク:新商品/天候急変時は誤差増→人の最終確認を必須に
提出パック(そのまま使える)
1) Notebookサマリ雛形
## 04_report(サマリ)
- 目的・業務影響
- データと品質チェック
- 手法(ベースライン→選定理由)
- 結果(誤差/改善率)
- 意思決定(発注点の式と例)
- 運用(更新頻度/自動化/監視)
- 次の一歩(A/B、特徴量追加、データ拡張)
2) 採用担当の採点表(自己チェック)
- 再現性(40点):requirements.txt/Dockerfile/データ入手手順
- 構成(20点):
src/
の役割分離、tests/
で最小テスト - 説明(20点):要件→実装→レポートの一貫性
- 示唆(20点):具体的な次アクションと影響試算
3) よくあるNG→改善
- NG:Notebook1枚に全ロジック → 改善:
src/
へ純粋関数、Notebookは結果と説明に - NG:精度が出ない時に沈黙 → 改善:ベースライン/制約/代替案を明示し、意思決定案を提示
- NG:
pip install
で詰まる → 改善:[内部リンク:Docker超入門]で箱を配る
用途別の“型”への当てはめ
- 価格モニタ: [内部リンク:API入門] or [内部リンク:Webスクレイピング] → [内部リンク:可視化入門] → [内部リンク:自動化]
- 異常検知: [内部リンク:scikit-learn基礎](IsolationForest/OneClassSVM)→ [内部リンク:モデル評価](Precision/Recall)→ 通知
- RFM/CLV: [内部リンク:pandas実践](集計/ピボット)→ セグメント施策 → ABテスト
今日やること(90分で骨格を作る)
- テーマを1つ選び、要件定義1ページを書く
- 本記事のリポジトリ構成を丸ごと作る
etl.py
とfeatures.py
をダミーデータで動かし、Parquetを出す04_report.ipynb
に結論→根拠→運用のひな形を書く
伴走サポート:あなたの“案件1本目”を仕上げます
無料カウンセリング/体験で、あなたのテーマを要件定義→実装→レポートまで添削し、提出できる形に仕上げます。レビュー→改善→再提出を1サイクル回しましょう。
TechAcademy データサイエンスコース(受講料:174,600円~ ※更に割引あり)

株式会社キカガク AI人材長期育成コース(受講料:237,600円~)

この記事から次に読むべきもの(内部リンク)
-
-
【保存版】データ職のポートフォリオ完全ガイド|再現性・評価・LTまで
ポートフォリオって「作ったものの置き場」でしょ? いいえ。採用側が見たいのは「意思決定に効いた証拠」と「再現性」です。 本ガイドは、未経験〜初学者が週10時間×4〜6週で、テーマ選定→要件定義→データ ...
-
-
コピペで回るレポート納品|Jupyter→PDF/HTML→共有の自動化テンプレ
毎週のレポート納品、朝にバタつきませんか? コードや図表は作ったのに、PDF化や共有で崩れる…。その“揺らぎ”を今日で終わらせましょう。 分析の価値は、最後の“納品物”で決まります。本記事では、Jup ...
-
-
“落ちない”社内自動化3選:再実行安全・ロック・JSONログで回す設計とテンプレ
社内の自動化、まず何から作ればいい? ちゃんと動き続けて、運用が楽になる設計が知りたい…! そんな悩みに対して、現場で短期に価値を出しやすい“3つの自動化”と、そのまま使える設計&コードの型をまとめま ...
-
-
コピペで動く需要予測|ARIMA×LightGBMでベースライン→運用まで
現場でちゃんと当たる需要予測って、どこから始めればいい? ベースライン→検証→運用まで、一気通貫で進める“型”で解説します。 この記事は、ARIMAとLightGBMを使った需要予測ミニプロジェクトの ...
-
-
勤怠・売上の異常検知は設計が9割|SLOとRules→Stats→MLで“静かな監視”を作る
異常検知は「驚きを、早く・静かに・正しく知らせる」ための仕組みづくり。 本記事は、勤怠/売上データの監視を“現場で使える形”に落とし込むための設計と実装テンプレをまとめました。結論から言うと、SLOを ...
-
-
【保存版】面接で刺さる発表の作り方:10分LTテンプレ/スライド構成/図解/Q&A台本/練習法まで完全ガイド
面接で評価されるのは「精度の高さ」ではなく、「意思決定を動かす説明力」です。10分のライトニングトーク(LT)で、結論→根拠→打ち手を一貫したストーリーで語れれば、未経験でも十分に刺さります。本ガイド ...
最近のコメント