スタートページ＞ 主張・講演＞ 論文等

情報システム開発に関する各種標準

－ＩＴコーディネータ・プロセスガイドラインを中心に－

「東京経営短期大学紀要」第１１巻，pp.53-73, ２００３年３月

日本経営システム学会経営情報研究部会（２００２年８月１０日）での発表をベースに加筆したものです。

注（２００５年５月記入）
ここでの「ＩＴコーディネータ・プロセスガイドライン」は「β版」を指しています。２００５年６月に「ｖ１.０」になります。全面的な改訂になり，ここで示している各種基準類の参照はなくなりました。

主な標準
ＩＴコーディネータ・プロセスガイドライン，ビジネス・エクセレンスモデル，日本経営品質賞，ＡＰＱＣモデル，バランス・スコアカード，成熟度モデル，ＣＭＭ，ＩＴコーディネータ簡易診断ツール，ｅ－ＢＡＴ，ＣＯＢＩＴ，共通フレーム，ＳＰＡ，ジェネリックモデル，ＰＭＢＯＫ，ＥＶＭＳ，ＩＳＭＳ

１　はじめに

情報システムを構築するには，経営戦略や情報化計画の作成，個別システムの設計，運用管理などのプロセスがある。これらのプロセスを実施するには，ベストプラクティスによる方法を参考にするのが適切である。それらの方法をここでは標準というが，多くの機関が多様な標準を発表している。
　ここでは，ＩＴコーディネータ協会によるＩＴコーディネータ・プロセスガイドラインで示している標準を中心に，最近注目されている各種標準の概要を紹介する。

２　各種標準の位置づけ

ここで取り上げる各種標準が，情報システム開発のどの局面に用いられるかをＩＴコーディネータ・プロセスガイドラインの体系をベースにして示す。それに先立って。ＩＴコーディネータについて簡単に説明する。

２．１　ＩＴコーディネータとは

ＩＴコーディネータとは，「中堅企業等ＣＳＯ（Chief Strategic Officer：経営戦略企画責任者）にとっては、戦略的情報化のビジョンを示し、これを設計するのみならず、システムインテグレータ等がシステム構築を実施する場合にもアドバイザー的に働き、これが無事に稼働するまで一貫して関与し続けるような経営戦略とＩＴをつなぐ人材」である。

通商産業省（現経済産業省）産業構造審議会情報産業部会「情報化人材対策小委員会」中間報告『戦略的情報化投資による経済再生を支える人材育成』，１９９９年

中堅企業や中小企業の情報化にあたり，経営者とベンダ（システム開発企業）との橋渡しをするコンサルタントであり，プログラミング等のシステム構築作業には直接関与しないが，経営戦略の立案からベンダへの提案依頼書の作成，システムの受入れや運用管理までを一貫して経営者を支援することが特徴である。
　そのＩＴコーディネータを育成し認定する母体として，２００１年にＮＰＯ（特定非営利団体）であるＩＴコーディネータ協会が設立された。その資格を得るための研修コースがあるが，そこではこのような標準（特に国際的に注目されている標準）の紹介とその適用を中心にしており，それをＩＴコーディネータ・プロセスガイドライン（β版）（以下「ＩＴガイドライン」と略す）としてまとめている。また，ＩＴコーディネータになるには研修コースの受講が義務付けられているが，専門知識研修コースの教材も公開されている。

２．２　ＩＴガイドラインによる体系

ＩＴガイドラインは，国際会計士連盟（ＩＦＡＣ）の「国際ＩＴガイドライン」を参考にしたものであり，情報システム構築のプロジェクトを体系化して，それぞれについて留意するべき事項（原則）と，その内部手順を説明したものである（図１）。
　図１の上半分の３つはプロジェクトを円滑に運営するためのものであり，下半分の５つは経営戦略検討から運用までの各プロセスである。ここでは後者だけを対象にする。

