システム企画の要点とまちがえやすい点（ITパスポート試験 論点テキスト）

このページの論点

ストラテジ系｜システム戦略｜8論点・要点46本・まちがえやすい点28本・式1本

• システム化計画
  • システム企画・構想・計画の位置づけ
  • 計画の承認・見直しと実現可能性調査
  • 費用対効果・投資評価とリスク分析
• 要件定義
  • 業務要件・機能要件・非機能要件
  • 要件定義の進め方と手法
• 調達計画・実施
  • 調達の流れとRFI・RFP
  • ベンダ選定・調達方式とSLA
  • 発注者責任・多重下請けとパッケージ導入

システム化計画

システム企画・構想・計画の位置づけ

システム化構想・システム化計画・要件定義・調達の関係と、システム企画がライフサイクルの上流に位置することを扱う。

要点

• システム企画は、経営戦略・情報システム戦略を踏まえてシステム化構想やシステム化計画を立案し、要件定義や調達計画へとつなげる、システム開発ライフサイクルの上流の工程である。
• システム化構想は、経営戦略や事業目標を踏まえて、対象とする業務・システムの範囲や実現すべき全体像を大まかに描く、システム化計画に先立つ上流の検討工程である。
• システム化計画は、経営戦略や業務上の課題を踏まえて、情報システム導入の目的・対象範囲・予算・スケジュールなどの方針を明確にする、最上流に位置する計画である。
• システム化計画は、経営戦略を踏まえた全社的な方向性を示す全体計画と、個々のシステム導入・更新に関する個別計画から構成される。
• 共通フレームでは、経営課題からシステム化構想と計画を立てる工程を企画プロセス、利用者側の要求を整理して合意する工程を要件定義プロセスという。
• 情報システムのライフサイクルは、企画段階から運用・保守を経て、最終的な更新・廃棄に至るまでの一連の流れを指す。
• 共通フレーム（SLCP-JCF）は、ソフトウェアライフサイクルの標準的な作業や用語を定め、発注者と受注者の認識のずれを防ぐガイドラインである。

まちがえやすい点

• システム設計は要件を実現する仕組みを決める開発側の工程であり、利用者の要求そのものを決める要件定義プロセスではない。
• システム化構想は企画の初期段階に位置づけられ、バグ修正の保守計画や利用者マニュアルの作成とは別である。
• 共通フレームはソフトウェアライフサイクルの作業や用語を定めるものであり、言語規格やPMBOKとは異なる。

計画の承認・見直しと実現可能性調査

システム化構想・計画の承認と見直し、フィージビリティスタディでの着手可否の判断を扱う。

要点

• システム化計画やシステム化構想は、経営層や関係部門の承認を経たうえで進め、その後の状況変化に応じて必要な修正を行いながら進めることが望ましい。
• システム化構想は、投資規模やリスク、経営戦略との整合性等を踏まえて経営陣の承認を経ることが一般的で、全社的な経営資源配分の意思決定として正式に位置づけられる。
• システム化計画は、策定後も事業環境や経営戦略の変化、案件の進捗状況等を踏まえて定期的に見直し、計画と実態の乖離を是正していく。PDCAサイクルに沿った運用が求められる。
• フィージビリティスタディは、システム化構想・企画の初期段階で技術面・コスト面・スケジュール面・組織面等から実現可能性を調査し、プロジェクトの着手可否を判断するための検討である。

まちがえやすい点

• システム化計画は策定後も定期的に見直すものであり、一切変更してはならないという考え方とは異なる。
• フィージビリティスタディは着手可否を判断する事前の調査であり、最終検収作業や人事上の適性検査とは別である。
• システム化構想の承認は経営陣が行うのが一般的であり、情報システム部門の一存で決定できるという考え方とは異なる。

費用対効果・投資評価とリスク分析

ROI・NPV・TCO・費用対効果・費用便益分析といった投資評価の指標と、リスク分析・優先順位付けの考え方を扱う。

要点

• ROIは、投資した費用に対してどれだけの効果が得られたかを測定し、投資の妥当性を評価するための考え方である。
• 費用対効果分析は、システム投資に要する費用と、それによって得られる効果であるコスト削減額や売上増加額等を比較し、投資として妥当かどうかを判断する分析である。
• NPV（正味現在価値）は、将来得られるキャッシュフローを現在価値に割り引いて合計し、初期投資額を差し引いて算出する投資評価指標であり、プラスであれば投資価値があると判断される。
• 費用便益分析は、システム化によって得られる効果を定量的効果と定性的効果の両面から把握し、投資費用と比較して投資の妥当性を評価する手法である。
• ROIは投資に対する利益の割合であり、TCOは導入から廃棄までにかかる総費用を捉える考え方である。
• システム企画段階のリスク分析は、プロジェクトを妨げうる要因を洗い出し、影響度や発生可能性を評価して対応策を検討する取り組みで、許容可能な水準までリスクを管理することを目的とする。
• 複数のシステム化案件がある場合は、投資対効果や経営戦略との整合性、緊急性、リスク等の観点から各案件を評価して優先順位を付け、限られた経営資源を有効に配分する。

