ITパスポート単語帳 - システム企画

新しいシステムの最も初期段階であるいわゆる超上流工程の一部で、システム化構想によってシステム化の対象に選定された業務について、その内容を分析・整理し、ふさわしいシステム方式や目標とする品質などを基本方針として策定する。

大まかなスケジュールやコストの概算も同時に行うことが多い。システム化計画が完了・承認されると、計画の実行段階へ移行し、開発の初期段階である要件定義プロセスなどへ進むことになる。

システム化によって実現する新しい業務モデルを固める段階であり、ここで経営戦略に合致した的確な計画が立てられなければ、この後の工程でシステムが滞りなく完成しても有益な効果は得られない。

事業の遂行などに伴って将来起こりうる悪い出来事やその確率、損害の程度を「リスク」（risk）という。企業などの組織体、あるいはプロジェクトチームなどの集団は、リスクに備え、あるいは対応するために「リスクマネジメント」(risk management)などの活動を行う。

ある事業や業務、プロジェクトなどについて想定される様々なリスクについて、詳細を調べる工程をリスク分析という。事象が生起する可能性(確率や頻度、周期など)の大きさ、実際に生起した際に生じ得る事態や状況、引き起こされる影響や損害、損失の大きさなどを見積もる。

リスク分析に先立って、考えられるリスクを洗い出し、列挙する工程を「リスク特定」という。また、リスク分析の後に、一定の基準に基いて各リスクへの対応・行動の必要性の有無や優先順位を判断・決定する工程を「リスク評価」という。これらの3つの工程を合わせて「リスクアセスメント」(risk assessment)という。

費やしたコストに対してどのような効果が得られたか、また、費用に見合った効果が得られているかを表す概念で、費用が安く、効果が高いほど大きくなる。最安のものが最も高いとも、最良のものが最も高いとも限らず、費用と効果のバランスが最も良いものが最も高い費用対効果となる。

大量生産される工業製品の場合、同じ製品カテゴリーで最も高価なモデルは、最も高性能・高機能なことが多いが、これを達成するために追加のコストがかかったり、高い加工精度などが必要で製造歩留まりが悪かったり、生産数が少なく量産効果が出にくいことなどから、費用対効果は低いことが多い。

一方、最も安価なモデルは性能や機能は低いが、量産効果や価格戦略で売価が極端に安くなることがあり、その場合は最も費用対効果が高いモデルとなる。ただし、仕様の違いに関わらず固定的にかかるコストが高い製品分野では、最安モデルと上位モデルの価格差が小さく、中程度の価格・性能のモデル(ミッドレンジモデル)が最も費用対効果が高くなることもある。

自社の経営戦略や事業構想、業務の現況などに基づいて、どのような情報システムを導入すべきか検討し、開発プロジェクトの立ち上げを行う。標準的にはシステム化構想の立案、システム化計画の策定の二段階に分かれる。

システム化構想では経営上のニーズや課題などからシステム化の対象とする業務を検討・決定する。システム化企画では対象業務の内容を分析し、どのような情報システムが必要となるか、どのように開発・導入を進めるかなどの基本方針や目標を策定する。

要件定義では、利用者がそのシステムで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。

まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討される。

主に利用者側の視点から業務手順を明確化して分析し、情報システムで何がしたいのかをまとめる工程と、これを元に開発者側の視点からシステムが何をすべきか、何が必要かをまとめる工程に分割して考える場合もあり、前者を(狭義の)要件定義と区別して要求定義と呼んだり、両者とも要件定義内の工程として業務要件とシステム要件と呼び分けたりする。

主に大企業などが専門の事業者にシステム開発を委託する際に用いられるウォーターフォール型の開発モデル(前工程を完全に終わらせて次工程に移る方式)では、要件定義はプロジェクトの最初に一度だけ行われ、これを元にシステムの仕様や設計が固められる。

一方、アジャイル開発など同じ工程の流れを循環的に繰り返す反復型の開発モデルでは、前の反復で作られた半完成品に触れながら要件定義を繰り返し、段階的に要件を明確化・詳細化していく手法が用いられる場合もある。

