2007 年 3 月

経済産業省委託調査

（社）日本情報システム・ユーザー協会

企業におけるＩＴ投資の利活用が適正に行われるための環境調査事業

ＩＴ投資価値評価に関する調査研究

（ＩＴ投資価値評価ガイドライン（試行版）について）

＜目次＞ はじめに ................................................................................................................................................................................................... 1

1．経営における IT 投資マネジメント............................................................................................................................................. 3 1．1 経営課題に対する IT 投資の位置づけ .......................................................................................4 1．2 IT 投資の意思決定、評価体制 ...................................................................................................5

2．プロジェクトにおける IT 投資価値の評価 ............................................................................................................................... 7 2．1 プロジェクトにおける IT 投資評価の現状と課題 .....................................................................7 2．2 IT 投資評価方法と IT 投資評価の現状 ....................................................................................11 2．3 プロジェクトの評価 ................................................................................................................24 2．3 プロジェクトの評価 ................................................................................................................25 2．4 構想・企画段階における IT 投資評価（事前評価 1） .............................................................29 2．5 開発実行段階における IT 投資評価（事前評価 2）.................................................................50 2．6 開発完了後の IT 投資評価（事後評価）..................................................................................82 2．7 （参考）新システム稼動開始の承認 .......................................................................................92

3．まとめ................................................................................................................................................................................................. 93

4．参考資料 .......................................................................................................................................................................................... 95 4．1 「ＩＴ投資の見える化」についての IT 部門長インタビュー、CIO 座談会の結果 .................95 4．2 ユーザー満足度調査 ................................................................................................................96 4．3 生産性環境変数評価表 ........................................................................................................... 111

1

はじめに

今日、企業経営は IT 抜きに語ることが出来ない。企業内においてはあらゆる業務プロセスにシス

テムが実装され、かつネットワークの高速・大容量化の進展とともに、企業間、企業と個人間を結

ぶコンピュータシステムが構築されつつある。経営判断にあたり、膨大な情報を処理するためにシ

ステムは必須不可欠のものであり、新しい事業の企画にあたっても IT 利用の巧拙が成果を大きく左

右する。また、IT への依存度が高ければ高いほど災害・セキュリティなどのシステムリスク対策上，

経営としても IT への対応を求められている。即ち、IT をいかに駆使し統制するかという IT 戦略は

経営戦略といっても過言ではない。

一方、IT は、その技術的な難解さ（システム部門が説明責任を十全に果たしていない面もあるが）

等のため経営から見た場合、IT 投資の判断が非常に困難になる場面も少なからず存在する。また、

ＩＴ投資のあり方も SaaS（Software as a Service）・ASP(Application Service Provider)の出現等

多様化しており、それらの評価がますます困難になってきている。

IT 投資が伝統的な機械化・効率化投資からセキュリティ対策・基盤整備投資など定量的な効果を

計りがたいものに変化していること、長期的な視点に立ってＩＴ投資を評価しなければならないこ

とも困難さを加速させている。

これまで、IT 投資に対する効果をどのように計測し評価するかという研究はさまざまなところで

行われており労作も少なくない。ただ、これまでのそれは、経営者が自ら行うものとしては実務的

すぎるものが多い。

本ガイドラインでは、「必ずしもＩＴのプロでない経営者が、IT 投資をいかに捉えるか」という

マネジメントの重要ポイント、および経営者が新規投資を評価する場合の重要ポイントの観点から、

他のＩＴ投資価値評価に関する研究成果を再構成し、達成度合を図るチェックリストと改善のヒン

トを提供することをねらいとしている。

1 章では、「経営における IT 投資マネジメント」について、「経営課題に対する IT 投資の位置づ

け」「IT 投資の意思決定、評価体制」という 2 つの観点から重要ポイントを挙げている。

2 章では、個別のプロジェクトにおける IT 投資価値をどう評価していくか、構想・企画段階、開

発実行段階、開発完了後、それぞれの段階において経営の観点から確認すべき重要なポイントとそ

の方法について解説している。

何よりも重要なことは自らの IT 課題すなわち経営課題認識である。協力いただいた委員に感謝す

るとともに、本ガイドラインが多くの方に活用されることを期待したい。

（社）日本情報システム・ユーザー協会

IT 投資価値評価検討委員会 委員長 中津 伸一

2

IT 投資価値評価検討委員会（所属・役職は 2007 年 3 月時点）

検討委員会

委員長 中津 伸一 新日本製鐵㈱ 執行役員業務プロセス改革推進部長 委員 鵜飼 保雄 荏原製作所㈱ ＩＴ企画室参事 委員 大塚 順三 日本放送協会 総合企画室〔情報システム〕統括担当部長 委員 岡崎 猛 東京ガス㈱ ＩＴ活用推進部・ＩＴ品質マネジメントグループ

委員 岡本 裕之 小田急電鉄㈱ グループ経営企画本部 IT 戦略部（情報システム）参事 プロジェクトマネージャー

委員 加曽利 勝 プロミス㈱ 執行役員ＩＴ推進部長 委員 鈴木 敏廣 リコー㈱ ＩＴ／Ｓ本部 ＩＴ／Ｓ企画室室長 委員 武田 篤典 伊藤忠商事㈱ IT 企画部 IT 戦略チーム

委員 久井 敏次 東京海上日動火災保険㈱ ＩＴ企画部次長 兼 企画室企画グループリーダー

委員 藤原 章一 リクルート㈱ 執行役員 委員 水落 直樹 ＫＤＤＩ㈱ システム企画部課長補佐

事務局

細川 泰秀 （社）日本情報システム・ユーザー協会 専務理事 三木 徹 （社）日本情報システム・ユーザー協会 事務局長 佐藤 亘 （社）日本情報システム・ユーザー協会 事務局

オブザーバー

鍜治 克彦 経済産業省商務情報政策局情報処理振興課 課長 石川 浩 経済産業省商務情報政策局情報処理振興課 課長補佐 安藤 崇雄 経済産業省商務情報政策局情報処理振興課 係長

3

1．経営における IT 投資マネジメント

企業経営に寄与する IT 投資をしていくためには、経営者が IT 投資をいかに捉えるか、IT 投資に

係る体制などのマネジメント体制をどのように整備していくかは非常に重要である。

本章では、「経営課題に対する IT 投資の位置づけ」「IT 投資の意思決定、評価体制」それぞれの

マネジメントの重要ポイントをチェックリストとして挙げ、解説を行っている。

図表 1-1 経営における IT 投資マネジメント チェックリスト

（1） 経営課題に対する IT 投資の位置づけ

評価

できている← →できていないわから

ない

①経営トップが IT を経営改革・事業改革における「付加価値創造」の

源泉・ツールと位置づけ重視している 4 3 2 1 0

②IT 戦略あるいは（中期的な）IT 投資計画の策定にあたり、経営戦

略が十分に反映されている 4 3 2 1 0

③IT 戦略あるいは（中期的な）IT 投資計画を経営トップレベルで十分

議論している 4 3 2 1 0

④経営トップ自らが、IT 戦略・方針を明示している 4 3 2 1 0

⑤IT 部門から経営トップへ、経営戦略構築に必要な情報が適宜上げ

られている 4 3 2 1 0

⑥CIO もしくはそれに準じる人材の育成が十分留意されている 4 3 2 1 0

（2） IT 投資の意思決定、評価体制

評価

できている← →できていないわから

ない

①IT 投資にかかわる意思決定および評価する機関が設置され、その

構成員に過不足がない 4 3 2 1 0

②決裁レベルが明確になっており、経営レベルで意思決定する案件が

明らかになっている 4 3 2 1 0

③適切な事前評価と事後評価のタイミングが定められ実施されている 4 3 2 1 0

④システム費用は利用部門に適切に配賦されている 4 3 2 1 0

⑤IT 投資を実施するにあたり、必要な人材の確保・育成ができている 4 3 2 1 0 ⑥（該当する場合）アウトソーシング会社の経営管理が適切になされ

ている 4 3 2 1 0

⑦IT 投資の全体水準について明確な方針を持っている 4 3 2 1 0 ⑧IT 投資の内訳について適切なカテゴリーを設け、そのポートフォリオに

ついて明確な方針を示している 4 3 2 1 0

⑨カテゴリー別に適切な評価尺度を持っている 4 3 2 1 0 ⑩購買について、ハード・ソフト・ネットワークを提供するベンダーの管理

などを含めて明確な方針を持っている 4 3 2 1 0

4

1．1 経営課題に対する IT 投資の位置づけ

経営課題に対する IT 投資の位置づけとして重視すべき点として、以下の 6 点を挙げる。

①経営トップが IT を、経営改革・事業改革における「付加価値創造」の源泉・ツールと位置づけ重視している

今日、情報通信技術の進歩は目覚しいものがある。とりわけ、オープン化・ウェブ化の進展に伴

い、従来考えられなかったビジネスモデルの創出、あるいはこれまで出来なかった業務プロセスの

改革・構築が可能となってきた。また、事業継続管理（BCM）・セキュリティ対策などのリスク管

理上も IT への対応が求められている。今や、IT を使いこなすことは経営として必須不可欠となっ

ている。

② IT 戦略あるいは（中期的な）IT 投資計画の策定にあたり、経営戦略を十分に反映させている

③ IT 戦略あるいは（中期的な）IT 投資計画を経営トップレベルで十分議論している

上述の状況から、IT と経営戦略は表裏一体のものであり、IT への経営資源投入には経営の意思・

経営戦略を十分に反映させる必要がある。IT 戦略は経営戦略の極めて重要な一部、あるいは経営戦

略そのものである。経営の場で議論されない IT への資源投入計画は経営計画ではないと言えよう。

④ 経営トップ自らが、IT 戦略・方針を明示している

経営戦略の表明と同様、IT についても経営者自らがリーダーシップを発揮する必要がある

⑤ IT 部門から経営トップへ、経営戦略構築に必要な情報が適宜上げられている

経営者は必ずしも IT についての専門家である必要はないが、④で述べたリーダーシップ発揮のた

めにも、自社の IT に関する大きな課題、IT の 新の動向など経営戦略構築に必要な情報を自社の

IT 部門から上げさせることが重要である。

⑥ CIO もしくはそれに準じる人材の育成が十分留意されている

企業統合など置かれた環境や課題の大きさによっては、経営者自ら CIO を兼ねる場合もあるが、

多くの場合 CIO もしくはそれに準じる人材を選びその任にあたらせることになる。CIO の資質は経

営への影響が極めて大きいことから、その任命はもちろんのこと人材育成に十分留意する必要があ

る（情報通信技術の進歩がめざましい今日、CIO は社内外で IT のキャリアパスを踏んだものもしく

は IT に対するリテラシーの高いものが望ましい）。

5

1．2 IT 投資の意思決定、評価体制

IT 投資の意思決定や社内の IT 投資の評価体制を整備するにあたって、重要なポイントは以下の

通りである。

① IT 投資にかかわる意思決定および評価する機関が設置され、その構成員に過不足がない

IT に関する意思決定・評価のための社内機関は、委員会もしくは会議などの名称を問わず多くの

企業に存在すると思われるが、企画・財務の専門家、システム技術の専門家（場合によってはアウ

トソーシング会社）に加え、現業部門が入っているか、その構成員をどうするかは重要である。

現業部門がメンバーに入ることにより、当該システムに対する当事者意識、期待効果を達成しよ

うとする責任感が高まることとなる。

② 決裁レベルが明確になっており、経営レベルで意思決定する案件が明らかになっている

投資額・重要性などの基準を設けるなど、経営として自ら意思決定する投資案件のレベルを明示

しておく必要がある。任せるべきものは任せるのであるが、全体感は常に把握しておく必要がある。

③ 適切な事前評価と事後評価のタイミングが定められ、実施されている

IT 投資のマネジメントにあたっては、事前評価とともに事後評価を行うことは極めて有効であり、

事後評価を実施する項目、そのタイミング、あるいはその期間をあらかじめ決めておく必要がある。

これによりシステムの設計部門・利用部門双方に一定の緊張感を与えることができる。そして当該

システムの事後評価の結果は、次の投資にあたって貴重な反省もしくはサクセスストーリーとして

PDCA サイクルが回ることとなる。

④ システム費用は利用部門に適切に配賦されている

システム投資はそれが実現するとコスト化するが、それをある一定の納得的なルールに基づいて

利用部門に配賦すると、投資の起案にあたって利用部門に自律的な責任感を植え付けることができ

るとともに、当該システムを使いこなし、効果を具現化する契機となる。また、不要あるいは使用

頻度の少ないシステムの廃棄などを通じてシステム資産の圧縮にも資する。

⑤ IT 投資を実施するにあたり、必要な人材の確保・育成ができている

企業は人であり、 終的に仕事のでき具合は人材にかかわっているが、システムもその例外では

ない。システム人材をどこまで自社で抱える必要があるのか、アウトソーシングの考え方は各社そ

れぞれであるが、少なくとも戦略・企画と検収は自社の業務であろう。その戦力確保と人材育成は

極めて重要である。人材育成にあたり、現業部門の実務経験は貴重であり、また、大規模なシステ

ム開発に関わることも、その人を大きく成長させる経験となる。

⑥ （該当する場合）アウトソーシング会社の経営管理が適切になされている

アウトソーシング会社に任せる範囲は今のままでよいのか、そもそもアウトソーシング自体がど

うかという議論が盛んな今日、当該会社をいかに管理するかは経営上重要である。

6

すなわち、アウトソーシング会社の競争力・人材は親会社の競争力・人材だからである。一定の

収益と親会社に対する 新のシステム技術を踏まえた企画・提案、そして安定的なシステム開発・

維持･運用を同時追求させるにはいかにすべきか。グループとして共通の利益の追求という目標の共

有化がもっとも重要であろう。

⑦ IT 投資の全体水準について明確な方針を持っている

IT 投資の総額をどの水準にするかは、自社のシステム課題に対する認識、次の事業戦略、 新の

IT の動向、同業他社の状況などを踏まえた経営戦略の問題である。その際、他社とのベンチマーキ

ングは 1 つの参考になる。

⑧ IT 投資の内訳について適切なカテゴリーを設け、そのポートフォリオについて明確な方針を示している

IT 投資のカテゴリーをどうするか、またそのポートフォリオをどうするかも経営方針の表明に他

ならない。情報セキュリティが経営としての 大の課題であれば、それが当該企業の戦略投資にな

ることもあり、社運をかけた新しい事業への進出に伴うシステム開発が戦略投資になる会社もある

だろう。したがって、カテゴリーとそのポートフォリオは各社ごとに異なる。

⑨ カテゴリー別に適切な評価尺度を持っている

それぞれのカテゴリー毎に、事前評価・事後評価する項目と尺度が必要である。

従来の業務効率化を目的とした投資であれば、投資によって具現化する効果（一次効果と二次効

果の問題はあるが）を現在価値に置き換え ROI を計算する手法もあれば、投資回収年数で判断する

場合もある。ただし今日、投資判断に迷うケースが増加しているのは基盤整備的な投資、あるいは

戦略的な投資の場合が考えられる。その際、投資をしなかった場合のリスクは何であるのかを問う

のは有効であろう。さらに、定量的な効果と定性的な効果が混在する場合、定性的な項目について

KPI としてフォローする手法も有効である。

⑩ 購買について、ハード・ソフト・ネットワークを提供するベンダーの管理などを含めて明確な方針を持って

いる

IT に対する資源投入にあたって、その分母としての投資額自体も十分把握しておく必要がある。

したがって、ハード・ソフト・ネットワークのベンダー管理は重要である。そのベンダーの競争力・

信頼性（安定性）・企画提案力などを総合的に評価しておく必要がある。アウトソーシングの如何に

かかわらずベンダーに対する発注能力は担保する必要がある。

7

2．プロジェクトにおける IT 投資価値の評価

2．1 プロジェクトにおける IT 投資評価の現状と課題

企業の競争力強化のため、毎年多くの金額が IT 投資に振り向けられている。

企業において、ある目的を持って投資を行えば、その成果は当然問われるはずであるが、IT 投資

についての評価は必ずしも実施されているとはいえない状況である。

「予算令達の承認は上がってくるが、進捗の報告も少ないし、結果の報告はほとんど上がってこ

ない。IT 部門とは不思議な部門だ」

と思っている経営者は多い。また投資案件が起案されてきても、経営者は、その案をどのように

考え、判断すれば良いのか悩むことになる。

対策は 4 項目ある。第一に「案件内容を理解するための基礎を作ること」であり、第二に、「案件

を正しく理解し対応すること」、第三に「起案の問題を見抜くためには、一歩先を行く理想像を考え

ること」 後に、「IT 投資評価を実際に実施するための諸施策をとること」である。

以下順を追ってこの問題を論じてみたい。

（1） 案件内容を理解するための基礎を作ること（コミュニケーションの基礎を築く）

「予算審議段階で内容を聞いても、SCM、SFA、OSS、SOX などの 3 文字英略語が氾濫し、理解

できない。もっと素人にも分りやすく説明してくれないものか」と悩んでいる経営者はたくさんい

る。

このような 3 文字英略語は不思議な性格を持っている。お互いに知っていれば確かに説明は簡単

になるが、知らない人に説明する場合、非常に説明が難しく時間もかかる。聞く側も、1 つ 2 つな

らば「それはどういう意味なのか」と聞くこともできるが、三つ目くらいからは聞きにくいのが心

情である。「聞くは一時の恥、聞かぬは末代の恥」なる諺があることは知っていて、知らないことを

尋ねることは、何も恥じることではないと割り切っていても、三つ目からは尋ねにくいことである。

これを何とかしたいという経営者は多い。対策を講じている例を紹介する。

ある経営者は、まず CIO に IT に詳しくない営業部長を任命し、その営業部長が理解したならば、

自分にも分りやすく説明してくれるだろうと期待した。なお、「国内 CIO 実態調査（経済産業省委

託事業（（社）日本情報システム・ユーザー協会（JUAS）実施））」によると、日本企業における CIOの 80％は IT の経験がないことが報告されているが、彼らは、企業を引っ張る力、関連部門をリー

ドできる力を持っている。この場合も営業部長出身の CIO はわかりやすい説明を経営者にして、社

内の業務改革をリードしている。

また、別のある経営者は、役員会での IT の議題は、IT の素人である経営企画部長が IT 部長に替

わって説明するように命じた。経営企画部長が分かったならば、経営陣にも理解しやすいように説

明してくれるだろうとの期待が込められていた。実際に経営企画部長の説明はきわめて分りやすく、

皆納得した。

8

また別のある社長は役員会に出す IT 部門提出の資料に、分らない箇所は赤鉛筆で×の字を書き、

すべて訂正させてから役員会に提出させた。

経営の言葉で ITの問題を語ることができるのは 1つの技術であり、経験なくしては取得できない。

そのためには IT 部門からの出身者の中にこの経営の言葉で IT を語ることができる人を確保する必

要がある。

そのような人物がいればその人を抜擢すればよい。しかし、長く IT しか経験していない SE の中

にこの要素を備えている人物は残念ながら少ない。それならば、将来経営者を任せても良いくらい

の人物を経営企画、営業、工場の中から抜擢して IT 部門を経験させておくという手もある。

次の CIO を誰にするか悩み、今いる中で 適な人物を選抜するのも 1 つの方法であるが、まず、

CIO 候補者を選定し長期的視野を持って育成することが望まれる。中小企業の社長の中には、息子

の二代目を若い頃に IT 担当に任命し将来を考えた育成を実施している人もいる。1 つの案である。

（2） 案件を正しく理解し対応すること

上がってくる IT 案件を経営者が決済することは、｢総合経営活動を承認する｣ことである。予算以

上に社員のパワーをそのプロジェクトにつぎ込み、場合によっては企業の組織文化を変革すること

になる。IT 案件を説明する起案者は、「この案件を早期に決裁しないと大変な問題が起こる」がご

とく説明することがあるが、案件を正しく理解するために、「何が問題なのか、解決策は他にないの

か」など、様々な難問を起案者に浴びせなければならない。

社員はどこかの組織に位置づけられ、必ず、①組織の壁、②経験の壁、③予算の壁、④時間の壁、

という 4 つの壁に囲まれている。この 4 つの壁を持っていないのは経営者だけである。

① 組織の壁

社員は必ずどこかの組織に属しており、自分の所属する組織内から問題を捉えがちである。解決

すべき経営課題は、一部門の問題なのか、全社に影響を与える問題なのか、ひょっとしたら関連企

業を含めて再考させればもっと異なる解決策があるかもしれない。組織を作ったのは経営者であり、

それを壊せるのも経営者である。組織の壁を破った見方ができるのは経営者である。

②経験の壁

社員は経験を積んで成長するが、経験は常に中途であると考えた方が良い。

幅の広い見方を社員に期待するのはよいが、限界があることを認識しておく必要がある。もっと

違った目で見て発想をした方が良い場合は積極的に指導しないといけない。

システムは、業務システムと情報システムから成り立っている。重要なのは業務システムである。

話をじっくり聞けば、必ず何らかの発想の転換を指示できるはずである。少なくとも重要な業務シ

ステムの改革のポイントの是非は判断できるはずである。

9

③予算の壁

社員は会社の予算を念頭においた使い方しか考えない傾向があるが、経営者は自分の財布、すな

わち会社全体のキャッシュを念頭において考える。逆に担当者であるからこそ予算枠を考えケチな

案になっている場合もあり、もう少し予算枠を大きく与えればもっと良い案を出してくることも考

えられる。IT を使わない問題解決策だってありうるが、経験の少ない担当者にはこの発想は難しい

かもしれない。

④時間の壁

現在の IT 技術レベルで本当に問題解決が図れるのか、もっと時間を置いて数年後に実施したら周

囲の環境や技術も進歩して、かえって楽に成果を得ることができるかもしれない。「起案者にはすま

ないが、ここは保留にしておき、再度この案が提出された場合には決断しよう」などの総合判断が

できるのは、経営者である。

（3） 起案の問題を見抜くためには、一歩先をゆく理想像を考えること。

別の解決策を提示できるわけではないが、「なんとなく理解し難い、なんとなくピントこない」と

経営者の勘が働くことがある。この場合は、理想像を考えさせるために次のような質問をしてみて

はどうだろうか。

「もっと迅速に処理できる方法はないのか」 「もっと高い品質にできないのか」 「もっと顧客満足を得る案はないのか」 「もっと効果をあげる案はできないのか」 「他社はどのような解決策を採用したのかその上のレベルとは何か」 「もっと楽に開発し、移行できる方法はないのか」

このように「もっと・・・」をつけた質問を浴びせ、社員の総智を絞ってもらう。この効果を高め

る方法への努力は、企業の競争力の強化に結びつく。

（4） IT 投資評価を実際に実施するための諸施策をとること

経営者が理解し難いことの 1 つに IT 部門のプロセス志向がある。

開発におけるそれぞれのフェーズで、しなければいけないことを指示している「ソフトウェアラ

イフサイクルプロセス」が標準化されており、それに頼っているのが IT 部門やソフトウェア産業で

あるが、システム開発における品質目標は明確になっていない。各プロセスで実行することは決め

られてあるが、目標値はない。

一方、企業の商品はすべて顧客を相手に品質や価格で勝負している。一定の品質、原価で競争力

を維持しているのが業務部門であるが、IT 部門は歴史が浅いこともあって目標値を持っていない、

あるいは明確に示せない場合が多い。定められた目標のプロダクト（製品）を作るためにプロセス

を守っている業務部門に対し、IT 部門やソフトウェア産業は、プロセスに始まりプロセスに終わっ

ている傾向がある。

10

「紺屋の白袴」になっているのを改善できるのは経営者である。「何をすれば、過残業をしないで、

安定品質のシステムを提供できるのか」を問うて欲しい。

効果の測定はもっと難問である。IT インフラ基盤の投資に対する効果を数値で示すことは難しい。

社員を採用する際、机を買い文房具を用意する代わりに、パソコンを準備する時代になっている

が、その効果を定量的に測れと言われても難しい。

戦略的テーマ、競争相手と勝負するための IT 投資案件が増加しているが、これをどのようにして

評価すればよいのか。もっと効果を出して欲しい、もっと上手い活用方法を生み出して欲しいと願

うのが経営者である。

この問題を解くのが本報告書の中心テーマである。上記の 4 つを念頭に、各フェーズでの IT 投資

評価について考えてみよう。

11

2．2 IT 投資評価方法と IT 投資評価の現状

2．2．1 IT 投資評価の方法

IT 投資効率は、一般には以下のとおり表される。

難しいのは分子で効果額が明らかにならないプロジェクトが多いことである。そのために図表

2-2-1 の手法が活用されている。

図表 2-2-1 IT 投資評価の手法

手法 概要

ROI Return On Investment 投資利益率

効果金額を投資額で割ったもの

一般的に、投資回収年数は2～10年程度になる。 近のシステム再構築案件は5年程度の

改修年数で承認・開発し実際は 10～20 年活用する場合が多い

KPI Key Performance Indicator 効果が業務スピードの向上や顧客満足度の向上などの場合は

効果を金額換算し難いので、その代わりに業務処理時間が 1 日から即時になるとか、顧客

満足度が何％向上するなどの評価目標になる

BSC（Balanced Score Card）もこの要素を持っており、財務、顧客、業務プロセス、人材育成

の 4 視点から評価する

ユーザー満足度 システムの利用者側の満足度を問う方法である。

システム利用者の満足度は「工期、品質、システム開発の生産性、利用容易性」で確認し、

開発責任者の満足度は「開発マナー」で確認し、プロジェクト責任者の満足度は、KPI を含め

た効果、業務改革度、開発の協力度などの項目で測定する。一般的には、アンケート方式

あるいはインタビュー方式が用いられる。

他社比較

（ベンチマーク）

機能内容、売上高投資金額比、従業員あたりの投資金額などを他社と比較する方法

機会損失 このプロジェクトを実施しない場合の、他社との競争力を比較すること

戦略的プロジェクトの投資評価可否の場合に使用される。

将来性を含め、システムの効果を問うことが多い。

NPV Net Present Value 正味現在価値 / 純現在価値

将来のキャッシュ・インフロー（現金流入）の現在価値から、投資であるキャッシュ・アウトフロ

ー（現金流出）の現在価値を差し引いた正味の金額。投資（金融投資および事業投資）の採

算性を示す指標で、投資判断の も一般的な基準となっている。

簡単にいえば DCF（Discounted Cash Flow 法）をベースに「回収額－投資額」を算出したもの

で、その投資案件で得られる正味の価値（金額）のことである。NPV が大きければ大きいほ

ど経済価値が大きく、NPV がマイナスであれば採算が得られないことを示す。

ＩＴ投資効率＝効果額÷投資額

12

また、IT 投資は、大きくは以下の 3 つのタイプに分けることができる。それぞれのタイプ別に適

した評価手法が用いられている。

図表 2-2-2 プロジェクトのタイプ

タイプ 概要

インフラ型 かつて鉛筆と紙で仕事をしていた時代は終わって毎日パソコンと対話しながら情報を

入手し指示をする時代になった。

プロジェクトを起案する場合に、ハードウェアはそのプロジェクトだけで使用するだけで

なく、さまざまなプロジェクトでも端末機は活用される。したがって、端末機（パソコン）

は特別な場合を除いてプロジェクト予算からは除外される傾向になってきた。パソコン

購入費はインフラ投資として扱い、各プロジェクトのコスト負担に持ち込まないケース

が増えている。また、サーバー費用も各種プロジェクトが 1 つのサーバーを共同で活

用するケースが増えており、個別プロジェクトごとに負担させることに矛盾を感じるの

で IT 部門が一括して基盤整備として予算化する場合が多い。

しかし、ここ数年間はハードウェアの技術革新の効果を受け「従来の費用に比べて安

くなりますからインフラを更新します」の理論が通じていたが、セキュリティ投資などの

費用が増加しており、どこまで守りの投資を強いられるのか不満を感じている経営者

も多い。特に中小企業には負担感が高くなっている。

業務効率型 システム化によって業務効率を高め省力化を推進するためのプロジェクトで通常は省

力化効果を含めて ROI で評価される。人手作業を機械化した第一世代のシステム化

はこの効果が大きかった。基幹業務システムの再構築の時代に入ると普通のアイデ

アの出し方では、効率的な案の実現は難しくなってきている。

トップダウン型で「わが社の業務システムの体系化を考える」

「情報共有で生産性と業務の質の向上を図る」等の工夫が要求されている。

戦略型 IT が業務を効率化するツールから、企業の戦略を実現するためのツールへと変化す

る時代に入り、このタイプの投資が増加した。効果は ROI などの単純な評価方式は通

じなくなり、KPI、ユーザー満足度などでしか測定することが難しくなっている。

終的には企業あるいは対象事業部の営業利益で評価するしかないプロジェクト案

件である。顧客関係の強化により売上を増大するプロジェクト、IT の新しいツールを活

用したビジネスモデルにより市場拡大を図るプロジェクトなどさまざまなタイプがある。

このタイプのプロジェクトも使いこなすと利用者にとってなくてはならないシステムにな

り、投資は基盤案件化する性格を持つことになる。

13

2．2．2 IT 投資評価の現状

実際に企業ではどのように IT 投資評価が実施されているのであろうか。「企業 IT 動向調査 2007経済産業省委託事業（JUAS 実施）」の結果を見てみよう。

（1） IT 投資対象の現状と今後の方向性

IT 投資の計画を立案し、評価を行うにあたっては、カテゴリーを設け、そのポートフォリオにつ

いて明確な方針を示すことが必要である。

図表 2-2-2 は、IT 投資をインフラ型投資、業務効率型投資、戦略型投資の 3 つのカテゴリーに分

け、評価を行う手法について述べたものであり、JUAS により推奨されている。このようなカテゴ

リー分けを行った場合、どの分野が重点的に投資されているのか、「企業 IT 動向調査」では、現状

の投資タイプの比率と今後の方向性を質問している。

① 現状の投資タイプごとの比率

図表 2-2-3 は、IT 投資を、インフラ型投資、業務効率型投資、戦略型投資の 3 つのタイプに分類

した場合の現状の比率について回答を求めた結果である。回答を単純に平均したものが「単純平均」、

IT 投資金額を加味しその大小により重み付けをして平均値を算出したものが「金額加重平均」であ

る。

単純平均では、インフラ型投資 4 割、業務効率型投資 4 割、戦略型投資 2 割であった。この結果

は昨年とはほとんど変わりがなかった。

金額加重平均では、インフラ型投資が 33％、業務効率型投資が 28％であった。戦略型投資が 39％と、IT 投資の 4 割が戦略型案件に向けられている。

企業規模（売上高）別に投資の割合を算出したものが図表 2-2-4 である。企業規模（売上高）大

きくなるにつれてインフラ型投資と業務効率型投資の合計が減少し、戦略型投資が増加する傾向で

あった。

インフラ型投資については、ネットワークの整備・拡充やハード／ソフトの導入など、企業の規

模の大小に関わらず整備しなければならないものがあり、扱う量が多くなればなるほど単価が下が

り、コスト負担が相対的に減少する。このため大企業ほどインフラ整備の負担が軽くなり、整備が

進みやすく、多くの投資を業務効率型に振り向け、情報システムの構築により業務プロセスを改善

してきたのだろう。さらに経営戦略と IT 戦略の統合の流れの中で、経営戦略目標達成のための投

資・戦略型投資として情報システムの再構築に向けて重点的に投資していると思われる。

14

図表 2-2-3 カテゴリー別 IT 投資の比率

33.0

28.1

39.3

39.3

28.0

32.2

20.4

19.5

39.0

39.8

41.2

40.3

0% 20% 40% 60% 80% 100%

06年度(n=582)

05年度(n=776)

06年度(n=582)

05年度(n=694)

単純

平均

金額

加重

平均

インフラ型 業務効率型 戦略型

図表 2-2-4 企業規模別 IT 投資カテゴリーの割合

46%

39%

37%

31%

47%

33%

37%

37%

29%

28%

36%

41%

37%

38%

37%

37%

32%

26%

28%

25%

17%

19%

26%

32%

16%

30%

31%

37%

43%

48%

0% 20% 40% 60% 80% 100%

10億円未満(n=8)

10億円～100億円未満(n=126)

100億円～1000億円未満(n=322)

1000億円～1兆円未満(n=103)

1兆円以上(n=22)

10億円未満(n=8)

10億～100億円未満(n=131)

100億～1000億円未満(n=402)

1000億～1兆円未満(n=128)

1兆円以上(n=18)

単純

平均

金額

加重

インフラ型 業務効率型 戦略型

15

② IT 投資の今後の方向性

図表 2-2-5 は、インフラ型投資、業務効率型投資、戦略型投資の今後の比率について回答を求め

た結果である。

インフラ型投資については、「不変」と回答した企業が も多く 50％、「増加」させる方向の企業

が 31％、「減少」させる方向の企業が 18％となった。経年的な変化を見てみると、「増加」させる意

向の企業が、30％（03 年度）→23％（04 年度）→24％（05 年度）→31％（06 年度）と過去 3 年

の減少傾向から増加に転換している。

業務効率型投資については、「不変」と回答した企業が 54％、「増加」させる意向の企業が 29％、

「減少」させる意向の企業が 16％であった。「増加」させたい企業は、36％（03 年度）→30％（04年度）→31％（05 年度）→29％（06 年度）と減っている。

戦略型投資については「不変」と回答した企業が 44％と半数を下回っており、「増加」させたい

企業が 52％と過半数を超え、「減少」させたい企業は 4％に留まった。「増加」すると回答した企業