図２はその後者をさらに細分化したものである。図２の左上隅や右下隅に黒三角印のついたブロックを，本論文が対象にする「各種標準」である。右下隅に黒三角印のついたブロックはＩＴガイドラインには記述がなく，私が付け加えたものである。


（拡大図）
（１）経営戦略策定
ビジネスとしての経営戦略であり，情報化に限定したものではない。どのようにして収益を確保して企業を発展させるかを策定するものであり，その結果をビジネスモデルという。図２では戦略版と戦術版に分けているが，概要と具体策と考えればよいようである。
（２）戦略情報化企画
経営戦略に基づき全社的な情報化計画を作成するプロセスである。ここでの戦略情報化企画書とは，個別のアプリケーションシステムではなく全社的な統合したシステムである。それは，個別システムを構築するのではなくＥＲＰパッケージによる開発を想定しているからだと思われる。
（３）情報化資源調達
情報システムを自作するのではなく，ベンダに発注することを前提としている。発注に先立ち，対象とする情報システムの要件をベンダに示すＲＦＰ（提案依頼書）の作成が必要になる。図２の「調達の手順１」はＲＦＰを作成するまでのプロセスであり，「調達の手順１」はベンダからの提案書を検討して発注先を決定し，さらに詳細の交渉をして契約を締結するまでのプロセスである。
（４）情報システム開発・テスト・導入
開発自体はベンダが行うが，その仕様の詰めや進捗状況などをモニタリング（監視して改善すること）する必要がある。出来上がったシステムを利用者の立場からテストをして受入れるまでのプロセスである。
（５）運用サービス・デリバリー
運用管理と展開とでもいうべきプロセスである。このプロセスでも外注あるいはアウトソーシングを想定している。それで情報システムが期待した性能を発揮できるか，どのような運用管理をするかといったＳＬＡ（サービスレベル・アグリメント）の作成が重視される。また，ＩＴコーディネータとして，運用により期待した成果が得られているかのモニタリングが求められる。

３　各種標準の概要と意義

図２で示した各種標準について，研修コースでの説明にこだわらずに，私がそれらの基準を理解した観点からその概要と意義について解説する。

３．１　ビジネス・エクセレンスモデル

経営の仕方や成果を経営品質という。優れた経営品質のビジネスモデルを実現した企業を表彰して広く公開することにより多くの企業の参考にするために，経営品質賞の制度がある。米国のマルコム・ボルドリッジ国家品質賞や欧州のヨーロッパ品質賞が有名であり，日本では経営品質協議会が日本経営品質賞を設けている。日本経営品質賞の評価基準は毎年若干変更はあるが，２００２年の基準は次の通りである。活動成果に重点がおかれ，情報化自体には配点が少ないことに留意するべきである。

　　　　表１　日本経営品質賞の評価基準（配点）

　　　　１．リーダーシップと意思決定（１２０）
　　　　２．経営における社会的責任　（　５０）
　　　　３．顧客・市場の理解と対応　（１１０）
　　　　４．戦略の策定と展開　　　　（　６０）
　　　　５．個人と組織の能力向上　　（１００）
　　　　６．価値創造のプロセス　　　（１００）
　　　　７．情報マネジメント　　　　（　６０）
　　　　８．活動結果　　　　　　　　（４００）　　

経営戦略は経営者が自ら検討するべきことであるが，これらの事例をベストプラクティスとして参考にすることにより，多くのヒントを得ることができる。成功事例は経営誌でも多く取り上げられているが，経営品質賞は総合的な観点での審査を受けたものなので，参考にするのに適した事例だといえる。

３．２　ＡＰＱＣモデル

業務分析をしたり業務プロセスのベストプラクティスの調査をしたりするには，企業にはどのような業務があるかの列挙リストがあり，その名称が統一されていると便利である。米国生産性品質センター協会（ＡＰＱＣ）はマルコム・ボルトリッジ賞を創設しベストプラクティスの普及を目的とした機関であるが，同協会は標準的な業務プロセスを区分した“Process Classification Framework”を発表した。これをＡＰＱＣモデルという。
　上位モデルとは業務分野を１１の大区分にしたものであり，下位モデルとはそれぞれの大区分に中区分・小区分を示したものである。
　このような名称統一ができれば便利であるが，その和訳は必ずしも日本企業で一般に用いられている用語と一致しない。業務プロセスを検討するときに，見落とした分野がないかをチェックする程度の利用になろう。

