よく勉強されていますね。
プロジェクトマネジメントの知識領域と聞かれれば、PMBOKの９の知識領域を答えるのが普通だと思います。ではなぜ、ITCのプロセスガイドラインでは知識領域は９ではなく、８なのでしょうか。それは、ITCのプロセスフローをもう一度思い起こしていただくといいと思います。

この図からもわかるように、ITCの活動フェーズはプロセス＆プロジェクトマネジメント／コミュニケーション、モニタリング／コントロールといった共通フェーズと、経営戦略に始まり、ＩＴサービス活用にいたる個別フェーズから成り立っています。
そして、ITCプロセスでは、PMBOKでいう調達マネジメントは、個別フェーズのＩＴ資源調達の部分で実施されることになります。
ITCプロセスガイドラインには、必ずしもPMBOKでいう調達マネジメントが含まれないのではなく、この部分を共通フェーズではなく、個別フェーズに落とし込んで実施することにしたと考えていただくのがいいのではないかと思います。

PMBOKとは、米国ペンシルバニア州フィラデルフィア市郊外アッパーダービーに本部を置くプロジェクトマネジメントのプロフェッショナル協会であるPMI(Project Management Institute)が発行した『A Guide to the
Project Management Body of Knowledge』の略称です。PMBOKの第3版（2004年版）［最新版］の和訳版が出ています。詳しくはPMI本部にお問い合わせ下さい。E-mail：　booked@pmi.org
PMBOKは、PMIの設立・活動目的のうち、特に、「プロジェクトマネジメントの基礎プロセスを明確にして、プロジェクト遂行管理を成功に導くためのプロジェクトマネジメントの知識体系を整備する」という目的に対応する成果物です。
また、PMBOKは、プロジェクトマネジメントという高度専門職業の知識体系を包括的に意味する用語でもあります。

PMBOKの使命は、
・プロジェクトマネジメントの適用分野（業界）を超えた標準知識体系を定めて、プロジェクトマネジメントプロセスの共通概念・用語を設定し、
・プロジェクトマネジメント実践者の知識面での自己啓発のベンチマークとし、
・PMIが行うPMI PMP資格認定や大学でのプロジェクトマネジメント教育のカリキュラム認定の基準とする
とされています。

バランス・スコアカードは、従来の財務的業績評価指標のみでは、顧客、サプライヤー、従業員、プロセス、イノベーション等に投資して、将来の企業価値を創造したり、企業行動を評価することが困難であるとの認識から生まれたものです。

次に、バランスの意味についてですが、それは、財務、顧客、社内ビジネスプロセス、そして、学習と成長の４つのバランスということではありません。この点、よく誤解があるようです。
これらの４つは、企業の業績を評価するためのバランスのとれた４つの視点です。つまり、バランスの取れた業績評価をするために設けられた視点、換言すれば、フレームワークだとお考えいただいたほうがいいと思います。

では、何についてのバランスかといえば、松原恭司郎著『バランス・スコアカード』（日刊工業新聞社）にそのひとつの解答があります。
松原氏によれば、バランスとは、�@財務評価指標項目と非財務評価項目、　�A外部評価項目と内部評価項目、�B短期目的と長期目的、�C遅行指標と先行指標とされています。
なお、松原氏は、バランス・スコアカードの「戦略的経営システム」への発展的変容の視点から、これら４つのバランスでは不十分で、新たに、�@ステークホルダー間、�A時系列間、�B組織間、�C戦略と実行間というバランスをあげています。

これに対し、日本のBSCの第一人者横浜国立大学吉川武男教授による翻訳、キャプランとノートンの『バランス・スコアカード』、いわば本家本元によれば、その序文で、「バランスという言葉は、�@短期目標と長期目標のバランス、�A財務的業績評価指標と非財務的業績評価指標のバランス、�B過去と将来の業績評価指標のバランス、�C外部的視点と内部的視点のバランスを意味している」とされています。

また、バランスに関する誤解は、財務の視点、顧客の視点、業務プロセスの視点、人材と変革の視点を
１／４ずつバランスさせるという誤解です。そうではなく、財務の視点ばかりに目を向けてはダメですよ、顧客の視点や業務プロセスの視点にも目を向け、企業経営しなさい、ということです。
また、短期的指向に走らず長期視点にも立って企業経営しなさい、という意味でのバランスでもあります。

テクノファは、この吉川先生の翻訳に従うのが妥当ではないかと考えています。なぜなら、著者、すなわち、キャプラン教授とノートン氏の意図をなるべく変えない方が、バランス・スコアカードの本質をつかむのに都合がよいと考えるからです。

また、このバランスについて、同書本文で、「バランススコアカードは、４つの視点により、短期目標と長期目標、目標とする成果と成果のパフォーマンスドライバー、定型的な客観的業績評価指標と弾力的な主観的業績評価指標というようにバランスを保っている」との表現もあります。

詳細は、吉川先生の翻訳によるキャプランとノートンの『バランス・スコアカード』（生産性出版）をご参照下さい。
なお、バランス・スコアカードについて詳細に学習されたい方は、吉川武男著『バランス・スコアカード入門』（生産性出版）、吉川武男訳　『戦略的バランス・スコアカード』（生産性出版）等をご参照下さい。

　　　　　　　　　　　　　　　　　（監修　横浜国立大学教授　吉川武男）

確かにおっしゃるように多くのガイドラインがあります。
ＩＴコーディネータ協会のWEBには、現在次のものがあります。
　「ＩＴコーディネータ専門知識教材・研修コース認定ガイドライン」、
　「ＩＴコーディネータ資格更新条件に関する運用ガイドライン」、
　「ＩＴコーディネータ資格認定制度ガイドライン」、
　「ＩＴコーディネータ報告書」、
　「ＩＴコーディネータプロセスガイドライン」、そして
　「ＩＴコーディネータカリキュラム作成ガイドライン」

このうち、ＩＴコーディネータのCBKに関するものは、「ＩＴコーディネータプロセスガイドライン」です。確かに「ＩＴコーディネータカリキュラム作成ガイドライン」もＩＴコーディネータに求められるパフォーマンス基準が提示されていますが、主として、教育機関及び教材開発会社等がＩＴコーディネータを養成するためのカリキュラムを開発する際の指針を示したものと理解していただいていいと思います。

