デザインの根拠（design rationale）

対象: 株式会社ネクストブリッジ（SES専業、エンジニア186名、営業8名、経営層3名）向け業務システム 画面: projects.html（案件一覧・検索）、management.html（経営方針検討）

本書はHTML実装より先に書いた。実装中に判断を変えた箇所は末尾「実装時の変更」に追記する。

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

A-1. 利用者と目的

利用者は営業担当。基準ペルソナは東京営業・佐藤（担当エンジニア23名、うち終了予定・待機中が5〜6名）。 彼が画面を開く目的は次の4つ。

G1とG2は本質的に同じ問い（「この待機予定者に合う案件はどれか」）を、G1は新着に限って毎朝、G2はエンジニア1人に絞って深く行う。したがって両者を同じ操作系（エンジニアを選ぶ → 合う案件が絞り込まれる）で扱うのがこの画面の中心設計。

A-2. 目的ごとの操作フロー（時系列）

G1: 朝の新着チェック

1. 画面を開く。最初に知りたいのは「今日・昨日の新着が何件あるか」と「自分の待機予定者は誰か（何人か）」。
2. 待機予定エンジニア（5〜6名）を1人ずつ頭に置きながら新着を眺める。実務では「Javaの田中さんに合うのは…、インフラの鈴木さんに合うのは…」と人を軸に流し読みする。
3. 合いそうな案件があれば、単価・開始時期・リモート条件・経験年数・面談回数・他営業の提案有無を確認する。
4. 良さそうなら詳細を開き、その場で提案操作をする（後回しにすると埋まる）。

G2: エンジニアに合う案件を探して3件提案

1. 画面を開き、対象エンジニア（例: 田中）を選ぶ。
2. 田中の条件（スキル・希望単価・終了日・希望勤務形態）で案件が絞られる。ここで手入力は不要であるべき。
3. 絞られた候補（10〜20件想定）を、単価・商流の浅さ・開始時期・リモート・勤務地・経験年数・社内競合 で比較する。表形式で列を揃えて並べるのが最も比較しやすい。
4. 気になった案件に候補マークを付ける（3件程度）。
5. 候補を1件ずつ詳細で確認（備考の「面談1回、即決したい」等、必須スキルの全文、エンド企業、商流制限、外国籍）。
6. 詳細から「提案する」→ 提案エンジニアは田中が既定で選ばれている → 確定。ステータスが「提案中」に変わり、一覧にも反映される。
7. 次の候補へ（一覧は閉じずに残っている）。

G3: 取引先の振り返り

1. 取引先名で絞る。
2. 普段は隠している「充足・クローズ・情報古い」を含めて、その取引先の全案件を見る。
3. 単価の分布（下限・中央値・上限）、商流、件数、直近の受信頻度を把握する。
4. 個々の案件をざっと見て、どの役割・スキルをどの単価で出しているかを掴む。

G4: 社内競合の把握

• G1/G2の一覧比較（ステップ3）と詳細（ステップ5）の中で「他営業が提案中」が視認できればよい。独立操作は不要。

A-3. 何を最初に見せ、何を隠し、何を最短にするか

最初に見せる（初期表示）

• 「本日の新着 N件 / 昨日 M件」のサマリ。G1の第一の問いに即答する。
• 自分の担当エンジニアのうち「終了予定・待機中・提案中」の5〜6名を左パネルに常時表示。氏名・主要スキル・終了日・希望単価・希望勤務形態を1カードに収める。G1ステップ2の「人を軸に眺める」を記憶に頼らせない。各カードに「該当案件 N件（新着 K件）」を出し、朝はカードの数字を見ただけで「今日は田中さんに新着2件ある」と分かるようにする。
• 一覧は受信日時降順、ステータスは「募集中・提案中」のみを既定。鮮度が命なので新しいものが上。本日受信の行は左端に青いマーカーを付け、一目で「ここまでが今日の分」と分かるようにする。

隠す（既定では見せない）

• ステータス「充足・クローズ・情報古い」。要件どおりG3のときだけ見せる。取引先を1社に絞った瞬間に自動的に全ステータスを含め、その旨を表示する（G3ステップ2の手数をゼロにする）。
• 案件の全項目。一覧には比較に必要な列（商流・案件名/取引先・単価・開始・リモート/勤務地・役割・必須スキル・経験・ステータス/提案状況・受信）だけを出し、精算幅・期間・面談回数・外国籍・商流制限・歓迎スキル・エンド企業・備考・最終更新は詳細に置く。
• 稼働中で終了未定のエンジニア（17〜18名）。左パネルでは折りたたみ、提案時のエンジニア選択では全員を出す。

最短にする操作

• 「エンジニアを選ぶ → 合う案件だけになる」を1クリックにする。条件の手入力を不要にする（G2ステップ1〜2）。
• 詳細は右側のドロワーで開き、一覧を残す。ページ遷移は使わない（G2ステップ5〜7の往復を最短化）。
• 提案は 詳細の「提案する」→ エンジニア（既定で選択中の人）→ 確定 の2クリック。

