「システムを導入したのに仕事が楽にならない」「現場と開発チームで必要な機能の認識が違う」。こうした問題の背景には、解決したい業務課題とシステムに求める要件が十分につながっていないことがあります。そこで、現場の実態を調べ、関係者の要望を整理し、実行できる要求にまとめるビジネスアナリストが重要になります。
この記事では、IPAが2026年4月に公開したデジタルスキル標準（DSS）Ver.2.0に沿って、仕事内容、1日の流れ、関連職種との違い、必要スキル、学習方法を説明します。さらに架空の受発注業務を題材に、読者自身が要求整理表を作れるよう具体例を示します。
結論：ビジネスアナリストは「要望」を「実行できる要求」に変える人
ビジネスアナリストは、組織の課題を整理し、業務・組織・システムの関係を分析して、関係者が合意できる要求や改善案にまとめる役割です。IPAのDSS Ver.2.0では、ビジネスアーキテクト類型に含まれる一つのロールとして位置づけられています。業務・組織・システムの分析、要求の整理と実装担当者への伝達、関係者間の調整を担います（出典1）。
「入力画面を増やしてほしい」という要望があっても、実際の困りごとは二重入力によるミスかもしれません。入力画面を増やすより、入力元の統一や業務ルールの変更が適切な可能性もあります。最初からシステム開発を正解と決めず、問題を確かめて複数の改善策を比較するのが重要です。IPAも、システム構築の前段階でビジネス上の問題や機会を分析することを説明しています（出典2）。
主な仕事内容：現場調査から導入後の評価まで
1．課題と目的を定義する
「問い合わせ対応が遅い」を「AIチャットを入れる」と即断せず、何が遅いのか、誰が困るのか、改善を何で測るのかを確かめます。「初回返信までの時間を短くする」「誤案内を減らす」など、検証できる目標へ落とし込みます。
2．現状の業務を観察し、可視化する
担当者への聞き取り、作業手順、使用画面、帳票、差戻し履歴などから現状フローを作ります。「誰が／何を受け取り／何を判断し／何を渡すか」を明確にし、通常処理だけでなく例外処理も確認します。
3．要求を集めて整理する
要望を「必須」「優先度は低い」「運用で代替できる」などに分類し、法令・契約・情報管理上の制約も確認します。立場の異なる関係者の意見が衝突したときは、根拠と影響を示して合意を支援します。未決事項は未決のまま記録します。
4．解決策を比較する
業務手順の変更、既存システムの設定変更、外部サービス導入、新規開発などを、改善効果、費用、導入期間、運用負荷、リスクで比較します。判断できない項目は推測で埋めず、調査担当と期限を決めます。
5．開発担当者と認識を合わせる
「検索しやすく」という抽象的な要望を、対象者、対象データ、検索条件、権限、例外、受入条件に分解します。技術的に難しい場合は、目的を維持した代替案を協議します。すべてのコードを自分で書く必要はありませんが、システムとデータの基礎理解は役立ちます。
6．変更管理と導入後の検証を支援する
導入後、現場が実際に使えるか、改善前と比べて効果があるかを確かめます。要求の変更理由、影響、承認結果を記録します。DSS Ver.2.0でも要求分析・変更管理、仮説検証、関係者調整などの実践力が示されています（出典1）。
実務例：受発注の二重入力を減らす
以下は説明のための架空事例で、実在企業の改善実績ではありません。
ある卸売会社では、営業担当がメールで注文を受け、受注管理表に入力し、経理担当が同じ情報を会計ソフトに再入力しています。現場からは「新しい受注システムが欲しい」と要望が出ました。しかし、最初から新規システムを選ぶのではなく、現状の作業を整理します。
【架空の前提】1日40件の注文があり、注文1件当たりの重複入力に平均3分かかると仮定すると、40件×3分＝120分／日の作業です。これは説明用の仮定であり、実測値ではありません。入力時間が減っても照合や例外処理が増えれば、総工数は減らない可能性があります。
STEP 1：営業・経理・管理者に、注文情報をどこへ何回入力するかを聞きます。作業の開始点・終了点を揃え、通常例と例外例を観察します。
STEP 2：「新システムが欲しい」を「二重入力と転記ミスを減らしたい」に言い換えます。成果指標の候補は総処理時間、修正件数、締め作業の遅延です。
STEP 3：現状フローを「注文受信→内容確認→受注登録→請求データ作成→照合」と図にします。どこで入力が重複するかを示します。
STEP 4：改善案A＝入力ルール統一、B＝既存ソフト間のデータ連携、C＝新規システム導入を比較します。連携可否や契約条件が不明なら「要調査」とします。
STEP 5：B案を検討する場合、「承認済み注文データを所定形式で取り込む」といった要求を具体化します。
STEP 6：通常注文だけでなく、取消し、数量変更、重複注文、取引先コード不一致も受入テストの対象にします。
STEP 7：導入後に、入力だけでなく確認・修正を含む総工数を測り、想定外の作業が増えていないか確認します。
この案件で残す主な成果物は、現状業務フロー、課題一覧、関係者一覧、要求一覧、改善案比較表、受入条件、変更履歴です。文書の枚数より、判断理由と責任の所在が追えることを重視します。
コピーして使える「要求整理表」
表計算で次の列を用意します。
要求ID｜困っている人｜現状の問題｜解決したい目的｜要求内容｜優先度｜根拠｜受入条件｜例外｜担当者｜承認状況｜変更履歴
【記入例】
要求ID：R-01
困っている人：経理担当
現状の問題：受注表から会計ソフトへ同じ注文を手入力している
目的：転記作業と転記ミスを減らす
要求内容：承認済みの注文情報を指定形式で取り込める
優先度：高（仮）
根拠：業務観察と経理担当への聞き取り
受入条件：通常注文・取消し・数量変更が想定どおり処理されること
例外：取引先コードが一致しない場合は担当者に確認を求める
担当者：業務責任者・開発担当
承認状況：未承認
変更履歴：初版
「誰でも簡単に使える」は、誰が何をできれば合格かが不明確です。「経理担当者が注文について指定条件で検索し、結果を確認できる」なら対象者と動作が分かります。性能条件などの数値は、業務の重要性と測定方法を確認してから設定します。機能以外にもアクセス権、監査、復旧、運用責任などが関わるため、専門担当と連携してください。
1日の流れ：仮想スケジュール
次は社内業務改善プロジェクトの一例です。企業・担当案件・開発段階によって変わります。
9:00 変更依頼と未決事項を確認し、優先順位を整理する。
10:00 現場担当へヒアリングし、例外処理や困りごとを確認する。
11:00 現状業務フローを更新し、問題点と根拠をまとめる。
13:00 開発担当と要求・制約を確認し、曖昧な表現を修正する。
14:30 営業・経理・管理者の意見が異なる論点を調整する。
16:00 受入条件、変更履歴、未決事項、次回確認事項を記録する。
17:00 責任者へ決定事項とリスクを共有する。
ヒアリング中心の日も、テストや改善効果の確認が中心の日もあります。「会議が多い仕事」というより、会議や分析から検証可能な成果物を生み出す仕事と捉えると分かりやすいでしょう。
ビジネスアーキテクト・プロダクトマネージャー・SEとの違い
IPAのDSS Ver.2.0では、ビジネスアーキテクト類型にビジネスアーキテクト、ビジネスアナリスト、プロダクトマネージャーの3ロールが置かれています。違いは職位の上下ではなく、主に責任の中心です（出典1）。
ビジネスアーキテクト：組織や事業を俯瞰し、経営戦略を事業構造や変革ロードマップに落とし込む。複数施策の優先順位や経営判断の支援に関わる。
ビジネスアナリスト：具体的なプロダクト・プログラムの業務・組織・システムを分析し、要求整理と利害調整を行う。現場と実装担当の認識をつなぐ。
プロダクトマネージャー：特定の製品・サービスの企画、開発、継続改善と成果に責任を持つ。
SE・エンジニア：技術要件を満たす設計・実装・テスト・運用に責任を持つことが多いが、要求分析も兼ねる企業がある。
業務コンサルタント：課題診断や改善提案を担うことが多いが、名称だけではビジネスアナリストとの違いを決められない。
企業規模によっては一人が複数ロールを兼ねます。求人の職名だけで判断せず、成果物、意思決定権限、関係部署、担当範囲を確認しましょう。
必要なスキルは？学ぶ順番を間違えないために
第一に、課題発見と論点整理。現場の発言をそのまま受け取るだけでなく、「事実」「解釈」「要望」を分け、誰が何に困っているかを確認します。問題を分解して仮説を立てる力が基礎になります。
第二に、ヒアリングと合意形成。立場によって成功の意味は異なります。現場は手間の削減、管理者は統制、開発担当は実現可能性を重視するかもしれません。会議の前に目的と確認事項を共有し、会議後に決定事項・未決事項・担当・期限を残す習慣が役立ちます。
第三に、業務・データの可視化。業務フロー、データ項目、入出力、例外処理を説明できること。初学者は複雑な専用ツールより、表計算とシンプルなフローチャートで十分練習できます。SQLやAPIの基礎知識はデータ連携の可能性を理解する助けになりますが、必要水準は職務によって異なります。
第四に、要求分析と変更管理。目的に沿って要求を優先順位付けし、受入条件を決め、変更の影響を記録します。何を今回は扱わないかを合意することも重要です。
第五に、効果測定とリスク理解。処理時間だけでなく品質、例外対応、費用、利用定着などを確認します。技術を使う場合はデータ利用権限や契約上の制約にも注意します。
IPAのDSS Ver.2.0では要求分析・変更管理や関係者調整、問題解決、ビジネスモデリングなどに関わるスキルが示されています（出典1）。IIBAのビジネス分析標準でも情報収集と協働、要求管理、現状・将来分析、解決策の評価などを整理しています（出典3）。資格の有無だけでなく、具体的な成果物を作る練習が重要です。
未経験から目指す90日間の学習・実践プラン
90日は説明用の目安であり、到達や転職を保証する期間ではありません。実際の業務で許可されていない資料を使わず、架空事例や公開情報を使います。
1〜2週目：IPAのDSS Ver.2.0を読み、3ロールの違いを説明します。日常の作業を一つ選び、開始条件、入力、担当、判断、出力を書き出します。
3〜4週目：架空の受発注や予約受付の業務フローを作り、待ち時間、転記、差戻し、情報不足の発生箇所を示します。課題の根拠が仮定なのか観察なのかを区別します。
5〜6週目：関係者の要望を3種類以上想定し、矛盾や優先順位を整理します。要求ID、目的、受入条件、例外、承認者を含む表を作ります。
7〜8週目：業務ルールの改善、既存ツールの設定変更、新規導入の3案を、効果、費用、負荷、リスクで比較します。分からないことは「要確認」とします。
9〜10週目：正常例・例外例を含む受入テストの観点を作成し、どの要求にどのテストが対応するかを記録します。
11〜12週目：課題の背景、現状フロー、要求一覧、比較表、受入条件、変更履歴、未確認事項を一つのポートフォリオにまとめます。架空事例を実務実績として偽らないでください。
13週目：求人や社内異動の職務要件と照合します。既にできること、証拠となる成果物、次に補うスキルを3項目ずつ書き、学習計画を更新します。
営業経験者なら顧客要望の整理、経理経験者なら照合・例外処理、接客経験者なら業務フローと顧客接点、Webマーケ経験者ならデータと施策評価を題材にできます。既存の業務理解を分析の強みに変える考え方です。
向いている人と仕事の難しさ
異なる意見を整理するのが好きな人、曖昧な問題を言語化したい人、現場の話を聞いて仕組みを改善することに関心がある人に向く可能性があります。技術への興味は役立ちますが、業務と人を理解する姿勢も重要です。
難しさは、正解が一つではないこと、利害が衝突すること、決定権が自分にないこと、導入後に想定外の運用が生じることです。分析が得意でも決定を先延ばしにすると案件は進みません。逆に結論を急ぐと重要な制約を見落とします。確認範囲と意思決定期限を明確にしましょう。
生成AIはビジネスアナリストの仕事をどう変える？
AIはヒアリングメモの要点整理、要求文の曖昧表現の洗い出し、想定例外の案出し、テスト観点の下書きなどを支援できます。ただし、AIは現場で起きた事実を自動的に知っているわけではありません。生成された要求に実際の根拠があるか、関係者が合意したか、会社の規程に反していないかは人が確認します。
安全な練習例として、架空の業務フローをAIに渡し「曖昧な要求を5件挙げ、確認質問を提案して」と依頼できます。その後、出力された質問が目的に合うかを見直します。業務資料を入力する場合は組織の承認済み環境と規程を確認してください。AIが文章の下書きを速く作れるほど、要求の優先順位、関係者の合意、結果の検証が重要になると考えられますが、職種の将来を断定するものではありません。
求人票・面接で確認したい8項目
1．職名ではなく、要求分析・業務設計・システム導入のどこが主担当か。
2．現場へのヒアリングや業務観察を自分で行えるか。
3．成果物は業務フロー、要求一覧、仕様書、ロードマップのどれか。
4．要件の優先順位を決める権限は誰にあるか。
5．開発担当、事業責任者、情報管理担当との役割分担はどうなっているか。
6．導入後の効果測定や運用改善まで関わるか。
7．未経験者への研修・レビュー体制、必要な業務知識は何か。
8．評価基準は納品資料の量か、課題解決や業務成果か。
面接では「最近の改善案件で、現場の要望が途中で変わったとき、誰がどう判断しましたか」「この職種が残す成果物の具体例を教えてください」などと尋ねると、実際の仕事を理解しやすくなります。給与や求人数は地域、経験、雇用形態、職務範囲による差が大きいため、募集時点の求人情報を個別に比較してください。
よくある失敗と防ぎ方
要望をそのまま機能にする→背景にある困りごとと成果指標を確認する。
通常の流れだけを書き例外を落とす→取消し、差戻し、入力ミスなども質問する。
会議で合意したつもりになる→決定事項、未決事項、担当、期限、承認者を確認する。
変更の影響を記録しない→変更理由、費用・期間への影響、承認結果を履歴に残す。
AIの提案を事実と誤認する→現場資料と関係者確認で根拠を照合する。
今日から30分でできること
最初の10分：自分が知っている業務を一つ選び、開始点と終了点、担当者、成果物を書き出します。
次の10分：困りごとを「事実」「推測」「要望」に分け、確かめる質問を3つ作ります。
最後の10分：要求整理表に一件だけ記入し、誰が承認し、何を確認すれば完了かを書きます。
ここまでできれば職種理解から一歩進み、仕事の入口を体験できます。次は架空の例外処理を加えて要求を見直し、変更履歴を残しましょう。
まとめ
ビジネスアナリストは、現場の課題を業務・組織・システムの観点から整理し、実装担当と関係者をつなぐ仕事です。2026年のDSS Ver.2.0では、ビジネスアーキテクト類型の一つのロールとして明示されました。職名や必要技術は企業によって違うため、仕事内容、成果物、権限を確認することが重要です。興味がある人は、身近な業務の現状フローと要求整理表を一つ作り、求人の要件と照らし合わせてみましょう。
参考資料（2026年10月22日確認）
出典1｜IPA「デジタルスキル標準 Ver.2.0」（2026年4月16日公表。資料ページ2026年7月9日更新）。第III部のロール定義・業務・スキルに対応。
https://www.ipa.go.jp/jinzai/skill-standard/dss/download.html
https://www.ipa.go.jp/jinzai/skill-standard/dss/rcu1hd000000j76k-att/dss_ver2.0.pdf
出典2｜IPA「システム構築はビジネス分析から始まる」（2026年3月23日公開、2026年9月11日更新）。システム導入前の分析に対応。
https://www.ipa.go.jp/digital/kaihatsu/slcp/business-analysis.html
出典3｜IIBA「The Business Analysis Standard」。情報収集・協働、要求管理、分析、解決策評価の実務領域に対応。
https://www.iiba.org/knowledgehub/the-business-analysis-standard/
出典4｜IPA「デジタルスキル標準ver.2.0を公開」（2026年4月16日）。改訂の背景と3ロール再定義に対応。
https://www.ipa.go.jp/pressrelease/2026/press20260416.html
