デザインの根拠（C_rationale_after）

対象: projects.html（案件一覧・検索）、management.html（経営方針検討） この文書は2つのHTMLを実装・ブラウザ確認したあとに書いた。抽象原則ではなく、この要件のこの利用者に対して「なぜこの配置・この操作にしたか」を書く。

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

1. 利用者と目的

利用者は東京営業・佐藤（担当エンジニア23名、うち終了予定・待機・提案中が6名）。1日20〜40件のメールで届く案件を、自分の担当エンジニアの空きに当てはめることが仕事の中核。画面を開く目的は3つ。

副次的に「他営業が同じ案件に提案していないか（社内競合）」を常時把握する必要がある。これは目的ではなく、A1・A2の判断中に必ず確認する制約条件として扱った。

2. 目的ごとの操作フロー（実装した画面での時系列）

A1 朝の新着チェック

1. 画面を開く。既定タブは「募集中」で受信が新しい順。先頭に本日分がまとまり、左端の青いバーと NEW タグで「ここまでが今日届いた分」が一目で分かる。タブには「本日新着 27」のように件数が出ているので、まず「今日は何件来たか」を把握する。
2. 左サイドバーの「要対応」グループ（待機中→終了予定→提案中の順、終了日が近い順）を見て、今日どのエンジニアのために案件を見るのかを思い出す。ここは常時表示で、エンジニア画面へ遷移しなくて済む。
3. 新着行を上から流し読みする。1行で「案件名／取引先／商流バッジ／単価／開始／リモート／役割・経験・必須スキル／状態／自社提案状況／担当」が読めるので、行を開かずに「山田に合いそう」「これは大阪だから無視」と判定できる。
4. 気になる案件があれば、サイドバーのエンジニアをクリックして A2 のフローへ移る（またはそのまま行をクリックして詳細を見る）。

A2 特定エンジニアに合う案件を探して提案する

1. サイドバーで対象エンジニア（山田）を1クリック。画面上部に「山田太郎に合う案件を表示中」のバーが出て、判定に使った条件（スキル、希望単価、終了日、リモート希望、経験年数）が並ぶ。
2. 一覧が「適合度が高い順」に並び替わり、左端に「適合／条件近い／一部一致」ラベルと点数が付く。不適合（必須スキル不一致、単価が希望を5万以上下回る、大阪常駐、終了前開始など）は既定で非表示。件数バーに「不適合 91件を非表示」と出るので、隠されていること自体は分かる。
3. 必須スキル列では、山田が持っているスキルが青く塗られ、持っていないものは点線枠で薄く表示される。「Java・Spring Boot は合うが Oracle が足りない」がその場で読める。
4. 上位3〜4件の行をクリックして右のドロワーで詳細を見る。ドロワー冒頭に「山田太郎との適合」ブロックがあり、単価・開始日・リモートの照合結果が緑（一致）／橙（懸念）で列挙される。備考欄（原文メール抜粋）と自社提案状況を確認する。他営業が提案済みなら黄色の警告が最上部に出る。
5. 「エンジニアを提案する」を押すと、ドロワー内にエンジニア選択リストが開く。この案件に対する適合度順に並び、既定では稼働中・不適合は畳まれている。山田にチェックを入れ、必要なら面談予定日を入れて「提案する（1名）」。
6. 行の状態が「提案中」、自社提案状況に「山田太郎」、サイドバーの山田が「提案中 1件」、「自社提案中」タブの件数が +1 に変わる。トースト通知で完了を確認。矢印キー下で次の候補に移り、2件目・3件目も同じ手順で提案する。

A3 取引先の振り返り

1. 一覧またはドロワーの取引先名（青リンク）をクリック、あるいはフィルタの取引先セレクトで選ぶ。
2. 自動的に「すべて」タブに切り替わり（充足・クローズ・古い情報を含む）、上部に取引先サマリバーが出る: 直近30日の案件数（状態別内訳）、単価の中央値とレンジ、主な商流、自社提案数（全営業分も併記）、最終受信日時。
3. 一覧は受信順なので、時系列で「この会社は最近どんな役割を、いくらで、どの商流で出しているか」を追える。行の単価列を縦に眺めれば単価水準が分かり、充足した案件は薄く表示されて「決まった案件」として区別できる。
4. 「取引先指定を解除」で通常表示に戻る。

3. 何を最初に見せ、何を隠し、どの操作を最短にしたか