A-4. 操作負荷・認知負荷の低減策

A-5. 検討したが採用しなかった案

• カード型グリッド一覧: 案件ごとに情報量が多く見栄えはするが、単価・開始・商流を横に並べて比較できない。G2ステップ3は列を揃えた表が明確に速い。不採用。
• 詳細を別ページに遷移: 候補3件を往復するG2で一覧の状態（フィルタ・スクロール位置）が失われる。ドロワーに変更。
• エンジニアを選ぶUIをモーダルだけにする: 「今日は誰が待機予定か」がG1で毎朝最初に必要なので、常時見える左パネルの方がよい。モーダルは提案時のエンジニア選択に限定。
• ステータス別タブ（募集中/提案中/充足…）: G3で「その取引先の全案件」を一望する用途と相性が悪く、G1/G2でも募集中と提案中を分けたくない（提案中でも追加提案は可能）。フィルタの複数選択に統一。
• 全文検索1本: 「Java 70万 フルリモ」のような入力を解釈する方式。実装の曖昧さが高く、エンジニア選択で条件が自動で入るなら不要。キーワード欄は案件名・取引先・備考の部分一致に限定。
• マッチ度スコア（0〜100）でソート: 数値の根拠が営業に説明できず信用されない。「条件を満たす/満たさない」の二値と、単価・商流・受信日の明示的な並び替えに留める。
• 担当営業=自分の案件だけを既定表示: 案件情報の入手元が他営業でも提案は可能で、むしろ埋まる前に動くべき。既定は全営業、トグルで自分のみ。

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

B-1. 利用者と目的

利用者は経営層3名（代表、営業本部長、管理本部長）。

• 毎月第2営業日の経営会議で、1920×1080の会議室モニタに映しながら1時間議論する（主用途）。
• 代表が前日に自席PCで30分予習する（副用途）。

会議で決めることは要件の7議題。それぞれについて「この画面で答えるべき問い」に言い換える。

要件の並び（採用→単価→商流→待機→…）から、待機対策を採用方針の前に移す。理由: 待機（名前つきの具体行動）は会議の中で最も即時性が高く、また採用判断の根拠（今の待機が若手に偏っている）でもあるため、先に見せた方が採用の議論が噛み合う。

B-2. 目的ごとの操作フロー（時系列）

会議（1時間、モニタ）

1. 画面を開くと、上部に今月のKPI（売上・粗利率・稼働率・待機人数・待機コスト・平均単価・在籍・BP人数）が先月比・3ヶ月前比の差分付きで並ぶ。稼働率の低下（96→92%）が赤く目立つ。ここで「今月の異常は稼働率と待機」が共有される。
2. 左の議題ナビに7議題が並び、それぞれに1行の「要点」（例: 「終了予定14名、うち未着手6名」）が出ている。司会が「今日は待機から」と言って議題1をクリックする。
3. 議題1: 終了予定者一覧が営業別に並び、「提案未着手」が赤で目立つ。営業本部長が営業名を見て指示する。営業別の終了予定/提案中/未着手の横棒で、どの営業に未着手が偏っているか分かる。
4. 議題2: 稼働率・待機人数の24ヶ月推移、採用数と待機数の関係、採用パイプライン、単価帯別（若手=〜50万帯の待機）を見る。「月Nの採用を続けたら半年後の稼働率・待機コストはどうなるか」の簡易試算を、採用ペースを変えながら議論する。ここで来期採用数を決める。
5. 議題3: 単価帯別の人数・粗利率（50〜60万帯が薄利）と、顧客別の平均単価・粗利率を見る。粗利率が低い顧客・単価帯が琥珀色で目立つ。「4月改定で50〜60万帯を対象に、顧客X・Yから」と決める。
6. 議題4: 商流別の人数・平均単価・粗利。二次以下の人数比率と、取引先別（商流が深い取引先）を見る。
7. 議題5: 顧客別売上の横棒と依存度%。上位1社22%が閾値（20%）を超えて赤。
8. 議題6: 自社稼働率とBP人数・BPマージンの推移。「自社員が待機しているのにBPを増やしているか」を見る。
9. 議題7: 離職数・離職率の推移と、離職者の単価帯×年次×理由の分布。
10. 各議題の末尾に「決定事項メモ」欄があり、書記が結論を書く（ローカル保持でよい）。

予習（30分、代表のPC）

1. 上から順にスクロールして全議題の要点を読む。議題ナビの1行要点だけで全体像を10分で掴める。
2. 気になる議題（今月なら稼働率低下と採用）を深く見る。試算をいじる。
3. 論点を「決定事項メモ」に下書きしておく。

B-3. 何を最初に見せ、何を隠し、何を最短にするか

最初に見せる

• KPI帯（8指標）。数字は大きく（32px）、差分は色と矢印。閾値を超えたものは赤/琥珀で背景を付ける。
• 議題ナビの1行要点。「数字の羅列」ではなく「何が問題か」を文にして出す（データから自動生成する）。
• 各議題の冒頭に「この議題で決めること」と「現状の要点（2〜3行、数字入り）」を固定表示する。グラフはその下。

