これは何か
現状課題一覧は、新しいシステムを作る前に、「今の業務と今のシステムで何が困っているか」を一つずつ書き出し、困りごとの大きさと根拠をそろえた成果物です。
「システムが古い」「使いにくい」という言葉は、刷新の理由にはなりません（01-01 「システムが古い」だけでは刷新理由にならない）。何が、どの業務で、どれだけの手間や損失や危険を生んでいるかを、誰が見ても同じに読める形にして初めて、投資の判断の材料になります。この一覧は、BUS-002 システム投資企画書 の「なぜ今やるのか」を支える土台です。
なぜ作るか
- 「困っている」という印象を、業務ごとの事実（頻度・時間・金額・件数）に変える
- 課題の大きさを比べられるようにし、何を先に解くかを決められるようにする
- 刷新で解く課題と、刷新では解けない課題（業務のやり方・組織の問題）を分ける
- あとで「刷新して何が良くなったか」を測るときの出発点（BUS-004 効果測定指標一覧）を残す
誰が使うか・いつ作るか
- 作る人：業務部門のリーダーと IT 部門。外部のコンサルタントが聞き取りを手伝うこともある
- 使う人：投資を判断する経営層、企画書を書く人、要件を決める人、効果を測る人
- 一般的には、構想の初期（プロジェクトが正式に始まる前）に作り、要件定義の入口で読み直します
- アステリア案件の現状課題の中身（何が、どれだけ困っていたか）は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
現状に関係する記載
- アステリア株式会社（架空企業）。業種は IT コンサルティング・システム開発。売上高 約5,000億円、従業員 約4,000名
- 大規模基幹システム刷新。約120人規模のプロジェクト、約1,500件の要件、約36本のシステム連携、10年分のデータ移行、マルチベンダー、AI活用あり
- M-6 構想開始、M0 正式キックオフ
- P-001 佐伯 隆志 — CFO／プロジェクトスポンサー、P-002 高瀬 真理 — CIO／IT統括責任者
構想開始（M-6）の時点で、どんな課題が、どの業務で、どれだけの大きさで挙がっていたかは、正本に記載がありません。未確定 上の人物が課題の洗い出しを指示した、承認したという記載もありません。未確定
主な項目
一般的には、課題 1 件ごとに次の項目を持ちます。
- 課題の番号と名前：あとから要件や効果指標とつなげるための番号
- 業務と担当部門：どの業務の、どの場面で起きるか
- 現象：何が起きているか（事実だけ。原因や解決策は書かない）
- 大きさ：頻度（月に何回）、かかる時間（1 回あたり何分、月に何時間）、金額（損失・余計な費用）、危険（誤り・漏えい・法令）
- 根拠：大きさをどう測ったか（記録・集計・聞き取り）。推定なら推定と書く
- 原因の候補：システム・業務のやり方・組織のどれに由来しそうか（断定しない）
- 刷新との関係：刷新で解く／業務のやり方で解く／今回は解かない
- 確認した日と確認した人
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 課題の書き方の違い
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、同じ困りごとを「印象」で書いた場合と「事実」で書いた場合の違いを学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 書き方 | 例（教材上の例） | 判断の材料になるか |
|---|---|---|
| 印象 | 請求の処理が面倒で、月末に残業が多い | ならない。大きさも原因も分からない |
| 事実 | 請求データを表計算で手作業で突き合わせており、月に 3 回、1 回あたり 2 人で 6 時間かかる。直近 12 か月で転記の誤りが 9 件あり、うち 2 件は顧客への再請求になった | なる。頻度・時間・件数・影響が分かる |
| 番号 | 業務 | 現象 | 大きさ（根拠） | 原因の候補 | 刷新との関係 |
|---|---|---|---|---|---|
| 課題-01 | 請求 | 営業の契約情報と請求の情報を手作業で突き合わせている | 月 36 時間（担当者の作業記録、3 か月平均） | システム間でデータがつながっていない | 刷新で解く |
| 課題-02 | 原価 | 工数の集計が月の中旬までできず、案件の赤字に気づくのが遅れる | 判明が平均 25 日遅れる（直近 6 か月の案件 14 件） | 工数の入力が月 1 回／集計が手作業 | 刷新と業務のやり方の両方 |
| 課題-03 | 経営分析 | 部門ごとに売上の定義が違い、会議で数字が合わない | 会議の前の数字合わせに月 8 時間（聞き取りによる推定） | 定義が決まっていない | 業務のやり方で解く（刷新だけでは解けない） |
| 課題-04 | 権限 | 退職者のアカウントが残っていた | 直近 1 年で 4 件（棚卸しの記録） | 削除の手順が決まっていない | 刷新で解く（仕組み）＋業務のやり方（手順） |
読み方
- 現象が「事実」で書かれているか。「面倒」「遅い」「使いにくい」で終わっていないか
- 大きさに根拠があるか。推定なら推定と書いてあるか
- 原因の候補と現象が分けて書かれているか（原因を決めつけていないか）
- 刷新で解く課題と、業務のやり方で解く課題が分かれているか。すべてをシステムのせいにしていないか
- 一覧の課題が、あとの企画書・要件・効果指標とつながる番号を持っているか
書き方
- 業務ごとに、困っている場面を現場の人から聞き取る。印象の言葉はそのまま記録し、あとで事実に置き換える
- 大きさを測る。作業の記録、件数の集計、サンプリングなど、測り方も書く
- 原因の候補を、システム・業務のやり方・組織に分けて書く。断定しない
- 刷新との関係を仮置きし、企画の段階で経営層と確かめる
- 日付と確認者を残し、要件定義の入口で読み直す
何を書いてはいけないか
- 原因の断定（「古いシステムのせい」）。現象と原因の候補を分ける
- 解決策（「新システムで自動化する」）。それは要件や設計で決める
- 根拠のない大きさ（「かなり」「とても」）。測れないなら「未計測」と書く
- 特定の個人への評価や責任の記述
どこを見るか
- 現象が事実で書かれているか
- 大きさの根拠（記録か、推定か）
- 原因の候補と現象の区別
- 刷新で解く課題と、業務のやり方で解く課題の区別
- 企画書・要件・効果指標とつながる番号
赤信号
- 課題のほとんどが「使いにくい」「古い」のような印象で、大きさが書かれていない
- 原因がすべて「システムが古いから」になっている（業務のやり方や組織の問題が見えなくなる）
- 課題の数は多いが、どれが大きいかが比べられない
- 一覧が構想の初期に作られたまま、要件定義で一度も参照されていない
よくある失敗
- 課題を集めることが目的になり、大きさを測らないまま一覧が長くなる。優先順位が付けられず、要件が膨らむ
- 現場の「こうしてほしい」（解決策）をそのまま課題として書く。本当の困りごとが見えなくなる
- 刷新では解けない課題（定義の不一致、手順の不在）を刷新の効果に含めてしまい、稼働後に「良くならなかった」となる
関係するUnit・成果物・危機演習
- Unit：01-01 「システムが古い」だけでは刷新理由にならない、01-02 システム投資で何を実現するのか、00-02 アステリア刷新プロジェクトを知る
- 成果物：BUS-002 システム投資企画書、BUS-003 プロジェクト対象範囲定義書、BUS-004 効果測定指標一覧
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、聞き取りの記録から「印象の言葉」と「事実の言葉」を分け、大きさの根拠が書かれていない課題を見つける下書きに役立ちます。
「次の聞き取り記録を読み、課題ごとに、現象・大きさ・根拠・原因の候補に分けて表にしてください。大きさや根拠が書かれていない課題は、空欄のまま『未計測』と示してください。原因を推測して埋めたり、解決策を提案したりしないでください。」
REVIEW
- AIが空欄を「それらしい数値」で埋めていないか（未計測は未計測のまま）
- 現場の言葉の意味を変えていないか（元の記録と突き合わせる）
- 聞き取り記録を AI に渡してよいか（個人名・顧客名の扱い）を事前に確かめたか
人間が判断すること
- どの課題を刷新で解き、どの課題を業務のやり方で解くか
- 大きさをどこまで測ってから企画に進むか
- 課題の優先順位と、今回は解かない課題
投資承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 01｜なぜ数十億円を使うのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この一覧を読んだ経営層は、「今のシステムと業務で、何が、誰に、どれだけの損失や手間を生んでいるか」を、数値と根拠つきで説明できますか？