• 最初に見せる: 本日新着（既定ソートと NEW 強調）、要対応エンジニア（サイドバー最上段）、商流バッジ（濃い青ほど浅い商流＝高単価が残る）、他営業提案の有無（自社提案状況列の橙タグ）。この4つはA1・A2の判断に毎回使うため、スクロールもクリックもなしで見える位置に置いた。
• 隠す: 充足・クローズ・情報古い（既定タブから除外。A3のときだけ自動で含める）、不適合案件（エンジニアモード時）、歓迎スキル・精算幅の詳細・外国籍・商流制限・備考（ドロワーに送る。一覧の1行判定には使わないため）。隠したものは必ず「このタブ外 50件」「不適合 91件を非表示」と件数を出し、空振りのときは「充足・古い情報も含めて表示する」ボタンを空状態に置いた。
• 最短にした操作: 「エンジニアに合う案件を出す」を1クリック（サイドバー）にした。要件にある5軸（スキル×単価下限×開始時期×リモート×勤務地）＋経験年数を人間がフィルタに入力すると6操作以上かかるが、エンジニアの登録情報から機械的に導けるので、判定ロジックを裏で走らせて結果だけ見せる。提案操作もドロワー内で完結し、画面遷移なし・最小2クリック（提案ボタン→チェック→確定で3クリック）。
• 理由: A2は1回の判断ミスが月49万円の損失に直結する高頻度・高価値タスクなので、ここに操作数削減を集中させた。A3は頻度が低いため専用画面を作らず、フィルタ＋サマリバーで済ませた。

4. 操作負荷・認知負荷を減らした具体策と、効くステップ

操作負荷

• サイドバーのエンジニア1クリックでマッチング条件を一括適用（A2-1）。手動フィルタは「条件を緩めたいとき」の補助に降格。
• 行クリックで右ドロワー表示。一覧を離れないので「戻る」が不要（A2-4、A3-3）。矢印キー上下で前後の案件、Escで閉じる（A2-6で候補を連続比較）。
• ドロワー内エンジニア選択は「この案件への適合度順」に並び、稼働中・不適合は既定で畳む。提案対象になり得る5〜6名だけが見える（A2-5）。
• 取引先名はどこでもリンク。振り返りモードの入口を一覧・ドロワー・フィルタの3箇所に置いた（A3-1）。
• 「条件クリア」「エンジニア指定を解除」「取引先指定を解除」をそれぞれのコンテキストバー右端に固定し、モードから抜ける操作を迷わせない。

認知負荷

• 1行の情報を「判定に必要な最小セット」に絞り、案件名は2行まで、取引先・エンド・業種は小さく副題に。密度は高いが列の役割が一定なので視線が縦に走る（A1-3）。
• 商流は5段階を色の濃さで表現（エンド直＝濃青、三次以下＝白抜き）。「浅いほど良い」が色で読める（A1-3、A2-2）。
• 状態バッジは募集中（緑）／提案中（橙）／その他（灰）の3系統にまとめ、行全体を薄くすることで充足・古い案件を背景に沈める（A3-3）。
• 適合判定の根拠を「必須スキル 2/3（Oracleなし）」「単価上限65万（希望70万に対し-5）」のように、数字入りの短文で列挙。点数だけの判定にしないことで、営業が自分の判断で覆せる（A2-4）。
• スキルチップの塗り分け（一致＝青、不足＝点線）で、一覧から詳細を開かずに不足スキルが分かる（A2-3）。
• 異常への気づき: 他営業提案／社内競合は橙タグで一覧に出し、ドロワーでは最上部にアラート。情報古い案件には「N日更新なし」を受信列に赤字で出し、ドロワーでも「取引先に確認してから提案」と促す。商流制限「貴社社員のみ」はBP提案不可の警告として出す（A2-4）。
• 件数バーで「今見えている件数／本日新着／元請け直以上／他営業提案あり／隠している件数」を常時表示。フィルタで絞りすぎて見落としているのか、本当に案件がないのかを区別できる（A1・A2共通）。

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