一般的には要件定義プロセスの初期の段階で定義されるもので、対象業務の現状を分析し、新たに実現すべき業務の流れを明らかにする。この段階ではシステムの存在は意識せず、業務の詳細な手順や担当者、扱う情報とその流れなどを決めていく。

業務要件が完成した後に、その中のどこをどのようにシステム化するのかを検討し、システムに要求される要件(システム要件)を定義する。業務要件は業務全体の流れを対象とするため、中にはシステム化の対象とならない(システム要件に対応する項目や要素がない)部分が存在する場合もある。

システムが備えるべき機能や動作、振る舞いを定義したもので、システムが何を扱うのか、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定める。扱うデータの種類や構造、処理内容、画面表示や操作の方法、帳票などの出力の形式などが含まれる。

これに対し、機能面以外の要件を「非機能要件」(non-functional requirement)と呼び、性能や信頼性、拡張性、運用性、セキュリティなどに関する要件が含まれる。

システム開発における要求分析や要件定義などの工程で主に検討されるのはシステムの機能や動作、振る舞いを定義する機能要件で、システムが何を扱うのか、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定める。

しかし、機能要件だけでは求めるシステムの定義としては不完全であり、システムに求められる特性や動作の前提条件などを非機能要件として定義する。例えば、可用性について何の要件も定めなければ、要求された機能は確かに動作するが装置の一部が故障すると即座にシステム全体が停止してしまう脆弱なシステムが納品される事態が起こりうる。

情報処理推進機構(IPA)の発行している「非機能要求グレード」では、大項目として「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つを定義し、それぞれについてさらに詳細な項目とレベルを定義している。

また、日本情報システム・ユーザー協会(JUAS)が発行した「非機能要求仕様定義ガイドライン」では、非機能要件を「機能性」「信頼性」「使用性」(操作性や習得の容易さなど)「効率性」(計算資源・時間を効率よく使っているか)「保守性」「移植性」「障害抑制性」(障害の発生・拡大のしにくさなど)「効果性」(投資対効果など)「運用性」「技術要件」(システム構成や開発手法など)の10種類に分類して定義している。

製品やサービスに求める要件や調達条件などを決定するために必要な情報を集めるために発行するもので、一般的にはこれを元にRFP(Request For Proposal：提案依頼書)を作成し、具体的な提案の募集と発注先の選定に移る。

発注元の担当者や担当部門は発注先の専門事業者に比べて技術や当該分野の事情などに通じていないことが多くあり、自らの必要とするシステムや製品などをどのように定義・記述すればよいか決めかねる場合がある。

また、初めて発注するタイプのシステムや、Web関連など技術変化の速い分野で久しぶりにシステムを更新するような場合、取引したことのない業者に発注する場合などには、システムの構成要件や調達条件を記述するための基礎的な情報が不足していることがある。

このような場合にRFIが作成され、事業者から必要なシステムに関連する情報を提供してもらい、適切なRFP作成に役立てる。同時に、事業者に発注の可能性があることを知らせて提案の準備を促したり、RFIの結果を比較してRFPを発行するに足る能力があるか事前審査(スクリーニング)を行う場合もある。

RFIに盛り込む項目は業界や発注元によって様々だが、RFI作成の趣旨や目的を説明し、事業者の基本情報、提供している製品やサービスの概要、同種のプロジェクトの経験や遂行能力などを尋ねることが多い。事業者が何を答えれば良いか迷わないよう、問い合わせ事項を明確にするのが重要で、記入式の回答書の雛形(テンプレート)などを添付することも多い。

一般的なRFPには、まずシステム導入の目的や背景、現状の課題を記述し、今回の案件の範囲や目標、目安となるスケジュールや予算規模などを提示する。選定の進め方や日程、選定方針なども指定する。現行のシステムが存在する場合はその概況を記述したり、発注元企業の組織や事業、業務の説明を加えることもある。

これを踏まえ、提案を依頼したい項目を挙げていく。案件の内容によるが、システムの概要や要件、開発体制、開発手法、納品される成果物の構成、運用・保守の方法や内容、スケジュール、費用の見積もり、契約方法などを要求することが多い。

