前回までは、新たなシステムの導入手段としてソフトウェアの購入、クラウドなどのソリューションの利用について取り上げたっすけど、それでは対応できない場合もあるっす。
じゃあ、いよいよ自前でシステムを開発するんだね。
そうっす。一般的にシステム開発はベンダー（システムを作る会社）に依頼するわけっすが、その前に依頼元の会社でもやることはあるんすよ。
| 目的 | ・システム化計画の目的を理解する。 ・現状分析などに基づく業務要件定義の目的を理解する。 |
| 説明 | ・担当業務の情報化，システム化に関する検討に参加できるように，システム化計画の目的やプロセスを理解する。 ・担当業務のシステム化に関する検討に参加できるように、業務要件定義の目的を理解する。 ・担当業務の分析、データの洗出しや整理の進め方を理解し、活用する。 |
システム化計画
青字の部分が今回の学習内容です。
ソフトウェアライフサイクル
ソフトウェアライフサイクルとは、システムの企画から使命を終えるまでの流れをモデル化したもので、「企画」「要件定義」「開発」「運用」「保守」の5つのプロセスに分けられることが多くなっています。
ソフトウェアライフサイクルはあくまでもモデルの１つであって、必ず５つのプロセスに分けないといけないというものではありません。ITパスポート試験では、どのように分けるかは問題文に指示があると思います。
このうち、「企画」と「要件定義」のプロセスは【ストラテジ編】で学習し、「開発」「運用」「保守」のプロセスは【マネジメント編】で学習します。
なんで、そんな中途半端な分け方をするの？
「企画」と「要件定義」は依頼元の会社が話題の中心となるのに対し、「開発」「運用」「保守」はベンダーが話題の中心になるっす。そのため、こんな分け方になってるんすよ。
- 企画プロセス：システム化構想の立案とシステム化計画の策定を行う。
- 要件定義プロセス：システムに必要な機能や条件などをまとめる。
- 開発プロセス：実際にシステム・ソフトウェアを開発していく。
- 運用プロセス：開発プロセスで作成したシステム・ソフトウェアを運用する。
- 保守プロセス：運用しているシステム・ソフトウェアのメンテナンス等を行う。
それではまず、企画プロセスにおけるシステム化構想とシステム化計画についてみていきましょう。
システム化構想の立案
まず最初に、経営戦略や情報システム戦略にもとづいてシステム化構想を立案します。経営上のニーズや課題の把握、事業環境・業務環境・現行業務・システム・情報技術動向等の調査分析、システム化の対象となる業務の明確化、業務の新全体像の作成などを行います。
まずは、経営戦略を前提としてぼんやりとした大まかな構想を練るというイメージです。
システム化計画の策定
次に、少しぼんやりとしたシステム化構想をより具体化したシステム化計画を策定します。システム化計画では、システム化対象業務の問題点を分析し、システムで解決する課題を定義してシステム化の全体像を明らかにし、システムを実現するための実施計画を策定します。
具体的には、システム化計画の立案においては次のような作業を行います。
- システムの適用範囲：どの業務をシステム化するか、どこまでシステム化するかなど。
- 開発スケジュール：優先順位、業務移行、納期の目標などのスケジュール。
- 開発プロジェクト体制：開発部門、利用部門から必要な人員を確保。
- 費用対効果：システム開発・運用にかかるコストと効果を予測・分析。
- リスク分析：システム開発・運用に伴うリスクの分析と対応を検討。
- システム化計画の文書化と承認：計画を文書化し、責任者の承認を得ます。
ここで記載した作業はほんの一部で、各プロセスにおいて実施すべき作業はとてもたくさんあります。それらをすべて丸暗記するのは大変な作業で、勉強の効率としては悪いものとなります。なので、「各プロセスでは大体どんなことをするのか？」というざっくりとしたイメージで捉えておき、試験では選択肢の中から選べるようになれば大丈夫です。
要件定義
企画プロセスの次は要件定義プロセスに入ります。要件定義プロセスでは、システムに必要な機能を明確にし、利害関係者の合意を形成します。
システム開発において「要件定義」という言葉は2度出現します。2回目の「要件定義」は開発プロセスで出てきます。この2つを混同してしまうとわけが分からなくなるので注意してください。
ここでの「要件定義」（1回目の要件定義）は、依頼元の会社側で行う要件定義を意味します。システム化の適用範囲になる業務担当者のニーズを考慮し、システムに必要な機能や仕組みを明確にします。
まだシステム開発を依頼する前ってことに気を付けるっすよ。
「要件定義プロセス」における要件定義（1回目の要件定義）は、システム開発を依頼する側の企業（非エンジニア）が行うものです。したがって、技術的なことはあまり考えずに、とりあえずどんなことがしたいのか（システムに求めるもの）を決定する、といったイメージになります。
ここでの要件定義は内容に応じて、業務要件定義とシステム要件定義に分類されます。
業務要件定義
利用者のニーズを調査し、調査内容の分析や現行業務の分析などを行って、業務上、情報システムが実現すべき業務内容（業務としてどんなことを実現したいのか）をまとめます。また、システム化の範囲と機能を具体化し、利害関係者間で合意します。
システム要件定義
業務要件を満たすためにシステムが持つべき機能要件と非機能要件を定義します。
機能要件
業務要件の実現に必要な情報システムの機能に関する要件で、システムが備えるべき機能について定めたものです。そのシステムが扱うデータの種類や構造、処理内容、操作画面や帳票印刷といったインタフェースなど。必ず備えていなければいけない最低限必要な機能です。
非機能要件
性能や可用性及び運用・保守性などの品質要件や、技術要件、セキュリティ、運用要件などの機能面以外の要件全般。利用者の満足度や利便性などを向上させるものです。
ここでは業務要件定義がメインとなり、システム要件定義は業務要件をまとめる中で派生的に出てくるものといったイメージになります。
業務要件がメインとなる１回目の要件定義のことを「業務要件定義」、システム要件がメインとなる２回目の要件定義のことを「システム要件定義」と表現している参考書もあります。
わかりにくいなぁ。。。
簡単な例を示しておくっす。あくまでも、ざっくりとしたイメージっすよ。
| プロセス | 例 |
|---|---|
| システム化構想の立案 | 手作業で会計帳簿を記入しているため、時間がかかる・ミスが多い。自動化して効率をアップさせたい。 |
| システム化計画の策定 | 経理業務をシステム化するため、どこまでを、いつまでに、いくらで、どういう方法・体制でシステム化するかを計画。 |
| 業務要件定義 | 取引を入力すると、仕訳→帳簿作成→決算処理→財務諸表作成までの一連の流れを自動化する。 |
| 機能要件 | 決算処理結果は経理部長が確認する、処理の過程は全て記録に残す、など |
| 非機能要件 | 24時間365日フル稼働、年間停止時間は○時間以内、処理時間は〇分以内、など |
確認○×問題
企画プロセス、要件定義プロセス、開発プロセス、保守プロセスと続くソフトウェアライフサイクルにおいて、企画プロセスの段階で行う作業として「機能要件と非機能要件の定義」などがある。
（出典：平成23年度秋期分 問29一部改変）
答え：×
「機能要件と非機能要件の定義」は要件定義プロセスで行う作業です。企画プロセスでは、システム化構想の立案とシステム化計画の策定を経て、システムを実現するための実施計画を策定します。
システム化構想の立案の際に、前提となる情報は「経営戦略」である。
（出典：平成27年度秋期分 問4一部改変）
答え：〇
取得するシステムは経営戦略と整合性がなければなりません。よって、システム化構想の立案の際に前提となる情報は「経営戦略」です。
次の中で、ソフトウェアライフサイクルにおいて、システム化計画の立案で行うべき作業は2つある。
- 経営要求、課題の確認
- システム要件の定義
- 導入の費用対効果の予測
- 品質、コスト、納期の目標値と優先順位の設定
（出典：平成21年度秋期分 問25一部改変）
答え：〇
1.の作業：企画プロセス（システム化構想の立案）で行う作業です。
2.の作業：要件定義プロセスで行う作業です。
3.の作業：企画プロセス（システム化計画の立案）で行う作業です。
4.の作業：企画プロセス（システム化計画の立案）で行う作業です。
ソフトウェアライフサイクルを、企画、要件定義、開発、運用のプロセスに区分したとき、「利害関係者のニーズと要望事項」は、要件定義プロセスで明確にする項目である。
（出典：平成25年度春期分 問23一部改変）
答え：〇
要件定義プロセスでは、利用者のニーズを調査し、調査内容の分析や現行業務の分析などを行って、業務上、情報システムが実現すべき業務内容（業務としてどんなことを実現したいのか）をまとめます。また、システム化の範囲と機能を具体化し、利害関係者間で合意します。
定義すべき要件を業務要件とシステム要件に分けたとき、以下の記述のうち、業務要件に当たるものは２つある。
- オンラインシステムの稼働率は99%以上とする。
- 情報漏えいを防ぐために、ネットワークを介して授受するデータを暗号化する。
- 操作性向上のために、画面表示にはWebブラウザを使用する。
- 物流コストを削減するために出庫作業の自動化率を高める。
（出典：平成28年度秋期分 問4一部改変）
答え：×
業務要件は、情報システムが実現すべき業務内容のことです。したがって、業務要件に該当するものは4.の記述のみです。他の記述はすべてシステム要件となります。
連結会計システムの開発に当たり、機能要件と非機能要件を次の表のように分類したが、分類を誤っている項目が3つある。
| 機能要件 | 非機能要件 |
|---|---|
| ・国際会計基準に則った会計処理が実現できること ・決算処理結果は、経理部長が確認を行うこと ・決算処理の過程を、全て記録に残すこと ・故障などによる年間停止時間が、合計で10時間以内であること ・連結対象とする会社は毎年変更できること | ・最も処理時間を要するバッチ処理でも、8時間以内に終了すること ・誤入力した伝票は、訂正用伝票で訂正すること ・法定帳票以外に、役員会用資料作成のためのデータを自動抽出できること ・保存するデータは全て暗号化すること |
（出典：平成28年度春期分 問1一部改変）
答え：〇
機能要件は、業務要件（業務上、システムによって実現したいこと）の実現に必要な情報システムの機能に関する要件で、そのシステムが扱うデータの種類や構造、処理内容、操作画面や帳票印刷といったインタフェースなどです。
また非機能要件は、性能や可用性及び運用・保守性などの品質要件や、技術要件、セキュリティ、運用要件などの機能面以外の要件全般です。
よって、正しくは次のような分類になります。
| 機能要件 | 非機能要件 |
|---|---|
| ・国際会計基準に則った会計処理が実現できること ・決算処理結果は、経理部長が確認を行うこと ・決算処理の過程を、全て記録に残すこと ・誤入力した伝票は、訂正用伝票で訂正すること ・法定帳票以外に、役員会用資料作成のためのデータを自動抽出できること ・連結対象とする会社は毎年変更できること | ・最も処理時間を要するバッチ処理でも、8時間以内に終了すること ・故障などによる年間停止時間が、合計で10時間以内であること ・保存するデータは全て暗号化すること |
「システムに盛り込む業務ルールの誤った解釈」は、要件定義プロセスの不備に起因する問題である。
（出典：平成31年度春期分 問17一部改変）
答え：〇
「システムに盛り込む業務ルール」の定義は、要件定義プロセスで行う作業となります。したがって、業務ルールの誤った解釈は要件定義プロセスの不備に起因する問題といえます。