３．３　バランス・スコアカード

バランス・スコアカード（以下ＢＳＣという）とは，ロバート・Ｓ・カプランとデビッド・Ｐ・ノートンが１９９２年に発表した企業や部門の評価方法である。図３のように，財務の視点，顧客の視点，内部プロセスの視点，学習と成長の視点の４つの視点から，各部門の計画や実績を評価するものである。

「バランス」には二つの意味がある。その一つは，評価に際して短期と中長期の観点をバランスさせることである。米国での企業や部門の評価は，とかく短期的な収支である財務の視点のみを重視しがちであったが，その財務内容を改善するには，顧客満足度を得ること，業務のしかたを改革すること，さらに社員の能力を高めるなど，これらの先行する非会計的な要因の成果を評価することが必要である。
　もう一つは，各部門あるいは各活動のバランスをとることである。上の４つの観点を向上させるには，多くの部門が相互に関係している。部分最適化ではなく全体最適化を図るために，総合的な視点から整合性をとることである。

「スコア」とは，これらの計画や実績を数値的な尺度で評価することである。日本では上記の４つの視点を含めた中期計画も重視されてはいたものの，全体をフレームワークとしてとらえること，具体的な数値目標としてマネジメントすることに欠けていた。ＢＳＣでは，各視点について戦略的目標，成果尺度，パフォーマンス・ドライバを示すことが要求される。例えば，学習と成長の視点では，次のようなものになる（これは企業環境により異なる）。
　学習と成長の視点での戦略的目的としては，社員の能力向上や生産性向上などが考えられる。社員の能力向上の成果尺度では具体的な数値として測定できる尺度，例えば資格取得件数，ＩＴ技術習得度，社員満足度などを目標数値として設定する。パフォーマンス・ドライバとは，成果尺度の目標値を達成するための手段である。資格取得への補助規程の作成，社内教育の体系化と実施，トップと社員の対話機会などを具体的に示す。

ＢＳＣはその後，単なる評価ツールではなく，経営戦略の策定や実施のためのツールへと発展してきた。それで最近，経営戦略の分野でバランス・スコアカードの活用が注目されているのである。

３．４　成熟度モデル（ＣＭＭ）

「成熟度」とは，経営品質や情報システムの品質について，組織としてどれだけ関心を持ち，その維持向上のための仕組みを作り，それを発展させているかの尺度である。本論文で取り上げた各種基準でも多様な成熟度が提案されている。各種成熟度モデルとそれが主に対象とする情報化プロセスの関係を図４に示す。

これらの成熟度の考え方はＣＭＭ（Capability Maturity Model）の５段階レベルに倣っていることが多いので，図２での順序と異なるが，ここでＣＭＭについて説明する。
　１９９３年にカーネギメロン大学（ＣＭＵ）のソフトウェア工学研究所（ＳＥＩ）は，国防総省が情報システムを発注する際にベンダのソフトウェア開発能力のレベルをアセスメントする基準の研究を行い，それを「ソフトウェアプロセス成熟度モデル（ＣＭＭ）」として発表した。
　ＣＭＭでは，成熟度を次の５段階のレベルに区分し，それぞれのレベルで何がなされているかのプロセスエリアを掲げ，それを実現する基本活動などを掲げている。その構成を図５に示す。

ＣＭＭの５段階レベルとは，次のような状況を指す。

多くの企業での利用により，このような成熟度モデルが実際に適切であると評価され，ソフトウェアプロセス以外の分野にもＣＭＭが適用されるようになった。