そうすると、ＩＴコーディネータのCBKを身に付けるために主として参照すべきは、ＩＴコーディネータプロセスガイドラインということになります。プロセスガイラインには、プロセス＆プロジェクトマネジメント、コミュニケーション、モニタリング／コントロールの３つの共通フェーズと経営戦略、戦略情報企画、IT資源調達、IT導入、そしてサービス・デリバリーという５つの個別フェーズごとにＩＴコーディネータ活動の標準がまとめられています。
ＩＴコーディネータに求められる専門知識体系をマスターするためには、このプロセスガイドラインを熟読されることをお奨めします。

その他のガイドラインについて簡単に説明しておきますと、「ＩＴコーディネータ専門知識教材・研修コース認定ガイドライン」は教材開発・研修コース開発の際、研修機関が遵守すべきガイドラインであり、「ＩＴコーディネータ資格更新条件に関する運用ガイドライン」はＩＴコーディネータが資格認定及び資格更新に際して管理すべきガイドです。また、「ＩＴコーディネータ資格認定制度ガイドライン」は、ＩＴコーディネータの資格認定の基準を提示したものであり、「ＩＴコーディネータ報告書」はITSSP（経営情報化推進協議会）がＩＴコーディネータ制度の趣旨および活動内容に関する最終的な提言をおこなったものです。

これに対して、ＲＦＰ(Request For Proposal)は、調達の目的を達成するために調達対象の情報化資源に対する提案を求め、最適な調達先を決定するための「提案要請」です。
また、短期間で目的に適った効率的な調達先選定のため、ＲＦＰ発行対象は最大でも７〜８社程度に抑えたほうがいいとされています。
そうはいっても、実際にはＲＦＩとＲＦＰとでは、基本的に記載事項が重複するかもしれません。

それでは、何故ＲＦＰに先立ってＲＦＩを発行するのかといえば、昨今の企業を取り巻く環境の変化が背景にあるといえましょう。これほどまでにＩＴの進歩が早く、状況が刻々と変化すると、ＩＴベンダーについての自己調査にもおのずと限界が生じてきます。正確な情報を持たない状況ではＲＦＰを作成することも困難になってきます。
ここにＲＦＩを発行する必要性が生じてきます。逆に言えば、自己調査による情報並びにＲＦＩ以外の方法でＲＦＰが作成できるのであれば、かならずしもＲＦＩを発行する必要はないかもしれません。
一般に、高額の調達で、調達内容の定義が困難な場合、あるいはＩＴベンダーからの提案が多くないような場合には、ＲＦＰ発行に先立ってＲＦＩを発行するようです。

さて、その違いですが、一般には、ＫＧＩはKey Goal Indicatorsの略ですから、「何を達成すべきか」という評価指標であり、一方、ＫＰＩは、Key Performance Indicatorsの略で、「どのレベルで」を意味し、IT活動が「どのようにうまく」実行されているかを評価する指標であると解説されています。また、ＫＧＩは「事後的に」報告する指標であり、ＫＰＩは、「事前に」示す指標で、将来の成功または失敗の可能性を予測可能なものとするための指標であるとされています。

具体的なイメージを持っていただくために、ここでは、バランス・スコアカードを例にとって説明します。

顧客満足度の向上を戦略的目標とした場合、これを事後的に評価する成果指標、すなわち、ＫＧＩの一つとして、顧客満足度調査や顧客定着率があげられると思います。また、顧客満足度の向上を予測可能なものとするための事前指標、すなわち、ＫＰＩとしてリードタイムの短縮があげられるのではないかと思います。

この表から、KGIの対象はWhatであり、「ビジネス指向」であるとされるのに対して、ＫＰＩの対象は Howであり、「プロセス指向」であるということがお分かりいただけたのではないかと思います。

なお、ＫＧＩとＫＰＩの例をもっと多く知りたいという方は、「ＩＴコーディネータ専門知識教材テキスト０７　モニタリングとコントロール」等をご参照下さい。ＣＯＢＩＴの３４のＩＴプロセス定義それぞれについて、ＣＳＦ（重要成功要因）、ＫＧＩ及びＫＰＩの具体的な例が掲載されています。

テクノファでは、バランス・スコアカードの第一人者横浜国立大学吉川武男教授による「バランス・スコアカードマスターコース」を開講しております。本コースは、バランス・スコアカードの本質をご理解いただくと共に、実際にケースを通じてバランス・スコアカードを作成いただくコースです。

プラクティスを十分経験しておられる方ならではのご意見ではないかと思います。
確かに、プロジェクト計画・管理手法として一般的にＰＥＲＴやＣＰＭが効果的であると説明されることが多いようです。ただし、実際のスケジュール管理では、まずWBSで、もれなく作業（タスク）を定義することが前提となります。作業が体系的にもれなく定義できていなくては、ＰＥＲＴもＣＰＭもその効果は半減してしまいます。
また、ＷＢＳは、利用の仕方によっては、スケジュール管理にも使用でき、また、機能分析（ファンクションアナリシス）にも用いることができるという点から考えても、利用効果は非常に高いと思われます。

下図は、WBSの一般的な例ですが、これにガントチャート式に、作業開始と作業終了予定日を書き入れれば、スケジュール管理ツールとしても利用可能だと思います。

ただ、WBSでは、作業間の優先順位を決定することはできません。作業工程数が非常に多く、関連する作業が多数ある場合には、精緻なスケジュール管理をすることは難しくなります。そこで、各作業の工程にプライオリティをつけ、「作業スケジュールを最適パスに基づいて策定する手法」としてＰＥＲＴやＣＰＭが必要になってくるというわけです。

プロジェクトマネジメントに関する、主要ツールを使いこなし、プロジェクトマネジメントに関する実践力をアップしたいと考えておられる是非、以下のコースへのご受講下さい。
�@PMBOKに基づくプロジェクトマネジメント実践コース
�AMicrosoft Project活用によるPM実践【Advanced】コース
�BMicrosoft Project活用によるPM実践【Standard】コース
�CEVMS活用によるプロジェクトマネジメント実践【Advanced】コース
�Dプロジェクト・リスク・マネジメント実践【Advanced】コース

また、こうした複雑なスケジュールを管理するツールとして、マイクロソフト社のプロジェクト管理ソフト『Microsoft Project 2007』　 http://office.microsoft.com/ja-jp/project/FX100487771041.aspxやEVMS（Earned Value Management System）対応プロジェクト管理ソフトウエア Primavera　Project　Planner（プリマベーラ・プロジェクト・プランナー）通称：P3（http://www.ite.co.jp/products/primavera/ ）が知られています。ご興味・ご関心のある方は是非これらのサイトをご訪問してみてください。

