システムを構築する際の設計に関して、要件定義から具体的なシステム開発までの流れをまとめて解説しましょう。
システム化計画
ここでは、中長期的な経営戦略や事業戦略に基づいたシステムを確立するために、情報システム化の方向性を決める「システム化構想」や、構想をもとに策定する「システム化計画」について学んでいきます。
システム化構想
「システム化構想」は、今後のシステム化の全体的な構想や戦略を明確にするフェーズです。
システム化の目的、システム化に関連する業務プロセス、システム化の対象範囲、システム投資額、システム化による効果、各目標の選定などを明確化する必要があります。
システム化を行うことは、企業の経営戦略や業務戦略と連携して開発することになるので、「システム化構想」の誤りが経営に悪影響を与えることも考慮しなければなりません。
そのようなことを防ぐため、「システム化構想」の段階で、開発関係者や経営者間などあらゆる関係者で構想を共有し、費用対効果の見極めや、業務上のリスク、フィージビリティ等も検討します。
「システム化構想」の手法としては、「EA（エンタープライズアーキテクチャ）」が有名です。現在の業務と理想とする業務の状態をモデリングし、理想とするシステム化のイメージを確立することが、「システム化構想」の最大の目的となります。
システム化計画
策定された「システム化構想」をもとに、どのようなシステムを構築していくか計画することを「システム化計画」といいます。
「システム化計画」では、全社的な経営戦略を見据えて、対象となる業務の調査、現在使用されているシステムの分析を行ったうえで、「全体システム化計画」を策定。
さらに各部署の業務で必要とされる業務を考慮に入れた「個別システム化計画」を立案します。
システム化計画の立案で配慮すべき点には、対象となる「システム適用範囲」、開発規模を考慮しての「システム開発スケジュールの明確化」、開発にあたりどのような人員構成にするかを決める「プロジェクト推進体制」等があるのです。
さらに、システム導入によって発生するリスク分析（情報システム導入リスク分析）も行っておく必要があります。
システム適用範囲
企業内には様々な業務があり、その業務は様々な部署により実施されています。システム化計画の際には、どの部署がどの業務を行っているのかを把握した上で、その業務をシステム化すべきかどうかを検討し、「システム適用範囲」を決定。
システム適用範囲に含めるかどうかを判断する基準の例としては、システムの開発費用に見合うだけの業務の効率化や、何らかのプラス成果が実現できるか、いわゆる「費用対効果」が見込まれるかどうかがあげられます。
システム開発スケジュールの明確化
システムの適用範囲がきまり規模が見えてきたら、「全体開発スケジュール」を検討します。開発規模に対して不適切な開発期間の設定は、開発コストの増加につながるのです。
費用対効果を上げるためには、全体開発スケジュールをしっかり計画し、投資に見合うシステム構築を行わなくてはなりません。
経験から、設計から総合テストまでの標準的な開発期間（月）は、開発規模（工数、人月）の3乗根に比例し、その係数は概ね2.5 と言われています。
スケジュール管理には「ガントチャート」などを用いて、開発期間と日程を管理します。
プロジェクト推進体制
全体の開発スケジュールが決定したら、どのような人員構成でシステム化計画を進めていくかを検討します。
人員の構成には、システム開発関係者だけではなく、経営者も参加。
また業務面については、営業部門、業務部門等、開発したシステムを利用する部門が責任を持って進めていくことが大切です。
リスク分析
「リスク分析」とは、情報システムを構築し運用していく上で、リスクがどこにどのくらい存在しているか、またそのリスクが発生したとき、どの程度の影響があるかを予想し測定することです。
先ずリスクとして考えられる事項を洗い上げ、次にその各々について顕在化する程度（リスクの発生可能性）を推定します。
リスクが顕在化した際にどれくらいの影響が生じるか（影響度）を整理し、リスクの発生可能性×影響度を計算して、リスクの評価とします。
そして影響が大きいと考えられるものから対策をたてていきます。リスク対策は「回避」「低減」「移転」「保有（受容）」の4つに分類できるのです。
「リスク回避」とは、リスクが発生しそうな要因を停止することです。例えば、情報資産をネットワークから切断するようなことを指します。
「リスク低減」とは、脅威発生の可能性を事前に下げることです。例えば、情報管理するコンピュータを分散して設置することは「リスク低減」です。
「リスク移転」とは、リスクを他社などに移すことです。例えば、外部委託などの契約内容でリスクを分散することを指します。
「リスク保有」とは、損失を許容範囲内と見なして自社で負担することです。リスク発生時の損害が小さいときに用いられ、特に対策は行いません。
要件定義
システム化計画を実施する上で、システム化の範囲やシステムに要求される機能や性能などを決定するのが「要求分析」と「要件定義」です。
「要件定義」を行うにはまず「要求分析」を行い、要求の実現可能性や投資対効果を勘案して「要件」として決めるという手順で行います。
「要件定義」では、「ヒアリング」などの手法を用いて、利用者から現在の業務状況を聞き取ります。ヒアリングをスムーズに行うためには、事前に聞き取る項目を準備しておくことが必要です。
そして聞き出した内容を分析した結果、どの様に業務を改訂するか、どの業務をシステム化するか、どの範囲までを対象とするかなどの目標を設定。
このような目標を設定することで、対象となる部署の意見や業務の内容を整理して、利用者と開発者の意識を同じ方向に向けることが可能となります。
要件定義においては、「業務要件」「システム機能要件」「非機能要件」などを明らかにします。
要件分析
「要求分析」とは、システムを利用する利用者のニーズを把握し、分析することです。
そのニーズをまとめたものが「要求仕様書」です。要求仕様書は次のような手順で作成します。
①ユーザニーズの調査
②要求の洗い出しと現状分析
③システム化ニーズの整理
④業務における各種前提条件や制約条件の整理
⑤現状システムの課題整理
⑥解決策の検討と実現可能性の分析
⑦新業務モデル、業務フローの提案
⑧要求仕様書の作成
要求分析の結果を踏まえてシステム化の可否を判断し、個々の要求の投資対効果等も評価し、システムの全体の枠組み・機能を明らかにすることが「要件定義」です。
要件定義には「業務要件定義」「機能要件定義」「非機能要件定義」の3つがあります。
「業務要件定義」とは、全体業務の中でシステム化を実現しなければならない業務に関する要件を定義することです。
現在、その業務が誰によってどのように行われているかを可視化する必要があります。
「機能要件定義」とは、利用者が求めている業務要件を実現するために必要なシステムの動作、及び処理の機能を具体的に定義することです。
機能内容を明確に定義することで費用が算出され、限られた予算内での優先順位を決めることができます。
「非機能要件定義」とは、機能要件以外の要件を指します。具体的には、処理時間や応答時間などの性能、信頼性、可用性、移行要件、運用性、情報セキュリティ、環境配慮やエコロジー、拡張性、想定する寿命、開発基準などがこれにあたります。
要件定義書を作成したら、その要件が適切かどうか改めて評価を行います。この際、開発に携わる関係者だけではなくシステムの利用者も含め、共同レビューという形式での評価です。
共同レビューを行う際には、レビュー参加者を誰にするか、どのような方法で行うかを取り決めておく必要があります。
「共同レビュー」では、要件定義の結果が、適切な投資や、期待される効果を想定して要求事項を満たせるかどうかを営業部門や生産部門等、利用者側のメンバを交えて確認することが大切です。
調達計画・実施
要件定義に沿って、システム化に必要なハードウェア・ソフトウェア・ネットワーク機器・設備などを整えることを「調達」といいます。
また開発行為を自組織で行うか外部の企業に委託するか、いつどのような機器等を導入するか、どのような調達方式で実施するかといった計画のことを「調達計画」といいます。
調達計画をたてる際には、社員の情報スキル・予算・自社開発と外部委託を比較した費用対効果の判断など、様々な点が検討課題となります。
政府の調達は、WTO の協定や、会計法・予算決算及び会計令などの法令、政府内のガイドライン等に従って実施することが大切です。
調達の流れ
外部からの調達を行う場合、要件定義に照らし合わせ、慎重に依頼先企業の選定を行うことが必要となります。
一連の流れは次のとおりです。 ①「情報提供依頼（RFI：Request For Information）」とは、「提案依頼書（RFP：Request For Proposal）」の作成にあたって、外部の企業に対してシステム化の目的や業務内容を示し、システム化のための情報提供を求める文書のことです。
②「提案依頼書（RFP：Request for Proposal）」とは、外部の企業に対して調達システムの概要や条件などを示し、提案書の提出を求める文書のことです。 「提案依頼書」には、システムの概要・目的・必要機能・求められるシステム要件・契約事項などのシステムの基本方針を盛り込みます。
③「見積依頼書（RFQ：Request for Quotation）」とは、調達要件を明示し、概算での見積額の提示を求める文書です。調達先の選定にあたっては、提案評価基準や要求事項適合度の重み付けを含めて、選定 の手順を確立します。
実際の選定は、提出された外部企業の提案書や見積書から、開発の確実性・信頼性・費用の内訳・工程スケジュール・納期などの比較評価を行います。調達によるリスクを分析、評価し、対策をたてる必要があるのです。
評価の内容としては、最低限の法令遵守や利益貢献だけではなく、社会貢献や情報公開を自主的に行うべきだという考え（CSR 調達）や、地球環境に配慮しているかどうか（グリーン調達）を検討します。
選定の方法としては、提出された企画内容を優先して行う「企画競争」や、価格面を優先して選定する「一般競争入札」などがあります。
選定した結果に関しては、選定に参加した企業すべてに、選定方法が明確に解るような方法で連絡します。
選定した外部企業と契約について交渉を行い、契約を締結します。事前に契約内容を明らかにしておくことで、開発現場の混乱・納期遅れ・システム障害などを事前に防ぐことができるのです。
ソフトウェアの開発時の取引契約モデルとして、経済産業省が公表している「情報システム・モデル取引・契約書」や情報サービス産業協会が公表している「ソフトウェア開発委託基本モデル契約」などがあります。
またデータ利活用やAI技術開発に関する契約作成の手引きとして、2018年に経済産業省が「AI・データの利用に関する契約ガイドライン」を策定しました。法令改正に従ってアップデートし、「1.1 版」として2019 年に公表しています。
コメント