そして現在ではＣＭＭＩＳＭ（Capability Maturity Model Integration）に統合化されてきた。なお，このＣＭＭＩでは，従来の５段階モデル（Staged）の他に連続的モデル（Continuous）がある。

先に示したように，このＣＭＭに倣って多様な成熟度モデルがある。これらの５段階レベルの内容はＣＭＭとほぼ同様であるが，初期段階の前にＣＭＭにはない「０　混沌」を置くこともある。すなわち，関心を持っていない段階を０とし，関心を持った段階である１と区別するのである。

３．５　ＩＴコーディネータ簡易診断ツール

ＩＴコーディネータが，クライアント企業（中小企業）の情報化に協力する最初の段階で，経営の成熟度を簡単に測定するためのテンプレートである。その概要を図６に示す。
　日本経営品質賞などで採用している各アセスメントプロセスについて，いくつかの簡易アセスメント項目と着眼点を示したリストがあり，それらの項目のそれぞれを成熟度レベルで評価する。その各レベルに各項目に特有な説明がある。

３．６　ｅ－ＢＡＴ

ｅ-ＢＡＴ（e-Business Assessment Tools）は，製造業を対象にした情報化戦略立案のための技法である。英国ｅ－ビジネス産業協議会（ＵＫＣｅＢ）により開発され，日本ではＥＲＰ研究推進フォーラムがその普及推進をしている。
　ファシリテータと呼ばれるコーディネータの指導の下に，ユーザ企業の経営者や業務責任者がチームになって図７に示す手順で作業することにより，経営課題の確認と情報化戦略の立案ができる。

（１）業種プロフィールの作成
業種・規模，製品特徴，企業ポジション，対象分野などの基本項目を指定する。
（２）業務改善テーマの選定
あらかじめ定義されている１７の業務改善テーマについて，重要度により数個のテーマを選択する。（１）と（２）を与えると，チェックシートにより標準的な場合とのチェックが行われる。
（３）コンピタンスの検討と確認
あらかじめ定義されている４つのコア・コンピタンス（全社共通の視点）と６つのプロジェクト・デリバリ・コンピタンス（主な業務プロセスの視点）につき，個々に５段階のレベル例から，現状の姿（as is）とあるべき姿（to be）のレベルを確認する。
（４）最重要コンピタンスの特定
（３）を検討して，最重要なコンピタンスを各２つ決定する。ここでもチェックシートがあり，標準的なあるべき姿とのチェックができる。
（５）ビジネス・エレメントの特定
最重要コンピタンスと業務改善テーマとの組み合わせによるマッピングシートから，自動的にビジネス・エレメントが求められる。ビジネス・エレメントとは情報化の重点分野のことで「コアビジネスプロセスを支援する技術システム及び業務システム」や「情報共有化のためのアプリケーション」などの１８の分野がある。
（６）情報化戦略の作成
ビジネス・エレメント一覧表には，それぞれの分野について，どのように情報化を進めればよいかの例示がある。それを参考にして情報化戦略を作成する。この（５）（６）はチーム員が行うよりもファシリテータが行うのが適切だとされている。

ｅ-ＢＡＴは次のような特徴を持つ。

  1. アセスメントのための質問項目があらかじめ定められており，チェックシートやマッピングシートができているので，この手順通りに行うことによりアセスメントができる。
  2. 多くのベンダがこのような技法を持っているが，ｅ-ＢＡＴは多くの専門家が作成に参加していることと，標準として広く利用されていることに特徴がある。
  3. 質問項目が比較的少なく，チーム作業が容易である。その質問内容や作業プロセスが工夫されており，単に結果を得るだけでなく，その過程において多くの問題認識やコンセンサスが得られるようになっている。

３．７　ＣＯＢＩＴ

ＣＯＢＩＴ（Control Objectives for Information and related Technology）とは，情報システムコントロール協会（ＩＳＡＣＡ）により作成された。ＣＯＢＩＴは，特にＩＴガバナンス能力を評価するのに適している。情報システムの開発を外注することを前提にして，戦略的な情報化企画から運用に至るまでの３４のプロセスを表２（左）のように定義して，それぞれのプロセスについて，表２（右）のようなＣＳＦ／ＫＧＩ／ＫＰＩを例示し，それを成熟度モデルにより評価する。