• エンジニア選択時にフィルタ欄へ条件を自動入力する案: 一見透明性が高いが、リモート希望と案件のリモート区分は1対1で対応せず（「週1〜2出社まで」は2区分に対応）、単価は「上限≥希望」「-5万までは要相談」の2段階判定が必要で、セレクトボックスで表現しきれない。結果、フィルタ欄が中途半端な状態になり混乱すると判断。判定ロジックは裏で持ち、条件の表示はコンテキストバーに、根拠は行とドロワーに出す形にした。
• カード型（タイル）一覧: 案件名や備考が読みやすいが、1画面に入る件数が1/3になる。朝の新着チェックは20〜30件を数分で流し読みする作業なので、表形式で行高44pxに固定した。
• ステータスのチェックボックス群を常設する案: 5つのチェックボックスを毎回操作させるより、「募集中／本日新着／自社提案中／すべて」の4タブのほうが意図に対応している。「充足だけ見たい」のような要求は取引先振り返りの文脈でしか起きないため、タブ＋取引先モードで吸収した。
• 提案をモーダルダイアログで行う案: モーダルは背後の案件情報（備考・他営業の提案状況）が見えなくなる。提案対象を選ぶときに「面談1回、即決したい」などの備考を見直すことが多いので、ドロワー内にインラインで展開した。
• 新着を別画面（受信トレイ）に分ける案: 新着を見る目的は「担当エンジニアに合うか」の判断であり、判断には一覧と同じ列が必要。画面を分けると往復が増えるため、タブとソートで同じ表を使うことにした。
• 適合度をスコアだけで表示する案: 点数は並び替えに便利だが、営業は「なぜ83点か」を確認しないと顧客に提案できない。点数＋ラベル（適合／条件近い／一部一致）＋根拠短文の3層にした。

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

1. 利用者と目的

利用者は経営層3名（代表、営業本部長、管理本部長）。毎月第2営業日の経営会議で1920×1080の会議室モニタに映して1時間議論する。代表は前日に自分のPCで30分予習する。8月確定値をもとに9月2日に開く会議を想定した。

会議で最も時間を使うのは B1 と B4（今月悪化している指標に直結）。B2・B3・B7 は「同じ層（二次以下・50〜60万円帯・中堅）」に原因が集約されるため、画面上で相互参照させる。

2. 目的ごとの操作フロー

B0 予習・冒頭サマリ

1. 開くと「経営サマリ」が表示される。10枚のKPIカードのうち赤枠4枚（稼働率、待機、終了予定、粗利率の悪化）、橙枠4枚（依存度、商流比率、離職率）が目に入る。各カードには24ヶ月のスパークラインと前月・3ヶ月前との差分文があり、「悪化しているか」がカードだけで読める。
2. 左ナビの各議題にも赤／橙のフラグと数値（「稼働率 -3.8pt」「未着手 11名」）が付いており、今日の会議で時間を割くべき議題が分かる。
3. 下段の「売上・粗利の推移」「粗利率と稼働率」を見て、売上は伸びているのに8月の粗利率が落ちた原因が稼働率であることを確認する。
4. 赤枠カードをクリックすると該当議題へスクロールする。予習の代表はここから気になる議題だけを読む。

B1 採用方針

1. 議題見出しに「決めること: 来期の採用人数を継続／抑制／停止のどれにするか」と、選択肢ボタン3つ（計画どおり継続／若手採用を抑制し中堅にシフト／一時停止）が並ぶ。議論の着地点が最初に見える。
2. KPI行: 稼働率の3ヶ月推移（96.0→94.1→92.0）、待機15名のうち3年未満12名、直近6ヶ月の採用31名（前の12ヶ月の月2.3名→月5.2名）、新規契約−契約終了が-13件、内定7名。ここで「採用が待機を作っている」「案件が付いていない」の2つの仮説が立つ。
3. 左グラフ「在籍・稼働・待機の推移」で、直近3ヶ月の在籍増（179→183→186）がそのまま赤い待機に積まれていることを見る。右グラフで採用線が3月以降跳ね上がり、契約終了線も8月14件と上がっていることを見る。
4. 「待機15名の内訳」で年次（1年未満7・1〜3年5）、スキル、待機期間（2ヶ月以上2名、累計流出額）を見る。
5. 「採用シミュレーション」のスライダーで来期の追加採用人数を動かし、「稼働率95%を維持するために半年で必要な新規契約数」と「新規契約が直近ペースのままの場合の3月末想定待機」を見る。現行ペース30名だと待機が増えることが赤背景で示される。
6. 論点ボックスで「採用を止める前に、待機の原因が若手のスキル不足か営業の再配置遅れかを見極める（議題4へ）」という順序を確認し、選択肢ボタンで決定、テキストエリアに宿題・担当を書く。

B4 待機対策

1. KPI: 終了予定34名（10月末14・11月末20）、うち未着手11名、10月末終了で未着手6名は残り7週間、未着手者が1ヶ月待機した場合の原価概算。
2. 「営業別 担当状況」表で、未着手3名以上の鈴木・渡辺の行が赤くなっている。稼働率も86.4%・87.5%と低く、個人の抱え込みが疑われる。
3. 右の「契約終了予定者一覧」は未着手が先頭に来る。チップで「未着手のみ 11」「鈴木 5（未着手3）」などに絞り、会議中に営業本部長が担当者名を挙げながら確認する。
4. 論点ボックスで「今週が提案着手の期限」「案件不足ではなく着手遅れ」を確認し、決定（本部長が今週中に着手を指示／再アサイン会を設定）を選ぶ。

