SES企業向け業務システム 画面要件

0. 成果物

• 画面ごとに 単一の自己完結HTMLファイル（CSS/JS埋め込み、外部CDN不可、ブラウザで開けばそのまま動く）
  • projects.html … 案件一覧・検索画面
  • management.html … 経営方針検討画面
• ダミーデータはHTML内のJSに埋め込む。要件に書かれた業務上リアルな分布になるよう生成すること（全件同じような値は不可）。
• 日本語UI。フォントはOS標準のゴシック系（Hiragino Sans / Yu Gothic / Noto Sans JP 等のフォールバック指定）。
• メインカラーは青系。いわゆる生成AI的な見た目（紫〜ピンクのグラデーション、絵文字アイコン、ガラス風の半透明カード、意味のない装飾、全部丸角）は避ける。実務者が毎日8時間見続けられる業務システムの見た目にする。
• フレームワーク不要。バニラJSで良い。グラフが必要な場合もライブラリ不可（SVG/Canvasを自前描画）。

1. 会社のシチュエーション

• 株式会社ネクストブリッジ（仮名）。SES（システムエンジニアリングサービス）専業。設立11年目、東京・秋葉原本社、大阪支店あり。
• 所属エンジニア 186名（正社員 152名、契約社員 34名）。ほか、協力会社（BP）からの外部要員を常時 30〜40名 抱えて再委託している。
• 営業 8名（東京6・大阪2）。各営業が担当顧客と担当エンジニア（20〜25名）を持つ。
• 経営層：代表取締役、取締役営業本部長、取締役管理本部長 の3名。毎月第2営業日に経営会議を実施。
• 売上規模：月商 約1.35億円（年商 約16億円）。平均売上単価 約68万円/月/人。平均原価（給与+法定福利）約49万円。
• 業界慣行：
  • 契約は準委任、月単位。精算幅（例：140〜180h）で上下精算あり。
  • 商流：エンド → 元請け（SIer）→ 一次 → 二次 …。自社の立ち位置が深いほど単価が下がる（一段で概ね 5〜10万円 落ちる）。
  • 案件情報は元請け・一次会社の営業からメールで日々届く（1日 20〜40件）。良い案件は 2〜3日で埋まる。
  • 契約終了は翌月末が多く、終了確定から次案件決定までに 待機期間 が発生すると原価だけ出続ける（待機1人あたり月約 49万円の損失）。
  • エンジニアの面談は通常 1〜2回。オンライン面談が主流。
  • 単価改定交渉は年1回（4月）or 契約更新時。

2. 画面A：案件一覧・検索（projects.html）

利用者と利用状況

• 主利用者：営業担当（例：東京営業・佐藤、担当エンジニア 23名）。
• 使うタイミング：
  1. 朝、届いた新着案件を眺めて「自分の待機予定エンジニアに合うものがあるか」を確認する（毎日10分）
  2. 特定のエンジニア（例：来月末で契約終了する Java 7年のエンジニア、希望単価 70万以上、フルリモート希望）に合う案件を探して提案先を3件ほど選ぶ
  3. 顧客との商談前に、その顧客の過去〜現在の案件と単価水準を振り返る
• 提案するとステータスが「提案中」に変わり、他の営業も見える。同じ案件へ複数営業が別エンジニアを提案することもある（社内競合の把握が必要）。

案件データ項目

• 件数：120〜160件。ステータス分布は 募集中 45% / 提案中 15% / 充足 20% / クローズ 10% / 情報古い 10% 程度。

業務上の探し方（ユーザーが何を見て、何で絞りたいか）

