□ IT投資評価の基本的考え方

□ IT投資評価の基本的考え方
 ITの技術革新のスピードはシステムの陳腐化を促します。業界標準にマッチしたITテクノロジーの採用は、企業間における双方向でのオープンな情報のやり取りの実現のためには不可欠なアプローチといえます。自社のコア技術,業務・技術ノウハウ,強みのオペレーションや経営資源の最適化を図るために,どのようなITテクノロジーを選択し,情報システムのインフラ基盤を構築していくべきかを検討しなければなりません。ITのニューテクノロジーの導入では、現行システムとの技術的な整合性の検討も重要です。情報システムの変更、改善では、大きな再投資が不要なITデザインが要求されます。投資効率を十分に評価・検討し、クライアント企業の業態、事業特性にマッチしたITソリューションを選択できる能力が必要です。 情報システムのRFP(Request For Proposal:提案要請)では、クライアントに対して、複数の代替案を提示することがポイントです。少なくとも3案からなるITデザインをクライアント企業に提示することが有効です。

 IT投資効果を検討する際,複数のプロジェクトの優先付けには,会計利益率法などが用いられます。さらに、現在価値法や回収期間法などの投資評価手法により,事業採算に支障を来さない投資判断を行うことがポイントです。現在価値法では,投資金額を利率で割り引いて現在価値に直して投資効果を算出します。回収期間法では,予想される効果金額が何年で回収できるかを算定して,回収のメドが立つ期間・年数と回収基準期間・年数とを比べて,投資の意思決定を行います。基本的には、投資判断はクライアント企業のトップが行い、SEは、そのための情報提供の役割を担います。

ITプロジェクト推進計画書の作成と要求定義のポイント
 SEは,プロジェクトマネジメントの視点から、システム化におけるユーザ・ニーズを明確にし,推進スケジュール,開発体制,予算などに関する計画を立て,関係部門,関係者,経営トップの承認を得ます。さらに、システム化における対象業務内容を明確にし,ユーザ・ニーズとして開発技術者に提示します。基本計画はシステム化計画,プロジェクト実行計画,要求定義の3つに作業工程が分かれます。
□書くべき必須項目をマーク
 ITプロジェクト推進計画書の作成では,プロジェクトの狙い・背景をまず,明確に記述することが重要です。なぜ,情報化を進めなければならないのか,事業性や競合他社の動向,業界の動向,技術革新の動向など,企業内外の環境を十分に把握したうえで,現状の問題点を整理し,全体最適化の発想で,戦略思考でもって,問題点の解決策を練ります。さらに,問題点を解決するためのITソリューションの選択では、投資効果,現状のITの整備状況,IT人材の情報システムの運用管理能力やスキルなどを見極めたうえで,明確なソリュ−ションの絵を描く必要があります。
 プロジェクトの推進では,後戻りはできないという覚悟のもとに、様々な問題や障害に万全の体制をもって望む必要があります。登山に、万全の準備をして望む場合でも、気象条件の変化や思わぬトラブルなどに遭遇して、戦略の練り直しが幾度も要求されるのが常です。プロジェクトでは関係者が多数関わり、チームワークのパワーを発揮できるかどうかにより、プロジェクトの成否が決まるといえます。このため、十分な意見調整と情報の共有が図れる仕組みを構築することが不可欠です。
プロジェクトの推進スケジュールは、関連部門,関係者,ITベンダーとの調整のもとに明確にし、理解を得て、周知徹底を図ることが大切です。ここでは,①情報化のための現状調査・分析,ユーザ・ニーズのヒアリング,続いて,②システム設計,開発,テスト,③システム導入・本格稼働・運用管理からなる日程計画を記述します。システム化計画の記述では、投資額対期待効果の評価,開発の体制及び規模,技術革新の動向調査だけでなく、推進上の問題点・課題・対策なども明記します。
 企画書には,以上のように,プロジェクトの推進における必須項目を明記するとともに、IT投資効果の明確化を図るため、経営的視点で目標効果の明細をできる限り金額,数値で記述することがポイントです。

RFP(RFP:Request For Proposal)
 クライアントが、ITベンダーにITシステム導入の見積もりを依頼する際には、提案依頼書(RFP:Request For Proposal)が作成されます。ITシステムの投資検討では、複数のITベンダーに対して、システムの概要や構成要件、調達条件を記述したシステム提案を依頼する文書(RFP)が必要となります。RFPには、ハードウェア及びソフトウェアの構成、サービス内容、依頼事項、保証用件、契約事項などを明記します。
 
□要求定義のポイント
 要求定義ではシステムに反映すべきユーザの要件を明確にします。システムが持つべき機能,性能,運用管理要件やハードウェア,ソフトウェアへのユーザ・ニーズを集約化します。
  
 要求定義書では,次の項目を満たす必要があります。外部設計では、ユーザの視点からソフトウェアの仕様を決定します。画面や帳票などの仕様を明確にすることが目的です。業務で要求される機能や画面,帳票などのヒューマン・インタフェースのニーズを明確にします。

システム開発の手法を理解する
 システム開発では、ユーザのニーズをシステム化に反映するため,ムの開発に参画して,クライアント、ユーザ
及びクライアント情報部門と十分なコミュニケーションを図り,一体になって進めます。基幹業務システムの開発
では,開発の手順をモデル化したものとして,ウォータフォールモデル,プロトタイピングモデル,スパイラルモデ
ルの3つの開発モデルがあります。迅速な開発手法としてはRADがあります。
 ウォータフォールモデルでは,システムの開発の上位フェーズから下位フェーズに向けて,前工程の成果と次工程