B2 単価交渉方針 / B3 商流改善 / B7 離職（同じ層への打ち手）

1. B2: 単価帯別表で50〜60万円帯（42名、粗利率12.1%）が赤ハイライト。原価48.5万円が60〜70万円帯とほぼ同じで、「年次が上がって給与だけ上がった層」と読む。右の顧客別粗利率で15%未満の4社（いずれも二次以下）が赤。「+3万円改定できた場合 月+126万円」のカードで打ち手の金額感を持つ。
2. B3: 商流別表で二次以下が橙、二次以下比率の推移が30%目安線を超えて上昇。取引先別表の「判断メモ」列で「更新時に商流・単価を同時交渉」「新規は受けない方針を検討」と打ち手の候補が行ごとに出る。B2の薄利4社と同じ会社が並ぶ。
3. B7: 年次×単価帯のヒートマップで「1〜3年×50〜60万円」8名が最も濃い。理由は待遇が8名。論点で「B2の層と同じ」「給与+2万円を42名に配っても年1,008万円で、離職半減で回収できる」と、B2の決定が離職にも効くことを確認する。

B5 顧客集中リスク / B6 BP活用

• B5: 横棒で上位1社が濃色、累積構成比を右に表示。KPIで「同社の終了予定6名が更新されなければ月商の何%が消えるか」を見る。論点で「同社は一次商流・粗利率19%で条件は悪くなく、断るのではなく元請け直の新規開拓で分散する」と方向を示す。
• B6: 自社稼働率とBP人数の2軸推移で「2025年前半にBPを40名まで増やし、その後の採用強化で自社が余った」流れを見る。右の横棒でBPと自社待機者のスキル重複（12名）を見る。KPIで「置換できれば月726万円改善」。

決定事項の記録

• 各議題の見出し右で選択肢を押し、メモを書く。最下部「本日の決定事項」に一覧化され、「議事メモをコピー」でテキスト化できる。決定はブラウザの localStorage に保存され、翌日代表が開いても残る。

3. 何を最初に見せ、何を隠し、どの操作を最短にしたか

• 最初に見せる: 各議題の「決めること」と選択肢（見出し行）。次にKPI4〜5枚（今月の異常値と、その金額換算）。グラフと表はその下。会議は「何を決めるか」から始まり、数字は判断材料として後から見るため、この順にした。
• 隠す: 24ヶ月分の月次生データ表は置かない。必要な数値はKPIカードとグラフのホバーツールチップで出す。契約終了予定者一覧はスクロール領域に収め、チップで絞ってから見る。顧客はその他17社をまとめて1行にし、上位10社だけ名前を出す。
• 最短にした操作: 議題間の移動はナビ1クリック、またはサマリのKPIカードクリック。決定の記録は見出し行のボタン1クリック。契約終了予定者の絞り込みはチップ1クリック。スクロール量は1議題が概ね1.5〜2画面に収まるように、KPI行＋グラフ2枚＋表1枚＋論点に統一した。
• 理由: 会議室のモニタ操作は1人が担当し、他2名は見るだけ。操作者が迷わずスクロールと1クリックで進められる構造にし、見る側は左ナビの赤フラグで「今どの議題か、次に何が来るか」を追える。

4. 操作負荷・認知負荷を減らした具体策と、効くステップ

操作負荷

• 単一ページ縦スクロール＋左ナビ。タブ切替やページ遷移をなくし、会議中の「戻って見せて」に1クリックで応えられる（全議題）。
• 決定・メモは各議題の見出し行に置き、別画面の議事録ツールを開かせない。決定事項一覧とコピーで議事録転記を省く。
• 契約終了予定者一覧のチップ絞り込み（B4-3）。営業名で1クリック。
• 採用シミュレーションはスライダー1本のみ。入力項目を増やさず、議論中に代表が「じゃあ20名だと」と即答できる（B1-5）。
• Fキーで本文フォントを一段大きくできる（モニタが遠い会議室向け。要件の「離れて見ても読める」に対する保険）。

認知負荷