もちろん、バランス・スコアカードについて、これを「戦略的マネジメントシステム」として位置づけ、個別に導入することも可能でしょう。

しかし、最近、統合マネジメントシステムへの取り組みの動きが活発化している例からも明らかなように、実は、品質や目標あるいは方針を管理する手法（すなわち、マネジメントシステム）や、成熟度モデルには、共通する部分も多くあるのではないかと思います。

例えば、ISO 9000認証取得済企業が、環境経営を経営理念として掲げ、ISO 14000（環境マネジメントシステム）に取り組み、さらには労働災害防止という観点からOHS/MSに取り組むばあいには、統合認証の取得を目指す傾向にあります。このようなことが可能なのは、文書管理といった要求事項が共通であるためです。

それでは、バランス・スコアカードとの関係はどうなるのでしょうか。バランス・スコアカードもまた、他のマネジメントシステムや成熟度モデルと共通している点が多々あります。例えば、ビジョンと戦略を各部門、各部署、各担当者というふうに　　ブレークダウン (落とし込み) し、最終的に、ビジョンや戦略の達成度を測定するというシステムは、品質方針や品質目標を文書化し、マネジメントレビューにより達成度を把握し、継続的改善につなげるというISO 9000品質マネジメントシステムと共通しています。　

また、バランス・スコアカードが４つの視点の結びつき（各視点に基づく戦略指標の因果関係）を重視しているという点は、ISO 9000のプロセスアプローチという観点に通ずるのではないかと思います。

つまり、バランス・スコアカードを用いようと、他のマネジメントシステムを用いようと、基本的な要素は共通しており、決して矛盾関係を生ぜしめたり、あるいは一つのマネジメントシステムが他に対して絶対的に優越的な地位に立つということはないのではないかと思います。ただ、階層的にやや複雑なシステムになりうる可能性はあるかもしれません。問題はこれらマネジメントシステムをどんな目的で導入するかということではないかと思います。

バランス・スコアカードは、これらのマネジメントシステムが効果的に機能しているかどうかを、ＩＴを用いてモニタリング／コントロールするための画期的なツールです。その機能は、飛行機のコックピットにたとえられます。

これまでに導入したマネジメントシステムや、成熟度モデルや、他の経営管理ツールの「パフォーマンスを測定するためのモニタリングツール」として効果的に活用していただける戦略的マネジメントシステムであると位置づけていただくのがバランス・スコアカードの正しい理解の仕方ではないかと考えます。

バランス・スコアカードの第一人者吉川武男教授は、この点について、「バランス・スコアカードは、他のマネジメントシステムと決して競合関係に立つものではなく、ＴＱＭ、ＩＳＯ、6σといったエンジンと一体となって企業を成功に導く戦略的マネジメントシステムである」と述べられています（テクノファ主催ＩＴコーディネータシンポジウム報告より）。

それぞれの個別機能を融合させた、「バランス・スコアカードに基づく融合マネジメントシステム」こそが、求められる理想のマネジメントシステムではないのかと考えます。

まず、ご指摘いただいたプロセスガイドラインから見てみましょう。
プロセスガイドライン４４ｐに定義が解説されています。
すなわち、「モニタリングとは、現業部門の状況がその管理担当及びそれよりも上位の管理者によってタイムリーに把握され、それをあらかじめ設定した目標と比較し、差に対しての対応を機敏に行うことで環境変化に対応しようとするものであり、COSO の内部統制のフレームワークで新たに定義されたコントロールの要素のひとつであり最も上位に位置づけられている。」とされています。

一方で、「コントロールの概念は、広義で用いられれば政策、経営戦略、戦術策定から日常管理、現業業務、機器制御までも含むチェック機能を一般的に総称するものであり、対象とする機能が一定の目的を達成しているかどうかを機能の対象物の状況を記録にとり継続的または定期的にチェックを行うことであり、モニタリングもそのひとつである。一般的に狭義で用いるときは、日常管理、現業業務、機器制御レベルのチェック機能を言う。コントロール機能はTQC 活動においてもPDCA（Plan, Do, Check, Action）のCheck として明確に示されている。」とコントロールを定義付けています。

この概念定義の特徴は、モニタリングを単に、１）状況をタイムリーに把握する機能にとどまらず、２）設定目標との比較機能、さらには３）ギャップに対してのアクションという環境変化対応機能まで持たせ、コントロールの要素の最上位に位置づけているということです。

これに対して、コントロールについては、対象とする機能が目的を達成しているか否かを記録にとって継続的又は定期的にチェックを行うこととしており、専らチェック機能のみを対象としているという点が特徴的です。

改めて、モニタリングとコントロールの概念の峻別がほとんど困難ではないかと思うほど重なりあってしまっています。そこで、一旦ＩＴコーディネータプロセスガイドラインから目を転じて、一般定義を見てみましょう。

まず、岩波広辞苑は、コントロールを「制御すること。統制。抑制。管理・調節。」とし、モニターを「機械などが正常な状態に保たれるように監視する装置。」としています。したがって、モニタリングは、「機械など
が正常な状態に保たれるように監視すること」という定義になるのではないかと思います。
また、研究社：英語語源辞典によると、monitorは（ラジオ・テレビなどの送信状態を）監視する、（一般的に）監督することであり、controlは照らし合わせて調べる、抑制する；支配するといった定義づけがなされています。

さらに、小学館ランダムハウス英和大辞典では、monitorは＜ラジオ電波・電話の声など送信の状態を＞（監視装置によって）モニターする、監視する、（テレビ・ラジオ放送）画質・音質をチェックするためにモニターする；＜番組などを＞モニターとして見る[聞く]、（無線電話・ラジオ放送を＞傍受する、＜人・仕事などを＞監視[監督]する、統制[管理]する。
＜機械などを＞（作業の具合を見るために）観察[記録、探知]する；＜脈拍数などを＞機器で測定する、（管理・監督のために）観察[検討]する、；　監査する；＜飛行機などを＞（レーダーで）追跡する、などと定義されています。

また、controlは、＜社会・機構・機械などを＞支配する、管理[監督、統制]する；操作する、＜感情・支出＞を抑制する、制御する；規制する、＜実験などを＞（類似の実験結果・基準）と照合して確かめる、照査する；…を確認する、といった定義がなされています。

