DX改善シナリオ演習 / 約20分
業務ヒアリングと要件整理
なぜこれを学ぶか
エンジニアに転職後、最初に求められるのは「コードが書けること」ではなく「課題を正しく理解できること」かもしれません。このレッスンでは、「毎日同じ問い合わせが来る」という現場の声から、解決すべき課題を整理し、解決策を提案するまでのヒアリングの型を学びます。
「現象」と「課題」は違う: 「毎日同じ問い合わせが来る」は現象です。本当の課題は「情報を探す手段がない」なのか、「情報はあるが見つけにくい」なのか、「情報はあるが更新されていない」なのかで対策が変わります。ヒアリングで「現象の裏にある原因」を掘り下げるのが要件整理の第一歩。
ヒアリング5W1H: ①What — 何が問題か（問い合わせ内容の具体例）②Who — 誰が困っているか（問い合わせ側・対応側）③When — いつ起きるか（頻度・時間帯）④Where — どこで起きるか（部署・チャネル）⑤Why — なぜ今の手段では解決しないか ⑥How much — 何件/日でどれほど工数を取られているか。数値化できると「解決する価値」の説明がしやすくなります。
要件整理の「AS-IS / TO-BE」フレーム: AS-IS（現状）「毎日30件の問い合わせが来て、担当者が1件5分かけて個別回答している」→ TO-BE（目標）「80%の質問をFAQページで自己解決でき、担当者の工数を1日2.5時間削減する」。これを文書化したものが「要件定義書」のコアになります。
解決策を提案する前に確認すること: ❶現状のリソース（何人でやっているか）❷技術的制約（どんなシステムを使っているか）❸承認フロー（誰がOKを出す必要があるか）❹「完了」の定義（何ができれば成功とみなすか）。これを確認せずにいきなり「こうしましょう」と提案すると、実現不可能な提案になりがちです。
重要ポイント
- 「現象」ではなく「課題の本質」を掘り下げるのがヒアリングの目的
- AS-IS（現状）とTO-BE（目標）を数値込みで整理する
- 解決策の前に制約（人・技術・承認）を確認する
- 「何ができれば完了か」を先に決めておく
理解度チェック
選ぶと即座に解説が表示されます。
上司から「問い合わせが多いから何か対策して」と言われました。最初にすべき行動は？
ヒントを見る
「問い合わせが多い」はまだ「現象」の段階です。何種類の問い合わせが来ていて、それぞれ何件あるか分かりますか？
コードレビュー演習
あなたは社内ヘルプデスク担当。1か月分の問い合わせログを集計したところ、以下の内訳でした。 この数値を見て、「要件整理」に使えるAS-IS/TO-BE文書を選んでください。
/* === 1か月の問い合わせ集計（150件）=== */
// 種類別内訳
const inquiries = [
{ category: 'VPNの接続方法', count: 42, avgMinutes: 4 },
{ category: 'パスワードリセット', count: 38, avgMinutes: 3 },
{ category: 'Slack通知の設定変更', count: 27, avgMinutes: 5 },
{ category: '勤怠システムの使い方', count: 25, avgMinutes: 6 },
{ category: 'その他/個別対応', count: 18, avgMinutes: 8 },
]
// 計算例
// 上位3カテゴリの合計: 42+38+27 = 107件（全体の71%）
// 上位3カテゴリの月間対応工数: 42×4 + 38×3 + 27×5 = 168+114+135 = 417分（約7時間）このデータから作るべき最も適切なAS-IS/TO-BEはどれ？
ヒントを見る
AS-ISは「現状の数値」、TO-BEは「解決後の目標数値」を含めると説得力が増します。
スキルセルフチェック
このレッスンの内容をどの程度理解できましたか？