は 59％（03 年度）→59％（04 年度）→56％（05 年度）→52％（06 年度）と半数以上ではあるが

減少傾向を示している。「不変」とする企業は 38％（03 年度）→37％（04 年度）→41％（05 年度）

→44％（06 年度）と増加傾向を示している。

企業規模別に見ると、企業規模に比例し、インフラ型投資と戦略型投資については「増加」する

と回答する企業が増えている。戦略型投資については、売上高 100 億円を境に、「増加」するとした

ものが半数を超え、1000 億円以上の企業ではその傾向が明確になっている（図表 2-2-6）。

一方、業務効率型投資についても、売上高 1000 億円を境に、規模が小さい企業では「増加」する

と回答した企業が「減少」すると回答した企業を 15－18 ポイント上回っているが、売上高 1000 億

円～1 兆円の企業で「増加」が 24％、「減少」が 27％、「不変」が 49％となっていて、1000 億円以

上の企業では、それぞれの企業によって方向性が 2 分されている状況と言える。

大企業では基幹システムの再構築など業務効率型の投資をある程度終了し、経営戦略と IT 戦略の

統合の流れの中で、投資先が経営戦略目標達成のための戦略型システムに向かっている様子が見え

る。

16

図表 2-2-5 年度別 IT 投資カテゴリーの今後の割合

図表 2-2-6 企業規模 別 IT 投資カテゴリーの今後の割合

31%

24%

23%

30%

29%

31%

30%

36%

52%

56%

59%

59%

50%

61%

56%

53%

54%

53%

53%

50%

44%

41%

37%

38%

18%

15%

21%

17%

16%

16%

18%

14%

4%

3%

4%

3%

0% 20% 40% 60% 80% 100%