最後にOxford現代英英辞典（第６版）は、
　　　　　monitorを、to watch and check something over a period of time in order to see how it
　　　　　develops, so that you can make any
　　　　　necessary changesとし、
他方で、controlを[Have power] 1 to have power over a person, company, country, etc. so that you
　　　　　　　　　　　　　　　　　　　are able to decide what they must do or how it is run:
　　　　　　　　 [Limit/Manage] 2 to limit something or make it ｈappen in a particular way:
　　　　　　　　　　　　　　　　　　　3 to stop something from spreading or getting worse:
　　　　　　　　 [Machine]　 1 to make something, such as a machine or system, work in the way that 　　　　　　　　　　　　　　　　　　　you want it to:
と定義しています。

これらの辞書の定義を総合すると、モニタリングとは、状況に応じて必要な変更ができるように、対象がどう機能しているのかを一定期間、監視・観察することであり、他方、コントロールとは、ある特定の結果が生じるよう、管理、統制・制御することである、と一般的に定義することができるのではないかと思います。

本定義を一つの事例を基に当てはめて見ましょう。

これから、12000キロメートル離れた地点のターゲットに向けて、ロケットを発射するとします。
この場合、１）発射前状況から発射直後そしてターゲット到着まで、レーダーでミサイルの位置を確認し、２）ターゲットとの誤差を測定し、３）軌道を修正し、４）最終的にターゲットに正確に的中させる、という一連
のプロセスは、それぞれモニタリングにあたるのでしょうか、それともコントロールにあたるのでしょうか。

なお、本定義は、ビジネス目標を設定し、これを達成するためにモニタリングし、コントロールするというプロセスにもまったく同じように当てはまります。

これを表にすると以下のようになるのではないかと思います。

プロセスガイドラインの定義が重複してしまうのは、モニタリングがコントロールの一部であると規定しているためです。

翻って、これらの一般的な定義をＩＴコーディネータプロセスガイドラインの定義と比較してみると、その違いが歴然だと思います。
つまり、一般定義は、モニタリング（monitor）を「対象の監視」機能に限定しているのに対し、プロセスガイドラインはモニタリングに捕捉機能、設定目標との比較機能、そして環境変化対応機能（アクション）まで広範な機能を持たせているということです。逆に、プロセスガイドラインでは、チェック機能にとどまっているコントロールという概念は、一般定義では、管理、統制・制御するという広範な機能が与えられています。

この一般定義は、ISO 9001:2000年版の定義とも合致しています。
すなわち、ISOの規格では、モニタリングを監視と訳し、コントロールを管理と訳しています。この訳語は、一般定義に適っているため、非常にわかりやすいように思います。

このように見てくると、ご質問にありましたように、ＩＴコーディネータプロセスガイドラインの定義はむしろ逆ではないのかという疑問も当然出てまいります。

それでは、ＣＯＳＯ（The Committee of Sponsoring Organizations　of the Treadway Commission）が公表している内部統制の統合フレームワーク（Internal Control - Integrated Framework）ではどう定義されているのでしょうか。　　　

モニタリングについては、一定期間システムパフォーマンスの品質を評価するプロセスであると定義され、定常のマネジメント及び監視活動や、任務遂行上のその他の活動を含むと規定されています。また、
コントロールは一定目標が達成されるよう管理、統制することと定義されています。コントロールについては、さほど違和感はありませんが、モニタリングについては、やはりしっくりこない感じがします。
この定義は、パフォーマンスの品質を評価する機能までも含んでいるという点で、一般定義よりも広範であり、プロセスガイドラインのモニタリングの定義と近いようにも思いますが、以下の点を忘れてはならないと思います。

すなわち、COSOの定義は、内部統制という特定の目的から演繹的に導かれた定義であり、�@効果的かつ効率的な運用、�A信頼性ある財務報告、�B法令遵守という３つの目的に資するために、内部統制は如何にあるべきかという視点からモニタリングとコントロールを捉えているということです。特に不正な財務報告を排除するという目的が主であるところから、本定義では、モニタリングそのものに、広範な機能をもたせる必要があったのではないかと考えられます。

そうすると、COSOの定義は、ITコーディネータのプロセス一般には当てはまらないようにも思えます。

一方で、ITコーディネータプロセスガイドラインは、定義上は、モニタリングとコントロールを区別しているものの、ＩＴコーディネータプロセスの共通フェーズでは、モニタリング／コントロールと表記し、機能的一体
性を持たせています。ITコーディネータの定義の中に、監理という用語が用いられていることからも如何にITコーディネータ制度がモニタリング／コントロール機能を重視しているかがわかります。

結論としては、ご質問にあるように、ITコーディネータプロセスガイドラインの定義は一般の定義やISO の定義から若干乖離しているといっていいと思います。また、この定義は、COSOの内部統制の統合フレームワークを参照しているということもご理解いただけたのではないかと思います。

まずは、ITの成熟度を、ＩＴガバナンスに関する成熟度モデルとソフトウェア開発の成熟度モデルに分類することができると思います。前者には、COBIT (Control Objectives for Information and related Technology)が、後者には、SPA（Software Process Assessment）：ISO/IEC TR15504やCMU/SEI（カーネギーメロン大学ソフトウェア工学研究所）によるCMMR (Capability Maturity Model)があります。そして、SPA(ISO/IEC TR15504)がソフトウェア開発プロセスの成熟度の国際標準とされるのに対して、CMM
はシステム／ソフトウェア開発能力の成熟度の国際標準(デファクトスタンダード)とされています。

もっともSPAについても、ISO/IEC TR15504に準じて実施されている試行プロジェクトであるPICE(Software Process Improvement and Capability Determination)のことを指すとされたり、あるいはISO/IEC TR15504に準拠して主としてイギリスで利用されているPPA（Process Professional Definition and Assessment）と混同して用いられるなど少し混乱が見られます。

また、ＣＭＭRについても、SW-CMM（Capability Maturity Model for Software）やSE-CMM（Systems Engineering Capability Maturity Model）、IPD-CMM（Integrated Product Development Capability Maturity Model）、SA-CMM（Software Acquisition Capability Maturity Model）、さらにはP-CMM（People Capability Maturity Model）、PST（Personal Software Process）、TSP（Team Software Process）など派生的なモデルが多く存在します。