まちがえやすい点

• TCOは運用・保守費用を含めて総費用を捉える考え方であり、導入費用だけで判断する見方とは異なる。
• リスク分析の目的はリスクをゼロにすることではなく許容可能な水準まで管理することであり、技術リスクのみを対象とする説明ではない。
• 費用対効果分析は費用と効果を比較して投資の妥当性を判断する分析であり、デザインの評価や処理速度の測定、利用者数の集計とは別である。
• ROIは投資の妥当性を評価する考え方であり、費用を集計するだけで効果を測定しないものとは異なる。

式

• NPV（正味現在価値）将来のキャッシュフローの現在価値の合計−初期投資額プラスであれば投資価値があると判断する

要件定義

業務要件・機能要件・非機能要件

業務要件・機能要件・非機能要件の違いと、要件定義書の記載内容、非機能要求グレードの役割を扱う。

要点

• 要件定義では、システムが実現すべき業務機能を示す機能要件に加えて、性能・信頼性・拡張性・セキュリティなど機能面以外の品質に関する非機能要件も明確化する。
• 業務要件は業務上実現したい内容・目的を示し、機能要件はその業務要件を実現するためにシステムが備えるべき具体的な機能を示す。
• 非機能要件は、性能・可用性・セキュリティ・保守性・拡張性・運用性等、機能要件以外のシステムの品質に関わる幅広い要件を指す。
• 非機能要求グレードは、可用性・性能・セキュリティ等の非機能要件について求める水準を段階的に整理したモデルで、発注者とベンダーが要求水準を認識合わせする参考資料として使われる。
• 要件定義書には、業務要件・機能要件・非機能要件のほか、システム化の範囲や前提条件・制約事項等を整理して記載し、発注者とベンダーの共通認識の基礎とする。

まちがえやすい点

• 業務要件は実現したい内容、機能要件はそれを実現するためのシステムの具体的な機能であり、両者を同義語とする説明ではない。
• 非機能要求グレードは要求水準を段階で整理したモデルであり、技術者の資格等級を示す指標とは別である。
• 非機能要件は性能や可用性などの品質に関わる要件であり、機能要件と同じ内容や、契約金額・支払条件を定めるものとは異なる。
• 要件定義では機能要件だけでなく非機能要件も定義するのであり、機能要件を定義すれば足りるという考え方とは異なる。

要件定義の進め方と手法

要件定義のプロセス、利害関係者の合意形成、業務プロセスの可視化、プロトタイピング、MoSCoW法といった手法を扱う。

要点

• 要件定義は、業務要件を明確にしたうえで機能要件・非機能要件へと具体化し、利害関係者間で合意を形成しながらシステム化の範囲を確定していくプロセスである。
• 要件定義では立場の異なる利害関係者の要求が競合することがあるため、優先順位の整理や調整を通じて関係者間の合意を形成しながら要件を確定していく。
• プロトタイピングは、早い段階で試作品を作成して利用者に実際に操作してもらい、要求内容の認識のずれを早期に発見して仕様の確認・修正に役立てる開発手法である。
• 要件定義に先立って現行の業務プロセスを可視化・分析することは、システム化すべき範囲や課題を正確に把握し、要件の抜け漏れを防ぐうえで有効である。
• MoSCoW法は、要件をMust（必須）・Should（重要）・Could（あれば望ましい）・Won't（対象外）の4区分に分類し、優先的に実現すべき要件を明確にする優先順位付けの手法である。

まちがえやすい点

• 要件定義の合意形成は優先順位の整理と調整によるものであり、最も声の大きい利用者の要求のみを採用する方法とは別である。
• プロトタイピングは試作品で要求を確認する手法であり、要件定義を行わない開発方式や本番運用後の動作確認とは異なる。
• 要件定義はシステム化の範囲を確定する工程であり、プログラミング完了後に実施する工程ではない。

調達計画・実施

調達の流れとRFI・RFP

RFI・RFP・調達仕様書の役割と、調達計画から検収までの一連の流れを扱う。

要点

• RFIは情報提供依頼書で、発注者がシステム化の検討段階でベンダー企業に対して技術動向や提供できる製品・サービスに関する情報の提供を依頼する文書である。
• RFPは提案依頼書で、発注者が調達したいシステムの要件・機能・予算・納期などの条件を整理してベンダー企業に提示し、具体的な提案を依頼する文書である。
• 調達計画・実施は、調達の方法・スケジュール・基準を計画し、RFI・RFPの提示、見積り比較、契約締結、納品後の検収に至るまでの一連の手続きを指す。
• 調達は、まずRFIで市場や技術の情報を集め、次にRFPで要件を示して提案を求め、提案内容を評価して発注先を決めるという順で進む。
• RFPは、要件や予算、納期を示して具体的な提案と見積りを求める文書であり、RFIは先に出して製品や実現方法を知るための文書である。
• 調達仕様書は、発注者が求める要件や納期、契約条件等を明確化した文書で、RFP等とあわせて提示することでベンダーの提案内容のばらつきを防ぎ、公正な比較・評価を可能にする。
• グリーン調達は、価格や品質だけでなく環境への負荷の小ささも基準にして、製品やサービスを優先的に購入・調達すること。
• AI・データの利用に関する契約ガイドラインは、データの提供・共有やAIソフトウェアの開発・利用に関する契約を結ぶ際の、取決め事項や留意点を整理した経済産業省の指針。

