リソース配分ボード

設計ノート

解いている課題

ある程度の規模のチームでは、リソースの情報が3段階に分かれて別々の場所に溜まります。 ①案件側が立てる計画（何人・何時間必要か）②管理側が決める割り当て（誰をどこに何%） ③本人が入力する実績（実際に何時間）。3つとも「人 × 案件」の話なのに、 置き場所も更新のタイミングも粒度も違うため、突き合わせは手作業の表計算になりがちです。 この画面は、その突合を毎朝の自動処理側に寄せることを狙っています。

設計判断：なぜ「残高を減らしていく」見せ方なのか

消化の状況は「今月これだけ使った」（積み上げ）でも表せますが、この画面では 予定を月初残高に置き、そこから引いていく形にしています。 現場が知りたいのは使った量ではなく「あとどれだけ残っているか」で、 引き算の形にすると残高がそのまま縦軸に出るためです。灰色の点線＝理想のペースと比べれば、 線が下に離れていれば使いすぎ、上に離れていれば消化が遅れている、と一目で判断できます。

工数と原価を別の画面に分けているのも意図的です。 メンバーの等級によって1時間あたりの単価が違うため、この2つは一致しません。 単価の高いメンバーが多く動いた月は、時間には余裕があるのに予算が先に尽きます。 同じ軸に重ねると（単位の違う2本の縦軸になり）関係のない相関を読ませてしまうため、 形を揃えた2枚のチャートを並べて、差そのものを読み取れるようにしました。

設計判断：ステータスを「予定消化率との差」で出す理由

案件の良し悪しを消化率だけで判断することはできません。予定は期間の最後まであるのに、 実績は今日までしか無いからです（半分しか経っていない案件の消化率50%は正常）。 そこで本日までに消化しているはずの割合＝予定消化率を工数・原価それぞれで出し、 実績の消化率と比べています。判定は2つで、①予定消化率との差が20ポイント以上開く ②実績が予定を使い切っている（100%超）。工数と原価を別々に判定しているのは、 片方だけがずれる状態こそ拾いたいものだからです （工数は予定どおりでも、単価の高いメンバーが動いていれば原価だけ先に超過する）。

予定消化率は「期間の経過率」ではなく予定そのものを日割りした累計にしています。 月によって割り当て人数が違う案件では、この2つは一致しません （後半に人を厚くする案件は、期間が半分過ぎても予定の消化は半分に届かない）。

設計判断：なぜ月次のボードと案件別の一覧を分けたのか

見たいものの期間の単位が違うためです。ボードは「今月あと何時間使えるか」＝ 月の中の残高を見る画面で、締めの単位が月に固定されています。一方で案件は月をまたぎ、 月初から始まるとも月末で終わるとも限りません。案件の良し悪しは着手から完了までの通算で見るもので、 これを月次の画面に同居させると「今月の消化」と「案件通算の消化」という別物の数字が並び、必ず取り違えが起きます。 そこでタブで画面ごと分け、工数実績（案件一覧）のほうは対象月を「どの案件を並べるか」の絞り込みにだけ使い、 表に出る数字は期間トータルとしました。さらに工数実績（案件詳細）を分けて、 1案件を期間全体で掘る場所（消化の推移・誰がどの月に入っていたか）を用意しています。 一覧で気になった案件をクリックすればそのまま詳細に入る、という順路です ＝一覧で見つける → 1件を掘るの2段階に画面を対応させています。

月をまたぐ以上、月の途中で始まる・終わる案件が出ます。その月の予定工数は その案件が動いている営業日ぶんに按分して数え、消化の理想線もその案件の稼働日から下がり始めるようにしています （月まるごとの予定と比べると、途中から始まった案件が一律で「消化が遅れている」と誤検知されるため）。

設計判断：なぜ「事前生成した静的ページ」なのか

• 速さ：閲覧時に集計しないので、開いた瞬間に出ます。毎朝見る画面では表示待ちがそのまま利用率に響きます。
• コスト：常時起動のサーバーもBIツールのライセンスも要らず、配信は静的ホスティングだけで済みます。
• 単純さ：閲覧権限の管理が「このURLを見られる人」の一点に集約され、ツール内の権限設計を持ち込まずに済みます。
• 割り切り：代わりにリアルタイム性は捨てています。日次で判断が変わらない指標だからこの方式が成立するのであって、 当日の残業判断のような用途には向きません。この線引きが設計の要点です。

デモデータについて

表示しているデータは全て自動生成した架空のものですが、ランダムに散らしているわけではありません。 案件ごとに「消化のクセ」を設計して埋め込んでいます — 工数も原価も超過している案件、 工数は想定どおりなのに上位等級に作業が偏って原価だけ先に減っている案件、 工数は超過ぎみでも下位等級中心なので原価は予定内に収まっている案件、 立ち上がりが遅れて後半に巻き返している案件、ほとんど動いていない案件。 全部が予定どおりに進むデータでは、このダッシュボードを見る意味が無いためです。 案件の期間もばらしてあります — すでに完了した案件、今月立ち上がったばかりの案件、 1ヶ月だけのスポット案件などを混ぜ、対象月を切り替えると工数実績（案件一覧）の顔ぶれが変わるようにしました。 生成スクリプトには「案件の進み具合が3種類以上あるか」「工数は想定どおりだが原価だけ減る案件が存在するか」 「対象月ごとにその月にしか出ない案件があるか」を確認する自己チェックを入れてあり、 条件を満たさないと生成が失敗します。

効果をどう測るか

この種のツールの効果は「作った画面の数」ではなく、消えた作業で測ります。 置き換え対象は「毎朝／毎週、複数システムから抽出して表計算で突き合わせていた時間」。 役割ごとに削減時間を見積もり、人数を掛けて月あたりの人日に換算するのが実務的です。 厳密な計測をしていない場合は、その旨も含めて概算だと明示するのが誠実だと考えています。

作り方

合成データの生成から集計・HTML生成までを1本のPythonスクリプトにまとめ、 画面側は表示と絞り込みだけを担当します（重い処理をブラウザに持ち込まない）。 絞り込みの組み合わせ（月 × チーム × 案件）はあらかじめ全通り集計してページに埋め込んであるため、 操作しても再計算も通信も発生しません。代わりにページ自体は大きくなりますが、 同じ構造の繰り返しなので圧縮が効き、実際に転送されるのは1割程度です。生成スクリプトはリポジトリに同梱しています。