こうした派生モデルをできるだけ一つにしようとの意図から、CMM　は上述のアンダーラインのある4つのモデルを統合し、CMMI SM（Capability Maturity Model Integration）へと進化を遂げました。その背景には、ISO/IEC TR15504の国際標準化があります。ISO/IEC TR15504が2002年もしくは2003年に国際規格として制定される見込みだからです。CMM　と言えども、グローバルスタンダードを参照せざるを得なかったというのが実情でしょう。

しかしながら、ISO/IEC TR15504もCMMR　もSPI(Software Process 　Improvement)、すなわち、ソフトウェアプロセス改善のためのアプローチ手法であるという点では共通しています。また、SPAには主として「ソフトウェアを開発する組織が自己のSPIを進めるために行う現状の自己組織の状態を調査・評価」と「ソフトウェアを調達する組織が、プロジェクトのリスクを軽減するために行うソフトウェアの発注先のプロセスの成熟度の評価」の２つがあります。

端的に言えば、企業・組織が自社のソフトウェアプロセス改善(SPI)のため、及び企業・組織が調達先企業のプロセスの成熟度を判定するために実施するのがソフトウェアプロセスアセスメント（SPA）であると考えていただいていいと思います。その上で、ソフトウェアプロセスアセスメントの手法として、一方にISO/IEC TR15504があり、他方にCMM　があるということです。

さて、ISO/IEC TR15504とCMM　の違いについてですが、ここでは、派生モデルの中でも最も導入が進んでいると考えられる、SW-CMMを取り上げます。
SW-CMMRは、各成熟度レベルで焦点を当てるべきKey Process Area(KPA) を特定しているため、「Stagedモデル」と呼ばれます。これに対して、ISO/IECTR15504は、レベルごとの活動要素をKPAのような形で特定せず、ソフトウェアのライフサイクルプロセスそれぞれに対して活動要素の能力を評価する形
式をとっているため、「Continuousモデル」と呼ばれます。　すなわち、SW-CMM がキープロセスエリアを特定し、これに基づいて成熟度、ゴールを設定するのに対して、ISO/IEC TR15504はその組織にあったプロセスだけを選択してその部分のみについて評価することができると言う意味で、SW-CMMに比してフレキシビリティに富むと言え、他方、SW-CMMは、ステージごとにキープロセスが設定されているため、目標を設定しやすく、かつインセンティブを働かせやすいといったメリットがあります。

なお、ご参考までに、ソフトウェア改善に関する最近の動向について若干ご紹介しておきます。　　　　

まず、山本喜一慶應義塾大学理工学部助教授を委員長とするソフトウェアプロセス改善専門委員会報告書では、「我が国ＩＴサービス産業の競争力強化等の観点からも、官民の役割分担を十分に踏まえつつ、ここで認定されたCMMISM やその他のSPI手法に関する施策も含め、SPI活動を推進するための施策をできるだけ早期かつ着実に実行に移していくべきである」との結論が導かれています。

また、２００２年４月１９日に公にされた経済産業省商務情報政策局情報処理振興課（ソフトウェア開発／調達プロセス改善協議会事務局）による「ソフトウェアプロセスの改善に向けて〜SPIへの今後の取り組み〜」では、「国際市場でも通用する競争力を涵養するため、ソフトウェアにおける改善活動の育成・普及を行わなければならない」とされ、また、「「SPIの推進に向けての体制整備」として、米国カーネギーメロン大学ソフトウェア工学研究所（CMU/SEI）のような公的な組織を特定し、中立的な立場から、SPI推進活動
全体のコーディネータ役を担わせるとともに、産業界や学界等の活動と十分連携を図っていくことが必要である」と述べられています。

なお、経済産業省の「日本版CMM」構想及びその後のSPI／SPAの動向については、機会を改めて詳しく紹介したいと思います。

また、テクノファにはプロジェクトマネジメントに関するコースが複数あるようですが、これらの違いが分かりません。私自身はＩＴコーディネータで、プロフェッショナル特別認定用専門知識研修コースの中で、ＩＴＣプロセスのプロジェクトマネジメントを学習しましたが、PMBOKそのものについての知識はあまりありません。どのコースが適切かご指導いただければ幸いです。

PMBOKTMとPMBOKRとの違いはありません。
この点、直接アメリカのＰＭＩ本部に問い合わせた際の回答は、次のようなものでした。すなわち、「TMもRも登録商標を指すという意味において差異はない。ただし、ＰＭＩとしては、現在ＴＭという表記を削除するようにしている。」とのことでした。この回答からもわかるように、基本的な差異はないとの認識でいいと思います。変遷からすれば、ＴＭという表記は９７年版まで主として使用されており、２０００年版以降はRという表記が使用されるようになったと考えていただくのがいいのではないかと思います。PMBOKR２０００年版の翻訳がＰＭＩ本部から発行されておりますので、入手方法についてはＰＭＩ東京支部へお問い合わせ下さい。

次にテクノファのプロジェクトマネジメント（PM）に関するコースの違いについては、簡潔に以下のように考えていただきたいと思います。

プロジェクトマネジメントについての基礎知識の枠組みを理解したいとお考えの方は、TM73「PMBOK概要コース」PMP資格取得試験の出題範囲となるＰＭＢＯＫを理解し、かつ人間関係のスキルについて学びたい方は、TM74「ＰＭＰ取得対策コース」、

実践的なITケーススタディによりＰＭに関する実践力を身に付けたいとお考えの方は、以下のコースをご受講をお奨めいたします。

�@PMBOKに基づくプロジェクトマネジメント実践コースPMBOKに基づくプロジェクトマネジメント実践コース　
�AMicrosoft Project活用によるPM実践【Advanced】コース
�BMicrosoft Project活用によるPM実践【Standard】コース
�CEVMS活用によるプロジェクトマネジメント実践【Advanced】コース
�Dプロジェクト・リスク・マネジメント実践【Advanced】コース

なお、ご参考までに受講マップも併せてご参照下さい。　

　　　　「ＩＴコーディネータ関連コースフローチャート」、及び　
　　　　「ＩＴコーディネータ関連コース専門性相関図」をご参照ください。

「シリーズ　プロセスガイドライン改定のポイント」、今回はその第１回目で、プロセス全体フロー編です。ＩＴＣプロセスフローの構成や全体フローからみた変更点を取り上げてみないと思います。
以下は旧プロセスガイドラインと新プロセスガイドラインのそれぞれの構成図です。