に引き継ぎながら,順次開発を進めていきます。

基本計画―>外部設計―>内部設計―>プログラム設計―>プログラム開発―>テスト―>運用・保守

 作業のフェーズは,基本計画,外部設計,内部設計,プログラム設計,プログラミング,テストからなります。各工程ごとに成果物の検証作業が組み込まれす。これにより,前工程に戻るのが困難であるという欠点を防ぐことができます。ウォータフォールモデルによるシステム開発では,単体テスト,統合テスト(モジュール間のテストであり,結合テストともいう),システムテスト(システム全体の機能テストや処理時間,処理能力をチェックする性能テストであり,総合テストともいう),承認テスト(検収時に行うテスト),運用テストがあります。
 プロトタイピングモデルでは,開発段階で試作品(プロトタイプ)を作って,エンドユーザのニーズを十分に確
認しながら開発を行います。試作品の結果を以降のシステム開発工程に反映できます。エンドユーザに画面や帳票
のイメージを与えながら開発者と一体になって要求分析と基本設計を行います。
スパイラルモデルでは、大規模開発向きのウォータフォールモデルと小規模開発に向いているプロトタイピングモデルの長所を取り入れています。この手法では、システムの一部の開発から始め,サブシステムごとに開発し,発展的に成長させて全体のシステムにつなげいきます。通常、開発工程のリスク管理に重点が置かれ,ユーザの要求定義のステップでプロトタイピングモデルを用います。
 RAD( Rapid Application Development)では,短期間でアプリケーション開発を行うことができます。①キックオフミーティング、②要求定義、③外部設計、④開発、⑤導入のステップからなります。RADでは、特に、外部設計において、プロトタイピング手法を用いて、ユーザ・ニーズを明確にし、外部仕様を効率的にすばやく確定するところに特徴があります。開発のステップでは、CASEツールなど、各種のツールやソフトウェアパッケージを活用し、短期間の開発を実現します。プロトタイピングの開発では、ユーザの参画により、効率的なユーザ・ニーズの吸収を図ります。
□開発規模と生産性の評価
 情報システムの開発規模を表す項目としては、画面の数、帳票の数、端末の数、プログラムの数、プログラムのステップ数、開発工数などがあります。情報システムでは、限られた人員、予算、日程の制約の中で、当初の目標を満足できる開発を進める上で、開発の生産性の評価が重要になってきます。開発の生産性は、開発規模/開発工数 により、計画・実績の対比を行うことで評価できます。例えば、①画面の数/開発工数、②プログラムの本数/開発工数、③ステップ数/開発工数などで、開発の生産性の実績値、及び計画値を求め、差異を把握して評価します。
■ システム化の各種アプローチ
システム化では、システムを一から個別に開発するアプローチを採用せずに、ERPソフトウェアパッケージや、ASPなどを活用して、短期決戦型で低コストを狙う選択肢もあります。ここでは、スーパーSEとしてマークしておくべき基本的な開発のパターンを紹介します。
ERPとプロトタイピング手法
ERPソフトウェアパッケージによるシステム化では、ERPが本来備えている標準機能ではユーザ・ニーズを満たせない場合、プロトタイピングの手法が採用されます。システムの部分ごとのプロトタイプ(試作品)の評価を操作性や機能性などの面からエンドユーザによって行い、改善すべきところは作り直すというような一連のステップを繰り返して、ユーザ・ニーズを具現化していきます。
 プロトタイピングでは、作り直しが容易であるという手軽さに甘えて、ユーザ・ニーズの見極めと要件定義があいまいなまま作り直しを繰り返すと、プロトタイピングの開発コストが膨らみ、予算と納期のオーバーという事態に陥ることになりかねません。必要機能を明確に絞り、客観的な評価基準を明確にしてユーザと一体でプロトタイピングに取り組むことが重要です。ERPソフトウェアパッケージでは、当初の見積もり金額が開発完了後、3倍に膨らんでいたといった事例もよくあります。クライアント企業の現場の実態を十分に分析・調査し、パッケージの基本コンセプト、詳細機能を十分に確認し、関係者に満足な理解を得たはずだと思っても、ふたを開けてみると開発コストはいつのまにか膨大なものになっていたということに遭遇するリスクが、ERPの導入プロジェクトでは起こり得るということを忘れてはならないでしょう。

ERPソフトウェアパッケージの導入では、クライアント企業の実態にマッチしたシステム化を図るためには、ユーザ・ニーズの個別仕様をシステム化に盛り込む必要があります。
 カスタマイズは、新規機能の追加が必要なアドオン(機能追加)ならびに、機能修正が発生しないパラメータ設定、及び、パッケージ自体の機能修正を図るモデフィケーション(機能修正)から構成されます。
 アドオンでは、パッケージの持つ機能がクライアント企業のニーズを満足できない場合に追加機能の開発作業と追加コストが発生します。
 モデフィケーションでは、本来ERPソフトウェアパッケージに備わっている標準的な機能の修正を加えるために、プログラムやテーブルの変更を実施します。ここで注意しなければならないのは、安易にモデフィケーションを勝手に行うと、供給側のITベンダーからの機能サポートやバージョンアップサービスを受けられなくなるケースが多い点です。

図解入門 3分でわかるITエンジニア・PM・SEのための能力開発の極意: IT戦略論シリーズ

図解入門 3分でわかるITエンジニア・PM・SEのための能力開発の極意: IT戦略論シリーズ