この記事は、PD-S（システム）試験（仮称）科目B 第1章「システムアーキテクチャに関すること」の最初の節、小項目1-1「デジタル戦略，業務モデリング及びニーズ分析を踏まえた業務要件の定義，システム化計画の立案」の教科書です。シラバス案がこの小項目に挙げる7つの技能を1つも飛ばさずに取り上げ、それぞれについて「何が求められているのか」「支える基礎知識」「実務でのイメージ」を、前提知識ゼロから解説します。読み終えると、経営の意図（デジタル戦略）が、どういう手順で「作るべきシステムの姿」まで具体化されるのかという上流工程の全体像が説明できるようになります。
この節の全体像 — 7つの技能は「3ステップ」に整理できる
シラバス案は小項目1-1に対して「目標とする技能の例」を7つ列挙しています。一見バラバラに見えますが、実務の時間軸に沿って並べると「①課題をつかむ → ②業務を設計する → ③システム化を計画する」の3ステップにきれいに整理できます。
図1：小項目1-1の全体像 — デジタル戦略から システム化計画まで の3ステップ
前提知識：「業務要件」と「システム要件」— 要件の階層を最初におさえる
本文に入る前に、この節の理解を左右するいちばん重要な前提知識を固めます。それは「要件」という言葉の階層構造です。シラバス案の小項目も 1-1「業務要件の定義」→ 1-2「機能要件の定義」→ 1-3「非機能要件の定義」という順に並んでおり、この階層をそのままなぞっています。
図2：要件の階層 — 業務要件を頂点にシステム要件（機能・非機能）へ展開する
ステップ①：課題をつかむ（技能1・技能2）
技能1：デジタル戦略を踏まえて「業務課題」を定義する
組織のデジタル戦略を踏まえて，対象業務に関する業務上のニーズや問題点を把握し，システムを用いて実現すべき業務課題を定義するスキル
出発点は「システムを作りたい」ではなく組織のデジタル戦略です。デジタル戦略とは、組織が経営目標を達成するためにデジタル技術をどう使うかの基本方針のこと（例：「全店舗の在庫情報を一元化し、EC と実店舗の垣根をなくす」）。個々のシステム開発は、この戦略を実現する手段の1つとして位置づけられます。
そのうえで、対象業務のニーズ（こうしたい・こうなってほしいという要望）と問題点（現にうまくいっていないこと）を集め、「システムを使って解くべき業務課題」の形に定義し直します。ここで重要なのは、現場の声をそのまま要件にしないことです。
技能2：現行の業務システムを分析する（As-Is分析）
対象業務システムを分析し，機能，他システムとの関係，リスクなどを把握するスキル
課題を定義したら（あるいは定義するために）、現状（As-Is）を正確に把握します。分析の観点はシラバス案に3つ明示されています。
- 機能：現行システムが何をしているか。長年の運用で「実は使われていない機能」「手作業で補われている機能」が必ずあります。
- 他システムとの関係：受注システムは在庫・会計・物流と繋がっているのが普通です。このインタフェース（連携点）を見落とすと、改修時に連携先を壊します。
- リスク：老朽化（サポート切れのOS・ミドルウェア）、属人化（仕様を知る人が1人しかいない）、性能限界、セキュリティ上の弱点など。
ステップ②：業務を設計する（技能3・技能4）
技能3：業務と組織をモデル化し、業務機能を取りまとめる
対象業務を，システムを用いて実現すべき課題，ステークホルダの要件及び制約条件に基づいて整理し，業務と組織をモデル化して整合性のとれた業務機能を取りまとめるスキル
この技能には前提となる用語が3つ詰まっています。順に定義します。
なぜモデル化が必要なのか。文章の議事録だけで業務を定義すると、部門ごとの認識ズレ（同じ「出荷」という言葉が指す範囲の違いなど）に気づけないからです。図の形式に落とすと抜け・重複・矛盾が目に見えるようになります。「整合性のとれた業務機能を取りまとめる」とは、部門Aの要望と部門Bの要望が矛盾したまま並記されている状態を解消し、業務全体として筋の通った機能のセットに編集することを指します。
技能4：新しい業務のあり方を描き、業務要件を確定する
対象業務における新しい業務のあり方や運用をまとめた上で，業務上実現すべき要件を明らかにするスキル
As-Is（現状）の分析とモデル化ができたら、To-Be（あるべき姿）の業務を設計します。ここで大切な考え方が、「現行業務をそのままシステムに置き換えない」ことです。紙の帳票をそのまま画面にしただけのシステムは、紙時代の非効率（三重チェック、部門間の紙の回覧など）をデジタルで固定化してしまいます。技能4が「新しい業務のあり方や運用をまとめた上で」とわざわざ書いているのは、業務の再設計が先、要件の確定は後という順序を求めているからです。
ステップ③：システム化を計画する（技能5・6・7）
技能5：システム方式（アーキテクチャ）を策定する
取りまとめた業務機能を実現するために必要なシステム方式（アーキテクチャ）を策定するスキル
業務要件が固まったら、それをどういう構造のシステムで実現するか＝システム方式（アーキテクチャ）を決めます。アーキテクチャとは、システムを構成する要素（サーバ・アプリケーション・データベース・ネットワークなど）の分け方と繋ぎ方の設計思想のことです。この段階で決める代表的な論点は次のとおりです。
- 処理形態：1か所のサーバに処理を集める集中処理か、複数の拠点・サーバに分ける分散処理か。
- 実現手段：自社で一から開発（スクラッチ）か、パッケージ製品の導入か、クラウド上の既製サービス（SaaS）利用か。
- 稼働環境：自社設備（オンプレミス）か、クラウドか、その組み合わせか。※クラウド活用の設計論は小項目1-4で本格的に扱います。
- 連携構造：他システムとどこで・どうデータを受け渡すか（リアルタイム連携かバッチ連携か等）。
ポイントは、方式の選定が常にトレードオフの意思決定だということです。例えばSaaS利用は構築が速く運用負荷が軽い一方、業務側をサービスの仕様に合わせる必要があります。スクラッチ開発は業務にぴったり合わせられる一方、コストと期間がかかります。業務要件と制約条件（予算・納期）に照らして選ぶのが正解筋で、「最新技術だから」「他社が使っているから」は根拠になりません。
技能6：移行・連携・運用保守の「基本方針」を策定する
システム移行，他システムとの連携，運用・保守など，システムの稼働に必要な事項に関する基本方針を策定するスキル
システムは「作って終わり」ではなく、旧システムから安全に切り替え（移行）、周辺システムと繋がり（連携）、動かし続ける（運用・保守）ことで初めて価値を生みます。計画段階でこれらの基本方針を決めておかないと、開発の終盤で「切り替え方を考えていなかった」という事故が起きます。中でも試験対策上おさえておきたいのが移行方式の3類型です。
| 移行方式 | やり方 | 利点 | 注意点 |
|---|---|---|---|
| 一斉移行（一括移行） | ある時点で旧システムを止め、新システムへ一度に切り替える | 移行期間が短く、二重運用のコストがない | 切り替えに失敗したときの影響が最大。入念なリハーサルと切り戻し計画が必須 |
| 段階移行 | 拠点別・業務別・機能別などに分割して順次切り替える | 問題を小さい範囲で発見・修正でき、リスクを抑えられる | 移行期間中は新旧が混在し、その間の連携の仕組みが必要になる |
| 並行運用 | 一定期間、新旧両システムを同時に動かし、結果を突き合わせて確認してから旧を停止する | 新システムの正しさを実データで検証でき、最も安全側 | 二重入力・二重運用の負荷とコストが大きい |
技能7：サービスと品質の「基本方針」を策定する
システムが提供するサービスと，それに基づくシステムの品質に関する基本方針を策定するスキル
最後の技能は見落とされがちですが、実務上とても重要です。「システムが提供するサービス」とは、利用者から見たときにそのシステムが約束する働きのこと。サービスの水準（サービスレベル）を先に決め、そこからシステムに必要な品質を逆算するという発想です。
混同しやすい概念の整理
この節に登場した、似ていて紛らわしい概念を対比表でまとめます。試験では「どの段階の・どのレベルの話か」の仕分けが問われやすいポイントです。
| 紛らわしいペア | 違いの核心 |
|---|---|
| ニーズ・問題点 ⇔ 業務課題 | ニーズ・問題点は生の声・事実。業務課題はシステムで解ける形に翻訳・定義し直したもの（技能1） |
| 業務要件 ⇔ システム要件 | 業務要件は業務がどうあるべきか（1-1の守備範囲）。システム要件はシステムが満たすべき条件で、機能要件（1-2）と非機能要件（1-3）に分かれる |
| 要件 ⇔ 制約条件 | 要件は実現したいこと（調整可能）。制約条件は守るべき前提（予算・納期・法規制など、原則動かせない） |
| As-Is ⇔ To-Be | As-Isは現状の業務・システム（技能2で分析）。To-Beはあるべき姿（技能4で設計）。現状の単純置き換えはTo-Be設計ではない |
| 基本方針 ⇔ 詳細設計 | 1-1で決めるのは移行・運用・品質などの方針レベル。数値目標や具体的設計は1-3以降・後工程の仕事 |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
「受注から出荷までのリードタイムを2日以内に短縮する」という記述のレベルとして、最も適切なものはどれか。
デジタル戦略を踏まえてシステム化を進めるとき、最初に行うべき活動として最も適切なものはどれか。
「一定期間、新旧両方のシステムを同時に運用し、処理結果を突き合わせて新システムの正しさを確認してから旧システムを停止する」移行方式はどれか。
営業部門と経理部門の要求が矛盾している。要求を調整して取りまとめる際の考え方として、最も適切なものはどれか。
まとめ：小項目1-1で身につけること
- 上流工程は「①課題をつかむ → ②業務を設計する → ③システム化を計画する」の3ステップ。シラバス案の技能7つはこの順に対応する。
- 出発点はデジタル戦略。ニーズ・問題点（生の声）を業務課題（システムで解ける形）へ翻訳する（技能1）。現状分析は機能・他システム連携・リスクの3観点（技能2）。
- モデル化で業務を可視化し、矛盾する要求は業務課題と制約条件を拠りどころに調整する（技能3）。To-Beの業務を設計してから業務要件を確定する（技能4）。
- システム方式（アーキテクチャ）の策定はトレードオフの意思決定（技能5）。移行（一斉・段階・並行）・連携・運用保守（技能6）とサービス・品質（技能7）は「基本方針」レベルでこの段階に決める。
- 要件の階層（業務要件→機能要件・非機能要件）の仕分けは頻出。迷ったら主語が業務かシステムかで判定する。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目1・小項目1-1（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（要件の階層、モデリング手法、移行方式など）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