旧プロセスガイドライン

新プロセスガイドライン

Ａ１４：

Version1.1では、経営戦略は、プロセス改革により実行されるという視点が従前に比して色濃く出ていて、このプロセスの中から切り出されるのが「プロジェクト」であるという位置付けがなされています。また、プロジェクト化はプロセス改革の有効な手段の一つであるとされ、プロジェクトはプロセスを補完するものであるとされています。「プロセス」と「プロジェクト」との関係を最も端的に表しているのが次の記述です。すなわち、「プロセス改革課題の中から、優先度・重要度・影響を与える範囲等を考慮してプロジェクトとして切り出す範囲を判断する。」と。プロセス改革が目的であって、IT化はその手段であることを明記している点で、従前ともすればIT化が目的化されてしまっていた傾向が否めなかったのですが、こういったトレンドにも一石を投ずることになるかもしれません。この点、人と組織の呼び方で、業務プロセス改革部門：当該の経営戦略に従って業務プロセスを改革する責任を持つ部門、と定義しているところからも、主眼が経営戦略上のプロセス改革にあることが伺えます。このように、「プロセス＆プロジェクトマネジメント」では、各フェーズの活動が適切に行われていることを「プロセスの視点」からマネジメントすることになります。

次に「プロセス」と「プロジェクト」についてそれぞれその意味するところを比較検討してみたいと思います。

ジョハリの窓

出典: フリー百科事典『ウィキペディア（Wikipedia）』
　このジョハリの窓を理解するためのキーワードの一つが、「自己開示」であり、もう一つが「フィードバック」です。つまり、このコミュニケーションモデルが意図していることは、相互理解を図るためには、自己開示により「開放の窓」を広げるとともに、相手からフィードバックを貰うことによって「盲点の窓」や「未知の窓」を狭くすることが必要であるという点です。
　自己開示のために必要なスキルがアサーションスキル（いうなればさわやかな自己主張、換言すれば、I’m O.K and You’re O.Kの態度）であり、フィードバックを受け入れるために必要なスキルが傾聴（Active Listening）です。傾聴の基本的態度として挙げられているのが、�@共感的理解　�Aジュニュインネス（純粋性）／自己一致　�B尊重・受容・配慮です。傾聴スキルがことさらに強調されているのは、クライエント（相手）のニーズが分からなければ支援のしようがなく、また、課題が何であるかが分かれば本人自身が課題解決にむけて自分で行動を起こすことができると考えられるからです。傾聴にとって最も重要なのは、「クライエント自信が問題解決の中心である」という明確な認識であり、かつまた、この認識を実際に実務で使えるスキルを有していることです。
　このように述べてくるとITコーディネータには、いかに高度の「アサーションスキル」と「傾聴」スキルが求められているかがお分かりになったかと思います。上で見てきた、コミュニケーションに関する諸原則も、PRAMも、そしてまたDDPも対話を通じて互いに分かり合おうとする姿勢が重要であり、可能な限り、合意できる範囲を明らかにしていこうという対話のプロセスが重要であるということを視点を変えて述べているに過ぎないのです。ITコーディネータにはこのことを明確に認識し、かつ、これを実践できるコンピテンシーを求められているということをもう一度再確認していただければ、本稿の意図を達することができたのではないかと考えます。
　最後になりましたが、これらコミュニケーション・モデルの基本に「自己理解」があるということを看過しないで頂きたいと思います。人は、他人のコミュニケーション・スタイルやコミュニケーション・モデルについてはいろいろ意見を言うことができます。しかし、こと自分のコミュニケーション・スタイルとはどんなスタイルなのか、また、自分のコミュニケーション・モデルはどんなモデルなのかということを知ることが実は前提にあるということを忘れがちです。「他者理解」の前にまず「自己理解」があることを努々忘れてはならないと思います。
　その「自己理解」のためには、他者評価（フィードバック）も重要ですが、アセスメントツールを使うことも効果的です。アセスメントツールを使用することで「気付き」が得られ、「自己理解」が深まり、今後の自分のキャリア開発の目標やキャリア・デザイン／キャリア・プランニングへと繋がってきます。ここで、アセスメントツールとしてご紹介申上げたいのが、「ハーマンモデル」です。ハーマンモデルはノーベル賞受賞学者の大脳生理学理論に基づいた脳優勢度調査により自己の行動特性（コミュニケーション・スタイルを含む）を知ることができる画期的なツールです。