• 「決めること」を議題見出しに明記し、数字の羅列にしない（要件の「議題ごとに何を判断するかが分かる構成」）。
• 赤＝判断が必要な悪化、橙＝要注意、緑＝良化の3色を、ナビのフラグ・KPI枠・表の行ハイライト・グラフのマーカーで統一。異常値は場所が変わっても同じ色で出る（B0〜B7）。
• KPIカードは「数値＋差分（3ヶ月で-3.8pt、前月-1.5pt）＋金額換算（待機コスト月738万円）」で構成。率だけでなく円に換算して、経営判断のスケールに合わせた（B1、B4、B6）。
• グラフは1枚1メッセージ。サブタイトルに読み取るべき結論を先に書く（「直近3ヶ月は在籍が増えた分がそのまま待機になっている」）。直近3ヶ月の点は赤マーカーで強調（B0、B1、B6）。
• 表は「人数の横棒」を数値の隣に置き、構成比を数字を読まずに比較できるようにした（B2、B3）。
• 議題間の因果を論点ボックスで明示。「B2の薄利層＝B7の離職層」「B3の商流とB4の待機はトレードオフ」「B1の採用停止判断はB4の結果待ち」など、別々の表を頭の中で突き合わせる負担を減らす。
• ヒートマップ（年次×単価帯）で離職者20名の分布を1枚で見せ、行列の合計も添えて「どこに集中しているか」を色で読む（B7）。
• 会議室モニタ向けに、本文15px、KPI数値32px、表15pxとし、通常の業務画面より1〜2段大きく設定。淡色（--faint）はグラフ軸ラベルに限定して、本文は濃色で統一。

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

• 議題ごとのタブ切替: 会議で「さっきの待機の表と並べて見たい」という要求が頻発するため、タブは往復操作が増える。単一ページ縦スクロールで、ナビは現在位置の強調に留めた。
• 月次データの全件テーブル: 24ヶ月×18指標の表は「数字を羅列するだけ」の典型で要件に反する。必要な値はKPIカードとホバーで出し、表はグラフの補助にしなかった。
• 円グラフ（商流構成、退職理由）: 5区分の比率比較は横棒の方が正確に読め、ラベルの配置問題もない。すべて横棒か表＋バーにした。
• KPIカードの自動スクロール／プレゼンモード: 会議は議論の流れで前後するので、自動進行は邪魔になる。代わりにナビとカードクリックで任意の議題に飛べるようにした。
• 採用シミュレーションの多変数モデル（採用単価、立上げ期間、離職率の入力）: 会議中に入力させると議論が止まる。1変数（追加採用人数）だけを動かし、他は直近6ヶ月実績を固定値として説明文に書いた。精密な試算は別途管理本部が持ち込む前提。
• 決定事項をサーバに保存する設計: 単一自己完結HTMLの制約と、会議室PCで使う実態から localStorage を選んだ。保存先がブラウザであることはナビ下部に明記した。
• 顧客名を全社表示: 上位10社以外は1社あたりの売上が小さく、行が増えるだけで判断に効かないため「その他17社」に集約した。

根拠記述後の修正

根拠を書く過程で見つけた不整合と、HTMLへ加えた修正。

1. management.html: 佐藤担当の契約終了予定者の提案状況を projects.html と整合させた 会議日（9/2）時点で「山田太郎 提案中2件」としていたが、projects.html（9/10時点）では山田はまだ提案なしの「終了予定」であり、時系列が逆転していた。会議で山田・佐々木を「未着手」として指摘され、9/10に佐藤が案件一覧のエンジニアモードで山田の提案先を探す、という流れになるよう、management.html の固定データを次のとおり変更した。

   • 山田太郎: 提案中2件 → 未着手
   • 小林美咲: 提案中1件（面談09/12）のまま
   • 佐々木健: 未着手のまま
   • 加藤さくら: 未着手 → 提案中1件（佐藤の「提案中4・未着手2」の集計値は維持） なお projects.html 側で加藤が「終了予定」（提案なし）なのは、9/2〜9/10の間に提案先が充足で流れた、という解釈で矛盾しない範囲とした。

2. projects.html: 空状態の導線を確認し、そのまま採用 根拠3で「隠したものは件数と復帰導線を出す」と書いた点を再確認し、エンジニアモードで0件のときに「不適合の案件も表示する」「充足・古い情報も含めて表示する」の2ボタンが出ることをコードで確認した（変更なし）。

（ブラウザ確認の段階で行った修正 — 根拠記述前 — は次のとおり。参考として記す: 案件名の2行折り返し、件数バーの折り返し防止、サイドバー行の折り返し、単価下限を45万円で下限クランプ、受信2日以内の案件が充足・クローズにならないよう補正、適合判定で「適合」を懸念ゼロのときに限定、経営画面のチャート幅・最終値ラベル位置・ナビラベル幅の調整、離職率グラフを12ヶ月分のデータが揃う月からの表示に変更。）