「人事データマートの構築」「BI化」と言われると大きな話に聞こえますが、 中小企業の実物はたいていスプレッドシートから始まっています。 ここでは、その一番小さい形を実際に動かせるようにしてあります。
全体の構造
1件＝1行で表に書く
＝データマート
スクリプトが自動で
＝BI化
言葉の置き換え
| よく聞く言い方 | 実際にやっていること | この見本での中身 |
|---|---|---|
| 人事データマートの構築 | 散らばった人事の記録を、分析できる形で1か所に整える | 応募者の表と面談記録の表を、決まった列で作る |
| BI化 | その数字を、見て分かる画面にする | 集計スクリプト＋ダッシュボード1枚 |
| 採用歩留データの集計 | どの段階で何人減ったかを数える | 採用ファネルの表示 |
| 面談履歴のデータ化 | 面談メモに点数の欄をつけて残す | 4観点のスコア＋あとから傾向を出す |
| スクリーニング自動化 | 要件との合致を機械が整理し、判断は人がする | 書類選考の整理ページ |
| 定型業務の自動化 | 毎回同じ手順を1コマンドにまとめる | 集計コマンド1本で全部更新 |
「データマート」は倉庫の名前のようなもので、道具の名前ではありません。 Excelでもスプレッドシートでも、決まった形で貯まっていればそう呼べます。
実際のファイル構成
この見本は6つのファイルでできています。画面を作っているファイルより、記録の表のほうが大事です。
| ファイル | 役割 | 誰が触るか |
|---|---|---|
| data/applicants.csv | 応募者の表（1応募＝1行） | 人事担当（スプレッドシートで運用） |
| data/interviews.csv | 面談記録の表（1面談＝1行） | 面接官・人事担当 |
| data/requirements.json | 職種ごとの募集要件 | 人事担当（要件が変わったら書き換え） |
| build.js | 集計してダッシュボード用データを作る | 作った人（普段は触らない） |
| screen.js | 要件と突き合わせて合致度を整理する | 作った人（普段は触らない） |
| publish/*.html | 見る画面 | 見るだけ |
色をつけた2行が、この仕組みの本体です。ここさえ埋まっていれば、集計と画面はいつでも作り直せます。 逆に記録がなければ、どんなに立派な画面を作っても中身は空です。
動かすコマンド
cd "Dev/jinji-mini" node seed/generate.js # 架空データを作り直す（本番では不要） node build.js # 集計してダッシュボードを更新 node screen.js # 書類選考の合致度を整理
実際の運用では2行目は使いません。スプレッドシートから書き出したCSVを置いて、下2つを実行するだけです。
人に渡すなら、どの形にするか
渡し方は3通りあります。相手が自分で運用を続けられるかと、 こちらが保守を抱え込まないかの2点で選ぶのがおすすめです。
スプレッドシート完結型
渡すもの：記録用のスプレッドシート（関数と集計シート入り）＋運用マニュアル。
向き：相手にIT担当がいない中小企業。相手の環境だけで完結し、こちらの保守がほぼ発生しません。 見た目は地味になりますが、いちばん壊れません。
この見本と同じ構成
渡すもの：CSV＋集計スクリプト＋HTML画面 一式。
向き：相手側に手を動かせる人がいる場合。表現の自由度は高いですが、 実行環境の準備が必要で、相手が自力で直せないと問い合わせがこちらに戻ってきます。
記録は相手・集計はこちら
渡すもの：記録用スプレッドシート。月1回こちらが集計して、レポートを届けます。
向き：継続的な関係にしたい場合。相手はいつもの表に書くだけで、 システムを渡さないので障害対応が発生しません。月額の形にしやすい構成です。
渡すパッケージの中身（4点セット）
| # | 渡すもの | 中身 |
|---|---|---|
| 1 | 記録テンプレート | 応募管理シート・面談記録シート（列が決まっている） |
| 2 | 自動集計 | 歩留まり・経路別・職種別・採用単価の計算 |
| 3 | 見る画面 | ダッシュボード（この見本の1枚目） |
| 4 | 運用マニュアル | いつ・誰が・どの欄に書くか。列を増やしたいときの手順 |
4番を省くと、3ヶ月で記録が止まります。仕組みが壊れるのではなく、書く人が分からなくなって止まります。
渡す前に決めておくこと
個人情報をどこに置くか
応募書類・面談メモは個人情報です。相手の会社の中で完結させるのが基本で、 こちらが預かる場合は範囲と期間を決めます。氏名を伏せた集計だけを受け取る形にもできます。
止まったときに誰が困るか
集計が止まっても採用は続けられます。ただし「今月の報告に間に合わない」は起きます。 締切のある業務に組み込むなら、こちらが不在でも回る形にしておく必要があります。
合否の判断は渡さない
スクリーニングは材料を整えるところまで。判定まで機械に任せる設計にすると、 説明責任がこちらにも及びます。契約の文面でも線を引いておくのが安全です。
最初は1職種だけで試す
全職種を一度に始めると、列の設計が合っていなかったときの手戻りが大きくなります。 1職種3ヶ月で回してから広げると、要件の抜けが早く見つかります。
すでに手元で動いている同じ形
この構造は新しいものではなく、いま自分の事業で回している仕組みとまったく同じ骨格です。 対象が変わるだけで、やっていることは変わりません。
| 記録（表） | 集計 | 見る画面 | |
|---|---|---|---|
| 売上管理 | 売上ログ・請求書台帳 | build.js | 売上ダッシュボード |
| 経費管理 | 経費ログ・仕分けinbox | 同上 | 同じダッシュボード内 |
| 採用（この見本） | 応募者・面談記録 | build.js / screen.js | 採用ダッシュボード |
この見本に入れていないこと
また、この見本のデータは架空です。数字の傾向は実務でよく見る形に寄せてありますが、 特定の企業の実績ではありません。