サーベンスオクスレー法については、今日なお、その厳格な運用を促すことを疑問視する声すらありますが、J-SOXへ多大な影響を及ぼしたことは間違いのないところです。
　ところで、わが国のJ-SOX法の枠組みはどのようなものでしょうか。
証券取引法の抜本改正である「金融商品取引法」がこれに該当します。同法は24条で、「有価証券報告書を提出しなければならない会社のうち、金融商品取引所に上場している有価証券の発行者である会社その他の政令で定めるものは、事業年度ごとに、当該会社の属する企業集団及び当該会社に係る財務計算に関する書類その他の情報の適正性を確保するために必要な体制について評価した報告書（内部統制報告書）を有価証券報告書と併せて内閣総理大臣に提出しなければならないこととする。また、内部統制報告書には、公認会計士または監査法人の監査証明を受けなければならないこととする」と規定しています。
　すなわち、ここでは、�@内部統制報告書を提出することと、�Aその内部統制報告書について監査を受けていること、が求められます。
　金融庁企業会計審議会内部統制部会が2005年12月に「財務報告に係る内部統制の評価及び監査の基準の在り方について」を公表しています。この指針は、監査法人が企業の内部統制システムをチェックする際の基準に関する指針を示したものですが、その中で、「経営者が実施した内部統制の評価」について公認会計士が法定監査（財務諸表監査）の一環として監査を実施することとされています。
　では、本法公布前はどうであったかというと、２００４年３月期決算から会社代表者による有価証券報告書の記載内容が適正であることの確認書を添付する制度が任意で始まっており、その中で財務報告に関わる内部統制システムの有効性の確認が求められてきました。主要な金融機関２００社以上が２００５年３月期決算で確認書を提出しているようです。
　さて、指針にもどって、少し詳しく見てみましょう。本報告書では、企業の４つの目的である、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守、資産の保全に対する６つの基本要素として、�@統制環境、�Aリスクの評価と対応、�B統制活動、�C情報と伝達、�Dモニタリング、�EITへの対応が挙げられています。この内部統制強化には、財務データだけでなく、あらゆる業務プロセス上のデータが適切に収集、処理された上で、これらが財務報告に反映される必要があるとされています。
　わが国のSOX法に対応する J-SOX法ともいうべきものは、上に見た通りですが、実は、この内部統制の枠組みの前提となっているのが、先に見たCOSOのフレームワークです。本報告書では、金融商品取引法が、もともとのCOSOのフレームワークの5つの構成要素になかった、「ITの利用」(IT統制)を挙げていることは注目に値します。すなわち、内部統制とIT活用とが密接不可分の関係にあることを物語っています。　　　
　このように、内部統制の仕組みについては、会社法と金融商品取引法で枠組みが与えられ、なおかつ、内部統制が経営者の説明責任の問題であることが明確にされたことにより、企業は従前にまして、ITガバナンスの問題に正面から取組まざるを得なくなったと言えるでしょう。
　新たな法規制が登場したことにより、これに対応するための、内部統制フレーム構築プロジェクトが至るところで立ち上げられ、全社的な取り組みをされている企業も多くあるようです。しかし、翻って考えてみれば、新たな法規制が登場したから、仕方なくITガバナンスの問題に取組むという姿勢は本来あるべき姿ではないようにも思います。冒頭にも述べましたように、このような法規制が登場したことで、これを契機として社内プロセスを見直し、全社の業務プロセスを可視化し、財務に関するリスクマネジメントを実践し、PDCAサイクルを回すことで業務プロセスのパフォーマンスを向上させ、コーポレートガバナンスの大きな柱であるITガバナンスに優れた企業としてブランド価値を向上させるのだという積極的な姿勢で取組む企業もあるようで、この点、内部統制フレーム構築コンサルティングを展開するITコーディネータにとっては朗報といえると思います。
　しかしながら、一方では、ことリスクマネジメントいう観点から考えれば、諸業務プロセスに潜む潜在リスクを明らかにし、影響度を評価して、これに対する対応策を講じる、というリスクマネジメントプロセスは、それがプロジェクトマネジメントであろうと、情報セキュリティーであろうと、どのマネジメントシステムに共通する、リスクアセスメントシステムの重要なポイントであることは論を待たないでしょう。内部統制を構築したある企業は、ISMSのリスクアセスメントを活用したと述べています。したがって、このようなプロセス自体はそれ程目新しいものとは言えないのではないかと思います。もちろん、後に述べる文書化やプロセスの可視化という課題への対応ではそれなりのコスト負担（IT資源のみならず、人的資源も含めて）が生じることは止むを得ないところです。

　それでは、最後にJ-SOXに対応するための具体的なプロセスを見てみることにしましょう。J-SOX法最大のポイントは、財務処理手続きそのものに誤りがないよう内部統制システムを構築する必要があるということです。つまり、財務報告が結果的に適正であったかどうかという視点から、財務プロセスそのものが適正であったかというプロセスの観点からの内部統制システムが必要になってくるわけです。そのプロセスですが、大きく３つに分けられるのではないかと思います。
　すなわち、�@内部統制の対象となる業務プロセスの特定、�A特定した業務手続の文書化並びに財務報告にかかるリスクの特定及び管理策の文書化、�C構築された内部統制の整備・運用状況の評価するというプロセスです。
　内部統制構築の最大のポイントは、業務やリスクを誰でもわかるように可視化することにあります。そのために業務プロセスを書いた「業務記述書」、業務プロセスや承認手続きなどを図示した「フローチャート図」、業務で発生するリスクやこれに対する予防策や低減策（コントロール手法）を記述した「リスク・コントロール・マトリクス」の３種類の文書を整備する必要があります。これらの文書化プロセスがおそらくもっとも工数を要する部分ではないかと思います。

　内部統制システム構築プロジェクトを簡単に図示すると、以下のようになるのではないかと思います。

　このような内部統制システム構築プロジェクトのプロセスを実現するために各企業で様々な取り組みがなされているところだと思います。
　大手企業では、既にERPパーケージ導入による内部統制ソリューションを導入しているところも多いように聞きます。確かにERPパッケージを活用すれば、生産、販売業務に対応したサブシステムを組みあわせ、あらゆる業務データを収集し蓄積することが可能となります。データの一元化が図れることにより、帳票の重複化や複雑化を避けられるという利点もあります。またカスタマイズにより、ERPパーケージにモニタリングシステム機能を組み込み、監査リポートなどを用意に作成することも可能のようです。また、あるソリューションベンダーでは、ワークフローの機能による内部統制システム構築コンサルティングを展開しているようです。このワークフロー機能を使えば、アクセスや承認権限の設定変更などを一元的に管理することも可能になるようです。このように、ともすると情報システムに組み込む内部統制（アプリケーションコントロール、インテグリティコントロール、セキュリティコントロール）フレームの確立は企業に多大なコスト負担を強いることにもなります。このようなトレンドに対して、ERPパッケージを導入すれば直ちにJ-SOX法に対応が完了するなどと努々考えてはならないと警鐘をならすエキスパートもいることを付記しておく必要があるかもしれません。モニタリング＆コントロールプロセスの可視化という機能を考えれば、むしろ、バランス・スコアカードの有効活用が考えられてもいいように思います。コックピット経営という標語にも表れているように、財務指標を含む経営に必要な視点を盛り込んだバランス・スコアカードこそは、常にジェット旅客機のコックピットのように定常的なモニタリング機能を果たすことができるからです。
　上に見てきたように、J-SOX法は、財務諸表の信頼性の担保という目的を達成するために何をなすべきかを真剣に考える好機を提供してくれたように思います。また、ITコーディネータにとっては、内部統制フレーム構築のためにどのような支援ができるのかが問われると同時に、ビジネス展開の好機が到来していると考えることができると思います。
　なお、最後にお断りを申上げておきたいと思います。10月25日現在で実務指針が公表されていない段階での分析ですので、今後実務指針が公表された後でここで述べたことについて訂正や修正が必要になる可能性もございますこと予めご了承いただきたいと存じます。また、内部統制監査と財務諸表監査における「内部統制の有効性の評価の検証」の相違、会社法の内部統制と金融商品取引法の内部統制の相違などについても、本来であれば検討が必要なところですが、CBKの範囲を超えることになりますので、取り上げませんでした。この点もご了承いただきたいと存じます。
　ＩＴ統制フレームとしてのCOBITやITILについては、また機会を改めて取り上げる予定です。