隠す

• 24ヶ月の生の月次表。要点はグラフで、数表は各議題の「月次データを表示」で折りたたみから出す。
• 顧客11位以下、離職者の個票、契約終了予定者の3ヶ月以上先。会議の1時間に不要。

最短にする

• 議題間の移動: 左ナビの1クリック、またはキーボードの左右矢印/PageUp・PageDown。プレゼン中にスクロールで探させない。1議題 = ほぼ1画面（1080px以内）に収める。
• 採用試算: スライダー1本（月あたり採用数）とラジオ（新規契約獲得ペース: 弱い/現状/強い）だけ。結果は半年後の在籍・稼働率・待機コスト・粗利を即時再計算。

B-4. 操作負荷・認知負荷の低減策

B-5. 検討したが採用しなかった案

• 12タイルのダッシュボード（全指標を1画面に）: 見た目は経営ダッシュボード的だが「何を決めるか」がなく、要件の「数字の羅列は不可」に反する。議題単位の構造に変更。
• 議題をタブで切り替え: 会議中の移動は速いが、予習で「上から読む」流れと、議題間（待機→採用）の連続した参照ができない。縦スクロール + 左ナビ + キーボード移動にした。
• ダークテーマ（プロジェクタ向け）: 会議室は明るく、印刷・他画面（案件一覧）との統一感も必要。白背景 + 濃色文字で高コントラストにする。
• フィルタやドリルダウンを多数用意する: 会議中の操作は司会1人で、操作が増えると議論が止まる。操作は「議題移動」「採用試算」「月次表の展開」「メモ」の4種に絞る。
• 稼働率などのゲージ（円形メーター）: 面積が大きく情報量が少ない。数値 + 差分 + 推移折れ線の方が「変化」を伝える。
• Canvas描画: 拡大時にぼける、テキスト選択不可。SVGで描く。

共通の見た目方針

• メインカラー: 青 #1f5fa8（濃）、#3b7ddd（標準）、#e8f0fa（淡）。警告: 赤 #c8382d、琥珀 #b8741a。文字: #1a1f2b、補助 #5b6472。背景: #f4f6f9、面: #ffffff、罫線: #d9dee6。
• 角丸は 3〜4px まで。影は使わない（ドロワー・モーダルのみ薄く）。グラデーション・半透明・絵文字なし。
• フォント: "Hiragino Sans", "Hiragino Kaku Gothic ProN", "Yu Gothic", "Noto Sans JP", "Meiryo", sans-serif。数字は font-variant-numeric: tabular-nums で桁を揃える。
• 状態バッジは塗り + 文字で、色に依存しない（文字が読めれば分かる）。

実装時の変更

実装・ブラウザ確認（1426×746 のウィンドウ）で根拠と異なる判断をした箇所。

• A: フィルタ帯は1行に収まらない。 根拠 A-4 では「1行に収め、常時表示」としたが、10項目 + ステータス5チェックを1行に置くと 1920px でも折り返す。2〜3行の折り返しを許容し、代わりに表の上に常時表示（スクロールしない）という性質は維持した。
• A: 取引先フィルタ解除時にステータスを既定へ戻す。 根拠では「取引先を選ぶと全ステータスを含める」のみ記述していたが、解除後も充足・クローズが残ると G1 の朝の確認で邪魔になるため、解除時は既定（募集中・提案中）に戻す動作を追加した。
• A: 本日受信の受信時刻は基準時刻（09:30）以前に限定。 ダミーデータ生成の都合で当初は本日 19:56 のような未来時刻が出たため修正。根拠に影響はないが、鮮度表示の信頼性のために記録する。
• A: エンジニア条件は個別フィルタに展開せず「エンジニアモード」として重ねる。 根拠 A-4 の「条件を緩める」ボタンは、個々のフィルタ欄を書き換えるのではなく、エンジニア条件の4要素（スキル・単価・時期・リモート）を個別にオン/オフする方式にした。通常フィルタと併用でき、解除で元の状態に戻れるため。
• B: 「1議題 = 1画面」は 1920×1080 前提。 1426px 幅では待機対策・採用方針の2議題が 1画面を超えた（表の折り返しが原因）。列の折り返しを抑え、グラフ高さを 260→230px に下げたが、会議室モニタ（1920 幅）以外では多少スクロールが発生する。予習用の PC 画面ではスクロールを許容する。
• B: 離職の月次グラフは直近13ヶ月のみ表示。 「直近12ヶ月の年率換算離職率」の折れ線は12ヶ月の履歴が必要なため、24ヶ月分の月次離職数のうち先頭11ヶ月は折れ線が描けない。24ヶ月の棒 + 13ヶ月の線という不揃いを避け、13ヶ月に揃えた。24ヶ月の生データは全体状況の「月次データを表示」で見られる。
• B: KPI の差分は2行（前月 / 3ヶ月前）に縦積み。 横並びだと 8タイルの幅で折り返して読みにくかったため。
• B: 上位1社のダミーは 45名。 売上依存度が要件の「22%」になるよう 44名から調整した。