これまで情報システム業界では、口約束やあいまいな発注による開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに悩まされてきた。事前にRFPを通じて調達条件や契約内容を明らかにしておくことで、こうした混乱を未然に防ぐことができる。RFPに先立って必要な情報を集めるためにRFI(Request For Information/情報提供依頼書)を発行する場合もある。

製品やサービスを買い手・利用者に対して直に販売する事業者などを指し、自らがその製品を開発・製造しているとは限らない。開発元や製造元が別にいる場合はこれを「メーカー」(maker)と呼ぶことがある。また、買い手・利用者のことは「ユーザー」(user)「カスタマー」(customer)「クライアント」(client)などという。

インテグレータとベンダ

企業や官庁などから委託を受けて情報システムをオーダーメイドで開発・構築して販売する事業者を「システムインテグレータ」(SIer)というが、インテグレータから見てシステムの構成要素(機器や既製ソフトウェアなど)の供給元のことをベンダーと呼ぶ。

ある特定の企業の製品(コンピュータ本体や周辺機器、オペレーティングシステム、ミドルウェア、開発ツールなど)だけでシステムを構築することを「シングルベンダー」、複数の企業の製品を組み合わせて構築することを「マルチベンダー」という。

一方で、情報システムの発注者・利用者の側(ユーザー企業)からは、インテグレータのことをシステム全体の売り主として「ITベンダー」「システムベンダー」「開発ベンダー」などと呼ぶことがあり、ベンダーという語の使用や解釈には立場や文脈に留意する必要がある。

グリーン調達における環境への配慮には、製造・流通工程における二酸化炭素(CO₂)排出量の削減や省資源・省エネルギーなど主にCSR(企業の社会的責任)の観点から求められるものと、規制化学物質の削減や排除など法令適合(コンプライアンス)やリスク管理の観点から必要となるものがある。

グリーン調達調達を実施している企業などは独自の調達基準を策定し、調達元に対して特定の物質の使用を控えるよう求めたり、原料や部材に含まれる物質の種類や含有量の報告を求めたり、環境関連の認証・資格の取得を求めたりしている。

工業製品に含まれる化学物質の規制は国や地域により異なるため、グローバルに活動する製造業では生産国で問題にならない物質が販売国の規制に抵触するといった問題が生じることがある。各社がグリーン調達を推進するのは単にCSR対応や企業イメージの向上などのためだけでなく、こうした問題に対応するためでもある。

似た概念として、主に国や自治体、消費者などが最終製品を購入する際に環境負荷の低い製品を積極的に選ぶことを「グリーン購入」というが、グリーン調達をグリーン購入の同義語として用いることもある。

納品された製品の種類や型番、数量が発注時に指定した通りに揃っているか、仕様や品質の基準などを満たしているか、破損や汚損、欠陥、不具合、不良品が無いかなどを調べる。対象が機械やソフトウェアなどの場合は、実際に動かして挙動を確認する動作試験を行う場合もある。

一般的には検収に合格すると納品完了となり、代金の請求と支払いの手続きに進む。検収完了をもってその製品に関する責任は受注者から発注者へ移動し、後で不具合などが見つかっても発注者側の負担で解決するのが原則である。ただし、契約内容や両者の力関係により必ずしもその通りにならないことも多く、原因や責任、費用負担をめぐって争いになる場合もある。

情報システム開発の委託の場合は、受注者によるシステムの開発が終わり、発注者側に構築されたシステムに対して、発注側の人員や責任において稼働試験を行うことが多い。これを「受け入れテスト」(UAT：User Acceptance Test/ユーザーアクセプタンステスト)と呼び、これに合格すると納品されたシステムの検収完了となる。

検収が完了したら、発注者が受注者に検収書を発行する場合がある。法的に義務付けられている書類ではないが、トラブル防止や手続きを円滑に進めるために発行される。記載される項目としては、発注者と受注者、商品の名称や数量、金額、検収を行った日付や担当者、部署などがある。