プロセスガイドラインVersion1.1【経営戦略フェーズ】のCBKにリスク・マネジメントが加えられたにより、経営戦略フェーズのプロセスも、より詳細に８つのプロセスになりました。具体的には、リスク・マネジメントはこのうちの3-5．リスク評価のプロセス（アクティビティ）になります。
すなわち、
　　　3-5-1.経営リスクの事前予防と発生を想定した予防
　　　3-5-2.経営リスクの発生と分析、対処
　　　3-5-3.経営リスクの実現による損失発生への対処
という３つの詳細プロセス（タスク）に落とし込まれています。

　ここで注目すべきは、この経営戦略フェーズにおけるリスク・マネジメントの対象は、全社的な、換言すれば、経営全体を通じてのリスク・マネジメントであり、個別の情報セキュリティや個人情報保護のみを対象にしているのではないという点です。ここに、ERM（Enterprise Risk Management:統合リスク管理）とう手法が必要になってくるわけです。
　そのＥＲＭの定義ですが、COSOの定義を引用し、一般に、「事業体の取締役会、マネジメントおよび他のスタッフの全てが関わるプロセスであり、事業体全体の戦略策定にも関連するとともに、事業体へ影響する可能性のある事象を識別し、事業体のリスク選定に応じて統合的にリスク管理を行い、事業体の目標達成に関して合理的な保証を提供することを目的とするプロセス」とされることが多いようです。ここに、COSO ERMがJ-SOX法対応のための有益なツールとして注目を浴びている理由があります。すなわち、経営者および取締役会にとってのERMは「保証」という機能を果たすことになり、また逆に、ERMを構築する場合には、それが経営者や取締役会にとって「保証」の機能を果たさなければ意味を成さないということになるからです。ただし、このＥＲＭが登場したからといって、従来のフレームワークに取って代わったわけではなく、従来のCOSOフレームワーク（内部統制フレームワーク）が補完的に拡張され、リスクの観点からマネジメントと内部統制が統合されているにとどまることには注意を要します。
より具体的には、下図COSO ERMの構造を示すキューブをご覧いただければわかるように、リスク許容度を経営や戦略の視点から設定・コントールすること、及び個々のリスクをポートフォリオという観点から統合管理することを意図しており、従来のフレームワークをいわば拡張したものと理解できます。
　

COSO ERMのキューブ
（COSO ERM Executive Summaryより）

　COSO ERMのフレームワークとしての特徴は、�@内部環境、�A目的設定、�B事象認識、�Cリスク評価、�Dリスク対応、�E統制活動、�F情報とコミュニケーション、�G監視活動、という８つの要素から成り、また、企業経営の目的として、1）戦略、2）業務活動、3）財務報告、4）コンプライアンスという4つのカテゴリが設定されている点です。ERMフレームワークには、事業体（全体）や部署（部分）といった「適用範囲」があり、それらが立方体（キューブ）の関係にあります。COSOフレームワークに比べると、目的に「戦略」が追加され、構成要素に「目的設定」が加わり、さらに「リスク評価」が「事象認識」「リスク評価」「リスク対応」に分割・詳細化されています。
　このように、COSO ERMは全社的な視点からリスク・マネジメントを実施する場合の非常に有益なフレームワークであるとともに、J-SOXで求められている内部統制フレームとしてもその機能を果たすべきことが期待されており、また、全社的にリスクを洗い出してこれらを評価し、これらのリスクに対して対策を漏れなく効果的に実施することがスコープになります。
　このように事前にリスク・マネジメントを実施するという手法そのものは、内部統制のためのフレームワークにも共通する理念であり、また、ISMSであろうとPMBOKであろうと、事前にリスクを洗い出し（識別し）、これらリスクの影響度を評価し（定性的リスク分析／定量的リスク分析）、これらのリスクに対する対応策を策定する（リスク対応計画／リスクの監視・コントロール）というプロセスに大きな差異はありません。ただCOSO ERMがそのリスク・マネジメントの対象を全社としており、なおかつ、事業体の目標達成に関して合理的な保証を提供することを目的としている点でJ-SOX法に対応できるその機能に注目が集まっているということができるのではないかと思います。これを、簡潔に図示したのが下図です。
　すなわち、コーポレートガバナンスという目的達成のための手段としてCOSO ERMがあり、コーポレートガバナンスの要素として内部統制があり、その達成手段としてCOSOの内部統制フレームがあり、内部統制の要素としてITガバナンスがあり、その達成手段としてCOBITやITIL、あるいはITSMがあり、さらにITガバナンスの要素としてISMSがあり、その達成手段としてISO/IEC27001がある、というふうにそれぞれが目的と手段の関係になるのではないかと思います。上位概念としてのコーポレートガバナンスの中に、内部統制も、ITガバナンスも、そしてまたCSRも包含されると考えると、最終的に目指すべきはいかにしてコーポレートガバナンスを構築するのかということに尽きるのではないかと思います。その最終目的を達成するために、それぞれのフレームワーク／ツールを有効に活用するというふうに考えると、コーポレートガバナンスとITガバナンスの関係も、あるいはCOSOとCOSO ERMとの関係も、COSOやCOBIT、COBITやITILとの関係もすっきり整理されてくるのではないでしょうか。

　「コーポレートガバナンスとＩＴガバナンスとの関係図」

　なお、J-SOX法対応に必要とされる「IT統制」の具体例について、経済産業省（経産省）が2007年3月20日、システム部門向けに「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」を公表していますので、是非こちらもご参照いただきたいと思います。経産省は指針を作成した目的について、「システム管理基準等を活用している企業が、財務報告にかかる内部統制に必要な『ITへの対応』を行うために、システム管理基準等と『ITへの対応』との具体的な対応関係を明確すること」と説明しています。この　追補版は、(1)本追補版の構成と用語について、(2)IT統制の概要について、(3)IT統制の経営者評価、(4)IT統制の導入ガイダンス（IT統制の例示）、という4章で構成されており、約150ページほどあります。経産省が公表している「システム管理基準」や「情報セキュリティ管理基準」に加えて、日本版SOX法対応の実務指針として2007年2月15日に金融庁企業会計審議会内部統制部会が公表した「財務報告にかかる内部統制の評価および監査に関する実施基準」との対応関係も明記されています。