• 「このエンジニアに合う案件」探し：スキル（必須に含まれる）× 単価下限 × 開始時期 × リモート条件 × 勤務地 で絞る。経験年数条件も見る。
• 「今日入った新着」を先に見たい。鮮度が命。
• 商流が浅い（単価が高く残る）案件を優先したい。
• 他の営業がすでに提案している案件は社内競合になるので分かるようにしたい。
• 「情報古い」「充足」は普段は隠したいが、顧客振り返りの時は見たい。
• 顧客（取引先）単位で単価水準を比べたい。
• 一覧から1件を選んだら詳細を見て、そこから「エンジニアを提案する」操作をする（提案するエンジニアを選ぶ → 提案中に変わる）。提案の実送信（メール）は画面外で良いが、状態変更は画面に反映すること。

補助データ：担当エンジニア（自分の担当分）

• 営業・佐藤の担当エンジニア 23名。各エンジニアに：氏名、年齢、主要スキル（複数）、経験年数、現在の単価、現契約終了予定（未定 / 2026-09-30 / 2026-10-31 / 2026-11-30 など）、希望単価、希望勤務形態、居住地（沿線）、ステータス（稼働中 / 終了予定 / 待機中 / 提案中）。
• 終了予定・待機中は 23名中 5〜6名程度。

3. 画面B：経営方針検討（management.html）

利用者と利用状況

• 主利用者：経営層3名。毎月第2営業日の経営会議で、この画面を大型モニタに映しながら1時間議論する。また代表は会議前日に自分のPCで30分ほど予習する。
• 会議で決めること（=この画面で判断したいこと）：
  1. 採用方針：来期（半年）で何人採用するか。今のペースで稼働率と待機を見て、採るべきか止めるべきか。
  2. 単価交渉方針：どの顧客・どのエンジニア層の単価を上げに行くか。原価に対して利幅が薄い契約はどこか。
  3. 商流改善：二次以下の案件比率をどう減らすか。どの取引先経由が薄利なのか。
  4. 待機対策：来月・翌々月に契約終了予定が何人いて、うち提案が進んでいないのは誰か（営業別に）。
  5. 顧客集中リスク：上位顧客への売上依存度。
  6. BP（外部要員）活用：自社員の稼働率と BP マージンのバランス。
  7. 離職：離職率の推移、離職者の属性（単価帯・年次）。

用意すべきデータ（過去24ヶ月分の月次時系列を含む）

• 月次：売上、原価、粗利、粗利率、在籍エンジニア数、稼働人数、稼働率、待機人数、待機コスト、平均売上単価、平均原価、BP人数、BP売上、BPマージン、採用数、離職数、契約終了数、新規契約数。
  • 直近の傾向として：稼働率がここ3ヶ月で 96% → 92% に落ちている。採用を強化した結果、若手の待機が増えている。平均単価は微増。離職は年率 10〜12%。
• 顧客別：上位10顧客の売上・人数・平均単価・商流・粗利率・契約終了予定人数。上位1社への依存が 22% ある。
• 商流別：エンド直/元請け直/一次/二次/三次以下 の人数・平均単価・平均粗利。
• 単価帯別（〜50 / 50〜60 / 60〜70 / 70〜80 / 80〜90 / 90〜）：人数、平均原価、粗利率。50〜60 の層が薄利であることが見える。
• 営業別：担当人数、稼働率、契約終了予定人数、うち提案中人数、うち提案未着手人数、平均単価。
• 契約終了予定者一覧（来月・翌々月）：氏名、スキル、単価、終了日、担当営業、提案状況。
• 採用パイプライン：応募/一次面接/二次面接/内定/入社予定 の人数と、入社予定月。
• 離職者（過去12ヶ月）：入社年次、単価帯、退職理由分類（待遇 / 案件内容 / 転職 / 家庭事情 / その他）。

見せ方に関する条件

• 会議室のモニタ（1920×1080）で離れて見ても読める。
• 議題ごとに「何を判断するか」が分かる構成。数字を羅列するだけの画面は不可。
• グラフはSVG/Canvasの自前描画。ライブラリ不可。
• 判断につながる異常値・変化（例：稼働率の低下、薄利の顧客、提案未着手の終了予定者）は目立たせる。