（拡大図）

（注）ＣＳＦ，ＫＧＩ，ＫＰＩ
　ＣＳＦ（Critical Success Factor：重要成功要因）
　　　目的を達成するための重要な手段
　ＫＧＩ（Key Goal Indicator：重要目標達成指標）
　　　何をどれだけのレベルにするかを測定できる尺度で数値的に示す。ＢＳＣの成果尺度に類似。
　ＫＰＩ（Key Performance Indicator：重要業績達成指標）
　　　ＫＧＩを実現する手段の達成を測定する数値的尺度。ＢＳＣのパフォーマンス・ドライバに類似。

３．８　共通フレームとＳＰＡ

システム開発契約から検収して運用するまでのプロセスをシステム開発のライフサイクルという。その間のプロセスの用語や定義がばらばらだと，ユーザ企業とベンダ企業の間，ベンダ企業内での各チームの間で誤解を生じる危険がある。それを防ぐために，ライフサイクルのプロセスを体系化・構造化して用語の統一やそこでの業務内容を明確にしたのがＩＳＯ／ＩＥＣ １２２０７である。それを日本の状況にしたのが「共通フレーム」（ＳＬＣＰ－ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998）である。この共通フレームは，情報処理技術者試験での共通知識とされており，情報処理技術者の間で定着している。

共通フレームの基本構成を図８，そのなかの開発プロセスを展開したものを図９に示す。



ＳＰＡ（Software Process Assessment，ＩＳＯ１５５０４）は，上述のＩＳＯ／ＩＥＣ １２２０７の各プロセスについて，自社プロセス状態の認識，目標とＲＦＰ（提案依頼書）あるいは契約内容との合致，ベンダの開発状況の把握などについてアセスメントする。すなわち，「共通フレーム」が的確に運用されているかの評価をするものといえる。

図１０に示すように，ＳＰＡではＣＵＳやＥＮＧなど５つのカテゴリがあり，それぞれのカテゴリがＣＵＳ１.２などのようにプロセスとして細分化して，それぞれのプロセスについてプロセスの目的や基本プラクティス（目的達成の状況）を定めている（これは関係者間で設定してもよい）。それを能力水準（成熟度）と評価尺度により評価する。

３．９　ジェネリックモデル