まちがえやすい点

• RFPは提案を受け取る前に出す文書であり、選定結果を通知するための文書とは異なる。
• RFIは検討段階で情報の提供を求める文書であり、契約締結後の文書や稼働後のアンケート、見積金額を提示する文書ではない。
• SLAはサービス品質の水準を合意する文書であり、調達の初期に出す依頼文書であるRFIやRFPとは別である。

ベンダ選定・調達方式とSLA

一般競争入札・指名競争入札・随意契約、提案評価、ベンダ選定基準、調達の透明性、SLAによる品質の合意を扱う。

要点

• ベンダー選定では、提案内容の技術的な妥当性や実績、価格、サポート体制などを、RFPに基づいてあらかじめ定めた評価基準で総合的に評価し、要件に最も適したベンダーを選ぶ。
• 提案評価（コンペ方式）は、複数のベンダーの提案を価格に加えて実現性・技術力・実績等の観点から総合的に審査して発注先を選定する方式で、評価基準をあらかじめ定めて示すことが望ましい。
• 調達方式には、広く参加者を募る一般競争入札、あらかじめ選定した複数事業者から選ぶ指名競争入札、特定事業者と個別に交渉する随意契約等があり、案件の性質に応じて使い分けられる。
• 調達の透明性確保は、発注先の選定過程が公正であることを対外的に説明できるようにする取り組みで、評価基準の事前提示や選定理由の記録等が求められる。
• SLAは、サービス提供者と利用者との間で、稼働率・障害復旧時間・応答時間等のサービス品質水準に関する具体的な目標値を明確にし、双方で合意する契約である。

まちがえやすい点

• 一般競争入札は広く参加者を募る方式、指名競争入札は選定した複数事業者から選ぶ方式であり、一般競争入札を特定1社との交渉とする説明ではない。
• ベンダー選定は総合評価で行うものであり、価格だけで機械的に選定する方法とは別である。
• 調達の透明性確保は選定理由を記録・説明することであり、特定ベンダーとのみ非公式に交渉する進め方とは異なる。
• SLAはサービス品質の目標値を合意する契約であり、脆弱性診断のみの技術文書や著作権帰属のみを定めた文書ではない。

発注者責任・多重下請けとパッケージ導入

ユーザー企業とベンダーの役割分担、発注者責任、多重下請け構造の課題と、パッケージ導入・カスタマイズ・アドオンの違いを扱う。

要点

• 多重下請け構造は、元請けから下請け、さらに孫請けへと開発業務が段階的に再委託される重層的な構造で、責任の所在の不明確化や情報伝達の劣化、中間マージンの発生等の課題が指摘される。
• システム開発では、業務内容を熟知するユーザー企業が要件確定に主体的に関わり、ベンダーが技術面の専門性を発揮して実現方法を提案・実装するという役割分担で、双方が協力して進めることが望ましい。
• 発注者責任は、要件確定や仕様に関する意思決定、必要な情報提供等、ユーザー企業が主体的に果たすべき役割を指し、怠ればプロジェクト失敗の一因として発注者側にも責任が問われることがある。
• パッケージソフトウェアの導入は、スクラッチ開発に比べて一般に短期間・低コストで導入できる一方、自社独自の業務プロセスに合わせたカスタマイズには制約が生じうる。
• カスタマイズはパッケージ本体の設定変更や一部改修、アドオンは本体を変更せず外部に機能を追加して連携させる方式で、アドオンはバージョンアップ時の互換性への影響を抑えやすい。

まちがえやすい点

• カスタマイズは本体の設定変更や一部改修、アドオンは本体を変更せず外部に機能を追加する方式であり、両者を同じ意味とする説明とは別である。
• 要件確定に主体的に関わるのは業務を熟知するユーザー企業であり、要件定義の責任を常にベンダーのみが負うという説明とは異なる。
• 発注者責任はユーザー企業側にも問われうるものであり、責任のすべてを常にベンダーのみが負うという説明とは異なる。
• 多重下請け構造は段階的に再委託される構造であり、単一ベンダーが自社完結する体制とは異なる。

ほかのページ

出典と作り方

この読み物は、IPA「ITパスポート試験 シラバス Ver.6.5」の中分類の順に、アプリ「ITウカール」の収録問題の解説をもとにアプリ製薬が作成したものです。公式の文章の転載ではありません。問題文・選択肢は載せていません。

• ITパスポート試験 シラバス Ver.6.5（IPA）