システム企画｜プロジェクトマネージャ試験

要件の分け方と、発注するまでの文書と順番

システム企画では、何を作るかを利用者の側から要件として固め、外部のベンダに頼むまでの流れを扱います。要件の分け方、案の比べ方、発注に使う文書、作業の順番が整理の軸です。

要件は、システムが何をするかを表す機能要件と、それをどの程度の品質や条件で実現するかを表す非機能要件に分かれます。可用性、性能、拡張性、運用性、保守性、移行性、使用性、サービス時間などは非機能要件です。使用性は、短い訓練で操作を覚えられるかのように、人が使いこなすまでの手間で測ります。満たしたかどうかを妥当な費用で確かめる方法がある要件を、検証可能といいます。

システム化案は数値で比べます。投資利益率は利益の増加額を投資額で割ったもので、年ごとの運用費や削減額には利用年数を掛けて合計します。効果とリスクを重み付けして採点するときは、点数に重みを掛けて合計し、効果からリスクを引きます。重みの大きい項目が結果を大きく左右します。

調達では、まずRFI（情報提供依頼書）で利用できる技術や製品、導入実績などの情報を集め、要件が固まってからRFP（提案依頼書）で具体的な提案を求めます。RFPには要件や条件を明確に書き、提案の評価項目も示しておくと、各社の提案を同じ物差しで比べられます。

システム化計画では、まず業務を分析して業務モデルを作り、それを基にシステム化機能を整理して情報と処理の流れを明らかにします。業務の流れを統一した記法で描く道具がBPMNです。共通フレームは、取得者と供給者が作業の内容や用語をそろえる共通の物差しで、要件定義プロセスでは利害関係者の要件を定義します。

契約の形は、仕様が確定しているかで選びます。経済産業省のモデル取引・契約書では、仕様が固まった後のシステム内部設計からシステム結合までを請負型とし、要件定義のように発注者の判断が中心になる工程は準委任型とする考え方をとっています。