開発するべきシステムの仕様を記述する図法の代表的なものにＤＦＤ（Data Flow Diagram）とＥＲＤ（Entity-Relationship Diagram）がある。社内での検討資料やベンダへの説明資料にＤＦＤやＥＲＤを用いることが望ましい。
　それらを白紙の状態から作成するのではなく，標準的なサンプルを適宜修正することができれば便利である。ＩＴコーディネータ協会が作成した標準サンプルをジェネリックモデルといい，ＤＦＤ形式のものをジェネリック・ビジネスプロセスモデル（図１１），ＥＲＤ形式（部分的にＵＭＬのクラス図の形式も取り入れている）のものをジェネリック・情報モデルという(図１２）。それぞれに全社を対象とした上位モデルと個別システムを対象とした詳細モデルがある。
　さらにジェネリック・データモデルがある(図１３）。これはジェネリック・ビジネスプロセスモデルでの機能とジェネリック・情報モデルでのデータ項目との対応表であり，各機能での成熟度に応じてどのデータ項目を取捨選択するべきかを示したものである。



（拡大図）

これらは，ＩＴコーディネータ専門知識研修コースの教材に部分的に掲げられている。これらのモデルは未だ整備段階であるが，実用にたえるレベルまでにリファインされれば，情報システム開発において画期的な有用なツールになろう。

３．１０　ＰＭＢＯＫ

ＰＭＢＯＫ（The guide to the Project Management Body of Knowledge：プロジェクト・マネジメントの基礎知識体系）とは，特定の分野ではなくプロジェクト全般をマネジメントするための方法や知識を体系的に示したものである。プロジェクト・マネジメント協会（ＰＭＩ：Project Management Institute）が策定して，日本ではエンジニアリング振興協会がその普及にあたっている。

従来のプロジェクト管理では，納期までに（Ｔ：タイム），期待された品質の成果を（Ｑ：品質），予算内で（Ｃ：コスト）完成するＴＱＣだけが重視されてきた。しかし，それを実現するには，人や組織の面や情報の伝達・共有化などの面も重要であり，それらを総合的に管理することが重要である。このようなプロジェクト管理のことを「モダンＰＭ」というが，それにはＰＭＢＯＫの普及が引き金になったといわれている。
　ＰＭＢＯＫは，図１４に示すように，プロジェクト・マネジメントに必要な９つの知識エリアを設定して，各分野でのマネジメントの内容とそれを実施するための知識項目を掲げている。

情報分野でのＰＭＢＯＫの最も典型的な適用分野は情報システムの開発プロセスであろう。それにはＥＶＭＳ（Earned Value Management System）が注目されている。プロジェクトの進捗計画をベースにしておき，それとプロジェクトの中間段階までに要した時間と費用を比較することにより，完了までの納期遅れや予算超過の程度を予測する手段である。図１５にその概念図を示す。

３．１１　ＩＳＭＳ

情報システムではセキュリティ対策が重要であり，その対策に関する基準化が行われてきた。その基本になるのが英国規格のＢＳ７７９９である。これの第１部（情報セキュリティ管理実施基準）をベースにして国際基準にしたのがＩＳＯ／ＩＥＣ１７７９９であり，さらにそれを日本工業規格としたのがＪＩＳ Ｘ５０８０である。これらの内容はほぼ同一と考えてよい。
　Ｘ５０８０は，表３に示す１０の管理分野があり，それに関して３６の管理目的と１２７の対策が示されている。

　　　　　　　表３　ＪＩＳ Ｘ５０８０の管理分野

　　　１　セキュリティ基本方針　　・・・・・全体の方針
　　　２　組織のセキュリティ　　　・・・・・委員会等の体制
　　　３　資産の分類および管理　　・・・・・資産項目の整理
　　　４　人的セキュリティ　　　　・・・・・責任の明確化
　　　５　物理的および理論的セキュリティ・・入退室管理・設備機器
　　　６　通信および運用管理　　　・・・・・ウィルス対策など
　　　７　アクセス制御　　　　　　・・・・・不正アクセス対策など
　　　８　システムの開発および保守　　・・・情報の秘匿，暗号など
　　　９　事業継続管理　　　　　　・・・・・災害や事故と危機管理
　　１０　適合性（準拠）　　　　　・・・・・知的所有権、プライバシー保護など

ＩＳＭＳ（情報セキュリティ・マネジメント・システム）とは，企業が情報セキュリティ対策を構築することである。それにはＸ５０８０などの標準を参考にするのが適切である。また，それを第三者の認定機関が審査をする制度として，ＢＳ７７９９の第２部の認証制度によるものと，日本情報処理開発協会（ＪＩＰＤＥＣ）の「ＩＳＭＳ適合性評価制度」がある。
　ＩＳＭＳ適合性評価制度の説明は「ＩＳＭＳガイド」がある。これは審査員が審査業務で参考とすることを想定したものであるが，審査を受ける企業にとっても参考になる。「Ⅰ基本編」では，対象となる情報資産の列挙とリスク評価についての解説，「Ⅱ事例編」は，審査までの一連の作業を解説したものである。これらも日本情報処理開発協会から入手可能なので参照されたい。
　なお，情報システムに限定したものではないが，これに関連した標準にＪＩＳ Ｑ２００１「リスクマジメントシステム構築のための指針」がある。その目的は，「組織が社会的要請と経済的ニーズとのバランスの中でリスクマネジメントシステムを確立し充実させていくことによって、個々の組織及び社会全体を、危機に強く、リスクに適正に対応できるようにしていくこと」にある。

４　標準について

以上，情報システム開発に関する各種標準を紹介したが，それらの標準を理解することの意義や，その普及について考えたい。

４．１　標準に関する知識の必要性

これらを理解して活用することは，次のような理由により意義がある。

（１）生産性・品質の向上

当然，このような標準を知らなくても情報化戦略は策定できるし情報システムを構築することはできる。企業の環境は千差万別であるから，標準に従うことがよい結果を与える保証にはならない。しかし，このような標準を利用することにより，白紙から検討するよりも生産性が向上する。また標準の策定には多くの専門家が参画しているので，適切なベストプラクティスである。まずそれを理解して模倣することにより，ある一定レベルの品質を保証することができる。

（２）共通語としての意義

情報システムの構築を社内の数人で行うことは稀である。ユーザ企業では，社内での各部門からなるチーム，社外のベンダへの外注が行われ，ベンダ企業では複数のベンダによる共同受注，海外への下請け発注などが行われる。すなわち，多くの人が関与している。そのようなプロジェクトを運営するためには，各プロセスの用語や概念の統一，方法論の理解が重要になる。それには，一企業内で作成した標準よりも，国際的に認知されている標準を用いるほうが適切である。逆にいえば，情報システムに関係する者はこれらの標準を理解していることが期待される。

（３）中小企業への支援

企業にとって情報システムは経営戦略に重要な位置づけになってきたが，中小企業では経営者の認識，資金の不足，人材の不足などにより，情報化が遅れている。日本経済回復の観点からも中小企業が健全な情報化戦略を構築することが重要であることが指摘され，多様な支援策が取られている。その中で，人的な支援，すなわち中小企業の情報化を経営者の立場でアドバイスする人材の育成が重視されている。そのような業務をする者に中小企業診断士やＩＴコーディネータがいるが，それらが最新の経営や情報に関する知識能力を持つことが必要である。これらの標準を理解することは，その基本的な知識といえよう。

　

４．２　普及での問題点

標準に関する知識が必要であるならば，それを普及させることが重要になる。私はこれらの標準をベースにした教科書や経営者向けの入門書を著作しようとしているのであるが，それには次のような困難がある。

（１）用語の難解性

用語や概念が難解である。難しい漢語や英略語が多いというのではなく，英語を和訳したために，われわれの日常的な表現になっていない。それらの用語・概念は少なくとも情報技術者間での共通用語にする必要があるが，従来の情報技術者が用いてきた表現とも異なるので，現実にどれだけ定着するか懸念が残る。まして，学生や経営者のような一般人にそのまま使うのでは，かえって拒否反応を得る危険がある。とはいえ，無理に日用語にすると本来の意味と違ってしまう。

（２）網羅性と選択

標準の性格から網羅性が求められるので，巨大な複雑な体系になる。実際に企業で適用する場合では状況に合わせて取捨選択すればよいのであるが，教科書などでは対象が不特定なので，単純に主観的に取捨選択するのは不適切である。全体を簡素化するとますます抽象化されて，上記の解説のように，初心者には理解しにくいものになってしまう。

（３）全体の整合性

ここでのような各種標準を個々に羅列するのではなく，どのようなプロセスにおいてどの標準をどう活用するかといった内容にする必要がある。ところが，当然ながら各標準間には重複があり，しかも異なる目的で異なる表現をしていることが多い。各標準をいったん分解して，それを統合する作業が必要になるが，かなりの見識と作業量が必要になる。

５　おわりに

私は以前からこの分野に関心を持ち，実務や執筆などを行ってきた。その一環としてＩＴコーディネータの資格を取得したのであるが，それを機会にこれらの基準をベースとして「情報システム構築の方法と知識体系」を作ろうと思った。本論文はそのために各種標準を整理したものである。このような知識体系は，上述のように困難が多いが，情報技術の授業として基礎的なものであると考える。