06年度(n=729）

05年度(n=811）

04年度(n=850)

03年度(n=701)

06年度(n=713）

05年度(n=793）

04年度(n=837)

03年度(n=700)

06年度(n=695）

05年度(n=729）

04年度(n=792)

03年度(n=675)

イン

フラ

型業

務効

率型

戦略

型

増加 不変 減少

38%

28%

31%

34%

39%

15%

25%

33%

24%

25%

69%

38%

50%

68%

70%

46%

55%

50%

46%

50%

54%

65%

52%

49%

54%

23%

55%

47%

25%

26%

15%

17%

19%

20%

11%

31%

10%

15%

27%

21%

8%

4%

7%

3%

7%

0% 20% 40% 60% 80% 100%

10億円未満(n=13)

10億～100億円未満(n=152)

100億～1000億円未満(n=410)

1000億～1兆円未満(n=125)

1兆円以上(n=28)

10億円未満(n=13)

10億～100億円未満(n=146)

100億～1000億円未満(n=402)

1000億～1兆円未満(n=123)

1兆円以上(n=28)

10億円未満(n=13)

10億～100億円未満(n=141)

100億～1000億円未満(n=390)

1000億～1兆円未満(n=123)

1兆円以上(n=27)

イン

フラ

型業

務効

率型

戦略

型

増加 不変 減少

17

今後の IT 投資について業種グループ別にどのような特徴があるかを見たものが図表 2-2-7 である。

各業種グループで、それぞれの「増加」ポイントと「減少」ポイントの差を、インフラ型投資、業

務効率型投資、戦略型投資の別に示している。

インフラ型投資は業種群により も大きなバラツキを示した。重要インフラ系、素材製造で増加

傾向が強く出ている。一方、金融、機械等製造では増加をあまり見込んでいない。金融系ではポイ

ント差は 0 であった。

業務効率型投資は、3 つの投資タイプの中では増加傾向が も弱かった。インフラ型投資と比較す

ると、機械等製造でのみより強く増加傾向が出ている。商社・流通でもやや強めに増加傾向が出て

いる。

戦略型投資はどの業種群でも今後の増加を見込む企業の割合が圧倒的に多いが、重要インフラ系

で特に強い傾向が見られた。

3 つの投資タイプについて、重要インフラ系の増加傾向が強く出ている反面、金融の増加傾向が

も小さい結果となった。

図表 2-2-7 業種グループ別 IT 投資カテゴリーの今後の性向

0%

20%

40%

60%一次産業

素材製造

機械等製造

商社・流通金融

重要インフラ系

サービス系

インフラ型

業務効率型

戦略型

18

（2） IT 投資評価の実施状況

① IT 投資評価の実施状況

IT 投資に対して事前／事後評価をどの程度実施しているか、現状を聞いてみたところ、事前評価

を実施していると回答した企業は、「実施している」「一部実施している」を合わせて 61％となった。

ここ数年の推移を見ると前年の調査では足踏み状態／やや後退した感もあったが、2004 年度調査以

来の半数超となり、概ね増加傾向を示している（図表 2-2-8）。

事後評価を実施していると回答した企業も、「実施している」「一部実施している」を合わせて 53％となっており、2006 年度初めて過半数を超えた。こちらも、ここ数年の推移を見ると、足踏み状態

／やや後退した感もあったが、2006 年度は増加傾向に転じている。

企業規模別に見ると、企業規模が大きくなるにしたがって、事前評価／事後評価を実施している

企業が増えている（図表 2-2-9）。

事前評価については、2005 年度の調査では、1 兆円を超える企業ではすべての企業が事前評価を

実施していると回答したが、今回調査もほぼ同様の結果となった。

事後評価について、2005 年度は 10 億円未満の企業はすべての企業（10 社）が事後評価を実施し

ていないと回答した。今回調査では 4 割の企業（5 社）が「実施している」「一部実施している」と

回答している。

投資に対する評価を行なうことは、企業として必要な行動である。特に今後の方向として戦略型

投資を増加させるという企業が多い状況下で、投資評価の実施は企業規模を問わず重要な課題であ

る。

調査の結果より、IT 部門の事業運営姿勢が年々改善されていることが明らかになっている。

図表 2-2-8 IT 投資評価の実施状況

21%

17%

19%

13%

11%

9%

7%

6%

40%

35%

37%

34%

42%

33%

40%

35%

39%

48%

44%

53%

46%

58%

52%

59%

0% 20% 40% 60% 80% 100%

06年度(n=776)

05年度(n=914）

04年度(n=963)

03年度(n=842)

06年度(n=775)

05年度(n=913)

04年度(n=963)

03年度(n=841)

事前

評価

事後

評価

実施している 一部実施している 実施していない

19

図表 2-2-9 IT 投資評価の実施状況

11%

10%

16%

35%

59%

66%

4%

7%

8%

19%

22%

38%

31%

37%

46%

46%

33%

31%

33%

35%

46%

53%

59%

48%

58%

53%

37%

19%

7%

3%

62%

58%

46%

28%

19%

14%

0% 20% 40% 60% 80% 100%

100人未満（n= 45）

100～499人（n=356）

500～999人（n=153）

1000～4999人（n=166）

5000～9999人（n= 27）

10000人以上（n= 29）

100人未満（n= 45）

100～499人（n=355）

500～999人（n=153）

1000～4999人（n=166）

5000～9999人（n= 27）

10000人以上（n= 29）

事前

評価

事後

評価

実施している 一部実施している 実施していない

20

② IT 投資評価の実施基準

IT 投資の事前／事後評価を「実施している」あるいは「一部実施している」と回答した企業を対

象に、評価実施基準について聞いてみたところ、「一定金額以上の案件は評価を実施」している企業

が半数であった（図表 2-2-10）。

事前評価については、「一定金額以上の案件は実施」と回答した企業が約半数であった。また、「そ

の他の基準」と回答した企業が 16％あった。

事後評価については、「一定金額以上の案件は実施」と回答した企業が半数を超えたが、「その他

の基準」と回答した企業が 26％あった。

金額以外の基準として、利用ユーザー数の多い案件、年度重点投資上位ｘｘ位までの案件、年度

計画案件、金銭的な効果／定量効果のある案件、基幹系など主要機能を支援する案件、などが上が

っている。

図表 2-2-10 企業規模別 IT 投資評価実施ルール

35%

43%

32%

36%

34%

22%

37%

22%

13%

19%

49%

41%

52%

45%

59%

52%

37%

53%

54%

70%

16%

16%

17%

19%

7%

26%

25%

26%

33%

11%

0% 20% 40% 60% 80% 100%

全体(n=462)

100億円未満（n=74）

100億円～1000億円未満（n=241）

1000億円～1兆円未満（n=118）

1兆円以上（n= 29）

全体(n=405)

100億円未満（n=67）

100億円～1000億円未満（n=207）

1000億円～1兆円未満（n=104）

1兆円以上（n= 27）

事前

評価

事後

評価

すべての案件を実施 一定金額以上の案件は実施 その他の基準

21

「一定金額以上の案件は実施」と回答した企業について、具体的にどの程度の金額規模以上のもの

を対象としている質問しているが、当然のことながら企業の売上規模により評価対象基準額が異な

っている。具体的にどの程度の金額を評価対象の基準値としているか、売上高から見た企業規模別

に見てみた（図表 2-2-11、2-2-12）。

売上高 100 億円未満の企業（25 社）では、1000 万円を事前評価する基準としている企業が多い。

20 万円、100 万円を基準にしている企業もあり、500 万円を基準としている企業が中位となってい

る。

売上高 100～1000 億円未満の企業（106 社）では、1000 万円を事前評価する基準としている企業

が も多く、かつ中位となっている。

売上高 1000 億～1 兆円未満の企業（44 社）でも、1000 万円を事前評価する基準としている企業

が も多く、かつ中位となっている。

売上高 1 兆円以上の企業（12 社）では、1 億円を事前評価する基準としている企業が多い。1000万円を基準にしている企業もあり、5000 万円を基準としている企業が中位となっている。

事前評価の基準値としている金額を対売上高比率で見ると、売上高 100 億円未満の企業では単純

平均が 17/10000 となる。企業規模が大きくなるにしたがってこの値が低くなり、売上高 1 兆円以上

の企業では 0.3/10000（3/100000）となる。

大企業ほど対売上高比率でみて少額の案件まで評価対象としていることになり、IT 投資に対する

評価がよりきめ細かく実施されているとも言える。

評価をするにはそれなりの工数が掛かり、要員を確保しなければならない。また評価項目など評

価スキルや評価の仕組みの整備も重要となってくる。企業規模の大きさが投資評価をよりきめ細か

くする環境にプラスに働いている。

事後評価についても同様の傾向が見えた。

売上高 100 億円未満の企業（20 社）では、1000 万円を事後評価する基準としている企業が多い。

100 万円を基準にしている企業もあり、500 万円を基準としている企業が中位となっている。

売上高 100～1000 億円未満の企業（95 社）では、1000 万円を事後評価する基準としている企業

が も多く、かつ中位となっている。

売上高 1000 億～1 兆円未満の企業（46 社）でも、1000 万円を事後評価する基準としている企業

が も多く、かつ中位となっている。

売上高 1 兆円以上の企業（15 社）では、5000 万円を事後評価する基準としている企業が も多

く、かつ中位となっている。

22

図表 2-2-11 企業規模別 投資評価実施基準額（事前評価）

図表 2-2-12 企業規模別投資評価実施基準額（事後評価）

10 10 10

100

510 10

50

0.166%

0.049%

0.003%0.009%0

20

40

60

80

100

120

100億円未満（n= 25） 100～1000億円（n=106） 1000億円～１兆円（n= 44） 1兆円以上（n= 12）百万円

0.00%

0.05%

0.10%

0.15%

0.20%

頻値 中央値 対売上高

10 10 10

50

510 10

50

0.118%

0.070%

0.012%0.004%0

20

40

60

80

100

120

100億円未満（n= 20） 100～1000億円（n= 95） 1000億円～１兆円（n= 46） 1兆円以上（n= 15）百万円0.00%

0.05%

0.10%

0.15%

0.20%

頻値 中央値 対売上高

23

インフラ型、業務効率型、戦略型の投資カテゴリー別に、事前評価／事後評価で実施している評

価手法を聞いたところ、「システムのユーザーの満足度」が評価手法として圧倒的に多くの企業に利

用されていることがわかった（図表 2-2-13）。

事前評価と事後評価での評価方法を比較すると、事後評価では「システムオーナーの満足度」、「シ

ステムのユーザーの満足度」、「顧客の満足度」がより多く利用されている。

インフラ型投資については、事前評価で「他社との比較、ベンチマーキング」が 39％の企業で利

用されている。この割合（39％）は「評価を行なわない」と回答した企業を除いて、評価を実施し

ている企業の中での利用率をみた値である。企業全体では 21％となる。「KPI」を利用している企業

も 19％ある。事後評価では、評価を実施しているほぼすべての企業が「システムのユーザーの満足

度」となっている。

一方で「評価を行なわない」としている企業が全体の 27％に上っているが、IT 投資に責任を持ち、

主体的な判断できる IT 部門として改善の余地があると言えないか。

業務効率型投資については、事前評価で「KPI」を利用している企業が 35％、「ROI」を利用して

いる企業が 31％に上っている。事後評価についても「KPI」を確認している企業が 32％、「ROI」を確認している企業が 29％となっており、これらの企業では一貫した事前／事業評価が実施されて

いるようだ。

戦略型投資については、事前評価で「KPI」を利用している企業が 31％、「ROI」を利用している

企業が 29％に上っている。事後評価についても「KPI」を確認している企業が 29％、「ROI」を確

認している企業が 25％となっている。

インフラ型投資については「他社との比較、ベンチマーキング」、業務効率型投資については「ROI」、戦略型投資については「KPI」を評価方法として検討することが必要である。

事前評価を実施している企業が 61％、事後評価を実施している企業が 54％と、調査を開始して以

来、どちらも半数を超えたとは言うものの、まだ 4 割以上の企業で事前／事後評価がされないまま

に IT 投資が承認／決裁され実施されている事実がある。

企業グループとして IT 投資を判断し、評価機能は親会社などグループの他の企業が持っているケ

ースもあるかもしれない。投資案件の技術的な評価は情報子会社やビジネスパートナーの協力を得

ている企業・任せている企業も多いと思う。

経営戦略と IT 戦略の統合が求められている中で、IT 部門として評価機能を持つことは益々重要

になってきている。

「どのように経営課題を認識し、その課題解決のためにどのようなシナリオを描いて実現させる

のか」「課題解決のために効果的な IT 投資なのか」「IT 投資で何をどこまで変えようとしているの

か」「その変化がどのような評価指標で確認できるのか」などを明らかにする必要がある。

また、IT 投資が業務効率型から戦略型に重心をシフトしていく中で、個々の投資案件を評価する

指標だけではなく、経営戦略／事業戦略の達成度を測る指標や｢KPI｣および継続的なシステムパフ

24

ォーマンス指標を設定し、その現在値を明らかにし、中期的な目標値をもって、一連の IT 投資がど

のように経営貢献しているのかを振り返りながら次の投資先を検討／評価する姿勢が重要である。

図表 2-2-13 投資タイプ別・採用されている IT 投資評価の手法

23%

31%

29%

20%

29%

25%

19%

35%

31%

18%

32%

29%

18%

21%

39%

22%

27%

45%

71%

61%

50%

98%

83%

77%

10%

16%

31%

14%

22%

42%

39%

16%

29%

20%

9%

17%

5%

5%

4%

5%

5%

4%

0% 20% 40% 60% 80% 100%

①インフラ型投資（n=366）

②業務効率型投資（n=398）

③戦略型投資（n=306）

①インフラ型投資（n=301）

②業務効率型投資（n=331）

③戦略型投資（n=250）

事前

評価

事後

評価

ROI(投下資本利益率)KPI(システム化対象業務上の指標)システムオーナーの満足度システムのユーザーの満足度顧客の満足度他社との比較、ベンチマークその他

25

2．3 プロジェクトの評価

IT 投資評価は構想・企画時、実行計画承認時、開発完了後の 3 段階に分けて実施される。

評価すべきプロジェクト案件に対しどのような質問を浴びせ、より自社にふさわしい、競争力強

化に役立つ案に仕立ててゆくのか、結果をどのように評価したらよいのかを考える。

この検討および承認は、社を上げての大規模プロジェクトの場合、経営者が参画する情報システ

ム委員会などで行われるが、小規模プロジェクトの場合は利用部門、IT 部門、経営企画の代表責任

者を集めての承認がなされる。

図表 2-3-1 は、システム開発の各フェーズ、各契約と投資評価時期の関係を図示したものであり、

図表 2-3-2 は各段階での投資評価の目的と実施内容である。

構想・企画時、実行計画承認時は、次の工程に進んで良いかどうかを判断するために投資評価を

行う。ただし、構想・企画時の費用・投資効果はまだ見通しが利きづらく超概算にならざるを得な

い。場合によっては費用のみしか想定できない場合もある。開発フェーズが進み、システム内容が

確認されてくるに従い投資効果は明確になってゆく。

実行計画承認後は、大規模システムでは、契約は分割されて実施されることが多い。その場合は、

実行計画で承認された予算に基づき、分割契約される。

稼動後半年、あるいは 1 年後の投資実績効果評価は、当プロジェクトの効果をもっと上げるため

と、次のプロジェクトのためのノウハウ蓄積のために行われる。

図表 2-3-1 開発フェーズと IT 投資評価の時期 （開発フェーズおよび契約プロセスについては「信頼性向上・取

引可視化のためのモデル取引・契約書（経済産業省）」を参照）

企画支援サービス業務要件定義

作成支援業務

外部設計書作成業務

ソフトウェア開発業務ソフトウェア運用準備・

移行支援業務

ＲＦＰ①見積①（試算）

ＲＦＰ②見積②（概算） 見積③（確定）

ＲＦＩ

運用業務

保守業務

契約 契約 契約 契約契約 契約

システム化の方向性

システム化計 画

要件定義 システム方式設計（システム内部設計）

ソフトウェア設計プログラミング

ソフトウェアテスト

運用テスト

システムテスト

運用 保守システム設計

（システム外部設計）

システム結合

導入・受入支援

企画・要件定義段階 開発段階 運用段階 保守段階

システム化の方向性

システム化計 画

要件定義 システム方式設計（システム内部設計）

ソフトウェア設計プログラミング

ソフトウェアテスト

運用テスト

システムテスト

運用 保守システム設計

（システム外部設計）

システム結合

導入・受入支援

企画・要件定義段階 開発段階 運用段階 保守段階

ＩＴ投資評価時期

②実行計画承認時

（投資効果確定）

①構想・企画時

（投資効果は超概算）

③開発完了後（稼動

後の一定時期）

＜契約プロセス

＜モデル契約＞

開発フェーズ

26

図表 2-3-2 各段階の IT 投資評価の目的と実施内容

段階・目的 前提 主作業 アウトプット 次工程

構想・企画時

：中期計画に基づ

く主要プロジェクト

の選択と検討着

手の承認

各部から実行したい

希望案が提出されて

いる

各 案 に 対 し て 、 目

的、目標の方向性確

認、要件定義開始の

優 先 度 、 条 件 を つ

け 、 進 め 方 の 方 向

性、承認を与える

・中期 IT 投資計画書

の見直し（数年間を

展望したIT業務推進

方針）

・各案の次フェーズ

への着手の承認書

各プロジェクトは要

件定義を開始し実行

計画案を作成する

開発実行時

：各プロジェクトの

実行承認

プロジェクトの概要

が整理でき、実行計

画書が作成されてい

る。

・開発着手の可否判

断を行う

・目標、効果、予算、

体制、予定、リスク分

析等を吟味する

プロジェクト別実行

計画書

基本設計を開始し開

発工程に入る

（※）稼動開始時 システム稼働準備完

了

稼動承認 稼動開始承認書

(注意事項を含む)

保守運用、利活用

開発完了後

：プロジェクトの開

発結果の反省と

運用フェーズでの

対策・反省を通じ

て ノ ウ ハ ウ の 蓄

積

稼動後安定した時期

(半年あるいは 1 年

後)

稼動直後にプロジェ

クトの開発結果のみ

評価し，効果は実際

に評価可能時期に

実施するケースもあ

る）

・IT 投資効果、費用

推進実績の確認とフ

ォロー

・次プロジェクトへの

知見の整理と蓄積

・プロジェクト実施報

告書

保守運用および利活

用（保守運用計画と

課題整理）

（※）稼動開始時の判断は重要ではあるが、他の 3 段階の評価とは、やや性格が異なるのでこの稼動時期の

問題は別途論じることとしたい。

図表 2-3-4 は、IT 投資のそれぞれの段階において、チェックすべき点をまとめている。次節以降

では、それぞれのチェックポイントについて解説する。

対応関係は図表 2-3-3 の通りである。

図表 2-3-3 IT 投資価値評価ポイントと解説の対応

A．構想・企画段階 B．開発実行段階 C．事後評価

1 経営戦略との適合 A-1 B-1 C-1

2 投資費用 A-2 B-2 C-2

3 投資効果 A-3 B-3 C-3

4 プロジェクトマネジメント A-4 B-4 C-4

図表 2-3-4 個別 IT プロジェクトにおける IT 投資価値評価ポイント

A．構想・企画段階（事前評価 1） B．開発実行段階（事前評価 2） C．開発完了後（事後評価）

１

経営戦略

との適合

（1）投資目的・目標が明確であり、経営戦略との適合はあるか（経営戦略と主要プロジェクトの関係、システム構造、プロジェクトの優先順位は保たれているか） （2）プロジェクトの優先度は妥当か、今実施すべき案件は他にないか

（1）計画は企業戦略と適合しているか （2）改革案に自社の総智が盛り込まれているか（利用者と開発者の間に意識のずれはないか） （3）実行承認にあたっての条件は何か

（1）プロジェクトの結果は企業戦略と適合しているか、補完すべき要素は必要十分か （2）成功要因、失敗要因が整理され、企業のノウハウとして蓄積される仕組みができているか （3）運用、利活用の体制は十分か

２

投資費用

（1）対象案件を加えた場合の新規投資と保守運用費用のバランスは妥当か （2）対象案件を加えた場合の目的別 IT 投資の比率（IT投資ポートフォリオ）は妥当か （3）投資回収年数は妥当か （4）超概算予算は妥当か （5）対象プロジェクトは「小さく生んで大きく育てる」ことが徹底されているか （6）コスト配賦の方法は明確か、方法は妥当か

（1）機能の絞り込みは十分か （2）システムライフサイクルコストを分析しているか、分析結果は妥当か （3）投資費用の細分化、客観的評価との対比を実施しているか（税制の活用等費用低減への取り組みを実施したか）、結果は妥当か （4）リスク分析を実施したか、分析結果は妥当か （5）パッケージの活用、自社システムの横展開について検討したか

（1）当初の開発で取り残した機能のフォローの仕方は明確か （2）総合効果表による確認（稼動工期、稼動後の品質、投資費用の対計画比など）ができているか、結果は妥当か （3）システムライフサイクルコストは計画通りか （4）リスク計画は妥当であったか、どのようにフォローしたのか

３

投資効果

（1）BPR（業務改革）を実施する案になっているか、システム化以前の準備は十分か （2）一次効果に加え、余剰時間の使い方を検討する計画になっているか（一次効果、二次効果の切り出し） （3）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの見極めなど、効果検討の方針は明確か、検討結果は妥当か （4）開発実績評価の時期、撤退条件などを明確にしているか、内容は妥当か

（1）業務フローを見直し、BPR（業務改革）、組織改革を実施しているか、何が変わるのかを確認できたか （2）一次効果、二次効果、三次効果を見極めたか、結果は妥当か （3）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクが数値化されているか、結果は妥当か （4）実施結果の評価時期を決めているか、決定した時期は妥当か （5）撤退条件は明確か、内容は妥当か （6）効果データの収集方法は明確か

（1）一次効果、二次効果、三次効果（ROI）と、フォローの仕方を確認しているか（さらに追跡評価すべき項目は何か、追加予算の必要性はあるか） （2）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの計画対比は確認したか、問題はなかったか

４

プロジェクト

マネジメント

（1）品質、工期、費用など守るべき優先順位を定めているか、定めた優先順位は妥当か （2）プロジェクト責任者（開発、運用、利用責任者）は明確か、選定結果は妥当か （3）ベンダーの選定基準は明確か、選定結果は妥当か

実行計画書を基に以下の項目を確認する （1）推進体制図、リーダーの職階、資質は十分か、社内の協力体制は十分か （2）十分なレベルの要求仕様書（RFP）を作成しているか （3）工期は妥当であるか （4）品質目標は示されているか、妥当であるか （5）予算額は妥当であるか （6）社内体制、ベンダーの確保はできているか （7）稼動条件、移行方針が決まっているか、内容は妥当か（8）進捗報告のサイクルを決めているか、頻度は妥当か （9）プロジェクトマネジメントに抜けがないか

（1）運用目標値（含む SLA）が設定されているか、その内容は妥当か （2）運用・利活用のリスクは何か、関係者の配慮事項は明確か （3）顧客迷惑度指数を設定し評価しているか

28

29

2．4 構想・企画段階における IT 投資評価（事前評価 1）

本節では、構想・企画段階における IT 投資評価の重要ポイントをチェックリストとして挙げ、解

説を行っている。

図表 2-4-1 A 構想・企画段階（事前評価 1）における投資評価チェックリスト

点数 質問内容

納得← →不満

わから

ない

（1）投資目的・目標が明確であり、経営戦略との適合はあるか（経営戦略と主要プロジェクトの関係、システム構造、プロジェクトの優先順位は保たれているか）

4 3 2 1 0 １

経営戦略

との適合

（2）プロジェクトの優先度は妥当か、今実施すべき案件は他にないか 4 3 2 1 0

（1）対象案件を加えた場合の新規投資と保守運用費用のバランスは妥当か 4 3 2 1 0

（2）対象案件を加えた場合の目的別 IT 投資の比率（IT 投資ポートフォリオ）は妥当か

4 3 2 1 0

（3）投資回収年数は妥当か 4 3 2 1 0

（4）超概算予算は妥当か 4 3 2 1 0

（5）対象プロジェクトは「小さく生んで大きく育てる」ことが徹底されているか 4 3 2 1 0

２

投資費用

（6）コスト配賦の方法は明確か、方法は妥当か 4 3 2 1 0

（1）BPR（業務改革）を実施する案になっているか、システム化以前の準備は十分か

4 3 2 1 0

（2）一次効果に加え、余剰時間の使い方を検討する計画になっているか（一次効果、二次効果の切り出し）

4 3 2 1 0

（3）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの見極めなど、効果検討の方針は明確か、検討結果は妥当か

4 3 2 1 0

３

投資効果

（4）開発実績評価の時期、撤退条件などを明確にしているか、内容は妥当か

4 3 2 1 0

（1）品質、工期、費用など守るべき優先順位を定めているか、定めた優先順位は妥当か

4 3 2 1 0

（2）プロジェクト責任者（開発、運用、利用責任者）は明確か、選定結果は妥当か

4 3 2 1 0

４

プロジェクト

マネジメント

（3）ベンダーの選定基準は明確か、選定結果は妥当か 4 3 2 1 0

経営者・プロジェクトの責任者が確認し、それぞれ項目について、「4：納得している」「3：まあ納得している」「2：や

や不満を感じている」「1：不満」「0：わからない、判断できない」より選択し、それぞれ合計点が一定基準以下の場

合は再度担当者に説明を求める、あるいは議論しなおす必要がある。「0：わからない」を選択した項目は、再度担

当者に説明を求める、あるいは議論しなおす必要がある。

30

2．4．1 構想・企画段階における経営戦略との適合（A-1）

（1） （1）投資目的・目標が明確であり、経営戦略との適合はあるか

（経営戦略と主要プロジェクトの関係、システム構造、プロジェクトの優先順位は保たれているか）

「次にこのシステム開発を実施したい」と全社から提出された要求を整理し、議論するのが構想・

企画段階の 大の主眼である。したがって「要件定義のフェーズに進んで良いか」の決断を迫られ

る。そのためにはシステム開発の目的が明確で、目標が妥当でなければならない。

開発作業着手に至る前に再度実行計画審議があるが、その段階での開発拒否、保留はなかなかし

難いので、まずは構想・企画段階で慎重に議論を重ねなければならない。

① 経営戦略と主要プロジェクトの関係は保たれているか

まず問わなければならないのは、各プロジェクトが経営戦略の一端を担うものであるかどうかで

ある。

経営戦略、経営課題と IT プロジェクトの整合性は、もちろん一致するに越したことはないが、大

きなシステム開発は 2～3 年開発期間が必要であり、環境変化等の影響から IT プロジェクトがタイ

ムリーに経営課題に追随出来ない場合も多い。その場合は小改善や既存システムの修正で迅速に対

応するか、すべての機能を一括開発せず、必要 小機能に絞り短期間で迅速に開発することになる。

こうした経営課題と主要 IT プロジェクトの関係を認識するための表が図表 2-4-2 である。

このような表を作成し、経営課題と主要 IT プロジェクトの関係を整理・を作成し、確認する。必

ずしも各年度の経営戦略と IT 戦略が合致していない場合もあるが、それは大型プロジェクトであれ

ばあるほど工期が長くなるためである。

将来に備えて何を IT 部門がなすべきかを考え、先読みをした対策を採る必要がある。ちなみに IT部門は研究開発予算をほとんど持っていないので、経営戦略を先読みしても対策が打てない。この

問題を解決する施策も非常に重要な課題である。

企業によっては経営企画部門に情報システム部を抱え込み、合併システムなど、まだ情報公表で

きない段階から密かに準備をはじめ、合併情報の発表後数ヶ月以内に必要 小限のシステム準備を

完了させている企業もある。

図表 2-4-2 経営課題と主要ＩＴプロジェクト関係表

年度 経営課題 主要 IT プロジェクトと主たる目的

2005

2006

2007

中期 数年先を読み準備すべき技術・案件

31

② 全社のシステム構造はどのようになっているか

全社のシステム構造がどのようになっているかを理解しておくことは重要である。

自社の組織図が分らない経営者はいない。実はこのシステム構造図は業務の構造であり、組織と

密接な関係がある。図表 2-4-3 では調達システムは会社で 1 つの調達部を支援する機能になってい

るが、企業によっては大量購買のメリットよりも個別調達の柔軟性を優先し、事業部内に別々にも

っている場合もある。

初から調達部門は 1 つと決めている企業では、図表 2-4-3 のように 1 つの調達システムを開発

し運用すれば良いが、そうでない場合は複数の調達システムを開発せざるを得なくなる。

もちろん少し工夫して、調達システムは 1 つだが事業部ごとのデータベースを持って運用すると

いう方法も中間案としては存在する。このような議論がこのシステム構造図から生まれてくる。実

例で考えてみよう。

さて、今回はこのシステム構造図を持つ企業に顧客から事業部共通で、納入品管理をしてほしい

との案が持ち込まれた。そこで自社内で共通のシステムを構築することが起案されてきた。各事業

部のデータベースとのインターフェースが重要になることが容易に想像される。各事業部と円滑に

調整できるリーダーが必要であることが分る。

あるプロジェクトが起案されてきた場合でも、全体との関係を配慮して開発しないと無駄やムリ

が生じやすい。問題をあらかじめ議論できるように「見える化」をすることが要求されるので、こ

のような構造図が必要となる。

図表 2-4-3 全社システム構造

販売システム

Ａ事業部

販売システム

Ｂ事業部

販売システム

Ｃ事業部

販売システム

Ｈ事業部

・・・・・・・

顧客管理システム

調達システム

財務システム

人事システム

MAIL システム、情報共有システムなど

32

③ システム再構築のタイミングと負荷を総合的に整理する

「システムが古いので業務効率を阻害し、新規の機能も活用できない」との不満が業務部門から

挙がることは多い。システムの寿命は 5 年から 20 年にわたっており、徐々に更新せざるを得ない状

況である。しかし、IT 部門の開発できるパワーは限られており、情報子会社を含めても優秀な SEやプロジェクトマネージャーは少ないというのが現状である。

そこで、場当たり的な開発を回避し、計画的にシステム再構築を行うために、図表 2-4-4 のような

表を作成する必要がある。どのシステムから再構築するのが良いか、何人 SE が必要かなどの問題

を整理できる。こうした表を作成することにより全体像が可視化されるので、

①表の上から順に切り替える方法が良いのか財務システムを 初に切り替える方が良いのか ②パッケージ活用をするとこのシステム再構築の順序はどうなるのか ③IT 要員は確保できるのか誰が責任を持って開発できるのか

などの議論が可能となる。

図表 2-4-4 システム再構築に必要なパワー

開発年次 再構築年度と負荷（人月）

01 02 03 04 05

販売管理システム 1988 800 人月

生産管理システム 1986

調達システム 1992

原価管理システム 2002

財務システム 2001

④ プロジェクトの優先順位を検討する

どのシステムを優先すべきかは、大きな悩みである。

図表 2-4-3 のようなのシステム環境をもった会社において、各プロジェクトが起案されてきた状

況を考えてみよう。SE が 40 人いるが、半数はシステム保守対応に必要な要員であるので、開発を

担当できるのは実質 20 人、しかもその中の 8 人は開発継続案件で活躍中である。残り 12 人をどの

ように振り向けるのかが問題となる。また、このほかに外注 SE がおおよそ 2 倍程度必要と考えら

れる。

実際に SE を各プロジェクトに配置しようとすると、それぞれの SE が持っている技術、経験が異

なり、 適配置が取れない場合が出てくる。その場合は、コンサルタントなども活用し、能力の補

足をする体制作りと予算が必要になる。情報子会社を持っている場合は、情報子会社 SE との十分

な連携が要求される。

2000 人月

1000 人月

600 人月

33

このような環境の中で IT プロジェクトの着手順位の優先度付けは、図表 2-4-5 のように、「期待

される効果の優先度」と「実施しない場合の損失」の総和で決める方法がある。これは方針が明示

され全社の納得の上で実施順位を決める方法である。工夫次第でこの優先度付けの方法は改良の余

地がある。

図表 2-4-5 検討開始案件表

案件名 目的 期待される効果 優先度 実施しない場合の損失 優先度

（合計点）

着手順

要件定義に必要な直営 SE

人数、予算額（含外注費）

Ａシステム 業 務 効 率 向

上

10 人省力化

業務スピードの向上

2 納期競争劣勢になる 5

（7）③

2 人×6 月

1200 万円

Ｂシステム SOX 法対応 会計監査への対応 3 会計監査に耐えられな

い

1

（4）②

6 人×12 ヶ月

1 億円

Ｃシステム 顧 客 対 応 力

強化

受注維持 5 受注減 4

（9）⑤

3 人×6 月

Ｄシステム システム更新 システム保守能力の

確保

4 システム保守不可能 3

（7）③

4 人×3 月

Ｅシステム 商 品 開 発 の

迅速化

商品開発期間の短縮

30％程度期待できる

1 商品開発期間の長期化

から脱出できない

2

（3）①

6 人×3 月

（2） プロジェクトの優先度は妥当か、今実施すべき案件は他にないか

案件について経営者に説明する際、部下が経営者に も期待するアドバイスは、「提案されてきた

案件以外に取り上げたいテーマはないかどうか」である。

経営者の目から見て、ボトムアップで上がってきた案件以外に、実行して欲しい企業の体質強化

案件はないだろうか。また、他社と比較して劣っているように見えることはないだろうか。

それならば遠慮なく希望を申されるのが良い。コンピュータシステムなど知らなくても業務の仕

組みを理解していれば十分注文はつけられるはずである。それが企業の競争力を高める基になる。

例を挙げる。ある企業の経営者と部下の対話である。

経営者 「月が変わったら 3 日以内に前月の結果を知りたい」 部下 「外部の会社から作業結果のデータは 10 日たってから報告されてきます」 経営者 「それなら、その項目は計画値を使えば良い」 部下 「あの工場のデータは手数がかかるので、3 日以内などとてもムリです」 経営者 「そうか、それなら 20 日締め切りに変えれば良い」

このようにして、この経営者は、翌月 3 日に経営戦略に役立つ月次決算データを入手した。

このような英断がないと企業は変われない。「当社のシステムからのデータは役に立たなくて・・・」

と嘆く前に、経営者は理想を頭に描き、希望を述べる必要がある。

34

2．4．2 構想・企画段階における投資費用 （A-2）

構想・企画段階では、各案件にどの程度投資してよいのかの方向性を決める。この段階では費用

は超概算であり、効果も見えていない傾向が強いことから投資効率を議論することは難しいため、

案件を実施した場合の費用バランスの妥当性と、個別案件について費用の超概算の妥当性を議論す

る。

（1） 対象案件を加えた場合の新規投資と保守運用費用のバランスは妥当か

新しいプロジェクトを実施したいが予算がない。そこで、「保守運用費を我慢し削減し、その費用

を集めて新規開発予算に振り向けた」という企業は多い。

「企業 IT 動向調査」では、毎年 IT 予算全体における新規投資と保守・運用費の比率を調査して

いるが、その結果によると、IT 予算のうちの保守・運用費の平均は、2／3 程度である。2006 年度

の調査結果（「企業 IT 動向調査 2007」）では、新規投資の比率は、全体平均では 36％であった（図

表 2-4-6、2-4-7）。

この調査結果について企業の CIO に意見を求めたところ、「自社では新規投資と保守運用費の比

率は結果とは逆である」という、新規プロジェクトを次々に実施し企業変革を引き起こしている企

業もあれば、「保守・運用費が 80％以上を占めている」という企業もあり、この新規投資と保守運

用費の比率は、企業の経営戦略・事業分野、おかれた状況によってよってバラツキが出ている。

「現在のシステムの利用者には不便をかけるが、新規システムに切り替えるために我慢して欲し

い」程度のことを言わないと予算を捻出するのは難いということも事実である。

いずれにしても、この保守・運用費の IT 予算全体に対する比率は 1 つの鍵である。

図表 2-4-6 新規投資と保守・運用費の比率（企業 IT 動向調査 2007）

保守運用費 新規投資 合計 保守運用費 新規投資

04年度実績 915 514 1,429 36%05年度計画 924 580 1,504 1.1% 12.7% 39%

05年度実績 1,030 489 1,519 32%06年度計画 1,050 606 1,657 2.0% 24.1% 37%07年度予測 1,055 630 1,685 0.4% 4.0% 37%

IT予算（百万円） 新規投資の構成比

本年度調査（n=621）

伸び率

前年度調査（n=731）

35

図表 2-4-7 業種グループ別に見た保守・運用費と新規投資の動向 ※05 年度=100 とした指数

（企業 IT 動向調査 2007）

74

72

71

65

65

66

79

79

79

77

76

71

68

68

65

63

63

63

65

65

60

35

33

29

35

35

34

24

27

21

31

33

29

57

48

35

42

46

37

65

57

40

0 20 40 60 80 100 120 140

一次産業 07年度予測(n=85)

一次産業 06年度計画(n=85)

一次産業 05年度実績(n=85)

素材製造 07年度予測(n=100)

素材製造 06年度計画(n=100)

素材製造 05年度実績(n=100)

機械等製造 07年度予測(n=169)

機械等製造 06年度計画(n=169)

機械等製造 05年度実績(n=169)

商社・流通・卸売・小売 07年度予測(n=116)

商社・流通・卸売・小売 06年度計画(n=116)

商社・流通・卸売・小売 05年度実績(n=116)

金融 07年度予測(n=41)

金融 06年度計画(n=41)

金融 05年度実績(n=41)

重要インフラ系 07年度予測(n=38)

重要インフラ系 06年度計画(n=38)

重要インフラ系 05年度実績(n=38)

サービス系 07年度予測(n=72)

サービス系 06年度計画(n=72)

サービス系 05年度実績(n=72)

保守・運用費 新規投資

36

（2） 対象案件を加えた場合の目的別 IT 投資の比率（IT 投資ポートフォリオ）は妥当か

一度投資すると税法上は 5 年償却が繰り返されるのが一般的である。したがって 6 年目には償却

費がなくなり、同じレベルの償却費を維持して良いとするならば、新規プロジェクトへの再投資が

可能になる。また、逆に今年稼動に入る大型新規プロジェクトがあれば償却費が増加するので、他

の保守費用を削減するなどの工夫が必要となる。

この論理を持って各企業は新規プロジェクトの投資が可能になるが、その予算資源を何に使うの

か投資ポートフォリオをあらかじめ定めている企業もある。あるいは各年度の投資ポートフォリオ

を整理し、戦略の重要な決定要素として社長に判断を求めている企業もある。

ある企業では、「事業の性質上、安全が第一に求められるので、安全投資に 1/3 の予算配分を行い、

残りの 1/3 を顧客のために使い、残りを自社の合理化に活用する」などの方針を定めて実行してい

る。反対に「必要なものにはいつでも必要なだけの予算を投資する」方針で、ポートフォリオは持

たない柔軟性を売り物にしている企業もある。また、システム再構築を 5 年間かけて実施すること

を 優先に掲げて実行している企業もある。

このように、各企業のおかれている立場、環境の差で予算審議の形は変わってくる。各企業の戦

略を明確に提示し、従業員の改革意欲を持たせることは、経営改革の有効な手段の 1 つになる。

ある企業で、「同業他社よりも売上高に対する IT 予算比率は当社が断然低く、IT 予算を効率的に

使っている」と経営者に説明したところ、「システム化は良いことだ。その予算が少ないことは、ま

だ効率化努力が不足していることを意味する。今、わが社は上り坂で他社との競争力強化をする時

期である。IT 予算削減の時期ではない。何を考えているのか？」と叱られたという例がある。

IT 予算削減時期なのか、多少の無駄は目をつぶっても投資増加すべき時期なのか、これこそ経営

者が も意思決定しなければならない点である。時局判断を間違えないようにしなければならない。

（3） 投資回収年数は妥当か

近の大規模プロジェクトはシステム再構築がほとんどである。システム再構築を実施する場合

の効果計算方式には 2 つの考え方がある。

（考え方 1）既存システムの機能は継承するが、効果は持ち込まない場合（図表 2-4-8）

過去の省力化効果、投資効果を計算に再び取り込むことは難しいので、投資回収年数は長くなり 5年間程度に伸び、その代わりシステム寿命も 10～20 年に延長して使う場合が増加してきている。

あるいは、既存システムの効果などを活用せずに、新しい智恵をさらに出して投資回収年数基準

を変えていない会社、あるいはさらに短縮している会社もある。

「投資回収年数が 2 年以上ならば、IT でない合理化、効率化にお金を使った方が良い。お金を使

うのだから他の案件と同一列にみる」としている会社もある。

37

（考え方 2）既存システムの効果も継承する場合（図表 2-4-9）

効果の内容にもよるが、「このシステムを仮にやめたとしたら、やっぱり経費が増加する。したが

って再構築予算に、効果を繰り入れてもおかしくない」と効果継承を求めている企業もある。その

場合は投資回収基準も変えていない。

いずれにしても企業環境とプロジェクトの性格付けをして、回収期間をこのフェーズで決める必

要がある。その基準を守って、次工程で効果額とのバランスで投資金額が議論されることになる。

図表 2-4-8 既存システムの機能の継承と効果（機能は継承するが、効果は持ち込まない場合）

図表 2-4-9 既存システムの機能の継承と効果（既存システムの効果も継承する場合）

新規システム 既存システム 投資回収年数は 2 年間

機能

効果

新規追加機能

機能

新規効果

再開発する場合に

継承機能は持ち込む

既存システムで発揮して

いた効果は持ち込まな

い、投資回収年数は 2 年

から 5 年に変わる

新規システム 既存システム

投資回収年数は 2 年間

機能

効果

新規追加機能

機能

新規効果

効果

再構築予算に効果を繰

り入れる（投資回収年数

は 2 年のまま

38

（4） 超概算予算は妥当か

この時点で予算根拠として想定可能なものは画面数である。「ソフトウェアメトリックス調査

2006（経済産業省委託事業（JUAS 実施））」によると、以下の式が成り立つ（図表 2-4-10）。

したがって、概算予算はこれに単価をかければ良い。「概算予算＝106 万円×1.53×画面数」とな

る。もちろんプロジェクトの特性で補正してもかまわない。人月予算基準も SE 調達環境により毎

年差が出ているので調整はしなければならない。

図表 2-4-10 画面数と工数の相関 工数(人月)

（5） 対象プロジェクトは「小さく生んで大きく育てる」ことが徹底されているか

「データがすべてシステムの中に入っているので、この分析システムが必要」 「アクションするためにはこの表が必要、あの表も必要」

とさまざまな要求が利用者から出されてくる。

一方「ソフトウェアメトリックス調査 2006」におけるシステム保守調査の結果によると、開発後

1～2 年以内に、開発機能の補充のために約 30％の追加開発費が発生していることが明らかになって

いる。

初は本当に必要な機能のみに予算を絞って開発し、運用し始めてから機能補充をするという方

法であれば無駄が生じない。

投入人月＝1.53×画面数

工数 Vs. 画面数

0

500

1000

1500

2000

2500

3000

0 100 200 300 400 500 600 700 800 900

画面数

全体

工数

Y= 1.53 X

39

しかし、 初から「あれも必要、これも必要」と想定して作った場合には、無駄な機能、使われ

ない機能も多い。思い切って必要予算の 30～50％に絞り開発を開始してみる、というような心がけ

が必要である。

（参考） 追加開発に関しての検証

システムも人と同じで「小さく生んで大きく育てる」ことが、以下のメリットにつながる。

・システムの立ち上げが楽になる ・本当に必要な機能だけを開発することになり、システムのメタボリック症候群の防止になる ・開発コストの削減ができる

これに対して「 初に機能を絞っても結局必要なものなら、一度に開発した方が結局安くつく」と

の反論も出されたので、この問題を分析し論じてみよう。

どちらが良いかはデータベースの機能拡張性と密接な関係を持っている。以下のような特性をふ

まえて決定する必要がある（図表 2-4-11～13）。

① 後からの機能追加が簡単であり、 初は機能を絞っておいた方が安くなる可能性が高い場合

：データベースの変更がない場合

データベース自体の追加もなく、データベースへの項目追加もないという場合、実態を確認し、「新

規プログラムが必要かどうか」を検証し、機能を絞ってから、やはり追加機能が必要であれば、新

規プログラムを開発すれば良い。例えば、帳票を追加発行したい場合や検索機能を追加したい場合

などがこれにあたる。

この場合、設計、実装、テストともに、一度に開発しても、二回に分けても大きく負荷は変わら

ず、作業のピークは避けられる。

このやり方の良いところは「本当に必要な機能だけを開発する」ことになるところである。

初は必要であると考えていても、他の手段で代替する事ができたり、滅多に発生しないケースで

あったりで、手作業でカバーしても大きな負荷増加にはならないことに気がつく場合が多いもので

ある。

② 追加機能をするために、既存のプログラム分も含めて再テストが必要になる場合

データベースの追加、あるいはデータベースへの追加項目が発生する場合は、データベースの設

計を二回せざるを得ないので、負荷は増加する。データベース設計までは 初に実施しておく方法

もあるが、その場合も詳細設計の結果、見直しが必要になるので負荷増加になる。結合、総合テス

ト、併行確認テストについて、既存プログラムも再テストをせざるを得なくなる。したがってテス

ト負荷は全機能を一度に開発する場合と比較して、既存プログラムを二重にテストせざるを得ず、

その分の負荷が増加する。

40

図表 2-4-11 データベースの機能拡張と同時開発の負荷（プログラム作成量）

設計 実装 テスト

データベースの変更がない場合

のプログラム作成量

一括で開発する

場合と同じ

一括で開発する場合と

同じ、ただし作業のピ

ークは避けられる

一括で開発する場合と

同じ、ただし作業のピ

ークは避けられる

データベースの変更がある場合

のプログラム作成量

一括で開発する

場合よりも増加

一括で開発する場合

よりも増加

一括で開発する場合

よりも増加

図表 2-4-12 データベースの変更がない場合

図表 2-4-13 データベースの変更がある場合

データベースへの追加項目

またはデータベースの追加あり

既存データベース

新規プログラム

既存プログラムも追加テストが必要

追加項目

データベースの拡張や追加がない 新規プログラム

既存プログラム（新規プログラムの開発に影響されない。

41

（6） コスト配賦の方法は明確か、方法は妥当か

IT 投資を有効に活用する 1 つの鍵が、この IT 投資コストの配布である。このコスト配布の狙い

はいくつかある。

① 無駄な IT 投資の起案を避ける

自らの業務を改革・改善するために新システム導入を希望するのだが、そのためには、システム

を活用する以外にも、他の手段がいくつかあるはずである。その中から 適な手段がコンピュータ

を活用することであるから選択するという意識を、常に利用者側に持ってもらう必要がある。「シス

テムは無料」という意識は捨ててもらわなければならない。

② 開発したシステムをより有効に活用し効果をあげるという意識を高める

開発あるいは導入されたシステムは、必ず償却してゆかなければならない。そのためには、基本

的に「償却費+運用費＜効果額」という式がは成り立たなければならない。

結果的には、システム費用とその投資効果は、収益に影響を及ぼすことは事実であるから、開発

したものは積極的に活用し、効果を出していかなければならない。コスト配布は、効果を発揮しよ

うとする意識を高める 1 つの方法である。

③ 利用部門および IT 部門に費用削減の意識が芽生える

コスト配布をした結果、利用部門の中にはコスト配布シートを見ることで、「IT 費用がこんなにか

かっているのか」と目を丸くする管理者が必ずいる。彼らから、以下のようなアイデアが出てくる

こともある。

「無駄と思えたり、我慢できたりする保守案件は控えよう」 「多少古いが今の端末で我慢しよう」 「これだけ費用がかかるならば、これは捨てて新しいシステムに切り替えよう」 「運用は 24 時間サポートする必要はないので、運用費を下げてくれないか」

結果的に、利用部門、あるいは IT 部門に費用削減の意識が芽生えることになる。

④ コストの配賦の考え方

このようにコスト配賦は意味があることであるが、実際は、すべてのコスト配賦を実施すること

が 善とは言えない場合もあり、以下のような配賦方式の選択が各社において実施される。コスト

配賦の形態も、様々である。

ａ．コスト配賦はしない

・1 社 1 商品を扱っているので、コスト配賦しても意味がないと考えている会社 ・コスト配賦のための負荷を考えると手が出せない会社 ・今はまだ多少無駄があっても、コンピュータを使いこなすリテラシーを高めてほしいと願って

いるシステム環境が未成熟な会社

42

・関連企業含めての育成策を採用中であり、システムの支援が重要な鍵を握っていると考えてい

る会社（少々の費用は親企業が持っても良いと考えている会社）

ｂ．一部のみ配賦する

・事業部独自システムはコスト配賦しているが、経理、人事システムの費用を配賦してみても、

その部分は各事業部ではなんらアクションが取れない。かえって「何故経理システムにこんな

に費用がかかるのか」などと批判ばかり登場し軋轢を生むのでそのような議論をしたくないと

考えている会社。 ・「コスト配賦されてもそのシステムは必要である、是非実施したい」との決意を示し、承認を求

める責任者がいる場合、「企業としては他の案件を優先したいが、あえてこの案件を実施する」

ということを承認することになる。

ｃ．すべて配賦する

・いろいろ意見はあろうが、総合的にシステムを有効に活用する意識が高まると判断しすべての

コストを配賦している会社。

「企業 IT 動向調査 2007」によるとコスト配賦をしていない企業は、大企業で 13％、中堅企業で

は 25％がコスト配賦を実施していない。この中には「配賦する意味がない」と考えている経営者も

いると考えられる（図表 2-4-14）。

図表 2-4-14 IT コストの利用部門への割り振り（企業 IT 動向調査 2007）

⑤コスト配賦の基準

IT コスト配賦のコストとは何を示すのか。新規投資費用（17 項目）、既存システム費用（38 項目）

合計 55 項目にのぼる（図表 2-4-15）。

これらの情報を正しく把握することは、かなり大きな負荷になる。場合によっては各 SE の作業

実績時間を把握することが必要になる場合もある。どこまで細かくデータを把握する必要があるの

か、どこまで精度を求める意義があるのかが問題である。

25%

23%

30%

46%

43%

52%

7%

8%

5%

22%

25%

13%

0% 20% 40% 60% 80% 100%

全体(n=728)

1000人未満(n=520)

1000人以上(n=208)

全面的に実施 一部実施 検討中 予定なし

43

IT 費用の全貌を把握することは、意外に難しい。生産設備の一部として入ってくるコンピュータ、

各事業部が便宜上、自事業部の意思で IT 部門の了解を得ずに導入しているコンピュータなど、コン

ピュータシステムが発達すればするほど、この種類の機器は増加して来る。

「IT 部門に断りなくコンピュータを購入しウイルスに攻撃され、初めて購入していることがわか

った」というような話はよく聞くが、IT 機器の費用を一括して正確に把握するためには、IT 機器に

関する経理コードをコンピュータの購入者が誰であっても、正しく割り当て、正確に報告すること

が必要となる。

コスト配賦基準も厄介な問題である。システム毎に専用機、専用計算センター、専用要員で処理

されている場合は簡単であるが、通常は複数のシステムで一つのコンピュータ、ネットワーク、デ

ータベース資源を共用し、一つの計算センター、操作要員を総合的に利用している。

これらの費用を配賦する基準は、以下のデータを組み合わせることになる。

各システムの資源使用量（ネットワークなど、必ずしも正確にデータを把握できない場合が

ある） 事業規模（売上高によって配賦するのか、営業利益で配賦するのか、など） 使用人数（共同作業をしている場合は、システムの数、データ入力数（月間）などで配賦す

る） 取り扱いデータ数（コールセンターの記録、データ更新回数、データ入力数など把握できる

範囲で配賦する）

図表 2-4-15 IT コストモデル基本構造（JUAS/IT コストマネジメント研究プロジェクト 2004）

運用費用情報システム付帯既存ICTインフラ既存アプリケーション

システム

アプリケーションシステム

ICTインフラ 情報システム付帯

自社開発アプリ

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

サーバマシン

ストレージ

ネットワーク

端末系

ミドルウェア

オフィス機器

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

自社資産償却費用

自社資産保守料自社社員費用

外部委託費用

借用資産使用料

借用資産保守料

自社社員費用外部委託費用

オフィス機器

償却費用

借用費用

保守費用

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

ネットワーク運用費用

端末系運用費用

ヘルプデスク運用費用

データ入力作業費用

システム管理費用

自社社員費用

外注委託費用

コンピュータ運用費用

自社社員費用

外注委託費用

アウトソーシング費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

サーバマシン利用料

ハード/ソフト使用料

ストレージ利用料

ネットワーク利用料

端末系利用料

ミドルウェア利用料

ソフト使用料

ソフト保守料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料ハード/ソフト保守料

既存ＩＴオペレーティング費用新規ＩＴ投資費用

全情報システムコスト

運用費用情報システム付帯既存ICTインフラ既存アプリケーション

システム

アプリケーションシステム

ICTインフラ 情報システム付帯 運用費用運用費用情報システム付帯情報システム付帯既存ICTインフラ既存ICTインフラ既存アプリケーション

システム既存アプリケーション

システム

アプリケーションシステム

アプリケーションシステム

ICTインフラICTインフラ 情報システム付帯情報システム付帯

自社開発アプリ

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

サーバマシン

ストレージ

ネットワーク

端末系

ミドルウェア

オフィス機器

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

自社資産償却費用

自社資産保守料自社社員費用

外部委託費用

借用資産使用料

借用資産保守料

自社社員費用外部委託費用

オフィス機器

償却費用

借用費用

保守費用

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

ネットワーク運用費用

端末系運用費用

ヘルプデスク運用費用

データ入力作業費用

システム管理費用

自社社員費用

外注委託費用

コンピュータ運用費用

自社社員費用

外注委託費用

アウトソーシング費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

サーバマシン利用料

ハード/ソフト使用料

ストレージ利用料

ネットワーク利用料

端末系利用料

ミドルウェア利用料

ソフト使用料

ソフト保守料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料ハード/ソフト保守料

自社開発アプリ

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

自社開発アプリ

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

自社開発アプリ

自社社員費用

外注委託費用

自社開発アプリ

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

外部アプリ

外部アプリ購入

自社社員費用

外注委託費用

サーバマシン

ストレージ

ネットワーク

端末系

ミドルウェア

サーバマシン

ストレージ

ネットワーク

端末系

ミドルウェア

サーバマシン

ストレージ

ネットワーク

端末系

ミドルウェア

オフィス機器

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

オフィス機器

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

オフィス機器

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

自社資産償却費用

自社資産保守料自社社員費用

外部委託費用

借用資産使用料

借用資産保守料

自社社員費用外部委託費用

自社資産償却費用

自社資産保守料自社社員費用

外部委託費用

借用資産使用料

借用資産保守料

自社社員費用外部委託費用

自社資産償却費用

自社資産保守料自社社員費用

外部委託費用

借用資産使用料

借用資産保守料

自社社員費用外部委託費用

オフィス機器

償却費用

借用費用

保守費用

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

オフィス機器

償却費用

借用費用

保守費用

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

オフィス機器

償却費用

借用費用

保守費用

電源空調設備

土地家屋

ユーティリティ

消耗品

データ類購入

保険料等

ネットワーク運用費用

端末系運用費用

ヘルプデスク運用費用

データ入力作業費用

システム管理費用

自社社員費用

外注委託費用

コンピュータ運用費用

自社社員費用

外注委託費用

アウトソーシング費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

ネットワーク運用費用

端末系運用費用

ヘルプデスク運用費用

データ入力作業費用

システム管理費用

自社社員費用

外注委託費用

コンピュータ運用費用

自社社員費用

外注委託費用

アウトソーシング費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

ネットワーク運用費用

端末系運用費用

ヘルプデスク運用費用

データ入力作業費用

システム管理費用

自社社員費用

外注委託費用

コンピュータ運用費用

自社社員費用

外注委託費用

アウトソーシング費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

自社社員費用

外注委託費用

サーバマシン利用料

ハード/ソフト使用料

ストレージ利用料

ネットワーク利用料

端末系利用料

ミドルウェア利用料

ソフト使用料

ソフト保守料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料ハード/ソフト保守料

サーバマシン利用料

ハード/ソフト使用料

ストレージ利用料

ネットワーク利用料

端末系利用料

ミドルウェア利用料

ソフト使用料

ソフト保守料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料ハード/ソフト保守料

サーバマシン利用料

ハード/ソフト使用料

ストレージ利用料

ネットワーク利用料

端末系利用料

ミドルウェア利用料

ソフト使用料

ソフト保守料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料

ハード/ソフト保守料

ハード/ソフト使用料ハード/ソフト保守料

既存ＩＴオペレーティング費用新規ＩＴ投資費用

全情報システムコスト

既存ＩＴオペレーティング費用新規ＩＴ投資費用

全情報システムコスト

44

2．4．3 構想・企画段階における投資効果 （A-3)

構想・企画フェーズで、投資効果額を具体的に提示することは難しいが、評価の方針については

明確にしておかねばならない。

（1） BPR（業務改革）を実施する案になっているか、システム化以前の準備は十分か

一般的に、人手の作業を単純にシステム化しても効果は少ない。業務フローを書き、その中のど

こに「ムダ、ムリ、ムラ」があるのかを見抜き、場合によっては組織間の業務統合を図り、組織簡

略化を図らなければ大きな効果は生まれてこない。BPR（Business Process Reengineering）の効

果は、この業務統合、組織統合から生まれる。

システム化をする以前に考慮すべき点、事前準備をすべき点は多い。

各企業は、顧客の要望に応える商品・サービス等を提供することにより利益を得ているが、顧客

の要望は多様であり、個別に対応していたのでは利益を確保することは難しい。

顧客の要望をどのようにして集め、真の要求は何かを見抜き、商品を標準化し、オプションを整

理することが必要である。システム再構築の場合も、商品体系をそのままにして、システムを再構

築するのか、商品体系から見直すのかなどの事前検討の意味は大きい。

（2） 一次効果に加え、余剰時間の使い方の検討をする計画になっているか

（一次効果、二次効果の切り出し）

ある機能をシステム化した際、「○○円／年効果が出る」「システム化された分の余剰人員は、他

の新規事業部門に回す、あるいは補充をせずに省人化して実際の効果に結び付ける」と言える場合

は「一次効果」と言える。

しかし「システム化された作業で○時間／人月減る」という場合は、残業代が減ることはあって

も、実際の省人化には結びつかないことが多い。これをそのまま金額換算しても、決算上の効果に

は結びつかない、ダミー効果となる。このような理由から投資効果がうやむやになっている企業は

多い。

「システム化で空いた時間にその人は何をするのか」を徹底して研究してみると、今まで作業を

していたベテランを有効活用する効果は非常に大きいことが分った。

一般的には、「空いた時間に、この作業をしてコストダウンを測る」「空いた時間で今まで出来な

かった顧客開拓に回る」などという回答が一般的であるが、それに対し、「このような作業をしたほ

うが、効果が大きいのでは」と、社内の衆知を集めたところ、効果が 6 倍になったという企業があ

る。これが「二次効果」である。

ただ単に「○○時間作業時間が浮きます」で終わらず、

効果額＝一次効果+二次効果

を追跡しないと、大規模プロジェクトはシステム再構築がほとんど、という現状では、効果を算

出できない。二次効果をどのように発揮するかを計画することも必要である。

45

（3） KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの見極めなど、効果検討の方針は

明確か、検討結果は妥当か

① KPI（Key Performance Indicator）

「顧客満足度が○○％向上し、当社のファンが増加します」 「納期達成率が○○％向上し、クレームが減ります」

などの効果説明は、なかなか金額換算しがたいものである。無理に金額換算すれば出来ないことも

ないが、他の確実に出る効果と一緒考えるのも面映いものがある。このような場合、無理に金額換

算はせず、○○を 1 つの指標として捉え、確実にできたかどうかをフォローする方法が、この KPI手法である。

BSC（Balanced Score Card）法もこの要素を備えた方法の 1 つである。財務の視点は ROI にな

るが、顧客の視点、業務プロセスの視点、人材育成の視点などは KPI に共通している。

この場合も漫然と定性評価に終わるのではなく、例えば顧客の視点では、「新規顧客が○○％増加

し、それは例年よりも○％多い」などと評価したい。それも結果だけ追うのではなく、計画の時点

から目標値を設定することが望ましい。

「結果として以前より○％増加した」と結果だけ追う場合と、 初から目標値を持って努力する

場合では、目標達成に大きな差が出てくる。また、高い目標値を持って努力しないと大きな効果は

実現しない。

何にどの程度効果を求めるのかを明確にし、要件定義以降の設計に臨むことが、構想・企画段階

における重要な点である。目標達成のためにどのような仕組みが必要か、以降のフェーズで中心課

題として検討し、目標を達成するための機能を新システムに盛り込んでおかなければならない。

② ユーザー満足度

「企業 IT 動向調査 2007」の結果よると、インフラ型投資、業務効率型投資、戦略型投資いずれ

においても も多く活用されている評価方法は、ユーザー満足度であり、ここ数年同じ傾向が続い

ている（図表 2-4-16）。

JUAS が 2002 年に実施した「ユーザー満足度プロジェクト」では、システム開発におけるユーザ

ー満足度を、工期、品質、価額（生産性）等の基本サービスと、各種マナーを含む上記以外の利用

者の評価項目を表層サービスとし、さらに発注責任者の開発機能、効果、共同開発状況についての

満足度を加えた評価方式としてを定義している（図表 2-4-17）。

また、開発後に任意な質問でユーザー満足度を測定するのではなく、企画時にユーザー満足度調

査の概要を定めておき、開発完了後に｢計画に対しての実績を問う方式｣を提案している。

プロジェクトによっては、一般顧客からのユーザー満足度を収拾しないと実績が判明しない場合

もある。構想・企画段階において、ユーザー満足度調査の予算を含め、開発完了後に「計画に対し

ての実績を問う方式」も合わせて準備するように決めておきたい。

46

なお、ユーザー満足度調査の詳細は、参考資料として、「4．3 ユーザー満足度調査について（96ページ）」に掲載している。

図表 2-4-16 投資タイプ別評価手法

図表 2-4-17 ユーザー満足度コンセプト（JUAS・ユーザー満足度プロジェクト 2002）

ＩＴ投資価値

属性３（費用）

属性２（品質）

利用者満足度

基本サービス

表層サービス

（ＩＴ投資効果の評価）プロジェクト責

任者の満足度

属性１（納期/工期）

属性ａ

属性ｂ

属性ｃ

行動マナー

経営戦略の実現性/効果性の評価

ＩＴ投資価値

属性３（費用）

属性２（品質）

利用者満足度

基本サービス

表層サービス

（ＩＴ投資効果の評価）プロジェクト責

任者の満足度

属性１（納期/工期）

属性ａ

属性ｂ

属性ｃ

行動マナー

経営戦略の実現性/効果性の評価

23%

31%

29%

20%

29%

25%

19%

35%

31%

18%

32%

29%

18%

21%

39%

22%

27%

45%

71%

61%

50%

98%

83%

77%

10%

16%

31%

14%

22%

42%

39%

16%

29%

20%

9%

17%

5%

5%

4%

5%

5%

4%

0% 20% 40% 60% 80% 100%

①インフラ型投資（n=366）

②業務効率型投資（n=398）

③戦略型投資（n=306）

①インフラ型投資（n=301）

②業務効率型投資（n=331）

③戦略型投資（n=250）

事前

評価

事後

評価

ROI(投下資本利益率)KPI(システム化対象業務上の指標)システムオーナーの満足度システムのユーザーの満足度顧客の満足度他社との比較、ベンチマークその他

47

③ 他社比較（ベンチマーク）

プロジェクトが戦略的になればなるほど、投資効果を測定することは難くなる。その場合のより

どころの 1 つが、ベンチマーク（他社比較）である。場合によっては国内だけでなく海外の同業種

の企業を含めて比較することが望ましい。

しかしながら、「売上高に対する IT 予算の比率」など、概要データは蓄積されているが、本当に

望まれるデータは、意外に測定・蓄積されていないものである。前述の「企業 IT 動向調査」「ソフ

トウェアメトリックス調査」などには、活用に資するデータが蓄積されていると考えられる。この

ような調査結果を活用も検討が必要である。。

④ 機会損失リスク（実施しないリスク）

仕事には「実施した場合の損失」と「実施しなかった場合の損失」の 2 つがある。

特に上級管理職になればなるほど、この「実施しなかった場合の損失」が結果的に問われるよう

になる。個人のミスが原因であっても、「実施しなかったため損失が起こった」場合の早期発見、対

処の仕組みを組織的に準備することが要求される。

セキュリティ対策強化などの、守りのためのリスク回避プロジェクトは、この「実施しないリス

ク」を考慮した典型的なものである。ただし、この「リスク回避のための投資」は、どこまで実施

すれば十分なのか、出口が見えにくいのが厄介なところである。

「今システム更新をしておかないと、システムが運用できなくなり、損失が出ても責任をもてな

い」などと IT 部門の責任者から言われると、「予算はないが実施せざるを得ないか」と、しぶしぶ

予算をつけることになる。あるいは業務部門の責任者から、「このシステムがないと競争相手に勝て

ない」と言われると、投資評価基準どころではない。経営者の判断で導入承認可否を決めてゆかざ

るを得ない。ただし、これが進みすぎると IT 統制は利かなくなる可能性があるので、注意も必要で

ある。

（4） 開発実績評価の時期、撤退条件などを明確にしているか、内容は妥当か

① 開発実績評価のタイミング

開発完了後半年、あるいは 1 年後に実績評価を実施し、不満の場合、あるいは追跡調査が望まれ

る場合は再度報告を求めるというケースが一般的である。

システムの寿命は 10 年以上ある場合が多い。特に大型の基幹業務システムは、簡単に作り変える

ことができないので、企業は、保守を続けながらシステムを長持ちさせている。

「開発時に○○人削減できました」等の効果を、システム寿命がある限り計上し続けたら、投資

対効果の信頼性は著しく低下する。今後システム再構築がより活発化することが予想されるが、シ

ステム保守の効果のあり方も整理しておくべき課題として議論する必要がある。

48

② 撤退条件の明確化

運用段階に入ってから、「前提条件が成立していない、あるいは変わってしまった、そのために効

果計算が狂った」というようなことは、しばしば起こることである。その場合に備えて「撤退条件

（Exit Rule）を明確化してから開発に取り組んでいる企業もある。

開始する以上に撤退することは勇気のいることである。構想・企画段階において、強気、中庸、

弱気など、いくつかの状況を想定し、撤退する条件を決めておくことによって、迷いから逃れられ

る。

49

2．4．4 構想・企画段階におけるプロジェクトマネジメント（A-4）

構想・企画段階では、まだ開発に進むかどうかは厳密には決まっていないが、プロジェクトマネ

ジメントに関する以下の項目について、方針を明確化しておく必要がある。

（1） 品質、工期、費用など、守るべき優先順位を定めているか、定めた優先順位は妥当か

工期が絶対延ばせないプロジェクト、場合によっては工期を伸ばしてでも品質を確保しなければ

ならないプロジェクト、予算は絶対にオーバーできないプロジェクトなど、プロジェクトによって

は守らねばならない特質がある。すべてを守ることがベストではあるが、なかなか難しいのでこの

優先順位の決定は、その後の開発の進め方に大きく影響を与える。

工期を 優先するプロジェクトであれば、仕様の決定時期の確保は絶対条件であり、それが可能

な立場の人物がプロジェクトマネージャーを務めなければならない。品質が 重要ならば、システ

ム開発経験豊かなプロジェクトマネージャーを選択しなければならないし、ベンダーの選定も価格

よりも実力を重視しなければならない。以降の開発体制に大きな影響を持つ QCD（品質・価額・納

期）の優先順位をこの段階で決めておくことにより、以降の開発が円滑に進む。是非この構想・企

画段階でこの優先順位を決めておくべきである。

（2） プロジェクト責任者（開発、運用、利用責任者）は明確か、選定結果は妥当か

開発の責任者のみならず、運用の責任者、利用（効果発揮）の責任者について、その選定基準を

明確にしておく必要がある。特に利用における責任者は、効果発現の責任者でもあるので、この段

階で明確にしておき、責任意識を持ってもらうことが必要である。事業部システムは事業部長が

高責任者になることが多いので比較的明確であるが、全社システムになると社長をトップに据える

のは良いとしても、利用部門は多岐に渡るので複数の利用責任者が生じてくる。

例えば、全社の経理システムの開発・導入の場合は一次責任者が経理部長であっても、各部の協

力がないとデータが円滑に流れず、経理システムは円滑に動かない。役割を細分化、明確化し予定

表を作成・更新し、協力を求めなければならない。

（3） ベンダーの選定基準は明確か、選定結果は妥当か

自社の要員だけではパワー・能力に不足がある場合、外部のベンダー・コンサルティング企業な

どからの協力を得て開発にあたるが、その選定方針について経営者がある程度了解しておく必要が

ある。

構想・企画段階では、要件定義におけるコンサルティングという形で協力を受けることが考えら

れるが、コンサルティングのみを行っている企業に委託する場合、開発・実行段階以降（基本設計

から安定稼動まで）での協力は期待できないため、自社の要員が開発実行段階において責任を持っ

て判断し対処できる能力を備えている必要がある。あまりにも理想的なシステムを要求し過ぎ、以

降の開発がついていけなかったり、無駄な機能が多すぎたり、高価になりすぎて実現できなくなる

場合があるので注意が必要である。

50

2．5 開発実行段階における IT 投資評価（事前評価 2）

2-2-2(2)で述べたとおり、「企業 IT 動向調査 2007」によると、事後評価を実施している企業が、

事前評価を実施している企業よりも少ないという結果が出ているが、事後評価実施のためには、開

発実行を承認する時点の事前評価の充実がポイントになっている。本節では、開発実行段階におけ

る IT 投資評価の重要ポイントをチェックリストとして挙げ、解説を行っている（図表 2-5-1）。

図表 2-5-1 B 開発実行段階（事前評価 2）における投資評価チェックリスト

点数 質問内容

納得← →不満

わ

か

ら

ない

（1）計画は企業戦略と適合しているか 4 3 2 1 0

（2）改革案に自社の総智が盛り込まれているか（利用者と開発者の間に意識のずれはないか）

4 3 2 1 0

１

経営戦略

との適合

（3）実行承認にあたっての条件は何か 4 3 2 1 0

（1）機能の絞り込みは十分か 4 3 2 1 0

（2）システムライフサイクルコストを分析しているか、分析結果は妥当か 4 3 2 1 0

（3）投資費用の細分化、客観的評価との対比を実施しているか（税制の活用等費用低減への取り組みを実施したか）、結果は妥当か

4 3 2 1 0

（4）リスク分析を実施したか、分析結果は妥当か 4 3 2 1 0

２

投資費用

（5）SaaS(Software as a Service) ASP(Application Service Provider)の活用、パッケージの活用、自社システムの横展開について検討したか

4 3 2 1 0

（1）業務フローを見直し、BPR（業務改革）、組織改革を実施しているか、何が変わるのかを確認できたか

4 3 2 1 0

（2）一次効果、二次効果、三次効果を見極めたか、結果は妥当か 4 3 2 1 0

（3）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクが数値化されているか、結果は妥当か

4 3 2 1 0

（4）実施結果の評価時期を決めているか、決定した時期は妥当か 4 3 2 1 0

（5）撤退条件は明確か、内容は妥当か 4 3 2 1 0

３

投資効果

（6）効果データの収集方法は明確か 4 3 2 1 0

（1）推進体制図、リーダーの職階、資質は十分か、社内の協力体制は十分か

4 3 2 1 0

（2）十分なレベルの要求仕様書（RFP）を作成しているか 4 3 2 1 0

（3）工期は妥当であるか 4 3 2 1 0

（4）品質目標は提示されているか、妥当であるか 4 3 2 1 0

（5）予算額は妥当であるか 4 3 2 1 0

（6）社内体制、ベンダーの確保はできているか

（7）稼動条件、移行方針が決まっているか、内容は妥当か 4 3 2 1 0

（8）進捗報告のサイクルを決めているか、頻度は妥当か 4 3 2 1 0

４

プロジェクトマネジメント

（9）プロジェクトマネジメントに抜けがないか 4 3 2 1 0

経営者・プロジェクトの責任者が確認し、それぞれ項目について、「4：納得している」「3：まあ納得している」「2：や

や不満を感じている」「1：不満」「0：わからない、判断できない」より選択し、それぞれ合計点が一定基準以下の場

合は再度担当者に説明を求める、あるいは議論しなおす必要がある。「0：わからない」を選択した項目は、再度担

当者に説明を求める、あるいは議論しなおす必要がある。

51

まず、システム開発プロジェクトを開始するに際し、図表 2-5-2 のような実行計画書を作成し、

それぞれの項目について関係者の同意を得る必要がある。この計画書に基づき開発が行われるため、

開発プロセスの中でも も重要な計画書である。この計画書がない状態、この計画書に記載されて

いない内容について事後評価を実施しても、評価基準が明確でないので、事後評価の意味が半減す

る。

小規模かつ影響範囲が限定的なシステムを除いては、開発実行に先立ち、以下の項目を必ず確認

するべきである。

図表 2-5-2 実行計画時の確認項目

確認項目 注意事項

①契約範囲、時期 • 基本仕様が確定するまでは準委任契約を結び、発注者、受注者が納得できるま

で内容の検討を行う

②予算 • 予算規模の縮小 予算枠の 30%カットから始める

• 規模の変化には「2．4．2．3 の法則」がある

• 規模の抑制には、予算カット担当者の設定がポイント

③工期 • COCOMO 法、自社標準、その他一般の基準との差を確認し、過去の自社事例と

比較を行う

• 1 週間の遅れが判断できる日程計画が作成できているか

• TRM、PAM、WBS、EVM、開発高制度などが準備されているか

④品質 • 開発フェーズ別品質目標が設定されているか

• 納入以降安定稼動までの障害目標が決められているか

⑤リスク分析 • 両社間でリスクについての共通認識がなされているか

• ユーザー側での努力が結果に跳ね返る仕組みができているか

⑥プロジェクトマネー

ジャーの実力 • ユーザー側プロジェクトマネージャーは業務に精通しているか、社内を動かす信

念、実力をもっているか

• ベンダー側プロジェクトマネージャーは過去に同規模、同種のプロジェクトでの成

功体験をもっているか

• 問題感知力、達成意欲などの人間性を備えているか

⑦SE 戦力分析表 • 必要技術要素とそのレベルに対して、今回の戦力のギャップが認識されているか

• 不足分の補充策はたてられているか（協力会社の SE，PG 含めての評価）

• 各人の性格、人間性の概要を把握して配置を決めているか（ハーマンモデルなど

を活用しているか）

⑧協力会社の

実力評価

• このプロジェクトを共に推進するのにふさわしい企業か担当者か

• 協力会社全体としてのバックアップ体制はあるか

⑨推進体制図 • プロジェクトの成功はこの体制図にある

• 何が課題であるか確認しているか

⑩ユーザー側のキー

マンとの規模、工期に

ついての確認

• 予算厳守、工期厳守、品質確保のプロジェクトか

• 予算リスクは準備されてあるか

• コストオーバーを支払う習慣のある企業か

⑪変更管理 • 変更管理シートごとの価額設定方式か工数設定方式か

• 一件ごとの承認かまとめての承認か

• 変更管理率の目標設定がなされ、一定範囲に抑える努力をしようとしているか

52

確認項目 注意事項

⑫顧客満足度計画 • 顧客満足度計画が作成されているのか

• プロジェクト完了時に何をもとに顧客満足度を測るのか

• 工期・品質・価格は基準に対してどのレベルにあるのか

• 発注責任者、利用責任者は企画内容について納得しているか

⑬効果発生の仕組み • 前提条件の確認、効果発生の仕組み、効果目標値

• （KPI、ROI、ユーザー満足度，ベンチマーク、実施しないリスクなど）

• 効果データの収集方法の確認（システム内への機能組み込み準備を含む）

• フォローのタイミングと分担別効果発揮責任者は明確か

⑭利益計画

（ベンダーのみ）

• 利益金額、粗利率、営業利益、営業利益率の妥当性

• 直営付加価値生産性（売上－外部支出費）／直営投入人月

• 画面帳票別単価、FP 別単価などの計画値と達成対策を準備しているか

・TRM：Task responsibilITy matrix 業務分担・責任をツリー状に示したもの（後述） ・PAM：Power Analyze Matrix 必要技術とチームメンバーの戦力ギャップをマトリックスで示したもの ・WBS．Work Breakdown Structure 作業をツリー上に細分化したもの ・EVM．Earned Value Management 作業を細分化した単位に計画と実行をフォローする仕組み

53

2．5．1 開発実行段階における経営戦略との適合（B-1）

（1） 計画は企業戦略と適合しているか

要件定義を行うためには、現状システムを見直し、改善・改革すべき点を検討し、新システム機

能を作り出さなければならない。

その過程での方針をぐらつかせないためには、プロジェクト構想企画書に記述されてあるプロジ

ェクトの目的・目標が意味を持つ。迷った時にはプロジェクト構想企画書を読み直し、方針確認を

することが重要である。

さらに、常に当初の狙いを外さないように、改善案を検討しプロジェクト実行計画書としてまと

める。実行計画書の一部は RFP としても活用できる。

（2） 改革案に自社の総智が盛り込まれているか（利用者と開発者の間に意識のずれはないか）

競争力強化のために企業が実現しなければならない点は、「①新商品新サービスの創出」「②業務

プロセスの改善・改革」「③人の気持を変更するための組織・諸制度・ルール・標準の策定」である。

改革案に、この 3 つの要素がどのように盛り込まれているかを含まれているのかを確認する必要が

ある。

経営者が「この 3 要素がどう反映されているのか」を質問することは、非常に有効である。質問

することによって、プロジェクトが目指すものが妥当性であるかが判断できる。

また、すべての案件は、自社が競争優位に立つためのものであるから、「このシステムで他社に勝

てるのか」という質問も必須ある。

「他社がやっているから、当社も実施する必要がある」との回答が返ってきた場合は、「他社より

もどこが優れているのか」「このシステムを当社が実施した場合に、他社はもっと先を行っているの

ではないか」「当社の独自の（他社にはない）智恵はどこに反映されているのか」などの質問は、自

社の総智を引き出し、プロジェクトをレベルアップさせる。

通常であれば、小規模な案件は部長以下が判断し実行しており、大規模システムのみが役員会な

どの経営レベルの会議に審査すべき案件として上がってくる。いたずらに新規性を求めてはいけな

いが、自社らしい智恵が盛り込まれていることは重要である。場合によっては、特定機能を人手作

業に任せて柔軟性を保つ方法もある。

業務プロセスの変更は、業務フローによって表示される。分りにくい図が説明時に提出されてき

たならば「もっと素人に分るようにしてほしい」と頼めば良い。フローチャートで記述されている

日能式業務フロー（日本能率協会方式）、PFD（プロセスフローダイヤグラム）であれば、誰もが簡

単に理解できるはずである。PFD の例を図表 2-5-3 に示した。

54

図表 2-5-3 PFD の例

（3） 実行承認にあたっての条件は何か

企業の成果に大きな影響を与えるプロジェクトであればあるほど期待感は大きい。また開発過程

で様々な問題が露呈してくるのが普通である。したがって、各プロジェクトの特性・特徴に応じて

条件をつけて承認をする必要がある。

（承認にあたっての条件の例）

・予算追加が 10％以上になる場合は再承認を得ること ・工期遅延が起きる見込みの場合は再承認を得ること ・毎月進捗状況を報告すること ・ 新技術が現れたあるいは利用技術が変化した場合は報告すること

55

2．5．2 開発実行段階における投資費用（B-2）

「開発を実施する必要性は理解できるが、なぜそれほど費用が高いのか」との疑問を持つ経営者

もいる。システムにおいても「安物買いの銭失い」になってはいけないが、高いから良いとも限ら

ない。また、安いからダメだとも言い切れない。重要なことは、必要な費用は使いながらも十分に

費用を絞込むことである。以下では、費用を絞り込むためのポイントを示している。

（1） 機能の絞込みは十分か

2.4.2（A-2）で前述したとおり、自社開発を実施する場合、 初は 低限の必要機能に絞って開

発する方が効率は良い。気が利いたシステムベンダーは、将来の発展性を兼ね備えたシステム構造

図に基づきシステム開発を実施しており、機能が大きく追加されても、影響が 低限度になるよう

に準備している。 初は 終型の 30～50％減で開発し、メタボリック症候群にならないようにする

ことが重要である。当然、開発の支援業務も少なくてすむので、稼動時のトラブルや切り替え作業

時の負荷も少なくなる。あわせて工期短縮にもつながる。

（2） システムライフサイクルコストを分析しているか、分析結果は妥当か

開発金額は安いが、後の保守運用費が高い場合がある。開発は一時期であるが、保守運用は、シ

ステムのライフサイクルが終わるまで続く。システムによっては 20 年使い続けることもある。これ

をもじって「開発は恋愛、保守・運用は結婚」という言葉もある。

開発でしっかりしたものを作り、後の運用は手がかからないということが理想である。開発の値

段は安いが、粗末なシステムを作ったため、後の保守費や運用費がかかってしまうことは避けなけ

ればならない。

開発後の保守・費用をある程度明らかにするために、仮にシステムライフを 5 年、10 年にした場

合の総合費用を開発委託先に見積もってもらい、総予算を下げる努力をしなければならない。「シス

テム総合費用＝開発費+年間保守費×年数」である。

「企業 IT 動向調査 2007」の結果によると、このライフサイクルコストを考慮しているという企

業は、従業員 1000 人以下の場合は約半分であり、1000 人以上の大企業では 3/4 がこのシステムラ

イフサイクルコストを計算している（図表 2-5-4）。

システムライフサイクルコストの計算は、システム開発において、パッケージを活用するのか、

自社で独自に開発するのかを選択する際の判断材料にもなる。

「ソフトウェアメトリックス調査 2006」では、以下のモデル式が提起されている。

・自社開発システムの 5 年間の総費用＝開発費＋5 年間の保守費用（＝開発費×1.85）

・パッケージの 5 年間の総費用＝購入費+5 年間の保守費用（＝購入費×0.20×5 年）

56

また、SaaS・ASP モデルの場合は下記のような式になる。

意外にも自社開発システムの保守費が高いが、これは初期開発での機能の不足を補うため、導入

初年度および次年度にかけて実施する追加機能の開発費が大きいからである。初期投資に匹敵する

費用が 5 年間で費やされるという結果が出ている。

次の 6 年目からの 5 年間をあわせた 10 年間では以下のようになる。

一方、ERP パッケージの場合の総費用は以下の通りである。

実際にパッケージの活用をする場合は、コンサルティング費用や 5 年毎のバージョンアップ費用

など、追加費用が必要となるので注意が必要である。

なお、パッケージによって実際の保守費用の算出方法は異なるので、個別に計算をする必要があ

る。また、ERP パッケージでないパッケージの場合は上記のような大きな費用はかからないのが普

通であるので、あくまでも個別のチェックが必要である。

図表 2-5-4 プロジェクト実行時のシステムライフサイクルコストの考慮

・SaaS・ASP の 5 年間の総費用＝年間利用料×５年

自社開発システムの 10 年間の総費用

＝開発費＋5 年間の保守費用（＝開発費×1.85）＋開発費×0.06×5 年 （＝合計開発費×2.15）

購入費×3

7%

4%

14%

7%

5%

11%

26%

33%

25%

22%

33%

27%

26%

29%

31%

32%

31%

38%

44%

23%

37%

42%

25%

28%

0% 20% 40% 60% 80% 100%

全体（n=765）

1000名未満(n=500)

1000人以上（n=222）

全体(n=893)

1000名未満(n=615)

1000人以上(n=273)

06年

度05年

度

1．プロジェクト実行決定にあたって必須2．プロジェクト実行決定にあたって必須ではないが、考慮している

3．規模などによっては、一部考慮している4．考慮していない

※標準的な ERP パッケージの保守費用を購入金額の 20％/年間として計算

7%

4%

14%

7%

5%

11%

26%

33%

25%

22%

33%

27%

26%

29%

31%

32%

31%

38%

44%

23%

37%

42%

25%

28%

0% 20% 40% 60% 80% 100%

全体（n=765）

1000名未満(n=500)

1000人以上（n=222）

全体(n=893)

1000名未満(n=615)

1000人以上(n=273)

06年

度05年

度

1．プロジェクト実行決定にあたって必須2．プロジェクト実行決定にあたって必須ではないが、考慮している

3．規模などによっては、一部考慮している4．考慮していない

57

（3） 投資費用の細分化、客観的評価との対比を実施しているか（税制の活用等費用低減への取り組みを

実施したか）、結果は妥当か

図表 2-5-5 は、システム開発の常識ともいえる一般的な生産性の指標である。

これは、10 億円以下のプロジェクトのデータに基づいた指標であるが、高品質、短工期、システ

ム規模、機能の実現難度などの影響によりバラツキが多いので、 終的にはベンダーの見積競争に

頼ることになる。自社におけるシステムの指標を整理しておくことが望まれる。

図表 2-5-5 システム開発における生産性指標（ソフトウェアメトリックス調査 2006）

指標 数値 コメント

KLOC／人月 1.2 加重平均 言語別には分析していない

FP／人月 9.8 加重平均 IFPUG のみ対象。

KLOC との比較は 118LOC/FP

予算(万円)／人月 102 万円 回帰式 加重平均は 106 万円／人月

予算(万円)／KLOC 91 万円 回帰式 加重平均は 74.1 万円／人月

予算(万円)／FP 12.6 万円 回帰式 IFPUG のみ対象。

工数(人月)／画面数 1.53 回帰式 プロジェクトの初期に活用する。

FP／画面数 16.5 回帰式 同上

※10 億円以上の超大規模プロジェクトは調整負荷などが大きくなるので、生産性は半分以下に低下することがあ

る。プロジェクトの特性に合わせてベンダーの競争見積方式を実施し妥当性を検証することが必要である。

※ベンダーが当該システムに詳しい場合は見積もり範囲、内容が充実しているので、その分費用が高くなって見

積が出される。詳しくないベンダーは、RFP に書いてある内容の必要 低限の機能しか見積もれない。したがって、

安い見積が提出されることは良くある現象である。発注者であるユーザー企業は見積範囲、内容を精査し正しい

判断をする能力をつけなければならない。

また、ＩＴ投資に対する税制上のインセンティブ措置が講じられている。こうした税制上のメリ

ットも検討した上でＩＴ投資評価を行うことが必要である。なお、「産業競争力のための情報基盤強

化税制」下記の URL から詳細な情報を入手することができる。

http://www.meti.go.jp/policy/it_policy/zeisei/

58

（4） リスク分析を実施したか、分析結果は妥当か

ベンダーの提供する見積価額は以下の方式で算出されている。

ベンダーの費用と利益の高低は競争見積で比較せざるを得ない。ユーザーとしての努力項目はリス

クの低減が可能かどうかである。両者でよく対話し双方の理解を深め、両者の努力目標を明確にし

なければならない。

参考資料として「4.4 生産性環境変数評価表（111 ページ）」に、このリスクの評価表を添付して

いる。ユーザーとベンダーが双方の努力でリスクを減らすために有効である。

（5） SaaS(Software as a Service) ASP(Application Service Provider)の活用、パッケージの活用、自社シス

テムの横展開について検討したか

自社独自に開発をするべきか、それともパッケージを活用するべきかという問題は、開発初期の

検討課題に必ずあがってくる。昨今では、SaaS(Software as a Service)、ASP(Application Service Provider)の活用も検討の対象となる。

「企業 IT 動向調査 2007」の結果によると、人事、経理等の共通業務業務システムでは、パッケ

ージを活用する企業がここ数年間で広がってきている（図表 2-5-6）。

独自開発が適切なのは、自社の業務モデルが競争力の根幹を確保しているものであり、パッケー

ジの活用ではカバーしきれないことが明確な場合である。ビジネスモデルにより競争優位に立ちた

い場合は進んで自社開発をするのが良い。

SaaS・ASP やパッケージの活用のが良い場合は、当該の機能で他社と競争する必要がない場合、

グローバル展開など自社の業務ノウハウよりもパッケージベンダーのノウハウの方が優れている場

合、関連企業を含めての活用が可能で将来性がある場合、アプリケーション保守の問題がないなど

の優位性を感じる場合などである。

費用も 1 つの要素になるが、これは前述したように、システムライフサイクルコストで判断をす

べきであり、初期投入費用だけで判断してはいけない。

パッケージの活用を目指したが、パッケージの機能だけでは自社のシステムがカバーしきれなく

なり追加費用が増加したケース、パッケージを使いこなせないことが判明し、独自開発に変更した

ケースもしばしば聞く。このような事態に至るとユーザーもベンダーも不幸になるのでパッケージ

の活用は慎重に行いたい。

SaaS・ASP やパッケージ採用のプロセスは、通常は、図表 2-5-7 の手順となる。この中で重要な

ことは、「①自社業務に必要な機能の整理・分析」である。これは、業務機能分析構造図を作成する

ことから始まる。（業務機能分析構造図のサンプルとして、図表 2-5-8、2-5-9 を挙げる）

見積価額＝ベンダーの費用+ベンダーの利益+リスク

59

業務機能分析構造図に基づき、すべての機能がカバーされているか、パッケージの機能に合わせ

て業務方法が変更できないかを検討する。

業務構造図を準備せず「大体こんな機能ができれば良い」と判断し、導入後「こんなこともでき

ないのか」と臍をかむ愚は避けなければならない。SaaS・ASP やパッケージは、通常多くの機能を

所持している。多少回り道でも十分業務を分析し準備して活用すれば、搭載されている機能でカバ

ーできるなど、活用手段が準備されているものである。

大方の機能が SaaS・ASP やパッケージに用意されていることが判断できた時点で、実際に活用

し問題点をあらかじめ認識しておくことが必要である。数日分の業務をシミュレーションしてもら

い、あらかじめ問題点を抉り出しておけば、導入後の問題発生が抑えられる。このステップで初め

て効率が確認できることに着目して欲しい。

機能としては十分であるが、「このユーザビリティでは入力や結果の確認に手間がかかり過ぎる」

などの情報は、ここで初めて判明する。このステップを安易に考え省略してしまうと、後で痛い目

にあう。

利用しているユーザーに直接聞いて有効情報を入手するのも問題発生防止に役立つ。

また、パッケージを採用した会社によく聞いてみると、「パッケージのデータベース構造を活用し

た」だけのケースもあり、「画面帳票はすべて作り直したため、予算がかさんだ」などの情報を入手

できることもある。

どの深さまでパッケージの活用の機能の活用をしているのか、など注意が必要である。

60

図表 2-5-6 基幹系業務システムの開発方法

図表 2-5-7 パッケージ採用のプロセス

① 自 社 業 務

に 必 要 な 機

能の整理

②パッケージ

の選択

③パッケージと自

社業務のギャップ

分析

（シミュレーション）

④ギャップ

補足の検討 満足？

NO

YES

採用

73%

71%

71%

73%

70%

60%

31%

31%

68%

67%

66%

69%

65%

62%

28%

24%

12%

12%

12%

12%

10%

16%

14%

12%

17%

15%

16%

16%

14%

15%

16%

15%

15%

17%

17%

15%

20%

23%

54%

56%

15%

18%

17%

15%

21%

23%

56%

61%

0% 20% 40% 60% 80% 100%

①受発注(n=761)

②仕入・在庫管理(n=738)

③生産・商品(n=588)

④物流(n=499)

⑤顧客管理(n=650)

⑥経営企画(n=390)

⑦財務会計(n=848)

⑧人事・総務(n=783)

①受発注（n=810）

②仕入・在庫管理（n=785）

③生産・商品（n=611）

④物流（n=532）

⑤顧客管理（n=694）

⑥経営企画（n=398）

⑦財務会計（n=916）

⑧人事・総務（n=847）

06年

度05年

度

自社開発 併用 パッケージ

61

図表 2-5-8 業務ルール定義書① 事例：製造業－営業関連業務

（JUAS ビジネスシステム定義プロジェクト報告書 2005）

図表 2-5-9 業務ルール定義書② 事例：製造業－営業関連業務

（JUAS ビジネスシステム定義プロジェクト報告書 2005）

納品先納入後テスト検収1標準品質の工場出荷/検収1納品検収条件7

受注センタで対応部材、生産枠の不足調整1納入納期確約(標準納期で受注)

1納期回答6

8

5

4

3

2

1

特注品の進行基準の請求1標準品の月間納品物の請求（月次請求書処理）

1請求条件

受注センタで対応別途設計・製作のQCD1受注契約(標準QCDの受注)

1受注伝票

将来ビジネス勘案で裁量1顧客与信限度(規定による与信限度)

1与信審査依頼

人間系で対応事業部決済条件の交渉企業のリスクで交渉

12

標準契約交渉（標準/ｵﾌﾟｼｮﾝ商品）（標準QCD対応）

1特例契約条件

別途設計・製作品納期1納期提案（標準納期提案）

4

特別単価の設定必要コストアイテム見積

12

見積単価選定（顧客別商品別単価選定）

3

別途設計し製造する商品1提案内容（標準／オプション商品）

2

提案見積方針見積作成依頼発行

1見積提案

終顧客別営業担当者の設定

グループ営業展開の指定グループメンバの選定

1営業テリトリ判別担当営業選定

1営業区分

終顧客直販1商流

製品／商品／サービス識別コード

1製品商品ｻｰﾋﾞｽ管理

2

取引先企業／担当者識別コード1顧客管理1共通

システム化要求例外ルール処理基準通例ルール処理基準準拠ベース分類

納品先納入後テスト検収1標準品質の工場出荷/検収1納品検収条件7

受注センタで対応部材、生産枠の不足調整1納入納期確約(標準納期で受注)

1納期回答6

8

5

4

3

2

1

特注品の進行基準の請求1標準品の月間納品物の請求（月次請求書処理）

1請求条件

受注センタで対応別途設計・製作のQCD1受注契約(標準QCDの受注)

1受注伝票

将来ビジネス勘案で裁量1顧客与信限度(規定による与信限度)

1与信審査依頼

人間系で対応事業部決済条件の交渉企業のリスクで交渉

12

標準契約交渉（標準/ｵﾌﾟｼｮﾝ商品）（標準QCD対応）

1特例契約条件

別途設計・製作品納期1納期提案（標準納期提案）

4

特別単価の設定必要コストアイテム見積

12

見積単価選定（顧客別商品別単価選定）

3

別途設計し製造する商品1提案内容（標準／オプション商品）

2

提案見積方針見積作成依頼発行

1見積提案

終顧客別営業担当者の設定

グループ営業展開の指定グループメンバの選定

1営業テリトリ判別担当営業選定

1営業区分

終顧客直販1商流

製品／商品／サービス識別コード

1製品商品ｻｰﾋﾞｽ管理

2

取引先企業／担当者識別コード1顧客管理1共通

システム化要求例外ルール処理基準通例ルール処理基準準拠ベース分類

納品先納入後テスト検収1標準品質の工場出荷/検収1納品検収条件7

受注センタで対応部材、生産枠の不足調整1納入納期確約(標準納期で受注)

1納期回答6

8

5

4

3

2

1

特注品の進行基準の請求1標準品の月間納品物の請求（月次請求書処理）

1請求条件

受注センタで対応別途設計・製作のQCD1受注契約(標準QCDの受注)

1受注伝票

将来ビジネス勘案で裁量1顧客与信限度(規定による与信限度)

1与信審査依頼

人間系で対応事業部決済条件の交渉企業のリスクで交渉

12

標準契約交渉（標準/ｵﾌﾟｼｮﾝ商品）（標準QCD対応）

1特例契約条件

別途設計・製作品納期1納期提案（標準納期提案）

4

特別単価の設定必要コストアイテム見積

12

見積単価選定（顧客別商品別単価選定）

3

別途設計し製造する商品1提案内容（標準／オプション商品）

2

見積作成依頼受信見積作成依頼発行

1見積作成

営業テリトリ判別担当営業選定

1営業区分

代理店経由販売1商流

製品／商品／サービス識別コード

1製品商品ｻｰﾋﾞｽ管理

2

取引先企業／担当者識別コード

1顧客管理1共通

システム化要求例外ルール処理基準通例ルール処理基準準拠ベース分類

納品先納入後テスト検収1標準品質の工場出荷/検収1納品検収条件7

受注センタで対応部材、生産枠の不足調整1納入納期確約(標準納期で受注)

1納期回答6

8

5

4

3

2

1

特注品の進行基準の請求1標準品の月間納品物の請求（月次請求書処理）

1請求条件

受注センタで対応別途設計・製作のQCD1受注契約(標準QCDの受注)

1受注伝票

将来ビジネス勘案で裁量1顧客与信限度(規定による与信限度)

1与信審査依頼

人間系で対応事業部決済条件の交渉企業のリスクで交渉

12

標準契約交渉（標準/ｵﾌﾟｼｮﾝ商品）（標準QCD対応）

1特例契約条件

別途設計・製作品納期1納期提案（標準納期提案）

4

特別単価の設定必要コストアイテム見積

12

見積単価選定（顧客別商品別単価選定）

3

別途設計し製造する商品1提案内容（標準／オプション商品）

2

見積作成依頼受信見積作成依頼発行

1見積作成

営業テリトリ判別担当営業選定

1営業区分

代理店経由販売1商流

製品／商品／サービス識別コード

1製品商品ｻｰﾋﾞｽ管理

2

取引先企業／担当者識別コード

1顧客管理1共通

システム化要求例外ルール処理基準通例ルール処理基準準拠ベース分類

62

63

2．5．3 開発実行段階における投資効果（B-3）

（1） 業務フローを見直し、BPR（業務改革）、組織改革を実施しているか、何が変わるのかを確認できたか

情報システムについて詳しくない経営者も、「このシステムで何が変わるのか」を必ず確認しなけ

ればならない。

現状の業務プロセスは、業務フローを描くことによって確認できる。では、どのような発想で現

状からのレベルアップを考えれば良いだろうか。実施されている方法として、「ケプナートリゴー法」

が挙げられる。

ケプナートリゴーの原則は、その作業を

①やめられないか ②減らせないか ③標準化できないか ④機械化できないか ⑤簡単にできないか ⑥ピークを減らせないか ⑦他の人に任せられないか

と確認し、改善案を創出する方法である。これらを繰り返すことで改善案が出てくる。この考え方

は、IE（Industrial Engineering：生産性向上を計る総合管理技術）の考え方と同じである。

しかし、システム再構築の場合、現行システムの開発時に上記①～⑦を既に繰り返し改善を実施

済みであり、同じことの繰り返すだけでは改善案は出てこない場合が多い。そこで、以下の項目の

検討を実施し、新たな改善案を生み出すことを提案する。この発想を十分に活用するとシステム開

発の重複を避けることができる。

⑧対象範囲の見直し： システム化対象範囲を変えて検討してみる。 例えば、特定業務部門から全社、さらに関連企業含めてのシステム化を考えてみる

⑨代替化： 定常作業の機械化だけでなく例外作業含めて簡素化できる方法はないか ⑩抽象化： 情報システムに取り組む場合は、標準化からさらに発想を広げて、抽象化、汎用化

ができないか ⑪理想目標設定法：経営活動目標を理想状態にまで高めて考えてみる。

例えば、在庫ゼロ、100％の品質、待ち時間ゼロのシステムの検討 ⑫新技術の活用：ユビキタス、WEB システム、携帯電話、RF-ID などの新技術の採用を検討

新しい技術、電子製品が次々と登場している。これらの文明利器を活用しない

手はない。RF-ID、携帯電話、などのユビキタス機器を活用した提案も有効で

ある ⑬顧客の顧客：「顧客の顧客」を考えてみる。顧客の要望は、「その顧客の顧客が何を望んでいる

のか」を見極めることから始まっている。顧客の要求をすべて素直に聞き入れる

のではなく、顧客の発言から真の必要としているものは何かを見抜き顧客の要求

にこたえる。

64

人間の智恵は限りないものがあるので、まだまだ新しい考え方が出すことは可能である。人のや

らないことを考えなければ、人よりも抜き出ることは出来ない。「もっと工夫し効果の出るシステム」

を追求し続けることが必要である。

上記に挙げた考え方、発想法で新システム案を考えると、業務内容の変化、業務量の変化が発生

する場合がある。その結果を受けて、より効果を挙げるためには、組織がどのように変わるべきか

を検討しなければならない。業務方法の変化は組織改革まで結びつかないと大きな効果には結びつ

きにくい。

（2） 一次効果、二次効果、三次効果を見極めたか、結果は妥当か

① 一次効果

従来の人手作業がシステムに変わり、余裕がでてくる場合、複数の人の複数作業を組み合わせる

ことによって省力効果に結びつく。あるいは組織の統合を行ってでも省力化する必要がある。数人

が「○○時間分作業が楽になった」と言っているだけでは IT 費用が増加しただけで終わってしまう。

上手くいっても「残業時間が減った」程度の効果しか出てこない。

② 二次効果

「空いた時間で何をするのか」を突き詰め、そこで生み出される効果を「二次効果」という。

「システム化により生じた時間の余裕を使い、普段出来なかった作業を、どのように日常作業の

中に組みこむか」までを考えないと、実際の効果には結びつかない。この二次効果追究の徹底度が

企業競争力につながる。空いた時間があるならばこの「二次効果」の追求を推進してほしい。顧客

訪問に時間を割く、人材育成を図るなど、企業として取り残している課題は山積しているはずであ

る。

③ 三次効果

単に「作業が楽になった」「ドキュメントがきれいになった」というのは、三次効果（一次効果、

二次効果意外の定量効果をいう）、あるいは定性効果である。場合によっては組織文化を変える必要

性が出てくる。省力化効果を実現するためには、ラインの業務部門、あるいはシステム部門に任せ

きりにするのではなく、実行計画作成時に経営企画部、人事部、総務部などのアドバイス、協力が

欠かせない。

65

（3） KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスク、は数値化されているか、結果は

妥当か

① KPI

「売上 1 億円達成」「生産量 5 万トン達成」「歩留 99％」「クレームゼロ」「大規模無災害 500 万時

間」など、業務部門では業務目標を決めて活動することはごく普通に行われている。これも KPI の1 つである。

KPI とは、「成果をトレースするための指標」である。

システム化の目標値は、実施開始時までの期間が長い、複雑な要素が絡み合うなどの要因がある

にしろ、基本的には KPI で測定し、評価することが可能である。プロジェクトの特性を活かし、図

表 2-5-10、2-5-11 のような KPI の整理表を作成したい。

目標値だけでなく、それを達成するための条件・リスクを整理し、環境の変化とシステム化の実

績効果との差を説明しやすくしておく。KPI の目標項目を BSC で整理し、総合的な目標とする場合

もある。目標があれば達成意欲とそのための施策も充実してくる。

図表 2-5-10 製造業におけるの KPI

KPI

（大区分）

KPI

項目

前提条件 （現状）

目標値

リスク

工期 納期達成率 現状の受注構成 （95％）

98％

・短納期品の増加

標準在庫量 受注構成が類似 （5 日分）

3．5 日分

・生産の安定

品質 欠陥率 調達先は継続 （99.6％）

99.9％

・コストダウンの要請限度

生産 生産性 従業員の勤務継続 （昨年 200ｔ/人）

+5％/年

・優秀若手従業員の確保と育成

図表 2-5-11 サービス業における KPI

業種 KPI 項目 目標値 具体例

旅行業 リピート顧客率 60％ 旅行ツアー参加者

損害保険 新規顧客 +1000 人 新規加入者数

66

② ユーザー満足度

測定すべきユーザー満足度の例として、図表 2-5-12 を挙げる。回答者は経営者、CIO、利用部門

責任者などである。プロジェクトマネージャー、ユーザー満足度調査者がチェック用としてこの表

を活用する。開発実績はこの表の目標を実績に置き換えて再度問い直すことになる。

図表 2-5-12 実行計画（事前評価段階）についてのユーザー満足度

NO 質問 目標尺度 理由

1 開発投資・戦略価値などプロジェクトの総括

目標についての満足

4 以上

2 実現した業務プロセス、システム機能につい

て満足していますか

4 以上

3 貴社 IT 部門・利用部門・ベンダー3 者の協調

体制について満足していますか

4 以上

4 工期は標準工期と比較して短いですか 3 以上 工期＝2.4（投入人月の立方根）との比較

5．非常に短い、3 普通、1、非常に長い

5 品質目標について満足していますか 4 以上 納入後の欠陥数

（1 個／500 万円以下）

6 生産性目標について満足していますか 3 以上 \/FP、\/ＭＭ

7 利用容易性目標について満足していますか 4 以上

8 効果目標についての整理について満足して

いますか

4 以上

5．非常に満足 4．やや満足 3．普通 2．やや不満足 1．非常に不満足

67

③ 他社比較（ベンチマーク）

他社との比較も 1 つの指標になる。同業他社との比較データがあれば も良いがなかなか入手は

難しいので、産業別などのデータを 1 つの参考にする。

業界トップレベルのビジネスモデルを目指すならば、費用比較よりも内容、効果、顧客の受け止

め方などを気にする方が良い。

外国では、特定産業を対象として

・ ヘルプデスク（コンタクトあたりのコスト） ・ SAP（ネームドユーザーあたりのコスト） ・ デスクトップ（ユーザーあたりのコスト） ・ アプリ開発（FP あたりのコスト）

を調査し、 低ライン、平均、 高ラインを示している事例が、「先進諸国との対比における、IT投資／IT コストダウンと IT コストマネジメント報告書（2004．4、JUAS）」に報告されている（図

表 2-5-13）。

図表 2-5-13 ベストプラクティス指標例（IT 投資／IT コストダウンと IT コストマネジメント報告書）

分野 低ライン 平均 高ライン

ヘルプデスク(コンタクトあたりのコスト) 26.73 ユーロ 19.24 ユーロ 12.45 ユーロ

SAP(ネームドユーザーあたりのコスト) 5936 ユーロ 4157 ユーロ 2289 ユーロ

デスクトップ(ユーザーあたりのコスト) 4356 ユーロ 3352 ユーロ 2056 ユーロ

アプリ開発(FP あたりのコスト) 471 ユーロ 353 ユーロ 206 ユーロ

④ 実施するリスク、実施しないリスクの分析

システム機能、非機能、ユーザビリティ、投資効果、投資費用などが明確になったこの時点で、

図表 2-5-14、2-5-15 のようなリスク表を作成し、実施した場合のリスク、実施しなかった場合のリ

スクを問い直す。リスクは具体的に明記する。

図表 2-5-14 実施した場合のリスク

NO 項目 理由 対策

1 工期延長の可能性 標準工期に対し 25％短工期 仕様の早期決定を図れるベテランを投入

2 システム切り替え時

のトラブル

業務改革が大きいのでシステムを

使い慣れる期間が必要

・併行運転期間を長く取る

・Ｕ字型開発方法を採用

3 予算オーバー 新規開発会社の採用で実力が不明 開発者の 適配置

機能の絞込み

レビュー、受入検査の強化

4 その他

68

図表 2-5-15 実施しなかった場合のリスク

NO 項目 理由 対策

1 顧客要望の採取およ

びその反映が不十分

になる

このシステムがないと、手数時間が

かかりすぎ真の顧客の要望がつか

めない

MAIL を活用しての限られた客からの情報

入手

2 既存システムのパッ

ケージ保守期限が切

れる

十分なベンダー支援が得られない 新パッケージの購入費用（2000/万年）

3 内部統制 既存システムではデータ精度、保証

方法の不備に対応しきれない

既存システムのシステム保守費用が 1000

万円程度かかる

4 その他

（4） 実施結果の評価時期を決めているか、決定した時期は妥当か

システム稼動後の安定した時期を想定し、実施時期、実施責任者、実施支援者を決めておく。例

えば、実施時期は稼動後半年後に実施する。実施責任者は IT 部門長、効果責任は販売部長、支援者

は人事部長など。

（5） 撤退条件は明確か、内容は妥当か

開発内容が明確化した時点で、このシステムが上手く開発できない、活用できない場合に備えて

撤退条件を明確化しておく。

利用頻度が問われる情報系システムの場合は、利用頻度、利用者などを自動的に記録できる仕組

みを備えておくことが望ましい。

（6） 効果データの収集方法は明確か

IT 投資評価の事後評価が十分に実行できない理由の 1 つに、「データ収集のための負荷が重い」

ことが挙げられる。計画時に「こんな効果が期待できる」と予算書に書いたとしても、具体的に、

どのようにしてその評価データを集めるのかを明確にしておかないと、徒労に終わってしまうこと

になりかねない。ROI、KPI、ユーザー満足度含め、どのようにしてデータを集めるのかを明確にし

て初めて実行計画は完成となる。

この効果測定項目の中には、人手では集めきれないものが多い。例えば、システムの利用頻度を

KPI として設定した場合、仕組みプログラムに組み込んでおけば簡単に測定できる。効率的にデー

タ収集を行うにはこのような配慮が必要である（図表 2-5-16）。

図表 2-5-16 効果測定方法の確立

①期待される効果目標の設定

・ROI ･KPI

＊企画構想時は項目

＊実行計画作成時は目標値

②測定方法の確立

・具体的な効果データの

採取方法の準備

＊実行計画作成時

③実績評価

・計画対効果

・データは自動採取

＊開発完了後

69

2．5．4 開発実行段階におけるプロジェクトマネジメント（B-4）

大規模プロジェクトは社をあげての一大事業である。実行の段階では、自社としてなすべき項目、

体制が決まっていなければならない。後の工程でのトラブル、社員の作業負荷増加にならないよう

に、とりわけ顧客に迷惑がかからないように、事前チェックを十分に実施しなければならない。

期待できる業務モデルが見え、投資対効果のバランスが取れており、実行計画が作成してあれば、

後は、経営者の立場としては、信頼できるスタッフに任せるしかない。

しかし、いくつかのチェックポイントがある。実行計画書をもとに、以下の項目を確認すると良

い。

（1） 推進体制図、リーダーの職階、資質は十分か、社内の協力体制は十分か

成功の秘訣は、実行計画書の中の組織体制図とスケジュールに隠れている。

プロジェクトのリーダーは、今の職制階層レベルで良いか、経営者はプロジェクトリーダーの名

前を聞いても分らないことが多い。しかし、肩書きは判断できる材料である。

昔からの習慣でプロジェクトのリーダーは課長クラスが担当している場合が多い。

数億円単位の大規模プロジェクトになればなるほど、階層を上げて部長あるいは役員を責任者に

した方が良い。上手くいっていないプロジェクトのリーダーをみると、「もともとこの職階層では難

しいのでは」と思われる立場の人が就任していることが多い。

部長クラスのプロジェクトマネージャーであれば、経営者との対話が対等にできるが、課長クラ

スのプロジェクトマネージャーでは、経営者と対話する頻度が少ない。さらに、問題が発生すると

自分だけでなんとか解決しようと努力しすぎ、社としての対応が遅れるなど、問題を抱えやすく、

注意が必要である。

企業の合併に伴うシステム統合プロジェクトの場合には、組織文化を変える必要もあるので、経

営者自らがプロジェクトリーダーになることもある。

（2） 十分なレベルの見積要求仕様書（RFP）を作成しているか

「企業 IT 動向調査 2006」によると、十分な要求仕様書（RFP）を自社で用意した場合、できあ

がったシステム品質に対する満足度は高くなることが判明している。一方、すべてベンダー任せの

場合、満足度も低くなる。（図表 2-5-17）

70

図表 2-5-18 は、自社の要求仕様書の作成レベルと費用の関係を示している。

自社が作成した要求仕様書のレベルはベンダーに評価してもらうのが良い。どこをどのように修

正・追加すればレベルが向上するのか、ユーザーとベンダーが対話をすることにより、次回以降の

要求仕様書の精度が上がり、開発時のトラブルが減少する。図表 2-5-18 の①のように要求仕様書に

必要項目・水準が網羅されている場合に比べ、④のように要求仕様書がほとんどない場合は、30％以上開発費用が高くなる（ソフトウェアメトリックス調査）。

なお、平成 18 年度経済産業省委託事業として JUAS が実施した「高品質情報システム開発に向

けた要求可視化・共有化手法に関する調査（UVC プロジェクト）」の報告書には、企画・設計・開

発に至るプロセスにおける要求仕様書に記載された項目の変化を可視化し、適切に管理することが

可能な仕組みを提案しており、活用を期待してる。

図表 2-5-17 要求仕様書の作成者と満足度（企業 IT 動向調査 2006）

図表 2-5-18 要求仕様書の充実度と製作費用

副品質

特性

内容

設計

製作

テスト

評価基準

① 0 － 0 必要項目・水準が網羅された要求仕

様書が存在

② 7 － 3 必要項目・水準のどちらかに不備あり

③ 15 － 6 必要項目・水準の両方に不備あり

要求仕様

の網羅性

・ソフトウェアがユーザーニーズを

満足ために必要十分な機能を備

えていることに対する要求

・ユーザーニーズの具体性、網羅

性、ステークホルダーの同意度合

を評価し，要求仕様書にニーズが

具体的に記載されていない場合

は、以降の工程でニーズの具体

化、検証作業が必要になる ④ 30 － 10要求仕様書が不存在(口頭説明、代替

資料など)

（注）3 列～5 列の数値は基の費用に対して増加する率を％表示したもの。

15%

11%

13%

12%

8%

7%

17%

7%

4%

71%

75%

65%

68%

67%

71%

65%

63%

63%

14%

13%

22%

19%

24%

22%

19%

31%

33%

0% 20% 40% 60% 80% 100%

ほとんど自社で作成(n=126)

ベースは自社、細部は委託先(n=292)

すべて委託先(n=105)

ほとんど自社で作成(n=73)

ベースは自社、細部は委託先(n=172)

すべて委託先（n=45）

ほとんど自社で作成(n=48)

ベースは自社、細部は委託先(n=104)

すべて委託先(n=27)

ﾌﾟﾛ

ｼﾞｪ

ｸﾄ規

模100人

月未

満100人

月～

500人

月未

満500人

月以

上

満足 ある程度は満足 不満

71

（3） 工期は妥当であるか

「ソフトウェアメトリックス調査 2006」の結果より、50 人月以上の規模のプロジェクトの工期

には、下記の式が成り立つ（図表 2-5-19）。

標準工期＝2.4×（投入工数の立方根）

プロジェクトの性格によってこの値よりも実績には、ばらつきがでるが、この式を基準にして「今

回のプロジェクトが標準工期よりも何％短いか」を確認し、それに対してどのようなアクションを

取れば良いのかを判断する。過去の自社プロジェクトの工期不足率とアクションの関係を整理して

おくと非常に参考になる（図表 2-5-20）。

50 人月以下のプロジェクトの場合、作業の積上げで工期を予測する。規模が小さいので全体の進

捗がよく見え、アクションが取りやすく、工期も短くかつ参加者も少ないので大きな問題になるこ

とは比較的少ない。

図表 2-5-19 標準工期

図表 2-5-20 工期差率とアクション

工期-工数グラフ

0

5

10

15

20

25

30

35

40

45

0 2.5 5 7.5 10 12.5 15

工数

全体

工期

3000人月1000人月400人月100人月15人月 2000人月

Y＝２.３８X

標準より長い工期 標 準 ２５％工期短縮 ２５％以上工期短縮

工期の標準

の考え方

金融等欠陥の発生

を無くしたい品質重

視のプロジェクトの

場合

工 数 の 立 方 根 の ２ 倍

（例：１０００人月のプロジ

ェクトは２０箇月）

・ユーザの要望

・流通業のシステム化など

に多い。

ユーザのやむを得ない外的事情で実施する場合

（対コンペ戦略、新商品の販売、株式の上場、企

業の統合など）

スケジューリ

ン グ の 対 応

策

充分なシステムテ

スト期間の確保

中日程計画の充実

（ 役 割 分 担 別 Ｗ Ｂ Ｓ 管

理）

中日程計画の充実

（週間別管理）

小日程計画の充実

（日別管理）

その他の対応策

・品質重視のテスト計画書及びテストケースの緻密化

・安定稼動のための分割立ち上げ等

・ＷＢＳによる総合計画と局面化開発

・レビューの徹底 ・テストケース充実 ・コンバージョンデータの

フル活用 ・確実な変更管理

同 左 + ・ＰＧの選抜

*標準化の徹底と実力のある一括外注の採用。

・システム範囲、対象の部分稼動

・ＲＡＤ+ＤＯＡ ・性能事前検証 ・変更管理の強化

同 左 + ・ベテランＰＭによる采配と会社あげての協力及び

監視 ・パート図での計画 ・ベストメンバー選出 ・クリーンルーム手法 ・二交代制の配置 ・顧客主体のテストチーム設置 ・パッケージの活用 ・部品の再利用 ・オープンな進捗情報管理

72

全体工期は問題のない範囲であることが確認できたとしよう。では日程計画表はどのように読め

ば良いだろうか。スケジュールの内容が妥当かどうかは、「何を基準に作成したのか」と聞くことに

よって判断できる。ただ単にバーチャートが書かれているだけのプロジェクトは危ない。バーの長

さの根拠を確認が必要である。重要なことは、仕事を週間単位で積上げた結果の計画書であるのか

どうかである。

工期、品質、生産性の具体値に裏付けされた計画書であるのかどうかを確認すれば、そのプロジ

ェクトの信頼度が見えてくる。

（4） 品質目標は提示されているか、妥当であるか

納入されたソフトウェアの品質が悪く、納入後にユーザーのテスト負荷が多く苦労したという経

験を持つ企業は多いと聞くが、一方ユーザー企業側の対応はどうかというと、品質目標を開発契約

時に提示していない場合が意外にも多い。

目標がなければ実績は評価し難いし、ベンダーに対する品質の牽制も効かない。希望する目標品

質が標準以上に高ければ工期も予算も十分に確保しなければならない。まずは、ユーザーが希望す

る品質の目標を提示することによりベンダーの意識も変わってくる。

ベンダーによっては、契約に品質目標を含むことを嫌がることがある。ユーザーが作成した要求

仕様書の質が悪い、 終工程近くになってからの仕様変更が頻発し、品質を低下させるなど、ユー

ザー責任で品質の悪化が起こるからである。このような事情を勘案し、契約項目にはしないが、両

者の努力目標として品質目標を設定する方法もある。

「企業 IT 動向調査 2007」によると、30％の企業は開発したシステムの品質に不満を持っている

（図表 2-5-21）が、ベンダーに品質目標を提示したかどうかを聞いてみると、なんと 2/3 のユーザ

ー企業は何も目標提示をしていない（図表 2-5-22）。

目標のないところに達成感もないし、評価もない。まず努力目標でもよいので、目標を提示しな

ければいけない。例えば、

「500 万円に 1 件以上のバグをつけて持ち込むな」 「稼動後は 1 億円に対して 2～6 件以上バグを出さないでほしい」

程度の目標で十分である。まずは目標を提示し、ユーザーとベンダーの両者が共同で努力すること

から始めなければならない。

73

図表 2-5-21 品質に対する不満（企業 IT 動向調査 2007）

図表 2-5-22 開発委託先への品質目標提示（企業 IT 動向調査 2007）

（5） 予算額は妥当であるか

「ソフトウェアメトリックス調査 2006」によると、10 億円以下のプロジェクトでは、生産性の

指標が、図表 2-5-5（再掲）の通り算出されている。

工期、品質、規模が生産性に大きく影響するが、これらの相関関係は、現状解明できておらず、

価額は、ベンダー間の競争入札により決められているのが実態である。

ユーザーにおける費用の算出方法は、図表 2-5-23、2-5-24 の通りベンダーからの見積を頼ってい

る企業が多いが、自らの基準を持ってベンダーの見積をチェックしている企業は予算が「予定より

も超過」する割合が少ないという結果がでている（図表 2-5-25）。

「ソフトウェアメトリックス調査」などを参考に、自社基準を持つ必要がある。

15%

9%

8%

13%

9%

9%

73%

65%

62%

73%

69%

64%

12%

26%

30%

14%

23%

27%

0% 20% 40% 60% 80% 100%

100人月未満(n=628)

100人～500人月未満(n=329)

500人月以上(n=206)

100人月未満(n=702)

100人～500人月未満(n=348)

500人月以上(n=208)

06年

度05年

度

満足 ある程度は満足 不満

20%

8%

6%

1%

70%

23%

7%

5%

2%

68%

0% 20% 40% 60% 80%

各開発フェーズ別にテスト条件を提示

納品テストから安定稼動までの目標障害件数を提示

稼動開始時から安定稼動までの目標障害件数を提示

その他

特に提示していない

06年度(n=591)

05年度(n=861)

74

（再掲）図表 2-5-5 開発における生産性指標

指標 数値 コメント

KLOC／人月 1.2 加重平均 言語別には分析していない

FP／人月 9.8 加重平均 IFPUG のみ対象。

KLOC との比較は 118LOC/FP

予算(万円)／人月 102 万円 回帰式 加重平均は 106 万円／人月

予算(万円)／KLOC 91 万円 回帰式 加重平均は 74.1 万円／人月

予算(万円)／FP 12.6 万円 回帰式 IFPUG のみ対象。

工数(人月)／画面数 1.53 回帰式 プロジェクトの初期に活用する。

FP／画面数 16.5 回帰式 同上

図表 2-5-23 基本計画策定時に採用している予算確定方法（企業 IT 動向調査 2007）

図表 2-5-24 開発着手時に採用している予算確定方法（企業 IT 動向調査 2007）

29%

5%

2%

12%

2%

44%

19%

2%

44%

10%

2%

16%

1%

50%

18%

1%

0% 20% 40% 60% 80%

過去の類似事例を参照し算出

概算FP基に算出

概算LOCをもとに算出

画面、帳票数を基に算出

WBSを定義し算出

ベンダーからの見積を基に決定

決められた予算枠を元に決定

その他

06年度(n=771)

05年度(n=892)

14%

5%

3%

18%

5%

49%

20%

1%

17%

11%

3%

24%

8%

59%

17%

1%

0% 20% 40% 60% 80%

過去の類似事例を参照し算出

概算FP基に算出

概算LOCをもとに算出

画面、帳票数を基に算出

WBSを定義し算出

ベンダーからの見積を基に決定

決められた予算枠を元に決定

その他

06年度(n=770)

05年度(n=878)

75

図表 2-5-25 予算算出方法とシステム開発費用の状況（企業 IT 動向調査 2006）

35%

29%

21%

16%

17%

15%

54%

54%

47%

54%

51%

46%

11%

17%

32%

30%

32%

40%

0% 20% 40% 60% 80% 100%

概算FP、画面・帳票数、WBS等で

自ら規模算出(n=302)

自ら規模算出せず、ベンダーからの

見積をもとに予算決定(n=302)

概算FP、画面・帳票数、WBS等で自ら規模算出(n=173)

自ら規模算出せず、ベンダーからの

見積をもとに予算決定(n=139)

概算FP、画面・帳票数、WBS等で

自ら規模算出(n=65)

自ら規模算出せず、ベンダーからの見積をもとに予算決定(n=68)

100人

月

未満

100人

～500

人月

未満

500人

月

以上

予定通り完了 ある程度は予定通り完了 予定より超過

76

（6） 社内体制、ベンダーの確保はできるているか

大規模プロジェクトの場合、 適なプロジェクト責任者が専任していることが重要である。

ベンダー側から見た、ユーザー側の主担当者（キーマン）の資質を評価したものが図表 2-5-26 で

ある。ベンダー側の期待と見て良い。

ユーザー側のリーダーとベンダー側のリーダーが気持ちと力をあわせて協力しないことにはプロ

ジェクトの成功はおぼつかない。

ユーザー側のプロジェクトマネージャーの資質はプロジェクトの成否に非常に大きな影響力をも

たらす。特に業務仕様の決定に対しての影響力は大きく、業務に精通したユーザー側プロジェクト

マネージャーがいる場合は、仕様決定の遅れは出ないことが実証されている（図表 2-5-27）。

このプロジェクトが成功すればその恩恵を一番享受できるのはユーザー企業であるし、失敗すれ

ば、その損害を多面的に大きく蒙るのもユーザー企業である。

もちろんベンダー側も失敗すれば金額的な損害を蒙ることにはなるが、迷惑をかけてしまった関

係者に謝罪するのはユーザー企業である。そのためにはユーザー企業からは、そのプロジェクトに

適な人材を選抜して専従させなければならない。

一方、ベンダー側のプロジェクトマネージャーの資質・経験は、納入ソフトウェアの品質に大き

く影響する。ベンダー選定時はこのプロジェクトマネージャーの資質経験を十分に調査、対話し、

納得がいかない場合は交替を早めに申し出た方が良い（図表 2-5-28）。

77

図表 2-5-26 ベンダー側から見たユーザー側プロジェクトマネージャーの影響度

ユーザー側プロジェクトマネージャーの資質

高 中 低

システム開発のオーナー意識 高い 曖昧 無し

契約金額 必要と認めた分は承認 できるだけ安いほうがよ

い 値切りに値切る

システム要求仕様書の定義 完全 曖昧 皆無

後付の智恵の仕様増加

ソフトウェア仕様書のチェック 約束納期厳守

緻密なレビュー

約束納期甘い

曖昧なレビュー

約束納期守れず

レビューはなし

開発規模 ほぼ約束どおり やや増加 大幅増加

仕様変更 ほとんど無し 頻発 多発

開発時の追加支払 不要、有れば、

全額支払 大幅な値切り 要求すれど、ゼロ回答

カットオーバー 計画通り、

または、早期化 納期確保に苦戦 納期遅れ常態化

粗利率 高い 計画より低下 低い、場合によっては、

赤字

運用時のトラブル ほとんど無し 時々 頻発

運用費用 低コスト 増加しがち 高コスト

キーマンの常用言 当社分の開発責任作業

は実施します

できるだけ開発会社が

実行してください

当社では IT は判らない

から、すべて開発会社

にお任せします

完了時の発言 また次の開発もお願い

します

曖昧 次は別のベンダーと開

発したい

開発担当ベンダーSE の発言 また次の開発もください （キーマンが変われば考

えます）

2 度と一緒に仕事をした

くない

78

図表 2-5-27 ユーザー側プロジェクトマネージャー能力と品質（ソフトウェアメトリクス調査 2006）

図表 2-5-28 ベンダー側プロジェクトマネージャー能力と品質（ソフトウェアメトリックス調査 2006）

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

1 2 3

工期遅延率

ユーザープロマネ業務精通度

遅延度２０％以上

1.十分精通していた 3.精通していたとはいえない2. ある程度のレベルまでは精通していた 4.全く経験も知識もなかった

PM業務精通（選択肢）

-1 予定より早い 2 遅延20%未満

0 予定通り 3 遅延50%未満

1 遅延10%未満 4 遅延50%以上

遅延率（係数）

PMスキル(ベンダ)別欠陥率

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1.8

2.0

1 2 3 4 5 記入なし

PMスキル（ベンダ）

欠陥

率

平均

79

（7） 稼動条件、移行方針は決まっているか、内容は妥当か

終工程近くになってから移行準備をするのではなく、プロジェクトを開始した初期段階から稼

動条件、システムの切り替え方針・方法をあらかじめ設定しておかねばならない。

システム再構築の場合、既存システムから一挙に新システムに切り替えるので、この負荷は想像

以上に大きい。特に業務改革を実施し新ビジネスモデルに切り替える場合、ベンダー側のみならず、

ユーザー側も新規開発の 2 倍以上の負荷がかかる。

システム設計時から、切り替え方法を予測して準備しておかないと移行時につまずきやすい。

① カットオーバー（サービスイン）の条件

カットオーバー（サービスイン）の確認すべき点として、以下 9 点を挙げる。

ａ．プロジェクト開始時（又は、基本設計完了時）に移行計画および稼動開始条件を設定する。 ・品質目標を設定し、実績を管理する ・システム／ユーザー部門／運転部門の各々の稼動条件を明確化する

ｂ．プログラムの全ルートにテストデータを通す。 できれば「カバレージモニター（全プログラムの何％をテストしたか確認できるツール）」で確

認してあることが望ましい。 ｃ．インターフェースを含めて関係システムとの正確性、処理性（処理時間、レスポンスタイム

など）を確認する。 ・日次処理がその日に終わることを確認する（システム能力の確保） ・実機環境とシミュレーション環境でのストレステストを実施する

ｄ．ハードエラーを人為的に起こさないと確認できない場合の対策を検討する。 ｅ．出力書類を実際に使用して、運用上の問題が発生しないことを確認する。 ｆ．万全の対策を取ったつもりでも、問題が発生することはあり得るので、その準備をする。 ｇ．SE は、稼動開始した日は定時（残業しない）で帰宅できるという自信をもって作業に当たる。 ｈ．プロジェクトの責任者は部下に具体的に質問しその結果を聞いて稼動開始可否を判断する。 ｉ．それでも問題が発生した場合には、「問題は 3 倍根深い」と考えて対処する。

② システム切り替え方法

システム切り替え方式は、切り替え時に他のシステムを含む全体を停止するか、停止しないか、

および、新システム全体を一括して切り替えるか、部分的に切り替えるか、の組み合わせによって 4通りの方式がある。

①全面停止一斉切り替え型 ②部分停止部分切り替え型 ③無停止部分切り替え型 ④無停止全体切り替え型

それぞれの得失は、図表 2-5-29 の通りである。どの方式がふさわしいかを事前に検討し、それに

応じた準備をすることが必要である。

80

無停止切り替え型については、「そんなことは出来ない」という人が必ずいるが、実際に実行して

みると、「こんな楽な切り替えは始めて…」と愁眉を開くことになる。いつでもテストができ、品質

が満足するレベルに至った時に切り替えればよいのであるから、精神的な負担は少ない。ただしシ

ステム切り替えのためのプログラムの準備が少々必要である。

すべてのシステムでこの方式が採用できるとは考えにくいが、システムの再構築をする場合に、

一度は議論して欲しい方法である。

システムの稼動時の移行方法は、「一斉に既存システムを停止して一斉に切り替える」方法だけで

はない。十分な準備があればもっと気楽に切り替えることができる方法もあることを認識してほし

い。

図表 2-5-29 システムの切り替え方法

（8） 進捗報告のサイクルが決めているか、頻度は妥当か

システム開発は「便りのないのは良い便り」と思っていると、とんでもないことになる場合が多

い。「便りがないのは怪しい証拠、放っておいたら火の車」と覚悟し、無理やりにでも報告を聞く習

慣をつけ、被害を減らしている会社もある。

もともと建築やプラント建設などと異なり、実態が見えにくいのがシステム開発プロジェクトの

特徴である。進捗報告書が本当に実態を表しているかどうかを確認するために、開発現場に出向き、

SE の顔色を毎月眺め、判断を適格にしてプロジェクトを成功に導いた CIO も存在している。

計画承認時に報告サイクルを決めてから開発にとりかかる習慣をつけなければならない。

切替時無停止 切替時停止

部分的切替

全体一括切替

①全面停止一斉切替型

▲リスク大

ただし一般的な切替方法

○全てのプロジェクトに適

用が可能

④無停止全体切替型

◎リスク小

△準備負荷大

システム設計の 初から準備してお

くことが必要

③無停止部分切替型

◎リスク 少

△準備負荷やや大

ただしシステム設計の 初から準備

しておけば、それほどおおきな負荷に

ならないことが多い

②部分停止部分切替型

○リスク小

△切替回数が多いので，負荷は

かかる。

△全体整合性を取る準備が必要

81

（9） プロジェクトマネジメントに抜けがないか

近のシステム開発の特徴を捉え、プロジェクトマネジメントの新しい発想法を集めたのが、図

表 2-5-30 の「Ｕ字型開発法」である。システム開発時に残業残業にならず、ユーザー満足度の高い

システムを作るために効果的である。

Ｕ字型開発手法による改革

①企画段階のシステムコンセプト確立 要求仕様の変更は、企画段階のユーザ・リーダのシステム内容理解度の向上で抑制する

②ユーザーによるシステム要求： 利用者がシステム機能要求を、IT 部門が非機能要求を提示する、「裏を読め」はダメ

③見積の透明性： リスク要因についてのベンダーとの対話 ④徹底レビュー： 作成時間の 10％以上時間をかけて慎重に ⑤ユーザビリティの確保： ユーザビリティテストによる利用容易性確保と品質向上 ⑥仕様変更の可視化： 仕様の一貫性を確保する ⑦目標を持って管理： 目標の有効性とフォロー ⑧単体テストの徹底： データコンバージョンプログラムは単体テスト開始前に準備 ⑨単体テスト完了でユーザーに開示： プログラマーが側にいる間に完了を ⑩移行計画は早期準備： 開発当初より計画し準備 ⑪結合、総合、実運用試験の min 化： 単体テストの徹底 ⑫データベースの整合性： データベース間の整合性チェック ⑬カットオーバーの日は定時帰宅を： ノートラブルで稼動開始する ⑭利活用が 重要： 投資評価の実施、使いこなしが 重要

図表 2-5-30 U 字型開発方法

36Copyright©2006 JUAS, All Rights Reserved

要求定義

基本設計

詳細設計

プログラム設計書 単体試験

プログラム製造

総合試験

実運用試験

開始 終了

要求定義

基本設計

詳細設計

プログラム設計 単体試験

プログラム製造

機能結合試験

総合試験

実運用試験

機能確認の重点

使用者への開示拠点

Ｍｉｎ化

Ｍｉｎ化

Ｍｉｎ化

・各フェ ーズの発生欠陥は、相対するフェーズ　のテストで欠陥を発見する。

・ 後のフェ ーズの総合試験または実運用試　　験終了後になって仕様の欠陥が発見される。

　

ﾕｰｻﾞｰによるシステム要求

徹底レビュー

単体テスト開始前に全データコンバージョ ン完了

機能結合試験

ユーザビリティ１

ユーザビ

リティ２

日本的開発環境にあった開発手法

IT戦略・企画

見積透明性（品質・工期・

生産性）

調達（見積・契約）

新ビジネスモデル

保守・運用

利活用

ライフサイクルコスト（安定性・

信頼性）

ＩＴ投資効果評価

　　Ｖ字型開発からＵ字型開発へ（日本の開発環境に適した手法を）

ＤＢパトロー

ル

要求定義から

設計・試験までのトレーサビリ

ティ確保

外注プログラマーが一緒に仕事をしている間にユー

ザーにテスト結果を提示し確認・修正する

全工程を通じて可視化、指標化ができる

プロジェ クトマネージメント（ＥＡＳＥ）の実施

＊＊

注：＊＊開発用ＲＦＰ

　　＊要件定義用ＲＦＰ

＊

移行移行計画

開発保守問題と解決策

82

2．6 開発完了後の IT 投資評価（事後評価）

「企業 IT 動向調査 2007」によると、開発完了後の IT 投資評価（事後評価）を実施していない企

業は、全体のの実態は図表 2-6-1 の通りで、売上高 1 兆円以上の企業では 11％と少数派になってき

たが、全体としては半数近くの企業が実施していないという状況である。

図表 2-6-1 企業規模（売上高）別事後評価の実施状況

事後評価が行われない状況には、以下のような理由があると考えられる。

① 時間差

IT 投資評価は、投資費用、投資効果、開発実績を総合的に評価することである。開発実績は IT部門が評価すればよいが、効果はシステムの利用部門の責任となる。特に戦略型プロジェクトの場

合、システムの企画時とシステム利用時の時間差の影響で、環境がかなり変化している場合もあり、

実績を出しにくい。このため、前述した通り、前提条件を明確化し効果を予測をすることが必要で

ある。

② 負荷

効果測定には負荷がかかるため、「後ろ向きなデータを集めるくらいなら新しいシステム開発をす

る方が企業の役に立つ」と、次の新規開発プロジェクトに走りたがる人が多い。また、すべての項

目について 100％効果がでることはなく、特に IT 部門が弁明をさせられることが多い。例えば、

「レスポンスタイムが遅いので入力に時間がかかり予定通りの省力化はできません」 「システムの品質が悪く手作業でカバーをせざるを得ません」

などと、利用部門は効果目標が達成できない理由を IT 部門に押し付けてくる。

各担当者別に見ると、システム化して何らかの作業負荷増加を担う部門と、作業が軽減される部

門が生じてくる。この場合、作業負荷が増加する部門は必ず不平を言ってくるので、何らかの対応

策を講じる必要がある。一方、省力化する予定の部門も「いざ減員する」となると何らかの要求を

出してくる場合は多い。

11%

39%

13%

22%

19%

42%

37%

54%

53%

70%

46%

24%

33%

26%

11%

0% 20% 40% 60% 80% 100%

全体(n=775)

10億円～100億円未満（n=72）

1000億円～1兆円未満（n=104）

100億円～1000億円未満（n=207）

1兆円以上（n= 27）

すべての案件を実施 一定金額以上の案件は実施 その他の基準

83

このような場合の対策は、利用部門と IT 部門の間に、人事スタッフや経営企画部門が間に入り、

効果の議論に加わることである。あるいは監査役や経営者直属のスタッフを IT 投資評価の支援者と

して任命することも考えられる。

③ 組織文化の問題

「上手く行っていないじゃないか。だから IT 部門はダメなんだ」と経営者がひと言、発した途端

に、IT 投資評価は停滞することになりかねない。

IT 投資評価報告会は叱責する場ではない。この点を社長、経営者は十分に理解することが必要で

ある。「IT 投資報告会は前向きな対策を検討する会である、もし非難めいた発言をした場合は退場

してもらう」ことを前提に開催し、うまくやっている企業もある。

経営者自らが前向きな姿勢を持ち、相談相手になるつもりで対応することが重要である。部下の

失敗は IT が分ろうと分るまいと、 後はすべて経営者の責任となる。

株主あるいは顧客には、すべて自分の責任として説明せざるを得ないことを認識し、真実が報告

される企業の雰囲気、文化をつくっていくことが問われる。それでも報告が上がってこない場合は、

経営者自ら利用状況を視察したら良い。慧眼を持っている経営者ならば、実態と問題を見抜くこと

に時間はさしてかからないはずである。

84

2．6．1 事後評価段階における経営戦略との適合性（C-1）

開発終了後、企画承認時と開発開始時（実行計画作成時）に作成したプロジェクトの計画に対し

て、経営戦略との適合性の観点から結果を評価することは重要である。

図表 2-6-2 の通り、開発完了後（事後評価）における、IT 投資評価の重要ポイントをチェックリ

ストとして挙げ、当該評価を行うにあたって、検討すべきポイントを整理する。

図表 2-6-2 C 開発完了後（事後評価）における投資評価チェックリスト

点数 質問内容

納得← →不満

わ

か

ら

ない

（1）プロジェクトの結果は企業戦略と適合しているか、補完すべき要素は必要十分か

4 3 2 1 0

（2）成功要因、失敗要因が整理され、企業のノウハウとして蓄積される仕組みができているか

4 3 2 1 0

１

経営戦略

との適合

（3）運用、利活用の体制は十分か 4 3 2 1 0

（1）当初の開発で取り残した機能のフォローの仕方は明確か 4 3 2 1 0

（2）総合効果表による確認（稼動工期、稼動後の品質、投資費用の対計画比など）ができているか、結果は妥当か

4 3 2 1 0

（3）システムライフサイクルコストは計画通りか 4 3 2 1 0

２

投資費用

（4）リスク計画は妥当であったか、どのようにフォローしたのか 4 3 2 1 0

（1）一次効果、二次効果、三次効果（ROI）と、フォローの仕方を確認しているか（さらに追跡評価すべき項目は何か、追加予算の必要性はあるか）

4 3 2 1 0 ３

投資効果 （2）KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの

計画対比は確認したか、問題はなかったか 4 3 2 1 0

（1）運用目標値（含む SLA）が設定されているか、その内容は妥当か 4 3 2 1 0

（2）運用・利活用のリスクは何か、関係者の配慮事項は明確か 4 3 2 1 0

４ プロジェクト

マネジメント （3）顧客迷惑度指数を設定しフォローしているか 4 3 2 1 0

経営者・プロジェクトの責任者が確認し、それぞれ項目について、「4：納得している」「3：まあ納得している」「2：や

や不満を感じている」「1：不満」「0：わからない、判断できない」より選択し、それぞれ合計点が一定基準以下の場

合は再度担当者に説明を求める、あるいは議論しなおす必要がある。「0：わからない」を選択した項目は、再度担

当者に説明を求める、あるいは議論しなおす必要がある。

85

（1） プロジェクトの結果が企業戦略と適合しているか、補完すべき要素は必要十分か

「プロジェクトの目的は達成されたのか」「前提条件の変化があったとしても、大きな目的は達成

されたのか」「もしされていない場合は何故そうだったのか」をじっくり反省し、今後の企業戦略の

立て方、経営方針に反映させる事項は何かを見極め、正しいノウハウの蓄積を図らねばならない。

（2） 成功要因、失敗要因が整理され、企業のノウハウとして蓄積される仕組みができているか

失敗から真実やノウハウを得られれば、それもまた収穫である。まだ目標を達成できていない場

合は、何を補完すれば達成できるのか、それとも計画が杜撰であったため未達成だったのかを見極

め、各種のアクションをとらなければならない。

稼動後間もない時期の反省であるので、すべてが完璧に整理できてはいない。細かいことにとら

われず、失敗の本質を捉え、素直に反省すべき点は反省し、対策を採るべきところは確実にフォロ

ーするのが重要である。

完了報告会のリーダーは、弾劾裁判の雰囲気にならないように注意しなければならない。

（3） 運用、利活用の体制は十分か

開発が完了したときから、運用の緻密さと利活用の智恵が要求される。運用体制図、運用計画、

利活用方針と進捗状況の報告が求められる。

同じパッケージを活用するにしても、十分に活用できる企業もあれば、使いこなせない企業もあ

る。その差は環境の違いもあるが、智恵の出し方の差である場合も多い。

「どうすれば使いこなせるのか」を議論し、利用者をリードできる人物が必要になる。またコン

ピュータシステムの管理が正確、円滑でなければ期待された効果は生まれてこない。この見極めの

時期がこの完了報告会でもある。

86

2．6．2 事後評価段階における投資費用（C-2）

（1） 当初ので取り残した機能のフォローの仕方は明確か

本ガイドラインでは、「2.4 構想・企画段階」「2.5 開発実行段階」で前述した通り、予算を絞り、

開発してみてから、本当に必要であれば追加機能を開発することを推奨している。その場合、利用

状況、効果の明示性を見て、予算を追加し、機能の追加開発を行うかどうかの決断が必要になる。

機能を追加することは、利活用を推進するための潤滑材になる場合もある。必要なものは投資して

でも、開発あるいは導入したシステムを使いこなさねばならない。

(2) 総合効果表による確認（稼動工期、稼動後の品質、投資費用の対計画比など）ができているか、結果

は妥当か

① 工期

稼動予定時期が延びた場合は、その理由と今後同じことを繰り返さない対策を検討しておかなけ

ればならない。ソフトウェア開発の難しさは、その都度成功要因が変わることである。

全く同じプロジェクトを、全く同じメンバーで開発することはあり得ない。したがって、何か問

題は必ず起こる。複合要因の関係は、図表 2-6-3 のように、工期、品質、生産性、ユーザー満足度

の総合評価表に基づき議論するのが良い。

② 稼動後の品質

ベンダーは各プログラムをどの程度ケーステストしたのかを、品質確保の 1 つの手段としている

が、ユーザーが望むことは、「納入されてきたときにバグがない」ことである。

「納入以降から安定稼動までの欠陥数」が 1 つの尺度である。JUAS が実施した「ユーザー満足

度プロジェクト」では、分りやすい目標値として、「納入時の欠陥数が、500 万円につき 1 個程度」

という尺度を提示している。稼動後の欠陥数は、プロジェクトの特性に応じて計画時に目標設定し

た「1 億円につき 2～6 個」になっているかどうかである。修正の難易度に応じた個数把握などの変

化があって良い。

ユーザー企業は FP（ファンクションポイント）法はほとんど採用していない。仮に IT 部門は FP法を理解していても、利用部門は理解しにくい指標である。ステップ数（LOC：Line of Code）と

いう方法もあるが、「コピーした分はどう扱うのか」などユーザーには分りにくい基準である。結局、

ユーザーに理解しやすいのは発注金額である。難しい評価値を提示しても理解されなければ何の意

味もない。

仕様変更は重大な欠陥の素になる。仕様変更管理がどのようになされたのか、仕様変更率はどの

程度であったかも反省材料になる。仕様変更率が一定の割合に収まるよう、また、大きな仕様変更

をしないよう、ユーザーは努力しなければならない。

87

③ 投資費用および生産性

FP/人月、KLOC/人月、金額/人月のどれで評価してもよいが、できるだけ複数の指標を活用する

ことが重要である。

投資はリスクを伴っている。開発を開始すれば、予算通りにいかないことはままある。ある程度

ならばリスク予算として IT 部門が準備をしている企業もある。

問題は理由である。突然国の法制度が変更になり、急遽機能を追加する必要があった場合などの

費用追加は承認せざるを得ない。

問題は、メタボリックシンドロームのように、使わない機能が贅肉としてついていないかどうか

である。無駄な機能、使われない機能は早期に償却をすることが必要である。

図表 2-6-3 総合評価表

クラス

工期

工期短縮率＝1－

（実工期/標準）＊1

品質

納入時以降に発見され

た障害数／基準量 ＊2

生産性

FP/人月、KLOC/人月

金額/人月

ユーザー満足度＊3

1 20％以上の短縮 3 倍以上良い 20％以上高い 満足度 81～100％

2 20％以下の短縮 1～3 倍良い 1～20％高い 満足度 61～80％

3 基準値 基準値 基準値 満足度 41～60％

4 20％以下の延長 1～3 倍悪い 1～20％低い 満足度 21～40％

5 20％以上の延長 3 倍以上悪い 20％以上低い 満足度 0～32％

＊1 標準工期＝2.4×（計画投入人月の立方根）

＊2 例えば 1 個/500 万円など、稼動後の欠陥数が 6 個/億円、あるいはライフラインシステムならば 2 個/億円な

ど自社基準による

＊3 関係者の全員の総合満足度をアンケートで 5 段階評価してもらい 100 点評価法に換算し直した値

（3） システムライフサイクルコストは計画通りか

既に運用段階に入っているので、システムライフサイクルコストは、高い精度で計算することが

可能である。「開発費用に対して何％程度が保守費用、運用費用として生じるのか」「その削減に向

けた対策はどのようになる見込みか」なども報告が必要である。

（4） リスク計画は妥当であったか、どのようにフォローしたのか

見積時あるいは計画時に立てたリスク計画は、今回のプロジェクトでどのように活用されたのか

をチェックし、自社のリスク計画のレベルアップを考える。自社のリスク計画が有効になればなる

ほど、プロジェクトの失敗は減少する。まさにシステム部門の宝物である。

88

2．6．3 事後評価段階に効果実績評価（C-3）

事後の投資効果の評価は、 も重要で、かつ、難しい問題である。この問題を解く秘訣がいくつ

かある。

1 つは、計画時に約束した効果評価は、どのようにしたら測定可能かを考え準備することである。

できれば人手を煩わさずに算出できるように、システムの中に効果評価算定が可能な手段を組み込

んでおくことが望ましい。

例えば、誰が何回システムを活用したのか測定できるように、利用回数測定機能を組み込んでお

く、顧客データベースの中に新規顧客数をカウントしておく、在庫回転率を自動算出するなど工夫

はいくつもある。

「ISO/IEC 9126-1」品質モデルの基準には含まれていないが、利用頻度、効果測定機能をシステ

ムの中に組み込まないと効果測定は難しい。

ユーザー満足度も自動的に回答が得られる仕組みをあらかじめ準備しておくことも可能である。

測定不可能なものはアンケートや個別分析に頼らざるを得ないが、計画段階で効果測定機能をシス

テムの中に持ち込んであれば、効果測定負荷は大幅に減少する。（図表 2-6-4）

省力化効果は管理者の意思で左右される要素が多い。

システムの稼動前に組織統合などでできるものはあらかじめ実施するなどの心構えを見せること

が重要である。約束したことは実行する文化を持っている企業は強い。

（1） 一次効果、二次効果、三次効果（ROI）と、フォローの仕方を確認しているか（さらに追跡評価すべき項

目は何か、追加予算の必要はあるか）

（2） KPI、ユーザー満足度、他社比較（ベンチマーク）、実施しないリスクの計画対比は確認したか、問題は

なかったか

計画時に算出した一次効果、二次効果は出来れば、別々に把握することが望ましい。

ROI、KPI がどのような成果をもたらしたのか計画外の効果も発生するのが常である。これらを

含めて良いものは認めて表彰し、足りないものはフォロー対策を採るのがこの段階の主眼である。

計画時とは環境に変化があれば前提条件を変えた結果の説明をすればよい。

開発完了後半年、あるいは 1 年後の報告であれば、まだ効果把握は途中経過段階という場合もあ

る。追加予算が必要なものは、予算をつけて予定以上に効果が上がるようにフォローする必要があ

る。

89

図表 2-6-4 ユーザー満足度の評価（事後評価）

NO 質問 目標尺度 実績評価 備考

1 開発投資・戦略価値などプロ

ジェクトの総括目標について

満足していますか

4 以上 1,2,3,4,5

2 実現した業務プロセス、シス

テム機能について満足してい

ますか

4 以上 1,2,3,4,5

3 貴社 IT 部門・利用部門・ベン

ダー3 者の協調体制について

満足していますか

4 以上 1,2,3,4,5

4 工期は計画工期を守れまし

たか 3 以上 1,3,5

計画対比

（+、― ％）

工期＝2.4（投入人月の立方根）との比

較

5 延長、3 計画通り 1 計画より短い

5 品質実績について満足してい

ますか 4 以上 納入後の欠陥数

（○個/500 万円）

稼動後の欠陥数

（○個/億円）

納入後の欠陥数（○個、○個/500）

（目標は 1 個／500 万円以下）

6 生産性実績について満足し

ていますか 3 以上 1,2,3,4,5

○\/FP、○\/ＭＭ

○￥／ＬＯＣ

FP/人月、ＬＯＣ/人月

￥/人月などの把握でも良い

7 利用容易性について満足し

ていますか 4 以上 1,2,3,4,5

8 効果実績について満足してい

ますか 4 以上 1,2,3,4,5,6 効果実績は経過値での判定となる

9 投資回収年数は何年ですか （ ）年

5．非常に満足 4．やや満足 3．普通 2．やや不満足 1．非常に不満足 6．その他(測定不可能など)

(注 1)回答者は経営者、CIO、利用部門責任者などのキーマンがチェック用としてこの表を活用する。

「参考データ 各プロジェクトのデータ」この表と上記ユーザー満足度の表を合わせて回答を求める。

（業種

（輸送機器）

業務分野

（販売管理）

システム形態

（汎用、クラサバ、WEB）

開発形態

（新規／再構築）

開発総額．自社開発分

計画（ ）万円

実績（ ）万円

開発総人月

計画（ ）人月

実績（ ）人月

開発時期

○ 年 ○月

開発フェーズ（ ～ ）

工期

計画（ ）月

実績（ ）月

開発規模

（ ）FP

（ ）LOC1

（ ）LOC2

ライフサイクルコスト 5 年間

計画（ ）万円

投資回収年数

（ ）年

※システムライフサイクルコストは特別に期待がなければ、5 年間で、試算する。

90

2．6．4 事後評価段階におけるプロジェクトマネジメント （C-4）

（1） 運用目標値（含む SLA）が設定されているか、その内容は妥当か

（2） 運用・利活用のリスクは何か、関係者の配慮事項は明確か

運用段階では、改めて運用状況、運用問題、効果発揮、使いこなしへの努力を関係者全員で認識

しておいた方が良い。

・ 稼働率目標の設定値は、いくつであり、費用はいくらか、うまく運用されていることをどのよ

うに証明するのか、SLA は設定してあるのか ・ 運用費用を削減することは何をすることなのか、どの程度の効果になるのか ・ 保守作業、運用作業の手順は内部統制の基準をクリアできるものか ・ データが急激に増加した場合は、どのような現象になるのか、顧客に迷惑がどのようにかかる

のか、運転管理者だけでは対応できない問題もあるので関係者が注意しあう文化が必要になる。 運転開始されれば運用の段階の目標値が問われる。

① 稼動率

通常重要な基幹業務システムの稼働率の目標値は 100％である。しかし、100％の稼動率を実現す

ることは難しい。稼働率の計画と実績の差は、バックアップ機の有無にもよるところはあるが、実

際はバックアップ機の有無による稼働率実績の差は意外に少なく、稼働率に影響するのは、データ

ベース障害、ウイルスなどの外部からの侵入、電源故障などの不慮の障害である。必要があればそ

のような事態を十分考慮し、システム構成、体制を整備しなければならない。

② 稼動品質目標

「システム全体としては動いていたが、プログラム保守作業を間違えて、誤った結果を顧客に提

出してしまった」「システムが停止して、時間通りに書類が利用者の手元に届けることができなかっ

た」「外部からの入力データを間違えてセットし、正しい結果を利用者に渡すことが出来なかった」

などの障害は、稼働率とは別に稼働品質目標として管理しなければならない。

「稼動品質目標＝年間不都合事発生件数÷保持プログラムのステップ数（またはプログラム本

数）」を目標にしている企業もある。年間不都合事発生件数が 100 件で 5000 万ステップの資産があ

れば 1 万ステップあたり、で 0.02 件であり、100 万ステップあたり 2 件となる。これはかなり優秀

な値である。100 万ステップで 1 件をきればさらに優秀な状況である。

目標値があれば問題の把握は容易になり、関係者全員の努力目標になる。信頼度の指標の 1 つと

して活用したい。

（3） 「顧客迷惑度指数」を設定し、フォローしているか

運用に入ると、開発とは別の利用上の評価尺度が必要になる。その 1 つが「顧客迷惑度指数」で

ある。これは、顧客に迷惑をかけた影響度の基準ポイントを定めておき、ミスや迷惑をかけた場合

は、その基準に基づき迷惑度合いを評価する。組織全体で一定期間ごとに、その合計ポイント数を

91

集計し対策を立て、また改善する PDCA サイクルをまわす。例えば、

・システムが 1 時間以上停止した場合：100 点 ・入力ミス、あるいはプログラムミスで顧客に間違った情報を提供した場合：30 点 ・説明不足、あるいは操作説明書のミスで迷惑をかけた場合：20 点

など、顧客に迷惑をかけた件数と定められたポイントをかけあわせ、合計点数で毎月の成績を判断

する。

この「顧客迷惑度指数」は、IT 部門の要員や、プログラマーの努力だけではなく、業務部門が一

緒になって努力しないと下がらない指標である。ともすればシステム部門が運転を止めた、プログ

ラムにミスがあったと責められるが、この指標は利用部門が協力していかないと達成できない指標

である。

92

2．7 （参考）新システム稼動開始の承認

システム開発の 終局面では、「新システムができたが、まだプログラムやデータにかなり欠陥が

ありそうだ、稼動すべきかどうか」と、プロジェクトの担当者が相談に来る時期がやって来る。

安全を取ればもう数回総合テストを繰り返したいところであるが、外部に稼動時期の約束をして

あるので、伸ばせないし、費用もない。さてどう判断すれば良いかと悩むことになる。「何とかなる

だろう」と本番に突入した結果、大トラブルになり、顧客に迷惑をかけることになる。

切り替え前には総合テストは必ず実施している。「ソフトウェアメトリックス調査 2006」による

と、このときに出てきた欠陥数のおおよそ 1/3 は、稼動後にも現われる。

「稼動条件」としての指標を持つことが必要であり、稼動開始時の GO サインを出す条件は以下

のものがある。

条件 1：単体、結合、総合テストをしてないプログラムは存在しないこと 条件 2：大規模な欠陥は発生しないと予想できること 条件 3：稼動直後、「1 日間に発生すると予想される欠陥数＜待機している SE が半日で対応でき

る欠陥数…（安全係数を 2 倍にみた場合）」の関係式が成り立つこと 条件 4：一定時間稼動後に、物流、商流、金流、情報流含めて致命傷は現われないこと 条件 5：社内システムならば稼動当初 3 倍の処理能力を持っていること、インターネットで一般

顧客からの入力が集中する場合でも対応可能な処理能力を備えていること 条件 6．その他はシステムの特性で条件をつけ、それをクリアできればカットオーバーしてもより

条件になる。

逆に稼動を延期する場合のリスクもある。

条件 1：予算は大丈夫か、既存システムの費用、新システムの費用の両方を維持せざるを得なくな

る。延長期間も、どこまで延長すれば良いのかが、問われる。 条件 2：協力会社の SE は継続確保可能が可能かどうか。すでに SE は相当に疲弊しているはずな

ので、短期延長でシステム精度を上げることは限界がある。思い切って相当な期間延長を

せざるを得ない。 条件 3：その期間、旧システムを使用し続けることになるので、旧システム用の資源（所定の印刷

用紙など）を確保することは可能か

このような条件のバランスを取って、稼動延長の是非を決断することになる。もっと大雑把な判断

をせざるを得ない場合は、総合テストで発生した欠陥数の 1/3 が、稼動後にあらわれると仮定し、

「社内の業務システムならば、1 億円につき 6 個以上の発生が予想される場合は赤信号」 「シビアな条件が要求される乗り物の運行管理システム、銀行の勘定系システムなどは、致命傷

がなくても、1 億円について 2 個以上発生する予想の場合は稼動延長」

などと状況、システムの特性に応じて考える必要がある。いずれにしても欠陥ゼロは難しいので、

微妙な判断を要求されることになる。

93

3．まとめ

IT 投資評価は一般に、図表 3-1 のような理由で難しいとされている。しかしながら、それらに対

する対策ももちろんある。

図表 3-1 IT 評価の難しさと対策

区分 理由 対策

特性 ①費用対効果が見えにくい

案件が多い

ROI だけでなく KPI、ユーザー満足度、他社比較、投資しないリスク分析

など複数の方法で判定

特性 ②複合要因による効果の対

応が一意的でない

終的には営業利益で判定する

特性 ③省力化が実現してもその

判定が難しい

・省時間を何に使うのかをあらかじめ決めてその効果を把握する

・省力化案件は人事部を入れて確認する

特性 ④インフラ整備は効果が短

期的に計算し難い

・レスポンスタイム、費用、稼働率、スパンメール排除数、ユーザー満足

度など KPI を設定し確認する

方法 ⑤効果把握のできる人材が

いない

・IT 部門だけでなく、経営企画、システム監査、経理などの専門家を効

果把握支援者に任命する

方法 ⑥効果を判定するタイミング

のとり方が難しい

・稼動後半年、あるいは 1 年後などとあらかじめ決めておく。 終結果で

なくてもよい。

後に、IT 投資評価の推進のための注意事項をまとめる。

（1） IT 投資評価にマネジメントサイクルを取り込むこと

「測定できないものに進歩はありえない。PDCA は回らない」と効果把握できる方法を講じるこ

とである。

IT 投資評価は、効果と投資費用の両方を評価することであるから、投資の工期、費用、品質、ユ

ーザー満足度は評価可能である。実績把握（事後評価）をするためにも、評価計画を企画時、実行

計画時に準備する事前評価が非常に重要である。難しく考えずに、まずは初めることが必要である。

往々にして失敗プロジェクトは評価を公表するのを嫌がるものであるが、成功プロジェクトより

も失敗プロジェクトの方がその企業にとってノウハウが残せるものである。

勇気を持って企業内に IT 投資効果評価を公開してすることが必要である。様々な意見が寄せられ

ることになり、それがその企業の IT 投資の進歩につながる。

（2） ソフトウェアにおけるメトリックス（指標）を持つこと、また、その効果を把握すること（理解してもらえる評

価尺度を採用すること）

IT 部門は、IT 投資の必要性を社内利用者に理解してもらい、協力してもらえるように、自らの説

明能力を高める努力をする必要がある。

94

IT 部門の独りよがりの悪いところは、IT 部門にいる人にはわからないことが多い。

例えば品質を、「FP（ファンクションポイント）あたりの欠陥数」などで説明する場合が良くあ

る。確かに FP 法は、完璧ではないが、あるシステムの機能量を表す有効な指標であり、これ以上

の有効な指標はない。

しかし、「ソフトウェアメトリックス調査」では、FP 法は大企業でも採用している企業は 20％程

度である。

これをお金で、予算額で言い変えてみると、利用部門の方にも容易に理解できる。例えば、

「1 億あたり 6 個程度はカットオーバー後に欠陥が発生するが、迅速に対応するので、協力して

ほしい」

と新システム稼動前に利用者に説明しておけば、利用者は「多少の欠陥は仕方がない」と思いつ

つ協力してくれる。これを「ゼロにせよ」といわれると、工期は長くなり、費用は膨大にかかるこ

とになる。

利用部門は、導入するプジェクトの総予算がいくらかは皆知っているので、「稼動後のバグは 1 億

円あたり、6 個以内なら上出来だな」と理解してもらえる。

金融機関などのお金を扱う品質に厳しいシステムの場合は、1 億円当たり 2 個程度に抑えないと

顰蹙を買うことになる。

「測れるものは比較でき、進歩が期待できる」が、IT 部門やソフトウェア産業では、歴史が浅い

こともあり、投資効果の測定・評価の習慣が浸透していない。「ソフトウェアメトリックス調査」で

は、様々なシステムの評価尺度を検討しているが、これは、IT 部門やソフトウェア産業が、その優

秀さを説明するためでもある。この調査では、開発の評価値に続き、2005 年度は、保守の評価値に

ついても提示しており、2006 年度は運用の評価値をも検討している。

何か目標値があれば、それは多少バラツキが大きくても、1 つの目安にはなる。目標値がないより

は断然良い。

実績を整理していなくても、経験値で良いので仮の目標を設定し、ユーザーとベンダーが協力し

合うことが、説明能力を高め、システムのレベルを向上させる。目標値を持つことの重要性を認識

する必要がある。

IT 投資評価をすることが、気軽に IT プロジェクトを企画し、開発もしくは購入し、立ち上げる

ことの第一歩となる。今後も IT の活用力の良否が企業の競争力を決する。

そのための IT 投資評価であることを、忘れずに IT 投資評価を楽しんで実施して欲しい。それが

活性化した企業文化として花開くときが来る。

以上

95

4．参考資料

4．1 「ＩＴ投資の見える化」についての IT 部門長インタビュー、CIO 座談会の結果

（1）経営者は、ＩＴ投資に強い関心を持っている。しかし、多くの経営者は、その効果が見えな

いということで、依然強い不満を持っている。

（2）各企業では「見える化」の指標として、何らかの指標（indicator）を持っている。 著名な指標としては、以下のようなものがある。 ・KPI ：key performance indicator（主要業績評価指標） ・BSC ：balanced scorecard（バランス・スコアカード ） ・ROI：return on investment（投資利益率 / 投資収益率 / 投資回収率）

しかしながら、これら指標の適切かつ統一の概念はなく、上記の用語の使われ方も企業によって

異なる。言い換えると、KPI のひとつの手法としての BSC もあれば、BSC のひとつのファクター

としての KPI といった用いられ方もある。また、「顧客さま満足度」という KPI にも、BSC にも登

場する指標もある。

これら指標は、用いられる分野（経営計画、全社的施策、個々のプロジェクト単位等々）、局面（計

画段階、開発段階等）、役割（投資の可否の決定、成果のトレース等々）によって、当然のことなが

ら、得手不得手が出てくる。これらは、前章で見てきた通りである。

・何がなんでもという形で、ひとつの指標に固執すれば、鶏口牛刀になってしまい、そのオーバー

ヘッドが大きすぎて耐えられないという、実務家のぼやきも出てくる。

・精度を上げようと、きめ細かく多くの指標で脇を固めれば、チェックポイントが多すぎて、何を

目指そうとしているのか、目的そのものを見失いかねない。説明することに重きを置いた指標は、

早晩、アナログ的解決の壁にぶつかる。何がなんでも数値化というのも、どこかに無理が出てく

る。

・空間に浮かぶ 3 次元の物体（たとえば茶筒のような円筒形）ですら、見る方向によっては、円に

も見え、長方形にも見える。指標として、円の大きさをとるのか、長方形の面積を問題にしてい

るのか。われわれの IT 投資ははるかに多次元の空間を構成している。

いくつかの指標は、独立であることはほとんどない。新製品への貢献度ひとつをとっても、営業努

力もあれば、拠点展開といったアナログの世界が大きく広がっており、IT 投資の効果を見てくれる

経営者は少ない。

（4）CIO 座談会、IT 部門長へのインタビューを通じて、経営トップのいくつかの思いが感じられ

る。

・説明の的確さも重要であるが、分かりやすさがほしい。 ・どういう手法を採用しているかという説明より、何を目的としているかを知りたい。 ・指標へのコミットメントと継続的フォローが重要である

96

4．2 ユーザー満足度調査

以下、参考資料として、JUAS「ユーザー満足度プロジェクト報告書（2002）」からの抜粋を掲載

する。

９．開発計画合意書（ＵＳＰ）の作成

(ＵＳＰ：User Satisfaction Planning sheet)

ここに、顧客満足度、ユーザー満足度について様々な視点から考察してきたが、評価をする場合

には、「計画に対しての実績の評価」ができることが望ましい。 開発実行計画書作成時に以下に述べる開発計画合意書をユーザーとベンダー共同で作成しプロジ

ェクト推進中に、相互の役割についてまっとうすることが肝心である。 開発計画合意書としてあえて開発計画契約書としなかったのは、開発に関する作業はユーザーと

ベンダーでの共同作業が多く、両者の相互努力の結果プロジェクトは成功するものであることを強く

意識したためである。

（１）作成目的

当プロジェクトが完了した時（あるいは契約フェーズが完了した時に）、プロジェクト責任者が、

何をどのような状態にさせて欲しいと願っているか、つまりＩＴ投資戦略の評価項目をあらかじめ

明らかにし、ユーザー満足度を評価する基本資料として使用する。

（２）計画書の内容

１) 利用者の満足度

ⅰ．基本サービス

①品質：納入物に対する評価項目と評価尺度（品質目標値）を明確にする。 ・対象とするドキュメント：納入検査に持ち込んだ納入物 ・システムの欠陥性、システムの性能性、システムの信頼性を評価項目とし、それぞれに対

する目標値を設定する。 ・評価時期：納入テスト～フォロー間。

②納期／工期：成果物を規定し何時までに何を完了させるのかを明確にする。 ③費用：見積前提／条件に留意し、契約金額＋追加金額を明確にする。

ⅱ．表層サービス

①適用する評価項目および評価尺度を明確にする。

基本サービス、表層サービスともベンダー側の一方的義務ではなく、ユーザー側の資料提供、

説明、設計資料などの検査の精度によるところが大きいので、あくまでも計画値であって契

約保証値ではない。両者の役割を明確化したうえでの、相互努力目標値である。

２）プロジェクト責任者の満足度

①効果：時系列の変化値に留意したプロジェクト責任者の期待値を明確にさせる。 ・数値化できるもの、数値化しにくいものの両者について指標を確認しておくこと。

97

・前提整理方法、測定方法、確認方法、評価方法など手続きについても規定しておくこと。 ②目的を達成するための仕組み：たとえば、新ビジネスモデルについて納得の程度は？ ③プロジェクト推進上の課題：ＩＴ担当部門とベンダーとの共同推進作業などの満足度

３）計画～実績対比時の留意点

①開発完了時あるいは契約フェーズ別完了時に、このＵＳＰと実績を対比し、 ・いかなる対策をとればよかったのか ・今後の前向きなアクションの可能性 などをベンダー・ユーザー双方で確認する。

②本番後のＵＳＰ実績評価の実施時期もフォロー期間を予測して計画時に設定すること。 ③実際のシステムの効果を確認した後でないと評価できない項目は、改めて効果確認の時期を

設定し見直しをすること。

４）契約フェーズとＵＳＰの関連

注

・分割契約時には総合テスト１のフェーズは不要。 ・定期的に実施するユーザー満足度調査とは、別なものと考えること。

図９－１ 契約フェーズとＵＳＰの関連

既にここまでに開発・保守・運用についての業務、契約の多様性，関係者の輻輳性、評価項目の

複雑性等について見てきたが、できるだけ簡潔に日本型開発評価尺度を調査する技法をまとめてみ

た。日本の情報化社会からトラブルをなくすため、あるいは日本のソフトウエア開発およびシステ

ムの運用力を高めるための、実態を確認、追及するための技法である。 現時点でも日本のシステム開発力、品質管理の水準は国際的にみても高いと信じているが、数々

の理由により適確な指標が存在しない。このような現状課題にこの技法が役立てば幸いである。

要

件 定

義

基本 設計

詳細 設計

単体 テス

ト

結

合 テ

ス

総

合 テ

ス

事

前 調

査

一括契約方式 ＵＳＰ実績

ＵＳＰ計画

分割契約方式 ＵＳＰ計画

ＵＳＰ実績

同左 同左

同左 同左

同左

同左

総

合 テ

ス

フォロー

製

作

（ 納

（ 納

98

１０．ユーザー満足度の調査計画書案（対象：開発業務）

１０．１ 調査前提の設定 （１）ユーザーがプロジェクトを確認できるポイント

ユーザーにとっては、開発工程の全プロセスが見えるわけではなく、一括契約ではＢ

～Ｈ、分割契約ではＣ～Ｇの請負契約の範囲については見えない。これを前提にユーザ

ー満足度を考察する必要がある。なお、プロジェクトの評価ポイントは、一括契約、分

割契約ともＩである。

Ａ Ｂ Ｃ Ｄ Ｅ Ｆ Ｇ Ｈ Ｉ

要件定

義 基本設

計 詳細設

計 製作 結合ﾃ

ｽﾄ

総合ﾃｽﾄ

１ (ﾍﾞﾝﾀﾞ確認 )

総合ﾃｽﾄ

２ (顧客確認 )

ﾌ ｫ ﾛ ｰ

(安定稼動 ) 一 括 契

約

分 割 契

約

（請負）

［顧客/ﾍﾞﾝﾀﾞ］ ［ベンダ作業］

(納品)

［ベンダ作業］

（委任） （委任） （請負） （委任） (納品)

［顧客/ﾍﾞﾝﾀﾞ］ 共同作業 (顧客/ﾍﾞﾝﾀﾞ)

［工程なし］

(本番)

(本番)

共同作業 (顧客/ﾍﾞﾝﾀﾞ)

（ 同

半透明 不 透 明 透 明

不 透 明 顧客から

の投入負

荷確認度

［共同作業］ (顧客主体/ﾍﾞﾝﾀﾞ支援)

顧客から

の投入負

荷確認度

半透明

共同作業 (顧客/ﾍﾞﾝﾀﾞ)

作業の

主体性

作業の

主体性

99

（２）調査対象プロジェクト

項 目 調査対象プロジェクト 注 釈 １．開発方法 １．スクラッチ開発

ａ：ウォーターフォール ｂ：スパイラル型 ２．パッケージ開発 ａ：標準機能型 ｂ：機能追加型

一般に適用されている開発方法を

対象とした。

２．業務系列 業務アプリケーション ３．システム形態 汎用、ｸﾗｲｱﾝﾄ/ｻｰﾊﾞ、WEB ４．開発形態 新規／再構築 ５．開発規模 総額２千万円以上 ２千万円以下の小規模なものは開

発工程も明確ではなく、データも把

握しづらいことから対象外とした

（３）ユーザー満足度の調査の種類と今回の調査対象

調 査 対 象 調査要求者 比較のベース 時期

１ 個別プロジェク

トを対象に評価 開発完了したプロジェ

クトの実績評価 開発元ベンダー

／プロジェクト

責任者

・ Ｃ ・ ＵＳＰ ・開発結果の評価

開発完了

後

ユーザーと予め契約を

結べる場合 同 上 ・ＳＬＡ

・運用状況の評価 一定時期 ２ 一定期間のユー

ザー満足度を評

価 外部のリサーチ会社が

実施する場合 リサーチ会社 開発/運用状況の

評価 一定時期

今回は、１の個別プロジェクトの開発業務が対象。

100

（４）調査対象の工程範囲と主要調査項目

開発工程を対象に、ユーザーが理解しやすくて実業務に適用でき、ベンダーと共通に

認識できる評価項目と評価尺度を検討する。 開 発

主 要 調 査 項 目 調査 回答者 保守・ 運用

表

層 ｻｰ

ﾋﾞ

ｽ

行動マ

ナー

ユーザーがベンダーを評価できる項目と評価尺

度の実現可能性

調査

－

納期／

工期

①JUAS 提案 MODEL の妥当

性 ②ﾌﾟﾛｼﾞｪｸﾄの実工期（標準値と

の偏差）とｱｸｼｮﾝ対策状況 ③評価尺度の満足度

重点 調査

－

品質

①「欠陥性」「処理の性能性」

「安定稼動性」に関する評価

項目の利用可能性および適

用時の妥当性。 ②評価尺度の満足度

同 上

－

基

本

ｻｰ

ﾋﾞ

ｽ

費用

①見積り方式（LOC､FP､画帳

数、ドキュメント量）別の規

模、生産性、単価 ②評価項目の妥当性 ③評価尺度の妥当性、使用可能

性

①品質尺度と 費用との関連

性およびユー

ザー満足度へ

の影響。 ② 工 期 尺 度 と

品質・生産性

との関連性お

よびユーザー

満足度への影

響。 同 上

・ﾌﾟﾛﾏ

ﾈ又はｽ

ﾀｯﾌ ・利用

者代表

－

Pj責

任

者

評

価

投資効

果評価

投資対効果に関する評価項目と評価尺度の妥当

性

同 上

ﾌﾟﾛｼﾞｪ

ｸﾄ責任

者

－

101

（５）調査手続き

調査実施に際しては、限られた時間と調査資源（人、金）を有効に、かつ効果的に使う

ことからフィージビリティ・スタディ（ＦＳ）調査と本調査の２段階での調査手続きを適用

する。

（６）調査対象

本件における調査は、①フィージビリティ調査と②本番調査の２段階に分けて実施する。

１）フィージビリティ調査（Ｆ／Ｓ）の調査対象

Ｆ／Ｓでは、仮設定したユーザー満足度評価項目・尺度の妥当性、内容理解の容易性、例外条件

の取り扱い等を調査し、調査票の設計を行うことが目的である。 よって、ユニークかつある程度の散らばり（規模的にも、適用業務的にも、プラットフォームや

開発手法的にも）を持ったシステム案件（事例）を数多く保有し、それらに関するデータを定量的

に記録しており、本件の趣旨を短期間で理解することが条件となる。 ＪＵＡＳは、年間 20 件を越える各種研究会、部会を運営しており、また 50 件以上の研修講座を

開催している。本調査に関連したテーマは、これらの随所で問題提起し、情報収集に努めてきたた

め、Ｆ／Ｓ調査の対象とさせていただく、当該テーマに関心の高い企業群は確認できている。

１．評価項目と評価尺度に関するＪＵＡＳ案（質問票）を作成

２．ＦＳ調査対象のユーザ５社以上を選定

３．ＪＵＡＳのＩＳＣ(*)メンバーによるＦＳ対象会社の訪問・調査（５案件程度/

社）及び質問票のレビュー（ＪＵＡＳ案を評価・検証し、本番用の質問票を作

成）(*):Information System Consultant

４．本番調査対象のユーザー・ベンダー２０社以上を選定

５．ＪＵＡＳのＩＳＣメンバーによる本番対象会社の訪問・調査（５案件程度/社）

及び質問票の分析（単純集計／単純分析、クロス集計／クロス分析）

６．各評価項目及び評価尺度の見直し、及び新評価項目及び評価尺度の設定

102

２）本番調査の調査対象

本番調査では、Ｆ／Ｓで検証し確定させたユーザー満足度評価項目をもとに、調査内容を規定し、

各項目について、ユーザーの考える尺度を調査して、システムのパターンによる標準値とばらつき、

相互の影響度合い等を調べることが目的である。 ユーザーが、効果が高く無駄の少ないＩＴ投資を行えるための目安を設定するための分類と分析

を行う。 そのために、本番調査の対象は各業種から均等に抽出し、調査対象となるシステムについても、

適用業務や規模（発注金額 2000 万円以上を想定）が、それぞれ分析する母数として適当数収集で

きることが条件となる。 ＪＵＡＳでは、例年実施してきた企業ＩＴ動向調査により、会員企業を中心に、それらの基礎デ

ータを保有しており、企業の規模／業種、システム規模等から、均等に対象を抽出して、本番調査

に臨むことができる。 対象企業として、20 社程度の候補を準備。

103

１０．２ 調査記入用紙と記入要領 １０．２．１ スクラッチ開発

スクラッチ開発プロジェクト・ユーザ満足度マクロ調査 記入用紙

プロジェクト名：　　　　　　　　　　　 貴社名：　　　　　　　

作成年月日　平成　年　月　日

１．基本情報及び基本サービス（納期／工期、品質、費用）情報　、回答者　プロマネ／スタッフ(該当者を○で囲む）

業務分野 汎用、ｸﾗｲｱﾝﾄ/ｻｰﾊﾞ、WEB

開発総額 　計　画：　　 　実　績：　　

①機能の難易度（易しい、普通、難しい）　②現行保証時のﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞの有無（あり、なし）(納品) (本番)

総合ﾃｽﾄ1 総合ﾃｽﾄ2 フォロー（ﾍﾞﾝﾀﾞ確認） （顧客確認） （安定稼動）

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月～ ～ ～ ～ ～ ～ ～ ～

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月～ ～ ～ ～ ～ ～ ～ ～

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月

総工数 ｽﾊﾟｲﾗﾙ回数 工期(a) JUAS(b) (b)-(a) 　 本番時期分割立上げ

回数

計　画 　　　人月 回 　　ヶ月 　　ヶ月 　　ヶ月 　(　年　月)

実　績 　　　人月 回 　　ヶ月 　　ヶ月 　　ヶ月 　(　年　月)

番号：

２．ユーザ満足度、　 回答者　ＣＩＯ／プロマネ／スタッフ(該当者を○で囲む）

　　評価尺度　（５：非常に満足、　４：やや満足、　３：普通、　２：やや不満足、　１：非常に不満足）

尺　度

1

2

3

4

5

6

7

千万円

質　　　　　　　　　問

開発投資／戦略価値などプロジェクトの総括結果については満足していますか？

金額単位のバグ発生率

開　発　型

委　任

請　負

範　囲

時　期

時　期

システム形態

千万円、

製　作 結合ﾃｽﾄ

　

基本設計 詳細設計

新規／再構築

要件定義

範　囲

バグ個数 個

　　納期／工期

　　（内変更管理分：　　　個）

ｽﾊﾟｲﾗﾙ型 ／ｳｵｰﾀﾌｫｰﾙ型

／その他

品質(実績）

業　種

開発形態

契約情報（実績）

業務要件

個/500万円

（内変更管理分：　　個/500万円）

理　由（２、１と評価された場合はその理由を記入してください）

換算画帳数： 換算ﾍﾟｰｼﾞ数：

画面・帳票単価方式 成果物別比較方式

①２４％以下、②２５％～４９％、③５０％～７４％、④７５％～９９％、⑤１００％、⑥１０１％以上要求機能に対する充足率

LOC方式

換算LOC数：

ＦＰ方式

ＦＰ数：開発規模

（実績）

費用は、得られた価値（工期、品質）と比較して高いですか、安いですか？（尺度は、「5.高い4.やや高い　3.普通　2.やや安い　1.非常に安い」と置換）

提案／対応力、ｺﾐｭﾆｹｰｼｮﾝなどﾍﾞﾝﾀﾞｰのｻｰﾋﾞｽﾏﾅｰについては満足していますか？

実現した業務プロセス、システムについては満足していますか？

工期は、従来の実績と比較して短いですか、長いですか？(尺度は「5.非常に短い　4.やや短い　3.適当　2.やや長い　1.非常に長い」と置換)

品質については満足していますか？

貴社IT部門・利用部門・ベンダ三者の協調体制については満足していますか？

▼ ▼

104

スクラッチ開発プロジェクト・ユーザ満足度マクロ調査 記入要領

･プロジェクト名：オプションです。差し支えない範囲で記入ください。

･貴社名、　・作成年月日等を記入ください。

Ⅰ調査対象プロジェクト

　 ①開発規模：２千万円以上、　②業務系列：業務アプリケーション、　③調査タイミング：フォロー完了後（安定稼動後）

Ⅱ基本情報及び基本サービス情報

１．業種：下記を参考に該当業種を記入する。

２．業務：生産管理、購買・資材管理、販売管理、物流管理など開発対象業務を記入する。

３．システム形態：対象項目を○で囲む。

４．開発形態：対象項目を○で囲む。

５．開発総額：アプリケーション開発費、ＤＢソフト／ミドルウエア／ネットワークソフト購入費、プロジェクト管理費など（ハード

ウエア及びＯＳ購入費以外）を集計・記入する。

６．業務要件：該当項目を○で囲む。

（１）機能の難易度：事例のない新しい試み、高度な知識、複雑な論理、厳格な精度、厳しい無欠陥性、 複雑な

インターフェイスなどの要求レベルを考慮 して難易度を判断する。

（２）現行保証時のリバースエンジニアリングの有無（再構築ﾌﾟﾛｼﾞｪｸﾄ）：現ドキュメントの整備不良に起因するリバース

　　エンジニアリング業務負荷の変動は大きいので、この業務の有無を確認する。

７．契約情報（実績）

　　（１）範囲：契約類型に応じ該当フェーズの点線上を、　　　　　　　　　で表す。

　・スパイラルの場合は、回数に関係なく、開始フェーズから終了フェーズの点線上を同様に

　　　　　　　　　で表す。

（２）時期：該当フェーズにおける作業の開始時期及び終了時期(右図参考）を記入する。

　・スパラル型の場合は、回数に関係なく、開始フェーズの開始時期と終了フェーズの

　　終了時期だけを記入し、途中のフェーズは記入不要。

　・分割立上げの場合は、各フェーズとも、最初の分割立上げ開始時期と、最後の分割立上げ終了時期だけを記入する。

　・総合テストは、ベンダ主体の確認作業と顧客主体の確認作業に分かれることから、フェーズを二つに分割して記入する。

８．納期／工期

（１）開発型：該当項目を○で囲む。

（２）総工数：「５．開発総額」に対応する工数を記入する。

（３）スパイラル回数：スパイラル型の場合、その回数を記入する。スクラッチ型の場合は記入不要。

（４）工期（ａ）：プロジェクト開始から本番迄(分割立上げの場合は最終本番迄）の工期を記入する。

（５）ＪＵＡＳ（ｂ）：オプションです。関心のある方は、２×総工数の立方根を計算し、記入してください。

（６）（ｂ）－（ａ）：オプションです。関心のある方は記入してください。

（７）本番時期：本番時期（分割立上げの場合は最終本番時期）を記入する。

（８）分割立上げ回数：分割立上げ回数を記入する。

①農林・水産・食品、　②建設・土木・鉱業、　③化学・薬品、　④石油・石炭・ゴム、　⑤繊維関連・紙・木材、　⑥鉄・非鉄

金属・窯業、　⑦輸送機器・関連部品、　⑧一般機械製造、　⑨電気機械製造、　⑩その他製造、　⑪商社・流通・卸売り、

⑫銀行・保険・証券・信販、　⑬不動産・倉庫、　⑭運輸、　⑮通信・通信サービス、　⑯電気・ガス・水道、　⑰放送・新聞・

出版・印刷・映画、　⑱サービス業、　⑲情報処理業、⑳その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）

（該当ﾌｪｰｽﾞ）

開始時期 終了時期

105

９．品質（実績）

（１）バグ個数：納品～フォローで発生した、ベンダ起因のバグ個数を記入する。変更管理分は内数として（　）に記入する。

（２）金額単位のバグ発生率：オプションです。関心のある方は、バグ工数／開発総額×５００万円を計算し、記入してくだ

　　さい。変更管理分は内数として（　）に記入してください。

１０．要求機能に対する充足率：当初計画した要求機能に対する充足率（番号）を記入する。

１１．開発規模（実績）：該当欄に「８．（２）総工数」に対応する論理開発規模を記入する。

・下表で換算合計を算出し記入用紙に転記する。算出に際しては、［参考］をベースにプロジェクトの特性を反映した分類

　項目及び換算係数も適用可。

（１）ＬＯＣ換算方式（ＣＯＢＯＬ換算）

［参考：１ＦＰ当りのＬＯＣ数と換算係数］

(*) Software Quality Analysis and Gudeline for Success by Capers Jones P191 共立出版社

(**)２００２．１０．１７ のＪＵＡＳ講演資料

　　ＣＯＢＯＬ換算ＬＯＣ数は、夫々の言語における１ＦＰ当りの所要工数比較比×１００で算出。

・ＶＢ：1.8(VB工数対1FP工数)/2.6(COBOL工数対1FP工数)×100(COBOLLOC数/FP)=69→７０

・Ｊａｖａ：0.9/2.6×100=35→３５

（２）画面・帳票単価方式（難易度１換算）

［参考：画面・帳票作成の難易度と換算係数］　　

データ出所：「見積技術の基礎」新日鐵情報通信システム（株）1999.3

　(*):難易度別の作業負荷工数比で算出。

(画面・帳票の難易度１：1人月/機能、同難易度２：２人月/機能、同難易度３：３人月/機能)

51以上

難易度３

31 2

1～20 21～50

（普通）

（難しい） （易しい） （普通）

帳　　　　票　

（難しい）

（難しい） （難しい）（易しい）

100（＊） 70（＊＊） 50（＊） 35（＊＊）

ＣＯＢＯＬ

1.0

　項目　　　　　言語　　 換算合計

データ項目数

言　語　１ 言　語　２ 言　語　３

（普通）

11～20

（易しい）

データ編集処理

表 示 処 理

換算係数(*)

画　　　　面　

10以下 21以上

31 2

ｷｰ以外の編集、ﾏﾄﾘｯｸｽ編集等

換算合計

言　語　４

画　面　数 帳　票　数

（普通）（易しい）

ＪａｖａＶＢ Ｃ＋＋

3.01.5 2.0

複数の文字ﾌｫﾝﾄ+ｸﾞﾗﾌ等の表示処理が必要

複数の文字ﾌｫﾝﾄ+ｸﾞﾗﾌ等の表示処理が必要

ｷｰ以外の編集、ﾏﾄﾘｯｸｽ編集等

複数の文字ﾌｫﾝﾄが必要

複数ﾃｰﾌﾞﾙ/複数ｷｰによる編集

難易度３

難易度１ 難易度２ 難易度３ 難易度１ 難易度２

難易度１ 難易度２ 難易度３ 難易度１ 難易度２

複数ﾃｰﾌﾞﾙ/複数ｷｰによる編集

複数の文字ﾌｫﾝﾄが必要

単一ﾃｰﾌﾞﾙ/単一ｷｰによる編集

特別な処理無し

単一ﾃｰﾌﾞﾙ/単一ｷｰによる編集

特別な処理無し

項目　　　画面・帳票

ＬＯＣ数

換 算 係 数

画面・帳表数

換 算 係 数

　項目　　　　　言語

　項　目　　　　画面・帳票

LOC数/FP

換 算 係 数

106

（３）成果物別比較方式（基本設計・基本ドキュメントページ数換算）

［参考：成果物の構成と換算係数］　　

データ出所：（株）ジャステックの資料より抜粋

　　(*1):基本設計フェーズ・基本ドキュメント１ページ当りの作成作業負荷工数をベース。

(*2):テスト仕様書作成、テストデータ作成、テストの実施、検証・報告。

(*3):ＣＯＢＯＬ換算ＬＯＣ数÷(45LOC/ﾍﾟｰｼﾞ)でページ数に換算。

(*4):ページ換算が困難なことから実績値を記入する。換算合計欄には計上不要。

Ⅲユーザ満足度

各質問に対する評価結果を「尺度」欄に記入ください。２、１と評価した場合は、その理由を「理由」欄に記入ください。

注意：記入完了後、「記入用紙」及び「記入要領」をメールにて返送ください。

以　　上

記入内容に関する問い合わせ及び送付先

（社）日本情報システム・ユーザー協会　

（ページ数） （ページ数） （換算ページ数*3）

詳細設計 製作（換算ﾍﾟｰｼﾞ数）

基本ドキュメント

　項目 　　　 ﾌｪｰｽﾞ　

基本ドキュメント数

ﾃｽﾄﾄﾞｷｭﾒﾝﾄ数

換　算　係　数

（ページ数）

基本設計（ページ数） （テスト項目数）（LOC数÷45）

換算合計テスト

総　合

結　合

単　体

基本設計 詳細設計 製　　作　 テスト　項　目 　　　　　　 　 　　 ﾌｪｰｽﾞ(テスト項目数*4)

－

1.4 1.4 0.2 －

1.0 0.7 0.3

－

1.7 0.9 0.2 －

1.4 0.4 0.2

換算係数(*1)結　合

単　体

総　合テストドキュメント(*2)

107

１０．２．２ パッケージ適用開発

パッケージ適用プロジェクト・ユーザ満足度マクロ調査 記入用紙

プロジェクト名： 　　　　 貴社名：　　　　　　　

パッケージ名：　　　　　　　（Ｖ:　） 作成年月日　平成　年　月　日

１．基本情報及び基本サービス（納期／工期、品質、費用）情報　、回答者　プロマネ／スタッフ(該当者を○で囲む）

業務分野 汎用、ｸﾗｲｱﾝﾄ/ｻｰﾊﾞ、WEB

開発総額 　計　画：　　 　実　績：　　

①機能の難易度（易しい、普通、難しい）　②現行保証時のﾘﾊﾞｰｽｴﾝｼﾞﾆｱﾘﾝｸﾞの有無（あり、なし）(納品) (本番)

総合ﾃｽﾄ1 総合ﾃｽﾄ2 フォロー

（ﾍﾞﾝﾀﾞ確認） （顧客確認） （安定稼動）

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月～ ～ ～ ～ ～ ～ ～ ～

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月～ ～ ～ ～ ～ ～ ～

年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月 年　　月

総工数機能追加業

務工数 工期(a) JUAS(b) (b)-(a) 　 本番時期 分割立上げ回数

計　画 　　　人月 　　　人月 　　ヶ月 　　ヶ月 　　ヶ月 　(　年　月)

実　績 　　　人月 　　　人月 　　ヶ月 　　ヶ月 　　ヶ月 　(　年　月)

ﾊﾟｯｹｰｼﾞ本体

番号：

２．ユーザ満足度、　 回答者　ＣＩＯ／プロマネ／スタッフ(該当者を○で囲む）

　　評価尺度　（５：非常に満足、　４：やや満足、　３：普通、　２：やや不満足、　１：非常に不満足）

尺　度

1

2

3

4

5

6

7

品質(実績） 個/500万円

金額単位のバグ発

生率機能追加部

個/500万円

（内変更管理分：　　個/500万円）

業　種

開発形態

契約情報（実績）

業務要件

千万円

適　用　型

結合ﾃｽﾄ要件定義

委　任

範　囲

範　囲

時　期

システム形態　

業務分析(FIT&GAP)

ｿﾘｭｰｼｮﾝ設計(AP、ＤＢ設計）

新規／再構築 千万円、

詳細設計/製作/ｾｯﾄｱｯﾌﾟ

　　納期／ 標準機能型／

時　期

　　工期 機能追加ﾞ型(*)

請　負

(*)適用の理由

個

（内変更管理分：　個）

　バグ個数

ﾊﾟｯｹｰｼﾞ本体

機能追加部個

ＤＢ：項目不足。ｼｽﾃﾑ：機能不足。画面／帳票：使いづらい、見映えが悪い。その他（　 　　）

要求機能に対する充足率

開発規模（実績）

ＬＯＣ方式 ＦＰ方式

①２４％以下、②２５％～４９％、③５０％～７４％、④７５％～９９％、⑤１００％、⑥１０１％以上

画面・帳票単価方式 成果物別比較方式

換算LOC数： ＦＰ数： 換算画帳数：

貴社IT部門・利用部門・ベンダ三者の協調体制については満足していますか？

換算ﾍﾟｰｼﾞ数：

質　　　　　　　　　問 理　由（２、１と評価された場合はその理由を記入してください）

開発投資／戦略価値などプロジェクトの総括結果については満足していますか？

実現した業務プロセス、システムについては満足していますか？

費用は、得られた価値（工期、品質）と比較して高いですか、安いですか？（尺度は、「5.高い4.やや高い　3.普通　2.やや安い　1.非常に安い」と置換）

提案／対応力、ｺﾐｭﾆｹｰｼｮﾝなどﾍﾞﾝﾀﾞｰのｻｰﾋﾞｽﾏﾅｰについては満足していますか？

工期は、従来の実績と比較して短いですか、長いですか？(尺度は「5.非常に短い　4.やや短い　3.適当　2.やや長い　1.非常に長い」と置換)

品質については満足していますか？

▼ ▼

108

パッケージ適用プロジェクト・ユーザ満足度マクロ調査 記入要領

･プロジェクト名：オプションです。差し支えない範囲で記入ください。

･貴社名、　・パケージ名（バージョンNo.）、　・作成年月日等を記入ください。

Ⅰ調査対象プロジェクト

　 ①開発規模：２千万円以上、　②業務系列：業務アプリケーション、　③調査タイミング：フォロー完了後（安定稼動後）

Ⅱ基本情報及び基本サービス情報

１．業種：下記を参考に該当業種を記入する。

２．業務：生産管理、購買・資材管理、販売管理、物流管理など開発対象業務を記入する。

３．システム形態：対象項目を○で囲む。

４．開発形態：対象項目を○で囲む。

５．開発総額：アプリケーションシステム構築費、パッケージ購入費、ＤＢソフト／ミドルウエア／ネットワークソフト購入費、

プロジェクト管理費など（ハードウエア及びＯＳ購入費以外）を記入する。

６．業務要件：該当項目を○で囲む。

（１）機能の難易度：事例のない新しい試み、高度な知識、複雑な論理、厳格な精度、厳しい無欠陥性、 複雑なインター

　　　フェイスなどの要求レベルを考慮 して難易度を判断する。

（２）現行保証時のリバースエンジニアリングの有無（再構築ﾌﾟﾛｼﾞｪｸﾄ）：現ドキュメントの整備不良に起因するリバース

　　エンジニアリング業務負荷の変動は大きいので、この業務の有無を確認する。

７．契約情報（実績）

　　（１）範囲：契約類型の応じ該当フェーズの点線上を　　　　　　　　　で表す。

（２）時期：該当フェーズにおける作業の開始時期及び終了時期(右図参考）を記入する。

　・分割立上げの場合は、各フェーズとも、最初の分割立上げ開始時期と、最後の

　　分割立上げ終了時期だけを記入する。

　・総合テストは、ベンダ主体の確認作業と顧客主体の確認作業に分かれることから、

　　フェーズを二つに分割して記入する。

８．納期／工期

（１）適用型：該当項目を○で囲む。

（２）適用の理由：機能追加型適用の理由について、該当項目に○をつける。該当無しの場合にはその他（　）に適用理由

　　を記入する。

（３）総工数：「５．開発総額」に対応する工数を記入する。

（４）機能追加業務工数：機能追加業務（＊）に要した工数を記入する。

　（＊）ＦＩＴ＆ＧＡＰ分析により明確になった、機能追加部の工数で、具体的には、ソリューション設計～本番迄の業務に要し

た工数。標準機能型の場合は記入不要。

（５）工期（ａ）：プロジェクト開始から本番迄(分割立上げの場合は最終本番迄）の工期を記入する。

（６）ＪＵＡＳ（ｂ）：オプションです。関心のある方は、２×総工数の立方根を計算し、記入してください。

（７）（ｂ）－（ａ）：オプションです。関心のある方は記入してください。

（８）本番時期：本番時期（分割立上げの場合は最終本番時期）を記入する。

（９）分割立上げ回数：分割立上げ回数を記入する。

①農林・水産・食品、　②建設・土木・鉱業、　③化学・薬品、　④石油・石炭・ゴム、　⑤繊維関連・紙・木材、　⑥鉄・非鉄

金属・窯業、　⑦輸送機器・関連部品、　⑧一般機械製造、　⑨電気機械製造、　⑩その他製造、　⑪商社・流通・卸売り、

⑫銀行・保険・証券・信販、　⑬不動産・倉庫、　⑭運輸、　⑮通信・通信サービス、　⑯電気・ガス・水道、　⑰放送・新聞・

出版・印刷・映画、　⑱サービス業、　⑲情報処理業、⑳その他（　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）

（該当ﾌｪｰｽﾞ）

開始時期 終了時期

109

９．品質（実績）

（１）バグ個数

　①パッケージ本体：納品～フォローで発生した、パッケージ本体のバグ個数を記入する。

　②機能追加部：納品～フォローで発生した、ベンダ起因による機能追加部のバグ個数を記入する。変更管理分は内数と

　　して（　）に記入する。

（２）金額単位のバグ発生率

　①パッケージ本体：オプションです。関心のある方は、バグ工数／開発総額×５００万円を計算し、記入してください。

　②機能追加部：：オプションです。関心のある方は、バグ工数／開発総額×５００万円を計算し、記入してください。

　　変更管理分は内数として（　）に記入してください。

１０．要求機能に対する充足率：当初計画した要求機能に対する充足率（番号）を記入する。

１１．開発規模（実績）：該当欄に「８．（２）総工数」に対応する論理開発規模を記入する。

・下表で換算合計を算出し記入用紙に転記する。算出に際しては、［参考］をベースにプロジェクトの特性を反映した分類

　項目及び換算係数も適用可。

（１）ＬＯＣ換算方式（ＣＯＢＯＬ換算）

［参考：１ＦＰ当りのＬＯＣ数と換算係数］

(*) Software Quality Analysis and Gudeline for Success by Capers Jones P191 共立出版社

(**)２００２．１０．１７のＪＵＡＳ講演資料

　　ＣＯＢＯＬ換算ＬＯＣ数は、夫々の言語における１ＦＰ当りの所要工数比較比×１００で算出。

・ＶＢ：1.8(VB工数対1FP工数)/2.6(COBOL工数対1FP工数)×100(COBOLLOC数/FP)=69→７０

・Ｊａｖａ：0.9/2.6×100=35→３５

（２）画面・帳票単価方式（難易度１換算）

［参考：画面・帳票作成の難易度と換算係数］　　

データ出所：「見積技術の基礎」新日鐵情報通信システム（株）1999.3　

　(*):難易度別の作業負荷工数比で算出。

(画面・帳票の難易度１：1人月/機能、同難易度２：２人月/機能、同難易度３：３人月/機能)

1 2 3換算係数(*) 1 2 3

単一ﾃｰﾌﾞﾙ/単一ｷｰによる編集

複数ﾃｰﾌﾞﾙ/複数ｷｰによる編集

ｷｰ以外の編集、ﾏﾄﾘｯｸｽ編集等

表 示 処 理 特別な処理無し 複数の文字ﾌｫﾝﾄが必要複数の文字ﾌｫﾝﾄ+ｸﾞﾗﾌ等の表示処理が必要 特別な処理無し 複数の文字ﾌｫﾝﾄが必要

複数の文字ﾌｫﾝﾄ+ｸﾞﾗﾌ等の表示処理が必要

データ編集処理単一ﾃｰﾌﾞﾙ/単一ｷｰによる編集

複数ﾃｰﾌﾞﾙ/複数ｷｰによる編集

ｷｰ以外の編集、ﾏﾄﾘｯｸｽ編集等

（難しい）

データ項目数 10以下 11～20 21以上 1～20 21～50 51以上

（普通） （難しい） （易しい） （普通）

項目　　　画面・帳票画　　　　面　 帳　　　　票　

難易度１ 難易度２ 難易度３ 難易度１ 難易度２ 難易度３（易しい）

換 算 係 数

画面・帳表数

難易度２ 難易度３（易しい） （普通） （難しい） （易しい） （普通） （難しい）

3.0

　項　目　　　　画面・帳票

画　面　数 帳　票　数換算合計難易度１ 難易度２ 難易度３ 難易度１

換 算 係 数 1.0 1.5 2.0

Ｊａｖａ

LPC数/FP 100（＊） 70（＊＊） 50（＊） 35（＊＊）

　項目　　　　　言語 ＣＯＢＯＬ ＶＢ Ｃ＋＋

換 算 係 数

ﾛｼﾞｶﾙｽﾃｯﾌﾟ数

言　語　４ 換算合計　項目　　　　　言語　　 言　語　１ 言　語　２ 言　語　３

110

（３）成果物別比較方式（基本設計・結合テストページ数換算）

［参考：成果物の構成と換算係数］　　

データ出所：（株）ジャステックの資料より抜粋

　　(*1):基本設計フェーズ・基本ドキュメント１ページ当りの作成作業負荷工数をベース。

(*2):テスト仕様書作成、テストデータ作成、テストの実施、検証・報告。

(*3):ＣＯＢＯＬ換算ＬＯＣ数÷(45LOC/ﾍﾟｰｼﾞ)でページ数に換算。

(*4):ページ換算が困難なことから実績値を記入する。換算合計欄には計上不要。

Ⅲユーザ満足度

各質問に対する評価結果を「尺度」欄に記入ください。４、５と評価した場合は、その理由を「理由」欄に記入ください。

注意：記入完了後、「記入用紙」及び「記入要領」をメールにて返送ください。

以　　上

記入内容に関する問い合わせ及び送付先

（社）日本情報システム・ユーザー協会　

（ページ数） （ページ数） （LOC数÷45）

詳細設計 製作（換算ﾍﾟｰｼﾞ数） テスト 換算合計

1.4 0.4 0.2 －

－

－

1.0 0.7

1.4 1.4 0.2

結　合 1.7 0.9 0.2

0.3 －

（ページ数） （ページ数） （換算ページ数*3） (テスト項目数*4)

基本設計 詳細設計 製　　作　 テスト

結　合

（テスト項目数）

基本ドキュメント数

　項目 　　　 ﾌｪｰｽﾞ　 基本設計

ﾃｽﾄﾄﾞｷｭﾒﾝﾄ数

総　合

換　算　係　数

単　体

　項　目 　　　　　　 　 　　 ﾌｪｰｽﾞ

換算係数(*1)

基本ドキュメント

テストドキュメント(*2)

単　体

総　合

111

4．3 生産性環境変数評価表

開発リスク評価のための、「生産性環境変数評価表」次ページ以降に添付する。

（JUAS「システム・リファレンス・マニュアル（第 1 巻）」より抜粋）

生産性環境変数

生産性見積り方式 Ｐｉ ＝　ＰＢ

ｉ　×　（１+Σβｉｊ） βｉｊ:生産性環境変数

評価の観点 内責評価基準（参考）

生産性特性 副生産性特性 内　容 特記、特例事項 影響度

要件定義

設計 製作 テスト設計 製作 テスト

業務特性 業務ナレッジ(P01) ・顧客／当社の開発対象業務に対する業務ナレッジが生産性に及ぼす影響を、 →世の中に無い業務モデル等の創造、システム化の -10 -10 － -10 中核メンバー全員が当該業務経験多数

　それぞれ（外責／内責）個別に評価する 　要素も含む。 -5 -5 － -5 中核メンバーの一部の当該業務経験少

・外責評価はユーザー部門を含む顧客プロジェクト組織全体の能力として → プロジェクト全体としての方針・仕様意思決定能力 0 0 － 0 中核メンバーの一部に未経験者あり

　評価する 　 （旧組織複合度の要素を取り込む） 40 8 － 8 中核メンバーに当該業務経験者不在

・内責評価は当該プロジェクトへのアサインベースで評価する → 実／予定アサインメンバーの業務ナレッジで評価 50 10 － 10 メンバー全員が当該業務経験なし

ハードウェア特性 安定度/信頼度/使用実績 ・システムもしくは製品となるハードウェアの安定度・信頼度を － -5 － -5 当該ＨＷでの効果的開発手法を保有

(P02) 　外責として評価し、当社使用実績を内責として評価する → 実／予定アサインメンバーの使用実績で評価 － -3 － -3 当該ＨＷでの開発実績多数（安定度高）

　（注）「使用実績がある」ということは、ハードウェアの特性を把握し、 － 0 － 0 当該ＨＷでの開発実績が当社基準での平均

　　　　その対策は既知であるが故に、生産性が高いということ。 － 3 － 3 顧客に使用実績のないＨＷ

－ 5 － 5 世間で使用実績のないＨＷ

ソフトウェア特性 安定度/信頼度/使用実績 ・システムもしくは製品となる他社作成ソフトウェアもしくはCotsの → 実／予定アサインメンバーの使用実績で評価 － -5 － -5 当該ＳＷでの効果的開発手法を保有

(P03) 　安定度・信頼度を外責として評価し、当社使用実績を内責として評価する →要件定義の「－」は、ERPを利用する場合を想定して － -3 － -3 当該ＳＷでの開発実績多数（安定度高）

　（注）「使用実績がある」ということは、ソフトウェアもしくはCotsの特性 　いないことに注意すること。 － 0 － 0 当該ＳＷでの開発実績が当社基準で平均

　　　　を把握し、その対策は既知であるが故に、生産性が高いということ。 － 3 － 3 聞いたことはあるが特性がわからないＳＷ

－ 5 － 5 聞いたこともないＳＷ

コミュニケーション特性 顧客窓口特性(P04) ・問い合わせに対するレスポンス、約束期限の遵守度合い、方針・仕様に →組織としての特性を評価するものであり、窓口役の -10 -10 － -7 期限どおりに方針決定して頂ける

　関する決定が覆る度合により評価する 　個人を評価するものではない。 -5 -5 － -4 ほぼ期限どおりに方針決定して頂ける

　（窓口が複数あると受ける側は大変で、取りまとめ役 0 0 － 0 ほぼ期限どおりに方針決定して頂けるが、多少覆ることがる

　　がいないと混乱し、生産性は低下する。） 10 5 － 4 期限の遅延、決定事項が覆る事が多い

20 10 － 7 概ね期限は遅延し、決定事項が頻繁に覆る

工期の厳しさ(P05) ・システム規模に対する工期の厳しさが生産性におよぼす影響を、 →「工期の厳しさ」を以下の基準式を標準として評価する ー ー ー ー ー

　外責／内責別に評価する。 　　基準工期（月）＝２．７×（人月）１/３ 0 0 0 0 基準工期に対し▲5％未満

・２者間契約に適用するので、顧客が認識するプロジェクト全体ではなく、 （ＪＵＡＳソフトウェアメトリックス調査２００５年版参考） 3 3 1 2 基準工期に対し▲5％～▲10％以内

　ベンダの担当分に焦点を当てて評価する。 6 6 3 4 基準工期に対し▲10％～▲20％未満

10 10 5 7 基準工期に対し▲20％～▲30％以内

コミュニケーション基盤 ・コミュニケーションの速度および精度を低下させる物理的な要因を評価する → 内責は開発拠点（分散度）のみ -10 -5 -3 -3 利用制約のない基盤が確保され、適時適切に意思確認できる。

(P06) ・評価観点は以下のとおり → 基盤があっても秩序がない場合は評価しない -6 -3 -1 -1 利用制約のない基盤が確保されている

　a.開発拠点（分散度）　　b.資料･開発生産物の情報共有の基盤 　 「秩序がない」とは、例えばメーリングリストによる 0 0 0 0 基盤は確保されているが利用制約がある

　c.グループウエア・電子メールによる情報共有の基盤 　 大量情報の垂れ流しのように、決定したことがきちっ 6 3 1 1 指示が徹底されたことを確認する仕組みが欠けている

　 と伝達される仕組みが欠如していることを指す。 10 5 3 3 拠点が分散し、且つ、必要な基盤が確保されていない

レビュー体制(P07) ・共同レビューの目的・目標に照らして、レビュー体制およびレビュー方法 -5 -5 -3 -5 レビュー観点の整理および事前査読によりレビュー時間を短縮

　の適切性（効率および欠陥除去率などの品質向上への寄与率）を評価する -3 -3 -1 -3 事前に査読してレビュー時間を短縮

・体制：過剰なレビュー参加者要求はコスト増加に対して効果が少ない →体制：開発者全員によるレビュー実施など 0 0 0 0 適切な体制、方法で共同レビューを実施

・方法：多段階レビュー(担当者間→上司→その上司など）によるレビュー 　　　　対窓口レビュー以外のレビュー参加要請など 3 3 1 3 多段階もしくは関連範囲外へのレビュー参加要求

　　　　効率低下（なかなか収斂せず、結論が覆ることが多い） 5 5 3 5 多段階かつ関連範囲外へのレビュー参加要求

開発環境特性 開発手法／開発環境(P08) ・開発手法・開発環境（ソフト・ハード・ツール）について評価する → 既存テスト環境流用度合はツールとして評価する -3 -3 -5 -5 生産性向上の工夫が盛込まれた手法／環境

・評価観点は以下のとおり(「外責」にはベンダの習熟度の評価は含まない） 　 （標準試験項目セット有無も） -1 -1 -3 -3 一般的手法／環境であり安定度高

　a.機能充足度　　b.信頼性（安定性・使用実績） → 要件定義工程は要件定義手法・ツールなどを評価する。 0 0 0 0 一般的手法／環境であるが評価観点での不適あり

　c.操作・運用マニュアル具備状態　　ｅ.占有率(H/W等の占有利用可能の程度) 1 1 3 3 聞いたことはあるが特性がわからない手法／環境

　d.同時開発(ﾂｰﾙ、ｲﾝﾌﾗなどとｱﾌﾟﾘの同時開発） 3 3 5 5 聞いたこともない手法／環境

テスト手順書水準(P09) ・テスト手順の具体化度（操作手順＆入出力の具体化）を評価する － － － － －

－ － -3 -3 テスト項目、確認ポイントに限定して記載

－ － 0 0 キー項目実現値の記載を要求

－ － 2 2 入出力データ実現値すべての記載を要求

－ － 3 3 入出力データ実現値および手順の記載を要求

工程入力情報特性 業務関連資料(P10) ・既存資料についてはその信用度（正確性、最新度）を評価する 評価規準は以下の事項に着目して設定している -27 -7 -3 -3 検索しやすさを考慮し整備されている

他システム関連資料(P11) 　並行作成するものならば、上記に加え期日厳守率をあわせて評価する ・資料の整理のされ方 -16 -4 -1 -1 必要資料はすべて整合性をもって整備されている

規約・標準化関連資料(P12) ・他システム関連資料は当社がＩ／Ｆ設計およびテスト設計を実施する ・資料の読み易さ 0 0 0 0 必要資料の一部に不整合がある

　上で必要十分かつ正確な情報であるかを評価する ・情報の探し易さ 16 4 1 1 必要資料は整備されているが不整合が散見する

・規約・標準化資料は複数存在していたり不整合がないか評価する 27 7 3 3 資料の不足があり他資料からの補完が必要

影響度（％）

外責評価基準（見積プレゼン用）

要件定義の影響度は、以下の３要素を単純に加算した結果です。・業務関連資料：-10～+10・他ｼｽﾃﾑ関連資料：-10～+10・規約・標準関連資料：-7～+7

生産性特性 副生産性特性 評価の観点 内責評価基準（参考）

内容 特記、特例事項要件定義

設計 製作 テスト設計 製作 テスト

顧客の協力特性 役割分担特性(P13) ・顧客がベンダに協力する度合および顧客とベンダとの役割分担の明確性 ・ベンダが直接エンドユーザと交渉して開発する場合 － － － －

　を評価する ・エンドユーザとベンダの間に、情報システム部が入り、 － － － －

　エンドユーザと交渉した上で、ベンダに伝える場合と　では、ベンダ側の生産性は大分異なる。

-10 0 － 0 顧客側に情報ｼｽﾃﾑ担当窓口があり、ﾍﾞﾝﾀﾞは情報ｼｽﾃﾑ担当窓口と交渉する

0 5 － 5 ｴﾝﾄﾞﾕｰｻﾞの代表窓口とﾍﾞﾝﾀﾞとが直接交渉する

20 10 － 10 ｴﾝﾄﾞﾕｰｻﾞの代表窓口はなくﾍﾞﾝﾀﾞが直接交渉する

改造・再構築特性 既存システムへの練度 ・顧客／当社の改造の母体または再構築する元のシステムに関する熟練度が -50 -40 -10 -40 中核メンバー全員が母体システム経験多数

(P14) 　生産性に及ぼす影響を、それぞれ（外責／内責）個別に評価する -20 -20 -5 -20 中核メンバーの一部の母体システム経験経験少

→ 外責：プロジェクト全体としての母体システムへの 0 0 0 0 中核メンバーの一部に母体システム未経験者あり

・外責は、ユーザー部門を含む顧客プロジェクト組織全体の能力として 　 熟練者の比率で評価する 40 20 5 20 中核メンバーに母体システム経験者不在

　評価する 50 40 10 40 メンバー全員が母体システム経験なし

既存のテスト環境流用水準 ・既存のテストドキュメントおよびテストデータ（テスト環境を含む）の － － － －

(P15) 　流用可能度合をテストフェーズ別に評価する。 － － -20 -30 ５０％～７０％未満が流用できる

－ － -10 -20 ２０％～５０％未満が流用できる

－ － -5 -5 １０％～２０％未満が流用できる

－ － 0 0 １０％未満の流用に留まる

母体調査ツールの機能水準 ・母体の調査ツールの機能水準の高低を評価する。 － － － －

(P16) ・該当するツールなどの機能が以下の内容に当てはまる個数で評価する。 － -20 -10 -20 ４個～５個の機能を具備した調査ツールがある

　a.絞り込み機能　　b.モニタリング（ルート解析）機能 － -10 -5 -7 ２個～３個の機能を具備した調査ツールがある

　c.ドキュメント生成（リバース）機能 － 0 0 0 １個の機能を具備した調査ツールがある

　d.実機での稼働確認　　e.その他調査ツールなど － 15 5 10 調査ツールがない

既存母体の品質 ・改造/流用母体の品質特性から、以下の該当事象数（a～c）により評価する － － － － （注）各事象の影響度により、補正する

(P17) 　a.正確性（潜在バグ数） 0 0 0 0 該当する事象がない

　b.解析性（コメントに対する要求水準） 10 10 10 10 該当事象数　１

　c.環境適用性（多様なハード、ソフト、運用環境に適用度） 30 30 30 30 該当事象数　２

50 50 50 50 該当事象数　３以上

外責評価基準（見積プレゼン用）

品質特性 副品質特性 評価の観点 内責評価基準（参考）

内容 特記、特例事項要件定義

設計 製作 テスト設計 製作 テスト

機能性 合目的性(P18) ・ソフトウェアがユーザーニーズを満足させるために必要十分な機能を － －

　備えていることに対する要求（要件定義フェーズを対象とする） 0 既存業務で、システム化の目標が定まっている

　a.新規性(世の中にないものの考案)　　b.方針の明確性 20 システム化の方針が曖昧である

　c.ステークフォルダの納得性(ＲＯＩの明示度合） 50 ｽﾃｰｸﾌｫﾙﾀﾞが多様かつｼｽﾃﾑ化の方針が曖昧である

　d.ステークフォルダの多様性(ﾊﾞｯｸｵﾌｨｽ,ﾌﾛﾝﾄｵﾌｨｽ,一般ﾕｰｻﾞ/外部企業など) 100 上記に加えて、世の中にないものの考案が多い

（要求仕様の網羅性） ・ソフトウェアがユーザーニーズを満足させるために必要十分な機能を →要求仕様書の記述水準は標準ドキュメント記述文字数に － － － －

　備えていることに対する要求（設計～テストフェーズを対象とする） 　対する実要求仕様書記述文字数で評価できる 0 － 0 必要項目・水準が網羅された要求仕様書が存在

・ユーザーニーズの具体性、網羅性、ステークフォルダの同意度合を評価し、 　網羅性、ステークフォルダの同意度合を加味して評価 7 － 3 必要項目・水準のどちらかに多少、不備有り

　要求仕様書にユーザーニーズが具体的に記載されていない場合は、以降の → 未解決懸案項目数により評価レベルを調整する 15 － 6 必要項目・水準の両方に多少、不備有り

　工程でニーズの具体化・検証作業が必要になる → ユーザーヒアリング実施、プロトタイピング実施など 30 － 10 要求仕様書が不存在(代替:口頭説明,代替資料)

正確性(P19) ・実現されている機能が正常に動作することに対する要求 － － － － －

・前工程の機能が当該工程で正しく実現されていること、生産物間および機能間に 0 0 0 0 標準的なレビューにより確認・検証可能

　矛盾がないことを確認・検証する度合を評価する 2 2 1 2 標準に対し１．５倍のレビュー工数を要す

・具体的にはレビュー充実度で評価するが、上位工程においては生産物作成過程 → レビュー工数の標準は各工程の全体工数の 3 3 2 3 標準に対し２．０倍のレビュー工数を要す

　における確認・検証作業も考慮する 　 10％程度とする 5 5 3 5 標準に対し３．０倍以上のレビュー工数を要す

接続性(P20) ・ソフトウェアが他ソフトウェアや他システムと容易に接続・運用できることに →インタフェース数の増加は規模の環境変数で評価 -10 -5 － -5 社内のｲﾝﾀﾌｪｰｽのみでｲﾝﾀﾌｪｰｽ先が1件/100KS以内

　対する要求で、データの共通化や通信手段・インターフェイスの共通化検討が →インタフェーズ数は共通化により抑えることができる 5 -3 － -3 社内のｲﾝﾀﾌｪｰｽのみでｲﾝﾀﾌｪｰｽ先が3件/100KS以内

　必要になり、社外と接続するか否かも影響する 　が、接続先が多いと調整負荷が増加する 0 0 － 0 社外とのｲﾝﾀﾌｪｰｽを含みｲﾝﾀﾌｪｰｽ先が3件/100Ks以内

・上記を考慮して設計すべきインタフェース先の数で評価する →留意事項：保有システム規模が大きい程、インタ 5 3 － 3 社外とのｲﾝﾀﾌｪｰｽを含みｲﾝﾀﾌｪｰｽ先が7件/100Ks以内

　設計の難易度とインターフェーステストの複雑さに影響する 　フェース先の数も増加する傾向にある 10 5 － 5 社外とのｲﾝﾀﾌｪｰｽがありｲﾝﾀﾌｪｰｽ先が8件/100KS以上

整合性(P21) ・実現されている機能が公的規則・規格・基準に一致し、正常に動作することに →他ｼｽﾃﾑ、他ﾌﾟﾛｼﾞｪｸﾄとの方針整合性の保持などの -10 -5 -3 -3 整合をとる規則・規約が0件

　対する要求で、従うべき規則・基準が多いほど整合性の確認・検証作業が 　全体最適性も含む。 -5 0 0 0 整合をとる規則・規約が1件

　必要になる →ｸﾞﾛｰﾊﾞﾘｾﾞｰｼｮﾝ(多言語対応、多通貨対応、多国制度対応) 0 3 1 1 整合をとる規則・規約が2件

・金融監督庁、会計監査法人等が行う「外部監査基準」に基づく要求も 　を含む。 5 5 3 3 整合をとる規則・規約が3件以上

　本副品質特性で評価する 10 10 5 5 全体最適性の再構築が必要

効率性 実行効率性(P22) ・定められた条件下で所定の処理を実行する早さに対する要求 － － － － －

・具体的には、処理を要求してから結果が得られるまでの速さや単位時間に → 実現方式の検討要否および事例有無により評価 0 0 0 0 一般的要求水準で既知の事例にて実現が可能

　遂行される仕事の量を示す 2 3 2 3 既知の最適事例の１．２倍の速さを要求

・要求が高ければ設計工程における実現可能性検証やテスト工程における → 机上検証、ベンチマークテスト、パイロット開発など 3 6 3 6 既知の最適事例の１．５倍の速さを要求

　障害解析・対応作業の難易度が高まる 5 10 5 10 既知の最適事例の２．０倍以上の速さを要求

資源効率性(P23) ・定められた条件下で所定の処理を実行する際、資源を有効に使用することに － － － － －

　対する要求 0 0 0 0 一般的要求水準で既知の事例にて実現が可能

・具体的には、プログラムの実行に必要な資源の量、ハードウェア資源の使用の → ＣＰＵ使用率、主記憶使用量、ファイル使用量、 2 3 2 3 既知の最適事例の１．２倍の有効性を要求

　有効性に対する要求 　 ネットワーク使用量に対する要求 3 6 3 6 既知の最適事例の１．５倍の有効性を要求

→ 実現方式の検討要否および事例有無により評価 5 10 5 10 既知の最適事例の２．０倍以上の有効性を要求

保守性 解析性(P24) ・故障または運用上の不都合が発見された場合、どの程度労力をかけることなく → ソースコードのコード化規約に着目して、コメントに － － － － －

　原因の解析ができるかに対する要求 　 対する要求水準により評価する － － 0 － 機能概要を記述するヘッダコメントを付加

・解析用機能は規模環境変数として定義し、生産性環境変数としてはソースの → 旧コメント率、ＪａｖａＤｏｃ用コメントなどに対応し － － 2 － 上記に加え、50行程度毎にﾌﾞﾛｯｸｺﾒﾝﾄを付加

　解析性向上のための作業（リバースエンジニアリング用情報付加等）を対象 　 名称を変更 － － 3 － 上記に加え、20行程度毎にﾌﾞﾛｯｸｺﾒﾝﾄを付加

－ － 5 － ﾘﾊﾞｰｽﾂｰﾙで仕様を作成できる程度のｺﾒﾝﾄを付加(ｺｰﾄﾞを読めない人でも処理内容を理解できる）

安定性(P25) ・ソフトウェアに変更を施した場合、システム全体の品質がレベルダウンしない →将来変更が発生する確率が高いと想定される場合 － -3 -3 － システムのライフサイクル目標が２年未満

　ことに対する要求 　設計上将来の変更容易性（変更箇所の局所化を含む） 0 0 0 － システムのライフサイクル目標が５年未満

　拡張性（10年使えるシステム等）も本副品質特性で評価する 　考慮しなければならない 2 2 2 － システムのライフサイクル目標が７年未満

・当該要求を実現するために、上流工程においてデータ正規化やオブジェクト指向 3 4 3 － システムのライフサイクル目標が７年～１０年

　などの設計手法を取り入れることが必要となる場合もある 5 7 5 － システムのライフサイクル目標は１０年超

移植性 環境適用性(P26) ・ソフトウェアをどの程度多様な環境に移すことができるかに対する要求 → ４項目に対する要求の数（種類）で評価する － － － － －

移植作業性(P27) ・環境適用性は多様なハード、ソフト、運用環境に適用する要求 0 0 0 0 移植要求なし

規格準拠性(P28) ・移植作業性は環境を移す際に必要な労力に対する要求 → インフラ変更に対する対応容易性など 2 2 1 2 移植要求が１種類

置換性(P29) ・規格準拠性は国際／国内基準を遵守する要求 4 4 2 3 移植要求が２～３種類

・置換性は置き換えた場合に使用環境／条件を変更せずに使用できる要求 7 7 3 5 移植要求が４種類以上

　Patent　Pending By　JASTEC(注１）移行、教育、保守、運用作業は、生産性環境変数の適用対象から除いている。(注２）内責評価基準はベンダー内部事情で発生する環境変数ゆえ、今回は除いている。(注３）評価基準の影響度は実運用上、工程毎のアクティビティ（作業）単位に影響度を設定している。今回、工程は要件定義、設計、製作、テストと簡略化し、アクティビティも省略している。

外責評価基準（見積プレゼン用）

規模環境変数

生産物量見積方式 ＶＢ

ｉ　＝　ＶＢ

ｉ－１　×　Ｈｉ　　　　　　　　　Ｈｉ　：生産物量変換変数

Ｖｉ　＝　ＶＢ

ｉ　×　（　１　＋　Σαｉｊ　）　　αｉｊ：生産物量環境変数

評価の観点 内責評価基準（参考）

品質特性 副品質特性 内 容 影響度

要件定義

設計 製作 テスト 設計 製作 テスト

機能性 合目的性(V00) 下記要因による機能要求の増加を該当事象数（a～d）により評価する － － － － （注）各事象の影響度により、補正する

a.利用者の所在の広がり(ﾊﾞｯｸｵﾌｨｽ→ﾌﾛﾝﾄｵﾌｨｽ→一般ﾕｰｻﾞ)および利用時間の増加 0 0 0 0 該当する事象はない

b.ｽﾃｰｸﾌｫﾙﾀﾞｰの増加に伴う規模の増加（保有ｼｽﾃﾑ規模で評価） 10 10 10 10 該当事象数　１

c.ｺﾝﾃｨｼﾞｪﾝｼｰに対応する機能要求の付加 30 30 30 30 該当事象数　2～3

d.不正な移行元ﾃﾞｰﾀに対する配慮（例外処理など） 50 50 50 50 該当事象数　４以上

正確性(V01) ・実現されている機能が正常に動作することに対する要求 － － － － －

・前工程の機能が当該工程で正しく実現されていること、生産物間および機能間に － － 0 0 標準的なテスト項目により確認・検証可能

　矛盾がないことを確認・検証する度合を評価する － － 10 20 標準に対し１．２倍のテスト項目を要す

・具体的にはテスト密度で評価する － － 15 30 標準に対し１．５倍のテスト項目を要す

　標準テスト密度はテスト項目ガイド（別途）で定める － － 20 50 標準に対し２．０倍以上のテスト項目を要す

接続性(V02) ・ソフトウェアが他ソフトウェアや他システムとデータやコマンド等をやりとり - － － － －

　できる度合いに対する要求であり、コード変換、フォーマット変換の設計／ 0 0 0 0 変換数　　０

　実装が必要になる 2 10 10 10 変換数　　～５

・コード変換、フォーマット変換数で評価する 3 15 15 15 変換数　　５～１０

5 20 20 20 変換数　　１１以上

セキュリティー(V03) ・ソフトウェアが情報の漏洩・紛失・外部からの不正使用やシステム資源の － － － － －

　破壊等を防止あるいは検出できることに対する要求で、アクセス管理機能や 0 0 0 0 実現機能数　０ ～ １

　記録管理機能の設計／実装が必要となる 10 10 10 10 実現機能数　２ ～ ３

・対応が必要なセキュリティ機能の数で評価する 15 15 15 15 実現機能数　４ ～ ５

　※機能要件に定義されている部分は除く。詳細は、補足資料参照。 20 20 20 20 実現機能数　６以上

信頼性 成熟性(V04) ・ソフトウェアシステムに障害が起きた場合に、他システムコンポーネントへの － － － － －

　影響を遮断できることや、２次障害の影響を少なくできることに対する要求 0 0 0 0 実現機能数　０

・対応が必要な故障低減機能の数で評価する 2 3 3 3 実現機能数　１

3 6 6 6 実現機能数　２

5 10 10 10 実現機能数　３以上

障害許容性(V05) ・障害が発生しても、それをダウンとして顕在化させないことに対する要求で － － － － －

　異常が顕在化しないうちに再試行する機能やチェック強化によるダウン発生の 0 0 0 0 実現機能数　０

　回避機能の設計／実装が必要となる 2 3 3 3 実現機能数　１

・対応が必要な異常検知機能の数で評価する 3 6 6 6 実現機能数　２

5 10 10 10 実現機能数　３以上

回復性(V06) ・ソフトウェアシステムがダウンしてから再稼動し、処理再開するまでの時間が － － － － －

　短いことに対する要求 0 0 0 0 実現機能数　０

・対応が必要な再開処理機能の数で評価する 2 3 3 3 実現機能数　１

3 6 6 6 実現機能数　２

5 10 10 10 実現機能数　３以上

影響度（％）

外責評価基準（見積プレゼン用）

評価の観点 内責評価基準（参考）

品質特性 副品質特性 内 容 影響度

要件定義

設計 製作 テスト 設計 製作 テスト

影響度（％）

外責評価基準（見積プレゼン用）

使用性 理解性(V07) ・ソフトウェアの機能、働きが分かりやすいことに対する要求 － － － － －

・作成するプレゼンテーションツールの数で評価する － 0 － － 作成対象数　０

（留意）理解性を向上させる為の操作マニュアル作成アクティビティのみ対象 － 3 － － 作成対象数　１

（影響度：0～100％） － 6 － － 作成対象数　２

－ 10 － － 作成対象数　３以上

習得性(V08) ・ソフトウェアの使い方が学びやすいことに対する要求 － － － － －

・作成するマニュアルの数で評価する － 0 － － 作成対象数　０

（留意）習得性を向上させる為の操作マニュアル作成アクティビティのみ対象 － 3 － － 作成対象数　１

（影響度：0～100％） － 6 － － 作成対象数　２

－ 10 － － 作成対象数　３以上

操作性(V09) ・使用者からソフトウェアへの働きかけが簡単にでき、かつ分かりやすく － － － － －

　心理的／肉体的に疲れにくくなっていることに対する要求 0 0 0 0 実現機能数　０ ～ １

　（ソフトウェアの運用の容易さ、インストールの容易さを含む） 3 10 10 10 実現機能数　２ ～ ３

・対応が必要な操作性向上機能の数で評価する 6 15 15 15 実現機能数　４ ～ ５

10 20 20 20 実現機能数　６以上

保守性 解析性(V10) ・故障または運用上の不都合が発見された場合、どの程度労力をかけることなく － － － － －

　原因の解析ができるかに対する要求 － 0 0 0 実現機能数　０ ～ １

・対応が必要な解析機能の数で評価する － 3 3 3 実現機能数　２ ～ ３

－ 6 6 6 実現機能数　４ ～ ５

－ 10 10 10 実現機能数　６以上

変更作業性(V11) ・ソフトウェアの変更実施が容易であることに対する要求 － － － － －

　ソフトウェアの目的、働き、特徴等の外部から見た理解の容易さと、構造や － 0 － － 作成対象数　０

　アルゴリズム等の内部の実現方法の理解の容易さを含む － 3 － － 作成対象数　１

・作成する保守用ドキュメントの数で評価する － 6 － － 作成対象数　２

（留意）操作マニュアル作成アクティビティのみ対象（影響度：0～200％） － 10 － － 作成対象数　３以上

試験性(V12) ・ソフトウェアのテストや性能、効率等の特性の評価が容易であることに対する － － － － －

　要求（準備、実行のための労力や、ソフトウェアの実行状況の測定を含む） － 0 0 0 作成対象数　０

・対応が必要な試験機能の数で評価する － 3 3 3 作成対象数　１

－ 6 6 6 作成対象数　２

－ 10 10 10 作成対象数　３以上

　Patent　Pending By　JASTEC(注１）移行、教育、保守および運用作業は、規模環境変数の適用対象から除いている。　　　但し、ソフトウェア開発において、保守、移行、運用等で効率性が向上する支援ドキュメントの作成は、設計工程にオプションとして含めている。(注２）内責評価基準はベンダー内部事情で発生する環境変数ゆえ、今回は除いている。(注３）評価基準の影響度は実運用上、工程毎のアクティビティ（作業）単位に影響度を設定している。今回、工程は要件定義、設計、製作、テストと簡略化し、アクティビティも省略している。