システム開発の全体像と共通フレームの企画プロセス

結論：工程は「なぜ→何を→どう作る→使う→直す」の順

共通フレームとは、システム開発に関わる作業と用語を日本で統一したガイドラインです。発注側と受注側が同じ言葉で話せるようにするのが目的です。ソフトウェアの一生（ソフトウェアライフサイクル）を、試験では次の5つのプロセスに分けて考えます。

flowchart LR
  subgraph K["企画プロセス"]
    A1["システム化構想の立案"] --> A2["システム化計画の立案"]
  end
  A2 --> B["要件定義"] --> C["開発"] --> D["運用"] --> E["保守"]

たとえるなら家づくりです。企画は「なぜ建てるか・予算・ざっくりした全体像」、要件定義は「家族がどう暮らしたいか」を固める段階、開発が設計と施工にあたります。

企画プロセスで定義するもの（最頻出）

企画プロセスで定義するのは、経営・事業の目的と目標を達成するために必要な、経営上のニーズと業務上の課題です。目的は「システムに関係する要求事項の集まり」「システム化の方針」「実施計画」を得ることです。キーワードは経営・事業目的・方針・計画の4つです。

試験では、ほかのプロセスで定義する要求事項が選択肢として並びます。主語の大きさで見分けましょう。

見分け方：「経営」「事業目的」「方針」「実施計画」が出てくれば企画です。「業務手順」「入出力」は要件定義、「システムの機能・方式」「ソフトウェア」は開発です。

企画は2段階：「構想の立案」と「計画の立案」

企画プロセスは、システム化構想の立案とシステム化計画の立案の2段階に分かれます。構想で「将来の姿」を描き、計画で「どう実現するか（体制・費用・スケジュール）」を詰めます。

計画の立案で考えること

• 業務部門と情報システム部門の役割分担
• 開発・運用・保守の費用の算出根拠と投資効果、情報システムの有効性

ひっかけの定番：「自社社員で開発する前提で進める」「同業他社と同じシステムにする」は、検討の幅を狭めるだけなので誤りです。「テスト計画・運用マニュアル・障害対策を具体的に示す」は後の工程の作業です。

なお「業務モデルとDB・サーバ・ネットワークの構成概要を明確にするのはどのプロセスか」と聞かれたら、答えは企画です。「サーバ」という言葉に引っ張られて要件定義や開発を選ばないようにしましょう。

検証と妥当性確認の違い

どちらも「確認する」プロセスなので混同しがちです。検証は「仕様どおりに作れているか」、妥当性確認は「利用者の視点から見て、意図した正しいものになっているか」を確かめます。

問題文に「利用者の視点」「意図された」とあれば妥当性確認です。

フィージビリティスタディ

フィージビリティスタディは、新しい事業やプロジェクトの計画が実行可能かどうかを調べて検証することです。ブレーンストーミング（批判せずにアイデアを出し合う）、ロールプレイ（役割を演じて学ぶ）、理想システムから考える手法とひっかけで並べられます。「実行可能性」と覚えておけば十分です。

業務改善の6ステップと業務プロセスの再設計

業務改善は、改善目的の確認 → 問題の把握 → 改善目標の設定 → 改善案の策定 → 改善案の評価 → 実施と効果の確認の順に進めます。「問題が分からなければ目標は立てられない」「案が無ければ評価できない」と考えれば、順番は自然に決まります。

全社で業務プロセスを見直して作り直すとき（BPR）は、プロセスを関連する業務ごとに分類し、優先順位を付けて見直すのが正しい進め方です。部門をまたぐ業務を後回しにしたり対象から外したり、詳細なドキュメント作りを最優先したりするのは誤りです。