システム・リファレンス・マニュアル（srm）第2巻 - ipa（srm）第2巻...

システム・リファレンス・マニュアル（ＳＲＭ）

第２巻

独立行政法人情報処理推進機構（ IPA）

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

システム・リファレンス・マニュアル（ＳＲＭ）

第２巻

独立行政法人情報処理推進機構（IPA）

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

本報告書は、独立行政法人情報処理推進機構から委託を受け作成いたしました。作成実施機関：社団法人日本情報システム・ユーザー協会（JUAS）

All Rights Reserved , Copyright © IPA 2006

・Excel、Internet Explorer、Microsoft、PowerPoint、Visio、Visual Basic、Windowsは米国および／または他の国の Microsoft Corporation の登録商標または商標です。

・UNIX は、X/Open カンパニーリミテッドがライセンスしている米国およびその他の国に

おける登録商標です。・CMMi は、米国およびその他の国におけるカーネギーメロン大学の登録商標です。・Google は Google Inc.の登録商標です。・Yahoo!と Yahoo!のロゴマークは、米国ヤフーの登録商標または商標であり、ヤフー株式

会社はこれらに関する権利を保有しています。・Linux は、Linus Torvalds の米国およびその他の国における登録商標または商標です。・Java およびすべての Java 関連の商標およびロゴは、米国およびその他の国における米

国 Sun Microsystems, Inc.の商標または登録商標です。・COBIT と COBIT のロゴは、米国および／またはその他の国で登録された情報システム

コントロール財団（Information Systems Audit and Control Foundation）および IT ガ

バナンス協会（IT Governance Institute）の商標です。・その他の社名および製品名は、それぞれの会社の登録商標または商標です。・本文中には、TM、®マークは明記しておりません。

i

＜システム・リファレンス・マニュアル（ＳＲＭ）第２巻目次＞

システム・リファレンス・マニュアル（ＳＲＭ）の作成 .......................................... 1

◆ 第１章経営企画と人材育成 ◆ 第１節経営戦略と IT 組織 ...................................................................................... 3

１．企業内システム部門の組織変化の背景 ................................................. 4 （１）汎用機時代 ..................................................................................... 4 （２）クラサバ時代 ................................................................................. 4 （３）Web インターネット時代............................................................... 6

２．IT 組織の変化 ....................................................................................... 8 ３．情報子会社 .......................................................................................... 10 （１）情報子会社の存在状況 ................................................................. 10 （２）組織形態とその特徴..................................................................... 11 （３）情報子会社の経営形態 ................................................................. 13 （４）情報子会社の方向性..................................................................... 14 （５）関連会社へのサポート ................................................................. 15

４．親会社の IT 組織 ................................................................................. 16 ５．アウトソーシング ............................................................................... 17 ６．グローバル化時代を迎えて

（今後の発展今後の組織に及ぼす要因と影響） ........................ 19 （１）IT グローバルマネジメント......................................................... 19 （２）システム部門の体質変化 ............................................................. 20

７．IT 活動の見える化 .............................................................................. 20 （１）顧客との見える化 ........................................................................ 21 （２）経営者に対しての見える化 .......................................................... 23 （３）関係会社に対しての見える化 ...................................................... 24 （４）システム関係者（企画、開発、保守、運用）に対しての

見える化 ..................................................................................... 25 （５）株主に対しての見える化 ............................................................. 27

第２節人材戦略..................................................................................................... 29

１．組織経営に求められる情報システム機能............................................ 30 ２．各情報システム機能を実現するために必要な能力 ............................. 39 ３．情報システムに関与する人材の役割と現状 ........................................ 42 ４．組織力強化に向けた IT 人材育成の考え方.......................................... 50

ii

第３節提案力の強化.............................................................................................. 53 １．提案力の強化 ...................................................................................... 54 ２．提案力をめぐる実態と諸問題 ............................................................. 55 （１）企画提案力の強化 ........................................................................ 55 （２）IT 部門が利用部門から求められている提案................................ 56 （３）情報子会社、ベンダーに求める企画提案 .................................... 59 （４）各自の得意分野を活かして、事業貢献を .................................... 60 （５）情報子会社、ベンダーからの企画提案に対する

インセンティブ........................................................................... 62 （６）企画提案力不足の原因 ................................................................. 63

３．提案の課題とは何か............................................................................ 67 （１）課題が明確な場合 ........................................................................ 67 （２）課題が漠然としている場合 .......................................................... 69 （３）課題発見ユーザーは課題に気がついていない.......................... 69

４．問題とは何か、管理とは何か ............................................................. 70 ５．問題の見つけ方目の付けどころを何におくか ................................. 72

（１）BSC（Balanced Score Card ） .................................................. 72 （２）生産の 6 大要素............................................................................ 72 （３）5M＆I .......................................................................................... 73 （４）三次元的視野 ............................................................................... 73

６．企業は何を変えるのかユーザー企業の 3 変革要素.......................... 74 ７．業務改革の手法 ................................................................................... 76 （１）ケプナートリゴー法..................................................................... 76 （２）JUAS での追加検討項目.............................................................. 77

第４節 CIO の存在と役割 ...................................................................................... 79

１．企業における位置づけ ........................................................................ 80 （１）経営トップ、CIO、IT 部門の関係 .............................................. 80 （２）CIO の役職 .................................................................................. 84 （３）CIO の担当期間 ........................................................................... 86 （４）主な経験分野 ............................................................................... 88 （５）IT 以外の担当分野 ....................................................................... 93 （６）IT 関連業務への投入時間割合 ..................................................... 95

２．CIO の責任範囲と充足度 .................................................................... 99 （１）主な責任範囲 ............................................................................... 99 （２）責任範囲における充足度 ........................................................... 102 （３）不安に感じる項目 ...................................................................... 105 （４）責任を果たすために感じている悩み.......................................... 107 （５）必要とされる知識や能力 ........................................................... 109 （６）IT 担当役員として勉強したい点.................................................111

３．CIO への課題と期待 ......................................................................... 114 （１）CIO と企業の相関...................................................................... 114 （２）CIO 人材について...................................................................... 116 （３）CIO への期待............................................................................. 117

iii

◆ 第２章情報共有と情報活用 ◆ 第１節情報共有の目的と実態 ............................................................................. 121

１．情報共有の目的と目指すべき効果 .................................................... 122 ２．情報共有の実態 ................................................................................. 124 （１）全体の概況 ................................................................................. 124 （２）業務系の共有 ............................................................................. 128 （３）フロー情報 ................................................................................. 129 （４）ストック情報と知識・ノウハウ................................................. 131 （５）情報共有が進まない原因・推進上の課題 .................................. 133

３．情報共有とセキュリティ対策 ........................................................... 136 第２節情報共有の活用 ........................................................................................ 137

１．情報共有システムの構築方法 ........................................................... 138 （１）DMAIC 法.................................................................................. 138 （２）JUAS 法..................................................................................... 139

２．５種類の情報共有の進め方の特徴 .................................................... 140 （１）基幹業務情報 ............................................................................. 140 （２）顧客情報の共有.......................................................................... 144 （３）フロー情報 ................................................................................. 147 （４）ストック情報 ............................................................................. 148 （５）Know-Who 情報......................................................................... 151

３．企業の情報共有ベストプラクティス................................................. 155 （１）日本企業における情報共有と情報活用の実態 ........................... 157 （２）情報共有の事例紹介................................................................... 159

第３節情報共有技術の発展と今後 ...................................................................... 173

１．情報共有の発展（Web 2.0 の企業への影響など）............................ 174 （１）情報共有ツールの歴史的な変遷................................................. 175 （２）情報の蓄積 ................................................................................. 176 （３）情報の検索 ................................................................................. 178 （４）その他の情報共有ツール ........................................................... 181 （５）インターネットの世界 ............................................................... 183

２．情報共有の制約と対策 ...................................................................... 188 （１）個人情報共有の制約................................................................... 188 （２）内部統制上の制約 ...................................................................... 189 （３）各種法律への対策 ...................................................................... 189

３．情報共有・管理の実践手段 ............................................................... 189 （１）形式知化 .................................................................................... 189 （２）蓄積............................................................................................ 190 （３）検索............................................................................................ 190 （４）管理............................................................................................ 190

４．情報過多時代の選択と対策（情報廃棄）.......................................... 191

iv

◆ 第３章開発保守技術 ◆ 第１節開発の実態と評価 .................................................................................... 195

１．第一巻以降の変化 ............................................................................. 196 ２．U 字型開発法モデル.......................................................................... 196 （１）U 字型開発法の名前の由来........................................................ 197 （２）U 字型開発法の範囲 .................................................................. 197 （３）U 字型開発法の要素 .................................................................. 200

３．各要素についての解説 ...................................................................... 201 （１）企画段階のシステムコンセプト確立.......................................... 201 （２）見積の透明性 ............................................................................. 202 （３）ユーザーによるシステム要求 .................................................... 207 （４）徹底レビュー ............................................................................. 214 （５）ユーザビリティの確保 ............................................................... 215 （６）UVC 判りやすい仕様の書き方 .................................................. 218 （７）目標を持って管理（EASE） ..................................................... 220 （８）単体テストの徹底 ...................................................................... 229 （９）単体テスト完了でユーザーに開示 ............................................. 230 （10）結合、総合、実運用試験の最小化............................................. 230 （11）DB パトロール .......................................................................... 231 （12）移行計画は早期準備 .................................................................. 232 （13）カットオーバー（サービスイン）の日に SE は定時帰宅を ...... 235 （14）保守運用の信頼性向上............................................................... 236 （15）利活用が最重要 ......................................................................... 238

第２節保守の実態と評価 .................................................................................... 239

１．保守作業の概要 ................................................................................. 240 （１）保守戦略 .................................................................................... 240 （２）保守作業開始前.......................................................................... 240 （３）問合せ調査 ................................................................................. 241 （４）保守作業受付と作業見積 ........................................................... 242 （５）修正作業の実施.......................................................................... 244 （６）移行と評価 ................................................................................. 247 （７）保守担当者の育成 ...................................................................... 248 （８）管理業務 .................................................................................... 248

２．保守作業基本分析 ............................................................................. 249 （１）保守調査対象プロジェクトの属性 ............................................. 249

３．保守推進体制分析 ............................................................................. 254 （１）保守組織 .................................................................................... 254 （２）保守依頼数と実施割合 ............................................................... 256 （３）保守要員一人当たり年間対応件数 ............................................. 259 （４）保守要員の守備範囲................................................................... 261

４．保守作業分析 .................................................................................... 263 （１）保守作業負荷 ............................................................................. 263 （２）見積基準 .................................................................................... 263 （３）見積作業工数との対比 ............................................................... 264 （４）修正の実施 ................................................................................. 264 （５）移行と評価 ................................................................................. 266 （６）保守担当者の育成 ...................................................................... 266 （７）管理業務 .................................................................................... 267

v

第３節ユーザビリティと画面デザインプロセス................................................. 273 １．ユーザビリティの必要性................................................................... 274 ２．ユーザビリティとシステム開発 ........................................................ 278 （１）ウォーターフォール型とスパイラル型 ...................................... 278 （２）上流工程はスパイラル型、下流工程はウォーターフォール型 .. 278 （３）「人間系」の問題解決メソッド................................................... 279

３．User-Centered Design（UCD）メソッドの全体像 ......................... 280 （１）UCD メソッドとは .................................................................... 280 （２）「画面デザインプロセス」の位置付け ........................................ 281

４．企画................................................................................................... 283 （１）プロジェクトの発足................................................................... 283 （２）企画内容の共有.......................................................................... 283 （３）制約条件の共有.......................................................................... 284 （４）現状分析 .................................................................................... 284 （５）競合分析 .................................................................................... 285 （６）ゴール分析：〈クリティカル〉................................................... 285

５．設計：調査分析フェーズ................................................................... 287 （１）ユーザー観察 ............................................................................. 288 （２）ユーザーインタビュー ............................................................... 289 （３）ペルソナ作成：〈クリティカル〉 ............................................... 290 （４）シナリオ作成：〈クリティカル〉 ............................................... 292 （５）タスク分析：〈クリティカル〉................................................... 294 （６）機能分析：〈クリティカル〉 ...................................................... 296

６．設計：プロトタイピングフェーズ .................................................... 301 （１）タスクフロー作成：〈クリティカル〉 ........................................ 301 （２）プロトタイピング：〈クリティカル〉 ........................................ 307 （３）プロトタイプの評価：〈クリティカル〉 .................................... 311

７．実装前工程 ........................................................................................ 313 （１）実装の準備：〈クリティカル〉................................................... 313 （２）実装............................................................................................ 315

第４節システム再構築の課題と対策................................................................... 317

１．基幹システム再構築の状況 ............................................................... 318 （１）84％の企業が基幹システムの再構築に直面 .................................. 318

（２）企業規模が大きいほど再構築が進む.......................................... 318 （３）再構築が盛んな業種................................................................... 319

２．再構築の主な理由 ............................................................................. 320 （１）再構築は業務改革のために ........................................................ 320

３．再構築プロジェクトの投資規模 ........................................................ 321 （１）再構築に投じるコストは平均 14 億円 ....................................... 321

４．再構築の対象業務 ............................................................................. 322 （１）再構築の対象 ............................................................................. 322 （２）再構築により業務変革を伴うケースが 8 割............................... 322

５．再構築を推進する部門・体制 ........................................................... 323 （１）大企業では経営トップと利用部門が再構築をリード................. 323 （２）経営トップや利用部門の関心度は参画度に比例........................ 324 （３）IT 部門だけでは業務変革はできない ........................................ 325 （４）関係部門とプロジェクト体制をとる場合は予算に注意 ............. 326

vi

６．再構築後の構想 ................................................................................. 327 （１）再構築後のシステムのライフ .................................................... 327 （２）再構築後のハードウェア ........................................................... 328 （３）再構築後のソフトウェア開発方針 ............................................. 328 （４）脱ホストはパッケージ採用に意義ありか .................................. 329 （５）パッケージの採用は企業規模を問わない全般的な傾向 ............. 330 （６）再構築後のプログラム言語 ........................................................ 331 （７）Windows システム＝VB、UNIX システム＝Java.................... 331

７．再構築プロジェクトの工期・費用・品質.......................................... 332 （１）再構築の結果には概ね満足 ........................................................ 332 （２）品質はプロジェクトリーダー、

プロジェクトマネジメント次第か ............................................ 333 ８．再構築プロジェクトの課題 ............................................................... 335

（１）現行機能の継承とユーザーの理解・協力を得ることが大きな課題 ................................................................................ 335

９．システムの再構築の課題と対策 ........................................................ 336 （１）システム再構築が何故発生するのか、

何故再構築プロジェクトは難しいのか ..................................... 336 （２）システム再構築のタイプと難しさ ............................................. 337 （３）システム再構築の概念 ............................................................... 339 （４）業務システムと情報システムとの境.......................................... 340 （５）移行問題 .................................................................................... 343 （６）再構築推進体制.......................................................................... 344 （７）プロジェクトマネジメント ........................................................ 344

vii

◆ 第４章システムの信頼性確保 ◆

第１節システム監査............................................................................................ 363

１．システム監査の実施状況とその課題................................................. 364 （１）実施状況 .................................................................................... 364 （２）実施状況からみたシステム監査の課題 ...................................... 365

２．システム監査とその位置づけ ........................................................... 366 （１）システム監査の概要とその重要性 ............................................. 366 （２）システム監査とその視点 ........................................................... 369 （３）システム監査の位置づけ ........................................................... 370 （４）システム監査の法的規制 ........................................................... 371 （５）システム監査と関連する諸施策・制度 ...................................... 372

３．システム監査の課題と対応 ............................................................... 376 （１）システム監査で「何を」監査するのか ...................................... 376 （２）システム監査人の資格と育成 .................................................... 378 （３）システム監査の手順................................................................... 382 （４）システム監査手法 ...................................................................... 384

４．付加価値の高いシステム監査の実現に向けて（留意点）................. 386 （１）経営者にとってのシステム監査................................................. 386 （２）明確な目的設定.......................................................................... 386 （３）着眼点の明確な指示................................................................... 387 （４）アウトソーシング業務へのシステム監査 .................................. 387 （５）システム監査人の育成 ............................................................... 388 （６）独自のシステム監査チェックリスト.......................................... 389 （７）事実誤認有無確認調査の重要性................................................. 389 （８）自己チェック ............................................................................. 390 （９）システム監査のコストパフォーマンス ...................................... 390 （10）システム監査に関する法令等 .................................................... 391

第２節事業継続計画（BCP） ............................................................................. 395

１．企業リスクと事業継続計画の必要性................................................. 396 （１）災害・システム障害と事業継続の必要性 .................................. 396 （２）事業継続計画（BCP）の範囲 .................................................... 397 （３）事業継続計画（BCP）の概念 .................................................... 397 （４）最新のシステム障害事例 ........................................................... 399

２．事業継続計画（BCP）の取組み ....................................................... 401 （１）各企業の事業継続計画（BCP）取組み状況 .............................. 401 （２）業種別の事業継続計画（BCP）取組み状況 .............................. 402 （３）事業継続計画（BCP）策定企業の

災害発生後の業務再開目標時間................................................ 403 （４）アウトソーシングしている企業は｢丸投げ｣傾向........................ 405 （５）自社対応の情報システム防災対応はまだ不十分........................ 405 （６）IT システムの保全対策状況....................................................... 406

３．事業継続計画（BCP）策定と実施及び運用...................................... 407 （１）事業継続計画の目的 ................................................................. 407 （２）事業継続計画（BCP）サイクルの確立...................................... 407 （３）事業継続計画の行程 ................................................................. 408 （４）事業継続計画（BCP）のサイクル運用体制フローの確立 ......... 416 （５）事業継続計画（BCP）導入のポイント...................................... 417

viii

４．基幹務システムのバックアップシステム状況 .................................. 418 （１）基幹システムのバックアップ施策 ............................................. 418 （２）システム障害を削減する施策 .................................................... 420

５．ディザスターリカバリ ...................................................................... 421 ６．参考................................................................................................... 424

◆ 第５章リスク管理・内部統制 ◆ 第１節リスク管理態勢構築の基本的な概念 ........................................................ 427

１．はじめに ................................................................. 428 ２．リスク管理とは何か（守りの IT 戦略の担い手） ............................. 429 （１）リスクベースアプローチ ........................................................... 431 （２）リスクの認知・予測の歪み ........................................................ 432

３．システムリスク（IT リスク）とは何か ............................................ 434 ４．内部統制（Internal Control）とは何か ........................................... 435 ５．リスク管理で重要なこと ................................................................. 437

第２節リスク管理・内部統制を巡る様々な流れ（歴史編） .............................. 441 １．米国における内部統制の歴史 ........................................................... 444 （１）トレッドウェイ委員会 ............................................................... 444 （２）COSO フレームワークのレポート............................................. 444

２．英国における内部統制の考え方（ターンバルガイダンス） ............. 445 （１）ターンバルガイダンスの成立 .................................................... 445 （２）ターンバルガイダンスの特徴 .................................................... 446

３．COSO-ERM（Enterprise Risk Management）の考え方 ............... 446 （１）COSO-ERM とは....................................................................... 446 （２）COSO-ERM 作成の背景 ............................................................ 446 （３）COSO-ERM とは何か ............................................................... 447 （４）COSO-ERM で何が変わったか ................................................. 448

４．COSO のシステム統制を具現化した COBIT ................................... 450 （１）歴史............................................................................................ 450 （２）COBIT の特徴（第 3 版ベース）............................................... 451 （３）COSO 等との関係...................................................................... 451

５．米国企業改革法（Sarbanes‐Oxley 法）......................................... 452 （１）監査法人に対する規制の強化 .................................................... 453 （２）公開企業に対する規制の強化 .................................................... 453

６．日本における内部統制の考え方（ソロバン時代の内部統制） ................................................... 456

７．日本における内部統制の考え方（時代を先取りした金融庁検査マニュアル） .......................... 457

（１）検査マニュアルのできるまで .................................................... 457 （２）検査についての金融庁の考え方................................................. 457 （３）検査マニュアル.......................................................................... 458

８．裁判で取り上げられた内部統制の不備および会社法が定める内部統制................................................ 459

（１）裁判で取り上げられた内部統制の不備 ...................................... 459 （２）会社法が定める内部統制 ........................................................... 459

ix

９．日本における内部統制の考え方① （経済産業省「リスク新時代の内部統制」） ............................ 460

（１）経済産業省「リスク新時代の内部統制」作成の背景................. 460 （２）「リスク新時代の内部統制」の特徴 ........................................... 460

10．日本における内部統制の考え方② （経済産業省「開示・評価の枠組みについて」） ..................... 461

（１）「構築及び開示のための指針」の特徴 ........................................ 461 （２）問題点と積極的な取り組み事例................................................. 463

11．日本における内部統制の考え方③ （金融庁企業会計審議会の報告書）......................................... 464

12．リスク管理・内部統制の諸レポートの全体像 .................................. 466 （１）COSO フレームワークが浸透した理由 ..................................... 466 （２）歴史の流れと管理レベル ........................................................... 466 （３）COSO を中心とした流れ ........................................................... 467

第３節リスク管理（実践編）............................................................................. 469

１．システムリスクのシナリオ分析 ........................................................ 470 （１）「シナリオ」の意味 .................................................................... 470 （２）シナリオの描き方 ...................................................................... 471 （３）システムリスクシナリオ分析手法 ............................................. 473

２．数量的なトラブル管理（お客様迷惑度指数） .................................. 475 （１）要素ランクの設定 ...................................................................... 475 （２）指数の算出要領.......................................................................... 476

３．IT 法務 .............................................................................................. 477 （１）IT 法務の機能が求められる背景................................................ 478 （２）IT 法務の必要性......................................................................... 478 （３）IT 法務の役割 ............................................................................ 478 （４）IT 法務担当のミッション・資質................................................ 479

４．アプリケーションオーナー制度（発注者の果たすべき役割） ......... 480 ５．システム開発に係るリスク管理 ........................................................ 482 （１）基本を忠実に守る ...................................................................... 482 （２）数量的なプロジェクト管理 ........................................................ 483 （３）レビュー制度 ............................................................................. 483

６．システム運用に関わるリスク管理 .................................................... 484 （１）リスク管理の考え方................................................................... 484 （２）システム運用に関わるリスク管理の具体的なポイント ............. 486

７．自主点検（システムリスク管理態勢の確立） .................................. 487 （１）リスク管理の原点は、「自主点検」にある................................. 487 （２）自主点検は、総合的なものと

個別テーマによるものを使い分ける......................................... 488 （３）自主点検は、自社の現状を見ることから始まる........................ 488

x

第４節内部統制（実践編） ................................................................................ 491

１．内部統制での遵守事項・留意すべき事項の全体像 ........................... 492 （１）日本監査役協会「改定監査役監査基準」 .................................. 494 （２）企業内容等の開示に関する内閣府令.......................................... 494 （３）有価証券報告書の提出に関する金融庁の指導 ........................... 495 （４）東京証券取引所（証券市場からの要請） .................................. 495 （５）「システム監査基準」、「システム管理基準」 ............................. 496 （６）金融機関等コンピュータシステムの安全対策基準

（解説書：第 7 版） ................................................................. 496 ２．推進組織の考え方・コラボレーション ............................................. 497 ３．日本公認会計士協会の資料による財務諸表監査の流れ .................... 499 （１）IT の概括的理解のために企業が準備するもの .......................... 499 （２）企業及び企業環境を理解するために準備するもの .................... 500 （３）経営者の主張と IT のコントロール目標との関係を

理解するために準備するもの ................................................... 500 （４）各業務プロセスとの関係を理解するために準備するもの ......... 501 （５）ウォークスルーの実施 ............................................................... 502 （６）IT に関する統制の理解の留意点................................................ 502 （７）統制活動の理解の留意点（全般統制） ...................................... 504 （８）統制活動の理解の留意点（業務処理統制） ............................... 505 （９）その他参考となる留意点 ........................................................... 507

第５節今後の動向─内部統制進化論─ .............................................................. 511 １．内部統制とガバナンスの関係（信頼性のガバナンス） .................... 512 ２．リスク管理・内部統制の進化 ........................................................... 513 ３．組織・人材育成 ................................................................................. 515 （１）社内の推進体制.......................................................................... 515 （２）質の良い監査人・コンサルタントの確保 .................................. 516 （３）人材育成 .................................................................................... 517

４．リスク文化の醸成 ............................................................................. 517 （１）リスク管理態勢構築の難しさ .................................................... 517 （２）リスク文化の重要性................................................................... 518

５．最後に（見えた課題、残る課題） .................................................... 518 ６．付録 .................................................................................................. 520

◆ 参考資料一覧 ◆

1

「システム・リファレンス・マニュアル（SRM）」第２巻作成にあたって

JUAS は 280 社の日本のトップクラスの企業の IT 関係者の集まりで、40 を超えるプロ

ジェクト・研究会・フォーラムが走っている。そこで議論・検討されている内容は、非常

にレベルが高く示唆に富んでいるものが多い。そのノウハウをもっと広く紹介する目的で

平成 17 年 9 月に作成されたのが、システム・リファレンス・マニュアル第１巻である。第 1 巻の内容は主として以下の内容であった。・IT ガバナンス・人材育成・経営戦略と IT 投資の関係・ビジネスモデルの改革・IT 投資分析と IT 投資効果測定・システム開発プロジェクトマネジメント・システム保守・運用の指標・ユーザー満足度・ユーザビリティこの内容を熟読された方には非常に高評であったが、「このような視点を加えたらどう

か」「ここの分析が足りない」などの貴重なご指摘をいただいた。ドッグイヤーと呼ばれるだけあって、IT を巡る環境の変化は目覚しいものがある。JUASの研究会・セミナーで蓄積される情報量と質に関しても、ここ１年間で画期的な進歩を遂

げている。第１巻では書ききれなかったテーマ、発刊後の著しくレベルアップした情報の吸収を含

んだテーマなど、以下の内容となった。第１巻と第２巻あわせて企業の IT 化について必要

な知識はほぼ網羅したつもりである。・経営戦略と IT 組織・CIO の役割・人材育成・提案力の強化・情報共有と活用＊開発保守技術・システム再構築対策＊ユーザビリティ・システムの信頼性確保・内部統制・事業継続計画このうち、＊が付いたテーマは第 1 巻のレベルアップ版である。第２巻だけ読んでもご理

解いただけるように配慮したが、基礎理論に戻って理解したい方は第１巻も併せてお読み

いただけるとありがたい。なお、読者の便宜を考え 1、2 巻を通して索引やサマリー版を用意した。概要を知るうえ

では有効な役目を果たすものと期待している。今後は、合計で 1000 ページにも及ぶ大作となったことや、1 冊が厚くて重いため電車の

中などで読めない、などのご指摘を踏まえ、たとえば IT ガバナンス編、開発管理編、保守

2

運用編、ユーザビリティ編などに分割し、扱いやすく読みやすくして日本中に普及してゆ

かねばならないと考えている。さらに、必要情報をすばやく探すための情報検索の仕組みも検討を始めている。なお、第 2 巻に当たっては、光藤委員長をはじめとする「SRM レビュー委員会」メンバ

ーには、貴重なアドバイスの数々をいただき感謝している。また、情報処理推進機構（IPA）

からは、新谷様、保立様お二人にオブザーブ参加を賜り、貴重なアドバイスを頂いた。最後に、第 1 巻に引き続き、このような貴重な機会をいただいた IPA の関係者の方々に、

深くお礼申し上げる。

平成 18 年 11 月末

社団法人日本情報システム・ユーザー協会専務理事細川泰秀

3

概要と特徴 ■概要

ユーザー企業の IT 関係者はどの様な情報を求めているのかを念頭に置き、以下の整理

のもとに作成する。 ●ユーザー企業のシステム関係者が求めている基本情報 ●そのコンセプトとその解説：必ずしも１つでなく、数種類あってもよい。さまざまな考え方を柔軟に取り込みたい。

●コンセプトに基づく「評価指標とその値」とその解説 ●先進事例紹介：何を見て学べばよいのか、何を見れば前進できるのか。

●参考情報一覧：

■特徴 ●循環型モデルとらえ方として、評価基準値があり、これに対して、その時々の実績値を収集し、フ

ィードバックし、新たな評価基準値とする循環型のモデルである。また、評価基準値

だけでなく、この SRM 自体も循環型モデルと捉え、環境の変化を随時取り込んで反

映させていくことにより、ユーザー企業の方々の利活用に耐えうるものとなる。 ●ファジー情報の数値化ユーザー満足度をはじめとする数値化の難しいものの数値化を試み、客観性を持たせ

ることに大きな特徴がある。これも利用者（ユーザー）の視点と、フィードバックが

あって、はじめて客観性を持つものと思われる。 ■記述にあたっての留意事項

ａ．より一歩進んだ IT 活用や管理手法の情報を得たいと思っている IT 関係者の期待

に応えること。ｂ．従来の研究活動の成果をまとめるだけでなく、その後の環境の変化を含めて、「一

歩進んだ情報提供」とする。ｃ．視点はあくまでもユーザーの立場で、ユーザーの立場を主張できるものとする。ｄ．具体的に活用できる形の情報であること。

単に、「規格（ISO 等）には、このように作業するとなっている」と解説するので

はなく、「規格ではこのようになっているが、実際はこのような目標を持って実行

しているのが、一般的である」等の評価尺度を示す。

4

■本書における表記法について

●技術用語等のゆれについては、新聞・雑誌等で使われている表記法に準拠した。 ●主な調査報告書については、それぞれ次のように表記した。また、研究会、研究プ

ロジェクトの報告書は、適宜該当する報告書を一意に示す略称で表記した（巻末の

「JUAS 資料一覧」を参照）。 ○企業 IT 動向調査報告書 2004～2006 年版

それぞれ下記の略記とした。「IT 動向調査 2004」「IT 動向調査 2005」「IT 動向調査 2006」また、数年にわたる表記で、誤解のおそれの少ない場合は、単に「IT 動向調査」

と表記した。 ○ユーザー企業向けソフトウェアメトリックス調査報告書 2005 年版～2006 年版

それぞれ下記の略記とした。「ソフトウェアメトリックス調査 2005」「ソフトウェアメトリックス調査 2006」

○国内 CIO 実態調査報告書下記の略記とした。「国内 CIO 実態調査 2006」

●図表には原則として図表番号を付加し、表の場合は上に、図の場合は下に配置した。 ●他の書籍から引用した図表の場合は、その出典を明記した。ただし、執筆者が作成

した場合は特に記していない。 ■PDF 版について

システム・リファレンス・マニュアル第 1 巻および第 2 巻の PDF 版を、独立行政法人

情報処理推進機構のホームページにて提供している。 URL: http://www.ipa.go.jp/

■その他

本書に掲載されている Web サイトやその他の情報は、本書の編集時点で確認済みのも

のであり、本書の発行後、内容の変更、追加、削除やアドレスの移動、閉鎖などが行

われる可能性がある旨、あらかじめご了承いただきたい。

5

■SRM・レビュー委員会

委員長光藤昭男株式会社荏原製作所常務執行役員

副委員長伊賀哲雄東洋インキ製造株式会社執行役員 SCM 本部情報システム部長

宇羅勇治システムコンサルタント

新海順一株式会社 DNP 情報システム常務執行役員マネジメント本部長

田渕恭子株式会社パソナテックコンサルタントサービスデリバリー部

春山勉株式会社コーセー情報統括部狭山情報センター課長

日比野俊二ライオン株式会社統合システム部副主席部員

藤本礼久全日本空輸株式会社 IT 推進室 IT 企画グループ主席部員

矢野理恵子三菱商事株式会社 CIO オフィス企画・統括チーム

（五十音順、敬称略）

1

第１章経営企画と人材育成

第１節経営戦略と IT 組織

第２節人材戦略

第３節提案力の強化

第４節 CIO の存在と役割

3

第１章経営企画と人材育成第１節経営戦略と IT 組織

企業の IT 組織はユーザー企業のなかにおいてまず、IT 部門とユーザー部門において業務分担が

あり、ついで情報子会社、ベンダー間との業務分担がある。分担が多岐にわたっており複雑で効

率が悪いと利用者、経営者から批判されている。

この節では、何故そのようになってきたのかを、まず歴史を振り返り、そこから派生したユー

ザー企業の IT 組織を中央集権型、連邦型に分け、その特徴を整理した。さらに情報子会社の実態

を分析し、課題分析を実施している。

企業が活性化するための親会社の IT 組織のあり方へと展開し、グローバル時代の将来への展望

へとつなげ IT 関係組織のあり方を考察している。

最後に IT 活動の見える化について顧客との見える化、経営者に対しても見える化、関係会社に

対しての見える化、システム関係者に対しての見える化について IT 組織の抱える基本的な問題解

決を呼びかけている。IT 組織活動のための、なんらかのヒントを得ていただければ幸いである。

１．企業内システム部門の組織変化の背景

２．IT 組織の変化

３．情報子会社

４．親会社の IT 組織

５．アウトソーシング

６．グローバル化時代を迎えて（今後の発展今後の組織に及ぼす要因と影響）

７．IT 活動の見える化

１－１経営戦略と IT 組織

4

１．企業内システム部門の組織変化の背景

（１）汎用機時代

1980 年代後半までは、汎用機を中心にしたシステム化が実施された。企業内の IT 部門は、年々安くなる IT 機器を使ってのユーザーのシステム化要望は高まる一方

であり、需要と供給のバランスが崩れ「バックログの多さ」に悩まされていた。バックログは 5年間分を越える企業もあった。「高価な計算機」の活用方法は大きな課題ではあったが、IT 技術の進歩は予想されており、コ

ンピュータはタダ（無料）同然の箱になるとの予想さえ出されていた。今振り返ってみると、あ

の当時の能力のハードウェアでよければ確かにタダ近くになっている。企業内のさまざまな業務を吸収した S360 の主メモリは高々64KB であった。今の一般的なパソコンの 1/1000 以下である。小さくて遅いメモリにアセンブラで書いたプロ

グラムを押し込み、プログラマ自身で一定量のメモリに入るように、プログラム量の制御まで行

っていた。そのような努力を強いられる OS では、ソフトウェアの開発生産性は上がらず、ユー

ザーの要望に追随できなかったのである。当然システム部門への風当たりは強かったが、さりと

て要員増強はさせてもらえず、システム部門苦難の時代であった。しかし「システムの企画、開発、運用」は情報システム部門長の下で実施されていたので、SE

の育成の面では、この 3 作業要素をすべて修得させることが可能であった。分業が進んだ結果、

一部の経験しか持たない SE が多くなった現時点と比較すると、「人作り」の面では恵まれていた

ともいえる。

（２）クラサバ時代

技術の世界を見ると「規模の法則」が存在している。例えばエンジンがその一つである。昔の代表的な乗り物は汽車である。産業革命が起こり「蒸気機関車」が誕生した。大きな力を出すので、機関車は大きくなり続け

その威力を発揮した。C51、C53、有名なものは D51、D53 である。その後はさらに大きくなっ

たが、後は数メートル離れた倉庫に入れるためにも、大量の石炭を消費するようになり、この

規模の戦いは終わってジーゼル機関車に切り替わった。その後電気機関車が登場するのである。製鉄業の溶鉱炉も同じ運命をたどっている。2000 ㎥→3000 ㎥→4000 ㎥→5000 ㎥と規模は拡

大し続けたが、5000 ㎥を後に、内部にまで火が通りコークスを燃やすことが困難になり、規模

の法則は終焉した。コンピュータも同じように、汎用機の OS は、機能の拡大を続けた。しかし、簡単なプログラ

ムの作成でも手間がかかりすぎる、新技術を吸収するのが遅い、IBM がすべての技術を独占し値

段が下がらない、などの問題が生じたころオフコンが登場し、次いで本格的なクライアント・サ

ーバー（以降、「CL／SVR」と表記）システムが出現した。過去の IT 資産が多ければ多いほど、切り替えの負荷が大きいため、新しい機能に手を出すの

は遅れる。この時代の企業の情報システム部門は、新技術の対応に悩まされることになる。初は汎用機の機能不足を補う用途に活用された CL／SVR システムも、機能の安定と充実が


5

進むと、汎用機の置き換えに活躍することになった。ハードウェアと OS 関係のソフトウェアの安定性は抜群であったので、いまだに大規模安定性

重視のシステムには、価格が低下したこともあって、データベース管理を中心とするマシンとし

ての存在価値を示し続けている。小規模システムの場合、小回りの利く CL／SVR の方が開発や運用が簡単である。しかも安価

で、使いやすい画面操作機能が付属しているために、急速に普及した。この時代は情報システム部に頼まなくても、各事業部などで気の利いたスタッフが自分たちで

システムを作り出した。しかし開発は一次であるが運用は永久であり、実務者が好きで作ったシ

ステムの継続性に悩まされることになる。後は「やはり IT の管理は情報システムのスタッフに」と基幹業務のサポートは情報システ

ム部に任せ、基幹業務から取り出したデータ加工を利用部門のオープン実務者に任せる流れにな

った。この時代に合わせるように、日本の人口は頭打ちに入り、消費はかつての右肩上がり経済が頭

打ちになり始めた。日本企業は生き残りをかけて多角化戦略を採用し始め事業部性が普及し始め

た。そうなると、事業の責任はすべて事業部長が持つことになり、事業部長が IT 化を推進した

ければ、その責任の下で自由自在にシステム開発をすることが求められる。「SE が不足している

ため、貴事業部のシステムサポートは後回しになります」との論理は通らなくなった。そこで IT部門組織には連邦制が誕生し始め、急速に広がって行った。技術革新の波が IT 部門に押し寄せ、活用が進むと IT 予算の増加は目覚しくなった。日本全体の企業収入が減少し、当然税収入も減額したなかで、IT 費用がいかに増加したのかを

示しているのが、次の図である。1990 年と 2000 年時点で比較してみると、売上高が伸び悩んで

いる中で、情報化費用だけが 1.7 倍に増加している。経営トップにとっては、効果は上げており、IT がなければ事業は運営できないことはわかって

いても、「IT は金食い虫」の感は免れない。「何とか安くできないか」と願う気持ちが情報子会社

の増加につながっていった。

./keyword.htm#3701


6

（IT コスト・マネジメント研究会プロジェクト 2003）

図表 1-1-1 企業利益と情報化費用（10 年対比の増減率）

コンピュータが使いやすくなり、皆がソフトウェアを作り、パッケージの活用が容易になると、

その機能を IT 部門の管轄下に閉じ込めておくことは困難になる。汎用機以前の社員の机上には、電話と鉛筆、消しゴム、そして電卓が載っていたが、時代は変

わりパソコンと毎日「にらめっこ」する時代に変わっていった。パソコンも DOS が Windows に変わり、安定性と使用容易性が向上し、価額が低下すると、IT

部門の許可を得て購入しなくても、各部の経費で簡単に購入する、あるいは同じパソコンを自宅

に持ち、自宅でも作業する風土ができあがった。

（３）Web インターネット時代

パソコン機能が進歩し始めると、目に付くのはネットワークの速度の遅さである。光ファイバー技術が出現し、あっと言う間にインターネットの便利さとパソコンの結びつきが

改良された。さらに携帯端末が登場し、いつでもどこでもコンピュータとネットワークが利用で

きる「ユビキタス」時代にと進んでいった。使いやすい技術は広い範囲に普及し、企業においてもそのサポート業務はさらに拡大し続ける。そのような広範囲かつ多様で、ボリュームの多い仕事を企業内の IT 部門が持ち続けることが

できるのか、持つ必要があるのか、などの「コンピテンシー」議論が登場してきた。

./keyword.htm#3503


7

あるいは優秀な IT 部門を抱えていた場合は、「優秀な SE がいるならば、一般の外販ソフトウェアビジネスに乗りだし自ら収益を稼ぎ出せ」「余剰社員を情報子会社に吸収し事業の多角化に貢献せよ」と、大企業では、情報子会社を持つことが常識となった。日本の大企業において、この情報子

会社を持っている比率が 90％に達している形態は諸外国と比較してもきわめて特徴的である。中小規模の企業は、外部に進出するほどの技術やパワーがいない、優秀な SE が余っていない

など、の理由で情報子会社を持つことは少ない。企業は改革を続けなければ、厳しい競争に振るい落とされる。情報子会社を持ってはみたが、

当初は課題がむしろ情報子会社に集中していた感さえあった。しかし徐々に情報子会社も力をつけ始めてきた。この改善はさらに進むと期待され、数年後は

ソリューションベンダーと比較して、テーマによっては情報子会社が実力で逆転現象を見せるこ

ともありうる。

図表 1-1-2 情報子会社と他社に対する不満の比率

2 0 ％

1 9 ％

2 8 ％

8 ％

1 0 ％

1 4 ％

1 0 ％

5 ％

1 0 ％

1 2 ％

1 0 ％

5 ％

0 5 年度

提案力

価格

技術力

情報子会社

S Iベンダー

ソフトベンダー

ハードベンダー

情報子会社

S Iベンダー



情報子会社

S Iベンダー



6 2 ％

3 2 ％

2 0 ％

3 7 ％

3 1 ％

2 4 ％

1 9 ％

2 9 ％

3 6 ％

1 7 ％

7 ％

1 0 ％

0 4 年度

5 4 ％

3 4 ％

4 2 ％

2 7 ％

1 8 ％

2 8 ％

2 8 ％

3 0 ％

2 4 ％

1 8 ％

1 4 ％

1 0 ％

0 5 年度

3 0 ％情報子会社

1 5 ％S Iベンダー

7 ％ソフトベンダー

1 0 ％ハードベンダー

動員力


9 ％S Iベンダー


6 ％ハードベンダー

約束履行





信頼性・安定性

0 4 年度

2 0 ％

1 9 ％

2 8 ％

8 ％

1 0 ％

1 4 ％

1 0 ％

5 ％

1 0 ％

1 2 ％

1 0 ％

5 ％

0 5 年度

提案力

価格

技術力

情報子会社

S Iベンダー



情報子会社

S Iベンダー



情報子会社

S Iベンダー



6 2 ％

3 2 ％

2 0 ％

3 7 ％

3 1 ％

2 4 ％

1 9 ％

2 9 ％

3 6 ％

1 7 ％

7 ％

1 0 ％

0 4 年度

5 4 ％

3 4 ％

4 2 ％

2 7 ％

1 8 ％

2 8 ％

2 8 ％

3 0 ％

2 4 ％

1 8 ％

1 4 ％

1 0 ％

0 5 年度


1 5 ％S Iベンダー


1 0 ％ハードベンダー

動員力





約束履行





信頼性・安定性

0 4 年度

※この１年間で、情報子会社に対する不満が大幅に解消されつつある。今後の問題は提案力の強化


8

外販への期待

企画・開発・保守・運用の一体運営→ＩＴ要員、費用の増大→残業抑制、コンピテンシー議論

本社社員の採用抑制→ＩＴ要員補充の困難性情報子会社の分社 →親企業への戻し

→親企業ＩＴ部門縮小

更なる分社化 →ベンダーへの移管→そのまま継続インターネット関連業務の増加

→ＩＴ部門の追随遅れ→インフラ品質に対する不満

オープン化へのＩＴ部門の対応遅れ→エンドユーザーが自由な機器の採用→情報系システムの利用者開発→保守・運用品質の低下→業務改革はユーザー部門の責任

ＩＴコストの増大（サーバー、クライアント、ディスク、ソフトウェア）セキュリティへの不安

関連企業とのシステム連結→システム規模増加、複雑化

RFP作成能力の低下と問題プロジェクトの発生→工期、予算、品質への不満とベンダーの収益性低下→システムの信頼性・安定性への強化要望→組織分化・責任の不明確性への不満

インフラ管理は一元化（ＩＴ部門、情報会社へ）全社、関連会社のネットワーク化

・業務改革・運用管理についてのＩＴ部門への企画力の

期待増加・CIOの重要性・プロジェクトマネジメント技術の向上・業務部門の利活用力の向上・内部統制

ＩＴ機器の進化とコスト低下→システムの利用範囲の拡大→企業競争力の武器

環境の変化システム部門の変化課題・アクション

積み残し課題案件の増加ＩＴ業務のサービス低下

～1989

1990～1990～ 2005～

ａａ

（JUAS 作成資料）

図表 1-1-3 ユーザーの IT 関連作業と役割分担の変化

２．IT 組織の変化

IT 組織の変化を中央集権型、連邦型、分散型に分けてトレースしてみよう。

（IT 動向調査 2006）

図表 1-1-4 IT 組織の変化

55%

58%

64%

60%

47%

27%

3%

15%

9%

11%

12%

23%

10%

33%

4%

8%

5%

10%

13%

12%

11%

11%

11%

13%

13%

13%

11%

6%

7%

9%

14%

40%

33%

4%

9%

5%2%

1%

3%

3%

2%

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

全体

100人未満

100～499人

500～999人

1000～4999人

5000～9999人

10000人以上

集権型A 集権型B 集権型C 連邦型A 連邦型B 分散型

・2004 年度の組織形態は、集権型 74％、連邦型 20 パーセント、分散型 6％。

・分散型は 3 年前の 10％が 4％へと、年々減少する傾向。分散型の多くは連邦型へ移行。

・アウトソーシングが進んだ組織形態は、10000 人以上で 80％、5000～9999 人で 60％。


9

分散型は少数派であるので、ここでは除いて、中央集権型と連邦型と特徴を整理してみる。例外はあるが、その企業が取り扱っている商品と事業経営組織が、IT 組織に密着した関係を持

っていることがよくわかる。

図表 1-1-5 中央集権型と連邦型の特徴

中央集権型連邦型

取り扱っている

商品

大きく分類して、単一商品である場合ある

いは圧倒的に主力商品の売上・収益が中

心商品である場合

複数商品を取り扱っている場合に多い

組織社長を頂点とする組織事業部制を採用している企業に多い

事業責任社長社長+事業部長

IT 部門全社 IT 部門全社 IT 部門と事業部内 IT 部門

IT 部門の支援

体制

全社 IT 部門のレベルが高く、かつきめ細

かい支援で、各部の不満解消

インフラ構成などの全社機能と

事業部システムの支援は別組織

遠隔地の工場

支援

経営企画、経理、設備管理、事業管理など

が集中していれば IT 部門も集権型になる

ケースが多い

各工場の自立化を前提に運営されている

と、IT部門も全社機能と工場機能に分かれ

る

セキュリティ全社、関連企業含めて全社 IT 組織が管理

することが多い

全社、関連企業含めて全社 IT 組織が管理

する部分と事業部委託部分がある

関連企業への

支援

統一して強力なサポート可能全社 IT 部門の支援と事業部 IT 部門の支

援が併存

情報子会社との

関係

情報子会社は全社 IT 組織の下に位置づ

けられる

情報子会社は全社 IT 組織の下に位置づ

けられることが多い

全社システムと事業部システムの管理の分離

（企画のみ本社）

⑤連邦型B

ほとんどの機能を各事業部に分散

⑥分散型


④連邦型A

戦略機能のみ本社に残す

③集権型C

企画機能のみ本社に残す

②集権型B

一貫して

集中管理①集権型A

情報子会社アウトソーサー

事業部全社


（企画のみ本社）

⑤連邦型B

ほとんどの機能を各事業部に分散

⑥分散型


④連邦型A

戦略機能のみ本社に残す

③集権型C

企画機能のみ本社に残す

②集権型B

一貫して

集中管理①集権型A

情報子会社アウトソーサー

事業部全社

企画・開発・運用

企画・開発・運用

開発・運用企画

戦略

企画・開発・運用（全社システム）

企画・開発・運用（事業部システム）

企画・開発・運用（事業部システム）

企画（全社システム）

企画（事業部システム）

開発・運用・全社システム・事業部システム

戦略


図表 1-1-6 IT 組織の形態（詳細）

./keyword.htm#3701


10

３．情報子会社

親会社の中の IT 組織は中央集権型、連邦型、分散型の 3 タイプがあり、それぞれに特徴があ

ることは前述した。ここでは子会社との関係について考察する。

（１）情報子会社の存在状況

まず、情報子会社はどの程度日本に存在しているのだろうか。

16%

5%

6%

19%

24%

45%

76%

4%

5%

10%

10%

80%

94%

92%

79%

71%

45%

14%

2%

3%

2%

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

全体(n=883)

100人未満(n=63)

100～499人(n=363)

500～999人(n=188)

1000～4999人(n=206)

5000～9999人(n=29)

10000人以上(n=29)

情報子会社あり（経営権を持つ）情報子会社あり（経営権は他社）情報子会社なし


図表 1-1-7 情報子会社の有無

上記表に基づくと、親会社の規模に従い、徐々に子会社保持率は高まり、10,000 人以上の企業

では 86％が（経営権の有無は問わない場合）保持している。これは世界でも珍しいケースと言わ

れている。しかし「わが社は、親会社の業務効率化、競争力強化に IT 部門は欠かせない」とし、「情報子

会社は持たない」企業も 14％存在していることも一つの特徴である。参考として、2002 年度の IT 動向調査を確認してみよう。・大企業での情報子会社を持っている割合・・・38％・中堅企業での情報子会社を持っている割合・・・12％大企業においての情報子会社化が非常に進んでいることがわかる。


11

（２）組織形態とその特徴

機能の特徴を次の 8 種類に分けて整理した。 ① 親会社の業務改革の推進 ② 子会社の人の採用 ③ SE の育成（業務改革力） ④ SE の育成（IT 技術特にシステムの信頼性） ⑤ 関連企業の指導（業務改革） ⑥ 関連企業の指導（IT 技術特にネットワーク、セキュリティ） ⑦ 海外子会社の業務改革の推進 ⑧ 外販ビジネスの推進 ⑨ その他

図表 1-1-8 組織形態とその特徴

⑨その他

○△―⑧外販ビジネスの推進

△○○⑦海外子会社の業務改革の推進

○○△⑥関連企業の指導（ＩＴ技術特にネットワーク、

セキュリティ）

△△○⑤関連企業の指導（業務改革）

○○△④SEの育成（ＩＴ技術特にシステムの信頼性）

○○○③SEの育成（業務改革力）

○○―②子会社の人の採用

△○○①親会社の業務改革の推進

3：親会社にIT担当不在、子会社が企画～運用をすべて担当

2：親会社は予算管理、企画、子会社は開発運用保守

1：ＩＴ部門は親会社のみ

⑨その他

○△―⑧外販ビジネスの推進

△○○⑦海外子会社の業務改革の推進

○○△⑥関連企業の指導（ＩＴ技術特にネットワーク、

セキュリティ）

△△○⑤関連企業の指導（業務改革）

○○△④SEの育成（ＩＴ技術特にシステムの信頼性）

○○○③SEの育成（業務改革力）

○○―②子会社の人の採用

△○○①親会社の業務改革の推進

3：親会社にIT担当不在、子会社が企画～運用をすべて担当

2：親会社は予算管理、企画、子会社は開発運用保守

1：ＩＴ部門は親会社のみ

親親

○：有利 ×：不利 △：どちらともいえない－：関係なし

子子


12

タイプ１：親会社の中に IT 組織があり、すべての業務を担当している場合である。大企業には既に数少

ないケースである。情報システム部門は親会社の仕事をしていればよい。外部の一般ビジネスを

実施して小金を稼がなくても良いとする会社である。外部ビジネスの経験がないので、さまざまな IT 技術の活用のチャンスは減ると思われるので、

IT 技術の関係の機能には△をつけた。しかし、IT 技術基礎理解力を持っていれば対応は可能で

ある。あるいは外部から補充することも可能である。一般ビジネスを請け負うことはないので、井の中の蛙になる傾向は否めない。親会社の組織風土・文化にもよるが、IT 部門が受身になってしまい、社内から IT 部門に積極

的にくる人の確保がし難いなどの問題は残る。そのことが IT 部門要員の確保を困難にし、外注

会社への業務を依存する傾向がある。

タイプ２：主として親会社に企画機能を残し、開発運用業務は自社のコンピテンシー業務とはいえないの

で、自社外部の情報子会社で持てばよいと考えた企業である。外部一般ビジネスの窓口は開いてあるので、さまざまな経験を重ねることはできる。親会社に残った人と子会社に行った人との葛藤を避けるために、あるいは技術力担保のために

次のような対策を講じ、欠点を減らす努力をしている。・人事交流などの対策を行う・子会社で採用した人も親会社に席を置き、親の業務と顔を覚えさせる・子会社の社長は親会社のリーダーが担当する子会社は独自で人の採用も可能であるため、IT 人材の確保の点では恵まれている。

タイプ３：

親会社に IT 人材をごく少人数しか置かず、実質の企画業務から開発運用までのすべてを子会

社に委託している場合である。少ない IT 要員の総力を挙げる場合には適している。親会社の事業部で業務を担当している社員がこの情報子会社をどのように受け止めているか、

という組織文化が問われる。「子会社の提案では気に入らない」という社員が多数存在するようで

は、有効活用することは難しい。親会社からの仕事が減った場合は、子会社の外販ビジネスで補うなどの救済対策を働かせるこ

とも可能である。情報子会社の SE が親会社の業務を理解することがこの組織を活かすポイント

になるので、子会社の SE を親会社の業務部門に派遣して支援をしながら業務を覚える、改善ノ

ウハウを取得するなどの工夫が必要となる。


13

（３）情報子会社の経営形態

次に、子会社の経営形態についても分類してみる。タイプ A・・・親会社がほとんどの経営権を持っているタイプ B・・・親会社も持っているが、上場し経営権は分散されているタイプ C・・・コンピュータ専門企業が大半を持っている

このタイプ C にはさらに二つの形がある。（その１）・・・コンピュータ会社の経営戦略のため（本来の親会社が情報子会社の経営問題を解消する力を持っていないため）経営権を 51％以上コンピュータ会社が持っている場合は、基本的にはその会社の経営方針を推

進すれば良いわけであるが、コンピュータ・リソースなどの発注権限はユーザー企業が所持して

いるので、ユーザーの意思を無視した経営判断はし難い。両者持ちつ持たれつで情報子会社の育

成を実施している。（その２）・・・子会社が成長できるまでの指導のため従来のビジネスのお付き合いの関係から、現時点では情報子会社の経営を担当しているが、指

導育成は短期的であり、情報子会社がある程度経験を積みひとり立ちできるようになった場合は、

元に戻そうと初から予定し指導している場合将来どちらが成功しているかは、環境と経営者の意識と関係者の努力で決まると思うが、興味

ある課題である。

図表 1-1-9 情報子会社の経営形態

タイプ親会社の立場関連企業の立場情報子会社の立場

１：親主体ほとんどの経営判断、

アクションは親主体

親会社の指導力に従う・親に依存

・子の主体性不足になりがち

２：分散社会的責任は子会社が

持つが、親会社の責任

は逃れられない

・親会社の指導力はやや薄

れる

・すべてのデシジョンは是々

非々になる

社会的責任を持ち主体性が

生まれる

３：他社他社に委託してある・親会社の指導力は薄れる

・すべてのデシジョンは是々

非々になる

他社との関係の維持に配慮


14

（４）情報子会社の方向性

23%

24%

19%

5%

5%

7%

6%

10%

65%

65%

68%

3%

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

全体(n=172)

情報子会社の経営権あり（n=141)

情報子会社の経営権なし（n=31)

IT部門から情報子会社へ業務を移管する情報子会社から本社機構へ業務を吸収する

情報子会社を縮小しアウトソーシングする現状維持


図表 1-1-10 情報子会社の今後の方向性

日本企業において情報子会社は、一つの位置づけを確保してきた。情報子会社の評価は、数年前の①主体性がない、②技術力がないとの低評価から、関係者の努

力により着実にその評価を上げてきている。むしろ、本社の中に残されてあった IT 企画組織が情報子会社へ機能を移そうとしている企業

が増加している。本社と情報子会社に分散している SE を一括し、重複作業を避けて効率化する、

調整負荷を減少して意思決定を速やかに行う、などの効果を期待していることが伺える。一方、まだ少数派ではあるが、情報子会社のパワーを本社に戻し、総合力の強化を狙っている

企業もある。個別企業の環境の差により形は変わるが、IT パワーを集中化して効率を上げようと

していることは一致している。情報子会社のもう一つの狙いであった、「一般ビジネスへの進出」はどの程度成功しているのだ

ろうか。それを示しているのが、次の図である。

情報システムグループ会社の現在の外販比率（n=18)　2003/12月　現在

外販はしていない

17%

１割未満

27%

１割以上２割未満

22%

２割以上３割未満

17%

５割以上

17%４割以上５割未満

0%

３割以上４割未満

0%

外販はしていない１割未満１割以上２割未満２割以上３割未満

３割以上４割未満４割以上５割未満５割以上

出来ていない４４％

やろうとしているが出来ない

３９％

出来ている１７％

（2003 年度 IT グループ会社フォーラム資料）

図表 1-1-11 今後の推進方向外販の現状と課題


15

外販の目的は、2 つあった。

その１：親会社からの仕事が減少した時のリスク回避情報子会社になり、従業員を個別採用し始めたが、親会社からの業務が減少したときに首切り

をしなくてもよいように、ある程度の外販ビジネスを確保しておくことは、一つのリスク回避に

なる。しかし、親会社以外から仕事を受託し利益を上げることは、想像以上に難しい仕事である。顧客を探し受注する能力、受注した仕事を完璧に仕上げる力、お客とのコミュニケーションケ

ーション技術は一朝一夕にでき上がるものではない。親会社の業務の片手間に「外販ビジネスでも確保して・・・」と考えていたのでは成功できな

い難しいビジネスである。情報子会社のうち、外販ビジネスが 50％以上を占めている企業はわず

かに 17％しかないが、この優秀な情報子会社は歴史を 20 年以上持っている。簡単にはこの線ま

で達することはできない。「外販ビジネスを伸ばすためには、従来のシステムベンダーに頼る方が

早い」と有力ベンダーに経営を委託した情報子会社もある。不況になり親会社からの仕事が、仮に減ったときに頼りにしたいならば、少なくとも 30％以上

の外販ビジネスを確保しておくことが、必要である。10％程度外販ビジネスが確保してあっても、

仕事の穴うめには、ほとんど役に立たない。

その２：自社商品・技術の活用外販ビジネスのもう一つの狙いは、自社の持っている技術あるいは優秀パッケージを自社以外

にも販売し収益を得ることである。この成功事例はまだ少ないが、是非近い将来には、成功が期待できる分野である。パッケージビジネスを企画するならば、日本だけでなく世界市場を相手に戦い勝ち抜く戦略が

必要である。人の採用も外国人を集めるくらいの施策がないとグローバル市場での成功はおぼつ

かない。まだ情報子会社はそこまでに至っていないところが多い。（５）関連会社へのサポート

ネットワーク・サポートを中心に、関連企業に IT ビジネスは広がりつつある。セキュリティ対策を個別企業がフォローしきるには、高度な知識と経験が必要であり、関連企

業が個々別々にこの支援部隊を持つよりは一括した組織がある方が、有効である。関連企業含めた統一ネットワークの活用、本社開発・導入による経理プログラムの活用とそれ

による連結決算負荷の減少と精度の向上、人事プログラムの活用による総合的人材・知見の活用、

SOA などによる IT 資産の再利用など数多くのメリットが出る可能性はある。「親会社のような

立派なシステムを高い値段で押し付けられても困る」の批判もあるようであるが、優秀な情報子

会社 SE パワーの活用は今後も進むものと期待される。


16

４．親会社の IT 組織

これまで述べてきた情報子会社の増加を踏まえて、親会社の IT 部門の役割を考えてみたい。一般的には、以下の機能を持つ。 ① 予算管理（子会社含めた IT 予算） ② 業務改革 ③ システム企画推進 EA および個別システムの企画、推進 ④ 技術の選択・標準化 ⑤ 開発済みシステムのフォロー（効果算出・評価）配置されてある本社 IT 企画部の人数に応じて、③以下の作業は削減されている。一方、情報子会社も創業の背景により進展度合いは異なっている。本体事業が不振であったために、何が何でも成功しなければいけないとの要求を迫られた情報

子会社は、外販ビジネスの割合が増え、景気の動向で親会社の仕事が減ったときの救済策のため

に外販ビジネスを始めた情報子会社は、それほど外販ビジネスは増加していないようにみえる。

もっとも企業の年輪を重ねないと、外販ビジネスを上手く増加させることは難しい。一定期間、

時間薬が必要であるので、10 年以下の情報子会社が多い現状で一般外販ビジネスの量を論じるの

は、まだ時期が早すぎるのかもしれない。


図表 1-1-12 IT 企画を担当する IT 部門に求められる役割

IT企画推進要員比が1.0％以上であれば、

強いリーダーシップを発揮することが可能になる

業務の深度

⑤開発済みシステム

の使いこなし指

導、効果算出

①予算管理

IT企画推進要員比1.0％以下 IT企画推進要員比1.0％以上

③技術の選択

標準化 ②業務改革

④EAコンセプト、

主要システム

の企画・開発に

おけるリーダー

シップ

1.0％の壁

IT企画推進要員比（IT企画推進要員数／全システムユーザー数）

./keyword.htm#0501


17

５．アウトソーシング

しばしば登場してきたように、企業における IT 要員は爆発的な IT 業務をまかなえず、情報子

会社などを創立し、人材難を回避してきた。しかしベンダーの戦略の影響もあり、IT 関連業務のアウトソーシング作業はさらに進んでいる。

議論の焦点は 2 つある。

その１・企業において自社内で持つべき機能は何なのか。・システム開発、保守、運用機能は自社技術として持たねばならないのか。・業種によっては、あるいは企業の環境によっては外部の専門業者に任せたほうが良いのでは

ないか。

その２・自社内で持つ場合と外部業者に任せた場合で、どちらがコスト、品質、納期、従業員へのサ

ポート・サービスがすぐれているか。残念なことに、このような課題が出てきた場合に、実績として上記 4 要素の実績値を示せない

従来の IT 部門が多いことも事実であった。その結果、声の大きさに負けて、自社内主要業務をアウトソーシングしているケースもみられ

る。IT 部門にとって、必要なことは自分たちの業務実績・実態を評価値として社内に公表するこ

とである。プロセス志向だけでなく、プロダクト志向にして見える化をしないと、社内で理解さ

れないし、ましてやトップも理解できない。親会社が主権を保持している情報子会社であれば、お互いの情報共有も可能であるし、お互い

に協力できる企業文化の形成も可能であるが、競争入札で決まったベンダーに自社の主要業務を

託せるのだろうか。見極める能力を持つことが肝心である。自社で管理能力を持たない業務を外部業者に委託することは、「鶏小屋に狐を放すことと同じ」

であると、いさめているコンサルタントも存在する。


18

●業務管理

●品質管理

●予算管理

●組織労務管理

●予算管理

●ＳＬＡ管理

●セキュリティ管理

●運用状況管理

●発注先管理

●予算管理

●工期管理

●発注先管理

●開発モニタリングとレビュー

●予算管理

●工期管理

●発注先管理

●組織労務管理ＩＳ部門

●効果検証、評価

●業務改善、分析

●業務分析業務部門

管

理

系

の

業

務

●ＳＬＡ評価、締結

●セキュリティ・ポリシー作成

●ヘルプデスク

●保守“管理”体制構築

●開発“管理”体制構築

●受け入れ評価

●情報化戦略策定

●情報化計画立案

●業務改革

●ｼｽﾃﾑ企画立案

●提案および見積要求仕様書作成

●提案評価、見積評価

●契約、発注

ＩＳ部門

●利用計画作成

●利用体制確保

●業務適用と日常利用

●効果創出と確認

●保守項目の依頼と結果確認

●テスト参画●事業分野の特定

●ビジネスモデルの策定

業務部門

実

行

型

の

業

務

業務適用（利活用）

日常運転保守開発戦略・企画

●業務管理

●品質管理

●予算管理


●予算管理

●ＳＬＡ管理



●発注先管理

●予算管理

●工期管理

●発注先管理


●予算管理

●工期管理

●発注先管理

●組織労務管理ＩＳ部門




管

理

系

の

業

務

●ＳＬＡ評価、締結








●業務改革




●契約、発注

ＩＳ部門








業務部門

実

行

型

の

業

務



情報化関連業務の多くが、アウトソーシング（タスキング）されているケース

図表 1-1-13 ユーザー企業の IT に関係する業務の全体図

上図がユーザー企業の IT に関係する業務の全体図である。アウトソーシング対象業務は上図の A、B、C である。その他の業務を外注化対象業務にする

ことは十分な吟味が必要である。開発（A）を外部委託することは、通常頻繁に行われている。これはシステム要求仕様確認書、

設計書、プログラムの受入テスト、など開発フェーズの節々でチェックが可能であり、もし問題

ならば随時打ち合わせ軌道修正がお互いに取れるからである。保守運用業務（B、C）が次に外注化対象業務になる。高品質な保守・運用作業を日々完遂させることは簡単ではない。開発が一時的であるのに反し、

保守運用は永久的であり、かつ、問題が発生した場合は直ちに顧客に、あるいは社会広範に影響

が及ぶからである。企業の存亡に関わるケースさえ生ずる。・何をどのように管理するのか。・そのコストは妥当なのか。・品質やサービスは十分か。などの指標が持てない場合、外部への委託は危険であることを認識する必要がある。保守・運用が問題なく行われていること、今後も大きな問題は生じないことを証明すること、

さらに改善計画をユーザー企業の経営トップに説明し、納得を得る努力を発注側、受託側も努力

せねばならない。

アウトソーシ

ング A

アウトソーシ

ング B

アウトソーシ

ング C


19

６．グローバル化時代を迎えて（今後の発展今後の組織に及ぼす要因と影響）（１）IT グローバルマネジメント

図表 1-1-14 環境の変化（海外進出）と対策

高度成長を誇っていた日本経済は 1980 年代の終わりから低成長時代に入り、海外進出企業が

増加した。世界適生産、世界適立地が唱えられ、需要のあるところに工場や営業所・支店が

設置された。その体質変化を支える IT 部門は、汎用機からオープン化への技術変化にさらされ

ており、企業のグローバル戦略支援との 2 つの大きな波に洗われることになった。グローバル戦略を進めるためには、次のような条件が存在する。 ①IT ガバナンスの確立が必要であり、グローバルをリードできる強力な IT 組織が必要であり、

その業務基準の整備が必要となる。特に全世界の工場、支店が内部統制力をもち情報システムのみならず、業務システムも矛盾

なく正確に遂行せねばならない。 ②そのためには業務標準、コンピュータシステム標準を始めとする各種の標準化基準が整備さ

れていなければならない。 ③ウイルスなどのネットワーク侵入者から隔離できる、自社および関連企業の強固なネットワ

ークの確保が要請されてくる。また次から次へとコンピュータシステムの利用範囲が広がる

ため、あらかじめ将来を踏まえたサーバー、ネットワークの基盤準備が IT 部門の主要業務

の一つとなった。 ④企業が円滑に運営されるためには、信頼性の高いシステム運用が前提となる。開発作業そのものは情報子会社あるいはソリューションベンダーに委託されるが、丸投げを

することはできない。従来の情報システム部門の得意技の開発・保守・運用技術の推進者は「何を管理すべきか」、「どのように管理技術をレベルアップするのか」、「開発におけるリーダ

ーシップをどのように取るべきか」を問われることになった。このような期待に応えるために、以降で述べるような対策を採ってグローバル経営の支援に回

っている企業が多い。

経済成長率 1971～4％程度

1991～1.2％程度

日本企業の海外進出

（法人数 3582 社）

内 1991 年以降に 51％進出

電気機械、自動車、化学が多い

グローバル経営支援の IT 企画管理機能の充実

① IT ガバナンスの確立（組織、報告）

② 標準化の推進

③ 共通インフラの整備

④ システムの開発・運用

2000 年まで 2000 年以降


20

（２）システム部門の体質変化

図表 1-1-15 システム部門の体質変化

仕事の質や範囲が変化する中で、従来のコンピュータシステムだけが強い人間は情報子会社に

転籍して長所を活かすことになった。業務変革を企画推進できる人は業務をまず業務実体を知っていることが条件になる。当然業務部門から業務に強い人間が IT 部門に配置転換されてくる。組織の名前も情報システ

ム部から IT 企画部あるいは BPR（ビジネス・プロセス・リエンジニアリング）部などに名称も

変わってきた。戦略企画が中心業務になるが、保守運用の管理業務も本体企業の一部として残さ

れてあるので、少人数で多種多様な業務を分担することになった。しかしここでの問題は、業務は知っていても、開発・保守・運用の IT についての作業を実際

に実行した経験のない人が IT の管理をすることも多く技術の継承・育成には課題を残した。この問題は本社の IT 企画部から情報子会社への出向や、逆に情報子会社から本社側に出向し

本社業務を支援する、あるいは情報子会社と本社の IT 部門を一緒にして運営するなどさまざま

な、対策を各社とも模索している段階である。７．IT 活動の見える化

近年 IT 活動に対して「見える化」が盛んに言われるようになってきた。これは増え続ける IT 投資に対しての「このままでよいのだろうか」との経営者からの危惧も

あるが、IT 関係の組織が分散し、IT ガバナンスが効かせにくいようになっている組織上の課題

も内在しているとみることができる。また IT 技術は他の技術、学問と比較して歴史が浅く、未

成熟な部分もあり、PDCA が回っていないものが多い。したがって、評価されてもよいのにもかかわらず評価されていない、課題解消に更なる努力を

しなければならないのにもかかわらず、相変わらず同じ問題が引き起こされている等の不思議な

現象を何とかして欲しいと社会全体が叫んでいる実態も、見える化の掛け声の源にはある。では

見える化の実態と課題を関係者ごとに層別して分析してみよう。関係者とは、顧客、経営者、関係会社、システム関係者（企画、開発、保守、運用）、株主の５

者である。

仕事は質量とも変化

・リーダーシップ

・業務改革力

・仕事量の増加

直営要員増加は困難

①アウトソーシング→情報子会社、ベンダー

（ただし丸投げは禁止）

②社内配置転換

./keyword.htm#1601


21

（１）顧客との見える化

JUAS の IT 動向調査によると「ユーザーのベンダーに対するに不満」は、提案力がない、見

積が不透明、技術が不足あるいはマナーが悪い、が上位を占める。ここでは見える化の課題として「見積が不透明」を挙げて論じてみたい。

47%

49%

20%

21%1%

1%

27%

28%

2%

4%

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

05年度（n=660)　

04年度(n=703)　

非常に満足満足普通不満非常に不満


図表 1-1-16 開発ベンダーへの満足度

(n=557)

61

55

44

39

32

30

25

82

17

32

35

30

37

37

4

10

7

21

0 20 40 60 80 100

企画提案力不足

技術力が不足している

価格が高い

推進力が不十分で納期が守られない

「対応できる」と約束したことができていない

見積もり金額の妥当性が不明

こちらの指示への対応以上の仕事をしていない

セールスと実務担当者の意思が違う

その他

05年度(n=159)

04年度(n=161)


図表 1-1-17 開発ベンダーへの不満点

そもそもソフトウェアの値段については「お坊さんへのお経代と同じ」との説がある。品質は

ともかく一定の企業のブランドがあると高価になるとの見方である。「本来はそんなものではない」と反論したい。「良いものは高い」との説を一般化したいとソフ

トウェアメトリックス調査を試みた。その結果を下に示すが、驚くべきことに「欠陥がも少なく、品質の良いプロジェクトの平均単価が一番安い」との結果になってしま

った。

./keyword.htm#4001


22

41.4 万円45.7 万円76.1 万円41.4 万円43.2 万円76.5 万円71.5 万円単価（小）

300.0 万円250.0 万円175.7 万円285.7 万円300.0 万円150.7 万円117.5 万円単価（大）

112.8 万円117.3 万円119.2 万円101.7 万円121.6 万円119.9 万円91.6 万円単価（平均）

708101614157件数

総計F(3～)E(～3)D(～1)C(～0.5)B(～0.25)A(0)

品質区分（欠陥率）




708101614157件数

総計F(3～)E(～3)D(～1)C(～0.5)B(～0.25)A(0)


（ソフトウェアメトリックス調査 2006）

図表 1-1-18 品質と単価

プロジェクトの開始時に「ユーザーとベンダー間で、品質目標を明示していない」プロジェク

トが多いことにも原因がある。そこで JUAS はユーザーとベンダー間で情報共有できるリスク管

理システム案を提唱している。ユーザー側が発注時に「このプロジェクトのどこを直せば成功し、

費用をさらに抑えることができるのか」を問う基準である。詳細は第 3 章の「第４節開発保守」

を参照いただきたい。このような基準を基に両者がリスク減少に努力すれば、見える化は進み、結果的に欠陥プロジ

ェクトが減少して両者のメリットになる。


23

（２）経営者に対しての見える化

2006 年 3 月の JUAS の国内 CIO 実態調査によれば、システム経験のある CIO も、ほとんど

システム経験を持っていない CIO も、一番学ばねばならないと考えているテーマは「IT 投資評

価手法」である。

13%

26%

6%

21%

22%

5%

4%

3%

1%

19%

31%

6%

12%

15%

9%

5%

4%

0%

0% 10% 20% 30% 40%

ＩＴ分野の知識とトレンド

IT投資の客観的評価手法

プロジェクトマネジメント

リスクマネジメント

業務改革手法

組織運営、リーダーシップ論

人材育成方法

他社の事例

その他

IT部門の経験あり(n=79)

IT部門の経験なし(n=244)

（国内 CIO 実態調査 2006）

図表 1-1-19 CIO が今後勉強したいテーマ

CIO がその情報を欲しいと望んでいることは、経営トップの社長も同じくこの情報を求めてい

ると考えてよい。 JUAS の IT ガバナンス・プロジェクトでも、2002 年に、この投資評価の問題を取り上げ「大

会社の経営トップにどのような情報を IT 部門責任者に求めますか」と質問した。これに対し、「予

算の時は説明があるが、あとはほとんど IT 部門からは報告がないことが一番の不満」との回答

が多かった。そこで JUAS で IT 投資評価手法の追究を行い、実態把握に努めたところ、ここ数年で投資評

価を実施した企業は大幅に増加した。


24

13%

17%

6%

9%

42%

67%

25%

26%

32%

34%

33%

33%

29%

33%

33%

63%

51%

48%

57%

57%

29%

0%

42%

11%

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

03年度事前評価(n=840)


03年度事後評価(n=840)






全体

売上

1兆

以上

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


図表 1-1-20 投資評価の年度変化

投資評価は「基盤インフラ強化プロジェクト、投資評価型プロジェクト、戦略型プロジェクト」

に分類し、「ROI、KPI（BSC 含む）、ユーザー満足度、他社との BM ベンチマーク」の 4 種類の

評価手法により評価するように提案している。また業種区分別に IT 投資予算対売上高比、開発投資金額と保守運用予算の比、セキュリティ

予算対 IT 予算額比などの指標を示し、経営者と IT 部門が議論をするように勧めた。このような数値を参照し、「各社の情報化白書」をまとめて経営陣の理解を促す企業もある。ま

ず経営者と IT の活用方法と問題点について対話することが第一である。「うちの社長は IT についての理解が浅い」と嘆いていても始まらない。まずは現状を整理し

て「社長と共に一歩踏み出す」ことが、IT ユーザーである全社員から望まれている。（３）関係会社に対しての見える化

セキュリティを確保できるネットワークを関連企業含めて構築し、運用することはなかなかの

難問である。そこで関係会社含めたネットワーク構築が始まっている。また、IT 投資金額の増大を防ごうと、親会社の開発したソフトウェア資産の共同利用も進み始

めている。これは例えば IT 機器の共同発注などによる購入価額の低下などの活用効果にまで発

展している。適正在庫確保や顧客の要望への対応などに備えた SCM などの活用方法もある。個別の注文について、受注状況、進捗状況が見える、在庫が見えるなどの効果はまだまだこれ

からも進む。お互いの情報共有による効果は、関連会社とのビジネスのあり方の改善によって今

後も益々進むものと期待されている。

./keyword.htm#0202

./keyword.htm#1802


25

一方、関連子会社の立場からみると・セキュリティ面のサポートは評価できるが、IT コスト賦課の金額が関係会社から見ると高い・本社 IT 部門は関連会社の立場を理解していないなどの問題がある。関連会社に勤務してみないと、スモールカンパニーの苦労は理解できない。関連企業への勤務

経験はないけれども「なすべきことはなす」、「求めるべきは求める」、つまり人情と技術の使い分

けが必要となる。

（４）システム関係者（企画、開発、保守、運用）に対しての見える化

良い商品・サービスを作る方法とは？

•①製造プロセスを確立すること（プロセス志向？）

•＊ISO ＊CMM

•② 終商品の質（目標）を確保すること（プロダクト志向）

•＊ハードウェア・・・・・・ 6シグマ・・・欠陥商品はすぐに取り替えます

•＊ソフトウェア・・・・・・バグがあるのは当たり前？？？

貴方は商品・サービスを買う時に、製造元のプロセスを考えて買いますか？

それとも商品の質・価格・納期で買いますか？

＊Plan→Do→Check→Action

＊目標があるから、実績も評価でき改善アクションが見えてくる

＊貴社のシステム開発の品質？保守の品質？運用の品質？の

目標値とコストの関係は明確ですか？→ユーザーとベンダー間の常識が必要

（優秀な商品・人が正当に評価される情報化社会を）

図表 1-1-21 見える化の必要性目標値を持った管理を

「通常、私達が商品を購入する場合は何を基準にして買いますか。」との質問に対しては、「品質、価格、納期、サービス」などの答えが返ってくる。しかし、「では、個別開発ソフトウェアについて、その基準がありますか。」と再質問をすると、今度は明確な回答が返ってこない。さらに、「プログラム保守作業についての品質は何ですか。」と質問してみると答えが出ない。毎日作業をしている SE やプログラマは何を目標に作業をしているのか。これが明確ではない。

他プロジェクトや他社との保守比較ができてもよさそうなものであるが、そのような評価指標が

ない。


26

続けて、運用について、「貴方の仕事は他社の運用に比較してどれだけ優秀ですか。」と質問をしても自信を持って答えてくれる人は非常に少ない。なぜこのような商品あるいは作

業になってしまったのだろうか。 OS やアプリケーションパッケージについても価格の比較はあるが、性能、品質の尺度はあい

まいである。「今や汎用機の OS はほとんど欠陥がない」「それと比較して PC やサーバーはどう

か」と言いたいところであるが、汎用機の OS も売り出し直後は、一晩に 10 回近くも停止して

いた。今の Windows の比ではない。全世界からのクレームに答えて IBM が改善に改善を重ねた結果、今の品質になった。つまり歴史が浅いためにさまざまな問題を抱えていることも事実だ。しかし、ソフトウェア産業の諸基準は、ベンダーとその関係学者が「ソフトウェアには欠陥が

つきものであり、完全に欠陥を除去することができない商品である。したがって各プロセスで遵

守すべきことを明確にして努力しよう」とのプロセス志向のみが常識化し、商品そのものの価値

を問うプロダクト志向が存在しないことに根源がある。しかし組み込みソフトウェアのように、かつてはハードウェアで作成されていたものが、今は

ソフトウェアでその機能を代替している商品もある。ハードウェアならば欠陥部品の割合は 100万個に１つである。ソフトウェアに対しても何時までも甘えは許されない。ビジネスソフトウェアも、世の中に非常に幅広く活用されシステムとシステムが連結されてい

る。当然高度な品質が保たれなければ、高信頼性は担保できない。しかしその商品の品質基準は不透明であると言う不思議な商品になっている。工期も同じように基準は明確ではない。「テスト工期が不十分で完全なテストができなかったのに、カットオーバーして混乱を引き起

こした」事例にはこと欠かない。生産性のばらつきも、人によって、プロジェクトによって、非常に大きいことは知られている

が、一歩踏み込んだ分析にまでは至っていない。「各社、各プロジェクトによって、諸基準は異なるが、ばらつくデータの中に法則性や基準が

存在するはずである」と、JUAS では 2004 年に経済産業省、IPA の支援を得てソフトウェアメ

トリックスプロジェクトを発足させた。関係各社のご協力により、まず開発の知見を見出し、既に保守の諸基準もいくつか見出した。

2006 年度の調査では運用にも足がかりを得ようとして進めている。その詳細は本書の第 3 章の「第 1 節開発の実態と評価」および「第 2 節保守の実態と評価」

に譲るが、ここでは概要を紹介してみたい。組織論との関係で言えば、このような評価指標を確

保するための PDCA が回る仕組みを確保できる組織であって欲しいものである。各作業フェーズ別の作業評価指標を整理したものが次の表である。

./keyword.htm#1601


27

図表 1-1-22 作業フェーズ別の作業評価指標

評価項目評価値

戦略企画 IT ガバナンス

経営戦略と IT 戦略、経営者のリーダーシップ、CIO の権限、IT 推進

体制、審議機構、業務改革力、リスク管理資源管理、開発運用管

理、アウトソーシング管理、IT 投資効果測定、ＥＵ参加度、人材育

成、内部統制、組織文化

開発開発工期基準

開発品質基準

開発生産性基準

プロマネ基準

投入人月、標準工期、実工期とアクションの関係

投入人月と欠陥数（受入後～安定稼動）の関係

FP、LOC、人月、予算、データアイテム数、納期、品質の相互関係

開発標準、進捗度把握、問題分析

保守保守作業基準

保守工期基準

保守品質基準

保守生産性基準

各種作業標準の整備度

見積基準値

品質目標の設定と評価標準値

問合せ、是正、完全化、適応、基盤整備作業の生産性標準値

運用運用作業基準

運用品質基準

運用生産性基準

運用標準、報告制度

SLA（稼働率、作業管理など）

ジョブ数、サーバー台数、入出力データ数とオペレータ人数の関係

運用予算標準値

利活用業務ルール、基準

業務品質基準

IT 投資評価基準

業務ルール、基準と遵守度、報告制度

顧客迷惑度指数（各社別）

IT 投資評価の実現度把握（効果発揮責任）

実際に標準値を分析・整理してみると、各プロジェクトあるいは各社によって相当に大きなば

らつきを伴うデータになっている。したがって個々のプロジェクトあるいは企業で採用しようと

すれば、各企業別あるいはプロジェクト別の標準値に焼き直して活用する必要がある。また、よ

り高い目標値の設定と実現を求めて作業改革、標準値の改定を続けて行く必要がある。通常の作

業標準ではカバーできない未感応値、別要因もまだ存在している。欠陥ゼロを目指し、すべてのプロジェクトが高信頼性を持つには、まだまだ相当な努力が必要

である。未開拓な分野であるがゆえに新プロセス、新技術の創造の余地は十分にある。 PDCA が回り始めれば、レベルアップの実感も涌いてくる。今後の検討と発展が楽しみであり、

JUAS も努力を継続して行く予定である。（５）株主に対しての見える化

株主および社会に対しての企業の活動状況は経営理念から始まり CSR、SRI など各種報告があ

る。現在の経営財務状況、株価に加えて、今後の見通しを記述するのが一般的である。これに加

えて、「お客様にいかにして満足を得てもらうか」などは各社とも表出しているが、IT の活用状

況についてはほとんど触れられていない。やはり IT 部門とその業績は、縁の下の力持ちである。新しい仕事が発生した場合は、①直営社員に任せる、②機械に任せる、③アウトソースする、

のいずれかになる。プロジェクトの失敗時にのみ社長が頭を下げに登場する環境から、企画時に

も説明が登場してくる日も遠くない環境になってゆくものと思われる。そのような責任を担った

IT 部門への発展を期待して止まない。

./keyword.htm#1601

./keyword.htm#1903


28

29

第１章経営企画と人材育成第２節人材戦略

組織経営になくてはならない存在となった情報システム（IS）が、さらに組織力を向上させる

ためには、経営戦略を踏まえた適切な IS 戦略を立案して、それらを実行し、確実に効果を生み出

せる体制整備が求められる。本節では、その推進に大きな位置を占める IS 人材戦略の考え方と推

進、IS 機能と役割および能力の関係、そして、IS 人材育成について述べる。

１．組織経営に求められる情報システム機能

２．各情報システム機能を実現するために必要な能力

３．情報システムに関与する人材の役割と現状

４．組織力強化に向けた IT 人材育成の考え方

１－２人材戦略

30

１．組織経営に求められる情報システム機能

IT が組織運営に不可欠のものとなった現在、その効果を生み出す仕組みである情報システム

（以下「IS」という。）の重要性も高まり、企業経営への影響範囲が広がった。それに伴うよう

に、IS に関与する人材に求められるスキルや知識、実績も変化した。本項では、こうした背景を反映して、企業における情報システムの位置付けを再確認し、その

担うべき機能を体系的に明確化する。なお、組織力向上を目指した人材戦略において、経営に効果をもたらすのは個々の情報技術

（IT）ではなく、それらを各社のビジネスに合わせて構成した情報システム（IS）であるという

観点から、本節では IS を中心に調査研究成果を展開する。 JUAS では、ユーザー企業における情報化推進体制の変遷を次図のように示してきた。

～１９８０

戦略立案

企画

開発

運用

保守情報システム部

戦略立案

企画情報（業務）システム部

開発

運用

保守システム子会社

戦略立案経営情報システム部

企画

開発

運用

保守システム子会社

企画

開発運用

保守

戦略立案経営情報システム部

開発

運用保守

システム子会社

システムベンダ

利用（業務）部門（経営を含む）




２０００～

①管理する機能・能力

②実行する機能・能力

観点別分類

一部

Copyright©2005 JUAS, All Rights Reserved

１９８０～


図表 1-2-1 ユーザー企業における機能別に見た組織の変遷

これは、コンピュータ黎明期の『ユーザー／ベンダー協業推進体制』から始まり、1970 年代・

ベンダー企業の囲い込み戦略展開『ベンダー・フルサポート体制』全盛時代、1980 年代後半から

始まったユーザー企業のシステム関連機能切り出し戦略による『IT 子会社化体制』を経て、2000年以降の『アウトソーシング体制』まで、情報化推進組織の形態が様々な変遷を遂げてきたこと

を表している。昨今は、二極分化傾向が見られる。一方は、ビジネスプロセスも含めたフルアウ

トソーシングによる『ビジネス・プロセス・アウトソーシング（BPO）』の流れ。他方、経営戦


31

略／事業戦略を踏まえた情報戦略・企画の立案、評価から IS 活用と安定運用により得られる本

業への寄与度向上までをユーザー企業内で担う『IS 関連機能寄り戻し体制』が挙げられる。実際に、どれだけの機能をユーザー企業に内在させ、どの範囲を外注するにしても、組織を支

える IS 機能全体の位置付けと個々の IS 機能の関係性を明示できるものがあれば、あるべき姿の

設定や現状把握に非常に有益である。その発想の下に登場したのが『情報システムユーザースキ

ル標準』（UISS：User's Information Systems Skill Standards、以下「UISS」と表記。詳細成

果については、次のサイト http://www.meti.go.jp/press/20060623003/20060623003.html よ

りダウンロード可能）である。UISS の構成要素のうち、これを端的に表現したものとして下図

『タスクフレームワーク』を提示する。

（UISS Ver.1.0 より）

図表 1-2-2 タスクフレームワーク

機

情報システムユーザースキル標準対象範囲

【【ISIS戦略の策定と実行戦略の策定と実行】】

事業戦略策定

IS戦略

策定

全社戦略

事業戦略評価

IS戦略

評価

【【ISIS戦略以外の戦略以外の機能別機能別戦略戦略の策定との策定と実行実行】】

・・・・

・

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流・・

・・・

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流・・

・・・

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

経営・管理

Ｒ＆Ｄ

生産・物流

（戦略策定）（計画策定）（導入）（活用）（計画評価）（戦略評価）

IS企画 IS導入IS企画

評価


IS活用

IS保守・運用

IS戦略実行マネジメント

IT基盤構築・維持・管理

個別案件

・・・・

・・・・

・

・・・・

・

・・・・

・

・・・・

・

・・・・

・

・

・・・

セキュリティ

システム監査

共通業務

※ユーザー企業における IS 機能を、経営的観点から事後戦略も含めて体系的に整理


32

前述のとおり、IS は企業経営を左右するほどの重みを持った。それに伴い、各事業戦略を効果

的に遂行するため事業戦略策定支援の立場も担った。そして、全社 IS の具現化のための IS 戦略

を立案し、個別の IS 企画に落とし込んでいく。さらに、設計、構築、導入を経て、利活用によ

って本業への貢献を生み出す。また、IS 企画から IS 活用までをカバーする機能として、各 IS 案

件の全体最適化を担当する「IS 戦略実行マネジメント」、事業継続のために IS の安定かつ確実な

稼動・運行を実現する「IS 保守・運用」が存在する。これらはすべて、IS 機能全体かつ個々の

機能ごとにそれぞれ PDCA サイクル1が回って、常に改善がなされるように設定されている。さ

らに、各 IS 機能の PDCA サイクルに等しく関与する、「セキュリティ」、「IT 基盤構築・維持･管

理」、「共通業務（IS スタッフ業務）」、「システム監査」などの全フェーズをカバーする機能もあ

る。これらの各 IS 機能の目的と範囲をまとめたのが、『タスク概要』（UISS 構成要素）である。

図表 1-2-3 タスク概要


機能名概要

事業戦略策定

事業戦略評価

【目的】全社戦略の実現に向けた事業戦略の策定支援・評価

【主な機能】企業活動において、事業戦略策定・評価における以下の機能を範

囲とする。

●事業戦略策定支援（※事業戦略の作成主体は、各事業部門）

・事業環境分析

・情報技術動向分析

・ビジネスモデル策定への助言

●事業戦略評価

・事業戦略達成度の評価

・事業戦略達成度評価のフィードバック

IS 戦略策定

IS 戦略評価

【目的】事業戦略実現に向けた IS 戦略の策定・評価

【主な機能】企業活動において、IS 戦略策定・評価における以下の機能を範囲

とする。

●IS 戦略策定

・対象領域ビジネス及び環境分析

・IS 戦略の策定

・全体計画の策定

●IS 戦略評価

・全体計画の評価

・IS 戦略の評価

1 PDCA サイクル（plan（立案・計画）、do（実施）、check（検証・評価）、action（改善・見直し）計画から見直しまでを

一貫して行い、さらにそれを次の計画・事業に活かそうという考え方）


33

機能名概要

IT 基盤構築・維持・管理【目的】ビジネス環境の変化や情報技術の進展に企業として継続的に対応す

るための IT 戦略策定、構築、評価、維持・管理

【主な機能】企業活動において、IT戦略策定・評価、IT基盤構築・維持・管理に

おける以下の機能を範囲とする

●IT 戦略策定


・IT 戦略の策定


●IT 基盤構築・維持・管理

・IT 基盤の構築

・標準体系の策定

・標準作成

・品質統制（ガバナンス）

・標準の維持・管理

●IT 戦略評価

・IT 戦略の評価

IS 戦略実行マネジメント【目的】IS 戦略の実現に向けた複数の個別案件のマネジメント

【主な機能】企業活動において、IS 戦略実行マネジメントにおける以下の機能

を範囲とする。

●IS 戦略の分析

・把握

・IS 戦略の理解

・各プロジェクト実現上の前提条件把握

●IS 戦略実現のモニタリングとコントロール

・モニタリング（状況把握）・コントロール

●IS 戦略実現上のリスクへの対応

・原因分析

・対策策定

・調整等対応策の実施

プロジェクトマネジメント【目的】IS 戦略の実現に向けた個別案件のマネジメント

【主な機能】企業活動において、プロジェクト計画策定、実行管理における以

下の機能を範囲とする。

●プロジェクト立ち上げ

●プロジェクト計画策定

●プロジェクト追跡と実行管理

●プロジェクト変更管理

●プロジェクト終結

●プロジェクト完了評価

IS 企画（個別案件）

IS 企画評価

（個別案件）

【目的】IS 戦略の実現に向けた個別案件の IS 企画の策定・評価

【主な機能】企業活動において、IS 企画策定・評価における以下の機能を範囲

とする。

●IS 企画策定


・IS 企画の策定

・IS 導入計画の策定

・調達のマネジメント

●IS 企画評価

・システム運用の評価

・業務運用の評価

・IS 企画の評価

IS 導入（個別案件）【目的】IS 戦略の実現に向けた個別案件における IS 導入

【主な機能】企業活動において、IS 導入における以下の機能を範囲とする。

●IS 導入

・アプリケーションコンポーネントの分析、設計

・アプリケーションコンポーネントの開発

・システムコンポーネントの分析、設計

・システムコンポーネントの開発

・IS の受け入れ・IS の移行


34

機能名概要

IS 活用【目的】IS の効果の大化のために利用実態に即した活用計画の策定と遂行

【主な機能】企業活動において、対象となるシステムの評価とフィードバック、

活用促進、情報リテラシーの向上における以下の機能を範囲とする。

●評価とフィードバック

・システム利用実態の評価

・改善要求とフィードバック

●活用促進

・データ活用

・IT 活用の啓発普及

●情報リテラシーの向上

IS 保守・運用【目的】IS の効果の大化のために、IS の保守・運用を安定的・効率的に実施

【主な機能】企業活動において、保守・運用における以下の機能を範囲とす

る。

●IS 保守

・保守計画

・保守の実施

・移行

・情報システムの廃棄

●IS 運用

・システム管理計画

・システム管理

・資源管理

・障害管理

・セキュリティ管理

・性能管理

・システム保守

・システム移行

・運用に関するシステム評価

・システム利用者対応

セキュリティ【目的】全社の情報資産へのセキュリティにおける社内外から脅威やリスクへ

の対応

【主な機能】企業活動において、セキュリティにおける以下の機能を範囲とす

る。

●セキュリティ

・セキュリティ方針の策定

・セキュリティ基準の策定

・セキュリティの分析

・セキュリティの見直し

【目的】企業活動における IS 機能全般に対し、（安定的・効率的な）運営の企

画策定または遂行

【主な機能】企業活動において、共通業務における以下の機能を範囲とする。

●資産管理

全社の情報資産の管理と共有化による生産性向上のため、体制整備から施

策の実施・改善

企業活動において、情報資産の管理方針と管理体制の策定、リスク分析とリ

スク対策の実施、情報資産の有効活用、情報資産の共有化

●事業継続計画

事業継続計画の IS 領域に関わる計画策定から遂行

企業活動において、計画策定から実施、リスク分析、災害時対応計画、バック

アップ、代替処理・復旧

●コンプライアンス

IS 領域に関わるコンプライアンス管理方針と体制の整備、実施と改善

企業活動において、法令および規範の管理体制確立、管理責任者の選定、

遵守すべき法令および規範の識別、教育・周知徹底

共通業務

●人的資源管理

IS 部門および IS 利用部門の IS 活用における人的資源確保のために、人材育

成施策の企画、遂行

企業活動において、責任・権限・業務遂行、教育・訓練

./keyword.htm#3504


35

機能名概要

●契約管理

IS 領域に関わる社外との適切な契約関係の実現のため、契約業務全般の基

準・ルールなどの整備や維持管理

企業活動において、委託先選定方針などの策定、各種契約の管理

システム監査【目的】IS 機能の適切かつ健全な運営のための監査の計画、遂行

【主な機能】企業活動において、各種システムの監査における以下の機能を

範囲とする。

●システム監査

・システム監査の計画

・システム監査の実施

・システム監査の報告

・システム監査業務の管理

さらに、タスク概要の各 IS 機能を分割・詳細化し、それらを実現するための専門スキル、専

門知識を対応付けて一覧化したものが、『機能・役割定義』（UISS 構成要素）である。

図表 1-2-4 機能・役割定義（抜粋）


業務

大項目中項目小項目スキル知識項目

事業戦略策定要求（構想）

の確認

経営要求の

確認

経営方針を正確に捉えることができる

企業目標を正確に捉えることができる

中長期構想を正確に捉えることができる

対象領域（事業ドメイン）を正確に捉えることがで

きる

ビジネスモデル

バランススコアカード/戦略マップ

経営一般

経営要求の重点事項

業務環境調

査・分析（経

営環境）

外部環境を正確に捉えることができる

外部環境の分析結果と企業目標の関係を文書

化（情報戦略指針）することができる

情報を継続的に収集できる

外部環境の調査・分析手法

3C、7S、５Forces、バリューチェーンモ

デル

企業競争力の分析手法

マクロ経済

業界動向、競合他社の動向

関連法案

課題の抽出

収集した情報から IS 資源における課題を分析・

抽出することができる

構築面や保守・運用面から、課題を評価すること

ができる

SWOT 分析

ロジックツリー

ギャップ分析

新ビジネス

モデルへの

提言

情報技術動

向の調査・分

析

情報技術動向を網羅的かつ総括的に捉えること

ができる

経営・情報戦略に適用できる IT 利用方法を適切

に分析・抽出し、文書化できる

情報を継続的に収集できる

IT 動向

IT 動向調査手法

ビジネスモデ

ル策定への

助言

新しいビジネスモデルにより革新的な事業領域

を明確にすることができるビジネスモデル策定に

対して情報戦略と情報資源配分の面から適切に

助言できる経営環境の変化および IT がビジネス

に及ぼす影響を明確に説明することができる

仮説構築力

ビジネスモデル

ビジネスモデル策定のためのフレーム

ワーク検討

顧客満足度/ロイヤルティ

顧客の購買行動モデル

製品・サービスのライフサイクル

：


36

先行して世に登場した、IT スキル標準（ITSS）が、情報サービス業務に関するプロフェッシ

ョナルとしてのスキルを体系化したのに対し、UISS は飽くまで、経営戦略の実現に向け効果を

発揮する情報サービス機能とその実現能力を一覧化したものなので、その内容や範囲、実行する

際の立場などが異なる。IS の設計、構築、導入について、企業が自社内で対応する場合と、プロ

であるシステムベンダー企業に発注しその管理を行う場合とでは、関与する立場が違うので、機

能は同じでも求められる能力にも差異が生じる。つまり、発注者としてシステムが実現するビジ

ネスを見た場合と、実行者として実現すべきシステムを見た場合では、前者に必要なのは管理能

力であるのに対し、後者は実行（推進）能力である。その差異の例を表現したのが、次の 2 つの図表である。

図表 1-2-5 ユーザー企業における情報化関連業務の分類 ①


戦略企画から開発、保守、運転、利活用（業務適用）までの、ほとんどの情報化関連業務が、内製化されているケース

●業務管理

●品質管理

●予算管理


●運用体制確保

●業務管理

●品質管理

●予算管理


●進捗管理

●品質管理

●工期管理

●予算管理


●進捗管理

●品質管理

●工期管理

●予算管理


●組織労務管理ＩＴ

部門




管

理

系

業

務

●システム教育

●導入教育

●運転計画作成

●運転作業実施


●保守計画作成

●保守体制確保

●保守作業実施

●開発組織構築

●体制・要員確保

●実行計画作成

●開発実施



●業務改革


ＩＴ

部門





●端末管理●保守項目の依頼と結果確認



業務部門

実

行

型

業

務



●業務管理

●品質管理

●予算管理


●運用体制確保

●業務管理

●品質管理

●予算管理


●進捗管理

●品質管理

●工期管理

●予算管理


●進捗管理

●品質管理

●工期管理

●予算管理


●組織労務管理ＩＴ

部門




管

理

系

業

務

●システム教育

●導入教育

●運転計画作成

●運転作業実施


●保守計画作成

●保守体制確保

●保守作業実施

●開発組織構築

●体制・要員確保

●実行計画作成

●開発実施



●業務改革


ＩＴ

部門





●端末管理●保守項目の依頼と結果確認



業務部門

実

行

型

業

務




37

図表 1-2-6 ユーザー企業における情報化関連業務の分類 ②


これでわかるとおり、UISS は、IS の機能に着目して具体的に定義し網羅的に整理しており、

かつ、機能のアウトソースの状況により求められる能力を自社流に整理し、IS 機能を担う人材ポ

ートフォリオを、専門スキル、専門知識面で具体的に把握・検討するための標準的な項目を提供

している。まずは、この『機能・役割定義』を活用し、各社におけるこれらの IS 機能の過不足、および、

現在の担当部署（者）を確認してみることをお勧めする。この作業により、各社の IS 機能の内製と外注の分配が改めて明確になり、内在する機能の部

署（担当者）ごとの偏りと、対応されていない機能や当社独自の機能（業界特有の機能等）が明

らかになる。この結果を、経営目標を実現する上で適当かどうか検討し対策を実行することで、

組織としての IS 機能および関与する人材配分の第一段階の適正化を行うことができる。これまでは、IS 機能を体系的に整理したものがなかったため、ビジネス環境の変化や情報技術

の進展に対応するため、各社が独自に手探りで IS 機能を把握する作業を行なっていたが、UISSという標準を通して IS 機能の棚卸は格段に容易になり、他社との比較も可能となった。

情報化関連業務の多くが、アウトソーシング（タスキング）されているケース

●業務管理

●品質管理

●予算管理


●予算管理

● SLA管理



●発注先管理

●予算管理

●工期管理

●発注先管理


●予算管理

●工期管理

●発注先管理


ＩＴ部門




管

理

系

の

業

務

●SLA評価、締結








●業務改革




●契約、発注

ＩＴ部門








業務部門

実

行

型

の

業

務

業務適用

（利活用）


●業務管理

●品質管理

●予算管理


●予算管理

● SLA管理



●発注先管理

●予算管理

●工期管理

●発注先管理


●予算管理

●工期管理

●発注先管理


ＩＴ部門




管

理

系

の

業

務

●SLA評価、締結








●業務改革




●契約、発注

ＩＴ部門








業務部門

実

行

型

の

業

務

業務適用

（利活用）



38

図表 1-2-7 自社で遂行している IS 機能の洗い出し（例）


IS戦略グループ

IS基盤グループ

IS企画第Xグループ

システムベンダＡ社

（自社内に該当機能持たず）

業務スキル知識項目大項目中項目小項目

対象領域ビジネスのプロセスレベルでの理解現行業務 (AsIs)の調査・分析情報システム基盤の将来像の策定業務の新全体像と投資対象の選定情報システム基盤整備原案の策定情報システム投資原案の策定全体計画策定全体計画評価指標の評価全体計画遂行における課題の抽出IS戦略評価指標の評価IS戦略遂行における課題の抽出全体の評価

IT基盤の構築「IS企画」・「IS導入」に準ずるベースモデルの選定標準作成品質統制フレームワークの策定品質統制プロセスの運営実状調査標準の見直し対象業務システム課題の定義業務プロセスの企画業務運用の評価指標の設定費用とシステム投資効果の予測基本要件の実現性の検討開発スケジュールの大枠作成システム移行に対する基本方針明システム運用と保守の基本方針明調達方法の検討提案評価基準の作成ＲＦＰの作成と発行提案評価とベンダの選定システム運用指標の評価システム運用課題の抽出業務運用指標の評価業務運用課題の抽出システム化要件の定義システム化要件の評価システム方式の決定システムのテスト方針の設定ソフトウェア要求事項の定義ソフトウェアコンポーネントの設計物理データベース設計ソフトウェアの詳細設計ユニットテスト仕様の設計コーディング（プログラミング）各種テスト

内部設計

プログラム実装とテスト

ＩＳ導入

システム運用指標評価

業務運用指標評価

システム化要件定義

外部設計

標準の維持・管理

IS企画の策定

IS導入計画の策定

調達と調達マネジメント

IS戦略策定と評価


IS企画と評価

対象領域ビジネスおよび環境分析

IS戦略の策定

全体計画の策定

全体計画の評価

IS戦略の評価

標準作成

品質統制（ガバナンス）

ISストラテジスト

ISアーキテクト

ISアナリスト

（アウトソーシング／外注）


39

２．各情報システム機能を実現するために必要な能力

前項では、組織経営に必要とされる IS 機能の適正な設定アプローチについて触れた。しかし、

単なる機能の過不足調整および人材配置だけでは、その対応範囲の広さとしての網羅性は担保で

きても、深さを追及することは難しい。そこで、本項では、経営目標を実現する上で求められる IS 機能を、確実に遂行できるための

能力について考察する。前項では『機能・役割定義』を、IS 機能の洗い出しのために採り上げたが、これには、個々の

IS 機能遂行に必要なスキル・知識が紐付けられて表記されている。約 400 に分類された IS 機能

の小項目それぞれに複数のスキルが掲げられているため、ここですべてを採り上げることはしな

い。詳細は経済産業省のサイトにある次の URL を参照されたい

（ http://www.meti.go.jp/press/20060623003/uISs-teigISet.pdf ）。大きくは、『調達』、『評価』、『利活用』という情報システムユーザー企業ならではのスキルを意

識してまとめられており、IS 構築の部分については、先行する『IT スキル標準』（情報サービス

産業におけるスキルを体系化したもの）が引用されている。また、改善サイクルである PDCA が、

IS 機能全体としても各機能の遂行に際しても求められることを前提に、スキルも列挙されている。しかし、UISS は、「IS」という限定された範囲の専門スキルを定義しただけであり、実際の業

務遂行シーンにおいては、コンピテンシー（行動特性）や共通スキル、あるいは、IS 以外の専門

スキルとの相乗効果が強く求められる。加えて、 ※IS が合理化・効率化の道具から差別化・競争力強化の武器に進展し、事業継続には必要不

可欠なものに変化したこと。 ※「図表 1-2-1 ユーザー企業における機能別に見た組織の変遷」でわかるように、多くの

IS 機能がその遂行のプロであるベンダーや情報子会社にアウトソーシングされ、ユーザー

企業内には、経営戦略や事業戦略に直結する「IS 戦略・企画およびその評価」と「IS の

信頼性・安全性を確保」が手放せない能力とし残ったこと。などから、広義の IS スキルの範囲は、逆にビジネスマンスキルに近付く勢いで拡張している

と言える。 IS の置かれた状況の変化は、次の JUAS・IT 動向調査 2006 の結果からも読み取れる。


40


図表 1-2-8 情報システム活用現場における課題とその解決のために求められる能力

この背景を踏まえ、JUAS では、企業経営に根付き、品質と信頼性を確保しながら本業の効果

を導く IS の実現とその関与者のスキルを下図のようにまとめている。


図表 1-2-9 これからのシステム提案力をさせるスキル構成

１）経営環境の変化に対応するための業務改革と、それらを効果的に実現するための情報システムの見直しが

十分に行われていない。

－＞経営戦略とＩＳ戦略のギャップを埋め、長期的な目で戦略実現を意識しつつ改革推進ができる能力

２）企業規模が大きくなるにつれ、情報システム機能のアウトソーシング比率が高まっている。

－＞戦略的活用能力の空洞化を防ぎ、外注した機能を発注者として管理・評価できる能力

３）実質的なＣＩＯの不在、またはその機能が欠如している。

－＞ＩＴガバナンス機能、および、それを発揮できる能力を持つ人材

４）実現したいシステムの仕様が明確になっていないまま、情報システム構築に着手している。

－＞目的を明確にしてステークホルダを調整し、要件を明確に定義できる能力

５）実現したい機能をベースにシステムコストを積算せず、予算ありきで費用が決定している。

－＞ＩＳ投資および効果評価に関する能力

６）情報システム機能の整備による効果を組織力向上に結びつけることができない。

－＞安定的な稼動を維持し、本業貢献を意識した利活用能力

DB、ＮＷ、プログラム、セキュリティ、ＥＡ

開発技法（ＷＦ、ＳＰ、イテレーション）、ＥＡ、ＤＯＡ、ＤＢ、ＮＷ、プログラム、個別技術

ＩＣＴ技術（Computer Science）

プロジェクト管理理論、ＥＡＳＥ、ＳＬＭ

リスク管理手法、スケジュール/コスト管理手法、ＥＶＡ、

Ｕ字開発法、ソフトウエアメトリックス、ＳＬＡ

システム管理に関する能力

データ、数値処理系ドキュメント、イメージ等

ナレッジ処理系

システム技術文書、導線分析、ＣＳＣＷ、

ＳＮＡ、ナッレジコラボレーション

要求分析（ＩＥ、ＯＲ、ＷＤ、ＱＣ、ＢＳ、ＫＪ、面接調査法、）、

要件定義（ＳＡＤＴ、ＩＤＥＦ、ＥＲ、ＤＦＤ、ＵＭＬ、ＥＡ）、ＯＰＭ（ＢＰＲ、ＴＱＭ、ＪＩＴ、ＭＲＰ、ＳＣＭ、ＥＲＰ、ＣＲＭ、など）

ＴＥＸＴハンドリング、情報分析、情報共有

基幹ビジネスプロセス処理、

プロジェクトマネジメント、業務知識

システム化推進に関する能力

データ、数値処理系

ドキュメント、イメージ等ナレッジ処理系

チェンジマネージメント（問題発見力、ソリューション力、変革推進力、思考プロセス）、自己変革（ＥＱ、リーダーシップ、コミュニケーション、プレゼンテーション）、コーチング、アサーション、ディベート

ＫＪ、ＢＳ、ビジネスモデル特論ＥＰＭ（ＢＭの本質、存在価値、マーケテイングの構造、利益構造、ＳＷＯＴ）、ＩＴ戦略論（ＥＡ、ポートフォリオマネージメント、実行組織など）、企業戦略特論（新規事業企画、立ち上げ、事業遂行、経営管理、ＢＳＣ、ＡＢＣ、ＶＡ）

ビジネスモデル構築に関する能力

Ａ

ＢＣＤ

Ｅ

Ｆ

人間力、問題感知発見力、企業改革使命感

発想整理技術、ビジネスモデル立案改良技術、事業化知識、情報利活用技術


41

これまでの IS 系スキルは、前述の図表 1-2-9 の“C”、“E”および“F”を中心に論じられてき

た。しかし、前述のとおり、求められる IS 系の能力はシフトしてきていることが確認できてい

る。図表 1-2-9 で言えば、“A”、“B”および“D”が強調されるようになったことがわかる。ここで、以前に加えて強く求められるようになった能力を改めてまとめてみる。

１）経営戦略を理解しその実現に向けた IS 戦略立案能力２）IS 戦略の具現化によって業務の改革を推進できる能力３）問題を発見・整理し、関係者の合意を得て、要件を明確に定義できる能力４）明確な評価基準を持ち、計画に基づいたプロジェクトを管理・評価できる能力５）IT ガバナンスを効かせて全体最適化を実現できる能力６）目標値およびメジャメントを設定し、IS 投資効果評価ができる能力７）安定的な稼動を維持し、十分なシステム信頼性を確保できる能力８）経営環境や IT 技術の変化を把握し、適切な保守ができる能力９）恒常的に本業に効果をもたらせるような利活用能力８）タイミングごとの状況に応じた外注管理・評価能力

これらを強化し、組織力を向上させるためには、それらを発揮する人材像とその役割、キャリ

アアップのステップ等を設定しないと、実際に企業には適用できない。次項では、これまで述べ

た機能と能力を、役割群またはスキル群として有する人材像を設定する。そして、これらの人材

像を適用する手順をモデルとして提示し、立場に応じて求められる実績について考察する。


42

３．情報システムに関与する人材の役割と現状

企業内の IS 関与者は、大きく次の 3 つに分類できる。・CIO ・IS 部門要員・IS を利用して業務遂行を行う業務部門の要員このうち、CIO については、本書の第 4 章「CIO の存在と役割」にて独自に採り上げて詳細に

考察するので、本項ではその役割や在り方について具体的に触れることは除く。しかし、複数プロジェクトの調整、全体の最適化を含むプロジェクトマネジメントを、１つの

組織として対応することで、より機能強化を図ろうというプロジェクトマネジメントオフィス

（Project Management Office：PMO）の設置傾向が、各企業で強まりつつある。この PMO が、

さらに機能を拡張し、CIO 機能のサポートも担当しているケースも出てきている。我が国の企業

では、すべての CIO が本来の CIO としての役割を担当し切れていないことも多いため、CIO の

機能も組織として支援し IT ガバナンスを効かせているのである。この背景から、CIO に関する

章と記述内容が重複する部分もあることをご了承願いたい。前項までに、IS 機能と実現能力について触れてきたが、ここで人材像を設定するに当たり、２

つのアプローチが考えられる。１つは、一般的な企業運営においては、同一人物（部署）が担当するであろう IS 機能を役割

群に分類し、それをもって人材像を設定する方法。もう１つは、各スキルを分類しスキル群化し

て、それぞれの固まりをもって人材像とする方法である。後者は、コンピテンシー等も含む人材像を形成する多種のスキルを徹底して抽出、分析、分類

ができている場合は可能であり、より実存の人物への対応がしやすいと思われる。ところが、材

料となるスキルの洗い出しと整理が非常に困難なため、今後の UISS の成果において、スキルか

ら見て整理されたアウトプットが標準化されることを期待し、本項では、現版の UISS が採る、

機能・役割群からの人材像設定についてご紹介したい。 UISS の IS 機能設定の考え方として、全体においても各機能においても PDCA を意識してい

ることは述べた。これを前提に、人材像についても、同じ戦略の「策定」と「評価」は同一の人

物が担当する（すべき）との発想から、ロールモデルとしての人材像を設定した。この考えを踏

まえ、人材とタスクの関連付けをしたのが次の図である（図表 1-2-10）。また、「IS 導入」と「IS保守」は、同様のスキルが求められるとの考えから、同一の人材像として設定している。人材像とタスクの関連は、人材育成の観点からモデルとなる人材像を想定し、これらの人材像

が、IS 機能の中で主となって担当するタスク、従となって担当するタスクの関係を整理されてい

る。


43

図表 1-2-10 人材像とタスクの関係（UISS 構成要素）


人材像ビジネスストラテジスト


プログラムマネー

ジャ

プロジ

ェクトマネー

ジャ

ISアナリスト

アプリケー

ションデザイナー

システムデザイナー

ＩＳオペレー

ション

ISアドミニストレー

タ

ISアー

キテクト

事業戦略策定

IS戦略策定

IS戦略実行マネジメント


IS企画

IS導入(ｱﾌﾟﾘｹｰｼｮﾝｺﾝﾎﾟｰﾈﾝﾄ)IS導入(ｼｽﾃﾑｺﾝﾎﾟｰﾈﾝﾄ)

IS企画評価

IS保守(ｱﾌﾟﾘｹｰｼｮﾝｺﾝﾎﾟｰﾈﾝﾄ)IS保守(ｼｽﾃﾑｺﾝﾎﾟｰﾈﾝﾄ)

IS運用

IS活用

IS戦略評価

事業戦略評価


凡例主たる領域従たる領域

タスク

ただし、現実的には、各人の担当する職務は、単一の人材像からなるものではなく、異なる複

数の人材像の組み合わせとなることが多い。UISS の各社への適用においては、各社独自の人材

像定義の際に、本スキル標準の人材像をでは細かすぎるので組み合わせたり、逆に大括り過ぎる

場合は分割するなどをして活用されることが期待される。また、UISS では、セキュリティ及びシステム監査の機能を担う「セキュリティアドミニスト

レータ」、「IS オーディタ」、資産管理、事業継続計画、コンプライアンス等に携わる「IS スタッ

フ」という人材像も定義しているが、全体のタスクの基礎をなすため、本表には記述していない。こうしてロールモデルとして括り出して想定した各人材像を具体的に定義したのが「人材像定

義（UISS 構成要素）」である。各人材像のミッション、活動内容、レベル範囲を定義している。

UISS は、IS 機能の各組織への役割分担、マッピング後、そこから導き出される職務を各個人レ

ベルに落とし込み、各企業独自の人材像を取捨選択または組み合せあるいは分割するなどをして

活用されることを狙いとしており、「人材像ありき」からのアプローチは前提としていない。「人材像定義」を次の図表 1-2-11 に示す。

./keyword.htm#3504


44

図表 1-2-11 人材像定義


人材像人材像ミッションと活動内容レベル

範囲

ビジネスストラテジスト【ミッション】全社戦略の実現に向けた事業戦略を策定・評価する。３～７

【活動内容】企業活動において、事業戦略策定・評価を主な活動領域として以下

を実施する。

●事業戦略策定

・事業環境分析

・情報技術動向分析

・ビジネスモデル策定への助言

●事業戦略評価

・事業戦略達成度の評価

・事業戦略達成度評価のフィードバック

また、ＩＳ戦略策定・評価、ⅠＴ戦略策定・評価を支援する。

ＩＳストラテジスト【ミッション】事業戦略実現に向けたＩＳ戦略を策定・評価する。３～７

【活動内容】企業活動において、ＩＳ戦略策定・評価を主な活動領域として以下を

実施する。

●ＩＳ戦略策定


・ＩＳ戦略の策定


●ＩＳ戦略評価

・全体計画の評価

・ＩＳ戦略の評価

また、事業戦略策定・評価、ⅠＴ戦略策定・評価、ＩＳ戦略実行マネジメントを支援

する。

プログラムマネージャ【ミッション】ＩＳ戦略の実現に向けて、複数の個別案件をマネジメントする。３～７

【活動内容】企業活動において、ＩＳ戦略実行マネジメントを主な活動領域として

以下を実施する。

●ＩＳ戦略の分析・把握

・ＩＳ戦略の理解

・各プロジェクト実現上の前提条件把握

●ＩＳ戦略実現のモニタリングとコントロール

・モニタリング（状況把握）

・コントロール

●ＩＳ戦略実現上のリスクへの対応

・原因分析

・対策策定

・調整等対応策の実施

また、ＩＳ戦略策定・評価、ⅠＴ戦略策定・評価を支援する。

プロジェクトマネージャ【ミッション】ＩＳ戦略の実現に向けて、個別案件をマネジメントする。２～６

【活動内容】企業活動において、プロジェクト計画策定、実行管理を主な活動領

域として以下を実施する。

●プロジェクト立ち上げ

●プロジェクト計画策定

●プロジェクト追跡と実行管理

●プロジェクト変更管理

●プロジェクト終結

●プロジェクト完了評価

また、ＩＳ企画・評価、ＩＳ導入を支援する。


45


範囲

ＩＳアナリスト【ミッション】ＩＳ戦略の実現に向けて、個別案件のＩＳ企画を策定・評価する。２～６

【活動内容】企業活動において、ＩＳ企画策定・評価を主な活動領域として以下を

実施する。

●ＩＳ企画策定


・ＩＳ企画の策定

・ＩＳ導入計画の策定

・調達のマネジメント

●ＩＳ企画評価

・システム運用の評価

・業務運用の評価

・ＩＳ企画の評価

また、プロジェクトマネジメント、ＩＳ導入を支援する。

アプリケーションデザイナー【ミッション】ＩＳ戦略の実現に向けた、個別案件のアプリケーションコンポーネント

の導入・保守を実施する。１～６

【活動内容】企業活動において、ＩＳ導入、ＩＳ保守を主な活動領域として以下を実

施する

●ＩＳ導入

・アプリケーションコンポーネントの分析、設計

・アプリケーションコンポーネントの開発

（・機能の詳細設計）

・ＩＳの受け入れ

・ＩＳの移行

●ＩＳ保守

・保守計画

・保守の実施

・移行


また、ＩＳ企画・評価、ＩＳ活用、ＩＳ運用を支援する。

システムデザイナー【ミッション】ＩＳ戦略の実現に向けた、個別案件のシステムコンポーネントの導

入・保守を実施する。１～６

【活動内容】企業活動において、ＩＳ導入、ＩＳ保守を主な活動領域として以下を実

施する

●ＩＳ導入

・システムコンポーネントの分析、設計

・システムコンポーネントの開発

・ＩＳの受け入れ

・ＩＳの移行

●ＩＳ保守

・保守計画

・保守の実施

・移行


また、ＩＳ企画・評価、ＩＳ運用を支援する。


46


範囲

ＩＳオペレーション【ミッション】ＩＳの効果の大化のために、システム運用を安定的・効率的に

実施する。１～６

【活動内容】企業活動において、運用及び保守（ソリューション運用(システム

及び業務)）を主な活動領域として以下を実施する。

●システム管理計画

●システム管理

●資源管理

●障害管理


●性能管理

●システム保守

●システム移行

●運用に関するシステム評価

●システム利用者対応

ＩＳアドミニストレータ【ミッション】ＩＳの効果の大化のために、利用実態に即した活用計画を策定

し、施策を遂行する。２～６

【活動内容】企業活動において、対象となるシステムの評価とフィードバック、

活用促進、情報リテラシーの向上を主な活動領域として以下を実施する。

●評価とフィードバック

・システム利用実態の評価

・改善要求とフィードバック

●活用促進

・データ活用

・ⅠＴ活用の啓発普及

●情報リテラシーの向上

また、ＩＳ企画・評価、ＩＳ導入、ＩＳ保守を支援する。

ＩＳアーキテクト【ミッション】ビジネス環境の変化や情報技術の進展に、企業として継続的に

対応するため、ⅠＴ戦略を策定し、その構築と評価、維持・管理を行う。３～７

【活動内容】企業活動において、ⅠＴ戦略策定・評価、ⅠＴ基盤構築・維持・管

理を主な活動領域として以下を実施する。

●ⅠＴ戦略策定


・ⅠＴ戦略の策定


●ⅠＴ基盤構築・維持・管理

・ⅠＴ基盤の構築

・標準体系の策定

・標準作成

・品質統制（ガバナンス）

・標準の維持・管理

●ⅠＴ戦略評価

・ⅠＴ戦略の評価

また、ＩＳ戦略策定・評価を支援する。


47


範囲

セキュリティアドミニストレータ【ミッション】全社の情報資産へのセキュリティにおける社内外からの脅威や

リスクへの対応に責任を持つ。２～６

【活動内容】企業活動において、セキュリティの活動領域として以下を実施す

る。

●セキュリティ

・セキュリティ方針の策定

・セキュリティ基準の策定

・セキュリティの分析

・セキュリティの見直し

ＩＳスタッフ企業活動におけるＩＳ機能全般に対し、（安定的・効率的に）運営するために、

以下を遂行する。２～５

資産管理【ミッション】全社の情報資産の管理と共有化による生産性向上のため、体制

整備から施策の実施・改善までの責任を持つ。

【活動内容】企業活動において、情報資産の管理方針と管理体制の策定、リ

スク分析とリスク対策の実施、情報資産の有効活用、情報資産の共有化を

主な職務とする。

事業継続計画【ミッション】事業継続計画のＩＳ領域に関わる計画策定から遂行までの責任

を持つ。

【活動内容】企業活動において、計画策定から実施、リスク分析、災害時対

応計画、バックアップ、代替処理・復旧を主な職務とする。

コンプライアンス【ミッション】ＩＳ領域に関わるコンプライアンス管理方針と体制の整備から実

施、改善までの責任を持つ。

【活動内容】企業活動において、法令及び規範の管理体制確立、管理責任

者の選定、遵守すべき法令及び規範の識別、教育・周知徹底を主な職務と

する。

人的資源管理【ミッション】ＩＳ部門及びＩＳ利用部門のＩＳ活用における人的資源確保のため

に、人材育成施策の企画、遂行に責任を持つ。

【活動内容】企業活動において、責任・権限・業務遂行、教育・訓練を主な職

務とする。

契約管理【ミッション】ＩＳ領域に関わる社外との適切な契約関係を実現するために、契

約業務全般の基準・ルールなどの整備や維持管理に責任を持つ。

【活動内容】企業活動において、委託先選定方針などの策定、各種契約の管

理を主な職務とする。

ＩＳオーディタ【ミッション】ＩＳ機能が適切かつ健全に運営されるよう、その監査の計画、遂

行に責任を持つ。２～６

【活動内容】企業活動において、各種システムの監査に係る主な活動領域と

して以下を実施する。

●システム監査

・システム監査の計画

・システム監査の実施

・システム監査の報告

・システム監査業務の管理


48

なお、ここで言うIS戦略およびIT戦略については、次のとおり定義し使用している。・ IS戦略：全社戦略あるいは事業戦略の実現を目的とした、情報システム（IS）の利活用に関する戦略・ IT戦略：社内外の変化に柔軟かつ速やかに対応可能なIT基盤（プラットフォーム、セキュリティ、

システム管理などの基本的なシステム構造）の整備に関する戦略人材像を、各組織の IS 機能の健全化に向けた人材ポートフォリオの確認や、現実とのギャッ

プを解消していくための人材育成、人材配置等に活かしていくには、各人材像にステップアップ

のためのレベルが求められる。しかし、何度も述べたが、UISS は、IS に関する専門スキルのみを定義したものであり、JUAS

の提示する「図表 1-2-16 JUAS・システム提案力を支えるスキル構成において必要とされた能

力」と合わせても、さらに、コンピテンシーと併せて成長ステップを提示することが必要となる。そこで、UISS では、変化の激しい IS 関連スキルの計画的・段階的修得のため、レベル設定の

考え方を次のように例示している。まず、4 つの観点からのレベル感を定義した。

1 業務に関するスキルのレベル ①知っている、②支援を受けてできる、③独力でできる、④指導できる

2 業務を担当した際の範囲のレベル「機能・役割定義」で言う、 ①小項目相当、②中項目相当、③大項目相当

3 業務を担当した際の立場のレベル ①遂行責任を持つ立場、②目的達成に責任を持つ立場

4 IS の分野における認知度のレベル ①社内で認知される、②社内外で認知される、③社内外で目標とされるこれらを組み合わせ、レベル設定の考え方を概念図化したのが、次の図である。

図表 1-2-12 レベル概念図


エントリレベルハイレベルレベル１レベル２レベル３レベル４レベル５レベル６レベル７

業務経験業務

（小項目相当）の遂行を担当

業務（中項目相当）の遂行を担当

業務（中項目相当）

の遂行に責任をもつ

業務（大項目相当）の遂行を担当

業務（大項目相当）

の遂行に責任をもつ

社内外で目標とされる

スキル

支援を受けてできる

知っている

業務機能（大項目相当）の目的達成に責任を持つ

ミドルレベル

指導できる

独力でできる

社内外で認知される

社内で認知される


49

レベルについては、実情を反映させ更に標準的なものに洗練していくか、設定の考え方の提示

に終始しロジックの客観性を追求するか、が求められる。いずれにしても、JUAS としては、多

くの会員企業の実態を踏まえ、UISS の成果の向上を支援していきたい。例えば、上述の様な考え方に基づきレベルを設定し、実状も加味して人材像のレベル配置を表

現してみたのが「キャリアフレームワーク（UISS 構成要素）」である（図表 1-2-13 参照）。キャリアフレームワークは、キャリアパスを描く際の枠組みとして人材像ごとのレベルを定義

したものである。IT スキル標準と同様に、個人がキャリアパスをより具体的に描けるよう UISSを活用し、同時に人材像とレベルによる明確な指標を提示することで、企業（組織）目標と個人

の成長の方向性を一致させることが可能となり、もって企業の人材育成のガイドとなることが期

待される。なお、ユーザー企業で留意すべき点として、業務部門から IS 部門へのローテーション、また

IS 部門から業務部門へのローテーションがある。各企業ではそのようなローテーションが生じて

も、個人のスキルを適切に把握・管理することにより、効果的な人材育成を推進することが必要

である。図表 1-2-13 キャリアフレームワーク（UISS 構成要素）


レベル

人材像ビジネスストラテジスト



ジャ

プロジ

ェクトマネー

ジャ

ISアナリスト

アプリケー

ションデザイナー

システムデザイナー

IＳオペレー

ション

ISアドミニストレー

タ

ISアー

キテクト

セキ

ュリティアドミニストレー

タ

ISスタッフ

ISオー

ディタ

7

6

5

4

3

2

1

エントリ

ハイ

ミドル


50

４．組織力強化に向けた IT 人材育成の考え方

本節のこれまでの項で述べてきた企業に求められる IS 機能と、それらを遂行するための能力、

人材の考察を踏まえ、本項では、情報システム活用による組織力向上に効果的な機能配置、組織

設計、IS 人材育成について考えてみる。前項までの内容を活用すれば、自社に必要な IS 機能を選定し、その機能を遂行する組織・人

材を対応付けることができる。この IS 機能および遂行する人材を持って、推進に必要な人材配

置を検討し育成に結び付けることができる。まずは、自社で保有する人材ポートフォリオを把握することから始める。それをビジネス戦略

のもとに設定された IS 戦略に照らし合わせ、どの分野の人材が不足しているのか、或いは過剰

なのかを明確化する。そして、現状とのあるべき姿のギャップを埋めるための検討をする。現状

の人員を研修等を通じて育成し再配置するのか、外部から新たな人材を採用するか、または業務

機能を外注するのか、といった方策が考えられる。その流れのイメージを図示すると次のように

なる。


図表 1-2-14 標準的な活用イメージ（例）

OutputOutputOutput

InputInputInput

要求分析要求分析要求分析業務機能（ToBe）

策定

業務機能業務機能（（ToBeToBe））

策定策定

UISSとの

突き合わせ・対象範囲

確定

UISSUISSとのとの

突き合わせ・突き合わせ・対象範囲対象範囲

確定確定

スキルセット策定

スキルセットスキルセット策定策定現状把握現状把握現状把握育成方策

検討

育成方策育成方策検討検討

要求事項業務機能モデル（ToBe）

UISS適用範囲機能役割定義（企業固有部分）

スキルセット人材ﾎﾟｰﾄﾌｫﾘｵ（ToBe）

人材ﾎﾟｰﾄﾌｫﾘｵ（AsIs）

育成方策

経営戦略事業戦略IS戦略要求事項

業務機能モデル（ToBe）UISS

IS人材への要求事項業務機能モデル（ToBe）機能役割定義（企業固有部分）UISS スキルセット

機能役割定義（企業固有部分）スキルセット人材ﾎﾟｰﾄﾌｫﾘｵ（AsIs・ToBe）UISS研修ロードマップ

※ユーザー企業各社の状況に応じて UISS を取捨選択、固有部分の追加等、

カスタマイズして利用することが可能


51

例えば、次の図表 1-2-15 のような形で現状の人材像（あるいは組織・役割）とそのレベルを確

認し、今後のあるべき人材配置（人数）とのギャップを確認することが可能である。

図表 1-2-15 人材配置検討例


このように確認できたギャップを埋めるための方策として、「社内人材の育成」の方針を採った

場合、育成対象の組織あるいは人材像と目標人数、時期を検討し、具体的な個人にマッピングす

る。そのうえで、当人の現状と将来とのギャップを埋めるための具体方策を検討する。育成方策を検討する際には、業務経験の付与（仕事による成長）とスキル開発の双方を加味す

ることが必要となる。ギャップを分析し、対象となる個人にどのような業務経験が必要か、また

どのようなスキルを修得させる必要があるかを考慮し、育成計画を策定する。このように従来可視化されていなかった個人の強み・弱みを明らかにし、計画的に人材育成を

行っていくことが、個人のモチベーションの向上とともに、企業の競争力の強化につながると考

えられる。ここで、JUAS の提示する「図表 1-2-17 JUAS・システム提案力を支えるスキル構成におい

て必要とされた能力」において今後求められるとされた能力と、JUAS・IT 動向調査 2006 の結

果から確認できた IS 関与者に必要とされた能力を再掲する。これらの修得を実現する研修カリ

キュラムや実績の積み方、具体的な育成のステップについては、これから UISS から提示される

「研修ロードマップ」に期待したい。

人材像

レベルToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs ToBe AsIs

7

6

5 1 1 1 1 1 1 1 1 1 1 1

4 2 1 2 1 2 2 1 1 2 2 1 1 2 2 1 2 2

3 2 2 2 2 6 2 2 1 4 3 2 1 3 3 3 2 6 3

2 2 2 4 6 4 2 3 5 3 3 6 6 5

1 4 4 8

IS企画第2グループ

プロジ

ェクトマネー

ジ

ャ

ISアナリスト

IS企画第3グループ

プロジ

ェクトマネー

ジ

ャ

ISアナリスト

組織 IS戦略グループIS基盤

グループIS企画第1グループ


ジ

ャ

ISアー

キテクト

プロジ

ェクトマネー

ジ

ャ

ISアナリスト


エントリ

ハイ

ミドル

全体的にレベルアップが必要全体的にレベルアップが必要

戦略系へのキャリア戦略系へのキャリアチェンジが必要チェンジが必要

※対象組織における「あるべき人材配置」と「現状の人材配置を比較


52

１）経営戦略を理解しその実現に向けた IS 戦略立案能力

２）IS 戦略の具現化によって業務の改革を推進できる能力

３）問題を発見・整理し、関係者の合意を得て、要件を明確に定義できる能力

４）明確な評価基準を持ち、計画に基づいたプロジェクトを管理・評価できる能力

５）IT ガバナンスを効かせて全体適化を実現できる能力

６）目標値およびメジャメントを設定し、IS 投資効果評価ができる能力

７）安定的な稼動を維持し、本業貢献を意識した利活用能力

８）タイミングごとの状況に応じた外注管理・評価能力


図表 1-2-16 JUAS・IT 動向調査 2006 の結果から必要とされた能力（再掲）

１）ビジネスモデル構築に関する能力

①人間力、問題感知発見力、企業改革使命感

チェンジマネジメント（問題発見力、ソリューション力、変革推進力、思考プロセス）、

自己変革（EQ、リーダーシップ、コミュニケーション、プレゼンテーション）、

コーチング、アサーション、ディベート

②発想整理技術、ビジネスモデル立案改良技術、事業化知識、情報利活用技術

KJ、BS、ビジネスモデル特論 EPM（BM の本質、存在価値、マーケテイングの構造、

利益構造、SWOT）、IT 戦略論（EA、ポートフォリオマネジメント、実行組織など）、

企業戦略特論（新規事業企画、立ち上げ、事業遂行、経営管理、BSC、ABC、VA）

２）システム化推進に関する能力

ドキュメント、イメージ等ナレッジ処理系

～TEXT ハンドリング、情報分析、情報共有～

システム技術文書、導線分析、CSCW、SNA、ナレッジコラボレーション


図表 1-2-17 JUAS・システム提案力を支えるスキル構成において必要とされた能力

./keyword.htm#0302

./keyword.htm#0501

53

第１章経営企画と人材育成第３節提案力の強化

ユーザー部門の IT 組織関係者に対しての要望の第一が提案力の強化である。

まずは提案力強化への要望の実態を振り返り、本来自部門が自らなすべきことを他部門、他社

に求めているのではないかと指摘し、その上で各社がなすべき提案力強化策を提言している。

さらに提案力とは何を意味しているのか。提案力強化のための問題とは、管理とは、を考え、

問題の見つけ方、目の付けどころなどを紹介し、ユーザー企業の変革の 3 要素に触れて提案すべ

き課題の広さを考えていただく項につなげた。

最後に日本の復興時の理論的背景は Industrial Engineering、Operation Research、 Quality Control

Work Design などがあったが、最近はあまり聞かれなくなってしまった。それに変わるケプナ

ートリゴー法に触れ、システム再構築時代のアイデアの出し方に参考になる JUAS 方式の追加を

添付した。JUAS 会員の方々から寄せられたノウハウの断片である。

業務改革のヒントにしていただけることを期待している。

１．提案力の強化

２．提案力をめぐる実態と諸問題

３．提案の課題とは何か

４．問題とは何か、管理とは何か

５．問題の見つけ方目の付けどころを何におくか

６．企業は何を変えるのかユーザー企業の 3 変革要素

７．業務改革の手法

１－３提案力の強化

54

１．提案力の強化

「提案力がない」とユーザー企業がベンダーに苦情を述べていることは、JUAS の IT 動向調

査で 10 年越しに言われている。

(n=557)

61

55

44

39

32

30

25

82

17

32

35

30

37

37

4

10

7

21

0 20 40 60 80 100

企画提案力不足

技術力が不足している

価格が高い

推進力が不十分で納期が守られない

「対応できる」と約束したことができていない

見積もり金額の妥当性が不明

こちらの指示への対応以上の仕事をしていない

セールスと実務担当者の意思が違う

その他

05年度(n=159)

04年度(n=161)


図表 1-3-1 開発ベンダーへの不満点

しかし、さまざまな疑問がわいてくる。・何を提案して欲しいと言っているのか。・提案して欲しい内容はベンダーに正しく伝わっているのか。・提案には対価を支払うのか。他人の知恵を借りておきながら、報酬は何も出さないのか。・その問題はベンダーに提案を要求すべき問題なのか。自ら考えるべき問題ではないのか。・部下の提案力向上はどのように指導すればよいのか。これらの問題に対して、以下検討を進めてみる。なお、「提案力の強化」を「ベンダーがユーザーに売り込む手法」と捉えた書籍が多く出版され

ているが、ここでの提案力の強化は、もっと幅広い日常のシステム開発、運用まで含んだ活動の

提案能力向上である。セールスマンに役立つ、売り込むためだけの提案力強化ではない。


55

２．提案力をめぐる実態と諸問題

（１）企画提案力の強化

ここ数年間の IT 動向調査の結果として、「システムベンダーへの不満点」の第 1 位に「企画提

案力の不足」が挙げられている。本年度も昨年より不満の度合いがトーンダウンしたとはいえ 1位となっている。しかし、どのような「提案」を求めているのかはこれまで明確になっていなか

った。企画提案力については、図表 1-3-2 のような、提案力を求め、「不足している」と不満を持つサ

イクルになっているのではないだろうか。ここでは、この「提案力が不足」サイクルを解消するにはどうしたらいいか、まず求められて

いる企画提案力は何かを明らかにし、企画提案力の向上に向けてどのような施策があるのかを探

っていく。


図表 1-3-2 提案力不足サイクル

「提案力がない」サイクル

業務部門顧客

（企業）ＩＴ部門

ベンダー

経営者

関係会社

顧客の顧客

情報子会社

「提案力がない」サイクル

業務部門顧客


ベンダー

経営者

関係会社

顧客の顧客

情報子会社

業務部門顧客


ベンダー

経営者

関係会社

顧客の顧客

情報子会社


56

（２）IT 部門が利用部門から求められている提案

まず、IT 部門自身はどのような提案を求められているのであろうか。ここでは、以下の 2 点を利用部門に対して質問した。 ①利用部門から見て、IT 部門の企画提案力はどうなのか。 ②IT 部門は、利用部門からどのような企画提案を求められているのか。

ａ．利用部門は、IT 部門の企画提案力に不満 ───「満足」は 1 割、「不満」が 4 割まず、IT 部門の企画提案力に対し、満足しているかどうかとういう設問に対しては、「非常に

満足」という回答は、わずか１社からしかなく、「満足」という回答も 9％にとどまった。一方、

「不満」「非常に不満」という回答はあわせて 38％と満足層の 4 倍に達した。また、「あまり期待

していない」という選択肢も用意していたが、そのような企業は 4％しかいなかった（図表 1-3-3）。 IT 部門は企画提案を期待されている。しかし、満足されていないということが明らかになった。

ｂ．IT 部門に求めたい企画提案は、「IT を活用した業務改革」 ───これに尽きるでは、IT 部門はどのような企画提案を求められているのだろうか。図表 1-3-4 は、利用部門に

対し、IT 部門に求める提案の上位 2 つを選択してもらった結果である。これによると、「IT を活用した業務改革」を 1 位に挙げる企業が 7 割、2 位に挙げる企業も含

めると、85％もの企業が IT 部門に求めたいと答えている。これには、2 つの考え方があると考えられる。

①業務改革ありき、そこに IT 活用の提案をしてほしい利用部門が今後の IT 投資で重視する項目として、「業務プロセス・システムの再編」がトップ

に上がっており、IT 部門はそれに貢献する企画提案を求められている

②IT および IT 部門の視点から業務改革の提案をしてほしい IT 部門は IT を通して会社全体の業務に密接に関わっている。会社全体の業務を横通しで見る

ことができるのは、IT 部門の強みである。したがって、業務改革においても IT および IT 部門が

欠かせない存在になりつつある。まさに IT を活用した業務改革を提案してほしいという期待も

あると考えられる。以降、「IT を活用した業務改革」には、2 つの意味を含めていることを理解いただきたい。


57

（n=795）あまり期待していない4%

普通48%

非常に満足0.1%

非常に不満4%

不満35%

満足9%


図表 1-3-3 利用部門アンケート：IT 部門の企画提案力への満足度

(n=798)

70%

9%

8%

8%

3%

14%

27%

31%

7%

12%

8%1%

1% 1%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

ITを活用した業務改革

特定テーマにおける具体的な提案

コストの削減

ITを活用した新しい事業

他社の成功事例をもとにした提案

具体的ではないが役に立ちそうな情報

その他　1位 2位


図表 1-3-4 利用部門アンケート：IT 部門に求める企画提案


58

ｃ．「IT を活用した業務改革」

─── IT 部門自身も利用部門からの期待は理解 IT 部門に、経営トップや利用部門からどのような企画提案を求めてられていると思うかを質問

した結果が図表 1-3-5 である。利用部門の期待が IT 部門の認識と一致しているかが懸念されたが、利用部門アンケート結果

とほぼ一致する結果となった。「IT を活用した業務改革」が求められていることは、IT 部門自身も十分理解している。重要

なミッションという認識のもと、業務改革に邁進していることと推察される。

62%

14%

11%

8%

4%

20%

36%

26%

9%

9%

1% 1%

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%


ITコストの削減




その他　　1位 2位


図表 1-3-5 IT 部門が経営トップまたは利用部門から求められている企画提案


59

（３）情報子会社、ベンダーに求める企画提案

それでは、IT 部門は、情報子会社・ベンダーにどのような企画提案を求めているのだろうか。 ①情報子会社、②情報子会社以外のシステムベンダーのそれぞれについて、求める提案の上位

2 つを選択してもらった（図表 1-3-6、1-3-7）。

(n=166)

45%

16%

16%

14%

5%

4%

17%

35%

15%

19%

5%

8%

0% 20% 40% 60% 80%


運用費用の削減


開発費用の削減


他社の成功事例をもとにした提案1位 2位


図表 1-3-6 IT 部門アンケート：情報子会社に求める企画提案

(n=850)

43%

19%

19%

6%

6%

7%

18%

24%

22%

20%

12%

4%

0% 20% 40% 60% 80%


.特定テーマの具体的な提案


運用費用の削減

開発費用の削減


その他1位 2位


図表 1-3-7 IT 部門アンケート：情報子会社以外のシステムベンダーに求める企画提案


60

ａ．最も求めたいのは情報子会社・ベンダー共通で「IT を活用した業務改革」情報子会社に求めたい提案も、システムベンダーに求めたい提案も、ともに「IT を活用した業

務改革」がトップで、4 割が 1 位に挙げ、さらに 2 割が 2 位として選択している。これは、IT 部門自身が「IT を活用した業務改革」の企画提案を求められているからであると

言える。「求める提案は、物売りではなく、ビジネスプロセスにアプローチするような提案」とい

う声をインタビュー調査でも聞くことができた。

ｂ．業務改革は「情報子会社やベンダーに求めるべきではない」という意見もただし、IT 部門は利用部門に「IT を活用した業務改革」の企画提案をも求められていると

回答した企業が 6 割であるのに対し、それを情報子会社やシステムベンダーに求めたいという企

業は 4 割と、2 割のギャップがある。インタビューさせていただいた先進企業からは、「自分たち IT 部門こそが『IT を活用した業務改革』を推進していくべきであり、情報子会社

やベンダーに求めるのは間違っている。」「ただ、情報子会社には受身、業務の理解がなさすぎることが不満。本体と一緒になって業務

改善していくのだという意識を持ってほしい。」「ベンダーには、IT 技術に立脚した提案を求める。また、他社事例を教えてもらい、自社の業

務改革のヒントにしたい。」といった声が代表的であった。2 割のギャップはこのあたりにあるのではないだろうか。また、「システム開発」の項で「システムベンダーへの不満の第一位として『企画提案力不足』

が 3 年連続第一位だが、昨年より『企画提案力』に対する不満がトーンダウンしている」と紹介

したが、それも「IT 部門自らが『企画提案』を行うべき」という反省が反映されたものではない

だろうか。

（４）各自の得意分野を活かして、事業貢献を

IT 部門、情報子会社、情報子会社以外のシステムベンダーそれぞれの、求められる企画提案を

突き詰めると、それぞれの得意分野を活かした提案が求められていると考えられる（図表 1-3-8）。そこで、提案に必要となる能力（技術力⇔経営・業務）と自社適合度／汎用性（自社固有の課

題に適合するものか⇔汎用的なものか）の２軸でマッピングしたものが図表 1-3-9 である。すべて、IT 部門に求められている役割ではあるが、［技術寄り］×［汎用性］のある部分はベ

ンダーが強い領域であり、［やや業務寄り］×［自社適合度］が求められる部分は、IT 部門自身

または情報子会社に求めていきたい部分ではないかと推察される。また、このように並べると、IT 組織に求められる役割が複雑多岐にわたることに改めて気づく。


61

図表 1-3-8 各 IT 組織の強みと求められている企画提案


対象強み主に求められている企画提案

IT 部門会社全体の IT を見る目・IT を活用した業務改革

・IT インフラの全体最適

・IT コスト削減

情報子会社本社との一体感

業務・現行システムについての知識

・IT を活用した業務改革

・IT インフラの全体最適

・IT コスト削減、日々の運用改善

システムベンダー個別技術、業界動向、他社との関係・IT を活用した業務改革

・セキュリティ等技術に立脚した特定テーマ

の具体的提案

・他社成功事例を基にした提案

の面積：問題解決への要求度（点線は、アンケートの選択肢になかったため、インタビューなどからの仮説で大きさを決めたもの。）

ITを活用した

業務改革

ITを活用した

新事業

ＩＴコスト削減（開発・運用）

他社の成功事例

をもとにした提案

特定テーマ（セキュリティ等）技術に立脚した具体的提案

必要な能力技術力業務・経営

汎用性

大

小

日々の運用改善

ITインフラの全社最適化

委託先に期待したい領域インハウスですべき領域

（業務知識が必要な、自社適合度が高い領域） ⇒主に、情報子会社に期待される領域（技術に立脚した、汎用性の高い領域） ⇒主に、ベンダーに期待される領域

利用部門の

役割

IT部門の役割

自社適合度

小

大


図表 1-3-9 IT 組織に求められている企画提案

IT 技術が複雑化しているという背景もあり、IT 部門だけではすべての役割を担いきれなくな

ってきている。情報子会社やシステムベンダーに企画提案を求めたいという企業が多いのはその

ためと考えられる。図表 1-3-9 では単純化して示したが、情報子会社を持たない企業の場合は、メインコントラク

ターとなるシステムベンダーにその役割が期待されていると考えられる。 IT 部門・情報子会社・システムベンダーの得意分野は異なり、事業貢献していくためには、こ

れを自社に適化することが IT 部門にとって重要な役割となろう。


62

（５）情報子会社、ベンダーからの企画提案に対するインセンティブ

情報子会社、ベンダーが企画提案を求められた場合、良い企画提案をすれば報われるのだろう

か。提案を採用したいと考えた場合のリアクションと、良い提案には提案料を払うかどうかを質

問した結果が図表 1-3-10、図表 1-3-11 である。

ａ．7 割は、「提案した企業に仕事を依頼」「提案した企業を優先」、2 割は、「競争入札」提案を採用したい場合、「提案をした企業に仕事を依頼する」という企業は 1 割で、「他社から

も話を聞いてみるが、提案をした企業を優先する」が 6 割となっている。合わせて 7 割は提案を

した企業に報いる意思があるようだ。一方、「競争入札を行う」という企業も 2 割はある。提案する情報子会社、ベンダー側は、ア

イデアだけではなく、実行力についても自社がベストだという説得力ある提案をする必要がある。

10%

7%

9%

13%

57%

54%

60%

53%

18%

19%

15%

23%

10%

12%

12%

6%

1%

1%

1%

0%

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

全体(n=884)

100人未満(n=64)

100～999人(n=550)

1000人以上(n=265)

1．提案をした企業に仕事を依頼する2．他社からも話を聞いてみるが、提案をした企業を優先する3．競争入札を行う4．良い提案を受けたことがないのでわからない5．その他


図表 1-3-10 提案を採用したいと考えた場合のリアクション


63

ｂ．良い提案であれば、「提案料を払ってもよい」という企業が 3 割提案料については、「払ってもよい」が 3 割、「払わない」が 7 割。海外の影響もあってか、提

案に対価を支払う風土が育ち始めていると考えて良いのではないだろうか。

27%

35%

21%

38%

67%

56%

73%

56%

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

全体(n=888)

100人未満(n=62)

100～999人(n=540)

1000人以上(n=261)

1．良い提案であれば提案料を支払っても良い

2．提案料として特別に支払いをすることは考えられない


図表 1-3-11 提案料について

（６）企画提案力不足の原因

ａ．「技術力・経験」と並んで、「IT 技術の高度化・複雑化」が原因、「コミュニケーション能力」も

重要情報子会社、システムベンダーの企画提案力不足の原因は何であろうか。IT 部門側の意見を聞

いた（図表 1-3-12）。「技術力・経験不足」が 1 位、「IT 技術の高度化・複雑化」が 2 位に挙げられているが、この

2 つは併せて考えるべきであろう。情報子会社・システムベンダー側の努力不足というより、「IT技術の高度化・複雑化により、すべての技術に専門性を持つことが難しくなっている」という環

境変化が原因と考えられているようである。前述したベンダーに対する「要素技術ばかり」「個別適ばかり」という不満も、技術の複雑化

が原因といえる。よって、3 割の企業が指摘する「コミュニケーション能力不足」には、次の 2 つの意味のコミ

ュニケーション能力の必要性を指しているのではないかと思われる。 ①ユーザーの求める提案を察知する「問題感知力」 ②様々な技術に専門性を持つ企業と組んでトータルな提案をするための「リーダーシップ」 ②については、1 社だけですべての技術に専門性を持つことが難しくなってきているため、こ

のような能力が必要と考えられる。


64

ｂ．「ユーザー企業の業務、実態を理解していないため」という企業も選択肢になかったが、「その他」の内訳を見ると、38 件中 25 件（その他回答の 65％、全体の

3％）が、「ユーザー企業の業務、実態を把握していないため」という点を、企画提案力不足理由

の 1 位に挙げている。「IT を活用した業務改革」についての企画提案を求めたいという期待の一

方で、「ユーザー企業の業務・実態を理解していない」現状とのギャップ認識がうかがえる。

(n=876)

34%

18%

15%

10%

8%

5%

5%

4%

22%

23%

17%

10%

5%

15%

7%

2%

0% 10% 20% 30% 40% 50% 60%

技術力・経験が不足しているため

IT技術が高度化、複雑化しているため

コミュニケーション能力が不足しているため

人材育成方針、方法に問題があるため

経営理念・戦略に問題があるため

提案を受けるユーザー企業側に問題があるため

管理者の指導力に問題があるため

その他1位 2位


図表 1-3-12 情報子会社・ベンダーの企画提案力不足の原因

52%

30%

48%

70%

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

情報子会社との提案力強化を目指したコミュニケーション会議(n=170)

システムベンダーとの提案力強化を目指したコミュニケーション会議(n=873)

1.開催している 2.開催していない


図表 1-3-13 提案力強化を目指したコミュニケーション会議の実施状況


65

8%

11%

22%

39%

48%

43%

22%

7%

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

情報子会社との開催頻度（n=65）

システムベンダーとの開催頻度(n=236）

年に1～2回 2ヶ月に1回程度 1ヶ月に1回程度 1ヶ月に1回以上


図表 1-3-14 提案力強化をめざしたコミュニケーション会議の開催頻度

(n=797)

43%

14%

47%

30%

30%

2%

0% 10% 20% 30% 40% 50%

企画提案力強化のための研修への参加

社内ローテーション、関係企業への出向等の人事施策の実施

他社との交流ができる外部研修、外部会議への参加

コンサルタントの活用

社内関係者の創意が収集できる体制作り

その他


図表 1-3-15 IT 部門自身が企画提案力強化のために行っている施策


66

ｃ．情報子会社の提案力強化施策 ───親会社との人材交流、現場とのコミュニケーションなどで提案力強化を模索情報子会社のインタビューからも、IT 部門同様に、「企画提案力の不足は感じている。企画提

案力を強化しないと受注活動に勝てない」との認識が聞かれ始めた。そこで、企画提案力強化のためにどのような施策をしているかを聞いたところ、下記のような

回答があった。・親会社との人材交流・現場とのコミュニケーションによる業務理解推進・研修・社内勉強会・企画提案書をデータベース化し再利用・開発前のレビュー項目に、投資効果、顧客満足度などをいれて検討また、実際に提案して採用された例があるかどうかを聞いたところ、下記のような、本社やグ

ループ全体をサポートするシステムの提案や現行システムをより活用するための提案例が見受け

られた。中には、「年間 100～150 件程度の提案を行っている」という情報子会社もあった。・ある事業部の一貫したシステム・グループ全体の基幹ネットワーク、情報セキュリティの提案・グループ連結経営のためのネットワーク、コード統一、システム共通化・基幹システムのデータを分析する情報活用システム親会社や現場と共通の問題意識を持ちつつ、一歩離れて、本社やグループ会社全体を見通すこ

とができれば、情報子会社ならではの提案として、IT 部門を強力にサポートできるだろう。

./keyword.htm#3502


67

３．提案の課題とは何か

ユーザーが提案力不足を要求するときに、果たして課題は明確になっているのだろうか。ある

いは課題に気がついているのか。この関係をまとめたのが次の表である。

図表 1-3-16 提案の課題

課題の

明確化

ユーザーからの

課題提示

ベンダーからの

回答

ベンダーへの

見返り

コメント

A1：RFP 見積書受注 RFP の不十分さの見

極めは必要

A2-1：

回答書

提案書

開発中は契約内で処

理

通常、特別に支払い

行為は起きない

A2：日常問題であり

特に指定した書類

はない

A2-2：

回答書

提案書

運用中は SLA 内など

で処理

または CLA1で対処

コストダウンがあれ

ば、CLA で対応する

こともある

課題明確

A3：特別に指定した

問題

提案書

回答書

コンサルフィー依頼時に有料、無料

の明確化が必要

課題漠然 B1：指定はない解決策に導く検討方

法を提案

（例：課題検討チーム

の設置など）

実行作業の受注受託時に有料、無料

の区別が必要

課題発見

ユーザーは

課題に気が

ついていない

C1：なし提案書

課題と解決方法の提

示

実行作業の受注提案自体は無料

ベンダーが改善点を

見つけて提案

（１）課題が明確な場合

ａ．新しくシステム開発を行う場合

新しくシステム開発を行う場合は、ユーザーから見積要求仕様書（RFP）が提出されるのでそ

れに対して回答すれば良い。ただしこの回答の中で「新しい知恵や工夫」がどの程度盛り込まれ

ているかが各ベンダーの腕の見せどころとなる。 RFP をめぐる問題は、「ユーザーの提示内容が粗い」などベンダー側から見ると不満はあるが、

RFP についての日本の標準様式などがないことが、一番の問題である。ユーザーとベンダー間の前提条件の整理を含めて、RFP の内容について記述方法のベストプラ

クティスの追究が必要である。JUAS でも 2006 年度にはこの問題を取り上げて解決に踏み出し

ている。ベンダーの回答がユーザーの納得できるものであれば、受注につながる。ベンダーがユーザー

の RFP の不備をどのように見極めたかが、以降のプロジェクト管理のキーポイントになる。

1 Customer Service Level Agreement の略

./keyword.htm#1903


68

ｂ．既に開発中の場合 ①開発中の課題

契約が完了しプロジェクト開発に入った場合は、課題の提案は日常茶飯事になる。どこからが提案で、どこからが基本契約内であるかは、日常ほとんど問われない。技術問題であれ、プロジェクト管理手法であれ、業務改善であれ、提案から実行に、ベンダー

やユーザーの知恵はさまざまな形で活用される。後で振り返って「提案力がなかった」とユーザーが不満を持っても、もう過去の問題となって

しまっているので、開発中は切磋琢磨で相互が知恵を出すしか妙案はない。妙案を出し合ってこそプロジェクトは成功する。

②運用時の課題

運用に入っても改善の種は無限に存在する。改善された結果のメリットがユーザーだけのもの

となり、運用を担当し、改善案を提示したアウトソーサーあるいは情報子会社には何もメリット

が返されないのであれば、提案意欲は涌いてこない。この段階では CLA（Customer Service Level Agreement）などを結び、あらかじめ定めてお

いた契約に基づき、提案の取得メリットを両者が配分するなどの動機づけインセンティブが必要

となる。しかし、現実問題として、細かい提案についてその都度効果や金額を検討することは難しい。

提案件数あるいは提案ポイントなどで評価するといった工夫が必要となる。「日々是改善」が必要な分野であるゆえ、担当者が進んで改善提案を行い、作業のレベルアッ

プを意識づける運用文化の形成が求められる。

③特別に指定した課題ユーザー側に困っている課題があり、それに対する提案をベンダー側に求める場合である。た

とえば、業務改革案であったり、技術的な問題、人材育成に伴う教育の問題であったりする。コンサルタントとしての指導を仰ぐ場合などは有料で契約が伴うので、ベンダー側も信頼性の

ある回答をせざるを得ない。しかし中には、課題は明確であっても、ユーザーに本当に解決する気があるのか、予算を確保し

てまで解決に取り組む準備があるのかが不明確な場合もある。あるいは、解決法の出来次第で予

算を確保して実行するつもりでベンダー回答をに求める場合もある。短時間で負荷をかけずに回

答をひねり出せるのかどうかは、回答者側の実力の問題である。


69

（２）課題が漠然としている場合

「わが社は在庫量が多いのではないか」「わが社の販売管理費は多いのではないか」漠然と問題があることはわかっているが、何をしたら良いのかが判らないケースもある。このような問題に答えるためには、ベンダーSE が、問題を抱えているユーザー側に密接な関

係を築いて問題意識を共有していることが前提となる。ユーザー側はこの種の問題についての提案を期待している。もし、実態が良くわからない、あるいは分析をしてみないと何ともいえないのであれば、関係

者で検討チームを作成し一歩進める案でよい。回答を得る糸口になる。 IBM 社の CSP（Customer Planning Session）などもこの手法の一つである。

（３）課題発見ユーザーは課題に気がついていない

ユーザー側は問題に気がつかなくても、ベンダーSE が業界他社と比較して問題に気づく場合

がある。あるいは新しい IT 技術や IT 製品が登場した際、問題解決に活用できるのではないかと感じた

場合は、積極的に提案してみるとよい。多少ピントが外れていても「あのベンダーは常にわが社のことを考えていてくれる」との評価

を得ることができる。その提案がきっかけとなって、別の解決方法が見つかることもあるだろう。従来お付き合いのなかった会社でも、この種の提案をきっかけにお付き合いが始まる場合もあ

る。世の中の問題の存在と解決に常に問題意識を持っていることが肝心である。上記説明の中で「ベンダー」と書いたところを、「自社 SE」と置き換えると、システム部門を

外に出していない会社の SE や、アウトソースしていても企業内に残してある IT 部門の SE に当

てはまることが多い。ただしこの場合は「有料、無料」の問題は存在しない。当然すべて無料で

あるが、提案し問題解決に結びつけば、その社内 SE の評価になって返ってくるうえ、問題を発

見、解決できた喜びは人生の生きがいそのものに結びつく。


70

４．問題とは何か、管理とは何か

「提案力を向上させよ」と言われても、何から手を付けたらよいのか判らない。そこでまず「問題とは何か」から考えてみる。

図表 1-3-17 問題点

図表 1-3-18 管理

「問題とは何か」と新入社員の頃に先輩から質問され、悩まされたものである。上記図表にあるように、「問題とは、理想状態と現実のギャップである」。視線を高いところに置き、理想を高く考えている人は、現状との間を問題であると、受け止め

ている。理想が低い人に問題は存在しないが、理想を高く掲げる人には現状とのギャップが不満

の種になる。

理想・目標

問題・課題

現状

背景解決策前提条件

リスク

制約条件

時間

原因

目標管理範囲

異常値

異常値

管理とは

目標があり、管理範囲

があり、その中に押し込

めようと努力すること


71

理想には「制約条件」が伴うが、過去に制約条件であったと考えられていたことが、時間が経

って環境が変わると、制約条件から除かれていることが多い。特にネットワークを含む近の IT技術の進歩は目覚しいので、過去の制約は現在では解消していることも多々ある。また、法律や

人事制度などが制約条件の場合も、解消していたり、変更可能になっていたりするので注意が必

要である。問題解消策を生み出すためには、問題の背景や原因を考えることも必要である。「何をしているのか」「何のために実施しているのか」などと「Why？何故か？なぜか？」を繰り返して問題を追究する。通常は、いくつかの解決策が出てくる。前提条件を変え、リスクをも直すことによって解決策

が見えてくる。ただし、時間をかけて分析することも必要である。問題とともに「管理とは何をすることか」を問うことにより解決策が見えてくることがある。品質管理、生産管理、販売管理、納期管理、人事管理など、多くの管理の種類がある。管理を

するためには目標値があり、品質管理論で使われる「3 シグマ」などの管理範囲が定められ、そ

の範囲に押し込もうとすることが管理の基本である。例えば「納期管理」ならば、標準工期が 7 日と定められ、±１日以内に納入できなかった割合

を測定し、ゼロに持っていく活動をすることである。目標もなく、達成不可能の割合も認識していないところに納期管理は存在しない。提案力強化を期待するならば、この基本理論をしっかりと認識しておくことが必要である。目標もない、理想もない、実績も評価できないのに、ベンダーに提案を求めても、その回答の

評価ができるはずもない。プロジェクトを立ち上げる場合に、このことを正しく認識しなければ、システムが完成して実

行されても、その評価を正しく行うことはできない。


72

５．問題の見つけ方目の付けどころを何におくか

目線を高く、目標を高く掲げて見るものは何か。さまざまな考え方があるので紹介してみよう。各手法が掲げている要素について、目標を上下させながら、「ムリ」「ムダ」「ムラ」がないかを

考えることで、問題が浮かび上がってくる。（１）BSC（Balanced Score Card ）

これは企業経営の問題を探る場合に「財務の視点」「顧客の視点」「業務プロセスの視点」「人材

育成の視点」の 4 方向から、眺める方法である。短期的、長期的に問うてみることで、さまざま

な問題が浮かび上がってくる。企業における諸問題に対し、この 4 項目に絞ってみると、全体が

見えてくるのは興味深い。実態分析の例を次の表に示す。各企業の環境に応じて、これ以外の指標も対象となる。

図表 1-3-19 BSC 実態分析指標の例

項目評価指標

財務の視点営業利益、経常利益、粗利、売上高、

付加価値生産性（売上高―原料費―外注費）/従業員数

売上高/従業員、各利益額/売上高、商品別原価、地区別原価など

業務プロセスの視点品質（欠陥率、クレーム率など）、納期達成率、在庫量

従業員数/生産量又は販売量、販売量/店舗別、地区別

顧客の視点顧客満足度、顧客数、顧客別発注量

人材育成の視点業務種別質量確保率/職場別、育成計画達成度、従業員満足度

（２）生産の 6 大要素

製造業の社内問題は、次の 6 要素について検討するとよい。 Product（生産） Quality（品質） Cost（費用） Delivery（納期） Morale（意欲） Safety（安全）これを BSC と対比してみよう。働く人に重点を置いていることがよくわかる。BSC を念頭に

置いて問題を検討する場合も、この 6 大要素を常にチェックしながら検討するとよい。

図表 1-3-20 生産 6 要素と BSC

生産 6 要素 BSC

Product（生産）（財務の視点）業務プロセスの視点

Quality（品質）顧客の視点、（業務プロセスの視点）

Cost（費用）財務の視点、（顧客の視点）

Delivery（納期）顧客の視点、（業務プロセスの視点）

Morale（意欲）人材育成の視点

Safety（安全）人材育成の視点

※（）内は副次的要素を意味する

./keyword.htm#0202


73

（３）5M＆I

これは「人が触るもの」を中心として問題を拾い出す方法である。 Man（人） Machine（機械） Material（材料）Method（方法） Market（市場） Information（情報） M の字にこだわっているが、後に情報がついているのは興味深い。

（４）三次元的視野

上記（１）から（３）まで課題抽出の要素を拾い出してみたが、各要素についてもう一味加え

て、問題を拾い出してみると解決方法が見えてくる。

ａ．過去―現在―未来（１）や（２）の各要素について、次を考えてみることである。・過去はどのようであったか・現在はどうか・将来はどうあるべきか将来の中には、理想はどうあるべきか、という検討も含まれる。「同じ職場の仕事を過去は何人で実施していたのか。」「その生産性はいくらだったのか。」「現在の生産性は。」「将来外国と競争する場合に、あるいは他社と競争する場合に、どの程度

の人数に絞らねばならないか。」などと考えてみると、課題が浮かび上がってくる。

ｂ．上司―自分―部下あるテーマを考える場合に、上司、例えば直属の上司あるいは社長を想定する。・あの人ならこの場合はどのような発想をするのだろうか。・この程度の問題認識で満足されるだろうか。・この回答では満足しないだろう。その後、実際に上司に確認してみるとよい。「やはり想像どおりであった」と思い当たることが

結構多いものである。逆に、部下がどのように思うかを考えることも必要である。「なるほど、私の上司は考え深い方だ」と思ってもらえるほど良く考えた自信案を出せた場合

と何か足りないな、と感じながら出した回答の差は顕著である。一緒に部下に考えてもらうことで部下が成長する共に組織の一体感も出てくる。

ｃ．先輩―自分―後輩過去―現在―未来と似ているが、別の意味ではもっと直接的で親近感がある。「先輩の時代に、このようなことが現れると気が付いて対策を講じていてくれたら」「現在抱え込んだ問題のほとんどは、未来についての予測の誤りが原因である。何故先輩はこ

の事態を予測してくれなかったのだろうか」このようなことは言われたくないものだ。目先のことだけにとらわれず、将来を考えてその対

策を講じることは後輩たちへの義務である。三次元で考え、資産ならず負債を残さないようにす

ることは、重要な判断要素である。


74

ｄ．顧客―自社―競争相手

自社の採る戦略は、競争相手にどのように写るかを考えることもデシジョンの際には必要であ

る。移り気な顧客やシビアな競争相手があってこそ、世の中は発展する。競争相手から見ると、この施策は「生ぬるい、安易な施策」なのではないか。たとえば商品販

売戦略を採用する場合に考えることで、採用案の欠点を見出す一つの手がかりにもなる。広く情報を集め、このデシジョンをする際のデータにしてほしい。

ｅ．理解―納得―体得一つの方針を出す場合に、「この案について部下あるいは会社全体はどの程度理解しているか」

と考えることがリーダーには必要である。「言われたから、従う」と「単に理解していて、従っている部下が多い」場合は、その方針の

成功確率が低いと考えた方がよい。自分の会社の将来に必要である、と納得したうえで協力する

姿勢が欲しい。「この案の実行に私達の将来がかかっている。ぜひとも成功させねば・・・」と過去の経験と

もあわせて、肌で体得した部下が多い場合は成功間違いないし、将来「あの人が提案し、実施し

てくれて良かった」と評価されるに違いない。関係者の理解のレベルを冷静に評価することも、重要な施策を実行に移す場合にはリーダーに

とって必要である。６．企業は何を変えるのかユーザー企業の 3 変革要素

企業には時代と環境の変化と共に「変えて良いもの」と「変えてはいけないもの」が混在して

いる。これを、次の図表 1-3-21 のように整理した。変革の要素は次のとおりである。

・新商品・新サービスによる顧客確保・満足度確保顧客中心主義、顧客第一主義で顧客の要望を確実に把握し、自社の商品、サービスの市場にお

ける優位性を確保することが大切である。

・業務プロセスの改革日々環境の変化に合わせて業務プロセスを変え、納期、品質に挑戦しコストを下げる努力を続

けなければ生き残れない。当然必要に応じて IT 投資を実施し新システムを活用する。

・従業員の働く意欲を高めるためと組織力を向上させるための組織変更諸制度を変え、従業員の配置転換をして常にフレッシュでやる気を全従業員に持ってもらう仕

組みの構築が必要となる。新システム構築と共にこの組織変更、制度変更を一緒に実行すること

が大きな効果をもたらす。


75


図表 1-3-21 ユーザー企業の 3 変革要素と対策

新商品・新サービス

による顧客確保・満足

業務プロセスの改革

人の気持ちの変革

問題解消の源

・顧客管理システム

・顧客情報システム

・新商品開発支援システム

・迅速な業績把握

・企業内情報共有

・関連企業との連結決算の早期化

業務の再編成・迅速化

・基幹システムの再構築

・グローバルな経営システム

・リアルタイムシステム

・企業連結システム

・組織・制度改革

・意識改革

・企業風土・文化の改革

・基盤強化・情報共有・セキュリティ

・収益向上・コスト削減、省力化、在庫削減、経費削減・

・顧客満足度の向上・社会貢献・増力化

変えるべきもの問題への対応方法

（顧客の声をくみ取る問題感知力）


76

７．業務改革の手法

（１）ケプナートリゴー法

企業において改革のもポピュラーなものは、この業務プロセスの改革である。そのための発

想法の一つであるケプナーとトリゴーが考え出した手法であるケプナートリゴー法（以下、「KT法」と表記）を紹介したい。この考え方は 7 項目の原則に基づいている。

①廃止の原則

「この業務は何のために行っているのか」「何故必要なのか」「やめた場合にどのような問題が

発生するのか」を問い、その作業の廃止を検討する。廃止したら何が困るのかがわからないときは、まずやめて何が困るか、というレベルから冷静

に判断をしてみるとよい。

②削減の法則次に、「この作業は低どこまでやらねば困るのか」「過剰にやっているとまでは言わないが、

何故そこまでやるのか」などを見直すことである。重要な部分のみを取り上げ、瑣末な部分へのサービスは思い切って削減する方法である。

③標準化の法則

ある作業を実施する場合、標準化を行い、誰が実施しても一定レベルの成果が出るように作業

の標準化をする。ベテラン社員のノウハウを標準化し、アルバイト社員でもその作業ができるよ

うに工夫することである。あるいは標準化した結果を機械に任せることである。

④機械化の法則

近の IT 技術の進歩は目覚しいものがある。この文明の機器を有効活用することである。 OA 化し、新しいパソコンを購入してメールやインターネットを活用する、携帯端末を活用す

る、パッケージの活用をする、自社用のシステムを開発するなど改革の方法はさまざまである。

⑤簡素化の原則対象作業について重点を絞って簡素化してみる。パソコンを活用し、一つの表を作成する場合でも、代表的な商品に絞ってかつ作成方法を工夫

することにより作業時間が短縮されることは多い。


77

⑥同期化の原則

作業のピークに合わせて人や機械を準備せざるを得ないことがある。作業の内容を見直し、ピ

ーク時の作業を極小化して作業の平準化を測る方法である。あるいはピーク時に合わせた対応は

するが、ピークが過ぎたら対応体制を縮小するなどの方法を講ずることである。

⑦分担検討の法則社員を増やさないで、アルバイトで可能な作業はそちらに任せる、あるいは外注化するなどの

方策を採ることである。あるいは社員の中に生じる暇を有効活用することができないかを検討す

ることである。以上が KT 法の趣旨である。かつて 40 年前に日本に IE（Industry Engineering）手法が普及

したことがあったが、まさにその手法の一つである。この KT 法だけでは、主要業務がシステム化されコンピュータに既に任されている企業では、

新システム用のアイデアは生みにくい。そこで以下の方法を付け加えて検討されることを期待し

たい。（２）JUAS での追加検討項目

追加１：対象範囲の見直し（境界設計の見直し）

既存システムが対象としていた対象範囲をさらに広げたら効果が拡大しないか、を検討する。

企業内のある業務のすべてが、他の部門の業務と無関係であるわけがない。特定部門から業務対象範囲を全社に広げ、さらに関連企業との連携をすることによりメリット

が拡大しないかを検討する。自社だけのシステム検討から、関連企業との共同システムの検討に

目を広げた場合は、全く異なるシステムが誕生することさえある。 EDI2などのデータ連携による二重入力の省略だけでなく、物の二重運搬の廃止や、材料や製品

の発注情報を相互の計画システムで活用するなど、幅広い効果が得られる場合がある。

追加２：代替化現在使用している方法よりもさらに効率的に作業をする方法がないか。既に情報システム化さ

れている場合でも、新技術を使えばさらに効率的に行えないか。高級管理職の業務を一般社員に任せる、一般社員の業務をアルバイトに任せる、固定端末を携

帯端末に置き換えてみる、バーコードを RFID に変えてみる、バッチ処理を流れ作業化してみる、

など各種の代替化は存在する。

2 EDI（Electronic Data Interchange）。商取引に関する情報を標準的な書式に統一して、企業間で電子的に交換する仕

組み。受発注や見積、決済、出入荷などに関わるデータを、あらかじめ定められた形式にしたがって電子化し、ネット

ワークを通じて送受信する。


78

追加３：抽象化

システム化する場合でも要求をそのままプログラムするのでなく、要求を抽象化、汎用化して

からプログラムにする。例：顧客コードから顧客名、住所を検索するプログラムを作成する。「方法１」顧客コードから顧客名、住所を求めるプログラムを作成する取引先コードから取引先名、住所を求めるプログラムを作成する「方法２」会社コードから会社名、住所を求めるプログラムを作成する会社名の中には、顧客も、取引先も、個人も含まれる「方法３」コードから属性情報を引き出すキーの桁数、検索属性の桁数をパラメータで与え汎用化したルーチンで検索する。

追加４：理想目標値設定法

目線、目標値を高く設定して考える。先に挙げた BSC、6 大評価値などの値を極限まで上げて、

その達成方法を考える。例えば在庫量はゼロ、品質は欠陥ゼロにする方法、工期は従来の半分以下、顧客満足度は不満

足ゼロなどに上げて、その性格の本質を追究し、極限方法を検討することにより新ビジネスモデ

ルを掴む方法である。物事の本質を考え、原理原則を求めることにより、従来見えなかったものが見えてくることが

ある。

追加５：顧客の顧客を考える顧客の求めるものを直接に探しても、その実態が見えないときがある。そのような場合は「顧客の顧客」の要望を追跡してみると意外な発見がある。例えば、問題を抱えている会社が自動車部品の製造企業であった場合は次のような顧客が存在

する。この場合の顧客は以下のように移り替わる。・部品製造会社から、組み立て自動車会社へ納品し自動車に組み立てられる。・自動車は販売会社経由で、タクシー会社に売られる。・タクシー会社は運転手に車を貸し与え乗客を乗せる。・運転手は故障すると修理会社に車を持ち込む。・修理工が部品を取り替える。部品の良し悪しについては、修理会社の修理工に聞くのが一番良くわかることになる。このような複雑なケースほどではないにしろ、顧客の顧客の要求を解消するために、提案を求

めていることは非常に多い。「何故そのような提案を求めているのか」を考えてみることにも通じ

る。

./keyword.htm#0202

79

第１章経営企画と人材育成第４節 CIO の存在と役割

CIO（Chief Information Officer：最高情報統括責任者）という呼び方は、CEO（Chief Executive

Officer：最高経営責任者）の次によく使われる用語であるが、肩書きに使われている企業はほと

んどない。元来、日本における CIO の姿は、漠然とではあるが、欧米のそれに比較すると異なっ

ている。欧米における CIO は専任であり専門家が多いとされているが、日本企業における CIO の

多くは、IT 部門を管掌する“IT 担当役員”との認識である。

特に大企業においては、スペシャリストよりもゼネラリストを役員として選任してきた経緯が

あり、IT 担当役員も例外ではない。したがって、ゼネラリストの IT 担当役員が、1～2 年のうち

には経験を経て、大 CIO になる可能性は有るにしても、その就任当初においては、極めて不安定

な時期を送ることになる。これは企業にとっても、大変大きなリスクである。

中堅中小企業の多くは、IT 部門そのものがないだけでなく、ほとんどの場合、社長が CIO にあ

たる。

この節は、経済産業省委託事業として実施された平成 18 年 3 月の「国内 CIO 実態調査」報告

書をベースに再構成した。この調査自体は、ユーザー企業へのアンケート実施、CIO インタビュ

ー、CIO 座談会から構成されている。特に、インタビュー、座談会は現実の CIO の生の声が収録

されており、より興味深い。

１．企業における位置づけ

２．CIO の責任範囲と充足度

３．CIO への課題と期待

１－４ CIO の存在と役割

80

１．企業における位置づけ

企業において CIO、あるいは CIO は、どのような位置づけにあるのだろうか。ここでは、経

営トップおよび IT 部門長との相対的関係について質問を行うことで明らかにしようとしている。質問は次の 4 つである。 ①経営陣、CIO、IT 部門の関係 ②全社規模の IT 投資計画の実質的な決定者 ③CIO と経営トップとのコミュニケーションの頻度 ④CIO と IT 部門長とのコミュニケーションの頻度

（１）経営トップ、CIO、IT 部門の関係

各企業におけるこの三者の関係は明確ではないが、あえて 3 つのタイプに分類した（図表 1-4-1参照）。

1 2 3

CIO が経営トップと

IT 部門の間に位置する

CIO が IT 部門長を

兼ねている

CIO が存在せず、

経営トップ直轄


図表 1-4-1 経営トップ、CIO、IT 部門の関係パターン

経営トップ

IT担当役員

IT部門

IT部門長

経営トップ

IT担当役員

IT部門

IT部門長

IT部門

IT部門長

IT部門

IT担当役員兼IT部門長

経営トップ

IT部門

IT担当役員兼IT部門長

経営トップ経営トップ

IT部門

IT部門長

経営トップ

IT部門

IT部門長

IT部門

IT部門長


81

ａ．企業規模別

その結果は、次の図表 1-4-2 のようになっている。一番左のタイプ１は大企業において多く見

られる形である。また、一番右のタイプ 3（CIO 不在、社長兼任）は、中堅中小企業に多く見ら

れる。

64%

57%

75%

22%

24%

35%

14%

19%

7%

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

全体(n=318)

1000人未満(n=194)

1000人以上(n=121)

IT担当役員が経営トップとIT部門の間に位置するIT担当役員がIT部門長を兼ねている

IT担当役員が存在せず、経営トップ直轄


図表 1-4-2 企業規模別経営トップ、CIO、IT 部門の関係


82

ｂ．業種別図表 1-4-2 を業種別に集計したものが次の図表 1-4-3 である。それぞれの選択肢ごとに比率の

高い業種、低い業種をまとめると、図表 1-4-4 のようになる。

82%

70%

73%

50%

82%

92%

50%

61%

56%

44%

70%

78%

63%

75%

64%

18%

18%

18%

12%

35%

21%

22%

38%

27%

11%

13%

25%

18%

12%

9%

50%

6%

8%

15%

18%

22%

17%

11%

25%

18%

0%

0%

0%

3%

0%

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

農林・水産・食品(n=11)

建築・土木・鉱業(n=33)

化学・薬品・石油(n=22)

繊維関連・紙・木材(n=6)

鉄・非鉄金属・窯業(n=17)

輸送機器・関連部品(n=12)

一般機械製造(n=20)

電気機械製造(n=33)

その他製造(n=27)

商社・流通・卸売・小売(n=52)

銀行・保険・証券・信販(n=30)

不動産・倉庫(n=9)

運輸(n=16)

インフラ(n=8)

サービス業(n=22)

IT担当役員が経営トップとIT部門の間に位置する

IT担当役員がIT部門長を兼ねているIT担当役員が存在せず、経営トップ直轄

*インフラ（通信/電気/ガス

/放送/出版/印刷等）


図表 1-4-3 業種別経営トップ、CIO、IT 部門の関係


83

図表 1-4-4 業種別の特徴


比率が高い業種比率が低い業種

1．CIO が経営トップと IT 部門

の間に位置

・農林・水産・食品

・鉄・非鉄金属・窯業

・輸送機器・関連部品

・繊維関連・紙・木材

・一般機械製造

・商社・流通・卸売・小売

2．CIO が IT 部門長を兼任・一般機械製造

・商社・流通・卸売・小売

・繊維関連・紙・木材

・輸送機器・関連部品

3．経営トップ直轄・繊維関連・紙・木材

・その他の製造

・運輸

・農林・水産・食品

・鉄・非鉄金属・窯業

・銀行・保険・証券・信販

・インフラ（通信/電気/ガス/放送/

出版/印刷等）

業種ごとのサンプル数が少ないので、一概に特徴であるとは言い難いが、それぞれの業種の特

徴を考察すると、以下のように言える。「農林・水産・食品」、「鉄・非鉄金属・窯業」では、経営トップが自ら IT 部門を管理するの

ではなく、CIO を配置して IT 部門を管理している。この両業種における企業規模の構成比は極

端に偏っているということはないので、業種の特徴と考えられる。「繊維関連・紙・木材」では、経営トップが自ら IT 部門を管理している。この業種における

企業規模の構成比は他の業種と比較してそれほど偏りがないので、業種の特徴と考えられる。「一般機械製造」および「商社・流通・卸売・小売」では、CIO が IT 部門長を兼任している。

この両業種における企業規模の構成比は 1000 人未満の比率が高いにもかかわらず、経営トップ

自らの管理ではなく担当役員を配置し、IT 部門長を兼任させているところに特徴がある。「銀行・保険・証券・信販」および「インフラ（通信/電気/ガス/放送/出版/印刷等）」では、経

営トップが自ら IT 部門を管理するケースがほとんどない。この 2 つの業種は、売上高に対する

IT 予算の比率が高く（IT 動向調査 2006 では、銀行・保険・証券・信販：6.0％、インフラ（通

信/電気/ガス/放送/出版/印刷等）：2.4、全業種平均：1.3）、事業の IT への依存率が高い業種と言

える。そのため、IT への投資が重要視され、担当する役員を必要とするのではないかと考えられ

る。また、インフラ（通信/電気/ガス/放送/出版/印刷等）における企業規模の構成比は 1000 人以

上の比率が高いということも影響している。


84

（２）CIO の役職

現在の CIO の役職は、「常務以上の役員」がも多く 5 割を超える。次いで「取締役・執行役

員」で 4 割、「社長」が 1 割弱である。企業規模別に見ると、大企業では社長の割合が減り、そ

の分「常務以上の役員」の割合が増えている。一方中堅企業では、「社長」「取締役、執行役員」

の割合が若干増えている。

53%

55%

52%

38%

35%

33%

3%

4%10%

7%

7% 2%

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

①現在のＩＴ担当役員(n=346)

②前任のＩＴ担当役員(n=286)

③前々任のＩＴ担当役員(n=230)

社長常務以上の役員（副社長、専務、常務）取締役、執行役員その他


図表 1-4-5 CIO の役職

・大企業では「常務以上の役員」が多く、中堅企業では「取締役、執行役員」の割合が増加

現在の CIO の役職を企業規模別に見ると、大企業では社長の割合が減り、その分「常務以上の

役員」の割合が増えている。一方中堅企業では、「社長」「取締役、執行役員」の割合が若干増え

ている。

10% 46%

65%

41%

32%

3%

2%

1%

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

1000人未満(n=210)

1000人以上(n=133)



図表 1-4-6 企業規模別、現在の CIO の役職


85

業種別に見たものが次図である。

11%

13%

6%

10%

11%

18%

12%

73%

57%

52%

59%

48%

46%

48%

47%

68%

73%

59%

75%

28%

27%

31%

43%

38%

35%

38%

48%

46%

38%

42%

21%

9%

29%

25%

64%

6%

3%

4%

4%

0%

0%

0%

0%

50%

62%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

0%

8%

6%

3%

6%

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













運輸(n=17)

インフラ(n=8)




図表 1-4-7 業種別、現在の CIO の役職


86

（３）CIO の担当期間

CIO の担当期間は、2～5 年がも多い。なお、現在の CIO は、約 1／4 の企業で、担当して 1年に満たない。CIO の任期は大企業よりも中堅企業のほうが長い。担当期間でも、CIO という職

務に対して、日本企業の姿勢が感じられる。総務担当、人事担当、経理担当といった担当別の期

間を同一の条件で調査していないので即断は難しいが、明らかに短すぎる。ゼネラリストであれ

ばあるほどこの期間は必要である。

25%

23%

24%

30%

50%

45%

23%

23%

29%

23%

4%

3%

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




1年未満 1～2年未満 2年～5年未満 5年以上


図表 1-4-8 CIO の担当期間

・社長兼任の場合は、担当期間が長い

CIO の役職によって違いがあるのだろうか。前任の場合を調べると、CIO の役職が社長の場合

は他の役員の場合よりも担当期間が相当に長く、「5 年以上」という回答が 5 割を越している。「常務以上の役員」である場合は、「2～5 年」という割合がも多く、約 5 割、次いで、「1～

2 年未満」であった企業が 2 割強で、全体での比率とほぼ同じである。「取締役・執行役員」の場

合も同様である。

2%

20%

22%

27%

25%

52%

52%

55%

22%

19%

4%

0%

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

社長(n=20)　

常務以上の役員(n=156)

取締役、執行役員(n=99)



図表 1-4-9 CIO の役職と担当期間の関係（前任）

・大企業では CIO の任期はより短くなる前任の CIO の任期を企業規模別に見ると、従業員数 1000 人以上の大企業では、「2～5 年未満」

の担当期間である場合が 56％と過半数を超えている。一方、従業員数 1000 人未満の企業では、


87

担当期間が「5 年以上」という場合が 31％と、大企業よりも 20 ポイントも大きくなっている。

CIO の任期は大企業よりも中堅企業のほうが長いということがわかった。

6%

21%

27%

46%

56%

31%

11%

2%

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

1000人未満(n=163)

1000人以上(n=116)



図表 1-4-10 企業規模別担当期間の関係（前任）

これを業種別に見た。CIO の任期が極端に長い業種として、「繊維関連・紙・木材」「農林・水

産・食品」「鉄・非鉄金属・窯業」が挙げられるが、サンプル数が少ないことによる偏りという可

能性もあるので、業種の特徴としては断言できない。

10%

7%

11%

20%

33%

30%

18%

24%

27%

37%

13%

22%

20%

18%

33%

56%

44%

17%

63%

43%

35%

53%

33%

36%

44%

88%

44%

60%

55%

56%

24%

22%

83%

38%

29%

30%

24%

33%

36%

11%

33%

20%

27%

0%

0%

0%

0%

0%

0%

6%

5%

0%

0%

0%

0%

0%

0%

0%

29%

0%

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













運輸(n=9)

インフラ(n=5)




図表 1-4-11 業種別担当期間の関係（前任）


88

（４）主な経験分野

・約 8 割の CIO には IT 部門の業務経験がない

CIO はどのような経歴を持っているのだろうか。主な経験業務分野 2 つを挙げてもらった。こ

こでの主な経験分野とは、その人といえば「○○部門の人」と思いつくようなものを挙げてもら

っている。その分野の経験が長い、直近に経験した部門である、などが想定されるが、明確に定

義はしていない。まず、現在の CIO について見ると、1 つ目に挙げられた業務分野は、「総務・人事・経理」、「経

営企画・業務企画・営業企画」、「IT 部門」の順である。 2 つ目に挙げられた業務分野は、「経営企画・業務企画・営業企画」、「営業」、「総務・人事・経

理」の順で、「IT 部門」が消えて、「営業」が挙げられている。これらを合算して順位を見ると、も多いのが「経営企画・業務企画・営業企画」で、あわせ

て 62％の CIO の主な経験分野として挙げられている。次いで「総務・人事・経理」で 47％とな

っている。前任者、前々任者についても見ると、前々任で 63％とも多かった「総務・人事・経理」の経

験者が、前任：55％、現任 47％と徐々に低下し、相対的に「経営企画・業務企画・営業企画」の

割合が増加しているといえる。 IT の利用領域が社内の全領域に拡大し、特に、新規の事業戦略の遂行のために IT が活用され

るようになって、各種の企画業務と実践の経験が CIO に求められている状況が窺える。一方、IT 部門の経験者は、合算して 24％であった。前々任者：15％、前任者：17％、現任者：

24％と徐々に増えてきてはいるが、2 割程度の割合であることがわかった。 IT 部門の業務経験がない CIO が 76％も存在していることを考慮すると、彼らに対して経験を

代替し補完する手段を講ずる必要があるのではないだろうか。

20%

32%

27%

8%

2%

6%

4%

4%

15%

35%

22%

4%

9%

10%

0% 10% 20% 30% 40% 50% 60% 70%

ＩＴ部門

総務、人事、経理

経営企画、業務企画、営業企画

営業

研究

その他

他社出身経験分野1(n=343) 経験分野2(n=231)


図表 1-4-12 CIO の主な経験分野（現在の担当役員）


89

12%

41%

23%

11%

4%

5%

5%

5%

14%

35%

26%

3%

7%

10%

0% 10% 20% 30% 40% 50% 60% 70%

ＩＴ部門



営業

研究

その他



図表 1-4-13 CIO の主な経験分野（前任の担当役員）

13%

42%

25%

10%

1%

4%

5%

2%

21%

36%

24%

4%

7%

6%

0% 10% 20% 30% 40% 50% 60% 70%

ＩＴ部門



営業

研究

その他



図表 1-4-14 CIO の主な経験分野（前々任の担当役員）


90

・企業規模別経験分野これを企業規模別に見たものが図表 1-4-15 である（1 位と 2 位の割合を合算している）。従業員数1000人未満の中堅企業では、IT部門の経験者が26％とその割合が増えている。また、

「営業」経験者の割合も 33％と大企業よりも 5 ポイント高くなっている。一方、従業員数 1000 人以上の大企業では、「経営企画・業務企画・営業企画」の割合が 69％

までに達している。大企業ではより企画の経験が重視されているようである。

21%

47%

47%

58%

69%

33%

28%

5%

8%

14%

14%

16%

13%

26%

0% 20% 40% 60% 80%

1000人未満(n=209)

1000人以上(n=131)

ＩＴ部門総務、人事、経理経営企画、業務企画、営業企画営業研究その他他社出身


図表 1-4-15 企業規模別 CIO の主な経験分野（現在の CIO）

・IT 部門の経験の有無

CIO（IT 担当役員）については、大きく 2 つのタイプに分けられる。仮に A タイプ、B タイプ

とする。

A タイプの CIO：入社して、CIO に就任されるまで、IT ないしは IT 部門の経験を十分に持っている。多くの場

合、CIO 専任である。 B タイプの CIO：

入社して、CIO に就任されるまで、IT ないしは IT 部門の経験がほとんどない。多くの場合、

いくつかの部門の担当を兼任している。


91

そこで、現在の CIO の主な経験分野から、「IT 部門の経験がある CIO」、「経験がない CIO」

の 2 つに再集計した。その結果、「IT 部門の経験がある CIO」は 23％、「経験が無い CIO」は 77％と、「経験がない CIO」が圧倒的に多かった。

業種別には、現職の CIO で「IT 部門の経験がない」という比率が高い業種として、「鉄・非鉄

金属・窯業」（100％）、「輸送機器・関連部品」（92％）「建築・土木・鉱業」（91％）が挙げられ

る。一方、「IT 部門の経験がある」という比率が高い業種として、「サービス業」（58％）「銀行・保

険・証券・信販」（36％）が挙げられる。業態と IT の利用状況の関係から、IT 部門の社内における位置づけや CIO の選び方に差異が現

れているのではないだろうか。

24%

22%

58%

77%

73%

91%

92%

72%

76%

79%

78%

64%

82%

76%

75%

42%

18%

21%

25%

13%

27%

36%

28%

8%

9%

25%

24%

0%

23%

75%

87%

100%

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

全体(n=339)













運輸(n=17)

インフラ(n=8)


IT部門の経験あり IT部門の経験なし


図表 1-4-16 業種別、CIO の主な経験分野（現在の CIO）


92

・役職と専任の度合い

役職と専任度合いを比較した。 IT 部門の経験がある CIO の場合は、「取締役、執行役員」が 49％とも多いが、経験のない

CIO の場合、「常務以上の役員（副社長、専務、常務）」が 59％と約 6 割に達している。続いて専任度合いを見ると、IT 部門の経験のある CIO の場合、専任が 27％であるのに対し、

経験のない CIO の場合はわずか 0.4%（1 社）と非常に少ない。 A のタイプ（IT 部門の経験のある CIO）は、IT 部門の経験を活かした専任者、B のタイプ（IT

部門経験のない CIO）は上位の役職者で様々な部門を担当している、という 2 つの CIO の実像

が浮き彫りになった。

9%

6%

35%

59%

49%

34%

1%

6%

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





図表 1-4-17 IT 部門経験と役職

26%

40%

26%

37%

11%

12%

8%

9%

0.4%

27%

3%

2%

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



なし（ＩＴ部門専任）総務、人事、経理経営企画、業務企画、営業企画営業研究その他


図表 1-4-18 IT 部門経験と他の担当分野


93

（５）IT 以外の担当分野

・IT 部門専任担当役員は 1 割以下

CIO にあたる人が IT 部門の専任かどうか、また兼任の場合はどのような分野を兼任している

のかを調べた。まず、現在の CIO が兼務している担当分野としても多く選択されているのは、「総務・人事・

経理」で 38％、次いで「経営企画・業務企画・営業企画」の 34％であった。これは、前任者、

前々任者についてもほとんど同じ割合である。 CIO は、営業などの現場よりも一般管理業務あるいは企画業務との兼任が多いことがわかった。一方、IT 部門専任の比率は、7％であり、これは営業との兼任、あるいは、その他業務との兼

任よりも少ない割合である。なお、その他業務としては、生産管理、技術、物流、事務などが回

答されている。

7%

7%

7%

38%

39%

37%

34%

32%

39%

11%

13%

11%

3%

1%

2%

6%

6%

8%

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






図表 1-4-19 IT 以外の担当分野

・企業規模別兼任担当分野

現在の CIO の IT 以外の担当分野を企業規模別に調べたのが次表である。「IT 部門専任」と「営業」は、大企業と中堅企業との間に大きな差はないが、「総務・人事・

経理」は中堅企業の方の比率が高く、「経営企画・業務企画・営業企画」は大企業のほうが高い。

8%

44%

26%

31%

40%

10%

12%

6%

2%

2%

6%

12%

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

1000人未満(n=201)

1000人以上(n=129)



図表 1-4-20 企業規模別兼任分野


94

・業種別兼任担当分野

同様に、現在の CIO の IT 以外の担当分野を業種別に調べたのが図表 1-4-21 である。「IT 部門専任」の比率が高い業種は、「サービス業」（29％）と「インフラ」（25％）である。「総務・人事・経理」が高いのは、「農林・水産・食品」（55％）と「化学・薬品」（52％）で

あり、「経営企画・業務企画・営業企画」が高いのは、「繊維関連・紙・木材」（63％）である。「営

業」が高いのは、「商社・流通・卸売・小売」（24％）と「不動産・倉庫」（22％）である。業態と ITの利用状況などの要素から、IT部門の社内における位置づけや IT担当役員の選び方、

兼任分野に差異が現れていると考えられる。

図表 1-4-21 業種別兼任担当分野


なし

（IT 部門

専任）

総務、人

事、経理

経営企

画営業研究その他

総数

(n 値）

農林・水産・食品 0% 55% 36% 9% 0% 0% 11

建築・土木・鉱業 3% 33% 42% 6% 0% 15% 33

化学・薬品・石油 0% 52% 30% 4% 0% 13% 23

繊維関連・紙・木材 0% 38% 63% 0% 0% 0% 8

鉄・非鉄金属・窯業 0% 50% 44% 6% 0% 0% 16

輸送機器・関連部品 0% 46% 31% 0% 8% 15% 13

一般機械製造 13% 29% 42% 8% 8% 0% 24

電気機械製造 0% 38% 41% 6% 3% 12% 34

その他製造 4% 46% 27% 4% 4% 15% 26

商社・流通・卸売・小売 9% 33% 29% 24% 2% 4% 55

銀行・保険・証券・信販 3% 32% 32% 18% 0% 15% 34

不動産・倉庫 11% 44% 22% 22% 0% 0% 9

運輸 13% 40% 20% 20% 0% 7% 15

インフラ 25% 25% 13% 13% 0% 25% 8

サービス業 29% 25% 33% 13% 0% 0% 24


95

（６）IT 関連業務への投入時間割合

・60～70％の CIO の投入時間割合は 3 割未満

CIO が IT 関連業務に投入している時間の割合を聞いた結果が図表 1-4-22 である。現任者、前任者、前々任者すべてにおいて、60～70％の CIO の投入時間割合が 3 割未満であ

るが、このことは、IT 部門専任の比率が 7％であったことを考慮すれば、当然であろう。

9%

10%

10%

6%

5%

6%

20%

17%

13%

32%

29%

31%

32%

38%

39%

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




専任 5割以上 3割以上 1割以上 1割以下


図表 1-4-22 IT 関連業務への投入時間割合

・兼任している業務別の IT 業務への投入時間

現任の CIO が兼任している業務別に、IT 関連業務への投入時間割合を調べたのが図表 1-4-23である。

IT 部門専任であっても、投入時間が「1 割以下」の場合が１割弱ある。また、兼任している場

合には、業務によって投入時間が「5 割以上」の場合が 5～20％程度の範囲で分散している。

3%

2%

11%

13%

6%

17%

11%

22%

21%

21%

17%

32%

33%

39%

37%

50%

21%

9%

41%

32%

26%

17%

25%

78%

5%

0%

1%

11%

0%0%

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

ＩＴ部門専任(n=23)

総務、人事、経理(n=124)

経営企画(n=110)

営業(n=38)

研究(n=6)

その他(n=28)



図表 1-4-23 兼任している業務と、IT 関連業務への投入時間割合


96

・中堅企業の CIO のほうが投入時間は少ない企業規模によって違いはあるだろうか。図表 1-4-24 によると、従業員数 1000 人未満の企業で

は投入時間が「1 割以下」という企業が 34％であるのに対し、従業員数 1000 人以上の企業では

28％と 6 ポイントの差がある。これは、中堅企業では CIO が社長という場合が大企業より多い

ということが理由として考えられる。

10%

6%

22% 32%

34%

28%

9%

8%

19% 32%

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

1000人未満(n=208)

1000人以上(n=130)



図表 1-4-24 企業規模別 IT 関連業務への投入時間割合


97

・業種別の投入時間割合業種別に IT 関連業務への投入時間割合を見たのが次表（図表 1-4-25）である。投入時間割合が「5 割以上」（専任＋5 割以上）の比率が高い業種は、「サービス業」（24％

+16％）「インフラ」（25％+13％）であり、これは兼任担当分野に関する問いにおいて IT 部門専

任の回答比率が高い業種に一致している。投入時間割合が「１割以下」の比率が高い業種は、「化学・薬品・石油」（61％）と「その他製

造」（52％）であるが、その理由は明らかではない。

10%

12%

7%

12%

9%

13%

16%

9%

12%

9%

29%

12%

23%

21%

18%

14%

26%

50%

18%

24%

13%

8%

55%

38%

26%

14%

53%

31%

38%

38%

21%

28%

24%

27%

24%

38%

36%

36%

44%

61%

29%

35%

46%

29%

32%

52%

26%

12%

36%

18%

13%

16%

3%

29%

13%

0%

14%

6%

9%

0%

8%

4%

24%

25%

0%

0%

6%

4%

0%

3%

0%

0%

0%14%

0%

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













運輸(n=17)

インフラ(n=8)




図表 1-4-25 業種別 IT 関連業務への投入時間割合


98

6 割の CIO が IT 関連業務に投入する時間割合は、自身の総時間の 3 割未満である。

9%

10%

10%

6%

5%

6%

20%

17%

13%

32%

29%

31%

32%

38%

39%

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






図表 1-4-26 IT 関連業務への投入時間割合

3%

2%

11%

13%

6%

17%

11%

22%

21%

21%

17%

32%

33%

39%

37%

50%

21%

9%

41%

32%

26%

17%

25%

78%

5%

0%

1%

11%

0%0%

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

ＩＴ部門専任(n=23)

総務、人事、経理(n=124)

経営企画(n=110)

営業(n=38)

研究(n=6)

その他(n=28)



図表 1-4-27 兼任している業務と、IT 関連業務への投入時間割合


99

２．CIO の責任範囲と充足度

（１）主な責任範囲

肩書きに明示的に表示された CIO はごく少ない。また、各企業において、IT 担当役員の責任

範囲を明確に定義している例も少ない。例えば「システムの安定稼動」の場合、調査では、7 割

の企業では「IT 部門長の責任」としており、CIO（IT 担当役員）の責任としている企業は 2 割

である。昨今の東京証券取引所の事件のように、社会的あるいは経済的に大きな影響を与える事故が発

生した場合、終的責任は CIO が負わなければならない。定義されていると否とにかかわらず、

「CIO の責任」＋「IT 部門長の責任」をあわせた数字が、CIO の責任範囲である。こうしてみ

ると、CIO の責任範囲は際限なく大きい。ただ、ここでいう責任範囲は狭義のものであり、日常の実務を誰が担っているかというレベル

である。・業務改革への期待

4 割の企業で、「業務改革」を「CIO の責任である」としている。背景には、IT 関連組織が、現状の業務プロセスの問題点を分析し、IT を活用した業務改革、

社内業務プロセスの企画、業務効率の向上を促進する役割を果たすことへの期待の表れである。

このため、CIO をあえて Chief Innovation Officer という呼び方をする向きもある。業務改革への期待には 2 つの側面がある。

①業務改革ありき、そこに IT 活用の提案をしてほしい同調査で、利用部門（経営企画部門）に今後の IT 投資で重視する項目として「業務プロセス・

システムの再編」を挙げる企業の比率がも多く、IT 部門には業務改革につながる提案を求めて

いる。

②IT 部門の視点から業務改革の提案をしてほしい IT 部門は IT を通して会社全体の業務に密接に関わっている。会社全体の業務を横通しで見る

ことができるのは、IT 部門の強みである。したがって、業務改革においても IT および IT 部門が

欠かせない存在になりつつある。このような期待が背景にあり、CIO にも同様の期待があると考えられる。


100

・BCP への対応、内部統制

次に多い責任範囲が、「BCP（事業継続計画）への対応」、「内部統制」であり、いずれも１／

３強の企業で、CIO の責任範囲としている。しかし、「内部統制」については、CIO の責任とす

る企業、IT 部門長の責任とする企業、IT 以外の部門の責任としている企業いずれも１／３と拮

抗している。いわゆる日本版 SOX 法の施行の詳細がはっきりしていない現在、責任の所在は、

分かれている現状である。

・IT 部門長の責任範囲「システムの安定稼動」「IT 人材の育成と管理」「IT 資産、IT 基盤の評価と管理」「ベンダーの

評価、選定」「開発プロジェクトの進捗管理」「IT 予算の策定と管理」は、多くの企業で、主に IT部門長の責任としている。

これらを示したものが、以下の図表 1-4-28 から図表 1-4-30 である。

9%

40%

24%

35%

23%

9%

35%

71%

79%

82%

76%

81%

39%

45%

38%

40%

72%

32%

3%

7%

12%

14%

10%

22%

30%

27%

37%

18%

33%

27%

14%

6%

10%

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

①ＩＴ予算の策定、管理(n=347)

②ＩＴ資産、ＩＴ基盤の評価と管理(n=346)

③システムの安定稼動(n=347)

④ベンダーの評価、選定(n=347)

⑤ＩＴ人材の育成と管理(n=347)

⑥業務改革(n=347)

⑦ビジネスモデルの提案(n=347)

⑧BCP（事業継続計画）への対応(n=343)

⑨個人情報保護法への対応(n=345)

⑩開発プロジェクトの進捗管理(n=347)

⑪内部統制(n=346)

主にＩＴ担当役員の責任主にＩＴ部門長の責任その他の責任


図表 1-4-28 責任分担

./keyword.htm#0201


101

42%

28%

16%

27%

19%

52%

39%

39%

35%

19%

37%

22%

11%

3%

5%

7%

37%

21%

34%

19%

7%

35%

0% 20% 40% 60%

①ＩＴ予算の策定、管理

②ＩＴ資産、ＩＴ基盤の評価と管理

③システムの安定稼動

④ベンダーの評価、選定

⑤ＩＴ人材の育成と管理

⑥業務改革

⑦ビジネスモデルの提案

⑧BCP（事業継続計画）への対応

⑨個人情報保護法への対応

⑩開発プロジェクトの進捗管理

⑪内部統制




図表 1-4-29 CIO の IT 部門経験の有無と責任範囲

20%

8%

5%

6%

5%

29%

24%

6%

19%

11%

5%

6%

5%

38%

16%

27%

21%

9%

32%

33%

16%

7%

11%

9%

42%

33%

42%

25%

9%

34%

32%

24%

9%

17%

19%

51%

29%

44%

23%

13%

47%

25%

29%

18%

0% 20% 40% 60%

①IT予算の策定、管理

②IT資産、IT基盤の評価と管理

③システムの安定稼動

④ベンダーの評価、選定

⑤IT人材の育成と管理

⑥業務改革

⑦ビジネスモデルの提案

⑧BCP(事業継続計画)への対応

⑨個人情報保護法への対応

⑩開発プロジェクトの進捗管理

⑪内部統制

1年未満(n=79)

1～2年未満(n=85)

2～5年未満(n=102)

5年以上(n=78)


図表 1-4-30 CIO の担当期間と責任範囲


102

（２）責任範囲における充足度

全体の充足度は業務の難易度に比例している。充足度が高いのは、「予算の策定、管理」、「システムの安定稼動」、「ベンダーの評価、選定」、

「開発プロジェクトの進捗管理」、「個人情報保護法への対応」など、８割以上の企業で「十分実

現している」、「実現している」。逆に、実現していない項目は、「ビジネスモデルの提案」、「内部

統制」、「BCP への対応」、「IT 人材の育成」、「業務改革」となっている。これらは IT 部門が今後

新たに担当していかなければならない業務であり、CIOや IT部門長に課せられた課題は大きい。

4%

5%

3%

4%

15%

10%

4%

75%

68%

72%

74%

56%

56%

43%

54%

66%

75%

56%

5%

19%

5%

11%

37%

37%

51%

38%

18%

14%

38%

20%

12%

22%

13%

0%

0%

1%

2%

2%

2%

2%

1%

2%

5%

4%

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












十分実現している実現している実現していない全く実現していない


図表 1-4-31 充足度


103

17%

10%

20%

13%

4%

7%

3%

11%

9%

25%

15%

26%

14%

5%

5%

20%

13%

5%

76%

68%

73%

71%

55%

53%

43%

52%

61%

74%

53%

73%

69%

70%

78%

57%

60%

42%

56%

72%

77%

59%

21%

14%

39%

38%

51%

41%

16%

40%

16%

5%

7%

36%

36%

51%

32%

8%

11%

33%

3%

2%

4%

3%

2%

8%

5%

24%

6%

0%

3%

2%

0%

4%

2%

2%

1%

0%

0%

0%

2%

1%

3%

4%

2%

2%

2%

1%

0%

0%

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

①IT予算の策定、管理(n=210)

②IT資産、IT基盤の評価と管理(n=210)



⑤IT人材の育成と管理(n=209)



⑧BCP(事業継続計画)への対応(n=207)




①IT予算の策定、管理(n=133)

②IT資産、IT基盤の評価と管理(n=133)



⑤IT人材の育成と管理(n=133)



⑧BCP(事業継続計画)への対応(n=131)




1000人

未満

1000人

以上



図表 1-4-32 企業規模別充足度

図表 1-4-33 企業規模別充足度 DI（充足している-充足していない）


A：1000 人未満 B：1000 人以上 A-B

①IT 予算の策定、管理 85 95 -11

②IT 資産、IT 基盤の評価と管理 56 68 -12

③システムの安定稼動 88 91 -3

④ベンダーの評価、選定 68 85 -17

⑤IT 人材の育成と管理 18 23 -6

⑥業務改革 20 24 -4

⑦ビジネスモデルの提案 -8 -9 1

⑧BCP（事業継続計画）への対応 10 24 -14

⑨個人情報保護法への対応 45 83 -38

⑩開発プロジェクトの進捗管理 66 79 -13

⑪内部統制 14 29 -15


104

6%

6%

6%

6%

32%

16%

8%

68%

60%

67%

68%

66%

57%

55%

61%

48%

63%

56%

5%

22%

5%

9%

28%

36%

39%

29%

18%

22%

33%

26%

18%

29%

24%

1%

3%

3%

4%

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














図表 1-4-34 CIO の責任範囲における充足度

図表 1-4-35 CIO の責任範囲における充足度の比較


A：CIO の責任範

囲の場合 B：全体 A-B

①IT 予算の策定、管理 89 89 0

②IT 資産、IT 基盤の評価と管理 56 61 -5

③システムの安定稼動 90 89 1

④ベンダーの評価、選定 82 74 8

⑤IT 人材の育成と管理 44 21 23

⑥業務改革 26 22 4

⑦ビジネスモデルの提案 21 -8 30

⑧BCP（事業継続計画）への対応 34 16 18

⑨個人情報保護法への対応 59 60 -1

⑩開発プロジェクトの進捗管理 56 71 -15

⑪内部統制 29 20 9


105

（３）不安に感じる項目

不安のトップは「IT 人材の育成と管理」であり、以下、「内部統制」、「業務改革」、「BCP への

対応」なっている。「IT 人材の育成と管理」は、半数近くの企業が不安を感じており、IT 組織に

求められる機能、能力がますます拡大していく中で、求められる人材も変化している。多くの企

業が優秀な人材の確保と育成に課題を抱えている現状が浮き彫りになっている。「内部統制」につ

いては、J-SOX 法の施行に備えて、詳細が明らかになっておらず、多くの企業が不安に感じてい

る。

(n=342)

24%

19%

16%

12%

6%

6%

6%

6%

3%

1%

18%

14%

15%

5%

3%

12%

6%

3%

3%

2%

0.3%

21%

0% 10% 20% 30% 40% 50%

IT人材の育成と管理

内部統制

業務改革

BCP（事業継続計画）への対応

IT資産、IT基盤の評価と管理

システムの安定稼動

ビジネスモデルの提案

個人情報保護法への対応

ベンダーの評価、選定

IT予算の策定、管理

開発プロジェクトの進捗管理

1位 2位


図表 1-4-36 CIO が不安に感じている点

図表 1-4-37 実現度と不安に感じる項目


「実現していない」＋

「全く実現していない」比率

「不安に感じる」比率

（１位＋2 位）

IT 人材の育成と管理 39％ 45％

内部統制 39％ 37％

業務改革 55％ 30％

ビジネスモデルの提案 55％ 18％

BCP への対応 40％ 27％

./keyword.htm#0201


106

3%

8%

8%

3%

22%

21%

3%

13%

3%

0%

19%

2%

6%

7%

2%

29%

13%

4%

16%

7%

0%

13%

2%

7%

7%

2%

16%

18%

12%

14%

3%

1%

20%

5%

3%

0%

5%

32%

14%

3%

5%

11%

1%

21%

0% 20% 40%

IT予算の策定、管理

IT資産、IT基盤の評価と管理

システムの安定稼動

ベンダーの評価、選定

IT人材の育成と管理

業務改革

ビジネスモデルの提案

BCP（事業継続計画）

個人情報保護法への対応

開発プロジェクトの進捗管理

内部統制

1年未満(n=78)

1～2年未満(n=83)

2年～5年未満(n=102)

5年以上(n=76)


図表 1-4-38 CIO の担当期間と不安に思っている項目


107

（４）責任を果たすために感じている悩み

悩みのトップは「IT 分野独特の難しさ」であり、以下「IT 担当の役員のミッションが明確に

なっていない」、「社内の協力体制」、「IT 分野の知識、慣行、文化」の順である。「IT 分野独特の難しさ（投資の適正規模が不明、可視化が難しい、等）」は 7 割もの企業が抱

えている悩みである。CIO インタビューで、経営トップからどのようなことを求められているの

かを聞いたところ、「投資に本当に効果があるのか」、「投資が妥当であるか」についての説明が求

められているという。「投資の適正規模」、「可視化」は、IT 分野ならではの難しさである。「他の分野に比べ、IT 担当の役員のミッションが明確になっていない」では、BCP や内部統

制といった IT 部門の本来の業務とは異なると考えられる業務についても CIO の責任範囲として

挙げられている。まだ日本企業における CIO のミッションと業務責任範囲が不明確である問題点

を浮き彫りにしている。

(n=341)

45%

17%

11%

10%

4%

25%

13%

19%

15%

17%

1%

9%

2%

7%

2%

3%

0% 20% 40% 60% 80%

ＩＴ分野独特の難しさ：投資の適正規模が不明、可視化が難しい、等

他の分野に比べ、ＩＴ担当役員のミッションが明確になっていない

社内の協力体制が整っていない

ＩＴ分野についての知識、慣行、文化

ＩＴ分野に割ける時間が少ない

社内、社外を含め関係者が多く、それらの業務分担が明確になっていない

その他　

ＩＴ部門とのコミュニケーションが上手くいかない1位 2位


図表 1-4-39 CIO としての責任を果たすにおいて悩んでいる点


108

3%

14%

8%

50%

1%

21%

1%

3%

12%

18%

9%

45%

1%

9%

5%

1%

0% 20% 40% 60%

ＩＴ分野に割ける時間が少ない

他の分野に比べミッションが明確になっていない

ＩＴ分野についての知識、慣行、文化

ＩＴ分野独特の難しさ

ＩＴ部門とのコミュニケーションが上手くいかない

社内の協力体制が整っていない

社内、社外を含め関係者が多く、それらの業務分担が明確になっていない

その他




図表 1-4-40 IT 部門の経験と CIO としての責任を果たすにおいて悩んでいる点


109

（５）必要とされる知識や能力

5 割以上の企業で、「全社的リーダーシップ」「経営トップへの説明、調整」が、求められてお

り、次いで、1／3 強の企業で、「本業に関する知識・理解」、「リスク感知力・判断力」が求めら

れている。 CIO の責任範囲として業務改革がトップに挙げられており、「全社的リーダーシップ」につい

ては、その意味で当然といえる。業務改革はやはり IT を活用した業務改革であり、業務改革を

進めるには、IT 側から進める場合は、全社適が求められる。各利用部門から反発や抵抗もある

と考えられるが、それを説得し推し進めるにあたって全社的リーダーシップは必須である。「経営トップへの説明・調整」は、組織形態・企業規模にかかわらず、経営者の発想、ミッシ

ョン、ビジョンを理解した上で「経営トップの IT への理解と参加」を促し、「経営戦略と IT 戦

略の一体化」を図るうえで非常に重要である。また、経営トップからは常に、「投資金額の妥当性」

「投資の効果の妥当性」について説明を求められている。

(n=349)

38%

24%

19%

6%

5%

5%

3%

16%

7%

21%

6%

8%

8%1%

1%

33%

0% 20% 40% 60%

全社的リーダーシップ

経営トップへの説明、調整

本業に関する知識・理解

リスク感知力・判断力

ＩＴ部門へのリーダーシップ

ＩＴ分野の専門知識

管理業務（人事/経理等）に関する知識・理解

利用部門への説明、調整

1位 2位


図表 1-4-41 CIO に求められる知識・能力


110

24%

4%

3%

6%

35%

22%

1%

5%

17%

2%

5%

5%

38%

25%

1%

7%

0% 10% 20% 30% 40%

本業に関する知識・理解

管理業務（人事/経理等）に関する知識・理解

IT分野の専門知識

IT部門へのリーダーシップ

全社的リーダーシップ

経営トップへの説明、調整

利用部門への説明、調整

リスク感知力・判断力




図表 1-4-42 IT 部門の経験と必要な知識・能力


111

（６）IT 担当役員として勉強したい点

CIO が勉強したいテーマのトップは「IT 投資の客観的評価手法」で、「業務改革手法」、「リス

クマネジメント」が続く。

①「IT 投資の客観的評価手法」 CIO が社長から「IT 投資額の妥当性」「IT 投資効果の妥当性」を強く求められていることが背

景にある。客観的な評価手法としては、「ROI（投下資本利益率）」「KPI（システム化対象業務上

の指標）」「ユーザー満足度」などが一般的である。

②「業務改革手法」 IT 組織が業務改革（の一部）を担うことを期待されてきたのは、比較的近のことであり、ノ

ウハウがあるとは言えない状態である。このため業務改革手法を学びたいと言う企業が多くなっ

てきている。

③「リスクマネジメント」昨今は企業のおかれる内部、外部の環境が急激に変化しており、今まで想像もしなかったよう

なリスクが発生する。起こりうるリスクを感知・判断し、マネジメントすることは非常に重要で

ある。リスクが発生しない仕組みづくりも重要である。

(n=329)

29%

18%

17%

14%

8%

6%

5%

3%

14%

8%

18%

18%

11%

4%

12%

14%

0% 1%

0% 10% 20% 30% 40% 50%

ＩＴ投資の客観的評価手法


業務改革手法




人材育成方法

他社の事例

その他

1位 2位


図表 1-4-43 CIO が勉強したい点

./keyword.htm#1802


112

なお、当然のことであるが、CIO の IT 部門経歴の有無によって、学びたい、身につけたいも

のは若干異なる傾向にある。

13%

26%

6%

21%

22%

5%

4%

3%

1%

19%

31%

6%

12%

15%

9%

5%

4%

0%

0% 10% 20% 30% 40%





業務改革手法


人材育成方法

他社の事例

その他




図表 1-4-44 IT 部門の経験と勉強したい点


113

担当期間 1 年未満の CIO は「IT 分野の知識とトレンド」を重視、担当期間が長くなると関心

は多様になる。どの期間の場合でも「IT 投資の客観的評価手法」がも多くなっている。

24%

33%

5%

9%

14%

4%

8%

3%

18%

28%

9%

16%

14%

6%

5%

4%

13%

31%

2%

15%

21%

11%

3%

3%

16%

26%

8%

16%

16%

9%

3%

4%

0% 10% 20% 30% 40% 50%





業務改革手法


人材育成方法

他社の事例

1年未満(n=76)

1～2年未満(n=79)

2年～5年未満(n=99)

5年以上(n=74)


図表 1-4-45 CIO の担当期間と勉強したい点


114

３．CIO への課題と期待

（１）CIO と企業の相関

JUAS の調査では、日本の CIO（IT 担当役員）の平均的な像は次のようになる。・8 割の方が、IT 部門の未経験者である・1／4 の方が、就任して 1 年未満である・IT 分野ご担当期間は、半数の方が 2～5 年である・IT 部門専任という方は、1 割未満である・IT 分野に割くことのできる時間が、ごく少ない従来、CIO 像を論じる際に、「CIO の方のバックグラウンド」については漠然と語られること

はあっても、「企業における IT の位置づけ」との関係を厳密に論じられることは少なかった。また、CIO のミッションについても、ベストプラクティスを求めることが多かったように思わ

れる。経営のセンスは必須であると言われるが、テクノロジーのバックグラウンドについては、

必ずしも明確でなかった。両方のバランスが重要であるとは言え、いたずらにスーパーマンを求

めていたのではないだろうか。しかし現実に企業は、「企業における IT の位置づけ」によって

CIO を役員候補から選定している。特に大企業の専務や常務などの上級役員の場合、経理などの

他の担当の兼任が一般的であり、IT分野についてはCIO補佐官としての IT部門長を抱えている。論点を明確にするために、「CIO の方のバックグラウンド」と「企業における IT の位置づけ」

について、それぞれ、CIO／A タイプ、CIO／B タイプ、企業／A タイプ、企業／B タイプとす

る。

・CIO のバックグラウンド A タイプ：

CIO に就任するまでに、IT 関連の十分な経験を持つ。多くの場合、IT 分野が専任である。

B タイプ： CIO に就任されるまで、IT ないしは IT 部門のご経験がほとんどない方。多くの場合、いくつ

かの部門のご担当を兼任されている。

・企業における IT の位置づけ A タイプ：

・経営に占める IT 投資比率（情報化投資比率）の極めて高い企業・IT 投資の絶対額が多い（年間数百億円規模）企業・IT が企業にとって、単なる道具の域を超えて重要インフラとなっている企業・IT のトラブルが社会に与える影響が深刻である企業


115

B タイプ：・IT が、ミッションクリティカルにはなっていない企業ただし、今日ではいずれのタイプの企業にとっても、IT が重要であることには変わりはない。この関係を模式図で表示すると、次図のようになる。

図表 1-4-46 「CIO の方のバックグラウンド」と「企業における IT の位置づけ」


A タイプの CIO

（IT 経験者）

B タイプの CIO

（IT 非経験者）

A タイプの企業

（IT の重要度：高） Ⅰ Ⅳ

B タイプの企業

（IT の重要度：低） Ⅱ Ⅲ

CIO について、このような形で、便宜的に分類したが、必ずしも明確にタイプが分かれている

わけではない。企業についても同様である。ただ、このように分類したときに、当然のことなが

らⅠ～Ⅳの象限で、CIO に求められるミッションや知識、能力が異なってくる。従来、CIO 論の多くは、どちらかというとⅠ～Ⅱの象限（A タイプの CIO）のことが多かった。

しかし、現実的にはⅢ～Ⅳの象限（B タイプの CIO）がはるかに多く、ここで発生する課題や悩

みを少しでも軽減する方がはるかに重要である。JUAS としても、この 8 割以上の CIO への効率

的なカリキュラムの編成が喫緊の課題であると認識している。


116

（２）CIO 人材について

CIO のミッションを遂行するためには、経営向けの知識やスキル、経験と、IT 絡みの知識やス

キル、経験の両方が必要であることは明らかである。しかし、その両者を過不足なく備えている

スーパーマンを CIO に任命することは至難の業に近い。またそんな人材は引く手あまたで、CIOに回ってこない可能性もある。その結果、A タイプか B タイプの人材をひとまず CIO として任

命し、その上で、本人が努力して不足している能力を自ら開発し、優れた CIO に育ってもらうこ

とを期待するというのが日本の多くの企業でとられているアプローチである。その際、A タイプの人材が経営の知識やセンスを身に付けるよりも、B タイプの人材が IT の

知識を身につける方が日本の企業では一般的である。CIOはあくまでも IT絡みの知識やスキル、

経験をベースに経営に貢献するという、文字通りの意味での「チーフ・インフォメーション・オ

フィサー」という立場に立つと、B タイプの自己開発パターンを期待することは難しいし、現実

的でない。今日のように猛烈な勢いで多方面に向かって発達する IT に関する基本的な知識をゼ

ロから追いかけていたのでは、とても CIO の責を全うできないように思われる。 B タイプの CIO には CIO 補佐官をつけることが望ましい。上述のように、経営と IT の両方に

通じている人材を社内で見つけることは容易ではないし、CIO に先ず任命しておいて、後は本人

の努力に期待するというのも、ある意味では無責任な話である。したがって、B タイプの CIO に

は、CIO のパートナーとして働く CIO 補佐官をつけるべきではないだろうか。近の我が国の

企業では、経営戦略寄りに軸足を置いた CIO への需要が大きいことから、今後も、B タイプの人

材が主として CIO に登用されることになるであろう。その場合、より実務的で技術的な CIO 補

佐官の任命は、必須であると思われる。 CIO インタビューでは、CIO 補佐官を任命することの重要性や可能性も指摘された。どのタイ

プの CIO 補佐官が我が国の企業にふさわしいのか、CIO と CIO 補佐官との関係はどうあるべき

か、などについては、今後の調査に待たねばならない。今後、CIO はますます経営に軸足を置かざるを得なくなりつつあるが、その CIO を養成する

ための王道は存在しない。IT の技術的な知識や経験だけが理想的な CIO の条件ではないと考え

るならば、それは当然のことである。当面は、全社的な人事政策や人事ローテーションで、様々

な部門を経験し、その過程で経営者として抜擢された人材の中から、CIO 向きと考えられる人材

を見つけ出すことになるだろう。その中で、多くの CIO から、若い頃からの海外勤務の経験が有

効だという指摘があった。海外では、上司にすべて相談することは不可能であり、広範な問題に

ついて短時間で判断し、意思決定する必要に迫られる。この経験が、CIO になるのに有効だとい

うのだ。もっとも、これは CIO に限った話ではない。結論は、IT に拒絶反応を示すことなく、

興味や関心を持って接することのできる人材を CIO に、ということだけのようである。


117

（３）CIO への期待

単に IT を作り活用するのであれば CIO（Chief Information Officer）の役目に収まるが、CIO（Chief Innovation Officer）であれば、様々な改革の推進者であることが期待される。つまり、

日本の CIO はこの後者を期待されている。日々、プロセスを改善する意識を持つ組織文化を備えている企業の企業競争力は強い。この変

革を引き起こさせる CIO に必要な素質は、問題を問題と感じる「問題感知力」である。企業の中には過去の習慣で、何気なく実施しているルールや手法が数多く存在する。客観的に

「ここが問題である」と気づくためには、「原則に照らしてみる」、「競争相手の視点からチェック

してみる」、「顧客の立場に立ってみる」など、多くの視点が必要である。日本の CIO は業務経験

の豊かさを買われての起用が多い。CIO 自身で問題が感知できなければ、関係者の知恵を引っ張

り出して問題を認識できれば良い。この多くの従業員の知恵を引き出す才覚も必要な要素となる。この問題感知力は攻めの立場で企業競争力の向上を見極める場合と、守りのセキュリティ確保、

内部統制、システムの信頼性維持向上を意識して問題把握をする場合がある。いずれにしても、

企業内に潜む問題を問題として感知する力が原点になる。さて問題がわかれば次に「解決力」が要求されてくる。 CIO は企業にとってのすべての武器を使いこなすことが要請される。本来の IT に加えて、人、

組織、制度を変え、機械、店舗などの設備投資を行うほか、新商品開発などは研究所の支援が当

然必要になる。この新商品開発などにも IT の活用は有効である。IT の持つシミュレーション応

力、あるいは情報共有活用力などが近有効に活用され始めている。関係者の協力を得て企業内の問題を解決する力、すべての解決要素を総動員できる力が CIO に

は必要である。特に IT の企画・開発・運用・活用力および評価力は責任持って遂行しなくては

ならない。このように、多くの人やツールを使いこなすことが CIO には要求されるため、いわゆるコンピ

テンシーや人間力、人格含めての魅力が必要である。正しいことを正しいと主張できる力ととも

に、困ったときに助けることができる力が CIO には要求される。営業などの部門から初めて CIO になった場合、IT 分野のスタッフに戸惑うことがある。IT 技

術について自信を持っているだけに、対話に苦労することになる。判断について柔軟性の重要性

と正確性の調和を教えていただきたい。優秀なスタッフは、相手にわかりやすく説明できる力を

持っている。CIO もわからないことは素直に「素人の私にわかるように説明してください」と頼

んでいる。優秀な企業にとって価値のある人物を使いこなす度量が CIO には要求される。企業のグローバル化が進み海外事務所、工場とのコミュニケーションも欠かせなくなっている。

また IT の活用範囲が広がって、社内のみならず関連企業間との情報交換、システム共有利用な

どが行われている。情報子会社に限らず、多くの関連企業と利便性提供、全体適の説得ができ

る資質も CIO には要請されている。また、顧客から直接に受注情報などの情報提供を受ける仕組

みも広がっているほか、生活に直結している社会的に重要なシステムも多くなり、障害時のトラ

ブル説明の要領のよさも要求されるようになっている。マスコミなどへの対応には外向性もあわ

せて持つことが必要である。IT 部門出身であれ、業務部門出身の CIO であれ、経営や業務がわ

かり、顧客がわかり、人の心がわかることが重要である。このように重要な CIO の育成は、若い

頃からの人事ローテーションを前提に育成するのが一番の方策である。


118

119

第２章情報共有と情報活用

ここでは、情報共有の実態、活用方法、発展の歴史と今後の展望などを述べる。

第１節情報共有の目的と実態

第２節情報共有の活用

第３節情報共有技術の発展と今後

121

第２章情報共有と情報活用第１節情報共有の目的と実態

企業が業務効率化を図り省力化が進んだ後に残っている優秀なメンバーを増力して活用する一

つの手段が情報共有である。まずは情報共有の目的、目指すべき効果を明確にし、その後実態と

の差を認識する。さらに情報共有の影の部分であるセキュリティ対策について触れるのがこの節

である。

１．情報共有の目的と目指すべき効果

２．情報共有の実態

３．情報共有とセキュリティ対策

２－１情報共有の目的と実態

122

１．情報共有の目的と目指すべき効果

企業は業務効率化を図り、結果的に少ない人員で効率よく運営することを求められている。省

力化を実施し効率をあげているが、残った社員を効率的に活用する方法のひとつの強力な手段が

この「情報共有」である。別の見方をすれば、基幹業務システムの開発活用は省力化であり、こ

の情報共有は増力化である。情報共有システムの範囲は広い。単に社員に早く知らせたほうがよい総務、人事関係の情報共

有では、効果を明確に出しにくいが、顧客の営業情報や特定の社内の業務ノウハウやアイデアの

所持者の情報共有は効果に結びついてくる。漫然と情報を配布・伝達する情報共有システムから、より社内の総合力を強化する情報共有シ

ステム、効果を把握でき改善に結び付けられる進化可能な情報共有システムを社内に築いてゆく

ためには、どのように進めていけばよいのだろうか。情報共有の目的・狙いと対策の関係を整理したのが下図である。

（リアルコム社の資料を基に JUAS で改定 2006.10.8）

図表 2-1-1 情報共有の目的、狙い、対策の関係

目的狙い対策

情報収集・作成業務の効率化

連絡・コミュニケーション業務の

効率化

業務の QCD の改善

組織・従業員のスキルアップ

情報の整理、アクセスの

最適化 ①、②

コミュニケーションフローの

改善 ③

ベストプラクティスの

横展開 ②、④、⑤

スキル・ノウハウの流動化

④、⑤

企業文化の創出

迅速アクション、

日々改善の文化の形成

①基幹業務システム(社内、関連企業を含めての生産販売情報)

②顧客情報（社内、関連企業を含めて）

③フロー情報（業務連絡、事項通知など）

④ストック情報（プロジェクト情報、レポート情報など）

⑤Know-Who（誰が特定の知見やアイデアを持っているか）

生産性の向上

(Speed up)

付加価値の向上

(Quality & Power

up)


123

企業における情報共有の目的は「業務の迅速化による生産性の向上」と「社内の総智を集めた

付加価値の向上」にある。前者は主としてスピードアップであり、情報収集・作成業務の効率化

と連絡・コミュニケーション業務の効率化によってもたらされたものである。ノート、鉛筆は、

ほとんど机上から駆逐され、情報はパソコン、サーバーのディスクの中に保管されるようになっ

た。書類の作成時間、検索時間は極端に短縮された。またネットワークの高速化・広域化により、

情報保管源から手元に情報が届く時間も極端に短縮された。国内、海外からの情報収集含めての

物理的改善が企業の海外進出、グローバル化を促進している。後者の付加価値の向上は Quality & Power up であり、社内外から選択されたベストプラクテ

ィスの横展開とスキル・ノウハウの流動化によってもたらされる。ベストプラクティスの横展開、

スキルやノウハウの流動化によってバーチャル組織が誕生して企業の総智が活かされやすくなり、

総力を挙げた業務遂行が可能となった。このように情報共有は単に情報の共有にとどまらず、他の関連機器の活用とあいまって、BtoC、

BtoB、BtoE に見られるごとく、非常に幅広い面での利用と効果に関係している。「生産性の向上」と「付加価値の向上」の 2 つの狙いは、各社における「活性化された組織文

化の形成」に結びつき真の競争力のある企業となる。これが情報共有の終的な目的となる。しかし、情報の共有化は別の側面も持つことになった。蓄積された情報は、誰にまで公開可能

なのか。行き過ぎは許されない。また情報が集まれば集まるほど、そこからの情報の流出は大き

な被害になり、場合によっては社会的な問題にまで波及する。個人情報保護法や内部統制などの

影響もあって、広く活用はしたいが扱いは慎重にと、2 つの側面を抱えながら徐々に情報共有は

進化している。


124

２．情報共有の実態

IT 動向調査 2006 の段階では、情報共有すべき情報を以下の 4 区分に分けて調査した。 ①基幹業務システム（社内、関連企業を含めての生産販売情報） ②フロー情報（業務連絡、事項通知など） ③ストック情報（プロジェクト情報、レポート情報など） ④Know-Who（誰が特定な知見やアイデアを持っているか）情報共有の実態は以降に述べるが、必ずしも全面的に満足されている状態とはいえない。さら

に検討を進めると、顧客情報は特別に扱う必要があるとの指摘を受け、今後の検討は 5 区分で検

討を進めることになった。まずは上記 4 区分の実態を IT 動向調査 2006 から眺めてみる。 IT 動向調査 2006 では、「今後の IT 投資を行うにあたって、重視している項目」として常に上

位にランクされている「情報共有」の実施概況についての調査を行った。ここでの「情報共有」

とは、「情報が電子化され、各端末で閲覧ができる状態」を「情報共有が実施されている」状態と

定義している。なお、情報共有は JUAS で初めての調査であり、情報共有の定義や評価基準など回答者の判断

により、差が生じている可能性もあるが、この調査を基点として今後改善を進める。ここでは、共有すべき情報を以下の 4 つにまとめ、それぞれ、「部門／事業部」「国内全社」「国

内グループ・関連企業」「海外拠点・関連企業」「取引先企業」の 5 つに区切って情報共有の状況

を調査した。 ①業務系情報：在庫・生産・顧客等 ②フロー情報：業務連絡、通知通達等 ③ストック情報：文書、レポート、資料等 ④知識・ノウハウ

（１）全体の概況

―――克服が必要な 3 つの課題：「社内と社外の間の壁」「業務系・フロー系とストック系・知識ノウハウ系の段差」「企業規模で異なる進展度の差」を中心にして分析

それぞれの情報共有の状況を、「十分に実施されている」「実施しているが不十分」「行われて

いない」「対象外／必要性なし」の 4 つから選択してもらった。まず、現時点での認識として情報共有が「必要・妥当」と考えられている範囲を明確にするた

め、「十分に実施されている」「実施しているが不十分」「行われていない」を選択した場合を「必

要性を認識している」とし、「対象外・必要ない」と回答した割合を図表 2-1-2 にまとめた。必要・妥当な対象範囲は、経営戦略やその時々の組織運営方針や事業環境、また組織や従業員


125

の習熟度合により変化する性質のものであると言える。「部門／事業部」、「国内全社」以外では対象外／必要性なしの比率がかなり高いが、これには、

業務上関連性を持つグループ企業や海外拠点を持たない企業などの場合と、現時点ではそこまで

は考えていないという場合がある。後者は今後時間の経過や企業の戦略により、変化の可能性が

考えられる部分である。

98%

94%

65%

44%

52%

98%

96%

68%

48%

48%

97%

94%

67%

96%

93%

6%

35%

56%

48%

32%

52%

52%

6%

33%

53%

54%

7%

34%

54%

55%

46%

45%

47%

46%

66%

4%

3%

4%

2%

2%

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

A.部門/事業部(n=894)

B.国内全社(n=868)

C.国内グループ・関連企業(n=827)

D.海外拠点・関連企業(n=804)

E.取引先企業(n=820)
















業務

系情

報フ

ロー

系情

報ス

トッ

ク情

報知

識・ノ

ウハ

ウ

情報共有の対象情報共有の対象外/必要性なし


図表 2-1-2 情報共有の必要性の認識


126

次に、「情報共有の対象外／必要性なし」の回答を除いて情報共有の状況を再整理したのが、図

表 2-1-3 である。また、これより「十分に実施されている」と回答した割合のみを抽出したもの

が、図表 2-1-4 である。図表 2-1-3 と図表 2-1-4 の結果より、情報共有における以下の情況や傾向が推察できる。・「社内」と「社外の間には、4 分野すべてで実施の度合いに段差がある。会社が違えば、利害

関係、経営上の優先度、組織の習熟度、文化（価値感）・考え方、言葉など、諸々の壁が存在

する。これを突き破るリーダーシップが問われる。・「業務系情報」「フロー情報」の分野では、社内で「十分に実施」の比率が高く成功しつつあ

り、グループ・関連企業との間での実施が進みつつある。・「ストック情報」の全社共有の着手は軌道に乗った。今後成果を追う段階。・「知識・ノウハウ」については、当分試行・検討が続く段階。

46%

41%

18%

6%

5%

43%

40%

22%

12%

7%

25%

20%

11%

9%

7%

51%

52%

46%

38%

36%

48%

48%

45%

43%

29%

61%

62%

44%

40%

19%

49%

48%

35%

31%

14%

7%

36%

56%

59%

10%

11%

33%

45%

65%

14%

18%

45%

55%

77%

42%

45%

62%

67%

85%

3%

4%

4%

1%

2%

4%

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



















D.海外拠点・関連企業(n=368)　


業務

系情

報フ

ロー

系情

報ス

トッ

ク情

報知

識・ノ

ウハ

ウ

十分に実施されている実施しているが不十分行われていない


図表 2-1-3 （必要と考える対象についての）情報共有の実施状況


127

46%

43%

25%

9%

41%

40%

20%

7%

18%

22%

11%

3%

6%

12%

4%

2%

5%

7%

4%

1%

0% 10% 20% 30% 40% 50%

業務系情報

フロー系情報

ストック系情報

知識・ノウハウ

部門/事業部

国内全社

国内グループ・関連企業

海外拠点・関連企業

取引先企業


図表 2-1-4 情報共有の状況（「十分に実施されていると回答した」企業のみ抽出）


128

（２）業務系の共有

―――実施の流れは定着、ただし今後さらに共有範囲の広がりが必要

「業務系情報」について売上高の規模別に見てみた（図表 2-1-5 参照）。売上高１兆円以上の企業では、「十分に実施」は「部門・事業部」では 71％、「国内全社」では

61％となっている。しかし、「グループ・関連企業」となると 32％と下がり、「海外拠点・関連企

業」ではそれぞれ 8％、「取引先企業」では 0％といったように、大企業でも“会社の外”はこれ

からという状況である。また、売上 10 億円以上（～1 兆円）の企業群でも「部門・事業部」では「十分に実施」が 4

割を越えており、「全社」でも 4 割の水準に至っている。10 億未満の企業では「十分に実施」は

0％ながら、「部門・事業部」で「実施しているが不十分」が 57％、「全社」で 50％となっており、

これらの企業ではインフラ投資の相当部分が業務の情報共有に向けられた様子が覗える。

43%

45%

49%

71%

39%

40%

43%

61%

14%

18%

16%

32%

7%

8%

8%

7%

5%

6%

57%

53%

52%

47%

29%

50%

51%

54%

52%

39%

38%

45%

53%

53%

24%

30%

53%

75%

35%

31%

47%

36%

43%

50%

11%

6%

100%

48%

37%

31%

16%

100%

76%

63%

39%

17%

100%

59%

64%

46%

64%

5%

3%

3%

3%

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

10億未満(n=7)

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

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

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

1兆円以上(n=24)

10億未満(n=6)

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

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

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

1兆円以上(n=24)

10億未満(n=1)

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

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

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

1兆円以上(n=19)

10億未満(n=1)

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

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

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

1兆円以上(n=12)

10億未満(n=1)

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

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

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

1兆円以上(n=14)

部門

／事

業部

国内

全社

国内

グル

ープ

関連

企業

海外

拠点

関連

企業

取引

先企

業



図表 2-1-5 企業規模別業務系情報共有の実施状況


129

業務系の情報共有は、電子化する・しないに関わらず、日常の業務遂行のなかで担当関係者の

間で必須なものであった。その意味で対象情報は具体的であり、着手には比較的問題の少ない対

象といえる。経営環境の変化により情報伝達の更なる加速、また情報共有の範囲も、生産と販売といった業

務運用上の担当関係者から、設計と製造や購買、技術と営業、経営スタッフや経営層と現場、さ

らに社外（SCM、共同開発、…）など多様さを増し、情報内容もより詳細なものを求めるなど、

広さや深まりに対する変化が続くと考えられる。内容は変わっても「実施しているが不十分」が

続く性格の問題である。

（３）フロー情報

―――実施の流れは定着、小さい規模の企業での水準の向上が望まれる

この分野でも上記の「業務系」とほぼ同じような傾向を示し、売上高１兆円以上の企業では、

社内（部門／事業部、全社）では実施率 100％（「十分に実施」が 75％）あり、1000 億～１兆円

でも実施率 95％（「十分に実施」は 50％）である。100 億～1000 億、10 億～100 億、10 億以下

と企業規模が小さくなるに従い、実施率はやや低下するものの、それぞれ 80％を超えている（図

表 2-1-6 参照）。なお、「部門／事業部」と「全社」での「十分に実施」の水準にはあまり差がな

い。フロー系情報の共有目的が持つ特性と考えられる。対象となる情報の多くはイントラネットや電子メールで扱われるものである。内容的には高度

というより“便利”レベルの内容や、従業員に周知させる情報として、従来は紙ベースで扱って

いた社内広報的なものが多い。スピードや効率化、ペーパーレス効果（人手、コスト、環境問題）

で一定の効果を生んでいると考えられる。しかし、“情報発信”の奨励結果、一部で“便利”が煩わしくなる情報過多の傾向も否めない情

況になってきている。この情況を「実施しているが不十分」と感じてはいないだろうか。いわゆ

るネチケット1も乱れてきてはいないだろうか。過ぎたるは及ばざるがごとしである。効果の飽和

した分野なら深追いを避けるよう方針変更が必要である。取り扱う情報や扱い方についての見直

し、整理が期待されている。

1 ネチケット a netiquette ネットワーク上でのエチケットのこと

./keyword.htm#1901


130

31%

41%

56%

75%

29%

39%

52%

75%

15%

21%

24%

30%

10%

15%

24%

13%

4%

7%

70%

55%

48%

39%

25%

71%

51%

51%

41%

25%

37%

42%

55%

61%

31%

38%

55%

59%

27%

25%

40%

23%

20%

14%

11%

5%

14%

19%

11%

7%

100%

48%

37%

22%

9%

100%

62%

52%

30%

18%

100%

60%

71%

53%

69%

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

10億未満(n=10)

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

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

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

1兆円以上(n=24)

10億未満(n=7)

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

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

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

1兆円以上(n=24)

10億未満(n=2)

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

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

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

1兆円以上(n=23)

10億未満(n=1)

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

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

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

1兆円以上(n=17)

10億未満(n=1)

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

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

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

1兆円以上(n=13)

部門

／事

業部

国内

全社

国内

グル

ープ

関連

企業

海外

拠点

関連

企業

取引

先企

業



図表 2-1-6 企業規模別フロー系情報共有の状況


131

（４）ストック情報と知識・ノウハウ

―――大きな規模の企業で成果は見られるが、全体としてはこれから「ストック情報」については、売上高 1 兆円以上の企業でも、「十分に実施」は「部門／事業

部」で 46％、「全社」では 33％と「業務系」や「フロー情報」を大きく下回っている。1000 億

円～１兆円ではそれぞれ 32％と 26％、1000 億円以下では共に 2 割前後、10 億以下では１割で

ある（図表 2-1-7 参照）。

21%

23%

32%

46%

20%

18%

26%

33%

11%

9%

12%

14%

4%

6%

9%

2%

6%

78%

56%

63%

60%

54%

67%

52%

65%

62%

63%

33%

43%

53%

67%

29%

35%

51%

80%

16%

15%

28%

27%

11%

23%

14%

8%

17%

28%

17%

12%

100%

56%

48%

35%

19%

100%

66%

61%

43%

20%

100%

75%

83%

66%

73%

11%

17%

5%

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

10億未満(n=9)

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

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

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

1兆円以上(n=24)

10億未満(n=6)

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

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

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

1兆円以上(n=24)

10億未満(n=2)

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

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

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

1兆円以上(n=21)

10億未満(n=1)

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

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

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

1兆円以上(n=15)

10億未満(n=1)

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

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

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

1兆円以上(n=15)

部門

／事

業部

国内

全社

国内

グル

ープ

関連

企業

海外

拠点

関連

企業

取引

先企

業



図表 2-1-7 企業規模別ストック情報の共有状況

「知識・ノウハウ」についてはさらに状況は後退する。1 兆円以上に企業でも「部門／事業部」

で「十分に実施」は 25％、これ以下の規模の企業群ではせいぜい 1 割という、全体から見れば「ま

だ、これから」という段階である（図表 2-1-8 参照）。


132

10%

6%

12%

25%

10%

5%

7%

21%

3%

3%

2%

9%

2%

2%

5%

2%

50%

42%

47%

58%

67%

43%

41%

45%

60%

67%

24%

29%

50%

61%

11%

27%

41%

69%

19%

9%

20%

27%

38%

47%

47%

30%

43%

49%

50%

33%

100%

74%

68%

48%

30%

100%

89%

71%

57%

31%

100%

76%

91%

77%

73%

13%

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

10億未満(n=8)

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

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

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

1兆円以上(n=24)

10億未満(n=7)

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

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

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

1兆円以上(n=24)

10億未満(n=2)

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

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

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

1兆円以上(n=23)

10億未満(n=1)

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

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

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

1兆円以上(n=16)

10億未満(n=2)

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

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

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

1兆円以上(n=15)

部門

／事

業部

国内

全社

国内

グル

ープ

関連

企業

海外

拠点

関連

企業

取引

先企

業



図表 2-1-8 企業規模別知識・ノウハウの共有状況

これらの分野ではスピード・効率化などの量的効果もさることながら、質の向上効果に対する

期待も大きく、そのために高度な内容の情報の再利用を通じた仕事のグレードアップが考えられ

る。しかし、高度な内容は多くの場合、専門性の高い情報ということにつながり、共有に意味の

ある範囲は同種の業務の従事者や特定の関係者など、比較的狭い範囲になる場合が多い。これは一般的なシステム化では効果が期待しにくい中小組織の企業にとっても、業種によって

は有用な分野である。また、ストック情報は「知識・ノウハウ」のソースでもある。技術・知識・ノウハウ継承の仕

組み・手段として、世代間の情報共有に期待出来る部分も少なくない。なお、5 割、6 割を占める「実施しているが不十分」の多さが特に気になる。うまく行けば進

むほどに先の広がる問題である。「不十分」＝「実施した“対象分野が少ない”」というのなら問

題は小さい。しかし実態は、色々手がけているが“人が乗ってこない・効果が出ない・良い進め

方が分からない”が問題なのではないだろうか。進め方のノウハウを見つけなければならない。


133

（５）情報共有が進まない原因・推進上の課題

―――1 位は「利用者の効果・必要性認識」情報共有が進まない原因・推進上の課題について、上位 2 つを挙げてもらっている（図表 2-1-9）。

この結果によると、情報共有が進まない原因のトップは、「利用者の効果・必要性の認識」で、1位として 41％、2 位として 20％の企業が課題として挙げている。

41%

12%

11%

9%

9%

7%

6%

4%

1%

20%

25%

6%

7%

8%

10%

10%

12%

2%

0% 10% 20% 30% 40% 50% 60% 70%

利用者の効果・必要性の認識

利用者のIT活用能力

トップのリーダーシップ

IT部門の指導力

組織の柔軟性、非組織コミュニケーション

情報共有ツールの能力、またはその選択

情報が投稿されない、すいあがらない

質の高い情報が集まらない

その他1位 2位


図表 2-1-9 情報共有が進まない理由

1 位と 2 位の割合を合計し、企業規模別に見たものが図表 2-1-10 である。


134

8%

10%

11%

9%

5%

4%

8%

5%

7%

9%

6%

8%

5%

10%

8%

6%

15%

31%

35%

28%

32%

31%

31%

9%

20%

6%

8%

10%

17%

19%

23%

18%

19%

15%

8%

5%

8%

7%

10%

8%

8%

20%

5%

8%

10%

6%

1%

2%

0%

1%

0%

1%

2%

3%

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

全体（n=860)

10億円未満（n=10)

10億円～100億円未満（n=159)

100億円～1000億円未満（n=487)

1000億円～1兆円未満（n=169)

1兆円以上（n=24)

1.トップのリーダーシップ2.ＩＴ部門の指導力3.組織の柔軟性、非組織コミュニケーション4.利用者の効果・必要性の認識5.情報共有ツールの能力、またはその選択6.利用者のＩＴ活用能力7.情報が投稿されない、すいあがらない8.質の高い情報が集まらない9.その他


図表 2-1-10 企業規模別情報共有が進まない理由（1 位 2 位合わせた割合）

全体および売上１兆円未満の企業群では「利用者の IT 活用能力」が挙がり、ある程度の実績

を積んだと考えられる売上高１兆円以上の企業群では、「利用者の IT 活用能力」に加え「情報共

有ツールの能力、またはその選択」「組織の柔軟性、非組織コミュニケーション」がほぼ並ぶ点が

興味深い。利用者の IT 活用能力は、理解力・創造力・構成力・分析力などの情報活用力と言ってもよい。言うまでもなく、情報共有は何かを成し遂げるための 1 つの方法・手段であって企業目的では

ない。業務上の成果に結びつけるためには、主として従業員個人の意欲・意思、能力に依存する

問題である。従業員個人に対する“動機付け”が極めて重要になる。「企業として（あるいは組織として）ここまでやる必要がある」という改革や業績の目標を、

従業員に理解・徹底させるのが経営トップや部門長のリーダーシップである。その実現のための方針として、情報共有により効率やマネジメントの水準を高めることを業務

施策として、また、SCM のように関係会社や取引先まで巻き込んだ実施が必要な場合には事業

戦略やその施策のレベルで、明確にしておく必要がある。

./keyword.htm#1901


135

今後、社外（他社や海外）との情報共有を進める上では、異なった価値観、企業や国の文化へ

の理解、相反する利害関係に対する調整や納得を得る為の交渉力やリーダーシップが推進する関

係者に求められてくる。多くの場合、情報を共有して成果に結び付けることが出来るのは、同じような問題認識をもっ

た同じ程度の水準の人たちに限られる。情報共用範囲を広げようとすれば、そこに参加する人た

ちの水準合わせのために、十分な教育が必要になる。この情報共有の問題は、個人が自分ひとりで普及できる問題ではない。業務として遂行できる

ようにするための公式の仕組み、組織としての取り組みが必要である。情報活用の結果は業務の成果に現れるもので評価できるが、良い情報を提供した人に対するイ

ンセンティブの制度がもう一方で必要になる。マネージャーの力量が問われる問題になる。情報活用で仕事のグレードを高める必要性はわかっていても、これら上記の条件が整い、組織

全体で動かなければ成果はでてこない。ストック情報、知識・ノウハウ系となってくるほど、こ

れらの条件は重要になる。突き詰めれば“情報共有”の課題は人間系の問題となる。どのような

目的のために、誰と誰が、どのデータ・情報を共有するのかを事前に明確にすることが、この問

題の基本・必須の要件である。一方で、かなりの実績を積んだ売上 1 兆円の規模の企業から、推進上の課題として「情報共有

ツール」が挙げられていたのは現実問題として興味深い。的確にストック情報や知識・ノウハウ

を検出するツールの問題や、使える情報の信頼性や鮮度を確保するための管理や運用の問題など、

今後解決する必要のある実務上の問題も数多く残されている。


136

３．情報共有とセキュリティ対策

情報共有は、十分なセキュリティ対策とのバランスの上に成り立つ。データや情報の発生（提供）側では、それらデータや情報の重要性や機密度はわかっていても、

利用側にはその認識が十分でない場合が多い。また、個別のデータや情報では重要性や機密性が

それほどなくても、大量に集まることや、他のデータや情報との組み合わせによって飛躍的に価

値が高まる場合がある。情報共有によるデータや情報活用の狙いはこの点にあるが、セキュリテ

ィ面では極めて危険な環境を作りだしているわけでもある。セキュリティの観点からも、どのような目的のために、誰と誰が、どのデータ・情報を共有す

るのかを事前に明確にして厳密に管理する必要がある。個人情報に関しては、それを得て何らかの利益を得る人たちと、不利益を蒙る個人が“外”に

いる。個人情報保護法の施行が昨年行われ、情報漏洩が開示され、氷山の一角に過ぎないであろ

うが、マスコミでも取り上げられることがあった。しかし、機密情報の漏洩については、それを

得て利益を得る人からその事実が明かされることはまずない。漏洩していても気づきにくい性質

の問題である。今回の調査結果では、十分なセキュリティ対策のないまま、情報共有の推進に踏み出している

企業がかなりあるように見受けられた。これらの企業では、情報共有の推進とセキュリティ対策

の適切なバランスが取れるよう、早急な措置を期待したい。実施率が比較的高く、かつ機密情報が含まれる可能性の高い「ストック情報」の「部門／事業

部」での情報共有と、セキュリティ対策の実施状況の関連を 1 例として以下に示す。情報共有を「十分実施している」と「実施しているが不十分」という情報共有推進企業 745 社

の内、セキュリティポリシーの運用がされていないところが 372 社ある。実に情報共有推進企業

の 50％がセキュリティ面から大変危険な状態にあることになる。情報共有は、十分なセキュリテ

ィ対策とのバランスが必要な問題である。

29%

13%

4%

28%

33%

31%

15%

18%

16%

22%

26%

30%

6%

10%

19%

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

十分に実施されている(n=213)

実施しているが不十分(n=526)

行われていない(n=124)

情報セキュリティポリシーを策定し運用しており、定期的に見直し、更新している

情報セキュリティポリシーを策定し運用している

情報セキュリティポリシーを策定中である

情報セキュリティポリシーの策定を検討中である

情報セキュリティポリシーを策定する予定はない


図表 2-1-11 ストック情報の共有状況とセキュリティポリシー策定状況の関係

137

第２章情報共有と情報活用第２節情報共有の活用

企業の基幹システムの構築は要件定義、基本設計、詳細設計、テスト、移行と進めるのが一般

的であるが、情報共有システムの進め方は趣を異にする。まず情報共有システムの構築方法を紹

介し、その後に企業の基幹情報、顧客情報、フロー情報、ストック情報、Know-Who 情報の特徴

を整理し、最後に代表的な企業のベストプラクティスを紹介して、実際に情報共有を進める場合

の貴重な参考情報を提供する。

１．情報共有システムの構築方法

２．５種類の情報共有の進め方の特徴

３．企業の情報共有ベストプラクティス

２－２情報共有システムの構築方法

138

１．情報共有システムの構築方法

（１）DMAIC 法

リアルコム社の提唱している情報共有システムの作成方法は下図のような構成になっている。基幹業務システムは要件定義、基本設計、詳細設計、コーディング、単体テスト、結合テスト、

総合テスト、実機運用テスト（併行テスト）、移行などのフェーズと比較してみると、その差が認

識できる。

（JUAS 情報共有セミナー2005 年 5 月 20 日リアルコム吉田健一氏資料より）

図表 2-2-1 DMAIC 法 6Σ活動で用いられる経営改善のワークステップより

Step１ Define 定義

・適用組織と課題の選択・どの組織への情報共有システムを検討するのか、ターゲットを定め、その組織内のどの業務

の改善を図るのかを明確化する。

Step２ Measure 測定現状測定・分析改善しようとしている業務の実態を定量的に把握する。

Step３ Analyze 改善策検討と改善目標 Step２で把握したデータに基づき、改善案を作成し、その効果を予測する。

Step1

Define 定義

適用組織と課題の選択

Step2

Measure 測定

現状測定・分析

Step3

Analyze

改善策検討と改善目標設定

Step4

Improve

パイロット実施で効果と課題の確認

Step5

Control

パイロットの横展開

DMAIC

予算

予算

予算


139

Step４ Improve パイロット実施で効果と課題失敗を避けるために、計画した推進方法が適切か・否かを確認するために、パイロットプロ

ジェクトを実施する。効果も併せて確認し、実現可能性の確証を得る。

Step５ Control パイロットの横展開成功したパイロットモデルを基に、他の組織への横展開を図る。

（２）JUAS 法

図表 2-2-2 JUAS 法

DAMIC 法と比較すると興味深いが、実践的な方法となっている。計画段階は DAMIC 法の Step1、2、3 である。組織内であるプロジェクトを実施する場合は「予

算」が必要であり、予算が了解された場合は「実行計画」が必要である。この PLAN フェーズは、

様々な案を試行錯誤する期間である。IT 部門、ユーザー部門の企画要員がこれらの任務に当たる。 DMAIC 法にはこの予算の概念がないが、Step4、5 の前にも予算案作成が必要となる。 DMAIC 法はややスパイラル型に近く、JUAS 法はウォータフォール法に近いともいえる。はじめたからには成功させる決心を持った方法でもある。情報共有システムの普及には、情報

の収集・蓄積、活用、情報からの知恵の創出の 3 つの壁を乗り越えねばならず、時間を長く取っ

ての飴と鞭が必要となる。JUAS 法は普及に重きを置いた成功させるための方法とも言える。 2 つの方法のどちらを選ぶかは、環境に合わせて選択すればよく、ケースに合わせて使い分け

ればよい。

Do

・説得する（関係者へ）

・情報収集（飴と鞭）

・活用推進をする（入力者、利用者）

・サポート（コールセンター）を行う

Check

・活用状況と問題点の把握

・効果の確認

・計画との差異分析（費用、効果、利用度）

・使い勝手の確認と改善

Action

・システム改善計画の作成

・利用促進プランの作成

Plan

・情報共有の対象を定める

・目的を明確化する

・実態を計量化（把握）する

・効果を予測する

・必要予算を見積もる

・責任者を決める（実用部門、ＩＴ部門）

・工期決定（実作業量を基に定める）

・システム概要（現状と改善後）の確認


140

２．５種類の情報共有の進め方の特徴

（１）基幹業務情報

経済産業省の区分によると、下の図表のように基幹業務のステージは 4 段階に分けて論じられ

ている。

図表 2-2-3 情報共有（基幹業務システム）

ステージ評価グループ内容共有情報

１ IT 不良化資産群システム化したものが有効に活用され

ていない

―

２部門内最適化企業群部門内で特定業務のシステム化が行

われている

部門内販売、出荷、生

産情報

３組織全体最適化企業群経営トップに必要な情報が迅速にあが

り企業内最適化が図られている

全社の受注、進捗、納

期情報

４共同体最適化企業群情報技術を活用してバリューチェインを

構成し関連企業含めての最適化を実

現している

関連企業との受注、進

捗、調達、納期情報

部門内、企業内において基幹業務の情報は、一般に該当組織内に限定すれば公開されており、

情報は公開されている。ステージ 4 の共同体適化企業群では、関連企業間の情報公開は発注情報、受注情報、進捗情

報に限定させる。ここでの実現形態は多様であり、どこまで情報が公開されているかは、戦略の

立て方で決まる。共同仕入、共同発注を志す場合は大量仕入れによるコスト引き下げが狙いとなり情報共有は受

発注情報が主である。発注情報を基に、加工期間の短縮化を狙うのであれば、発注内容の計画情報と納期が決まった

時点での実際の納入指定日を指示した確定情報が必要になる。関係企業間の在庫の適化を狙うのであれば、受発注情報に加えて、各企業の在庫情報の共有

化が必要になるが、関係企業郡内の適化計画は高難度のシステムになる。部門内適化、企業内適化、関連企業間適化のシステム構造は一般には次のような形をと

っている。


141

図表 2-2-4 システム構造

パッケージが活用でき、かつ企業の競争力に直接に関係ない一般管理業務についてはパッケー

ジがコスト比較された上で活用されている。企業の中核業務であり、競争力の根幹を維持している部分は、自社開発モデルを使用している

ところが多い。自社業務ノウハウをカバーしているパッケージが出現してくること、自社開発モ

デルとインターフェイスが取りやすくなっていることが条件になるが、近い将来少しずつパッケ

ージも活用される可能性はある。

（経済産業省「情報経済産業ビジョン」（平成 17 年 4 月）、

野村総合研究所アンケート（平成 17 年 8 月））

図表 2-2-5 企業の IT 化ステージング

ステージ①IT不良資産化企業群

ステージ②部門内最適化企業群

ステージ③組織全体最適化企業群

ステージ④共同体最適化企業群

「経

営」の

壁

「企

業

」の

壁

情報技術導入するも活用せず

情報技術の活用により部門内最適化を実現

経営と直結した情報技術活用により企業組織全体の最適化を実現

情報技術活用によりバリューチェーンを構成する共同体全体の最適化を実現

企業のＩＴ化ステジング企業のＩＴ化ステジング

企業役

割

の変

革

人材力／ブランド力　　　　　の総合強化「深化する組織」への脱皮

社外と

の連携

統

合・標

準化

ビジネス／経営管理　　　　　の高付加価値化

特定業務の改善

情

報技術

による

企業

プ

ロセスの

最適化

業

務のＩＴ化

バック

オ

フ

ィ

スのＩＴ化

製品としてのSCMCR MSF A　・　・

製品としてのE R P人事財務　・　・

電子計算

機

の導入

ＥＤＩ導入

ＥＣ導入

「システム」の時代

「経営」の時代

コミ

ニ

ュケ

ーショ

ンの最

適化

組織改革

顧客視点の徹底トリガー

トリガー

6％ 68％ 24％ 2％

個別システム系

販売

生産

在庫

出荷

品質管理

人事、財務系システムパッケージ系

MAIL 系システム

発注情報

受注情報

関連企業システム


142

基幹業務の情報共有についてはいくつかの問題がある。

ａ．情報共有範囲を制限すべきかどうか業務担当者が知りうる情報と社長が知りうる情報が同じでよいか、という問いが基幹業務のシ

ステム構築に際して 20年前は話題になった。「中間管理職が事故やトラブルを知る以前に社長が

知るのは問題である」といわれたが、階層化数が減り社長の果たすべき役割も整理され、見たけ

れば社長も生情報は見ることができる企業の方が多い。

ｂ．企業間情報共有の問題

図表 2-2-6 リアルタイム結合

A 社と B 社間で、リアルタイムで発注情報、受注情報が共有されている場合は難しい問題が起

こる。A 社からの発注情報を受け取った B 社は直ちに自動的に販売網に情報を引き渡し、売り先

を見つけ商売が成立するビジネスモデルの場合、大変な事件に巻き込まれる可能性を秘めている。ミスの無い作業は無い。「入力作業が間違っていた」と数秒後に気が付いても、すでに正しい情

報として流され複数顧客に販売取引が完了する可能性がある。たとえば「値段を一桁安く入れ間違えました。販売契約を無効にしてください。」と説得する相

手が複数の場合はこのフォローは大変な負荷になる。顧客によっては無視されることもあり得る。商品が安ければ被害は少ないが、高価でかつ顧客数が多い場合、何百億円の損失につながる可

能性もある。顧客が日常取引を継続している企業である場合は、「すみません、訂正させてくださ

い」で、許してもらえる場合も新規顧客であるならば、冷たい返事が返ってくることを前提にし

たシステムデザインを配慮せねばならない。「リアルタイム結合、複数かつ新規顧客、商品が高価」な場合は、防波堤がない海岸のような

システムになることを認識しておく必要がある。データの訂正方法を議論し、妥当性、回復性のあるシステムデザインをする必要がある。

Ａ社Ｂ社

Ａ社Ｂ社

アクション

（複数顧客に売却、購入手配済）

間違いに

気付いた訂正処理すでに物は流れ始めており、

訂正処理は手作業で

フォローせざるを得ない訂正できない

発注情報

受注済み情報

発注情報

受注済み情報


143

ｃ．基幹業務情報共有化の問題点基幹業務情報の共有で一番問題になってくるのが、「コード」の問題である。電子情報での業務

の受け渡しにおいて、キーになるのは原料であれ、製品であれ「品名」である。これを効率よく、

かつ、的確に行うために、通常、品名をコード化してデータ化する。また、この「コード」は各

企業が各々のルールによって決定しているのが一般的である。同一システムを利用している場合

の共有は、システム上の統一された「コード」をキーにする事ができるので、システム的に情報

を共有する事は比較的容易なことである。しかし、異なる基幹業務情報を共有するとなると様々

な問題点が生じる。これは、同一企業グループ内でも起こりうることであり、ましてや、別法人

間での情報共有においては一層困難な問題点が生じる原因となる。ここでは、海外展開を行っているあるメーカー企業のグループ企業間での基幹業務情報共有へ

の取り組みを検討した際、その構築を断念した例で、その問題点を挙げる。この企業では、基本的に現地スタッフによる業務運営を行っている。また、現地の商習慣に対

応するため、現地法人ごとに基幹業務システムを構築し、また、企業活動が現地語で行われるた

め、そのシステムでは、現地語による品名を用い、独自にコードを設定している。

①コード基幹業務システムを連携するためには、第一にコードの統一が必要となってくる。コードの統

一には、人の判断と手作業が不可欠であり、その作業量は膨大である。また、コードを統一した

としても、そのコード体系によっては、基幹業務システムのデータベース構造までも改修する必

要も生じる。

②言語東南アジア、中国といったところで、地場に密着した業態では、商売は現地語を使用せざるを

得ないため、コードを統一したとしても、現地語対応のため、品名を読み替えるテーブル（デー

タベース）を各国ごとに構築しなければならない。構築後も、そのデータベース維持管理のため

には、コード管理の専門部署を設けなければ、対応ができない。

この企業では、以上のような状況ため、同一グループ間においても、基幹業務情報共有は断念

した。基幹業務情報の共有には、基幹業務システムを統一するか、連携するためのキー項目を統

一するという手段が考えられる。この企業でも検討したが、費用と人手をかければ解決するが、

コストメリットがでないという事で、連結決算システムを別途構築し、各基幹業務システムから

必要小限データ（決算データ）のみを抽出し、集約した。 EDI（Electronic Data Interchange）などによる企業間における基幹業務系の情報の受け渡し

では、システム上でデータの連携をとろうとすると、さらに困難な問題が発生する事になる。必

ず「コード」の読み替えが n 対 n で発生する訳で、規模によっては天文学的なものになってしま

う。現状、EDI と呼ばれている仕掛けも、すべての企業間で情報が共有されているわけではなく、

どこかに必ず人手が介在しているといってよい。


144

（２）顧客情報の共有

顧客との情報共有は多様である。５つの Step に分けて論じる。

Step１：顧客情報の登録固定情報、訪問情報「顧客が何を望んでいるのか。」「顧客に何をすれば評価が上がるのか。注文が増えるのか。」「販売生産性を高めるにはどうしたらよいか。」これらは自社にとって関心のあるテーマである。これらの課題を論じる場合の初のテーマは

顧客の基本情報の登録である。・顧客情報の登録は顧客名、住所、電話番号から始まり、商品の納入先、窓口担当者名などの

固定情報は顧客から頂いた名刺を基に入力されている。悩みは組織名、担当者名が頻繁に変わることである。新情報にしておかないと、失礼な現

象が発生しかねない。個人情報保護法の対象になるデータであり、扱いは慎重にする必要が

ある。限られた人に責任者数人に絞って管理してもらわねばならない。

・顧客への訪問記録を意味のある形にするためには工夫が必要である。営業担当者は、売ることが第一であり、報告はその次になりがちである。毎日数多くの顧客

を訪問しその結果を記入する作業負荷は大きなものである。その成果が自分のものになるの

なら多少の作業負荷はやむを得ないが、誰が読みどのような成果になるのか判らない情報を

入力することには抵抗を感じている。顧客訪問をして微妙な決断を迫られる場合に、営業上司への相談は携帯電話で行われる。携帯電話、携帯メールの扱いが今後の営業マンからの情報収集のキーの一つである。

こうして収集した顧客情報を、優秀な営業はどのように活用し、成績の悪い営業はどのように

利用しているのか。「朝から他の人が入力した営業情報を机に座って眺めている営業に成績の良い営業はいない」

との声をよく聞く。営業情報を読み解くセンスが問われている。後は対人折衝力が決め手になる営業担当者の業務においては、短時間に迅速に情報をキャッ

チして行動に移す能力が問われている。


145

Step２：顧客発注情報を全社（事業部間すべての連携）および関連会社含めて把握

図表 2-2-7 顧客発注情報の例

顧客は大規模なプロジェクトを実施する場合、数多くのベンダーに多くの部品を発注する。「このベンダーが、分社していなければ、1 社にまとめて発注でき管理が楽なのに・・・」と

思いつつも個別の発注先の営業マンに進捗状況などを問い合わせすることになる。発注を引き受けるユーザー企業側は事業部ごとに持っている顧客データベースを参照するが、

他の事業部あるいは関連企業への発注品については簡単に検索できない。「貴社の該当プロジェクトの当社ならびに関連企業への発注品管理はすべてお任せください」

という仕組みを作って、すべての発注をもらっている企業が現れた。関連企業には窓口担当者から「あの企業がこのような商品を必要としている」との情報は当然

流されるので、受注効率の向上にもつながっている。受注情報共有の進んだ例である。

顧客

プロジェクト

Ｘ社

事業部 A

事業部 B

関連企業 C

顧客 DB（ａ）

顧客 DB（ｂ）

事業部 B

関連企業 C

全社顧客

データベース

顧客

プロジェクト

顧客 DB（c）

■既存システム

■新規システム事業部 A


146

Step３：顧客からの注文情報のインターネット受付

営業マンを訪問させて受注を取る、来店してくれたお客に商品を売る方法に加えて、インター

ネットを活用して広い層のお客から注文を受ける方式が始まって数年たった。 JUAS でも、以前はセミナーの案内をダイレクトメールで行っていた。印刷し、折り機にかけ

てたたみ、封筒に入れ郵便局に持って行き郵便料を払い送付する。しかし、案内先は 10％／年程

度変更になるため、配達できない返信の束も相当に厚くなって戻ってくるむなしさを味わってい

た。時間と手間と費用が相当にかかっていた。これを顧客の同意を得て、メール形式に変更したところ、以下の効果があった。 ①手間と費用が画期的に減少した。 ②成功するセミナーと客集めに苦労するセミナーは発信した当日の反応でわかるので、追加対

策が取れるようになり、集客が順調になった。 ③発信から講演の日までの時間的余裕がとれるので、来客に合わせたセミナー内容の調整が可

能になった。 ④セミナーの結果をみて講師の著作物の PR をすると、相当な確率で注文が来るようになった。

一般商品のネット販売では、発注確率（購入者数/メール送付数）は低いが、データベースの顧

客数の一定割合（決して高い比率ではない）は売れる、いわゆるロングテール・ビジネスの成功

話は良く知られるところとなった。ここでの問題はお客にとってインターネット画面操作の難易度である。コンピュータの経験が少ない方でも簡単に入力ができる画面操作のユーザビリティは大切であ

る。入力操作で悩んだときの電話でのオペレーションや FAX でのサポートも重要であるが、使

い勝手の悪い画面を提供しているベンダーに限って上記サポートは貧弱である。

Step４：顧客との直接対話を基に贔屓顧客を増加、新商品への要求をキャッチ一旦商品を購入していただいた顧客をいかに自社ファンとして取り込むかは重要な課題である。単に商品を購入した情報を入力してくれただけでなく、自社商品のモニターになって幅広い質

問に答えていただく、さらに進んで新商品の期待や要求を聞かせていただける贔屓顧客になって

いただくためにインターネットを活用している企業もある。プロダクト志向から消費者志向に変

わるための IT 活用である。

Step５：顧客の顧客からの情報入手「顧客の問題点を探して提案活動をしなさい」と言われても若い SE にとっては難問で何が問

題点なのかはわからないのが普通である。「顧客の顧客は誰ですか」「その方の当社製品に対する問題意識は何ですか」と聞いて回ると自

社製品やサービスの問題が見えてくることは多い。自社、顧客、顧客の顧客、の情報共有まで考えた顧客情報管理にまで至っている企業は少ない

が、今後考えてみる価値はある。


147

以上、5 つの Step に分けて顧客情報共有の課題と対策を整理してみた。まだまだ知恵を働かせ

る場所が多い分野である。（３）フロー情報

フロー情報は一定規模以上の企業においては、ほとんどの企業で活用・普及されている。この普及は、企業の職制の階層化の減少とも関係している。かつての課長、係長は多くの企業

でマネージャーで統一され始めているが、そうなると書類回覧者の数も多くなり、情報が机上に

渋滞し、締切日を過ぎた情報が回覧されることもあった。数多くの従業員に情報が即時伝達され

ることはアクションの迅速化をもたらしている。このフロー情報の流し方にはいくかのタイプがある。

ａ．公示型企業の代表ページ（掲示板）に情報を載せ、「時々見てください」と読む人に促すタイプである。

ｂ．プッシュ型公示型では皆が見てくれたのかどうかは判らないので、メールの形で情報を送り込むタイプで

ある。この情報を読んでくれたのかどうかを確認する仕組みを持つ場合もある。

ｃ．応答型送付した情報に対して返事を要求するのがこのタイプである。ダイレクトメールを印刷し、封

筒に入れ郵便局に持って行き、配達してもらい、読者に記入してもらい、また郵便局経由で戻っ

てきた時間のかかる方法に対して数百分の一の時間で反応が得られる。公示型に応答型を組み合わせ、情報を集める方法もよく使われている。なお、このフロー情報は通常端末以外にも携帯端末を含めて活用する場合もあり、社員は机上

のみならず、どこにいてもフロー情報に触れることができる仕組みを構築している企業もある。事務所が分散している場合でも、国内、海外に出張している場合でも、自宅でも、このフロー

情報が入手できる効果は測り知れない。


148

（４）ストック情報

ａ．作成したドキュメントの共有

企業で作成される資料は、大半がストック情報である。プロジェクトの企画・進捗・実績情報、

顧客への説明資料、契約情報など自社で作成したドキュメントは、データベースに保管されてい

る。この活用を、ここではファイルの蓄積方法を例に分類してみる。

TypeA：社員の作成した資料はすべて各自のパソコンに保管されてあり共有は限られている

TypeB：社員の作成した資料は各自のパソコンに保管されてあるか、共有サーバーに保管されてあり、

共有は限られている

TypeC：社員の作成した資料はすべて共有サーバーに保管されてあり、個人のパソコンにデータを保管

することは許されていない。この問題を皆に確認してみると、意外にも「TypeC」は、限られた数社でしか実施されていな

かった。この方式では情報共有以外にもいくつかのメリットをもたらしてくれる。「資料を作成すると

同時に、個人のパソコン内でなく、サーバーに保管する」ことでパソコンの盗難による情報の流

出を防ぐ効果があり、また、破損によるデータ損失の危険などが減ることが、TypeC の良さであ

る。そのため、現在はセキュリティを特に気にする機密情報を多く持つ企業が TypeC を推進する

傾向にある。この方式の弱点は、パソコンとサーバー間の伝送速度の遅さにあるが、ここ数年は、回線速度

のスピードが速くなる傾向にあり、保存時にストレスを感じることは少なくなっている。特に、

社内 LAN に置いての回線スピードは大容量のファイルを送る場合にストレスを感じることもほ

とんどなくなっているはずである。ｂ．ファイルの検索方式

ここでは、ファイルの検索はどのような方法があるのかを、いくつかの Type に分類してみる。

時代を経るに従って、大きく Type１→Type2→Type3 と検索方式は変わってきた。

Type１：フォルダ名による検索フォルダを作成して、その中に部署・業務内容ごとにフォルダを作成し、格納する際に意識し

て入れる。ユーザーは、ディレクトリを辿ることで、目的のファイルを探し出す。インターネッ

トで言えば、Yahoo!のディレクトリ検索である。人の手で分類してファイルを格納するため、徐々

にフォルダの構成が崩れる場合が多い。また、似たようなファイルが複数あるが、どれがも新


149

しいファイルなのかを探すことが難しいと言う難点がある。探しているファイルが求めるものな

のかどうかは、ファイルを開いて中を見るまで分からない場合も多い。

Type２：属性情報での検索属性情報は、作成した文章、図表とは別に、あらかじめキーワードを作成者が抽出、登録をす

る方式。全文検索が発達する前は、大半がこの方式であった。特に、文書管理ソフトでは、この

ような方式をとることが多かった。この方式の欠点は、保管時にユーザーが自分で文書の属性を付与すると言う手間がかかること

である。ユーザーが属性情報の付与や、ファイルの登録を嫌がる。そのため、充分な情報が集ま

らなくなり、ツールの導入をしただけで終わるといったことが多かった。

Type３：全文検索エンジンを利用作成された文章を基に全文を解析してインデックスを作っておくことで、ユーザーの検索要求

に応える。Google の検索窓を、社内のファイルサーバーに応用したと考えるとよい。ユーザーが

自由に検索のキーワードを指定してファイルサーバーの中のファイルを検索することが出来る。

以前は、テキスト系のみが検索可能で PDF や PowerPoint の中身を検索することが出来ないもの

が多かったが、現在はほとんどのツールで PDF まで検索できるようになっている。全文検索エンジンの利点としては、ユーザーがキーワードを登録する手間が省ける点が挙げら

れる。ただ単にファイルサーバーに資料を格納するだけで検索対象とすることが出来、ツールに

よってはアクセス権の制御を行う事が出来るなど、細かな設定を行う事もできる。事前にインデ

ックスを作っているため、要求に対してすばやく回答をすることができる。全文検索エンジンの現在の問題点はユーザーの言葉のゆらぎを吸収できない場合があることで

ある。言葉のゆらぎにも、色々なレベルのものがあり、現在解決できているものから解決するこ

とが難しいものまである。ひらがなとカタカナを同一のものとして見る事や、「ユーザー」と「ユ

ーザ」を同一の単語として検索する事は比較的簡単に解決できる。だが、「カフェ」と「喫茶店」

を同じ言葉として検索する事は難しい。だが、ユーザーは、「カフェ」で検索していた場合であっ

ても、「喫茶店」の結果が同時に表示される事を望んでいる場合がある。これを解決するためには、

「カフェ」と「喫茶店」を同じ意味であるというシソーラス（同義語辞書）を事前に作成する必

要がある。だが、このように同じ意味を持つ単語は多数あり、我々が使用する言葉それ自体も日々

増えているため、辞書のメンテナンスを随時行う必要が出てくる。また、検索結果を「カフェ」

「喫茶店」と自力で入れることで解決できるが、システムの習熟度が低い場合や、同義語をユー

ザーが推測できない場合には目的とするファイルを発見できない。


150

図表 2-2-8 ファイル検索方式の利点と問題点

検索方法利点問題点

Type１フォルダ名による検索特別なツール導入の必

要がない

ファイルの内容で検索が出来

ない

ファイルを探し出すまでに時

間がかかる

Type2 属性情報での検索属性情報を基にファイル

の検索が行える

属性情報を付与する手間が

かかる

Type3 全文検索エンジンフリーワードでファイルの

中を検索できる

利用者が求めるファイル

にたどり着きやすい

方式によっては、同義語を検

索できない

探し出したファイル自体の信

頼性がわからない

ｃ．ストック情報の活用における問題点

企業のファイルサーバーの問題点として、情報過多と、情報の信頼性と、情報の鮮度の問題が

ある。ストック情報を活用できないときには、この 3 つの問題がある場合が多い。

①情報過多格納されたファイルが多すぎると、何がどこにあるかわからないと言う問題である。これは、

属性情報を検索する文書管理ツールや全文検索エンジンを入れることで解決できる。これ以降は、

何らかの検索ツールが導入されている事を前提に問題点を記載する。

②情報の鮮度検索されたファイルが新の情報であるかどうかという問題である。1 年以上前に作られたフ

ァイルが発見された場合、それの資料がそのまま使えるのかどうかは分からない。これは、次に

説明する情報信頼性とも関係してくる問題である。

③情報の信頼性ファイルサーバーから発見されたファイルに書かれている情報が正しいかどうかが分からない

ために使えないといったことが良くある。これは、書かれている情報の背景がどうなっているか

が分からないためである。ここでは、システムの提案書を例にとると、提案書を作成する場合に

は書かれた背景があり、そのときどきの環境や特別事情が入っている。だが、ファイルにはそれ

らの情報は記載されていないので、せっかくファイルサーバーで検索して使えそうなファイルを

発見してきたとしても特別な事情があるのかどうかが分からないために利用できない。これらの問題を解決するための方法としては、ファイルサーバーへの格納時に、背景情報など

を付加して、発見すれば即使えるようにする方法がある。この方法は手間とコストがかかるため、

行っている企業はごくわずかである。より現実的な方法としては、検索して発見したファイルを、

ファイルのプロパティ等から作成者を調べ、ファイルの作成者に聞きに行く方法である。ファイ

ルサーバーの利用者が少なく、顔見知りであればこの方法がとられることも多い。常にファイル

のプロパティから作成者が分かれば良いが、作成者が退職している場合や、プロパティ等も分か

らないために作成者が見つからない場合も多い。


151

ｄ．インターネットからの情報収集

現在では、ほとんどの企業がインターネットを利用できる環境にあり、インターネットからの

情報収集を行う機会も増えている。取引先の信用確認のための情報収集や、マーケティング活動

など、様々な用途でインターネットから情報収集を行っている。今までのインターネットの活用は情報収集と IR・製品情報の提供がメインで使われることが多

かった。今後は、インターネットでの双方向の情報のやり取りが増えていくと考えられる。ブロ

グなどのクチコミを使った双方向の情報のやり取りも拡大する。ネットを利用して社外の人間と

ディスカッションを行う事も増えると考えられる。ベンチャー企業などでは、知識の移転をイン

ターネット上の見知らぬ他人と行う事で情報効率を高める傾向が見られている。だが、これを大

企業で行う場合には、企業情報が外部に漏洩する危険も増えるので、セキュリティについての考

慮が必要となってくる。だが、インターネットに社員の PC が繋がっている以上、それを完全に

防ぐことは難しい。また、社外との情報交換を制限することで個人の知識が硬直化して、競争力

を下げる可能性も出てくる。この節では、ファイルサーバーと検索ツールを中心にストック情報の説明を行ってきた。だが、

ブログや SNS 等のインターネットを企業内システムに応用する事例も徐々に増えているため、

今後はファイルサーバーだけでなく、ブログや SNS 等を情報共有のベースとして検討する必要

がでてくる。

（５）Know-Who 情報

そもそも Know-Who 情報とは何か。またその特徴は何だろうか。前に出た基幹情報、顧客情

報、フロー情報、ストック情報とは性格が異なっていることに着目せねばならない。ストック情報、フロー情報は「形式知」であるのに対し、Know-Who 情報は情報そのものとい

うより「暗黙知へのリード」である。つまり Know-Who とは、「形式知を手がかりにして知識・情報を持っているライトパーソンに

たどり着き、その人の暗黙知を引き出す」ためのものである。したがって Know-Who のポイントは下記の 2 点である。 ①いかにして「手がかりになる形式知」を扱うか ②いかにして「引き出しやすく」するか具体的に企業内の情報から Know-Who 情報を入手する方法について考察する。

方法１：人事情報の活用社内には人事情報が蓄積されている。各自の経歴、経験を検索して情報を得る方法である。一番簡単な方法ではあるが、個人情報の保護の観点から公開されている企業は少ない。この方法を活用しようと思えば、人事担当者に依頼して人事情報データベースを検索してもら

い、問題がない範囲で問合せ者に回答が渡ることになる。一般的は活用が難しい方法である。

./keyword.htm#2601

./keyword.htm#3401


152

方法２：ストック情報の検索

過去のプロジェクトの情報が蓄積されてあり、社内で情報活用が可能であれば、キーワードで

該当プロジェクトを探しだし、そこから経験者名を探し出す方法である。担当者の名前だけでなく、経験内容も入手できるので、効率的である。この仕組みの基であるストック情報の蓄積が検索可能な状態で、整備されているかどうかが有

効結果の入手程度と関係してくる。

方法３：社内関係者会議の議事録を検索通常社内では、類似プロジェクトの関係者会議、関係組織の連絡会議などが持たれているケー

スが多い。その関係者の中から有識者をたどっていけば、真に有効な情報提供者を見つけ出すこ

とが出来る。コンピュータを使わなくても、たどり着くことは可能であるが、他の方法と兼ね合わせてこの

方法を活用する場合は、やはり議事録などの検索が可能である方が迅速に結果にたどり着ける。

方法４：Q&A コミュニティ掲示板を活用手がかりとしてよいのは「方法 4：（掲示板）」の活用である。「何かヒントを得たい」と望む場合は、掲示板の利用も考えられる。「私はこんな問題で悩んでいます。何かヒントをいただけませんか」と掲示板に書き込み全社

から情報提供を求める方法である。読み手が真の有識者であるかどうかの問題はあるが、この方法で何か手がかりを掴んだ人も多

い。社員の数も多く、かつ全世界に関係者が散在している場合に、この方法は有効である。質問して回答を求める形なので、ピンポイントでほしい情報そのものを得られる可能性が高い。

裏返して言えば、情報提供側のコストも極小である（聞かれたことに答えるだけでよいので、事

前に誰が使うかわからない資料を作ったりする手間がない）。ただし掲示板はグルーピングされてある、あるいは掲示板から要望者、提供者を問題ごとに簡

単に選び出す方法の支援など知恵とツールが必要となる。

方法５：ストック情報／フロー情報の発信履歴をベースにした動的 Know-Who 情報の活用ストック情報／フロー情報（＝形式知）の発信履歴を人単位で集約することにより、その人が

「どんな情報を発信した人なのか＝どんな暗黙知を頭の中に保有している可能性が高いのか」を

高い確率で予測することができるこのように、様々な Know-Who 情報の入手方法があるが、万全策はない。問題点と対策をま

とめてみる。


153

問題１：求める情報の質の問題

情報を求める人の欲しい情報がデータベースに入っていないことがある。一般に商品開発情報、技術情報などの登録をする場合は、きれいに整理された成功情報が登録

される。失敗情報の登録はしたがらないし、始めたらきりがない。したがって「このようなこと

に注意して作業に、あるいは研究に取り掛かってください」等の情報までデータベースから入手

しようと望む方が期待過剰であると主張される人も多い。この問題の奥は深い。プロジェクトの成功者に「プロジェクトの成功要因は何ですか」と質問

すると、優秀なプロジェクトリーダーほど「何も特別なことはしてはいません。標準書通りにし

ただけです」との回答が多い。注意事項には一定の基準がある。したがって一般の未経験者の欲しい注意情報を得ることはできない。成功者と面と向き合って対話して必要情報を得るしか手はない。すべてをコンピュータに頼ら

ない柔軟な姿勢が要求される。

問題２：求める情報の対象者、範囲の問題小企業でかつ職場数は限られている場合は、関係者も少ないし、わざわざデータベースを検索

するまでも無く、誰が関係情報を持っているかは分っている。大企業でかつ職場が全世界にわたっている場合などは、同一課題の関係者の名前さえ判らない

場合がある。また求めたい情報の所持者が、自社だけではなく関係会社の有識者が持っている場

合もある。全社の総知を集める工夫、関係会社含めての有識者から情報を集める工夫、大学など

一般から求める工夫などまだまだ研究・改善の余地は多い。

問題３：情報提供者の評価の問題自分の経験を有効活用してくれる可能性があることは、分ったとしても、そのために貴重かつ

多大な時間を割いてよいのかは気になるところである。社長が旗を振り、そのような情報提供の振興を唱え、情報共有の企業文化を奨励している企業

がある。有効情報提供者にはそれなりの評価も与える仕組みを作成している会社もあるがまだ少

数派である。

問題４：信頼関係の構築暗黙知が引き出されやすくするカギは「信頼関係」にある。「自分の頭の中にある暗黙知を同僚

に提供してもよい」と思うかどうかは、結局のところ同僚（あるいはその集合体であるところの

会社）との信頼関係があるかどうか、にかかっている。「企業文化」「社風」の問題でもあるが、

－もっと小規模なレベルでも信頼関係を成立させることも十分可能である。たとえば「場」の設定、制度化、社長など上司の奨励、貢献度の見える化、など。－金銭的あるいは人事的なインセンティブも一定の効果はあるが、も強力なのは「同僚からの認知」である。信頼関係が構築できない状態では、Know-Who を活かすのはかなり難しいと言ってよい。


154

たとえば、－自分の専門性を公開したら質問が殺到するのは困る、と思っていたり、－モノ言えば唇寒し、的な社風であったり、－積極的に暗黙知を提供したら「あいつはヒマだからね」と思われそうだったり、そうした「信頼関係」の欠けた状況では厳しい。

問題５：情報検索技術の問題「この問題を解きたい」と思ってパソコンに向かってキーワードを入力しても、検索時間に手

間取り、必要情報がなかなか入手できなければ結局諦められて活用されなくなる。近年、情報の

量は膨大化しているが、登録技術と検索技術が進歩したこと、情報を蓄えるディスクが安価・高

速化したこと等の影響でこの問題は大きく改善しつつある。むしろ、経験のある SE 含めて、この情報検索技術の発展レベルを正しく理解していないこと

の問題の方が大きいように思われる。まだまだ情報共有は進む可能性を秘めている。


155

３．企業の情報共有ベストプラクティス

───企業における情報共有の考え方と実践へ向けての流れ

一橋大学大学院の野中郁次郎教授と竹内弘高教授は『The Knowledge-Creating Company』（オッ

クスフォード大学出版／1995 年）において、「組織における知識創造（ナレッジクリエイション）」、

そして「知識創造プロセスのマネジメント」を提唱した。その中で、野中、竹内両教授は、企業組織

にとって知識の“処理”ではなく、“創造”の重要性を指摘し、「知識の創造」によって優れた業績を

あげている企業がどのようにして組織的知識を生み出しているかを説明するため、組織的知識創造理

論がまとめられた。この理論では、知識には暗黙知と形式知の 2 つがあり、それを個人・集団・組織

の間で、相互に絶え間なく変換・移転することによって新たな知識が創造されると示されている。こ

うした暗黙知と形式知の交換と知識移転のプロセスを示すのが、SECI モデル（図表 2-2-9）である。

図表 2-2-9 SECI モデル

2000 年代に入ると、「知の創造」と言えよう企業において SECI モデルを実践するに当たっての具

体的方法論も論ぜられるようになってきた。トーマス・Ｈ・ダベンポート、ローレンス・プルザック

は「ワーキングナレッジ」において、企業を取り巻く様々な情報を、知として取り入れ、分類・分析・

連結を繰り返し、企業戦略・戦術策定に活かしていくための具体論を示した（次に記す）。

・知識への貢献に基づいて報償を与えるインセンティブ構造。・経営陣が知識行動の例を示すことができること。・知識に基づいて、決定事項や意志決定を評価する。・知識の共有や知識の活用に対して表彰あるいは報償を与える。等々

ヘイム・メンデルソン、ヨハネス・ジーグラーは「スマートカンパニー（副題：e ビジネス時代の

覇者の条件）」において、「組織 IQ」という情報の取り入れ方や意思決定の仕組み、情報共有化の仕組

みを基に、企業の能力を定量化して表す尺度を示し、具体例を上げ、組織 IQ が高い企業と低い企業

では成長率や収益性に明確な差が出ることを示した。自社の情報能力を定量的に測ることで改善点を

./keyword.htm#1902

./keyword.htm#2201

./keyword.htm#3401


156

見出す指針が示された点で、情報戦略策定の具体的展開が示された。また、それぞれの著書では、企

業活動における情報共有・活用には IT の活用が欠かせないことも強調されている。 2003 年頃になると、情報共有・活用を実践するためには、使う人の意識改革や企業文化の変革が必

要であり、その改革のための実例も数多く紹介されるようになってきた。IT ツールの導入だけではな

く、人の果たす役割が情報共有・活用においては重要であることが認識されてきた（KM World2004、KM World2005 カンファレンス）。

その中の一例を紹介する。暗黙知を形式知に変換する手法として、シャドーイングという手法も紹

介されていた。形式知化にあたって、実務者個々人が形式知化するのではなく、形式知化専門メンバ

ーが実務者に影のように寄り添い、業務分析を行うと同時に、Know-Why（何故その業務を行うのか）

に裏付けられた Know-How（どうその業務を行うのか）を Know-Why とともに形式知化するもので

ある。このように、IT ツールだけでは解決できない点を、本質的に補う手法が明示されるようになっ

てきた。また、日本における情報共有・活用との大きな違いは、情報管理専門職が確立されている点にある。

特に、司書（Librarian）が単なる図書管理者から、図書情報の電子化に伴い、データベース管理者と

しての地位を確立し、情報共有・活用において重要な地位を築いている点にある。後述するが、情報

共有・活用を実践している企業においては、この Librarian の役割をもった職務を配置し、ビジネス

プロセスの中に組み入れて実践していることも注目すべき点だと考える。このように、人による情報共有・活用の推進方法がカンファレンスで紹介されるというのは、米国

における情報共有・活用において、IT ツール導入だけではうまく実践されないという証といえよう。


157

（１）日本企業における情報共有と情報活用の実態

日本企業における情報共有・活用はどのように進展してきただろうか。 1990 年代半ばより、IT ベンダー各社から「情報共有」や「Knowledge Management（KM）」

といったキーワードによる「知の創造」を実践するソリューションとして、グループウェアやナ

レッジベースツールの提案がなされた。先にも述べたように、2000 年代になると企業力の源泉に

「人」「金」「物」に「情報」を加えた経営理論も紹介されるようになり、「情報共有による企業力

強化」といったコピーが世の中で数多く目にするようになってきた。企業においても、業務効率

化のために活用されてきた IT を、業務の質を向上させ企業競争力強化のために用いることを検

討し始めた。研究開発部門における実験データの共有による研究開発の迅速化、製造部門における製造ノウ

ハウ共有による製造技術の伝承、営業部門における情報共有による営業力強化等を目指し、各企

業が様々な形で情報共有に取り組んできた。しかし、真に「情報共有」を実現し、企業競争力を高められた企業は少ないのではないだろう

か。各企業の取り組み実例を元に、日本企業の「情報共有」への取り組み実態と問題点を分析し、

「情報共有」「情報活用」のあるべき姿を検討する。検討に当たっては、SECI モデルを元にした「知のスパイラル」を図式したもの（図表 2-2-8）

を一つの指標を用いる。

図表 2-2-10 知のスパイラル

この図の説明を記す。知のスパイラルの実践には、次の 4 つのステップに分けて考える。

./keyword.htm#1902


158

①暗黙知から形式知への変換

暗黙知を形式知に変換するに当たっては、暗黙知の所有者（人）が表出化を意識することが必

要となる。（前述のシャドーイングは、暗黙知の所有者の意識によらない形式知化の手法一つ）ま

た、IT ツールの活用に結びつけるために、当然形式知を電子データ化することも必要となる。

②形式知の蓄積電子化された情報を蓄積するファイルサーバーやデータベースサーバーが必要となる。

③形式知の選択

蓄積された情報をサーバーから効率よく抽出するためには、目的に応じた検索エンジンが必要

となる。ただし、検索エンジンを使いこなすためには、利用者が目的の情報に辿り着くための検

索条件等を考えることが必要となる。

④形式知から新たな知（暗黙知）の創造様々な情報の中から得られた情報から新たな知を生み出すのは、人間の思考力である。 ①の段階をクリアするためには人の意識が重要であり、②をクリアするためには、電子化され

た情報を効率よく蓄積する仕掛けが必要となる。③をクリアするためには、蓄積された情報から

必要な情報を的確に抽出する仕掛けが必要となる。④の段階では、抽出された情報を組み合わせ

新たな知を生み出す人間の思考が必要不可欠となる。それぞれの壁を乗り越えるために、人の意識や IT ツールの場面に応じた活用が重要となる。

そのステップごとに、活用する仕掛けが異なることから、各ステップをクリアする際には、それ

ぞれ障壁があると考える。 JUAS 情報共有研究会等で得られた各企業における「情報共有・活用」の取り組み事例を、「知

のスパイラル」に当てはめ、その達成度と各ステップをクリアする際に用いた手法、乗り越えら

れずに停滞している理由等について記述する。また、JUAS の情報共有に関する調査（この章の第 1 節の「２．情報共有の実態」を参照）の

際に、共有すべき情報を ①業務系情報：在庫・生産等 ②フロー情報：業務連絡、通知通達等 ③ストック情報：文書、レポート、資料等 ④知識・ノウハウに分類しその共有の必要性を問うている。ここでは、さらに「顧客の情報」を加え、それぞれ

の企業で共有情報についても、その種類と活用度合いも併せて記載する。

./keyword.htm#5201


159

（２）情報共有の事例紹介

ａ．素材メーカーＡ社（B to B）：営業・技術部門における情報共有

図表 2-2-11 情報共有・活用取り組み事例（A 社）

この企業では、営業部門と技術部門における情報共有への取り組みと実践するに当たっての問

題点と対応についてヒアリングを実施した。この企業は、営業力強化を目的に SFA（Sales Force Automation）を導入し、営業情報の共有

を目指している。しかし、営業現場において、SFA 導入までは口頭による報・連・相（報告・連

絡・相談）が主流で、営業情報を蓄積する習慣がなかった。そのため、SFA 導入後も、情報登録

がなかなか定着していない。情報共有の意義・必要性は理解されているが、営業活動に情報共有

をどのように役立てるか具体策が示されないため、情報共有が進展しない。

図表 2-2-12 種類別活用度合い（A 社・営業部門）

蓄積検索思考

1．基幹業務情報 ○ －－

2．顧客の情報 △ ○ －

3．フロー情報

（業務連絡、事項通知等） ○ △ －

4．ストック情報（プロジェクト情報、レポ

ート等）－－－

5．Know-Who －－－

営業部門（SFA）

技術部門：研究

報告、出張報告

などを共有。


160

入力を促進する人的サポートを行っているが、サポート直後は入力が増えるがしばらく経つと

入力が減少するとのこと。ただし、マネージャーの情報活用の意識がしっかりしている部署では、

ある程度入力が定着しているとのこと。顧客から得られる製品情報（評価等）や他社動向は、営

業戦略策定に極めて重要であるという認識はあるのだが、属人化しており、営業個人の能力に頼

っている感あり。今まで、営業力が強いと言われていた企業にこういった傾向が強いように思え

る。これは、今後、各企業からのヒアリングやアンケート調査などで明らかにできたらと考える。一方、技術部門では、ISO9000 を取得していることもあり、研究報告書をはじめ様々な報告の

文書化には抵抗がない。しかし、蓄積された報告書が再利用されることがほとんどないとのこと

である。図表 2-2-13 種類別活用度合い（A 社・技術部門）

蓄積検索思考


2．顧客の情報－－－

3．フロー情報

（業務連絡、事項通知等） ○ △ －

4．ストック情報（プロジェクト

情報、レポート等） ○ ○ △


研究開発部門では、トライ＆エラーで得られたデータが共有されると役立つということだが、

報告書にはうまくいったデータしかなく役に立つことが少ないとのこと。しかし、エラー部分を

残すことに研究者は抵抗感があるとのこと。そのため、本来必要とされる情報が表出化されない。

研究者の意識によるところが大きく、この問題点を打破する方策はまだ見つかっていない。さら

に、アイディアレベルの情報も表出化（共有化）されず、企業が持っているシーズの把握ができ

ていないという問題も抱えているとのことであった。


161

ｂ．部品メーカーＢ社（B to B）：営業情報の共有

図表 2-2-14 情報共有・活用取り組み事例（B 社）

この企業では、営業部門における情報共有の取り組みと問題点とその対応についてヒアリング

を実施した。この企業は、営業部門においてグローバルに SFA を導入し、営業報告を共有化している。日本

においては、日本語。海外においては、英語で登録されている。入力にあたって、当初システム

の機能不備を理由に入力が進まなかった。ユーザサイドから出されたシステム要望（機能不備）

をすべて改修し、入力しない言い訳を排除した上で、経営トップが入力を促し、入力されるよう

になった。ただし、追加改修した機能は、ほとんど使われないとのこと。新しい業務への抵抗か

らの要求であったようだというのが、システム担当者の声。システム展開にあたっては、専任サ

ポート部隊を作り、全営業拠点を巡回し、SFA 導入の意義と操作教育を徹底的に実施した。入力される報告は、一つの案件がクロージングしてからの報告で、途中経過における報告は口

頭で行われている。そのため、タイムリーな情報共有には至っていない。また、検索においては、

クロスランゲージ検索エンジン（日本語で検索しても日本語だけでなく英語コンテンツも検索さ

れる）がなく、蓄積情報を新しい知の創造にまで活かしきれない。今後は、いかにタイムリーな

情報を提供できる仕掛けにすることとクロスランゲージ検索エンジンの搭載が大きな課題となっ

ている。

ユーザーからのシ

ステム改修要望に

すべて応え、経営

トップの後押しも

得て、入力促進

（形式知化）。

グローバル

に営業情報

を共有。


162

図表 2-2-15 種類別活用度合い（B 社）

蓄積検索思考

1．基幹業務情報 ○ ○ －

2．顧客の情報 ○ ○ △

3．フロー情報

（業務連絡、事項通知等） ○ ○ －


情報、レポート等） ○ ○ －


この企業は、上記の表のように様々な情報を共有する環境にはあるが、なかなか活用するに至

らないとのこと。その理由は、蓄積情報が玉石混交であり、必要な情報になかなか到達できない

ためとのこと。この企業は、情報の蓄積は進んでいるが、情報洪水に陥っている一例と言えよう。

今後の課題として、IT ツールだけでなく、「人」の配置も含めたコンテンツマネジメント機能の

充実が挙げられていた。

ｃ．素材メーカーＣ社（B to B、B to C）：ホワイトカラー生産性向上→情報活用推進活動→マルチコミュニケーション

図表 2-2-16 情報共有・活用取り組み事例（C 社）

1990 年代中頃から第

1 ステップとして、情報

活用で業務効率向上

を図り、情報が業務に

役立つことを体感させ

た。

2000 年代になると、業務の効

率化から、情報を経営・事業

に活用をめざし、文書DBの構

築をおこない、新しい価値創

造への取り組みを開始した。

現在は、更なる情

報活用を目指し、マ

ルチコミュニケーシ

ョンによる、社内活

性化に取り組んでいる。


163

この企業では、情報化をキーワードにした IT 活用への取り組みについてヒアリングを実施し

た。ここでは、情報共有を企業力強化につなげる取り組みをクローズアップして記述する。この企業は、1990 年代中ごろより、ホワイトカラーの生産性向上を目的に、情報化に取り組み

はじめてきた。その段階で、すでに新しいビジネスモデルの実現ということで、段階的な情報活

用への取り組みを実施してきた。第１ステップとして、情報活用による生産性向上＝業務効率化を実現し、情報が役に立つこと

を社員に実感させるとともに、情報化推進体制を確立し、情報利用スキルの向上を図った。第２ステップとして、従業員自らが業務分析を行い、情報を活用できていないことによる問題

を洗い出し、情報活用による問題解決方法を導き出した。同時に、経営陣による情報化推進行い、

経営・事業に情報を活用する会社方針を徹底。現在は、組織の全方位に向けたコミュニケーション（マルチコミュニケーション）と情報共有

の強化・徹底にむけ全社運動を展開し、新たな社風喚起を目指している。全社員に必要な情報を的確に伝え（push 情報）、業務推進には全社一体となって取り組む姿勢

を育むとともに、必要とする情報（pull 情報）に容易にたどり着く仕掛けも用意し、業務の効率

化も損なわず「情報共有」を実現している。

図表 2-2-17 種類別活用度合い（C 社）

蓄積検索思考

1．基幹業務情報 ○ ○ ○

2．顧客の情報 ○ ○ ○

3．フロー情報

（業務連絡、事項通知等） ○ ○ ○


情報、レポート等） ○ ○ △

5．Know-Who ○ ○ △

情報の重要性にいち早く気が付き、情報共有・活用による企業力アップの青写真が 1990 年中

頃には描かれていた。そのため、いきなり「情報共有」という大上段に構えたところからアプロ

ーチせず、情報共有を業務効率化からアプローチし、従業員が情報の重要性を認識し、必要な情

報は何か、それをどう使うかを見出し、情報を業務に活かすところまで自らの手で引き上げた見

本となるような企業である。地道に情報共有・活用に取り組んできた結果が生んだ成功例といえ

よう。同じような取り組み方をしている企業も多々あるとは思うが、このような成功事例はなか

なかないのではないだろうか。この成功は、情報共有への取り組み方だけではなく、この企業の

持っている「企業文化」によるところも大きいと考えられる。


164

ｄ．一般消費財メーカーＤ社（B to C）：顧客情報の共有化

図表 2-2-18 情報共有・活用取り組み事例（D 社）

この企業の実例は、顧客と企業との情報共有の一例として、ヒアリングを実施した。メーカー

にとって、顧客の声は宝の山である。先の 2 例（B to B）の企業に比べ、一般消費財メーカーの

場合は、コールセンターやホームページ等、様々な方法で顧客の声を直接形式知として集め易い。

とはいえ、この企業では、その情報を迅速かつ的確に社内で共有し、新製品開発につなげている。

そして、市場に投入した製品に対する顧客の声を、次の新製品・新市場開拓への「知」を生み出

し、「知のスパイラル」が澱みなく回っている。情報鮮度の管理もしっかりしており、また、情報

を活かすために最適な IT ツールを積極的に活用している良い例である。

図表 2-2-19 種類別活用度合い（D 社）

蓄積検索思考

1．基幹業務情報

2．顧客の情報 ○ ○ ○

3．フロー情報

（業務連絡、事項通知等）


情報、レポート等）

5．Know-Who

顧客の声を電子化蓄積＆分析ニーズに裏付けら

れた新製品を開

発し、市場に投入

./keyword.htm#3401


165

事例紹介を聞いていると、いとも簡単に情報を活用しているように見えるが、情報の生み出す

価値の重要性を経営陣から一従業員まで全員が理解し、意識しているから実現できる。脈々と語

り継がれてきた経営者の思いが、情報を有効に活用する企業風土を育んだと感じられた。このよ

うな企業風土こそ、どんな IT ツールよりも、情報共有には欠くことのできないものであろう。

ｅ．素材メーカーＥ社（B to B）：業務別情報共有・活用への取り組み

図表 2-2-20 情報共有・活用取り組み事例（E 社）

この企業では、業務機能別に取り組んでいる情報共有についてのヒアリングを実施した。この企業は、経営課題解決に情報共有は欠かせないとのスタンスで、生産業務・スタッフ業務・

意思決定それぞれの業務に即した形での情報共有に取り組んでいる。

生産業務：業務遂行上、注文情報・在庫情報・納期情報等をラインで共有しないと効率的かつ迅速な生産

ができない。必然的に情報共有が進み、更なる効率化のために、情報に裏付けされた PDCA（Plan Do Check Action）サイクルが実現している。

スタッフ業務：

本来であれば、情報を知に変え、ビジネスチャンスを創出する部門ではあるが、「知」が属人化

されている部分が多く、情報共有までは進むが「知のスパイラル」が回るところまではいかない。

また、情報流通は活発なため情報洪水にさらされており、検索エンジンの整備等が課題となって

いる。

生産業務：情報活用による PDCA サイクルが実現

スタッフ業務：情報が属人化しがち

意思決定：共有すべき情報の分類が課題

./keyword.htm#1601


166

意思決定：

情報に裏付けられた迅速な PDCA サイクルが必要不可欠だが、レイヤーごとに必要とされる情

報が異なるため、共有すべき情報の分類により、一層の効果を上げるための方策を検討中とのこ

と。図表 2-2-21 種類別活用度合い（E 社）

蓄積検索思考

1．基幹業務情報 ○ △ △

2．顧客の情報 ○ △ △

3．フロー情報



情報、レポート等） ○ △ △

5．Know-Who

この企業は、情報動線分析も実施し、情報のあるべき姿を描き出している。情報共有のあるべ

き姿、共有すべき情報といった視点を持って、「情報共有・活用」に取り組んでいる。まだ、道半

ばとの話であったが、「情報共有」へのアプローチとして参考になる企業の一つと感じた。


167

ｆ．エネルギーＦ社：

図表 2-2-22 情報共有・活用取り組み事例（F 社）

この企業では、全般的情報共有への取り組みと今後の課題についてヒアリングを実施した。この企業の、情報共有の取り組みは、全社規模での経営情報の提供から始まり、各部門からの

情報発信を実施し、これをポータル機能で統合してきた。このツールは、情報発信のみでレポー

ティング機能を有せず、一方通行の情報共有となっている。もう一つのツールとして、情報シス

テム部門が企業内に蓄積された図形情報の管理システムを構築した。その後、そのシステムを文

書管理システムとして提供されたが、運用は、各部門に任されているとの事である。現実は、蓄

積されるだけで、活用するまでには至っていない。

図表 2-2-23 種類別活用度合い（F 社）

蓄積検索思考


2．顧客の情報 ○ －－

3．フロー情報

（業務連絡、事項通知等） ○ －－


情報、レポート等） ○ －－

5．Know-Who

IT インフラは、情

報システム部門、

活用は、各部門に

任されている。

情報は各部門から

のプッシュ情報文書管理

システムで

の情報蓄

積


168

この企業は、情報システム部門がツールを提供し、その使い方をユーザー部門が考えるという、

従来の情報システム部門とユーザーとの業務分掌の良い例といえよう。単に業務効率化を考える

システムを構築する際には、手作業をいかにシステムに置き換えるかを考えればよい。しかし、

「情報」を活用するシステムとなると、単にシステム機能の追求だけではなく、どんな情報をど

のように活用するのかというビジネスプロセスを十分に把握する必要がある。システムの機能追

求だけではなく、そのユーザーがどのようにシステムを使うかまでも検討しなければならない。

すなわち、IT で経営方針の実践を具現化するためには、情報システム部門は、経営企画部門やユ

ーザー部門と密接に連携できなければならないと言えよう。とはいえ、暗黙知を形式知化するという第 1 の壁を越えられない企業に比較すると、情報の形

式知化はできているといえる。したがって、コンテンツマネジメントと検索ツールなどの IT ツ

ールの提供で、一気に「知のスパイラル」が動き出す可能性を持った企業ともいえよう。ｇ．運輸サービス G 社（B to C）：全社情報共有方針と考え方

図表 2-2-24 情報共有・活用取り組み事例（G 社）

この企業では、情報共有による顧客満足度のアップを目指した取り組み実例をヒアリングした。この企業では、情報共有を会社・業務・コミュニティの三つの切り口で考え、実践している。

具体的には、経営管理や人事労務管理上必要な情報群（会社）、特定業務に必要な業務連絡や顧客

情報等の情報群（業務）、ボトムアップによる業務改善を促す情報群（コミュニティ）に分け、そ

れぞれに必要なツールを提供している。特に、顧客満足度アップを意識したものが、業務機能別のツールである。ここでは、業務別に

特化した情報の提供と、それぞれの業務の立場で接する顧客の声を詳細に登録し、全部門で共有

している。

./keyword.htm#3502


169

図表 2-2-25 種類別活用度合い（G 社）

蓄積検索思考

1．基幹業務情報 ○ ○ ○

2．顧客の情報 ○ ○ ○

3．フロー情報



情報、レポート等） ○ ○ ○


この企業の情報共有での特徴の一つに、顧客情報（顧客の声）の分析にある。業務分野ごとに

収集された情報を、業務分野の異なる社員の目から分析を実施する。より顧客視点に近く立って

の分析である。その際、登録された情報は、テキストマイニングツールなどを使用せず、人の感

性を重要視し、あらゆる業務分野の人の手によって分析を実施している。この中から、課題を抽

出し、その課題解決によって、顧客満足度アップにつなげている。IT と「人」のコラボレーショ

ンによって、情報価値を生み出している良い一例である。情報活用には、ツールだけでは解決で

きない課題があることを示唆しているとも言えよう。

ｈ．小売業Ｈ社（B to C）：本社機構と販売拠点の情報共有

図表 2-2-26 情報共有・活用取り組み事例（H 社）


170

この企業では、本社機構と販売拠点との情報共有の取り組みについてヒアリングを実施した。この企業では、本社の販売方針やその他必要な業務情報を、出店の店長および販売員と共有す

るためにシステムを構築している。店長も販売員も対面販売（接客）に業務時間のほとんどを費

やす。システム（パソコン）の前に座れる時間は限られている。店長でも 1 時間以内、販売員に

至っては５分ほどとの事。そのため、いかに短時間に必要な情報を伝えるために、そして、短時

間に情報に到達するために、仕組みはシンプルにし、ユーザーにいかに見てもらえるか、どう見

せるかに注力している。システムユーザーの視点に立ったシステム構築の設計思想については、

他の企業にも参考になる点が多々あった。

図表 2-2-27 種類別活用度合い（I 社）

蓄積検索思考


2．顧客の情報 ○ ○ ○

3．フロー情報

（業務連絡、事項通知等） ○ ○


情報、レポート等） ○ ○

5．Know-Who

さらに、ヒアリングを進めると、店舗ごとに固定客がおり、その固定客層によって、店舗ごと

に売れ筋商品も異なるとのことである。その情報が、店長や販売員に属人化しており、その情報

が共有できれば、本社部門のマーケティングにも一層有効なものになるとの事であった。売れ筋

だけであれば、POS（Point Of Sales）システムで把握できるが、商品が嗜好品であるため、購

入者の詳細データと売れ筋とが結びついたデータが必要との事。今後は、店長や販売員に属人化

している情報を、如何に表出化するかが課題となる。しかしながら、現状の業務状況から、その

情報を表出化するためには、IT だけでは解決できない問題も内在しているように思う。今後の展

開にも注目していきたい。

./keyword.htm#5201


171

ｉ．コンサルファームⅠ社：コンサルタントの情報活用

図表 2-2-28 情報共有・活用取り組み事例（I 社）

このコンサルファームは、情報共有・活用が企業内に文化として定着している。コンサルタン

トの業務は、様々な企業における諸問題を解決するために、その企業を分析し、あるべき姿を描

き、その姿に到達するための手段を提案することである。したがって、コンサルタントが必要と

する情報は、多岐に渡る。この企業では、コンサルタント業務で得た情報・知識等を集約して蓄積する専門職（ここでは

仮称として「ナレッジマネージャー」と呼ぶ）を設置している。ある企業で実施した事前の調査

内容と結果、それに基づくコンサルタントの提案内容（プレゼンテーション資料）とその評価・

結果を必ずナレッジマネージャーに報告する。ナレッジマネージャーは、その報告を蓄積し、コ

ンサルタントが次に請け負ってきた仕事に対し、その蓄積データから有効な提案資料や提案の方

向性などを抽出し、コンサルタントにフィードバックを行っている。コンサルタントは、ナレッ

ジマネージャーからの情報を活用し、現在取り組んでいるコンサル業務に合致した形にアレンジ

し、新たな提案を行っている。蓄積情報の活用から新たな「知」を生み出し、更なる蓄積情報の高度化を実践しているのであ

る。「知のスパイラル」が見事に構築されている良い例と言えよう。どのようにして、こういった仕組みが生まれたのかの問いに対しては、「こういうものだと思っ

ていたし、ごく普通の事」との答えが返ってきた。長年にわたって構築されてきた企業の仕組み

であって、現在そこで働く人にとっては、当然の事でしかない。当然、コンサルティングの中に、

ナレッジ活用のための仕掛け作りの依頼もあるとのことだが、彼らにとって、ごく自然な提案で

あり、その有効性に対し企業の理解も得られるのだが、ツールや仕組みの導入で終わってしまい、

定着まで進まないことも多いとのこと。

コンサルタントは、提

案終了後使用資料

と顧客情報と評価を

報告書にまとめ、情

報管理者に報告

情報管理者

は、報告書

等を電子デ

ータとして保

存

情報管理者

は、コンサル

タントの新た

な業務要求

に対し、必要

な情報を提

供

コンサルタン

トは、提供を

受けた情報

を元に、顧客

に対し新たな提案を提

供


172

173

第２章情報共有と情報活用第３節情報共有技術の発展と今後

近年 Web 2.0 などの情報の蓄積・検索・活用技術の進歩は著しい。その技術の概要紹介とそれ

を企業において活用する可能性についてまず触れている。

次に限りなく発展を続けている情報共有技術にも法的、倫理的制約があり注意して情報共有を

進めなければならない制約と実践手段を配慮事項として触れた。

最後に情報量の増大化への対処方法を情報過多時代の対策として紹介している。

１．情報共有の発展（Web 2.0 の企業への影響など）

２．情報共有の制約と対策

３．情報共有・管理の実践手段

４．情報過多時代の選択と対策（情報廃棄）

２－３情報共有技術の発展と今後

174

１．情報共有の発展（Web 2.0 の企業への影響など）

この節では、情報共有に関連するツールの変遷と、今後の情報共有の展望をみていきたい。インターネットの世界では、Web2.0 と呼ばれる現象によって個人の間での情報共有のあり方

は大きく変化し始めている。今後は、企業内の情報システムにも Web 2.0 で利用されるコミュニ

ケーションのあり方が取り入れられていくものと予想される。これまでも、メールや掲示板など

インターネットで発生したツールや技術は企業内システムに流用されてきた。これからも、イン

ターネットから企業内システムへの技術の流入は継続すると考えられる。情報共有に関するツー

ルの変遷と、インターネット上で起きている技術を見て行くことで今後の情報共有のあり方を考

えていただきたい。

図表 2-3-1 情報共有のツール

5．Know-Ｗho

4．ストック情報（プロジェ

クト情報、レポート等）

3 ．フロー情報（業務連

絡、事項通知等）

2．顧客の情報


思考検索蓄積

グループ

ウェア

SNS

ブログ

Wikipedia

DWH検索エンジン


175

（１）情報共有ツールの歴史的な変遷

情報共有を IT という切り口で見た場合には、その歴史はツールの歴史と重なる。企業におけ

る IT を利用した情報共有の初の段階は、メールによるコミュニケーションの開始と考えてよ

いであろう。その後、ファイルサーバーによる情報の蓄積がおき、それによって資料やデータの

共有化が行われるようになった。その後、ファイルをただ単に溜め込むだけでなく利用するとい

う動きが出てきた。文書管理ツールである。文書管理ツールの機能は登録者が、ファイルを共有

フォルダにアップロードする際に属性情報をつけることで、再利用を促進する。このようにして情報を蓄積していくと、情報の総量が増えたために、情報の山の中から必要な

情報を探すことが難しくなる。自分が探したい情報があるかもしれないが、どこにあるのかが分

からないという状態である。そこで、情報を探し出すためのツールが必要になってくる。インタ

ーネットに目を向けてみると、企業でこのような事が起きるよりも前に、ホームページの急速な

増大によって情報を探し出すことが難しくなっていた。そこで、Yahoo!や Google のような検索

エンジンが情報を探し出すための起点である、ポータルサイトとして注目を集めていた。ディレ

クトリをたどることや、検索エンジンで検索することで、必要な情報を探し出すことが出来るた

めである。この技術は、情報の過多に悩んでいた企業内の情報システムでも利用されるようにな

り、検索エンジンの企業内での活用が始まった。企業内やローカル PC でのも原始的な検索はファイル名による検索である。適切なファイル

名が付けられていればファイル名からある程度ファイルの内容を予測できる。だが、ファイルの

中身まで知ることは出来ない。この問題を解決する方法として、全文検索エンジンが利用される。

全文検索エンジンでは、全文検索システムに登録時にファイルの中身までを含めてインデックス

（索引）を作っておく。そのため、検索したいキーワードを入れて検索すれば、キーワードを含

むファイルを探し出すことができる。これによって、ファイルサーバーなどの企業内に存在する

情報を活用することができるようになった。 2006 年の前半からインターネットの世界では Web 2.0 と呼ばれる概念が入り、情報共有のあ

り方も変わってきた。Web 2.0 以前、情報は提供者側の一方的な提供であったが、ユーザーによ

る情報発信が増えている。これらの技術の中には、企業において現時点で活用できるものも少な

くない。情報共有という面ですぐに利用できるものだけに限っても、不特定多数が作る辞書であ

る Wikipedia や、日記風で簡単に更新できるホームページであるブログ等がある。これらの技術

については、企業への応用という切り口から、詳細は後述する。


176

（２）情報の蓄積

情報共有にはいくつかの段階がある。初に共有すべき情報を蓄積し、次に、情報を検索でき

る状態にし、後に情報を知識として利用するという流れである。この章では、情報共有で初

に行われる情報の蓄積に着目して説明する。ここでは、「蓄積」という切り口に当てはまるソリューションやツールの説明を行い、それぞれ

のソリューションが、企業の中でどのように利用され、どのような課題があるかを述べる。文書

の蓄積は、個人の PC 内で蓄積された情報が個人的に利用されているだけの状態から、部署内で

の情報共有を促進するために部門内ファイルサーバーに情報を保存する方針に変わった企業も多

い。だが、部門内ファイルサーバーにファイルをむやみに保存し、何がどこにあるのかが分から

ない状態になった企業もある。これを解決するために、文書管理ソフトを利用して、ファイルの

保存時に属性情報をつけ、フォルダをルールベースで分類することで文書を探し出しやすくする

という試みが進んだ。また、これらの文書管理ツールは、業務上で発生するファイルを管理する

ために、ワークフローと絡めることで情報を管理しやすくする方向に進んでいった。その後、文

書管理ツールはグループウェアやナレッジマネジメントツールと融合している。ａ．ファイルサーバー

企業内での情報共有は、部門ファイルサーバーに部門で発生する情報を収録することから始ま

った。ファイルサーバーによる情報共有の前提として、文書の電子化が必要であった。紙の資料

が主であった頃には情報の共有のためにはコピーなどしか方法が無かったが、エンドユーザーコ

ンピューティングが進められたことによって書類の電子化が進んだ。それによってファイルサー

バーにおける情報の共有の前提条件がクリアされた。文書の電子化が進んでからは、それらの情

報を共有するためにファイルサーバーを立てる段階へと進む。部門内ファイルサーバーでは、部や課のレベルでサーバーを立て、フォルダを作成し、その中

に情報（ファイル）を、どんどん溜め込んでいく。蓄積される情報は、文書やテンプレートであ

ったり、提案書であったりする。そして、格納者以外のユーザーが、サーバーの中のファイルを

活用する。これは、まさに情報共有である。これらが進むと、情報システム部などによって一元

管理されたファイルサーバーを一定のルールの元に利用するという段階に進んでいく。これによ

って、情報が共有される範囲が部・課の単位から全社での情報共有活用へと進んでいく。大企業

においては、部門内で個別で立てられたファイルサーバーは、アクセス検討のセキュリティの問

題を解決するため、全社的なファイルサーバーに移行されるという傾向にある。ただ、小規模な

企業やシステムインフラが整っていない企業では、現在でも部門内ファイルサーバーのみを利用

している企業が多い。だが、このようにして格納されたファイルも十分に活用されていない場合が多い。活用されな

い原因として以下のような理由がある。ファイルサーバーでは、様々な質のファイルが、あまり整理されずに保存されることが多い。

そして、年月を経るに従って整理されないファイルが大量に保管されて、誰が何をしまったのか

も理解されずに情報だけがたまっていくという状態になる。その状態で３年ほどが経過して、ユ

ーザーや担当者が変わっていくと、何がどこに格納されているのか分からなる。このようにして、

ファイルの信憑性や作成の背景が分からなくなるために利用ができなくなる。これを解決するた


177

めには、ファイルを加工して再利用可能なものにするという方法があるが、手間がかかるために

実施されることは少ない。また、ファイルサーバーが利用されない別の理由としては、情報量が多くなりすぎたために、

情報を探し出すことが大変になり、情報を見つけ出すよりも再度作成する方が手間がかからない

ため、過去の情報を探さない状況に陥る。また、フォルダ構成を頼りに探そうと思っても、時間

が経つに連れてフォルダ構成自体がおかしくなっているために探し出せなくなる。これらの問題を解決するために、ファイルのネーミングルールを作ることで整理するという企

業もある。これを実施することで、ファイルをタイトルで探すことができるようになる。だが、

サーバー内のフォルダ構成やネーミングルールを事前に決めていても、名前をつける際には、

終的には命名者の判断基準が入るために結果として整合性を保つことは非常に難しいという問題

点が残った。ｂ．文書管理ツール

ファイルサーバーに情報を蓄積する場合には、構造化されたフォルダの中に、登録者が当ては

まると考えたファイルを格納するのが通常である。これには、いくつかの構造上の問題点がある。

ファイルを登録する人全員がフォルダ構造を理解しているわけではないため、不適切なフォルダ

にファイルを格納してしまい、そのために探し出すのが難しくなる問題が発生する。文書管理ツ

ールでは、これを解決するために、ファイルの登録時に、登録者等が属性を着けることで、必要

な情報を検索しやすくする方法をとった。この方法は、再利用の可能性が高くなるメリットをも

たらすが、登録者に手間がかかるわりに、それによって得られる効果が少ないデメリットもある。わざわざ作成するには手間がかかり、得られる効果が少ないという欠点を補うために、文書管

理ツールでは業務に絡めた商品が出始めた。企業には、ワークフロー上でやり取りされる定型文

書が大量に存在している。それらの業務上の文書を自動的に格納することで、ユーザーはわざわ

ざ属性情報などを手作業で追加することなく、文書を管理できることになる。しかし、文書管理

ツールの機能だけでは、文書の属性情報やファイル名のみを利用して文書を探すので、その能力

に限界がある。だが、全文検索エンジンを利用することで、ファイルの中身まで見られれば、情報活用に対す

る効果はいっそう上がる。このような効果を狙った文書管理ツールと全文検索エンジンとの融合

が今後は進むとみられる。


178

（３）情報の検索

情報を蓄積し始めると、徐々に情報量が増えていき、何がどこにあるのかが分からなくなる。

そこで、必然的に情報を「検索」したいというニーズが発生する。検索の対象は多岐にわたる。

ファイル名を検索すれば十分な場合もあれば、ファイルの全文を検索したい場合もある。文言だ

けでなく、画像や音声や映像を探したい場合もある。ファイルの中身まで検索することのできる全文検索エンジンは、もともとはインターネットか

ら発生したものが多い。インターネットに存在している大量のウェブサイトを見るために作られ

た検索エンジンは企業内の情報システムでも活用できるため、社内システム用に応用されること

で商品化された。この節では、企業内システムで使われるファイルサーバー内の検索と、インタ

ーネットの検索エンジンについて解説する。この分野は、Google や YST（Yahoo! Search Technology の略。ヤフーの検索エンジン）を中心に日進月歩で技術が発達している分野である。

ａ．ファイルサーバーの検索

ファイルサーバーへの情報の蓄積が始まると、自然と検索のニーズが発生してくる。蓄積が始

まった段階では、情報も少ないために目で見ることで必要な情報を探し出すことが出来る。だが、

蓄積された情報がある程度を超えると、目では分からなくなる。ファイルの中身をいちいち開く

ことが必要になり、段々と目的のものが見つからなくなる。ある程度の混乱は、ネーミングルールの決定と徹底によって防ぐことは出来る。だが、ファイ

ル名だけでは本当に有用な情報なのかどうかが分からない。だが、ファイルをすべて開いて必要

な情報を探し出すのは時間の無駄である。そこで、検索ワードを利用してすべてのファイル内の

文言を検索する必要が出てきた。全文検索エンジンでは、フォルダ内のすべてのファイルのイン

デックスをあらかじめ作成しておき、検索キーワードとインデックスを比べることによって検索

を行う。あらかじめインデックスが作られているために、短時間でファイルの中身を検索した結

果を表示することができる。これによって、タイトルを調べるだけよりも格段に求める情報を見

つけられる可能性が高まる。また、ファイルの中身を見る必要が減るために情報を探し出す手間

も省ける。ただし、テキストによる全文検索には、ユーザーの習熟度が高くないと有効な情報を入手でき

ない問題点がある。キーワードを元に検索を行う場合には、何を探したいのかがあらかじめ具体

的にキーワードで思い浮かべられなければ、目的とするファイルを見つけることは難しい。また、

求めている資料のイメージが明確であったとしても、求めているような資料が存在していない場

合もある。どのようなファイルが存在していて、どのようなキーワードで検索すれば求める資料

が見つかるかが分かるためには、ユーザーの側が検索に慣れることが重要である。だが、ユーザ

ーは検索に慣れる前に、求める資料が見つからないことでシステムの利用を諦めてしまうことも

多い。検索エンジンをファイルサーバーに導入して利用させる場合には、ユーザーが自分で学習

する仕組みを組み込むことが重要となる。


179

ｂ．インターネットでの情報検索 1995 年に日本でのインターネットが始まり、徐々にインターネットによる情報収集が始まった。

日本では、1996 年に Yahoo!がディレクトリ型の検索を開始した。ディレクトリ型検索エンジン

とは、人力で分類することでディレクトリにＵＲＬを分類する検索サービスを指す。Yahoo!の登

場以降、検索サイトではポータルサイト化が進んだ。その後、1998年にGoogleが登場した。Googleでは、今までの検索サイトのようなポータルサイトを作らず、検索画面のみというシンプルなユ

ーザーインターフェイスのサービスを行った。検索結果に求める情報が多く出るとのユーザーの

反応によって、Google はユーザー数を増やしていった。その後、Google では地域情報の検索サ

イト、画像検索、ニュース検索などに検索サービスの範囲を広げている。インターネットにおける検索は、ニュース・ブログ・画像・動画などに検索対象を広げる方向

と、検索結果を動的に分類することや、表示方法に画像を利用することで表示することでインタ

ーフェイスを改善する方向に進化している。また、「人力検索はてな」のように人がコメントをつ

けることで抽象的な質問にも答えることが出来る検索サービスも出てきている。「はてな」では、

質問者が質問を投げかけると、それに対して別のユーザーが答えを出すというシステムを使わな

いアナログな検索サイトである。回答者に対してポイントを付与するなど、情報提供を活性化す

る仕組みが含まれているために活発に利用されている。ｃ．検索エンジンの発達

検索エンジンの発達で、今まであったブラウザのブックマークを利用する人が減ってきている

といわれている。これは、ブラウザの中から自分で登録したブックマークを探し出すよりも、検

索エンジンで検索してからホームページにアクセスするほうが早いと感じている人が多いことを

示している。これも、ある種のユーザーの変化である。検索エンジンの精度も低く、情報を検索

することが大変だった時には、求めるページが中々見つからなかったため、ブックマークを保存

してそこから必要なページに行くことが主流であった。だが、今では検索サイトでキーワードを

検索すれば自分の望むページが上位に出るために、そこから行きたいホームページに飛べばよい。

検索することを、Google をもじって「ググる」とう言葉が一般的になったのも検索が定着したこ

とを示す一例であろう。 Google を発端として、検索エンジンの検索精度は格段に向上した。思いついた言葉を Google

のトップページに入力して検索することで、自分が必要とするホームページが 1 ページ目に表示

されることも多くなってきた。そのために、お気に入りへの保存したページに訪問していた方法

から、検索エンジンで検索してから上位のホームページに訪問する方式を活用するように利用者

の行動パターンは変化してきている。ユーザーは検索結果の上位ページしか見ないため、Yahoo!や Google のような代表的な検索サイトで上位に表示されなければ、ホームページにアクセスさ

れないという傾向もある。


180

図表 2-3-2 検索エンジンの技術的な仕組みの概念図

だが、現在の検索が万能というわけではない。現在の検索にはいくつかの問題点がある。本当

に欲しい情報を検索するためには、ファイルサーバーの検索の項目でも前述したが、検索エンジ

ンを使いこなすためのリテラシーが必要である。また、自分がほしい情報が自分でも分かってい

ない場合には検索エンジンはあまり有効ではない。たとえば「自社のマーケティングに活かされ

る情報が欲しい」といった場合、検索エンジンを利用して求める情報を探すためには、色々な言

葉を入れながら試行錯誤して探すしかない。一部の検索エンジンでは、「もしかして×××です

か」のように、自分が検索した以外の情報が提示されることもある。だが、これも、間違えやす

い文言を入れた時に、似たスペルの単語を提示して「こちらが正しいのではないですか」と提示

するだけである。また、テキストの検索の問題や、「ゆらぎ」の問題、画像や動画の検索精度の問

題など、検索にもまだまだ課題が残っている。後に、簡単に検索エンジンの技術的な仕組みを説明する。検索エンジンはインターネット上

のホームページや社内システムなどを、エージェントを放って検索させる。このことを、情報を

かき集めることから一般的にはクローリングと呼ぶことが多い。クローリングしてきたデータを、

きれいにクレンジングして、インデックスと呼ばれる索引を作成しておく。検索ワードが入れら

れると、インデックスから合致する単語を探し出して結果として表示する。簡単に説明すると以

上のようになるが、これらの技術の詳細については本書の範疇ではないため、専門の書籍を参照

願いたい。ｄ．企業内ポータルにおける検索

社内の情報共有として使われているサイト内検索エンジンは、全社のポータルサイトのトップ

画面や、部門毎の社内ホームページに付属している場合も多い。これらの窓から検索ワードを入

力して検索できるようにすることで、自分が求める社内情報へのアクセスを容易にしている。社内システムに使われている検索エンジンには、元々はウェブサイト系の検索エンジンであっ

たものや、ナレッジマネジメントに寄った機能の製品まで様々な種類のものが存在する。それら

の検索エンジンを技術的に見ると、検索の精度はかなりの格差がある。検索した単語が完全に一

致していないと表示されない検索エンジンもあれば、半角や全角と角種が違っていても同一のも

のとして検索できる製品もある。ひらがなカタカナの揺れや、同義語を同じものとして検索でき

る製品はまだ少ない。

サーチエンジン

インデックス

検索

インターネット

社内システム

クローリング


181

今後、自社内における検索の位置づけは今以上に大きくなる。大企業ではイントラネットのペ

ージ数が巨大化してきたことで、自分が求める情報があるのかどうかを知ることは難しくなって

きたため、検索エンジンを利用することが多くなる。近では、社内で検索エンジンが利用され

ることが多くなっているが、その原因の一つとしては、ユーザー自体が検索エンジンを利用する

ことに慣れたことが挙げられる。Yahoo！や Google のユーザーが増え、会社の外でもキーワード

検索を行うという行動が一般的になったために、企業内の検索でも同様のシステムを使いたいと

いうニーズが出てきたと考えられる。また、以前はインターネット用に開発されていた大手検索

エンジン企業が、インターネットでの市場が飽和したために企業内部で利用するシステムに進出

を図っているという傾向も見られる。このように、大規模向けの検索エンジンが中小規模である

社内システムに進出している一方、前の項で記載した文書管理ツールが検索機能を強化している

という傾向もある。今後は、よりいっそう文書管理ツールとインターネット系の検索エンジンの

境目が曖昧になると思われる。（４）その他の情報共有ツール

ａ．企業内ポータル

ネットワークが発達するにつれて、業務ごとや、各部署で部門ホームページや小規模のアプリ

ケーションを作成するようになる。それによって、情報が分散化し、自分が必要としている答を

どこで探せばいいのかが分からなくなる。長年システムを使ってきて、個別のシステムに対する

理解度が高いユーザーにとっては、これでよいかもしれない。だが、会社のシステムができてき

た経緯を知らない者にとっては、分散して配置されたシステムを知ることは難しい。また、日々、

新しいシステムや情報が企業内にも増えてくると、情報が分散している状態では活用されづらく

なってくる。これらのことから必然的に、ユーザーは一元化されたシステムの窓口を望むように

なる。企業内ポータルは、この問題を解決するための方法である。社員にとってのサイトの入り口を

一箇所にし、そこから必要となるすべての情報にアクセスできるようにする。現在は、多くの企

業で社内ポータルサイトを持っている。ブラウザを立ち上げると自動的に社内ポータルが表示さ

れる企業は多い。これによって、社員が必要な情報に簡単にアクセスできるようにし、情報の活

用度合いを上げていく。また、通知事項などの社員に必須な情報をメールからポータルサイトに

移すことでメールによる情報過多の状態を減らすといった企業も負い。現在では経営者の意見を

直接伝えるためにブログを付けて更新することで上から下への情報伝達の迅速化を図ろうとする

企業も増えてきている。このように、社内ポータルは企業内システムの入り口としてすでに定着

している。だが、このポータルの情報も増えすぎて、すべての人にとって有効な情報だけをトッ

プページに表示することは難しくなってきている。今後の傾向としては、社内ポータルはパーソ

ナライズが進むと想像される。営業は営業に関連した情報、研究者は研究者にとって必要な情報

と、大企業になると同じ会社内でも必要とする情報は違うものになるはずである。そのため、そ

れぞれの立場でユーザーが自分自身で望む情報をトップページに表示することで、自分にとって

本当に必要な情報だけを短時間で見ることができるようになることを期待されている。


182

ｂ．グループウェア企業内の情報共有を活性化させるためのツールで、Lotus Notes/Domino や、Microsoft

Exchange Server、サイボウズなどがある。メール・スケジュール管理・在籍確認・施設予約・

掲示板・ワークフロー・文書共有・電子会議室等の機能を持つ物が主流となっている。また、

近の傾向としては、Web ブラウザや ASP で利用できるものが増える傾向にある。グループウェアは、情報共有のために必要な基本的機能をすべてそろえている製品である。導

入の利点としては以下のような項目が挙げられる。スケジュール機能によって、同僚等のスケジ

ュールが見えるようになり、会議調整がしやすくなる。アドレス帳によって、顧客情報の共有を

行う事も出来る。顧客情報は、名刺を自分で管理してしまっておくことが多かったが、グループ

ウェアによって顧客情報の共有も行う事が出来る。また、会議室予約や掲示板の機能も持ってい

る。ファイル共有の機能が実際には活用されていないケースも多い。また、全社共通のインフラ

として活用される事で効果を発揮するが、実際にはあまり利用されず、機能を活かし切れていな

いことも多い。通常は大企業ではすでにグループウェアを導入している企業が多い。だが、あまり利用されな

い割にライセンス料が高い、OS の変更に対応するために定期的なバージョンアップが必要、な

どの問題もあり、今後は低価格・高機能の製品への移行が進むものと期待されている。ｃ．社内掲示板

1990 年代の中頃から、社内掲示板を導入する企業が徐々に増えてきた。社内ポータルに単独で

掲示板を作成した企業と、グループウェアに付属の掲示板を使っている企業に分かれる。いずれ

にしても、社内掲示板が活発に使われている企業は少ない。その理由として、企業内掲示板は匿名ではないという部分がある。2 ちゃんねるなどの匿名の

掲示板が盛り上がっているのは、情報に責任を取らなくていいということ、つまり、書き込みを

行っている人が誰だかが分からないという点がある。自分の発言に責任を取らなくてもいいため

に、気軽に書き込むことができるということが掲示板活性化の要因の一つとなっている。企業内

のシステムでは匿名で返答をすることは少なく、ログを元に誰が書いているのかを確実に追跡で

きるため、気軽に意見が言えるという利点はなくなる。また、回答を誰が見ているか分からない

（上司が見ているかもしれない）ということが回答するためのハードルになっている。そして、

答えても答えなくても良い場所（掲示板）で、責任のある発言をするということに心理的な抵抗

が出るために、書き込みが少なくなる。このように、社内の掲示板を活性化させるためには、た

だ単に掲示板を作成するだけでは難しい。それでも掲示板を利用させようとすると、書き込ませ

るための強制力や様々な仕組みが必要となる。だが、そこまでの力を入れて情報共有を活性化さ

せようという企業は少ない。結果として掲示板で意見を言ったり質問を行ったりする事が少なく

なる。このような理由により、社内における掲示板は活性していないと考えられる。


183

ｄ．日報・月報

日報や月報も情報共有の一つのツールである。日報・月報自体は IT 化される前から存在する

もので、元々、上司と営業等の進捗状況などを確認するためのものだった。企業内での 1 人 1 台

のパソコン活用が進むにつれ、営業担当者の日報の電子化が進んだ。日報・月報に書かれた情報

を企業内で活用することも、情報共有の一つということができる。通常は、営業が他人の日報や

月報を読む時間はない。そのため、日報や月報を情報共有として活用するためには、何らかの解

析や処理が必要となる。日報や月報に書かれた情報を蓄積していき、ある程度の情報が溜まった

段階で、そこに書かれている情報を解析する。そこで解析された結果を営業にフィードバックす

ることで情報を活用していくといったことが多い。ただし、営業の日報・月報の活用は非常に難

しい。もともと、営業担当者は IT スキルの高くない場合が多く、そもそも情報を書き込む量が

少ない・情報の内容が不正確であるといったことも多い。これらの情報を元に解析を行って有用

な情報を導出することは難しい。だが、営業情報を共有して活用したいというのは、どの企業で

も持っている悩みであるため、これらの情報の活用の方法論を作り出すことが望まれる。（５）インターネットの世界

インターネットにおける情報共有は、ここ数年で大きく変ってきている。そもそも、インター

ネットの発明は、情報共有の規模拡大の歴史と言っても言い過ぎではない。メールによって、世

界中の人々と瞬時にやり取りが出来るようになり、ホームページによって情報の発信ができるよ

うになっていった。そして近ではブログや SNS によって、より一層の双方向コミュニケーシ

ョンが活性化されている。インターネットが普通に使われるようになってからは、インターネットで使われ始めた技術が

数年後に企業に入ってきてスタンダードになるという流れは、ここ 10 年ほどで確立されてきて

いる。も代表的なツールはメールである。E メールも、元々は研究者同士のメッセージ交換の

ツールとして発明されたが、インターネット上での個人のやりとりに利用されるようになり、現

在ではビジネスに欠かせない物となっている。また、同様に近年では IP 電話も企業に取り入れ

られて来ている。 2005 年頃から、徐々に SNS やブログが企業内システムに用いられているようになってきた。

ブログが流行し始めたのは 2004 年以降であるが、社長ブログや、部署ごとのブログなど、企業

内でもブログを立ち上げる企業は増えている。また、それらのブログを外部に紹介することで企

業や製品のブランディングに活かしている企業もある。経済産業省でも、地域活性化の一環とし

て地域 SNS を立ち上げている。ただ、ブログや SNS が Web 2.0 の流行によって、今後も企業内

システムで主流になるとは言えず、これらのツールを企業にそのまま応用するためには様々な課

題があるということも明らかになってきている。今後は、Web 2.0 は Ajax の技術を取り入れた社内システムや、パーソナライズ可能なポータ

ルサイトのように、基幹業務以外のインターフェイスの部分から企業内システムに応用されるこ

とが増えると予想される。Ajax とは JavaScript と XML を利用して、Web ページをリロードせ

ずに情報を更新していく技術を言う。代表的な例は、Google の Google Maps である。それまで

の地図では、地図を拡大縮小する場合や、表示している箇所を変える場合には、Web ブラウザの


184

表示をリロードさせる必要があった。だが、Ajax を利用すれば、シームレスに拡大縮小や移動さ

せることができる。このような、インターフェイスの技術を利用した、より効率的でインタラク

ションを補助するような技術から企業内システムに導入されていくと予想される。ａ．インターネットの発達による、情報共有の変化

図表 2-3-3 情報共有の変化

インターネットが始まった当初から、マスメディアが情報を提供するという一方的な構図が、

個人が情報を発信できるという変化するだろうといわれていた。だが、現実的にはホームページ

を作ることの出来る一部の人が情報を提供するだけにとどまっていた。それは、技術的な敷居が

高かったためである。ホームページから情報発信をするためには、HTML のタグを知っている必

要があり、ホームページをアップロードするためのサーバーを持ち（もしくはレンタルし）、FTPによってファイルをアップロードする必要があった。また、少し凝ったホームページを作成しよ

うとすると、これ以外にも CGI や JavaScript などの様々な技術を習得する必要があった。だが、ブログが流行したことによって誰でもすぐに情報を発信できるようになった。これは、

文章をブラウザ上で書いて送信すればいいという、非常に簡単なインターフェイスのためであろ

う。ブログでは、リンクをタグで囲む必要も無く、文章をただ単に書くだけで自分の日記を公開

できる。FTP によるファイルのアップロードの必要もない。単に記事を書きさえすればページを

アップロードし、修正することが出来る。その上、簡単に他人の記事を引用でき、リンクを貼る

ことも出来る。実は、ブログは技術的にはそれほど新しいものを使って作られたわけはない。無料の個人ホー

ムページ作成ツールは以前から存在し、それらとブログの本質的な差は少ない。ブログの流行に

は、2 つの原因が考えられる。

社内における情報共有

現在までの情報共有将来の情報共有

部門

部門

取引先

社内における情報共有

部門

部門

取引先



情報収集情報連携情報収集

相互の情報提供


185

１つ目の原因は、手軽さである。前に挙げたが、HTML によるホームページ作成や情報発信に

比べて、作成が簡単になった。また、ページ更新も容易に行えるようになった。これによって、

情報発信を行う人の数が格段に増えた。 2 つ目の原因は、パーマリンクという「記事レベル」で固定される URL を作った事である。

今まで、ページ単位にリンクを貼り付けていたものが、一つの投稿に URL を貼り付けることが

出来るようになった。これによって、検索エンジンの上位に記事が表示される機会が増え、外部

からのリンクも、記事を参照して表示することができるようになった。これによって、トラック

バックが出来るようになった。トラックバックとは、他人の日記に、自分の日記からリンクを張

ることである。これによって、その記事に書かれた「情報を共有」することが出来るようになっ

た。トラックバックを貼られた側から、リンクを貼った元のブログを知ることが出来る。また、

パーマリンクでは URL が記事ごとに存在するために、外部からのリンク切れが少なくなった。

今までは、自分のサイトでリンクを張ってもリンク先がアドレスを変えるとリンク切れが起きて

いたものが、記事自身の削除が起こらない限り、参照先が切れているということが無くなった。この 2 点と、「ブログ」という言葉自体の流行が重なり、現在では完全に定着した一つのメデ

ィアとして存在しているといえる。今後は、ブログそれ自体の利用者が多数居る状態が続く可能

性は低いが、ブログは定着して当分の間残るものと考えられる。企業から見たブログの利用方法としては、ブログによる情報発信と、ブロガーを利用した口コ

ミが考えられる。ブログによる情報発信では、更新の簡便さを利用して情報頻度を上げる方法で

ある。ベンチャー企業などでは、社長がブログを利用して自社を売り込んでいることも多い。た

だ、この方法は大企業においては発表前の情報の確認など、様々な制約があるために難しい面も

ある。そのため、ブログは社内に対する情報発信の一手段として利用されることが増えると思わ

れる。ブロガーを利用した口コミは、企業がブロガーを利用して情報を発信する方法である。ブ

ログによる口コミは、リアルな世界での口コミよりも格段に早いスピードで情報を伝播すること

ができ、また言葉とは違いネット上に文字として形を残すことができる。これを利用して、企業

が広めたい情報をブロガーを利用することで広めるといった方法も増えてきている。これらのブ

ログを企業が利用する方法は、まだ試みが始まった段階で、色々な欠点や課題があるため、有効

な活用の方法論を整えていく必要がある。ｂ．インターネットの技術の企業への流入

今後の企業内での情報共有を考える上で、インターネットから発生した技術や方法論に着目す

る必要が高まっている。遅くとも数年後には、現在インターネットで流行している技術が企業で

も当たり前のように使われるようになると考えられる。 2006 年になって、Web 2.0 というバズワード（流行語）を良く聞くようになった。まだ、多く

の技術や概念は企業システムには入ってきてはいないが今までよりも速いスピードで企業内のシ

ステムに取り入れられるはずである。なぜならば、ユーザーはインターネットにおける情報共有

の仕組みに慣れているために、企業で導入しなかったとしても、自然発生的に技術が使われるよ

うになるためである。これは、インターネットの技術が個人レベルでも社内で利用できることと

も関係がある。もし SNS のサイトを立ち上げたい場合には、標準的なスペックの PC が一台あれ

ば、後はオープンソースのパッケージを組み合わせて、1 日もあれば立ち上げることができる。


186

エンタープライズのシステムの面から見ると、Web 2.0 を個人レベルでの情報共有が大きく変

ってきたという点に着目することが重要である。ブログや、SNS で個人の情報発信が容易になり、

Ajax によってユーザーインターフェイスが使いやすい物となった。また、ソーシャルブックマー

クや Wikipedia も情報共有のあり方を大きく変化させるものとなっている。ここまで挙げた技術の一部は、既に企業に入ってきているものもあるが、多くのものは一般の

ユーザーがインターネットで使っているだけの状態である。企業が本格的にこのような技術を導

入できない理由として、セキュリティの問題がある。インターネットで新しく発生した技術は永

遠にベータ版といわれるサイトも多いため、セキュリティに問題がある場合が多い。企業として

は、今後の動向を見極めた上で利用したいと思っていると考えられる。また、別の理由としては、

そもそも大手の SI ベンダーなどで Ajax や XML 等の技術者が少ないため、作りたいと思っても

Web 2.0 に対応したシステムを作れないという問題もある。個人レベルで SNS を立ち上げられる

といった記載とは矛盾するように感じるかもしれない。だが、実は立ち上げるのは簡単だが、セ

キュリティが甘いため、企業内で正式に立ち上げるためには格段にハードルが上がるのである。今後、技術が成熟してセキュリティの問題が解決し、企業での効果が見えてくると企業内での

普及が進み、数年以内に流行する技術も多いと思われる。これまでも、インターネットの技術は

数年遅れで企業での標準的なツールとなってきた。も代表的な例はメールである。メール自体

は、現在でもセキュリティが確かだとはいえない。だが、現在ではメールはビジネスに欠かせな

いものとなっている。技術者が少ないという問題についても近いうちに解決すると考えられる。

インターネット上のサイト構築等で徐々に技術者が増え、企業内のシステム構築にビジネスの場

所を移していくことも予想される。ｃ．SNS・社内 SNS

SNS とは、Social Network Service の略であり、招待制のコミュニティを指す。日本では、

GREE が初の SNS とされているが、現在大の SNS は、mixi（執筆時の 2006 年 11 月現在

で参加者は 600 万人弱）である。自分のプロフィールを紹介し、日記を書くことで自分の情報を

発信する点はブログと同じである。自分の友人を登録できるという点と、同じ趣味を持った人同

士をつなぐコミュニティという仕組みが存在することがブログとは異なる。また、足跡機能によ

って、誰が自分のページを見てくれたのかを確認できるといった機能もある。SNS とブログの違

いは、次のようなものである。ブログでの人と人のつながりは、トラックバックかコメントであ

る。一方、SNS には、「友達」機能によって人と人をつないでいる。また、SNS にはテーマごと

のコミュニティがあり、そこで面識の無かった人をつなぐことが出来る。これは、掲示板に似た

機能である。掲示板との違いは、掲示板では、一テーマにつき一スレッドであるのに対して、コ

ミュニティでは、大きなテーマの中に多数のスレッドを作り、同じメンバーでディスカッション

をする点である。 SNS の大の効果は「気づき」である。メールや業務報告では切り捨てられてしまう「気づき」

を引き出すために、コミュニケーションの活性化を行う。ただ、課題は業務と全く関係ないこと

ばかりを SNS で会話し、悪影響が出る場合があることである。だが、実名を書いて SNS を作る

場合には、そのような私用との区別の曖昧さは減る。ネットサーフィンの普及時に私用でインタ

ーネットを見ていた人たちが、徐々に規制されて減って行った状況と同じ道を辿ると予想される。


187

近では、徐々に社内で SNS を利用する企業も増えてきている。今後の情報共有ツールの一

つの選択肢となると考えられるが、先行的に社内 SNS を開始した企業ではいくつかの課題が出

てきている。元々が、一般的な友人同士の情報を交換するものであるため、結びつきがある程度

弱い人同士をターゲットにしている。また、「人」や「コミュニティ」の単位で情報を発信するた

め、知らない人や興味のないコミュニティの情報を知ることができない。すべての人が入るコミ

ュニティを作ることも可能だが、ほかのシステムで代替できるため敢えて SNS を作ろうという

ところまでモチベーションが高まりづらい。また、既存システムに加えて SNS を作ることで、

ユーザーが見なければならない情報も増えるため、結果的には活用されない等の問題もある。

SNS に関してもブログと同様に、企業内で利用するための様々な課題が発見され、解決されてい

くと考えられる。ｄ．Wikipedia

Wikipedia とは、インターネット上で、不特定多数の人によって編集される辞書である。サー

ビスは無料であり、記事の作成はボランティアによってまかなわれている。内容は誰でも編集で

きるが、履歴は残され、また多数いる編集者によってチェックされて更新されることで内容の質

を保持している。不適切な内容の記事は短期間で修正されることが多い。 Wikipedia には、システムに関する用語やビジネスに関する用語まで幅広い内容の情報が書か

れている。以前は社内で作っていた辞書や、教育用の資料等は Wikipedia を利用することで十分

といった状況も徐々に生まれていくと思われる。Wikipedia やソーシャルブックマーク等の社外

のナレッジを企業で利用することで情報を効率的に収集できる可能性を秘めている。

ｅ．ツール以外の問題 ───ツールを入れるだけでは情報共有は実現されないここまでツールの説明をしてきた。だが、当然のことだがツールを入れるだけで問題は解決す

るわけではない。大規模な投資を行ってツールを導入しても、効果が出なかったという話を聞く

事が多い。これはツール自体に問題があるわけではなく、情報共有のあり方に問題がある場合が

多い。ツールを導入しても情報共有が活性化しない場合には、2 つの問題がある。１つは、ユーザー側のリテラシーの問題で、導入したツールがユーザーの理解度が低いために

活用されていない場合である。システムが効果を発揮するためには、地道な教育と習熟が必要で

ある。しばしば起こることだが、ツールを作成し、入れることには力を入れるが、それを利用す

るための教育が不十分な場合が良くある。また、ツール導入の目的がユーザーに理解されていな

いために、活用されない場合も多い。もう１つは、コンテンツの問題である。情報共有するためには、共有するための情報に価値が

あることが重要である。ファイルを社員全員に見せるだけで効果のある情報もあるが、他人が見

ても意味のない情報もある。作られてから時間が経ちすぎて役に立たない情報もある。加工する

ことで意味の出る情報もある。情報共有を効果的に行うためには、利用される場面を想定する必要がある。その上で、情報共


188

有を行う際に作成した目的を達成するために必要なコンテンツの質をどのように保つのかを考え

ねばならない。コンテンツの質を保つためには、加工してから情報を公開するといった手間をか

けることも必要となる。この場合には、加工にかかる費用と、それによって得られる効果の費用

対効果を考える必要がある。情報システム部が旗振り役になって、ツール主導で情報共有を行う場合、システムが無事にカ

ットオーバーされることが目標になってしまう場合が多い。他のシステムでも同様だが、情報共

有に関連するシステムでは特に、カットオーバー後にどれだけ有効に利用されるかといったこと

が重要となる。情報共有システムでは、ツールを導入するよりも、継続的で効果的にシステムが

利用されるように業務に踏み込んだ導入を意識してツールを使いこなしていく必要がある。そこ

まで考慮されずにただ単に情報共有のためにツールを導入すれば、新しく使われないシステムが

増えるだけにとどまる可能性が高くなる。２．情報共有の制約と対策

情報を共有することは、すなわち、情報を公開するである。しかし、情報は、その内容により、

個人情報など法律や道義的理由から公開が制限されるべきものもある。また、企業経営上重要な

情報（営業秘密など）の取り扱いなども、各企業の情報セキュリティポリシーに則った形での情

報共有・活用が必要であり、その機密度によって、情報管理がなされることは当然のことと言え

よう。ここでは、情報共有の法的制約と対策について考察する。（１）個人情報共有の制約

個人情報は、企業活動において極めて重要な情報である。しかし、2003 年施行の個人情報保護

法によって、その利活用には、各種制限が加えられた。情報共有・活用において、情報収集する

際に、その利用目的を明示する必要がある。そのため、企業は、事前に個人情報共有・活用の目

的と使用方法とを明確にし、従業員に徹底する必要がある。例えば、一般的な企業活動、特に、営業活動中には、顧客との接点が増え関係度が増すにつれ

て、得意先担当者から製品情報や市場動向などの一般情報とともに、顧客担当者の個人情報を入

手する場面も多々生まれてくる。この場合、個人情報に関しては、利用目的を明示し社内におい

て共有する事について了承を得る必要がある。（名刺情報も当然この範疇に入るが、企業活動にお

いては、曖昧な運用がされている例が多い）了承を得た情報のみが、共有されるべきであり、了

承を得られていない情報は共有すべきではない。当然ながら、収集蓄積された個人情報は、目的に合致した利用に限られる必要がある。そのた

め、企業内においても、利用すべき人・組織は限定されなければならない。したがって、個人情

報は、厳密なアクセス権管理がなされ、限定的な情報共有・活用が実施されねばならない情報と

言える。


189

（２）内部統制上の制約

日本における内部統制にかかわる法律に関しては、2006 年 11 月現在、その適応範囲がまだ明

確になっておらず、ここでは、米国 SOX 法による類推での記述になるが、特に、基幹業務シス

テムに対する制約が増すことは、確実である。日本における内部統制の枠組みは、米国の「COSO（the Committee of Sponsoring

Organization of the Treadway Commission）フレームワーク」をベースにしたものだが、もと

もとの COSO フレームワークの 5 つの構成要素のほかに「IT の利用」（IT 統制）が加えられて

いる。IT 統制では、Program Development：プログラム開発、Program Change：プログラム

変更、Computer Operations：コンピュータ運用、Access to Programs and Data：プログラム

とデータへのアクセスの４点が定義されている。その内、情報共有・活用では、特に、プログラ

ムとデータへのアクセス、すなわち、アプリケーションと使用するデータに対してのアクセス管

理、ID 管理、パスワード管理、アクセス制御などが確実に管理されているかどうかに注意を払う

必要がある。

（３）各種法律への対策

これまで、情報共有・活用に関する IT ツールを検討する際には、その促進を目的に利便性を

追及する場面が多かった。しかしながら、各種法律への対策として、利便性追求だけではなく、

共有する情報の内容（業務システムにおける入力値など）の正確性を確保するための各種チェッ

ク機能、情報へのアクセス権の管理や不正アクセス防止のためのアクセス制御システムや情報漏

洩防止のためのセキュリティ製品の導入なども十分に検討する必要がある。ただし、その対応に

は、その範囲を明確にしなければ確固たる対策も望めないだけでなく、過剰対策による費用の増

大も起こりうる。対策には、必要十分な条件を把握し、実施する事が大切である。３．情報共有・管理の実践手段

情報共有・活用そして情報管理に関しては、形式知化→蓄積→検索→思考のステージごとに必

要とされる仕掛けやツールは異なると考える。（１）形式知化

情報を形式知化（電子データ化）するためのツールはワープロソフト、グループウェア、SFAなど様々なものがある。ツールの選択は、形式知化された情報を、どのように使っていくかによ

って、決める必要がある。その選択を誤るとせっかくの形式知化情報も使われなくなってしまう

可能性があること注意しなければならない。一方、形式知化で一番問題になるのは、「人」の意識である。多くの企業が、情報共有を実践す

る際、初に躓くのがここである。この問題を打破する方法としては、知識への貢献に基づいて

報償を与えるインセンティブ構造の構築や経営陣が知識行動の例を示すことなど外部要因も有効

と考える。とはいえ、属人化した情報は、情報の所有者が、形式知化する必要性を認識しなけれ

ば、有益な情報は形式知化されない。やはり、「人」の意識を変えることが、真の情報共有は生ま

れてこないと考える。


190

（２）蓄積

形式知化（電子データ化）された情報を効率的に引き出せるよう蓄積しなければならない。次

項の「検索」につながることだが、情報の形式や量によって、ファイルサーバーでフォルダを整

理し共有したり、企業内の情報を従業員の業務内容に合わせ、カスタマイズし表示するポータル

サイトを構築し、情報への導きを促したりする方法を検討する事が重要である。また、情報量が

増えるに従い、蓄積する際に情報の分類を実施することも今後の課題となってくる。今後、情報量の増大に伴って、情報蓄積に当たっては、情報そのものだけではなく、同時にそ

の情報のメタデータ（作成者、作成日時、タイトルなどの関連情報）の整備・蓄積が、情報の管

理・検索の効率化に重要となってくる。（３）検索

検索に関しては、様々なツールがあるが、いかに必要な情報に的確かつ迅速に到達できるかが

鍵となる。詳細はこの節の「第 1 項情報共有の発展」を参照されたい。（４）管理

何の制約もなく収集・蓄積された情報は、そのままでは使用に耐えないものもある。さらには、

情報の背景にある様々な付加情報がなければ、情報そのものが意味をなさない場合もある。情報

の管理は、情報の取捨選択をはじめ、情報内容の整備、分類などを行い、情報利用者に対しての

ユーザビリティの確保が、情報共有を実践するためには必要不可欠である。情報によっては、その鮮度も重要であり、鮮度の落ちた情報を破棄するなど、情報管理を確実

に実践する必要がある。米国先進事例紹介では、膨大な情報の管理のための専門組織と専門職を

配置し、常に社内向け情報の管理を行っている報告もなされている。情報管理に関しては、ツー

ルだけでなく、組織的に人手によって解決すべき点が多々ある。日本の企業でも数社で同様の事

例を聞いているが、ツールを導入するに留まっている企業が多いのではないだろうか。


191

４．情報過多時代の選択と対策（情報廃棄）

企業において作成する情報は爆発的に増加している。検索技術の進歩と各種記憶装置の低価額化により、多少の情報の多さであれば費用面でのカバ

ーできる。しかし情報の多さはまたいくつかの問題をもたらす。一つは検索結果の精度の問題である。検索ルーチンが、たくさんの候補をあげてくれてもどれ

を読めば良いのかの絞込みは多すぎると時間の浪費をもたらす。もう一つは安くなったと言っても外部記憶装置は無料ではない。ましてやディスク上のデータ

は 365 日 24 時間エネルギーをもらい回転し続けているので地球資源のムダ使いになる。したがって何らかの対策をとって古い情報のふるい落としやあまり活用されない情報は別の媒

体に移す対策を講じる必要がある。かつて、ハードコピーが主流であった時代は、キャビネットの数を制限することにより、古い

情報、使われない情報は別の倉庫センターやシュレッダー行きになっていた。しかし近は媒体に情報が格納されており「情報が満杯だから捨てなければ・・・」の感覚を

肌で感じることがし難くなっている。企業によっては一人当たりの外部記憶装置の容量に制約を

設け制限している場合もあるが、組織ごとに一定量に抑えようとする場合は以下のごとき対策を

講じる必要がある。図表 2-3-4 情報の廃棄方法

情報削除方法具体的方法課題

①期限法一定期間経由した情報（数

年前の情報）を削除する

・5 年前（企業によって変更）の情報は削除することを

原則とする。

②検索実績法今年検索された実績回数

を記録しておき、検索され

ない情報は削除する

・検索結果の回数の実績情報をカウントし保管して

おく必要がある

③検索頻度法検索頻度の少ない情報は

削除する

・検索頻度の低い情報は検索結果のリストには優先

順位を落として表示し、結果的に自然と使われな

いように仕向ける仕組みを準備する。

注意・上記ルールでは困る情報のみ残存する

・法律で保存期間を定められている情報は、その規

則に従う

・情報を削除する場合は、もし必要になったらと、気

になる場合は、テープなどの常時不稼動の媒体に

落としておくこと


192

193

第３章開発保守技術

第１節開発の実態と評価

第２節保守の実態と評価

第３節ユーザビリティと画面デザインプロセス

第４節システム再構築の課題と対策

195

第３章開発保守技術第１節開発の実態と評価

JUAS の開発に関する技術の研究は、毎年急激な進歩を遂げている。

それを受けてこの U 字型開発法はまとめられてある。

改めて進歩の速さに驚いている。

第一巻の第 3 章第 5 節の 9．U 字型開発法のみ置き換えてお読みください。

１．第一巻以降の変化

２．U 字型開発法モデル

３．各要素についての解説

３－１開発の実態と評価

196

１．第一巻以降の変化

システム・リファレンス・マニュアル第一巻を発刊したのは 2005 年 9 月である。これ以降 JUAS

の活動が進みシステム開発についての新しい知見が生まれた。具体的に列挙してみる。・IT 動向調査 2005 年 12 月実施・ソフトェア・メトリックス調査 2005 年 12 月・仕事に役立つ文章作成術日経 BP 社 2005 年 11 月・各種 JUAS 研究会報告書 2006 年 3 月・JUAS のテスト革新セミナー 2006 年 7 月・UVC プロジェクトの発足 2006 年 6 月（user vender collaboration project）（要求仕様書から設計書、プログラムシートまでのプロセスの標準化プロジェクト）上記プロジェクトからシステム開発に関する成果を取り上げて U 字型開発法として整理した

のが次の図表 3-1-1 である。「情報は求めなければ、集まらない。情報は自らがまず発信しなければ、返信は来ない」この原則通り、第一巻を出したことにより「もっと良い方法がある」「ここはこのように改善し

たら」とのご指摘をJUAS会員の皆様から頂戴した。以上の情報を基に整理し直したものである。２．U 字型開発法モデル

要求定義

基本設計

詳細設計

プログラム設計書単体試験

プログラム製造

総合試験

実運用試験

終了

要求定義

基本設計

詳細設計

プログラム設計単体試験


機能結合試験

総合試験

実運用試験

機能確認の重点

使用者への開示拠点

Min化

・各フェーズの発生欠陥は、相対するフェーズのテストで欠陥を発見する。

・後のフェーズの総合試験または実運用試験終了後になって仕様の欠陥が発見される。

ユーザーによるシステム要求

徹底レビュー

単体テスト開始前に全データコンバージョン完了

機能結合試験

ユーザビリティ１

ユーザビリティ２

IT戦略・企画

見積透明性（品質・工期・

生産性）

調達（見積・契約）

新ビジネスモデル

保守・運用

利活用

ライフサイクルコスト（安定性・

信頼性）

ＩＴ投資効果評価

ＤＢパトロール

要求定義から設計・試験までのトレーサビリ

ティ確保

外注プログラマが一緒に仕事をしている間にユーザーにテスト結果を提示し確認・修正する

全工程を通じて可視化、指標化ができるプロジェクトマネジメント（ＥＡＳＥ）の実施

＊＊

注：＊＊開発用ＲＦＰ

＊要件定義用ＲＦＰ

＊

移行移行計画

開始

Ｍｉｎ化

Min化

図表 3-1-1 V 字型開発から U 字型開発へ

./keyword.htm#2002


197

（１）U 字型開発法の名前の由来

V の字と U の字の差は、単に Vender と User の頭文字の差を意識して付けたものではない。 20 年前頃までは、プロジェクトの参加者は本番切替時期まで SE もプログラマも全員残ってい

た。現在はシステムの信頼性・安定性を求めて、総合テストや併行運転などの期間が長期化してい

る。したがって予算削減の面から、プログラマはほとんど稼動開始時期までは残っていない。通常単体テストでプログラムを納品した時点でそのプロジェクトからは離れざるを得ない。そ

の後仕様変更があれば、納品検査をした SE かプログラマの代表者が修正をすることになる。つまりプロジェクトの関係者は単体テスト時期にも多くの人数が参加していることになる。近は、プログラムのコード化作業は二次請負会社やオフショア企業でまかなわれていること

が多い。総合テストや併行運転時期にここが悪い、ここを直せと言われて、他人が作ったプログ

ラム、内容が分りにくいプログラムを SE が修正するので、生産性、品質とも低下しがちになる。そこで「単体テスト時にプログラムの修正はほとんど完了させる」方法が望まれてくる。単体テストで多くの作業を終わらせるので、単体テストの作業幅は広いことを意識して「U 字

型開発法」と命名した。（２）U 字型開発法の範囲

ａ．プロジェクトの開始

V 字型開発法は、要件定義から始まり総合テストを経て実運用試験で終了している。 U 字型開発法の始まりは、IT 戦略・企画があり、見積・契約が入り、それからやっと要件定義

が始まる。あるプロジェクト開発で後の総合テストフェーズに入ってから、重大な仕様変更が

発生したケースがある。「なぜこんな基本的なことを見逃していたのか」と振り返って反省してみ

ると、この戦略・企画フェーズで、ユーザー部門とのコミュニケーションが不足していたことに

原因があった。一般にベンダーのプロジェクトマネージャーは、プロジェクトで失敗すると、「ユーザーが提出

してきた要求仕様書には明確に書いてなかった」と、原因をそこに押し付けていることが多い。その様子を記述したのが、次の 2 つの図である。JUAS、JISA1双方のデータで、同様にプロジ

ェクトの「遅延理由の 40%は、要求仕様書にある」となっている。これは遅延した理由に対しての回答であるためから、ベンダー各社の損害金額でみると実際は

さらに大きいと思われる。「要求仕様書に問題がある」から、「要件定義フェーズのアクションがまずかったと反省するだ

けでは、問題解決ができない」とユーザー企業は考えたので、プロジェクトの始まりは「戦略・

企画フェーズ」であると位置づけたのだ。 V 字型開発法のように「要件定義」がプロジェクトの第一ステップと考えていないところに、

着目して欲しい。次の見積・契約フェーズもプロジェクトを成功させるためにはさらに重要である。要件定義フ

ェーズの登場はその後である。

1 社団法人情報サービス産業協会（JISA）

./keyword.htm#2101


198


図表 3-1-2 工期遅延理由

（JISA データ）2

図表 3-1-3 品質とコストの関係

2 「情報サービス産業における受注ソフトウェア開発の技術的課題に関するアンケート調査 2004」

1.システム化目的不適当1%

2.ＲＦＰ内容不適当4%

6.発注会社選択ミス4%

7.構築チーム能力不足10%

8.テスト計画不十分9%

9.受入検査不十分1%

10.総合テストの不足5%

12.その他18%

5.自社内メンバーの選択不適当5%

11.プロジェクトマネージャーの管理不足

5%

4.要件分析作業不十分16%

3.要件仕様の決定遅れ22%

24%

17%

2%3%4%

9%

6%15%

13%

7%

①要件定義 ②プロジェクト計画③構成管理（変更管理） ④要員の技術力とその維持/トレーニング⑤開発体制 ⑥レビュー活動⑦品質保証体制 ⑧進捗管理⑨外注管理 ⑩プロジェクト間または組織間の調整

①

②

③

④

⑤

⑥

⑦

⑧⑨

⑩

61%

39%


199

ｂ．プロジェクトの終了

ユーザー企業では、実稼動試験をプロジェクトの終了とは考えていない。実稼動試験の後に、システム再構築が主体の現在のシステム開発では、一番負荷のかかる「シ

ステムの移行」が登場してくる。実際に大きな基幹システムを開発した経験があれば、ここでの

トラブル回避とフォローがも精神的・肉体的な難作業であることがおわかりだろう。 IT 部門だけでなく、利用部門の担当者を巻き込んでの経営総合活動がこのシステム移行・切替

である。さらに、プロジェクトによっては顧客を巻き込むことになるので、問題はより複雑にな

る。この難関を乗り越えてやっとサービスイン（カットオーバー）となり運用が始まる。プロジェクトはこの「保守運用」「利活用」から、はじめて効果を発揮し始める。システムは使いこなして初めて企業にとって役に立つ。開発作業はそのための生みのひとつの

過程である。この保守運用・利活用フェーズは、長期にわたって継続する。プロジェクトを立ち上げたときは、システムの寿命を考慮していない場合も多い。しかし、実

際は想像以上に長く使用されることになる。「開発に数年かかったので、サービスインしたら、すぐにハードウェアや OS のサポート期限

切れが来た」などと嘆いても始まらない。これらのサポート切れの問題をプロテクションしたいならば、要件定義以前の契約フェーズで

対処しておかなければならない。要件定義から始まり実運用試験で終わる V 字型開発法は、ベンダー志向の開発方法であり、戦

略・企画フェーズから始まり、利活用が続く U 字型開発法はユーザー志向の開発方法であること

がご理解いただけたであろうか。

./keyword.htm#2101


200

（３）U 字型開発法の要素

U 字型開発法を構成する要素は以下の 15 項目であるが、「未完成」と考えている。ビジネスシステムはその範囲が幅広いため、開発方法やベストプラクティスも数多く存在する

ことは当然である。世の中は広く、知恵者が多い。更なる知恵を頂き改良に努めたい。 U 字型開発法の特徴を整理してみる。

① 企画段階のシステムコンセプト確立･･･要求仕様の変更は、企画段階のユーザー・リーダーのシステム内容理解度の向上で抑制 ② 見積の透明性･･･リスク要因についてのベンダーとの対話 ③ ユーザーによるシステム要求･･･利用者がシステム機能要求を、IT 部門が非機能要求を提示する、裏を読めはダメ ④ 徹底レビュー･･･作成時間の 10％以上時間をかけて慎重に ⑤ ユーザビリティの確保･･･ユーザビリティテストによる利用容易性確保と品質向上 ⑥ UVC 判りやすい仕様の書き方･･･仕様の一貫性 ⑦ 目標を持って管理（EASE）･･･目標の有効性とフォロー ⑧ 単体テストの徹底･･･データコンバージョンプログラムは単体テスト開始前に準備 ⑨ 単体テスト完了でユーザーに開示･･･プログラマが側にいる間に完了を ⑩ 結合、総合、実運用試験の min 化･･･単体テストの徹底 ⑪ DB パトロール･･･データベース間の整合性チェック ⑫ 移行計画は早期準備･･･開発当初より計画し準備 ⑬ カットオーバー日は定時帰宅を･･･no-trouble で ⑭ 保守運用の信頼性向上 ⑮ 利活用が重要･･･投資評価の実施、使いこなしが重要


201

３．各要素についての解説

U 字型開発法の各要素を以下に紹介する。

（１）企画段階のシステムコンセプト確立

───要求仕様の変更は、企画段階のユーザー・リーダーのシステム内容理解度の向上で抑制ａ．企画段階の実行項目

戦略企画フェーズでの実施項目は以下の 9 項目である。 ①事業戦略と該当プロジェクトの関係の明確化と優先度付け ②システム化全体構成図と将来展開予想 ③目標目的の複数案作成と選択（別紙） ④変えるべきもの、変えてはいけないもの（組織、文化、業務プロセス、情報システム、設備、など） ⑤顧客戦略（顧客の顧客含めて） ⑥概要機能と範囲、概略予算と効果、 ⑦インフラ基盤整備 ⑧QCD の優先度付け ⑨推進体制（利用効果責任者、開発責任者、維持運用責任者）企業においてビジネスモデルを革新し、新しいシステムを導入する場合は慎重にならざるを得

ない。システムは要件定義から始まるのではない。この「方向付けのフェーズ」が重要である。

要件定義の前に上記 9 項目を押さえておくことが、後に続く開発工程に大きく影響を与える。

目的：在庫管理システムが欲しい

目標：不良在庫の減少

販社の在庫減少

工場在庫の減少

評価：＊効果測定はどのように行うのか？

＊ユーザー満足度は何で測るのか？

＊このシステムが完了したら次は何を望むのか？

実行案：在庫量を把握表示

不良在庫の販売

ＳＣＭ

図表 3-1-4 利用者の願望にあったシステムを作成するために


202

（２）見積の透明性

───リスク要因についてのベンダーとの対話

ａ．リスク見積アシステム特性を公開する見積

ユーザーからのシステム開発を受託することはベンダーにとって相当なリスクを伴う。ベンダーにとっては「見積金額＝開発費用＋利益＋リスク金額」

になるが、現状ではこのリスク金額は、発注側のユーザーにとって、「どのような意味を持っているのか」「ユーザーが何を努力すれば安くなるのか」はほとんどの場合、霧の中である。ほとんどのベンダーは「見積金額一式」で回答してくるので、折衝のしようがない。ベンダーのリスク見積モデルは 2 種類あり、その一つはリスクを発注者にも公開して相互にそ

のリスクを低減する方式であり、もう一つはリスクも見積金額に内包し発注者には見えないよう

にする方式である。後者が現状の日本では一般的であり、ユーザー企業からは改善を望まれてい

る。リスクには、システムの持つシステム特性リスクと現存プロジェクトチームの業務能力リスク

とがあり、ベンダー各社の見積りはリスク要素ごとに試算される。システム特性リスクとは、次の要素に分けて試算される。・システムの先進事例・要求仕様の網羅性・規模の大小・業務機能の難易度・要求機能のレベル・DB 構成の難易性・移行条件・現行保証の有無・標準化のレベル・レビューの充実度・開発・テストの環境・テスト密度・制約条件（納期･技術）など業務能力特性は次の要素に分けて試算される。・個人の能力・チームの能力・外注企業の能力・ハードウェア、ソフトウェアの経験度・ツールの経験度この業務能力特性はベンダーの費用の中に自社開発能力として織り込んでいただければよい。残りの問題はシステム特性リスクである。このシステム特性リスクを明確にし、見積時点でユ

ーザーに公開して、相互の努力によってリスクの低減を図るのが次に述べるリスク管理モデルで

ある。


203

イ JUAS 推薦の見積モデルとその特徴

ユーザーの求めるリスクが公開される見積モデルを持っており、なお一般に内容を公開できる

ベンダーを求めていたところ、ジャステック社に協力していただけることになった。ジャステック社の見積りモデルは一つのモデルであり、実プロジェクトへ適用するのには数々

の工夫を必要とするが、ここまでリスク管理の内容をオープンにし、可視化されたモデルは世界

でも珍しい。このジャステック社の見積りモデルは非常に優れたものであり、次の特徴を備えている。 a）この見積モデルは当然のことながら契約の基盤になるが、開発に入っても進捗管理の中で、

このリスク要素はフォローされる。したがってユーザーとの約束の実施状況、両社の努力結

果も明確にされるのでリスクとして積んだ環境変化による変動費（「リスク費」と呼んでもよ

い）の見直しが可能になる。しかし、一般的には契約金額の中に積み込まれたリスク費用は

ベンダーの中でのさまざまな対策に消費され、ユーザーに公開されることはない。 b）このリスク見積費用の中にはベンダーの生産性低下の要素は含まれていない。高価な SE を

使う、生産性の低い SE を使用するのはベンダーの内責であって、ユーザーの努力外の事項

である。しかし、一般の見積りモデルはベンダーの生産性低下の要素も区分されずにコスト

に盛り込まれている場合が多い。その点もユーザーにとって見積り費用の妥当性を分かりに

くくしている。 c）このリスク見積りはジャステック社では環境変数値の決定により実践している。さらに環境

変数値の予実差異分析はリスク管理以外に、開発プロセス改善に活かされている。ユーザー

協力に基づくプロセス改善は、次の見積り費用の低減に結びつく。この見積りモデルには 40 項目以上のリスク項目がある。各リスク項目はユーザーの特性によ

る変動要因（以降「外責」という）とベンダーの能力による変動要因（以降「内責」という）と

に、すべて区分されている。この外責での変動要因の中で、「ユーザーが努力すれば効果が大きく上がる項目は何なのか」「どれに注力すればどの程度の効果があるのか」を JUAS のシステム開発生産性プロジェクトのメンバーと議論して整理したのが、次表の環境

変数である。「こんな協力をすれば安くしてもらえるのか」「こんなことで高くなっていたのか。それなら協力するよ」と期待するユーザーが多く出現することを期待している。


204

（ジャステック社資料より）

図表 3-1-5 参考：コスト見積モデルと環境変数

ウリスク評価表

このリスク評価表はジャステック社の環境変数を基準にして、JUAS で議論し、整理したもの

である。この第 3 章第 4 節「システム再構築の課題と対策」の末尾に、参考資料として「生産性

環境変数表」「規模環境変数表」を添付しているので参照していただきたい。リスクは終的には､次のどちらかである。「作成する設計書、あるいはプログラムなどの生産物の量に影響する」「作業の効率に影響する」かのどちらかである。前者を「規模環境変数」と呼び、JIS の品質特性の機能性（4）、信頼性（3）、使用性（3）保

守性（3）に関するリスク要因を表している。後者を「生産性環境変数」と呼び、業務特性（1）、ハードウェア特性（1）、ソフトウェア特性

（1）、コミュニケーション特性（4）、開発環境特性（2）、工程入力情報特性（1）、顧客の協力特

性（1）、改造・再構築特性（3）、機能性（4）、効率性（2）、保守性（2）、移植性（4）に関する

リスク要因を表している。3 重要なポイントは外責評価基準の影響度であり、各工程にこの副特性がどの程度の影響を与え

るのかを％で表示してある。例えば「設計工程のある項目のリスクが 10％と評価されれば、その

工程にかける負荷を 10％増やして見積ってある」と言う意味になる。これは経験値であり直面し

ているプロジェクトの特性によって影響度は変わってくる。これはベンダーに依頼してどのよう

に評価しているのかを回答してもらえばよいが、そのための標準的な値とまずは考えてよい。こ

の方式が世の中に普及しデータが集まれば、そのときにはまた修正する。影響度の評価が低い場合は-10％、高い場合は 50％などと表されているが、これは標準的なサ

ンプルである。リスク項目が、この項目の開発負荷に与える影響の大きさを表している。上記事

3 （）内は副特性の数を表している。副特性ごとに評価の観点、特記特例事項を付してある。

コスト見積りモデルと環境変数

【コスト見積りモデル】

　ある工程ｉの生産物量をＶｉ、生産性Ｐ

ｉ、標準生産物量をＶBｉ、生産性の

ベースラインをＰBｉ、で表現すると、コストＣｉは次式で求まる。

　　

Ｃｉ　＝　Ｖｉ×Ｐｉ　＝　ＶBｉ（１+aｉ）×ＰB

ｉ（１+bｉ）

但し、 aｉ：（Σαｉｊ）　　 bｉ：（Σβｉｊ）　

　aｉ、 bｉは、それぞれＶBｉおよびＰB

ｉに対して開発環境の違いや品質要求の

多寡による変動を吸収する｢環境変数｣と呼ぶパラメータである。

（αｉｊ：生産物量環境変数、βｉｊ：生産性環境変数）

【環境変数】


205

例では 60％の幅があることを示しているが、中には上下の幅が 10%しかない項目もある。影響

度の大きい項目を重点的に検討したほうが効率的である。当然のことながら上流工程の要件定義、設計の段階でのリスク影響度は大きくなる。ベンダー内の内責評価基準はユーザーと協議しても意味がないので省いてある。

エこのモデルの活用方法このリスク評価表を使用する手順は次のようになる（図表 3-3-7）。

図表 3-1-6 リスク評価表を使用する手順

見積要求仕様書を作成する

ベンダーに提示し見積依頼をする。同時にこのリスク

評価表への記入提示を求める

リスク評価表に基づきユーザー側の努力と見積金額

への影響度を議論する

実行可能な計画の作成と開発着手

（計画時に品質、工期、生産性を指標化する）

厳密な進捗管理とリスク項目の実施状況の確認

（各工程の切れ目で必ず実施する）

品質、工期、生産性指標の達成努力

システム開発完了後の各種指標とリスクの分析評価

による金額の精算とプロセス改善

１

２

３


206

①ユーザーが作成した見積要求仕様書に基づいて見積もり、プロジェクトの計画を作成し合意するこのモデルでは、ユーザーが作成した見積要求仕様書を入力して、ベンダーがリスク評価表に

基づいてリスクを評価して、リスク金額とともにユーザーに公開する。ユーザーおよびベンダーはリスクに対する認識を摺り合わせた上で、相互に協力してリスクを

低減するリスク低減策を議論する。リスク評価表に記載するリスク項目は開発コストの変動要素

なので、これを利用してより積極的にコストを削減する改善策を議論することもできる。次に、

リスク低減策および改善策を適用することを前提として、ユーザーおよびベンダーが協力してリ

スクを再評価し、対策の実施に投ずるコストと対策による効果とを対比して、対策の妥当性を確

認し合意する。結果として、リスク金額は小さくなり、改善策を施すことにより、見積もり金額

を削減することができる。対策の合意に基づいて、実行可能なプロジェクトの計画を作成して開発に着手するが、プロジ

ェクトの進行中に対策の効果を確認できるように、品質、工期、生産性の目標を指標として設定

して、ユーザーおよびベンダーの間で合意しておくことが重要である。通常、見積もり行為はこれから基本設計を実施する、あるいは詳細設計を実施するときに行う

が、時にはユーザーが作成した見積要求仕様書を見直すこともあるかもしれない。このように、

より上流の工程で見積もるときほど不確実性は高くなる。したがって、契約を工程毎に区切るな

ど多段階に契約する方式を採用された方が、契約に含むリスク金額を低く抑えることができる。

②プロジェクトの進行中にリスクをフォローして見直すと共に対策する見積もりには不確実性が内在しているので、開発を開始した後でもリスクをフォローする。対

策の実施状況の確認はもとより、プロジェクトの計画時に、品質、工期、生産性の目標を指標化

しているため、対策の効果をより客観的に確認できる。少なくとも各工程の切れ目でユーザーお

よびベンダーが相互に確認することが重要である。相互に合意した対策が遵守されていないことが確認された場合は、当該工程に残作業が残って

いる可能性が高い。その時は、ユーザーは別途費用4を投じて残作業を片付けるか、別の方法で回

避するのかを議論して進めることになるが、放置して後工程で手戻りなどの混乱によるコストが

増加するのと比較すれば、安く済むことになる。このように、ユーザーおよびベンダー双方の努力の結果は開発工程ごと、あるいは WBS 毎に

明確にされ、アクションは早く取られることになる。この効果も大きい。

4対策が達成されることを前提とした契約にはこの対策費用は含まれていないので、ユーザーは対策が遵守されない場合

に備えて、予算を確保しておくことが肝要である。


207

③システム開発完了時に実績を評価して、プロセスの改善策を立案すると共に、リスクの実績を評

価して精算するシステム開発完了時には、ユーザーおよびベンダーが協力して、リスクの実績を評価する。プ

ロジェクトの計画で設定した品質、工期、生産性の指標と実績とを対比して、その差異理由をリ

スク要因による「影響度」の相違および対策の妥当性とで説明する。この結果、当該プロジェク

トで実施し効果を確認した対策を標準化して、プロセスの改善に活用される。ユーザー協力に基

づくプロセス改善は、次の見積り費用の低減に結びつく。後に、システム開発完了時に評価し

たリスク金額の実績を精算する。なお、「コスト＋変動コスト（リスク金額）＋利益」で契約するのか、「コスト＋利益」で契約

し、リスクが氷解した時点で、リスク金額を再配分するのかは、ユーザーとベンダーの実力によ

って使い分けられることになる。いずれにしても、ユーザーはリスク金額の精算に必要な予算を

確保しなければならないので、ユーザーの社内稟議は「コスト＋変動コスト（リスク金額）＋利

益」で了解を取っておく方がよい。このように、本見積もりモデルを活用することは、ユーザーとベンダーとが互いの責任と役割

を認識して協力することを促進する。結果として、ベンダーの健全な努力競争がなされ、ユーザ

ーのシステム開発コスト削減に繋がることを期待する。（３）ユーザーによるシステム要求

───利用者がシステム機能要求を、IT 部門が非機能要求を提示する、裏を読めはダメａ．利用部門が作成できる RFP ア基本的考え方

企業において毎日実行している実際の業務を一番よく知っているのは業務部門（＝システム利

用部門）である。

・「何をシステム化してほしいのか」「前提条件、実行後の評価方法」は通常の文章で表現すれ

ばよく、特別な知識・能力を必要としない。・プログラムの作成に結びつく業務処理手順を記述することは、専門家でない実務者には、難

しい業務である。したがってその部分も、できる人は作成してもらってかまわないが、一般

には専門家の SE に依頼することになる。・システム化する、しないにかかわらず、企業においては「企業／事業の規定」「「業務規定（基

本的商習慣などの記述を含む）」を整備しておかねばならない。・これらを整備しておくことは業務部門の義務である。・企業の情報システム部門は、開発運用の支援者であり推進者でもある。常に受身では IT 部門の意味がない。SE 自らが業務部門あるいは部門間の問題を発見し改善す

るモデルを見つけ提案できなければならない。業務部門のレベルアップを支援する傍ら、新技術・

新手法を学び問題感知力を発揮してさらに上のレベルの提案活動ができるように期待したい。


208

イ前提条件

実務にたずさわっている人は、必ずしもコンピュータの専門家ではなく、システムドキュメン

トの作成には限界がある。したがって、下記のような前提条件を設ける必要があると思われる。

①利用者は自らが必要とする機能が何であるかを開発者に要求する。

ただし、IT に詳しい開発 SE が明確に定義した方がよい項目はそちらに任せる。例：「画面から入力されるデータには新規、訂正、追加、削除がある」これらの処理は結構複雑で

難しいので開発者に任せる。「どのようにするか」まで記述することは利用者にとって難しい作

業である。

②入力データを基に例外作業が発生する場合は、その例外作業項目を構造図などで必ず記述する。

③この例外作業を具体的にシステムにどのようなプログラムにして取り入れるのかは開発者に任

せる。

④利用者は開発者に対して「文章の裏を読め」と言わないで、「何が例外作業にあたるのか」を明

確にする。ルール化できない例外作業は「異常作業」としてシステム外の扱いとなる。誤解が

生じないように極力具体的な表現方法を取る。

このユーザーとベンダーとの間で、「見積要求仕様書作成の前提条件」を明確にすることは、非

常に重要な課題である。「RFP があいまい」とベンダーSE が言う時があるが、どこまで書かなければならないのかは

今一つ明確ではない。これは、両者が乗り越えてゆかねばならないテーマである。暗黙知を含め

てこの前提条件を活用することによって、両者の負担が減少するのであれば、積極的に活用しな

い手はない。

ウユーザーが定義するドキュメント業務担当者はビジネスの動きを調査分析し、その機能／業務ルール／業務処理フロー／帳票類

などを明確にし、業務システム（業務の仕組み）として提示せねばならない。このために、業務担当者は図表 3-2-3、図表 3-2-4 に示される 14 種のドキュメントを作成しな

ければならないが、現実の対応力に合わせて 5 段階レベルで対応することになる。特にレベル１

～３の範囲では、IT 部門の SE やベンダーの協力に負うところが大きい。なお、個別業務処理定義書はさまざまな記述様式が存在する（HIPO、フローチャートなど後

述の事例参照）。適宜使い分ければよい。レベル 1 から 5 に移行するに従いベンダーへの支払いは減少する。ユーザー自ら業務内容を吟

味、整理することによる業務見直しには副産物も大きい。このため、できるだけレベルを上げて

対応することが望まれる。レベルが低いままに広範囲の作業をベンダーに依頼したドキュメント

のチェックについてはユーザー企業関係者がじっくり時間をかけ確認しなければならない。全ド

キュメントの作成時間をベンダーに確認し、その 10％以上の時間をかけチェックしたシステムに

は欠陥が少ないことが、JUAS の調査でも確認されている。


209

エ業務担当部門と IT 部門の作業分担の考え方業務担当部門は以下の作業を分担する。 ①ビジネスプロセスの分析整理 ②ビジネスプロセスに関連するビジネスルール／業務ルール（例外処理のルール化） ③ビジネスプロセス間の指示／帳票による連携関係の分析・整理（正常処理の連携と例外処理の連携を含む） ④ビジネスプロセスに関連するデータ、情報、知識の整理 IT 部門のシステム設計者はシステムの専門家として以下の作業を行う。 ①ビジネスプロセス内のビジネスロジック ②ビジネスデータのデータベース構造 ③情報システム自体の例外事態に対応する処理やルール ④詳細な画面レイアウト、帳票レイアウト

ｂ．業務システム定義の記述レベルとその構成業務部門だけでは作成が困難なドキュメントもあるので 5 段階のレベルを設定した。レベル－1 のビジネス機能提示レベルの定義は、これまでの RFP の記述内容と同等である。レベル－2 のビジネスプロセス提示は、簡単な業務システムや新規の業務システムを記述する

際に利用され、IT 部門やシステムベンダーの知見を活かして具体化する場合に採用される。レベル－3 は、標準的な業務システムの定義で使用されるレベルであり、ISO9000 等の認可を

受けている企業の業務部門は問題なく記述できるレベルである。システムベンダーのシステム設

計者はこのレベルの仕様から具体的な情報システム／アプリケーションソフトウェア設計を行う

知見とスキルを持たねばならない。レベル－4 では個別業務処理定義書までを提示する。このレベルの場合、システムベンダーが

プログラム設計を中心に実施することとなり、発注側はシステム開発のコストダウンを要求する

ことができる。レベル－5 では個別業務処理定義書とデータ項目定義書までを作成する。システムベンダーは、

レベル－4 以上にプログラム設計工数の削減を要求される仕様となる。

ケース 1 とケース 2 は企画段階の作業から、IT 部門の SE やベンダーに依存する形態をとるこ

とになる。各ケースによりベンダーに依存する範囲、作業量が大きく異なり発注価額も当然異なってくる。

ベンダーはユーザー企業が作成した見積要求仕様書を熟読し、理解しがたい部分や誤解しかねな

い部分、ドキュメント間で整合性が取れていない部分、別な解法の方が良いと思われる部分など

がある場合は、その旨を発注者側に確認取らねばならない。どこまでこの見積要求仕様書の内容を読み切れるかが、ベンダーの実力の現れるところである。なお、図表 3-1-8 でタイトルを「エンドユーザーによる業務システム仕様書」としたのは、ド


210

キュメント A～D はユーザー部門では必要であるが、見積時に必ずしも添付する必要はないので、

一連のドキュメント群を業務システム仕様書と名づけた。ドキュメント 1～10 は見積要求仕様書

となる。一連のドキュメントの事例を収録してあるので参考にしていただきたい。

図表 3-1-7 業務担当部門による業務システム仕様書の記述レベル5

（ビジネスシステム定義研究 2004）

ｼｽﾃﾑ設計開発の合理化/ｺｽﾄ低

減

綺麗な構造設計/ｺｽﾄ低減ｼｽテﾑ設計開発の合理化/ｺｽﾄ低

減設計、納入品の瑕疵責任納入/契約仕様の実現

ｼｽﾃﾑ設計の効率化の推進納品仕様/成果物の仕様確認詳細設計/機能性能の承認基本設計承認の責任要求仕様承認の責任

レベルｰ５レベルｰ４レベルｰ３レベルｰ２レベルｰ１

業務ｼｽﾃﾑの運用・操作の条件設定



運用・操作要件書10

ﾃﾞｰﾀ項目の属性を定義ﾃﾞｰﾀ項目定義書９

画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄ８

基本的に必要な画面/帳票一覧基本的に必要な画面/帳票一覧基本的に必要な画面/帳票一覧画面/帳票一覧７

各個別の業務処理手順を定義各個別の業務処理手順を定義個別業務処理定義書６

業務処理上の社内ﾙｰﾙを定義業務処理上の社内ﾙｰﾙを定義業務ルール定義書５

DFD方式での上位DFDとして作

成


成機能情報関連図４

業務処理ﾌﾛｰ指示（含む例外処理）



業務流れ図３

ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ関連図２

ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の中小分類定義

ﾋﾞｼﾞﾈｽ機能の大分類定義

ﾋﾞｼﾞﾈｽ機能構成表１

業務ｼｽﾃﾑのITﾍﾞﾈﾌｨｯﾄ定義業務ｼｽﾃﾑのITﾍﾞﾈﾌｨｯﾄ定義業務ｼｽﾃﾑ化の目標設定業務ｼｽﾃﾑ化の目標設定業務ｼｽﾃﾑ化の目標設定

ｼｽﾃﾑ化目標定義書D

企業/業務上の戦略ﾙｰﾙ企業/業務上の戦略ﾙｰﾙ企業/業務上の戦略ﾙｰﾙﾋﾞｼﾞﾈｽﾙｰﾙ定義書C

業務と対外系/他部門間との連携業務と対外系/他部門間との連携業務と対外系/他部門間との連携ﾋﾞｼﾞﾈｽ連携図B

IS部門で企業/事業全体機能定

義


義


義ﾋﾞｼﾞﾈｽ機能関連図A

To-Beﾍﾞｰｽのｼｽﾃﾑ機能強化と

適化の追求

To-BeﾍﾞｰｽのIT処理方法からの

改善改革と構造的で明快なｼｽﾃﾑ構築

更なるTo-Be機能への展開とｼｽﾃﾑ設計と納品物のQCD追求

提示ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽの改革を実現するｼｽﾃﾑ構築を実現

RFPのﾋﾞｼﾞﾈｽ機能からTo-Beのあるべき姿

のｼｽﾃﾑ機能を提案

ベンダ側責任2

To-Beﾍﾞｰｽでのｼｽﾃﾑ構築の発

注によるｼｽﾃﾑ構築効率追及

To-Beﾍﾞｰｽの業務処理方法の提

示による効果的な発注

As-Isﾍﾞｰｽ機能拡張で業務ﾌﾛｰを通常業務/例外業務処理につき

提示

既存ｼｽﾃﾑ再構築ではﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ定義と既存ｼｽﾃﾑ仕様提示で発注

RFPﾚﾍﾞﾙでﾍﾞﾝﾀﾞ提案

書をﾍﾞｰｽに要求仕様書を明確にしｼｽﾃﾑ構築

ユーザ側責任1責任分担

個別業務処理/ﾃﾞｰﾀ項目提示個別業務処理提示業務ﾌﾛｰ提示ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ提示ﾋﾞｼﾞﾈｽ機能提示

仕様の責任と記述項目

ｼｽﾃﾑ設計開発の合理化/ｺｽﾄ低

減

綺麗な構造設計/ｺｽﾄ低減ｼｽテﾑ設計開発の合理化/ｺｽﾄ低

減設計、納入品の瑕疵責任納入/契約仕様の実現

ｼｽﾃﾑ設計の効率化の推進納品仕様/成果物の仕様確認詳細設計/機能性能の承認基本設計承認の責任要求仕様承認の責任

レベルｰ５レベルｰ４レベルｰ３レベルｰ２レベルｰ１





ﾃﾞｰﾀ項目の属性を定義ﾃﾞｰﾀ項目定義書９

画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄを定義画面/帳票ﾚｲｱｳﾄ８

基本的に必要な画面/帳票一覧基本的に必要な画面/帳票一覧基本的に必要な画面/帳票一覧画面/帳票一覧７

各個別の業務処理手順を定義各個別の業務処理手順を定義個別業務処理定義書６

業務処理上の社内ﾙｰﾙを定義業務処理上の社内ﾙｰﾙを定義業務ルール定義書５


成


成機能情報関連図４




業務流れ図３

ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ間の関連定義ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ関連図２

ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の細分類定義ﾋﾞｼﾞﾈｽ機能の中小分類定義

ﾋﾞｼﾞﾈｽ機能の大分類定義

ﾋﾞｼﾞﾈｽ機能構成表１

業務ｼｽﾃﾑのITﾍﾞﾈﾌｨｯﾄ定義業務ｼｽﾃﾑのITﾍﾞﾈﾌｨｯﾄ定義業務ｼｽﾃﾑ化の目標設定業務ｼｽﾃﾑ化の目標設定業務ｼｽﾃﾑ化の目標設定

ｼｽﾃﾑ化目標定義書D

企業/業務上の戦略ﾙｰﾙ企業/業務上の戦略ﾙｰﾙ企業/業務上の戦略ﾙｰﾙﾋﾞｼﾞﾈｽﾙｰﾙ定義書C

業務と対外系/他部門間との連携業務と対外系/他部門間との連携業務と対外系/他部門間との連携ﾋﾞｼﾞﾈｽ連携図B


義


義


義ﾋﾞｼﾞﾈｽ機能関連図A

To-Beﾍﾞｰｽのｼｽﾃﾑ機能強化と

適化の追求

To-BeﾍﾞｰｽのIT処理方法からの

改善改革と構造的で明快なｼｽﾃﾑ構築

更なるTo-Be機能への展開とｼｽﾃﾑ設計と納品物のQCD追求

提示ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽの改革を実現するｼｽﾃﾑ構築を実現

RFPのﾋﾞｼﾞﾈｽ機能からTo-Beのあるべき姿

のｼｽﾃﾑ機能を提案

ベンダ側責任2

To-Beﾍﾞｰｽでのｼｽﾃﾑ構築の発

注によるｼｽﾃﾑ構築効率追及

To-Beﾍﾞｰｽの業務処理方法の提

示による効果的な発注

As-Isﾍﾞｰｽ機能拡張で業務ﾌﾛｰを通常業務/例外業務処理につき

提示

既存ｼｽﾃﾑ再構築ではﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ定義と既存ｼｽﾃﾑ仕様提示で発注

RFPﾚﾍﾞﾙでﾍﾞﾝﾀﾞ提案

書をﾍﾞｰｽに要求仕様書を明確にしｼｽﾃﾑ構築

ユーザ側責任1責任分担

個別業務処理/ﾃﾞｰﾀ項目提示個別業務処理提示業務ﾌﾛｰ提示ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ提示ﾋﾞｼﾞﾈｽ機能提示

仕様の責任と記述項目

5空白部分は企業内 IT 部門 SE やベンダーSE の支援を受けて作成する。


211

図表 3-1-8 エンドユーザーによる業務システム仕様書の利用目的と利用者


情報システム開発条件

（納品物検収の条件）

業務担当者

ＩＳ担当者

①業務システム上の操作要件、データ処理要件を明確化

②情報システムとしての運用／保守、セキュリティ／安全



（アプリソフト設計条件）

業務担当者

（ｼｽﾃﾑ構築担当者）

①ビジネスデータの属性を定義

（情報ｼｽﾃﾑ構築依頼後のｼｽﾃﾑ構築者の設計ｽｹｼﾞｭｰﾙに合わせて依頼下の業務担当部門が承認）

データ項目定義書９



業務担当部門長

業務担当者

①ビジネスデータの詳細を把握整理する基本ベース

②情報システムとして作り込む画面／帳票設計の参照

画面／帳票レイアウト

８


（納入物検収の基本条件）


業務担当者

①情報システムとして開発依頼する画面／帳票類を明確化

（ﾋﾞｼﾞﾈｽﾃﾞｰﾀの処理、人間がﾋﾞｼﾞﾈｽ／業務ﾙｰﾙの判断処理を行なう上の画面帳票、管理統制上の帳票を）

画面／帳票一覧７




業務担当者

①各ビジネスプロセスの業務ルール適用手順の明確化

（業務担当者はHIPO方式、ﾌﾛｰﾁｬｰﾄ方式を利用：情報ｼｽﾃﾑ設計側では、UMLｼｰｹﾝｽ等を）個別業務処理定義書

６

業務ｼｽﾃﾑ基本設計条件



業務担当者

①ビジネスプロセスに準じた社内業務の意思決定ルール把握

②取引ルール、リソース関連ルール、意思決定ルール明確化

業務ルール定義書５

業務システム基本設計条件

（基本ｼｽﾃﾑ構造条件）


業務担当者

①ビジネスプロセス間の基幹ビジネスデータの関係を把握（ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ関連図上に基幹ﾋﾞｼﾞﾈｽﾃﾞｰﾀを追記し作成が可能）（「業務流れ図からIS側が作成）

機能情報関連図４


（見積依頼範囲の指定）


業務担当者

①対象業務の組織とビジネス（処理）機能の基本関係把握

（業務担当者が現状の業務処理（As-Is）を記述し、業務改革／改善を行いTo-Beを作る）業務流れ図３

基本業務処理の構成指定



業務担当者

①対象の業務システムの概要、基本構成の整理把握

（詳細に整理する時は、「業務流れ図」または「機能情報関連図」をしようすることが望ましい）

ビジネスプロセス関連図

２

業務ｼｽﾃﾑのIT化対象指定



業務担当者

①対象に関連する全てのビジネス機能の整理把握

②各ビジネス機能のシステム化方針の設定

ビジネス機能構成表

１

情報ｼｽﾃﾑ基本設計指針

（契約の基本条件）


ＩＳ部門長

①情報システムの目的と狙いの明確化

②情報システムの投資効果の発揮方法の作り込み方針

システム化目標定義書

Ｄ

ビジネスルールの整理

（通例、例外のルール）


業務担当者

①社内外の責任部門とのビジネスルールの把握

②商流、物流、金流上の企業規範ルール

ビジネスルール定義書

Ｃ

ビジネスルールの把握業務担当部門長

業務担当者

①開発対象に関係する社内外の責任部門との関係把握

②対象内の責任分担組織間の商流、物流、金流の関係把握

ビジネス連携図Ｂ

全社システム上の関係ＩＳ部門長

ＩＳ企画担当

①ＩＳ部門が全社のビジネス機能を把握

②ＩＳ部門が全社のビジネス機能のシステム化度合把握

ビジネス機能関連図

Ａ

見積仕様作成上の利用承認者／利用者利用目的記述項目


（納品物検収の条件）

業務担当者

ＩＳ担当者

①業務システム上の操作要件、データ処理要件を明確化

②情報システムとしての運用／保守、セキュリティ／安全




業務担当者

（ｼｽﾃﾑ構築担当者）

①ビジネスデータの属性を定義

（情報ｼｽﾃﾑ構築依頼後のｼｽﾃﾑ構築者の設計ｽｹｼﾞｭｰﾙに合わせて依頼下の業務担当部門が承認）

データ項目定義書９




業務担当者

①ビジネスデータの詳細を把握整理する基本ベース

②情報システムとして作り込む画面／帳票設計の参照

画面／帳票レイアウト

８




業務担当者

①情報システムとして開発依頼する画面／帳票類を明確化

（ﾋﾞｼﾞﾈｽﾃﾞｰﾀの処理、人間がﾋﾞｼﾞﾈｽ／業務ﾙｰﾙの判断処理を行なう上の画面帳票、管理統制上の帳票を）

画面／帳票一覧７




業務担当者

①各ビジネスプロセスの業務ルール適用手順の明確化

（業務担当者はHIPO方式、ﾌﾛｰﾁｬｰﾄ方式を利用：情報ｼｽﾃﾑ設計側では、UMLｼｰｹﾝｽ等を）個別業務処理定義書

６




業務担当者

①ビジネスプロセスに準じた社内業務の意思決定ルール把握

②取引ルール、リソース関連ルール、意思決定ルール明確化

業務ルール定義書５

業務システム基本設計条件

（基本ｼｽﾃﾑ構造条件）


業務担当者

①ビジネスプロセス間の基幹ビジネスデータの関係を把握（ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ関連図上に基幹ﾋﾞｼﾞﾈｽﾃﾞｰﾀを追記し作成が可能）（「業務流れ図からIS側が作成）

機能情報関連図４




業務担当者

①対象業務の組織とビジネス（処理）機能の基本関係把握

（業務担当者が現状の業務処理（As-Is）を記述し、業務改革／改善を行いTo-Beを作る）業務流れ図３

基本業務処理の構成指定



業務担当者

①対象の業務システムの概要、基本構成の整理把握

（詳細に整理する時は、「業務流れ図」または「機能情報関連図」をしようすることが望ましい）

ビジネスプロセス関連図

２

業務ｼｽﾃﾑのIT化対象指定



業務担当者

①対象に関連する全てのビジネス機能の整理把握

②各ビジネス機能のシステム化方針の設定

ビジネス機能構成表

１

情報ｼｽﾃﾑ基本設計指針

（契約の基本条件）


ＩＳ部門長

①情報システムの目的と狙いの明確化

②情報システムの投資効果の発揮方法の作り込み方針

システム化目標定義書

Ｄ

ビジネスルールの整理

（通例、例外のルール）


業務担当者

①社内外の責任部門とのビジネスルールの把握

②商流、物流、金流上の企業規範ルール

ビジネスルール定義書

Ｃ

ビジネスルールの把握業務担当部門長

業務担当者

①開発対象に関係する社内外の責任部門との関係把握

②対象内の責任分担組織間の商流、物流、金流の関係把握

ビジネス連携図Ｂ

全社システム上の関係ＩＳ部門長

ＩＳ企画担当

①ＩＳ部門が全社のビジネス機能を把握

②ＩＳ部門が全社のビジネス機能のシステム化度合把握

ビジネス機能関連図

Ａ

見積仕様作成上の利用承認者／利用者利用目的記述項目

ｃ．見積要求仕様書の活用と課題

JUAS 業務システム見積要求仕様書を利用した見積／調達方法を採用しようとした場合、下記

の現実に直面することが予想される。 ①業務部門が業務システム仕様の作成能力に乏しい ②IT 部門の方が業務システムの内容を知っている ③システムベンダーのノウハウを活かす方が良い今までは、IT 部門が業務部門に成り代わり、業務システムの仕様作成を行い、業務システム設

計構築を長く依頼してきたシステムベンダーとの良好な関係を保ちつつ、RFP（提案要求書）を

ベースとして上記の課題を解決してきた。今後は、業務部門、IT 部門はお互いの甘えの構造をなくし、企業組織上での分業／協業を効果

的に行う役割分担／責任分担を明確にする必要がある。特に、グローバルに事業拠点を展開する

企業において経営者は、業務分担／業務責任／業務統括／業務評価を明確に行う能力を発揮しな

ければならない。一般的に、この見積要求仕様書によるシステム設計開発構築の調達を行うことは普及していな

い。すなわち、調達内容を明確に指示できないがゆえにラフな RFP によるベンダー主導の契約

./keyword.htm#1801


212

管理／遂行を行う方式が採用されており、これを前提にソフトウェア産業や情報処理学会等で「如

何に作るか」の議論がなされている。これまでは、業務部門で明確にできない発注仕様について IT 部門がベンダーとの橋渡しを行

ってきた。つまり、IT 部門とベンダーでの多くの重複作業工数をかけて設計を進めてきた。しかし、一般的な調達において、調達側が概要を指定して発注し、それを受託したベンダーは

責任を持って基本設計／詳細設計を行うのが常識である。今後は、企画仕様のレベルでの概要を

ベースに、基本設計／詳細設計のプロジェクトの進行を管理し、開発責任を全うできないシステ

ムベンダーは、システムベンダーの資格がないと判断すべきである。赤字プロジェクトが発生した場合に、ベンダー側は「ユーザーが見積仕様書をきちんと書いて

くれなかった」と弁明するが、仮にユーザー側が完全に書いてしまったら、残りの作業はコード

化作業のみが残り、楽しみのある作業は残らないことになる。優れたアイデアと創造性の発揮があるからこそ SE の仕事は楽しみがある。前提条件の確認な

どを踏まえた上でベンダーSE の創造性の発揮も、一つの要因として認められる業務体系の構築

が望まれる。

引用：EMｼｽﾃﾑｺﾝｻﾙﾃｨﾝｸﾞ

事業計画（ﾋﾞｼﾞﾈｽﾌﾟﾗﾝ）の設定

経営戦略/事業戦略の設定

新規事業/事業・業務改革の推進

情報システム化戦略策定

業務担当部門情報システム部門システムベンダ

情報システム応用技術の提供情報システム化/IT動向情報提供

企業ﾋﾞｼﾞﾈｽ機能/ﾃﾞｰﾀ構造の提供

業務ｼｽﾃﾑ記述方法の支援

情報ｼｽﾃﾑ設計開発構築の標準

業務ｼｽﾃﾑ構築要件書の作成

業務ｼｽﾃﾑ仕様書の作成

業務ｼｽﾃﾑ構築見積要求使用書（RFQ）

ｼｽﾃﾑﾍﾞﾝﾀﾞ選定基準/評価の提供

見積依頼/見積仕様評価/契約交渉

発注処理：契約締結

情報システム構築実績情報等の提供

見積仕様書作成・提示・交渉

受注処理：プロジェクト発足

受注責任発注責任

ﾍﾞﾝﾀﾞ業務/ﾉｳﾊｳ

ｼｽﾃﾑ化ﾉｳﾊｳ

仕様作成能力

設計責任の追及納品物品質の追求納期/金額の明朗化

ﾍﾞﾝﾀﾞ設計能力活用

業務ｼｽﾃﾑ見積条件書の作成

調達先ﾍﾞﾝﾀﾞ決定/ﾌﾟﾛｼﾞｪｸﾄ発足


図表 3-1-9 JUAS 業務システムによる見積要求仕様書の活かし方と課題


213

ｄ．情報システム構築コストダウンの追及実力のあるユーザーが努力して所望するシステムの内容を詳述すればするほど、本来は高品質、

安価なシステムが完成するはずである。図表 3-1-10 にケース別のコストダウン効果の関係図を示

す。


図表 3-1-10 JUAS 業務システム見積照会によるコスト効果

ここではコストダウンに着目したが、システム利用者が協力してシステム開発をすれば、自分

たちの使いやすい、高品質のシステムが短工期で入手できるので、幅広い意味での効果は大きい。

JUAS進捗管理 JUAS-SLCP

企画設計

（要件確認）

企画プロセス情報戦略立案/情報ｼｽﾃﾑ構想/

ｼｽﾃﾑ計画

開発プロセスｼｽﾃﾑ要求分析

開発プロセスｼｽﾃﾑ方式設計/ｿﾌﾄｳｪｱ要求分析

開発プロセスｿﾌﾄｳｪｱ方式設計/ｿﾌﾄｳｪｱ詳細設計

開発プロセスｿﾌﾄｳｪｱ作成及びﾃｽﾄ/ｿﾌﾄｳｪｱ結合

開発プロセスｿﾌﾄｳｪｱ適格性確認ﾃｽﾄ/

ｼｽﾃﾑ統合

開発プロセスｼｽﾃﾑ適合性ﾃｽﾄ/ソフトウェア導入

基本設計

詳細設計

開発・構築

総合試験

システム試験

（実用化）

情報システムコスト発生箇所 JUASﾚﾍﾞﾙ－１定義 JUASﾚﾍﾞﾙ－３定義 JUASﾚﾍﾞﾙ－５定義

発注コスト

ダウン域

発注コスト

ダウン域


214

（４）徹底レビュー

───作成時間の 10％以上時間をかけて慎重にレビュー時間がドキュメント作成時間の 5％を切ったプロジェクトは欠陥が大きく現れること

がソフトウェアメトリックス調査 2006 から出てきた（図表 3-1-11 参照）。

0

0.5

1

1.5

2

2.5

3

3.5

0 .0% 10 .0% 20 .0% 30 .0% 40 .0%

レビュー工数比率 (レビュー工数 /全体工数 )

欠陥

数

反復型開発PJ

欠陥率


図表 3-1-11 レビュー工数比率

「10％以上かけても、見つけにくい欠陥は見つからない」とも言われている。システムの品質を確保する上で、このレビューの価値は大きい。しかし SE は「自分のした仕事に、あれこれ指摘されるのは心地よいものではない」としてな

かなか自主的にレビューを受けようとしない。「レビューをしなさい」と言っても一般的にはなかなか動かない。「作成した時間の 10％をかけてじっくりレビューしなさい｣と目標値を与えてもなかなか動か

ない。とうとう「金曜日の午後はレビュータイム」と決めて、レビューの実施を強制した。机に座って作業している SE に「今週、貴方のレビューは終了したのですか」と聞いて回った

ら、さすがの SE も腰を上げてレビューへ参加を始めた。人を動かすことのコツが判ったような気がした。レビュー会議の雰囲気作りにもよるが、一度このレビュー効果を享受すれば、後は自らが喜ん

でレビューに参加するようになる。他人のドキュメントをチェックすることは自らの勉強にもなる。

./keyword.htm#4001


215

（５）ユーザビリティの確保

───ユーザビリティテストによる利用容易性確保と品質向上 Web システムが発達して画面の設計技術機能が拡張された。大文字小文字のサイズが自在に活用できる柔軟性の拡大、色の選択、背景の変化付け、ラジオ

ボタンなどの使用など幅広い多くの機能がユーザビリティ（usability：使用容易性）に貢献する

ことになった。しかしこのユーザビリティの確保・拡大をエンジニアリングとしてとらえ、開発の各フェーズ

にどのように取り入れてゆくかの標準化はまだ発達途上にある。 JUAS ではこの問題に着目し、ユーザビリティ研究プロジェクトを立ち上げ研究を続けており、

2006 年度で 3 年目となる。その成果の一つがユーザビリティテスト（操作シミュレーション）

であり、従来の Paper Prototype Approach に加え、新しいアプローチも研究中である。

ａ．Paper Prototype Approach 詳細は JUAS のユーザビリティ研究プロジェクトの報告書をお読みいただきたいが、簡単に言

えば画面操作者（入力役）、進行役、コンピュータ操作者（コンピュータ役）、記録係の 4 人が１

チームになり、紙の上に鉛筆で書かれた画面を使って操作シミュレーションを行うことである。例を示そう。進行役：「注文数量を 100 個入れてください」入力役：「100 個の入力ですね。これは簡単」などと実施する仕事の内容などをつぶ

やきながら、画面上の注文量フィールドに鉛筆で 100 と書く。コンピュータ役：OK の場合、画面の紙を上下に動かして OK のサインを出す。進行役：「あっ、間違えました。10 個に修正してください」入力役：「うーん、どうすればよいのか。では前の 100 個を取り消して…」

操作をしようとするが、なかなか訂正ボタンが見つからない。進行役：入力役が 20 秒以上黙って手が動かなくなった場合「では先に行きましょう」などと誘導する。

訂正、削除などのオペレーションは以外に難しいので、判りやすい方法に改善するべきである、

などの観察結果の成果が出てくる。紙の上にフリーハンドで書かれた画面を使って操作を行うため、もし画面を訂正したければ消

しゴムで消してから、書き直すだけですむ。社内システムの開発の基本設計段階で実際に画面操作を行う人にシミュレーション操作をして

いただくのは、本番前に操作に慣れる、新規システムの事前知識を得る、などの効果もある。


216

図表 3-1-12 ペーパープロトタイプのサンプル

paper prototype approach はこのように非常に簡単であるが、画面を鉛筆で描くのは、近の

若者には歓迎されない。 Microsoft PowerPoint、Microsoft Visio などを使って簡単に画面設計ができるので、これらの

ソフトを使ってもよい。手で描いても後は実装のために入力画面を作成するので、それなら

初から画面設計ツールで画面を作成し、それを基に paper prototype approach と同様にシミュレ

ーションをする方法でもよい。類似画面が多い大型システムの場合には、画面設計ツールを活用

するのも便利な方法である。このことから、JUAS では次の 2 つのアプローチも研究している。ｂ．Screen Type Approach

手書きでの画面作成は SE に好まれない。多くの画面を作成する大規模システムの場合は特に

効率面からもコピー機能を作成し重複作業をなくすこの方法の方が好まれる（図表 3-1-13 参照）。 Paper Prototype Approach の場合も、後は後の作業を実施する SE に画面作成は必要になる

ので、それなら初から画面設計ツールを使った方が良いと主張される方には、好まれる方法で

ある。

ｃ．Online Type Approach 画面設計もシミュレーションも画面だけで実施する方法である（図表 3-1-14 参照）。入力画面そのものの細部の作成にこだわりやすいなどの欠点がある反面、詳細な検討ができる

面も持っている。

y 確保本設計段階タグ

＜作業手順＞

①手書きの画面レイアウトに対してユーザーはデータを書く

②コンピュタ役はその結果に黙って紙の画面上に反応を返す

③その結果を観察役がチェックし状況、課題を記録する。

④①～③を繰り返し課題解消を図る

図表5-2-5 ペーパープロトタイピングのサンプル

＜チーム編成＞

①ユーザー

②コンピュータ役

③進行役

④観察者


217

図表 3-1-13 Screen Type Approach 図表 3-1-14 Screen Type Approach

終了

PowerPoint、Visio など

で画面作成

画面印刷

Paper Prototype

Approach と同様にシミュレ

ーション

不都合

合格

判断

画面ラフスケッチ

終了

PowerPoint、Visio など

で画面作成

画面上で直接

シミュレーション

不都合

合格

判断

画面ラフスケッチ


218

（６）UVC 判りやすい仕様の書き方

───仕様の一貫性

プログラムシート

⑦Vender

ユーザーの要求①User

要求仕様書（見積照会仕様書）

②User

要求確認仕様書③Vender

仕様を確認し補正する

vender

見積書④Vender

工数、工期品質、リスクの見積

vender

利用者の要求end user

見積評価調達契約

利用者の要求を明確化する

user

設計書⑥Vender

変更依頼書⑧User →Vender

→User

基本設計を実施するvender

Program（詳細設計、コーディング）

を作成するvender

仕様の変更を確認しあうuser＆vender

契約書⑤Vender

図表 3-1-15 UVC 要求仕様の明確化とトレース方法

ユーザーとベンダー間の要求仕様の明確化とトレース方法の強化を狙って、以下の項目を議論

し 2007 年度末完了を目指して整理中である。 ①ユーザーとベンダー間の要求仕様書作成についての前提条件・共有情報の整理 ②企画段階のシステムコンセプトの整理の仕方 ③理解しやすい要求仕様の定義方法の明確化 ④要求書～設計～設計変更を通じて仕様の変化が一貫管理できる様式の開発仕様変更率のマネジメント＝仕様変更数/仕様総数 ○%以下に ⑤データベースの定義方法と分担の明確化 ⑥画面、帳票のデザインとユーザビリティ ⑦品質要求の定義ユーザーが要求仕様をどのように書き、ベンダーあるいは企業内の SE やベンダーSE が、どの

ように仕様書を書くと上記①から④までの条件が達成できるのであろうか。ユーザーによるビジネスシステム定義書では、詳細な条件の記述書は「フローチャート」で書

いてもよいし、「HIPO」で書いてもよい。UML を使いシナリオで書いても良い、としてある。

./keyword.htm#2001


219

「もっと優れた方法はないのか」と探していたところ、清水吉男氏の著作が目に付いた。このノウハウを使わせていただき、さらに発展させて、多くの方々に成果を得て欲しいと、

JUAS ではこの方法の発展を検討中である。まずは、例題を考えていただこう。

例題：エレベーター（要求と要求仕様）問題１

駅の 11 人乗り、大積載量 700 キロのエレベーターに乗ると、後の一人が「重量オーバー

です」とアナウンスされて、降ろされることが、頻繁に発生する。そのために誰が降りるのか。乗車した人の葛藤が始まり、時間をロスすることが多い。これを

防ぐ要求仕様を作成してください。ヒント

・加重計が 600 キロを越えたら「あと一人で満員です。次の回までお待ちください」と乗車さ

れた方にお伝えする。・乗った人は全員合格であり、ドアは閉まるので、降りる人はいない。したがって時間もかか

らない。誰が降りるべきか。乗客間で葛藤が始まることはない。疑問

後に乗った人が、曙のような大型相撲力士だったらどうなるか

文章問題（エレベーター）回答の一部：

積載重量オーバーが検出された場合は、「制裁重量オーバーです。後の方はお降りください」とアナウンスし、制限以下になったら始動を開始する。

要求機能仕様ＳＫ０１－３

お客が少ない場合は、早めに発車するため理由

前の客が乗り込んできてから３秒以上たっても次の客が乗車してこなければ、制限重量以下であることを確認し、ドアーを閉め、始動する

要求機能仕様ＳＫ０１－２

乗ってから降りてもらう手間を省くため理由

お客が乗り込んできたら、その都度時間をカウントし始めると同時に体重を積算し、（制限重量－後の一人分の余裕）以上になった場合は「これが後の方です」とアナウンスして伝える

要求機能仕様ＳＫ０１－１

お客が乗り込んできてから、降りてもらう不快感と時間のロスを避ける

理由

乗り込んだ客の重量を予測し次ぎの一人が乗ったら満員になると予測された場合は警告を発する

要求機能ＳＫ０１積載制限

要求機能区分要求番号カテゴリー

積載重量オーバーが検出された場合は、「制裁重量オーバーです。後の方はお降りください」とアナウンスし、制限以下になったら始動を開始する。

要求機能仕様ＳＫ０１－３

お客が少ない場合は、早めに発車するため理由

前の客が乗り込んできてから３秒以上たっても次の客が乗車してこなければ、制限重量以下であることを確認し、ドアーを閉め、始動する

要求機能仕様ＳＫ０１－２

乗ってから降りてもらう手間を省くため理由

お客が乗り込んできたら、その都度時間をカウントし始めると同時に体重を積算し、（制限重量－後の一人分の余裕）以上になった場合は「これが後の方です」とアナウンスして伝える

要求機能仕様ＳＫ０１－１

お客が乗り込んできてから、降りてもらう不快感と時間のロスを避ける

理由

乗り込んだ客の重量を予測し次ぎの一人が乗ったら満員になると予測された場合は警告を発する

要求機能ＳＫ０１積載制限

要求機能区分要求番号カテゴリー


220

この清水吉男方式の良いところは、要求機能番号と要求機能仕様番号が要求仕様書（RFP）上

でつながり、さらに設計書、プログラムシートへと機能仕様番号がつながってゆくところである。ユーザーがひと言機能を要求したために、仕様が拡張されてゆくことが目に見えるようになっ

ている。気の利いたユーザーならば「そうか、このように機能仕様を書けばよいのか」と次から

は機能仕様まで書くことへのサンプルにもなる。「理由」を書くことで、｢なぜこのような機能仕様にしなければならないのか｣を、ユーザーや

SE が考える機会が増え精度が上がる。後に続く SE やプログラマにも、「理由」を書くことで、

仕様の趣旨を十分に伝えることも可能になる、などのメリットが生まれてくる。さらに仕様数が数えられることで、仕様変更の管理ができる道が開けた。仕様変更率を次の式と定義する。「仕様変更率＝更仕様数/総仕様数」これを一定の率に収める努力をする。特に基本設計完了後の仕様変更率を一定以下に収める努

力をユーザーとベンダーが協力して行うようになれば、システム開発は納期遅れも出さず、品質

も向上する。「ユーザーが要求仕様書を正しく書いてくれない」とベンダーの方は嘆く前に、このような仕

組みの採用が問題解決の一歩となることを理解し、努力してほしい。6 （７）目標を持って管理（EASE）7

───目標の有効性とフォロー

ａ．プロセス志向とプロダクト志向「あなたは車を買うときに、T 自動車会社や N 自動車会社がどのようなプロセスを採用してこ

の車を作ったのかを気にして買いますか」と質問すると、ほとんどの方は、「車は早く走れて燃費

が良く、乗り心地が良いものがいいね。後は安くて長持ちするかどうかだな」と答える。「あなたは昼の食事をするときに、レストランがどのようなプロセスで料理を作るのか気にし

てレストランを選びますか」と問えば「安くてうまければよいね。できれば静かで雰囲気が良い

ところを選びたい」と返事が来る。料理を作るプロセスは気にしていない。ほとんどの企業の業務部門は「自社の商品の品質、納期、価額」で市場競争をして何とか顧客

に買ってもらう努力をしている。「プロダクト志向」があっての「プロセス志向」である。 IT 部門の管理者に「何を目標にして開発作業をしていますか」と質問すると、「CMMi を守っ

てプロセスで実施すべき標準に則り作業しています」と答える。プロダクトの目標がないのに、プロセス志向である。これではユーザー企業の経営者から見れば、「IT 部門のやっていることはわからない。何かお

かしいではないか」と疑問視されてしまうことになる。

6参考：要求を仕様化する技術・表現する技術清水吉男著技術評論社 7 EASE：Empirical Approach to Software Engineering の略。


221

ｂ．ソフトウェア産業のプロセス志向の問題点 2006 年初めに、外国のソフトウェア企業を訪問させていただいた。「当社は CMMi の５を取得しています。プログラマが作成したプログラムの終検査実績は、CMMi を取ったおかげで FP 単位で、1.8 個あった平均バグが、1.3 個に減りました」と得意げに説明してくれた。「何かの間違いではないでしょうか。10000Step のプログラムで 130 個のバグを抱えたシステ

ムを日本の顧客に納入すれば、間違いなく出入り禁止になります。ユーザーの要望から見ると、

二桁ぐらい品質の差がありますね」とコメントをした。社長はしどろもどろになり「日本からの注文は品質が厳しいことは良くわかっています。今目

標の見直しをやっています」との鮮やかな答えであった。つまりプロセス志向は「ソフトウェアにはバグがつき物であり、その保証をさせられるのは避

けたいのでプロセス志向にしよう」と海外の情報産業関係者が唱えた主張がそのまま今も継続さ

れていることに問題がある。これはソフトウェア提供者の発想であり、ユーザーからの要望とは根本的に異なる。この会社のために若干補足すると、納品前終検査で 130 個のバグがあったと言うことは、た

とえそれを修正しても、経験的に、その 1/3 の約 40 個のバグが内蔵されていると見ればよい。「万が一」という素晴らしい諺が日本には存在している。ハードウェア製品のように 6 シグマ（100 万個の商品に 1 個不良品があるレベル）までは行か

ないにしても、10000Step に 1 個のバグがある程度までに品質を高めて納品されなければ、関係

者はその後のバグの発見と修正に追われることになる。ベテランのプロジェクトマネージャーが担当して品質を重視した開発をすれば、この「万が一」

のレベルのソフトウェア開発が可能なことは、JUAS の実施したソフトウェアメトリックス調査

でも証明されている。ｃ．工期の標準

「システムの工期は何で決まりますか」と尋ねると、「ユーザーが何時までに作ってくれと要求

した時期までの間が工期」と、ほとんどのソリューションベンダーの代表は答える。「では、それが無謀とも思える工期であったとしたらどうされますか」と迫ると、「過去の実績

で考えます」との答えが返ってくるのが通常である。もともと無理な工期をユーザーが要請し失敗する、出来もしない工期を約束して病人を出す、

などの無茶をしないためにはどのようにすればよいのであろうか。 JUAS ではまずこの工期の標準を、日本の代表的なプロジェクトのデータを基に分析した。そ

れが、次の図表である。ソフトウェアメトリックス調査 2006 に、「システム標準工期＝2.4×（投入人月の立方根）」が紹介されている。日本企業の予算令達後のプロジェクト開始時期から稼動までの期間の平均値である。

./keyword.htm#0601


222

なお、１年前のデータ（ソフトウェアメトリックス調査 2005）では、「システム標準工期＝2.７×（投入人月の立方根）」であり、これはほぼ COCOMO 法に近似している。


図表 3-1-16 標準工期の考察

なぜ立方根なのかを気にされる方がおられるが、上記例に見られるごとく相当にデータはバラ

ツキを示している。この図から標準の回帰式を引き出すのであるが「システム標準工期＝ｋ×（投入人月）のべき乗」とし、例えば「システム標準工期＝ｋ×（投入人月）0.423」なる形に整理したとしても、ユーザー企業含め

て簡単に計算できず、活用し難いので「会議室の場で簡単に電卓あるいは筆算でも概略計算でき

る方式」として使いやすい形に整理したものである。ユーザーの要望工期はこの式とは関係なく、新商品の発売予定日や工場の完成日などの理由で

工期は決められる。この式で計算し工期が決まるケースはほとんどないと言ってもよい。肝心なことは、上記計算工期と要望工期の比率である。計算工期に対して何％不足なのかを知り、過去の自社のプロジェクト工期不足率と採用した対

策を比較し、自社では今回のプロジェクトを始めるに当たって何をすればよいのかを認識するこ

とである。システム標準工期の係数（k）は近の値は 2.4 であったが、これを大きく割る超短工期は各社

ごとの IT 部門、利用部門の実力によって異なる。3 割減が限界の企業もあれば５割減でもこなす

会社もある。いずれにしても企業ごとに工期とアクション、品質、トラブルの程度などをデータ

として保存しておけば、このプロジェクトを利用部門の要望工期で実施できるか。どのような準

備をすればよいか。などの実際に活用できるデータが蓄積できる。「短納期システムで苦しんだが

これで終了した」など、本番稼動を迎えたらすべて終了では何度も失敗を繰り返す「塀の中の面々」

になってしまうので、このような形のデータをユーザーもベンダーも保存して欲しい。

工期-工数グラフ

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


223

図表 3-1-17 納期に関する問題

標準より長い工期標準２５％工期短縮２５％以上工期短縮

工期の標準

の考え方

金融等欠陥の発生

を無くしたい品質重

視のプロジェクトの

場合

工数の立方根の 2.4 倍

（例：１０００人月のプロジ

ェクトは２4 箇月）

・ユーザの要望

・流通業のシステム化など

に多い。

ユーザのやむを得ない外的事情で実施する場合

（対コンペ戦略、新商品の販売、株式の上場、企

業の統合など）

スケジューリ

ングの対応

策

充分なシステムテ

スト期間の確保

中日程計画の充実

（役割分担別ＷＢＳ管

理）

中日程計画の充実

（週間別管理）

小日程計画の充実

（日別管理）

その他の対応策

・品質重視のテスト計画書及びテストケースの緻密化

・安定稼動のための分割立ち上げ等

・ＷＢＳによる総合計画と局面化開発

・レビューの徹底・テストケース充実・コンバージョンデータの

フル活用・確実な変更管理

同左 + ・ＰＧの選抜

*標準化の徹底と実力のある一括外注の採用。

・システム範囲、対象の部分稼動

・ＲＡＤ+ＤＯＡ・性能事前検証・変更管理の強化

同左 + ・ベテランＰＭによる采配と会社あげての協力及び

監視・パート図での計画・ベストメンバー選出・クリーンルーム手法・二交代制の配置・顧客主体のテストチーム設置・パッケージの活用・部品の再利用・オープンな進捗情報管理

次に工期遅延と発注単価の関係を求めてみた。「安い単価で無理をさせているのではないか」「短工期は残業などを強いることになるので、高価格になるのではないか」との仮説を頭に描

いて分析したのが、次の図である。一定限度を下回る単価企業に仕事を頼むと、安物買いの銭失いになる。単価以外の要因での遅延が、かなり存在すると思われる。




844496529件数

総計FEDCBA

工期遅延度




844496529件数

総計FEDCBA

工期遅延度

0 50 100 150 200 250 300 350

A

B

C

D

E

F

総計

工期

遅延

度単価（小）

単価（大）

単価（平均）

件数 A 予定より早いB 予定通りC 遅延10%未満D 遅延20%未満E 遅延50%未満F 遅延50%以上


図表 3-1-18 工期遅延度と単価


224

ｄ．品質の標準 ① ソフトウェアメトリックス調査における品質議論

一般的に各企業で使われる受注委託プログラムはどの程度の品質で納入され使われているのか。 JUAS の調査対象は各ユーザー企業を対象としているので、開発ソフトウェアの品質を「ベンダーができましたと納入してきてから、受入確認テストを行い、結合テスト、総合テス

トを経てカットオーバーし、安定稼動までに発生した欠陥数（ほぼ修正数に同じ）」と定義してデ

ータを集めた。ベンダー側の品質データは「カットオーバーしてから安定稼動までに発生した欠陥数を品質の

評価指標」となっている。つまりユーザー側は「バグをつけて持ってこないでくれ」と主張し、ベンダー側は「本番稼動

以降に実際の利用者に迷惑をかけた欠陥数」を対象に調査をしたことになる。「それは限りなくゼロに近いのでしょう」と言いたいが、一定の割合で発生している。ユーザー側の品質目標データは世界中に残されているものは少ないが、マイケル・A．クスマ

ノ教授8の調査によると、日本の受託開発プログラムの精度は、アメリカの数倍良いと言われ、日

本のソフトウェア産業は優秀であると評価されている。ユーザーから提供された JUAS モデルによると「0.25 個/開発投入人月」を守れた日本のプロ

ジェクトは 40％である。これは国際的に見ると非常に良い品質実績である。経験値としてユーザーや開発者にわかりやすいようにと「納入時には１件/500 万円に抑えてほ

しい」と言い続けてきた。優秀なプロジェクトリーダーと優秀な開発者がいれば、おおよそ半分

のプロジェクトはこの目標を達成できる。世界的に見てもすばらしい実力を日本の情報会社は持

っている。

② 品質目標ユーザー企業は品質目標をベンダーに示して発注しているのか。ソフトウェアメトリックス調査 2006 では、欠陥率の計算できた 99 プロジェクトについて、品

質基準の有無と欠陥率の関係を調べた（図表 3-1-17 参照）。品質目標を持っていたプロジェクトと目標がないプロジェクトでは、発生欠陥率において平均

0.57 件/人月（2 倍）の差があった。すなわち品質基準を持っていないプロジェクトでは、欠陥率

が 2 倍になっている。これは、昨年度と同様の傾向（平均 0.25 件/月（1.4 倍））がさらに強まっ

たことになる。つまり、品質目標を持っているプロジェクトは 44％であり、納入品質実績は 2 倍良い。

8 MIT（マサチューセッツ工科大学）スローン経営大学院教授。


225

図表 3-1-19 品質基準の有無と欠陥率


また、PM の能力と欠陥率の関係も調査した。その結果、優秀なプロジェクトマネージャーが

指揮したプロジェクトは未熟なプロジェクトマネージャーの場合と比較して 5 倍も良い品質であ

ることが証明されている（図表 3-1-20）。

1 2 3 4 5 記入なし計件数 24 19 18 6 3 29 99平均 0.54 0.82 1.17 0.81 2.68 1.15 0.97

大 3.25 3.11 7.54 2.00 4.35 16.56 16.56小 0.00 0.00 0.00 0.05 0.40 0.00 0.00

PMスキル（ベンダ）

欠陥率

ＰＭベンダスキルと欠陥率

0.54365

0.816136842

1.170666667

0.81445

2.678833333

1.152024138

0

0.5

1

1.5

2

2.5

3

1 2 3 4 5 記入なし

PMスキル（ベンダ）

欠陥

率（平

均）

PMｽｷﾙ1.多数の中・大規模プロジェクトの管理を経験2.少数の中・大規模プロジェクトの管理を経験3.多数の小・中規模プロジェクトの管理を経験4.少数の小・中規模プロジェクトの管理を経験5.プロジェクト管理の経験なし


図表 3-1-20 PM（ベンダー）スキルと欠陥率

有り無し記入なし計44 54 1 99

44.4% 54.5% 1.0% 100.0%0.66 1.23 0.33 0.973.25 16.56 0.33 16.560.00 0.00 0.33 0.00

品質基準

小欠陥率

件数比率

平均欠陥率大欠陥率


226

③ 「プロダクト志向」活用のすすめ実はこの「目標を持った管理」は、何もユーザーに限らず、ベンダーにも非常に重要であり、

「優秀な SE やプログラマが実際に評価されていない」問題点を解消できる仕組みでもある。製造業では PDCA を回して改善をすることは常識であり「評価するためには、計画があり実績

対比ができる仕組み」は各社で実施されている。その仕組みで世界を制覇してきたとも言える。日本の情報産業は製造業を見習うことができないのか。プロダクトの目標を示す、それが日本

の SE やプログラマの優秀さを説明する手段でもある。

④ 品質とコストの関係上記 500 万円に１件の欠陥でプロジェクトを開発できるチームに、「5000 万円に１件の欠陥に

までテストをして良い品質で納品してほしい」と依頼した場合は、いくらコストが上がるか、ソ

リューションベンダー各社に聞いてみた。「予算を 20％増しにしていただければ、できます」から始まり「50%増し」「100％増し」

「200％増し」「500％増し」と選択してもらうと、後の二つが多い。しかしすでに厳しいソフト

ウェア品質管理を実施している会社は前二つを選択する。つまり「定見がない」のがソフトウェア産業の実態で「お寺のお経の値段とソフトウェアの値

段のつけ方は同じ」などの説が登場する原因でもある。「欠陥の少ないプロジェクトは、確実に管理しないとできないと思うので、単価が高いのでは

ないか」「優秀な一時請負ソリューションベンダーに依頼すると、価格は高くとも、良い品質で納

品されるので結局安いものになるのではないか」との推測を基にデータを整理した。

図表 3-1-21 品質と費用の関連性

欠陥の数

開発総費用・購入価格

開発総費用

購入価格

品質尺度

無管理ゾーン管理ゾーン特別管理ゾーン無欠陥目標ゾーン

5～20/500

ユーザー満足度

1/500 1/5000 ほぼ　0

注１　品質尺度：（納入時～安定稼動期迄の欠陥個数）／開発費用（万円）

注２　開発総費用と購入価格のギャップはテスト結果の確認、修正結果の確認のために要するユーザー側の　　　負荷増加費用をイメージ化したもの。


欠陥の数

開発総費用・購入価格

開発総費用

購入価格

品質尺度

無管理ゾーン管理ゾーン特別管理ゾーン無欠陥目標ゾーン

5～20/500


1/500 1/5000 ほぼ　0

注１　品質尺度：（納入時～安定稼動期迄の欠陥個数）／開発費用（万円）

注２　開発総費用と購入価格のギャップはテスト結果の確認、修正結果の確認のために要するユーザー側の　　　負荷増加費用をイメージ化したもの。



227

41.4 万円45.7 万円76.1 万円41.4 万円43.2 万円76.5 万円71.5 万円単価（最小）

300.0 万円250.0 万円175.7 万円285.7 万円300.0 万円150.7 万円117.5 万円単価（最大）


708101614157件数

総計F(3～)E(～3)D(～1)C(～0.5)B(～0.25)A(0)


41.4 万円45.7 万円76.1 万円41.4 万円43.2 万円76.5 万円71.5 万円単価（最小）

300.0 万円250.0 万円175.7 万円285.7 万円300.0 万円150.7 万円117.5 万円単価（最大）


708101614157件数

総計F(3～)E(～3)D(～1)C(～0.5)B(～0.25)A(0)


図表 3-1-22 品質と単価

結果は頭の痛いことになった。なんと「納入品質と単価の関係はない」ことになる。「常識に反している」「データの層別に問題があるのではないか」などのご指摘もあったが事実

は事実である。「目標を持って作業しないプロジェクトに結果が伴ってくるわけがない」目標がないから実績もばらつくのである。この改善策はユーザーが、まず品質目標値を提示することから始まる。日本のベンダー各社は

皆優秀であるから、その期待に応えてくれるに違いない。


228

ｅ．生産性の標準１プロジェクトのソフトウェア開発費が 10 億円を越す場合を、除いた標準的な生産性を求め

たのが次の表である。LOC 単位、FP 単位、人月単位、画面数単位などバラツキの多い中で、ひ

とつの指標として意味があると考えている。もちろん各プロジェクトとして、様々なリスクを抱えており、結果的にばらつくのはやむを得

ないが、おおまかな指標として受け止めてほしい。本来ならば、システムの停止が社会的に問題になるライフラインなどの社会インフラシステム

と、企業内の一部の担当者だけが困るシステムと値段の差が出て当然であるが、まだ価格差の定

説は出ていない。多くの事例を集めそのような常識を作りたいものである。

図表 3-1-23 生産性まとめ

指標数値コメント

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 回帰式同上

./keyword.htm#0601

./keyword.htm#1201


229

（８）単体テストの徹底

───データコンバージョンプログラムは単体テスト開始前に準備かつて多くのプロジェクトで、あるいは今も多くのプロジェクトで、総合テストに間に合うよ

うにデータコンバージョンプログラムを作成していた。これは「その時期にならないとすべての仕様が決まらず、データコンバージョンプログラムの

仕様が作成できない」とプロジェクトマネージャーが決めつけていたところにある。そして総合テストで発見された幾つかのバグは、このデータコンバージョンプログラムのミス

であったことに気づく。中には「そのコードには、1、2、3 の値しか入らない」と聞いていたの

に「コンバージョンしたデータには、4 も 5 もある」などの仕様のミスが、後のこの工程で発

見され、あわててプログラムを補正することになる。総合テスト工程でこのようなミスが発生すると、SE はかけなくてすむ手間をかけプログラム

の修正、データの訂正に追われ無駄な残業時間が発生することになる。従来の単体テスト用データは、以前と同じように作成しテストをしなければならない。それに

加えてこのコンバージョンデータを活用する。このことの成果はいくつかある。 ① 大量のコンバージョンデータを流すことができるので、大量テストの時間測定や内部テー

ブルなどの上限オーバーなどのテストが可能になる。 ② 旧システムの結果と比較できる。例えば旧システムでの月報の値と新システムで月報の答

を比較し、数値の整合性を確認できる。 ③ 異常データを発見することができる。 ④ 機能仕様の不備を発見することができる。是非ユーザーとベンダーは協調し、「単体テスト開始前にデータコンバージョンプログラムが

完成していること」の魅力を味わって欲しい。総合テスト、併行運転、稼動後の欠陥発生数の少

なさに驚かれるに違いない。


230

（９）単体テスト完了でユーザーに開示

───プログラマが側にいる間に完了を昔のプロジェクト人数は多くなかったが、SE もプログラマも皆プロジェクトの完了時まで一

致団結して働いたものである。もちろん長い総合テスト期間などは取れなかったし、カットオー

バー後の品質も良くなかった。近のシステム開発では、プログラムは社内ではほとんど作成さ

れず、外部に発注する。そして受入試験が終わればプログラマとは「さよなら」になる。総合テ

スト、併行運転なども一緒に付き合う予算が確保されないからである。その結果、総合テストや併行運転期間で発見されたバグは、プログラムには慣れていない SE

が修正せざるを得なくなる。そしてプログラムの品質を落とし、生産性を低下させている。「単体テスト終了後、ユーザーはプログラムの確認作業を実施し、自分の目で品質を確かめよ」

と指示を出すと、ベンダーからは「そこで仕様変更を多数出されてはたまらない」と拒否される

ケースが多い。「どうせ修正するなら、プログラマが横にいる間にしてもらう方が早くて正確であ

る」と説得して一度試してみると、この良さがすぐにわかる。特別な準備は不要であるため、完成したと思うならユーザーの目で確認してもらうことである。超短工期プロジェクトならば、「ユーザーの実務の専門家を横においてテストデータ作成を専

門にしてもらい、単体テストも一緒に実施する」方式が短工期でも良い品質を確保できる一つの

コツである。 U 字型開発法は何も特別に準備が要ること、負荷がかかることを強いているわけではない。この事項は一番簡単な方法である。是非一度試して欲しい。

（10）結合、総合、実運用試験の小化

───単体テストの徹底単体テストの不十分なプログラムを結合テスト、総合テストに持ち込み、単体テストの欠陥補

正をこのテスト時期に実施していないだろうか。前述のようなコンバージョンデータを活用した

テストまで単体テストで実施し、処理時間対策まで単体テストで行っておけば、当然この結合、

総合、実運用試験期間は短縮される。場合によっては本番稼動時期を早めることも可能となる。

総合テストの時期に SE が多忙を極めているようなら、「このプロジェクトは何かおかしい。もっ

と別の方法があるはずだ」と考え直してほしいものである。


231

（11）DB パトロール

───データベース間の整合性チェック総合テストに入る段階になって「単体テストはほぼ完全にこなしたが、これで完璧か」と疑問

を抱いた SE が考え出した方法である。「各データベース間は、整合性が取れているはずであるが、そうなっていない」ケースは、時々

発生する。多数のプログラムを通して処理を行っていること、各入力項目には新規、訂正、追加、

削除機能が複雑に絡み合っている。プロジェクトマネージャーは「この帳票のこの値とこの帳票のこの値は合致していなければな

らないのに、なぜか異なるので調べてほしい」などの要請を受け苦労した経験があるだろう。

近はディスクの値段が下がり、ほとんどのデータが 1 年分くらい即時検索可能になっている。たとえば、出荷、売掛、入金、財務のデータベースの値はタイミングを配慮すれば、正しく整

合性が取れていなければならない。しかし、集荷作業の報告は 20 種類、入金方法は 5 種類など、

相当数のプログラムを経てデータは処理される。新規入力時のデータは正しくても、その後の訂

正作業処置に伴って不一致が起きても不思議ではない。この間の処理が正しく行われているか、サーチして欠陥をあらかじめ見つける方法がある。こ

れを「データベースパトロール（DB パトロール）」と称する。これによって、思いがけない処置

ミスが発見できる。産業によっては 24 時間中データベースをサーチする仕組みを持っている。この DB パトロールを作成しチェックすると、「利用者から今度のシステムは精度が良いと評

価された」と言われることが多いと聞いている。是非トライしてほしい。

出荷売掛入金財務

出荷量、請求金額は出荷、売掛、入金、財務の各DB間で整合性が保たれて

いなければならない。しかし出荷方法、入金方法が数種類ありそれに伴う新規、訂正、取消、削除処理が多くのプログラム経由で処理されるので、必ずしも整合性が取れているとは限らない。理想的状況が保たれているかを、DBパトロールプログラムを作成して、全DBを読み合わせて検証する。

全データはデータベースの上に載っており、相互間の整合性は簡単にチェックできる。

財務の総勘定元帳の売上高と出荷量は一致しているか（架空計上の防止にも役立つ）

トランザクション

トランザクションDBに正規に入力されていないデータがアプリDBに載っていないか

出荷プログラム（新規・訂正・取消・削除）

入金プログラム（新規・訂正・取消・削除）

財務プログラム（新規・訂正）

（丸文情報システム案より）

図表 3-1-24 DB パトロール


232

（12）移行計画は早期準備

───開発当初より計画し準備

業務戦略Business Architecture

情報（データ）戦略Data Architecture

実装戦略Application Architecture

技術戦略Technology Architecture

Standards（データモデル・セキュリティ要件などの標準を作成）

Transitional Processes（業務システムなどの移行計画を策定）

修正箇所の発見・分析

修正作業

修正後の確認

保守フェーズでの、移行準備システムの再活用

保守フェーズでの活用を前提にした移行システムの設計・開発

保守・運用フェーズ企画・開発フェーズ

点線内はJUASで補完

図表 3-1-25 EA（Enterprise Architecture）の概念

システム再構築時代に入って、このシステムの切り替え方法は益々重要になってきた。稼動当初から試走もほとんどなく、荷物満載でフル能力を発揮して走るトラックを想像してほ

しい。いや稼動当初は切り替えのための様々な作業が入ってくるので、定常時の 3 倍の入力をこなす

能力が必要とさえ言われている。インターネットを活用し、多くの一般入力者がデータを入力す

る方法では、ピーク作業をこなすためには通常の 10 倍の受付能力を必要とする話もある。従来

のシステムで作成されたデータベースを引き継ぎ、新規システムでの入力に対応する切り替え時

の作業負荷の大きさと、うまく稼動し続けてくれるかの不安感は並大抵のものではない。この壁を乗り越えるためのノウハウを整理したのが次図である。


233

④無停止全体切替型

◎リスク小

△準備負荷大

システム設計の初から準備しておくことが必要

①全面停止一斉切替型

▲リスク大

ただし一般的な切替方法

○すべてのプロジェクトに適用が可能

③無停止部分切替型

◎リスク小

△準備負荷やや大

ただし、システム設計の初から準備しておけば、それほど大きな負荷にならないことが多い

②部分停止部分切替型

○リスク小

△切替回数が多いので、負荷がかかる

△全体整合性を取る準備が必要

④無停止全体切替型

◎リスク小

△準備負荷大

システム設計の初から準備しておくことが必要

①全面停止一斉切替型

▲リスク大

ただし一般的な切替方法

○すべてのプロジェクトに適用が可能

③無停止部分切替型

◎リスク小

△準備負荷やや大

ただし、システム設計の初から準備しておけば、それほど大きな負荷にならないことが多い

②部分停止部分切替型

○リスク小

△切替回数が多いので、負荷がかかる

△全体整合性を取る準備が必要

切替時停止

部分的切替

全体一括切替

切替時無停止

図表 3-1-26 システム切替方式

①従来のシステム切り替え

従来のシステム切り替えはこの図の左下のゾーンである。システムのカバー範囲全体を新シス

テム稼動のために一旦全面停止し、一斉切り替えを行う。新システムが動き始めシステムの欠陥が発生した場合は大変なことになる。プログラムを修正するのは勿論のこと、誤ってデータベースに書かれたデータの修復を実施す

る負荷は非常に大きく複雑な作業になる。大規模システムの場合は、テストにテストを重ねても、本番稼動後ソフト開発予算の 2000 万

円に 1 件程度はこのバグが発生してくる。1 億円のシステムならば 5 個程度はバグが発生してく

ると思って対応策を講じておいたほうがよい。P によっては１個／億円でも欠陥が問題視される

場合がある。大は 1 件、中は 1／2 件、小は 1／4 件などと、ウエイトをつけて目標を作る必要が

ある。

②部分停止部分切り替え型このような欠陥の影響を避けるためには部分停止部分切り替え型がある。システムの適用の範

囲をまずは狭めて実施する。全社一斉でなくある営業所のみに適用し入力件数を少なくする。そ

のような対策を行っておけば、欠陥が発生しても修復量は少ないので大きな問題にはなりにくい。初の営業所がうまくいったら次の営業所展開を図り、徐々に全社に展開する方法である。

③部分切り替え型

部分切り替え型ではあるが、従来のシステムを停止しないで新システムに切り変えてゆく方法

である。端末機を新しくして二重入力などを入力者に依頼し、問題がなくなった時点で新システ

ムに切り替える方法である。旧システムのデータを新システム用にデータコンバージョンするな


234

どの工夫が通常必要になるが、設計時の初からこの方式の採用を決めて準備するならば、それ

ほど大きな負荷にはならない。

④無停止全体切り替え型旧システム全体を動かしながら、新システムに移行する。大変な方法であると感じられるかも

知れないが、システム設計の初からこの方法を採用すると計画しておけば、この方法が採用可

能なケースがある。すべてのシステムでこれを実行する必要はないが、思ったよりも切り替えの

精神負担は軽くなる。当然新旧双方向のデータコンバージョンプログラムを準備しておかねばな

らない。旧システムからの入力データを拝借し新システム用にコンバートしてテストを重ねておくなど

の工夫が必要である。要するに新システムへの切り替えは「全面停止一斉切り替え」しかないと思わないで工夫して

ほしいということである。


235

（13）カットオーバー（サービスイン）の日に SE は定時帰宅を

───no-trouble で稼動開始日は大きなトラブルもなく、定時には帰宅できるのが理想である。先に「プログラム納入から総合テストを経て、サービスインし、安定稼動にいたる間の欠陥発

生比率を 500 万円につき 1 件以下の割合におさえてほしい」とユーザーはベンダーに要求しよう

と提言した。ではこの割合が達成できた場合は、安定稼動後にどの程度の欠陥数が発生するのか

を分析してみたのが次の図である。ユーザー総合テストで発見された欠陥数の 1/3 が、稼動後に

発生している。つまり 1500 万円にひとつの欠陥が出てくる。おおよそ 1 億円で 6 個程度の欠陥は普通の努力

では残存する。規模が小さい間は目立たないが、規模が大きくなるとこの割合で生じた欠陥はか

なりの数になり目立つ。10 億円では 60 個のバグになる。大規模システムのサービスインへの入

り方（（12）参照）の工夫、超大規模システムにならないように、インターフェイスを考え分割

開発を試みるなどの努力をするとよい。 500 万円に 1 件でも厳しいと主張されるベンダーは多いが、超大規模システムになるとそれ以

上の品質確保対策が望まれる。ユーザーのプロジェクトマネージャーはこの実態を認識しておき、

利用者に「この程度の欠陥数が普通は発生するものです」と宣言しておくとよい。ともあれ、カットオーバー（サービスイン）の日に SE は定時帰宅ができるようにシステム作

りを目指すことが重要である。

カットオーバー後の欠陥数ｖｓ総合ﾃｽﾄ2欠陥数

0

50

100

150

200

250

300

350

0 100 200 300 400 500 600 700

総合テスト2不具合数

フォ

ロー

不具

合数


図表 3-1-27 カットオーバー後の欠陥数 Vs.総合テスト２欠陥数


236

（14）保守運用の信頼性向上

本番稼動に入るとシステムの安定稼動がユーザーからは要求される。保守の対策は本章の第 2 節に詳述したので、参照してほしい。運用の指標は 2006 年秋の調査に準備されている。すでに判明している情報は、以下のとおりである。IT 動向調査 2004 によると以下の事実が判

明している。 ①ユーザーはバックアップマシンの有無にかかわらず、高稼働率を望んでいる。

99.99%以上の高稼働率を約 3/4 のユーザーは期待している。 ②実績では 99.99%以上の高稼働を 55％のユーザーで達成しているがバックアップマシンの有

無は、意外ではあるがほとんど影響していない。 ③99.9%以下の稼働率の割合は、バックアップマシンの有無に影響を受ける。当然バックアッ

プ機がない場合は低稼働率の割合が増える。 ④バックアップマシンを持つほうが目標値と実績値の差は少ない。バックアップマシンを準備してあっても次のような理由で停止する場合がある。

プログラムでファイルを破壊し、その修復に時間を要したウイルスにアタックされてバックアップマシンも動かなくなった電源など二重化してない部分があった JUAS では稼働率とバックアップ機能、コストとの関係を次図のように整理した。このように

高度な信頼性を望めば、システム投資は高価なものになるという関係図の明示が必要である。


図表 3-1-28 バックアップマシンと基幹系システム稼働率

61%

45%

55%

31%

23%

27%

14%

27%

18%

23%

32%

26%

12%

8%

15%

17%

13%

14%

6%

7%

15%

11%

11%

11%

10%

13%

15%

17%

23%

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

３重化している(n=28)

２重化している(n=294)

１台のみ(n=439)



１台のみ(n=431)

目標

値実

績値

100% 99.99％以上 99.95％以上 99.90％以上 99.90%未満

• バックアップマシンが無いのに99.9％未満の目標値を設定している企業は13％、実績は23％

• 二重化、三重化していても15～17％は99.9％未満の実績。データの二重化、ホットスタンバイなど

の要因が影響していると思われる。


237

図表 3-1-29 信頼性とコストの関係

図表 3-1-30 稼動率目標と SLA とシステムコストの関係

（2003 年度運用研究会報告会資料）

対象対象対象ペナルティ8

SANクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ三重化、四重化

SANクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ三重化

SANNASクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ

NASシステム構成（例）必要な機能

7

4～6倍3～4倍

1.5～4倍2.0～3倍

（保守も）

1.2～3倍1.3～2.0倍

1.2～1.8倍1.1～1.3倍

（マニュアル）

1.0倍1.0倍

費用・構築費用・運用費用

6

3時間-6時間即時

3時間-6時間0分-10分

3時間-6時間10分-1時間



修復時間・故障修復・再立ち上げ

5

常駐常駐ケースによって

は2時間

1-3時間（昼）6時間（夜間）

1-6時間1-6時間（昼）12時間（夜間）

到着時間4

5分50分8.6時間86時間172時間サービス停止時間（）時間／年

3

あり(Hot stand by)


あり（2／N＋1台）

あり（部分的）

なしバックアップ機2

99.999%以上99.99%99.9%99%98%以下稼働率1

レベル５レベル４レベル３レベル２レベル１SLA項目

対象対象対象ペナルティ8

SANクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ三重化、四重化

SANクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ三重化

SANNASクラスタリングﾛｰﾄﾞﾊﾞﾗﾝｼﾝｸﾞ

NASシステム構成（例）必要な機能

7

4～6倍3～4倍

1.5～4倍2.0～3倍

（保守も）

1.2～3倍1.3～2.0倍

1.2～1.8倍1.1～1.3倍

（マニュアル）

1.0倍1.0倍

費用・構築費用・運用費用

6

3時間-6時間即時

3時間-6時間0分-10分




修復時間・故障修復・再立ち上げ

5

常駐常駐ケースによって

は2時間

1-3時間（昼）6時間（夜間）

1-6時間1-6時間（昼）12時間（夜間）

到着時間4

5分50分8.6時間86時間172時間サービス停止時間（）時間／年

3



あり（2／N＋1台）

あり（部分的）

なしバックアップ機2

99.999%以上99.99%99.9%99%98%以下稼働率1

レベル５レベル４レベル３レベル２レベル１SLA項目


238

（15）利活用が重要

───投資評価の実施、使いこなしが重要


図表 3-1-31 IT 企画推進要因費

システムの企画段階で 3 種類の責任者と役割の明確化が必要である。 ①システムを使いこなし効果を発揮する責任者（一人とは限らない） ②開発責任者（ユーザー側とベンダー側） ③保守運用責任者（ユーザー側とベンダー側）これにシステムを企画した企画責任者を加えた体制が終フェーズのここで効果を発揮する。特に企画責任者は、企画したものが実際に使われているのか、使われて効果を発揮しているか、

に配慮せねばならない。この企画部門の責任を表したのが上図である。利用部門が利用状況、効果に関心を持つのは当

然であるが、企画部門がこの後の効果フォローまで意識している企業は強い競争力をもってい

る。効果測定と評価の方法などは、第一巻に記述してあるが、JUAS は、なお詳細に追加分析を続

けている。3 年前には、大企業でも 45%の企業が効果測定を実施していなかったが、現在効果測

定を行っていない企業は 11％程度にまで減少した。効果手法は ROI、KPI、ユーザー満足度、他社との比較などで行われるが、更なる工夫改善が

求められる。

IT企画推進要員比が1.0％以上であれば、

強いリーダーシップを発揮することが可能になる

業務の深度

⑤開発済みシステム

の使いこなし指

導、効果算出

①予算管理

IT企画推進要員比1.0％以下 IT企画推進要員比1.0％以上

③技術の選択

標準化 ②業務改革

④EAコンセプト、

主要システム

の企画・開発に

おけるリーダー

シップ

1.0％の壁

IT企画推進要員比（IT企画推進要員数／全システムユーザー数）

./keyword.htm#1802

239

第３章開発保守技術第２節保守の実態と評価

システムの開発は短期間であるが基幹業務システムの保守作業は短くても 10 年、長ければ 20

年を越す作業となる。地味ではあるが、非常に大切な作業である。しかし、保守の品質とは何か。

生産性とは何か。保守作業者、管理者に聞いても、ほとんど明確な回答はない不思議な世界がこ

の保守作業である。システムの信頼性確保はこの保守作業から始まる。

保守作業とは何をすることなのかをまず認識し、保守作業の実態を分析し、保守作業の推進体

制にふれ、最後に保守作業の分析結果を載せた。世界でもきわめて珍しい調査・分析結果を収録

したが、ここを切り口として更なる保守生産性、品質向上対策に結びつくアイデアが続出し 2007

年度版ソフトウェアメトリックス調査報告書につながる準備をしている。

この保守作業の常識・標準値作成の足がかりになることを期待している。

１．保守作業の概要

２．保守作業基本分析

３．保守推進体制分析

４．保守作業分析

３－２保守の実態と評価

240

１．保守作業の概要

システムが稼動を始めると、この保守作業が始まる。この仕事の難しさは、他人が作成したプログラムを利用者の要求した新しい要望にあわせて修

正し間違いなく新機能を提供することにある。常に新規開発を短時間で要求されていると言って

も良い。開発時はテスト環境が整えられているが、保守に入ると十分なテスト資源が与えられないこと

が多く、厳しい環境での作業となる。その中で品質、生産性、納期を確保し、かつユーザーの満

足を得る仕事にエンジニアリングの視点を持って分析してみよう。経営的に見ると「開発はコストが多少かかっても、一次的なので我慢できるが、保守は半永久

的に続くので、コストダウンをしたい」との願望がある。この命題は保守作業担当者にとっては、

逆に厳しい命題になる。「安く良い品質の保守作業」のための諸施策を考えてみる。（１）保守戦略

保守作業のフェーズは、プロジェクトの保守をどのように実施していこうかとの保守戦略に始

まる。この基本戦略の有無は保守品質、生産性、SE の活動意欲、システムの信頼性、寿命、ユ

ーザー満足度など大きな影響力を持つ。該当プロジェクトだけでなく多くのシステム保守作業を

実行する企業全体の前提ともなるので、システムを長期間、上手に使いこなすためにこの保守戦

略の明記は欠かせない。保守計画書の作成を義務付け、保守標準を準備して保守作業の目標、評

価を明示し保守作業者に勇気と元気を与える仕組みを作っておく必要がある。プロジェクトを企画する場合は SLC（system life cycle）を通じた費用と効果に配慮が必要で

ある。「このシステムが完成後は何人でシステム保守をするのか」「何年間使い続けるのか。その間のハードウェア、ソフトウェアのサポートをベンダーは保証

しているのか」などを確認し、経営者やユーザーに対して責任を持たねばならない。使用開始直後にハードウェア、ソフトウェアのサポートが切れてしまった、などと不満を言っ

ても始まらないので、購入時の準備が大切である。（２）保守作業開始前

開発開始時から保守準備は始まっている。開発完了後から保守作業は始まるが、「誰が保守を担当するのか」「そのための保守容易性をど

のように確保するゆくのか」を決めてプロジェクトをスタートしないと、保守に対して無責任な

プログラムが誕生することになる。開発チームのレビューに参加し、RFP、設計書を理解し場合

によっては修正を依頼するなどのアクションが必要となる。・今まで使用していたシステムでプログラム保守の多かったプログラムあるいはモジュールは

どこなのか（これを Hot Module と言う）。・常識で考えて変更がもっとも発生しそうな箇所はどこなのか。

./keyword.htm#1801


241

・その部分は外部 Table 化、あるいは変動変数として扱えないか。・Module として独立できないか。システム変更を容易にする準備・工夫があるのでそれを検討し、開発者に依頼しておくことも

必要である。受身の保守作業から、攻めの保守作業に踏み込んでほしいものである。開発完了後の引渡しの方式・基準の設定、保守チームの編成（役割と保守担当者の選定）、業務

範囲、保守作業の目標、保守作業の効率化対策なども保守作業に入る前に決めておかねばならな

い。保守作業範囲は二つの形態に分かれる。（ａ）保守作業すべてを請け負う場合（ｂ）一定規模以下の日常保守案件のみを保守チームが担当し、それ以上の規模（金額又は人

月）の修正は別チームにて対応する場合通常は（ａ）で作業をしているが新しい大きな機能の追加などの場合は（ｂ）の方式をとるケ

ースもある。この場合も新規機能追加完了後には組織は（ａ）に戻る。 JUASの調査結果によると自社スクラッチ開発をした後も 1~2年間は比較的大きな追加開発依

頼が残っており、その予算の当初金額に対する割合は平均で 33%に達することが判っている。（後述の３．（７）ｂの章参照）（ｂ）方式を採用する場合は、同じプログラムを同時に保守することがないように分担を明確

化するか。資源をすべて別扱いするとか明確な作業分けが必要となる。これは本番移行時のバージョン管理に影響する。

（３）問合せ調査

システムは生き物であり、日常保守作業を通じて姿を少しずつ変えている。したがってシステ

ム利用者から日常の運用で発生する疑問やトラブルについての質問、改善要望が数多く発生する。この対応が「問合せ調査」の作業内容である。保守の修正作業中にこの質問が飛び込んでくる

ため修正作業の阻害要因にもなるが、緊急を要する場合が多く、優先度を上げて対応せざるを得

ない。即時対応ができ、かつその結果が有効であった場合は、ユーザーと友好な関係を築くこと

ができる。システム開発 SE は、ともすれば「予算がない、工期がない、あの機能はカットせよ」とユー

ザーと激論になり、友好な関係を築くのが難しい。しかし、この保守フェーズでは SE はユーザ

ーを支援する関係に入るので、お互いを尊重する雰囲気作りが可能になり、業務遂行時の楽しみ

も増え、さらには業務を覚えるきっかけもできる。保守作業は、開発作業と異なって新しい IT技術の習得などが少ないうえに、忍耐力を要するが、ユーザーとの関係構築の面では楽しみが多

い作業である。なおこの問合せ調査は、重要な作業にもかかわらず、ISO に明記されていないが、利用者との

インターフェイスであり、ユーザー満足度を高めるためには、この窓口に適材を配置しないとユ

ーザーとの良好な関係は築けない。


242

（４）保守作業受付と作業見積このフェーズで実施する作業内容は次の 4 項目である。

ａ．保守要求に対する回避策の提言ユーザーが提起してきた問題に対しての回答はプログラムの修正を必要としない方法が見つか

ったならばそのほうが良い。まずプログラムの保守作業をしなくてすむ対策を考える必要がある。ユーザーの実行したい願望の本質を聞き出してみると必ずしもプログラムの修正を必要としない

で既存の仕組みで対応できることが多い。ユーザーの要求の本質分析が重要である。

ｂ．複数システムの修正方法の列挙と選択次にプログラムの修正をせざるを得ないと判断した場合でも、通常はたった一つしか方法が存

在しないとする場合は稀である。この保守フェーズに入っての問題に対する解答は数種類見つか

るのが通常のケースであり、その中から効果最大、使用容易性最高で変更負荷が少なくかつトラ

ブルの発生が限定的な回答を採用すればよい。

ｃ．依頼に対する作業優先度付けさて回答が絞られ実際の保守作業に入るが、通常いくつかの案件を抱えているので、どれを優

先的に取り上げるべきか、優先度付けを検討しなければならない。ユーザー窓口とも相談し、効果、納期を勘案して着手する。この場合作業効率を考えるならば、個別要求にその都度対応するのではなく、要求をまとめて、

修正対象が同じプログラムならば同時に修正し、まとめてテストを行い確認すれば保守作業生産

性が向上する。この要因もあわせて実行着手を検討するのが良い。

ｄ．見積手法の選択と見積作業の実施システムの修正方法を決定する場合の見積作業はどのような基準、考え方により実施されるの

か。いくつかの手法を紹介する。 ①修正内容により負荷を加算して見積もる場合（ａ）帳票、画面の中の位置を調整する場合（ｂ）プロセスのロジック変更を要する場合（ｃ）データベースの値を変更する場合（ｄ）データベースの項目の変更や追加を実施する場合（ｆ）その他 ②ドキュメントの調査範囲、修正量、テスト確認の範囲に基づき負荷を予測する場合 ③該当する箇所だけでなく、関係箇所も含めて巻き込み範囲を定め（ｄ－②）を実施する場合（修正該当部分対象量÷生産性１）+（関連部分対象量÷生産性 2）＝必要負荷人月となる ④すべての作業の WBS を基に負荷を算出する場合 ⑤リスク要因も含めて負荷を算出する場合 ⑥その他


243

ｅ．システム再構築の見積方法とリスク変更規模が大きくなる場合の見積方法である。 JUAS の開発生産性部会で 2006 年 8 月に合宿し検討した結果を以下に示す。 Type1 を主体に検討してあるが、Type2 でも、リスク項目はほぼ同じであり、リスク予想数値％

が減少することを配慮して活用すればよい。

Type1：保守作業結果のアウトプット作成作業量をベースにした見積とリスク査定

Type2：WBS までブレークダウンした見積とリスク査定

Type1 は作成するアウトプットを基にした積上げに伴う見積方式であり、 Type2 は、綿密な調査を行い、WBS に落とした見積を実施する。

ｆ．見積担当・組織

保守作業量の見積作業を担当者任せにするのか、別組織で実施するのか、の選択もある。別組

織にするためには標準化が必要である。長く同じシステムの保守作業を担当すれば熟練し生産性の向上、工期の短縮が期待できるが、

生産性・品質の向上を含めて数値で明確に説明できないと保守経験者の有効性を発注者に理解さ

せるのは難しい。見積担当者が同じ組織内に属する場合、どうしても見積作業が甘くなりがちであるが、逆にそ

の見積結果を守ろうとする意識が反映する。別組織で見積もる場合は標準化技術レベルが一定水

準以上用意されていないと成功しない。保守作業は様々な想定外のアクティビティが発生しがち

でありこの見積標準のあり方は相当な工夫が必要である。別組織で見積もり、開発者とは関係な

い保守専任者が保守作業を担当し、なおかつ生産性が高く高品質を出す集団の出現とそのための

標準化技術が求められる。

調査

・既存システム資料

・新規追加機能

・開発体制

見積

WBS

積上

リスク査定

WBS ベース

調査

・既存システム資料

・新規追加機能

・開発体制

見積

作成資料

の積上

リスク査定

出力アクティビティベース


244

（５）修正作業の実施この作業は以下の 7 作業から成り立つ。修正しないで、別の方法にて対処することが理想であるが、この件については既に触れたので、

ここでは省略する。

ａ．修正追加箇所の発見と修正まず修正箇所の発見であるが、該当部分をまずチェックし次に関係箇所を念のために確認する。経験度によって生産性と品質に大きな差が出てくる。新しい要求仕様に対して、どことどこを修正すれば必要十分であるかを、保守作業を新しく引

き継いだ SE、プログラマが見つけて適切な処置をすることは、高度な技である。ましてや原プログラムやデータにミスが内蔵されている場合は、「何が正しいのか」を疑いなが

ら作業をし、必要以上のチェックとテストをせざるを得なくなる。現在の要求仕様書、設計書、プログラムシートは、ほとんどがマシンに内蔵されているが、こ

れらの関係が仕様番号でトレースできるようには実態として開発されていない。 IEEE の Std830 に 1997 年に、このドキュメント間のトレーサビリティの必要性がうたわれて

いる。図表 3-2-1 要求管理

「要求工学」の概要（第8回、第9回、第10回）

NTTデータ技術開発本部山本修一郎

2005-06/05

参照：IEEE-Std830 追跡性

DOD-Std-2167A

要求に対する責任部門要求の依頼元利害関係者

日付要求変更理由を明確にする要求変更理由

要求の優先順位要求理由や根拠

要求前提の仮定

要求理由

分析状況

分析中、保留中、確認中、修正中、確認済み

要求の分析内容、経費、期間

（ビジネス要求とソフトウェア仕様要求）

要求内容

作業開始日、終了日要求を一意に識別するための番号識別番号

補足項目主要内容管理項目

「要求工学」の概要（第8回、第9回、第10回）

NTTデータ技術開発本部山本修一郎

2005-06/05

参照：IEEE-Std830 追跡性

DOD-Std-2167A

要求に対する責任部門要求の依頼元利害関係者

日付要求変更理由を明確にする要求変更理由

要求の優先順位要求理由や根拠

要求前提の仮定

要求理由

分析状況

分析中、保留中、確認中、修正中、確認済み

要求の分析内容、経費、期間

（ビジネス要求とソフトウェア仕様要求）

要求内容

作業開始日、終了日要求を一意に識別するための番号識別番号

補足項目主要内容管理項目

（参考）清水吉男著技術出版社「要求を仕様化する技術・表現する技術」

上記 IEE－Std－2167A とは関係なく独自で、創案された素晴らしい方法が、上記参考書に紹

介されてある。要求仕様と理由を分けて記述されている。これらを参考に、JUAS では UVC プ

ロジェクトとして、要求仕様書から設計書、プログラムシートまで一貫してまとめる方式を提案

する準備を進めている。


245

ｂ．テストデータの準備引き継いだプログラムにバグが内在した場合の修正作業を主とする「是正保守」の場合は特に

その条件を作り出すことが出来、欠陥を再現することが出来るのか。そのためのテスト環境をどのようにして作り出すのか。その環境作成のための負荷軽減策などを考え欠陥の再生をトライすることが重要である。共通ルーチン、汎用クラスなどを修正する場合は、修正結果の影響がどこまで広がってくるの

か。理解できない場合もありテスト計画は念を入れて作成する必要がある。またテスト環境は、本番用環境、保守検証用環境とテスト環境を備えるのが理想であるが、費

用の制約あるいは必要度によって十分なテスト環境が準備されていないこともある。あるいはバックアップ機なしで休業日あるいは休み時間にのみテストを実施しているプロジェ

クトもある。与えられた環境を十分に活かしてテスト準備をする。なお現在ではハードウェアは日進月歩で革新されており安くなっている。保守の品質を問う作

業であるならば、テスト環境を十分に準備することが望ましい。 IT 動向調査 2004 年度での「基幹系システムにおけるバックアップマシンの所持状況と稼働率」

の状況を次に示す。稼働率 99.99%以上を実績で出している割合は、バックアップマシンを何重に持っていようが

いまいが、関係ないが、99.9%以下の割合はやはりバックアップ台数が多いほうが少ない。また稼動計画値と実績値の乖離％は、3 重が 1.36 2 重が 1.50 バックアップなしが 1.77 であ

り、バックアップ機の準備をしてあるほうが信頼性は高い。なおバックアップ台数を二重三重に持っていても実績として稼働率 99.90%切ってしまった理

由は次のような理由によるものであった。興味ある結果である。・プログラムバグでデータベースを破壊してしまい修復に時間がかかった・ウイルスにやられてしまい、バックアップが役にたたなかった・電源の予備が十分に用意してなかった


図表 3-2-2 バックアップマシンと基幹系システム稼働率

61%

45%

55%

31%

23%

27%

14%

27%

18%

23%

32%

26%

12%

8%

15%

17%

13%

14%

6%

7%

15%

11%

11%

11%

10%

13%

15%

17%

23%

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



１台のみ(n=439)



１台のみ(n=431)

目標

値実

績値

100% 99.99％以上 99.95％以上 99.90％以上 99.90%未満


246

ｃ．修正およびテスト実施修正作業を行い必要十分なテストケースを用いて検証する。短工期でかつ保守作業の精度を要求されるプロジェクトであるならば、本番用 DB と同じもの

を保守作業用に準備しておくことが望ましい。テストデータを直接作成し、テストし、失敗するよりも、テスト計画書を作成しテスト方法を

吟味してからテストに入るくらいの慎重さが欲しい。

ｄ．修正結果および修正箇所以外の不変確認正しく修正されてあるか、修正してはいけない箇所が修正されていないか、を確認する。特に修正してはいけない箇所が修正されていないかを確認するのは、そのための検証プログラ

ムを作成する準備が必要である。

ｅ．要望結果の確認保証要望してきたユーザーの望む通りの結果になっているのか。検証作業結果をユーザーが確認す

る。望む通りの結果になっていない場合は再度要求の趣旨の確認から始め、修正作業に入る。

ｆ．ドキュメントの修正と確認

修正結果を正しく分りやすく各種ドキュメントを修正する。テスト結果も含めて一定期間保管

する。元ドキュメントを直接修正した場合は、間違えた場合、修正が不十分な場合の再訂正はややこ

しいことになる。この仕様で完成と言うまでは別のバージョン番号を確保し、原ドキュメントを

修正しないなどの対策を採っている企業もある。それくらいの慎重さが要求される。ｇ．生産性・品質の確認

修正作業の生産性を確認し、計画時間と実績時間の差が大きいものは対策を議論して次回の修

正作業に反映する。あるいは見積基準を見直す。この PDCA を回すところに保守作業の前進対策が潜んでいる。「何回も訂正し、やっと完了した。もっと最初から正確な仕様を言ってくれればよいのに」と

ぼやいているだけでは、進歩しないことを改めて認識いただきたい。


247

（６）移行と評価ａ．納期の確保

修正結果を本番に持ち込む。修正要求を個別に本番に移すのが良いか、まとめてタイミングを

見て移行するのが良いかは修正内容、タイミング、緊急度によって異なる。データベースに新しい項目を設置した場合は特に注意を要する。保守作業者の立場を考えれば、修正作業完了時期が納期と見て良いが、「本番移行はまとめて」

実施するケースもある。保守作業に専念できれば、それに越したことはないが、実作業では、トラブルの修復、問い合

わせへの対応、より高い緊急保守の割り込みなどがあり、納期確保率は単純ではない。保守作業の納期はこのように微妙なニュアンスを含んでいる。

ｂ．品質の評価保守作業の品質とは何か。これについてはさまざまな意見がある。（ａ）本番に修正結果を移行したが結果が好ましくなく再度修正を余儀なくされる割合（ｂ）保守者が修正完了とユーザーに確認を求めたが、修正結果に問題があり再度修正作業を

余儀なくされる場合。ユーザーの要求仕様に問題があったために修正結果が不良であった場

合も含む。ユーザー部門の要求を正しく確認出来なかったのも保守部門の責任とする厳しい考え方であ

る。システムの最終顧客は商品の購入者である場合もありその場合は次の（ｃ）を評価指標

とする考え方もある。（ｃ）入力データの正確性、出力情報の正確性の品質を問う「顧客迷惑度指数」を品質評価値

とする方法もある。この目標値を向上させるためには、開発プログラムの品質、プログラム

保守作業の正しさ、セキュリティを含めて運用の正確性、停止時間の短縮、利用部門のデー

タ入力の精度確保など、さまざまな活動が確実に実行されないと、この指標値は目標達成で

きない。経営の総合活動を評価されている指標とも言える。


248

（７）保守担当者の育成

保守担当者を経歴別に分けると次の 2 種類になる。

ａ．開発チームに所属していた SE を保守作業者に配置する場合開発チームに所属して開発の背景、経緯、苦労したポイント、総合テスト時、移行時の課題な

どを肌で感じた SE がこのシステムの保守作業を継続して担当する場合は安心して任せることが

できる。しかし往々にして優秀な SE は保守作業をしたがらないことが多い。もっと新しい技術、

プロジェクトの経験をしたがるからである。

ｂ．このプロジェクトの開発経験がない SE が保守作業を担当する場合開発チームに所属していなかった SE が保守をする場合の予備期間や習熟度曲線はどのように

なるのか、コストを考えてもこの方法は成り立つのか、疑問とする人も多いが、開発者≠保守者

の関係を構築しないと開発者は永久に開発したプロジェクトから足を洗えないことになる。この難しい問題を説くために各社はどのような対策をとっているのか。この問題の解決策のノ

ウハウはあるのか。システムの信頼性確保のためにも、これから紐解きたい問題である。保守用

ドキュメントの確保と維持状況も関係する。基幹業務で長期的に活用するシステムでは、上級管

理職になっても、若い頃作成したプログラムの保守を担当させられることは、非常にマレであり、

どこかで後継者に引き継いで行かざるを得ない。後継者が開発したシステムではないプログラム

を高生産性・高品質で保守し続けることは大きな課題であるにもかかわらず、いまだにこの研究

は実施されたことがない。JUAS では、まずは実態把握から開始したい。（８）管理業務

ａ．環境維持作業

システム保守作業を円滑に進めて行くためにはそのための環境維持・改善が必要となる。ソフトウェアのバージョンアップにあわせての更新、ハードウェア、ソフトウェアのサポート

期間切れ、寿命にあわせての更新処置、BCP、DR への備え、セキュリティの確保対策なども保

守作業者の業務である。

ｂ．保守管理作業 SE が専任、非専任にかかわらず、ユーザー企業自社がシステム（ソフトウェア）保守作業を

する場合、情報子会社など含めて外部企業へ発注する場合、などで管理する業務の内容は異なっ

てくるが、何かのミスが発生しそれが社会問題化すれば、すべてユーザー企業の責任が問われる。そのためには保守作業を管理するために、どのような報告を求めアクションを実施すれば良い

のかが問われてくる。さらに現状維持のための管理だけでなく、コスト削減もユーザー企業のト

ップから問われてくる。この期待にも応えてゆかねばならない。

./keyword.htm#0201


249

２．保守作業基本分析

保守作業フェーズ区分に則り具体的に評価指標の現状を、8 業種、82 社から寄せられた JUAS

の 2006 年度ソフトウェアメトリックス調査結果に基づき観察、分析してみる。大質問項目は 12であるが、クロス分析によってさまざまな現状と課題が浮かび上がってくる。参考までにデータの特性をいくつかの表とグラフによって示しておく。すべての質問に回答いただくのは、非常に難しく、「自社ではこのデータは採取していない」と

して答えられないものもあるので一部合計回答数は 82 件に満たないものがあるが、総じて良く

回答していただいている。この質問表に答えることが、各社の保守作業を管理する結果になるよ

うに質問表を改善してゆく予定である。具体的な保守作業評価項目について他社の実態が知りた

い、ベストプラクティスを紹介して欲しいなどの要望にも応えて行けるようにしたい。この保守作業についての調査は世界的にも例が少ない。改善の手がかりになる質問が準備出来

たので次年度の調査結果がまた楽しみである。質問を改善し保守作業についての PDCA を回して

評価が正しく行うための保守作業評価指標を追究してゆきたいと考えている。

（１）保守調査対象プロジェクトの属性

ａ．対象システム業種別分類

6

21

23

15

7

3 3

01

16

21

5

2 2

9

12

1

87

0

5

10

15

20

25

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

業務種別

件数


図表 3-2-3 対象システム業種別分類


250

＜選択肢＞

1 経営・企画 2 会計・経理

3 営業・販売 4 生産・物流

5 人事・厚生 6 管理一般

7 総務・一般事務 8 研究・開発

9 技術・制御 10 マスター管理

11 受注・発注・在庫 12 物流管理

13 外部業者管理 14 約定・受渡

15 顧客管理 16 商品計画（管理する対象品別）

17 商品管理（管理する対象品別） 18 施設・設備（店舗）

19 情報分析 20 その他

業務種別の分類を行った。82 件のデータで重複回答があるため、割合の合計は 100％を超過す

る。会計・経理、営業・販売、生産・物流、マスター管理、受注・発注・在庫、顧客管理、以上

6 種のシステムのデータ件数が相対的に多い。

01 1 1

01

0 01

0 0

3

0

32

3

6

15

13

10

22

0

5

10

15

20

25

1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005

開発時期

件数


図表 3-2-4 開発時期分布

収集したデータの開発時期についての実態である。 20年前のデータのものもあるが、約25％のデータが2005年以降の新しいプロジェクトである。

古くから修正を重ねて寿命を延ばしている様子が伺える。


251

ｂ．業種分類

8

25

49

0

10

20

30

40

50

60

金融サービス製造

データ区間

件数


図表 3-2-5 業種分類

・金融、・サービス、・製造で業種分類を行った。相対的に製造の業種からのデータが多い。

ｃ．サイズ（FP）

0

1

3

1

4

6

4

00

1

2

3

4

5

6

7

0 ～100 ～500 ～1000 ～5000 ～10000 ～50000 50000～

FP値

件数


図表 3-2-6 FP 値分布

82 件のデータのうち、FP の記入のあったデータ 19 件について分析を行った。値の範囲が極

端に広く、データの 2 極化が見られる。平均は約 6300FP であるが、値の大きい 5000FP 超のデ

ータの影響が強いことが分かる。

./keyword.htm#0601


252

ｄ．サイズ（LOC）

0 0

3 34 4

16

2

00

2

4

6

8

10

12

14

16

18

0 ～10 ～50 ～100 ～500 ～1000 ～5000 ～10000 10000～

KLOC

件数


図表 3-2-7 KLOC 値分布

82 件のデータのうち、有効データである 32 件について分析を行った。桁数が大きくなるため、

KLOC に換算している。半数のデータが 1000KLOC 以上であり、1000-5000KLOC の階級にデ

ータが固まっている。平均は約 1600KLOC であるが、値の大きいデータの影響が大きい。ｅ．言語・プラットフォーム

14 14

17

5

31

0

19

0

5

10

15

20

25

30

35

COBOL C関連 VB関連 PL/SQL JAVA HTML その他

開発言語分類

件数


図表 3-2-8 開発言語分類分布

82 件のデータのうち、言語の記入のある 73 件のデータについて分析を行った。重複回答があるため、割合の合計は 100％を超過する。COBOL から Java に移り変わりつつ

時代の流れが伺われる。

./keyword.htm#1201


253

19

4

42 42

11

4

0

5

10

15

20

25

30

35

40

45

メインフレームオフコン UNIX Windows LINUX その他

開発PF

件数


図表 3-2-9 開発プラットフォーム分布

82 件のデータのうち、開発プラットフォームの記入は全データについて見られた。重複回答が

あるため、割合の合計は 100％を超過する。プロジェクト数とプラットフォーム数の割合は、ほぼ 50％増しであり、１プロジェクトで複数

の基盤を扱うケースが増加している状況が良くわかる。 Windows、UNIX のデータが顕著であるが、LINUX が活用され始めている様子がうかがえる。

ｆ．カットオーバー時の品質

7

25

30

18

2

0

5

10

15

20

25

30

35

1 2 3 4 5

カットオーバー時品質

件数


図表 3-2-10 カットオーバー時品質分布

82 件のデータのうち、カットオーバー時の品質の記入は全データについて見られた。典型的な

5 スケール選択型の項目であり、典型的な散らばり具合である。横軸の品質評価指標（保守発注側の責任者の主観）１．非常に良い２．良い３．普通４．やや悪かった５．非常に悪かった


254

３．保守推進体制分析（１）保守組織

保守を担当する人は誰なのか。保守SE約 700人を組織区分別に求めたのが図表 3-2-11である。

自社、情報子会社で半数以上の 54％を占め、社外要員もいるが自社と情報子会社と社外を含める

と 80％に達する。社外に全面的に依存しているプロジェクトは 20％である。やはり保守作業は身近の問題であり、自社あるいは情報子会社で責任を持って対応している。非専属要員の数え方は 10 人が 10％ずつサポートに借り出された場合は１人分としてカウント

してある。保守要員全体に対して専任は 34％、非専任者相当分が 43％、社外の応援を頼む分は 23％とな

っている。保守チームの要員数は平均 4 人となっているが規模が大きくなると 50 人、１チーム

の場合もある。

ａ．保守担当組織

16

23

12

35

14

54

0

5

10

15

20

25

1（自

社内

）

2（情

報子

会社

）

3(社

外）

4（そ

の他

）

5（1+

2）

6（１+

3）

7（2+

3）

8（1+

2+3）

重複を含めた保守担当組織

件数


図表 3-2-11 重複あり保守担当組織分布

重複回答も含めて分析した。単独保守では情報子会社、重複も含めると自社内保守が優位であ

る。自社あるいは情報子会社を中心に保守作業は実施されているが、必要に応じて開発者など外

部の応援を得ていることがわかる。これはコストの問題と内容を継承することの難しさの両方の

問題が影響していると思われる。


255

ｂ．保守要員種別図表 3-2-12 保守要員種別


平均中央値最小最大標本数

保守要員総数（人） 9.0 4 0 101 77

専任保守要員割合（％） 34.1% 17.0% 0.0% 100.0% 76

兼任保守要員割合（％） 42.7% 33.3% 0.0% 100.0% 76

社外応援要員割合（％） 23.2% 0.0% 0.0% 100.0% 76

保守要員について記入があったデータは 77 件であった。保守要員の総数は平均が約 8 人であ

り、62％のプロジェクトが 5 人以下となっている。

1

16

31

13

7 7

2

0

5

10

15

20

25

30

35

0 ～1人～5人～10人～20人～50人 50人～

保守要員総数

件数


図表 3-2-13 保守要員総数分布


256

16

8

22

9

2 2

00

5

10

15

20

25

0 ～1 ～5 ～10 ～20 ～50 50～

専任保守要員

件数


図表 3-2-14 専任要員総数分布

専任保守要員の分布を描いてみた。平均は約 4 人であるが、0 人のケースも 27％見られる。中

央値は 2 である。

（２）保守依頼数と実施割合

保守チームへの依頼数は平均 173 個／年で、依頼のあった 81％を実施している。対応しなか

った理由を図表 3-2-18 にまとめた。保守対応できなかったうち 32％は保守不要と判断しているので実際は 20％程度が予算不足、

人不足で対応が出来ていないとみなせる。ａ．保守依頼対応

1716

5

1514

32

0

2

4

6

8

10

12

14

16

18

20 50 100 200 500 1000 1000～

年間保守依頼数

件数


図表 3-2-15 年間保守依頼数分布

専任保守要員数

平均 4.067797標準誤差 0.908549中央値（メジアン） 2最頻値（モード） 0標準偏差 6.978698分散 48.70222尖度 19.48458歪度 3.982971範囲 44最小 0最大 44合計 240標本数 59信頼区間(95.0%) 1.818657

専任保守要員数

平均 4.067797標準誤差 0.908549中央値（メジアン） 2最頻値（モード） 0標準偏差 6.978698分散 48.70222尖度 19.48458歪度 3.982971範囲 44最小 0最大 44合計 240標本数 59信頼区間(95.0%) 1.818657


平均 173.431標準誤差 29.0845中央値 100最頻値 30標準偏差 246.791分散 60905.6尖度 10.4841歪度 2.88324範囲 1379最小 0最大 1379合計 12487標本数 72信頼区間(95.0% 57.993


平均 173.431標準誤差 29.0845中央値 100最頻値 30標準偏差 246.791分散 60905.6尖度 10.4841歪度 2.88324範囲 1379最小 0最大 1379合計 12487標本数 72信頼区間(95.0% 57.993


257


図表 3-2-16 保守依頼対応率

ｂ．保守依頼対応率と保守理由

年間保守依頼数は 2 極化を示しており、開発規模と関連がありそうである。保守依頼対応率は

高率を示しており、かなり対応ができているものと判断できる。年間保守依頼数はシステム年齢で変化することが考えられる。そこでカットオーバー後 2 年で

分けて分析してみた。図表 3-2-17 年間保守依頼数



年間保守依頼数＿2 年以上 152.391 76 0 1187 46

年間保守依頼数＿2 年以内 210.653 123 0 1379 26

年間保守依頼数＿全体 173.430 100 0 1379 72

若いシステムは安定していないので保守依頼数が大きくなっている。保守依頼対応件数を回答した 72 件のうち、対応しなかった件数回答がある 45 件（62.5％）に

ついて各データでの割合で統計値を算出した。不要判断、人手不足、即時性なしという理由が顕

著である。

保守依頼対応率

0.00 0.00 0.000.03

0.09

0.04 0.030.07 0.06

0.24

0.44

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

保守依頼対応率

件数

比

～～～～～～～～～～

依頼対応率

平均 0.81162標準誤差 0.0268中央値 0.88855最頻値 1標準偏差 0.2242分散 0.05027尖度 0.10703歪度 -1.1686範囲 0.72297最小 0.27703最大 1合計 56.8133標本数 70信頼区間(95.0% 0.05346

依頼対応率

平均 0.81162標準誤差 0.0268中央値 0.88855最頻値 1標準偏差 0.2242分散 0.05027尖度 0.10703歪度 -1.1686範囲 0.72297最小 0.27703最大 1合計 56.8133標本数 70信頼区間(95.0% 0.05346


258

ｃ．保守理由次に、保守理由を１年目と 2 年目以降に分けて分類してみた。

図表 3-2-18 保守理由（1 年目 2005 年カットオーバー）



保守理由＿システムバグ 33.0% 36.5% 0.0% 70.0% 22

保守理由＿担当者要望 42.7% 30.0% 10.0% 100.0% 22

保守理由＿制度ルール変化 4.5% 0.0% 0.0% 30.0% 22

保守理由＿業務方法変化 7.3% 0.0% 0.0% 30.0% 22

保守理由＿経営目標変化 3.4% 0.0% 0.0% 30.0% 22

保守理由＿ユーザビリティ変化 4.8% 0.0% 0.0% 30.0% 22

保守理由＿その他 4.3% 0.0% 0.0% 30.0% 22

図表 3-2-19 保守理由（2 年目以降 2004 年以前カットオーバー）



保守理由＿システムバグ 15.0% 10.0% 0.0% 64.0% 54

保守理由＿担当者要望 31.9% 30.0% 0.0% 79.0% 54

保守理由＿制度ルール変化 18.6% 10.0% 0.0% 60.0% 54

保守理由＿業務方法変化 16.5% 14.5% 0.0% 60.0% 54

保守理由＿経営目標変化 2.6% 0.0% 0.0% 30.0% 54

保守理由＿ユーザビリティ変化 7.8% 5.0% 0.0% 50.0% 54

保守理由＿その他 7.6% 0.0% 0.0% 60.0% 54

保守開始１年目はシステムバグや担当者の使い具合の悪さが多く、2 年目以降は制度ルールの

変更や業務方法の変化が多い。ユーザビリティの変更は担当者の要望にも含まれていると思うが

１年目は最低限なユーザビリティの変更にとどめ、２年目以降に修正を回している様子が伺える。初心者用のユーザビリティからある程度熟練したユーザビリティに変えているのかどうかなど

の分析は今後の課題である。

図表 3-2-20 保守対応しなかった理由



対応なし割合＿不要判断 32.2% 25.0% 0.0% 100.0% 45

対応なし割合＿人手不足 21.9% 0.0% 0.0% 100.0% 45

対応なし割合＿経済理由 8.3% 0.0% 0.0% 70.0% 45

対応なし割合＿即時性なし 17.2% 11.1% 0.0% 70.6% 45

対応なし割合＿工期不足 6.3% 0.0% 0.0% 100.0% 45

対応なし割合＿スキル不足 2.2% 0.0% 0.0% 43.8% 45

対応なし割合＿その他理由 11.9% 0.0% 0.0% 100.0% 45


259

（３）保守要員一人当たり年間対応件数

保守要員一人当たり年間対応件数は、平均で 38 件／年、3 件/月程度になる。問い合わせへの

回答など他の作業もこなしながらの対応件数である。中央値はこの半分程度であるので大きな修

正が入った場合は 1.5 件／人月程度になる。開発者が引き続いて保守をした場合と、開発にタッ

チしておらずに保守作業をした場合の生産性の比較データが欲しいところであり、次年度の調査

項目に取り入れてある。

ａ．保守要員 1 人当たりの年間対応件数

1

42

10

5 42

6

0

5

10

15

20

25

30

35

40

45

0 ～20 ～40 ～60 ～80 ～100 100～

要員１人当たり年間対応件数

件数


図表 3-2-21 保守要員 1 人当たり年間対応件数分布

保守要員 1 人当たり年間保守依頼対応件数の統計を取った。平均は約 38、中央値は約 15 であ

る。グラフからわかるように件数では圧倒的に 0-20 のランクのデータが突出している。


平均 38.20300644標準誤差 7.589975034中央値（メジアン） 15.71153846最頻値（モード） 2標準偏差 63.50228714分散 4032.540472尖度 10.39600845歪度 3.100413411範囲 340最小 0最大 340合計 2674.210451標本数 70信頼区間(95.0%) 15.1415812


平均 38.20300644標準誤差 7.589975034中央値（メジアン） 15.71153846最頻値（モード） 2標準偏差 63.50228714分散 4032.540472尖度 10.39600845歪度 3.100413411範囲 340最小 0最大 340合計 2674.210451標本数 70信頼区間(95.0%) 15.1415812


260

図表 3-2-22 要員 1 人当たり年間対応件数比較


保守組織平均中央値最小最大標本数

全体 38.2 15.7 0.0 340.0 70

自社内 21.2 14.5 2.0 70.0 16

情報子会社 21.7 11.1 1.7 70.0 18

社外 42.5 13.3 1.0 216.5 11

その他 64.0 85.3 8.8 98.0 3

自社+情子 13.9 16.8 3.7 18.2 4

自社+社外 78.0 17.3 0.0 340.0 10

情子+社外 20.6 16.7 3.9 42.1 5

自社+情子+社外 115.5 162.5 9.7 174.2 3

保守組織別に要員 1 人当たり年間対応件数を比較した。保守を外部組織に依存すればするほど

件数が増加する傾向がうかがえる。特に、自社+社外の組織構造の場合、件数は増加する。外部からの支援者は該当システムの経験者であり、効率よく作業をしている様子が伺われるが、内部専任者は「問い合わせや調査」などの保守作業実施以外の作業に追われている分は、上記

対応数に含まれていないことも、配慮しておかねばならない。サンプル数が少ないので、なお追跡の必要があるが業種別対応数、引き受け率を調べてみた。

図表 3-2-23 保守要員一人当たりの年間対応件数（業界別）と引き受け率


平均中央値

件数対応率件数対応率

最大最小標本数

金融 10.5 75 5.5 60 2.0 21.7 8

サービス 36.9 90 11.6 65 0.0 340.0 19

製造 43.9 78 17.6 82 2.0 288.0 43

金融の標本数が少ないが、精緻にテスト、確認作業、ドキュメント化を実施していると思われ

る。対応率＝保守対応数/依頼総数を参考に載せておいた。中央値で見ると約 1/3 は別の対応方法で

済ませたのか。他の理由で対応しなくてすんだのか。いずれにしてもこの対応率は考えさせられ

る課題である。


261

（４）保守要員の守備範囲

01

5

8

15

1 1

0

2

4

6

8

10

12

14

16

0 ～10 ～50 ～100 ～500 ～1000 1000～

KLOC保守守備範囲

件数


図表 3-2-24 KLOC 保守守備範囲分布(非専任要員を含む)

保守要員は平均で 21 万 step、中央値で 10 万 step であるが、ばらつきは大きい。業種別の考察として、金融業は守備範囲が狭く、製造業は守備範囲が広いという傾向が見られ

る。システムの開発の計画時に、保守要員数の目標を、システムの変更度、システムの安定度、シ

ステムの品質、対応の迅速性などを配慮して、概算予算を立てる場合の根拠として利用すればよ

い。専任保守要員数はさらに絞られて、平均 56 万 step、中央値は 25 万 step になっている。シス

テムの内容、開発年度、利用状況などの理由で異なっている。

KLOC守備範囲

平均 210.0842916標準誤差 45.05811078中央値（メジアン） 101.7391304最頻値（モード） #N/A標準偏差 250.8729434分散 62937.23375尖度 7.459366189歪度 2.427994965範囲 1191.646最小 8.354最大 1200合計 6512.613041標本数 31信頼区間(95.0%) 92.02084379

KLOC守備範囲

平均 210.0842916標準誤差 45.05811078中央値（メジアン） 101.7391304最頻値（モード） #N/A標準偏差 250.8729434分散 62937.23375尖度 7.459366189歪度 2.427994965範囲 1191.646最小 8.354最大 1200合計 6512.613041標本数 31信頼区間(95.0%) 92.02084379


262

専保備要員_分布

0

1

2

1

11

6

2

0

2

4

6

8

10

12

0 ～10 ～50 ～100 ～500 ～1000 1000～

KLOC専任保守守備範囲

件数


図表 3-2-25 KLOC 専任保守守備要員分布

図表 3-2-26 保守要員守備範囲


保守守備範囲（専任+非専任）専任保守守備範囲

平均中央値平均中央値

1476 736 3050 1962FP

177Kloc 換算 88Kloc 換算 366Kloc 換算 235Kloc 換算

210 102 557 250Kloc

1750FP 換算 850FP 換算 4641FP 換算 2083FP 換算

保守要員一人当たり、どの程度の規模まで保守範囲を拡大できるかは興味ある課題である。 1FP≒0.120Kloc として換算したのが、FP の行の下の段の値であり、逆に Kloc をＦＰ換算し

なおしたのが、KLOC の下の段の値である。非専任保守要員を含む、保守要員一人当たりの守備範囲は、おおよそ 10 万 Step～20 万 Step

（Cobol ベース）、700～1750FP（FP ベース）を持ち、システム保守をしている。これを保守専任者だけを対象にして計算してみると、おおよそ 25万Step～56万Stepになる。

保守要員の作業の厳しさが表れている値である。ほとんど修正が発生しないシステムや、発生す

ることが非常に少ないシステムに、システム保守要員をつける必要はない。このプロジェクトごとの性格が、システム保守範囲／保守要員一人当たりの差になって表れて

いる。おそらくカットオーバー後の年数も関係してくると思われるが、個別プロジェクトで、か

つ安定度合により対応要員数の差が生じるのは、やむを得ない。しかし優れた保守性を持つシステム、保守作業が殆ど発生しないプロジェクトは、50 万 Step

場合によっては 100 万 Step の範囲を一人でカバーしていることが今回の調査で判明した。保守作業は継続して数十年続くのでこの保守性の向上は大きな課題である。多少開発費をかけ

ても保守性の良いシステムを作成しておくなど、幅広い対策が求められている。


平均 556.7398422標準誤差 189.1880569中央値（メジアン） 250.0908889最頻値（モード） #N/A標準偏差 907.3140469分散 823218.7797尖度 14.71455445歪度 3.609521443範囲 4329.811最小 8.354最大 4338.165合計 12805.01637標本数 23信頼区間(95.0%) 392.352437


平均 556.7398422標準誤差 189.1880569中央値（メジアン） 250.0908889最頻値（モード） #N/A標準偏差 907.3140469分散 823218.7797尖度 14.71455445歪度 3.609521443範囲 4329.811最小 8.354最大 4338.165合計 12805.01637標本数 23信頼区間(95.0%) 392.352437


263

４．保守作業分析

（１）保守作業負荷

保守作業負荷の状況を図表 3-2-25 に示す。保守作業のうち半日以下で完了してしまう軽微なも

のが 25％ある反面 1 週間以上かかるものも、ほぼ同じ割合で発生している。

図表 3-2-27 保守作業負荷



保守作業半日以下割合 25.6% 10.0% 0.0% 90.0% 73

保守作業 1 日以内割合 19.5% 10.0% 0.0% 100.0% 73

保守作業 3 日以内割合 17.7% 15.0% 0.0% 100.0% 73

保守作業 1 週間以内割合 13.4% 10.0% 0.0% 80.0% 73

保守作業 1 ヶ月以内割合 15.4% 5.0% 0.0% 100.0% 73

保守作業 1 ヶ月以上割合 8.4% 0.0% 0.0% 90.0% 73

回答のあった 73 件のデータで項目ごとの割合の統計を算出した。半日以下、1 日以内の作業時

間が相対的にやや多く、この 2 項目で半分弱を占める。その一方、一週間以上の割合は約 25％も

見られ、決して少ない割合ではない。プログラムの修正はもとより、ドキュメントの修正、テスト結果の確認、必要以上の箇所を誤

って修正していないことの確認などを、実施して半日以内で完了できるのか、と疑問を持つ方も

ある。次年度の追跡分析が楽しみである。

（２）見積基準

図表 3-2-28 保守工数見積基準


件数割合

工数見積り基準あり 38 47%

工数見積り基準なし 43 53%

保守作業の工数見積り基準の有無については 81 件のデータで回答があった。基準のありなし

が、若干「なし」が多いものの、約半々に分かれている。

図表 3-2-29 負荷軽減策


件数割合

保守負荷を低減するしくみあり 42 55%

特別な配慮はしていない 35 45%

保守負荷低減のしくみの有無についての回答件数は 77 件であった。工数見積り基準の有無と

は逆で、若干「あり」が多いものの、約半々に分かれている。「特別な配慮はしていない」プロジェクトは当然なんらかの負荷軽減策を考える必要があるが、

「保守負荷を低減するしくみあり」のプロジェクトでも、更なる効率化対策を追究してゆかねば

ならない。


264

（３）見積作業工数との対比

見積手法がどのような実態であるのか分かっていないので今後追究するが、作業が効率的に行

われたかどうかは「見積作業時間」と「実績作業時間」との比較になる。この値はまだ収集していないが興味ある課題である。

（４）修正の実施

ａ．保守欠陥率業種別保守欠陥率

図表 3-2-30 保守欠陥率製造業



初年度保守欠陥率_製造 12.6% 9.0% 0.0% 50.0% 33

2 年目以降年間発生保守欠陥率_製造 7.0% 5.0% 0.0% 40.0% 35

2 年目以降受入確認即時合格率_製造 86.6% 90.0% 20.0% 100.0% 38

図表 3-2-31 保守欠陥率サービス業



初年度保守欠陥率_サービス 30.4% 10.0% 0.0% 90.0% 11

2 年目以降年間発生保守欠陥率サービス 8.0% 5.0% 0.0% 30.0% 11

受入確認即時合格率_サービス 79.7% 95.0% 0.0% 100.0% 12

図表 3-2-32 保守欠陥率金融業



初年度保守欠陥率_金融 11.3% 10.0% 0.0% 35.0% 8

2 年目以降年間発生保守欠陥率_金融 9.8% 10.0% 0.0% 15.0% 8

2 年目以降受入確認即時合格率_金融 85.0% 95.0% 40.0% 100.0% 7

図表 3-2-33 保守欠陥率まとめ



初年度保守欠陥率_全体 16.1% 10.0% 0.0% 90.0% 52

2 年目以降年間発生保守欠陥率_全体 7.6% 5.0% 0.0% 40.0% 54

2 年目以降受入確認即時合格率_全体 84.9% 90.0% 0.0% 100.0% 57

初年度を除く欠陥発生率は、業種に関係なく 7～10％に収まっている。興味あるのはサービス

業で初年度の欠陥発生率と次年度以降の欠陥発生率の差が大きい。開発は品質よりも工期優先で

早く作ることに主眼をおくサービス業の特徴と理解できるのではないか。開発完了後 2 年目以降で修正要求に対して、１回で受入検査合格になる割合は 80～87％に収

まっている。これは相当に優秀な値である。この値を参考に 1 回で受入検査合格になる割合の目

標値を 90％にして各社で努力するなどの指標が考えられる。品質目標値のセットは大切である。


265

ｂ．完了時の品質と保守結果の品質

完了時の品質と保守結果の初年度の品質には相関関係がある。図表 3-2-34 完了時の品質と保守結果


開発完了時の品質 1.非常に

良い

2.良い 3.普通 4.やや悪い 5.悪い

（標本数少で

あり参考）

初年度欠陥率％ 11.7 10.5 17.4 22.5 8.5

修正後即合格率 91.6 88.7 85.4 76.8 90.0

2 年目以降年間欠陥発生率 7.3 4.5 7.7 11.3 3.5

標本数 3 15 18 14 2

保守作業半日以下の割合 20.0 27.1 23.6 26.5 40.0

初年度欠陥率、修正後即合格率とも開発品質の良いプロジェクトは、開発後の保守品質の実績

も良く出ている。その逆に品質が「やや悪い」と評価されているプロジェクトは、1 年目はもと

より、2 年目以降の品質も尾を引いてよくない。おそらく修正箇所以外の欠陥も現れてくる、開

発時に保守容易性を考えてプログラムが作成されていない、十分なテストも行われていなかった、

あるいはドキュメントも正確に残されておらず仕様が正確にわからないなどの理由が存在してい

ると思われる。開発後２年目以降の保守品質は開発時の品質と関係ない。これは保守者が責任を持って保守作

業を推進しているためと思われる。「品質が悪い」5 番目の列は標本数が少なく参考にとどめたい。なお品質の評価の「良い」「悪い」は、回答者の判断に委ねられており、具体的な欠陥発生数に

基づいた区分ではないことを最後に触れておきたい。

ｃ．保守理由

図表 3-2-35 業種別保守理由


保守理由

標本数

金融

7

サービス

21

製造

48

理由別割合％平均中央値平均中央値平均中央値

システムバグ 11.4 10.0 23.0 18.0 20.3 15.0

担当者の要望 26.4 20.0 40.3 30.0 34.0 30.0

制度・ルールの変化 25.7 15.0 10.4 5.0 14.7 10.0

業務方法の変化 22.2 10.0 13.5 8.0 17.2 10.0

ユーザビリティ変化 11.4 0 5.6 0.0 6.8 5.0

その他 2.9 0 7.2 0.0 7.0 0.0

金融業はバグのための修正は少なく、制度・業務方法の変更が 49.9％と半数を占めている。変

更せざるを得ない理由で修正を余儀なくされている。サービス、製造業は担当者の要望が多い。


266

（５）移行と評価

ａ．納期遅延

納期遅延率は中央値で見ると 1.5～5％程度に収まっており比較的良く守られている。問い合わせの対応や、突発作業の割り込みがある中で、保守担当者は良く努力している。

図表 3-2-36 納期遅延率


業種平均中央値標本数

全体 9.6 5.0 64

金融 10.1 5.0 7

サービス 14.6 1.5 16

製造 7.5 5.0 41

ｂ．見積基準と納期遅延との関係

図表 3-2-37 納期遅延率見積基準あり、なし



納期遅延率_工数見積り基準あり 13.1% 5.0% 0.0% 100.0% 31

納期遅延率_工数見積り基準なし 6.4% 1.5% 0.0% 35.0% 32

工数見積り基準があると納期遅延になることは少ないのではないかという仮説で分析を行った

が、逆に納期遅延率が大きくなってしまっている。工数見積り基準ありには、納期遅延率 100％、

50％という極端な値がありこれを除いても工数見積り基準なしの値よりも劣っている。少なくと

も工数見積り基準があることが納期遅延防止につながっているとはデータ的には言えない。その理由として、・作業見積者と実施者が異なる・見積基準が現実を反映していない・他の要因（緊急割り込みなど）の影響度などが考えられる。

（６）保守担当者の育成

システムの寿命が長い場合は特に開発者から保守専門者に作業を移管して行かねばならない。その場合の育成方法、課題を論じたいが現時点ではまだデータを持たない。関係者での息の長い検討が必要である。


267

（７）管理業務

ａ．保守作業の管理

保守作業をどのように管理しているのか、どのようなドキュメントを使って費用削減、品質向

上、納期保証、利用者の質問への回答レベルとサービス度の向上、担当者のモラル維持などを推

進しているのか、は興味ある課題であるが、まだ分析は十分ではない。品質目標は上記に考えかたと実績を掲げたが、保守作業は労多く功少ない業務である。工場の安全度数率（100 万作業時間に対しての災害数などの割合で表彰する制度が一般に行わ

れている）表彰のような保守災害影響度数は考えられないものか。大きなミスは高損害ポイントと小規模なミスは小損害ポイントと決めて年間の損害度を低下さ

せて目に見える管理をするなどの工夫が求められる。ｂ．年度別保守費用の変化（ERP と対比）

保守作業の予算は開発投資規模に対してどの程度必要か「ERP パッケージの保守費用を 20％も請求されるのは高い」とユーザーからは不満の声があ

がっているが、では自分で開発したシステムはどの程度の費用がかかっているのか。自社開発のスクラッチシステムの保守費率は

｛年度別保守費÷初期投資費用｝+｛該当システムの年度別開発費÷初期投資費用｝で把握できる。初年度は開発時に積み残した機能の開発が入ってくるので高いことを予想して

いたが、安定しても一般には初期投資費用 10%程度はかかっている。ただこの値は、開発したシステムの性格、開発時のシステム品質などの影響を大きく受けて

「0％から 100%にまでバラツキ」がある。したがって個々のシステムの保守予算を確保する仕方

はケースバイケースとなる。年度別保守費は開発直後には、やはり利用者が使いこなすための修正が相当量要求されるが、

年を追って安定してくる。該当システムの年度別開発費とは、保守予算ではカバーしきれない大きい修正や追加作業のた

めの費用を意味する。他のシステムを開発した影響で該当システムを修正するための費用なども

大きな修正になれば、この予算を使う。自社開発したシステムと ERP パッケージ活用の導入後 5 年間の保守経費モデルを下表に示す。自社開発システムも投資予想していたよりも多くの保守経費がかかっている。ERP パッケージ

の活用は本体の保守費用に加えて、追加修正の費用が結構かかるので、できる限りパッケージの

機能をそのまま活用することが望まれる。


268

図表 3-2-38 保守費用分析


パッケージ本体費用 b 保守費用分析

(中央値を採用)

自社開発 a

アドオン開発費用 c

保守費用(件数) 開発費用(件数) 合計本体保守(件数) 開発保守(件数)

初年度開発費用 6.0% (30) 23.1% (36) 29.1% 17.2% (4) 3.1% (4)

2 年目開発費用 10.6% (28) 10.5% (33) 21.1% 17.0% (3) 5.6% (3)

3 年目開発費用 10.5% (23) 5.5% (25) 16.0% 17.0% (3) 5.0% (3)

4 年目開発費用 8.7% (19) 2.0% (19) 10.7% 9.9% (2) 3.5% (2)

5 年目開発費用 5.0% (14) 2.7% (15) 7.7% 2.8% (1) 3.3% (1)

年間平均 8.2% 8.85 16.9% 12.8% 4.1%

初期開発費用 a b C

b + b × 0.13 × 5 合計費用比較 a + a × 0.17 × 5

= a × 1.85 c + c × 0.04 × 5

自社開発をしたほうが安いか、ERP パッケージを活用したほうが安いか、判断に悩むことがあ

る。上記資料を基に吟味してみる。注意してほしいのは、「上記式の数値だけに着目し比較するこ

とは避けてほしい」ことである。ａ×1.85 やｂ×1.65、ｃ×1.2 の積算結果値が問題になる。ａ、ｂ、ｃの値によっても、どち

らが高いのか影響をうける。

＜検討＞ここで簡単な試算をしてみる。ａ＝ｂ＝ｃならば 1.85：2.85 で、パッケージは不利となる。ｂ＝0.8ａｃ＝0.2ａならば 1.65×0.8+0.2×1.2＝1.56 でパッケージがやや有利となる。

上記式内で使われている、数値ｂは今回のデータ収集結果に基づく数値であり、実プロジェク

トの見積では、ベンダーからの提示の数値を活用することになる。ａ、c も自社用、今回プロジ

ェクト用に修正して活用されたら良い。


269

ｃ．保守費用の現実的モデル

図表 3-2-39 ソフトウェアの保守費用について

原表では、データ数が少ないなどの事情があり、多少修正しモデル化して SLC（システムライ

フサイクルコスト）を考えたほうが良い部分があるので、調査結果の特徴を活かして現実的モデ

ルを以下に提案したい。 ERP 型は 20％／年（パッケージによって差がある）程度のパッケージ保守費用が永続的にか

かるが、スクラッチ型は開発直後の 2 年間で追加開発費用が 50％（25％／年）かかるが、次の 3年間は 11％／年平均に下がる。それ以降は 8％／年程度に低下する。初期投資を含めての総費用モデルは、以下のようになる。

図表 3-2-40 総費用モデル

1～5 年 6 年～10 年

スクラッチ型ａ+ａ×0.85 ａ×0.08×5

ERP 型ｂ＋ｂ×0.20×5.+ｃ×0.04×5 ｂ×0.2×5.+ｃ×0.04×5

スクラッチ型累計ａ×1.85 ａ×2.25

ERP 型累計ｂ×2.0.+ｃ×0.2 ｂ×3.0.+ｃ×0.4

仮にｂ＝0.8ａｃ＝0.2ａとすると 5 年間では ERP 型は 1.8ａ 10 年間では 2.4ａ+0.08ａ＝2.48ａとなる。

つまり最初の 5 年間ではやや安く、次の 5 年間ではやや高くなる。各プロジェクトにより、ａとｂ、ｃの比率は異なるので、プロジェクト別に試算されたら良い。通常、ERP 型はこのほかにも、導入指導のためのコンサルタント費用やバージョンアップ費用

等がかかることがあるが、ここではそのような要因は除外して計算した。

初期投資費 1.0

2.0

3.0

5 年 10 年

ERP 型

スクラッチ型


270

図表 3-2-41 参考：保守作業とその評価

フェ

ーズ主たる作業内容評価項目

調

査補足

保守

戦略

・保守戦略、計画書の作成

・保守標準の準備

・専任か非専任か（保守組織の有無）

・保守手順

・見積標準の有無

・担当者の守備範囲（FP、LOC／人月）

・開発チームへの保守容易性確保のガイ

ド有無

06

06

06

06

07

保守組織の有無質問な

し

具体的な方法の確認要

保守

フェ

ーズ

前

・レビュー会議に参加

・ドキュメントの査閲、指導

・保守担当者（社）の役割と選定

・保守作業目標（品質、生産性）

・保守資源

・引渡し方法と支援

・引渡し後の支援（非専任者の

協力範囲）

・「事前準備の良いプロジェクトは初年度

の品質が良い」ことの証明可能か

・24 時間随時テストの可能性、DBの準備

07

07

07

専任者の開発班との関

係

品質生産性の目標の付

与か

本番機と全く同じ DB 準

備か

問合

せ、

調査

利用者からの質問への回答

・即時応答率、保留残存率、担当者の処

理時間比

07 この作業の割合は重要

質問

保守

作業

受付

と

作業

見積

（1）保守要求の内容確認と保守

作業回避策の提言

（2）依頼の作業優先度付け

（3）複数システムの修正方法の

列挙と選択

（4）見積手法の選択と見積作業

の実施

（5）テスト方式の確認

（6）実施可否の確認

・改善提案度数

・対応状況度（受付、かつ実施する割合）

・見積手法別のばらつきの確認

・見積手法の採用比率

・テストツール、テスト DB の準備など

07

06

生産性に大きく影響する

修正

の実

施

（1）修正追加箇所の発見と修正

（2）テストデータの準備

（3）テスト実施

（4）修正結果および修正箇所以

外の不変確認

（5）要望結果の確認保証

（6）ドキュメントの修正と確認

（7）生産性の確認

・保守時間／件

・フェーズ別作業時間

・保守件数／人

・保守欠陥率（開発品質との関係含む）

・顧客の確認・修正後即時合格率

・ドキュメントの修正度

・保守作業時間比率

・見積時間に対する実績作業時間比

06

06

06

06

07

07

フタコブラクダの検証

採取可能か

移行

と評

価

（1）納期の確保

（2）開発の品質と保守品質の関

係

・納期遅延率と原因

・受入総合テストの品質と本番移行後の

品質

・稼動時の品質と保守欠陥率の関係

06

06

06

保守

担当

者の

育成

・専任要員の備えるべき資質、

能力とは

・開発チームから継続の割合

・保守専任教育のカリキュラム

07 非継続者でも可能な割

合

管理

業務

・保守生産性向上、安定稼動対

策などの計画、および環境作

り

・管理、報告作業

・保守費用

・管理作業別の納期、作業量の評価

・上記すべての作業の報告責任

・ユーザー満足度

・年度別保守費用の変化（ERP と対比）

07

07

06

この作業時間割合は

フォローが必要


271

参考：保守作業の種類調査に当たって保守作業とは何かが話題に上がった。まず、保守作業の対象は以下のように保守の問い合わせ、基盤整備、是正保守、適応保守、完

全化保守の 5 項目から成っている。図表 3-2-42 参考：保守作業一覧

保守の問い合わせ

1-1 問い合わせの識別、案件番号の発行、登録

1-2 問い合わせ者への支援、回復方法指示、データ採取、方法指示、連絡代行、システム

利用者への助言、新商品・事例などの紹介

1-3 質問の調査中間回答、正式回答

1-4 変更担当作業者への指示タイプ、優先度、作業見積、実施可否の調整、作業担当と

の調整、対応計画作成、進捗フォロー

1-5 企画提案調査、情報収集、見積

1

1-6 保守作業についてのユーザー満足度の把握

ユーザー満足度調査の準備、実施とまとめ

保守の基盤整備

2-1 調査環境の整備再現テスト環境の維持、文書履歴の保存管理と履歴検索システム整

備、リバースエンジニアリング環境の保存、遠隔端末の設定およびトラブル処置

2-2 テスト環境の維持整備客先動作環境の確認、性能確認ツールの整備、リグレッション

（修復希望箇所以外の箇所について健全性の確認手段の確保）

2

2-3 保守作業環境の整備

作業場所、作業ツール、リポジトリーなどの整備

保守作業者への支援作業指導育成

予算管理予算、生産性、品質、工期管理

是正保守開発時あるいは保守作業時に生じた不良や故障の是正処置

3-1 不良内容の把握（再現テスト）

3-2 不良内容の分析・原因切り分け

3-3 是正計画の作成、変更方法検討

3-4 変更および変更部分のテスト

3-5 リグレッションテスト（修正必要箇所以外の箇所を間違って直していないか）

3-6 移行（本番投入、確認、ユーザーへの引渡し）

3

3-7 移行後のフォロー

適応保守

法律の変化、新しい受注仕様への対応、新顧客仕様への対応、新設備・新環境への対応、ハード

ウェア、ソフトウェア、ネットワークの新技術環境への対応など

4-1 環境変化情報の把握

4-2 影響範囲の調査・分析

4-3 適応計画の作成、変更方法の検討


4-5 リグレッションテスト

4-6 移行本番投入、確認、ユーザーへの引渡し

4


完全化保守

既存ソフトウェアの品質（性能、保守性、セキュリティ対策など）の向上

5-1 既存ソフトウェアの品質向上要件の把握

5-2 要件関係部分の調査・分析

5-3 完全化計画の作成、変更方法検討


5-5 リグレッションテスト

5-6 移行本番投入、確認、ユーザーへの引渡し

5



272

273

第３章開発保守技術第３節ユーザビリティと画面デザインプロセス

この節では、ユーザビリティの高い画面デザインを実現するための、具体的な「画面デザイン

プロセス」について記述する。ユーザビリティの高い画面デザインという「結果」だけをいくら

紹介しても、そこに至るプロセスが分からなければ、自らの開発には適用できない。結局、「セン

スと権限のある画面デザイナーがプロジェクトに参加することがなければ、ユーザビリティの高

い画面デザインはできない。」という昨日と同じ認識に立ち返るだけである。そうではなく、情熱

と信念のある開発者は、開発プロセスさえ間違えなければ、ある程度のユーザビリティを備えた

画面デザインは実現できるのだということを伝えたい。そのプロセスのメソッドを紹介すること

が、この節の目的である。

基本的には、「ユーザー中心設計」（User-Centered Design：UCD）の考え方を踏襲しているが、

実際の開発現場の実態を踏まえた方法論となっている。

内部設計以降の局面では、ウォーターフォール型の開発が十分に力を発揮する。また、そうで

なくては、ある程度の規模を超える企業システム開発の現場への適用はできないだろう。従来の

UCD の手法は、開発の全行程をスパイラル化しようとしたところに、大きな難点がある。この節

の方法論は、UCD メソッドを「画面デザインプロセス」に特化させたところに特徴がある。

１．ユーザビリティの必要性

２．ユーザビリティとシステム開発

３．User-Centered Design（UCD）メソッドの全体像

４．企画

５．設計：調査分析フェーズ

６．設計：プロトタイピングフェーズ

７．実装前工程

./keyword.htm#2801

３－３ユーザビリティと画面設計プロセス

274

１．ユーザビリティの必要性

Web システムの出現により、従来に増して画面の操作性機能の充実が図られ、汎用機のシステ

ムでは活用できなかった機能が登場してきた。少し考えるだけでも、次のようななど表現力の充

実が図られている。・画面の文字のサイズは自由に選択可能・白黒主体からカラーの時代へ・ビュー画面が充実しさまざまなコードの選択が可能・ラジオボタンなどの画面コントロール機能の増加・イメージデータ、写真の活用も可能しかし昔のままの開発標準書、あるいはプロジェクト管理基準には、そのような機能を使いこ

なす設計技術を開発工程の中に位置づけ、操作性向上を狙うことの明記は見当たらない。ユーザビリティの専門家は、一般にシステム開発技術の標準化には疎く、ユーザビリティと開

発エンジニアリングの間には溝がある。逆に、開発エンジニアはユーザビリティには弱いのが実

態である。したがって、開発工程も最後の総合テストフェーズに入ってから「画面が操作がしにくいため、

データ入力に時間がかかる。画面を修正して欲しい。」などと利用者から画面の修正を要求される

ことになる。 JUAS のソフトウェアメトリックス調査結果によると、年度によって多少異なるものの、設計：

実装：テストの工期比率は、5：7：7 あるいは 3：3：4 であり、テスト工期が一番長い。最後の

工程に入ってから、顧客に画面の使い勝手を指摘され、また後戻りをして画面修正を実施してい

るために、最後のテスト工期が長くなるのである。

図表 3-3-1 規模別フェーズ別工期比


ＰＪ規模（工数）件数設計工期実装工期テスト工期テスト比率

10人月未満 1 2.00 5.00 6.00 46.2%

50人月未満 23 2.48 3.35 3.26 35.9%

100人月未満 7 3.29 5.86 6.00 39.6%

500人月未満 18 4.17 5.00 5.83 38.9%

500人月以上 8 5.25 7.63 6.00 31.8%

記入なし 6 3.00 4.50 2.83 27.4%総計 63 3.44 4.78 4.65 36.1%


275

図表 3-3-2 テスト工期の遅延状況


計画平均実績平均（実績÷計画）平均実績平均÷計画平均10人月未満 4 2.00 1.93 0.85 0.9650人月未満 18 2.58 3.33 1.27 1.29100人月未満 5 6.80 7.40 1.12 1.09500人月未満 13 5.31 5.46 1.00 1.03500人月以上 7 6.00 5.43 0.99 0.90記入なし 2 1.40 2.75 1.94 1.96合計 49 4.13 4.47 1.14 1.08

プロジェクト規模件数テスト工期

スクラッチ（自社製）開発システムにおいてテストフェーズが計画に対する遅延の程度を整理

したのが、上表である。（実績÷計画）は個別のデータ値を層別区分ごとにまず集計し、合計値を割った値である。実績平均÷計画平均で左の表の値そのものを割り算した値である。いずれにしても、開発の最終工程に来て 10%程度の遅延が発生している。この中にはユーザビ

リティの修正も含まれている。では、開発直後のプログラム保守においてユーザビリティの修正負荷はどの程度であろうか。ユーザビリティ変化では、1 年目は 4.8%、2 年目は 7.8%となっており、通常の感覚とは異な

る。おそらく「担当者の要望」にユーザビリティに関する変更が相当に入っていると思われる。

図表 3-3-3 保守作業の発生理由


2005 年カットオーバー


保守理由＿システムバグ 33.0% 36.5% 0.0% 70.0% 22

保守理由＿担当者要望 42.7% 30.0% 10.0% 100.0% 22

保守理由＿制度ルール変化 4.5% 0.0% 0.0% 30.0% 22

保守理由＿業務方法変化 7.3% 0.0% 0.0% 30.0% 22

保守理由＿経営目標変化 3.4% 0.0% 0.0% 30.0% 22

保守理由＿ユーザビリティ変化 4.8% 0.0% 0.0% 30.0% 22

保守理由＿その他 4.3% 0.0% 0.0% 30.0% 22

2004 年以前カットオーバー


保守理由＿システムバグ 15.0% 10.0% 0.0% 64.0% 54

保守理由＿担当者要望 31.9% 30.0% 0.0% 79.0% 54

保守理由＿制度ルール変化 18.6% 10.0% 0.0% 60.0% 54

保守理由＿業務方法変化 16.5% 14.5% 0.0% 60.0% 54

保守理由＿経営目標変化 2.6% 0.0% 0.0% 30.0% 54

保守理由＿ユーザビリティ変化 7.8% 5.0% 0.0% 50.0% 54

保守理由＿その他 7.6% 0.0% 0.0% 60.0% 54

いずれにしても最終テストフェーズに入ってから、ユーザビリティの観点からの修正が発生す

ると、単体テストから再作業をすることになり負荷は大きくなる。


276

「企画段階あるいは基本設計で操作性を確保できる設計を実施し、実装に入ってからの後工程

では操作性などの画面修正は行わない方法はないのか」と JUAS では、3 年前から「ユーザビリ

ティ研究プロジェクト」を設置して研究に取り組んできた。その結果、「ペーパープロトタイプ・アプローチ」と「スクリーンプロトタイプ・アプローチ」

に大きな可能性を発見した。この 2 手法の特徴を整理してみる。

図表 3-3-4 プロトタイプアプローチ

比較項目ペーパープロトタイプ・アプローチスクリーンプロトタイプ・アプローチ

画面設計・鉛筆で手書き

・修正が極めて簡単であるが、シミュレ

ーション完了後、SE やプログラマーに

伝えるために PowerPoint などのツー

ルを活用して画面情報の入力を行う

・PowerPoint または Visio などを使用し

て最初から描く

・若い SE には手書きと比較しての負担

感は低い

シミュレーション方法入力者、コンピュータ役、進行役、観察

記録者が一定の手順で行う

同左

画面の訂正消しゴムと鉛筆で修正

（シミュレーション結果を基にパワーポイ

ントなどで再入力が必要）

PowerPoint などで訂正する

（やや煩雑ではあるが画面訂正の手間

は大きなものではない）

類似画面の制作手書きで書き直すので多少わずらわし

い

コピー機能が使えるので簡単

小規模システムへの

適用

可能（負荷増感はない）同左

大規模システムへの

適用

冗長であり負担感を伴うコピー機能を活用すれば、負担感少なし

将来性 ○

◎若い方向き

最初の画面設計を手書きで行うか、画面設計ツールを活用するかの差でしかない。必要に応じ

て両者を使い分ければよい。「ペーパープロトタイプ・アプローチ」を最初の数画面について試み、入力コンセプトや入力

イメージを固めたあと、「スクリーンプロトタイプ・アプローチ」を活用する、などの使い分けも

ある。いずれにしても、関係者を集めてのシミュレーションを実施する手順は同じである。「後戻りし

ない、させないユーザビリティの求め方」の方法を、従来の方法と比較した表を次に示す。


277

図表 3-3-5 後戻りしないユーザビリティの求め方

フェーズ後戻りが発生する方法後戻りをしない方法

①企画ユーザビリティについては何も規定し

ない

画面の操作性の重要性を確認する

②要件定義ユーザビリティについては何も規定し

ない

画面設計のコンセプトを確定する

③基本設計画面設計は行うが、ユーザビリティテ

ストは実施しない

画面設計結果に基づき、シミュレーシ

ョンを実施し利用者とともに操作性の

妥当性を確認する

④詳細設計利用者の了解がないままに画面詳細

設計を行う

利用者の了解を得た画面を基に詳細

部分の設計を行う

⑤プログラム、

コード化、

ユニットテスト

プログラムのコード化を実施するプログラムのコード化を実施する

⑥結合テストベンダーSE のみで結合テストを実施

する

利用者を含め動く状況、レスポンスタ

イム含めての確認を行う

⑦総合テスト利用者含めてテストを行い、操作性含

めてのユーザビリティへの修正要望が

出される

入力データの相互干渉状況を確認す

る。ユーザビリティの変更は原則とし

て行わない

⑧稼動開始利用開始してからもユーザビリティの

変更が多発する

利用開始してからの変更も限られたも

のになる


278

２．ユーザビリティとシステム開発

（１）ウォーターフォール型とスパイラル型

企業の情報システム開発は、そのほとんどが「ウォーターフォール型」と呼ばれる開発方式を

採用している。つまり、基本計画から始まり、要件定義、外部設計、内部設計、開発、テスト、

リリース、保守／運用と、上流から下流の工程へ滝の流れのごとく、開発工程を進めるという手

法である。前の工程をフィックスさせて初めて次の工程へ進むことができる。長年の経験と実績

に支えられ、また開発工程管理表等のドキュメントもある程度整備されており、情報システム開

発とはそのように進められるべきものだと思い込んでいる SE も少なくない。インターネットの興隆以降、オープンシステムの企業情報システムへの適用が現実となり始め、

ホストコンピュータ時代の開発手法とは異なる方法論が生まれた。つまり、早めに完成系に近い

システムの形まで開発を進め、検証／検討を行い、また要件定義や外部設計を見直し、設計を修

正し、再開発する。これを複数回繰り返し完成とする、スパイラル型開発である。

（２）上流工程はスパイラル型、下流工程はウォーターフォール型

多くの SE が、「ユーザビリティ」を要求されると戸惑うのはなぜか。それは、開発工程のどこ

に「ユーザビリティ」のための工程を入れるべきか、判断に迷うからだ。現在のウォーターフォ

ール型の開発スタイルの中のどこで「ユーザビリティ」の判断をするのか。リリース前にチェッ

クしてもらえばよいのか。その段階で NG が出されてもどうしようもない。 UCD メソッドの前に、ソフトウェア開発に対する基本的な考え方の再構築が必要だ。システム構築の前半－上流工程－と、後半－下流工程－では、全く異なるスキルと方法論が必

要とされる。そもそも、狭義の開発－内部設計／プログラミング－は、ユーザーには無縁の世界

である。ユーザーは、目に見え操作できる画面のみがシステムであると認識している。情報システムも今や一定の成熟を迎え、自動車で言えばエンジンのメンテナンスができること

が運転する条件ではなくなっていることと同様に、目に見え操作できる画面と、その裏のシステ

ムは明確に区別されていると言ってよい。この点をまず、明確に認識すべきである。つまり、イ

ンターフェイスデザインとプログラムデザインは異なり、その設計や開発にも異なる手法が要求

されるということである。インターフェイスデザインは、そのほとんどが「人間系」である。プログラムデザインは、完

全な「システム系」である。前者の設計には、「人間系」が故に試行錯誤が欠かせない。後者の設

計は、ある程度パターン化されており、正しい手順で開発を進めれば、洗練の度合いはともかく

として、（バグ以外は）正しくないシステムは生まれにくい。プロジェクトのゴールを明確にした後、ユーザーの要求要件を引き出し、利用ユーザーのタス

クを明確にし、機能を導出する。そしてその機能を実現する画面デザインを行う。いわゆる、外

部設計までに相当するこの局面－上流工程－では、プロトタイピングの手法を用いて、繰り返し

の検証と修正が有効である。なぜなら、多くのユーザーは「類推」といったことが不得手で、目

に見えない、触れないものを頭の中でシミュレーションすることがほとんどできないからである。「人間系」―上流工程：インターフェイスデザインでは、まさにスパイラル型が適当である。

./keyword.htm#2801


279

こうして得た成果物－「ユーザーインターフェイス仕様書（UI：User Interface、以下「UI 仕様

書」と表記）」－があれば、内部設計以降では、ほとんど人間系が係わる部分はない。緻密なステ

ップ・バイ・ステップの、ウォーターフォール型で開発を進めればよい。つまり、ユーザビリティの高いシステム開発のためには、１）開発工程を大きく 2 つのフェーズ－上流工程：インターフェイスデザインのフェーズと下

流工程：プログラムデザインのフェーズに分けて考えること、２）それぞれには異なる開発型－スパイラル型とウォーターフォール型－が適すること、３）それぞれには要求される文化とスキル－「人間系」と「システム系」－があること、を理解する必要があるということである。

（３）「人間系」の問題解決メソッド：User-Centered Design （UCD）メソッド

そうして、User-Centered Design（UCD）：ユーザー中心設計の手法が登場する。プログラム

デザインではなく、あくまでもインターフェイスデザインを解決する手法である。熟練の SE であっても、過去の経験とスキルをそのままでは適用できない「人間系」のメソッ

ドである。「人間系」という言い方が分かりにくければ、文化系と言い換えてもよい。理科系の世

界で生きてきた SE には、もはや文化系の発想や曖昧性を許容するメンタリティが希薄になって

しまっている。UCD がすんなりなじまない原因の一つでもある。次頁から、「人間系」―上流工程：インターフェイスデザインを革新するための、具体的な UCD

メソッドについて記述する。「ユーザビリティ」とは、単に使いやすい画面や、格好いい画面から生まれるものではない。

そこには、「思いやりのこころ」が必要だと言った人もいる。同感である。だが、ここでは「人間

系」の話とはいえ、ある程度具体的なプロセスの話をする。UCD メソッドを、上流工程の革新

に役立てていただきたい。

./keyword.htm#6201


280

３．User-Centered Design（UCD）メソッドの全体像（１）UCD メソッドとは

この節は、基本的に UCD の一般的なメソッドに従って、その全体像の一部を紹介する形で構

成される。 UCD メソッドとは、システム構築プロジェクトにおいて、ユーザビリティを第一義に捉えた

設計方針である。ユーザーの動向や活動内容をもとに要求分析を行うことで、プログラム設計に

先行して画面やインタラクションのデザインを実施し、プログラムは、そのデザインを実現する

ために設計される。また、画面デザインの完成までの間にユーザビリティ評価を複数回行うのが

特徴である。図表 3-3-6 に示すとおり、UCD のメソッドは主に、「1.企画：現状理解とゴールの設定」「2.設

計：調査分析およびプロトタイプの作成と評価」「3.実装前工程」という流れで構成される。

図表 3-3-6 UCD メソッドと「画面デザインプロセス」


281

（２）「画面デザインプロセス」の位置付け

UCD メソッドの中で、特に画面のデザインに関わりの深い設計工程（「調査分析フェーズ」お

よび「プロトタイピングフェーズ」）に重点をおいて詳しく解説する。画面デザインプロセスは、大きく 9 つの作業ブロックで構成される。本節では、それぞれの作

業について、方法論や中間成果物の例示などを交えて解説する。あらかじめ、各作業の前後関係

や作業の結果として作成される成果物の関連性を理解したうえで、実際の作業にあたることが望

ましい。また、本節では、各作業内容が理解しやすくなるように、汎用性の高い架空のシステムを題材

にして、その画面デザインの手順を追いながら解説する。今回は、営業担当者が利用する Webベースのシステム「誕生日カード自動送信システム」を用いる。なお、UCD メソッドにおいては、本節に示す各作業を全て行うことが理想的であるが、状況

に応じて簡略化して進めることも可能である。ただしその場合も、プロジェクトメンバーが UCDメソッドの全体像や各作業の目的などを理解したうえで検討し、作業を簡略化することによる弊

害を最小限に留めるように配慮すべきである。次の図表 3-3-7 で示す成果物のうち、「クリティカルドキュメント」に位置付けられているもの

は必須であるだけでなく、プロセス全体のクオリティを決定する重要なドキュメントである。


282

図表 3-3-7 「画面デザインプロセス」の流れと成果物の関係


283

４．企画

「企画」の工程では、当該システム開発の前提要件と目的（ビジネスゴール）をプロジェクト

メンバー全員で共有する。ここで議論や分析を行った結果として明らかになったビジネスゴール

は、後に続く「設計」の工程で常に参照され、メンバー全員の基本的な共通理解として利用され

るべきものである。

（１）プロジェクトの発足

プロジェクトの発足とその趣旨を、プロジェクトメンバー全員によって共有する。参加メンバ

ーには、クライアント部門、管理部門、開発部門のメンバー、あるいはユーザビリティ専門家を

はじめとした特定業務に特化された外部のコンサルタントなどが含まれる。一般的にはプロジェ

クトの発足を明示するため、「キックオフミーティング」「プロジェクト設定会議」などが催され、

以下のようなことをメンバー全員で実施することで、以後行われる様々な活動の「スタートライ

ン」を共有することに意義がある。 ① プロジェクト発足時に実施されること a プロジェクトリーダー、および各メンバーの顔合わせ b プロジェクトの組織構造、および組織構造に基づく指示系統と各メンバーの責任範囲の明確

化 c 以後の工程全体、および様々な作業単位の把握

（２）企画内容の共有

企画立案（起案）の内容を、プロジェクトメンバー全員で共有する。起案内容は、当該システ

ム開発の最も基礎的な、初期段階の前提要件である。ここでは、プロジェクトの当初の目的やコ

ンセプトを議論することが重要であり、後に続く現状分析や競合分析の作業、さらにビジネスゴ

ールを設定するための素材となるように、理解を深めておく必要がある。


284

（３）制約条件の共有

システムを開発する際には、必ず何らかの制約条件があると考えてよい。プロジェクトメンバ

ーは、それらの制約条件を理解したうえで、最も優れたシステムを創り上げようとする意識を持

つことが重要である。そのためには、まず、プロジェクト全体を通じて遵守すべき制約要件を明確にしておかなけれ

ばならない。具体的には、以下のような事項について担当者がその根拠を示し、必須事項とそう

でない事項の優先度付けを行う必要がある。さらに以後これらの事項の優先度付けや変更などと

いった「制約条件の見直し」を行うマイルストーンを設定しておくことが望ましい。 ① システム開発時に発生する制約条件の例 a スケジュール面 b リソースおよびコスト面（人員、設備、資材、物品など） c 技術面 d システムのコンセプト面

（４）現状分析

開発するシステムが、既存の特定システムに置き換えられる場合や複数のシステムの統合が目

的である場合、あるいは、特定のシステムをベースに新たな用途を加えることを想定している場

合は、ここで既存のシステムの現状課題を分析し、新しいプロジェクトの中で改善すべき点を明

確にしておく必要がある。ここでは、プロジェクトメンバー（クライアント部門、管理部門、開発部門など）の観点から、

すでに把握されている課題などを挙げて認識を共有しておく。方法としては、各部門において入

手可能なデータやそのデータに基づく見解に関して分析することが中心になる。また、この時点

で既存システムのユーザー層を把握しておくことで、「設計」の工程で実施されるユーザーの要求

分析を行う際に参考になる。


285

（５）競合分析

開発するシステムと同等のシステムが、他の開発者（他社、他部門など）によってすでに存在

している場合、既存システムを「競合システム」と位置付け、その課題や優位性などを分析する

ことが役に立つ。特に、特定の競合システムよりも優れたシステムを開発することが起案内容と

して含まれる場合は、この競合分析の作業を欠かすことはできない。方法としては、各部門において入手可能なデータやメンバー自身の見解などに基づいて分析す

るほか、該当する市場データを含む報告書を入手して傾向を把握したり、マーケティングリサー

チの専門家にアウトソースしたり、該当するテーマを持つイベントなどに参加することも効果が

ある。また、この時点で競合システムのユーザー層を把握しておくことで、「設計」の工程で実施され

るユーザーの要求分析を行う際に参考になる。

（６）ゴール分析：〈クリティカル〉

企画立案の内容、制約要件の検討、現状分析や競合分析などの結果を踏まえ、当該システム開

発の基礎前提となるビジネスゴールを具体的に定義する。ここで作成されるビジネスゴールは、主に経営サイド（ガバナンス、あるいはリスクマネジメ

ント）の視点から定義されるもの、もしくは開発者サイドのミッションを反映して定義されるも

のが多い。つまり、「企画」の工程では当該システムをトップダウンのアプローチを用いて定義することに

なり、後に続く「設計」の工程ではユーザーの視点からユーザー側のゴールをボトムアップのア

プローチで定義していくことになる。双方のゴールは随時相互参照され、最終的な「デザイン上

のゴール（最も良い画面デザイン）」を明らかにする根拠となる。


286

図表 3-3-8 ゴール定義書


287

５．設計：調査分析フェーズ

ユーザーにとって使い勝手の良いシステムを構築するには「そのシステムを使うユーザーが、

より良い仕事を間違いなく、早く済ませることを支援するために、技術的に解決すべきこと」を

明確にする必要がある。そのために、UCD メソッドの「設計」工程の前半では、システムを利用するユーザーの活動

を段階的に調査分析し、その結果から、画面デザインを行う際に必要となる判断材料を論理的に

取りまとめる。なお、当該システムのユーザーとなる人々の「活動内容」を広く示す言葉として、本節では「タ

スク」という用語を用いる。タスクとは「特定の目的を達成するために、ユーザーが行う仕事全

体、およびその仕事を達成させるためのさまざまな行為」である。一方、そのタスクを実現する

ためにシステムが提供する手段は「機能」という言葉で示される。「ユーザーのタスクを分析し、

必要な機能を抽出すること」が、UCD メソッドの基本的な作業であり、このフェーズの最終的

な目的である。また、各作業の解説は、概要に始まり、「作業目的」「作業内容」「作業のポイント」から構成さ

れる。作業の概要および目的を理解したうえで「作業内容」に書かれた手順に沿って作業を進め

る必要がある。その際「作業のポイント」をチェック項目として利用することができる。


288

（１）ユーザー観察

「ユーザー観察」の作業では、開発プロジェクトのメンバーが、当該システムが介在すること

になる場面に出向いて、実際にシステムのユーザーとなる人々の活動そのものを直接観察する。ここで得られた観察の結果は、分析を加えたうえで後に続く「ユーザーインタビュー」の作業

で検証され、「ペルソナ」や「シナリオ」として具体的なユーザー像およびシステムの利用場面を

描くための素材となる。

［作業目的］営業職や管理職など、すでに認識されている「ユーザーの役割」に捕われずに、人々の活動範

囲やその内容を分析し、ユーザーが現状直面している問題を客観的に把握する。

［作業内容］以下の手順で観察計画を立て、観察を実施、分析する。 ① まず以下のような項目について検討し、「観察の計画」をまとめる。

a. 観察の目的と理由 b. 観察対象とするユーザーの属性（タスクを分析するためには、「性別」「年齢」などといった

人口統計的な属性ではなく、ユーザーのスキルレベルや活動の場に着目し、セグメント化す

るほうが有効である。 c. 観察に際しての留意点／取り決め d. 観察する場所と実施日時 e. 観察チームの体制と役割分担 f. ユーザーに対する趣旨説明の内容

② 次に、実際のユーザーが存在する場面に出向いて観察を行う。必要に応じて、ユーザー観察

の「予行練習」を実施すると良い ③ 観察の内容を記録する。その際、出来事のすべてを正確に記録するのではなく、以下のよう

な点を把握できるようにする。また、観察時に気づいた点やユーザーに尋ねた内容とその回

答などについても忘れずにメモしておく a. ユーザーの役割 b. タスクの前提となるユーザーの目的（ユーザは何のためにその行為を行うのか） c. 目的を達成するためのタスク d. タスク達成の方法と手段（当該システムがない現状での、ユーザーのタスクに対する取り組

みかた） e. タスク達成を阻害する要因（問題を引き起こす「ボトルネック」となっていることは何か。

他のユーザーや環境などによる影響も含む）


289

f. 問題の解決方法（トラブルが発生した際、ユーザーはどのように解決しているか） g. ユーザーの習慣となっている行為や言葉（ユーザーが慣れ親しんでいる様々な習慣は、ユー

ザー自身が試行錯誤し、さらに効率性を重視した結果として淘汰されたものであることが多

い）以上の観察結果を、「ユーザーの役割」と「タスク」の関係、タスクの流れ（タスクフロー）や

問題点を中心に整理／分析する。

（２）ユーザーインタビュー

「ユーザーインタビュー」の作業では、「ユーザー観察」に引き続き、システムを実際に利用す

るユーザーに対して直接インタビューを行う。ここで得られたインタビューの結果は、ユーザー観察の分析結果を改訂する形でまとめられ、

後に続く「ペルソナ作成」や「シナリオ作成」の作業において具体的なユーザー像およびシステ

ムの利用場面を描き出すための素材となる。

［作業目的］「ユーザー観察」の結果を検証すると共に、観察では得ることができなかった、ユーザーの主

観的な見解や問題点を把握する。また、プロジェクトメンバーによってあらかじめ定義された「ビ

ジネスゴール」との整合性を確認することも重要である。それらの内容を確認したうえで、さら

に有用な付加情報を得ることが望ましい。

［作業内容］以下の手順でインタビューの計画をまとめ、インタビューを実施、分析する。 a. 観察対象となったユーザーのうち、重要な役割を担っていると考えることができるユーザー

セグメントから 2～3 名を抽出する b. 観察の中で得た「ユーザーの役割」について、ユーザー自身に妥当性を確認する c. 観察の中で得た「タスク」の内容をより詳しく確認する（たとえば、それらのタスクが発生

する時期、きっかけ、頻度など） d. 観察の中で得た「タスク達成を阻害する要因」について、その根拠と回避策を再確認する e. 観察では得ることができなかった、個人の背景、知識、態度、見解、などをヒアリングする f. 観察結果とインタビュー結果をもとに、再度「ユーザーの役割」と「タスク」の関連付けを

分析する


290

（３）ペルソナ作成：〈クリティカル〉

「ペルソナ作成」の作業では、ユーザー観察やインタビューから得た当該システムの典型的な

ユーザー像を架空の人物（ペルソナ）として設定し、各人物の詳細な属性やシステム利用の背景

などを明確にする。ここで設定されたペルソナは、後に続く「シナリオ作成」や「タスク分析」の作業、および「プ

ロトタイプの評価」作業において活用される。

［作業目的］「ユーザー」というあいまいな人物像を、現実のユーザーに対する観察やインタビューの結果

に基付き、特定の人物として具体化する。それによってプロジェクトメンバー全員が、その人物

を代表的なユーザーとして常に念頭に置いた開発に取り組めるようにする。また、ペルソナの存在により、プロジェクトメンバー間で、「（ペルソナである）○○さんなら

どうするか」といった、具体的かつ建設的な議論が可能となるため、それをもとに当該システム

のユーザビリティ向上の活動を活性化することも重要である。つまり、「管理部門スタッフ」や「開

発部門スタッフ」など、既存の枠組みの中では気づかなかったユーザーにとっての利便性や使い

勝手を、ペルソナおよびその後作成されるシナリオを「共通言語」に、「プロトタイプの評価」な

どを通して検証していく。

［作業内容］以下の手順で、「ユーザー観察＆インタビュー分析結果」をもとにペルソナを作成する。 a. ユーザー観察およびインタビューの結果として明らかになった「ユーザーの役割」ごとに、

ペルソナを 1 名ずつ設定する b. 各ペルソナについて、その人物の属性やシステムを利用する動機につながる背景などをまと

める c. 当該システムのユーザーとして、複数のペルソナが存在する場合は、最も典型的なユーザに

該当する 1 名を「主要ペルソナ」とする。「主要ペルソナ」は、当該システムを最も頻繁に

利用する人物であり、それ以外のペルソナは、利用場面や頻度などの面で、主要ペルソナと

違う経験を持つことになる d. ペルソナの数は、合計で 1～5 名程度にする（あらかじめ、ユーザーの役割が論理的に整理

されていないと、不要なペルソナが設定されがちである）


291

図表 3-3-9 ペルソナ記述シート


292

（４）シナリオ作成：〈クリティカル〉

「シナリオ作成」の作業では、直前に設定したペルソナそれぞれについて、今後当該システム

が介在することになる日常場面での行動や思考を、物語風の文章（シナリオ）として記述する。ここで作成されたシナリオは、後に続く「タスク分析」の作業において、タスクを抽出するた

めに利用される。

［作業目的］先んじて実施したユーザー観察やユーザーインタビューなどを通じて分析した「ユーザーの役

割」「ユーザーの目的」「目的を達成するためのタスク」を再度検証し、現実に即した形でシステ

ムの利用場面内に置き換えることで、実際に画面デザインを行う際に根拠となる「タスク」およ

び、そこから導かれる「機能」を得るための素材とする。また、先にも述べたとおり、この作業の成果であるシナリオは、プロジェクトメンバー全員の

「共通言語」として機能するという意義がある。各シナリオを、開発者やデザイナー自身が様々

な角度から捉え直すことで、システムの存在意義や解決すべき課題をユーザーの視点から発見す

ることができる。

［作業内容］以下の手順で、「ペルソナ」をもとに「ユーザー観察＆インタビュー分析結果」を参照しながら

シナリオを作成する。

a. 各ペルソナが持つ動機や背景から、今後システムが介在することになる日常場面を想定し、

そこでの特定の目的を描いていく b. 設定した目的を達成するためのタスクの実行過程を、「基本シナリオ」1 種類と、「応用シナ

リオ」1～2 種類に記述する c. 「基本シナリオ」では、タスクを問題なく達成した様子を記述する d. 「応用シナリオ」では、ペルソナが特定のタスクを行う途中で何らかのトラブルが発生し、

作業を中断せざるを得なくなった様子や、何らかの理由により通常とは違う方法でタスクを

達成する様子などを記述する


293

図表 3-3-10 シナリオ記述シート


294

（５）タスク分析：〈クリティカル〉

「タスク分析」の作業では、ユーザーの代表者であるペルソナが持つシナリオを、ユーザーの

目的達成に必要な「タスク」という最小単位で整理した「基本タスクリスト」を作成する。ここで得られた個々のタスクは、後に続く「機能分析」の作業において、システムの機能を抽

出するための基礎データとなる。

［作業目的］「タスク分析」以降の作業では、いよいよ、当該システムで実際に採用される画面デザイン（画

面遷移や UI 仕様など）を徐々に明らかにしていく。そのためには、システムのあるべき姿を「ユ

ーザーのタスク」と「そのタスクを実現するための機能」という 2 つの側面から検討し、それぞ

れについて優先度付けを進めていく必要がある。まず、それらの起点となる「タスク」を、シナ

リオとして描かれたユーザーの日常場面から抽出し、ユーザーニーズを機能として満たすための

下地および判断基準とする。

［作業内容］以下の手順で、「シナリオ」をもとに、適宜「ユーザー観察＆インタビュー分析結果」や「ペル

ソナ」を参照しつつ、タスクを洗い出す。

a. シナリオから、「～する」「○○を～する」といった、動詞と名詞（主に目的語）を含む箇所

を抽出する b. それらがユーザーの目的を達成するために、当該システムを用いて実行されるタスクとして

有効かどうかを検証しながら、リストにまとめ直す c. これらの作業を、すべてのペルソナが持つすべてのシナリオについて実施する d. 複数のシナリオ内に同じタスクが発生している場合は、重複を取り除く。ただし、その発生

頻度を後から確認できるようにしておく e. 特定のシナリオに記述されている以外にも、ユーザーの目的達成に必要なタスクがないかを

検証し、リストに追加する f. リストアップしたタスクを、主に名詞（目的語）を基準に関連の深い活動ごとにグルーピン

グしたうえで、その分類に名称を付け、「基本タスクリスト」とする


295

図表 3-3-11 基本タスクリスト


296

（６）機能分析：〈クリティカル〉

「機能分析」の作業では、これまでの調査／分析を通して得られたタスクをもとに、当該シス

テムが提供する必要のある機能を洗い出していく。タスクから機能を導き、それぞれに優先度付

けを行い、視点を変えながら、「タスクと機能の対応」を繰り返し分析することは、ユーザーの要

求と画面デザインを結び付けるための基礎を築く重要な作業である。

① 機能の抽出「機能の抽出」の作業では、すでに整理された「基本タスクリスト」に基付き、実際にシステ

ムの「機能」として切り分けることができる要素を抽出する。ここで作成された「タスクと機能の対応表」および「基本機能リスト」は、後に続く「機能の

優先度付け」の作業において、システムが優先的に搭載すべき機能の検討に利用される。

［作業目的］あくまでタスクから導き出される機能として、当該システムが技術的に提供すべきことを明ら

かにする。

［作業内容］以下の手順で、「基本タスクリスト」をもとに、「タスクと機能の対応表」を作成し、さらにそ

の対応表から「基本機能リスト」を作成する。

a. 「基本タスクリスト」内の個々のタスクについて、そのタスクを達成するために必要なシス

テムの機能をリストアップする b. リストアップした機能を、タスクとの対応付けが明確に分かる形で「タスクと機能の対応表」

としてまとめる c. 再度、「タスクと機能の対応表」から、機能を取り出す d. 違うタスクを支援するために同じ機能が利用されている場合は、重複を取り除いて整理する。

ただし、その発生頻度も分かるようにしておくと良い e. 対応表に含まれる特定のタスクを支援する機能ではなくても、他に必要と思われる機能があ

れば追加する f. 以上に整理した機能を、関連の深い機能ごとにグルーピングし、その分類に名称を付けて「基

本機能リスト」としてまとめる。


297

図表 3-3-12 タスクと機能の対応表


298

② 機能の優先度付け「機能の優先度付け」の作業では、すでに整理された「基本機能リスト」の個々の機能につい

て、「必須機能」「重要な機能」「あると良い機能」の 3 段階で優先度付けを行う。ここで作成された「優先度付き機能リスト」は、後に続く「タスクの優先度付け」の作業にお

いて、再度タスクの観点から当該システムに必要な機能を見直すための土台となる。

［作業目的］一部のユーザーのみが使う機能をシステムに詰め込み過ぎることを避け、多くのユーザーが必

要とする機能を使いやすい形で提供できるようにする。妥当性を持って正しくまとめられた「優先度付き機能リスト」は、最終的にデザイナーや技術

者が UI の具体的な要件をスムーズに決定するための根拠となる。画面デザインプロセスの中で

も、特に重要な作業であると言うことができる。

［作業内容］以下の手順で、「基本機能リスト」をもとに、機能の優先度付けを行ったうえで、再度対応表に

反映させる。 a. 「基本機能リスト」上にリストアップされた機能に対し、以下に示した判断基準を用いて優

先度付けを行う b. 優先度付けした結果を「タスクと機能の対応表」にマークなどを使用して反映する。この段

階で、新たに加えた機能からタスクにも追加が生じた場合は、表に含めておく


299

・優先度 1.「必須機能」「必須機能」とは、それが含まれなければシステムの存在意義を認めることができない、必要

最低限の機能である。・多くのタスクを支援し、さらにビジネスゴールに直結する機能である・ユーザーのニーズに根ざした確かな根拠がある・当該システムを意義あるものとして使用するための中心的な機能である・プロトタイプを作成し、ユーザビリティテストを開始するために最低限必要な機能である

・優先度 2.「重要な機能」「重要な機能」とは、システムをリリースするために最低限必要な機能である。・「重要な機能」は、後に続く作業の過程で繰り返し検討されるため、優先度が変わりやすく、

定義が難しい・「必須機能」の存在を支援するものが「重要な機能」となる場合がある・システムのセットアップや、プライバシー、セキュリティ関連で必要な機能が「重要な機能」

となる場合がある・プロジェクトの規模などに応じて、「重要な機能」の中で優先度をより小分けにし、当該シス

テムに搭載すべき機能を削ぎ落とすための手掛かりとすると良い「重要な機能」に含める機能をなるべく少なく保っておくことで、ユーザーにとって本当に必

要な機能を使いやすい形で提供することに集中できる

・優先度 3.「あると良い機能」「あると良い機能」とは、ユーザーの満足度や使いやすさには貢献するが、さしあたって存在

していなくてもシステムとして成立し得る機能である。

・システムを使いやすくするための様々な機能のアイデア群である・後に続く作業の過程で、一段階優先度の高い「重要な機能」に含めるべき機能であるかどう

かを見極める・本当に必要な機能であることが分かるまでは、「あると良い機能」のままにしておく・「あると良い機能」から最終的に実装されるものは少ないかもしれないが、それで良い。「重

要な機能」を検討するための素材として割り切ることも必要である・機能の優先度付けを行った後に、新たなアイデアが出された場合には、「あると良い機能」に

含めておくことで、アイデアを紛失させずに、本当に実現すべき機能かを検討するための効

果的なバッファとなる


300

③タスクの優先度付け「タスクの優先度付け」の作業では、再度「タスク」という視点に立ち返り、抽出済みの個々

のタスクについて「機能の優先度付け」と同様に、「必須タスク」「重要なタスク」「あると良いタ

スク」の 3 種類に分類する。ここで作成された「優先度付きタスクリスト」は、後に続く「タスクフロー作成」の作業にお

いて、当該システムを構成する各画面に対し、機能を割り振る際の判断材料として活用される。

［作業目的］当該システムを利用するユーザーが優先的に行う必要のあるタスクを検討し、ユーザーにとっ

て最も使いやすい画面設計を行うための根拠を組み立てる。先にも述べたように、画面デザインは「そのシステムを使うユーザーが、より良い仕事（タス

ク）を間違いなく、早く済ませることを支援する」ために決定されるものであり、単に「必須機

能」を強調することが正しいとは限らない。よって、ただ「機能」から「タスク」に見方を変え

るだけでなく、一度「機能」として切り分けて優先度付けした結果をもとに、「タスク」の優先度

付けとして展開しながら十分に検証し、再度「機能」の優先度も確認／修正することに重要な意

義がある。

［作業内容］以下の手順で、「優先度付き機能リスト（対応表に反映したもの）」をもとに、タスクの優先度

付けを行う。また、その結果から機能の優先度を再検討し、対応表全体を再更新する。 a. 対応表上で、各タスクについて、そのタスクを支援する機能の優先度を確認する b. 機能の優先度付けは参考程度に、あくまでもユーザーの目的と、当該システムが介すること

による現状の仕事の改善を念頭にタスクの優先度付けを行い、記入する c. タスクの優先度をもとに、再度機能の優先度を見直し、修正する d. タスク、機能それぞれに優先度を付け、修正した結果を対応表に反映し、「優先度付きタス

クと機能の対応表」として更新する


301

６．設計：プロトタイピングフェーズ

UCD メソッドを用いた開発では、実際にシステムを利用するユーザーのタスクを中心に分析

した結果に基付き、システムの機能を使い勝手の良いUIとして実現していくことが重要である。そのため、「設計」工程の後半では、「調査分析フェーズ」の成果物をもとに各画面の遷移や要

素の見た目を具体的に表現し、プロトタイプとして作成した段階で、使い勝手の評価／改善作業

を実施する。

（１）タスクフロー作成：〈クリティカル〉

「タスクフロー作成」の作業では、「調査分析フェーズ」を通して明らかとなった、ユーザーに

とって優先的なタスクと機能をもとに、タスクのフローという視点から各画面の関係図にまとめ

ていく。この関係図は、プロトタイプの作成にあたって、これまでの成果をすべて反映し、ユーザーの

目的達成を適切に支援する当該システムの、実際の画面遷移を決定するための重要な土台である

と言える。

① タスクケース・マトリックス作成「タスクケース・マトリックス作成」の作業では、優先度付けを行ったタスクを、「利用頻度」

と「利用者割合」という 2 種類の利用ケースで再分類する。ここで作成された「タスクケース・マトリックス」は、当該システムの各画面への機能の割り

振りやその表現を決定するための判断材料として活用される。

［作業目的］タスクの利用状況を考慮に入れることで、より多くのユーザーのタスク達成をできる限りスム

ーズに支援する UI をデザインしていくための根拠とする。なお、この作業の成果は、画面デザイン（画面遷移や UI 要素のデザイン）の決定に直結する

ため、あらかじめ以下のような対応付けが行われることを理解しておく必要がある。


302

・利用状況をもとに画面デザインを決定する際の原則

利用頻度の高いタスクは、少ないクリック数で実行できるようにする利用者割合の多いタスクは、認識しやすいよう表現する

図表 3-3-13 利用状況をもとに画面デザインを決定する際の原則

［作業内容］

以下の手順で、「優先度付きタスクリスト（「優先度付きタスクと機能の対応表」内）をもとに、

タスクを利用頻度と利用者割合に基づいて再分類する。 a. 個々のタスクに対して、それを実行すると考えられるユーザーの属性とその属性を持つ人々

の延べ人数を検討する（利用する延べ人数が多い場合は「利用者割合＝多い」となる） b. 個々のタスクに対して、その利用頻度を検討する（頻繁に発生するタスクであるほど「利用

頻度＝高い」となる） c. それぞれの検討結果をもとに、各タスクを「多数のユーザーにとって頻繁に発生するタスク」

「少数のユーザーにとって頻繁に発生するタスク」「多数のユーザーにとって稀に発生する

タスク」「少数のユーザーにとって稀に発生するタスク」の 4 つのタスクケース別に分類し、

「タスクケース・マトリックス」としてまとめる d. すでに完了している「必須タスク」「重要なタスク」「あると良いタスク」の優先度付けも分

かるようにする


303

図表 3-3-14 タスクケース・マトリクス


304

② 画面別・優先度付き機能リスト作成「画面別・優先度付き機能リスト作成」の作業では、「優先度付きタスクと機能の対応表」にま

とめた当該システムの機能を、実際にどの画面上に実現していくかを明確にする。つまり、この

作業において初めて「画面」という単位や「画面とそこに含まれる機能」というセットが明らか

になる。ここで作成された「画面別・優先度付き機能リスト」は、「タスクフロー・ダイアグラム作成」

時に、各画面に含めるべき機能を再整理しつつ、タスクの流れを画面同士の関係として視覚化す

るために利用される。

［作業目的］当該システムを構成する画面を明らかにし、多くのユーザーにとって優先度の高いタスクを達

成するための機能に対してすぐにアクセスできるよう、それぞれの機能を各画面に適切に配分し、

その遷移を決定するための下地とする。なお、ここでは多数のユーザーが頻繁に行うタスクを中

心に、優先的なタスクをいかに達成するかを機能として画面に割り振ることに重要な意義がある。

そのため、作成するリストはタスクリストではなく、機能リストとなる。

［作業内容］以下の手順で、「優先度付きタスクと機能の対応表」をもとに、「タスクケース・マトリクス」

を参照しながら、それぞれの機能を割り振るための画面を決定する。 a. 「優先度付きタスクと機能の対応表」にリストアップされている機能に着目し、当該システ

ムを構成するために必要となりそうな画面の名称をいくつか書き出す b. 画面名を書き出しながら、その画面に含める機能も合わせて書いていく c. いくつかの画面の存在が明らかになったところで、「タスクケース・マトリクス」をもとに、

多くのユーザーにとってタスク達成の起点となる「主要な画面」を 1～2 画面ほど想定する d. 「利用状況をもとに画面デザインを決定する際の原則」を参考に、「多数のユーザーにとっ

て頻繁に発生するタスク」に対応付けられている機能については、主要な画面に含めること

を前提に、割り振り先の画面を適宜追加しつつ決定する e. 「少数のユーザーにとって頻繁に発生するタスク」に対応付けられている機能については、

主要な画面を煩雑にすることなく明確に提示できそうであればそこに含め、そうでなければ

他の画面への割り振りを検討する f. 「多数のユーザーにとって稀に発生するタスク」に対応付けられている機能については、ま

ず主要な画面に含めることを検討するが、主要な画面からの導線が明確となるのであれば、

他の画面に割り振る g. 「少数のユーザーにとって稀に発生するタスク」に対応付けられている機能については、主

要な画面には含めず、関連タスクを進行させる過程でその存在が見えれば良い h. 以上に行った機能の割り振り作業を、各画面の名称とそれに属する機能を一覧にした「画面

別・優先度付き機能リスト」としてまとめる


305

③タスクフロー・ダイアグラム作成「タスクフロー・ダイアグラム作成」の作業では、各画面に割り振られた機能を利用して、ユ

ーザーがタスク達成にあたって、画面間をどのように移動していくかをダイアグラムとして図示

する。ここで作成された「タスクフロー・ダイアグラム」は、後に続く「プロトタイピング」の作業

において、プロトタイプの画面遷移そのものに反映される。

［作業目的］ユーザーのスムーズな目的達成を支援するために必要な当該システムの画面数、および画面間

の関係、当該システムで用いられる共通メニュー（グローバルナビゲーション）要素などを明ら

かにし、プロジェクトチーム内外において確認／共有する。また、作成されたダイアグラムがシンプルであるほど、ユーザーのタスク達成を効率良く支援

するシステムであると言える。このため、「タスクフロー・ダイアグラム」の作成過程でシステム

の複雑さを描き出し、各画面に対する機能配分を再整理することも重要である。

［作業内容］以下の手順で、「タスクケース・マトリックス」にまとめたタスクや「画面別・優先度付き機能

リスト」をもとに、画面間の関係を視覚化する。 a. 「タスクケース・マトリックス」内の「多数のユーザーにとって頻繁に発生するタスク」を

はじめ、すべてのタスクの流れを追いながら、タスク達成までに必要な画面を「画面別・優

先度付き機能リスト」を用いて、矢印などでその遷移過程を示しつつ書き出す b. 書き出し作業の過程で、タスク達成に必要な画面や、画面間の移動に必要な機能などに追加

が生じた場合は追加／調整する c. 書き出した画面遷移のうち重複する画面を重ねて描き、複数のタスクフローを反映した 1 つ

のダイアグラムとしてまとめる d. 各画面に含まれる機能を再度整理する。画面の割り振り先の妥当性や、機能としての実装可

能性を、「あると良い機能」を中心に再検討しながら削ぎ落とし、修正を重ねる f. 「タスクフロー・ダイアグラム」として、当該システムを構成する各画面とそれに含まれる

機能、および画面間の関係性を理解できるように工夫して描き上げる


306

図表 3-3-15 タスクフロー・ダイアグラム


307

（２）プロトタイピング：〈クリティカル〉

「プロトタイピング」の作業では、優先的なタスクとそのフローをもとに各画面に割り振った

機能および画面遷移について、実際にユーザーや評価者が評価作業を行えるよう、具体的な UI要素を決定しながらプロトタイプとして試作する。初めに白黒のラフスケッチによる「ペーパー

プロトタイプ」、次に当該システムの実装時に近い見た目を持つ「スクリーンプロトタイプ」を作

成し、後に続く「プロトタイプの評価」作業を十分に意義のあるものとして実行できるよう準備

する。なお、ユーザーにとって価値のあるシステムをデザインするためには、ユーザーのタスクを十

分に意識することに加え、それを具体的な UI 要素として実現する際の原則をきちんと理解して

おかなければならない。

①ペーパープロトタイピング「ペーパープロトタイピング」の作業では、「タスクフロー・ダイアグラム」にまとめた画面お

よびそれに付随する機能を、UI としてどのように実現するかを紙とペンによるスケッチに起こす。ここで作成された「ペーパープロトタイプ」は、「プロトタイプの評価」をもとに 1～数回のブ

ラッシュアップを経て、「スクリーンプロトタイプ」を作成するための土台となる。

［作業目的］ UI の具体的な見た目を決定しコーディング作業を開始する前に、ユーザーや評価者から機能面

に関する問題点の指摘を受け、その結果を改善案としてすぐに反映できるよう、構築も修正も容

易な簡易システムを用意する。

［必要な道具］ペーパープロトタイプの作成にあたっては、以下を中心に必要な道具を揃えておく。・画面を描くための同サイズの用紙・筆記用具（ペン）・その他、必要に応じて「貼って剥がせるテープ」など


308

［作業内容］以下の手順で、「タスクフロー・ダイアグラム」をもとに、それぞれの画面を紙に描く。 a. 画面ごとに、メニューやボタン、リンクラベルなど、機能を実現するために最低限必要な

UI の要素（部品）をリストアップする。システム全体に共通の要素があれば、別途まとめて

書き出す b. UI の共通部分を定義／作成する。Web アプリケーションについては、ブラウザの UI およ

び当該システム全体に共通の要素を含む 1 枚のウィンドウを基本とし、紙にペンで描く。そ

の際、特定のブラウザをイメージさせるような見た目を表現せず、「戻る」や「進む」などの

基本機能が分かる程度のスケッチに留める c. 作成した共通部分を、各画面の「共通 UI」としてコピーしておく d. 各画面について、ユーザーはタスクをどのように進行させるか、つまり、ユーザーにとって

どの機能の優先度が高いかを意識しながら、共通 UI 上に要素を配置する e. タスクフローを意識し、画面を遷移したときにもユーザーが次にすべきことが明確となるよ

う、全体的な画面間の関係を見ながら、スケッチを調整する f. 以上に作成したペーパープロトタイプは、画面遷移が分かるよう、「タスクフロー・ダイア

グラム」を参照しつつグルーピングしておく

図表 3-3-16 ペーパープロトタイプの例


309

② スクリーンプロトタイプ「スクリーンプロトタイプ」の作業では、「プロトタイプの評価」による評価作業を終えたペー

パープロトタイプをもとに、より具体的な UI 要素や画面遷移のイメージを掴むことのできるプ

ロトタイプとして、Microsoft PowerPoint や Microsoft Visio などの描画ツールを用いたスライ

ドショーを作成する。ここで作成された「スクリーンプロトタイプ」は、「プロトタイプの評価」による 1～数回のブ

ラッシュアップを経て、後に続く「実装」工程での UI 仕様書作成のための土台となる。

［作業目的］機能の表現、つまり UI 要素の見た目によって引き起こされる問題、およびハイパーリンクを

利用した画面遷移にまつわる問題について、より実装時に近い状態での動作検証を可能とする。ただし、PowerPoint や Visio などの描画ツール自体が持つ制約から、ブラウザの基本機能であ

る「戻る」や「進む」ボタンやスクロールなど、実装時と同等のインタラクションを再現するこ

とは困難である。これを踏まえたうえで、各画面をスクリーンプロトタイプとして作成すること

で、タスクを的確に支援する機能表現ができているかどうかの検証が可能となる。

［作業内容］以下の手順で、「ペーパープロトタイプ」をもとに、画面デザインをスライドショーとして作成

する。 a. 「ユーザビリティテスト」および「ウォークスルー評価」を終え、そこから導き出された改

善策を反映したペーパープロトタイプを用意する b. 各画面の個々の UI 要素について、どのような見た目が適切であるかを、タスクベースで検

討し、決定する。たとえば、「タスクケース・マトリックス」内の「多数のユーザーにとって

頻繁に発生するタスク」に対応付けられた機能は認識しやすい必要があるため、色や大きさ、

余白などを工夫して表現する c. PowerPoint や Visio などの描画ツールを起動し、ブラウザでの当該システムの表示幅、高さ

をスライドに指定する。この範囲が 1 画面の領域であり、ブラウザのウィンドウを含むすべ

ての UI 要素が含まれることとなる d. システム全体に共通の要素があれば、スライドマスタ（共通部品置き場）に配置する e. 共通要素以外の UI 要素については、1 画面をスライドとして作成して配置する f. ハイパーリンクが可能な箇所すべてに、スライド内リンクを設定する（Visio 等では PDF に

書き出してから設定する必要がある場合がある）


310

図表 3-3-17 スクリーンプロトタイプの例


311

（３）プロトタイプの評価：〈クリティカル〉

「プロトタイプの評価」の作業では、「ペーパープロトタイプ」「スクリーンプロトタイプ」そ

れぞれに対する使い勝手の評価を行う。手法としては、想定される利用者層の参加を得て実施す

る「ユーザビリティテスト」、ペルソナを用いた「ウォークスルー評価」を用いる。また、評価の

結果何らかの問題が発見された場合は、それぞれ「プロトタイピング」の作業に戻って再検討を

行う。ここで評価を終えたプロトタイプは、次の「実装」工程における「テンプレートの作成」の作

業に利用される。

① ユーザビリティテスト「ユーザビリティテスト」の作業では、当該システムのユーザーが、プロトタイプを実際に利

用しながらタスクを進行させる様子を、評価者となるプロジェクトメンバーが観察／記録する。ここで得られたテスト結果は分析を行い、UCD メソッドにおける次の段階へ移る前に、評価

対象に改善案として反映される。

［作業目的］ユーザーによる行動を実際に観察しなければ得ることの難しい、プロジェクトメンバーが予想

もしない致命的な欠陥や、タスク達成までの想定外の道筋などを発見し、メンバーや専門家によ

る「ウォークスルー評価」と合わせて、システムのユーザビリティを向上させる。

［作業内容］以下の手順でテストの計画を立て、テストを実施、分析する。

a. テストの目的、会場、テスト環境、ユーザー数、スケジュールなど、テスト計画をまとめる b. 「優先度付きタスクリスト」などをもとに複数のタスクを検討し、テスト中にユーザーに実

行してもらう課題として適切なものをいくつか選定する c. 決定した課題を、テスト実行時にユーザーに提示するための「ユーザビリティテスト用課題

シート」にまとめる d. 課題の優先度、実行順序など詳細を詰め、テスト手順や観察のポイントを観察者が把握しや

すいように「ユーザビリティテスト用進行シート」にまとめながら、テスト方法を検討する e. ユーザーを確保する f. テスト会場および機材を確保する。検討する機材としては、椅子 3 脚（ユーザー、ユーザー

に指示を出す進行役のプロジェクトメンバー用、記録者用）、ビデオ 1 台、ノート PC1 台が

ある g. テスト実施の前日に最終的な準備を終え、できる限り事前に機材の確認などを中心に予行を

行い、発見した不具合に対処しておく h. テストを実施する。テスト実施前にユーザーに対して十分に説明を行い、撮影の許可や、秘

密保持契約（NDA：Non-Disclosure Agreement）への署名／捺印を依頼する。テストの記

録内容はユーザーの求めがあれば、すべてのタスク終了後に開示する


312

i. ペーパープロトタイプに対する評価では、プロジェクトメンバーから「コンピュータ役」を

1 名設定する。コンピュータ役が紙を入れかえることで、ユーザーの行為を継続させる j. 記録を整理しつつ、問題と思われる箇所をまとめる

② ウォークスルー評価「ウォークスルー評価」の作業では、実際のユーザーではなく、評価者となるプロジェクトメ

ンバーが具体的なユーザー像である「ペルソナ」になり代わり、プロトタイプを用いてタスクを

進行させながら、その過程における行動や感想を記録する。ここで得られた評価結果は分析を行い、「実装」の工程へ移る前に、評価対象に改善案として反

映させる。

［作業目的］「ユーザビリティテスト」による評価では、実際にシステムを利用するユーザーから直接問題

点を導き出すことに意義があった。ただし、ユーザーに対してはユーザビリティに関する知識を

期待しにくく、ユーザーの感想や要望がそのままユーザビリティの向上に結び付かないことも考

えられる。このため、「ウォークスルー評価」を用い、プロジェクトメンバーや専門家があくまで

「ペルソナ」というユーザーの視点で評価を行い、問題点抽出に加えることが重要である。

［作業内容］以下の手順で、「ペルソナ」を用いた評価作業を行い、結果を分析する。 a. 評価の目的を意識しながら、シナリオやタスクリストから複数のタスクを検討し、課題を設

定する b. 課題を実行する際に用いるペルソナを選定する。通常、「ペルソナ作成」の作業において作

成済みの「主要ペルソナ」を用いるが、ユーザーの役割やタスクとの関係を考えながら適切

なものを選択する c. 評価者がペルソナになり切り、行動、および「今考えていること、感じていること」といっ

た思考過程を記録していく d. 行動と思考過程の記録をもとに、タスク達成に至るまでに「何を見、何を考え、どう行動し、

次の行動のためにどのような判断を下したか」という視点でタスクフローを整理する e. 以上から浮かび上がった問題点や、「タスクフロー・ダイアグラム」に示されたタスク達成

までの想定フローとの比較結果から見える問題点などをまとめる


313

７．実装前工程

「実装」の工程では、「企画」「設計」の工程を経て導出された画面デザイン要件を、実際に動

作するシステムとして実現、最終的に本稼働に至ることになる。本書では、画面デザイン要件を、

「UI 仕様書」や HTML テンプレートとして表現し、その後継続するコーディング作業の基礎を

作成するまでについて解説する。

（１）実装の準備：〈クリティカル〉

「画面デザインプロセス」を通してユーザーニーズを反映させたプロトタイプを実装すべく、

UI の詳細な部品や振る舞いを仕様書に規定する。できれば、それをもとに実際のシステムとして

使用するためのベースとなる HTML のテンプレートを作成することが望ましい。ここで当該システムの実体を明らかにし、その後の作業へスムーズな受け渡しができるよう、

プロジェクトメンバー間での意思疎通を再度図っておくことも重要である。

① 「UI 仕様書」作成評価を終えた「スクリーンプロトタイプ」およびその結果を反映した「タスクフロー・ダイア

グラム」に基付き、当該システムで用いられる様々な UI デザインの詳細を「UI 仕様書」として

文書化する。この仕様書は、「HTML テンプレート作成」作業やその評価の結果を踏まえて最終

的に決定されるが、その後も様々なコーディング作業のほか、システム稼動後の改善や見直しな

ど、当該システムのライフサイクルのあらゆる局面において参照されることになる。この作業は、これまで行ってきた「タスク分析」「機能分析」などの成果を、「ひとまとまりの

仕様書」として記述するものであるが、そこではユーザーと UI の関係性を表現する必要がある。

前提として、この点を忘れてはいけない。

・「UI 仕様書」で表現されるべき「ユーザーと UI の関係性」ユーザーにとっての見え方ユーザーとのインタラクションユーザーに対する効果具体的には、「UI 仕様書」には以下のような項目を含める。基本的に各画面別に記述し、その中で、各 UI の図版と共に、説明文を付与する。


314

・「UI 仕様書」に含めること・レイアウト（ベースウィンドウ：一覧リスト閲覧画面・編集画面など）・コントロール（各種コントロールの表現と、選択肢が用意される場合はその内容など）・ラベルとテキスト（メニュー項目やその他のラベル／各種メッセージなど）・その他（プロセスやステータス表示が用意される場合はその表現方法など）

図表 3-3-18 UI 仕様書の例


315

② HTML テンプレート作成 UI 仕様書に基づいた HTML および CSS のテンプレートが作成され、その後のコーディング

作業で用いられることになる。また、テンプレート化を行う作業は、仕様としてまとめられた画面デザインを、以下の視点よ

り再度検証する作業とも言える。作業の途中で UI 仕様上の矛盾が明らかとなったり、不足点が

発見される場合がある。その際には、再調整後、UI 仕様書を改訂する。

・UI 仕様を再検証するポイント・画面上の「共通要素」と「非共通要素」の切り分け・画面上の「見た目の表現」と「文書の論理構造の表現」の切り分けまた、各種テンプレートをあらかじめ作成しておくことのメリットは以下のとおりである。

・テンプレートを作成するメリット・当該システム内で、UI 仕様を遵守した画面デザインを一貫して提供できる・その後のコーディング作業が効率化される・これまで発見できていない、技術的に実装不可能な制約を検証できる・テンプレートを対象に、再度「ユーザビリティテスト」「ウォークスルー評価」を行うことで、

本番環境への実装前にその使い勝手を検証できる。それにより、詳細コーディング後の手戻

りを回避できる

（２）実装

完成した「UI 仕様書」に基付き、コーディングが開始される。実際には、「UI 仕様書」は外部

設計書を構成する重要なパーツとして位置付けられる。この後、内部設計局面に入るが、場合に

よっては内部設計の一部分は、「UI 仕様書」の作成と同時進行されるかもしれない。なお、この後の各作業においても、必要に応じて「UI 仕様書」が参照されることになる。また、

システム公開の前後にも、ユーザビリティテストやウォークスルー評価を実施することで、ユー

ザーにとっての利用価値を向上させることができる。


316

317

第３章開発保守技術第４節システム再構築の課題と対策

80 年代後半に導入したレガシーシステムの再構築や Y2K 対応のため 2000 年頃に導入したパッ

ケージソフトウェアの更改時期にあたり、多くの企業においてシステム再構築が課題となってい

る。ここでは、これまでのシステム再構築について調査することで、今後の再構築を実施する企

業に役立つ情報を整理したい。

過去の情報資産の中に蓄えられたシステム仕様をどのように継承すればよいのか。あるいは、

継承を行わず新ビジネスモデルを構築する方法はないのか。様々な角度からシステムの再構築を

考える。

１．基幹システム再構築の状況

２．再構築の主な理由

３．再構築プロジェクトの投資規模

４．再構築の対象業務

５．再構築を推進する部門・体制

３－４システム再構築の課題と対策

318

１．基幹システム再構築の状況

（１）84％の企業が基幹システムの再構築に直面

既に基幹システムの再構築を実施している企業が54％、再構築を検討中の企業が31％に上り、

「再構築」がユーザー企業共通の課題であることが改めて明らかになった（図表 3-4-1）。

（２）企業規模が大きいほど再構築が進む

企業規模に比例して、規模の大きい企業ほどシステム再構築が進んでおり、従業員 5000 人以

上の大企業では 7 割超が再構築経験済みまたは実施中と高い比率を示している。これは大企業ほど、投資余力があり市場変化に対応する課題に取り組んでいること、社歴が長

く既存システムの利用期間が長いこと等から、更新が進んでいると考えられる。歴史の浅い企業でシステム再構築と無縁な企業以外は、競合に遅れをとらないため、自社のビ

ジネス展開に不可欠な基幹システムの更新を怠らないよう注意を払う必要があるといえる。

43%

25%

39%

45%

48%

59%

73%

11%

7%

9%

9%

13%

17%

10%

31%

36%

32%

33%

29%

17%

13%

16%

31%

19%

13%

10%

7%

3%

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

全体(n=912)

100人未満(n=912)

100～499人(n=912)

500～999人未満(n=912)

1000～4999人(n=912)

5000～9999人(n=912)

10000人以上(n=912)

1．既に基幹システム再構築を経験している2．現在初めて基幹システム再構築を実施している3．基幹システム再構築を検討している4．基幹システム再構築の予定はない


図表 3-4-1 企業規模別基幹システムの再構築の状況


319

（３）再構築が盛んな業種

業種別に再構築の状況を見ると、図表 3-4-2 のとおりである。今後、「再構築を検討している」

とする企業も、業種を問わず数多く存在する。

51%

59%

52%

67%

44%

31%

28%

30%

41%

45%

43%

42%

34%

42%

75%

33%

58%

39%

25%

14%

11%

12%

17%

7%

17%

12%

14%

12%

10%

5%

7%

11%

25%

8%

9%

8%

27%

22%

25%

19%

38%

52%

48%

31%

29%

31%

32%

41%

39%

67%

25%

28%

17%

8%

8%

12%

17%

30%

15%

17%

10%

13%

14%

16%

22%

17%

8%

8%

23%

50%

3%

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



化学・薬品(n=60)

石油・石炭・ゴム(n=6)










運輸(n=36)

通信・通信サービス(n=4)

電気・ガス・水道(n=6)

放送・新聞・出版・印刷・映画(n=12)


情報処理業(n=24)

1．既に基幹システム再構築を経験している

2．現在初めて基幹システム再構築を実施している

3．基幹システム再構築を検討している

4．基幹システム再構築の予定はない


図表 3-4-2 業種別基幹システム再構築の実施状況


320

２．再構築の主な理由

（１）再構築は業務改革のために

システムを再構築した主な理由を、選択肢より上位 2 つ回答してもらったところ、1 位、2 位

共に「業務の効率化、業務改革のため」が断然多かった（図表 3-4-3）。1 位に挙げられた理由で

次ぐのは「業務がシステムに合わなくなった」「サポート切れ」「システムの整備・統合」である。「業務の効率化、業務改革のため」「業務がシステムに合わなくなった」「新事業への対応」の

3 つは、市場や事業環境の変化へ対応するための投資と言える。こうした競争力強化の目的で再

構築が進める企業が 6 割を占める。一方、「ハードウェアのサポート切れ」「ソフトウェアのサポート切れ、アップグレード」は利

用を継続するために再構築が必要となるもので、企業にとって積極的な意義は低い。「ハードウェ

ア・ソフトウェアのサポート切れ」が再構築理由として 2 割を占めることは、企業が望むシステ

ム利用期間のニーズに、システムベンダーが応えられていない結果と言えよう。また、「保守、運用コストの低減」「セキュリティ対策」「システムの整備・統合」は 2 位の理

由として挙げる企業が多い。第一義的な目的ではなく、「業務改革」や「サポート切れ」に合わせ

て実施されるケースが多いことを物語っている。次のビジネスに合わせて基幹システムを再構築する時期が到来しており、投資が必要となって

いる。また、ハードウェアやソフトウェアのサポート切れにより、再構築しなければならない事

態も多く発生している。ダウンサイジングで基幹システムを UNIX サーバや PC サーバ上に構築

する傾向が顕著になっているが、採用する機器のライフサイクルにも考慮が必要である。

(n=480)

41%

20%

17%

6%

5%

5%

4%

27%

12%

11%

18%

17%

8%

3%

0.4%

1%

2%

2%

0% 10% 20% 30% 40% 50% 60% 70%

業務の効率化、業務改革のため

業務にシステムが合わなくなってきたため

ハードウェアのサポート切れのため

システムの整備・統合のため

保守、運用コストの低減のため

ソフトウェアのサポート切れ、アップグレードのため

新規事業へ対応するため　　

セキュリティ対策　　

その他1位 2位


図表 3-4-3 再構築を実施した主な理由


321

３．再構築プロジェクトの投資規模

（１）再構築に投じるコストは平均 14 億円

今回のアンケートでは、システム再構築に投じた（投じる）コストの実額を調査している。1社あたりの平均額は 14 億円であるが、企業規模別に見ると、売上高 100 億円未満の企業で平均

37 百万円、100 億～1000 億円未満の企業で平均 105 百万、1000 億～1 兆円未満の企業で 1,104百万、1 兆円以上の企業で 14,507 百万となった。

企業規模が大きいほど投資額が多いのは当然であるが、売上高に対する再構築費用の比率を見

ると、企業規模が大きいほど投資額の割合が低い事が分かる。システム構築は企業規模が大きい

ほど、有利であることが現れている例である。

37 105

1104

14507

1 .1%

1 .9%

4 .4%

0 .5%

0

2000

4000

6000

8000

10000

12000

14000

16000

100億円未満 100～1000億 1000億～1兆 1兆円以上

再構築費用（百万）

0%

1%

2%

3%

4%

5%

再構築費用

再構築費用/年間売上高


図表 3-4-4 再構築プロジェクトの投資規模


322

４．再構築の対象業務

（１）再構築の対象

対象業務は、「受発注」「仕入・在庫管理」「生産・商品」といった、営業に直結した業務が中心

となっている。また、「財務会計」を対象としている企業も多い（図表 3-4-5）。システム再構築が業務改革を目的としている例が多いことと考え合わせると、前者は市場や販

売チャネルの変化に対応した販売体制を構築する取り組みと考えられ、後者はコスト管理の高度

化や会計基準の変更に対応するためのものと考えられる。

(n=473)

59%

44%

35%

26%

11%

20%

46%

22%

6%

0% 10% 20% 30% 40% 50% 60%

1.受発注

2.仕入・在庫管理

3.生産・商品

4.物流

6.経営企画

5.顧客管理

7.財務会計

8.人事・総務

9.その他


図表 3-4-5 再構築の対象業務

（２）再構築により業務変革を伴うケースが 8 割

再構築により、大きな業務変革を伴うとする企業が 35％、小規模だが業務変革を伴うとした企

業が 46％となり、合わせて 8 割を占めている（図表 3-4-6）。

(n=486)

3.業務は変えていない

19%

2.業務変革を伴うが小規模

46%

1.大きな業務変革を伴う

35%


図表 3-4-6 適用業務の状況


323

５．再構築を推進する部門・体制

（１）大企業では経営トップと利用部門が再構築をリード

再構築を企画・推進した部門は、全体のでは IT 部門が 75％、経営トップと利用部門が共に 11％となった（図表 3-4-7）。システムの担当部署が再構築をリードするケースが多いことは当然の結果とも言えるが、これ

を企業規模別に見ると、企業規模が大きいほど経営トップや利用部門が企画・推進を担う事例が

増える。10000 人以上の大企業では、経営トップと利用部門が共に 3 割を占め、IT 部門が 4 割に

とどまる。経営トップや利用部門がシステム再構築に積極的に参画している企業は、ビジネスにおけるシ

ステムの重要性が経営層や利用部門に理解されており、関心も高いため、業務革新を成功させる

可能性が高いと考えられる。この点について次項以降で検証を深めて行きたい。

11%

18%

8%

12%

8%

18%

29%

11%

14%

11%

9%

11%

14%

29%

75%

68%

78%

76%

80%

64%

42%

5%

2%

3%

3%

2%

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

全体(n=483)

100人未満(n=22)

100～499人(n=177)

500～999人(n=105)

1000～4999人(n=132)

5000～9999人(n=22)

10000人以上(n=24)

経営トップ利用部門 IT部門その他


図表 3-4-7 企業規模別再構築を企画推進した部門


324

（２）経営トップや利用部門の関心度は参画度に比例

システム再構築を成功させるためには、経営トップや利用部門の理解がも重要なファクター

となる（この節の第 8 項「再構築プロジェクトの課題」参照）。経営層や利用部門は、どのよ

うな推進体制をとると関心が高くなるのであろうか。経営トップの関心が高くなるのは、経営トップが再構築を企画推進したケースで、「積極的」な

関心を持つ割合が 8 割に達する。他部門が企画推進した場合にトップの関心度は下がり、5 割前

後となっている（図表 3-4-8）。利用部門の関心が高くなるのは、利用部門が企画推進したケースで、利用部門が「積極的」な

関心を持つ割合が 7 割を超える。他の部門が企画推進した場合の利用部門の関心は相対的に低く、

「消極的」の割合が 15％弱ある。

28%

18%

13%

9%

24%

4%

51%

38%

38%

32%

47%

41%

21%

38%

40%

43%

22%

41%

0%

4%

6%

9%

7%

12%

6%

2%

3%

2%

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

経営トップが推進(n=53)

利用部門が推進(n=55)

IT部門が推進(n=363)

経営トップが推進(n=53)

利用部門が推進(n=55)

IT部門が推進(n=363)

経営

トッ

プの

関心

利用

部門

の関

心

非常に積極的積極的どちらともいえない消極的非常に消極的


図表 3-4-8 企画推進した部門による経営トップの関心度の違い


325

（３）IT 部門だけでは業務変革はできない

システム再構築が業務変革を伴う場合には、経営トップまたは関係部門を巻き込んだプロジェ

クト推進体制で取り組む企業が圧倒的である。IT 部門だけで実施する業務は、業務に変更を生じ

ない「サポート切れ」対応等のプロジェクトが中心となる。

36%

56%

27%

22%

54%

39%

67%

49%

10%

5%

7%

29%

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

全体(n=484)

大きな業務変革を伴う(n=168）

業務変革を伴うが小規模(n=225)

業務は変えていない(n=91）

経営トップ、関係部門の担当者を含む全社プロジェクトチームを編成

IT部門と関係部門で実施

IT部門だけで実施


図表 3-4-9 業務変革の有無とシステム再構築の実施体制


326

（４）関係部門とプロジェクト体制をとる場合は予算に注意

経営トップや利用部門とプロジェクト推進体制をとった場合、IT 部門だけで実施した場合に比

べて、予算が超過する割合が、2 倍程度に増えている（図表 3-4-10）。これは、経営トップや利用部門が推進するプロジェクトが、業務変革を伴う、投資規模の大き

い大規模プロジェクトであることが大の理由であろう（図表 3-4-11）。一方で IT 部門の担当者に比べて、利用部門の担当者は各要件がコストに与えるインパクトを

熟知していないため、過大なシステム要件となってしまう要素も大きいのではないだろうか。利

用部門や経営トップが主体的に参画する体制をとる場合には、この点を抑制することを意識する

必要がある。

20%

22%

39%

34%

43%

41%

46%

36%

20%

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

経営トップ、関係部門の担当者を含む全社プロジェクトチームを編成(n=169)

IT部門と関係部門で実施(n=256)

IT部門だけで実施(n=49)

予定通り完了ある程度は予定通り完了予定より遅延


図表 3-4-10 実施体制によるプロジェクト予算の超過状況

9%

24%

23%

6%

12%

23%

34%

37%

42%

13%

8%

12%

26%

14%

0%

4% 8%

1%

3%

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




5000万未満 5000～1億未満 1～5億未満 5～10億未満 10～50億未満 50～100億未満 100億以上


図表 3-4-11 実施体制とプロジェクト予算規模の関係


327

６．再構築後の構想

（１）再構築後のシステムのライフ

───ユーザーが望むシステムライフサイクルは 10 年再構築後のシステムのライフを何年と見るかについて聞いた結果が、図表 3-4-12 である。6～

10 年とする企業が 6 割を占め、次いで 1～5 年とする企業が 3 割であった。以前の調査よりサイクルが短くなっているが、これはユーザー企業が採用するハードウェアが、

ホストからサイクルの短い Windows や UNIX マシンにシフトした要因が挙げられる。一方で、

Windows でメインロジックを稼動させるとしながらも、6 年を超えるライフサイクルを望む企業

もある。

30%

23%

23%

32%

38%

19%

63%

63%

70%

63%

57%

74%

7%

13%

7%

5%

5%

6%

1%

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

全体(n=481)

ホスト系(n=91)

UNIX系(n=118)

Linux系(n=19)

Windows系(n=219)

オフコン(n=31)

1～5年 6～10年 11～20年 21年以上


図表 3-4-12 ハードウェア別再構築後のシステムライフ


328

（２）再構築後のハードウェア

───急速に進む脱ホスト今回の調査結果では、再構築前は 66％の企業がメインロジックをホスト系機器で稼動させてい

たが、再構築後はわずか 19％となった。一方で、Windows 系マシンを採用する企業が 12％→46％と急増し、UNIX 系システムを採用する企業も 6％→25％に増加した。他方、相変わらず Linux 系を採用する企業は少ない。コスト面では優位にあるものの、サポー

トレベルの低さ、サポート期間への不安、利用できるパッケージの少なさといった点がネックに

なっていると思われる。

(n=484)

66%

19%

6%

25%

12%

46% 4%

15%

6%

0.4%

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

A.再構築前

B.再構築後

ホスト系 UNIX系 Windows系 Linux系オフコン


図表 3-4-13 再構築前と再構築後のハードウェア

（３）再構築後のソフトウェア開発方針

───独自開発が激減し、パッケージの積極採用へ今回の調査結果では、再構築前は 76％の企業がシステムをすべて独自開発していたが、再構築

後は激減して 33％となり、パッケージを活用してシステムを構築する割合が 67％と高い割合を

占めるという明確な逆転傾向が現れた。

(n=482)

76%

33%

12%

23%

9%

27%

4%

17%

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

A.再構築前

B.再構築後

1.すべて独自開発2.一部パッケージ利用3.パッケージを多用するが一部独自開発4.全面的にパッケージを利用


図表 3-4-14 再構築前と再構築後のシステム開発方法


329

（４）脱ホストはパッケージ採用に意義ありか

Windows や UNIX マシンへの移行を進めている企業の動向を分析してみよう。脱ホストを図

る一つの要因として、コスト削減が考えられる。確かに図表 3-4-15 によると、これらの機器を採

用した企業の 3 割～4 割は、再構築後の運用費用を削減させたとしている。しかし、ホスト系マ

シンを採用する企業も 3 割程度は運用費用を削減させるとしており、ハードウェアの採用による

顕著な差異はない。

27%

29%

5%

28%

19%

26%

18%

21%

21%

32%

30%

40%

63%

33%

42%

17%

13%

11%

17%

6%

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

ホスト系(n=88)

UNIX系(n=119)

LINUX系(n=19)

Windows系(n=212)

オフコン(n=31)

増加普変減少わからない


図表 3-4-15 再構築後のハードウェアと再構築後の運用費用の関係


330

一方で、これらの機器を採用した企業のソフトウェア開発方針を見ると、「パッケージを利用す

る」とする企業が 75％と非常に高い割合を示している。Windows 系システムや UNIX 系システ

ムを採用するのは、自社の独自開発からパッケージを使って開発工数や開発期間を短縮する動き

と重なるものと考えられる。

54%

23%

53%

23%

58%

26%

29%

21%

20%

19%

14%

31%

26%

31%

19%

5%

17%

0%

26%

3%

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

ホスト系(n=92)

UNIX系(n=120)

LINUX系(n=19)

Windows系(n=219)

オフコン(n=31)

すべて独自開発一部パッケージ利用パッケージを多用するが一部独自開発全面的にパッケージを利用

図表 3-4-16 再構築後のハードウェア別ソフトウェアの開発方法

（５）パッケージの採用は企業規模を問わない全般的な傾向

ソフトウェアの開発方針を企業規模別に集計してみると、規模による差異はなく、どの規模に

おいても、パッケージを多用する傾向があることが分かる。

55%

28%

38%

31%

41%

28%

14%

26%

25%

20%

23%

28%

14%

27%

30%

32%

18%

19%

14%

19%

9%

12%

23%

27%

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

100人未満(n=22)

100～499人(n=177)

500～999人(n=104)

1000～4999人(n=131)

5000～9999人(n=22)

10000人以上(n=25)

すべて独自開発一部パッケージ利用パッケージを多用するが一部独自開発全面的にパッケージを利用


図表 3-4-17 企業規模別のソフトウェア開発方法


331

（６）再構築後のプログラム言語

───COBOL 採用が激減し、VB・Java へ再構築前は 69％の企業が COBOL を採用して開発していたが、再構築後は激減して 22％とな

った。一方で、増加したのが「VB（Microsoft Visual Basic）」と「Java」で、VB は 8％→24％と最も採用の割合が高い言語に、次いで Java は 1％未満→17％と採用する企業が急増する結果

となった。

(n=452)

69%

22%

3%

8%

8%

24% 9% 16.5%

16%

21%

2%

0.2%

1%

0.4%

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

A.再構築前

B.再構築後

アセンブラ COBOL C言語 VB PL/SQL Java その他


図表 3-4-18 再構築前と再構築後のプログラム言語

（７）Windows システム＝VB、UNIX システム＝Java

VB や Java の採用が増えているのは、再構築後のシステムで採用するハードウェアとの適合性

によるものと考えられ、Windows 系では VB が、UNIX 系では Java が多く採用されている。

4%

63%

15%

6%

6%

39%

14%

10%

3%

10%

6%

44%

4%

14%

11%

10%

5%

26%

78%

13%

24%

21%

16%

54%

2% 2%

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

ホスト系(n=87)

UNIX系(n=111)

LINUX系(n=18)

Windows系(n=204)

オフコン(n=28)

アセンブラ COBOL C言語 VB PL/SQL Java その他


図表 3-4-19 再構築後のハードウェア別プログラム言語


332

７．再構築プロジェクトの工期・費用・品質

（１）再構築の結果には概ね満足

再構築のプロジェクトの工期と予算については、全体の約 4 割が予定どおり行かなかったと回

答しており、課題が多い（図表 3-4-20、3-14-21）。特に再構築プロジェクトの投資規模と予算の関係を見ると、投資規模が大きいほど予算超過の

割合が高くなっており、プロジェクト推進の難しさが伺える。また、工期についても、投資規模

が大きいほうが超過の割合が大きくなっているが、50 億以上のプロジェクトでは予定どおり完了

している割合が多くなっている。

26%

18%

37%

35%

36%

43%

35%

24%

30%

33%

42%

39%

38%

43%

50%

52%

30%

23%

25%

19%

22%

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

全体(n=476)

5000万未満(n=76)

5000～1億未満(n=47)

1～5億未満(n=146)

5～10億未満(n=42)

10～50億未満(n=67)

50億以上(n=27)



図表 3-4-20 投資規模別再構築プロジェクトの工期の状況


333

19%

16%

11%

39%

38%

45%

42%

38%

37%

30%

38%

30%

32%

34%

43%

46%

59%

24%

23%

32%

23%

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

全体(n=476)

5000万未満(n=76)

5000～1億未満(n=47)

1～5億未満(n=146)

5～10億未満(n=42)

10～50億未満(n=67)

50億以上(n=27)



図表 3-4-21 投資規模別再構築プロジェクトの予算の状況

（２）品質はプロジェクトリーダー、プロジェクトマネジメント次第か

一方、再構築のプロジェクトの品質については、77％と高い割合で満足とする結果となってい

る（図表 3-4-22）。投資規模と品質の関係を見てみると、規模と「満足」「不満足」の割合に相関

した傾向はみられなかった。また、実施体制と品質のクロス集計でも、明確な相関関係は出ていない（図表 3-4-23）。これはプロジェクトの品質は、規模や体制によらず、プロジェクトリーダーを中心とするマネ

ジメント次第と言えるのではないだろうか。

7%

9%

30%

63%

67%

51%

65%

69%

63%

52%

23%

17%

34%

24%

24%

28%

19%

14%

16%

15%

11%

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

全体(n=476)

5000万未満(n=76)

5000～1億未満(n=47)

1～5億未満(n=144)

5～10億未満(n=42)

10～50億未満(n=67)

50億以上(n=27)

満足ある程度は満足不満


図表 3-4-22 投資規模別再構築システムの品質の満足度


334

14%

12%

20%

61%

64%

65%

25%

24%

14%

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




満足ある程度は満足不満


図表 3-4-23 実施体制と再構築プロジェクトの品質


335

８．再構築プロジェクトの課題

（１）現行機能の継承とユーザーの理解・協力を得ることが大きな課題

再構築プロジェクトにおける問題点として、上位 2 つを選択してもらったところ、「現行シス

テム機能の把握と業務要件の継承」を 1 位にはも多くの 32％の企業が課題としている。2 位も

あわせると 51％と過半数の企業が課題として挙げている。再構築の対象となる現行システムに、必要かどうか分からない機能が残っている、あるいは要

件が不明確な機能がある、要件が網羅的に把握できないなど、現行機能の継承について、多くの

企業が悩みを抱えているようだ。一方で、「ユーザーへの説明、ユーザーの理解・協力」が 1 位にあげた企業が 28％と 2 番目だ

が、2 位に挙げた企業もあわせると 53％とも多い。稼動中のシステムを切り替えることになる

ので、現行の仕組みを変更することに対する、ユーザーの理解・協力を得ることも大きな課題と

なっている。

(n=478)

32%

28%

16%

5%

5%

4%

4%

19%

25%

10%

12%

9%

6%

8%

6%

4%

2%

3%

2%

2%

0% 10% 20% 30% 40% 50% 60%

現行システム機能の把握と業務要件の継承

ユーザーへの説明、ユーザーの理解・協力

経営陣への説明、経営陣の理解

IT部門の説明能力・プロジェクトマネジメント能力

昔のシステム仕様をわかる人がいないこと

新しい技術をわかる人がいないこと

ドキュメントが残っていないこと

ユーザビリティの継承　

引き継ぐデータベースに問題がある　

その他　

1位 2位


図表 3-4-24 再構築プロジェクトにおける課題


336

９．システムの再構築の課題と対策

（１）システム再構築が何故発生するのか、何故再構築プロジェクトは難しいのか。

システムは生き物であり寿命がある。まずハードウェアは劣化する。回線など劣化しにくいものであっても新しい機能が出現し周囲

の企業が使い始めれば、その機能を自社も使い始めないと競争についていけない。日進月歩の新技術はコストダウンをもたらしてくれ、おおよそ毎年 10％、物によっては 20％

のハードウェアの価額低下をもたらす。このことが５年償却を基本とする税制の影響もあってハ

ードウェアの置換をしたくなる。ソフトウェアは、劣化はしないが、陳腐化する。ビジネスを取り巻く環境の変化もあって業務

改革が常に要請される。業務改革、新商品新サービスの提供のためにはシステム再構築が避けら

れない。しかしこのシステム再構築は、IT 部門、業務部門が大きな努力を強いられる経営活動と

なるので、実施の判断は慎重にならざるを得ない。企業統合、合併などの影響を受けていやおうなく再構築に入る場合もある。 JUAS の 2003 年度の本調査結果によると独自開発のシステムは、17 年使用されることがわか

った。一度開発したシステムは 20 年近く手直しを繰り返しながら使われているのである。 20 年前に作成した担当者の大部分は退職したり、配置転換になったりしており、現存している

システムの仕組みを良く知っている人は少ない、あるいはその企業には誰もベテランはいない場

合さえある。残されたドキュメントが必ずしも正しいあるいはわかりやすいとは言い切れない問

題もある。このような背景を受けて実施した再構築プロジェクトは工期の遅延は42％で、予算超過は38％、

品質の不満は 23％であることが今回の調査で判明した。日本企業の優秀さ、勤勉さを持ってして

も半数近くのプロジェクトは予定どおり進めることが出来なった。再構築プロジェクトの難しさは確実な業務仕様の確定が難しいことと移行の難しさにある。まったくシステムのないところにシステムを導入する場合とすでにあるシステムを再構築する

場合では、後者がやさしいように感じるが実は反対である。旧システムのデータを引き継ぎ新しいデータを受け入れることは実は新システムを初めて動か

す場合の 2 倍のテスト負荷がかかる。「今すでにシステムはあるのだからその切り替えは簡単だろう」と一般的には思われがちであ

るが誤解で、そのように考えて甘い対応で計画したプロジェクトはことごとく足をすくわれてい

る。単にシステムのハードウェアを新しくした場合、業務改革を取り込まず新機能を付け加えな

い場合は比較的スムーズに移行が進むが、新規投資を回収しようとすれば、新機能を取り込まざ

るを得なくなる。新機能を取り込めばそこに問題発生の卵が潜んでくる。しかし、企業が生き残るためにはこのシステム再構築は避けて通れない。以下もう少しこの問題を考えてみよう。


337

（２）システム再構築のタイプと難しさ

再構築の目的と効果、影響など再構築を取り巻く問題を分析してみる。

図表 3-4-25 システム再構築

ユーザー企業の基幹業務システムの再構築には上表のごとく 3 パターンがありおのおの特徴を

持っている。

①基盤変更のみ「ハードウェアのサポート期限が切れます」「ミドル・ソフトウエアーのサポートがなくなります」などの理由で更新を余儀なくされる場

合である。「何故そのようにサポート期限が短いのか」と経営者から尋ねられてユーザー企業の IT 関係

者が頭をかかえるのがこの切り替えである。幸いにしてハードウェアは 5 年前に比較して少なくとも 50%は安くなっており「コストダウン

案件」として経営者の承認を得ることになる。この導入のために実作業で苦労するのは、IT 部門

の基盤支援技術者であり、アプリケーション関係者の作業はほとんど生じない。ユーザーにとっ

てはハードウェアの能力アップによるレスポンスタイムの短縮やシステムの安定性および新機種

や新ソフトウェアが持つ機能が効果となる。

大

（旧データも新プログラムで正しく動く保証が必要

新規開発に比較して２倍の負荷）

中

中

大

低

大

移行難度

説得負荷

旧システムの機能、ＤＢ内容の確認+新規

追加機能の確認

ありなしアプリケーションの切り替え作業

同左+新規開発プロ

ジェクトの負荷大

同左+アプリ開発保

守部門の負荷大基盤技術関係者のみ負荷大

ＩＴ部門の負荷

新規アプリの活用少々(Usabilityの部分）ほとんど無しユーザへの影響

同左+新機能の効果同左+システム保守

の容易性インフラのコストダウン

効果

同左+新機能の取り

込み

同左+スパゲッチー

プログラムの解消

+ＤＢ構造の刷新

ハードウエアー、ソフトウエアーの更新

目的

基盤変更+新業務機

能を追加したプログラム開発

基盤変更+プログラ

ム刷新基盤変更のみ変更形態

比較項目

大

（旧データも新プログラムで正しく動く保証が必要

新規開発に比較して２倍の負荷）

中

中

大

低

大

移行難度

説得負荷

旧システムの機能、ＤＢ内容の確認+新規

追加機能の確認

ありなしアプリケーションの切り替え作業

同左+新規開発プロ

ジェクトの負荷大

同左+アプリ開発保

守部門の負荷大基盤技術関係者のみ負荷大

ＩＴ部門の負荷

新規アプリの活用少々(Usabilityの部分）ほとんど無しユーザへの影響

同左+新機能の効果同左+システム保守

の容易性インフラのコストダウン

効果

同左+新機能の取り

込み

同左+スパゲッチー

プログラムの解消

+ＤＢ構造の刷新

ハードウエアー、ソフトウエアーの更新

目的

基盤変更+新業務機

能を追加したプログラム開発

基盤変更+プログラ

ム刷新基盤変更のみ変更形態

比較項目 ① ② ③


338

②基盤変更+プログラム刷新「スパゲッティプログラムになりメンテナンスできない」と保守担当者に泣きつかれて更新す

る場合である。 20 年前はユーザーの要求を満たすため、能力の低いインフラ環境のデータベース構造や性能の

低さをカバーするために各種の工夫を凝らしてしてきた。技術が進化した今となってはそのよう

な工夫は必要なく、むしろ足かせになっているので、何とかすっきりプログラムを組み替えたい

と SE は考える。データを正規化するだけでプログラム量は 30％減少するといわれている。ユーザーからの保守要求が出てきても迅速に修正できない環境を嘆いている SE の願望を解決

するひとつの方法である。しかし経営者には「ハードウェアのように、古くはならないはずのプ

ログラムが何故古くなってしまうのか」は理解しがたい問題である。「担当している SE が保守できないと言うので更新する」との説明は、経営者にとっては素直

に受け入れがたいものとなる。新機能を取り込むための更新であり、「この更新作業が終わればユ

ーザー部門からの要求へ迅速に対応できる」との説明は、この次に投資が必要なく機能更新でき

ることを約束しているわけではない。しかし、ユーザーの新機能要求にこたえて、システム再構

築前より迅速かつ容易に対応できることが期待できることは間違いない。本来は新機能追加の検討を十分に行いその後でプログラムを刷新するのが、効果が増える意味

からは適であるが、効果検討まで十分に実施している期間がとれない場合などにこの手法が使

われる。

③基盤刷新＋新業務機能を追加したプログラム開発企業の基幹業務刷新は単に投資額の問題だけでなく、各社の経営総合活動のひとつとなり、プ

ロジェクトの成功失敗は株主報告の話題にまでなる。したがって再構築の戦略・企画での上記３

手法の選択と投資効果、リスク分析の明確化は非常に重要な経営判断である。特にこの中で IT 投資効果の検討は経営者、企業のリーダー含めての重要判断事項である。できれば切り替えに困難を伴っても、第３の新業務機能を追加しての開発が投資効果をあげる

面では望ましいと考えられる。方法①②を採用しても結局企業の興隆のためには、再度新業務機

能への挑戦をどこかで強いられることになるので、本来ならば①②を実施する前に③の検討をは

じめることが望ましい。


339

（３）システム再構築の概念


図表 3-4-26 再構築のタイプ

システム再構築を実施する場合の一番の問題点は新しいシステムにどのような改革機能を盛り

込めばよいのかを考える知恵がどの程度あるかである。もともと手作業をシステム化した何年か前にも業務改善、組織変革、設備改善などの改革を実

施して現行システムを作成してきたはずである。その基盤を乗り越えた新しい知恵を十分に盛り

込む必要がある。しかし業務部門はリストラを繰り返し、新機能を考える余裕と高度な知恵を持っている人が少

なくなっている。たとえそのような知恵者が存在していても、その中心人物は多忙である。ここ

に計画どおりにシステム再構築が進まない原因が潜んでいる。業務部門を支える立場の IT 部門

も情報子会社化されて業務に関心が薄い SE が増加している。それでも競争優位に立つためには、全社挙げての総知恵を出す組織的な活動が要請されてくる。

現状業務を整理し問題を問題として感じる問題感知力の強化が改革案の創造につながってくる。この情報システム開発以前のビジネスモデルの改革案創出に十分な時間をかけることが、効果

的なシステム作りに結びつく。この期間を十分に確保し議論に議論を重ねることが社員，SE の

育成にもつながってくる。現行システムの詳細を知らない人ばかりなら、いっそ新しい商品体系、新サービス体系を創り

出しその仕様をまとめるほうが早いとの発想で挑戦する方法もある。いずれにしても、まず新情報システムの前に新ビジネスモデル、新業務モデルが論じられなけ

ればならない。

手作業業務改善組織変革設備改善

現行システム

「課題」・業務部門の効率化による改革創出能力の低下・業務継承能力の低下・情報子会社化による業務改革への関心低下・IT部門の提案力の低下

新たな知恵によるシステム再構築

新システム

「対策」・改革案の創造力・問題感知力の強化・推進体制、特に利用部門の協力強化

・プロジェクトマネジメント力の向上・新技術の活用（含むユビキタス）

*H/W、OS等の置き換えについては別扱い


340

（４）業務システムと情報システムとの境


図表 3-4-27 業務システムと情報システム

新機能を盛り込んだ業務システムの骨格が出来た次に情報システムが登場してくる。ユビキタ

スなどの新 IT 技術を目玉にした業務システムが誕生する場合もあるが、情報システムが出来て

から業務システムを始めて考えるケースはまれである。さて業務システムを情報システムとの接点は「業務ルール」「画面など通じた情報入出力方法」

「データ」「出力帳票」の４項目である。この４項目の中で一番あいまいさが入ってくるのは業務

ルールであり、問題の多くはここに潜んでいる。20 年前に作成した時とシステムの作り方が一番

変わっていないのもこの業務ルールをシナリオに変換する方式である。この部分の改革を提案し

たい。

①業務ルールの展開システム利用者が提案できるのは「必要とする要求機能である」これを「要求仕様」に変換す

る必要がある。システム設計とは何かをある程度学んだ利用者が、要求仕様を提示する場合もあ

るが完全なものを作成することは難しい。ここは開発者のベテランの知恵と力を借りたい。ユーザーが要求した要求機能が要求仕様にどのように変化したのか。トレースでき、それがプ

ログラムのどこに組み込まれているのかがわかるようなシステム作りを期待したい。要求機能番号が要求仕様番号に引き継がれ、プログラムのポジションコードに展開されてわか

りやすいプログラムとなり保守性が向上する仕組みを期待したい。今や手書きの仕様書はない。すべて仕様はコンピュータの中に入っているので、この資源をも

っと有効に活用し仕様変更がトレースできる仕組みに変えてゆく必要がある。

業務システム

情報システム

プロセスモデルユーザー

インターフェイス

データモデル

④画面・帳票

画面

①シナリオ

③DOA手法

②手法

担当者（発注者、受注者）の主観・あいまいさ・の入る大きさ

システムの

使いこなし

業務ルール


341

また機能仕様の記述は｢必要機能仕様｣と「その機能仕様が必要とされた背景、理由、原因」を

分けて記述することにより、後継者の理解が容易になることも証明されつつある。このような努

力、改善が大きく望まれる分野である。

②画面のユーザーインターフェイスシステム再構築でユーザーが一番変わったと感じる部分はこの画面の入出力インターフェイス

である。操作性は確実にレベルアップし使いやすくなっている。その分のプログラムを作成する

手間も増えてきた。この部分の合理化はまずペーパープロトタイプアプローチを試みると良い。

フリーハンドで A4 サイズの紙の上に、入出力項目を鉛筆で素描し消しゴムを使いながら操作方

法を確認するこの手法は時間短縮になるし設計技術の向上にもつながる。画面の流れなどの確認

にも役立つ。このペーパープロトタイプアプローチを経た上で、ブラウザ技術により実装に入る

方法が無駄が少ないと考えている。一度試みられると良い。

③データモデル・データ構造の問題

現行システムから新システムへと変更する場合にもっとも安定しているのがデータである。こ

のデータベースの設計には通常は DOA が活用されることが多いが、従来は完全な正規化がされ

ていないケースが多い。これは過去のコンピュータの能力、特にディスク能力が不足していたた

めにレスポンスタイムを確保するためにデータを重複して持ったことに起因している。しかし近はディスクも高速化し完全性正規化しても処理時間は問題がなくなってきている。

完全な正規化ができると、Relational Database の balance tree 構造機能などもあわせて活用す

ることによりプログラム処理構造は非常にシンプルになり、「SORT」→「Matching」→「SORT」のバッチ処理システム構造は解消する。従来のバッチシステムの構造を脱却した新時代にあったバッチシステムは運転管理の容易化に

つながってくるので是非挑戦してほしいものである。データ構造が変化する典型的なケースに ERP への移行の場合がある。ERP などのデータベー

スに展開する場合には、データ構造が変わる場合があり相当な移行負担になることがあるので注

意が必要である。

・コードの追加・変更がある場合新しいコードや情報を現行システムデータベースに追加する場合も負荷は大きい。既存データ

コードを集約することは簡単であるが、分化することは至難の業になる。また既存のデータベースの中には、システム保守の段階で発生したと思われる不思議なお化け

データが潜んでいることもまれにある。あるいは仕様書には現れてこないコードが登場してくる

こともある。


342

・データコンバージョンの時期と現行データの有効活用

新規システム開発と比較してシステム再構築が優位に立てるのは「既存データが存在する」こ

とである。既存データを活用してテストができ新システムの正確性が検証できることである。この優位さを十分に活用しない手はないのだが、実際は「データコンバージョンは総合テスト

の前に実施すること」という従来の慣習が邪魔をして発想の転換が出来ず、単体テストからこの

データを活用することは進んでいないように見える。「持ち帰り開発に実データは出せない」と抵抗する発注者もいるがそれなら名前や住所などは

架空のものにして実在データとは異なるものにして提供すればよい。従来のきめ細かい仕様の単体テストデータの活用に加えてこのコンバージョンデータを活用す

る。この現行システムからのデータコンバージョンを単体テスト開始時に実施することの効果は、

単に単体テストの精度が向上するだけではなく結合テスト、総合テストの効率化にも結びつく。

さらに十分にデータコンバージョン結果が活用されるので、不良データ、仕様の抜けのチェック

にも役立ち立ち上げトラブルの減少にもつながる。変わるべき箇所は変わり、変わらない箇所は現行システムと整合性がとれているかどうかの検

証にも役立つ。しかもプログラムを使っての新旧出力の比較も可能となるケースも多く確認の負

荷減少にもつながる。「できない」とあきらめずに「95 点のコンバージョン結果でも活用できる」と考えればこの早

期コンバージョンの効果に結びつくので是非トライすることをお勧めしたい。

④引き継ぐもの、引き継がないもの現行システムから再構築後の新システムへ引き継ぐもの、引き継がないもののうち、代表的な

要素を以下にまとめる。

・引き継ぐもの ①データ ②入出力項目 ③業務不変部分の仕様

・引き継がないものは ①OS (ただし変更しない場合もある) ②DB 構造（同上） ③画面処理（ユーザビリティ） ④アプリケーションプログラム ⑤仕様書、設計書 ⑥操作ガイドなど現行システムのドキュメントが正しく更新されていない場合が多いので、引き継ぐ場合は十分

にその機能を動かして問題がないことを確認してから活用する必要がある。


343

（５）移行問題

システム再構築の移行の難しさは、再構築後の新システムの稼動当初から大量データが流れる

ことである。それに新しい業務方式の採用があると利用者は慣れるまでに相当苦労すると考えて

準備したほうがよい。移行方法には 2 種類ある。・Ⅰ→Ⅱ： Ⅰでまず現在の機能を確認し、本番に移行してから、機能改良をする方法・Ⅲ：新旧機能を一度に移行する方法

図表 3-4-28 システム移行方法

上記手法のどれを採用するかは、そのシステムの置かれた環境によって変わるが、ⅠからⅡの

ステップを採用した場合には、切り替え時の混乱は少なく出来る。しかしこのようなステップ分けが取れない場合もある。何が正しいのか十分に認識できていない場合に、いきなりⅢの方式で切り替える場合で、特に

情報だけが動くのではなく、その結果荷物が動く、人が動く、在庫が動くなどの場合には注意を

要する。たとえシステムの出力が正しくてもそれに伴った物が正しく動けるかどうかは、情報の

正確さのみならず、実物の行動までがシステムに同期して正しく動くことを要請される。現行シ

ステムが存在して物が動いているのに、新システムによって物を動かすテストは行いにくいのが

普通である。したがってテスト不十分でぶっつけ本番になるケースが多い。たとえ机上シミュレーションなどを十分に行っても本番では何が起こるかは判らず、すべての

事象をシミュレーションすることは出来ない。しかも切り替え当初は切り替え時の処置がさまざまあり、データ入力数は通常時の 3 倍にも達

する場合がある。そのような時にでもシステムが正しく運用できるように端末操作者、情報利用

者の十分な訓練が欠かせない。以上システム再構築の問題と対策を縷々述べてきたが、これを乗り越えるための対策として推

進体制(組織)とプロジェクトマネジメントについて補足しておきたい。

現行保証機能改良

Ⅰ

Ⅱ

Ⅲ

システム機能レベル

プログラムにより出力結果を

新旧全項目比較する


344

（６）再構築推進体制

基幹業務の再構築は、大規模であり長期間に複数部門が協力しないと目的を達成できないプロ

ジェクトである場合が多い。したがって予算規模は大きく、関係者は多数かつ複数部門にわたるので、経営者あるいは社長

の強力なリーダーシップが要求される。うまくいっていない場合はプロジェクトのリーダーの階

層を上げて見るのも一つの手である。 IT 部門主体でこのプロジェクトを進めたとしても後に活用するのは業務部門であり、この業

務部門の協力は重要課題である。環境やその場の役割や人柄などにもよるが業務部門のトップ

を再構築プロジェクトのトップに担ぎ出して成功した例は多い。 IT 部門が勝手にやっていると思われない組織作りは成功に欠かせない。プロジェクトが大型になるので長期間、多くの残業を強いらざるを得ない場合もあり、プロジ

ェクトメンバーの健康管理も課題としてあがってくる。ガス抜きの懇親会や同じ T シャツを着て

頑張ってもらうなどの配慮をして乗り切ったプロジェクトもある。社員だけでなく、協力会社の

SE への配慮もプロジェクトの成功のためには欠かせない。

（７）プロジェクトマネジメント

①プロジェクトマネージャーの選抜

予算、工期、品質をプロジェクトメンバーの健康を考えたプロジェクトマネジメントの出来る

管理者は限られてくるが成功のための一番重要な要素である。この実質のプロジェクトマネージ

ヤーの影響力は大きい。十分な仕様整理をせずにベンダーのプロジェクトマネージャーに早い時

期から任せて後戻りをした例には事欠かない。プロジェクトが大きくなればなるほど技術力より人間力が重要になる。まず自社内から適任

者を選抜せねばならない。暇な人に頼むよりも忙しい実力者に頼むほうが成功率は高い。また日本企業も今やグローバルな経営を要求されている。世界中で使うシステムを開発する場

合には英語力の堪能さとともに人間力が不可欠となる。「あいつが要求しているならやむをえま

い」と国際的な了解を得られる人物をプロジェクトマネージャーに選抜しないと、世界の支社の

人は動かない。

②仕様確定再構築プロジェクトが遅延する場合はこの仕様確定フェーズの遅れが影響している。業務モデ

ルの検討、要求仕様の確定には時間をかけてかけすぎることはない。

・絶対納期と相対納期仕様確定を急ぐ原因の一つが納期制約である。経理システムの切り替えは、会計年度末を逃すと余分な作業が発生してくるので切り替え時期

は年度末を逃せないので絶対納期と考えざるを得ない。新商品の販売開始にあわせた再構築シス

テムは納期設定を変えにくいのでこれも絶対納期である。それに対して多少納期が変動できるシステムは相対納期である。社内の情報検索システムなど


345

は結構納期調整が出来るものが多く相対工期である。この納期からさかのぼっていつまでに仕様確定しなければならないのかを決めてプロジェクト

は走るため、仕様確定の時間が不足しがちになる。期日までに仕様を確定するのが、あるいは仕様を確定してもらうのがプロジェクトマネージャ

ーの腕になる。このポイントは以下のとおりである。・決定できる責任者を見極めプロジェクトに参画してもらうこと・決定できない仕様は上位管理者の裁断を仰ぐこと・仕様確定会議には上位管理者の出席を仰ぎこの仕様確定の意味の徹底と変更の承認プロセス

を明確にしてもらうこと・複数案を提示し右か左か選んでもらうこと・決定作業を細分化し実情を可視化し督促を適宜行うこと・会議の進捗を図れる司会の仕方を考えて実行すること・プログラムを作成する部門の責任者に早めに仕様をチェックしてもらい不十分な仕様の解消

に努めること ③新技術、新商品の採用

ユーザーの要求を解決するには新しい技術の採用が望まれる場合もある。あるいは開発効率を

あげるために新技術、新商品を採用せざるを得ない場合もある。しかし IT の世界において新技

術が安定して提供されるのはマレだといってよい。この新技術・新商品によるトラブルで足を掬われたケースも多い。PILOT 試用を十分に実施し

たうえに新技術の採用に踏み切ることが望ましい。大型システムでの新技術の採用は致命傷にな

るので初物は避けて安定した技術のみ採用している賢明な企業もある。

④リスク管理システムの採用基本設計に入る前に、あるいはベンダー選定を行う場合に生産性を落とす要素は何か。生産物

を増やす要素は何かに分けて、ユーザーとベンダーがリスクを見通す仕組みを JUAS の SRM 第

一巻に提供したが、今回はシステム再構築の場合を配慮したリスク基準を作成したので、ここに

紹介したい。この方式により発注者と開発作業受注者が「今回の再構築プロジェクトにおいて、何がどの程

度のリスクになるのか。また何に注意して進めればよいか」を見極めることが可能になる。今まで保守作業を実施していない未知なシステムへの再構築プロジェクトを一括で引き受ける

ことは、ソリューションベンダーにとっては、危険なこととされている。既存システムの状況や品質がわからないのに、既存システムの機能どおりに作成せよ、という

危険な要求がユーザーから出されるからである。中には一部既存システムのプログラムを引き継

いで活用して欲しいの要求がでる場合もある。既存システムにはバグが潜んでいる可能性もある

ため、どこまでテストを実施して品質を保障したら良いのか判らず悩むことになる。こようなリスクをユーザーとベンダーで認識を共有する基準を記述したものが、この改造型固

有のリスク変数表である。


346

ａ．生産性環境変数再構築型プロジェクトの生産性環境変数は次の 7 個である。

１）既存設計書類の具備状態

既存システムの内容が完全に記述されているドキュメントが存在するのかは再構築作業に大き

な影響を与える。開発時に完全に作成されたドキュメントも保守作業中に完全に保守され引き継

がれていないケースが多い。不完全なドキュメントを基に仕様書を作り直してもまともなシステ

ムは出来上がってこない。その状態によって要件定義、設計、製作、テスト作業は+30％も負荷

が異なる場合がある。いくつかの既存ドキュメントとプログラムを照合し記述・保管内容のレベ

ルを確認することが望まれる。

２）母体調査ツールの機能水準母体のシステムの仕様書とプログラム、データベースの関係を調査するツールがどの程度完備

しているか」は、作業効率に大きな影響を与えるので、その具備状況を確認する。

３）既存テスト環境流用基準既存のテストドキュメントおよびテストデータが再構築のテストに活用できるかどうかを確認

する。流用率はそのまま活用できる生流用率とデータの加工程度割合とデータに残っている残存

バグ率の掛け算で決まる。そのまま精度良く完全に流用できれば、テストデータ作成負荷は 30％程度軽減される。

４）構成管理の不備度合い要求仕様書、設計書、プログラムシートの不整合は、無駄な調査を巻き起こす。気の効いた構成管理の仕組みがあれば以降作業は効率的に作業が進むので、その影響を見込む。

５）既存母体の品質既存システムにバグが多数潜んでいる場合には、何が正しいのか悩むことになる。既存システムの潜在バグの程度は保守作業記録をチェックすることにより判断する。

６）既存母体の解析性既存プログラムのソースへのコメントの記入程度、修正履歴の保存程度、モジュールサイズの

適正化、その他のプログラム作成上の標準化程度などの解析性を評価する。

７）既存システムの母体の環境適用性を評価するほとんど同じ環境に移行する場合はリスク値が低いが、ハードウェア、OS、フレームワーク、

言語、データベース、画面ツールなどが大きく変わる場合はリスク値を大きく設定しないと負荷

がカバーできない。


347

ｂ．改造型固有規模環境変数１）既存母体の正確性

改造・流用母体が正しく動作しない場合のテスト量が増加することへの配慮が必要となる。既存母体の残存バグ数によりリスクを推定する。

⑤U 字型開発法従来の古典的システム開発論の V 字型開発法を日本的開発環境に合わせて、上記改革案を盛り

込んだものがこの U 字型開発手法である。システムの開発は要件定義から始まるものではなく IT 戦略・プロジェクト企画から始まり、

開発を経て利活用フェーズまで一貫して眺める必要を唱えている。またエンドユーザーによるシステム機能の要求から始まり徹底レビュー、ユーザビリティ、単

体テストフェーズからのコンバージョンデータの活用など各種工夫が採用されている。手法はシステム再構築のような大規模、高品質のシステム開発には適しているので是非参考に

してほしい。この手法の紹介は第 3 章第 1 節「開発の実態と評価」にあるので、そちらを参照されたい。

要求定義

基本設計

詳細設計

プログラム設計書単体試験


総合試験

実運用試験

終了

要求定義

基本設計

詳細設計

プログラム設計単体試験


機能結合試験

総合試験

実運用試験

機能確認の重点

使用者への開示拠点

Min化

・各フェーズの発生欠陥は、相対するフェーズのテストで欠陥を発見する。

・後のフェーズの総合試験または実運用試験終了後になって仕様の欠陥が発見される。

ユーザーによるシステム要求

徹底レビュー

単体テスト開始前に全データコンバージョン完了

機能結合試験

ユーザビリティ１

ユーザビリティ２

IT戦略・企画

見積透明性（品質・工期・

生産性）

調達（見積・契約）

新ビジネスモデル

保守・運用

利活用

ライフサイクルコスト（安定性・

信頼性）

ＩＴ投資効果評価

ＤＢパトロール

要求定義から設計・試験までのトレーサビリ

ティ確保

外注プログラマが一緒に仕事をしている間にユーザーにテスト結果を提示し確認・修正する

全工程を通じて可視化、指標化ができるプロジェクトマネジメント（ＥＡＳＥ）の実施

＊＊

注：＊＊開発用ＲＦＰ

＊要件定義用ＲＦＰ

＊

移行移行計画

開始

Ｍｉｎ化

Min化

図表 3-4-29 V 字型開発からと U 字型開発へ

./keyword.htm#2002

./keyword.htm#2101


348

図表 3-4-30 生産性環境変数

生産性見積り方式Ｐｉ＝ＰＢｉ × （1+Σβｉｊ） βｉｊ:生産性環境変数

評価の観点外責評価基準（見積プレゼン用）内責評価基準

（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容

特記、特例事項要件定義

設

計

製

作

テスト

設計

製作

テスト

業務特

性

-10 -10 － -10 中核メンバー全員が

当該業務経験多数

業務ナ

レッジ

(P01)

-5 -5 － -5 中核メンバーの一部

の当該業務経験少

0 0 － 0 中核メンバーの一部

に未経験者あり

40 8 － 8 中核メンバーに当該

業務経験者不在

・顧客／当社の開発対象

業務に対する業務ナレッジ

が生産性に及ぼす影響

を、それぞれ（外責／内

責）個別に評価する

・外責評価はユーザー部

門を含む顧客プロジェクト

組織全体の能力として評

価する

・内責評価は当該プロジェ

クトへのアサインベースで

評価する

→世の中にない業

務モデル等の創

造、システム化の

要素も含む。

→ プロジェクト全

体としての方針・仕

様意思決定能力

（旧組織複合度の

要素を取り込む）

→ 実／予定アサ

インメンバーの業

務ナレッジで評価

50 10 － 10 メンバー全員が当該

業務経験なし

ハードウ

ェア特性

－ -5 － -5 当該HWでの効果的

開発手法を保有

－ -3 － -3 当該HWでの開発実

績多数（安定度高）

安定度/

信頼度/

使用実

績

(P02)


インメンバーの使

用実績で評価

－ 0 － 0 当該HWでの開発実

績が当社基準での

平均

－ 3 － 3 顧客に使用実績の

ない HW

・システムもしくは製品とな

るハードウェアの安定度・

信頼度を外責として評価

し、当社使用実績を内責と

して評価する

（注）「使用実績がある」と

いうことは、ハードウェアの

特性を把握し、その対策は

既知であるが故に、生産

性が高いということ。－ 5 － 5 世間で使用実績の

ない HW

ソフトウ

ェア特性

－ -5 － -5 当該 SW での効果的

開発手法を保有

安定度/

信頼度/

使用実

績(P03) － -3 － -3 当該 SW での開発実

績多数（安定度高）

－ 0 － 0 当該 SW での開発実

績が当社基準で平

均


インメンバーの使

用実績で評価

→要件定義の

「－」は、ERP を利

用する場合を想定

していないことに

注意すること。

－ 3 － 3 聞いたことはあるが

特性がわからない

SW

・システムもしくは製品とな

る他社作成ソフトウェアもし

くは Cots の安定度・信頼

度を外責として評価し、当

社使用実績を内責として

評価する

（注）「使用実績がある」と

いうことは、ソフトウェアも

しくは Cots の特性を把握

し、その対策は既知である

が故に、生産性が高いとい

うこと。

－ 5 － 5 聞いたこともない SW


349


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

コミュニ

ケーショ

ン特性

顧客窓

口特性

(P04)

-10 -10 － -7 期限どおりに方針決

定して頂ける

・問い合わせに対するレス

ポンス、約束期限の遵守

度合い、方針・仕様に関す

る決定が覆る度合により

評価する

-5 -5 － -4 ほぼ期限どおりに方

針決定して頂ける

→組織としての特

性を評価するもの

であり、窓口役の

個人を評価するも

のではない。

（窓口が複数ある

と受ける側は大変

で、取りまとめ役が

いないと混乱し、

生産性は低下す

る。）

0 0 － 0 ほぼ期限どおりに方

針決定して頂ける

が、多少覆ることが

る

10 5 － 4 期限の遅延、決定

事項が覆る事が多

い

20 10 － 7 概ね期限は遅延し、

決定事項が頻繁に

覆る

工期の

厳しさ

(P05)

→「工期の厳しさ」

を以下の基準式を

標準として評価す

る

ーーーーー

基準工期（月）

＝2.7×（人月）１/３

0 0 0 0 基準工期に対し▲

5％未満

（JUAS ソフトウェア

メトリックス調査

2005 年版参考）


5％～▲10％以内

・システム規模に対する工

期の厳しさが生産性にお

よぼす影響を、外責／内

責別に評価する。

・２者間契約に適用するの

で、顧客が認識するプロジ

ェクト全体ではなく、ベンダ

ーの担当分に焦点を当て

て評価する。


10％～▲20％未満

10 10 5 7 基準工期に対し▲

20％～▲30％以内

・コミュニケーションの速度

および精度を低下させる物

理的な要因を評価する

→ 内責は開発拠

点（分散度）のみ

-10 -5 -3 -3 利用制約のない基

盤が確保され、適時

適切に意思確認で

きる。

コミュニ

ケーショ

ン基盤

(P06)

→ 基盤があって

も秩序がない場合

は評価しない

-6 -3 -1 -1 利用制約のない基

盤が確保されている

0 0 0 0 基盤は確保されて

いるが利用制約が

ある

・評価観点は以下のとおり

a.開発拠点（分散度）

b.資料･開発生産物の情

報共有の基盤

c.グループウエア・電子メ

ールによる情報共有の基

盤 6 3 1 1 指示が徹底されたこ

とを確認する仕組み

が欠けている

「秩序がない」と

は、例えばメーリン

グリストによる大量

情報の垂れ流しの

ように、決定したこ

とがきちっと伝達さ

れる仕組みが欠如

していることを指

す。

10 5 3 3 拠点が分散し、且

つ、必要な基盤が確

保されていない


350


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

レビュー

体制

(P07)

-5 -5 -3 -5 レビュー観点の整理

および事前査読に

よりレビュー時間を

短縮

-3 -3 -1 -3 事前に査読してレビ

ュー時間を短縮

0 0 0 0 適切な体制、方法で

共同レビューを実施

→体制：開発者全

員によるレビュー

実施など

対窓口レビュー

以外のレビュー参

加要請など

3 3 1 3 多段階もしくは関連

範囲外へのレビュー

参加要求

・共同レビューの目的・目

標に照らして、レビュー体

制およびレビュー方法の適

切性（効率および欠陥除去

率などの品質向上への寄

与率）を評価する

・体制：過剰なレビュー参

加者要求はコスト増加に

対して効果が少ない

・方法：多段階レビュー(担

当者間→上司→その上司

など）によるレビュー効率

低下（なかなか収斂せず、

結論が覆ることが多い）

5 5 3 5 多段階かつ関連範

囲外へのレビュー参

加要求

開発環

境特性

・開発手法・開発環境（ソフ

ト・ハード・ツール）につい

て評価する

-3 -3 -5 -5 生産性向上の工夫

が盛込まれた手法

／環境

開発手

法／開

発環境

(P08)

・評価観点は以下のとおり

(「外責」にはベンダーの習

熟度の評価は含まない）

→ 既存テスト環境

流用度合はツール

として評価する（標

準試験項目セット

有無も） -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 入出力データ実現

値および手順の記

載を要求


351


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

工程入

力情報

特性

業務関

連資料

(P10)

・既存資料についてはその

信用度（正確性、新度）

を評価する

-27 -7 -3 -3 検索しやすさを考慮

し整備されている

他シス

テム関

連資料

(P11)

並行作成するものなら

ば、上記に加え期日厳守

率をあわせて評価する

-16 -4 -1 -1 必要資料はすべて

整合性をもって整備

されている

0 0 0 0 必要資料の一部に

不整合がある

規約・標

準化関

連資料

(P12)

・他システム関連資料は当

社が I/F 設計およびテスト

設計を実施する上で必要

十分かつ正確な情報であ

るかを評価する

評価規準は以下

の事項に着目して

設定している

・資料の整理のさ

れ方

・資料の読み易さ

・情報の探し易さ

16 4 1 1 必要資料は整備さ

れているが不整合

が散見する

・規約・標準化資料は複数

存在していたり不整合がな

いか評価する

27 7 3 3 資料の不足があり

他資料からの補完

が必要

－－－－顧客の

協力特

性

役割分

担特性

(P13)

・顧客がベンダーに協力す

る度合および顧客とベンダ

ーとの役割分担の明確性

を評価する

－－－－

-10 0 － 0 顧客側に情報シス

テム担当窓口があ

り、ベンダーは情報

システム担当窓口と

交渉する

・ベンダーが直接

エンドユーザーと

交渉して開発する

場合

・エンドユーザーと

ベンダーの間に、

情報システム部が

入り、エンドユーザ

ーと交渉した上

で、ベンダーに伝

える場合とでは、

ベンダー側の生産

性は大分異なる。

0 5 － 5 エンドユーザーの代

表窓口とベンダーと

が直接交渉する

20 10 － 10 エンドユーザーの代

表窓口はなくベンダ

ーが直接交渉する

要件定義の影響度

は、以下の 3 要素

を単純に加算した

結果です。

・業務関連資料：

-10～+10

・他システム関連

資料：-10～+10

・規約・標準関連

資料：-7～+7


352


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

改造・再

構築特

性

-50 -40 -10 -40 中核メンバー全員が

母体システム経験

多数

既存シ

ステム

への練

度(P14)

・顧客／当社の改造の母

体または再構築する元の

システムに関する熟練度

が生産性に及ぼす影響

を、それぞれ（外責／内

責）個別に評価する

-20 -20 -5 -20 中核メンバーの一部

の母体システム経

験少

0 0 0 0 中核メンバーの一部

に母体システム未

経験者あり

・外責は、ユーザー部門を

含む顧客プロジェクト組織

全体の能力として

→ 外責：プロジェ

クト全体としての母

体システムへの熟

練者の比率で評価

する

40 20 5 20 中核メンバーに母体

システム経験者不

在

評価する 50 40 10 40 メンバー全員が母体

システム経験なし

－－－－

既存の

テスト環

境流用

水準

(P15)

・既存のテストドキュメント

およびテストデータ（テスト

環境を含む）の流用可能

度合をテストフェーズ別に

評価する。

－－ -20 -30 50％～70％未満が

流用できる

－－ -10 -20 20％～50％未満が

流用できる

－－ -5 -5 10％～20％未満が

流用できる

－－ 0 0 10％未満の流用に

留まる

－－－－

－ -20 -10 -20 4 個～5 個の機能を

具備した調査ツール

がある

－ -10 -5 -7 2 個～3 個の機能を

具備した調査ツール

がある

母体調

査ツー

ルの機

能水準

(P16)

－ 0 0 0 1 個の機能を具備し

た調査ツールがある

・母体の調査ツールの機

能水準の高低を評価す

る。

・該当するツールなどの機

能が以下の内容に当ては

まる個数で評価する。

a.絞り込み機能 b.モニ

タリング（ルート解析）機能

c.ドキュメント生成（リバ

ース）機能

d.実機での稼働確認

e.その他調査ツールなど

－ 15 5 10 調査ツールがない

・改造/流用母体の品質特

性から、以下の該当事象

数（a～c）により評価する

－－－－（注）各事象の影響

度により、補正する

既存母

体の品

質(P17)

a.正確性（潜在バグ数） 0 0 0 0 該当する事象がな

い

b.解析性（コメントに対す

る要求水準）

10 10 10 10 該当事象数 1

c.環境適用性（多様なハ

ード、ソフト、運用環境に適

用度）

30 30 30 30 該当事象数 2

50 50 50 50 該当事象数 3 以上


353

評価の観点外責評価基準（見積プレゼン用）

内責評価基準

（参考）

品質特

性

副品質

特性内容特記、特例事項

要

件

定

義

設

計

製

作

テ

ス

ト

設

計

製

作

テ

ス

ト

機能性合目的

性(P18)

－－

・ソフトウェアがユーザーニ

ーズを満足させるために必

要十分な機能を備えてい

ることに対する要求（要件

定義フェーズを対象とす

る）

0 既存業務で、システ

ム化の目標が定ま

っている

a.新規性(世の中にないも

のの考案) b.方針の明

確性

20 システム化の方針

が曖昧である

50 ステークフォルダが

多様かつシステム

化の方針が曖昧で

ある

c.ステークフォルダの納

得性(ROI の明示度合）

d.ステークフォルダの多

様性(バックオフィス、フロ

ントオフィス,一般ユーザー

/外部企業など) 100 上記に加えて、世の

中にないものの考

案が多い

（要求仕

様の網

羅性）

－－－－

→要求仕様書の

記述水準は標準ド

キュメント記述文

字数に対する実要

求仕様書記述文

字数で評価できる

0 － 0 必要項目・水準が網

羅された要求仕様

書が存在

網羅性、ステーク

フォルダの同意度

合を加味して評価

5 － 3 必要項目・水準のど

ちらかに多少、不備

有り

→ 未解決懸案項

目数により評価レ

ベルを調整する

15 － 6 必要項目・水準の両

方に多少、不備有り

・ソフトウェアがユーザーニ

ーズを満足させるために必

要十分な機能を備えてい

ることに対する要求（設計

～テストフェーズを対象と

する）

・ユーザーニーズの具体

性、網羅性、ステークフォ

ルダの同意度合を評価し、

要求仕様書にユーザーニ

ーズが具体的に記載され

ていない場合は、以降の

工程でニーズの具体化・検

証作業が必要になる → ユーザーヒアリ

ング実施、プロトタ

イピング実施など

30 － 10 要求仕様書が不存

在(代替:口頭説明,

代替資料)

正確性

(P19)

－－－－－

0 0 0 0 標準的なレビューに

より確認・検証可能

2 2 1 2 標準に対し 1.5 倍の

レビュー工数を要す

3 3 2 3 標準に対し 2.0 倍の

レビュー工数を要す

・実現されている機能が正

常に動作することに対する

要求

・前工程の機能が当該工

程で正しく実現されている

こと、生産物間および機能

間に矛盾がないことを確

認・検証する度合を評価す

る

・具体的にはレビュー充実

度で評価するが、上位工

程においては生産物作成

過程における確認・検証作

業も考慮する

→ レビュー工数

の標準は各工程

の全体工数の

10％程度とする 5 5 3 5 標準に対し 3.0 倍以

上のレビュー工数を

要す


354


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

接続性

(P20)

→インターフェイス

数の増加は規模

の環境変数で評価

-10 -5 － -5 社内のインターフェ

イスのみでインター

フェイス先が 1 件

/100KS 以内

5 -3 － -3 社内のインターフェ

イスのみでインター

フェイス先が 3 件

/100KS 以内

・ソフトウェアが他ソフトウ

ェアや他システムと容易に

接続・運用できることに対

する要求で、データの共通

化や通信手段・インターフ

ェイスの共通化検討が必

要になり、社外と接続する

か否かも影響する

→インターフェイス

数は共通化により

抑えることができる

が、接続先が多い

と調整負荷が増加

する 0 0 － 0 社外とのインターフ

ェイスを含みインタ

ーフェイス先が 3 件

/100Ks 以内

・上記を考慮して設計すべ

きインターフェイス先の数

で評価する

→留意事項：保有

システム規模が大

きい程、インタ

5 3 － 3 社外とのインターフ

ェイスを含みインタ


/100Ks 以内

設計の難易度とインター

フェイステストの複雑さに

影響する

フェース先の数も

増加する傾向にあ

る

10 5 － 5 社外とのインターフ

ェイスがありインタ


/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 既知の適事例の

1.2 倍の速さを要求


1.5 倍の速さを要求

・要求が高ければ設計工

程における実現可能性検

証やテスト工程における障

害解析・対応作業の難易

度が高まる

→ 机上検証、ベ

ンチマークテスト、

パイロット開発など


2.0 倍以上の速さを

要求


355


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

－－－－－

資源効

率性

(P23)

・定められた条件下で所定

の処理を実行する際、資

源を有効に使用することに

対する要求

0 0 0 0 一般的要求水準で

既知の事例にて実

現が可能


1.2 倍の有効性を要

求

・具体的には、プログラム

の実行に必要な資源の

量、ハードウェア資源の使

用の有効性に対する要求

→ CPU 使用率、

主記憶使用量、フ

ァイル使用量、ネッ

トワーク使用量に

対する要求 3 6 3 6 既知の適事例の

1.5 倍の有効性を要

求

→ 実現方式の検

討要否および事例

有無により評価


2.0 倍以上の有効性

を要求

保守性－－－－－

解析性

P24)

・故障または運用上の不

都合が発見された場合、ど

の程度労力をかけることな

く原因の解析ができるかに

対する要求

→ ソースコードの

コード化規約に着

目して、コメントに

対する要求水準に

より評価する

－－ 0 －機能概要を記述す

るヘッダコメントを付

加

－－ 2 －上記に加え、50 行

程度毎にブロックコ

メントを付加

・解析用機能は規模環境

変数として定義し、生産性

環境変数としてはソースの

解析性向上のための作業

（リバースエンジニアリング

用情報付加等）を対象

→ 旧コメント率、

JavaDoc 用コメント

などに対応し名

称を変更－－ 3 －上記に加え、20 行

程度毎にブロックコ

メントを付加

－－ 5 －ﾘﾊﾞｰｽﾂｰﾙで仕様を

作成できる程度のコ

メントを付加

(コードを読めない人

でも処理内容を理解

できる）

変更容

易性

入出力（画面、嘲笑）、

DB、設計書、プログラムが

変更容易に出来ている度

合

開発体制と保守体

制との連携度合で

評価する

－－－－－

－－－－－

・当該要求を実現するため

に、上流工程においてデー

タ正規化やオブジェクト指

向などの設計手法を取り

入れることが必要となる場

合もある

－ 0 0 0 開発者が保守を継

続して行う体制を前

提とした作り

－ 5 3 5 開発者が保守に支

援できる体制を前提

とした作り

－ 10 10 10 開発者が保守に支

援できない体制を前

提とした作り


356


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

安定性

(P25)

→将来変更が発

生する確率が高い

と想定される場合

－－ 0 －機能概要を記述す

るヘッダコメントを付

加

ー -3 -3 - システムのライフサ

イクル目標は 2 年未

満

・ソフトウェアに変更を施し

た場合、システム全体の品

質がレベルダウンしないこ

とに対する要求拡張性（10

年使えるシステム等）も本

副品質特性で評価する

0 0 0 - システムのライフサ


満



満


イクル目標は 7 年～

10 年

5 7 5 システムのライフサ

イクル目標は 10 年

超

移植性 → 要求の数（種

類）で評価する

－－－－－

環境適

用性

(P26)

・多様なハード、ソフト、運

用環境に適用させる要求

の水準

0 0 0 0 移植要求なし

2 2 1 2 移植要求が 1 種類

4 4 2 3 移植要求が 2～3 種

類

7 7 3 5 移植要求が４種類

以上

→ 要求の数（種


－－－－－

移植作

業性

(P27)

・環境を移す際に、必要な

労力を低減させる要求の

水準


→ インフラ変更に

対する対応容易性

など

2 2 1 2 移植要求が 1 種類

4 4 2 3 移植要求が 2～3 種

類

7 7 3 5 移植要求が 4 種類

以上



－－－－－

規格準

拠性

(P28)

・移植性に関する国際／国

内規格または規約を遵守

する要求の水準


2 2 1 2 移植要求が 1 種類

4 4 2 3 移植要求が 2～3 種

類

7 7 3 5 移植要求が 4 種類

以上


357


（参考）

影響度（％）

影響度

生産性

特性

副生産

性特性内容


設

計

製

作

テスト

設計

製作

テスト

置換性

(P29)



－－－－－

・使用環境／条件を変更

せずに他のソフトウェア製

品と置き換えて使用可能と

する要求の水準


2 2 1 2 移植要求が 1 種類

4 4 2 3 移植要求が 2～3 種

類

7 7 3 5 移植要求が 4 種類

以上

Patent Pending By JASTEC

(注 1）移行、教育、保守、運用作業は、生産性環境変数の適用対象から除いている。

(注 2）内責評価基準はベンダー内部事情で発生する環境変数ゆえ、今回は除いている。

(注 3）評価基準の影響度は実運用上、工程毎のアクティビティ（作業）単位に影響度を設定している。今回、工

程は要件定義、設計、製作、テストと簡略化し、アクティビティも省略している。

図表 3-4-31 生産性環境変数（改造型固有）

評価の観点外責評価基準（見積プレゼン用）内責評価基

準（参考）

影響度（％）影響度

生産性

特性

副生産

性特性内容

特記、特例事項

要

件

定

義

設

計

製

作

テ

ス

ト

設

計

製

作

テ

ス

ト

改造・再

構築特

性

既存シ

ステム

への錬

度(P14)

改造型見積モデルに組込み環

境変数対象外とした母体の調

査ツールの機能水準の高低を

評価する。

－－－－

母体調

査ツー

ルの機

能水準

(P16)

・該当するツールなどの機能が

以下の内容に当てはまる個数

で評価する

－ -20 -10 -20 4 個～5 個の機能

を具備した調査

ツールがある

a.絞込み機能 b.モニタリング

（ルート解析）機能

－ -10 -5 -7 2 個～3 個の機能

を具備した調査

ツールがある

c.ドキュメント生成（リバース）

機能

－ 0 0 0 1 個の機能を具

備した調査ツー

ルがある

d.実機での稼動確認 e.デー

タディクショナリー機能（データ

定義統一）

f．その他調査ツールなど

－ 15 5 10 調査ツールがな

い

既存設

計書具

備状態

－－－－

・改造/流用母体の設計書有

無および設計書が存在した場

合のメンテナンス状態が、改造

作業（All）に及ぼす影響を評価

する 0 0 0 0 完全にメンテナン

スされた設計書

が存在する

3 10 10 5 メンテナンス履歴

が存在する


358


準（参考）


生産性

特性

副生産

性特性内容


要

件

定

義

設

計

製

作

テ

ス

ト

設

計

製

作

テ

ス

ト

5 20 20 15 初期設計書のみ

存在し、メンテナ

ンス個所が不明

10 30 30 25 既存設計書が存

在しない

－－－－

既存の

テスト環

境流用

水準

(P15)

・既存のテストドキュメントおよ

びテストデータ（テスト環境を含

む）の流用可能度合をテストフ

ェーズ別に評価する。

法規制（個人情報保護

等）で本番データのテスト

流用制限により手間が掛

かる、および既存データ

の残存バグ率を考慮す

る。

－－ -20 -30 50％～70％未満

が流用できる

流用率＝生流用率×

データ加工率×データ残

存バグ率

－－ -10 -20 20％～50％未満

が流用できる

－－ -5 -5 10％～20％未満

が流用できる

－－ 0 0 10％未満の流用

に留まる

ソースとロードモジュールとの

不整合

－－－－

構成管

理の不

備度合

構成管理プロセスの具備

度合（CMMI の PA’構成

管理’レベルで評価）

－－ -5 -5 CL4 以上

－－ 0 0 CL3

－－ 5 5 CL2

－－ 10 10 CL1

・既存システムが正しく動作し

ない場合の生産性に及ぼす影

響を評価する

－－－－

既存母

体品質

（正確

性）

・既存母体調査の精度および

テスト作業における障害解析

生産性が低下する

⇒ 直前１年間のバグ件

数により評価し、残バグ

率に応じて影響度を評価

する 0 0 0 0 改造/流用母体

の残バグ≒0 件

/100KS

既存データの残存バグ

率を考慮する

2 4 4 4 改造/流用母体


/100KS

5 8 8 8 改造/流用母体


/100KS

8 10 10 10 改造/流用母体


/100KS

－－－－

既存母

体品質

（解析

性）

・既存システムの改造個所特

定（改造設計）におけるソース

コードの解析容易性を

評価する

0 0 0 0 すべて遵守され

ている

・下記標準化項目の遵守度合

いで評価する

3 10 10 5 遵守項目が３項

目

a.ソースコメント b.修正履歴

c.モジュールサイズ d.その他

規約

5 15 15 10 遵守項目が２項

目

10 25 25 15 遵守項目が１項

目以下

既存母

体品質

（環境適

用性）

・現行システム資産を別環境

への移植し改造する開発にお

ける、別環境への

⇒ 同一環境で改造する

開発においては評価対

象外

－－－－


359


準（参考）


生産性

特性

副生産

性特性内容


要

件

定

義

設

計

製

作

テ

ス

ト

設

計

製

作

テ

ス

ト

適用容易性を評価する 0 0 0 0 適用用意項目が

６項目

・適用容易な環境の個数により

評価する。

3 10 10 5 適用用意項目が

４～５項目

a.ハードウェア b.OS c.フレ

ームワーク（ミドル） d.DB/DC

5 15 15 10 適用用意項目が

２～３項目

e.バッチ運用システム f.その

他の環境

10 25 25 15 適用用意項目が

１項目以下

ジャステック（2006 年度版）

図表 3-4-32 規模環境変数（改造型固有）


準（参考）



品質特

性

副品質

特性内容

要

件

定

義

設

計

製

作

テ

ス

ト

設

計

製

作

テ

ス

ト

機能性（既存母

体の）正

確性

－－－－

・改造/流用母体が正しく動作し

ない場合のテスト量（現行保証）

に及ぼす影響を評価する

⇒ 直前１年間のバグ

件数により評価し、残

バグ率に応じてテス

ト量を増加させ品質向

上を行う

－ 0 0 0 改造/流用母体の

残バグ≒0 件

/100KS

－ 0 5 5 改造/流用母体の

残バグ≒3 件

/100KS

－ 3 10 15 改造/流用母体の

残バグ≒8 件

/100KS

－ 5 15 25 改造/流用母体の

残バグ≒15 件

/100KS

ジャステック（2006 年度版）


360

361

第４章システムの信頼性確保

第１節システム監査

第２節事業継続計画（BCP）

363

第４章システムの信頼性確保第１節システム監査

システム監査の実施状況をアンケート調査から概観し、その中で明らかになってきた課題（シ

ステム監査へのコンセンサス・組織風土、担当者の確保、システム監査の制度・方法・手続き)

について考察し、｢付加価値の高いシステム監査｣について考察する。

１．システム監査の実施状況とその課題

２．システム監査とその位置づけ

３．システム監査の課題と対応

４．付加価値の高いシステム監査の実現に向けて（留意点）

４－１システム監査

364

１．システム監査の実施状況とその課題

（１）実施状況

システム監査の実施状況に関し、JIPDEC（Japan Information Processing Development Corporation：財団法人日本情報処理開発協会、以下「JIPDEC」と表記）の平成 16 年度調査に

よれば、調査対象企業 421 社のうち約半数の企業が、何らかのシステム監査を実施している。

JIPDEC が調査を開始した平成 2 年度の実施状況と比べると、約 2 倍の実施率となっている。な

お、調査対象企業に金融機関の多い FISC（The Center for Financial Industry Information Systems：財団法人金融情報システムセンター、以下「FISC」と表記）の平成 16 年度調査では、

半数以上の企業が何らかのシステム監査を実施している（図表 4-1-1 参照）。

図表 4-1-1 システム監査の実施状況に関する調査結果

平成 16 年度

JIPDEC 調査1

平成 16 年度

FISC 調査2

（参考）平成 2 年度

JIPDEC 調査

システム監査を

実施した

46.3%

（195 社）

54.4%

（259 社）

24.3%

システム監査を

実施していない

53.7%

（226 社）

45.2%

（217 社）

（無回答 0.4%）

22.2%

金融機関のシステム監査実施率が高いことは、平成 16 年度 JIPDEC 調査（平成 16 年度 FISC

調査とは対象企業が異なる）でも明らかである。業態別実施率は、高い順に金融業、情報処理サ

ービス業、電気機械器具製造業となっている（図表 4-1-2 参照）。

図表 4-1-2 業態別のシステム監査実施状況

（平成 16 年度 JIPDEC 調査）

業態システム監査実施率

金融業 79.3%

情報処理サービス業 59.1%

電気機械器具製造業 57.1%

1 JIPDEC「（平成 16 年度版）わが国におけるシステム監査の現状─システム監査普及状況調査─」（財団法人日本情報処

理開発協会、2005 年 3 月）より

母集団 40 業種、4000 事業体に対するアンケート

回収数 421 件、回答事業体の平均従業員数 2,751 人 2 「金融機関などにおけるシステム監査の実施調査」（財団法人金融情報システムセンター、2005 年 2 月）


365

また、実施した企業の約 8 割が、システム監査を受けた効果があったとしている（図表 4-1-3

参照）。図表 4-1-3 システム監査を受けた結果について


効果があったと思う 73.4%

どんな点に効果があったと思うか

セキュリティ対策の向上 38.3%

リスク対策をどこまで行えばよいかが明らかになった点 25.5%

規則と手続きなどの遵守 14.1%

本節では、後述の「2．システム監査とその位置づけ」で、システム監査の経営上の必要性・

重要性について確認する。（２）実施状況からみたシステム監査の課題

システム監査を実施していない企業も約半数存在している。主な理由は次のとおり（図表 4-1-4参照）。

図表 4-1-4 システム監査を実施していない理由


理由割合

実施する担当者（部門）の確保が難しい 22.1%

実施のためのコンセンサス・組織風土などが十分でない 18.6%

方法・制度・手続きなどがわからない 16.4%

本節では、これらの課題に対し、解決方法、指針あるいは参考資料を取り上げ、解説する。

・実施する担当者（部門）の確保・・・・・本節第３項の「（２）システム監査人の資格と育成」・実施のためのコンセンサス・組織風土・本項の「２．システム監査とその位置づけ」・方法・制度・手続き・・・・・・・・・本節第３項の「（３）システム監査の手順」


366

２．システム監査とその位置づけ

本項では、システム監査の概要とその位置づけ（経営上の位置づけ、監査における位置づけ、

認証制度との関連など）を明らかにし、その必要性・重要性について確認する。（１）システム監査の概要とその重要性

ａ．システム監査とは

JIPDEC 調査によれば、「システム監査」の概要については、約 4 割が「理解している」とい

うレベルであり、新システム監査基準とその考え方の正しい理解が望まれる。なお、「システム監

査」と「システムの監査」があり、厳密には区別して考えるべきであろう。以降は「システム監

査」を中心に考えることとする。3 「システム監査」とは、新システム監査基準4の目的から「組織体の情報システムにまつわるリ

スクに対するコントロールがリスクアセスメントに基づいて適切に整備・運用されているかを、

独立かつ専門的な立場のシステム監査人が検証又は評価することによって、保証を与えあるいは

助言を行う活動」であると言える。（参考：新システム監査基準前文）

「組織体が情報システムにまつわるリスクに対するコントロールを適切に整備・運用する目的は、

以下のとおりである。・情報システムが、組織体の経営方針及び戦略目標の実現に貢献するため・情報システムが、組織体の目的を実現するように、安全、有効かつ効率的に機能するため・情報システムが、内部または外部に報告する情報の信頼性を保つように機能するため・情報システムが、関連法令、契約又は内部規定等に準拠するようにするため」

これらの考え方は、米国トレッドウェイ委員会組織委員会（The Committee of Sponsoring

Organization of the Treadway Commission：COSO）の内部統制の定義を踏まえながら、情報

システムの信頼性、安全性、効率性の向上という考え方を発展させたものと言える。また、旧シ

ステム監査基準（1985 年 1 月）の「情報システムを総合的に点検・評価する」ことから、「情報

システムにまつわるリスクに対するコントロールがリスクアセスメントに基づいて適切に整備・

運用されているかを、検証又は評価する」となっており、「IT ガバナンス」の実現に寄与すると

の考え方を示すものとなっている。なお、FISC の「金融機関などのシステム監査指針」（2000 年 7 月）では、「金融機関等のシス

テム監査は、情報システムの有効性、信頼性、遵守性、及び安全性の達成を妨げようとする情報

システムリスクの管理体制が適切かつ効果的であるかを、監査対象から組織的に独立したシステ

ム監査人が把握、評価し、その結果を経営者に報告するものである。」としており、新システム監

査基準の考え方に先立ってその考え方を早くから、取り入れた基準と言える。

3 「システムの監査」とは、「システム」を任意に監査することを指す。それに対し、「システム監査」とは、「システム

監査基準」で規定している原則に則り、その監査項目を明確にし、決められた監査手順に従って行うことを指す。

4 参考文献① 2004.10.8


367

また、新システム監査基準は、「システム監査基準」と「システム管理基準」の二本立てになっ

ており、従来のシステム監査基準の実施基準にかかわるリスクコントロールは組織体にあり、シ

ステム監査人は、組織体が管理基準に従って管理を実施しているかを監査することが明確になっ

ている。ｂ．システム監査と情報セキュリティ監査

システム監査と情報セキュリティ監査との位置づけ、関連をまとめると、下記のとおりであり、

両監査基準（経済産業省が策定し公表）の違いと補完する面があることの理解が必要である。

図表 4-1-5 情報セキュリティ監査制度との比較

システム監査制度情報セキュリティ監査制度

制度の目的企画・開発・運用・保守という情報システ

ムのライフサイクルに従って、特に情報シ

ステム構築・運用の全体最適化を目的と

した監査制度

情報資産のライフサイクルに従って、情報

システム以外の部分も対象として情報セ

キュリティ確保のための管理・運用を有効

に行うことを目的とした監査制度

監査および

報告書の位置づけ

被監査組織に対する助言被監査組織に対する助言

および利害関係者等に対する保証

基準および

ガイドライン

・システム監査基準

一般基準

実施基準

報告基準

・システム管理基準

・情報セキュリティ監査基準

・情報セキュリティ監査基準実施基準ガイ

ドライン

・情報セキュリティ監査基準報告基準ガイ

ドライン

・情報セキュリティ管理基準

・個別管理基準策定ガイドライン

両制度の関連システム監査において情報セキュリティ確

保の観点からの監査項目を加えて行う場

合は、・情報セキュリティ管理基準を活用

して、実施する。

情報セキュリティ管理基準の中にシステ

ム監査基準を参照することはない。

台帳制度

・システム監査企業台帳情報セキュリティ監査企業台帳

企業台帳登録時の

記入可能資格

・システム監査技術者・システム監査技術者

・CISA（公認情報システム監査人）

・公認システム監査人

・セキュリティアドミニストレータ

・ISMS 主任審査員


368

（経済産業省システム監査基準の前文より）

図表 4-1-6 システム監査と情報セキュリティ監査との関連

ｃ．システム監査の重要性

以下のような点で、システム監査の重要性が、ますます高まっている。 ①増大するシステム化投資が組織体の情報戦略の効果を発揮しているか、また競争優位を発揮

するうえで貢献しているか否かの評価が必要とされている。 ②ネットワーク化の進展のなかで、企業のネットワークシステムが社会のインフラとなってお

り、その可用性の確保が重要となってきているシステムが多くなっている（2005 年 12 月の

東証での売買停止事件など、耳目に新しい）。 ③ネットワーク化の進展のなかで、情報セキュリティ対策が緊急な課題となっており、システ

ム監査がネットワーク社会における組織体の信用に係わる基盤の担保として重要になってい

る（金融機関を狙った偽造・盗難キャッシュカードに関する犯罪など）。 ④企業における経営戦略を実現するための組織体の重要なインフラとして、情報システムの監

査が、情報システムリスクを経営リスクとして捉え、内部監査の一環として実施することが、

ますます重要となっている。


369

ｄ．システム監査に関する調査結果

システム監査に関する調査結果は、次のとおり。

図表 4-1-7 システム監査に関する調査結果

（JIPDEC 調査 2005 年 3 月に基づき編集）

利用したことが

ある

知っている

（利用したこと

があるを含む）

知らない

システム監査基準（2004 年 10 月） 6.9% 61.1% 38.2%

システム管理基準（2004 年 10 月） 7.4% 63.5% 35.6%

情報セキュリティ監査基準（2003 年 4 月） 15.4% 75.7% 22.3%

情報セキュリティ管理基準（2003 年 4 月） 15.0% 71.0% 27.8%

（２）システム監査とその視点

ａ．システム監査の判断の尺度（コントロール項目）

新システム監査基準では、情報システム部門及びその関連部門が自らの組織の情報システムの

管理を行うための構造的な実践規範として、「システム管理基準」（287 項目）を定めている。シ

ステム監査は、この管理基準を尺度とて、その遵守状況について監査することになる。

・情報戦略に係わる管理 47 項目全体最適化組織体制情報化投資情報資産管

理の方針事業継続計画コンプライアンス

・企画業務に係わる管理 23 項目開発計画分析調達

・開発業務に係わる管理 49 項目開発手順システム設計プログラム設計プログラ

ミングシステムテスト・ユーザー受け入れテスト移

行

・運用業務に係わる管理 73 項目運用管理ルール運用管理入力管理データ管理

出力管理ソフトウェア管理ハードウェア管理ネッ

トワーク管理構成管理建物・関連設備管理

・保守業務に係わる管理 19 項目保守手順保守計画保守の実施保守の確認移

行情報システムの廃棄

・共通業務に係わる管理 76 項目ドキュメント管理進捗管理品質管理人的資源管

理委託・受託変更管理災害対策

なお、情報セキュリティに関する詳細な監査を実施するときは、情報セキュリティ管理基準の

活用を推奨している。

./keyword.htm#3504


370

ｂ．システム監査の際の着眼点

システム監査の際に何に着眼して監査するかは、システム監査を行う上で極めて大切である。

① 情報システムの有効性情報システムが提供する情報や業務処理機能が、企業の

経営方針や戦略の策定・実現に対して効果的であること。

② 情報システムの効率性情報システムが提供する情報や業務処理機能の生産性・

経済性が高いこと。

③ 情報システムの信頼性情報システムが提供する情報や業務処理機能が、確実に

信頼できること

④ 情報システムの遵守性情報システムや情報処理プロセスが、法令・規制や当該企

業の方針・手続きなどを遵守していること。また情報処理プ

ロセスに、これらの規制情報が組み込まれていること。

⑤ 情報システムのセキュリティ下記の 3 点が確実に維持されていること。

・情報システムの機密性情報システムにアクセスを許可されたものだけがアクセス

できること。

・情報システムの完全性情報及び処理方法が正確であること及び完全であること。

・情報システムの可用性認可された利用者が、必要なときに、情報及び関連する資

産にアクセスできること。

（３）システム監査の位置づけ

組織体にとって、いくつかの「監査」がある。それら「監査」とシステム監査との関連及びそ

の中でのシステム監査の位置づけの正しい理解が必要である。ａ．会計監査との関係

会計監査の一環としてのシステム監査がある。この場合、一般的には、「システム監査」もあれ

ば「システムの監査」もある。会計監査の一環であるから、システム監査人は、建前としては会

計士の指揮下にあり、システム監査報告書の提出先は会計士になる（システム監査基準では、提

出先を「監査の依頼者」としている）。なお、実態としては監査人が、システム監査の資格、力量

を持っている場合も、「システムの監査」になることが多い。ｂ．「IT を利用した内部統制の監査」としてのシステム監査

2005 年 12 月に金融庁は、財務報告を作成する情報システムの信頼性を証明するため企業の ITの内部統制についての記録を保管するよう求めた「財務報告に係わる内部統制の評価及び監査の

基準のあり方について」（いわゆる「J-SOX」）を発表した。具体的に J-SOX に従い、財務報告の信頼性を確保する場合、企業は業務プロセスの文書化、シ

ステムの仕様書保管、ログなどを保存する必要が生じよう。こうした内部統制の新たな構築とそ

れを自ら評価し、報告する「内部統制報告書」を経営者は作成し、外部に報告する。監査人は、

この「内部統制報告書」について、意見を表明し「内部統制監査報告書」として、報告すること

になる。この対象となる企業は、当面公開企業などに限定されるが、「IT を利用した内部統制の

監査」としてのシステム監査が要請されることとなる。こうした状況を踏まえ、金融機関のシステム監査指針が 2007 年 3 月に改定されるとの報道が


371

ある（「日経コンピュータ 2006 年 8 月 7 日号 17 ページ」）。同記事によれば、改定を進めている

金融情報システムセンター（FISC）は、2007 年 3 月末までに作業を終える計画で、「金融機関等

のシステム監査指針（FISC 指針）」の改定に 7 月 25 日着手した。改定は、「金融商品取引法（い

わゆる「J-SOX」）や個人情報保護法といった法律・制度変更への対応」であり、最近の法規制で

使われている用語との整合性と内部監査の重要性を宣言するとともに、金融庁が作成中の J-SOX法の指針に当たる「実施基準」を踏まえたチェックポイントを盛り込む。さらに、「システム統合

に伴う障害の発生や、偽造キャッシュカードなどの新しい犯罪を考慮した事件・事故への対応」

「勘定系システムのオープン化や、開発・運用のアウトソーシングなどをうけた技術・社会情勢

への対応」についてもその監査チェックポイントを盛り込みたいとしている。このように IT 統制に関する社会的な要請の高まりを受けて、システム監査はより一層その重

要性を増してきている。ｃ．認証制度における監査との関連 ①ISMS の監査

ISMS の要求事項（6-4 マネジメントレビューの中の内部監査）として、システム監査の実施

が求められている。この場合のシステム監査は、「システムの監査」までも含んだものと考えられ

る。

②JIS Q 15001（プライバシーマーク制度）の監査コンプライアンス・プログラムの 4.5 監査として、監査が求められている。なお、この場合の

監査は「システムの監査」を含む「内部監査」と言える。（４）システム監査の法的規制

システム監査そのものを規定する法令はない。経済産業省の定めた「システム監査基準」、「シ

ステム管理基準」（いずれも 2004 年 10 月）、「情報セキュリティ監査基準」、「情報セキュリティ

管理基準」（いずれも 2003 年 10 月）が準拠すべき基準である。これらの基準は、下記の法令な

どを踏まえた基準となっている（詳細はこの節の末尾の｢システム監査に関する法令等｣を参照）。 ①国の基本的指針（1） ②電子商取引関係（8） ③行政の情報化関連（7） ④通信・ネットワークの安全性・信頼性関係（1） ⑤個人情報保護法関連（11） ⑥監査関係（3） ⑦共通・その他（24）


372

（５）システム監査と関連する諸施策・制度

システム監査についてのコンセンサス・組織風土の醸成のため、システム監査と関連する諸施

策・制度について俯瞰する。ａ．システム監査制度 ①監査基準

システム監査基準、システム管理基準（いずれも 2004 年 10 月）を監査基準とする。

②金融機関などのシステム監査指針（FISC 基準）（既述。この項の（１）の「ａ．システム監査とは」参照）

③システム監査企業台帳制度 1991 年に通商産業省が告示した制度。システム監査企業を登録し、Web で閲覧でき、システ

ム監査人のいない企業への利便提供を図った制度である。（http://www.jipdec.jp/security/daicho/h17daicho）

④システム監査技術者試験制度情報処理技術者の認定制度の一環として、独立行政法人情報処理推進機構（IPA）の情報処理

技術者試験センター（JITEC）が実施している資格認定制度（詳細は後述の第 3 項（２）の「④

システム監査人に関連する代表的な資格」参照）。 ⑤公認システム監査人制度

1999 年の通商産業省の提言を受けて、知識に加えて、実務経験のあるシステム監査人を認定す

る資格制度で、特定非営利活動法人日本システム監査人協会が 2002 年に創設した制度（（詳細は

後述の第 3 項（２）の「④システム監査人に関連する代表的な資格」参照）。ｂ．情報セキュリティ監査制度 ①監査基準

情報セキュリティ監査基準、情報セキュリティ管理基準（いずれも 2003 年 10 月）を監査基準

とする。

②情報セキュリティ監査企業台帳 2003 年に経済産業省が告示した制度。情報セキュリティ監査企業を登録し、Web で閲覧でき、

情報セキュリティ監査人のいない企業への利便提供を図った制度である。（http://www.meti.go.jp/policy/netsecurity/is-kansa/）


373

③公認セキュリティ監査人資格制度

2005 年に経済産業省の「情報セキュリティ監査制度」の一環として、日本セキュリティ監査協

会が公認セキュリティ監査人を認定する資格制度。

④地方公共団体情報セキュリティ監査ガイドライン 2003 年 12 月に総務省が告示した地方公共団体における情報セキュリティ監査に関するガイド

ラインで、「地方公共団体情報セキュリティ監査管理基準」「地方公共団体情報セキュリティ監査

手順」の総称である。このガイドラインの一環とて、地方公共団体の職員がチェックに使える「セ

ルフチェックリスト」も公表されている。ｃ．個人情報の保護制度 ①個人情報保護法

2005 年 4 月に全面施行された「個人情報の保護に関する法律」。

②個人情報保護ガイドライン経済産業省が 2004 年 6 月に公表した「個人情報の保護に関する法律についての経済産業分野

を対照とするガイドライン」などであり、各所管省庁や各業界団体で、業界特性にあわせた個別

のガイドラインが公表されている。2006 年 6 月 30 日現在、21 分野に関して 33 のガイドライン

が公表されている。

③プライバシーマーク制度 1998 年に日本情報処理開発協会（JIPDEC）が創設し運用を開始した制度。JIS Q 15001 が基

準となっている。ｄ．ISMS 適合性評価制度

経済産業省が 2002 年に「情報セキュリティ管理に関する国際的なスタンダードの導入および

情報処理サービス業情報システム安全対策実施事業所認定制度の改革」として公表した制度で、

従来の「情報システム安全対策実施事業所認定制度」（2001 年 3 月 31 日廃止）に変わる制度。

英国の情報セキュリティ認証制度である BS7799 を基に創設した制度。2002 年 4 月から JIPDECが本格運用している。なお、2006 年 5 月から、順次 ISO27000 に移行していくことが公表され

ている。


374

ｅ．システム監査関連団体 ①情報システムコントロール協会（ISACA）

1969 年に設立された国際的な団体。米国本部を中心に 60 か国以上に支部があり、2000 年 7月に COBIT（IT と関連技術に関するコントロール目標）第 3 版を提唱。（http://www.isaca.gr.jp/）

②日本内部監査人協会（IIA） 1941 年に設立された国際的な団体。米国本部を中心に 85 か国以上に支部又は協会があり、内

部監査の理論・実務に関する研究や情報交換を行っている。（http://www.iiajapan.com/）

③システム監査学会（JSSA）

1987 年に設立された学術団体。システム監査に関する研究交流を促進し学術的な研究・調査を

行っている。（http://www.sysaudit.gr.jp/）

④日本セキュリティ・マネジメント学会（JSSM） 1986 年に設立された学術団体。情報セキュリティ全般に関する学術的・学際的な調査研究を行

っている。（http://www.jssm.net/）

⑤日本システム監査人協会（SAAJ） 1987 年に設立され、2002 年に特定非営利活動法人となった団体。システム監査の啓蒙・普及、

システム監査人の育成・研鑽を行っている。（http://www.saaj.or.jp/）

⑥システム監査普及連絡協議会 1987 年に設立された団体。金融機関などにおける適切なシステム監査の普及を目指して活動し

て、事務局を FISC 内に置いている。（http://www.fisc.or.jp/sysaud/）

⑦日本セキュリティ監査協会（JASA） 2003 年に設立された特定非営利活動法人。情報セキュリティ監査の監査技術の向上、監査主体

の質の向上のほか、各種団体との連携、監査制度の国際標準の調査研究や改善提言などを行って

いる。（http://www.jasa.jp/）

./keyword.htm#0301


375

⑧日本情報処理開発協会（JIPDEC） 1967 年設立の財団法人。ISMS の認証、プライバシーマークの認証団体であり、情報化環境整

備の促進、情報化信頼性確保の促進、電子商取引の推進、情報技術開発促進、データベースの開

発振興、情報化人材の育成などを行っている。（http://www.jipdec.jp/）

⑨情報処理推進機構セキュリティセンター（IPA/ISEC） 1997 年に機構改革で、情報処理推進機構（1990 年設立）から分離された団体。セキュリティ

施策を一元的に展開する体制として、情報セキュリティ対策の必要性・重要性についての認識を

啓発・向上し、具体的な対策実践情報・手段を提供している。（http://www.ipa.go.jp/security/）


376

３．システム監査の課題と対応

（１）システム監査で「何を」監査するのか（システム監査テーマ）

ａ．企業のシステム監査テーマ JIPDEC 調査によれば、企業のシステム監査テーマは下記の順に多い。いずれのテーマも半数以上の企業がテーマとして、取り上げている。・セキュリティ対策·························安全性、機密性に着眼した監査・コンピュータウイルス対策·············安全性に着眼した監査・ネットワーク管理·························安全性、信頼性に着眼した監査・個人情報保護対策·························機密性に着眼した監査・情報システム関連のリスク管理·······安全性、信頼性に着眼した監査・災害対策·····································安全性に着眼した監査・PC・モバイル機器管理 ·················安全性、機密性に着眼した監査・外部委託（アウトソーシング）·······機密性、信頼性、安全性に着眼した監査・外部委託（開発の委託）················信頼性、機密性に着眼した監査・品質管理·····································信頼性に着眼した監査

図表 4-1-8 システム監査テーマについての調査結果（実施テーマ）


件数全件数に対する割合（％）

回答件数 171 -

ドキュメント管理 100 58.5

進捗管理 79 46.2

品質管理 88 51.5

コスト管理 67 39.2

要員管理 67 39.2

外部委託（開発の委託） 89 52

外部委託（アウトソーシング） 91 53.2

セキュリティ対策 144 84.2

ネットワーク管理 100 58.5

ソフトウェアの適正利用（ライセンス管理） 80 46.8

個人情報保護対策 99 57.9

PC管理、モバイル機器管理 94 55

コンピュータウィルス対策 106 62

情報システム関連のリスク管理 99 57.9

災害対策 99 57.9

無回答 7 4.1 （※複数回答）


377

ｂ．システム監査テーマの動向

システム監査テーマとして、「安全性」に着目したテーマが多い。テーマにより、機密性に着目

したテーマ、信頼性に着目したテーマもあることがわかる。「有効性」「効率性」「遵守性」に着目

したに着目したテーマの取り上げが、半数以上の企業でなかったことは、その監査の難しさとも

関連すると思われるが、注目したい。

図表 4-1-9 システム監査テーマについての調査結果（着眼点）


着眼点

テーマ安全性信頼性機密性準拠性採算性生産性適時性効率性有効性無回答

複数回

答計

5 25 12 38 1 1 1 5 9 1 2 100

5.0 25.0 12.0 38.0 1.0 1.0 1.0 5.0 9.0 1.0 2.0 100.0

2 10 0 7 0 21 9 13 14 2 1 79

2.5 12.7 0.0 8.9 0.0 26.6 11.4 16.5 17.7 2.5 1.3 100.0

11 55 0 7 1 0 2 0 10 1 1 88

12.5 62.5 0.0 8.0 1.1 0.0 2.3 0.0 11.4 1.1 1.1 100.0

0 2 0 2 33 0 6 12 10 1 1 67

0.0 3.0 0.0 3.0 49.3 0.0 9.0 17.9 14.9 1.5 1.5 100.0

6 11 4 2 4 4 14 10 11 1 0 67

9.0 16.4 6.0 3.0 6.0 6.0 20.9 14.9 16.4 1.5 0.0 100.0

8 32 24 5 5 2 2 7 1 2 1 89

9.0 36.0 27.0 5.6 5.6 2.2 2.2 7.9 1.1 2.2 1.1 100.0

21 22 26 6 5 0 1 4 1 2 3 91

23.1 24.2 28.6 6.6 5.5 0.0 1.1 4.4 1.1 2.2 3.3 100.0

56 15 51 3 0 0 0 1 10 1 7 144

38.9 10.4 35.4 2.1 0.0 0.0 0.0 0.7 6.9 0.7 4.9 100.0

39 28 20 1 0 2 0 4 2 1 3 100

39.0 28.0 20.0 1.0 0.0 2.0 0.0 4.0 2.0 1.0 3.0 100.0

8 7 4 49 0 3 0 0 7 1 1 80

10.0 8.8 5.0 61.3 0.0 3.8 0.0 0.0 8.8 1.3 1.3 100.0

14 4 58 14 0 0 0 0 4 1 4 99

14.1 4.0 58.6 14.1 0.0 0.0 0.0 0.0 4.0 1.0 4.0 100.0

29 8 34 11 0 3 0 2 2 1 4 94

30.9 8.5 36.2 11.7 0.0 3.2 0.0 2.1 2.1 1.1 4.3 100.0

65 12 8 4 0 3 0 0 10 1 3 106

61.3 11.3 7.5 3.8 0.0 2.8 0.0 0.0 9.4 0.9 2.8 100.0

39 22 8 7 0 3 0 1 13 1 5 99

39.4 22.2 8.1 7.1 0.0 3.0 0.0 1.0 13.1 1.0 5.1 100.0

65 7 0 2 0 6 0 0 14 1 4 99

65.7 7.1 0.0 2.0 0.0 6.1 0.0 0.0 14.1 1.0 4.0 100.0

情報システム関

連のリスク管理

ドキュメント管理

進捗管理

品質管理

コスト管理

要員管理

セキュリティ対

策

ネットワーク管

理

ソフトウェアの適

正利用（ライセン

個人情報保護

対策

PC管理、モバイ

ル機器管理

コンピュータウィ

ルス対策

外部委託（アウ

トソーシング）

外部委託（開発

の委託）

災害対策 ※上段：件数、下段：回答件数に対する割合（％）


378

（２）システム監査人の資格と育成

JIPDEC 調査によれば、75%強の企業で内部監査部門（監査部、検査部等）が設置されている

が、システム監査人（システム監査の担当者）がいる企業は、25%にすぎない。また、システム

監査を実施していない理由として、「実施する担当者（部門）の確保が難しい」ことが挙げられて

おり、システム監査人についての課題が多い。システム監査人の資格とその育成について触れる。ａ．システム監査組織（チーム）について

システム監査は、通常監査チームを編成して監査にあたることが多い。チームとして次の様な

構成が望まれる。また、下記のような知識及び技能を備えていることが必要である。

①チームシステム監査組織（チーム）は、監査責任者、監査人、監査補助者、アドバイザー等で構成す

る。

②必要な知識及び技能システム監査組織（チーム）は、監査の効率と品質の保持のために次のような知識と技能を備

えていることが必要である。・システム監査の実施に関する知識及び技能・情報システムの企画・開発・運用・保守に関する知識及び技能・情報システムのマネジメントに関する知識及び技能・情報システムの技術に関する知識及び技能・当該システムに関する法務知識・当該業務に関する基本知識および関連知識システム監査人個人というより、システム監査組織（チーム）として、上記②の要件を整えて

いることが必要なのである。ｂ．システム監査を内部監査とするか外部監査とするか ①システム監査の担当者

システム監査を行う社内事情によって、内部監査とする外部監査とするかが、決まることが多

いが、社内事情に加えて、システム監査の目的、テーマを考慮して決定すべきである。なお、

JIPDEC 調査では、「誰がシステム監査するのが効果的か」との問いに、「内部の監査人」と答え

たもの 40%強、「監査法人・公認会計士」と答えたもの 20%強となっており、内部の監査人によ

る内部監査を望む企業が多い。


379

②内部監査と外部監査との差異

内部監査と外部監査の相違点は、以下のとおりである。

図表 4-1-10 内部監査と外部監査の差異

（「情報システム監査実践マニュアル」P35～36 に筆者の見解を一部加筆）5

内部監査外部監査

狙い組織体の経営目標の効果的達成に役立つ

ことを目的として、経営方針・経営者の意向

と現在の情報システムのコントロール状況

のギャップを明らかにする。

世の中一般、業務水準に比べて監査を依

頼した組織体の情報システムのコントロー

ル状況の実態を明らかにする。第三者に対

する説明責任の手段とすることもある。

実施主体

組織体内の監査部門（システム監査人）

一部もしくは全部の外部委託も可能。

監査を依頼した組織体外部の監査実施機

関（監査法人、監査登録企業など）。

監査権限組織体で定めた監査規定によって、組織体

内の監査部門が持つ。

監査契約に基づいて、監査実施機関が持

つ。

監査基準システム監査基準、システム管理基準を監

査基準とする監査が多い。

システム監査基準、システム管理基準によ

る監査に加えて、情報セキュリティ監査基

準、情報セキュリティ管理基準を監査基準

として使用することが多い。

監査プロセス組織体で定めた監査規定、監査マニュアル

に従う。

監査実施機関の監査プロセスに従う。

監査テーマ安全性、信頼性、機密性、情報セキュリティ

などに関するコントロール状況の評価がテ

ーマとなることが多い。システム運用段階

が対象になることが多い。

左記に加えて、有効性、効率性などに関す

るコントロール状況の評価も監査テーマに

なる。

段階としては、左記に加えて情報戦略、企

画、開発段階なども対象になることが多

い。

意見交換会報告の前に被監査部門の意見（事実確認）

をきく場を設定する。

意見を聞く場を設定しない場合が多いが、

監査プロセスとして、「事実誤認有無確認」

を定めた監査企業もある。

報告内容評価よりも問題点の指摘、改善案に重きを

おく（助言型中心）。

評価基準に照らしてどうかという評価に重

きをおく。助言型の監査もある。

報告先組織体の長。監査依頼者（多くの場合、組織体の長）。

フォロー

アップ

監査の一環として実施。必要に応じ監査報告までとは別契約で実

施。

5 参考文献 ⑨


380

ｃ．システム監査人への要求

システム監査人の要件として、独立性と専門的能力とが必要とされる。

①システム監査人の独立性システム監査の信頼性が確保されるためには、システム監査人の独立性が保たれていることが

絶対に必要である。

・外観上の独立性システム監査人は、システム監査を客観的に実施するために、監査対象から独立していなけれ

ばならない。監査の目的によっては、被監査主体と身分上、密接な利害関係を有することがあっ

てはならない。

・精神上の独立性システム監査人は、システム監査の実施にあたり、偏向を排し、常に公正かつ客観的に監査判

断を行わなければならない。

②専門的能力システム監査人の専門的能力として、IT の知識、監査能力および会計基準および法規・業務の

知識が必要とされる。

・システムの知識システム監査の監査対象はシステムであるから、システムの知識は当然に必要である。ハード

ウェアの知識、ソフトウェア・プログラムの知識、システムの企画・開発の知識、システムの運

用・管理の知識など、それぞれの領域で一定の知識が要求される。当該知識の中には、システム

のマネジメントの知識が含まれる。

・監査能力システム監査人には監査人としての意識と能力が要請される。監査人としての意識とはシステ

ム監査を独立した第三者の立場から実施するという認識と監査目的の明確な認識をもって、シス

テム監査を計画・遂行する能力と監査結果を分析・報告する能力である。

・会計（簿記、財務諸表）の知識・「システム監査基準」等のシステム監査の基準および会計監査、労働、セキュリティ等の関連

法規・システム化する業務、たとえば経理・財務、販売、購買、在庫、原価計算等の業務に関する

知識・業務の分析、運用、管理の知識


381

③システム監査人の現状 JIPDEC の調査によれば、システム監査人に最も不足していると思われる知識は、「業務知識」

と「情報システムの知識」であり、不足していると思われる能力は、「分析能力」「インタビュー

能力」「判断能力」であるという。システム監査人に要求されるものとアンケートの現実とのギャ

ップの大きさを痛感する。こうした状況を踏まえて、システム監査人の育成の課題を捉えること

が大切で、急務と言える。 ④システム監査人に関連する代表的な資格

システム監査人としての一定の公的資格の取得も、システム監査人の育成の具体的な形として、

その人材の増強と拡大に資することと考え、この点について触れる。現在システム監査人に関連する代表的な資格には、経済産業省管轄の認定試験である「システ

ム監査技術者」および米国における認定試験である「公認情報システム監査人」（Certified Information System Auditor：CISA）ならびに日本システム監査人協会が認定する「公認システ

ム監査人」（Certified System Auditor：CSA）等がある。その試験制度の概要は以下のとおりで

ある。

・システム監査技術者経済産業省は、情報処理業務に係わる技術者に対して、１つの目標を示し、刺激を与えること

によってその技術の向上を図ることや、当該技術者の評価に関して客観的な尺度を提供すること

等を目的として、情報処理技術者試験制度を設け、情報処理技術者試験センターがその資格試験

を実施している。この試験のうち、システム監査技術者試験は昭和 61 年より開始され、その期

待される技術水準は以下のようになっている。・ビジネス要件や経営方針に合致した監査計画を立案できる。・情報システムの企画・開発・運用段階において、効率的な監査手続を実施するための監査技

法を適時かつ的確に運用できる。・ビジネスアプリケーションが適用される業務プロセスの現状に関し、その問題点を洗い出し、

問題点を分析・評価するための判断基準を自ら形成できる。・監査結果を論理的に矛盾のない報告書にまとめ、説得力のある改善報告を行うことができる。・監査の実施にあたって必要となる情報技術およびその技術動向を理解できる。・外部環境の変化をとらえ、組織の将来像を描き出すことができる。システム監査技術者試験は合格率が平均 6.7%でその試験水準から情報処理技術者試験の中で

もっとも難しい試験の一つとされていが、実務経験の必要性がなく、継続教育も義務づけられて

いない。


382

・公認情報システム監査人（CISA）

公認情報システム監査人は情報システム監査および、セキュリティ、コントロールに関する高

度な知識、技能と経験を有するプロフェッショナルとして情報システムコントロール協会

（ISACA）が認定する国際資格で、この試験は日本でも受験できるが、実務経験を必要とし、合

格後も継続教育が必要とされている。

・公認システム監査人（CSA）実務に応じられるシステム監査人を育成し、情報化社会の健全な発展に寄与するため、NPO 日

本システム監査人協会が認定する資格である。システム監査技術者試験に合格した上で、一定の

有効な実務経験を積むことによる認定のほか、公認情報システム監査人、その他の高度情報処理

技術者、中小企業診断士、公認会計士、技術士にも、一定の要件を満たすことで、認定を行って

いる。実務経験を必要とし、合格後も継続教育が必要とされている。

なお、地方公共団体に対する情報セキュリティ監査を要請した総務省のガイドライン「地方公

共団体情報セキュリティ監査実施手順」には、「資格の要件を踏まえた専門家」が必要とした上で、

「資格の要件を踏まえた専門家」とは下記であるとしている。・内部監査・・公認内部監査人（CIA）､公認会計士、公認システム監査人（CSA）、システム

監査技術者、公認情報システム監査人（CISA）、ISMS 主任審査員、ISMS 審査員・セキュリティ技術・・情報セキュリティアドミニストレータ、上級システムアドミニストレ

ータ、公認情報セキュリティ管理者（CISM）、公認情報システムセキュリティ専門家（CISSP）、公認システムセキュリティ熟練者（SSCP）

（３）システム監査の手順

システム監査の標準的な手順を、時系列で述べる。システム監査に係わる期間は、監査テーマ

や監査対象の大きさにもよるが、3 ヶ月間から 6 ヶ月間が通常であろう。ａ．監査計画

監査計画は、基本計画と個別計画に分けて、監査を有効かつ効率的に実施するため策定する。

また状況の変化に対応して計画は弾力的に運用する。

①基本計画年度計画（監査の継続性→中長期を含む）として、当該年度の監査対象、重点監査テーマ、実

施体制、日程、予算などを策定する。

②個別計画個別監査業務の計画（予備・本調査、評価・結論、報告）として、監査対象、監査目的、監査

範囲、監査手続（具体的な調査手段・方法）、監査時期・日程、監査人氏名、予算などなどを策定

する。


383

ｂ．システム監査の実施手順 ①事前の情報収集

・監依頼者（代表者あるいは内部監査責任者など）の意向調査・被監査部門の情報収集・トップインタビュー（代表者、内部監査責任者あるいは被監査部門長など）

②予備調査・監査テーマに沿った調査の狙いの設定・重点項目についての調査項目、調査方法を検討し監査チェックリストなどの作成・調査項目、調査データなどを被監査部門に提示し、調査（往査）準備を要請・往査可能な場合･･･監査チェックリストなどにより、ヒアリングおよび資料実査・調査による場合･･･関連資料によりシステムの状況の把握・予備調査まとめ･･･予備調査結果の整理、問題点・指摘事項の抽出、今後の調査必要事項の洗

い出し

③本調査・準備･･･予備調査で抽出された問題点、指摘事項の確認方法検討、改善のための確認必要事項

の整理、未調査事項の整理・監査項目の見直し・監査方法の検討・監査チェックリストの見

直し確認、本調査の調査項目一覧作成・本調査･･･調査項目一覧、監査チェックリストなどによるヒアリング実査

④評価・結論

・予備調査・本調査結果の整理と分析・指摘・改善事項の整理・監査人内部の意見・認識の確認

⑤報告

・報告書作成監査報告書の記載事項は、監査対象、監査概要、保証または助言意見、制約または除外事項、

指摘事項、改善勧告、その他特記事項。ア助言型監査報告書の場合：監査の結果、改善を要する指摘事項を認めた場合には、「システ

ム管理基準」に照らして、指摘事項を示し、必要に応じて改善勧告、改善提言を記載する。イ保証型監査報告書の場合：情報システムの内部統制がリスクアセスメントに基づき適切に

整備・運用されている場合には、「システム管理基準」に照らして、適切である旨を記載する。・事実誤認有無確認調査（意見交換会）被監査部門にこれまでの調査結果を伝え、事実誤認の有無について確認する。

・報告会


384

⑥改善指導（フォローアップ）

・フォローアップ計画・改善計画の作成・フォローアップの実施

（４）システム監査手法

一般的な（業務監査や会計監査でも使用される）監査手法とコンピュータを利用した監査技法

（Computer Aided Audit Technique：CAAT）とがある。参考までに掲載する。

図表 4-1-11 一般的なシステム監査手法

（情報システム監査実践マニュアル P82 ページから）6

監査手法内容

アンケート法監査対象に関係している管理者・担当者の中から対象者を選定し、監査人が作成

したアンケート票に回答してもらうことで、監査テーマについての状況認識、問題

意識を幅広く収集することを目的とする。予備調査で利用することが多い。

インタビュー法監査項目についての実態を立証するために、システム監査人が直接に問い合わ

せ回答を入手すること。効率よく必要十分な監査証拠を入手するため、あらかじめ

インタビュー対象部門、対象者を十分に検討し、質問内容を吟味しておく必要があ

る。

チェックリスト法システム監査人がチェック項目をリスト化しインタビューを通じて状況をチェックす

る。個別の監査対象に対してそのまま合致するチェックリストはない。システム監

査人は組織体としての標準的なシステム評価基準を監査目的、監査テーマ、監査

対象に合わせてカスタマイズしそのシステム評価基準に基づいたチェックリストを

作成する。

ドキュメント

レビュー法

システム監査人が監査目的に関連した資料及び文書類を入手し、内容を確認す

ること。システム監査人は、事前準備の際、被監査部門におけるドキュメントの整

備状況を確認して、どのドキュメントが利用可能かを把握する。

突合・照合法ドキュメントレビュー法の一種であり、関連する記録同士を突き合わせたり、記録さ

れた最終結果をその起因となった事象を示す原始データまで遡り突き合せたりす

ることによって、状況確認を行うこと。

現地調査法システム監査人が被監査部門へ赴き、そこでの作業状況を自ら調査すること。現

地調査は、対象業務プロセスの始点から終点まで、取引の開始から結果の出力

まで、建物・施設であれば入り口から出口まで業務フローをトレースすることが有

効である。なお、現場の業務の妨げにならないよう、事前に調整をしておくことが

必要である。

6 【文献 9】「情報システム監査実践マニュアル」NPO 日本システム監査人協会編


385

図表 4-1-12 コンピュータを利用した監査手法

（情報システム監査実践マニュアル P83 ページから）7

技法名内容

テストデータ法実際にテスト用のデータを作成・入力してシステムをテストし、処理の正確性を

検証する。特定の機能に限定したテストや、総合的な計算機能、コントロール機

能をテストするなど、監査人の判断で対象を定めることができるメリットがある。

システムが設計されたとおりに動いているか否かを検証する手法である。テスト

したシステムが実際に稼動しているものと同一であることを確認する必要があ

る。

監査プログラム法監査人の指定した基準に従ってファイルからデータを抽出し、比較演算を行い、

処理の妥当性を検証する。このデータ抽出に使用されるものが、一般に「汎用

監査プログラム」と呼ばれ、監査人にコンピュータについての高度な知識がなく

とも使用できること、システム変更に容易に対応できること、ひとつのパッケージ

で多くのアプリケーションの監査ができること、などのメリットがある。

監査モジュール法監査人のためのモジュールをシステムに組み込み、監査人の要求した抽出条

件に合致したデータが生じた際、これを抽出してファイルを作成する。自動的に

データを抽出するので余分な時間を必要としないが、抽出条件によってはデー

タが膨大となるリスクがある。機能の弾力性を欠くが、エラーや不正の発見には

有効な手法である。

ITF （ Integrated Test

Facility）法

システム的に架空講座を設け、稼働中にテストデータを流し、その結果をあらか

じめ準備しておいた正しい結果と照合する方法である。テストデータが実際の業

務処理や記録に影響しないように配慮する必要がある。ミニカンパニー法とも

呼ばれる。

並行シミュレーション法特定のアプリケーションプログラムに対して、監査人がテストプログラムを準備

し実際のデータを入力して、その結果を本番プログラムと比較することによって

正確性を検証する。

ぺネトレーションテストネットワークに外部から不正に侵入できないかどうか、コンピュータやネットワー

クのセキュリティ上の弱点を発見するテスト手法の一つで、システムを実際に攻

撃して、侵入を試してみるテストである。ネットワークセキュリティ対策を施してい

ても、それが正しく機能しているかどうかは、実際に試してみなければ確認でき

ない。主なテスト項目は以下のとおりである。

・外部から不正に侵入されないかどうか

・DOS 攻撃を受けた場合にどの程度耐えられるか

・他のコンピュータを攻撃する踏み台にされないかどうか

7 【文献 9】「情報システム監査実践マニュアル」NPO 日本システム監査人協会編


386

４．付加価値の高いシステム監査の実現に向けて（留意点）

（１）経営者にとってのシステム監査

システム監査の重要性・必要性についての認識は徐々にではあるが高まっている。その一方で、

「簡単に実施できるテンプレートや基準」を求める声もある。システムは、企業活動そのものを具体的に支援し、また管理する手段である。しかし、システ

ムの性格は企業業態、企業風土により様々である。金融機関システムのような信頼性・遵守性・

セキュリティ（機密性・完全性・可用性）を重視するシステム、あるいは統計システムのような

効率性を重視するシステムなど、その性格は様々である。また、同一業種の企業内システムであ

っても財務会計システムと顧客管理システムとは、その性格が異なる。したがって、システム監

査にあたっての着眼すべきポイントは異なる。システム監査が一様であるはずがない。極めて複

雑な対応が必要なことは、容易に首肯できる。簡単ではないのである。また、システムにかかるコストが、システムの信頼性・遵守性・セキュリティ（機密性・完全

性・可用性）のどこにポイントを置くかにより、大きな差があるように、そのシステム監査も有

効性、効率性、信頼性・遵守性・セキュリティ（機密性・完全性・可用性）のどこに着眼した監

査にするかにより、大きな費用の差が生ずる。この点からも、「安いシステム監査とは何か」とい

う問いに対する答えは、一律には存在しない。経営者にとって、システムが厄介な代物であるように、そのシステム監査となるとさらに厄介

な代物であると知るべきであろう。しかしながら、経営にとって重要なのである。留意すべき点

はある。これについて以下に述べる。（２）明確な目的設定

監査依頼者（組織体の長）はシステム監査の目的設定を明確にする必要がある。

ａ．経営との関係システムは多くの面で経営に関わっている。「システムの活用状況に関する監査」と「システム

の導入や利用についてシステムを適切にガバナンスする仕組みがあり、それが有効に機能してい

るかの監査」のどちらを監査対象にするのかの明確化が必要である。JIPDEC 調査によれば、大

半の企業の監査テーマは、「システムの活用状況に関する監査」であった。しかし、既に述べたよ

うに「ｂ．「IT を利用した内部統制の監査」としてのシステム監査」（この節の第 2 項の（３）の

b.参照）が重要になっている。この点を踏まえて監査目的の設定が必要である。ｂ．対象となるシステム

システム監査対象システムを、何にするかに留意したい。例えば、対象システムが財務に関わ

るシステムであれば、システム監査の着眼点、手法などが大きく異なる。この場合、財務会計シ

ステム、及び財務データの生成や処理に関わるシステムである販売管理情報システム、購買管理

情報システムなども関連する。


387

ｃ．システム監査報告（保証型と助言型）さらに、監査報告として、何を求めるかを明確にしたい。監査報告には、保証型報告と助言型

報告とがある。 ①保証型報告

定められた監査基準（監査チェック項目）に従って監査することになるので、内部統制報告書

の根拠に資する報告書ともなる。監督官庁などへの報告付属文書として利用されることも多い。

しかし、情報セキュリティ監査を含むとしたら、容易に想定されるように、情報システムリスク

が、システム監査によってなくなることはありえず、「少なくする努力をしている」という企業努

力の表明であることを念頭におくことが重要であろう。厳密な保証型監査は、難しいのが現状で

ある。 ②助言型報告

内部統制の不備や脆弱性を指摘し改善指摘を行うので、内部監査というより、外部監査による

ほうが、付加価値の高いシステム監査となると思われる。（３）着眼点の明確な指示

監査依頼者（組織体の長）はシステム監査にあたっての着眼点を明確にする必要がある。システム監査にあたっての着眼点については、既に述べた（この節の第 2 項の（２）の b.参照）。

JIPDEC 調査によれば、監査テーマや監査対象の決定は、半数以上の企業において「内部監査部

門の判断」で決められており、トップの要求に基づく企業は 3 割弱である。こうした中では、そ

の着眼点として、「有効性」についてのシステム監査の要求が少ないことが首肯できる。たとえば、

「システム分析」のテーマにおける「有効性」の着眼点からは「ユーザーの開発要件について」、

「ユーザー要件の妥当性の検証が如何におこなわれたかリスク分析、システムライフサイクル、

費用対効果などについて」などに監査の重点をおくことになろう。「安全性」「遵守性」の着眼点

からは、「ユーザー要件の充足性、法令制度との合致性」の監査にとどまり、「ユーザー要件の妥

当性の検証がいかに行われたかリスク分析、システムライフサイクル、費用対効果などについ

て」などは監査されないだろう。着眼点の明確な指示が必要である。（４）アウトソーシング業務へのシステム監査

情報システムに関する業務を外部委託することは、コスト削減、専門的で高度なサービスの享

受、自社の資産のコア業務への集中などのメリットが大きく、その外部委託は多い。しかし、外

部委託することにより、発生するリスクを分析し、それへの対応として様々な統制活動をするこ

とが必要である。 FISC 調査では、システム監査未実施の理由として「共同センター等外部会社を利用しており、

システム監査の必要性が低い」という企業が 33%を占めている。金融機関の支店端末システムは

対象外であろうか。最新の調査は異なる結果がでていることを願う。外部委託先管理のポイントは以下の 3 点である。


388

ａ．委託先選定の管理

評価項目と評価基準の明確化が必要である。なお評価項目と評価基準は委託業務により適切な

ものとなるよう考慮する必要がある。エントリー委託業者、情報処理委託業者、ネットワーク委

託業者はおのおの少しずつ異なるだろう。

ｂ．契約管理次のような事項を委託契約書に盛り込むべきことを明確化すべきであろう。・業務委託の内容及び範囲・業務などのセキュリティ要件・瑕疵担保責任・損害賠償・免責・第三者への再委託の制限や事前通知義務・監査権

ｃ．委託業務の履行状況管理委託業務の履行状況についての定期的な報告、評価尺度としての SLA の盛り込み、などにつ

いて考慮する。（５）システム監査人の育成

監査依頼者（組織体の長）は、切実な問題としてシステム監査人の育成を行う必要がある。システム監査人の資格と要件については、概括的に既に述べた（第 3 項の（２）参照）。ここ

では、システム監査人の人材の育成に当たって、いくつかの留意点を補足する。システム監査人には、システム開発・運用経験が必要であることは既に触れたが、さらに具体

的には、多くの失敗を経験した人間がよい。システム監査、なかでも助言型監査では、改善指摘が大切である。システム監査人は、数ある

指摘事項のなかで、重点とする改善指摘を絞ることが通常である。対象組織体の状況を総合的に

勘案できる能力が要求されるのであるが、何が重要であるのかの判断には、失敗経験が有用であ

る。システム監査人は、システム監査チェックリストの単なるチェッカーであってはならない。

チェッカーとなれることも大変な研鑽が必要であるが、被監査組織体にとって、その時点での、

改善指摘の良否（説得性）が付加価値を持つシステム監査か否かの岐路である。システム監査改

善指摘は、理路整然として正しくとも、その時に、被監査組織体にとって、受け入れがたい（組

織上の制約、費用の制約など）ものであったとしたら、システム監査は付加価値を生み得ないの

である。被監査組織体の現状を是認せよということではない。改善にステップが必要なのである。


389

システム監査人にとって、基本的で重要な要素がある。監査人の人格である。システム監査の対象はシステムであっても実際に監査を受けるのは、主にシステム部門の「人」

であり、その改善を行うのも「人」である。被監査組織体の人達と悩みや課題を共有できる豊か

な心の人材が必要である。システム監査人として毅然たる立場に立つとともに、被監査組織体か

ら受け入れられる人柄が必要である。こうした人材の育成が必要である。システム監査人が、被監査組織体のシステムの目的、特徴、業務知識、特徴的なリスクなどを

把握できる能力を育成することも必須である。それはインタビュー能力であり、分析力であり、

総括的な理解力である。システム監査人にとっては、耳新しいことであったとしても、被監査者

にとっては、ごく当たり前でその被監査組織体にとっては、常識と思われていることが多い。こ

の問題は深刻である。被監査者が、「こんなこともわからない監査人か。こんな人が指摘をするこ

となんか聞く耳をもたない。」と思ったとしたら、その時点で、システム監査は、儀礼的にすすん

でいくしかないのである。被監査組織体にとって何の付加価値も生まないのである。システム部

門の専門家集団にこうした「自分の専門分野」は他の人にとっても、常識であると思っている人々

が多いことは、容易にうなずけるのではないだろうか。（６）独自のシステム監査チェックリスト

「システム監査チェックリスト」は被監査組織体独自のものが必要であると知るべきである。システム監査の手続きについては、既に第 3 項の（3）で触れたが、システム監査人が、予備

監査や本監査で使用する「監査チェックリスト」は重要である。しかし、システム監査人によっ

ては、一律の概念的な「監査チェックリスト」を使用しているケースがある。その被監査組織体

の監査テーマと要請された着眼点を踏まえて、具体的でかつ客観性のあるその被監査組織体オリ

ジナルの「監査チェックリスト」が作られるべきである。被監査組織体の業務特徴（ソフト開発かインターネット事業者かなど）により、同一のチェッ

ク項目であるとしてもリスクの大きさが異なる。このことを「監査チェックリスト」には反映す

ることが大切である。業態ごとのシステム監査チェックリストはあっても、すべての業態で同一の「監査チェックリ

スト」はないと知るべきである。（７）事実誤認有無確認調査の重要性

システム監査手続きにおける事実誤認有無確認調査（意見交換会）を大切にしよう。事実誤認有無確認調査（意見交換会）というステップがあることは、既に述べた（第 3 項（３）

の⑤参照）。しかし、実態としては、特に外部監査では簡略化するケースが多い。これは問題であ

る。被監査組織体にとっては、具体的な監査報告書の雛形ができて、はじめて監査人の調査意図に

気づくことも多い。「この事実で、このような指摘を受けるのは、捉え方が針小棒大である」など

の感想を抱くことが多いのである。システム監査人にとっては、針小棒大であろうが監査証跡に

基づく指摘であるのだが、この事実認識の確認が大切である。この場が事実誤認有無確認調査（意

見交換会）なのである。システム監査人は、限られた時間でサンプリングして、監査を行うので

あり、このステップは、簡略化してはならない。被監査組織体もこの認識をすべきである。


390

（８）自己チェック

システム監査は、これまで述べてきたように必要かつ重要である。しかし、一方で容易に取り

組みがたいのも事実であろう。次善の策として、自己チェックをしてみてはいかがであろうか。 FISC の「金融機関等のシステム監査指針」は、1024 項目にわたるチェック項目が網羅されて

いるが、テーマ別にかつ着眼点別に表示されており、便利である。全部を完璧に網羅することは

考えず、まずは気懸かりなテーマについて、自己チェックしてみることである。また、情報セキュリティに係わるチェックリストとして、経済産業省の「情報セキュリティ管

理基準」のサブコントロール（957 項目）の中から、必要な分野についてピックアップすること

もお薦めである。（９）システム監査のコストパフォーマンス

繰り返しになるが、システム監査では、次の点を明確にチェックすることが必要である。 ①監査目的の設定 ②監査対象システムの設定 ③求めるシステム監査は、保証型か助言型か ④監査の着眼点（有効性、効率性、信頼性・遵守性・セキュリティ（機密性・完全性・可用性）） ⑤アウトソーシング業務の監査を含めること（委託先選定の管理、契約管理、委託業務の履行

状況管理） ⑥有能なシステム監査人の確保 ⑦システム監査を具体化する「システム監査チェックリスト」 ⑧システム監査手続きにおける事実誤認有無確認調査（意見交換会）こうして考えると、システム監査のパフォーマンスということが、あまりにも漠然としたこと

に思われる。馴染まないのである。パフォーマンスとは何に対してのパフォーマンスなのか。何

を基準としたパフォーマンスなのか。それらの「前提とすべきことを決めているか否か」からの

論議が、システム監査なのである。漠然として、抽象的では、実務には無用である。むしろ、な

らば「企業にとっての付加価値」を上げるシステム監査の留意点くらいが適切のように思う。ただ、システム監査にかけている各企業のコスト実態は、捕捉公表されたものが少ない。監査

目的、監査対象システム、着眼点などを明確にして、ユーザーの立場で調査し公表するなど JUASの役割の一つかもしれない。システム監査に一層付加価値をつける為に、何をなすべきかを考えてきた。システム監査が IT

ガバナンス、IT 統制の高まりのなかで、ますますその必要性、重要性が増してきていることも述

べてきた。しかし、システム監査の実施実態はまだ企業の半数にすぎない。システム監査を実施

するコンセンサス、組織風土の改善がまだ必須のように思う。システム監査の概要、企業におけ

る位置づけの理解がまず必要である。安直なシステム監査は、何の付加価値も企業にもたらさな

い。腰を据えた取り組みが必要である。


391

（10）システム監査に関する法令等8

①国の基本的な方針

名称略称、俗称など

1 高度情報通信ネットワーク社会形成基本法（平成 12 年 12 月 6 日法律第 144

号）

IT 基本法

②電子商取引等関係


1 電子署名及び認証業務に関する法律（平成 12 年 5 月 31 日法律 102 号）電子署名法

2 商業登記法（昭和 38 年 7 月 9 日法律第 125 号）

（商業登記法の一部を改正する法律（平成 12 年 4 月 19 日法律第 40 号））

商業登記法

3 書面の交付等に関する情報通信の技術の利用のための関係法律の整備に関

する法律（平成 12 年 11 月 27 日法律第 126 号）

IT 書面一括法

4 電子消費者契約及び電子承諾通知に関する民法の特例に関する法律（平成

13 年 6 月 29 日法律第 95 号）

電子契約法

5 特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に

関する法律（平成 13 年 11 月 30 日法律第 137 号）

プロバイダ責任制

限法

6 特定電子メールの送信の適正化等に関する法律（平成 14 年 4 月 17 日法律第

26 号）

特定電子メール法

特定電子メール送

信適正化法

迷惑メール防止法

7 特定商取引に関する法律（昭和 51 年 6 月 4 日法律第 57 号）

（特定商取引に関する法律の一部を改正する法律（平成 14 年 4 月 19 日法律

第 28 号）

特定商取引法

8 電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関

する法律（平成 10 年 3 月 31 日法律第 25 号）

電子帳簿保存法

③行政の情報化関係


1 住民基本台帳法

（昭和 42 年 7 月 25 日法律第 81 号）

住基台帳法

2 行政手続等における情報通信の技術の利用に関する法律（平成 14 年 12 月

13 日法律第 151 号）

行政手続オンライ

ン化法

行政手続 IT 利用法

3 行政手続等における情報通信の技術の利用に関する法律の施行に伴う関係

法律の整備等に関する法律（平成 14 年 12 月 13 日法律第 152 号）

4 電子署名に係る地方公共団体の認証業務に関する法律（平成 14 年 12 月 13

日法律第 153 号）

5 地方公共団体の議会の議員及び長の選挙に係る電磁的記録式投票機を用い

て行う投票方法等の特例に関する法律（平成 13 年 12 月 7 日法律第 147 号）

電子投票法

6 行政機関の保有する情報の公開に関する法律（平成 11 年 5 月 14 日法律第

42 号）

行政機関情報公開

法

7 独立行政法人等の保有する情報の公開に関する法律（平成 13 年 12 月 5 日法

律第 140 号）

独立行政法人情報

公開法

8 【文献 10】「システム監査・情報セキュリティ監査ハンドブック」より抜粋


392

④通信・ネットワークの安全性・信頼性関係名称略称、俗称など

1 不正アクセス行為の禁止等に関する法律（平成 11 年 8 月 13 日法律第 128 号）不正アクセス禁止

法

⑤個人情報保護関係


1 個人情報の保護に関する法律（平成 15 年 5 月 30 日法律第 57 号）個人情報保護法

2 行政機関の保有する個人情報の保護に関する法律（平成 15 年 5 月 30 日法律

第 58 号）

3 独立行政法人等の保有する個人情報の保護に関する法律（平成 15 年 5 月 30

日法律第 59 号）

4 情報公開・個人情報保護審査会設置法（平成 15 年 5 月 30 日法律第 60 号）

5 行政機関の保有する個人情報の保護に関する法律等の施行に伴う関係法律

の整備等に関する法律（平成 15 年 5 月 30 日法律第 61 号）

6 行政機関の保有する電子計算機処理に係る個人情報の保護に関する法律

（昭和 63 年 12 月 16 日法律第 95 号）

行政機関個人情報

保護法

※廃止法令

7 地方公共団体における個人情報の保護に関する条例

8 警察の保有する電子計算機処理に係る個人情報の取扱いに関する規則（平

成 2 年 6 月 8 日国家公安委員会規則第 2 号）

警察個人情報保護

法

10 貸金業の規制等に関する法律（昭和 58 年 5 月 13 日法律第 32 号）

11 割賦販売法（昭和 36 年 7 月 1 日法律第 159 号）

⑥監査関係


1 株式会社の監査等に関する商法の特例に関する法律（昭和 49 年 4 月 2 日法

律第 22 号）

商法特例法

※廃止法令

2 証券取引法（昭和 23 年 4 月 13 日法律第 25 号）証取法

3 Sarbanes-Oxley Act of 2002 サーベンス・オクス

リー法

米国企業改革法

※米国法

⑦共通、その他


1 労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等

に関する法律（昭和 60 年 7 月 5 日法律第 88 号）

労働者派遣法

2 労働安全衛生法（昭和 47 年 6 月 8 日法律第 57 号）

3 職業安定法（昭和 22 年 11 月 30 日法律第 141 号）

4 刑法（明治 40 年 4 月 24 日法律第 45 号）

5 不正競争防止法（平成 5 年 5 月 19 日法律第 47 号

6 商法（明治 32 年 3 月 9 日法律第 48 号）

7 法人税法（昭和 40 年 3 月 31 日法律第 34 号）

8 所得税法（昭和 40 年 3 月 31 日法律第 33 号）

9 労働基準法（昭和 22 年 4 月 7 日法律第 49 号）労基法

10 雇用の分野における男女の均等な機会及び待遇の確保等に関する法律（昭

和 47 年 7 月 1 日法律第 113 号）

男女雇用機会均等

法

11 建築基準法（昭和 25 年 5 月 24 日法律第 201 号）

12 消防法（昭和 23 年 7 月 24 日法律第 186 号）


393

13 著作権法（昭和 45 年 5 月 6 日法律第 48 号）

14 著作権等管理事業法

（平成 12 年 11 月 29 日法律第 131 号）

15 特許法（昭和 34 年 4 月 13 日法律第 121 号）

16 知的財産基本法

（平成 14 年 12 月 4 日法律第 122 号）

17 有線電気通信法（昭和 28 年 7 月 31 日法律第 96 号）

18 電気通信事業法（昭和 59 年 12 月 25 日法律第 86 号）

19 電波法（昭和 25 年 5 月 2 日法律第 131 号）

20 犯罪捜査の為の通信傍受に関する法律（平成 11 年 8 月 18 日法律第 137 号）通信傍受法

21 通信傍受規則（平成 12 年 8 月 8 日国家公安委員会規則第 13 号）

22 刑事訴訟法（昭和 23 年 7 月 10 日法律第 131 号）

23 サイバー犯罪に関する条約

（欧州評議会）

24 民間職業仲介事業所条約

（ILO 第 181 号条約）


394

395

第４章システム信頼性確保第２節事業継続計画（BCP）

JUAS 調査部会で実施している『IT 動向調査 2006』の結果、事業継続計画（BCP：Business

Continuity Plan ）はまだまだ社会インフラ業界（電力・通信・銀行業界）を除くと大手企業とい

えども認知度が低く、策定が進んでいない状況であることがわかる。

今日では、企業が自社の基幹事業を継続的に行うためには、自社に止まらず関係会社や社外利

用者に対してコンピュータシステム障害の影響度やリスクを事前に調査し事業継続計画（BCP）

を策定して、実際にシステム障害が発生しても慌てることなく障害に即して早期に最善の回復手

段を講じて基幹の事業継続が行われる必要がある。これを怠ると利用者やマスコミ等が騒ぎ立て

て企業存続が危ぶまれることが起きる。

昨年度より、災害やシステム障害に際して経済産業省が『事業継続計画（BCP）』のガイドライ

ンを無償で提供し、大企業だけでなく、中小企業に対しても『事業継続計画（BCP）』の重要性を

認識するよう啓蒙を推進している。本節を読まれる方は、経済産業省が『事業継続計画（BCP）』

のガイドラインを是非ホームページから参照して活用を図っていただきたい。

何事も、システム障害が発生してからあたふたするのでなく、事前にシステム障害のリスクを

想定して、実際システム障害が発生した場合の連絡体制や基幹事業への影響の最小化をはかる回

復方法を策定しておくことの重要性を再認識する必要がある。

１．企業リスクと事業継続計画の必要性

２．事業継続計画（BCP）の取組み

３．事業継続計画（BCP）策定と実施及び運用

４．基幹務システムのバックアップシステム状況

５．ディザスタリリカバリ

４－２事業継続計画（BCP）

396

自然災害

政治、政変等

コンプライアンスリスク

人的リスク

ITリスク

不正取引、虚偽報告、個人情報等

財務、技術等

製品リスク

IT障害、ウィルス、データ改竄等

過労、引き抜き、モラル、士気等

事件、事故

戦争、政変

製造責任、製品欠陥等

特許侵害等

外的リスク要因

内的リスク要因

内部統制強化

火災、テロ、停電、断水、各種汚染等

地震、台風、洪水、大雪、竜巻、津波等災害対策強化

図表 4-2-1 企業の外的・内的リスク要因

１．企業リスクと事業継続計画の必要性

近年システム障害や災害が社会に及ぼす影響の大きさがクローズアップされ、企業の基幹事業

に直接影響を及ぼすシステム障害がマスコミでも頻繁に報道されている。システム障害や災害が

発生した内容を吟味すると、一次障害だけでなく二次障害など複合的な障害も散見される。事前

に回避可能なものや回復の方法が後手に周り、利用者に大変な迷惑をかけるケースも増えている。

企業基幹業務遂行がシステム障害や災害発生で危ぶまることを事前に想定しての緊急体制や対処

方法についての事業継続計画（BCP：Business Continuity Plan）策定・訓練の重要性について

述べる。（１）災害・システム障害と事業継続の必要性

企業は図表 4-2-１に示すように、自

然災害、事件、事故、政変などの外的

リスクや、コンプライアンスリスク、

IT リスク、人的リスク、製品リスク、

財務・技術等の企業の内的リスク要因

によって引き起こされる災害や障害が

発生しても、企業の基幹業務の停止に

至らないように配慮する必要がある。 SCM（Supply Chain Management）

に代表されるように、自社の部分適

から企業間を包含した全体適なシス

テムが求められており、この企業間全

体適での在庫を極力持たない仕組みは効率化や利益率に貢献をもたらしているが、災害や障害

によって自社の基幹事業継続ができないだけでなく関連企業にも多大な影響を及ぼすことが発生

している。例えば、在庫を小限にしているために部品供給会社の工場で事故が発生し部品供給

ができなくなった場合、即製品の製造中止や代替部品調達ができないため製品製造を中止せざる

を得ない状況が発生する。あまりにも効率化を目指したばかりに、災害や障害に対するリスク回

避の考え方が検討されておらず、自社のみならず関連企業にも多大な影響を及ぼし企業の事業継

続ができなくなることになる。金融・証券・証券所・通信事業などは、情報システムそのものが

企業の中枢を司っており、システム障害が発生すると社会に及ぼす影響が大きく企業の存続に多

大な影響があり、事業継続計画（BCP）対応が進んでいる。取引先や利用者等の利害関係者から企業の基幹となる重要な業務が中断しないこと、万が一事

業活動が中断しても目標復旧可能時間内に重要な業務を再開させるために日常的に様々な備えを

行うことで、業務中断に伴う顧客の他社への流出やマーケットシェアの低下、企業評価の低下な

どから企業を守り、事業継続を追求する計画を｢事業継続計画（BCP）｣である。


397

（２）事業継続計画（BCP）の範囲

事業継続計画（BCP）は企業全体の活動に及んでいるが、業種によってシステムの利用状況が

異なっており、システムインフラや金融・通信業界など情報システムそのものが企業活動となっ

ている業種と、製造業のように直接に関わりが少ない業種によって、同じシステム障害でも、事

業継続計画（BCP）の対象範囲が異なってくる。例えば、銀行・通信業界では大規模な障害は即利用者に影響を及ぼすため事業継続計画（BCP）

の範囲となる。一方、製造業では大きなトラブルでも他社や利用者への影響度合いによりある程

度のシステム障害は事業計画（BCP）の範囲から除外しているケースが多い。業種やシステムの

活用度によって適な事業継続計画を立てる必要があり、一概に範囲をルール化できるものでな

い。本節ではシステム障害・災害に対する事業継続計画（BCP）の範囲を大きなシステム障害、自

然災害などの復旧に限定する。小さなシステム障害は、システムの信頼性に類することが多いの

で事業継続計画の範囲から除外する（図表 4-2-2 参照）。

System trouble

③Small trouble ①Big trouble

②DR

BCPの範囲信頼性の範囲

銀行・通信業界BCPの範囲

製造業のBCPの範囲業種・業態によってBCPの範囲が異なる

①大きなシステム障害（Big System Trouble）

②自然災害などの復旧（De

③信頼性の対象範囲（Small System Trouble）

背景

①コンピュータにビジネスが依拠していることへの危険性②『対策実現』の実行力にかかわる問題③ディザスタリーリカバリ対策取組む以前の問題・・・

情報システムに関する潜在的な問題がディザスタリーリカバリー対策取組とともに顕在化する問題、本来の目的に加えてそれまで隠れていたもんだいも含めて解決が必要

図表 4-2-2 事業継続計画（BCP）の対象範囲

（３）事業継続計画（BCP）の概念

企業の重要な事業のシステムに障害が発生して社会に及ぼす影響が大きくなると、システム障

害からの復旧時間やシステム障害の対処方法、利用者への周知方法などを誤ると、利用者やマス

コミなどから批判がおき、経営責任者が謝罪し対応をせざるを得ない状況が多々見受けられる。災害や障害を『ゼロ』にはできないが、災害や障害が発生しても重要な業務を許容限界以上の

レベルで事業を継続させること、許容期間内に操業度を復旧させる方法、障害発生の回避、障害

発生時の体制・対応方法などを事前に検討し、事業継続計画（BCP）を策定することが重要にな

ってきている（図表 4-2-3 参照）。事業継続計画（BCP）は、災害やシステム障害時に


398

・目標と現状の復旧期間の乖離の把握。・許容される期間内に操業度を復旧させる。・許容限界以上のレベルで事業を継続させる。災害発生を想定して、企業の重要な事業を継続させる許容範囲を事前に検討しドキュメント化

して実際の災害や障害に役立てることである。日本では、社会インフラは諸外国に比べ堅固に構築されているが、阪神・淡路大震災のように

地震や台風による災害が社会インフラに突然襲ってくることを想定しておく必要がある。システ

ムが事業遂行の主たる役割を担っているため、災害による社会インフラ中断にも二次災害となら

ないように許容基準内の事業が継続できるように考慮する必要がある。また保守運用の見直しや

システム構成の二重化やディダスタリリカバリー等、リスクと投資対効果を考慮した『災害やシ

ステム障害に強い』事業継続計画を策定して、策定内容に基づいた対応を実施する必要がある。なお、事業継続計画の策定に際して、過大投資とならないように、継続業務の絞り込みや業務

再開目標時間（RTO：Recovery Time Objective）も留意する必要がある。障害や災害内容によ

って、適な業務再開目標時間は異なる。自然災害時では、数日～数週間（約 2 週間）でも可能

な事もあり、システム障害では即復旧～数週間の業務再開目標時間（RTO）が想定される。社会

インフラに関するシステムでは、障害や災害での業務再開目標時間は約半日（4 時間）以内での

一次復旧に善を尽くすことが求められており、この時間を超えると利用者への影響が大きくな

り、利用者への代替え方法も含めた対応が必要である（図表 4-2-5 参照）。

（内閣府防災担当事業継続ガイドライン第一版より追記）

図表 4-2-3 事業継続計画（BCP）の概念

システム障害

RTO(4 時間以内)

RTO目標値


399

費用と損失のバランス

8時間３日間 2週間

再稼働（RTO）（Recovery Time Object）

投資額（システム投資を含む）

損害（影響）企業リスク

災害

：グラフの交差点が必ずしも適正ポイントでなく、リスク毎の適を業種、企業の方針、社会的立場、財務状況等を考慮した上で決定する。

13日間（災害の平均RTO）

4時間

影響度合いの小目標時間

１日間

影響度合いの小目標時間

：社会インフラを担うシステムや、重要基幹システムの災害や障害が発生してからの回復目標時間

図表 4-2-4 費用と損失のバランス

（４）最新のシステム障害事例

近の経済活動に大きな影響を及ぼしたシステム障害事例を挙げると、一次障害、二次障害、

複合障害など多義に渡り、簡単にシステム障害の復旧ができない状況が見受けられる。システム

障害の発生後、半日、あるいは丸一日回復にかかっているシステム障害事例もある（図表 4-2-5参照）。たとえば、2006 年 8 月 14 日、作業船の電力ケーブル切断が関東地区の電力供給停止となり、

予備電源への切り替えやシステム自動停止が行われなかったために、株価配信が停止してしまっ

た。この株価配信システムは、各証券会社、放送などで利用されていたため、株価指標が丸一日

表示されない状況となった。これは事前に電力供給停止時のシステム動作確認を実施していれば

防げた内容である。人によるオペレーションミスや事前にシステム障害に対するリスクを検討し、

対応していれば防げる二次障害も多く見受けられる。図表 4-2-5 に記載されているシステム障害事例は、マスコミ等に報告された社会の影響が大き

いシステム障害の一部である。これ以外にも、社会に影響するような重要なシステム障害も数多

く発生していると思われる。企業が利用者にホームページ上でシステム障害を掲載するなど、シ

ステム障害の発生と対応状況を社外に積極的に告知するようになってきている。これは企業の存

続に直接関わるシステムが多くなり、システム障害対応に関しての企業の取組みも問われるよう

になってきているためであろう。


400

図表 4-2-5 経済活動に大きな影響を及ぼしたシステム障害事例

システム名障害発生日障害発生内容及び影響内容回復時間

株価配信

システム

2006 年

8 月 14 日

東京電力の停電に伴って、日経平均株価などの

株価指数の算出システムに障害が生じ更新が停

止しした。

8 時間

（翌日回復）

証券取引

システム

2006 年

1 月 18 日

証券取引件数の急激な増大のため、システム処

理能力を超えたため取引時間を 30 分早めたが、

その後取引を強制停止した。

8 時間

（翌日回復）

証券取引

システム

2006 年

1 月 14 日

システム障害により、対面・ネットでの取引業務が

できなく、ATM での資金振替サービスが一次停止

した。

交通情報系

システム

2006 年

1 月 12 日

首都高速等の 30 箇所の料金所で、自動料金収

受システム（ETC）が故障し支払いができなくなっ

た。

約 8 時間

6 万台影響

航空運行管理

システム

2006 年

1 月 3 日

運行情報全体を管理しているシステムが停止し

た。

1 時間にわたり利用ができなくなり、10 便が 30 分

以上遅れた。

1 時間

2.2 千人影響

ネットワーク

サービス

プロバイダ

2005 年

12 月 10 日

ブロードバンド通信サービス障害が発生。ハード

ウェアの CPU 故障により認証サーバーが過負荷

に陥ったため接続ができなくなった。

7 時間 30 分

71 千人影響

証券取引

システム

2005 年

12 月 8 日

証券会社が大量の誤発注を出し、すぐに注文を

取消せなかった。オペレーションミス、ソフトウェア

の不具合、緊急取引停止が不可。

ネットワーク

サービス

プロバイダ

2005 年

12 月 3 日

光ファイバを使ったインターネット接続サービスと

電話サービスで通信障害発生。契約者の 8 割が

通信一時不通となった。

利用者の

8 割接続不可

証券取引

システム

2005 年

11 月 4 日

株価情報などの相場報道システムに障害が発生

し、午前中の株式売買を全面的に停止した。オペ

レーションミス

5 時間

証券取引

システム

2005 年

11 月 1 日

取引所システムに障害が発生し、取引株の売買

が 8：30～13:30 まで全面的に株式売買停止となっ

た

5 時間

証券取引

システム

2005 年

10 月 24 日

証券のインターネット取引が AM8：40 から夕方ま

で応答遅延。

9 時間


401

２．事業継続計画（BCP）の取組み

JUAS『IT 動向調査 2006』で事業継続計画（BCP）の取組み状況を調査した。企業の事業継

続計画（BCP）取組み状況は、まだまだ取組が進んでおらず災害やシステム障害が発生した時点

であたふたする企業が多いといえる。

（１）各企業の事業継続計画（BCP）取組み状況

『IT 動向調査 2006』の調査結果では、各企業の BCP（事業継続計画）はあまり進んでいない

（図表 4-2-6 を参照）。「BCP の策定を検討中である」、「BCP を策定する予定がない」を加算し

て、「BCP の策定が済んでいない」として見ると回答企業全体の 78％となる。この結果から見る

と経済産業省が支援策を進めているが、各企業に浸透しておらずあまり進んでいないといえる。 BCP（事業継続計画）の策定状況を企業規模別に見てみると、企業規模が大きいほど策定が進

んでいる傾向にあるが、従業員が 1000 名を超える大企業の集計結果を見ても 61%企業が「BCPの策定が済んでいない」状況となっている。100 名未満の小企業にいたっては、実に 91%の企業

が「BCP の策定が済んでいない」状況にあることがわかる。もっと各企業が事情継続計画（BCP）の重要性を認識する啓蒙が必要であり、経済産業省の事業継続計画（BCP）ガイドラインの周知

とテンプレート活用を進めることが必要である。

【Q10-7】BCP(事業継続計画)の策定状況

4%

3%

9%

3%

4%

11%

12%

5%

9%

19%

31%

20%

30%

35%

47%

71%

54%

26%

2%

6%

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

合計：N値

100名未満

100～1000名未満

1000名以上

1.BCP(事業継続計画)を策定し運用しており、定期的に見直し更新している

2.BCP(事業継続計画)を策定し運用している

3.BCP(事業継続計画)を策定中である

4.BCP(事業継続計画)の策定を検討中である

5.BCP(事業継続計画)を策定する予定はない


図表 4-2-6 企業規模別事業継続計画（BCP）の策定状況


402

（２）業種別の事業継続計画（BCP）取組み状況

業種別に見ると、社会インフラを担う業界｢電気、ガス、水道｣業界、｢通信、通信サービス｣、

と銀行・証券業界は、事業継続計画（BCP）が進んでいるが他の業界は、事業継続計画（BCP）が全然進んでいない。特に電気、ガス、水道」業界、「通信、通信サービス」業界といった社会イ

ンフラを担う業界が他の業界に比べ BCP の策定が進んでおり、担当省庁の取組みや指導状況で

取組み状況によって差が生じているといえる（図表 4-2-7 を参照）。

4%

25%

15%

17%

8%

13%

16%

18%

8%

9%

14%

11%

10%

19%

10%

10%

17%

11%

50%

33%

25%

26%

17%

17%

32%

23%

36%

40%

24%

43%

27%

21%

30%

31%

45%

33%

39%

17%

22%

30%

58%

58%

41%

49%

45%

40%

52%

38%

56%

52%

55%

54%

45%

50%

50%

3%

2%

4%

3%

3%

2%

4%

25%

33%

22%

22%

8%

4%

4%

5%

4%

5%

5%

4%

3%

17%

15%

8%

8%

7%

7%

8%

11%

7%

5%

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

通信・通信サービス(n=4)

電気・ガス・水道(n=6)


情報処理業(n=23)

放送・新聞・出版・印刷・映画(n=12)

繊維関連・紙・木材(n=24)　

電気機械製造(n=69)　

化学・薬品(n=57)　

建築・土木・鉱業(n=83)　

運輸(n=35)　

不動産・倉庫(n=29)　

農林・水産・食品(n=37)　

その他製造(n=79)　

鉄・非鉄金属・窯業(n=42)　

サービス業(n=71)　

商社・流通・卸売・小売(n=156)　

一般機械製造(n=58)　

石油・石炭・ゴム(n=6)


1.BCP(事業継続計画)を策定し運用しており、定期的に見直し更新している

2.BCP(事業継続計画)を策定し運用している

3.BCP(事業継続計画)を策定中である

4.BCP(事業継続計画)の策定を検討中である

5.BCP(事業継続計画)を策定する予定はない


図表 4-2-7 業種別事業継続計画（BCP）の策定状況


403

（３）事業継続計画（BCP）策定企業の災害発生後の業務再開目標時間

ａ．業務再開目標時間（RTO）の設定状況

災害発生後の業務再開目標時間（RTO）を定めている企業は全体の約 30％である。事業継続

計画（BCP）｢策定済み｣の企業であっても業務再開目標時間を定めている企業は、52％と半数の

企業に過ぎない（図表 4-2-8、図表 4-2-9 参照）。業務再開目標時間を設定していない企業にその理由を聞いたところ｢社会インフラの復旧状況

に依存するため｣が 62％とも多くなっている。社会インフラ及び公共機関の事業継続計画に関

する情報公開が進めば、業務再開目標を設定しやすくなり各企業の業務再開目標時間（RTO）を

設定する企業の割合が改善される可能性が高くなると推定される（図表 4-2-10 参照）。

（2005 年事業継続計画（BCP）と IT 防災に関するアンケート調査）1

図表 4-2-8 BCP 策定企業における業務再開目標時間の設定状況

（2005 年事業継続計画（BCP）と IT 防災に関するアンケート調査）

図表 4-2-9 BCP 策定状況と業務再開目標時間の設定状況

1 「事業継続計画（BCP）と IT 防災に関するアンケート調査」。2005 年に(株)エヌ・ティ・ティ建築総合研究所と(株)三

菱総合研究所が大手企業（東京証券取引所一部上場企業、国内非上場従業員 1000 人以上、外資系企業従業員 1000 人以上）

1865 社（回答 243 社）を対象にして実施した結果が報告されている。


404


図表 4-2-10 BCP 策定状況と業務再開目標時間の設定状況

ｂ．業務再開目標時間（RTO）は業種によって差が大きい

業務再開目標時間は（RTO）、放送、通信、金融の一部で 1～6 時間と非常に短い時間設定を行

っている企業がある一方で、製造業や流通業では１ヶ月以上と比較的長期に設定している企業も

ある。業務再開目標時間を設定している企業の平均は約 2 週間（13 日）となっている。災害の度

合いにもよると思われるが、阪神・淡路大震災での教訓から業務再開目標時間を短縮する対策を

考えているといえる（図表 4-2-11 参照）。


図表 4-2-11 業務再開目標時間の分布


405

（４）アウトソーシングしている企業は｢丸投げ｣傾向

「事業継続計画（BCP）と IT 防災に関するアンケート調査」によると、情報システムをアウ

トソーシングしている企業のうち、｢自社運用基準を定めて指示している｣と回答した企業が 2 割

弱となっており、情報システム運用の｢丸投げ｣傾向が見受けられる。アウトソーシング会社『丸

投げ』から、自社基準運用基準を設けてアウトソーシング者と SAL を締結して事業継続計画

（BCP）の遵守が必要である（図表 4-2-12）。


図表 4-2-12 アウトソーシングしている情報システムの管理状況

（５）自社対応の情報システム防災対応はまだ不十分

「事業継続計画（BCP）と IT 防災に関するアンケート調査」によると、IT 設備（サーバ、ル

ータ等）とその IT 稼働環境（サーバ室の電源、空調等）の両方を考慮した対策が不足している

傾向が見られる。これは IT システムと建築設備の対策が個別に行われており両方の視点を持っ

て情報システムを包括的に検討する体制が不十分であると考えられる（図表 4-2-13）。


図表 4-2-13 自社で対応している IT 機器への防災対策


406

（６）IT システムの保全対策状況

「事業継続計画（BCP）と IT 防災に関するアンケート調査」によると、サーバルームを管理

している企業のうち、｢システム復旧の訓練を実際に行った事がある｣企業は 25％に過ぎず、実効

性に課題を含んでいる。訓練で実際にシステム復旧をしてみなければ、想定している手順が妥当

とはいえない可能性がある。（図表 4-2-14 参照）


図表 4-2-14 IT システムの保全対策


407

３．事業継続計画（BCP）策定と実施及び運用

事業計画（BCP）の策定～実施～運用が、一度限りでなく、日々刻々と変化するビジネスへの

対応、業務改革や IT システム更改を事業継続計画（BCP）に反映されているか継続的に実施さ

れなければならない。『計画倒れ』とならないようにしないと、いざ緊急事態が発生したときに対

応ができないことが推測される。

（１）事業継続計画の目的

事業継続計画（BCP）の目的は、災害やシステム障害などの緊急事態が発生した時、企業の重

要な事業が中断して顧客信用が落ちマーケットシェアの低下を招き、結果業績不振となり、事業

縮小や雇用削減に陥り、地域経済も低下する『負のサイクル』にならないように、事業が許容範

囲内で継続できるか、中断しても許容範囲内に復旧できるような施策を行い、『顧客からの信用』、

『従業員の雇用』、『地域経済の活力』を守り企業の価値を継続して維持することを目的とする（図

表 4-2-15 参照）。

事業継続計画の策定・運用

事業の継続を図る

緊急事態発生

顧客から信用を守る

従業員の雇用を守る

地域経済の活力を守る

企業の価値を継続維持させる

（経済産業省中小企業 BCP 策定運用指針より抜粋）

図表 4-2-15 事業継続計画（BCP）の目的

（２）事業継続計画（BCP）サイクルの確立

事業継続計画（BCP）の策定に止まらず、策定した内容に基づき運用体制が BCP サイクルで

きちんと回るように推進する必要がある。『危機に強い企業』となるためには、日々刻々変化する

ビジネス環境や IT システム更改に伴う変化を事業継続計画（BCP）に反映できる組織と事業継

続計画（BCP）策定～運用が Plan-Do-Check-Action サイクルが継続的に推進されることが必要

である（図表 4-2-16 参照）。


408

BCM（Business Continuity Management）サイクル

リハーサル訓練

リスク対策システム構築

見直し

BIA分析

リスク分析

BCP策定基本方針

《プロジェクト》《運用体制》

定期的な実施

ビジネスの変化 ITの変化【環境の変化】

◆ビジネスドメインの変化◆合併、提携、分割

etc.

◆ITの変化◆IT構成の変化◆システム再構築 etc。

Plan Do

Action Check

図表 4-2-16 事業継続計画（BCP）の管理サイクル2

（３）事業継続計画の行程

事業継続計画を進める工程は、a～ｈの工程で進められる。以降では、各工程のポイントを述

べる。

ａ．方針の決定経営戦略にそって災害やシステム障害が発生した場合を想定して、重要な事業がどのように継

続が可能か、事業の中断が企業に及ぼすリスクを考慮して、重要事業の選別、事業の許容操業度、

事業中断時の復旧許容期間、復旧優先順位など経営者を巻き込んで基本方針を明確にする。重要な業務を洗い出し、業務一覧表（図表 4-2-17）に纏め、障害発生時に主要業務の責任者、

代行者、協力会社への連絡網等を主要業務連絡網（図表 4-2-18）にまとめて完備して置く事が重

要である。障害発生時の対応者の権限等も事前に複数の代替えを考慮してドキュメント化をする。

組織や人事異動に伴い、常に新となるように配慮して更新ルール化、棚卸しを行う必要がある。【参考テンプレート：業務継続マネージメント入門書より抜粋】・業務一覧表（図表 4-2-17）・主要業務連絡網（図表 4-2-18）

2 BCM（Business Continuity Management）は、事業継続計画（BCP）が推進されるように、事業継続管理を実施すること

である。


409

図表 4-2-17 業務一覧表

（『事業継続マネージメント入門』共立出版より）

作成日/更新日

BCMT責任者

項番優先順位

1

2

3

4

5

部門の主要使命と目標

業務名業務内容

部門責任者

会社の使命と目標

BCP名業務一覧表

部門名

図表 4-2-18 主要業務連絡網


項番リソース

1

2

氏名：住所：勤務先電話：E-Mail：携帯電話：自宅電話：緊急時役職：


会社名：所在地：【担当者】氏名：、役職：、電話：、E-Mail：、携帯電話：【代行者】氏名：、役職：、電話：E-Mail：携帯電話：

作成日/更新日

BCMT責任者

責任者代行者協力会社



会社名：所在地：【担当者】氏名：、役職：、電話：E-Mail：、携帯電話：【代行者】氏名：、役職：、電話：、E-Mail：、携帯電話：

部門責任者

主要業務-A

BCP名主要業務別連絡網

部門名


410

ｂ．分析災害やシステム障害が、重要な事業中断に及ぼすビジネスインパクト分析（BIA：Business

Impact Analysis）をする。ビジネスインパクト分析手法は、影響度（高、中、低の三段階）と発

生率（高、中、低の三段階）との関係で分析を行い、影響度も定量的影響（停止時間を数分、数

時間、数日、数週間、数ヶ月に区分して）と、定性的な影響（お客、供給者、従業員、法遵守等）

を合わせて分析する。・地震、洪水、台風などの自然災害や停電、断水、通信、ガス供給停止、重油などの燃料供給

停止等社会インフラ災害によっての事業継続への影響を分析する。・自然災害や社会インフラ災害による重要な業務システムへの影響度とシステムの障害時への

対応状況を把握して、事業継続への影響を分析する。・ビジネスインパクト分析と業務の IT 依存度（IT が稼働しない場合にどのように影響を与え

るか）を分析する。・多数のアプリケーションシステムの全てを対象にするのでなく、重要性な業務を継続するための重要性の高いシステムを選定して、優先順位をつけて取り組む必要がある。

・重要な業務のシステムを選定しても、そのシステムだけでなく様々なシステム関連性（相互依存度）も合わせて分析する必要がある。対象システムだけでなく様々なシステムも含めて

同時稼働をさせなければならないシステムについての依存度を分析する。・システム事態の障害とシステム障害対応状況を把握し事業継続への影響を分析する。・災害や障害発生時に協力会社へ依頼する内容や契約状況を、把握できるようにドキュメント化しておく必要がある。契約状況がわからないとどの協力会社に依頼すべきか、何処まで依

頼が可能か判断できなく、対応の遅れが発生する。【参考テンプレート】・リスク分析表（図表 4-2-19）・システム影響度表（図表 4-2-20）・システム区分表（図表 4-2-21）・IT 協力会社一覧表（図表 4-2-22）


411

図表 4-2-19 リスク分析表


作成日/更新日

BCMT責任者

項番リソース又は

プロセスクリティカル

リンクリスク顕在時の結果予測

影響度(高、中、低)

発生確率(高、中、低)

予備状況（短/中/長）

1

2

3

4

5

項番リソース又は

プロセスクリティカル

リンクリスク顕在時の結果予測

影響度(高、中、低)

発生確率(高、中、低)

予備状況（短/中/長）

1

2

3

BCP名リスク分析表



部門責任者

部門名

主要業務-A

主要業務-B

図表 4-2-20 システム影響度表


作成日/更新日

BCMT責任者

RTO RPO ユーザ数関係部署優先順位主要アプリケーション

BCP名システム影響度表



部門名

部門責任者


412

図表 4-2-21 システム区分表


B2

高 B3 C１ D1

C4

A4 C2 A2 D3 E5

中 A5 E3

E1 E2 B4 D4

A1 A5 A7 D2 B5 C5

低

B1 C3 D5 E4 A3 C6

低中高

発生確率

作成日/更新日

BCMT責任者

システム区分表

影響度

BCP名

部門名

部門責任者

レベル３と２のリスク区分基準レベル２と１のリスク区分基準

リスク分析の業務番

号、項番


413

図表 4-2-22 IT 協力会社一覧表


作成日/更新日

BCMT責任者

注文番号協力会社製品/サービス代替会社

適用範囲（協力会社が関与するＩＴ業務範囲）

システム概要(関連するＩＴコアシステム)

部門責任者

目的(協力会社が関与する業務の明確化)

BCP名ＩＴ協力会社一覧表

部門名

ｃ．設計システム障害や災害によって、業務停止にならないように色々なケースを想定して、許容操業

範囲を下回るボトルネックを洗い出す。・自然災害や社会インフラの災害を想定した、ネットワーク障害の代替やコンピュータセンタ

ー、コンピュータサーバ室の代替え等、重要システムの何を何処まで実施するか業務プロセ

スとシステムのプロセスを一元化して代替えを考慮する。・停電時に対応できるようにコンピュータセンターやコンピュータサーバ室などに、電源を供

給できるように自家発電装置を設置し停電に耐え得るように考えられている。しかし大規模

地震や洪水、台風などによる道路遮断によって備蓄燃料がなくなり自家発電装置へ供給する

燃料が途絶えてしまうことが想定される。自家発電の備蓄燃料を何日分確保するか、自家発

電用燃料の供給できる道路ルート確保、近隣のスタンドからの供給など色々な対応方法を検

討する必要がある。想定する障害や災害を一面だけでなく多面的な検討が必要である。・地震や停電、通信の障害でもシステムを稼働させるために、遠隔地のシステムに半自動的に

切り替えることができる遠隔クラスタの機能を有するシステムの導入を検討する（銀行 ATMシステムなど）。

・システム障害に対応できるように、データのリカバリを考慮する。 A）データのリモートミラーリング機能を有するシステムの導入 B）データバックアップの採用（RPO を考慮したバックアップ時期と手法、保管場所の考慮） C）クラスターシステムの導入


414

ｄ．構築設計に基づき、IT インフラ基盤の標準化を進め、保守運用費用の軽減が可能なシステムの構築

を図る。特に稼働しているシステムと連携して再構築を行う場合は、事業継続への影響を把握で

きるようにシステムカットオーバー前に確認テストを実施しておく必要がある。事業継続に関す

るシステムのボトルネックがないかのテストも漏れずにする必要がある。これをきちんと実施し

ないと、システム障害で原因解明に時間がかかり長時間業務停止となることがある。

ｅ．運用重大なシステム障害が起きないように、運用と事前保守に留意をする必要がある。特にヒュー

マンエラーに起因する運用ミスが起きないように、運用要員の教育とモラル向上を図る必要があ

る。重大な障害が発止した場合を想定した訓練を定期的に実施して、訓練結果の評価を行い、方

針、分析、設計、構築へフィドバックして改善を図る。

ｆ．運用の見直し訓練の実施結果の反省を行い、再改善すべき事項を洗い出し、現時点での課題の対策を・システム障害の漏れの再点検の実施システム障害の漏れがないか、BCP（事業継続計画）の

チェック内容に基づいて実施する必要がある。・システム構築・更改のチェック体制システムを全面的に再構築する場合は、BCP（事業継続計画）との整合性を見直すことが重要

である。特に情報戦略、企画時にきちんと方針を確定して望まないと、個々の部分適となり、

全体適とかけ離れた内容となってしまう。


415

ｇ．再分析、ｈ．方針の見直し運用の見直しを受け、方針やビジネスインパクト分析、IT 依存度分析の再見直しを行い、ビジ

ネスドメインの変化やシステム構築や IT 技術の変化によって事業継続計画（BCP）再見直しを

行い、事態に即した投資対効果が現れる施策、実行、運用サイクルを確立する（図表 4-2-23 参照）。

図表 4-2-23 事業継続計画の工程

1.≫全社BCP

方針策定

2.≫BIA＆リスク

業務IT依存度分析

3.≫障害対策

システム検討

4.≫災害対策

システム構築

5.≫災害対策

システム運用

方針分析設計構築運用

③.≫BCP文書化

②.≫BIA＆リスク

可視化文書化

①.≫経営戦略との

整合性確認

6.≫見直しの実施

8.≫全BCP方針

のズレ見直し

④.≫リハーサル

訓練

7.≫再分析

BIA&IT変化の見直し

■経営層の積極的関与

■業務縮小・再開の指針・許容度

■過大投資回避

■BIA（ビジネスイ

ンパクト分析）と業務再開のボトルネックを探す

■業務の重要性分析

■障害発生訓練の継続実施

■訓練の反省を踏まえた見直しの実施・フォロー

■ボトルネック解消■事業再開の

期間許容度・操業許容度を満足させる

■DR仕組導入■バックアップ仕組

構築■運用要員育成


416

（４）事業継続計画（BCP）のサイクル運用体制フローの確立

事業継続計画（BCP）は、BCP 基本方針の立案と BCP サイクルの運用体制を確立する事が求

められる。事業継続計画（BCP）を策定しても運用体制が不備で実際に発生したときに対応がで

きなければ『絵に描いた餅』状態であり、策定してからの定期的な見直しが（BCP サイクル）が

されず古いままの状況では事業継続計画が効果を発揮できない事があり得る。BCP 基本方針に基

づき刻々と変化する事業内容や社会環境に合わせて BCP サイクルが継続運用できる体制が望ま

れる。阪神・淡路大震災からかなり年月が経過しており、新潟地震や台風による洪水災害、近

関東地区で発生した停電など災害が頻繁に発生しているが、事業継続計画（BCP）への見直しが

継続的に行われている企業が少ない。特に 2000 年問題でのシステム再構築から、システム費用削減要請による大型ホスト削減、基

幹システムのオープン化への再構築等、システム環境が急激に変化している。事業継続計画が継

続的に行われていれば、既にこの節の第 1 項の（４）で紹介した「図表 4-2-5 経済活動に大き

な影響を及ぼしたシステム障害事例」と同様な事故が防げていたと推察される（図表 4-2-24 参照）。

BCP基本方針立案

BCPサイクルの運用体制確立

緊急事態発生

緊急事態発生

BCPの発動

BCPの発動

BCPサイクルの継続運用

緊急時・復旧時平常時

新たな課題に基づく更新（収束後）

図表 4-2-24 事業継続計画のフロー


417

（５）事業継続計画（BCP）導入のポイント

事業継続計画（BCP）導入のポイントを以下にまとめる。事業継続計画（BCP）の方針やビジ

ネスインパクト分析を一生懸命行っても、リスク回避の対策ができていないと絵に描いた餅とな

り、災害が発生時に効果が発揮できないことになる。

ａ．最初から欲張った事業継続計画をしない重要な業務の継続に影響のある部分を対象範囲が狭くても、完成度が低くてもまずは短期間で

具体的な形にして、欲張った事業継続計画（BCP）をしない。少しずつでも事業継続計画を実施

し、段階的に適用範囲を広げて改善を継続的に実施して行くことが重要である。

ｂ．目的を明確にして、対象業務を絞り込む何の発生をも避けたいのか、それをどうやって食い止めるのかをベースとして、対象業務を

極力絞り込んで優先順位をつけて実施する。

ｃ．ビジネスインパクト分析（BIA）の必要性を見極める・も重要な機能や各機能の優先順位を明らかにする。・個々の機能に対する大許容中断期間を見つける。・事業の継続・復旧に関する資源の状況把握をする。・重要な機能の継続・復旧に係わる社内外の依存関係を明らかにする。上記の内容が厳密に把握できていなくても、概要がわかり社内コンセンサスが得られる内容で

進める。

ｄ．自社にあったやり方で進める事業継続計画（BCP）のガイドラインの標準的な工程に拘らず、使える部分を上手に活用して

自社に合ったやり方で進める。

ｅ．事業継続計画（BCP）の改善サイクルを確立する事業継続計画（BCP）のサイクルの何処からでも始め、継続的に改善することを初から念頭

に置いて取組み事業継続計画（BCP）フローサイクルを確立する。


418

４．基幹務システムのバックアップシステム状況

システム信頼性・安全性を確保するためにユーザー企業で実施している施策について述べる。

（１）基幹システムのバックアップ施策

バックアップ機が基幹系で 4 割しか採用されていない。6 割が１重系で稼働しているのが現状

である（図表 4-2-25 参照）。企業規模別に見ると、大企業は 66％が 2 重系で稼働しているが、中

堅企業では 42％で、小企業は 25％と企業規模によりバックアップ機の導入に差が見られる（図

表 4-2-26 参照）。システムインフラを担っている企業は、二重化やディザスターリカバリを含めてバックアップ

に関しての取組みがなされているが、業種や企業規模によっての差が顕著に表れている。銀行・

通信業などは、システムの障害が即利用者への影響が大きいので二重化、ディザスターリカバリ

対策が行われているが、製造業では、システム障害が発生してもある時間内（約 4 時間程度）で

復旧が可能であれば、事業継続計画（BCP）の対象とされていない。したがって、業種や企業規

模によって各々システムのリスク分析を十分に実施して、事業継続直接に影響する業務再開目標

時間（RTO）、障害回復ポイント（RPO）を考慮して、バックアップシステムの選定をする必要

がある（図表 4-2-27 参照）。

12%

11%

36%

36%

51%

52%

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

①基幹系システム

②情報系システム

複数箇所で多重化している 1箇所で多重化している 1台のみ


図表 4-2-25 バックアップマシン所有状況


419

6%

9%

20%

33%

46%

65%

58%

34%

29%

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

100名未満

100～1000名未満

1000名以上

複数箇所で多重化している 1箇所で多重化している 1台のみ


図表 4-2-26 企業別基幹系バックアップマシン所有状況（基幹系）


図表 4-2-27 業種別バックアップマシン所有状況（基幹系）

12%

0%

7%

7%

6%

13%

4%

5%

8%

18%

10%

11%

8%

15%

17%

50%

0%

50%

31%

32%

36%

14%

24%

26%

29%

26%

35%

41%

39%

30%

38%

41%

47%

42%

42%

25%

80%

33%

54%

53%

51%

86%

69%

67%

65%

62%

62%

54%

53%

53%

53%

48%

44%

42%

42%

25%

20%

17%

15%

15%

総計（N=901）

輸送機器・関連部品（n=29）

不動産・倉庫（n=29）

一般機械製造（n=58）

電気機械製造（N=69）

鉄・非鉄金属・窯業（n=47）

繊維関連・紙・木材（n=26）

農林・水産・食品（n=37）

化学・薬品（n=59）

建築・土木・鉱業（n=80）

商社・流通・卸売・小売（n=160）

その他製造（n=83）

運輸（n=36）


情報処理業（n=24）

通信・通信サービス（n=4）

石油・石炭・ゴム（n=5）

電気・ガス・水道（N=6）

放送・新聞・出版・印刷・映画（n=13）

銀行・保険・証券・信販（n=62）

複数箇所で多重化している１箇所で多重化している 1台のみ


420

（２）システム障害を削減する施策

JUAS の 2006 年度 IT 部門インタービューから、システム障害の回避や障害回復時間安短縮の

施策に対し、以下のような留意すべき事項を得ている。ａ．ハードウェア・ネットワーク等の十分なメンテナンスと冗長性の確保

・ハードウェア、ネットワークの二重化、定期的な保守点検・予防保守の徹底等・バックアップ機の二重化、ディスクのミラー化、RAID 化等の機器異常に対応できる冗長化

を検討する必要がある。特にハード機器は、故障発生が避けられないので故障しても復旧時

間を短縮できる仕組みを考慮することが重要である・CPU 本体だけでなく、電源の二重化（自家発電）も考慮する。二重化された電源を、サーバーだけでなく、ネットワーク機器、ディスク機器、事業継続に

重要な業務端末、空調に至る関係機器への電源供給・ネットワークの入口（ルータ）二重化ネットワーク機器とサーバー（LAN カードを 2 枚差しで LAN カード障害の即時対応）間の

二重化。・クラスターサーバの採用（CPU、Disk とも）、自動切り替え・サーバーの Raid Disk の採用・サーバー機器等の予備機器の準備（故障発生時に予備機器交換用）・バックアップしたデータは遠隔地に保管

ｂ．体制の充実・関係者間の定期的情報交換、トラブル情報の共有化、24 時間体制を導入して即対応、障害時

のリスク管理体制の強化など

ｃ．目標管理・開発・運用管理標準を 7 項目定め、これを元に実行して安全性を確保・トラブルを指数化し、判定基準を設け、何に影響が出たのかを把握。トラブルのレベルによ

っては経営報告を必要とする・SLA、SLM による管理｢リスク管理グループを作り、1 回／月トラブル撲滅運動を実施している｣

ｄ．作業の標準化、確認の徹底

・マニュアル化の実施・入念なチェック・運用の自動化促進・点検の実施と｢原因不明｣を放置しないこと


421

ｅ．ソフトウェア開発における信頼性の向上

・ソフトウェア構造の向上・システムアーキテクチュアの明確化や開発標準化の徹底

｢採用する技術については、社内に技術評価の体制があり、ここで十分吟味されて実システム

に活用されるため、技術面からのトラブルは発生しがたい｣等、示唆になる施策が挙げられる。

５．ディザスターリカバリ

近年、ディザスターリカバリの技術（ネットワーク、コンピュータ、レプリケーション、フェ

イルオーバ、バックアップ機器）が発達し、簡単に導入が可能となった。データセンター内での

障害回復（ハードウェア、ハードディスク、ネットワーク）は、バックアップ機や機器の二重化

などの対策を行うことで対応が可能であるが、地震・水害・台風などの自然災害や 2001 年 9 月

11 日米国で発生したテロなどによる被災でデータセンターが稼働できない場合を想定して、遠隔

地にバックアップ用のデータセンターを用意することである。これがディザスターリカバリ（DR）

である。（図表 4-2-35 を参照）

図表 4-2-28 ディザスターリカバリ技術の進化

ネットワーク

コンピュータ

レプリケーション

フェイルオーバ

DR技術

DR技術

バックアップ機器

・高速化・低廉化

・CPUの高速化

・低廉化・ストレージの大容量化・ストレージの低廉化

・高速化・大容量化・ストレージの低廉化（Tape→HDへの移行）

・クラスタリングの発展系でのサイト間フェイルオーバが可能な技術の提供

・レプリケーション製品の提供

推進技術


422

データセンターを用意してデータをどのように復旧するかによってディザスターリカバリ方法

が異なる。ハードウェアやソフトウェアは時間をかければ何らかの方法で回復することが可能で

あるが、データは企業固有の財産であり、いかなる災害や障害でも、データのバックアップを取

得して保管することが必要である。しかしバックアップデータが、自然災害やテロなどによる被

災したデータセンター内で保管されていると、バックアップデータが破壊され復元できなくなる

恐れがある。この解決方法として、遠隔地にバックアップセンターを用意し、災害やシステム障

害が発生した場合にバックアップセンターで代替え運転可能な予防対策が必要である。経済産業省「事業継続計画策定ガイドライン」セクション 2．3 を参考にすると、ホットディ

ザスターリカバリ対策の方法は以下の 4 種類に分類できる。・コールドサイト方式・ウォームサイト（データ更新なし）方式・ウォームサイト（非同期データ更新あり）方式・ホットスタンバイ、ホットサイト方式遠隔地のデータセンターにリアルタイムにデータを更新し障害発生時に自動的システムがバッ

クアップセンターに切り替わるホットスタンバイ方式、遠隔地にデータセンターのみ準備して、

障害発生時に機器やシステムを構築しバックアップデータで復旧するコールドサイト方式などが

ある。いずれにせよ、業務回復目標時間（RTO）と業務復旧時点（RPO）を考慮し、適なディ

ザスタリーリカバリ（DR）の仕組みを導入することが必要である（図表 4-2-28 を参照）。

ａ．コールドサイト方式（機器のスペースを予め準備）遠隔地にバックアップセンターのみ準備してバックアップデータを外部保管する。投資が安価

であるが、ハードウェア調達、システム構築、データリカバリに時間がかかり RTO（業務再開時

期）が遅くなってしまう（1 ヶ月～半年程度必要）。

ｂ．ウォームサイト（データ更新なし）方式（同等の機器を準備）遠隔地にバックアップセンターとハードウェアやシステムを準備して、バックアップデータを

外部保管する。災害や障害発生時に外部保管データからリカバリを行い復旧する。この方法は、

システムが複雑でなく投資費用は安価である。しかし RTO（業務再開時期）短縮には、リカバリ

人材の確保やデータ復旧に課題が残る（１週間～１ヶ月）。ｃ．ウォームサイト（非同期データ更新あり）方式（同等の機器を準備）

遠隔地にバックアップセンターとシステムを準備して、データを非同期であるが順次データを

更新しておく。データの更新方法により、オペレータの人件費やシステムでの更新方法の採用に

より運用費用がかさむが、RTO（事業再開時期）はかなり短縮が可能である。更新時期のサイク

ル前までデータが復旧しているので、災害や障害発生までのデータ回復で対応が可能である（１

日～１週間）。


423

ｄ．ホットスタンバイ、ホットサイト方式（同等の機器やシステムを準備、同じ動作を行う）遠隔地にバックアップセンターとシステムを準備して、データもリアルタイムに更新して、障

害や災害が発生した場合に、システムを切替て継続運転ができる。RTO（事業再開時期）をも

早く可能である（数分～数時間）。システムを監視して自動切替や手動切替、データのリアル更新

などシステムが複雑で構築費用が高いのが難点である。各ディザスタリ方式の選択は、事業継続計画の BIA（ビジネスインパクト）分析やリスク分析、

さらには投資対効果も鑑みて適な方法を決定する（図表 4-2-29、図表 4-2-30 を参照）。

Time（時間）

投資額

災害・障害

RPO(Recovery Point Objective)災害・障害発生時に過去のどの時点にデータを戻せるか

RTO(Recovery Time Objective)災害・障害発生から、業務再開するまでの時間

災害・障害発生時間からの業務再開を直後すると投資額が膨大になる。

災害・障害発生時間からのデータ復旧時点を直前すると投資額が膨大になる。

図表 4-2-29 災害対策の考慮すべきポイント

・システムセンタと同程度の環境をバックアップセンタに準備するため、オペレータが常駐する必要がある

・通常時は、システムセンタとバックアップセンタは同期をとる

・被災時は、バックアップセンタのシステムに切り替える

④ホット・スタンバイ、ホットサイト方式

・バックアップセンタとしての場所、復旧用マシンをあらかじめ準備しておく

・通常時は、バックアップセンタにて随時データの更新を行うため、オペレータが常駐する必要がある

・被災時は、バックアップセンターにてデータを新状態にする（データの更新作業は②データ保管型よりも時間はかからない）

③ウォームサイト方式（非同期データ更新あり）

・バックアップセンタとしての場所、復旧用のマシンをあらかじめ準備をしておく

・通常時はバックアップセンタデータ保管のみ行う

・被災時は、バックアップセンタにてデータの更新作業を行う必要がある。

②ウォームサイト方式（データ更新なし）

・バックアップセンターとしての場所だけを準備しておく

・被災時は、必要な設備・機器を調達し、外部保管しておいたバックアップメディアを搬入し、データのリストアを行い情報システムを復旧する。

①コールドサイト方式

《搬送》

システムセンタバックアップセンタ




被災時

N/w

N/w

《搬送》

データ

N/w

データデータ

更新

データ更新

データ

（『ITIL による運用管理の実際』より一部追記）

図表 4-2-30 ディザスターリカバリ（DR）復旧の仕組み


424

６．参考

図表 4-2-31 ホームページ参考資料一覧

発表

時期ホームページからの参考資料作成主体

１ 2005 年

3 月事業継続計画（BCP）策定ガイドライン http://www.meti.go.jp/policy/netsecurity/downloadfiles/6_bcpguide.pdf

経済産業省

２ 2005 年

6 月 BCP 策定ガイドラインの概要 http://www.meti.go.jp/policy/netsecurity/downloadfiles/6_bcpguide_gaiyou.pdf

経済産業省

３ 2005 年

8 月事業継続ガイドライン（第一版） http://www.bousai.go.jp/MinkanToShijyou/guideline01.pdf

内閣府

中央防災会議

４ 2005 年

8 月 BCP（事業継続計画）を作成する http://www.udri.net/portal/kigyoubousai/bcp.htm

財団法人

都市防災研究所

５ 2006 年

2 月中小企業 BCP 策定運用指針 http://www.chusho.meti.go.jp/bcp/

経済産業省

中小企業庁

425

第５章リスク管理・内部統制

第１節リスク管理態勢構築の基本的な概念

第２節リスク管理・内部統制を巡る様々な流れ（歴史編）

第３節リスク管理（実践編）

第４節内部統制（実践編）

第５節今後の動向─内部統制進化論─

427

第５章リスク管理・内部統制第１節リスク管理態勢構築の基本的な概念

リスク管理・内部統制は、いまだ日本企業にとって異文化の概念である。

この節では、「リスク管理とは何か」、「システムリスクとは何か」、「内部統制とは何か」、そし

て、「リスク管理で重要なこと」の 4 点について述べる。

なお、本書はシステム関連事項を対象としていることもあり、本編でもシステムリスクを中心

に記述する。ただ、「システムリスク＝経営リスク」という要素が強くなっていることから、リス

クの全体像についても常に捉える必要がある。

そのため、各事項とも、「全体像を簡単に示しながら、システム部分を掘り下げる」という構成

とした。

１．はじめに

２．リスク管理とは何か（守りの IT 戦略の担い手）

３．システムリスク（IT リスク）とは何か

４．内部統制（Internal Control）とは何か

５．リスク管理で重要なこと

５－１リスク管理態勢構築の基本的な概念

428

１．はじめに

IT ガバナンスという概念は、様々なところで論議された結果、重要性が認識されてきているが、

近は新たに内部統制というキーワードが急浮上している。内部統制は決して新しい概念ではないが、施行された会社法の中で、また経済産業省のレポー

トの中で取り上げられ、今後、金融庁の企業会計審議会での実施基準が固まれば、企業の IT 部

門にも大きな影響を与えることから、盛んに議論されている。その背景には、規制が緩和されて自由競争の時代を迎えていること、および複数の金融機関で

の不祥事件や、金融以外でもシステム障害や隠蔽によって社会の信用を失った事件がある。企業は、経営理念に照らして管理すべき目的を明らかにしてそれに即した対策を講じるととも

に、襟を正して法律や策定されたルールに則って業務運営を遂行しなければ、存続し得ない時代

に入っている。その中でも、システムが経営の多くの活動において必須のツールとなり、システムの不具合が

そのまま経営陣の記者会見での謝罪や社長交代にまで及ぶ時代になったことに鑑みると、システ

ム部門がガバナンスの一翼を担う重い責任を全うしなければならなくなった。 JUAS では、「IT 法務」という新しいテーマを中心に、システム部門が経営や法律に絡んでい

く様々な接点で発生する課題を、システム部門および関連する部門の第一線の方達と３年にわた

って論議し、自社に適用できるところまで落とし込む研究会活動を進めてきた。具体的には、開発プロジェクトを成功に導くための発注契約の在り方、個人情報保護法対応、

そしてリスク管理と米国企業改革法対応の基本的な考え方等である。本論は、システムに関するリスク管理や内部統制を軸に、様々な概念の鳥瞰図を描きながら、

自社の業務運営の中で知っておくべき事項について記述する。このテーマでは、他社の事例セミナーで聞いたベストプラクティスの良い所取りを自社に適用

したり、目の前にある気がついた欠陥の応急措置だけを繰り返していても、企業を本質的に改革

することはできない。監査人や法律家等の専門的なアドバイスも参考に、自社の身の丈にあった PDCA の仕組みを日

常業務にビルトインして「リスク文化」を醸成していくために、経営と各組織が一体となった地

道な活動を展開していくことしか解決策はない。言い換えると、足腰も鍛えられておらず、応急手当の包帯だらけの力士には力強さを感じられ

ないのと同じで、企業の五臓六腑を健全に保ち、怪我をしない健全な身体を日々鍛錬することが

ベースにあると言うことである。

./keyword.htm#1601


429

２．リスク管理とは何か（守りの IT 戦略の担い手）

リスク（RISK）という言葉は、昔から、経済学や経営学などの分野で様々に定義されてきた

が、近は、金融分野の話題を中心に、新聞の見出しにも載るように一般化してきている。しかし、リスクは、日本人にとっては何となくわかっても、やはり観念的で苦手な概念ではな

いだろうか。日本にはなかった概念という心構えで論じていく必要がある。リスク（RISK）は、“RISICARE”(あえて～する)という古イタリア語から派生したそうであ

るが、様々な定義が唱えられている1。厳密には、HAZARD や PERIL などから説き起こすことになるが、まずは、企業にとってのリ

スクに絞ることにする。一言で言えば、「企業にとってのリスクとは、経営資源に対して、不確実性によって影響をもた

らすと思われる事態の発生要因およびその影響」という表現が妥当かと考える。なお、ここでいう影響には、損失、障害に加えて収益機会や事業戦略等の不確実性による影響

も含み、経営資源は、組織の構成員の能力や生活と健康などの人的資源、不動産施設などの物的

資源、有価証券などの金銭的資源、情報・技術・文化などの無形の資源、さらには、企業の置か

れている社会的地位や経済環境をも含む広い概念である。企業の立場に立ったリスク管理とは何かについて、経済産業省のレポートでは、以下のように

定義している2。『（リスク管理とは、）「企業経営者が企業経営を行い利益を追求していく上で、企業を取り巻く

様々な事象が抱えている不確実性（企業経営にマイナスの影響を与える不確実性だけでなく、プ

ラスの影響を与えるそれも含む）というリスクに個々に対応するのではなく、経営理念、事業目

的等に照らして経営に重大な影響を及ぼすリスクを企業経営者が認識・評価し対応していくマネ

ジメントの一つ」とする。このようなマネジメントは、リターンを得るためにはリスクは不可避

であるという観点から企業経営そのものであるという面があり、すなわち、経営を取り巻く様々

な不確実性（リスク）を如何にコントロールし、利益を大化していくかという、企業経営をリ

スクの視点から見たものとも言える。』こうした要点が盛り込まれていれば、自社で使い慣れた用語などあれば取りいれて、分かりや

すくすれば良いと考える。理解するのに、いつも手元にマニュアルを置いて、定義を調べないと身につかない抽象的で複

雑な用語にすると、結局社内の組織の末端まで浸透するのは難しくなるので、その点が注意事項

である。なお、シンプルな表現としては、「リスク管理とは、リスクの顕在化による企業活動への影響を

抑制するための一連の活動」と定義するのがお勧めである。参考までに、JIS 規格（付録１「JIS 規格での定義」参照）でのリスクの定義を見ると、「事態

の確からしさとその結果の組み合せ、又は事態の発生確率とその結果の組み合せ」という表現に

なっている。

1 【文献 8】「企業価値向上のためのコーポレートガバナンス」P75 2 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P4


430

要するに、影響度（damageability）と発生頻度（frequency）の 2 つの要素で構成されている。リスク管理について、同じく JIS 規格では、「リスクマネジメントは、リスクに関して、組織

を指導し管理する調整された活動」としている。この定義は、一般的過ぎて、「企業活動（経営理念、事業目的等）」、「リスクの顕在化（影響・

認識・評価）」というキーワードがない。企業にとってのリスクの種類と言う観点からは、①コアリスク、②付随的リスク、③受動的リ

スク、の 3 つに分類することが考えられる。

図表 5-1-1 リスクの区分

リスクの区分内容

①コアリスク企業の事業活動の一環として、利潤の追求、収益の対価として意図的に積極的にと

るリスク

②付随的リスクコアリスクをとる事業を遂行してゆく上で付随的に発生するリスクでオペレーショナルリ

スク（事務・システムリスク等）

③受動的リスク上記2 つのリスクに対し、自らの意図には関係なく存在するリスクで、外部要因や外部

環境の変化によって被害を受けるリスク

上記①②の動態的リスクに呼応して、③は静態的リスクとも呼ばれ、企業一般に共通するリス

クで、その大半は危機管理の観点から取り上げられるリスクでもある。「③受動的リスク」を例示すると以下のとおり。例：自然災害（地震、噴火、津波、異常気象など）、犯罪・事件（爆破、脅迫、誘拐、強盗、毒

物混入、テロ）、環境・公害（廃棄物処理、水質汚染、大気汚染、騒音、海洋汚染など）などこうしたリスク事例を元にブレーンストーミングで自社のリスクを洗い出して同じカテゴリー

のものをまとめていく方法、本書で取り上げる不祥事案や過去の新聞での事例を自社に当てはめ

てより具体的に洗い出していく方法などで、自社のリスクを整理して、現状に合った分類のカテ

ゴリーを定義していけばよい。リスク管理を実行する局面になると、整理したカテゴリーと社内組織がリンクして責任部署と

なっていくために、一般論の分類を当てはめてもすぐに見直しが必要になる。大切なのは、自社の重要リスクが網羅されていれば、形式的にならないことである。リスク管理の概念を理解するために重要な以下の 2 つのことを、説明する。


431

（１）リスクベースアプローチ

リスクベースアプローチとは、次のように説明できる。 ①リスクを見る視野を当該分野に限定せず経営の視点で見る ②個別のリスクを管理するに当たり、そのリスクの発現の可能性、発現した場合の被害の大き

さなどから、経営の受けるダメージを測る ③測ったダメージの値に応じたリスク対策を行っていくすなわち、リスクが少なければ予防・軽減策に大きな負担はかけず、危機管理対策も講じない

が、発現に相当程度の蓋然性があり影響も大きければ、予防・軽減のために相当規模の投資を行

うというように、リスクの大小に応じメリハリをつけたリスク対策を講じるというものである。経営の観点に立てば、リスクが経営に与えるダメージを分析・評価し、経営として容認できな

いリスクのみに絞り込んだうえで、顕在化した時のダメージの程度に応じた対策を講じることで

ある。例えば、経費の誤払い防止の仕組みに大きな問題がなければ、高給な管理職がチェックするコ

ストと予想損失額とのバランスも考え、都度の現場での文房具購入などの小額なチェックはせず

に営業活動に専念させるということも有りうるということである。

モニタリング重視

ルールの遵守状況や、対

策の有効性のチェックに

ついて十分に考慮する

現実主義

リスクの大きさに応じて

対策の強度と優先順位を

変更していく

2000年頃以降

実効性を問わない

モニタリングを十分に行

わずに「あってはならな

い事」等で片付けてきた

対策やルールの

実効性担保

完璧主義

狭い目的に照らした理想形の

みを示すことにとどまり、そこ

へ至る過程や他の経営目標

とのトレードオフを考慮しない

1990年頃まで

対策やルール

に求める水準

モニタリング重視

ルールの遵守状況や、対

策の有効性のチェックに

ついて十分に考慮する

現実主義

リスクの大きさに応じて

対策の強度と優先順位を

変更していく

2000年頃以降

実効性を問わない

モニタリングを十分に行

わずに「あってはならな

い事」等で片付けてきた

対策やルールの

実効性担保

完璧主義

狭い目的に照らした理想形の

みを示すことにとどまり、そこ

へ至る過程や他の経営目標

とのトレードオフを考慮しない

1990年頃まで

対策やルール

に求める水準

図表 5-1-2 リスク対策のパラダイムシフト


432

リスクベースアプローチという損害保険の考え方が、一般にも受け入れられてクローズアップ

されてきた背景には、20 世紀の建前を重んじた「完璧主義」（トラブルや障害はあってはならな

いと片付けてきた）から、21 世紀に入って取り巻く環境が厳しくなって足元を見ていかざるを得

ない「現実主義」（リスクの大きさに応じて対策の強度と優先順位を変更していく）へ、パラダイ

ムシフトが起きてきたことによる。パラダイムシフトの歴史的な背景については、本章の２節「歴史編」で、欧米および日本のリ

スク管理の流れを読んでいただきたい。経済産業省のレポートにおいても、以下のように記述されている3。『業種業態や規模等により企業ごとにリスクは異なるし、経営戦略や事業目的によってそれぞ

れの事象が企業経営に与える影響は異なるが、それらをトータルに認識・評価し､対応していくこ

とが必要である。また、米国で実態として問題となっているような重要性の低いリスクも含めて

一律的に対応するといったアプローチ（米国において実態として重要性の低いリスクに対する内

部統制についてまで検証が求められていることについて、企業活動への過度な負担となっている

という意見があった。）を取るべきではなく、その中でどのリスクが経営戦略や事業目的に照らし

て重大なものと考えるかを企業経営者が認識し、その重要度や発生可能性等を勘案して対応して

いくことが重要である。』

（２）リスクの認知・予測の歪み

リスク管理の専門家と素人である一般人とのリスク認知の仕方に食い違いが発生することを

「リスク認知のバイアス」と呼び、研究成果が報告されている。考え方は、リスク専門家のリスク判断を科学的で客観的な基準として受け入れ、その基準と比

較して素人の判断がどのように歪んでいるかを検討しようというものである。リスク管理の専門家でさえ発生しやすい判断の歪み（偏り・誤差・ミス）を回避するヒントと

して興味深く、著者の経験とも良く一致している。多少の解説を加える。 ①『リスクとつきあう : 危険な時代のコミュニケーション』4では、イソップの「酸っぱいブ

ドウ」という寓話を例えに引いている。「キツネがおいしそうなブドウを取ろうとしたものの手が届かないので、あのブドウは酸っ

ぱいに違いないと考え直して諦めるという話であるが、人は誰でも、こうして、自分の認知

の不協和音を解消するために、認知を変更し、不快な状態を脱すると言う心理が働くと言う

ことである。」この心理がリスクに適用されると、自分が係るリスクに関しては、「自分には降りかからな

い」とリスク認知を変更して、認知度を下げていくということになる。結果として、リスク

が高い事象でも、リスク回避行動を妨げ、情報をいくら伝えても効果がない。経営者の謝罪の記者会見で、「まさか自分の会社で起きるとは思わなかった」、「（知らされ

ていたにもかかわらず）知らなかった」という表現がまだ見受けられる。自社の悪い情報は

聞きたくない、聞いても一時だけで通り過ぎる、というのは人間の心理であるというリスク

3 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P31 4 【文献 3】「リスクとつきあう : 危険な時代のコミュニケーション」


433

認知の示唆は肝に銘じる価値がある。そして、欧米人（米・仏）と日本人のリスク心理の調査5に拠れば、日本人は欧米人に比較

して、「世の中は危険であっても、自分達に災いが及ぶことはない。自分達は安全だと漠然と

考えている」との結果である。欧米に比べて、より安全な生活をしているからであろうか、リスクの概念が日本人に浸透

していない１つの証拠でもある。 ②報道の量や話題性が大きくリスク認知に影響しやすいので、リスクを分析するときも、感覚

ではなく、発現の可能性を数量的（デジタル）に捉えていく必要がある。このときの捉え方は、精緻なものというより、少なくとも桁数を合わせる程度のもので十

分である。逆に、世間で話題になっているリスクについて、認知が高くなったときに、経営に自社で

の発現の可能性および現在の対策状況をタイムリーに報告することで、リスクに関する関心

を高めることができるということでもある。こうした日頃の活動がなければリスク管理の重

要性を伝えていくことは難しい。 ③「リスクがある」という漠然とした言い方は、相手に不安を与えやすく、特にシステムリス

クのように技術的な要素が絡む場合には、専門家としての発現可能性や影響度予測について

の見解を添えて経営や他の部門に伝えることが重要である。システムリスクの生情報は、消

化不良を起こすことが多いと考えたほうが現実的である（殊に、ウイルス、ネットワーク障

害、情報セキュリティの技術的措置など）。 ④システムのことは、元々わかりづらいと考えている人に、初に十分な説明をせずにそのま

まにしておくと、いつの間にか、リスク管理のことを理解してもらうチャンスが訪れなくな

る。何か事件が発生したときを逃さずに、タイミングよく説明するように心がけることであ

る。 ⑤同じ文献の例にある「生存率 40％と死亡率 60％とは同じリスクの表現であるが、このよう

な同じリスクであっても、生存率で表現された治療法を患者が選択することが知られてい

る。」というとおり、ビジネスでも、ポジティブ・フレームで表現された選択肢の方を好む。例えば、プロジェクトの成功率という言い方はあっても、失敗率という言い方は好まれな

い。危ないプロジェクトであるが故に成功率 60％と言ったところで、受け手の脳裏には「成

功」という言葉しか残らずに後の 40％は捨象される。こうした場合には、「以下の各項目を

満たすことが成功する条件である」と、ネガティブフレームの要素を具体的に箇条書きで伝

えるとよい。 ⑥「プロジェクト開発担当が弱音を吐くようでは失格」という想いを誰もが抱いているため、

自分が一員として参画したプロジェクトが危なくなっても、リスク認知の魔術で、ネガティ

ブには考えられなくなる、言えなくなるというのも、示唆するところである。一人の人間に、守りと攻めを担当させることは、スーパーパーソンでもない限り難しい。守り

のスペシャリストであるリスク管理担当が、開発担当を支援することによって、プロジェクトが

ガラス張りになっていく（付録２「リスク認知・予測の歪みの事例」参照）。

5 朝日新聞 1995.6.1 夕刊 11 面「リスクの基礎力欠く日本社会」、および【文献 9】「企業のリスクマネジメント」P70


434

３．システムリスク（IT リスク）とは何か

各企業でのシステム開発の工程やシステム運用で実施している現実の業務の諸要素には業態の

差が少ないと言えるが、システムリスクについては、何処までを対象にするかなど、各社でかな

り考え方が異なる。この差は、業態の差や会社の個性ということでは片付けられない。特に対象範囲が違うと、そ

の結果や検討するときの体制も異なるなど、終の全体像が大きく異なって、対策も実を結ばな

くなるからである。リスク管理の目的は、個々のリスクに起因して経営リスクを顕在化させないことにあり、シス

テムリスクを、「システムの停止または誤作動」、あるいは「システムの不正使用」といった伝統

的なリスク形態の範囲にとどめてしまえば、リスク管理の実効性の面で、所期の目的が達成され

ないのは明らかである。システムに関連して発生する主なリスクをリストアップするだけでも次のようなものがある。・システム投資が適正に行われていないリスク・開発したシステムが所期の狙いどおりに活用されていないリスク・システム開発におけるプロジェクト管理が適正に行われていないリスク・システムの開発効率が適正レベルに達していないリスク・システムの運用効率が適正レベルに達していないリスク・企画、開発、運用の面で競争優位なレベルが保たれていないリスク・顧客情報等の機密情報が流出または漏洩するリスク上記に掲げたリスクは、システムリスクとは言っても経営リスクとしての性格をもったもので

ある。特に「システム投資」、「狙いどおりの活用」、「競争優位なレベル」に係るリスクはその傾

向が強い。これらをシステムリスクに分類するか、それとも経営リスクに入れるかは、必ずしも本質的な

問題ではない。どちらのリスクに分類しようと、重要なのは、システムリスクを特別扱いするこ

となく、企業としてすべてのリスクがきちんと管理されているかどうかである。もし、狭くしてしまうと、その定義に沿って展開していく対策に漏れが生じる。参考までに、著者が考えるシステムリスクの定義を次に示しておく。 ①情報システム（および通信ネットワーク）の停止または誤作動 ②情報システムの不正使用 ③情報システム関連のセキュリティ対策の不備 ④その他情報システムの企画・開発・運用にかかわる不備


435

４．内部統制（Internal Control）とは何か

「内部統制（Internal Control）」の言葉の解説については、付録３「「内部統制（Internal

Control）」という言葉」を参照してほしい。本章の第 2 節で COSO について詳述するが、内部統制の今日のデファクトスタンダードとして

用いられているのが、1992 年に策定された COSO フレームワークの定義である。 COSO フレームワークの定義の原文を下に引用したが6、内部統制に関する様々な概念を１つ

の文章で表現しようとするあまり、ややわかりづらい表現となっている。この文章を分解すると、

COSO フレームワークでは内部統制の内容や機能について以下のとおり定義していると言える。・内部統制とは、企業のあらゆる階層の人々が遂行するプロセスである。・内部統制は経営の目的の達成について合理的な保証を提供するものである。・内部部統制の目的は、①業務の有効性と効率性を確保すること、②財務報告の信頼性を確保

すること、③関連法規を遵守すること、にある。

内部統制というと、何か特別な仕組みやシステムを構築し、日常業務に過剰な負担がかかって

くると理解されがちであるが、COSO フレームワークの定義では内部統制の本質が「企業のすべ

ての人々が遂行するプロセス」であるとした点がまず注目される。当時、内部統制は経営者や管理者が行うものという考え方もあった中で、企業の人々が日常業

務の中に組み込んで実施する業務上および経営管理上のツールであって、企業のすべての人々の

自主的な行動およびチームとしての協働活動であるとしたことは画期的なことであった。また、内部統制の水準は、その構築コストとベネフィットとの兼ね合いで決定されるものであ

るが、統制が弱すぎれば企業価値が破壊され、統制が過剰であれば企業価値の創造が阻害される

という意味で、業務の有効性と効率性の確保という視点を内部統制の定義の中に取り入れている

ことも注目される。さらに、いかに有効な内部統制を構築しても、判断や処理の誤り、従業員の共謀や経営者の独

断などにより内部統制が正常に機能しないことがあるなど、内部統制の限界も意識して、「絶対的

な保証」ではなく「合理的な保証」を提供するものとしていることも、この定義の特徴である。金融庁・企業会計審議会での内部統制の定義は、以下のように COSO フレームワークに沿った

ものだが、目的に「資産の保全」、構成要素に「IT への対応」を追加した点が変更点である。

6 COSO の正式名称および定義の原文は以下のとおり

COSO：The Committee of Sponsoring Organization of Treadway Commission(トレッドウェイ委員会を支援してきた組織

団体の委員会)

Internal control is broadly defined as a process, effected by an entity’s board of directors, management and other personnel, designed to provide reasonable assurance regarding the achievement of objectives in the following

categories:

Effectiveness and efficiency of operations.

Reliability of financial reporting.

Compliance with applicable laws and regulations.


436

『内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる

法令等の遵守並びに資産の保全の 4 つの目的が達成されているとの合理的な保証を得るために、

業務に組み込まれ、組織内のすべての者によって遂行されるプロセスをいい、統制環境、リスク

の評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及び IT（情報技術）への対応

の６つの基本的要素から構成される。」7

さらに、別な面からの定義も見ていく。施行された会社法および会社法施行規則によって定義すれば、「取締役の職務の執行が法令及

び定款に適合することを確保するための体制その他株式会社の業務の適正を確保するために必要

なものとして法務省令（会社法施行規則第 100 条）で定める体制」となる。また、経済産業省のレポートでは、以下のとおり記載されている。『内部統制は、企業経営者の経営戦略や事業目標等を組織として機能させ達成するための仕組

であり、企業が組織として経営戦略や事業目的を遂行していく上で不可欠なものである。企業経

営者は、内部統制を組織管理、監視の観点からのみとらえるのではなく、経営戦略や事業目的の

遂行の観点から積極的にとらえ､企業価値の増大という企業の基本的な目的に照らして合理的な

仕組を構築するべきである。』8 残念ながら、こうして、COSO フレームワーク、会社法、経済産業省、企業会計審議会などの

諸定義が混在せざるを得ない現状では、社内の各部署で異なった概念で使用することによって混

乱が生じないように、内部統制の定義の背景を理解し、全貌を明らかにしておく必要がある。例えば、COSO フレームワークでは、組織に属するすべての人間が内部統制にかかわるという

立場をとっているのに比べると、会社法は取締役を対象にしている。「誰が実施主体なのか」というスタートのポイントからして、それぞれの立場を軸とした考え

方で、スタンスは必ずしも一致してはいない。なお、金融庁・企業会計審議会の内部統制部会でも、こうした内部統制の定義の不明確さに関

して、整理が必要であるとの意見が、出されている9。加えて、JUAS の研究部会でも、統制という言葉を使うと、企業の中、特に現場ではアレルギ

ーを生じやすいとの意見がある。言葉の響きから、「言論統制」のようなネガティブな要素を強く

感じるからではないかというコメントである。こうして、内部統制という概念は、様々な観点から異なった定義が行われてきたが、その流れ

について、次の「第 2 節歴史編」で紹介する。この項の後に、「内部統制とリスク管理は何が違うのか」と言う質問を良く受けるので、触れ

ておく。上記のように定義が定まらない 2 つを比較するのは難しいし、プロセスとマネジメント

という異なるカテゴリーのものは比較できないと言うのが本音である。とは言っても、質問には以下のように答えている。

7 【文献 A5】金融庁企業会計審議会議事録「企業がその業務を適正かつ効率的に遂行するために、社内に構築され、

運用される体制およびプロセス」と簡略化した言い方もしている。 8 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P32 9 【文献 A5】金融庁企業会計審議会議事録例えば、審議会の第 9 回部会議事録によれば、手塚弁護士が以下の発言

をされている。

・内部統制という概念そのものがかなり不明確で、人によって使い方がかなり違っている。

・ある意味でこれだけの大きな制度の構築を考えている場合には、そういう概念整理というものをなされたらさらにわか

りやすくなると考える。


437

問題を言い換えてみる。「内部統制システムを構築せよ」と言われた場合と、「リスク管理態勢を構築せよ」と言われた

場合で、アクションプランにどう違いが出るかである。まず、「リスク管理態勢を確立せよ」と言われた場合には、当該テーマに関連するリスクをすべ

て洗い出す。コアリスクや付随的リスクも含めて、ステークホルダーへの影響を思い浮かべなが

ら、ヒアリングなども行って気がつくものを整理してみる。そして、関係者で担当を割り振り、

その分析を行って重み付けをしながら評価し、リスクベースアプローチで対策を講じる。一方、「内部統制システムを構築せよ」と言われた場合には、まず当該テーマを所管する部署、

および関連する部署を特定して、関係者に集まってもらって、当該テーマに関する調査・分析・

評価の実施と結果報告を依頼する。こうして、同じ目的であってもアプローチが異なってくる。ラフに言えば、内部統制には、職制（権限と責任：職務要件記述書）の概念があり、その職制

の下で報告・連絡・相談の仕組みを機能させていくイメージが強いのである。リスク管理は、自主的なアクションプランの要素が強いとも言える。QC 活動的、ボトムアッ

プ的、チーム推進向きである。

５．リスク管理で重要なこと

リスク管理に関するキーメッセージを挙げる。これは、企業の中でリスク管理を担当してきた著者の経験によるものである。

ａ．一歩掘り下げた危機意識を持つ

リスク管理の観点から見ると会社は常に降りのエスカレーターに乗っている。耐えざるイノベーションと言うと、前向きに何か進んでいるように思うが、元々自然に放置し

ておけば品質は下がっていく中で努力してやっと質を維持できるというのが正しいと思っている。本当に、改善するには、何がリスクかを掘り下げた本物の危機意識に根付いた対策でないと、

実効が上がらない。掘り下げた深さと、効果が比例するとまでは言えないが、その厳しさを忘れ

ないことが大切である。そして、効果があったように見えても、暫くすると、マンネリになってしまって、効かなくな

る。それは施策が誤っているからではなく、小さな効果に甘えてしまうからである。

ｂ．完璧主義・理想主義を廃して現実的なアプローチを図る（リスクベースアプローチ）これは、上記で述べたとおり、リスク管理の基本的な考え方である。


438

ｃ．客観的かつ数量的に状況を把握する（科学的なリスク管理の推進）リスクを、「発生頻度」と「影響度」の 2 つの要素に分解して考えることにも見られるように、

周りに左右されがちな人間心理の判断を排除するには、事象を素因数分解してかつ数量的な指標

を導入していくことが、出発点である。こうした指標を生み出すには、過去の吟味された実績データの蓄積に基づかないと、信頼性が

なく、適用してもすぐに改定が必要になることが多い。また、IT 技術の急速な進歩を考えると、

長期間に亘ると意味づけが変化して行くので、データの吟味を忘れてはならない。指標が恣意的にならないようにするためには、リスク管理の観点から立案した案を、経営（取

締役会など）がレビューし、承認することが必要で、このステップを経て始めて、経営の指標と

して確立する。

ｄ．中立の立場で冷静に事実を見るリスク管理担当は、障害発生時の対応や、様々な相談事に関して、組織間のコミュニケーショ

ンのハブ機能を果たすことが、求められている。このため、日頃から正確な情報が入手できるよ

うに関係を密にし、何か起きれば、現場の一線の動きを正確に捉えて、従軍記者のように、経営

を始めとしてしかるべき部署に情報を発信していくことが必要である。また、発信した情報はそ

のまま、社外に流れることもありうるという前提での配慮が必要となる。

ｅ．過去からのノウハウの継承の有無が大きな差を生む残念なのは、多くの会社で、Y2K のノウハウが生かしきれていないことである。Y2K は、想

定していたリスクなどからも、リスク管理の原点である。もう過ぎ去ったこととして、ノウハウ

を継承しなかった企業が、次の個別課題で一から苦労して考えており、リスク管理の芽を育てて

きた企業はリスク管理のサイクルが身についてより根本的な対応が可能になっているように思う。失敗してから歴史を学ぶことは避けなければならないので、他山の石を大切にするとともに、

自社の一つの事例の教訓から多くを学ぶ感性が大切である。ｆ．トラブルを起こすのは担当者、損害の責任と対策の推進は経営者・管理者の責務

トラブルを起こすのは、開発担当であったり、日々の運用担当であったりするが、当然のこと

ながら、責任は経営者・管理者にある。トラブルの原因を遡っただけでは、次のトラブルを直接予防することには繋がらず、同じ管理

職の下で違う担当が新たなトラブルを起こすことがよくある。何もせず、何も言わない管理職が、

結局こうしたトラブルを間接的に引き起こしていることになる。現場の担当にこうしたリスクに関する情報が伝わり、責任は管理職が取るということが明確に

示されないと、安心して仕事ができなくなる。不安な心理が働く職場で、ジョブディスクリプシ

ョンに則った業務が行われると、皆記載された事項以外は、たとえリスクが身近にあっても手を

出さなくなる風潮を生んでいく。そして、このメッセージは、単に責任論ではなく、会社として、システム化された仕組みを構

築してトラブルが起きないようにしていくことが求められていると言うことでもある。ヒューマ

ンエラーはなくならないが、リスクベースで軽減する仕組みを工夫することを怠ってはならない。


439

ｇ．経営にリスクを認識してもらう機会を捉えて警鐘を鳴らす

──発現してからでは遅い。ON GOING MONITORING 経営に影響を与える事件が本当に発生した後では、手遅れである。しかし、何も材料がないと

真剣にはなれないというのも事実である。日々の新聞報道の中で行われる、自社で発生した場合の机上シミュレーションは、このような

場合に役立つ。有用と思われる対策を経営にタイムリーに報告することが、企業全体でリスクを

身近に感じるきっかけとなる。ｈ．攻めの IT ガバナンスのための守りであることを忘れない

リスク管理は、守りの IT ガバナンスであるからと言って、システム障害の恐ろしさや漏洩事

故の対策などのマイナス面ばかりを強調してはいけない。終的には、自社の企業価値の向上が目標であるため、事業面での優位性、一層の業務の効率

化、将来の成長といった面も視野に入れて、正しく評価して伸ばしていくことも必要である。なお、米国のリスク管理の話を聞くと、誉め言葉を散りばめ、経営に企業の良い所を再認識さ

せることを忘れてはいないようである。ｉ．自分の健康管理は自分の責任

ベストプラクティスや好取り組み事例は、その会社が創意工夫して編み出したものだけに、当

該企業の「リスク管理文化」そのものに根ざしている。素晴らしいと思いつつも、自社に導入するには骨組から作り直さないと本当に機能させること

ができないものもある。単に共鳴したという理由だけで、自社に同様の仕組みを構築しても、足

元の日々の運用が追いつかずに悩んでいる事例を聞く。ベストプラクティスは、貴重な血と汗の結晶であるが、受け手にとっては「輸血」なのである。緊急手当てが必要であればすぐにでも対応せざるを得ないが、冒頭の「はじめに」でも述べた

ように、応急手当の包帯だらけの力士にならないためには、自身が呼吸して、肺に新鮮な息吹を

送り込み、血液を浄化させていく仕組みで身体を健全にしていかなければならない。


440

441

第５章リスク管理・内部統制第２節リスク管理・内部統制を巡る様々な流れ（歴史編）

─リスク管理態勢構築の成功の秘訣は、「賢者は歴史に学び、実践で逞しくなる」こと

この節では、「賢者は歴史に学ぶ」として、米国、英国、そして日本の内部統制の歴史的な報告

書をベースに変遷を取り上げている。

社内に展開していくには、「会社にとって何が大切か」、「何のためにするのか」、「自社に適した

ものにするために何をすべきか」という企業としての課題の全体像および長期的な取り組みを考

える必要がある。

リスク管理担当は社内に様々な依頼をせざるを得ない。何故そうするのかを自信を持って話す

（説明責任を果たす）ためには、これまでの経緯を踏まえたうえで、現在の状況を認識しておく

必要がある。過去の紆余曲折・試行錯誤を繰り返しながら、今なお全世界で大きな問題を抱えつ

つ、進化の過程にあることを理解して、初めて将来が見えてくる。態勢構築の成功の秘訣は、遠

回りであるが、歴史に学ぶことから始まる。

１．米国における内部統制の歴史

２．英国における内部統制の考え方（ターンバルガイダンス）

３．COSO-ERM（Enterprise Risk Management）の考え方

４．COSO のシステム統制を具現化した COBIT

５．米国企業改革法（Sarbanes‐Oxley 法）

６．日本における内部統制の考え方（ソロバン時代の内部統制）

７．日本における内部統制の考え方（時代を先取りした金融庁検査マニュアル）

８．裁判で取り上げられた内部統制の不備および会社法が定める内部統制

９．日本における内部統制の考え方①（経済産業省「リスク新時代の内部統制」）

10．日本における内部統制の考え方②（経済産業省「開示・評価の枠組みについて」）

11．日本における内部統制の考え方③（金融庁企業会計審議会の報告書）

12．リスク管理・内部統制の諸レポートの全体像

５－２リスク管理・内部統制を巡る様々な流れ（歴史編）

442

図表 5-2-1 米国・英国における内部統制の歴史年表

年出来事

1938 年上場企業による大型の不正会計事件を契機として、外部監査人が理解すべき内部統

制の適正範囲が何かという摸索がなされるようになる。

1950 年前後 EDP 監査が、システムリスクに関する監査としてスタートする。

1972 年 6 月ワシントン DC のウォーターゲートビルにある民主党本部に盗聴器を仕掛けようとした 5

人組が逮捕されたウォーターゲート事件が起きる。

1977 年ウォーターゲート事件を契機に、海外不正支払防止法が成立する。この法では、賄賂禁

止規定に加えて、会計と内部統制に関する規定を定めている。

EDP 監査の理論的な背景になった「システムの可監査性と統制」が出る。

1978 年アメリカ公認会計士協会が、企業の経営者は自社の内部統制システムの状況を説明し

た経営者報告書を提出すべきとするコーエン委員会報告を公表する。1979 年には内部

統制特別諮問委員会を設置し、内部統制の確立および評価に関する指針を策定する。

1980 年代多くの企業の経営破綻や粉飾決算が政治・社会問題となり、企業倒産や監査の失敗に

対する訴訟が引き金になって、米国議会は経営者の行為、財務報告の適切性および外

部監査の有効性に関して審議する公聴会を開催する。

1985 年アメリカ公認会計士協会が、トレッドウェイ委員会を組織する。

委員会の目的は、不正な財務報告の原因を究明し、その発生を減少させるための勧告

を行うこと。

1987 年同委員会が、不正な財務報告に関する報告書を公表して、経営陣は不正な財務報告を

防止するために総合的な内部統制環境を確立すべきであるとの提言を行う。

1988 年監査基準の一つである SAS55 が公表される。内部統制上のリスク評価に関する指針を

明らかにするとともに、監査人の責任の拡大が図られる。

1992 年トレッドウェイ委員会の一連の策定作業の集大成として、COSO フレームワークが完成

する。策定の目的は、様々な立場から主張されてきた内部統制の概念と定義を統一し、

共通のフレームワークを明らかにすること。

1992 年 12 月（英国）コーポレートガバナンスの財務的側面、特に財務報告について検討するためにキャドベ

リー委員会が設置され、報告書を公表する。財務報告を中心に、取締役会の責任、監

査人の役割、株主の権限と責任などについて規定している。

1995 年 7 月（英国）民営化された公益企業における取締役の報酬についての論議が政治・マスコミを巻き

込む論議に発展し、経済団体である CBI が、取締役の報酬のあり方について検討を行

い、報告書を公表する。

1996 年 ISACA が、COSO フレームワークをベースに IT コントロール体系を網羅した COBIT を出

版する。（その後、2 年おきに改訂されて、2000 年 7 月に第 3 版が発表される。）

1998 年 6 月（英国） 1995 年 11 月に財務報告評議会が、過去の 2 つの委員会報告書の内容をより具体的・

体系的に見直して、1998 年 1 月に終報告書を取りまとめる。これら 3 つの報告書を統

合して、財務報告評議会により「The Combined Code（統合規範）」が公表される。

1998 年 9 月大和銀行 NY 支店の事件等がきっかけとなって、バーゼル銀行監督委員会が、「銀行組

織における内部管理体制のフレームワーク」を公表する。

1999 年 9 月（英国）英国における内部統制のスタンダードとなるターンバルガイダンスが公表される。

2002 年 7 月 2001 年にエンロン社が、簿外取引の巨大損失隠しに端を発して、その年の 12 月に破綻

する。2002 年 7 月 30 日には、「公開会社に関する会計改革および投資家保護法」が連

邦法として承認される。

2004 年 9 月 COSO フレームワークが、COSO-ERM として改定される。従来の内部統制の考え方を

すべて内包しつつ、戦略も含む事業リスク管理という概念へと発展・拡張を図ったもの。

2005 年 12 月 COBIT4.0 が発行される。実際の組織により適用しやすく、ITIL、ISO17799、PMBOK、

PRINCE2 等との調和を図ったもの。

./keyword.htm#0301


443

図表 5-2-2 日本における内部統制の歴史年表

年出来事

1951 年 7 月産業合理化審議会から「企業における内部統制の大綱」の答申が出る。

1998 年 3 月国内外から政府への不信が高まる中で、大蔵省が「新しい金融検査に関する基本事項

について」を発出する。

1995 年 9 月邦銀への海外金融市場での信頼が低下している中で、大和銀行NY支店の巨額損失事

件が発覚する。米国における邦銀全体に対する不信を決定付ける。

1997 年 11 月・1995 年に始まった金融機関の経営破綻が、三洋証券、北海道拓殖銀行、山一證券な

どが破綻した「ブラック・ノーベンバー」で頂点に達する。

・1998 年 1 月、金融当局における接待スキャンダルの発覚が日本の金融当局に対する

海外の金融当局の不信を決定付ける。

1998 年 6 月金融機関が自己責任に基づいて経営し、当局はこれを促進・検証する役割を担う方式

への転換が図られ、現在の金融庁の前身である金融監督庁が発足する。

1998 年 7 月政府・与党策定の金融再生トータルプランで、外部のノウハウを取り入れた検査マニュ

アルおよびチェックリストを整備し、年内に公開することが明記される。

1998 年 8 月金融監督庁（当時）が、「金融検査マニュアル検討会」を発足させ、1999 年 7 月には、

「預金等受入金融機関に係る検査マニュアル」が発出される。

2000 年 9 月大和銀行 NY 支店事件に関する代表訴訟において、大阪地方裁判所で、役員に 829 億

円（当時）の損害賠償を命じる判決が出て、内部統制がキーワードとして注目される。

2003 年 2002 年 1 月の企業会計審議会の改訂監査基準、2002 年 10 月の日本経済団体連合会

の企業行動憲章の改定、企業法制における 2003 年 4 月の改正商法などで、コーポレー

トガバナンスの確立と内部統制の整備・強化が掲げられる。

2003 年 6 月経済産業省が、「リスク管理・内部統制に関する研究会」を設置し、「リスク新時代の内

部統制」と題する指針を公表する。

2004 年 11 月上場企業の不適正な開示が相次いで判明したことから、金融庁が「ディスクロージャー

制度の信頼性確保に向けた対応」を公表する。全開示企業に対して株主の状況等につ

いての自主点検を要請したところ、多くの訂正報告書の提出が為される。

2005 年 12 月 2005 年 1 月の企業会計審議会総会において、「内部統制部会」を設置することが決定さ

れ、7 月には公開草案を公表する。パブリックコメントを受けて、2005 年 12 月 8 日に「財

務報告に係る内部統制の評価及び監査の基準のあり方について」を公表する。

2006 年 2 月経済産業省が、「企業行動の開示・評価に関する研究会」を設置して、「コーポレートガ

バナンス及びリスク管理・内部統制に関する開示・評価の枠組について一構築及び開

示のための指針－」をまとめる。不祥事防止等のために企業経営者が取り組むべき項

目が示され､それらを構築および開示するための指針が提示されている。

2006 年 5 月会社法の省令である会社法施行規則、会社計算規則及び電子公告規則が公布され、

会社法が 2006 年 5 月 1 日に施行される。

2006 年 6 月「証券取引法等の一部を改正する法律」が、2006 年 3 月 13 日に国会へ提出され、「金

融商品取引法」として 6 月 7 日に成立する。


444

１．米国における内部統制の歴史

米国におけるトレッドウェイ委員会までの歴史については、付録４「米国の内部統制の歴史（ト

レッドウェイ委員会以前）」を参照。

（１）トレッドウェイ委員会

1980 年代に入ると金融機関を含む多くの企業の経営破綻や粉飾決算が政治・社会問題となり、

企業倒産や監査の失敗に対する訴訟が引き金になって、米国議会は経営者の行為、財務報告の適

切性および外部監査の有効性について疑問が生じた公開会社における様々な事件を集中的に審議

する公聴会を開催した。また、経営破綻や粉飾決算が相次ぐ中で、監査人がほとんどの場合警告を発することができな

かったことから、公認会計士不要論が出てくるなど監査人に対する批判も高まった。こうした動きに危機感を抱いたアメリカ公認会計士協会（AICPA）は、関連する 4 つの専門家

組織に呼びかけて、1985 年に J.C.Treadway 氏（SEC の前コミッショナー）を委員長とする「不

正な財務報告に関する全国委員会(National Commission on Fraudulent Financial Reporting)（通称：トレッドウェイ委員会）を組織した。トレッドウェイ委員会の主たる目的は、不正な財務報告の原因となる要因を識別し、その発生

を減少させるための勧告を行うことであった。そして 1987 年、同委員会は「不正な財務報告」に関する報告書を公表して「経営陣は不正な

財務報告を防止するために総合的な内部統制環境を確立すべきである」との提言を行った。特に強調されたことは、統制環境(Control Environment)、企業の行為要綱(Code of Conduct)、

有能で業務に専念する監査委員会および積極的で客観的な内部監査部門の重要性であった。さらに、1988 年には会計監査人の監査基準の１つである SAS55「財務諸表監査における内部

統制組織の勘案」が公表され、内部統制構造の要素をより明確に定義して内部統制上のリスク評

価に関する指針を明らかにするとともに、内部統制の実情に精通すべきとする監査人の責任の拡

大が図られた。

（２）COSO フレームワークのレポート

こうした動きに並行して、トレッドウェイ委員会は組織委員会の活動の一環として、内部統制

に関する様々な概念と定義を統一し、すべての企業に共通な準拠枠（フレームワーク）を明らか

にする作業に着手した。この作業部会は、内部統制の確立・監視・評価・報告に対する責任は経営者にあるとして、こ

のフレームワークに経営者のニーズをできるだけ反映させるべきであること、また、内部監査人、

外部監査人、学者、監督機関など内部統制に大きな関心を寄せている関係者により承認されるプ

ロセスを経て設定されるべきであること、という方針の下に調査・策定作業を行っていった。そして、1992 年にこの策定作業の集大成として完成したのが COSO レポート「内部統制の包

括的フレームワーク（Internal Control – Integrated Framework）」である。 COSO レポート策定の目的は、様々な立場から主張されてきた内部統制の概念と定義を統一し、


445

共通の準拠枠（フレームワーク）を明らかにすることにあった。 COSO レポートが公表される前の諸団体の定義を見てみると、アメリカ公認会計士協会の監査

基準書（SAS55）では、内部統制を「事業体の特定の目的が達成されるであろうことについて合

理的な保証を提供するために設定された方針および手続き」と広義に定義していた。また、内部

監査人協会は、「設定された目的と目標が達成される可能性を高めるために、経営者によって採ら

れているあらゆる行動」と定義し、経営者による指揮・命令という点を強調していた。立法当局

や監督機関では、監視の対象となる活動の種類を特定して内部統制を定義するのが一般的で、海

外不正支払防止法においても資産の保全と正確な会計記録という内部会計統制の観点から定義し

ていた。これらの定義に共通するのは「内部統制は目的を達成するための手段である」という点であり、

COSO レポートの策定にあたっては、「内部統制の定義には事業体が達成しようとする目的と、

その目的に向かってなされる行動が示されていなければならない」との考え方が採用された。２．英国における内部統制の考え方（ターンバルガイダンス）

米国の COSO フレームワークが、世界のデファクトスタンダードとなっているが、すべてでは

ない。ほぼ同時期に不祥事を抱えることとなった他の国においても、同じような検討が進められた。

米国 COSO 一辺倒にならずに、欧州、カナダ（CoCo レポート）、豪州からの視点を入れると、

中立的に物を見る視座を与えてくれる。情報セキュリティでも、英国の BS7799 が終的に世界標準になっていったように、独善的な

見方にならないためには、英国は忘れてはならない存在である。以降は、数ある候補の中から英国の内部統制システムに目を転じる。

（１）ターンバルガイダンスの成立

1990 年代のコーポレートガバナンス改革の経緯については、付録５「英国における 1990 年代

のコーポレートガバナンス改革の経緯」を参照。英国における内部統制のスタンダードとなっているターンバルガイダンスとは、1999 年 9 月

に ICAEW（Institute of Chartered Accountants in England & Wales：イングランド・ウェール

ズ公認会計士協会）が発行したもので、正式名称は「Internal Control：Guidance for Directors on the Combined Code（内部統制：コンバインドコードに関する取締役のためのガイダンス）」

という。この策定を行った ICAEWのワーキングパーティの座長を務めたNigel Turnbull氏の名前にち

なんで、一般に「ターンバルガイダンス」と呼ばれている。ターンバルガイダンスは、コンバインドコードの中の D2 原則（内部統制）に関して取締役（会）

が遵守すべき指針を示したものである。ターンバルガイダンスは、目次などを除くと 12 ページで、約 50 のパラグラフで構成される簡

潔なレポートである（付録６「ターンバルガイダンスの内部統制に関する原則と条項」参照）。


446

（２）ターンバルガイダンスの特徴

COSO フレームワークの内部統制の 3 つの目的、5 つの構成要素と比較してみると、ターンバ

ルガイダンスにおいても、形式は異なるものの基本的な考え方に大きな差はなくほぼ同様の内容

が記載されている。違いの一つ目は、内部統制システムを独立した概念として捉えるのではなく、コンバインドコ

ードという英国におけるコーポレートガバナンスの枠組みの一つとして捉えていること、また、

そのため内部統制システムのディスクロージャーに関する規定を持っている点などである。内部

統制を企業文化として根付かせることで、新たなリスクが発生しても個別に切り離して論議せず、

コーポレートガバナンスを補強するという捉え方がベースにある。コンバインドコードおよびターンバルガイダンスは共にロンドン証券取引所の株式上場基準に

取り入れられており、1999 年 12 月 23 日以降の決算期から年次報告書の中で、これらの規程に

基づいて上場企業の内部統制やリスクマネジメントの状況に関する情報公開などが義務付けられ

ることになった。 COSO フレームワークは法的な強制力を持たないが、同じように民間団体等により策定された

英国のこれらの規程・ガイダンスは、株式上場基準に取り入れられているという意味で規範性の

より強いものとなっている。コンバインドコードについて付言すると、5 つの分野の内、4 つは企業の側面であるが、後

の分野は、株主である機関投資家に関する規定である。企業だけでなくもう一方の当事者たる株

主（機関投資家）にも規範を示している点が特徴である。

３．COSO-ERM（Enterprise Risk Management）の考え方

（１）COSO-ERM とは

世界各国でいろいろな形で参照・利用されて、内部統制のグローバルスタンダードとなった

COSO フレームワークが、2004 年 9 月に「Enterprise Risk Management Framework（全社的

リスクマネジメント）」として改定された（以下「COSO-ERM」という）。この COSO-ERM は、従来の COSO レポートにおける内部統制の考え方をすべて内包しつつ

つ、戦略も含む事業リスク管理という概念へと発展・拡張を図ったものである。

（２）COSO-ERM 作成の背景

COSO-ERM策定の背景ともなったCOSOレポート公表当初からの 2つの批判についてまず触

れる。第一の批判は、同レポートが想定している企業の組織形態が、旧来型のピラミッド型の階層構

造であるという点である。すなわち、1990 年代初頭から IT 環境の急速な発展により、企業にお

いて権限委譲型のフラットな組織形態がとられることが多くなっているが、同レポートのフレー

ムワークはそうした企業にとって必ずしも適合的ではないという批判である。こうした批判を受けて、COSO-ERM においては、ピラミッド型の組織図はなくなり、企業内

の組織形態にかかわらず適用できる仕方に変わっている。第二の批判は、内部統制という概念が主に当時の外部監査の領域で問題にされていたこともあ


447

って、その概念に含まれない企業活動・企業経営の側面があるということである。特に内部統制

の構成要素である「リスクの評価」については、リスクの範囲や性質が限定的に捉えられており、

近年重要性が認識されてきた事業リスクに関しては実務指針として十分に機能するものではなく、

総合的かつ全社的観点からリスクを識別し分析するプロセスが必要であるとの指摘がされていた。このような事業リスクマネジメントの必要性は、企業自身の認識でもあり、また資本市場から

の要求でもあった。企業にとっては、事業環境の変化に早期にかつ的確に対応するとともに、事

業の収益性と永続性を高めるためにリスクに対する効率的な対応が求められる時代になってきて

いるといえる。また、リスクを認識せず適切な対応を怠ると株価や資金調達に悪影響を及ぼす結果となるため、

企業に対して社会的・倫理的な責任の充足を求める市場の要求も強くなってきている。こうした背景から、COSO レポートの公表から約 9 年経った 2001 年秋に、包括的な枠組みを

整備すべく新たな活動が開始された。当時は 2002 年の終版公表を予定していたが、2001 年 9月の同時多発テロや同年のエンロンの破綻を受けて一層強力なリスクマネジメントシステムが必

要であるとの認識から検討を重ね、2004 年 9 月に完成した。（３）COSO-ERM とは何か

同書の冒頭にある「要約篇」および「フレームワーク篇」の中で、COSO-ERM のフレームワ

ークの前提となる基本的な考え方や目的・効用などについて記載している。 COSO-ERM は、リスクマネジメントという言葉を使っているものの、企業にとってのダウン

サイドリスクを軽減するリスク管理の仕組みというよりは、経営そのもの、言い換えればエンタ

ープライズマネジメントを標榜しているものと捉える方がよいと考えられる（付録７

「COSO-ERM の考え方」を参照）。なお、COSO-ERM の定義は、以下のとおりである。

『ERM は、事業体の価値の創造や保持に影響するリスクや事業機会に対処するものであり、

次のように定義される。 ERM は、事業体の取締役会、経営者、その他の組織内のすべての者によって遂行され、事業

体の戦略策定に適用され、事業体全体にわたって適用され、事業目的の達成に関する合理的な保

証を与えるために事業体に影響を及ぼす発生可能な事象を識別し、事業体のリスク選好に応じて

リスクの管理が実施できるように設計された、一つのプロセスである。』


448

（４）COSO-ERM で何が変わったか

従来の COSO フレームワークでの定義と照らし合わせてみれば、COSO-ERM が従来の内部統

制の概念を包含した考え方となっていることがわかる。さらに、COSO-ERM は、・戦略の設定はもとより事業体のあらゆる領域に適用され、・当該企業に影響を及ぼす可能性のある潜在的な事象を識別し、・リスクを自らのリスク選好度の範囲内に収めるよう管理するものであるとしており、企業全体のリスク管理の分野へ発展・拡張させたものであることがわ

かる（付録８「COSO との対比」参照）。

①目的の追加 COSO-ERM の事業目的には COSO フレームワークの 3 つの目的が含まれ、さらに新たな柱と

して、戦略（Strategic）が加えられた。従来の COSO フレームワークでは、戦略は企業の組織目標（ミッション・ビジョン）に基づい

て既に存在し、内部統制はいわばそれぞれの戦略を確実に遂行することを支援する仕組みという

考え方であったが、COSO-ERM では戦略の設定や選択までも対象にして、同じ方法論が適用さ

れるべきものという考え方が採用されている。 COSO フレームワークが、「不確実性」のうちマイナス面の発生の防止・軽減を主な対象とし

ていたのに対し、COSO-ERM は不確実性のリスクと機会の双方に対して効果的に対処するフレ

ームワークを提供することを意図したものであるので、その目的として新たに戦略の柱を追加し

たことは当然といえる。また、COSO フレームワークの目的の一つである「報告」は、外部に対する財務報告を念頭に

置いていたが、COSO-ERM では内部で利用される報告や外部関係者に対して発行される報告書、

および規制当局への提出書類も含み、範囲においても非財務情報を含む広い概念に拡張されてい

る。 ②構成要素の追加・修正

COSO フレームワークでは、内部統制を構成する要素として、１）統制環境、2）リスクの評

価、3）統制活動、4）情報と伝達、5）モニタリングの 5 つを掲げていた。 COSO-ERM においては、これに修正・追加を行って、8 つの要素に拡張し、すべての要素は

相互に関連しながら、経営プロセスに組み込まれて運営されるべきものとしている。と言うか、元々、各要素は、経営者がビジネスを推進する方法から導き出されたものであって、

それぞれが有効に機能し、または経営のプロセスと有機的に結びつくことによって、目的が達成

されるというのは自然なことである。

③COSO Cube

4 つの事業目的、8 つの構成要素、組織内の 4 つのレベルは、相互にかつ密接に関わりあって

いる。この関係を表わすために、従来のいわゆる COSO-Cube（図表 5-2-3）を図表 5-2-4 のよう

に改定している。


449

図表 5-2-3 COSO Cube 図表 5-2-4 COSO-ERM Cube

（コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて）10

④ERM の実施主体・効果および限界

COSO-ERM でも、企業のすべての構成員によって遂行されるものであるとの考え方は変わっ

てはいないが、特に、経営者、業務執行役員、リスク担当役員、取締役会、監査委員会（監査役

会）、内部監査人（内部監査部門）などが果たすべき役割と責任についてより具体的に記載してい

る。なお、外部関係者（外部監査人、立法当局・監督機関、顧客、財務アナリスト等）も ERM の

有効性向上に役立つ情報源となるものの、責任を負わない（すなわち ERM は企業の自己責任に

おいて構築すべきもの）と整理している。 COSO フレームワークと同様、COSO-ERM においても限界について言及している。すなわち、有効な ERM は経営目標の達成に有用であり、またそれを支援するものではあるが、

いかに適切に設計され運営されたとしても、固有の限界があり、事業の成功自体を約束するもの

ではないとしている。例えば、政府の方針、経済情勢、市場環境など経営陣のコントロールを超える外部要因があり、

内部的にも単純なエラーやミスなどの人的要因、悪意ある構成員の共謀などもありうる。また、

ERM は費用対効果のバランスの上に成り立つものであるため、経営資源の制約が ERM や内部統

制の有効性に限界を与える場合もあるとしている。したがって、ERM も内部統制と同様、目標の達成に役立つものではあるが万能薬ではないと

結論している。COSO フレームワークに比べて、戦略にまで広げたことで、こうした限界はさら

に広がっていくと言える。

10 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P8

および P10


450

４．COSO のシステム統制を具現化した COBIT11

COSO フレームワークを IT 分野で深掘りした方法論が、COBIT である。 COBIT は、「Control OBjectives for Information and related Technology」の略語で、米国の

情報システムコントロール協会（ISACA：Information Systems Audit and Control Association）および IT ガバナンス協会（IT Governance Institute）によって策定された情報と情報技術に係

るオープンスタンダード（公開標準）である。事業活動におけるプロセスおよび IT のリスクと効果のバランスを取りながら、企業価値を向

上させていくために、改善の効率および効果を可視化することを目指している。そして、「企業における IT の適切な管理レベルはどのようなものか」という経営者の質問に答

えようとしている。（１）歴史12

米国では、1950 年前後に既に EDP 監査が、システムリスクに関する監査としてスタートして

いたと言われている。その後、EDP 監査の理論的な背景になったのが、1977 年に内部監査人協会がスタンフォード

研究所に依頼してまとめた「システムの可監査性と統制」（SAC レポート）である。その中には、「コンピュータを用いる情報システムの正確性および完全性に対する運営上の責

任は、ユーザーにあるが、全般的な内部統制に対する主要な責任は高経営者にある」とか、「コ

ンピュータを用いる情報システムの導入前後に、統制の検証を行う必要がある」と言った結論が

述べられていた。こうした内部監査人協会の動きとは別に、ISACA は、Control Objectives というコンピュータ

環境におけるコントロールを提供し、検証する上で新かつ分かりやすいガイドラインを定期的

に公表してきた。日本語にも、1983 年版、1990 年版は翻訳されている。 1996 年に、ISACA はこうした情報技術のコントロール目標に検討を加え、COSO フレームワ

ークをベースに IT コントロール体系を網羅した COBIT を出版した。 COBIT は発行以来 2 年おきに改訂されて、2000 年 7 月に第 3 版が発表された。 2005 年 12 月には、実際の組織により適用しやすくし、ITIL13、ISO17799、PMBOK14、

PRINCE215等との調和を図った COBIT 4.0 が発行された16。

11 “COBIT”と COBIT のロゴは、米国及びその他の国で登録された情報システムコントロール財団（Information Systems

Audit and Control Foundation、本部：米国イリノイ州）及び IT ガバナンス協会（IT Governance Institute、本部：米

国イリノイ州：www.itgi.org）の商標（trademark）。COBIT®の内容に関する記述は、情報システムコントロール財団

および IT ガバナンス協会に著作権がある。本文中では、Copyright、TM、R マーク等は省略している。 12 【文献 1】「システムリスクに挑む : 金融検査マニュアルを超える実践ガイド」P254 13 ITIL：Information Technology Infrastructure Library 14 PMBOK：米国の非営利団体 Project Management Institute が策定したプロジェクトマネジメントの知識体系 15 PRINCE2：PRojects IN Controlled Environments の略。英国で開発されたプロセスベースのプロジェクトマネジメン

トの手法 16 ISACA 東京支部で COBIT 4.0 の日本語への翻訳が進行中である（2006 年 9 月現在）。

第 3版のマネジメントガイドラインおよび「IT Control Objectives for Sarbanes-Oxley」の日本語版は、ISACA のホー

ムページからダウンロード可能である。

・COBIT 第 3 版の日本語版無償ダウンロード登録ページ（PDF 形式）：


451

（２）COBIT の特徴（第 3 版ベース）

COBIT は、以下の実践的で汎用的な目標の設定手法を 4 つ導入している。・IT プロセスを適切にコントロールすることができるようにするための主要成功要因・IT プロセス全体の目標達成状況をモニタリングするための重要目標達成指標・個々の IT プロセスの成果達成状況をモニタリングするための重要業績評価指標・戦略的な意思決定をベンチマークによって他企業と比較ができる成熟度モデル各項目の詳細の説明は、付録９「COBIT の各項目の解説」を参照。

（３）COSO 等との関係

COBIT は、COSO の 3 つの目的を踏襲しているが、信頼性については、財務情報に限らずす

べての情報を含めるように拡大解釈している。このため、情報セキュリティの要件として共通な

「機密性」、「万全性」、「可用性」は、IT 全体をカバーしている。 COSO との関係について、COBIT の統制活動と COSO の構成要素とのマッピングを「サーベ

インズ・オクスリー法遵守のための IT 統制目標」の中で提示している17。 COBIT は、IT に焦点を絞ったコントロールモデルと、COSO のようなビジネスコントロール

モデルとのギャップに橋渡しをすることを目指している。したがって、一般のマネジメントレベ

ルよりは技術面に対象を広げ、IT 分野でのテクノロジー表現に加えてビジネス寄りの分野もカバ

ーしようとしていると言える。 COBIT は、カーネギーメロン大学が開発したソフトウェア開発能力の成熟度を測るモデルか

ら生まれた。同じモデルから生まれた CMM との相違点は次のとおりである。・レベルが 6 段階ある点（CMM は 5 段階）・COSO フレームワークに即しており、リスクという概念が強く打ち出されている目標および目標に対する成果達成指標をより理解しやすくするために、バランススコアーカー

ドの視点を考慮して、マッピングのための図を取り入れて解説している。 COBIT の各プロセスは、業種によらない共通のプロセスを取り上げており、業態によっては

適さないものもあるので、個別に改良を加える必要がある。加えて、開発の形態として、ベンダ

ーからの調達を前提にし、一般的な技術プラットフォームを前提にしているので、開発の形態や

特定のテクノロジーを用いる場合等に注意が必要である。 COBIT は、IT 管理のプロセス毎に必要なマネジメントやコントロールを定義しており、IT ガ

バナンス構築の際にも活用できる。近では、内部統制全体の見直しにおいて、IT 分野では

http://www.isaca.gr.jp/standard/cobit_ver3_MG.html

・「IT Control Objectives for Sarbanes-Oxley」の日本語版のダウンロード：

http://www.isaca.org/Template.cfm?Section=Home&Template=/ContentManagement/ContentDisplay.cfm&ContentID=242

30 17 【文献 A8】「通商白書 1．イギリスコーポレート・ガバナンスの改革の背景と動向」P49


452

COBIT が利用されるケースが増えてきている。また、COBIT のフレームワーク全体を組織に適用する方法と、必要な部分を取り出して利用

する方法が有りうる。

以上述べたとおり、COBIT は、体系的に高度に整備されていることと、評価が数量的に捉え

られる点で、優れものの管理ツールである。こうしたシステマティックなアプローチがビジネスプロセス全般に適用できるようになれば、

内部統制が、経営者および従業員にわかりやすく受け入れられていくものと思う。しかしながら、便利なだけに、導入に当たっては、冷静にその適用の限界も見極めておく必要

がある。まず、広範囲の項目をチェックすることで、網羅性を確保できるメリットはあるが、企業のコ

アの部分や標準と異なるプロセスのリスクを深掘りし、実態に合わないところは書き換えて、自

社の業態や規模に応じたものにしていく必要がある。チェック項目の数を増やしていくと充実し

ているように見えるが、リスクの種類や対策が同じものの羅列になっているケースも多く、実際

は、リスク分析の質が却って低下する場合もあるので、注意が必要である。また、初めのうちは、平均的で玉虫色の評価をする傾向が予想される。一定のレベル合わせの

確認が取れるまでは、厳し目にスタートして評価することも必要である。そして、個々の企業内での現状と改善を目指すポジションの対比は可能であるが、同じ業界の

優秀企業との比較といったデータはまだ整備されていないのが、日本の現状である。以降取り

上げるリスク管理での指摘事項の事例集なども併用していく必要がある。

５．米国企業改革法（Sarbanes‐Oxley 法）

2001 年にエンロン社が、簿外取引の巨大損失隠しに端を発して倒産を申し立て、その年の 12

月に破綻した。また、司法省が、エンロン社の監査人であったアーサーアンダーセン社を、調査のために必要

とした証拠の未提出・改変・破棄したという司法妨害を理由に起訴した。裁判は、2002 年 5 月 17 日から始まり陪審の協議が膠着状態になる時期が続いたものの、終

的には有罪となった。同社は、LLP（Limited Liability Partnership）という会社の組織形態を

取っていたことから、エンロン社を担当していたヒューストンのオフィスに留まらず、8 月 31 日

には上場企業の監査を全事務所で停止する事態に追い込まれた。他にも不祥事件が相次いだことで、米国の株式市場は大きな打撃を受け、財務報告における透

明性や正確性を確保することが緊急の課題となったことから、2002 年 2 月 14 日、下院の金融サ

ービス委員会（Michael G Oxley 委員長）に、「企業及び監査の責任と透明性に関する法案」が提

出された。その後、4 月の下院本会議での可決を経て上院に送られ、6 月の上院の金融委員会（Paul

Sarbanes 委員長）でも可決し、7 月には、上院と下院の法案を一本化した内容で両院の本会議で

可決した。


453

2002 年 7 月 30 日には、大統領が署名して、「公開会社に関する会計改革および投資家保護法」

18が連邦法として承認された。実に、1933 年に連邦証券法、1934 年には証券取引所法が制定されて以来の大きな変更が、こ

うして短期間の内に行われた。その後、米国証券取引委員会（SEC）が同法に関して、適用および施行するための細則を公表

した。また、公開会社会計監視委員会（PCAOB）19も、「監督基準第 1～3 号」等を作成している。

米国企業改革法は、構成として、全体で 11 の章と 69 の条文から成り立っている。監査法人と公開企業それぞれに分けて、主なポイントを以降に挙げる。

（１）監査法人に対する規制の強化

・公開会社の監査を行う監査法人・監査人は公開会社会計監督委員会に登録しなければならな

い。

・利益相反となる行為を制限・禁止する。・監査担当責任者の交代期間を従来の 7 年から 5 年に短縮する。・公開会社会計監督委員会は、監査法人を毎年または 3 年に 1 回検査する。・違反があれば、登録の一時停止や抹消・過料を課す等の処分もある。・監査調書は 5 年間保管する義務があり、違反すれば 10 年以下の拘禁刑となる。

（２）公開企業に対する規制の強化

・経営者が虚偽記載を知りつつ故意に宣誓書に署名した場合、500 万ドルの罰金/20 年以下の

拘禁刑（両方のケースもある）、故意でない場合には 100 万ドル／10 年以下の拘禁刑が科せ

られる。・財務諸表のディスクロージャーを促進し、簿外取引に関しては定期的に報告する。・取締役または役員が保有する証券の取引停止期間中の売却を制限する。・内部告発者を保護する。なお、この法は、米国内の企業に限らず、ニューヨーク証券取引所や NASDAQ 等の米国の証

券市場に上場している外国企業も対象としているため、こうした市場に上場している日本企業も

対応を求められる。特に、注目すべきは、年次報告書の開示が適正であるという宣誓書の提出を義務づけた第 302

条と、投資家に対する企業経営者としての責任と義務・罰則を定めた第 404 条であり、SEC への

提出書類に「虚偽報告や記載漏れがないこと」、「内部統制の有効性評価を開示すること」等を保

証する証明書と署名を併せて提出することを求めている。記載事項に虚偽があった場合には、第 906 条等で、高経営責任者（CEO）や財務担当責任者

（CFO）個人に、高 20 年の禁固刑が科せられるという厳しいものになっている。

18 原文: Public Company Accounting Reform and Investor Protection Act of 2002

サーベインス・オクスレー法、SOX 法、SO 法、SOA、企業改革法等、いろいろな呼び方がある。 19 PCAOB：Public Company Accounting Oversight Board コロンビア特別区非営利法人法に基づく非営利法人で、監査基

準・品質管理・独立性などのルールを策定する。構成員は 5名で SEC が指名する。


454

この 2 つの条文について、特徴をまとめたものが、次の図表 5-2-5 である20。

図表 5-2-5 SOX 第 302 条と第 404 条の特徴

第 302 条

（CEO／CFO による宣誓書）

第 404 条

（経営者による内部統制の評価と監査人による監査）

対象者企業経営責任者、財務担当役員企業経営責任者、財務担当役員

概要 ①内部統制の開示が新で適正

であることを評価すること

②財務報告に係る内部統制の変

更を評価すること

③知りえたすべての内部統制の

問題、欠陥を開示すること

④不正行為を開示すること

①内部統制機構の確立と維持する責任があること

②経営者による機構とその有効性に関する報告をする

こと

③経営者が行った内部統制の評価について外部監査

人により監査を受けること

施行時期 2002 年 7 月から施行現時点では、市場価格および米国企業か外国企業か

によって、いくつかに分かれて段階的に実施することと

なっている。

・米国早期適用企業は、2004 年 11 月 15 日以降適用

・外国の大規模早期適用企業は、2006 年 7 月 15 日以

降適用

・上記以外の企業は、2007 年 7 月 15 日以降に適用

頻度経営者による 4 半期ごとの評価経営者および外部監査人による年度毎の評価・監査

報告宣誓書経営者による内部統制報告書および外部監査人によ

る内部統制監査報告書

この法では、財務報告の透明性を確保するため、財務報告に係る企業内の各データを明確に定

義し、公正で適格な手続きによって業務プロセスが遂行されていることを証明できるようにして

おく必要がある。その際、アプリケーション・システムや基盤のシステム、現場でのエンドユーザーコンピュー

ティング、そして業務委託している先での管理状況も対象にし、工程としてはシステム開発／保

守／運用といった全プロセスに及ぶ。具体的には、公開会社会計監視委員会（PCAOB）が定めて、米国証券取引委員会（SEC）が

承認を与えた「監査基準第 2 号」（2004 年 6 月）で、財務報告に関する内部統制の文書において

は、以下の項目を記載するものとされている21。・重要な勘定科目と注意事項に関して、経営者の主張（アサーション）と内部統制のコントロ

ールを関連付ける。・重要な取引の起案・承認・記録・処理・報告がいかになされているかを明らかにする。・不正やエラーによって、重要な虚偽記載がどの業務フローの部分で起こりうるかを明らかに

する。・統制活動の区分（防止的・発見的のいずれか）と統制の実行者（もしくは職務の分掌等）に

ついて記載する。・資産の保全、決算期の決算作成手続きに関する統制活動を記載する。・経営者が行った財務報告に関する内部統制の手続きとその結果を記載する。

20 【文献 13】「平成 17 年度企業情報マネジメント研究会報告書」


455

この際、文書化の形式は書類でも電子ファイルでもよく、方法はフローチャートでも記述式の

説明など、様々な要領が考えられるとしている。ただ、不適切な文書化は、それ自体が内部統制

の問題であるとも記載している。こうして厳しい法が準備期間も十分には取れないまま施行されたが、当然様々な問題が浮上し

てきた。そのために、2005 年 4 月 13 日には、「内部統制報告制度の実施状況に関するラウンド

テーブル」が、証券取引委員会（SEC）の主催により開催された。出席者は、企業、監査人及び投資家で、議題としては、①初年度適用、②外部報告、③計画と

構築、④文書化と検証、そして⑤今後の課題であった。証券取引委員会（ドナルドソン委員長）と公開会社会計監視委員会（マクドノー委員長）は、

当日の議論を踏まえて、5 月 16 日に内部統制報告制度実施に関する追加的なガイダンスを公表し

た。その中で、新制度の総括として、「企業改革法への準拠によって、公開企業の高経営層におけ

る内部統制への関心が高まっており、より良い財務報告が行われることが期待される。」としなが

らも、「内部統制報告制度は、多大なコストを生じさせている。その多くの部分は、新規定の導入

初年度に特有のものではあるものの、過度で、重複が多く、又は焦点が絞れていない作業によっ

て無視できない額のコストが生じていることも確かである。」と、一番の改善項目として過大なコ

ストを挙げた。そして、対応策として、提示したのは以下の項目などである。・経営者と監査人が、合理的な判断を行使して、「紋切り型の、積み上げ式のチェックボックス

アプローチ」ではなく「トップダウン型のリスク重視のアプローチ」を採用し、他の専門家

等の利用を図れば、不要の作業を回避できる。・財務諸表監査と内部統制監査を効果的に統合すれば、コストは大幅に削減できる。・財務報告に係る内部統制は、企業の性質及び規模を反映するものでなければならず、特に小

規模の企業については、COSO に対して、新たなガイダンスの策定を求める22。・経営者、監査人及び監査委員会が頻繁かつ率直に対話することは、内部統制及び財務報告の

改善という目標の実現のために重要であり、経営者が内部統制の構築を経営者自身の意思決

定で行う限り、監査人の独立性規定違反とはならない。

その後も、見直しを求める声は強く、今後の企業活動に定着して組み込まれていくレベルまで

定まっているとは言えない状況である。

21 【文献 14】「米国企業改革法のインパクトとｅ文書法施行の意味」 22 小規模公開企業向けのガイダンスは、2005 年 10 月 26 日に公開草案が出された。


456

６．日本における内部統制の考え方（ソロバン時代の内部統制）

米国および英国の事例を見てきた。目を転じてわが国の内部統制の歴史を振り返ってみる。今から 55 年前の 1951 年 7 月に、通商産業大臣（当時）の諮問を受けて、産業合理化審議会が

「企業における内部統制の大綱」という答申を出している。その冒頭に、以下の記述がある23。

『もともと企業の内部統制の問題は、企業の創意工夫にまつべきものであるが、諸外国殊に米

国に比して甚だしく立遅れたわが国企業の合理化を速やかに推進するためには、この際、わが国

企業の現状に即する内部統制のあり方を提示してこれを普及徹底することがも当を得ていると

いうことができる。以上の見地から、産業合理化審議会は、長期にわたる審議において米国の諸文献を研究すると

ともに、わが国の現状の把握に努めた結果、企業における内部統制の大綱につき別紙のような結

論に達したので、ここに答申する。（省略）あたかも本年 7 月 1 日から実施されることになった証券取引法に基く公認会計士の強制監査に

対する受入体制を整えるためにも、企業における内部統制組織を整備確立することは時宜に適す

るものと信じる。』この大綱の中での内部統制の定義は、以下のとおりである。『ここに内部統制とは、企業の高方策にもとづいて、経営者が、企業の全体的観点から執行

活動を計画し、その実施を調整し、かつ実績を評価することであり、これらを計算的統制の方法

によって行うものである。』 1950 年の監査基準では、内部統制を内部牽制と内部監査に限定していたが、5 年かけて検討を

重ねたこの定義では、プロセスに注目して、執行活動の実施計画・計画実施の調整・実施結果の

記録と計算の評価を要素とする新しい定義を出している。予算実績対比をベースにしたコーポレートガバナンスの強化宣言のようなものであるが、米国

での歴史と照らし合わせると、日本が米国の先端の情報を貪欲に取り入れようとしていたこと

が窺える。

23 【文献 6】「企業における内部統制について：産業合理化審議会答申」


457

７．日本における内部統制の考え方（時代を先取りした金融庁検査マニュアル）

（１）検査マニュアルのできるまで

日本において、COSO フレームワークの概念が全面的に導入されたのは、1999 年に、金融機

関においてであった。これは、大和銀行 NY 支店の事件等がきっかけとなって、米国が内部統制

の強化をバーゼル銀行監督委員会（BIS）に働きかけて、1998 年 9 月に「銀行組織における内部

管理体制のフレームワーク」を公表したことによる。その時に参考とされたのが、COSO フレームワークであり、日本の金融検査マニュアルのベー

スとなった（そこまでの経緯については、付録 10「金融庁検査マニュアルのできるまで」を参照）。金融検査マニュアルが策定されることになった直接の発端は、政府・与党の金融再生トータル

プラン推進協議会がとりまとめた 1998 年 7 月の「金融再生トータルプラン」である。その本文の中に「検査・監視・監督のための体制強化」の一環として、「金融検査については、

外部のノウハウを取り入れた検査マニュアルおよびチェックリストを整備し、年内に公開する」

ことが明記された。 1998 年 8 月、金融監督庁（現在の金融庁）は金融検査マニュアルを検討するために「金融検

査マニュアル検討会」を発足させた。検討会の座長は岩原紳作・東大法学部教授、座長代理に野

村修也・中央大学法学部教授、その他、監査法人、日銀考査局、銀行業界からのメンバーが加わ

り、民間からのメンバーとして木村剛氏を加え、総勢 12 名で検討が開始された。そして 14 回の

検討会を経て、1998 年 12 月に「中間とりまとめ」を公表し、パブリックコメントを反映させて、

1999 年 4 月に「終とりまとめ」を公表した。そして 1999 年 7 月銀行等を対象とする初の検

査マニュアル「預金等受入金融機関に係る検査マニュアル」（金融検査マニュアル）が発出された。なお、2005 年 8 月には監督指針が公表されるとともに、6 年ぶりに改訂された新しい保険検査

マニュアルが 2006 年 7 月 1 日から適用されている24。

（２）検査についての金融庁の考え方

金融庁の検査は「業務の健全かつ適切な運営を確保し、契約者等の保護を図る」ために行うも

のとされており、検査マニュアルはその際の検査官の手引書として策定されている。改訂前の検査マニュアルの冒頭には「基本的な考え方等」と題する記述があって、良くまとま

っていた。他業界の方にも通じるポイントは以下のとおり。

ａ．自己責任原則自己責任原則に則った経営が基本である。・業務の健全かつ適切な運営を確保し、契約者等の保護を図ることは、自己責任の徹底と市場

規律の強化によって達成されなければならない。・自己責任原則に基づく企業自身の内部管理と、会計監査人等による厳正な外部監査が前提に

あって、検査がこれらを補強する。・企業が内部統制のプロセスを説明し、そのプロセスが適切に機能していることを自ら証明す

24 【文献 A3】「新しい保険検査マニュアルと総合的な管理指針」


458

る義務を負わされている。

ｂ．プロセスチェックを中心とした事後監視型チェック不祥事件が生じていないかどうかといった結果のみに着目するのではなく、むしろ問題が生じ

ないような内部管理・外部監査体制が確保されているか否かというプロセスチェックに重点を置

いている。すなわち、外見ではなく中身であり、器ではなく実態が重視されることになる。方針

や規程だけでなく、リスクの顕在化を防止・軽減するような仕組みがあるのか、またそれが有効

に機能しているかといったプロセスが問われることになる。

ｃ．トップダウン型の検査取締役会・監査役自身が、企業の抱える各リスクの特性を十分理解し、必要な資源配分を行い、

かつ、適切な内部管理を行っているか否かをまず確認していく、いわゆるトップダウン型の検査

方式を念頭に置いている。検査の際には、まず担当取締役や部長にヒアリングを行って、その後に現場でのチェックを行

って実態を検査するという手法がとられる。その結果実態が伴っていないということであれば、

場合によっては、取締役や管理者が虚偽の説明をしたか管理能力がないと判断され行政処分につ

ながってゆくという過程を辿ることになる。なお、外部監査人によるシステム監査も、同じようにトップダウン型で進められるが、システ

ム担当役員あるいはしかるべき責任者へのヒアリングに、本人が初に出てくる企業は管理もし

っかりしているが、部下が代わりに出てくるケースが現状では多く、そうしたケースでは管理レ

ベルも低く、経営が関与しているかどうかのバロメーターになるという話をよく聞く。立派なド

キュメントをリスク管理担当が作っても、経営が理解し自らの言葉で語ることができなければ、

絵に描いた餅と言うことになる。

（３）検査マニュアル

検査マニュアルの構成については、付録 11「検査マニュアルの構成」を参照。

ａ．システムリスク管理態勢のチェック項目 9 ページ弱に渡って、以下の 6 つの区分で、チェック項目が挙げられている。・「システムリスク管理態勢の整備・確立状況」・「情報セキュリティ管理態勢」・「システム企画・開発態勢」・「システム運用態勢」・「外部委託管理」・「非常時等への対応」それぞれの項目について、自社の現状を点検して、「現状と問題認識」、「エビデンス」、「講じる

対策」等を簡潔に記載したシートを作成してみてほしい。答えに窮するものも出てくるが、課題

として、全体を整理していく。そのとき、チェックシートの項目を限定的に捉えるのではなく、

それを参考に自社に当てはめて広く捉えていくことが大切である。


459

ｂ．検査における主な指摘事項検査において金融庁が指摘した主な事例が「金融検査指摘事例集」として、公表されている。

新の 2005 年度（2005 年 7 月～2006 年 6 月）分の中から、システムリスクを中心に具体例を

付録 12「金融検査指摘事例集」に挙げた。

８．裁判で取り上げられた内部統制の不備および会社法が定める内部統制

（１）裁判で取り上げられた内部統制の不備

内部統制の不備を理由に、過去厳しい判決が下されている（付録 13「大和銀行事件の判決（抜

粋）」参照）。も有名なものは、大和銀行 NY 支店事件に関する代表訴訟である。この判決は、2000 年 9

月 20 日大阪地方裁判所で、役員に 829 億円（当時の日本円）の損害賠償を命じたことから、大

きな話題になり、今回の会社法制定の一つのきっかけにもなったが、判決文の中に、「内部統制シ

ステム」という言葉が判決に使われており、その意味するところを判決から読み取って対策を講

じなければいけないと言うことである。他にも、粉飾事件ではないが、神戸製鋼所の利益供与事件の和解（3.1 億円）などにも、「大企

業の取締役には不正行為防止のための内部統制システムを構築すべき法律上の義務がある」とい

う判決がある。近も増えてきているこうした判例に照らして、各企業が構築している、または考えている内

部統制で、裁判に勝てるのか、という問いをしてみることが必要になる。しかし、具体的にどうすれば良いのかについては、過去のこうした判例からだけでは明確なイ

メージが湧かないと言うのが事実である。前記金融庁の検査マニュアルに加えて、以降述べる経済産業省のレポートや各団体の資料が参

考になる。さらに、よりシステムに近い事案として、米国証券取引所（SEC）から制裁金を命じられ、株

主訴訟で高額の賠償を求められている事例の方が、システム部門の方達には強烈なインパクトが

あり、システムが主管となって対応しなければならないので、注意すべきである。例えば、有名になった事例として、モルガン・スタンレー社がメールの保管を怠りログを提出

しなかったために、SEC に対して 1,500 万ドルの制裁金、フロリダの個人投資家に対して 14.5万ドルの賠償金を支払いを命じる判決が出た。

（２）会社法が定める内部統制

2006 年 2 月 7 日に、会社法の省令である会社法施行規則、会社計算規則及び電子公告規則が

公布され、会社法が 2006 年 5 月 1 日に施行された。「内部統制システムに関する取締役会決議」は、会社法施行日以後初に開催する取締役会ま

でには行われなければならないということが規定されている。この関係で、既に、内部統制システムに関する何らかの決議が行われているかも知れない（内

部統制システムに関して取締役会で決議すべき事項については、付録 14「会社法が定める内部統

制」を参照）。


460

９．日本における内部統制の考え方①（経済産業省「リスク新時代の内部統制」）

（１）経済産業省「リスク新時代の内部統制」作成の背景

厳しい判決が、日本国内の内部統制に関する取り組みが活発化する契機となった。企業法制における 2003 年 4 月の改正商法、企業会計審議会の改訂監査基準、日本経済団体連

合会の企業行動憲章の改定などで、コーポレートガバナンスの確立と内部統制の整備・強化が掲

げられた。こうした状況の中で、経済産業省は経済産業政策局長の私的研究会として 2002 年 12 月に「リ

スク管理・内部統制に関する研究会」（座長：脇田良一明治学院大学学長）を設置し、6 回にわ

たり研究会を開催するとともに、パブリックコメントも踏まえて 2003 年 6 月に「リスク新時代

の内部統制」と題する報告書（指針）を作成した。この報告書の冒頭で、この指針策定の背景となる企業を取り巻く環境の変化について記載する

とともに、リスクマネジメントおよび内部統制の重要性について説明している。この報告書の第二部が「内部統制に係る指針」となっており、内部統制の構築・運営上の留意

点が示されている（主なポイントおよび概要については付録 15「経済産業省「リスク新時代の内

部統制」の背景」を参照）。

（２）「リスク新時代の内部統制」の特徴

この指針の策定手法および内容についての主な特徴を挙げると、以下のとおりである。・一連の企業不祥事の分析を行い、内部統制上の問題点を洗い出すことから検討を開始してい

る。また、日本経営品質賞等を受賞した企業へのアンケート調査も実施している。・米国の COSO フレームワーク、そしてより動態的でリスクマネジメントを強調したターンバ

ルガイダンスやカナダの CoCo レポートを参考に策定されており、企業不祥事の分析に当た

っては、COSO フレームワークで定義される内部統制の構成要素（統制環境、リスク評価、

統制活動、情報と伝達、モニタリング）に照らして問題点を明らかにし、対応を検討してい

る。・副題として「リスクマネジメントと一体として機能する内部統制」が付されており、リスク

マネジメントと内部統制とが相互に補完・補強しながら一体として運営されてゆくべきもの

と位置付けている。具体的には、リスクマネジメントを内部統制が支え、内部統制が有効であるためには総合的

なリスク評価に基づいてダイナミックに見直されなければいけないということである。・リスクを「事業活動の遂行を阻害する事象の発生の可能性」というマイナス要因（悪い結果

の可能性）としてだけで捉えるのではなく、「将来の企業収益に影響を与える事象発生の不確

実性」と捉え、収益機会や事業戦略など（プラス要因）の不確実性なども含む広義の概念と

して定義している。プラス要因の不確実性がなぜリスクなのかについて、やや理解しにくいかも知れない。例えば、

売れすぎて工場生産が間に合わなくなって供給に支障が出たり、ステークホルダーである株主に

とっては株価が上がるのであればもっと購入株数を増やすことができたはずという例が、挙げら

れる（この指針の概要については、付録 16「「リスク新時代の内部統制」の指針の概要」を参照）。


461

10．日本における内部統制の考え方②（経済産業省「開示・評価の枠組みについて」）

経済産業省は「リスク新時代の内部統制」から 2 年 8 ヶ月後の 2006 年 2 月、産学官の代表お

よび弁護士、機関投資家、各協会代表等をメンバーとした「企業行動の開示・評価に関する研究

会」を設置した。結果としてまとまった「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評

価の枠組について－構築及び開示のための指針－」には、不祥事防止等のために企業経営者が取

り組むべき項目が示され､それらを構築および開示するための指針が提示されている25。特に、「コーポレートガバナンス」と「内部環境（特に行動規範）」の 2 項目において何らかの

問題があったことが、多くの不祥事発生及び発生後の重大な損害の拡大の重要な原因となったの

ではないかという結論を導き出している。そして、推進体制の整備・運用に積極的に取り組んでいると考えられる企業経営者等に対して

ヒアリンダ等を行い、積極的な取組事例を調査している。続いて、「コーポレートガバナンス及びリスク管理・内部統制」を自主的に構築し、その結果の

社内体制・規範等を、ホームページや諸資料において開示していくこと、および評価する枠組み

を整えることの重要性を述べている。

（１）「構築及び開示のための指針」の特徴

特徴 1：「COSO レポート」、「COSO-ERM」、「コンバインドコード」、「リスク新時代の内部統制」と

言ったフレームワークに加えて、カナダの CoCo レポート、EWRM モデル、ORCA モデルの考

え方をまずは幅広く紹介している。目的を、指針を参考にして自主的に構築していくことに置き、そのために参考とするべき基本

的事項を提示するという、本マニュアルと同じシナリオになっている。

特徴２：「リスク新時代の内部統制」では、「リスクマネジメントと一体として機能する内部統制」と言

っていたが、本指針では、さらに一体化して、「リスク管理・内部統制」という一単語で扱われる

ようになっている。そして、その代わりに、「コーポレートガバナンス」という言葉が加わってい

る。日本経済新聞では「内部統制」という単語を使わずに「企業統治」と言い換えているが、同じ

ように、本指針のコーポレートガバナンス（企業経営を規律するための仕組み）は、会社法の説

く内部統制に近く、かつイメージが明確になっている。コーポレートガバナンスという言葉を持ち出したことで、一歩踏み込んだ回答を導き出してい

る点が評価できる。

25 経済産業政策局長の私的研究会、座長：伊藤邦雄 ―橋大学副学長

分類の項目は、「コーポレートガバナンス」に加えて、COSO-ERM の構成要素を意識した 7つの項目、すなわち、「内部環

境（行動規範、職務権限）」、「リスク認識・評価」、「リスク対応」、「情報と伝達」、「統制活動」、「監視活動」という計 8

項目を用いている。


462

JUAS の部会で、「エンロン事件を契機に米国版 SOX 法が制定されたが、日本版エンロン事件

として取り上げられている西武鉄道事件等を、貴社で構築中の内部統制で防げますか」と質問す

ると、「ストレートな解決にはならないが、管理レベルの向上に役立つ」というような回答が返っ

てくる。これは、COSO-ERM の部分で述べた限界に該当する（この節の「（３）COSO-ERM（Enterprise

Risk Management）の考え方」参照）。その回答を、以下のように用意している。「企業経営者自身が構築した企業風土によって自らの経営を規律していく。企業目的や経営理

念を無視して暴走したり、保身のために隠蔽行動を取るなど、自身による規律が働かなくなる場

合には、監視する仕組みを整備・運用する方策を用意して、実質的に機能する形態を選択できる

ようにする。」26

特徴３：

多くの日本企業の取り組みは、計画と実行までは力を入れるが、その結果を評価してオープン

にし、継続的に改善していく部分が弱いと言われる。そういう意味では、制度的な要請によるも

のとは言え、会社法上の事業報告、証券取引法上の有価証券報告書、東証の上場規則での決算短

信などでの開示は、将来の格付機関等からの評価も考え合わせると、今後、企業にとって、大き

な課題になっていくものと考える。なお、「リスク管理・内部統制」と「コーポレートガバナンス」という切り分けについては、リ

スク管理という面で懸念事項がある。企業経営者を対象とする「コーポレートガバナンス」と、それ以外、すなわち従業員のための

リスク管理というイメージが強くなると、本来、企業の中で一つの概念でまとめて一体感を持っ

て推進していくものが、2 つの概念で分断されることになる。実は、企業経営者が暴走したり隠蔽を行うことは、企業にとって大のリスクであり、企業経

営者にとっても失職と言うリスクを抱えることになる。規律もあるが、「リスク認知の歪み」に注

意して、経営者が自分を見失わないようにすることが重要である。

26 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P36


463

（２）問題点と積極的な取り組み事例27

報告書ではガバナンスの問題と位置づけられても、IT としてどう捉えるのかと言う紐付けを常

に考えて読まなければならない。明示的に IT の問題としてクローズアップされる指摘はほとん

どなく、あっても新聞で騒がれた誰でも知っているシステム障害の話題で、自ら問題を掘り起こ

していかなければ、一歩踏み込んだ解決には至らない。問題点

経営者のリスクヘの認識の欠如によって、不祥事が起こった際の社会への影響等を事前に考慮

できない。また、経営者が、企業内の専門性のある業務の内容を理解せず、当該業務分野への統

制・監視が働かずに、不祥事の発生、損害が拡大する。著者のコメント

リスク認識の問題であり、社内にブラックボックスを作らないように、「見える化」、「可視化」

を推進していくことである。システム分野もこの種の一つとして扱われやすい。CIO という役割

を作ることも必要であるが、そのことで取締役会の責任は免れられない以上、ラインやスタッフ

はわかりやすい経営への報告を心がけ、経営はわかるまで説明を求めることで溝を埋めていくし

かない。

事例① 経営に重大な影響を及ぼす不測な事態が発生した場合の対応を事前にマニュアル化して、重大

な問題が発生した場合でも適切な対応が取れるようになっている。著者のコメント

マニュアルを作成するだけでは、不十分である。大多数のミドルマネージャが緊急対応の検討・

実習に参加して日頃から体験しておくことである。また、マニュアル化するだけでは不十分なことが多いのが現実である。不測の事態になると机上の想定にない事態が起きる。卑近な例であるが、平時で起きたシステ

ムトラブル発生時に、関係者に召集のための携帯電話メールを一斉に送ってみると、プロバイダ

がスパムメールと判断して機能しなくなることがある。有事には尚更である。

事例② 具体的な不祥事例を基に研修を実施し、従業員の教育に役立てている。また、そのような不祥

事例を踏まえて、リスク認識・評価を定期的に見直している。著者のコメント

具体的な不祥事例に基づく研修は極めて有効である。また、不祥事例を踏まえた見直しは、同

種の不祥事が自社で発生しないようにするには、手堅いアプローチである。

27 重要と指摘された「コーポレートガバナンス」と「内部環境(特に行動規範)」の 2項目に関する問題および取り組みに

ついては、経済産業省のレポート（【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・

評価の枠組みについて」P16～P28）を参照。


464

11．日本における内部統制の考え方③（金融庁企業会計審議会の報告書）

上場企業の不適正な開示が、2004 年 10 月以降相次いで判明したことから、内部統制を巡る論

議が活発になり、2004 年 11 月 16 日に金融庁が「ディスクロージャー制度の信頼性確保に向け

た対応」を公表した。そして、全開示企業に対して株主の状況等についての開示内容の自主点検

を要請したところ、2005 年 1 月末までに 14.3%（652 社/4543 社）もの訂正報告書が提出される

状況であった。28 こうした事態もあって、2005 年 1 月の企業会計審議会総会において、「財務報告に係る内部統

制の有効性に関する経営者による評価と公認会計士等による検証の基準の策定を行う」ために「内

部統制部会」を設置することが決定された。内部統制部会は、2005 年 2 月からスタートして、計 11 回の審議を経て 2005 年 7 月 13 日に公

開草案を公表し、寄せられたパブリックコメントを反映させて、2005 年 12 月 8 日に「財務報告

に係る内部統制の評価及び監査の基準のあり方について」を公表した。報告書では、財務報告の信頼性を確保するために、経営者による財務報告に係る内部統制の評

価の報告と、監査人によるこの評価の妥当性監査を要求し、評価・監査の際に準拠すべき基準を

定めている。構成としては、公表文と基準案からなる。公表文では審議の背景や基準案の構成および主な内容等などが記載されている。基準案は、「Ⅰ．内部統制の基本的枠組み」「Ⅱ．財務報告に係る内部統制の評価及び報告」「Ⅲ．

財務報告に係る内部統制の監査」の 3 部から構成されている。このうち「Ⅰ．内部統制の基本的枠組み」の部分で、COSO フレームワークと対比しながら、

内部統制の考え方をまとめている。追加された「資産の保全」については、他の 3 つの目的にも含まれるものの、これを明示的に

示すことで、日本の監査役制度における財産調査権を持つ監査役と内部統制の係り方をより明確

にするために加えられたとされている。また、「IT への対応」は IT 環境の飛躍的進展により IT が組織に浸透した現状に即して明示的

に追加したとしている。さらに、基準案は、内部統制の限界および関係を有する者（経営者、取締役会、監査役または

監査委員会、内部監査人、その他）の役割と責任について触れている。「基準案」後半の 2 つの部分は、米国企業改革法（サーベインズ・オックスリー法）第 404 条

に対応する部分であり、本基準が「日本版 SOX 法」と呼ばれる由縁ともなった。 2005 年 12 月 22 日に、金融審議会金融分科会第一部会が公表した「投資サービス法（仮称）

に向けて」の「開示規制」において、この「基準案」の検討結果を踏まえ、「財務報告に係る内部

統制の有効性に関する経営者による評価と公認会計士による監査について、その義務化を図るこ

とが適当である。」として取り上げられ、導入の具体的な方向が明確になった。

28 【文献 15】「日本版内部統制報告実務の新動向（EA フォーラム 2005 Winter）」


465

「証券取引法等の一部を改正する法律」は、2006 年 3 月 13 日に国会へ提出され、「金融商品

取引法」（いわゆる投資サービス法）として 6 月 7 日に成立した。この結果、2008 年 4 月 1 日以

降に始まる事業年度より、有価証券報告書の提出会社は、財務報告の適正性を確保するために必

要な体制について評価した内部統制報告書を、有価証券報告書と併せて提出することが求められ、

また、内部統制報告書には公認会計士または監査法人の監査証明を受けなければならないことに

なった。基準案は骨格のみを示したものであり、実務に適用していくには具体的な指針が必要である。

内部統制部会もそうした要請に応え、「実施基準」の整備を行うべく、策定のための作業部会（22名の専門委員）を設置し「実施基準に係る主な検討項目」に沿った作業を進めている。しかしな

がら、実施基準は現時点（2006 年 9 月）、まだ公表されてはおらず、年末までずれ込むとの予測

もある。期限までに残された時間が削られていく中で、JUAS 研究会の参加企業も含めて各企業は手探

り状態で体制を立ち上げつつある。マスタースケジュールは、やらなければならない作業を低

限必要な期間でつなぎ合わせていくと似たようなものになるが、まだ「何をしたら良いかわから

ない」、「パイロット的に代表的な業務に適用してドキュメントを作成してみたが全体を期限内に

終えられない」等の声を聞く。そして、理想論（やらねばならない）からスタートして行き詰ま

り、何のためにやるのかと自問したり、やれるものしかやれないと開き直ってしまう傾向が出て

きている。やはり、「会社にとって何が大切なのか」という観点からの経営を巻き込んでの整理がないと、

主管部門の安全サイド（完璧主義）に偏り過ぎた指示や、実現した後の日々の実務に耐えられな

い重い仕組みに気がつかずにいたり、書籍や講演会で学んだことの受け売りを吟味しないまま自

社に当てはめようとしたりする傾向がある。検討中の実施基準の内容に関わらず、経済産業省の項で述べた問題認識と、背景となった米国

企業改革法の実績などを参考に、自社なりの考え方を整理することがまずは大切である。


466

12．リスク管理・内部統制の諸レポートの全体像

繰り返された不祥事に都度対策を練ってきた変遷を知ると、この問題の深さと同時に、机上の

検討だけでは手に負えない難物で、現場を巻き込んでの実践に数々のハードルがあるということ

がわかる。

（１）COSO フレームワークが浸透した理由

COSO フレームワークが、なぜあれほど世界に浸透し、いまだにデファクトの位置を保ってい

るのか。これは、粉飾を監査法人が見抜くよりも、倒産しないような企業体質に変えていくことが根本

解決ではないかという、一歩掘り下げた問題意識からであると推察している。そのために、目的に会計監査の対象ではない「業務の有効性・効率性」という柱を設け、構成

要素の一つとして、「コミュニケーション」というキーワードに辿りついて、盛り込んだ。29

当時の米国がどうであったのかと言えば、米国全体で経済が低迷していた時期に当たる。COSOフレームワークの発表された 1992 年は、ブッシュ（親）大統領が、GM（General Motors）社、

フォード・モーター社、クライスラー社のアメリカ自動車ビッグスリーの首脳を連れて来日し、

アメリカ製自動車部品の購入拡大など、日本の市場開放を求めて圧力をかけた年であり、秋には

ゼネラル・エレクトリック（GE）社のウェルチ氏が、『アメリカの多くの会社同様、GE もトッ

プダウンの組織体系を持っていた。しかし、私たちは新しい文化を育てた。それは、コンセンサ

スを得るために、一緒に討論するという日本の文化に似たものだ。アイデアの重要性を、組織の

どのポジションから出てきたのかということではなく、その質によって決めようという新たな文

化だ。』と、人間尊重の日本的経営を賞賛した。30 COSO だけが当時検討された解決策ではなく、経営品質賞でベストプラクティスを横展開して

管理レベルを上げていくような、国家を挙げての複数の取り組みと共にシナジー効果を持って推

進されたと見るべきだと思う。COSO が欧米で新鮮さを持って受け入れられていったのは、日本

のこうしたモノ造りの良さを採り入れたからだとすれば、日本はさらにその強みを活かしていか

なければならない。少なくとも、不祥事案への対策だけが過度に先行しないように、車の両輪である企業価値の向

上ともバランス良く保ちながら進めることが必要と思う。

（２）歴史の流れと管理レベル

全体の歴史の流れを整理してみると、事業活動に係る統制と会計統制の 2 者が絡みながら、管

理レベルが上がってきた様子がわかる。初は、会計に注目するが、それでも不祥事は発生して事業活動に係る統制の強化に発展して

いき、ERM に辿り着いたのが米国の流れである。そして、その強化の仕方は、経営の自由度を

尊重しつつも、不祥事件が重なるたびにより深く細かくなってきている。

29 【文献 1】「システムリスクに挑む : 金融検査マニュアルを超える実践ガイド」P105 30 【文献 10】「ウェルチが日本を変える」


467

一方、英国のように、会計統制から入っていくが、ガバナンスとして大きく捉えて、内部統制

をその一部として位置づけ、経営の責務を厳格に捉える一方で、投資家にも規範を求める流れも

ある。欧州が米国企業改革法にクールな対応をしている背景に、こうしたリスク文化の違いがあ

るものと考えられる。

（３）COSO を中心とした流れ

COSO を中心とした流れを以下に図示する（図表 5-2-6）。特に、目的の範囲に注目して書き込

んでいる。今までの流れを振り返ると、まず COSO は目的が 3 つあった。COSO-ERM は目的をもう一つ

（戦略）加えた。米国企業改革法はその 1 つの目的に絞って掘り下げていった。金融庁の検査マ

ニュアルは COSO フレームワークをベースとして、いろいろ付け加えている。米国ではCOSOフレームワーク発祥の国として3つの目的が浸透しているという前提があって、

さらにその柱の一つである財務報告の信頼性を深掘りしているという点で、日本と米国では環境

の成熟度が違う（米国は T 字型）。日本において、金融庁の検査マニュアルを通して COSO フレームワークを理解している金融機

関や自主的に取り入れている企業を除けば、一つの目的（財務報告の信頼性）だけで、いきなり

深掘りすることになるが、全体が見えずに部分適になりやすく、後から必ず修正が発生する（I字型）。終的に、企業活動に必要な統制の目的をすべてカバーするように、全体像の中での位置

づけを明確にしながら、段階的に実現していく必要がある。

時代に合わせた改定

財務報告中

COSO 内部統制（1992）

COSO ERM （2004）

米国企業改革法404条（2002.7.30）

米国米国

バーゼル委員会（BIS）指

金融庁・検査マニュアル

金融証券取引法（2008）

日本日本

各国の銀行の監督官庁

採択

日本で目的：４項目

企業

目的：3項目

目的：１項目目的：４項目

目的：１項目

英国ターンブル委員会ガイダンス

1999年：金融機関に係る全てのリスクを対象に、リスク管理態勢を構築

国例

他の

1999年：取締役会の責任を明確化するなど実効性を担保

1998年：銀行組織における内部管理態勢のフレームワーク

内部統制の有効性に関する企業経営の報告義務。違反に厳しい罰則。

内部統制とリスク管理の融合。

図表 5-2-6 世界の内部統制の流れ


468

469

第５章リスク管理・内部統制第３節リスク管理（実践編）

─システムリスク管理の実践で逞しくなる─

リスク管理の一般的な進め方は、次のようなサイクルとなる。

・リスクの洗い出し

↓

・リスク評価（シナリオ作成・数量化）

↓

・リスクマップの作成

↓

・リスクの優先度付けと対策の目標設定

↓

・リスク対策計画の策定（年度計画と中長期計画）

↓

・自主点検

↓

・指摘事項に対する対策の実施

↓

・改善状況の振り返り

↓

・経営者によるレビュー

この節では、システムリスクの管理に関して、以下のトピックスを紹介しながら、この流れの

ポイントを解説する。

１．システムリスクのシナリオ分析

２．数量的なトラブル管理（お客様迷惑度指数）

３．IT 法務

４．アプリケーションオーナー制度（発注者の果たすべき役割）

５．システム開発に係るリスク管理

６．システム運用に関わるリスク管理

７．自主点検（システムリスク管理態勢の確立）

５－３リスク管理（実践編）

470

１．システムリスクのシナリオ分析

ある会社の事例をベースに、実践例を紹介する。31

自社で定めたリスクの定義に則って、まずは、自社にとって何が大切か、自社を廃業に追いや

る可能性のあるリスクは何かを洗い出すことから始める。特に、コアビジネスに関連した調査・分析を行うことで、リスク感性が磨かれていく。

（１）「シナリオ」の意味

リスク管理では「ベストシナリオ」、「ワーストシナリオ」、「標準シナリオ」のような言葉が出

てくるので、この言葉から説明する。例えば、システム開発の設計ミスに起因するリスクを考えてみる。設計ミスは誰もが起きて欲

しくないと願っているが、細心の注意を払っていかに小さく抑え込んだとしても、可能性として

ミスは常にありうる。ここで仮に、インターネットを利用した有料の顧客サービスシステムがあり、リスクとしては、

開発担当が仕様を一部間違え、特定のケースだけ、本来の料金よりも高額の料金を請求するよう

なかたちでシステムが開発されているとする。その後の推移を予測してみる。も望ましいのは、システムテストの段階でその誤りが発見さ

れ、サービス提供に先立って正しく修復されることである。一方、悪のケースとしては、こんな事態が想定される。システムテストでもミスは発見され

ることなく、予定どおりサービスが開始された。初は利用者も少なく、仕様の誤りに誰も気づ

かなかったが、次第に利用者が増加し、1 年ほど経ってから料金がおかしいのではないかとの照

会が寄せられた。この結果、サービス開始以来の誤りが判明し、調査したところ、該当する顧客

は 1 年間で 5,000 名に及んだ。これらの顧客にはお詫びの文書を送るとともに超過料金の返戻を

行ったが、マスコミの知るところとなり、週刊誌に書き立てられた。ここまで行かなくても、気がつかないままサービス提供が開始され、開始から数日のうちに誤

りではないかとの照会が寄せられ、大急ぎで修復を図るというようなことはありうる話である。以上の例で、システムテストで発見されたという「いちばん望ましい」事態が、「ベストシナリ

オ」である 1 年経って誤りが発見され多くの対応を余儀なくされた「悪のケース」が、「ワー

ストシナリオ」である。そして、「もありそうな」サービス開始後数日で誤りが発見されるケー

スが「標準シナリオ」となる。このように、一つの問題状況を想定したとき、それに起因して顕在化するリスクは様々である

ことを知っておく必要がある。

31 【文献 1】「システムリスクに挑む : 金融検査マニュアルを超える実践ガイド」


471

（２）シナリオの描き方

同じ原因を設定しても、想定する途中経過によって、顕在化した場合のリスクの程度は千差万

別である。リスクシナリオに詳しいリスクコンサルタントによると、この 3 種類のシナリオは、

コンサルティングを業とする者であれば、さほどブレなく描くことができるのだという。また、

それぞれのケースの予想損害額や回復期間も、正確には予測できなくても、ケタを誤るほど読み

違えるようなことはなく、それができないようでは一流とはいえないそうである。リスク対応を的確に行うには、事実を冷徹に見つめ、ある程度の先読みを行うことが必須であ

り、リスク管理にかかわる立場にあるならば、日々の新聞等に載ったトラブル報道から、リスク

シナリオを描いてみることをお勧めする。自分なりに分析し、シナリオを何度も描いていると、システム障害の具体的な情報がなくとも、

結果は大体見通せるようになっていく。「システムのことはよくわからないから」、などと遠慮する必要はまったくない。事実を直視し

ながら冷静にリスクを読んでいると、自ずと見えてくる世界があり、これはシステムリスクの門

外漢でもできることである。大切なことは、自ら調べ、自ら考える姿勢を失わないことである。とはいえ、ベスト、ワースト、標準の 3 シナリオを読んだとしても、近のマスコミに取り上

げられる事例をみると、企業側では楽観的な評価・見通しでいたものの、結局そうはならなかっ

たケース、あるいはほとんワーストシナリオとなってしまったケースが目立つようである。これ

は、日本企業にリスク管理はまだ根付いていないことを感じさせる。補足しておきたいのは、例えば標準シナリオとして想定したケースであっても、リスク発現直

後の対応のいかんによっては、あっという間にワーストシナリオと化してしまうことがあること

である。その大きな差は、経営や部門の責任者のリスク対応の巧拙に大きく左右される。こうし

た人達が本来果たすべき働きをせず、しかも会社として一貫した方針によることなく行動するの

であれば、初からワーストシナリオを適用することが正しい判断ということになる。これに対し、経営者の大号令で組織が機敏に動き、迅速な対応で顧客に好印象を与えたケース

を目にするとほっとする。適切なリスク対応ができなかったために、一瞬にして地獄をみるとい

う恐怖は、幸いにしてこれまでほとんどの経営者が実感せずに済んできたが、これからは、そう

はいかなくなると考えるべきである。


472

図表 5-3-1 シナリオの実物例

【分類】システム ─ 止まる（2）火災

【概要】名古屋支店のサーバー室から猛煙が上がり破裂音が出たため、119 番通報し、消防署員による注水で消火し

た。復旧まで 4 日間名古屋および近隣のシステムが停止した。

【経緯】月末の早朝、警備貝が煙感知器の作動により現場に急行。猛煙と破裂音を確認したので 119 番通報。消防署員

による注水で消火・鎮火したものの、現場検証等があり、片づけを開始したのは、当日夕刻。翌朝より内装業者による

修理が始まった。サーバーについては、調査の結果、煙による汚染と水濡れでほぼ全損であることがわかり、早速代替

機器を手配した。事故から 2 日後に代替機器を搬入し、その日に現地調整を完了。3 日後の午前にソフトウェアをインス

トールしてテストを開始した。殆どの業務が復旧したのは 4 日後の朝となった。

【原因・背景】上階の排水管からの水漏れが原因で、サーバーの電源モジュールが過熱して基板が焼け、さらにコンデ

ンサの破裂等が発生した。

【換言拡大・助長要因】【発生可能性】

・注水消火による水濡れ損害。

・代替機器の手記遅れ（さらに代替機器が製造終了の

場合は深刻）

・名古屋配下の支社が他のサーバーに接続する機能を

持っていない。

・事務繁忙期に事故が発生。

□1 回／数千年クラス

■1 回／数百年クラス

□1 回／数十年クラス

□1 回／数年クラス

□1～2 回／年クラス

□1 回／月クラス

□1 回／週またはそれ以上

【直接損害】【間接損害】

*損害額オーダー* *主な損害内容* *損害額オーダー* *主な損害内容*

□一千億円以上・サーバー等楓器損害 □一千億円以上・お客様､代理店へのサービス水

準が大きく低下

□数百億円クラス・他部店事務代行ロード □数百億円クラス・火災報道によるイメージダウン

□数十億円クラス・緊急エンジニアリング費用 □数十億円クラス

▼ 数億円クラス

□ 数億円クラス

▲数千万円クラス

・緊急用電話・FAX 等

・名古屋支店人的コスト □数千万円クラス

□数百万円クラス □数百万円クラス

□数十万円クラス □数十万円クラス

□十万円以下 □十万円以下


473

（３）システムリスクシナリオ分析手法

リスク分析に際しては、初に、大まかな業務単位ごとに、数種類の代表的なリスクシナリオ

を作成し、予想される直接的損害・間接損害、発生傾度ランク等のビジネスへの影響度合を推定

する。リスク分析結果の全体像は、図表 5-3-2 のように縦軸を予想損害額、横軸を発生可能性として

整理してみると、「巨大リスク」と「日常的なリスク」との 2 つに大別される。一般には、図の

右上に位置する「予想損害額が大きく発生頻度も高い事案」ほど対応の優先順位が高い。一方、日常的なリスクについては、トラブル記録からリスク要因や頻度分布に関する分析が可

能であり、その分析を経て有効なリスク対策を洗い出していくべきである。これは品質管理の考え方に通じるものであり、お客様に与える影響を分析しながら、どの程度

の信頼度を求めていくかである。こうしたリスクベースアプローチによるマネジメント手法は、システム分野に限らず、広くビ

ジネス全般に適用可能なものである。

数十万円オーダー

数百万円オーダー

数千万円オーダー

数億円オーダー

数十億円オーダー

数百億円オーダー

数千億円オーダー

予想損害額

１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻

は対策による変動幅

関東震災級地震

社員の故意による重大な情報漏洩

部門サーバデータ消失

ビル火災によるシステム停止重要帳票紛失

基本ソフト障害による停止(数時間×３日)

顧客磁気テープ紛失

東京直下地震

メールサーバ乗っ取られ

金利計算誤り

ＰＣ紛失情報漏洩

ロジックミスで損金

大規模な証券誤配送

キャタリスク数理統計的分析が

困難な領域


困難な領域

日常的リスク数理統計的分析に

馴染む領域


馴染む領域








予想損害額

１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻








東京直下地震


金利計算誤り





困難な領域


困難な領域








予想損害額

１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻








予想損害額

１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻








予想損害額

１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻１回／数百年

１回／数十年

１回／数年

数回／年

数十回／年

発生頻








東京直下地震


金利計算誤り





困難な領域


困難な領域








東京直下地震


金利計算誤り










東京直下地震


金利計算誤り





困難な領域


困難な領域


困難な領域


困難な領域


馴染む領域


馴染む領域


馴染む領域


馴染む領域

図表 5-3-2 シナリオ分析結果のリスクマップ

この図の便利なところは、経営にとって会社全体の抱えるリスクの全体像を見やすくすること

ができる点である。例えば、「社員の故意による重大な情報漏洩」がどの程度なのかは経営陣それ

ぞれに受け取り方が異なっているので、皆が自分の見解を述べて論議し合うことでそのレベル合

わせをすることができる。


474

この図表 5-3-2 は、実は 2001 年に作成した事例である。当時、情報漏洩が関東震災クラスの

損害を与えるというシナリオで優先の対策が必要と言う説明は、反響を呼んだ。しかし、その

後、こうした対策をリスク管理担当が検討する上で協力を得るのに大いに役立った。シナリオ分

析手法の良い所は、こうして組織全体でのリスク意識の共有化、リスク文化の醸成に役立つこと

である。そして、ベストシナリオに移行させるためにはどうしたら良いか、いくら投資が必要なのか、

ワーストシナリオはどうすれば回避できるのか、いくらかければ何処まで改善されるのかという

ことも、この図に矢印で書き込むことによって、全体適の観点からアクションプランをどう取

るのが望ましいのかなどの論議も一枚の図でできることである。また、2 つ目として、個別テーマの事例として重要情報（個人情報だけでなく、機密情報も含

む）の漏洩対策に取り組んだ事例の図も紹介しておく（図表 5-3-3）。会社の固有な形態によるものであるが、EUC の進展によって、コンピュータセンター以外に、

営業現場での PC の活用による漏洩リスクの発現する確率および予想損害額も大きいことから、

今までのコンピュータセンター対策に加えて、このカテゴリーに注目した対策にも力を入れた。

1件

10件

100件

1千件

1万件

10万件

漏洩の規

１件／年 10件／年発生の想定頻

紫（Ａ）：社内コンピュータセンター黄色（Ｂ）：社外委託先緑（Ｃ）：社内営業拠点青（Ｄ）：代理店

Ａ：コンピュータ

Ａ：コンピュータ

Ａ：ＰＣ、媒体の紛失・盗難

Ａ：ＰＣ、媒体の紛失・盗難

Ｂ：ＰＣ、媒体Ｂ：ＰＣ、媒体

Ａ帳票類の紛失･盗難

Ａ帳票類の紛失･盗難

Ｂコンピュータからの漏洩

Ｂコンピュータからの漏洩

Ｃ：コンピュータＣ：コンピュータ

Ｂ：帳票類の紛失・盗難Ｂ：帳票類の紛失・盗難

Ｃ：帳票類の紛失・盗難

Ｃ：帳票類の紛失・盗難

Ｃ：ＰＣ・媒体の紛失・盗難Ｃ：ＰＣ・媒体の紛失・盗難

Ｄ：ＰＣ・媒体の紛失・盗難Ｄ：ＰＣ・媒体の紛失・盗難

Ｄ：帳票類の紛失・盗難Ｄ：帳票類の紛失・盗難

Ｄ：代理店システムからの漏洩

Ｄ：代理店システムからの漏洩

大きく３つのグループに分類できる

図表 5-3-3 情報セキュリティのリスクマップ


475

２．数量的なトラブル管理（お客様迷惑度指数）

「日常的なリスク」については、統計的分析によって、システムリスク管理を行う。具体的な一例として、お客様迷惑度指数という取り組みを取り上げる（図表 5-3-4）。これは、被害金額を直接算出する仕組みにはなっていないが、システムやネットワークのトラ

ブルの大きさをお客様の視点や社員の現場感覚に合わせて数値的に評価していこうというもので

ある。

（１）要素ランクの設定

リスク分析は、素因数分解のようにして、構成要素を切り出してそのランクの設定を行い、ラ

ンク毎に係数（初期値は 1）を定めることから始まる。

業務の重要度

影響範囲

発生日のピーク性

時間的要素

地域の広がり

再発、反復性

係数のかけ算で数値化

×

×

×

迷惑度指数迷惑度指数

×

×

軽微・小規模・中規模・大規模に分類軽微・小規模・中規模・大規模に分類

＝＝

図表 5-3-4 お客様迷惑度指数

オンライン業務の場合を、例示すると以下のとおり。・影響の深さ・・・「お客様にまで影響が及んでご迷惑をかけた場合」、「影響が社内の現場まで

で収まった場合」、「IT 部門だけに留まった場合」等、その影響範囲の違いで係数は、小 1から 11 段階変化する。

・業務の重要度・・・3 つの区分に分けて係数が大 2 まで変化する。・時間的要素・・・回復までにかかった時間を 15 分未満から 4 時間以上までの 5 区分に分け

て、大 5 まで係数が変化する。・影響地域・・・一地域から全国レベルまで、3 区分で大 2.8 まで係数が変化する。・再発・・・迷惑は一定期間内に同じトラブルを再発させると大きい。再発は 1.3 とする。・ピーク・・・ピーク時のトラブルは影響が大きくなるので、1.3 とする。


476

（２）指数の算出要領

指数の算出要領は、初期値を 1 として、基礎の要素のランクに応じた係数をすべて掛け合わせ

て求める。こうして、すべてを順に掛け合わせていくと、この事例では結果の指数は低 1、高で 840

にまでなる仕組みになっている。評価の基準として、100 以上であれば大トラブル、50 以上が中

トラブル、20 以上は小トラブルとして扱い、20 未満は軽微と呼ぶことするものの、20 未満も含

めて、トラブルはすべて管理の対象とする。この指数は、2000 年 4 月に導入して、システム部門の経営品質を測る尺度として確立してい

った。一度社内に浸透すると、重要度に応じてトラブルを報告する基準などにも自然な形で組み

込まれていくようになっていく。この考え方の根底にあるのも、リスクベースアプローチで、改

善策の優先度を明確にしてゆこうというものである。軽微というのは、例えばデータを送信したらノイズが入ったためか相手方がうまく受信できな

かったが、もう一度送信したらうまくいったという類の話で、実際の影響はなかったものの、ト

ラブル予備軍としての分析をしておくことで、運用の管理対象として改善を図り、将来の大トラ

ブルの芽を摘んでいくことが可能になる。米国の保険会社のハインリッヒ氏が、労災事故を分析して導き出した「1：29：300 の法則」

をご存知だろうか。 1 件の重大な事故は氷山の一角で、水面下に 29 の小さな災害、さらに 300 の作業者がヒヤリ

とした潜在事故が潜んでいるというものである。システムの場合の軽微にあらゆるものをすべて含めると、300 の値は実はもっと大きな値にな

っているが、軽微なトラブルの対策を立てることが、将来の大トラブルを未然に防止することに

繋がっていく。システムリスクの定義に、損害を与える怖れのあるものを対象として含むようにして、こうし

た予防的なマネジメントを目指していくことが、重要である。近は、内部統制の対象が広がって、単一なシステムではなく、グループ会社にも横串を通し

て同一の基準で足並みを揃えた管理が求められたり、買収・合併などで、システムが一本化され

たりするケースも増えている。両社にまたがるトラブルをどうやって同じ尺度で管理していくのか、経営に報告すべきトラブ

ルや所管官庁に報告すべきトラブルの基準はどうするのか等々、の具体的な課題が出てくるが、

こうした指標はトラブル管理のデータベースを一本化しておけばすぐに適用可能となる。或る意

味では、両社の品質の管理レベルを揃える特効薬となる。副産物として、報告基準も客観的な尺度で明確になり、経営のリスク管理に対する目線も合う

ようになって、自然な形で管理スキームを明確にすることができることになる。たかが指標ではなく、組織がその値によって無駄なく確実に動ける優れものと評価している。導入に際し、経験から得た注意事項を以下に記す。


477

・要素のハロー効果が見えてくる。独立した要素と思っていても、3 年経過して分析してみる

と、連動する要素があることがわかる。リスク認知の歪みと同じで、重大なトラブルに関連

する要素は、何もかも重たく位置づける傾向があると、掛け算では何倍もの値になる。重く

なっても当然と言う考え方もあるが、数量的な指標としては、是正が必要と判断して、近

全面改訂した。・第一報の報告のときに、迷惑度指数を算出できるようなスピーディなものが求められていく。

トラブル影響度を出すまでに、データベース内の影響を与えたデータ抽出を繰り返さなけれ

ばわからないというのでは、今日的な経営の指標としては不十分である。精緻で完璧なもの

であることは求めず、一つの尺度であることを第一義として、同時に全面改訂した。・システムトラブルでも、個人情報の漏洩のような案件では、件数の多少に関わらず、大きな

事案になる。迷惑度による算出はするものの、別管理にしたほうが良い。・システムは環境が変わると、算出の要素も変わっていく。このスピードが速い。インターネ

ットを利用したシステムにホストコンピュータの指標はそぐわない。・迷惑度が、カテゴリー別に、どのプロジェクトに多いのか、結果を基にランク付けによる対

策の優先度を考えたりして、フィードバックを検討することが課題になっていく。既に顕在

化している予兆などの事実から「リスクが顕在化する可能性」「どの程度の損失を招くか」等

を分析して、早期警戒するようなリスクマネジメントまで実現できれば、素晴らしい。また、付け加えると、リスク管理の経営に対する報告という観点では、単に数量的な把握だけ

でなく、お客様迷惑度指数のワーストとして定めた件数の具体的な事例を一覧にして、定期的に

報告をしておくと、改めて会社の置かれたリスクの状況が認知されるきっかけになる。取締役会などでも、具体的な事例で、その迷惑度を実感して戴くことで、迷惑度を身近に感じ

ると共に、システム部門としても、大きな教訓としてそれぞれの事例を振り返って見る機会にす

ることができる。３．IT 法務

IT 法務については、リスク管理・内部統制の範疇で述べるのが適切なのかという疑問はある。

しかし、いまだ独立したジャンルには育っていないので、リスク管理に入れている。経済産業省が、信頼性のプロジェクトを起こして検討を始めているが、IT 法務担当が重要な役

割を果たすと考える。JUAS では、2004 年度のテーマに、契約締結の課題と解決策を論議するた

めに、IT 法務をテーマに取り上げた。


478

（１）IT 法務の機能が求められる背景

この機能が必要とされる背景として、2 つの理由が考えられる。 1 つ目は、新しいビジネスプロセスを実現するために、いくつもの新技術を用いたシステム開

発の形態が浸透していることで、開発に当たって抱えるリスクが多様化し増大していることであ

る。 2 つ目には、システム運用の面でも、アウトソースの進展によって、大きなトラブルから日々

の細々としたミスに至るまで、様々なトラブルが発生するなど、新しいリスクがどんどん現れて

来ているということである。

（２）IT 法務の必要性

システム開発は、目的物が不可視なため、機能・要件等定義が曖昧になり、開発後に「このよ

うなものは頼んでいない」などのトラブルが起きやすい。また、開発に関与する当事者も、例えば、発注者（アプリケーションオーナー）、システム開発

を担当する IT 企画部とそのグループ会社、そして実際のシステムのユーザーなど、多く存在す

るため、役割分担もあいまいになりがちである。加えて、システム開発にも新しい形態が登場してきていることで、従来の請負のみで整理でき

るものばかりではなくなってきている。こうしたことから、IT 法務の必要性がクローズアップされてきた。

（３）IT 法務の役割

IT 法務の役割について述べると、プロジェクトに内在するリスクを把握し、法務面から支援す

ることにある。そのため、次の 2 つのことを出発点としている。

ａ．予防的なリスクマネジメント

法務というと、紛争解決機能を求める事後的な機能が重視されるが、事前の機能として発動し

ようというのが、予防的なリスクマネジメントであり、今後ますます重要になっていくと考えて

いる。予防的な機能としては、開発委託内容の定義や役割分担などの契約内容を明らかにするこ

とが大切だと考える。特に、危険負担などの事項は後で紛争が発生した場合での解決策を担保す

る意味でも重要である。このように抽象的な内容を、具体的にしていくことが、IT 法務の役割として求められることと

なる。


479

ｂ．関係者をリードして早期解決を図る a の手当てを十分に尽くしても、紛争事案が発生することはありえる。このようなときに、弁

護士、SE などの関係者をリードして早期に解決できるようにすることである。システム開発に限らず、紛争事案を早期に解決することが、損害額を抑えると同時にその他の

ビジネスリスクの発生回避につながる。特に、近では、システムに関する紛争がレピュテーシ

ョンリスク（風評リスク）を発現することは良く知られている。こうして、IT 法務の普段のミッションとして、契約手続きの事務処理フローの流れにおける審

査業務に加えて、それ以上に積極的に、大規模プロジェクトで、委託先の候補者選定から参画し

て前広に内在しそうなリスクをあぶり出し、契約の中に盛り込んでいくことが求められている。

（４）IT 法務担当のミッション・資質

システム部門の第一線の SE にとっては、IT 法務という極めて文科系的な分野は不得手な現状

にあり、このレベルを上げていくための牽引役になってもらうことが大切である。 IT 法務に求められる資質について、研究会でも質問が出される。法務の専門家の方が IT を勉強していくのが良いのか、IT の専門家が法律を勉強するのが良い

のかということである。当然のことながら、個人差があって、この回答は候補の人の素質次第である。ただ、IT と法の専門領域の知識が求められている訳で、いずれから出発しても、本人が興味を

持ってチャレンジすることしかない。広くリスク管理の担当について言えることだが、大切な資質は、長期的な展望に立ち、社会的

な見識および人の機微を捉えて公平な判断ができることである。その公平さが個人的な信頼、引いては、社内および会社間の信頼関係の構築に繋がっていく。法務と言うのは、双方が同じ専門の世界にいるので、自分にとって有利にしようと動けば、相

手も身構える。こうした平行線が続いた結果、鎧に固まった契約になってしまう。戦略的なパー

トナーとして歩もうとする相手には、胸襟を開いて無駄な鎧も脱ぎ捨てていく。信頼されること

が一番大切で、組織に属するというよりも、専門家としての見識を重んじて行動できるかどうか、

譬えれば行事役を務められるようになれば、本物である。こうした IT 法務の関与によって、プロジェクトの立ち上がりの受発注者双方での条件の食い

違いが減っていくことは実証済みである。近のプロジェクトの失敗の多くは、稟議起票時に想定される規模・コストの上振れ幅の分析

が不十分であったり、要件定義局面でも要件が確定しないままで動き出すところに起因する。このような状態では、予想外の開発規模の増大によって、発注者としては予算の増大、受注者

としては無理な単価のカットに結びついたり、性能要件の認識の差で本番稼動が延期されたりと

いうことも起きる。受注者は、自社の標準の契約書を前提に提案書を作るが、多様なサービスや、納品時の厳しい

性能要件などは、いくつもの仮定の上で検討される。プロジェクトを成功させる妙案はないが、RFP の時点でこうした契約条件も含んだ契約書を提

示して一緒に確定させると、双方に大きな勘違いが潰せるうえ、入札者にも公平な条件での回答

を求めることができる。


480

４．アプリケーションオーナー制度（発注者の果たすべき役割）

或る会社では、システム開発の発注者を「アプリケーションオーナー」（システムオーナー）、

システム部門は「サプライヤー」（またはシステム部門そのもの）と呼んでいる。新たなネーミングでイメージの刷新を図ったのには理由がある。トラブル削減の問題を一歩掘り下げて追求していくと、一番上流工程の要件定義に、その根本

原因が多いことに気がついた。したがって、良いシステム作りには、要件定義を行う発注者の役割を明確にし、その役割を責

任を持って果たしてもらうことが必要だと考えたわけである。アプリケーションオーナーの仕事や責任は工程毎にある。具体的には、経営に計画着手を諮る

ときから、要件確定、そしてテストケース作り、そのテストの実施であり、さらには、システム

開発工程終了の確認、開発終了後の効果検証までが、一連のサイクルで果たすべき役割である。大雑把ではあるが、次の図表 5-3-5 が両者の関係を説明しやすいため、紹介する。

利用促進

システムの稼働・供給

利用促進マニュアル教育

効果測定と

効果検証

コストの測定

こういうものを

作って欲しい

アプリオーナー

サプライヤー

こういう風に作ろう

システムの作成

効果検証

要求通りにできているか

テスト

欲しかったものに

なっているかオーナテスト

開発

図表 5-3-5 オーナーとシステム部門の役割分担


481

プロジェクトは、左から右に流れていく。まず、開発の初の局面では、アプリケーションオーナーは「こういうものを作ってほしい」

という要件をまとめる。システム部門では、その要件を受けて、「こういう風に作ろう」というこ

とで本格的な開発を始め、作成した結果をテストする局面に移っていく。システム部門でも、当然責任をもってテストをするが、それは「要求どおりにできているか」

という観点からであって、終的に「欲しかったものになっているか」というテストは、アプリ

ケーションオーナーが自らテスト計画を立て、テストデータも作り、結果の検証も行うことがや

はり必要になる。そのワークロードは、テストがより本番に近く進むに連れて、アプリケーションオーナーの負

担の方がより重くなっていく。良いシステムを作るための秘訣は、このアプリオーナーの参画を

高めることと、計画当初から何時の時点でどれだけのオーナー側のロードがかかるかを算定して

要員計画に織り込めるかにかかっている。システム部員の要員確保にはすぐ眼がいくが、アプリケーションオーナーの要員確保が十分に

はできずに走り出して、テストのワークロードに耐えられなくなって、不十分なまま本番稼動時

期を迎えることになったという事態を、少なからず目の当たりにしていると思う。そして、積み残しのテストケースは本番稼動後に一部実施することとなるが、決して良い結果

にはつながらず、却って稼動後の運用局面で長く拘束されることになる。アプリケーションオーナー制度では、本番稼動時のサービスインレビューにおいて、アプリケ

ーションオーナーも承認の押印をする。残タスクを抱えての稼動は、リスクもあるわけで、後々

問題が発生した場合には責任が問われる。こうして、システムトラブルを分析していく中でわかったことは、強化すべき開発工程のミッ

ションの多くは、アプリケーションオーナーが全面的に参画して理解を深めながら果たすべきも

のであったということである。また、オーナーの役割で一番大きいものは、システム開発予算の管理をするということである。

システム開発予算をシステム部門で一括して持っていた時代とは違って、オーナー自ら経理部や

関係各部と交渉してシステム開発予算を手当し、かつ開発途上でもその予算管理責任もオーナー

が持つことで、システム開発要件が膨らんで予算が足りなくなった場合には、オーナーはその不

足分は自分でやりくりすることになる。元々、システム部門が自からの責任で解決できるものは勿論するものの、アプリケーションオ

ーナーの役割を明確にしてその役割を厳格に果たすようになることで、大きな成果を生んだと評

価している。さらに、先ほど説明した IT 法務も、アプリケーションオーナー制度において、中立的な立場

で両者の役割を明確にしつつ、行事役として大いに貢献が期待される。こうした制度によって、「オーナーの甘え（IT への他力本願）の体質からの脱却」、「リスクと

ビジネス機会をフラットに判断」、「関係者間（オーナーやベンダーも含めて）での信頼の絆を取

り戻す」と言った、本章第２節「２．歴史編」で取り上げた内部統制の不備を補っていくことが

できる。


482

５．システム開発に係るリスク管理

システム開発のプロジェクト管理は、様々な分類があるが、例えば、大きく 6 つの機能に分け

られる。こうした管理は、各企業で進められている施策とほぼ同様であろう。

「基本ルールが本当に明確か」

「ルールを愚直に守っているか」

「現在の基本ルールが適正か」

「基本ルールが本当に明確か」

「ルールを愚直に守っているか」

「現在の基本ルールが適正か」

デジタルな進捗管デジタルな進捗管

障害管障害管

品質管品質管

スケジュール管スケジュール管

要員管要員管

要件変更管要件変更管

図表 5-3-6 プロジェクト管理

プロジェクト管理は本章の主題ではないので、リスク管理に関係した面から取り上げる。

（１）基本を忠実に守る

プロジェクト管理のポイントは、基本を忠実に守るという 1 点に尽きる。「基本ルールが本当に明確か」「ルールを愚直に守っているか」「現在の基本ルールが適正か」

を、繰り返しチェックしていくことになると考える。対策が予想した効果を上げないと、次の対策へと眼がいくが、実は対策自体が駄目なのではな

く、現場も含めて、やるべきことをやっていないので実効が上がらないケースが多い。また、たくさんの対策を並べることが良いことではない。開発現場の人達の日々の活動で守れ

る注意事項は、机の上に広げられた 1 枚のチェックシートに収まる量に限られると言うことであ

る。


483

（２）数量的なプロジェクト管理

数量的な管理の例として、お客様迷惑度指数の事例を挙げたが、言い換えれば「科学的なシス

テムリスク管理」であり、近流行の「見える化」、「可視化」ということでもある。プロジェクトにおける数量的な管理については、プロジェクトの「規模」、「開発期間」、「新技

術の採用の有無」、「担当メンバーのスキルレベル」、「要員の確保状況」等などの要素をリスク評

価してランク付けを行い、その総合点の指標をベースに、プロジェクトの進行中は、リスクを軽

減させるような管理を行うことである。具体的には、指標が或る一定水準を超えたら、発注者（オーナー）の課長レベルの承認ではな

く部長レベルの承認を要するとしたり、逆に、リスクが低ければ書面で済ませたりする、メリハ

リのついた管理をして行くことが、現実的である。こうして、無駄なレビューを止めることで、

真にリスクの高いプロジェクトに注力できる余力を生むことが可能となる。

（３）レビュー制度

一定規模以上のプロジェクトでは、各局面での終了時点等のマイルストーン毎に、定められた

権限者（経営レベル、部門長などのレベルがある）が、進捗していく過程で見直した計画の承認

をするプロセスをビルトインしておくことが重要である。レビュー制度については、『実務で役立つプロジェクトレビュー』（菊島靖弘著、株式会社翔泳

社刊）という著書が出版されている。レビュー制度全般を対象に、詳細に記載されているので、

同書をご覧戴くこととして、割愛した。32

①開発過程でカットオーバーまでに５回のレビューを義務付け②アプリオーナーと共同で主催、各管理レベルでの承認取り付け③品質管理部門によるチェック

①開発過程でカットオーバーまでに５回のレビューを義務付け②アプリオーナーと共同で主催、各管理レベルでの承認取り付け③品質管理部門によるチェック

プロジェクト計画レビュー

プロジェクト計画レビュー

要件確定レビュー

要件確定レビュー

テスト計画レビュー

テスト計画レビュー

運用受け入れレビュー

運用受け入れレビュー

サービスイン承認レビュー

サービスイン承認レビュー

サービスイン

サービスイン

開発着手

開発着手

図表 5-3-7 レビュー制度

32 【文献 5】「実務で役立つプロジェクトレビュー : システム開発プロセスを「見える化」する」


484

６．システム運用に関わるリスク管理

（１）リスク管理の考え方

この項は、東京海上日動システムズ社の島田洋之氏の社内資料をベースに、著者が再編成して

いる。ａ．システム運用のポイント

システム運用業務において、システムリスク管理態勢の確立を目指すためには、以下の諸点を

念頭に置き、日々の業務遂行状況をモニタリングしていくことが重要である。・経営に影響を及ぼすシステム障害を起こさないことを優先にする・担当するメンバー全員の小さな業務の積み重ねが大切であるという認識を徹底する・対外的にも各業務の確実性に関する説明責任を果たせる工夫をする

ｂ．モニタリングの条件こうした課題を達成するためのモニタリングに要求される条件とは、以下のとおりである。・日々の業務を常に同じ視点からモニタリングする（モニタリングの原点）・「トラブルを起こさないこと」に加え「何事も起こしていないことの証明」も考慮する（個人

情報保護法や米国企業改革法で求められるようになってきている傾向）・システム部門の自己満足にならないように、経営からの観点を盛り込む

ｃ．モニタリングのアプローチ方法アプローチする時の考え方のベースは 2 つある。

①リスクベース管理偏重にならず、効率的で実効性の高いモニタリングをリスクベースで、実現する。具体的には、システム運用時に想定される 4 つのリスク、すなわち、「システムの不備」、「シ

ステムダウンまたは誤作動」、「情報の改竄・削除・漏洩」、「コンピュータの不正使用」について、

「サービス品質」、「継続性」、「セキュリティ」の 3 つの重点確認ポイントを優先で、モニタリ

ングする。こうした定常的なモニタリング（COSOで定義されたON GOING MONITORING）に加えて、

定期的なモニタリングとして、毎月の発生状況および与えた影響の度合いを、「リスクベースレポ

ート」としてとりまとめ、システム運用のグループ会社から本社の主管部門に報告している。主

管部門では、必要に応じて、担当役員および内部監査部門などの関連する部署にも報告を行う。併せて、システム運用のグループ会社は、日常の様々な業務を委託している企業とも相互に評

価を行うことで、実態に関する情報共有および改善すべき事項を把握する。


485

②パフォーマンスベースシステム運用の業務全般に関して、その活動が網羅的にモニタリングされている保証があるか、

および、実現のための各業務プロセスが確立されて効率的かつ確実に行われているかを確認する。同じく、この観点からも、毎月「パフォーマンスポート」をとりまとめ、各種指標の妥当性・

正確性について、関連する組織および委託先なども含めて、検証し相互に評価を行う。ｄ．IT 対応の検討をスタートさせる出発点はシステム運用から

①「システム開発は短期、システム運用は一生」という言葉があるとおり、システムを導入す

るときに、定着したときの運用にどこまで配慮していたかが大きな決め手で、後の運用の安

定化、金食い虫のように言われる運用コストの圧縮を左右する。経営資源の投入の無駄はこうしたシステムサイクルの全体像を見失ったときに発生する。リスク管理の対応でも、プロジェクト開発はその仕組みを改善していくことが比較的容易

である。しかし、リスク管理において重要で手間がかかるのはエビデンスの確保であるが、

それはシステム運用における継続性を確保しなければできない。

②大規模な理想的な仕組みを構築しても、あとでメンテナンスに入った途端に、量や複雑さで

日々の業務が回らないということがないようにしないと、大変なことになる。「身の丈にあっ

た仕組み」とは、初の構想が、局面が段々進むと尻すぼみになって、結局負担感だけ、し

かもなぜ行っているかの意味も失われたままやり続ける不毛の作業になっていかないように

するために重要である。

③継続性の保証は難しい課題である。新のハードウェアやソフトウェアの売込みが盛んだが、すぐに陳腐化していく。このため、例えば、ログの管理はシステム運用で大きな課題となる。オペレーションの記録を吐き出すだけという簡単な要件のようでいて、何に使うのか、必

須項目と任意項目は何かなどが不明瞭な中での構築は、とても難しいものになる。どのよう

なリクエストにも応えられるログとは、金食い虫の典型である。そして、定められた期間は、そのデータを提出可能な状態に維持するとなると、ハードウ

ェアやソフトウェアのバージョンアップの互換性や、異なったメーカーでも必須情報は同じ

レベルで確保しなければならなくなる。また、会社の合併やシステムの統合でも、ログ情報のデータを保証するなど、ビジネスの

あらゆるシーンをカバーすることは不可能に近い。加えて、自社の中でログ情報を蓄積して後の分析に利用できても、改ざんされていないと

言う無罪証明は、コンピュータや PC の日付を始めとして難しく、第三者に委託したりする

などの対策も挙がっている。仕組みを構築するときに、できること、できないことを明示しておかないと、経営に対し

て「できないことを明示しなかった」ことで、結局は嘘をつくことになる。


486

④開発の人達は、要求された眼に見えるアプリケーションの機能要件に集中して、リスク管理、

セキュリティのような非機能要件には、開発過程では余り関心がないケースが多い。しかし、

インフラ部分の要所にこうした非機能要件が確実に組み込まれていないと、後ほど大改造が

必要になったりするが、インフラの改造は簡単にはいかなくなって、後年度負担を増やすこ

とになる。こうした非機能要件を固められるのは、システム運用部隊だが、開発部隊に多く

の人を回すと運用部隊には少数の人達しか残らなくなるのが実態である。 ⑤システムへの投資コストが問題になり、その中でも経営にとっては何も新しいものを生み出

さないシステム運用コストの根雪の部分を如何に少なくするかの論議になる。しかし、大限努力しても必要な金額は必要であり、毎年確保しておくことが、健全に機

能するために必要なことである。これは、例えれば、新築マンションを購入しても、例えば 15 年目に改修し、25 年目には

大改修を、35 年目には建て替えをする計画が初から想定されているのと、同じことである。そういう意味で、異常に保守・運用コストが低いというのは、却って将来の集積リスクに

なりやすいとも言える。

（２）システム運用に関わるリスク管理の具体的なポイント

以上のような考え方で、システム運用に関するリスク管理態勢を確立・強化してきたが、具体

的に用いた手法およびそのチェックのポイントを挙げる。ａ．COSO を参考にした運用ガバナンスの明確化

内部統制の標準的なフレームワークである COSO フレームワークをベースにしている。そして、具体的に用いているのは、COBIT の「調達と導入」、「サービス提供とサポート」、「モ

ニタリング」の 3 部分である。このフレームワークを常に意識しながら業務を行なうことで、内部統制機能の一層の強化を図

ると共に、社内外の監検査に対しても、その根拠となる考え方を明確に説明できるように努めて

いる。ｂ．ITIL を参考にした運用プロセスの明確化と正当性の確保

COSO を参考にしてシステム運用のガバナンスを明確化することに加えて、ITIL のプロセス

も参考にして、対応の正当性確保に努めている。具体的には、自社のシステム運用のプロセスを明確に規定する作業を行い、その結果の各プロ

セスの実施状況と正当性について、ITIL を参考にしたチェックポイントによって確認し、かつ確

認に用いたエビデンスを明確にしている。チェックポイント項目については、付録 17「ITIL を参考にしたチェックポイント」を参照。

ｃ．月例レポート

何をモニタリングするかということに関して、月例レポートに盛り込む目次を付録 18「月例レ

ポートの目次」で紹介する。


487

７．自主点検（システムリスク管理態勢の確立）

リスク管理・内部統制は、世界各国で実際に生じた不祥事を契機に生まれたものだけに、累積

的に厳しい規制が積み重なってきている。誰も「今のままで何が悪い」という反論は難しいし、実際に、規模の差こそあれ、今でも似た

ような事例が新聞に載ることがあって、なお更、段々マイナスの世界に落ち込んでいく。したがって、都度、個別対応のための規制強化の指示が出されると、現場では、自然と「やら

されている」という印象を持つようになる。 COSO の説く「全員参加」という QC 活動的な要素が消え、ERM で説いているようなビジネ

スチャンスを活かしていく攻めの IT ガバナンスも、こうなると夢物語である。ここでは、原点

に返って、一歩掘り下げた話をする。

（１）リスク管理の原点は、「自主点検」にある

監査人から、リスク対策が不十分なところ、潜在リスクが見えていないところ、考慮が足りな

いところ、他社で発生した参考になるケースに照らして不十分なところ等の指摘を受け、諸外国

での新の論文などを踏まえた知見を教えていただくことは、重要であるし、アドバイスは実際

貴重であると思っている。しかし、それだけに頼ったリスク管理は、本来の姿ではない。業務知識を一番持っているのは現場であり、大半の問題は自分で認識している。ただ、報告しづらい風土があるか、自分でリスクの大小の判断がつかずに報告しないでいる。

リスク管理担当は、会社内にいるわけで、社外から該当の短期間だけ接する監査人に比べたら、

事情を踏まえた一歩踏み込んだ観察が可能である。まずは、定期的に自分達でリスク管理のサイクルを回していくことが大前提にあり、そのサイ

クルを回して発見した課題を自己評価し、経営へ提出した社内報告書を、監査人にも提出して、

より本質的で有意義なディスカッションをしていくことが求められている。このように、改善のための PDCA を自力で回していけるようにしていくことが、本来の「自己

責任」の解釈であると考える。さらに、こうした結果を内部監査部門と言う社内でのプロ集団からも監査してもらうことで、

当該部門のみのリスク分析・評価に限定されがちになるのを回避し、他部門への新たなリスクが

発生していないかを検証することで、経営として判断できる重要な情報の質を高めていく相乗効

果が期待できる。

./keyword.htm#1601


488

（２）自主点検は、総合的なものと個別テーマによるものを使い分ける

自主点検は毎年実施しなければならない。しかし、個別にテーマを選んで深堀することも併せ

て実施することが望ましい。

ａ．毎年実施する総合的な点検各種法対応や過去の指摘事項も含め、新たに想定されるリスクを追加して、網羅的に実施する。

方法は、各社で工夫すればよいが、詳細な記述文書を大量に作成することは必ずしも必要なく、

例えば、5 段階評価で不備事項は詳細の記述と対策を記載する、などのレベルでも良い。この自主点検のチェックリストは、様々な法対応を網羅した表で、これだけ作成すれば基本的

には、重複して調査をしなくて済むように工夫することが必要である。

ｂ．個別テーマ組織の中で抱えている問題や新たなテーマを選んで、集中的に実施する。期間は 1 ヶ月程度で、

テーマの選定は、担当役員や部門長からの指示となる。この個別テーマを利用すると、部門で困っている課題解決の全体像と検討案のヒントを提示す

ることができて、部門の関係者の悩みを解決することに繋がる。現場に喜ばれるリスク管理とな

る。ただ、現実的には、近年は個人情報保護、米国企業改革法対応等のビッグテーマが続いたので、

個別テーマをさらに実施する時間を確保することは難しく、著者も近は実施できなかった。自

主点検マニュアルの記載事項については、付録 19「自主点検マニュアルの記載事項」を参照。

（３）自主点検は、自社の現状を見ることから始まる

JUAS で自主点検を話題にしたときに、意義は理解できたが、具体的にどのような手順で実施

すれば良いのかという質問があった。問題解決の「打ち出の小槌」のように受け止められたようで、特殊な手続きやチェックシート

があるだろうから、そのノウハウを教えてほしいというものである。次のようにお答えした。

ａ．直面する課題に即して考えるシステムリスク管理の中で、IT 部門にとって一番重たい課題は何かと言えば、トラブルを起こ

さないことである。トラブル削減（撲滅）に各企業の経営・現場とも苦労しているだろうが、そのときの手順や体

制をどのように組んでいるかを振り返ってほしい。標準的な例を取れば、「何処までトラブルの影響が及ぶかの判断は誰が何に基づいてするのか」、

「影響を与える関係者への連絡の責任者は誰でどのようにして行うか」、「修復は何時から着手で

きるか」、「誰が修復の責任者になるか」、「何時までに修復を完了させるか」、「暫定対応として何

をするか」、「何時まで暫定対応で持ちこたえられるか」、「根本解決として究明すべき事項はない

か」、「対応を終えたことを判断する責任者は誰か」、「判断をするときのエビデンスは何か」等な

ど、頭に浮かんでくる。


489

リスク管理・内部統制のチェックシートを考えるときの項目も、一般論で考えるのではなく、

各企業がトラブル対策で工夫してきたことを参考にすれば自社に慣れ親しんだものになっていく。

ｂ．課題の対象を広げていくトラブルで血を噴出している場合は、早急に止血をするしかない。しかし、応急措置を終えた

ら、速やかに再発防止策の検討に着手し、対策を立案していくことが求められる。再発防止策は、人間系の対策「ミスをしないように注意する」などにとどめず、仕組みで対応

していく必要があり、そのためには、各担当が個別に考えるというよりも、IT 部門全体で取り組

む課題の一覧にノミネートして管理の対象にする。これが、「IT 部門として取り組むべきリスク管理・内部統制の課題一覧」＝「自主点検の対象

として分析し根本対策を求めていく材料」になる。もし、課題がこれだけであれば、「お客様迷惑度指数」などで、課題の優先度をランキングし、

与えられた要員・期間・コストの中で解決に取り組んでいくこととなる。資源が不足しているの

であれば、経営に増強を伺うことになる。ただ、トラブルのカテゴリーでのリスク管理の課題はこれだけではない。新聞などで取り上げられたシステムトラブル、または不祥事案でシステムが対応すべき事項に

ついては、同様の事象が自社で発生しないかを検証して、防止策が必要であれば、リスク管理・

内部統制の対象一覧に追加していく。なお、トラブルを例にして話を進めたが、リスクの洗い出しから着手してリスク分析を行って

優先的に取り組むリスクを定めた場合には、そのリスクが出発点となる。

ｃ．IT 部門が発案する取り組み課題を盛り込むさらに、コンピュータセンターや営業部店における安全対策が行われているかの自主点検も挙

げられる。これも、事情のわからない企業内の他の部署からリクエストされるものではなく、自

ら点検していく必要がある。この点検の項目については、金融情報システムセンター（FISC）の「安全対策基準」が準拠す

べきスタンダードとして活用できる。ただし、バインダー1 冊の厚みから容易に察せられるように、チェック項目は多岐にわたり、

各社のシステムの構成などで取捨選択しなければいけないなど、取り入れて自社版の点検リスト

にするには、時間とロードがかかる。まずは、優先度をつけて必要な部分から充実させていくことである。一度作れば、翌年からは、

システムの追加・変更および対策基準の見直しに応じた部分はかなり点検を簡素化できるように

なる。ここまで来ると、IT 部門が発案して取り組む自主点検は一段落である。


490

ｄ．全社的な見地からの取り組み課題を盛り込む次に、IT 部門にとってグローバルスタンダードと言われる ISO、COBIT などの資料から、自

社の実態に照らして当てはまるチェック項目を盛り込んでいく。この局面になると、抽象的な表現が多くなってくるので、具体的なポイントに落とし込んでい

くことが必要である。玉虫色にして、何となくできているような気分になっても、IT 部門の改善

には繋がらない。内部監査部門などのアドバイスももらいながら、的確なポイントにしていくと、

点検の実効性が上がっていく。さらに、個人情報保護法や企業改革法などの法令・各種省庁のガイドラインによって会社全体

で取り組むことが求められる点検項目を、分析し、整理して組み込んでいく。基本的には、FISC の安全対策基準やスタンダード自体が、こうした法令に IT 部門として対応

すべき事項を都度盛り込んでくれるので、追加で大きな対応するものは多くはないと推察する。

ｅ．内部監査による見直し内部監査が実施されると、指摘された事項によって、取り組むべき課題の追加および優先度の

見直しが必要になるので、年の途中であっても見直す必要がある。以上で、自社内で点検する事項が揃ったことになる。後は、外部監査の指摘を受けながら、毎年レベルアップを図っていくことになる。この改善のサイクルが定着することで、システム開発計画（攻めの IT ガバナンス）と同じよ

うに、守りのガバナンスとしての「リスク管理・内部統制の全体像」を経営が論議するようにな

っていくことが望まれる。

自主点検も一度実施した後、同じ体制で続けていくと、マンネリになってしまいがちである。

問題を吸い上げて都度解決し、必要なものにはより大きな観点から対策を打っていく仕組みを現

場に定着させること、および社会から求められる管理の強化や法令やガイドラインによる新たな

観点によって常に原点に立ち返って企業全体の管理レベルを見直していくことで、自主点検も充

実していく。そして、自主点検の結果が様々な局面で求められる説明資料のベースになることで、部門の取

り組みを企業内で共有し、対策の実効性を上げるなど、会社の管理レベルが進化する原動力にな

ってほしいと願っている。

491

第５章リスク管理・内部統制第４節内部統制（実践編）

─内部統制の全体像と流れを理解する─

リスク管理と内部統制は、企業活動をどの方向から見るかの違いであって、企業の活動として

分離されたものではないが、内部統制として求められる法・指針・ガイドラインなどの整理と、

財務諸表の内部統制に関する全体の流れを概観することとする。

この節では、内部統制に関して、以下のトピックスを紹介する。

１．内部統制での遵守事項・留意すべき事項の全体像

２．推進組織の考え方・コラボレーション

３．日本公認会計士協会の資料による財務諸表監査の流れ

５－４内部統制（実践編）

492

１．内部統制での遵守事項・留意すべき事項の全体像

COSO フレームワークの 3 つの柱の一つである「法令遵守」について、企業の IT 部門として、

一体何を遵守すれば良いのか、全体がわからないという声を聞く。 IT 部門として、法令対応が重要になってきた背景として、以下のようなものが挙げられる。

・事業活動に IT が活用されていることで、各法令や指針・ガイドラインの一部に、技術的な

管理措置等として、盛り込まれるケースが増えている・情報漏洩対策など、IT 部門自体の運営強化が求められるような事案が増えている業種別に様々な法令や指針・ガイドラインがあるので全貌は把握しようがないが、IT 部門が内

部統制を検討するときに考慮・参考にする日本の主な法令・指針・ガイドラインを一覧にしたも

のが、次の図表 5-4-1 である。本章で今まで触れていなかった事項（表の①～⑥）について、解説を加える。ただし、IT 部門の実務で密接なものは、基本的には既に取り上げており、ここでは概要の解説

に留めている。


493

図表 5-4-1 主な日本の法令・指針・ガイドライン

区分具体的な指針・マニュアル・報告など参照先

会社法新会社法（2006 年 5 月）既述

リスク新時代の内部統制リスクマネジメントと一体となって

機能する内部設計の指針

（2003 年 6 月）

文献 A133

経済産業省の指針コーポレートガバナンス及びリスク管理・内部統制に関する

開示・評価の枠組みについて―構築及び開示のための指針

― （2005 年 8 月）

文献 A234

特定業界の先行事例金融庁検査マニュアル文献 A3 35 ・

A436

本章の直接の対象ではないが関

係する法

労働基準法、独占禁止法、個人情報保護法、下請代金支払

遅延等防止法、ｅ―文書法、廃棄物処理法など省略

日本監査役協会「改定監査役監査基準」

（2004 年 2 月）この項の（１）

会社業務全般

社内の他の組織での基準で参考

になるもの内部統制システムに関する監査役の当面の実務対応

（2006 年 3 月）文献 A637

金融商品取引法金融商品取引法（2006 年 6 月）既述

企業内容等の開示に関する内閣

府令

企業内容等の開示に関する内閣府令

（直近は 2006 年 4 月内閣府令第五二号）この項の（２）

ディスクロージャー制度の信頼性の確保に向けた対応につ

いて（2004 年 12 月）」文献 A1038

金融庁（ディスクロージャー制度

の信頼性の確保など）有価証券報告書の作成・提出に際しての留意事項について

等（直近は 2006 年 6 月）この項の（３）

東京証券取引所（株式市場から

の要請）

適時開示体制の整備の手引きと宣誓書記載上の留意点

等（2005 年 7 月）この項の（４）

財務・会計・市場調達関連

会計監査基準日本公認会計士協会の各種報告書省略

参考になる監査人の手続き

財務諸表監査における情報技術（IT）を利用した情報システ

ムに関する重要な虚偽表示リスクの評価及び評価したリス

クに対応する監査人の手続について（2006 年 3 月）

後述（この節

の第３項）

参考になるシステム監査の基準経済産業省「システム監査基準/システム管理基準」

（2004 年 10 月）この項の（５）

ITに焦点を当てた手続き

・基準など

特定業界の先行事例 FISC「安全対策基準」（2006 年 3 月）この項の（６）

33 【文献 A1】「リスク新時代の内部統制リスクマネジメントと一体となって機能する内部設計の指針」 34 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」 35 【文献 A3】「新しい保険検査マニュアルと総合的な管理指針」 36 【文献 A4】「金融検査指摘事例集」 37 【文献 A6】「会社法及び法務省令に対する監査役の実務対応」 38 【文献 A10】「ディスクロージャー制度の信頼性の確保に向けた対応について」


494

（１）日本監査役協会「改定監査役監査基準」

（http://www.kansa.or.jp/siryou/elibrary/el_001_040219.html）具体的・体系的実務指針として、内外から評価される監査実務のあり方、責任のとれる監査の

あり方を明示することを目指している。さらに、監査役は、独立の立場から取締役の職務執行を

監査することにより、企業不祥事を防止し、健全で持続的な成長を確保・担保することが基本責

務であると認識し、良質な企業統治体制の確立と運用を監査役の基本的な監査視点とすることを

明示している。前文で述べられている改定の主要な視点は、以下のとおり。・取締役会その他における意思決定に関しては、取締役の善管注意義務履行の判断基準として

いわゆる経営判断の原則が判例で定着しつつあることに鑑み、十分な情報と適切な意思決定

過程に基づいた合理的決定がなされているか否かという観点を、盛り込んだ。・取締役個々の職務執行に関しては、いわゆる内部統制システムの確立が特に大規模公開会社

の取締役の善管注意義務として認識されつつあることに鑑み、会社の規模・事業内容等に即

した適切な内部統制システムが整備されているか否かを監査役監査基準に据えることとし、

その規定化を図った。・監査役の職務遂行を補助する体制の整備や内部監査部門等との連係など、監査環境の整備を

より具体的な形で監査の基準として位置づけ、その重要性を一層明確にした。・監査役制度は独任制であるが、機関としての実効性向上のため、監査役会、議長、社外監査

役等の機能強化などについて規定した。・企業情報開示の適正性、透明性及び信頼性を確保するため、監査役は会計監査人の独立性を

監視し、取締役が財務諸表及び計算書類等を作成するために必要かつ適切な財務報告体制を

構築・運用しているかを監視・検証すること等について規定した。・平成 13 年の企業統治に関する商法等改正において、取締役の責任減免や代表訴訟における

会社の被告取締役側への訴訟参加等において監査役の同意が求められるなど、取締役会社間

の利益相反状況における一定の役割が監査役に期待されていることを踏まえ、その規定化を

図った。・監査役の監査活動及び監査報告の透明性を高め、かつ、信頼性を確保するため、監査の報告・

開示のあり方、株主に対する説明責任について規定した。

（２）企業内容等の開示に関する内閣府令

（1973 年 1 月 30 日大蔵省令第五号：2006 年 4 月 25 日内閣府令第五二号） http://law.e-gov.go.jp/cgi-bin/idxsearch.cgi 有価証券報告書・有価証券届出書の様式に適正性確認書の添付を認めるというもの。証取法 24 条 6 項（法 27 条において準用する場合を含む）、企業内容等の開示に関する内閣府

令（開示府令 10 条 1 項、17 条 1 項、18 条 2 項）は、有価証券報告書および半期報告書又は有価

証券届出書を提出する会社の代表者がその有価証券報告書等に記載された事項が適正であると確

認し、その旨を記載した「記載内容の適正性に関する確認書」を、当該有価証券報告書等に添付

できる。確認書の提出は任意で、確認書には、代表者がその役職を表示して自署し、かつ、自己の印を


495

押印の上、概ね次の事項を記載することとされている。・当該報告書の記載内容が適正であることを確認した旨・当該確認を行った記載内容の範囲が限定されている場合はその旨及びその理由・当該確認を行うに当たり、財務諸表等が適正に作成されるシステムが機能していたかを確認

した旨及びその内容・当該確認について特記すべき事項（企業内容等の開示に関する内閣府令第 17 条第 1 項）

（３）有価証券報告書の提出に関する金融庁の指導

http://www.mof-kantou.go.jp/cgi-bin/to.cgi?/disclo/index.htm 開示書類の提出について留意すべき事項等がまとめられている。以下の文書は、近のものを例示。・有価証券報告書の作成・提出に際しての留意事項について(平成 18 年 3 月期版) ・平成 17 年 3 月期有価証券報告書の重点審査結果について・半期報告書の作成・提出に際しての留意事項について

（４）東京証券取引所（証券市場からの要請）

重要な会社情報の適時適切な開示は、上場有価証券の公正な価格形成及び流通を確保する上で

不可欠で、投資者の証券市場に対する信頼の根幹を成すため、適時開示に関する宣誓書、有価証

券報告書等の適正性に関する確認書制度を設ける。

ａ．適時開示にかかる宣誓書「投資者への適時適切な会社情報の開示が健全な証券市場の根幹をなすものであることを十分

に認識するとともに、常に投資者の視点に立った迅速、正確かつ公平な会社情報の開示を適切に

行えるよう添付する適時開示体制概要書に記載した社内体制の充実に努めるなど、投資者への会

社情報の適時適切な提供について真筆な姿勢で臨むこと」を宣誓する。上場有価証券の発行者の

代表者が、記載して東証に提出し、東証のホームページにおいて公衆縦覧する。

ｂ．適時開示体制概要書（宣誓書への添付書類）による適時開示体制の整備状況の開示（http://www.tse.or.jp/jokan/sensei/gaiyo.html）適時開示体制概要書は、東証が上場有価証券の発行者に対して提出を求めている適時開示に係

る宣誓書の添付書類として提出が求められているもの。適時開示体制概要書には、上場会社各社の適時開示体制を記載する。適時開示体制とは、上場会社各社が適時適切な開示を実施することを可能とする体制で、具体

的には、適時開示すべき決定事実、発生事実、決算情報等を迅速かつ網羅的に収集し、適時開示

規則その他の関連話法令等を遵守しつつ、正確、明瞭かつ投資判断資料として十分な情報が記載

された開示資料の作成を行い、会社として公式な乗認・決定等を実施した上で、適切な時期に投

資者の公平性等に留意しつつ情報を公表できるような体制とされている。


496

ｃ．適時開示体制の整備の手引きと宣誓書記載上の留意点（http://www.tse.or.jp/jokan/sensei/notes/pdf）上場会社が適時開示体制の点検・見直しを進める上での指針、あるいは適時開示体制概要書を

記載する上での参考。

（５）「システム監査基準」、「システム管理基準」

（http://www.meti.go.jp/policy/it_policy/press/0005668/index.html） 2006 年 10 月に、経済産業省商務情報政策局情報セキュリティ政策室が公表した。趣旨は、情報技術の浸透や技術革新の影響により、企業経営における IT 投資の目的が、単な

る現場の合理化から経営そのものの革新へと大きく変化しつつある中、国際的な新動向も踏ま

えつつ、1985 年に策定した「システム監査基準」を改訂し、新たな「システム管理基準」及び「シ

ステム監査基準」を策定するというもの。

（６）金融機関等コンピュータシステムの安全対策基準（解説書：第 7 版）

本基準は、1985 年 12 月に金融機関等の自主基準として金融情報システムセンター（FISC）に

おいて策定され、その後 6 回の改訂を経て、現在まで金融情報システムに関する安全対策の共通

のよりどころとなっている。今回の改訂は、2005 年 6 月に着手し、個人情報保護法対応の追補、偽造・盗難キャッシュカ

ード問題に対応した追補 2、さらにオープンネットワークを利用した金融サービスの運用管理並

びに技術対策の見直し、定期的な（改訂サイクルの技術進歩、新法令等の対応）見直し等を行

っている。

以上の a～e が、内部統制で遵守・留意する事項として挙げた日本の法令・指針・ガイドライ

ンであるが、内部統制の捉え方次第でより範囲を拡大することも必要となる。 KPMGビジネスアシュアランス株式会社の「内部統制セミナー」（2005年 6月 7日開催）では、

企業に求められる様々な内部統制テーマとして、以下の 5 つを挙げている。・環境/品質（環境マネジメントシステム/経営品質マネジメント）・コンプライアンス・情報セキュリティ・個人情報保護・ビジネス継続内部統制をより広義に CSR とも関連させていくと、こうした定義も妥当である。本章で扱っているのは、こうしたテーマのベースとなる考え方であるが、上記の対象までカバ

ーするとなれば、次の図表 5-4-2 のように国際標準となっている ISO（JIS 化されているものも

あるが）、および各種フレームワークなども順次盛り込んでいくことが、必要となる。


497

図表 5-4-2 国際標準 ISO・フレームワークなど

区分具体的な指針・マニュアル・報告など

ISO14000 環境マネジメントシステム

ISO9001 品質マネジメント

ISO17799:2005 情報セキュリティマネジメントシステム

ISO/IEC 27001:2005 情報セキュリティマネジメントシステム

ISO

ISO/IEC 20000 IT サービスマネジメント

COSO Committee of Sponsoring Organizations of Treadway

Commission

COSO ERM COSO Enterprise Risk Management Framework

COBIT Control Objectives for Information and related Technology

リスク管理・プ

ロジェクト管理

PMBOK Project Management Body of Knowledge

２．推進組織の考え方・コラボレーション

内部統制を推進していく第一歩は、推進組織をどう編成するかである。米国企業改革法に対応している企業の中には、数十名の専従者（外部からの支援者も含む）を

確保しているところもあるが、必要性の度合いからして、読者の参考には必ずしもならない。現在は、実施基準が何時出るかと云う微妙な段階にあるが、JUAS の調査部会で例年実施して

いる上場企業などへのアンケート調査に、今年度初めて｢リスク管理・内部統制への取り組み状況｣

を組み込むことにしている。その一番の質問は、体制のことである。現時点で、想定している質問項目は以下のとおりである。 ◎内部統制・リスクマネジメント体制・「推進体制の有無」「専門委員会の有無」・「推進体制あり」「専門委員会あり」の場合の「主管部門」、「関連して推進する部門」・体制の構築状況 ◎金融商品取引法への対応の体制の構築状況（推進組織の内容など） ◎金融商品取引法への対応の進行状況 ◎同じく情報収集方法 ◎同じく外部コンサルタント（監査法人を含む）の利用 ◎同じく対応作業に必要な工数・費用 ◎同じく対応推進にあたっての悩み集計結果を読者にフィードバックすることで、組織を考える参考にしていただければと考えて

いる。


498

なお、Y2K や個人情報保護法のときに感じたのは、様々な組織の考え方があることである。大きなプロジェクトで著者の頭にすぐに思い浮かぶのは、「委員会を設置してプロジェクト型

で推進する組織」で、会社を挙げて推進するという姿勢を社内外に示しながら進むことである。しかし、JUAS で意見交換してみると、従来のラインを変えずに取り組む企業も多い。理由を

聞くと、プロジェクト型は、良い面も多々あるが、線香花火のようにブームが去るとそのノウハ

ウはどこかになくなるし、推進していくときの責任が時として曖昧になるので、本業として捉え

て継続的に取り組むには、従来の組織が主管となるのが良いとのことである。後の「今後の動向」で、社内の推進体制を取り上げるが、内部統制では大きなテーマである。

調査結果の中から何かヒントになるものがあればお伝えすることとしたい。

IT 部門が自らの問題意識・危機意識に基づいて独自に進める自主点検について、既に述べたが、

企業全体としてリスク管理を行い、法令などの外部要請による内部統制を推進するためには、ITが関係するシステム監査について、外部監査人および社内の内部監査部門とのコラボレーション

が必須となる。財務報告に関する内部統制を例にして、一連の流れを図にしたものが、次の図表 5-4-3 である。 IT 部門として監査にどう対応するかの第一の鍵は監査人の手続きを理解することから始まる

ので、次の項で日本公認会計士協会の資料を元に、監査の手続きの概要を紹介することとする。

また、本書の「第 4 章の 1 システム監査」において、システム監査の意義・概要・実態につ

いて述べられているので、参照してほしい。

（JUAS 企業情報マネジメント研究会遠藤誠氏の講演資料）39

図表 5-4-3 内部統制の手続きの全体像

39 【文献 13】「平成 17 年度企業情報マネジメント研究会報告書」


499

３．日本公認会計士協会の資料による財務諸表監査の流れ40

企業内の IT 担当が、財務諸表監査に対して何をどのように進めていけばよいのか、という点

に関して、日本公認会計士協会の一連の資料が 2 つの意味で役に立つ。 ①監査がどのような考え方と具体的な手続きで行われるかという流れを理解することで、IT 担

当として提出する資料等、準備しておくべきことが見えてくる。 ②監査法人ごとに諸手続きおよび監査の独自のノウハウがあって有益ではあるが、一般的な監

査の考え方を学ぶには協会でまとめた資料から入るのが順当である。本項では、企業側から見て監査を受けるために必要な対応を再編成して例示するにとどめてい

る。監査人として実施すべき詳細の項目については、協会のホームページをご覧戴きたい。文中で「理解する」とあるのは、監査人に向けてであるが、説明する企業側の IT 部門側から

は、当然理解しやすい資料を作る立場として自らに照らしてお読みいただきたい。以下の構成になっている。（１）IT の概括的理解のために企業が準備するもの（２）企業及び企業環境を理解するために準備するもの（３）経営者の主張と IT のコントロール目標との関係を理解するために準備するもの（４）各業務プロセスとの関係を理解するために準備するもの（５）ウォークスルーの実施（６）IT に関する統制の理解の留意点（７）統制活動の理解の留意点（全般統制）（８）統制活動の理解の留意点（業務処理統制）（９）その他・参考となる留意点

（１）IT の概括的理解のために企業が準備するもの

・IT インフラの概要（ハードウェア構成、基本ソフトウェア構成、ネットワーク構成）・アプリケーション・システムの構成（プロセスの何処に IT が利用されているか等）・電子商取引の利用実態・IT 投資（直接投資だけでなく人的投資も含む）・情報システムの変更（内部統制のデザインに影響があるかないか）・情報システムの安定度（過去における障害発生の有無と障害の程度）・外部委託先の利用状況・アライアンスの状況（支配力の及ばない相手先の信頼度など）

40 【文献 A9】日本公認会計士協会「財務諸表監査における情報技術（IT）を利用した情報システムに関する

重要な虚偽表示リスクの評価及び評価したリスクに対応する監査人の手続について」


500

（２）企業及び企業環境を理解するために準備するもの

財務諸表、会計アプリケーション・システム及び業務アプリケーション・システムの関係を例

示したものが、次の図表 5-4-4 である。

（【文献 A9】41）

図表 5-4-4 財務諸表、会計アプリケーション・システム及び業務アプリケーション・システムの関係

（３）経営者の主張と IT のコントロール目標との関係を理解するために準備するもの

情報システムの内部統制は経営者が構築するものであるが、その情報システムを有効なものと

するために経営者が設定する目標が、IT のコントロール目標である。例えば、次のものが挙げられる。・準拠性：情報が会計原則、会計基準、関連する法律及び社内規則等に合致して処理されてい

ること・網羅性：情報が漏れなくかつ重複なく記録されていること・可用性：情報が必要とされるときに利用可能であること・機密性：情報が正当な権脹雀以外に利用されないように保護されていること・正確性：情報が正確に記録され､提供されていること・維持継続性：必要な情報が正確に更新されかつ継続使用が可能なこと・正当性：情報が正規の承認手続を経たものであること

41【文献Ａ9】日本公認会計士協会「財務諸表監査における情報技術（IT）を利用した情報システムに関する重

要な虚偽表示リスクの評価及び評価したリスクに対応する監査人の手続について」


501

IT のコントロール目標の達成度（IT を利用した統制活動の有効性）に係る評価結果を、直接

的あるいは間接的に経営者の主張（アサーション）と関連付けて理解する。経営者の主張とその経営者の主張に関連する IT のコントロール目標は、企業の業種、組織、IT

の状況などに対応して、監査人が自らの判断で選定する。例えば、販売取引が適正に総勘定元帳に記録されていることを確かめる場合には、業務処理統

制、全般統制に分け、次の事項を確かめる。

ａ．業務処理統制・販売管理システムから会計システムヘの売上データの転送処理が、漏れなく重複なく処理さ

れたことを確かめることができる統制活動があること（網羅性）・売上取引を入力する際に、得意先や価格をマスタ・ファイルと照合する統制活動があらかじ

めプログラムされていること（正当性）

ｂ．全般統制・プログラム変更管理体制がること（正当性、正確性）・アプリケーション・システムの運用監視体制があること（可用性・維持継続性）

（４）各業務プロセスとの関係を理解するために準備するもの

企業の主要な取引を理解するとともに、取引と財務諸表、及び各業務プロセスと IT との関係

を理解する。財務諸表の重要な勘定科目が、どのような取引、企業の業務プロセス及びアプリケーション・

システムと関連しているかについて理解する。次の図表 5-4-5 は、販売取引における売上と入金の業務プロセス、ファンクション（働き）及

び会計データとの関連を、一つの例として図式化したものである。必ずしもこのような図を作成

する必要はないが、主要な取引等について、どの会計データがどのアプリケーション・システム

に依存しているのかを理解する。また、その業務処理が手作業によるものか IT を利用しているものかを識別し、重要な勘定科

目に関する財務情報の信頼性を確保することに関連する内部統制を理解する。


502

（【文献 A9】42）

図表 5-4-5 販売取引における業務プロセス、ファンクション及び会計データとの関連

（５）ウォークスルーの実施

理解した関係が実際に存在することを確かめるため、ウォークスルーを実施する。例えば、先の図表 5-4-5 のケースでは、販売取引のウォークスルーの一部として、販売管理シ

ステムの出荷データと売掛金管理システムの請求データとを照合する。

（６）IT に関する統制の理解の留意点

以下のチェックポイントに照らして、統制状況を理解する。

ａ．経営者の関心、考え方及び理念・経営者の関心、考え方及び理念は、企業の構成員の内部統制に対する意識に影響を与える。

（含む、情報システムに対する投資、情報システムの信頼性及びセキュリティに関する経営者の

意識や認識）

42 【文献 A9】日本公認会計士協会「財務諸表監査における情報技術（IT）を利用した情報システムに関する重

要な虚偽表示リスクの評価及び評価したリスクに対応する監査人の手続について」


503

ｂ．知的資産（無形資産）・知的資産としての情報の信頼性を支える情報システムに変化しつつあり、経営者は自ら、知

的資産の管理責任者として管理すべき情報を明確にしているか。・その資産を保全するためのセキュリティを確保するとともに、その方針をセキュリティポリ

シーとして社内に周知しているか。

ｃ．経営者の管理すべき範囲（スコープ）他社の情報システムが自社のビジネスに影響を及ぼし、また、自社の情報システムが、他社に

影響する場合もあることを経営者が認識しているか。

ｄ．ネットワークの利用インターネットによる電子商取引のように、企業の構成員とは異なる価値観や倫理観を持つ人

間が、企業の情報システムに重要な影響を与える場合がある。企業の情報システムが、企業外部

の様々な人間によって影響を受ける可能性について､経営者が認識しているか。

ｅ．法令等への準拠性電子商取引のビジネスモデルの特許問題や個人情報の保護、及びソフトウェアの不正使用など

に関する訴訟の可能性、また、多国間のインターネット取引に関する課税問題など、企業の財務

諸表に影響を与える可能性に経営者が注意を払っているか。

ｆ．IT の発達に伴う社会の基本的なインフラの変化経営者が必要な情報システム投資を行わないこと、又は必要以上に高いコストを情報システム

に払うことなどにより、企業のビジネス自体の継続性に問題が生じたりすることのないように、

経営者が IT の動向に注意を払っているか。

ｇ．アウトソーシングのサービスレベルアウトソーシングのサービスレベルは相手先との契約上の合意によって決まる。アウトソーシ

ングに関する契約内容について、経営者が注意を払っているか。

ｅ．IT に関する教育・IT 担当者がその企業の情報システムに関して十分な知識や経験等を有しているか。・新しい情報システムの導入時には、IT 担当者のみならず IT のユーザーに対しても適切な教

育を行う必要があることに経営者が注意を払っているか。・情報システムの維持・継続に十分な人員を確保しているか。

ｆ．財務報告目的の情報システム（関連する業務プロセスを含む）と伝達の理解企業の経営者が適切な判断を行うために必要な信頼性の確保された情報を入手できるように情

報システムを設計しているか。（例えば、滞留在庫や不良品、滞留売掛金などの不利な情報）

./keyword.htm#3601


504

（７）統制活動の理解の留意点（全般統制）

全般統制は、主要な取引、勘定残高、開示等並びにそれらに関連する経営者の主張のほとんど

に関係している。この全般統制は、取引、勘定残高、開示等における情報の信頼性を確保するこ

と、及び業務処理統制の継続的な運用を確実にすることを間接的に支援するものである。全般統

制は、企業のシステム構成によりその範囲が異なってくるため、企業の実態を十分検討の上、全

般統制の適用範囲を識別する。・大型汎用コンピュータを中心とするホスト系システムを利用している場合・クライアント・サーバシステムを利用している場合・Web アプリケーションを利用している場合・企業内外のネットワーク環境への対応全般統制の例示と評価上の留意点は、以下のとおり。

ａ．情報システムに関する企画・開発・調達業務の統制活動情報システムに関する企画・開発・調達は、他の内部統制の整備状況や運用状況に影響を与え

る。特に、ユーザー部門の参画による十分なテストの実施・検収や、適切なプログラム等の移行・

変更管埋け、情報システムの信頼性に影響を与える。情報システムの新規開発やパッケージソフトの導入、並びに情報システムの運用・管理のため

の内部統制がデザインされているかについて検討する。

ｂ．情報システムに関する運用・管理業務の統制活動適切なデータを適切なプログラムで処理し、信頼できる処理結果を得るための内部統制をデザ

インしているか。この内部統制には、例えば、次の事項が含まれる。・オペレータによる手動又は自動実行ツールによるプログラム等の運用手順・プログラムによる処理結果の確認手続・実行スケジュール管理・エラーが発生した場合の再処理の方法を含めた対応手順・不具合が発生した場合のプログラムの修正手順・適切なプログラムの使用のためのライブラリ管理

ｃ．セキュリティに関する統制活動・企業がデータ、ソフトウェア、ハードウェア及び関連設備等の不正使用、改竄、破壊等を防

止するために、アクセス管理や自然災害等への対策のための内部統制をデザインしているか。

（内部統制には、アクセス管理用のソフトウェアを導入し、ID とパスワードの組合せをプロ

グラムでチェックするような論理的なものだけでなく、コンピュータルームヘの人室を制限

して、ハードウェアの物理的な破壊や盗難を防止するような対策も含まれる。）・セキュリティに関する方針を、情報システムの企画・開発・調達段階においても検討し、文

書化しているか。


505

ｄ．アウトソーシングの統制活動委託業務を管理するための内部統制をデザインしているか。・企業による受託会社の選定基準、成果物等の検収体制、受託会社の内部統制が自社に与える

影響等を評価する。・企業の基幹業務の一部を受託会社が担っている場合には、受託会社のシステム障害が、企業

の業務の運営に支障をきたす可能性があるので、受託会社との間で合意されているサービス

レベルに留意する。

（８）統制活動の理解の留意点（業務処理統制）

続いて、業務処理統制の例示と評価上の留意点は、以下のとおり。

ａ．情報システムに関する統制活動企業の財務報告の信頼性を確保することに関連する業務処理統制を理解するに当たっては、情

報システムに関連する統制活動を次のように分類する。・アプリケーション・システムに組み込まれた統制活動（自動化された統制活動）・人と IT が一体となって機能する統制活動（IT による情報を使用した統制活動）企業の各業務プロセスの内容を理解するとともに、IT のコントロール目標と経営者の主張を関

連付けながら、統制活動と監視活動の整備状況を理解する。なお、アプリケーション・システムは、業務プロセスごとに作成されることが多いため、監査

人は、各企業の実態に応じてアプリケーション・システムを分析する。業務処理統制に関しては、業務プロセスにおいて適用されている活動が、手作業によるもので

あれ、IT を利用したものであれ、一体として実施されていることをウォークスルーにより理解す

る。

ｂ．業務処理統制の評価指針の例示会計データとファンクションに関する業務処理統制を評価するための指針として、例えば、次

の IT のコントロール目標が挙げられる（図表 5-4-6 参照）。・会計データの網羅性

会計データが漏れなく、重複なく記録され、残高更新され、未決済及びエラーと成った会計デ

ータは、期間内にすべて適切に処理されていること・会計データの正確性

・会計データは、正確に適時に適切な勘定に記録されていること・エラーとなった会計データは、期間内にすべて適切に処理されていること

・会計データの正当性・会計データは、当該企業に財務的影響を及ぼす取引その他の事象を表し、かつ当該企業に承

認されたものだけが入力され、処理されていること・適切な職務権限に応じて、アクセス権限が設定され、適切な担当者により処理されているこ

と


506

図表 5-4-6 IT のコントロール目標と経営者の主張との関係の例示（販売取引の一部）

IT のコントロール

目標

会計データの

網羅性

会計データの

正確性

会計データの

正当性

ファイルの

維持継続性

具体的な IT のコン

トロール目標

売上取引が漏れな

く、重複なく記録さ

れ､残高更新され､

未決済及びエラー

となった売上取引

は期間内にすべて

適切に処理されて

いること。

売上取引は、正確

に適時に適切な勘

定に記録されてい

ること。エラーとなっ

た売上取引は期間

内にすべて適切に

処理されているこ

と。

売上取引は、実際

に生じた経済事象

を表し､かつ、当該

企業に関連するも

のであり、承認され

たものだけが入力

され､処理されてい

ること。

コンピュータに入力

され､処理されたす

べての売上取引

が､販売管理システ

ム及び会計システ

ムに正確に更新さ

れていること。

統制活動の例


された出荷指図書

の連番管理。

売上データが出荷


ごとに作成され、販

売管理システムか

ら会計システムに

バッチで転送される

際に､数量と金額の

件数と合計の突合

が行われる。



の数量又は単価

が、一定の範囲を

超えるとエラーにな

る。

コンピュータ入力時

に、得意先及び価

格についてマスタ・

ファイルとの存在チ

ェックが行われる。

コンピュークヘの入

力時に、得意先、価

格及び与信限度に

ついて、マスタ・ファ

イルとの存在チェッ

クが行われる。

与信限度を超えた

取引は上司の承認

入力が必要となる。

販売管理システム

の売上取引の合計

額と会計システム

の売上高は､システ

ム上で照合されて

いる。

発生 ○ ○

実在性 ○ ○ ○

網羅性 ○ ○

正確性 ○

権利と義務

(注)

評価 ○

経

営

者

の

主

張

期間帰属 ○

（注）この例示では､経営者の主張の｢権利と義務｣と関連付けられる IT のコントロール目標がないため○を

どの欄にも付していない。

・ファイルの維持継続性

・マスタ・ファイルは、常に新の状態に保たれ、正しく維持及び継続されていること

・異なる IT 間で利用される分散マスタ・ファイル間の整合性が保たれていること


507

（９）その他参考となる留意点

ａ．記録や文書の閲覧監査人は、システムの運用記録、障害報告を閲覧することにより、発生した障害が網羅的に記

録されていること、記録された障害対応が適切に行われていることを確認する。また、電子データを利用した総勘定元帳、補助元帳、各種証憑書類等との突合を実施すること

がある。システム設計書等を閲覧し、会計方針、法務要件、業務要件に合致したシステムが作成されて

いることを確認する。 IT については、システム要件、設計の確認を行うことによって実証手続を兼ねることができる

ケースが存在することに留意する。

ｂ．観察／システム運用現場視察 IT システムの運用、管理現場の視察を行い、システム運用、変更に関する続制についての把握､

テストを行う。観察は主に、リスク評価手続で利用されるが、IT については、リスク評価手続を通して、運用

評価手続を兼ねることができるケースが存在する。

ｃ．具体的な評価手続き監査人による具体的な評価手続は、参考までに以下のとおり。・システム担当者への質問やフローチャート等の作成により、統制活動の設定状況を理解する。・企業が実際に統制活動を実施している現場の観察や、文書による証拠などを検討する。・IT を利用しているユーザー部門における実施状況を検討することにより、企業が設定してい

る統制活動が実際に業務に適用されていることを確かめる。・IT を利用した統制活動が手作業による統制活動により補完されている場合には、監査人は、

重要な虚偽表示リスクを識別するため、IT を利用した統制活動と手作業による統制活動の両

方を総合的に評価する。・内部統制の目的は、１つの統制活動で達成できるものではなく、いくつかの統制活動で補完

されて達成される。したがって、監査人は、情報システムに関する統制活動の弱点を発見し

た際には、その弱点を補完する統制活動の有無を調査し検討する。購買システムのうち、検収業務の監査上のリスクについて、業務処理統制及びその検証手続を

例示すると、次の図表 5-4-7 のようになる。


508

図表 5-4-7 業務処理統制およびその検証手続き例

監査上の

リスク

IT のコントロール

目標業務処理統制業務処理統制の検証手続

検収入力ができるのは､

システムに登録された発

注取引に対してだけであ

る

・システムに登録されていない発注番号の入

力ができないことを観察・再実施等により

確認する

・分納や数量違いの場合の処理ロジックの妥

当性を質問・再計算等により確認する

・完納済みの発注番号は検収入力ができな

いことを観察・再実施等により確認する

発注してい

ない物品

が検収され

る

会計データの正

当性

｢検収違算報告書｣が出

力され､発注データと検

収データのチェックがで

きる

・「検収違算報告書」の作成ロジックの妥当性

を質問・再計算等により確認する

・「検収違算報告書」の検証・承認手続が実

施されていることを閲覧・質問等により確

認する

検収画面にエディット・バ

リデーション・チェック（入

力内容が入力を予定して

いる要件と一致している

かどうかをチェックする）

が組み込まれている

・組み込まれているエディット・バリデーショ

ン・チェックが機能していることを観察・再

実施等により確認する

検収データ

が正確に

入力されな

い


確性

｢入力プルーフ・リスト｣

が作成される

・「入力プルーフ・リスト」の作成ロジックの妥

当性を質問・再計算等により確認する

発注入力、検収入力を行

える者が限定されている

・入力可能なデータ項目が、業務担当者の職

務権限に対応した範囲に限定されている

ことを観察・再実施等により確認する

・パスワード等の登録、変更の手続を閲覧・

質問等により確認する

購買取引

が適切に

記録、又は

仕訳されな

い


当性/正確性

検収入力時に仕入計上

され、システムにより自

動仕訳される

・システム上、検収入力時に仕入計上される

ことを質問・再計算等により確認する

・自動仕訳パターンの妥当性を閲覧・質問等

により確認する

・自動仕訳パターンの登録、変更の手続を閲

覧・質問等により確認する


509

ｄ．情報システムに関するリスク評価における重要性の判断情報システムに関するリスク評価における重要性の判断においては、金額的な面のみだけでは

なく、質的な面、及び当該リスクが企業に与えるその他の潜在的な影響の大きさなども勘案する。例えば、ID とパスワードの管理であっても、販売アプリケーション・システムの場合、アプリ

ケーション・システム全体の管理者の管理は、売掛金等の特定のデータヘのアクセス権を持つ担

当者の管理よりも重要である。

ｅ．全般統制に不備があった場合の留意点全般統制の不備は、直接的には重要な虚偽表示リスクに繋がるものではない。しかしながら、

全般統制は、主要な取引、勘定残高、開示等並びにそれらに関連する経営者の主張のほとんどに

関係しているため、全般統制に重要な不備があった場合には、たとえ業務処理統制が有効に機能

するようにデザインされていたとしても、その継続的な運用を支える情報システムの内部統制は

有効に機能せず、重要な虚偽表示リスクが高まることとなる。当該業務処理統制が関連している財務諸表項目レベルの重要な虚偽表示リスクを評価する追加

的リスク評価手続、運用評価手続の必要性及び実施する手統の内容、範囲等を検討し、何らかの

追加的リスク評価手続、運用評価手続の実施が財務報告の信頼性の確保に寄与すると判断したと

きは、その手続を実施することになる。例えば、不備がある全般統制に関連する業務処理統制の運用評価手統の範囲（件数、期間等）

を拡大するなどの対応が必要になる。


510

511

第５章リスク管理・内部統制第５節今後の動向─内部統制進化論─

─リスク文化が身についてこそ、社会から信頼されるビジネスが展開できる

システムリスクが企業全体、社会にまで広がっている昨今、社会的にリスク管理態勢が求めら

れている。経営理念に沿ったリスク管理が末端にまで浸透するには、最終的にその会社の文化に

まで高めることが必要である。

１．内部統制とガバナンスの関係（信頼性のガバナンス）

２．リスク管理・内部統制の進化

３．組織・人材育成

４．リスク文化の醸成

５．最後に（見えた課題、残る課題）

６．付録

５－５今後の動向─内部統制進化論─

512

１．内部統制とガバナンスの関係（信頼性のガバナンス）

各種概念の定義がマチマチであれば、概念間の関係図もバラバラになる。一番困るのは、お互

い微妙な関係にあり、一部を共有化しつつ別な概念として整理されることで、2 つ位なら我慢で

きても、こうした概念がいくつも出てくると、説明することすら難しくなり、具体的な解決には

寄与しない机上の空論に入ってしまう。「信頼性のガバナンス」という考え方で、様々な同種の概念を整理しようという動きがある。

信頼性のガバナンスは、次の図表 5-5-1 のような図式で表される43。

外部監査格付け社会コミュニケーション

社会的責任経営（ＣＳＲ）

コーポレートガバナンス

コンプライアンス

内部統制

情報セキュリティガバナンス

個人情報保護

顧客価値創造

顧客接点

信頼資産が価値創造の源泉に

（野村総合研究所村上輝康理事長「経営と情報とセキュリティ」2006 年 6 月 20 日講演資料）

図表 5-5-1 信頼性のガバナンス

43 野村総合研究所村上輝康理事長の 2006 年 6 月 20 日の東京大学での講演資料を著者が再現


513

情報セキュリティ → 内部統制 → IT ガバナンス → CSR の順番で範囲が広がって

いく。厳密には、プロセス、マネジメント、ガバナンスは次元の違う概念なので比較しようがな

いということも言えるが、カバレッジの大きさということで理解していただきたい。重要なこと

は、入れ子構造になっていることである。各言葉の定義の違いを論じても意味がなく、要は、複雑な相関を止めて単純な包含関係が成り

立つように、言い換えれば、境界線が明確で範囲が重ならないようなイメージにまずは簡単にま

とめておくことが、全体像を説明するのに良いということである。このことは、同じ企業内での組織や対策が重複しないようにして、組織間のインターフェイス

で取られる時間の無駄を廃除し、一貫した判断を可能にするにはどうしたらよいかと言う課題の

ヒントになる。社内の体制を思い浮かべながら、シンプルに表現しようとするとこうなるのでは

ないだろうか。この図表 5-5-1 に、リスク管理も入れると、結構複雑で論議を呼ぶが、ディスカッションして

いくと、文殊の智恵で、自社の経営環境や風土に合った各企業なりのラフなイメージが湧いてく

る。以上が、誰にでもわかりやすくするための図の効用であるが、リスク管理担当の頭の中では、

マトリックスで整理するなりして、実態の複雑さは複雑なままで止めておく必要がある。そして、

新たなビジネスに挑むとき、深刻な事故例に遭遇したとき、リスク管理のフレームワークが陳腐

したと感じたときには、ゼロベースで再考することが肝要である。同じ会社でも進化して行くに

連れて、図も変化していく。また、包含関係と言っても、狭い目的で実行した施策が、無条件でより大きな目的にも貢献す

ると言うことではない。皆が広い視野で物を考えて、実行段階ではそれぞれのポジションをきっ

ちりと実行するということである。２．リスク管理・内部統制の進化

COSO-ERM が 2004 年に公表されたが、その時点で米国におけるリスク管理の成功事例、ベ

ストプラクティスが掲載されている。挙げられた先進企業は、その時点で適化されて成果を公

表できる状態にまで達しているということである。グローバルな時代に、守りの IT ガバナンスの日米の彼我のこのスピードの差が、攻めである

ビジネスの差にも表れてくることを考えると、危機意識を持たざるを得ない。即効性のある対策はなく、そのために一定の時間を覚悟しなければならない。例えば、対応をするとすぐに効果が現れるものではないという理解に役立つ図が、米国版企業

改革法に関連して紹介されている（図表 5-5-2）。44

44 PROTIVITY 社資料:URL www.protiviti.jp/downloads/coso_erm.pdf


514

①企業改革法の要請を遵守する

⑤継続的な改善を通じて適化する

②改善のために外部情報を探す

③改善をデザインする

④改善を実行する

時間

虚偽表示のリスク

ほとんどの会社の状況

リスクが大きく削減される

段階

法令順守は必要低限更なる改善のためのステップが必要

①企業改革法の要請を遵守する方針および手続きの文書化、コントロールの整備状況と運用状況の評価

②改善のために外部情報を探すベストプラクティス、パフォーマンスとのベンチマーク

③改善をデザインするコスト削減、コントロールの改善、時間短縮のためのプロセス改善

④改善を実行する改善されたリスクマネジメントプロセス、内部統制およびＫＰＩの導入

⑤継続的な改善を通じて適化する

（トレッドウェイ委員会 www.protiviti.jp/downloads/coso_erm.pdf）

図表 5-5-2 リスク管理・内部統制の進化

5 段階に分かれているが、中でも印象的なのが、⑤の部分である。この段階が、内部統制が導入されてスタートラインに立ったと言える時点で、PDCA が回り始

めたと言える時点である。 Web 進化論という中で、Web 2.0 が注目を集めているが、先進の米国企業を 2.0 とすれば、法

の成立が既に 4 年遅れている日本の現状は 0 ではないだろうか（マイナスと言われる方もいる）。欧米の金融機関の将来予測をしたレポートでは、「金融機関は全社的なリスク統合に向けて大

きな進歩を遂げており、殆どすべての企業が今後 4 年以内にあらゆるタイプのリスクを ERM 戦

略に完全統合することを計画している」とある。45 日本の大半の企業がこれからスタートして追いつけるかと言うことである。難しいことではない。地道に進めるしかないことを厭わずに実行するかである。それだけに、抜け道はなく、追いつくのもまた難しいと言える。その解決のキーワードは、「人材の育成」と「リスク文化の醸成」にある。

45 【文献 A7】日本 IBM 社の HP から（Building an Edge 欧米金融 IT レポート「リスク、規制と、そのリタ

ーン」）


515

３．組織・人材育成

（１）社内の推進体制

個人情報保護法のとき、経営企画部、文書法務部、コンプライアンス部、IT 企画部など、多く

の部門が関係し、主管部門の性格も企業によって異なっていた。 JUAS 研究部会でも、2006 年度のテーマとして掲げている会社法や金融商品取引法対応への参

加メンバーの所属組織は、経営企画部、リスク管理部、経理部、IT 企画部など、多彩である。複数の組織をまたがるテーマをどう処理するのか、推進体制の在り方が重要になってきている。

では、どうすれば良いのだろうか。考えるヒントは、今まで述べてきた。信頼性のガバナンスの図（図表 5-1-1 参照）のように、概念を 1 枚の絵に表して見ることが整

理の第一歩である。経営者の立場に立って全体像を描きながらアプローチする部署が社内にないと、混乱する可能

性が高い。全体適の組織を常に考える。何時までも、個別課題の組織を抱えているとすれば、テーマが

変質していくのに対応しきれず、部分適にしかならない。振り返ってみると、個別課題が発生

する都度、プロジェクトチームや委員会組織で動くことは、日本の現況で機動力を確保するには

有効であると思う。したがって、ある程度サイクルが回った時点で既存の定常的な仕組みにビル

トインしていくことをタイミングよく行えればよい。これからは、導入のときに定着したときの運用を考えられるかが大きな決め手になる。導入は

一時であるが、運用は会社が存続する限り続く。経営資源の無駄使いはこうした入り口論議のみ

に執着したときに発生するので、可能な範囲で、全体像を描いて取り掛かるように努めていく。基本的な課題である「改善のための PDCA を回す仕組みの定着」ができていれば、個別課題は

応用問題になる。ISO は「コンテンツ」は違うが皆同じ枠組みで動く。リスク管理も個別コンテ

ンツではなく、企業改革の PDCA を回す下層のレイヤーと考えて取り組んだほうが良い。金融

商品取引法対応も、財務諸表の信頼性に限定したとしても、社内のリスク管理全体を俯瞰した体

制に組み込んでいくことが必要と考える。システム部門が単独でコンピュータセンターの中で仕事をする時代はとうに終わっている。シ

ステムのノウハウ自体が専門家として評価されていたホストコンピュータの時代は過去のもので、

誰もが PC を利活用したビジネスを日々行って、システムリスクが企業全体、社会にまで広がっ

ていることも見逃せない。法律家や監査法人も、システム関連の事案に多く携わり、様々なアプ

ローチをしてくる。システムが広く社会や部門外と接して、自らの説明責任を果たしていく時代

に入っている。


516

（２）質の良い監査人・コンサルタントの確保

監査や法対応を効率的かつ的確に進めていくには、専門家との二人三脚で、アドバイスを受け

ながら実践していくのが早道である。特に、ガバナンスという観点に焦点を当てた検討には、高度なノウハウを求めるので、ベテラ

ンで自社の状況にも明るい方の確保が望ましい。しかしながら、ベテランの監査人・コンサルタント、特にシステムに精通した方の人数は、国

全体で極めて限られている。そうした優秀な方達のキャパシティでは、今の時代の要請に応えることはできず、未経験者が

導入されることをリスクとして認識しない訳にはいかない。そして、米国では、監査人に高額な時給を要求されて断ったところ、新米に担当が変わり、説

明の時間や資料作りに貴重な労力を注ぐことになったという事例を聞いている。説明というか初

期教育のために業務に詳しい企業のキーパーソンが割いた時間を考えると、却って高くなってし

まうということにもなりかねないという現実もある。監査を受け、コンサルタントを依頼する企業が自ら身を守るための自己防衛の対応が求められ

ている。 JUAS の研究部会でも、会社の高機密を監査人やコンサルタントに開示するときに守秘義務

は当然課すとしても、漏洩のリスク（不注意によるものも含めて）等は、企業が損害を蒙ること

＝存続の危機に繋がるという重大な事件であることを考えると、ベテランでないコンサルタン

トに対しては慎重にならざるをえないという意見を聞く。こうして、平時であれば、リーズナブルな金額でノウハウを持った監査人やコンサルタントを

確保することができたが、特需と言われる異常な盛り上がりの中で、優秀な人材を確保すること

が難しくなっていることが、リスク管理・内部統制の普及を難しくしている。前述のとおり、自主点検で実施した結果にアドバイスを求めていくことが、この面からも有益

であると考える。


517

（３）人材育成

今着手しなければいけないのが、人材の育成である。 55 年前の産業合理化審議会の答申を取り上げたが、その当時の、答申の大の眼目は何であっ

たかというと、国を挙げて内部統制の専門家の育成をすべきであるということである。 IT 関連では、もっと広く根の深い「高度 IT 人材育成」という大きな課題も抱えている。プロ

ジェクトマネージャー、組み込み系ソフト開発担当、CIO の不足である。産学官が一体となってプロジェクトチームを編成し、2007 年度から、重要拠点大学に大学院のコ

ースを設置し、産業界からも講師を派遣するなどして、より質の高い、産業界の将来の核となれ

る人材の育成カリキュラムを作成していくこととしている。その中にも、こうした信頼性向上のためのベーシックな講義も入れていくように働きかけている。企業の中で、システムリスク管理・内部統制のためにコンスタントな専任組織を作れるかどう

かはその会社の規模や考え方次第で、多くは、品質管理担当や情報セキュリティ担当が兼務した

りすることになる。専門知識の勉強は自社の中では難しい。一番望ましいのは、期間は短くとも、良きコンサルタ

ントに巡り合うことである。次に、JUAS 研究会のような学際的な勉強会で周辺の勉強や、実践

の勘所などを情報交換することである。経営がリスク管理担当のノウハウの蓄積をバックアップしながら、社内にリスク文化を定着さ

せて自主的に進化していく仕組みを地道に築いていくことが、結局早道である。

４．リスク文化の醸成

（１）リスク管理態勢構築の難しさ

システムリスク管理態勢の確立と言うが、簡単なものではない。トラブル削減を出発点に、リスク管理担当、システム開発、システム運用の 3 者の強力なトラ

イアングル体制で綿密な連携を取りながら、地道な対策を並行して進めてきたが、環境が整って

大きく掘り下げていくにはやはり時間がかかっている。システム開発では、テストの見直しから始まって、要件定義、プロジェクトの稟議へと上流に

遡って行って、初めて下流への水が綺麗になる。足元の濁り水を地道にすくい上げていく仕事で

ある。システム運用は、さらに自社の環境に合った具体策な足固めに時間がかかる。こうして、

PDCAを何度も回して、やっと大きな流れができて、進化の螺旋階段を一回り上ったと思ったら、

また、新たな問題が山積しているという現状に愕然とする。環境変化に、改善のスピードが追いつけないといけないが、IT の進歩や経営を取り巻く環境が

激変し、緊急課題の度重なる出現（例：個人情報保護法対応での技術的安全管理措置）を考える

と、悠長に PDCA を回している余裕がなくなってきている。戦略を核にした全社的リスクマネジメントの海外での事例を読んでいると、経営理念に沿った

リスク管理態勢を、工夫と智恵で白地に書いているのを見て、経営レベルでの本物の危機意識こ

そ進化の原動力だと改めて感じている。


518

（２）リスク文化の重要性

法令等を遵守して、公正な取引をすることは、企業として当然の社会的な責任である。その上

で、経済合理性と透明性をベースとした企業価値向上の経営活動を行うために、本書で言う、攻

めと守りのバランスを取ったリスク管理が求められている。リスク管理に会社全体で取り組み、末端まで行き渡るということは、終的に、その会社の文

化にまで高まっていくということになる。筆者は、リスクに挑むことによって収益を生むことができるのであり、何か悪いものと言う誤

った印象が流布しないよう願っている。コンプライアンスという言葉も、初の堅苦しい定義から、徐々に馴染みやすいコンプライア

ンス宣言に改善されてきている。次は、内部統制の導入を機に、リスク文化の導入の局面に入ったと言える。リスク文化が浸透

しなければ、スピード感を持って企業が動くことはできないし、進化していくための遺伝子まで

変える改革は難しい。そのためにも、自社の良い所を強調して持続的な成長を支えられるような

要素も、併せて組み込むことが必要となる。結論として、全社員および関連するグループ会社、戦略的な委託先に至るまで、同じリスク管

理の文化を共有することが、今後の経営の重要課題である。本当に浸透するには時間がかかる。そのためにも、第一歩は、早いほうが良い。

５．最後に（見えた課題、残る課題）

「難しいことをやさしく、やさしいことを深く、深いことを誠実に」書いたつもりであるが、

元々複雑な論議が積み重ねられ、関係者が様々な思いを抱くようになったテーマだけに、すっき

りとした解説は難しいと感じている。近、各方面の方が内部統制をテーマに出版されている書籍で、本質を掘り下げようというも

のが増えてきているのは嬉しいことである。ただ、実務になると、監査人またはコンサルタント

の立場からの意見や問題の提起が大半で、企業の中で攻められる側、本来は責任を持って推進す

る立場にある担当が、全体適を考えながら何を考え、どう行動するかについて、言及されてい

るものはまだ少ない。各分野の専門家としての立場から止むを得ないとは考えるが、後まで遂

行する立場にある企業の担当は、背骨を真っ直ぐに立てて揺らぐことのない思索力を大切にして

いかないと、翻弄されてしまいがちである。本論の記述で、以下の質問に、自分なりに答えられるようになっていただければ幸甚である。・リスク管理、内部統制の諸概念や様々な方針を自社の全組織に浸透させられるか。・内部統制を巡る諸外国・日本の判例等に照らして、自社の対応は十分か。・過去の内部統制の不備を理由にした判例への再発防止策はできているか。・米国証券取引所の制裁金や株主訴訟で高額の賠償を求められた事例に対応できるか。・COSO をベースにした金融庁の検査マニュアルや経済産業省のレポートを活かしていけるか。・リスク管理・内部統制の管理態勢を構築するにはどうするか。先端のリスク管理態勢とは

何か（推進母体の組織、投入する人材の確保など）


519

本章は、リスク管理・内部統制の基本的な考え方を理解していただくことを主眼にしている。関心の高い金融庁・企業会計審議会からの実施基準を受けての対応は、未発表の段階なので詳

論はできないこと、JUAS 会員を中心に上場企業などにアンケートを取って新情報を踏まえた

分析は年末になり本論では間に合わないなど、微妙なタイミングでの出版となる。46 企業のリスク管理・内部統制の担当にとっては、是非参考にしたい情報であろうが、日本にお

いての推進基盤が整っていない状況で、手探りの検討がこれから暫くは続くこととなる。リスク管理・内部統制は、個別企業の努力だけで解決できないものもあり、企業間の情報ネッ

トワークおよび国を挙げての推進の支援を望みたい。特に、以下の点は今後検討が必要な項目である。・金融庁・企業会計審議会からの実施基準を受けての対応（平成 18 年 9 月末時点で未公表）・国家基本戦略からのインパクトも取り入れた全体像（経済産業省の IT 経営や、情報セキュリティ基本計画など）・リスク対策への投資コストの目安（上場企業のミニマムラインのモデル）・講じる施策の程度（身の丈に合ったとはどの程度か）・推進組織の雛形・リスク管理担当の役割と人数・推薦できる具体的な手法（実装の仕方、ツールなど）・日本企業の良さを活かしたリスク管理の適切な適用の仕方（金融機関の先行事例とモノ作りのノウハウを活かした事例の活用）・より戦略的なリスク管理への展望（バランススコアーカードの活用など）

46 編集者注：本書の執筆は 2006 年 9 月末現在


520

６．付録

付録１：JIS 規格での定義

リスクマネジメントシステム構築のための指針 JIS Q 200147 解説：『リスクに相当する適切な日本語は、存在しない。辞書によれば、RISK の一般的な定義

は、“危険、冒険、危険性［度］、損傷［損害］のおそれ”（研究社の辞書より引用）とされており、

一般的な理解もこのようなものであろう。しかしながら、この定義では、具体性に欠けるので、

リスクマネジメントを行うにはさらに明確な定義を行って関係者間の理解を共通にすることが必

要である。リスクには、複数の定義が存在するが、共通の性質として次の 2 つがある。 1）その事象が顕在化すると、好ましくない影響が発生する。 2）その事象がいつ顕在化するか明らかではないという発生の不確実性がある。』

付録２：リスク認知・予測の歪みの事例

本文で取り上げた文献以外にも、「全社的リスクマネジメント（COSO-ERM）」48においても、

「リスク評価の発生可能性と影響度の推定」の項で、以下のように、リスク認知・予測の歪みに

ついて記載している。意思決定者は、自らの予測能力を過信して、不確実性を予測する際に、不当に信頼性のないほ

どの誤差を生み出す。ただし、内外で生成される経験的なデータを有効に活用することによって、

この誤差は限りなく小さくできる。また、人が利益を追求する際（アップサイド：潜在的な収益機会）と損失を回避する際（ダウ

ンサイド：潜在的な損失懸念）とで異なる選択をする。・確実に 240 ドルの収益を得るか、25%の確率で 1000 ドルの収益を確保するかと言う質問に

は、ほとんどの人が 240 ドルの収益を選択する。・確実に 750 ドルの損失を被るか、75％の確率で 1000 ドルの損失を被り、25%の確率で損失

を被らないとの質問には、75％の確率の回答を選択する。

47 【文献 11】「2006 年版 JIS ハンドブック 58-4 リスクマネジメント」P33、P60 48 【文献 2】「全社的リスクマネジメント. フレームワーク篇」


521

付録３：「内部統制（Internal Control）」という言葉

「内部統制（Internal Control）」という言葉について考えてみる。まず、「統制」であるが、国語辞書によれば「一つにまとめて治めること、一定の計画に従って

制限・指導を行うこと」（広辞苑）という意味を持つ。また、英文の「Control」とは「影響力を行使し抑制または方向付けること、指示を与え管理す

る権限、命令・規制・調整すること」（Webster）を意味する。「Control」の語源をたどると、羊の保全のために、羊の皮で作った巻物（Roll）に羊の頭数を

書き込み、それを定期的に照合する（Contrast）ところから来ているとされており、資産の保全

のために正確な記録をつけ、それと現物を照合するというのが本来的な意味のようである。経営論の中では「統制」とは「あらかじめ設定された目的に対して意味のある影響を及ぼすこ

と」（James R. Beniger）とされ、「目的を設定し、その達成に向けて行動すること」が統制とい

う概念の基本とされている。「内部（Internal）」というのは、企業内、組織内という意味で、外部の監督機関や外部監査人

からの統制は除かれているという意味である。コーポレートガバナンスとの関連で考えると、コ

ーポレートガバナンスを「経営陣に対し株主価値の維持・向上を求めるメカニズム」という外部

からの要請とした場合、「内部統制」は経営陣がそうした要請に応えて「限られた経営資源を効率

的かつ合理的に活用し、大限の効果を発揮する」という使命を果たすための有効な社内的なメ

カニズムの一つと言える。ただし、社内的なメカニズムとは言っても、開示を求められることを前提として、構築してい

くことが必要な時代になってきている。

付録４：米国の内部統制の歴史（トレッドウェイ委員会以前）

①内部会計統制（Internal accounting control）の時代

20 世紀前半に成長した米国企業において、一部の経営者の間では、企業の成長および効果的な

経営の実践のためには、有効な内部統制システムが重要であるということが認識されていた。また、有効な内部統制システムを備えた企業の財務諸表を監査した監査人からの報告でも、こ

うした企業については、会計監査の範囲を限定できるなどの実効性が上がって、効率的に監査を

遂行できることが認識されたことから、監査人は企業の「内部会計統制」（会計数値の信頼性を確

保するための社内体制）の状況を理解することを求められていた。しかしながら、内部会計統制の明確な定義が行われることはなかった。 1938 年の NYSE 上場企業による大型の不正会計事件49を契機として、外部監査人が理解すべ

き内部統制の適正範囲が何かという摸索が漸くなされるようになった。 1940 年代に入って、アメリカ公認会計士協会によって、内部統制の定義と改正が続けられた結

果、会計機能および財務報告に係る統制である「内部会計統制」と、それ以外の事業活動に係る

統制である「内部管理統制」（Internal administrative control）の 2 つの概念に基づく説明が試

49 マッケソン＆ロビンス社が、総資産の 2割に上る在庫と未収利益の架空計上を行っていた事件で、同社会長による不正

を外部監査人が全く見抜けなかった。会計監査業界は特別委員会を結成して報告書を作成し、これが監査手続書（現在の

監査基準書 SAS の前身）第 1 号につながった。


522

みられるようになった。しかし、2 つの概念の整理まで行われ、「内部管理統制」に対する理解の重要性を認識しつつも、

相変わらず外部監査の主眼は「内部会計統制」の理解にあるという基本姿勢がとられ続けてきた。 ②ウォーターゲート事件と海外不正支払防止法

1972 年 6 月 17 日、ワシントン DC のウォーターゲートビルにある民主党本部に盗聴器を仕掛

けようとした 5 人組が逮捕されたウォーターゲート事件が起きた。この事件をきっかけに、米国政府の違法な諜報活動が摘発され、国防総省の対ベトナム秘密文

書が明らかになるなど一連のスキャンダルが明るみに出され、この問題で共和党のニクソン大統

領は 1974 年辞任に追い込まれることとなった。しかし、この事件の影響はそれだけでは済まなかった。1973 年から 1976 年にかけて行われた

調査の結果、立法当局と監督機関は内部統制に対して大きな関心を払い始めた。と言うのも、ウ

ォーターゲート特別検査局および証券取引委員会が別個に調査を行った結果、米国を代表する数

多くの企業が、国内での違法な政治献金と、賄賂を含む疑わしい支出や違法な支出を外国の政府

高官に対して行っていたことが明らかになったからである。また、田中角栄元首相が逮捕されたロッキード事件が発覚する端緒ともなった。これを受けて議会では、公聴会が開催されるとともに法案が提出され、終的に 1977 年海外

不正支払防止法（Foreign Corrupt Practices Act of 1977、FCPA）が成立した。この FCPA は賄賂禁止規定に加えて、会計と内部統制に関する規定を置いている。具体的には、企業の経営者に対して、取引と企業資産の処分を正確・適正に反映する帳簿・記

録および勘定を作成・保存すること、およびこの目的を果たすのに十分な内部会計統制システム

を設計・維持することを求めている。 ③会計部門レベルから経営レベルへ

不正支払防止法（FCPA）制定の影響は広範囲にわたった。財務担当役員の横断的組織である財務担当経営者研究財団は、研究チームを組織して、米国企

業の内部統制の実情を調査して、内部統制の本質・目的・評価基準および有効な内部統制を達成

する方法などの提言を、1980 年にまとめている。アメリカ公認会計士協会は、企業の経営者は自社の内部統制システムの状況を説明した経営者

報告書を財務諸表に加えて提出すべきとする勧告書（コーエン委員会報告）を 1978 年公表し、

1979 年には内部統制特別諮問委員会を設置し、内部統制の確立および評価に関する指針を策定し

た。内部監査人協会も、内部監査人向けに内部統制の設定・維持・評価に関する指針を策定した。さらに、証券取引委員会は内部会計統制に関する経営者報告書の作成を義務付ける規則を提案

した。これは実業界からの反対でその後撤回されたが、企業は財務情報のみならず未監査情報に

対しても有効な内部統制システムを維持する責任があるとの認識を一層定着させた。このような状況から、多くの企業が内部監査部門の規模と能力を拡充し、自社の内部統制シス

テムに対して一層の注意を払うようになり、内部統制は会計部門の問題から経営レベルでの関心

事となっていった。


523

付録５：英国における 1990 年代のコーポレートガバナンス改革の経緯

①英国における金融不祥事件米国の COSO レポートと同様に、英国におけるコーポレートガバナンスのあり方に関する論議

が活発化したのは、1980 年代から 1990 年代のいくつかの企業不祥事が契機となった。じり貧を

余儀なくされていた英国経済の再生を目指してサッチャー政権は金融ビッグバン（大規模規制緩

和）を実施したが、いわばその副作用として金融システムにからむ不正事件・不祥事も多発した。新聞王であったマックスウェル氏の企業グループで年金資産が不正に流用されていたマックス

ウェル事件、ギネス社が買収先の株を自社株との交換で有利に買い取るため自社株の買い集めを

委託して株価を吊り上げたギネス事件、手数料目当てとされる保険会社の年金不正販売事件、

BCCI が詐欺的な資金調達と会計操作で大型破綻した BCCI 事件、シンガポールのトレーダーに

よる不正取引で生じた巨額損失による名門ベアリングズ銀行の破綻などである。このような不祥事の発生は、個性の強い経営トップの独走を他の経営陣が抑制できなかったこ

とや、企業財務における作為的な会計報告、内部統制が十分に機能していなかったことなどが背

景にあると言われている。 ②３つの委員会

このような企業不祥事による一連の企業の破綻を契機に、財務諸表はどういうルールで作られ

ているのか、監査人の役割は何なのか、取締役はどのように機能しているのかといったコーポレ

ートガバナンスの問題が指摘されるようになった。こうした事態を受け、コーポレートガバナンスの財務的側面、特に財務報告について検討する

ためにキャドベリー委員会（Cadbury Committee）が 1992 年 5 月に設置された。その通称は座

長を務めた Adrian Cadbury 卿（食品会社キャドベリー社会長）の名前に由来する。キャドベリ

ー委員会は 1992 年 12 月に報告書を公表した。このレポートの中では、財務報告を中心に、取締

役会の責任、監査人の役割、株主の権限と責任などについて規定している。 1990 年代半ばになると民営化の進展とともに、民営化された公益企業における取締役の報酬に

ついての論議が政治・マスコミを巻き込む論議に発展した。そこで英国の経済団体である CBI（Confederation of British Industries：日本の日本経団連に

相当する）は、Richard Greenbury 卿（流通会社マークス＆スペンサー社会長）を座長とするス

タディグループを設置し、取締役の報酬のあり方について検討を行い、1995 年 7 月に報告書を

公表した。さらに、1995 年 11 月に財務報告評議会は、Ronnie Hampel 卿を座長とする委員会を設置し、

前述の 2 つの委員会報告書の内容をより具体的・体系的に見直すこととした。そして 1998 年 1月、健全なコーポレートガバナンスへの取締役会の貢献、株主投資と資産の保全のための適切な

内部統制の維持などの視点を盛り込んだ終報告書を取りまとめた。これら 3 つの報告書を統合してまとめられたものが、財務報告評議会により 1998 年 6 月に公

表された「The Combined Code（統合規範）」である。50

50 【文献 4】「企業価値向上の条件: ターンバル・ガイダンス : イギリスに見る内部管理態勢ガイドライン」、


524

付録６：ターンバルガイダンスの内部統制に関する原則と条項

【原則】取締役会は株主投資と企業の資産を保全するため、健全な内部統制システムを維持す

べきである。【条項 1】取締役は、企業集団の内部統制システムの有効性について、少なくとも年 1 回レビ

ューを行い、レビューを行ったことを株主に報告すべきである。このレビューには、財務

（Financial）、業務（Operation）およびコンプライアンスにかかる統制およびリスクマネ

ジメントを含む、すべての内部統制を対象とすべきである。【条項 2】内部監査機能を持たない企業は、そうした機能の必要性について、折に触れてレビ

ューすべきである。51

付録７：COSO-ERM の考え方

・すべての事業体は、営利企業であるか政府機関であるかを問わず、そのステークホルダーに

対して、何らかの｢価値｣を提供する為に存在している。・「価値」は、戦略の設定から日々の業務運営に亘るすべての活動における経営陣の意思決定に

よって、創造され、維持され、又は失われてしまうものである。・すべての事業体は常に｢不確実性｣に直面しており、ステークホルダーの価値を高める努力を

するにあたり、事業体がどれだけの｢不確実性｣を受け入れられるのかを決定することが経営

陣の課題である。・｢不確実性｣とは、潜在的な事象の発生する可能性とそれによる結果・影響を正確に測定でき

ないことから生じるものであるが、価値を減少させるだけではなく増加させる可能性も持つ

という意味において、「リスク」と「事業機会(Opportunity)」という二面性を持っている。・COSO-ERM は、このような｢不確実性｣とそれに伴うリスクと機会に効果的に対処するフレ

ームワークを提供し、それによって「持続可能な価値を創造する能力」、および、「創造され

た価値をステークホルダーに伝達する能力」を向上させるものである。・COSO-ERM の導入により、経営陣は、企業のリスク選好度と戦略の適切な組み合わせ、リ

スク対応における意思決定の質の高度化、予期しない事象の発生や損失の低減、多重リスク

や企業全体にわたるリスクへの対応、事業機会の把握、資本配分の改定、といった分野の組

織能力を達成することができる。52

【文献 A8】「通商白書 1．イギリスコーポレート・ガバナンスの改革の背景と動向」 51 【文献 4】「企業価値向上の条件: ターンバル・ガイダンス : イギリスに見る内部管理態勢ガイドライン」P15 52 【文献 2】「全社的リスクマネジメント. フレームワーク篇」


525

付録８：COSO との対比

COSO フレームワークと COSO-ERM の構成要素を対比する形で示すと、次の図表 5-5-3 のと

おりである。図表 5-5-3 構成要素の対比

COSO フレームワークの構成要素 COSO-ERM の構成要素

①統制環境（Control Environment） ①内部環境（Internal Environment）

－ ②目標設定（Objective Setting）

③事象の特定（Event Identification）

④リスク評価（Risk Assessment） ②リスクの評価（Risk Assessment）

⑤リスク対応（Risk Response）

③統制活動（Control Activities） ⑥統制活動（Control Activities）

④情報と伝達

（Information and Communication）

⑦情報と伝達

（Information and Communication）

⑤モニタリング（Monitoring） ⑧モニタリング（Monitoring)

COSO フレームワークの構成要素との違いが 3 点ある。・「統制環境」が「内部環境」という表現に修正されている・「目標設定」という構成要素が新設された・「リスクの評価」が「事象の特定」「リスク評価」「リスク対応」に細分化された

付録９：COBIT の各項目の解説

①主要成功要因・・・CSF (critical success factors)

IT プロセスのコントロールを達成するためのも重要な事項あるいは行動を表している。CSFはマネジメント指向の導入ガイドラインであるとともに、戦略面、技術面、組織面、あるいは手

続の面でも重要な事項である。

②重要目標達成指標・・・KGI（key goal indicator） IT プロセスがその業務要件を達成したかどうかを事後的に経営者に示す評価尺度を定める。通

常、次のような用語を用いて表される。・ビジネスニーズを支援するために必要な情報の可用性・インテグリティの欠如および機密性に関するリスク・プロセスとオペレーションのコスト・効率性・信頼性、有効性および遵守性の確認


526

③重要業績評価指標・・・KPI（key performance indicator）事業の目標を達成できるように、IT プロセスがいかに有効に機能しているかを評価するための

評価尺度を定める。事業の目標が達成される可能性があるかないかを示す先行指標であるととも

に、能力、手続およびスキルに関する指標でもある。 KGI が何を達成するかに焦点合わせているのに対し、KPI は如何に達成するかに重点を置いて

いる。 KPI によって IT プロセスが目標達成に向けてどの程度良好に機能しているかを判断しながら、

継続的にモニタリングと対応をしていくことで、IT プロセスを改善するチャンスが生まれる。

④成熟度モデル企業の IT プロセスのコントロールレベルを、各 IT プロセスに記述された内容に即してスコア

リングすることで、自社の組織のレベルを測ることができるモデルである。コントロールレベルは、以下の 6 段階。 0：不在（Non-Existent）：管理プロセスは全くない 1：初期（Initial）：管理プロセスは場当たり的で組織的ではない 2：反復（Repeatable）：管理プロセスが標準的なパターンに従うようになる 3：定義（Defined）：管理プロセスは文書化され、周知されている 4：管理（Managed）：管理プロセスはモニタリングされ、評価測定されている 5：適化（Optimized）：管理プロセスは、ベストプラクティスに従っており、また自動化さ

れている成熟度モデルで、何を比較するのかということについて、ガイドラインは以下の 4 つを挙げて

いる。・組織の現在のポジション・業界の中の優秀企業との比較・国際基準との追加比較・改善に関して戦略として組織が目指すポジション

⑤4 つの領域（ドメイン）と 34 の IT プロセス COBIT が定義する IT プロセスは、4 つのドメインに計 34 ある。


527

付録 10：金融庁検査マニュアルのできるまで

ａ．検査マニュアル策定に至る海外の動き・大和銀行 NY 支店の巨額損失事件

巨大な預金量、健全な財務体質、当局主導の護送船団方式などを背景に海外事業を展開し、1990年代初頭までオーバープレゼンスとまで言われた邦銀の黄金時代も 1990 年代半ばには終焉し、

バブルの崩壊とともに格付けも急降下し、邦銀が海外で資金調達しようとすると上乗せ金利を払

わなければならない状況になった。このように邦銀への海外金融市場での信頼が低下している中

で、1995 年 9 月に大和銀行 NY 支店の巨額損失事件が発覚した。銀行のトレーダーが 1,100 億

円にも及ぶ損失を 9 年間も隠し続けていたという事件は、米国における邦銀全体に対する不信を

決定付けた。米国の GAO（General Accounting Office、会計監査院）は下院からの要請を受け在米外銀の

調査を開始し、2 年におよぶ調査の末 1997 年 9 月にレポートを公表した。このレポートでは、「内部統制と監査が全然できていない」という在米外銀（なかんずく邦銀）

の深刻な弱点を指摘した内容となっている。・BIS（国際決済銀行）の動き

邦銀の内部管理に危機感を覚えた米国の金融当局は、BIS に対して働き掛けを始めた。そして

バーゼル銀行監督委員会の大規模な組織替えを行い、その下にリスク管理小委員会を創設して、

インターナルコントロールを焦点とするケーススタディーを実施した。その初の対象となった

のが大和銀行であった。このようなケーススタディーを重ねていく中で、不祥事の発生原因が内

部管理の欠陥にあることが明らかになり、全世界の銀行にインターナルコントロールを義務づけ

ようという動きにつながった。その結果として出てきたのが 1998 年 9 月に終公表された「銀

行組織における内部管理体制のフレームワーク」である。ｂ．検査マニュアル策定に至る国内の動き・ブラック・ノーベンバー

日本の金融機関の経営破綻は阪神大震災のあった 1995 年に始まる。金融機関の経営破綻が表

面化し、そのクライマックスがブラック・ノーベンバーと呼ばれる 1997 年 11 月である。まず

11/3 に三洋証券が会社更生法を申請、11/17 に北海道拓殖銀行に営業譲渡を発表、11/24 に山一

證券が自主廃業を決定、11/26 に德陽シティ銀行が自主廃業を決定した。こうした一連の事件は日本の金融当局は絶対に金融機関を破綻させないという海外金融当局の

想定を崩壊させた。さらに日本の金融当局による銀行の保有株式に対する会計基準の緩和（低価

法から原価法への変更を認めた）は「nationally organized cover-up（国家による組織的な隠蔽

工作）」との非難を浴びた。さらに 1998 年 1 月、金融当局における接待スキャンダルの発覚が日本の金融当局に対する海

外の金融当局の不信を決定付けた。


528

・金融行政の転換このように銀行・金融当局への国内外の不信が高まる中で、大蔵省は 1998 年 3 月に「新しい

金融検査に関する基本事項について」を発出する。『こうした環境変化に的確に対応してゆくためには、自己責任原則の徹底と市場規律とを基軸

に、明確なルールを前提とした透明性の高い行政に転換することが必要不可欠である。』として、

事後的実態把握を中核とする行政に転換することになる。さらに、『近の一連の不祥事により大きく損なわれた金融検査・監督に対する信頼を一刻も早

く回復するためにも、真に厳正で実効性ある金融検査を早急に確立し、実施することが急務であ

る。』として「新検査方式」の導入を行った。金融機関が自己責任に基づいて経営し、当局はこれを促進・検証する役割を担う方式への転換

が図られた訳で、1998 年６月には、現在の金融庁の前身である金融監督庁が発足した。53

付録 11：検査マニュアルの構成

検査マニュアルは、「内部管理態勢」、「法令等遵守態勢」、「各リスク毎の管理態勢」という構成

になっている。さらに、「内部管理態勢」の部分は、トップに「取締役及び取締役会の役割」を掲げて、以下の

5 つに細分化されている。すなわち、「経営全般」「法令等遵守」「リスク管理」「内部監査」「取締

役会等議事録」である。検査マニュアルにおいて、管理者とは、管理部門の上級管理職だけに限らず、営業拠点長と同

等以上の職責を負う上級管理職（取締役を含む）をいうことで、広く定義している。改訂前は、

7 つの役割を挙げていたが、基本的なところは削って、改訂後は以下の 2 つに集約している。・管理者は、法令等遵守の重要性、リスクの所在や種類及び管理手法を十分に理解した上で管

理方針に沿って、その種類に応じたモニタリングを行うなど適切な管理を実行しているか。・管理者は、取締役会等で定められた方針に基づき、相互牽制機能を発揮させるための施策を

実施しているか。

53 【文献 7】「新しい金融検査の影響と対策/変貌する銀行経営と企業財務の革新」


529

付録 12：金融検査指摘事例集

①障害対策・開発管理

・顧客に重大な影響を与える障害の発生状況や処理結果が経営陣へ報告されていない。・顧客に影響を及ぼすシステム障害が多数発生しているが、事後対応が中心で、リスク管理委

員会や経営陣は、障害発生の傾向分析や抜本的な改善策の検討を指示していない。・度重なるシステム障害が発生しているにもかかわらず、危機管理マニュアルの見直しを行っ

ていない。・外部と電子メールを送受信するシステムを情報資産の洗出しの対象としていない。・稼動後に導入したシステムについて、リスクの把握が行われていない。・ユーザーテストの時点で不備が発覚したシステムを、承認体制が不明確なままリリースした

結果、正規の処理が行われず、重大な事故を惹起している。・経営陣に、システム開発の進捗状況について報告が行われていない。

②リスク管理のための規定の整備・各種リスクに係る管理規程が整備されていない。・取締役会等に対する付議事項等が明確に定められていないことなどから、子会社等に係る重

要な事項について報告等が行われていない。・子会社等に係るリスクを管理する規程が整備されていない。

③情報セキュリティ管理（含むアクセス管理）・委託先におけるセキュリティ管理状況を把握しておらず、重要情報が流出している。・重要システムのサーバー設置場所への入室権限を職務の実態で必要のない者に与えている。・入退室の暗証番号の定期的な変更の規定がなく、長期間に亘って変更されていない。・退職者の職員 ID 及びパスワードを不正に使用して、社内システムヘアクセスしている。・外部委託業者が規定に反し、障害発生等の緊急時以外においても、事前の了解を得ることな

く、システムヘアクセスしている。・外部から持ち込まれた媒体によって、社内 PC にウイルスが発見される事件が連続して発生

しても、媒体の持込を防止する改善策の検討や営業店への指導を行っていない。

④個人情報の管理態勢・個人情報保護に係る委員会では、規程整備の検討が中心となっており、不備事項が報告され

ているにもかかわらず、問題点の対応策を検討していない。・個人情報の管理方法に関する各部店への周知徴底が十分に図られていないことから、内部規

定に反している事例が認められる。・法律の施行での対応について、各部署が担当業務につき各々洗出しを行うだけで、関係部署

間の連携が不十分なため、組織全体での検討事項等の洗出しが行われていない。・個人情報を保護するためのコンピュータシステムに係る技術的安全管理措置を講じるに当た

り、進捗管理を行っておらず、対応状況等を経営陣に報告していない。


530

・顧客情報の漏洩事故（FAX による誤送信等）について、統括部署に対する報告が行われてい

ない。顧客に対する説明等も行われていない。・一部の記録媒体の管理を行っていないことから、個人情報の紛失の有無が確認できない。

⑤災害時等におけるバックアップ体制等・センター被災時の基幹システムの代替策が策定されていない。・システム復旧後のバックアップデータの反映方法や、バックアップデータの搬出前に障害が

発生した場合のデータの復元方法について、対応策が十分に整備されていない。・システムのバックアップが隔地保管されていない。

⑥外部委託管理・規定で具体的な委託管理項目や評価項目等を定めていないことから、コンピュータ稼動環境

の整備や機器の保守点検などに係る評価等が十分に行われていない。以上が、指摘事項の具体例である。特別なことと言うよりも、法令や自社の規定で定めたことを忠実に実行できているかという点

が挙げられていることが読み取れる。54

付録 13：大和銀行事件の判決（抜粋）

『大和銀行株主代表訴訟事件・大阪地裁判決において、「健全な会社経営を行うためには‥

（中略）・・リスク管理が欠かせず、会社が営む事業の規模、特性等に応じたリスク管理体制（い

わゆる内部統制システム）を整備することを要する。‥（中略）・・会社経営の根幹にかかかるリ

スク管理体制の大綱については、取締役会で決定することを要し、業務執行を担当する代表取締

役及び業務担当取締役は、大綱を踏まえ、担当する部門におけるリスク管理体制を具体的に決定

する職務を負う。この意味において、取締役は、取締役会の構成委員として、また、代表取締役

又は業務担当取締役として、リスク管理体制を構築すべき義務を負い、さらに、代表取締役及び

業務担当取締役がリスク管理体制を構築すべき義務を履行しているか否かを監視する義務を負う

のであり、これもまた、取締役としての善管注意義務及び忠実義務の内容をなす‥（中略）・・。

監査役は、商法特例法 22 条 1 項の適用を受ける子会社を除き、‥（中略）・・取締役がリスク管

理体制の整備を行っているか否かを監査すべき職務を負〔い〕‥（中略）・・これもまた、監査役

としての善管注意義務の内容をなす・・（中略）‥また、どのような内容のリスク管理体制を整

備すべきかは経営判断の問題であり、会社経営の専門家である取締役に、広い裁量が与えられて

いる‥（中略）‥。』55

54 【文献 A4】「金融検査指摘事例集」 55 【文献 A2】「コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて」P51


531

付録 14：会社法が定める内部統制

「すべての大会社、かつ、監査役設置会社は、内部統制システムの構築の基本方針として、会

社法施行後初に開催される取締役会までに、会社法 362 条 4 項 6 号並びに会社法施行規則 100条 1 項及び 3 項に記載された事項の取締役会決議を行わなければならない。」

・会社法第 362 条 4 項 6 号（取締役会の権限等）

『取締役の職務の執行が法令及び定款に適合することを確保するための体制その他株式会社の

業務の適正を確保するために必要なものとして法務省令で定める体制の整備』・会社法施行規則第 100 条（業務の適正を確保するための体制）

『法第 362 条第 4 項第 6 号に規定する法務省令で定める体制は、次に掲げる体制とする。一取締役の職務の執行に係る情報の保存及び管理に関する体制二損失の危険の管理に関する規程その他の体制三取締役の職務の執行が効率的に行われることを確保するための体制四使用人の職務の執行が法令及び定款に適合することを確保するための体制五当該株式会社並びにその親会社及び子会社から成る企業集団における業務の適正を確保す

るための体制

詳細な項目が記載されていないが、例えば、社団法人日本監査役協会ホームページの電子図書

館で、プロセスチェックの着眼点を挙げている。56

その着眼点のリストの前文に以下の記述がある。『②内部統制システムは、自社の規模、事業の性質、機関の設計、その他の個性や特質に応じ

た、過不足のない必要、かつ、適な水準で構築・整備する必要があること。 ③内部統制システムは、構築することが目的ではなく、内部統制システムの目的を達成し得る

ものでなければならないことは当然である。内部統制システムの決議内容が、形式的に諸要件を

具備するだけでは不十分であり、現実的に有効に機能し得るかという観点から検証する必要があ

ること。』

付録 15：経済産業省「リスク新時代の内部統制」の背景

・環境問題の深刻化、消費者意識の向上、事業の国際化等により、企業の社会的責任は増大し

ており、広範なステークホルダーに対する企業責任を果たさない場合の社会からのペナルテ

ィというかたちでのリスクが増大してきている。・規制緩和が進み、自己責任に基づく事後規制へと社会的枠組みが変わっていく中で、企業が

それぞれの責任と判断で様々なリスクを管理し収益を上げていくことが必要となってきてい

る。・雇用の流動化や企業再編の進展等により、従業員等、当事者間の暗黙の了解や信頼関係のみ

に依存した経営管理のあり方に限界が生じてきている。・消費者や投資家等のステークホルダーも、企業の信頼性についての明確な説明を求めるよう

になってきており、企業の取組が不十分な場合、消費者や金融市場からの厳しいペナルティ

56 【文献 A6】「会社法及び法務省令に対する監査役の実務対応」別紙 P9


532

を受け、ブランド価値の崩壊、あるいは、はなはだしきは破綻につながる事例も見られる。・企業を取り巻く状況の変化の中で、企業として、社会的責任を果たしつつ、事業を取り巻く

リスクを管理して収益を上げていくために、内部統制の適切な構築・運用に積極的に取り組

むことが一層重要となってきている。・従業員と経営者との高いレベルでの情報共有や意志疎通等、我が国企業の良い点は残しつつ

も、一連の企業不祥事等で明らかになった弱点に対処するために企業として取り組むべき事

項について指針を策定する。

付録 16「リスク新時代の内部統制」の指針の概要

・リスクに対応した内部統制の構築・運営

経営者は、企業価値に影響を及ぼすリスクに対応して内部統制を構築するとともに、常にリス

クの変化を敏感に察知して適時適切に対処し、併せて内部統制をダイナミックに見直すことが必

要である。

・健全な内部統制環境の構築・運営企業が健全な事業活動を遂行するためには、経営者が、法令のみならず社会通念等とも整合し

たかたちで行動規範を明確に打ち出し、自らが率先垂範するとともに、従業員一人一人がこれを

強く認識し行動することが必要である。具体的には、適切な業績評価の仕組みの確保、従業員教

育の徹底、職務権限と責任の明確化、社内における明確な相互牽制機能の維持などが必要である。

・円滑な情報伝達の構築・運営企業が事業活動を効率的かつ効果的に遂行するためには、情報の識別、収集、処理及び伝達が

円滑に行われることが不可欠である。情報伝達に関しては、社内だけでなく、顧客の意見や苦情

等、外部からの情報の入手と活用のための体制や通常の業務報告経路とは別の報告経路（ヘルプ

ライン等）を確立することが必要である。さらに、企業価値に大きな影響を与える事象発生時等

に、被害の限定や復旧に向けて必要な対処を行うとともに、社外への迅速な情報発信等を行うた

め、考えられるケースについて対応方針を事前に明確にしておくこと（危機管理）も必要である。

・業務執行部門におけるコントロールとモニタリングの構築・運営リスクマネジメントによって識別されたリスクに則して経営管理・業務管理・業務執行の体制

や規則（手続き、マニュアル等）が定められ、かつ、定期的に、又は企業環境・組織再編・企業

戦略の変更・重大事象の発生などに対応して、リスクの再識別・再評価ができる仕組みが構築さ

れ、それに基づき、体制や規則等について見直しが行われることが必要である。


533

・業務執行部門から独立したモニタリング（内部監査）の確立経営者、管理者が適切な事業活動の遂行や有効な内部統制の運用を確かめることを支援するた

めには、通常の業務執行部門とは独立した専門性を有する内部監査機能が存在し、組織横断的に

内部監査を実施することが必要である。また、内部監査等により指摘された統制上の問題に関する業務プロセスの改善やフォローアッ

プの手続を明確にし、問題点を放置しないことが必要である。さらに、ガバナンスが適切に機能することを支援するため、内部監査部門には、必要に応じて

監査役（又は監査委員会）及び外部監査人と、問題点等について協議することが期待される。57

付録 17：ITIL を参考にしたチェックポイント

・運用業務の網羅性は満たされているか・運用業務を実施するプロセスは明らかになっているか・各プロセスの目的は明確になっているか・各プロセスは妥当なものか・評価できる指標は明確か・適切に指標の管理・評価ができているか・ドキュメントは整備されているか・プロセスは全員に周知徹底されているか・プロセスは遵守されているか・指標は達成できているか（正確性・効率性）・検討すべき何らかの予兆はないか・プロセスは現状に即しているか。必要な変更は行われているか・適切な改善が行われているか

付録 18：月例レポートの目次

ａ．リスクベースレポート（月例）の目次サービス品質に係わるリスク

・トラブル発生状況・SLA 達成状況・移管・変更管理状況

サービス継続性に係わるリスク・性能管理状況・有事テスト状況・ネットワークセキュリティ管理状況

57 【文献 A1】「リスク新時代の内部統制リスクマネジメントと一体となって機能する内部設計の指針」


534

セキュリティに係わるリスク・センターにおけるセキュリティリスク・外部委託先におけるセキュリティリスク・社内拠点おけるセキュリティリスク

システム運用に係わる案件の取り組み・運用サービスの継続的な提供に向けて・セキュリティリスク管理体制の強化・確立に向けて

ｂ．パフォーマンスレポート（月例）の目次

以下のシステム運用の業務プロセスごとに、各プロセス固有のパフォーマンス評価項目も含め

て、まとめている。・サービスレベル管理・トラブル管理・移管管理・変更管理・稼働管理・性能管理・継続性管理・セキュリティ管理・アウトソーシング管理・予算管理・設備管理・資産管理

付録 19：自主点検マニュアルの記載事項

自主点検のマニュアルは、例えば、以下の目次に沿って記載する。

・自主点検とは自主点検の意義・目的、自主点検マニュアルの位置づけ

・自主点検計画書の作成基本計画書の作成、個別計画書の作成

・点検実施点検準備、予備調査の実施、本調査の実施、評価・結論の実施

・点検報告点検報告書の作成、フォローアップ、年次点検計画書の作成

・点検資料の整理・管理

i

◆ ＪＵＡＳ資料一覧 ◆

■概要 JUAS の資料については、引用にあたり、読まれる方々の煩瑣を避けるために、ゴシックの部分を略

記に用いた。（例）IT 動向調査 2006、IT コストマネジメント研究プロジェクト 2004

＜調査報告書＞

・企業 IT 動向調査報告書 2006 年版（2006 年発行）

・企業 IT 動向調査報告書 2005 年版（2005 年 4 月発行）

・ユーザ企業 IT 動向調査報告書 2004 年版（2004 年 4 月発行）

・ユーザ企業 IT 動向調査報告書 2003 年版（2003 年 4 月発行）

・ユーザ企業向けソフトウェアメトリックス調査報告書 2005年版（2005 年 4 月発行）

「～システム開発・保守の実績プロジェクトデータを元に分析～」

・ユーザ企業向けソフトウェアメトリックス調査報告書 2005年版（2005 年 4 月発行）

「システム開発における品質・工期・生産性について－実績データを元に分析－」

・国内 CIO 実態調査報告書 2006 年版（2006 年 3 月発行）

＜IT ガバナンス研究プロジェクト報告書＞

・「IT ガバナンスに関する研究－その３ガバナンスレベル測定手法の考察－」（2004 年 4 月発行）

IT ガバナンス研究（2003 年度）

・IT ガバナンスに関する研究～その２ガバナンスレベル測定手法の開発と適用（2003 年 4 月発行）


・IT ガバナンスに関する研究～その１ガバナンスレベル測定手法の開発と適用（2002 年 4 月発行）


ii

＜研究部会報告書＞

・2004 年度研究部会活動報告書（3 研究部会合冊）（2005 年 4 月発行）

「経営における IT の戦略的活用の研究」IT 戦略研究会

「IT 部門に求められる人材像とその育成」情報化人材育成研究会

「個人情報保護法対策の苦悩」企業情報マネジメント研究会

・2003 年度研究部会活動報告書（4 研究部会合冊）（2004 年 4 月発行）

「企業経営における IT の戦略的活用」IT 戦略研究部会

「アウトソーシング後のユーザ企業 IT 部門に求められる人材像とその育成」情報化人材育成研究部会

「セキュリティポリシーの定着化に向けて－課題と解決のヒント集－」セキュリティ研究部会

「ユビキタス社会を支える商品トレーサビリティの現状と課題」商品トレーサビリティ研究部会

・経営における IT の戦略的応用の研究（2003 年 4 月発行）

IT 戦略研究部会（2002年度）

・日本企業に最適なナレッジマネジメントの実践的活用の研究（2003 年 4 月発行）

ナレッジマネジメント研究部会（2002年度）

・ＪＵＡＳが作るセキュリティポリシー－国際規格に準拠したセキュリティ管理汎用規定集－

（2003 年 4 月発行）セキュリティ研究部会（2002年度）

・企業内情報システムアウトソーシングのあり方の研究（2003 年 4 月発行）

アウトソーシング研究部会（2002 年度）

・情報化人材育成事例および WBT（ｅ-ラーニング）活用事例の調査・研究（2003 年 4 月発行）

情報化人材育成研究部会（2002 年度）

・インターネット技術の先進的活用ネットワークの研究（2003 年 4 月発行）

ネットワーク研究部会（2002 年度）

・ブロードバンドの企業における活用形態研究

ブロードバンド活用研究部会（関西）（2002 年度）

・ソフトウェアの品質向上についての検討

ソフトウェア品質向上研究部会（関西）（2002 年度）

・IT コンサルティングの実践に向けて

IT コンサルティング研究部会（関西）（2002 年度）

・経営における IT の戦略的対応用の研究（2002 年 4 月発行）


・経営に役立つナレッジマネジメントの活用（2002 年 4 月発行）


・情報セキュリティ管理の導入とリスク管理（2002 年 4 月発行）

セキュリティ研究部会（2001 年度）

・サプライチェーンマネジメントの導入事例とその考察（2002 年 4 月発行）

ビジネス連鎖研究部会（2001 年度）

iii

・IT 投資の評価手法の研究（2002 年 4 月発行）

IT 投資研究部会（2001年度）

・SI に求められる評価項目（2002 年 4 月発行）

システムインテグレータ評価手法研究部会（2001年度）

・ナレッジ・マネジメントに対する考察

関西・ナレッジマネジメント推進研究部会（2001年度）

・BtoB ビジネスの動向

関西・BtoB ビジネス研究部会（2001年度）

・情報セキュリティ管理

関西・情報セキュリティ研究部会（2001 年度）

・IT コンサルティングの現状と今後の課題

関西・IT コンサルティング研究部会（2001 年度）

・経営における IT（情報技術）の戦略的応用の研究（2001 年 4 月発行）


・ナレッジ・マネージメントの実証的研究（2001 年 4 月発行）


・セキュリティ・ポリシーの作成（2001 年 4 月発行）

セキュリティ研究部会（2000 年度）

・ビジネスモデル特許などネットビジネスの光と影の研究（2001 年 4 月発行）

ネットビジネス研究部会（2000 年度）

・ＡＳＰの動向とユーザー企業におけるメリットの研究（2001 年 4 月発行）

ASP 研究部会（2000年度）

・ナレッジマネージメントの現状と課題

関西・ナレッジマネジメント推進研究部会（2000年度）

・Ｅ－ビジネスの現状と今後の考察

関西・Eビジネス研究部会（2000 年度）

・情報セキュリティーポリシーの構築に向けて

関西・情報セキュリティ研究部会（2000 年度）

iv

＜研究プロジェクト報告書＞・「ユーザーのためのビジネスオブジェクト活用ガイドライン」（2005 年 4 月発行）

ビジネスオブジェクト検討プロジェクト（2004 年度）

・「エンドユーザによるビジネスシステム記述方法とリファレンスモデル」（2005 年 4 月発行）

ビジネスシステム定義研究プロジェクト（2004 年度）

・「IT コスト評価インデックスと IT コストベンチマーキング」（2005 年 4 月発行）

IT 投資＆コストマネジメント研究プロジェクト（2004 年度）

・「業務ソフトウェアのユーザビリティ基礎的分析」（2005 年 4 月発行）

ユーザビリティ研究プロジェクト（2004 年度）

・「これからの IT 投資を考えるユーザのために」（2004 年 4 月発行）

ビジネスオブジェクト研究プロジェクト（2003 年度）

・「IT ガバナンスに関する研究－その３ガバナンスレベル測定手法の考察－」（2004 年 4 月発行）

IT ガバナンス研究プロジェクト（2003 年度）

・「エンドユーザーによるビジネスシステム定義の進め方－業務システム構築見積照会書の作成と調達－」

（2004 年 4 月発行）ビジネスシステム定義研究プロジェクト（2003 年度）

・「先進諸国との対比における IT 投資/IT コストダウンと IT コストマネジメント」（2004 年 4 月発行）IT

コストマネジメント研究プロジェクト（2003 年度）

・欧州主要国（独・仏・英）における個人情報保護制度に関する研究（2004 年 4 月発行）（2003 年度）

・ユーザが考えるビジネスオブジェクト調査報告書（2003 年 4 月発行）

ビジネスオブジェクト研究プロジェクト（2002 年度）

・情報システムのユーザー満足度プロジェクト（2003 年 4 月発行）

ユーザー満足度研究プロジェクト（2002 年度）

・「アーキテクチャ設計・ＡＴＡＭ」

企画・運営：株式会社ライフプレナー・グループ・ジャパン（2002 年 8 月）

・「ＡＤＤ／属性中心アーキテクチャ設計法」

企画・運営：株式会社ライフプレナー・グループ・ジャパン（2004 年 2 月）

v

◆ 参考資料その他 ◆

＜第２章第２節＞

1 ：「 The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of

Innovation」Ikujiro Nonaka、Hirotaka Takeuchi 著、1995 年 5 月、Oxford University Press、$37.00

２：「ワーキング・ナレッジ―「知」を活かす経営」トーマス・H.ダベンポート、ローレンス・プルサッ

ク著、梅本勝博訳、2000 年 12 月、生産性出版、2,940 円（税込み)

３：「スマート・カンパニー―e ビジネス時代の覇者の条件」ヘイム・メンデルソン、ヨハネス・ジーグ

ラー著、校条浩訳、2000 年 4 月、ダイヤモンド社、2,520 円（税込み)

＜第２章第３節＞

1：「この情報共有が利益につながる―経営課題に適した 4 つの実践アプローチ」リアルコム株式会社著、

吉田健一監修、2004 年 11 月、ダイヤモンド社、2,100 円（税込み）

＜第３章第１節＞

1：「要求を仕様化する技術・表現する技術」

清水吉男著、2005 年 10 月、技術評論社、2,709 円（税込み）

２：「情報サービス産業における受注ソフトウェア開発の技術的課題に関するアンケート調査」報告書

2004 年 2 月、JISA 技術・通信委員会

＜第３章第２節＞

1：「要求を仕様化する技術・表現する技術」

清水吉男著、2005 年 10 月、技術評論社、2,709 円（税込み）

＜第３章第３節＞

1：「コンピューターは、むずかしすぎて使えない！」

アラン・クーパー著、山形浩生翻訳、2000 年 2 月、翔泳社、2,310 円（税込み）

２：「シナリオに基づく設計―ソフトウェア開発プロジェクト成功の秘訣」

ジョン・M. キャロル著、郷健太郎翻訳、2003 年 10 月、共立出版、4,095 円（税込み）

３：「ペーパープロトタイピング最適なユーザインタフェースを効率よくデザインする」

Carolyn Snyder 著、黒須正明監訳、2004 年 6 月、オーム社、3,360 円（税込み）

４：「ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン」

ヤコブニールセン著、篠原稔和監訳、三好かおる翻訳、2002 年 7 月、東京電機大学出版局、

3,885 円（税込み）

５：「ユーザビリティエンジニアリング―ユーザー調査とユーザビリティ評価実践テクニック」樽本徹也

著、2005 年 10 月、オーム社、2,625 円（税込み）

６：「Web 戦略としての「ユーザーエクスペリエンス」」ジェシー・ジェームス・ギャレット著、ソシオ

メディア株式会社翻訳、2005 年 2 月、毎日コミュニケーションズ、2,415 円（税込み）

vi

＜第４章第 1節＞

１：「システム監査基準」経済産業省、2004 年 10 月

２：「システム管理基準」経済産業省、2004 年 10 月

３：「情報システム監査基準」経済産業省、2003 年 4 月

４：「情報システム管理基準」経済産業省、2003 年 4 月

５：「地方公共団体情報セキュリティ監査実施手順」総務省、2003 年 12 月

６：「金融機関等のシステム監査指針」FISC、2000 年 7 月

７：「平成 16 年システム監査普及状況調査」JIPDEC、2005 年 3 月

８：「平成 18 年度金融情報システム白書」（財）金融情報システムセンター編、2005 年 12 月、財経詳

報社、4,410 円（税込み）

９：「情報システム監査実践マニュアル」NPO 日本システム監査人協会編、2005 年 11 月、工業調査会

刊、5,040 円（税込み）

10：「システム監査・情報セキュリティ監査ハンドブック」㈱ティエムエス編、2004 年 11 月、秀和シス

テム、5,040 円（税込み）

11：「システム監査と内部統制の実務」中央青山監査法人編、2006 年 3 月、税務経理協会刊、2,100 円（税

込み）

12：「IT 統制と監査の実務 Q&A」あずさ監査法人 IT 監査部編、2006 年 6 月、中央経済社刊、2,940 円

（税込み）

13：「IT 統制とシステム監査の意義と枠組み」島田祐次、2006 年 6 月、「日本セキュリティ・マネジメン

ト学会第 20 回全国大会発表要旨」から

14：「金融のシステム監査指針、7 年ぶり改訂へ」日経コンピュータ 2006 年 8 月 7 日号

＜第４章第２節＞

１：「事業継続マネージメント入門」、SEMI 日本地区 BCM 研究会編、2005 年 1 月、共立出版 1,890 円

（税込み）

２：「コンピュータシステム災害復旧の対策」谷井成吉著、2006 年 9 月、ダイヤモンド社、2,100 円（税

込み）

３：「ITIL 大全」、日経コンピュータ編、2004 年 12 月、日経 BP 社、8,000 円（税込み）

４：「IBM の危機管理」、内外コミュニケーション研究会編、亀岡太郎監修、2001 年 11 月、早稲田出版、

1,785 円（税込み）

５：「ストレージ・マネジメント」、ストレージ・マネジメント研究会著、喜連川優監修、2001 年 2 月、

日経 BP 企画、1,680 円（税込み）

６：「月刊 CIO Magazine 2006 年 10 月号 Vol77」ディザスタ・リカバリの真実 IDG ジャパン

７：「ITIL による運用管理の実際」山路幹夫・石坂浩之・武内真弓著、2006 年 8 月、ソフトリサーチセ

ンター、1,890 円（税込み）

vii

＜第５章＞

１：「システムリスクに挑む : 金融検査マニュアルを超える実践ガイド」

先端リスク研究会著（小俣龍、川島尚史、松尾明、前田信男、根川忠道、片岡学、遠藤誠、木村章展、

著者の共著）、金融財政事情研究会、2003 年 1 月

２：「全社的リスクマネジメント. フレームワーク篇」（原題：Enterprise risk management. (Executive

summary framework） COSO 著、八田進二監訳、中央青山監査法人訳、東洋経済新報社、2006 年

3 月※同書の翻訳権は PwC が所有、日本語版は中央青山監査法人が翻訳している。

３：「リスクとつきあう : 危険な時代のコミュニケーション」吉川肇子著、有斐閣、2000 年 3 月

４：「企業価値向上の条件: ターンバル・ガイダンス : イギリスに見る内部管理態勢ガイドライン」、

KPMG 著、KPMG ビジネスアシュアランス株式会社訳、八田進二監訳、白桃書房、2002 年 4 月※原

タイトル: The KPMG review,internal control

５：「実務で役立つプロジェクトレビュー : システム開発プロセスを「見える化」する」、菊島靖弘著、

翔泳社、2006 年 2 月

６：「企業における内部統制について：産業合理化審議会答申」

通商産業省通商企業局編、通商産業調査会、1951 年

７：「新しい金融検査の影響と対策/変貌する銀行経営と企業財務の革新」

木村剛著、TKC 出版、1999 年 5 月

８：「企業価値向上のためのコーポレートガバナンス」

KPMG ビジネスアシュアランス／吉川吉衞編、東洋経済新報社、2003 年 5 月

９：「企業のリスクマネジメント」

青井倫一、竹谷仁宏編著、慶應義塾大学出版会、2005 年 10 月

10：「ウェルチが日本を変える」長谷川洋三著、講談社、2000 年 1 月

11：「2006 年版 JIS ハンドブック 58-4 リスクマネジメント」日本規格協会、2006 年 1 月

12：「損害保険研究第 68 巻第 2 号」「（２）損害保険事業と内部統制（その 1）」、中村純也、2006 年 8 月

※（その 2）が 2006 年 11 月に発行予定

13：「平成 17 年度企業情報マネジメント研究会報告書」社団法人日本情報システム・ユーザー協会

遠藤誠氏講演資料より

14：「米国企業改革法のインパクトとｅ文書法施行の意味」

2005 年 4 月 26 日東京大学国際・産学協同研究センター情報・通信セキュリティプロジェクト

弁護士六川浩明氏の講演資料

15：「日本版内部統制報告実務の最新動向（EA フォーラム 2005 Winter）」

2005 年 12 月に開催された八田進二青山学院大学大学院教授、企業会計審議会・内部統制部会部会長

の講演資料

viii

◎インターネットで入手可能な情報 A1：リスク新時代の内部統制リスクマネジメントと一体となって機能する内部設計の指針リスク管

理・内部統制に関する研究会、2003 年 6 月【PDF】

www.meti.go.jp/kohosys/press/0004205/1/030627risk-hokokusyo.pdf A2：コーポレートガバナンス及びリスク管理・内部統制に関する開示・評価の枠組みについて

―構築及び開示のための指針― 2005 年 8 月【PDF】

http://www.meti.go.jp/report/data/g60605aj.html A3：新しい保険検査マニュアルと総合的な管理指針

http://www.fsa.go.jp/manual/manualj/hoken.pdf http://www.fsa.go.jp/common/law/guide/ins.pdf

A4：金融検査指摘事例集

http://www.fsa.go.jp/news/18/20060705-1.html（11～20、39～43、53 ページ）

A5：金融庁企業会計審議会議事録

http://www.fsa.go.jp/singi/singi_kigyou/top.html 内部統制を巡る様々な立場・観点からの論議を通して課題がわかる。

提出された資料も参考になる。

A6：日本監査役協会電子図書館

「会社法及び法務省令に対する監査役の実務対応―施行に向けた準備対応及び 6 月総会への準備対応

を中心として―」

http://www.kansa.or.jp/PDF/el001_060317a.pdf 別紙「内部統制システムに関する監査役の当面の実務対応」 2006 年３月 9 日（監査法規委員会

内部統制部会）

http://www.kansa.or.jp/PDF/el001_060317b.pdf A7：日本 IBM 社の HP から（Building an Edge 欧米金融 IT レポート「リスク、規制と、そのリター

ン」）

http://www-06.ibm.com/jp/domino07/fss/finnetjp_www.nsf/vwdockey/2BD195D1E05E855D492570

C900321D71?Open&cat=09 A8：通商白書 1．イギリスコーポレート・ガバナンスの改革の背景と動向

http://www.meti.go.jp/hakusho/tsusyo/soron/H15/01-03-01-01.html A9：日本公認会計士協会「財務諸表監査における情報技術（IT）を利用した情報システムに関する重要

な虚偽表示リスクの評価及び評価したリスクに対応する監査人の手続について」2006 年３月 17 日改

正

http://db.jicpa.or.jp/visitor/general/toshin_dl.php?id=40 A10：金融庁「ディスクロージャー制度の信頼性の確保に向けた対応について」

http://www.fsa.go.jp/news/newsj/16/syouken/f-20041116-1.html http://www.fsa.go.jp/news/newsj/16/syouken/f-20041224-2.html

ix

数字

3 変革要素 73, 74

B

BCP 395, 415

BSC 71, 100

C

CIO 23, 42, 80, 83

～以外の担当分野 93

～が勉強したい点 111, 113

～に必要な知識・能力 109

～の主な経験分野 88, 112

～の充足度 102

～の責任範囲 99, 107

～の担当期間 86, 113

～の悩み 107

～の不安 105

～の役職 84, 85, 92

CIO 補佐官 116

CL／SVR 4

COBIT 451, 525

COCOMO 法 222

COSO-ERM 524

COSO 189, 366, 436, 444,

446, 450, 457, 466, 486, 525

CSR 27, 512

D

DB パトロール 231

DMAIC 138, 139

E

ERP 267, 341

F

FP 228, 251

I

IS 29

ISMS 367, 371, 373, 382

IS 機能 31, 37, 39, 42, 50

IS 戦略 39, 43, 48

ITSS 36

IT ガバナンス 19, 27, 40, 440, 512

IT スキル標準 36, 39

IT 戦略 48

IT 組織 8, 16, 61

IT 投資 23, 111, 114, 499

IT 統制 189, 502

IT 部門 9, 16, 40, 56, 61,

80, 90, 139, 209, 325, 489

IT 法務 477, 479

J

JAVA 252, 331

JUAS 法 139

K

KLOC 262

Know-Who 122, 124, 151

索引

x

L

LINUX 253, 327, 331

LOC 27, 228, 252, 263

R

RFP 67, 207, 220, 479

S

SECI モデル 155, 157

SNS 186

SOX 法 371, 453

U

UCD 279, 280, 287

UISS 31

UISS 構成要素

機能・役割定義 35

キャリアフレームワーク 49

人材像とタスク 43

タスク概要 32

タスクフレームワーク 31

UNIX 327, 331

UVC 196, 218

U 字型開発法 197, 200, 230, 347

V

V 字型開発法 196, 347

W

Web 2.0 174, 183, 185

Wikipedia 187

Windows 6, 253, 327, 328, 330, 331

あ

アウトソーシング 18, 37, 387,

405, 503

暗黙知 151, 155, 157, 158

い

移行 199, 232, 247, 343, 504

インターネット 175, 183

～での情報検索 179

う

ウォーターフォール 139, 278

お

お客様迷惑度指数 475

親会社の IT 組織 16

か

改造型固有規模環境変数 347, 360

開発言語 252

開発プラットフォーム 253

外販比率 14

外部監査 379

株主 27, 446

画面デザイン 281, 302, 313

監査法人 453

xi

き

企画提案

IT 部門に対する～ 56, 61

情報子会社に対する～ 59, 61

ベンダーに対する～ 59, 61

基幹業務システム 189

基幹業務情報 140, 143

企業内ポータル 180, 181

業務改革 58, 75, 99, 111, 320, 322

業務系情報 124, 126, 128

業務再開目標時間 403

業務システム仕様書 210

業務担当部門 209

金融商品取引法 371

く

グループウェア 182

け

経営トップ 80, 83, 324, 386, 439

形式知 151, 155, 158, 189

掲示板 182

ケプナートリゴー法 75

検索エンジン 179

こ

コーポレートガバナンス 512, 523

顧客情報 144

個人情報 189

個人情報保護 512

個人情報保護法 189, 371, 373

コスト見積 204

コンプライアンス 34, 512

さ

財務諸表検査 499

作業評価指数 27

し

事業継続計画34, 396, 401, 407, 415

自主点検 487

システム運用 484

システム監査 35, 364, 366, 372

～の課題 364

～の実施状況 364

～の着眼点 370, 387

～のテーマ 376

～の手順 382

システム監査人 378, 380, 388

システム企画推進 16, 323

システム切り替え 233

システム再構築 243, 318, 337

～の課題 335, 336

～の対象 322

～の理由 320

システムライフサイクル 327

システムリスク 435, 470

シナリオ作成 292

仕様変更率 220

情報

～の検索 178

～の蓄積 176, 190

情報共有 122

～の課題 133, 187

～の実施状況 127

～の制約 189

～のツール 174

～の発展 174

～の必要性の認識 126

情報子会社 7, 10

～の経営形態 13

～の方向性 13

xii

情報システムユーザースキル標準 31

情報セキュリティガバナンス 512

情報セキュリティ監査 367, 372

人材育成 50, 516

人材像 42, 44

す

推進組織 497, 515

スキル構成 40

ストック情報 124, 126, 131,

148, 150, 152

スパイラル 278

せ

生産 6 要素 71

生産性 228

生産性環境変数 346, 348, 357

セキュリティ 34

セキュリティポリシー 136

全般統制 503, 509

そ

ソフトウェアメトリックス 22

た

ターンバルガイダンス 445, 524

タスク分析 294, 297, 305

単体テスト 230

ち

知識・ノウハウ 124, 126, 131

知のスパイラル 157

中央集権型 8

て

提案力 54

～不足の原因 63

～への満足度 57

ディザスターリカバリー 421, 423

データ構造 341

データコンバージョン 342

と

投資評価 24

ドキュメントの共有 148

な

内部監査 379, 490

内部統制 436, 442, 456, 492,

512, 513

に

日本版 SOX 法 100, 371, 464

の

納期遅延 266

は

パッケージ 328, 330, 504

汎用機 4, 19, 274

xiii

ひ

ビジネスインパクト分析 410, 417

標準工期 27, 221

品質目標 22, 27, 224

ふ

ファイルサーバー 176, 178

ファイルの検索 148, 150

プライバシーマーク 371, 373, 375

フロー情報 124, 126, 129, 147

プロジェクト管理 67, 482, 497

プロジェクトマネジメント 33, 344

プロセス志向 17, 25, 220

プロダクト志向 220, 226

プロトタイピング 301, 307

プロトタイプ 276, 308, 311, 313

文書管理ツール 177

へ

米国企業改革法392, 428, 452, 464, 467

ペーパープロトタイプ 216, 307, 341

ペルソナ 290, 294, 312

ベンダー 21, 54, 55

ほ

保守依頼 256

保守運用 18, 200, 236, 414

保守欠陥 264, 265

保守作業240, 242, 249, 263, 267, 270, 275

保守費用 267, 268

保守要員 255, 259, 261, 262

み見える化 20

株主に対する～ 27

関係会社に対する～ 24

経営者に対する～ 23

顧客に対する～ 21

システム関係者に対する～ 25

見積 242, 243, 263, 266, 202

ゆ

ユーザーインタビュー 289

ユーザー中心設計 279

ユーザビリティ 215, 274, 277, 280

よ

要求仕様書 208, 211

要件定義 201, 278, 347

り

リスク 23, 109, 111, 202,

204, 233, 243, 366, 396

リスク管理 345, 376, 429, 438,

470, 482, 484, 486, 513

リスク評価表 204, 205

リスク文化 467, 517

リスク分析 47, 387, 411, 472, 475

リスクベースアプローチ

431, 438, 473

リスク見積 202

れ

レビュー 214, 347, 482

連邦型 8, 9

■執筆者

相田秀司大日本インキ化学工業株式会社情報システム部情報戦略第１担当

第 2 章

岩原秀雄社団法人日本情報システム・ユーザー協会セキュリティセンター

第 4 章第 1 節

宇羅勇治システムコンサルタント第 4 章第 2 節

齋藤学株式会社シーエーシー SO コラボレーション本部マーケティングオフィス

第 2 章

高橋秀敏社団法人日本情報システム・ユーザー協会企業情報マネジメント研究会共同部会長

第 5 章

長尾和洋ソニー生命保険株式会社広報部広告宣伝課第 3 章第 3 節

細川泰秀社団法人日本情報システム・ユーザー協会専務理事

第 1 章第 1 節、第 3 節、第 3 章第 1 節、第 2 節、第 4 節

三木徹社団法人日本情報システム・ユーザー協会事務局長

第 1 章第 4 節

角田千晴社団法人日本情報システム・ユーザー協会事業部長

第 1 章第 2 節

（五十音順、敬称略）

「システム・リファレンス・マニュアル第 2 巻」発行：社団法人日本情報システム・ユーザー協会

〒103-0012 東京都中央区日本橋堀留町 1-10-11 井門堀留ビル 4 階 TEL 03-3249-4101 FAX 03-5645-8493 URL http://www.juas.or.jp/

本報告書は、独立行政法人情報処理推進機構から委託を受け作成いたしました。作成実施機関：社団法人日本情報システム・ユーザー協会（JUAS）

（禁無断転載）

All Rights Reserved , Copyright © IPA 2006

システム・リファレンス・マニュアル （srm） 第2巻 - ipa（srm） 第2巻...

Documents

システム・リファレンス・マニュアル（srm）第2巻 - ipa（srm）第2巻...