itスキル標準&研修改善報告書 -...

IT スキル標準＆研修改善報告書

© 2005-2006 独立行政法人情報処理推進機構（IPA） 1

IT スキル標準&研修

改善報告書

ＩＴスキル標準®

プロフェッショナル・コミュニティ®

プロジェクトマネジメント委員会

２００５年度版



・“PMI”と PMI のロゴは、米国及びその他の国で登録された Project Management Institute のサービス商標

（service and trademarks）です。

・“PMP”と PMP のロゴは、米国及びその他の国で登録された PMI®の資格のマーク（certification marks）で

す。

・“PMBOK”は、米国及びその他の国で登録された PMI®の商標です。

PMBOK®の内容に関する記述は、PMI®に著作権があります。

・“PMR”は、特定非営利活動法人プロジェクトマネジメント資格認定センター（PMCC)の登録商です。

・“PMAJ”は特定非営利活動法人日本プロジェクトマネジメント協会の登録商標です。

● 本報告書に記載されている「ＩＴスキル標準®」および「プロフェッショナルコミュニテ

ィ®」は、独立行政法人情報処理推進機構（ＩＰＡ）の登録商標です。また、社名およ

び製品名は、それぞれの会社の商標です。なお、本文中では「ＴＭ」、「®」表示は省略

しています。

● 本報告書に記載されているＷｅｂページに関する情報（ＵＲＬ等）については、予告な

く変更、追加、削除（閉鎖）等される場合があります。あらかじめご了承願います。



CONTENTS

はじめに

１．改善提案における前提条件

１．１プロジェクトマネジメントの役割と範囲

１．２プロジェクトマネジメント能力の定義

１．３プロジェクトマネジメントレベルの概念

２．改善検討と提言

２．１ＰＭ職種の説明と専門分野

１）職種の説明について

２）システム開発/アプリケーション開発/システムインテグレーションについて

３）e ビジネスソリューションについて

４）ソフトウェア開発について

５）アウトソーシングについて

６）ネットワークサービスについて

２．２ＩＴ投資の局面と活動領域、職種の説明

２．３達成度指標

２.３.１ 2004 年度提言

２.３.２ 2005 年度提言

２．４スキル領域

２.４.１ 2004 年度提言

２.４.２ 2005 年度提言

２．５スキル熟達度・知識項目

２.５.１ 2004 年度提言

２.５.２ 2005 年度提言

２．６改善提案サマリー

３．研修ロードマップ

３．１前提

３．２討議内容と改善理由

３．３改善提案

４．今後の課題と提言

添付資料



資料１－１プロフェッショナルコミュニティＰＭ委員会の紹介

資料２－１改善提案サマリー

資料２－２ＩＴスキル標準達成度指標改善提言版（職種：プロジェクトマネジメント）

資料３－１研修コース変更に対する改善提案内容

資料３－２研修ロードマップ・新規追加コース概要

資料３－３研修ロードマップ改善提案内容と理由



はじめに

独立行政法人情報処理推進機構（IPA）ＩＴスキル標準センターでは、第一線で活躍しているハイレ

ベルなスキルを持つ者同士が、社内や組織の論理にとらわれず建設的に情報交換や議論が行えるような

場において、ＩＴスキル標準の改訂、人材育成のあり方等、次世代ＩＴサービス・ビジネスを担う後進

人材のスキルアップに貢献するための諸活動を行う目的で「ＩＴスキル標準プロフェショナルコミュニ

ティ」を創設しました。

そして２００４年７月にＩＴアーキテクト委員会に続きプロジェクトマネジャーのプロフェショナ

ルコミュニティである「プロジェクトマネジメント委員会（略称：ＰＭ委員会：委員会メンバーは添付

資料１－１参照）」が活動を開始しました。

さらに、ＰＭ委員会の下に２種類の WG グループ（WG1：ＩＴＳＳ＆研修改善ＷＧ、WG2：ＰＭ

育成ガイド作成ＷＧ）を立ち上げ、下記に示されるメンバーにて下記目的及び内容を討議するため会議

を開催し、「ＩＴスキル標準（Ver1.1 及び 1.2）と研修ロードマップ（Ver1.2）」のプロジェクトマ

ネジメント部分を対象に検討及び確認しました。

なお、2005 年度はＩＴスキル標準＆研修ロードマップ（Ver.2）の公式発表に伴う作業に並行して

2004 年度の PM 部分の提案についても検討及び確認をしました。

・WG 名称：ＩＴＳＳ＆研修改善点ＷＧ（WG1）

・ＷＧ１グループメンバー：平成１８年２月現在におけるメンバー及び所属

（○はリーダ）は次の通りです。

井沢澄雄日本電気株式会社

乾諭史日本アイ・ビー・エム研修サービス(株)

〇向後忠明ＮＴＴリース株式会社

澤田友宏株式会社日立製作所

土出克夫富士通株式会社

丹羽武志株式会社インテック

橋爪宗信株式会社ＮＴＴデータ



// 本報告書の目的 //

本報告書はＰＭ委員会の 2004 及び 2005 年度活動の活動を通して、下記に示す目的にてＩＴスキ

ル標準（Ver1.1 及び 1.2）と研修ロードマップ（Ver1.2）のプロジェクトマネジメント部分を第一線

で活躍しているプロジェクトマネジメント・プロフェショナルの視点からその改善点を提言したもので

す。

＜今回の改善提言対象＞

プロジェクトマネジメントの職種の概要及び専門分野

ＩＴ投資の局面と活動領域

プロジェクトマネジメントのスキル領域

プロジェクトマネジメントの達成度指標

プロジェクトマネジメントのスキル領域・熟達度・知識項目

研修ロードマップ

// 作業内容 //

下記内容の検討及び確認作業を上記の各提言対象に対して行いました。

プロジェクトマネジメントの専門分野のチェックとレベル確認

職種の説明の確認

達成度指標の各指標の精査（責任制、複雑性、サイズ、タスク特性）

スキル領域の確認（スキル項目の過不足チェック）

スキル熟達度・知識項目の確認

プロジェクトマネジメント対象範囲の拡大に関する提案

ＩＴスキル標準 Ver．2 公式発行に際してのレビュー及び追加提案

研修ロードマップの確認

//報告書作成方針 //

2005 年度の IT スキル標準＆研修改善報告書は 2004 年度の報告書の改訂版として纏めました。

① 200５年度のＰＭ委員会報告書（ＩＴスキル標準&研修改善報告）の内容はＩＰＡより公式に発行

される「ＩＴスキル標準 Ver１．2」にベースに 2004 年度及び 2005 年度において PM 委員会

にて発案され、合意された内容を前提に、2005 年度の報告書として纏めました。

② 公式「ＩＴスキル標準改訂版（Ver．２）」に関連するドラフティンググループ及び改訂委員会で

の検討結果についても上記①の方針・前提にて 2005 年度の報告書に追加及び変更で記述しました。

③ 200４年度の検討課題としていた研修ロードマップについては本報告書（2005 年度ＩＴスキル標

準＆研修改善報告書）に新たに項を追加し、記述しました。



１．改善提案における前提条件

ＩＴスキル標準（Ver1.1 及び１.２）と研修ロードマップ（Ver1.2）の改善点を提言するにあたり、

その前提条件としてプロジェクトマネジメントの下記に関する項目について議論し、メンバーの合意及

びＰＭ委員会での了承を得ながら、その改善提案を行ないました。

１．１プロジェクトマネジメントの役割と範囲

１）役割と範囲

プロジェクトマネジメントの役割と範囲が企業によって異なっています。この部分を整理しなが

ら、明確化することにしました。

■役割

プロジェクトマネジメントは下記に示す目標の管理であり、そのため下記に示す役割範囲内にお

ける目標と仕事の内容の整理が必要との考えから検討を行いました。

■範囲

プロジェクトマネジメントの役割範囲については委託側と受託側の関係があり、その業務内容も異な

ってきます。本報告書は図 1.1－１に示す受託側から見たマネジメントについて検討を行いました。

（ただし、将来はその上流側であるエンタープライズマネジメント（委託側）の部分も含めて検討し

ます）

２）対象機能の整理

プロジェクトマネジメントの役割と範囲の中でＰＭに求められる必要なマネジメントスキル及

び特性要件を以下の前提での整理

・目標マネジメント（スコープ、スケジュール、品質、コスト、統合マネジメント）

・支援マネジメント（組織マネジメント、コミュニケーションマネジメント、リスクマネジメン

ト、調達マネジメント）

委託側事業化検討

フェーズ

委託側技術検討・

設計・調達フェーズ受託側提案フェーズ

プロジェクト

終フェーズ労

働

力

投

入

度（

関

連

要

員）

・委託側プロジェクト

　チーム編成

・情報化企画

（委託側）

・事業化妥当性検討

・委託側設計

・技術要件と

　委託側PJ計画

・調達要求書作成

（RFP）

・受託側プレゼン

　テーション

・引合書の発行

・提案活動（含む

情報化企画：

受託側）

・評価（委託側）

・技術

・契約交渉

・性能試験

・検収

・試運転

・契約内容の確認

（スコープ/契約条件

/技術要件の確認）

・プロジェクト作業

の明確化（WBS）

・スケジュール/予算

の確定

・プロジェクトチーム

の編成とスタッフの

配置

・基本設計

・調達

・詳細設計

・製造/プログラム

/各種試験

・搬送

・据付／導入.

・各種試験/検査

プロジェクト実行フェーズ

：受託側負荷曲線

：委託側負荷曲線

図1.1－１　委託者側/受託者側のプロジェクトマネジメント範囲

契

約

プ

ロ

ジェ

ク

ト

計

画

検

収



１．２プロジェクトマネジメント能力の定義

プロジェクトマネジャーの能力を定義するにはその背景にある組織を考慮する必要があります。しか

し、結果としてＩＴスキル標準がダブルスタンダード化するので組織の規模は考慮せず、あくまでも個

人の能力を議論の対象としました。例えば大規模なＩＴ企業であれば、ＰＭＯ（プロジェクトマネジメ

ントオフィス）といった、プロジェクトマネジャーを組織的に支援する仕組みや潤沢な要員リソースを

用いて、長期にわたる大規模プロジェクトを着実に遂行することが前提となるかも知れません。また、

中小規模のＩＴ企業ではひとりのプロジェクトマネジャーが短期間で多くのプロジェクトを効率よく

推進する能力が前提となるかも知れません。それらの前提毎にＩＴスキル標準を見直す意見も出ました

が、複数の標準を維持することは好ましくないと判断しました。

そのため、プロジェクトの規模や複雑性等のパラメータを複合させて、企業規模や対象プロジェクト

の性質に関係なくプロジェクトマネジャーの能力定義ができるような仕組みを考慮しながら検討しま

した。

１．３プロジェクトマネジメントレベルの概念

プロジェクトマネジメントのレベル概念は以下の通りですが、レベル 7 のあり方も含めそれぞれの違

いが明確になるように検討を進めました。

・レベル１、２：レベル設定を行わない（設置しない）

・レベル３：エントリーレベル（プロジェクトメンバ：ＰＭ見習いとし、この時点ではプロジ

ェクトサイズについての考慮は不要とします。そして、ＰＭは実質的にレベル

４からという前提としました）

・レベル４：ミドルレベル

・レベル５、６：ハイレベル

・レベル７：スーパーハイレベル

なお、プロジェクトサイズがレベル決定の主な決め手となっているのでそれ以外の要素についての定

義付けも検討しました。

また、ＰＭ委員会の２００５年度の活動結果により,さらに改善の提案を行い、ＩＴスキル標準及び研

修ロードマップへの反映も行いました。



２．改善検討と提言

本章はすでに発表されているＩＴスキル標準（Ver1.1 及び 1.2）と研修ロードマップ（Ver1.2）のＰＭ

部分における記述について具体的改善点を WG 内にて討論を行い、その具体的改善点を示したものです。

なお、2.1 節はＰＭ職種の説明と専門分野について改善提案を行い、2.2 節以降では、2.1 節にての改善

提案項目を前提として検討を行いました。

２．１ＰＭ職種の説明と専門分野

現在のＩＴスキル標準の専門分野の分類方法および名称に関しては、違和感を覚えるとの意見が多い

ため、本 WG では、まずプロジェクトマネジャーに求められる能力という観点から、専門分野の分類と

いう概念に関し、妥当性の議論を行いました。

基本的にプロジェクトマネジャーに求められる能力は、プロジェクトのタイプに係らず共通要素が多

いため、専門分野を設けるのは妥当ではないとの議論がありました。しかし、ＩＴ企業のサービス形態

として、システムインテグレーション、ネットワークサービス、アウトソーシング、ソフトウェア製品

開発という分類が存在することからも、専門分野をプロジェクトマネジャーの実務形態としての「ジョ

ブカテゴリー」という概念でとらえるならば、妥当であるという結論に至りました。また、専門分野と

いう枠組みは、育成面の観点からも有効に機能することが本 WG で合意を得ました。

例えばアウトソーシングのプロジェクトマネジャーの達成度指標はレベル 6 以上となっていますが、

これは当該分野を担当できるプロジェクトマネジャーが、それまでに他の専門分野を経験することを前

提としたキャリアパスを期待されているからです。

以上の基盤となる議論を踏まえ、現状のプロジェクトマネジャー職種の説明および、専門分野として

規定されている５項目を討議テーマとし、各論ベースで改善点の討議を行いました。

下記に、テーマ毎の討議内容および改善提案を記載します。


２）システム開発／アプリケーション開発／システムインテグレーションについて

３）ｅビジネスソリューションについて







【討議内容】

職種の説明に関し、ＩＴスキル標準では「プロジェクトの立ち上げ、計画策定、遂行及び進捗管理

を実施し、契約上の納入物にも責任を持つ」と定義されています。しかしながらプロジェクトマネジ

メントは、顧客だけではなく、社内ユーザも対象とするケースも多いので、契約上という記述を削除

すべきではないか、またプロジェクトマネジメントの重要な責務である品質、コスト、納期の遵守に

関してさらに強調すべきではないか、という点について討議を行いました。

【改善提案】

職種の説明に関する定義として、下記の通り提案いたします。

●現状

プロジェクトの立ち上げ、計画策定、遂行および管理を実施し、契約上の納入物にも責任を持つ。

●2004 年度改善案

プロジェクトの提案、立ち上げ、計画策定、遂行及び進捗管理を実施し、計画された納入物・サー

ビス及びその品質（Ｑ）・コスト（Ｃ）・納期（Ｄ）に責任を持つ。

●2005 年度改善案

プロジェクトマネジメント関連技術を活用し、プロジェクトの提案、立上げ、計画策定、遂行及び

進捗管理を実施し、計画された納入物・サービス及びその品質（Ｑ）・コスト（Ｃ）・納期（Ｄ）

に責任を持つ（下図 2．1－１参照）。



プロジェクトマネジメント関連技術を活用し、プロジェクトの提案、立上げ、計画、実行、監視コントロール、終結を実施し、計画された納入物・サービスおよびその要求品質、コスト、納期に責任を持つ。

ＩＴ投資の局面においては、戦略的情報化企画（課題整理、分析(ビジネス、IT)、ソリューション設計(構造、パターン)）、開発（コンポネント設計(システム、業務)、ソリューション構築(開発、実装)）及び運用、保守（ソリューション運用(システム、業務)、ソリューション保守(システム、業務)）を主な活動領域として以下を実施する。

－戦略的情報化企画・情報化企画（ＩＴアウトソーシング、ソフトウェア製品開発専門分野）・プロジェクト計画の策定

－開発・プロジェクトの管理、統制

－運用、保守・プロジェクトの管理、統制

当該職種は、以下の専門分野に区分される。 ●システム開発

ITシステムの提案、開発、保守に関わるプロジェクトマネジメントを行う（ＩＴシステムとして要求される機能を実現するためのソフトウェアを開発し、コンピュータ及びネットワーク環境を構築する。インターネットテクノロジを使用したものを含む）。

●ＩＴアウトソーシング顧客の経営戦略を受けて、外部組織としてＩＴシステムの企画、構築、保守、システム運用、サポート運用、業務運用に関わるプロジェクトマネジメントを行う。

●ネットワークサービスデータ(LAN/WAN)、画像、映像等の通信環境の設計、導入及び管理に係るプロジェクトマネジメントを行う。

●ソフトウェア製品開発不特定多数のユーザを対象としたソフトウェア製品の企画、設計、開発、改良および保守に関わるプロジェクトマネジメントを行う。

図２．１－１職種の説明




【討議内容】

システム開発／アプリケーション開発／システムインテグレーションの表記を統一することがで

きないか？

これらの用語は、利用者により、使われ方が統一されていないため、現在は併記されています。定

義を厳密に行うのであれば、個々を独立させることも可能ですが、むしろ統一的な定義を行うことに

より、ひとつにまとめた方が利用者にとってわかりやすいと思われます。当該専門分野の場合、シス

テムエンジニアリングとソフトウェアエンジニアリングを包含するものとして捉え、「システム開発」

と呼称することが適当であると思われます。内容については、システムインテグレーションの観点か

ら、対象職務フェーズを提案から保守までとすること、インフラ構築を含めること、ならびにｅビジ

ネスソリューションの観点から、適用技術に関する事項を盛り込み、包括的な記述としてはどうか

等々の意見がありました。

【改善提案】

システム開発／アプリケーション開発／システムインテグレーションおよびeビジネスソリューシ

ョンは、「システム開発」に統合されるものとしました。また、コンピュータ・ネットワーク環境及

び付帯設備の構築を含むものとします。名称を「システム開発」と改称し、定義の改訂を下記の通り

提案いたします。

● 現状

ＩＴソリューションの設計、開発に係るプロジェクトマネジメントを行う。

● 改善案

ＩＴシステムの提案・開発・保守に係わるプロジェクトマネジメントを行う（ＩＴシステムと

して要求される機能を実現するためのソフトウェアを開発し、コンピュータ・ネットワーク環境

及び付帯設備を構築する。インターネットテクノロジを使用したものも含む）。




【討議内容】

ｅビジネスソリューションは、固有技術のひとつである Web 技術を駆使したシステム開発との意

味合いが強いので、専門分野「システム開発」に含めてもよいのではないか？

“ｅビジネス“の定義は、インターネットテクノロジやＷｅｂ技術を活用したビジネス形態である

が、すでに一般的なシステム開発においても、同技術が活用されることが多くなってきています。ま

た、ビジネスソリューションの観点から、通常コンサルタントが実施する事業検討フェーズを除くな

らば、システム開発と大差はありません。よって、ｅビジネスと一般的なビジネスシステム開発を分

ける必要性はないと思われます。

【改善提案】

ｅビジネスソリューションは、専門分野「システム開発」に含まれるものと定義し、専門分野から

削除することを提案いたします。ただし、「システム開発」の定義にインターネットテクノロジの活

用を含む趣旨を盛り込むものとします。（システム開発／アプリケーション開発／システムインテグ

レーションの項参照）




【討議内容】

① ソフトウェア開発という名称は、システム開発との相違がわかりづらいのではないか？

システム開発は、ある特定のユーザ向けの開発であるのに対し、ソフトウェア開発は不特定

多数のユーザを対象としたものを意図しています。例えば、市販製品を作るのが、ソフトウェ

ア開発であり、その市販製品を用いて特定顧客向けのカスタマイズなどを行うのがシステム開

発であると理解してよいと考えます。したがって、現在の名称を「ソフトウェア製品開発」と

改訂すれば、この相違が比較的明確になるものと思われます。

② ソフトウェア開発に組込系ソフトを考慮すべきではないか？

当該専門分野のソフトウェアはそれ自体が終製品をイメージしており、何らかの製品に組

み込まれる「組込系ソフト」とは異なります。組込系は別委員会で検討されているため、本

WG の検討対象外とします。

③ ソフトウェア開発にレベル７がないが、検討すべきではないか？

近年のソフトウェア製品開発は大規模、複雑かつ短納期なものであることから、システム開

発と並び、レベル７が定義されてしかるべきです。

【改善提案】

ソフトウェア開発は、ソフトウェア製品の開発を意味するので、それを識別しやすくするために、

名称を「ソフトウェア製品開発」と改称し、定義の改訂を下記の通り提案いたします。また、当該専

門分野におけるプロジェクトマネジャーの高レベル能力の必要性を勘案し、新たにレベル７を新設す

ることを提案します。

● 現状

ソフトウェア製品の設計、開発、改良及び保守に係るプロジェクトマネジメントを行う。

● 改善案

不特定多数のユーザを対象としたソフトウェア製品の企画・設計、開発、改良及び保守に係る

プロジェクトマネジメントを行う。




【討議内容】

① アウトソーシングという名称は、広範な印象を与えるため、プロジェクトマネジャーの職務範

囲が特定しづらいのではないか？

ＩＴスキル標準におけるアウトソーシングは、単に運用のアウトソーシングや、開発のアウ

トソーシングではなく、長期にわたる事業検討から運用フェーズまでのライフサイクルに対応

する広範囲なものを意図しています。そのため、そのような名称と、定義に改訂することが好

ましいと思われます。

② アウトソーシングに運用フェーズを含めると、ＩＴＩＬの領域を加味する必要があるのではな

いか？

現状のＩＴスキル標準には、ＩＴＩＬは加味されていませんが、アウトソーシングのプロジ

ェクトマネジャーはＩＴＩＬ等を理解した上で、マネジメントすべきです。ただし、ＩＴスキ

ル標準にＩＴＩＬや他のメソドロジを安易に取り込むと、それらの改訂時の対応が煩雑となり、

好ましいとはいえません。

※ ITIL （Information Technology Infrastructure Library）

③ アウトソーシングでは、育成面を考慮し、下位のレベルから定義してはどうか？

アウトソーシングのプロジェクトマネジャーは、顧客の経営戦略を受け、ＩＴシステムの企

画から運用までを含むフルアウトソーシングを職務範囲としているため、要求されるレベルは

必然的に高いものです。このため、プロジェクトマネジャーの他の専門分野でキャリアを積ん

だ後、当該専門分野へ移行するキャリアパスを提示すれば、現在のレベル付けは妥当であると

言えます。

【改善提案】

プロジェクトマネジャーの専門分野としてのアウトソーシングは 10 年スパンで考えると、運用を

含めたＩＴシステムのフルアウトソーシングを意味するものとなります。よって専門分野名称を「Ｉ

Ｔアウトソーシング」と改称し、定義の改訂を下記の通り提案いたします。

● 現状

情報システム環境の改善を通じた情報システムの効果的な運用に係るプロジェクトマネジメ

ントを行う。管理対象として、アプリケーション開発、保守、システム運用、サポートデスク運

用、業務運用などが含まれる。

● 改善案

顧客の経営戦略を受けて、外部組織としてＩＴシステムの企画・構築・保守、システム運用、

サポートデスク運用、業務運用に係るプロジェクトマネジメントを行う。




【討議内容】

① ネットワークサービスにもレベル７の定義が必要なのではないか？

過去の電気通信技術であれば、レベル７に相当する技術者もいましたが、現在は既存の設備

を用いてシステムを構築することがほとんどであるため、現状通りのレベル設定でよいと思わ

れます。しかし、検証が必要であるという結論になりました。

そこで、ネットワークの専門家に参画いただき、再度議論を行った結果、レベル７追加の必

要性の議論を行いました。

② システム開発では、ネットワーク環境や付帯設備の構築等も含まれるので、当該分野を削除し、

システム開発に統合したほうがよいのではないか？

システム開発にはソフトウェアの開発が伴うので、ネットワークサービスをシステム開発に

含めると、やや違和感があります。例えば、ネットワーク系の企業のプロジェクトマネジャー

はシステム開発を行っているわけではなく、あくまでもネットワークの構築を専門としている

ため、当該職種を独立した専門分野として定義していることは妥当です。ただし、システムイ

ンテグレーションでは当該作業も含まれるため、「システム開発」の定義にネットワーク環境

や付帯設備の構築等を加えればよいと考えられます。

③ カスタマーサービスのファシリティマネジメントとの相違が明確でない

ネットワークサービスが存在する一方で、インフラ構築サービスがあれば、ファシリティマ

ネジメントとの相違も一層明確になるものと思われます。しかし、今回は「システム開発」「Ｉ

Ｔアウトソーシング」「ネットワークサービス」「ソフトウェア製品開発」の４専門分野で検

討を進めることとし、インフラ構築については、専門分野として含めません。

【改善提案】

ネットワークサービスについても新技術を用いた構築など、難易度の高いサービスも存在します。

また、管理する要員数がピーク時で 500 人以上、もしくは導入作業拠点数が 1000 拠点以上といっ

た大規模プロジェクトや国際的なプロジェクトにおいてはマネジメントの難易度も高く、レベル７の

定義も必要だと考えられます。



以上１）から６）までの改善提言をまとめるとのようになります。

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

専門分野

システム開発

ＩＴアウトソーシング

ネットワークサービス

ソフトウェア製品開発

レベル７

レベル６

レベル５

レベル４

レベル３

レベル２

レベル 1

職種の説明

プロジェクトマネジメント関連技術を活用し、プロジェクトの

提案、立上げ、計画、実行、監視コントロール、終結を実施し、計

画された納入物・サービスおよびその要求品質、コスト、納期に責

任を持つ。

ＩＴ投資の局面においては、戦略的情報化企画（課題整理、分析

(ビジネス、IT)、ソリューション設計(構造、パターン)）、開発（コ

ンポネント設計(システム、業務)、ソリューション構築(開発、実

装)）及び運用、保守（ソリューション運用(システム、業務)、ソ

リューション保守(システム、業務)）を主な活動領域として以下を

実施する。

－戦略的情報化企画

・情報化企画（ＩＴアウトソーシング、ソフトウェア製品開発

専門分野）

・プロジェクト計画の策定

－開発

・プロジェクトの管理、統制

－運用、保守

・プロジェクトの管理、統制

当該職種は、以下の専門分野に区分される。

●システム開発

ITシステムの提案、開発、保守に関わるプロジェクトマネジメン

トを行う（ＩＴシステムとして要求される機能を実現するための

ソフトウェアを開発し、コンピュータ及びネットワーク環境を構

築する。インターネットテクノロジを使用したものを含む）。

●ＩＴアウトソーシング

顧客の経営戦略を受けて、外部組織としてＩＴシステムの企画、

構築、保守、システム運用、サポート運用、業務運用に関わるプ

ロジェクトマネジメントを行う。

●ネットワークサービス

データ(LAN/WAN)、画像、映像等の通信環境の設計、導入及び管

理に係るプロジェクトマネジメントを行う。

●ソフトウェア製品開発

不特定多数のユーザを対象としたソフトウェア製品の企画、設

計、開発、改良および保守に関わるプロジェクトマネジメントを

行う。

図 2.1－２職種の概要と専門分野の改善のまとめ



２．２ＩＴ投資の局面と活動領域、職種の説明

１）討議内容

プロジェクトマネジメントにおけるＩＴスキル標準で定義された各局面とその活動領域に関し

て議論をしました。

■戦略的情報化企画局面での活動について

「表 2.２-1ＩＴ投資の局面と活動領域の関係」を時間軸で捉えるとプロジェクトマネジメント

の重要な活動は、ソリューション設計から始まります。従って特に課題整理/分析局面に関して

下記の議論をしました。

●システム開発、ネットワークサービスのこの局面での活動の有無

●ＩＴアウトソーシング、ソフトウェア製品開発では、プロジェクトの計画を策定するので

は無く製品開発やフルアウトソーシングの活動の延長線上で製品や戦略の情報化企画を

する局面では無いか

■プロジェクト基本計画について

プロジェクト基本計画は、プロジェクト計画の一部であり表現として不正確ではないかとの問

題提起が有り検討しました。またプロジェクト計画は、全てのプロジェクトで管理統制に入る前

に策定が必要です。そのタイミングについて課題整理/分析局面ではなくソリューション設計で

の活動とすべきでないかを議論しました。

さらに計画の変更/策定は、戦略的情報化企画、開発、運用のいずれの局面でも実施されるべ

き活動ですので全ての局面に記述することも検討しました。しかしながらプロジェクトマネジメ

ントの主たる活動を考慮すると、計画の策定は戦略的情報化企画局面での重要な活動です。従っ

てこの局面だけにおける記述の妥当性について議論をしました。また計画の策定は、プロジェク

トマネジメントの主要な活動にも関わらず「プロジェクト基本計画の作成」がプロジェクトマネ

ジメントの従たる活動になっているのはおかしいとの指摘があり、主たる活動に変更することを

決定しました。

■戦略的情報化企画の名称について

ＩＴアウトソーシング以外では、当局面の「戦略的」という言葉は不適切であり、プロジェク

トマネジメントの観点から変更すべきとの問題提起がありました。しかしながら、この名称はＩ

Ｔアーキテクトやコンサルタントの職務範疇として適切かつ必要であるのでそのまま残す事で

合意しました。

さらに、これらの職種がプロジェクトマネジメントの前段階としてプロジェクトに参加していれ

ば問題は無いのですが、現実的には参加していないケースが多々あります。その場合は、プロジ

ェクトマネジメントが当活動を兼務することになり、「戦略的に情報化を考える必要がある」と

の意味合いで変更する必要はないと結論しました。



■経営戦略策定局面について

ＩＴアウトソーシングやソフトウェア製品開発では企画以前の経営戦略策定の段階からプロジ

ェクトマネジメントが入っている必要が有ります。しかし、この局面でのプロジェクトマネジメ

ント共通の活動として意見を集約するには今後さらに検討を重ねる必要があります。

システムの

運用と管理

システムの

運用と管理

運用計画/運用管理

の策定

オペレーション

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の導入

導入計画

の策定

カスタマ

サービス

ｱﾌﾟﾘｹｰｼｮﾝ

ｺﾝﾎﾟﾈﾝﾄ

の保守



の運用



の開発



の設計


開発計画の策定

アプリケーション

スペシャリスト

システムの

保守

システムの

運用

システムの

導入構築

システム・コンポネントの

設計

システム構築計画の策定

ITスペシャリスト

プロジェクトの

管理/統制


管理/統制


管理/統制


管理/統制


管理/統制

プロジェクト基本計画の策定

プロジェクト

マネジメント

ソリューションの構築

コンポネントの設計

ソリューションアーキテク

チャーの設計

ソリューションの枠組み策定

ＩＴ

アーキテクト

ソリューションの設計

ソリューション策定のための

助言

ビジネス戦略策定の助言

目標/ビジョン

の提言コンサルタント

ビジネス課題

ｿﾘｭｰｼｮﾝ提案

ビジネス

戦略の確認

目標/ビジョン

の確認セールス

ソリューション

保守

（ｼｽﾃﾑ/業務）


運用



構築

（開発/実装）

コンポネント

設計

(ｼｽﾃﾑ/業務）


設計

(構造/ﾊﾟﾀｰﾝ)

課題

整理／分析

（ビジネス/ＩＴ）

ビジネス

戦略策定

経営目標／

ビジョン策定

運用・保守開発戦略的情報化企画経営戦略策定ＩＴ投資の局面

と活動領域

職種

ＩＴ投資の局面と活動領域の関係

主たる活動局面従たる活動局面

表２．２－１ＩＴ投資の局面と活動領域の関係



２）改善提言

① 現在のＩＴスキル標準で示されている活動領域の「プロジェクト基本計画の策定」は、プロジ

ェクトマネジメントの観点からは不正確です。そのために下記の通り変更することを提言します。

■ 「プロジェクト基本計画の策定」を削除する

■ 管理統制に必要な計画として定義し「プロジェクト計画の策定」と変更する

■ プロジェクトマネジメントの主たる活動局面とする

■ タイミングはソリューション設計の局面に位置づける

② 課題整理/分析局面での活動は、専門分野を 2 種類に大別し下記の通り変更することを提言し

ます。

■ システム開発及びネットワークサービス

特に活動は定義しない

■ ＩＴアウトソーシング及びでソフトウェア製品開発

・課題の整理、分析を継続的に実施しますので、この局面での活動を「情報化企画」と

する

・プロジェクトマネジメントの従たる活動局面とする

（参照：「表２．２－２ＩＴ投資の局面と活動領域の関係の新提案」）

システムの

運用と管理

システムの

運用と管理

運用計画/運用管理

の策定

オペレーション

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の保守

ハードウェア

ソフトウェア

の導入

導入計画

の策定

カスタマ

サービス



の保守



の運用



の開発



の設計


開発計画の策定

アプリケーション

スペシャリスト

システムの

保守

システムの

運用

システムの

導入構築

システム・コンポネントの

設計

システム構築計画の策定

ITスペシャリスト


管理/統制


管理/統制


管理/統制


管理/統制


管理/統制

プロジェクト基本計画の策定

プロジェクト

マネジメント

ソリューションの構築

コンポネントの設計

ソリューションアーキテク

チャーの設計

ソリューションの枠組み策定

ＩＴ

アーキテクト

ソリューションの設計

ソリューション策定のための

助言

ビジネス戦略策定の助言

目標/ビジョン

の提言コンサルタント

ビジネス課題

ｿﾘｭｰｼｮﾝ提案

ビジネス

戦略の確認

目標/ビジョン

の確認セールス


保守



運用



構築

（開発/実装）

コンポネント

設計

(ｼｽﾃﾑ/業務）


設計

(構造/ﾊﾟﾀｰﾝ)

課題

整理／分析

（ビジネス/ＩＴ）

ビジネス

戦略策定

経営目標／

ビジョン策定

運用・保守開発戦略的情報化企画経営戦略策定ＩＴ投資の局面

と活動領域

職種

ＩＴ投資の局面と活動領域の関係

主たる活動局面従たる活動局面

プロジェクト計画の策定

情報化企画

なし

ＩＴアウトソーシング/

ソフトウェア製品開発

システム開発/

ネットワークサービス

表２．２－２ＩＴ投資の局面と活動領域の関係の新提言




２．３．１２００４年度提言

「達成度指標」はスキルを客観的に観察する指標として、各専門分野のレベルごとに要求される経験

と実績を定義したものです。具体的には各「実務能力」レベルのプロフェッショナルとして認められる

ために必要かつ当該レベルのプロジェクトを成功裏に完了した経験と実績の要件として定義していま

す。指標の切り口には「タスク特性」・「サイズ」・「複雑性」・「責任性」の４つを取上げています。

当 WG ではこれらの達成度指標について、まず４つの切り口を議論し、次いで専門分野別のレベルご

とにその内容を検討し、現実との乖離があるもの、感覚的に合わないものについて改善案を提示するこ

とにしました。

主な検討・討議内容、及び個々の改善提案について、以下に記述します。

１）討議内容

1-1）プロジェクト難易度と達成度指標の関係

プロジェクトマネジメントを成功裏に完遂するには“プロジェクトの難易度が大きく作用する”

との共通認識から、難易度に影響を与える要因を挙げ、ＩＴスキル標準の達成度指標との比較検討

を行ないました。表-2.３.1 にその対応を示します。

表-2.３―1 プロジェクトの難易度に影響を与える要因と達成度指標

上記の要因をさらに分解し、達成度指標との関係性を検討しましたが、結果はＩＴスキル標準に

示される達成度指標がこれらの一般的に考えられる難易度の要因とは大きな齟齬がないことが検証

されました。

ただし、達成度指標の中で「サイズ」については「プロジェクト規模」としてはどうかとの意見

がありましたので、ご検討ください。

1-2）達成度指標についての議論

4 つの達成度指標については精査が必要との提起がされました。たとえば、複雑性については、

・プロジェクト経験は「回数」ではなく、「経験年数」を考慮する必要はないか？

難易度に影響を与える要因ＩＴスキル標準の達成度指標

① プロジェクトを取り巻く環境条件 ① 責任性

② プロジェクトそのものに含まれる各種条件 ② プロジェクトの複雑性

③ 企業のポリシー、トップの指示、 ③ プロジェクトのサイズ

ビジネスの目的 ④ タスク特性

④ 企業の対応能力



・プロジェクト体制に関して、「顧客特性」を考慮する必要はないか？

・プロジェクト立上げ時点での「要求仕様明確度」や「要求仕様明確可能性」を評価指標にでき

ないか？

といった問題提起でした。

これらの提起を含め、各専門分野・レベルごとに達成度指標の各項目を精査し、改善提案として盛

り込むことにしました。

以下、個別に議論・検討した項目について、議論のポイントと改善提案を示します。

なお、提案した達成度指標項目については、後にまとめて一覧化しましたので、ご確認ください。

1-3）各専門分野・レベルごとの議論

①「システム開発」における議論

● 責任性

・レベル４では「プロジェクトリーダ」、またレベル３では「プロジェクトメンバ」と記述さ

れていますが、これでは“本当のＰＭはレベル５から”と解釈できる、との指摘がありまし

た。

・レベル４の責任性においては「プロジェクトリーダ」という名称を削除し、レベル５以上と

同じく、「プロジェクトの責任者」とすることを議論しました。

● 複雑性

・回数の規定に対して、“過去３年間などの期限を設けてはどうか”との意見が出ましたが、“プ

ロジェクトによっては長期のもの、短期のものがあり、一律に規定するのは無理がある”との

多数意見がありました。

・レベル５の複雑性の中で「システム要件の複雑性」と表記されていますが、意味をより明確に

するために「システム構築要件の複雑性」と修正することを議論しました。

● サイズ

・レベル３の責任性において、「プロジェクトメンバとしての経験・実績を有する」と規定する

なら、サイズにおける「ピーク時の要員数１０人未満のプロジェクト」という規定は意味がな

い、との指摘がありました。サイズについてはこの規定を削除することを議論しました。

・“複数のプロジェクトの合計金額でレベルを評価してもよいのでは”との意見がだされました

が、“１千万円規模のプロジェクトを複数こなしても、１０億円の仕事ができるとはいえない”

との意見がだされました。

● タスク特性

・レベル６における「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル５に

おける「顧客の部長相当以上への満足感の提供」はお客さまによって対応者が異なるため（中

堅・中小企業では社長の場合もある）、レベル５，６において共通に「顧客への満足感の提供」

と表現することを議論しました。

②「ＩＴアウトソーシング」における議論

・名称を「ＩＴアウトソーシング」に変更されています。

・４つの指標について精査しましたが、現行で特に問題となる指摘はありませんでした。



③「ネットワークサービス」における議論

■ 責任性

・レベル４で「プロジェクトリーダ」と記述されていますが、システム開発同様、レベル４にお

いても「プロジェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを

議論しました。

■複雑性

・ネットワークサービスにはグローバル案件も数多く存在するため、レベル 5 以上の複雑性

の要件として「国際的なプロジェクト」の追加を議論しました。

■サイズ

・拠点数でサイズを定義することに対して、曖昧さをさけるため“全国規模・地域（領域）で

分ける、あるいはメーカ間の調整有無、プロトコルの難易度などを考慮した定義が望ましい

のではないか”との意見がありましたが、検討メンバーにネットワークに強いものがいない

ため結論は保留となりました。別途、ネットワークに詳しい方を招聘し、レベル７の必要性

や他の指標を含めて検討することにしました。

これを受けて、専門家に参加いただき、再度検討会を開きました。ネットワークサービスにお

いては、お客様の拠点特性により、小規模拠点を 1 万拠点以上実施するケース（例：コンビニエ

ンスストアなど）や、高信頼性を考慮した大中規模拠点を数百拠点実施するケース（例：金融業

など）など、拠点数のみでサイズを定義することは困難であると考えられます。よって、拠点数

もしくは要員数のいずれかの要素をみたすことによりサイズの定義を行うことが望ましいのでは

ないかとの意見がありました。

また、拠点の定義についても議論がなされ、無線系、有線系、そしてその内容について議論が

なされました。基本的にはそれぞれの拠点は無線であれば基地局、有線であれば例えばコンビニ

のようにある程度規模の導入作業を伴う拠点ではないかとの議論がされました。

契約金額についてはネットワークサービスではハードウェアの金額に左右されるため、サイズ

の決定要素とはしないことを議論しました。

④「ｅビジネスソリューション」における議論

・本分野は「システム開発」に含まれるとのＷＧでの合意から検討の対象外となりました。

⑤「ソフトウェア製品開発」における議論

・現行の「ソフトウェア開発」は「システム開発」と紛らわしいため、「ソフトウェア製品

開発」と名称変更となりました。

・レベル７の追加

ソフトウェア製品開発においてもレベル７が必要との多数意見により追加を提案します。

レベル７における達成度指標は、システム開発にほぼ準じた内容と思われますが細部について

は、後述の一覧表をご確認ください。



● 責任性

・レベル４で「プロジェクトリーダ」と記述されていますが、レベル４においても「プロジ

ェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを提案します。

● サイズ

・レベル３はプロジェクトメンバとしての経験・実績であることから、「ピーク時の要員数

１０人未満のプロジェクト」というサイズは無意味であり、削除することを提案します。

● タスク特性

・レベル６において「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル

５において「顧客の部長相当以上への満足感の提供」と記されていますが、お客さまによっ

て対応者が異なるため（中堅・中小企業では社長の場合もある）、レベル５，６共通に「顧

客への満足感の提供」と表現することを提案します。

２）改善提案

上述した専門分野別、レベルごとの達成度指標について、改善提案した項目を一覧表の形で示し

ます。

専門分野達成度指標

レベル６ ■タスク特性

プロジェクト終了時、顧客への満足度、プロジェクトメンバ

への達成感の提供

レベル５ ■複雑性

システム構築要件の複雑性（・・・）

■タスク特性

プロジェクト終了時、顧客への満足感、プロジェクトメンバ


レベル４ ■責任性

下記複雑性、・・・において、プロジェクト責任者

として、プロジェクトを実施した経験と実績を有

する（「プロジェクトリーダ」の表記を削除）

システム開発

レベル３ ■サイズ

－以下の規模に相当するプロジェクト成功の経験と

実績を有する

□ピーク時の要員数 10 人未満のプロジェクト

[削除、サイズは不問]


ＩＴアウト

ソーシング

特になし




ネットワーク

サービス

レベル７

（追加）

■責任性

下記複雑性、サイズに相当するプロジェクト全体に対する責

任を持ち、プロジェクト責任者として、プロジェクトを遂行

した経験と実績を有する

■複雑性

以下の幾つかに相当する複雑度のプロジェクトに関する複

数回のプロジェクトマネジメントの経験と実績を有する

・システム要件の複雑性(パフォーマンス要件、セキュリ

ティ要件、技術要件、稼働運用要件)

・ネットワーク要件の複雑性（パフォーマンス要件、セキュ

リティ要件、技術的要件、稼動運用要件）

・複雑なアプリケーション要件

・プロジェクト体制（サブコントラクト、複雑な協業関係、

複数の関係部門）

・複雑な契約条件、完了条件

・国際的なプロジェクト

■サイズ

以下のいずれかの規模に相当するプロジェクト成功の経

験と実績を有する

・管理する要員数がピーク時 500 人以上、または導入作業

拠点数が 1000 拠点以上

■タスク特性

以下のタスク特性を踏まえたプロジェクト遂行及びプロ

フェッショナル活動の経験と実績を有する

・上記サイズ、複雑性のプロジェクトに対するプロジェクト

対象の熟知、適解の選択、プロジェクト終了までの責任

・上記サイズ、複雑性のプロジェクトに対する期待される資

源と期間内でのプロジェクト遂行とプロジェクト管理

・プロジェクト終了時、顧客の経営層への満足感、プロジェ

クトメンバへの達成感の提供

・後進育成、学会等外部団体のコミュニティ活動、論文執筆、

講演活動、ビジネス特許取得等のプロフェッショナルとし

ての顕著な貢献と実績




レベル６ ■複雑性

■国際的なプロジェクト

■サイズ

以下のいずれかの規模に相当するプロジェクト成功の経験

と実績を有する

・管理する要員数がピーク時 50 人以上 500 人未満、また

は導入作業拠点数が 300 拠点以上

レベル５ ■複雑性

・国際的なプロジェクト

■サイズ

以下のいずれかの規模に相当するプロジェクト成功の経

験と実績を有する

・管理する要員数がピーク時 10 人以上 50 人未満、または

導入作業拠点数が 100 拠点以上 300 拠点未満

ネットワーク

サービス

（続き）

レベル４ ■サイズ

以下のいずれかの規模に相当するプロジェクト成功の経験

と実績を有する

・管理する要員数がピーク時 10 人未満、または導入作業拠

点数が 100 拠点未満


ｅビジネス


(専門分野から削除、システム開発に吸収)




レベル７

（追加）

（システム開発のレベル７に準拠）

■責任性

下記複雑性、サイズに相当するプロジェクト全体に対する責

任を持ち、プロジェクト責任者として、プロジェクトを遂行

した経験と実績を有する。

■複雑性

以下の幾つかに相当する複雑度のプロジェクトに関する複

数回のプロジェクトマネジメントの経験と実績を有する

・システム要件の複雑性(パフォーマンス要件、セキュリテ

ィ要件、技術要件、稼働運用要件、技術の成熟度、障害対

策、運用、保守を考慮した設計、開発サイクル)

・システムデザインの複雑性（マルチプラットフォーム、高

可用性）

・プロジェクト体制（サブコントラクト、複雑な協業関係、

複数の関係部門）

・複雑な契約条件、完了条件

■サイズ

以下の規模に相当するプロジェクト成功の経験と実績を有

する

・管理する要員数がピーク時 500 人以上

■タスク特性

以下のタスク特性を踏まえたプロジェクト遂行及びプロフ

ェッショナル活動の経験と実績を有する

・上記サイズ、複雑性のプロジェクトに対するプロジェク

ト対象の熟知、適解の選択、プロジェクト終了までの

責任

・上記サイズ、複雑性のプロジェクトに対する期待される

資源と期間内でのプロジェクト遂行とプロジェクト管理

・プロジェクト終了時、顧客の経営層への満足感、プロジ

ェクトメンバへの達成感の提供

・後進育成、学会等外部団体のコミュニティ活動、論文執

筆、講演活動、ビジネス特許取得等のプロフェッショナ

ルとしての顕著な貢献と実績

ソフトウェア

製品開発

レベル６ ■タスク特性

プロジェクト終了時、顧客への満足感、プロジェクトメンバ





レベル５ ■タスク特性

プロジェクト終了時、顧客への満足感、プロジェ

クトメンバへの達成感の提供

レベル４ ■責任性

下記複雑性、・・・において、プロジェクト責任者

として、プロジェクトを実施した経験と実績を有す

る（「プロジェクトリーダ」の表記を削除）

ソフトウェア

製品開発

（続き）

レベル３ ■サイズ

－以下の規模に相当するプロジェクト成功の経験と

実績を有する

□ピーク時の要員数 10 人未満のプロジェクト

[削除、サイズは不問]



２．３．2 ２００5 年度改善提案

２００５年のＩＴスキル標準改善提案のパブリックコメント、ＩＰＡの意見及び他の職種での検討結

果を踏まえて、討議を進めました。

しかし、上記の結果公式発行されるＩＴスキル標準＆研修ロードマップ（Ver.2）の内容と 2004 年度

の改善提案のベースとしたＩＴスキル標準＆研修ロードマップ（Ver1.2）の内容に大きな差異がある

ことが判明しました。 Ver.2 では 2004 年度の本節の改善提案があまりフォローされていないため、

もとに戻して議論することの意見も PM 委員会の中にありましたが、パブリックコメントに基づく内容

変更でもあり、公式発行されるＩＴスキル標準＆研修ロードマップ（Ver1.2）を尊重し PM 委員会に

てその変更内容を精査し、以下に示す改善提案を行いました。

１）討議内容

１-1）責任性

経験については、当該レベルにおける複数回の成功経験が必要ではないかという議論がありました。

ただし、レベル５以上のプロジェクトでは長期間のものが多いため、当該レベルでの実績は１回とし、

１ランク下のレベルでの実績を複数回カウントしてはどうかという意見が出されました。

Ver.２改定案に対する議論では、Ver.１．２と比較した結果、プロジェクトにおけるＰＭの活動範

囲や、具体的に達成するべき経験や実績を示し、かつ具体的な指標を追加しているため、下記事項を

除き、基本的に同意しました。

① 職種の説明で示しているＰＭの活動領域に示した範囲にあわせた記述とする。

② “達成した経験”を“遂行した経験”に修正する。

③ ＰＭ固有の検討課題については来年度【２００６年度】の検討課題として残す。

1-2）複雑性

プロジェクトマネジメント職種では複雑性をリスクと解釈し、その内容を討議しました。

複雑性の内容は、各企業が現在認識しているリスク項目を調査し、カテゴライズを図りました。

● 国際的なプロジェクト（文化的・社会的並びに、国際的・政治的に厳しい環境）

海外に納入するシステムか？

日本以外の法律に基づく契約か？

● 世界的にも先進的なプロジェクト

世の中に参考となる事例が１件もないシステム構築か？

● 複雑なシステムデザイン

構築するプラットホームの担当は自社か？

マルチベンダーによる開発か？

使用するハード・ソフト製品は、適用実績のあるものか？

他システム（対外システムを含む）との複雑な接続があるか？

当該システムに関する技術は自社の技術レベルに合っているか？

● 複雑なアプリケーション要件

ＲＦＰの完成度合いは？



新規システム・再構築か？

開発規模は？

海外に対応するシステムか？

開発規模に見合った開発期間となっているか（開発納期は調整可能か）？

● 複雑なシステム構築要件

高信頼性を要求されているシステムか？

高処理能力・高性能を要求されているシステムか？

● 複雑な移行要件

移行の空間的、時間的制約はあるか？

● 複雑なプロジェクト体制

顧客とのコミュニケーションラインの確保レベルは？(新規顧客／顧客側の人事異動が多い)

顧客側ＰＭとその後ろ盾の関係及び権限は？

経営者と顧客側プロジェクトの意思統一レベルは？

顧客側ＰＪ体制は必要十分条件を満たしているか？（管理能力・技術力・人数等）

必要な技術・業務知識を有するベンダー側要員の充足度レベルは？

● 複雑な契約条件、完了条件

顧客から開発手法、使用する製品及び開発ベンダー等の指定があるか？

（指定されたことに対するベンダー側の習熟度､納期確保等は？）

契約の範囲（要件定義～総合テストのどの部分が対象か）は？

契約のタイプ（フルターン契約・段階的契約）及び各工程の契約形態（開発請負、委任）は？

ペナルティ条項の内容は？

自社の標準契約書との相違点は？

ただ、「このカテゴライズでは変数が多く使いづらいのではないか／「①新規/既存 ②使用技術

の新規性 ③関係者数 ④社会的影響度(製品特性)の４つに集約してはどうか」という意見も上がり

ましたが、終的には、集約しすぎると利用者がそのカテゴリが意図する内容を適切に判断するの

が困難との結論に至りました。

また、各カテゴリの難易度のレベル感の定義について議論がありました。ソフトウェアベンダを

取り巻く社会環境やその組織の成熟度・専門分野により、各カテゴリの難易度に強弱があり、統一的

な難易度のレベル定義を提示できないとの結論になりました。

以上の議論からＰＭにおける表記は、「複雑性」をリスクと解釈したことを明示する意味から、「複

雑性（リスク）」が適切との結論に至りました。

なお、ＰＭ特有の複雑性の問題点については、来年度【２００６年度】の検討課題としました。、

その検討結果によっては次回改訂への反映が望まれます。

1-3）サイズ

サイズの議論の過程で

・大規模なシステムの保守プロジェクトを考えると、開発規模が小さくても母体システムが大

きい場合にはしっかりとしたプロジェクトマネジメントの方法論が身についている必要があ

る。



・アーキテクチャの分野は、新規性・高度な技術に集約してリスクを判断する。プロジェクト

の難易度（経験レベルの評価尺度）としては、新規性、規模、その他の３軸で判定してはど

うか。

等の意見がありました。

しかし、プロジェクトの新規性やその他はリスク要因の一部と捉え、規模とリスクの２つの軸で考え

るとの結論に至りました。

上記結果を受け、各レベルのＰＭのイメージを議論・集約した結果、以下のとおりとなりました。

レベル４のＰＭのイメージ：

・レベル４のＰＭは教科書通りにやれば、ＰＭとして、うまく出来るレベル。

（従って、担当するプロジェクトは、リスクが低く、少人数のプロジェクトが妥当である）

レベル５のＰＭのイメ-ジ：

・レベル５のＰＭはある程度自分なりのＰＭスタイルが確立してきているレベル。

・リスクが中位以上の中規模プロジェクトでは、標準的なＰＭ技術を、そのプロジェクトに適したや

り方に応用し、プロジェクトを計画、実行、コントロールし、プロジェクトを完遂出来るレベル。

・リスクが中位以下の中規模プロジェクトの責任者として、安心して任せておけるレベル。

・リスクの低い大規模プロジェクトでは、ある一部を責任を持って完遂できるレベル。

・問題が起きている小規模プロジェクトの建直しＰＭとして安心して任せられるレベル。

上記イメージの図式化を図２.３－１に示します。

ただし、将来的にはパブリックコメント及び統計などによりさらに現実に近いものにしてい

く必要があります。

図２．３－１ＰＭレベルとリスク・規模の関連について



1-４）プロフェショナル貢献

Ｖｅｒ１．２においてはタスク特性としていたものが、Ｖｅｒ２の改定方針において、プロフェ

ショナル貢献と言う用語で提言されました。

プロフェッショナル貢献は、指導、技術の継承そして後進の育成の 3 つのカテゴリに分けられてい

ます。

特許を貢献とみなすのが適当かどうかで議論がありました。ソフトウェアでも特許出願はありま

すが、方式特許等技術面のものでありマネジメントの特許ではなく、プロジェクトマネジメントの

貢献にはそぐわないとの理由で採用しないのが適当との結論に至りました。

後進の育成を、技術の継承の中で示すか、独立して提示するかの議論がありましたが、後進の育

成は非常に重要なキーワードのため、独立して提示するとの結論に至りました。

1-５）その他

プロジェクトマネジメント職種のレベル３については、プロジェクトメンバとしての参画であるた

め、成功裡に終えることや、複雑性、サイズなどは、特定すべきではないという結論になりました。

２）改善提案

上述した専門分野別、レベルごとの達成度指標について、改善提案した結果を添付資料２－２「達成度

指標（職種：プロジェクトマネジメント）に示します。



２．4 スキル領域

２．4．１ 200４年度提言

「スキル領域」は、技術者に求められる実務能力をスキル項目として定義したもので、職種共通スキ

ル項目とシステム開発・ＩＴアウトソーシング等４つの専門分野固有スキル項目から構成されています。

当ＷＧでは、主に職種共通スキル項目についてその内容を検討し改善案を提言しました。

以下、主な検討・討議内容、及び個々の改善提案について記述します。

１）討議内容

職種共通スキルは下記に示すように４つの領域に分解されます。

■プロジェクトマネジメントのスキル

■パーソナルスキル

■ビジネスマネジメントに関する知識／スキル

■職種共通的なテクノロジおよびメソドロジに関するスキル

① プロジェクトマネジメントのスキル

ＰＭＢＯＫガイド第３版に示されるプロジェクトマネジメントに関する以下に示す９つの知

識エリアに対応して、現行ＩＴスキル標準は定義されています。

統合マネジメント

スコープマネジメント

タイムマネジメント

コストマネジメント

品質マネジメント

人的資源マネジメント

コミュニケーションマネジメント

リスクマネジメント

調達マネジメント



「契約マネジメント」の追加の必要性について討議を行いました。その結果、各委員からは以下

に示すような多くの意見がありました。

・ＰＭＢＯＫでは、契約以降がＰＭの役割として定義されているが、ＰＭにとっては、顧客（プロジェ

クトの発注者）との契約も重要な意味を持つものであり、ＰＭも契約について充分な知識を持ってお

かなくてはならない。

・プロジェクトの立場には、調達する側（発注側）と調達される側（受注側）という２つの立場がある。

ＰＭＢＯＫでは、“調達するための契約”については述べられているが、それでは、契約としては一

方的である。

・ＩＴスキル標準では、「調達マネジメント」の中の「契約交渉」という項目で、契約について触れて

いる。

・ＰＭには、契約を締結した後に、その契約を精査し、理解する能力が必要だという意味で、契約はプ

ロジェクトの範囲内であると言える。

・受託側の立場で契約について議論すると、プロジェクトの範囲外を扱うことになってしまうので、契

約については、別のアウトプットで扱った方が良い。

・ＰＭにとって、契約に関する知識は必要不可欠なものであるが、ＰＭガイドライン等の別のアウトプ

ットで、その重要性を強調してはどうか。

・「調達」と「契約」は、「調達・契約マネジメント」として一つにまとめ、その中で契約の重要性を

強調してはどうか。

・契約は、プロジェクトのマネジメントすべてに関わるものであると言えるので、「スコープマネジメ

ント」等の各マネジメント項目の中で、契約を強調することもできるし、それらをまとめて「契約マ

ネジメント」として取り出してはどうか等々。

ＰＭBOK では、委託側としての契約マネジメントを調達マネジメントとして定義をしています。

しかし、受託側のプロジェクトに焦点を当てて考えてみると、発注を受ける立場としての契約マネ

ジメントも存在しているので、結果として、契約についての記述が、欠落しているとの意見の一致

を見ました。

②パーソナルマネジメントについてのスキル

ＰＭの活動様式としての人間力（ヒューマンスキル）及び倫理について討議を行ないました。

③ビジネスマネジメントに関する知識/スキル

知的資産管理（Knowledge Management）活用

知的資産の管理と活用

インダストリ／適用業務スキルの活用

をＩＴスキル標準（V1.2）で代表例として提示されています。これについて検討しました。

その結果、追加で例示すべき内容がないことが検証されました。



④職種共通的なテクノロジ及びメソドロジに関するスキル

ＩＴスキル標準（V1.2）で下記が追加されています。

業務分析

業務要件分析、技術要件分析、情報化と経営

コンサルティングメソドロジの活用

コンサルティングメソドロジの選択と活用

コンサルティングの実施

コンサルティング技術の活用、顧客リレーション

現実のプロジェクトでは、一人で何役もこなしており、コンサルタントもプロジェクトマネジャ

ーも同じ人間が担当していることが多いと考えられます。しかし、プロジェクトマネジャーの業務

を「スコープが確定し受注してから」と考えると、コンサルタントの業務範囲とのすみわけが曖昧

であり明確にする必要があります。

２）改善提案

①プロジェクトマネジメントのスキル

「統合マネジメント」の部分に、“ＰＭにとって、契約に関する知識は重要である”ということを記述

しておくことを提言します。

②パーソナルスキル

職種共通スキル項目として、現在のＩＴスキル標準では、下記の通りプロジェクト関係者とのプ

ロジェクト目標の共有について視点を当てられています。

リーダーシップ

プロジェクト目標設定､チームリーダーシップィビティ展開と推進、動機付け

コミュニケーション

意思疎通、プレゼンテーション、各種文書の作成、会議運営

ネゴシエーション

スコープ、コスト、スケジュール、契約条文と条件、及びリソースに関する交渉等

上記の項目に加え、その他の重要な要素として、下記項目の追加を提言します。

分析力

行動力

倫理（社会的責任）

③職種共通的なテクノロジ及びメソドロジに関するスキル

「業務分析」については、「専門家の意見に基づき、お客様の経営課題を理解し、適切な業務／

技術要件を提案・判断できる」との趣旨を盛り込みました。

「コンサルティングの実施」に関しては、コンサルティング技術の適用を行うとすべきではない

でしょうか（プロジェクトマネジャーとしては、コンサルの手法があるということお客様やプロジ

ェクト内のメンバーに伝え、実際に手法を実施する場合はコンサル等専門家を使って業務を行うの



が責務である）。その表現の見直しをしました。達成度指標レベルについては、スキルレベルで展

開することにした。具体的修正案を表2.4－1に示します。

表 2.4－1 プロジェクトマネジメントのスキル熟達度修正案

職種共通スキル項目スキル熟達度

業務分析

業界/技術動向の先見的見地に基づき複雑高度な業務要件/

技術要件分析を行うことができる。

→専門家の意見に基づき、お客様の経営課題を理解し、適

な業務／技術要件を提案・判断できる。

コンサルティングメ

ソドロジの活用

適なコンサルティングメソドロジの選択と適用、プロセス

の定義と実践、成果物の定義と作成、コンサルティング技術

の適用を行い、プロジェクトを成功裡に実施することができ

る。

→プロジェクト特性に応じたコンサルメソドロジの選択と

適用、プロセスの定義と実践、成果物の定義と作成、コンサ

ルティング技術の適用を行い、プロジェクトを成功裡に実施

することができる。

コンサルティングの

実施

コンサルティングメソドロジ、モデル、コンサルティング技

術を活用し、プロジェクトを成功裡に実施することができ

る。

→(削除)

④スキルレベル

各スキル領域におけるレベル（熟達度レベル）についての測定が、立場（各レベルにおけるプロジ

ェクトサイズ）を除いて具体性が十分ではありません。そのため、スキル熟達度のレベルごとにせず、

一本化し、各レベルは新たにスキルレベルを設定し、熟達度レベルに対応させることでＷＧでは提案

しました。



２．4．２ 2005 年度改善提案

プロジェクトマネジメントのスキル熟達度・知識項目においても「ＩＴスキル標準＆研修ロードマッ

プ（Ver.2）」公式発行に際して、2004 年度の改善提案からの引き続き検討事項として「スキル項目

と知識項目及びスキル熟達度」についての検討を行いました。

なお、2004 年度と 2005 年度のスキル熟達度、知識項目の表形式を見やすくするためその様式が変

更されました。

１）討議内容

職種共通スキル項目

スキル領域における職種共通スキル項目についてはＰＭＢＯＫガイド第３版が発刊されたことに伴

い、「ＩＴスキル標準＆研修ロードマップ（Ver1.2）」の内容との比較を行いました。その中でプロ

ジェクトマネジメント知識体系に関わる９個のスキル項目をＰＭＢＯＫガイド第３版の内容に置き換

えることを検討しました。

PMBOK ガイド第３版からの引用に際してはＰＭＩからの許諾を得て、下記の様な内容で各項目をＰ

ＭＢＯＫガイド第３版に沿って入れ替えることを提案しました。

① 知識項目名はＰＭＢＯＫガイド第３版に合わせる。

② ＩＴスキル標準で示す知識項目は中項目までとし、小項目は示さない。

③ ＩＴスキル標準Ｖｅｒ１．２に含まれるがＰＭＢＯＫガイド第３版に無い項目は削除する。

スキル熟達度

スキル熟達度についてはＩＴスキル標準＆研修ロードマップ（Ver.2）の公式発行に際して、スキル標

準改定委員会から出された討議結果をさらに PM 委員会にて詳細検討し、下記のような意見を提案しま

した。

① PMBOK ガイド第 3 版にあわせた表記をする。

② ソフトウェア製品開発及びＩＴアウトソーシングの専門分野については職種の説明に示すＩＴ投資

の局面にあわせた表記とする。

２）改善提案

職種共通スキル項目

職種共通項目の以下の９項目はＰＭＢＯＫガイド第３版あわせ修正することを提案しました。

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

プロジェクト・スコープ・マネジメント

プロジェクト・タイム・マネジメント

プロジェクト・コスト・マネジメント

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

プロジェクト人的資源マネジメント

プロジェクト・コミュニケーション・マネジメント

プロジェクト・リスク・マネジメント



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

なお、上記 9 つの職種共通スキル項目以外で以下のようなコメントが出されました。

◆ 業務分析

技術用件分析を含んでいるので要件分析と名称を変更する

◆ コンサルティングメソドロジの活用

知識項目の“顧客リレーションの確立”は本項目の内容にはそぐわないので削除する。

◆ 知的資産管理の活用

知的資産管理よりむしろ関連法規とナレッジマネジメントと読み替え、スキル熟達度の内

容も変更することを提案した。

◆ ＩＴソリューション設計と開発管理

知識項目の内容はソフトエンジニアリングそのものであるので専門分野固有スキル項目

を“ＩＴソリューション設計と開発管理からソフトエンジニアリング”と変更し、下記知

識項目を削除・追加する。

＜削除＞

ソフトエンジニアリング、汎用業務新動向、業務パッケージ新動向、グローバリゼー

ション、e ビジネス開発実施

＜追加＞

開発方法論、見積り技法、テスト技法

スキル熟達度

2005 年度における改善提案は公式発行されるＩＴスキル標準＆研修ロードマップ（Ver.2）に

てフォローされる内容となります。



２．５スキル熟達度・知識項目

２．５．１ 2004 年度提言

「スキル領域」は技術者に求められる実務能力をスキル項目として定義したもので、職種ごとに共通の

スキル項目と専門分野固有のスキル項目から構成されます。それぞれのスキル項目に対して、どのレベル

にあるかを表現するのが「スキル熟達度」です。スキル熟達度はすべて「～することができる」という基

準によってスキルの有無を問うもので、当該レベルに達していることの裏づけとなる要素として捉えられ

ます。つまり、ある職種のレベル５に該当する技術者ならば、「このスキル項目についてこれだけのこと

を行えるはずだ」というガイドラインを示すのが、スキル熟達度の意義です。

また各スキル項目にはそのスキルを身につけるための前提となる知識を「知識項目」として明記し、ス

キルに対応した知識習得の指針として活用できるようになっています。

１）討議内容「スキル熟達度」は、利用する側の視点で見ると、自らの「スキル熟達度」が、社会一般的なレベル

からみると、どのレベルにあり、どのスキル項目のどの知識項目が不足しているかを把握し、スキルア

ップのために活用するという捉え方ができます。育成者の視点からも、対象となる人材に対して、同様

の捉え方ができることが活用の視点から重要になります。

これに対し、現状の「スキル熟達度」は、以下のような点がわかりにくいとの指摘がありました。

レベルの違いをサイズ＋責任で表現しているが、達成度指標のレベルとの違いがわかりにくい。

知識項目とスキル熟達度のレベルとの関係が示されておらず、どの知識項目をどのようなレベルに

すれば、スキル熟達度が向上するのかがわかりくい。

レベル区分が達成度指標と同様に５区分（レベル３～７）に設定されているが、スキルのレベルを

５つに区分できるだろうか。

「スキル熟達度」は、複数の知識項目に対応するスキルのレベルの組み合わせで表現されるはずだ

が、そのレベルや組み合わせは、組織のニーズや個人の経験の違いによって個人ごとに異なると考

えられる。キャリアアップの視点からは、その違いに配慮できるような構成になっていることが望

ましい。

知識項目には、職種共通のものやいくつかの職種で共通に活用できるものもある。それらの知識項

目については、同様の視点で評価できる形が好ましい。

以上の指摘に対応するために、以下のような改善を提案しました。



２）改善提案

「スキル熟達度」のレベルをあらわす「スキルレベル」の概念を導入し、2 段階で表現すること

で、知識項目ごとのレベルと「スキル熟達度」のレベルの関係を論理的に表現できる考え方を提言

します。

■ 「スキル熟達度」のレベルを「熟達度レベル」、「スキルレベル」の 2 段階で考えます。

■ 「熟達度レベル」とは、対応するレベルのプロジェクトを実践するスキルを保有していることを表

す指標で、スキルに対応します。たとえば熟達度レベル４であれば、達成度指標レベル 4 の規模

や複雑性などを有するプロジェクトのプロジェクトマネジメントを行える可能性があるというこ

とです。因みに「達成度指標レベル」は、実際に行って成功裏に終了した実績を示します｡

■ 「スキルレベル」とは、スキル熟達度を構成する要素（スキル項目と呼ぶ。またこのスキル項目を

大括りにしたものを、スキル領域と呼ぶ）ごとにレベル 0 からレベル 5 までを設定します。ただ

し、そのレベル表現は、個々のスキル項目ごとに設定するのではなく、すべての項目に共通の表現

を用いることとします（表 2.5.２参照）。

■ 「スキル項目」ごとの「熟達度レベル」は「スキルレベル」を用いて、その総合スキルレベルによ

って決定します（表 2.5.３参照）。ただし、この評価点はあくまで一般的な例示と考えてくださ

い。組織によっては、海外でのプロジェクトで世情に不安があり、リスクがとても大きいためにリ

スクマネジメントに対するスキルが重視される場合もあります。そのような場合は、例示している

スキルレベルを変える必要があります。

■ トータルの「熟達度レベル」は、「スキル領域」ごとの総合スキルレベルを総合判定したものとし

て、表現されます。

■ 「熟達度レベル」によって、要求される「スキル領域」の割合は異なっていると考えられます。た

とえば、熟達レベル３では、テクノロジ及びメソドロジースキルのような現場でのスキルがより重

視され、ビジネスマネジメントスキルはまだあまり重視されないといえます(図 2.5―１参照)。レ

ベルごとの「スキル領域」の割合については、組織によって異なる場合があります。

■ また、個人ごとに強いスキルが異なる場合があります。たとえば、表 2.5―１のような 3 名の方

の熟達度レベルをどのように考えるかを見てみましょう。Ａ氏は、すべてのカテゴリのスキルレベ

ルが、熟達度レベル評価で 4 を上回っています。したがって、熟達度レベル 4 であると考えられ

ます。Ｂ氏は、パーソナルスキルとビジネスマネジメント･スキルの総合スキルレベルによる熟達

度レベル評価が 4 に達していません。しかし、テクノロジーメソドロジースキル、インダストリ・

適用業務スキルでは４を超えています。このような場合は、まずプロジェクトマネジメントスキル

を優先してこの部分が４を超えていますので、熟達度レベル 4 の可能性があると考えます。ただ

し、パーソナルスキルとビジネスマネジメントスキルに不安があることを認識する必要があります。

プロジェクトマネジャーの上司やメンターが適切な支援をする必要があります。一方、Ｃ氏の場合

は、プロジェクトマネジメントスキルの総合スキルレベルが、熟達度レベル 4 に達成していませ

んので、熟達度レベルは 3 と考えます。



表 2.5―１熟達度レベルの例示

各カテゴリにおける総合スキルレベル（）内が対応する熟達度レベル熟達度

レベルプロジェク

トマネジメ

ント

パーソナル･

マネジメン

ト

テクノロジ

ーメソドロ

ジー

インダスト

リ･適用業

務

ビジネスマ

ネジメント

Ａ氏４３．５（４）３．０（４）３．０（４）３．０（４）２．０（４）

Ｂ氏４３．５（４）２．０（３）３．０（４）３．０（４）１．２（３）

Ｃ氏３２．５（３）３．０（４）３．０（４）３．０（４）２．０（４）

■ ｢熟達度レベル｣を上記のように表現する形になりますので、「スキル熟達度」はレベル表現をせ

ず、スキル項目の説明を記述することになります(表 2.5.４参照)。

■ ここで示しました｢スキルレベル｣、｢熟達度レベル｣は、レベルアップのための仕組みとして活用

することを前提にしています。論理的にレベル判定ができるからと、この仕組みを個人の評価に

用いることは必ずしもよい結果を生まないと考えています。ＩＴ技術者の育成に活用されること

を切に望みます。

スキルレベル

スキルレベルの定義

具体的な説明例

0 知らない－

1 知っている研修などで勉強をして、知識として知っている

2 説明できる知識中心だが、人に説明できる。指導を受けながら実践したこともある

3活用できる、実践できる

そのスキル・カテゴリーについて、殆ど経験しており、自力で実践できる

4実践し、指導できる

そのスキル・カテゴリーについて、深い理解と数多くの経験を持ち、後進の指導ができる

5リードやコンサルテーションができる

そのスキル・カテゴリーについて、業界の第一人者で、業界をリードできる

表 2.5―2 スキルレベル



1 2 3 4 5 6 7

統合マネジメント 1 2 3 3

スコープマネジメント 0 1 2 3

タイムマネジメント 1 2 3 4

コストマネジメント 0 1 2 3

品質マネジメント 1 2 3 4

コミュニケーションマネジメント 1 2 3 3

人的資源マネジメント 0 1 2 3

リスクマネジメント 0 1 2 2

調達マネジメント 0 1 2 3

プロジェクトの立上げ 0 1 2 2 3

プロジェクトの計画 0 1 2 3 4

プロジェクトの実行 1 2 3 4 5

プロジェクトのコントロール 1 2 2 3 4

プロジェクトの終結 0 1 2 3 3

6 20 33 43 54 68 68

0.4 1.4 2.4 3.1 3.9 4.9 4.9総合スキル・レベル

知識分野

プロセス分野

熟達度レベル

総合ポイント

すべての項目でスキルレベル３以上で、スキルレベル４が４個以上、スキルレベル５が２個以上のこと

すべての項目でスキルレベル４以上で、スキルレベル５が７個以上のこと

すべての項目でスキルレベル４以上で、スキルレベル５が７個以上のこと

すべての項目がスキルレベル５のこと

すべての項目がスキルレベル５のこと

表2.5―3(1)　プロジェクトマネジメント･カテゴリーにおけるスキルレベル(例)

1 2 3 4 5 6 7

リーダシップ 0 1 2 2 4

コミュニケーション 1 2 2 3 4

ネゴシエーション 0 0 1 2 2

問題解決力 0 1 1 2 3

組織に対する影響力 0 0 1 2 2

動機付け 0 0 1 2 3

1 4 8 13 18 24 29

0.2 0.7 1.3 2.2 3 4 4.8

0 2 3 3 3 2 2

情報化と経営 0 0 0 1 2

財務諸表と経営分析 0 0 0 1 2

顧客とのリレーションシップ 0 0 1 2 3

関連法規の理解と順守 0 0 0 1 2

契約条項の理解と順守 0 0 1 2 3

顧客や相手国のビジネス習慣や文化の理解 0 0 1 2 3

0 0 3 9 15 20 25

0 0 0.5 1.5 2.5 3.3 4.2

熟達度レベル

パー

ソナルスキル

ビ

ジ

ネ

ス

マ

ネ

ジ

メ

ン

ト

ス

キ

ル

総合ポイント

総合スキル・レベル

総合ポイント


インダストリー／適用業務スキル

すべての項目でスキルレベル４以上で、スキルレベル５が５個以上のこと

すべての項目がスキルレベル３以上で、スキルレベル４以上が３個以上、スキルレベル５が２個以上のこと

すべての項目がスキルレベル３以上で、スキルレベル４以上が２個以上のこと

すべての項目でスキルレベル３以上で、スキルレベル４が２個以上、スキルレベル５が２個以上のこと

表2.5―3(2)　パーソナルスキル、インダストリー／適用業務スキル、ビジネスマネジメントスキルカテゴリーにおけるスキルレベル(例)



専門分野：システム開発

1 2 3 4 5 6 7

業務・システム要件分析 1 2 3 3 4 4 3

システム／ネットワーク／障害対策設計 1 2 3 4 4 3 3

セキュリティ設計 1 2 3 4 4 3 3

運用設計 1 1 2 3 3 2 2

情報技術（ＩＴ）、ネットワーク技術 1 2 3 4 3 2 2

ソフトウェアエンジニアリング 1 2 3 4 4 3 3

コンサルティングメソドロジーの活用 0 0 1 2 3 3 3

ナレッジマネジメントの活用 0 0 1 2 3 3 2

6 11 19 26 28 23 21

0.8 1.4 2.4 3.3 3.5 2.9 2.6

専門分野：ＩＴアウトソーシング

1 2 3 4 5 6 7

情報システム企画 0 0 0 1 2 3 3

情報システム資源管理 0 0 1 2 3 4 3

障害対策・セキュリティ対策 0 1 2 3 4 4 3

ＳＬＡ管理 0 1 1 2 3 4 3





2 6 11 18 25 26 22

0.3 0.8 1.4 2.3 3.1 3.3 2.8

専門分野：ネットワークサービス

1 2 3 4 5 6 7

ネットワーク環境・要件分析 0 1 2 3 4 3 3

ネットワークシステムの設計 0 2 3 4 4 3 3

ネットワークシステム資源管理 0 0 2 3 4 4 3

障害対策・セキュリティ対策 0 1 2 4 4 3 3

ネットワーク運用設計・運用管理 0 0 1 2 3 4 3




1 8 17 26 29 25 22

0.1 1 2.1 3.3 3.6 3.1 2.8

専門分野：ソフトウェア製品開発

1 2 3 4 5 6 7

ソフトウェア市場動向・ニーズ分析 1 2 2 3 3 4 4

業務システム要件分析 1 2 3 3 4 4 3

システム／ネットワーク／障害対策設計 1 2 3 4 4 3 3

セキュリティ設計 1 2 3 4 4 3 3





6 12 19 26 28 25 23

0.8 1.5 2.4 3.3 3.5 3.1 2.9

テクノロジー／

メソドロジースキル

総合ポイント

熟達度レベル

総合ポイント


熟達度レベル

テクノロジー

／

メソドロジースキル

総合ポイント


熟達度レベル

テクノロジー

／

メソドロジー

スキル



熟達度レベル


メソドロジー

スキル

総合ポイント

表2.5―3(3)　テクノロジー／メソドロジースキルカテゴリーにおけるスキルレベル(例)



表 2.5－4 スキル項目の説明

スキルカ

テゴリースキル項目説明

統合Ｍプロジェクト計画策定、計画実施、変更管理を行い、プロジェクトを成功裡に遂行

することができる

スコープＭプロジェクトスコープを適切に計画、定義、管理し、プロジェクトを成功裡に遂行す

ることができる

タイムＭ作業定義、順序設定、所要時間見積もり、スケジュール作成、管理全般を実施

し、プロジェクトを成功裡に遂行することができる

コストＭ資源計画、コスト積算、予算設定、コスト管理を実施し、プロジェクトを成功裡に

遂行することができる

品質Ｍ品質計画、品質保証、品質管理を実施し、プロジェクトを成功裡に遂行すること

ができる

人的資源 M プロジェクト組織計画、要員調達、チーム育成を実施し、プロジェクトを成功裡に


コミュニケー

ションＭ

コミュニケーション計画、情報配布、進捗報告、プロジェクト完了手続を実施し、プ

ロジェクトを成功裡に遂行することができる

リスクＭリスク特定、定量化、対応策策定、リスク管理を実施し、プロジェクトを成功裡に


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

調達Ｍ調達計画、引合計画等調達に関する業務の管理を実施し、プロジェクトを成功裡

に遂行することができる

図 2.5－1 熟達度レベル別スキル量の推移(イメージ図)

少ないスキル量多い

熟達度レベル

低

高７

６

５

４

３

２

１


パーソナルマネジメント

ビジネスマネジ

メント

インダストリー／

適用業務


メソドロジー

PMにはこのレベルはない

少ないスキル量多い

熟達度レベル

低

高７

６

５

４

３

２

１




メント


適用業務


メソドロジー


７

６

５

４

３

２

１




メント


適用業務


メソドロジー




２．５．２ 2005 年度提言

１）スキル熟達度･知識項目についても､PMBOK ガイド第 3 版に合わせた表記とすることを提案します｡即

ち､「スキル項目と知識項目」のうち､「プロジェクト統合マネジメント」から「プロジェクト調達マネジメント」にお

ける各「知識項目」を PMBOK 第３版のプロセス名称に合わせるというものです｡

なお､上記 9 つの職種共通スキル項目以外（「業務要件」以降）については２．４．２２）「改善提案」の記

載内容に同じです｡

２）スキル熟達度については､2004 年度「改善提案」として「熟達度レベル」と「スキルレベル」の概念の導入

を提言しましたが､

・各カテゴリにおけるスキルレベル（例）が細分化されすぎ､使いづらいのではないか

・熟達度レベルは３～７の範囲でいいのではないか

等の意見があり､下記再提案することにしました。

これらに沿って評価を行うことで、個人にとってはキャリアアップの方向性が明確になること､また組織にと

っては組織としてのポテンシャルが明確になり、不足している分野やレベルの強化のための施策を立案でき

ることなどが可能となります。 IT スキル標準の「スキル熟達度・知識項目」がより使いやすいものとなること

を意図しています。

スキル熟達度・知識項目はその評価方法とも密接に関係しています。 PM 委員会では WG2：PM 育成ガイ

ドライン WG で詳しく扱っていますので､詳細は WG2 の成果物である「PM 育成ハンドブック 2005 年度版」を

参照ください。ここではスキル評価方法の骨子のみの紹介に留めます。

① スキル領域ごとのスキル項目をスキルレベルで評価する。スキルレベルとはスキル項目の実践レベルを示すもので０～５の６段階で評価する。

（表 2.5－２「スキルレベルの定義」（2004 年度に同じ）参照） ② スキル領域ごとに総合スキルレベルを決める。

熟達度レベルによって必要とされるスキル量が異なるので､レベルに応じたスキルレベルの分布

を見て総合評価を行う。 ③スキル領域ごとの総合スキルレベルを総合評価しＰＭの熟達度レベルを決める。

表２．５―５に「総合スキルレベルの定義」、表２．５－６～８に熟達度レベルに必要な、スキル

領域・スキル項目別スキルレベルの例を示します。表２．５―５統合レベルにおける新スキル・レベル（◎、○、△）の定義

説明

◎ほぼ全てのスキル項目において十分な知識をもっていて、環境に応じて適切に応用ができる。独力で実践でき、安心して任せられる。また、一部について後輩の指導もできる。

○ほぼ全てのスキル項目において知識を持っていて、一部のスキル項目において独力で実践できるが、困難な場合に遭遇した場合には上級者の応援を必要とする場合がある。

△ほぼ全てのスキル項目において知識を持っているので、指導を受けながらなら実践ができる。



表２．５ー６プロジェクトマネジメント・カテゴリーにおけるスキルレベル（例）

注）ここに示すスキルレベルは一例です。例えば、海外プロジェクト等のリスクが高いプロジェクトを中心に実

施している組織では、熟達度レベル３でも、リスクマネジメントのスキルレベルは３もしくは４以上が必要な

場合もがあるなど､組織の実態に合わせてテーラリングが必要となります。

表２．５－７パーソナルスキル、インダストリ／適用業務スキル、ビジネスマネジメントスキル･

カテゴリにおけるスキルレベル(例)

熟達度レベル１２３４５６７

統合マネジメント 3 3

スコープマネジメント 2 3

タイムマネジメント 3 4

コストマネジメント 2 3

品質マネジメント 3 4

コミュニケーションマネジメント 3 3

人的資源マネジメント 2 3

リスクマネジメント 2 2

調達マネジメント 2 3

プロジェクトの立上げ 2 2 3

プロジェクトの計画 2 3 4

プロジェクトの実行 3 4 5

プロジェクトのコントロール 2 3 4

プロジェクトの終結 2 3 3

総合スキル・レベル △ ○ ◎

知識分野

プロセス分野

すべての項目でスキルレベル３以上で、スキルレベル４が４個以上、スキルレベル５が２

個以上のこと


リーダーシップ 2 2 4

コミュニケーション 2 3 4

ネゴシエーション 1 2 2

問題解決力 1 2 3

組織に対する影響力 1 2 2

動機付け 1 2 3

総合スキル・レベル △ ○ ◎

インダストリー／適用業務スキル 3 3 3

情報化と経営 1 2

財務諸表と経営分析 1 2

顧客とのリレーションシップ 1 2 3

関連法規の理解と順守 1 2

契約条項の理解と順守 1 2 3

顧客や相手国のビジネス習慣や文化の理解 1 2 3

総合スキル・レベル △ ○

ビジネスマネジメン

ト・スキル

パーソナルマネジメン

ト・スキル



表２．５－８テクノロジ／メソドロジースキル･カテゴリにおけるスキルレベル(例)


業務・システム要件分析 4 4 4

システム／ＮＷ／障害対策設計 4 4 3

セキュリティ設計 4 4 3

運用設計 3 4 3

情報技術（ＩＴ），ネットワーク技術 4 4 3

Ｓ／Ｗエンジニアリング 4 4 4

コンサルティング・メソドロジーの活用 2 3 3

ナレッジマネジメントの活用 2 3 3

総合スキル・レベル ○ ◎ ○

テクノロジー／メソドロ

ジー

・スキル



２．６改善提案サマリー

ＷＧにおいて各節 2.1～2.5 にて討議・提案された内容を一覧としてまとめたものを本報告書の添付

資料として添付します。

添付資料２－１：上記各節 2.1～2.5 の改善提案を表形式にまとめたものです。

添付資料２－２：討議結果に基づく改善提案をＩＴスキル標準様式に従い修正した表です。



３．研修ロードマップ

研修ロードマップ Ver1.2（以下、既存研修と称す）に対する検討は、下記前提の下で行われ、その検

討結果を改善提案として本章で記述します。

３．１前提（順不同）

① 学ぶべきスキル（知識）分野と研修受講の PM レベルについては、PM 育成ハンドブックのスキル量イ

メージに従って見直します。

② PM エントリに必要なテクノロジ分野の研修は、PM 職種になる前の職種に在籍している間に、習得して

いることとします。

③ メソドロジ、プロジェクトマネジメント、ビジネス/インダストリ、およびパーソナルなどのスキル分野

で示されるプロジェクトマネジメント研修コースについて、その妥当性や必要性について検討します。

④ その結果として、既存研修のプロジェクトマネジメント研修コース以外に必要なものが出てきたら追加

します。また不適当と思われる部分は変更または削除します。

⑤ 既存の研修コースごとのシラバスの内容にまで踏み込んだ検討は今回は行いません。また、改善提案も

行いません。但し、鳥瞰的に検証し、問題ある部分についてはその内容を指摘し、改善提案に含めます。

⑥ 既存研修体系図に示すコース名とその研修内容および関連知識項目に大きな食い違いあり、全面的に研

修コースを見直します。

⑦ 既存研修の研修体系図は、プロジェクトマネジメントの専門分野毎に作成されているが、見易さの観点

などから、ひとつに統一できないかを検討します。

⑧ 既存研修の研修コース一覧では、コースを職種共通、専門分野別選択、あるいは、基礎講座、上級講座、

特別講座に分類しているが、このような分類が必要か、妥当かなどについても検討します。

⑨ コースの中に特定の団体名や名称を使用している部分については、汎用的な名称に変更するか、または

削除する。（例、ＩＰＤ，ＰＭＰ，ＰＭＢＯＫなど）

⑩ ＩＴアウトソーシングのプロジェクトマネジメントは活動領域として情報化企画および運用が入るので、

これに関連する研修や知識項目を追加する。

３．２検討内容

研修コース体系全般について数回に分けて検討を行い、各委員から以下のような意見が提示されました。

１）全般的な検討

①コンサルティングメソドロジはレベル 4 で実施するのが妥当ではないか？

妥当なのでレベル４実施に改善提案します。

②DOA 構造化手法は、レベル 3 で実施するべきではないか？

開発手法には各種ありますので、ここでは開発手法と変更するとの意見もありましたが、要

件定義技法に含めることにしました。また、レベル２から 3 で行われる研修コースです。



③PM 方法論はメソドロジとしての分類のほうが適切ではないか？

PM 方法論はプロジェクトマネジメントのコースに入れるべきであるとの意見もありましたが、

開発方法論としてメソドロジに分類した方が適切であるということになりました。

④PM 方法論では、ライフサイクルモデルの適用方法などを学習すべきではないか？

開発方法論にて対応することになりました。

⑤コンプレックスマネジメントの名称と内容は見直したほうがよいのではないか？

事例演習などで対応することとし、コンプレックスマネジメントの名称にすることはないとい

うことで、当コースは削除することになりました。

⑥コンプレックスマネジメントでは、事例研究を含めると良いのではないか？

事例演習で対応することでよいのではないかということになりました。

⑦PMBOK の９つのエリア毎にレベル 4 での個別研修があるべきではないか？

レベル４で PMBOK をプロセス中心と技法中心のコースで対応することになりました。

⑧ファイナンシャルマネジメントはコストマネジメントとしたほうがよいのではないか？

（ファイナンシャルマネジメントの本義から言えば、もっと高レベルでの実施が妥当あろう）

ファイナンシャルマネジメントとコストマネジメントはコースを分けた方がよい。よって、コ

ストマネジメントは PMBOK の９つのエリアに属し、ファイナンシャルマネジメントはもっと

高次元の研修コースとしたほうが良いとの結論になりました。

⑨PM 基礎、実践、個別の内容（シラバス）の相違がほとんどない。これらを明確にするべきではない

か？

その通りであるので、そのようなコース体系で改善提言することになりました。

⑩PMBOK の９つのエリアのほかに、５つのプロセスの切り口でのコースがあってもよいのではいない

か？

上記⑦の結論と同じ。

⑪PM 実践：ツールとプロセスは分けて研修をするべきではないか？

PM ツールが使用できることは必要であるが、特定なメーカの製品のため、当コース体系に掲

載することは削除した方が無難ではないかということで、削除しました。

⑫ 新動向のレベル差は何を意味するのかを明確にしたほうが良い。

いくつかのレベルに跨ったコース体系になっているが、これは該当するレベルの PM すべてが

受講することを推奨していることを示している。

⑬全般的に、シラバスの内容を精査するべきではないか？（シラバスと知識スキル項目が合っていない

研修が散見される）

必要であるが、今回はシラバスとスキル項目まで踏み込んだ議論はできませんでした。

⑭パーソナルは、レベル 3 のみでの実施としたほうがよいのではないか？

レベル３で受講するもの、レベル４で受講するものをコースによって分けて明記することにな

りました。

⑮パーソナルは、細分化したほうがよいのではないか？（メンタリングなど）

レベル４からメンタリングについての研修も必要ということで追加することになりました。

⑯アウトソーシング：ファイナンシャルマネジメントをレベル 5 に追加するべきではないか？

上記⑧にも関連するが、ファイナンシャルマネジメントをレベル 5 に追加することになりまし

た。



⑰アウトソーシング：DOA を削除すべきではないと思われる

DOA は要件定義技法の一つであるので、アウトソーシングだけでなく、業務要件分析が必要な

すべてのＰＭ専門分野に関係するので、共通にとりあげ、アウトソーシングから削除すること

になりました。

⑱ネットワーク：ネットワーク手法という研修が必要ではないか？

この研修はＰＭで検討するより、ＩＴスペシャリストなどの職種でコース対応を検討してもら

う必要があるのでないかということになりました。

⑲ネットワーク：シラバスの内容を見直すべきではないか？

上記⑬と同じ。

⑳ソフトウェア開発：ファイナンシャルマネジメントをレベル 5 に追加するべきではないか？

その通り提言することになりました。（上記⑯参照）

○21 ソフトウェア開発：DOA（名称を開発手法に改める）を削除すべきではないと思われる

上記⑰と同じ

○22 SW 開発プロジェクトマネジメントのシラバスにおいて、IPD というのは一般用語か？もっとわかり

やすく記載するべきではないか？

PMBOK や IPD などの特定の名称は避け、汎用的な表現とすることになりました。

２）IT アウトソーシング、およびソフトウェア製品開発における情報化企画局面と運

用・保守局面の研修についての検討

既存研修における情報化企画局面と運用・保守局面に対する研修コースが弱いのではないかとの意見を受け

て、特にこのテーマで下記の検討が行われ、新たな研修コースの改善提案が必要との結論になりました。

２．１）IT アウトソーシング

IT アウトソーシングのプロジェクトマネジメント専門領域における戦略的情報化企画とはＩＴアウトソ

ーシングにおける企業の経営戦略（場合によっては顧客より RFP）を受けて、そのビジネスを具体化する

ための事業実現可能性検討書を作成（または RFP に対する提案書作り）します。

この種の事業は事業主、オーナから提起される事業概念や要求に拡張（要求の広がり）、多義（求める

要求に市場、技術、金融、制度などの問題）性があります。

また、プロジェクトライフサイクルも長いことから不確実性も加味される必要があり、下記のようなプ

ロセスを踏む必要があります。

① プロジェクト目的・目標の設定

② 基本運営方針の設定・基本要求仕様の確認

③ プロジェクト体制および協働関係の設定

④ Due Diligence などによるデータ収集（制約条件、資源調査、既存体制・ビジネスプロセス、設備

など）

⑤ システムと機能要件設定（概要設計）

⑥ 資金の拠出または融通に当たっての投資対効果検討（フィージビリティスタディ）

⑦ プロジェクト基本計画（開発および商用化に係る体制、技術要件、スケジュール、資源調達など）



これまでが情報化企画のプロセスであるが、場合によっては企業形態や投融資についての内容も⑥に盛り

込まれます。

よって、IT アウトソーシングビジネスにおけるレベル４または５での研修は上記に係る内容のものが必要

となります。

２．２）ソフトウェア製品開発

ソフトウェア製品開発の専門領域における線楽的情報化企画は一般の商品販売戦略における４P【プロダ

クト,プライス,プレース、プロモーション】と言ったマーケティング結果から来る情報を基に、ソフトウェ

ア製品開発に関する事業企画を受けて検討するフェーズです。

① プロジェクト目的・目標の設定

② 基本運営方針の設定・基本要求仕様の確認

③ プロジェクト体制及び協働関係の設定

④ システムと機能要件設定（概要設計）

⑤ 収支計画とその根拠、開発及び運営に必要な投資額と内訳の設定

⑥ 開発及び商用化スケジュール

⑦ マーケティング及び社外パートナーを含む開発そして運営体制（実現能力の明確化及び将来の展開

ビジョン等ビジネスモデル）

⑧ 上記を踏まえたプロジェクト基本計画（開発及び商用化に係る体制、技術要件、スケジュール、資

源調達計画等）

よって、ソフトウェア製品開発ビジネスにおけるレベル４または５での研修は上記に係る内容のものが

必要となります。

２．３）知識項目

以上から IT アウトソーシング及びソフトウェア製品開発の専門領域では、下記に示す知識・スキルが必

要となる。特にレベル 5（部分的にレベル４）にて必要な知識・スキルです。

① 各種調査及び分析手法または技法（思考・問題解決技法）

② ファイナンス

③ 経営管理【運営（アウトソーシング）】

④ 契約条項の理解と順守（プロジェクトマネジメント契約管理）

⑤ マーケティング知識【販売（ソフトウェア製品）に関する知識と手法】

⑥ 関連法規の理解と順守

２．４）既存研修ロードマップとの比較

上記に関連する知識・スキル習得のための研修としてこれまで研修体系としてレベル４または５までに

含まれるものと、そうでないものとの比較を行うと；

① 思考・問題解決技法【〇】

② 情報と経営（経営管理）



③ ファイナンス（ファイナンシャルマネジメント）【〇】

④ 契約条項の理解と順守（プロジェクトマネジメント契約管理）【〇】

⑤ マーケティング（ソフトウェア製品開発）

⑥ 関連法規の理解と遵守【〇】

【〇】はすでに研修項目として考慮され含まれているもの。

以上のことから、

①IT アウトソーシングとソフトウェア製品開発共通として追加する研修は

経営管理（情報と経営）

②ソフトウェア製品開発では

マーケティング

以上の２項目がITアウトソーシング及びソフトウェア製品開発で上流工程に関する研修項目として追加

することを提案しました。

なお、下流側については ITIL をベースとした下記項目についての研修コースを設けることを提案しまし

た。

レベル 4 には IT サービスマネジメント

レベル５には ITMS 専門分野別技法（SLA 管理、変更管理、構成管理）

なお、経営管理（経営と情報）及びファイナンシャルマネジメントは IT アウトソーシングやソフトウェ

ア製品開発のみへの適用ではなく全専門分野に適用することを提案します。

３）研修ロードマップ

２００５年度のコースの内容（シラバス）の検討は鳥瞰的なものとします。

その改善提案と理由については添付資料３－３を参照してください。



３．３改善提案

１）研修コース体系図に対する改善提案

１．１）改善提案内容

① 既存研修では、専門分野毎に作成されていた体系図を一種類に統一することを提案します。

② 各コースにスキル領域、テクノロジ（Ｔ）、メソドロジ（Ｍ）、プロジェクトマネジメント（Ｐ

Ｍ）、ビジネス／インダストリ（Ｂ）、パーソナル（Ｐ）の頭文字とそのスキル領域内の連番

をコース番号として記すことを提案します。

１．２）改善提案後の新プロジェクトマネジメント研修体系

改善提案に沿った新プロジェクトマネジメント研修体系図を図３．３－１に示す。

また、図３．３－１には、「既存コースどおり」、「既存コースを変更」、「新規追加コース」の

区分を色分けした○印で表しています。

図３．３－１プロジェクトマネジメント研修体系図

２）研修コース一覧に対する改善提案

２．１）改善提案内容

① 研修方法と研修期間は、研修機関の自由裁量にし、本一覧表から削除することを提案します。

【理由】研修コースについては、ｅラーニングと講義を使い分け、ｅラーニングで行う研修内

容や時間配分を規定しています。しかし、技術の進歩に合わせて研修内容の詳細が変

レベル１

システム設計の基礎

システム構築

システム運用/保守

テスト技法要件定義技法コンサルティング

メソドロジITSM専門分野別技法

（注１）

構造化設計・構造化プログラミング技法

開発方法論ITサービスマネジメント

(ITSM)基礎

思考・問題解決技法

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

プロジェクトマネジメント実践（プロセス編）

プロジェクト事例演習（計画編）

プロジェクトマネジメント実践（技法基礎編）

プロジェクトマネジメント技法演習

プロジェクト事例演習（実行・コントロール編）

プロジェクトマネジメントの契約管理

ファイナンシャルマネジメント

チーム編成と動機付け

業務知識

マーケティング（注２）経営管理（経営と情報）

関連法規とコンプライアンス

プロジェクトマネジメントのコミュニケーション

プロジェクトマネジメントのリーダーシップ

プロジェクトマネジメントのネゴシエーション

注１：アウトソーシングPMは必須注２：ソフトウェア製品開発PMは必須

テクノロジ

ビジネス/インダストリ

パーソナル


メソドロジ

ハイレベルエントリレベルミドルレベル

最新技術動向

レベル７レベル６レベル５

未経験レベルレベル２レベル３レベル４

メンタリング手法

コミュニティ活動

プロジェクトマネジメント最新動向

最新ビジネス動向

インダストリアプリケーション動向

メンタリング活動

T1

T2

T3

PM1

M1

M2

M3

P1

PM2

PM3

B1

M4

T4

M5

P2

P3

PM10PM5

PM7

B2

B4

B6

B5B3

P4

M7

M8

PM8

PM9PM4

PM6

M6

:既存 :変更 :新規:既存 :変更 :新規:既存 :変更 :新規:既存 :変更 :新規



化すると共に研修技術の進歩によりツールが改善されるため、この一覧表で規定する

より、研修機関の裁量に任せた方がよりよい研修が期待できます。

② また、一覧表には、各コースをコース群に分類し、かつ、このコース群を「職種共通」と「各

専門分野」に分けているが、これを廃止することを提案します。

【理由】専門分野別に固有の研修が必要とは言え、ＰＭは共通で必要になる知識が多く、敢え

て「職種共通」と「各専門分野」に分る必要がないので、体系図で示したように１種

類の体系にすることとします。

③ さらに、「基礎」と「上級」、および「特別」に分けているが、この分類の方法を廃止し、知

識項目（スキル分野）による分類のみでコース分を提案します。

【理由】「基礎」と「上級」、および「特別」もその基準が明確でなく誤解を与えるので、当

該コースを受講するＰＭレベルが分かれば受講者にはどのコースを受講したらよいか

が判断できるので、新体系図で十分です。

④ 上記の提言からコース一覧表の廃止を提言します。

【理由】新コース体系図は提言を考慮したコース一覧表の役割を果たすため、新コース体系図

があれば十分です。



２．２）改善提案後の新研修コースと既存コースとの比較

改善提案後の新研修コース一覧を、既存コースと対比して表３．３－１に示す。

表３．３－１ＰＭ研修コース新旧コース比較表

旧№ 新No.基礎システム設計 1 システム設計の基礎 T1 システム設計の基礎変更なし

基礎システム構築 2 システム構築 T2 システム構築変更なし基礎システム運用／保守 3 システム運用／保守 T3 システム運用／保守変更なし基礎プロジェクトマネジメント基礎 4 プロジェクトマネジメント基礎 PM1 プロジェクトマネジメント基礎内容変更

PM2 プロジェクトマネジメント実践（プロセス編）分割　（内容変更）PM3 プロジェクトマネジメント実践（技法基礎編）分割　（内容変更して新設）

6 プロジェクトマネジメントツールとプロセス－削除

基礎システム要件定義技法 7 システム要件定義技法 M3 要件定義技法名称・内容変更。「DOA構造化手法」コース内容の取り込み。

基礎コンサルティングメソドロジ 8 コンサルティングメソドロジ M5 コンサルティングメソドロジ変更なし上級プロジェクトマネジメントのリーダーシップ 9 プロジェクトマネジメントのリーダーシップ P2 プロジェクトマネジメントのリーダーシップ変更なし上級プロジェクトマネジメントのコミュニケーション 10 プロジェクトマネジメントのコミュニケーション P1 プロジェクトマネジメントのコミュニケーション変更なし上級プロジェクトマネジメントのネゴシエーション 11 プロジェクトマネジメントのネゴシエーション P3 プロジェクトマネジメントのネゴシエーション変更なし上級コンプレックスプロジェクトマネジメント 12 コンプレックスプロジェクトマネジメント－削除上級品質マネジメント 13 品質マネジメント－削除　（PM2、PM3に統合）上級リスクマネジメント 14 リスクマネジメント－削除　（PM2、PM3に統合）

上級ファイナンシャルマネジメント 15 ファイナンシャルマネジメント PM10 ファイナンシャルマネジメント内容変更。旧コースのコスト関連内容はPM2、PM3に統合

上級調達マネジメント 16 調達マネジメント－削除　（PM2、PM3に統合）PM5 プロジェクトマネジメントの契約管理分割　（内容変更）B6 関連法規とコンプライアンス分割　（新設）

特別最新技術動向 18 最新技術動向 T4 最新技術動向変更なし特別プロジェクトマネジメント最新動向 19 プロジェクトマネジメント最新動向 PM7 プロジェクトマネジメント最新動向変更なし特別最新ビジネス動向 20 最新ビジネス動向 B4 最新ビジネス動向変更なし特別インダストリアプリケーション動向 21 インダストリアプリケーション動向 B2 インダストリアプリケーション動向変更なし特別コミュニティ活動 22 コミュニティ活動コミュニティ活動変更なし

基礎プロジェクトマネジメント方法論（システム開発／アプリケーション開発／システムインテグレーション） 23

プロジェクトマネジメント方法論（システム開発／アプリケーション開発／システムインテグレーション） M4 開発方法論内容変更および、他コースを統合

上級 DOA構造化手法 24 DOA構造化手法－削除　（M3に統合）

上級アウトソーシングプロジェクトマネジメントのためのシステム運用管理方法論 25

アウトソーシングプロジェクトマネジメントのためのシステム運用管理方法論

－削除　（M4、M6、M8に統合）

26 アウトソーシングプロジェクトマネジメント概説－削除　（PM1でカバー）

27 アウトソーシングプロジェクトマネジメント実践－削除　（PM2、PM3でカバー）PM10 ファイナンシャルマネジメント分割　（旧ファイナンシャルマネジメントと統合）

B5 経営管理（経営と情報）分割　（新設）基礎

プロジェクトマネジメント方法論（ネットワークサービス） 29 プロジェクトマネジメント方法論（ネットワークサービス）－削除　（M4に統合）

上級ネットワークプロジェクトマネジメント事例 30 ネットワークプロジェクトマネジメント事例－削除　（PM8、PM9でカバー）上級ｅビジネスソリューション開発方法論 31 ｅビジネスソリューション開発方法論－削除　（M4に統合）上級ｅビジネスソリューションプロジェクトマネジメント 32 ｅビジネスソリューションプロジェクトマネジメント－削除　（PM2、PM3でカバー）基礎

プロジェクトマネジメント方法論（ソフトウェア製品開発） 33 プロジェクトマネジメント方法論（（ソフトウェア製品開発）－削除　（M4に統合）

上級ソフトウェア開発プロジェクトマネジメント 34 ソフトウェア開発プロジェクトマネジメント－削除　（PM2、PM3でカバー）

M1 テスト技法追加　（新設）

M2 構造化設計・構造化プログラミング技法追加　（新設）

M6 ITサービスマネジメント（ITSM)基礎追加　（新設）

M8 ITSM専門分野別技法追加　（新設）

PM14 プロジェクトマネジメント技法演習追加　（新設）

PM8 プロジェクト事例演習（計画編）追加　（新設）

PM9 プロジェクト事例演習（実行・コントロール編）追加　（新設）

PM6 チーム編成と動機付け追加　（新設）

B1 業務知識追加　（新設）

B3 マーケティング追加　（新設）

M7 思考・問題解決技法追加　（新設）

P4 メンタリング手法追加　（新設）

メンタリング活動追加　（新設）

17 プロジェクトマネジメントの契約管理プロジェクトマネジメントの契約管理

アウトソーシングビジネスのプロジェクトマネジメント

28アウトソーシングプロジェクトマネジメントのための会計・経営管理概説

eﾋﾞｼﾞﾈｽｿﾘｭｰｼｮﾝ

上級

プロジェクトマネジメント実践基礎

上級

コース群の種類

新コース名コース群コース名

ｿﾌﾄｳｪｱ開発

ｼｽ開発/AP開発/SI

職種共通

改善提案後の研修コースＩＴスキル標準　ＰＭ研修コース　V1.2

ｱｳﾄｿｰｼﾝｸﾞ

ＮＷｻｰﾋﾞｽ

5 プロジェクトマネジメント実践

変更点



３）研修コース内容に対する改善提案

「研修コースの内容」の項目で、【研修方法】【期間】は研修機関の自由裁量とするのでこの欄

から削除する。

「研修コースの内容」の項目で、【講座分類】（入門講座、基礎講座、上級講座、特別講座）を

削除する。

３．１）個別改善提案（既存コース）

『システム設計の基礎』コースについて

【研修方法】

提案内容：ワークショップは必要ない。

提案理由：基礎であり、座学のみでも良いと思われるため。

備考：【研修方法】欄の削除（研修機関の裁量範囲）提案が採用された場合は、意味を持た

なくなる提案。

【受講対象者】

提案内容：「運用管理経験者」があるが必要ない。

提案理由：「システム設計」と「運用管理」では関連が薄いと思われるため。

【受講前提】

提案内容：運用管理の経験は前提から除外する。

提案理由：「システム設計」と「運用管理」では関連が薄いと思われるため。

『システム構築』コースについて

【研修方法】

提案内容：講義を含める。

提案理由：システム構築に関しては講義なしのワークショップはやりにくいと思われ

るため。（講義をせず、プログラミング演習は難しいと思われる）



【コース概要】

提案内容：このコースで「進捗管理手法」は学習対象としなくてよい。

提案理由：システム構築活動に専念し、管理的な学習はマネジメントを扱う他コース

に任せて良いと思われる。

【関連する知識】

提案内容：このコースで「タイムマネジメント」は学習対象としなくてよい。

提案理由：システム構築活動に専念し、管理的な学習はマネジメントを扱う他コース

に任せて良いと思われる。なお、タイムマネジメントを対象とするなら、

品質マネジメントも必要と思われるし、際限が無くなる

『システム運用／保守』コースについて

【研修方法】

提案内容：ワークショップではなく、講義とすべき。

提案理由：基礎であり、座学のみでも良いと思われるため。

備考：【研修方法】欄の削除（研修機関の裁量範囲）提案が採用された場合は、

意味を持たなくなる提案。


提案内容１：本コースにはこの９つの知識エリアは不要。

提案理由１：ＰＭＢＯＫの９つの知識エリアのうち、統合Ｍ、タイムＭ、リスクＭの３

つのみ関連することになっており、理解がしにくいため。それらを含める



なら、コストＭ、組織Ｍ、スコープＭの関連も考えられ、際限がなくなる。

管理的な学習はマネジメントを扱う他コースに任せて良いと思われる。

提案内容２：「業務分析」の記述を追記すべき。

提案理由２：運用しながら次の業務改善につなげることがあると思われるため。

『プロジェクトマネジメント基礎』コースについて

コース内容全体

提案内容：コース内容を変更する。

提案理由：他の関係コースとのバランスを考慮して内容を整理した結果、他の関係コ

ースとの整合性をとるため

【研修方法】

提案内容：講義が必要。

提案理由：講義が必要であると思われるため。



【研修修了後のスキル修得目標】

提案内容：「プロジェクトマネジメントに関する基礎的な知識を駆使し、プロジェク

トメンバとして、プロジェクトを実行できる。」は、たとえば、「統一さ

れたＰＭ用語で意思疎通ができる」といった修得目標とすべき。

提案理由：基礎コースでは、左記の表現は、実態に合わないと思われるため。

『プロジェクトマネジメント実践』コースについて


提案内容：コース内容を分割後、内容を変更・追加して新コース（『プロジェクトマ

ネジメント実践（プロセス編）』と『プロジェクトマネジメント実践（技

法基礎編）』）とする。

提案理由：内容が豊富であるので、プロセス編と技法編に分けた。

『プロジェクトマネジメントツールとプロセス』コースについて


提案内容：コースを削除する。

提案理由：プロジェクト管理ツールを使いこなせることはPMとして必要であるが、

特定ベンダーのツールの学習になるため、あえて当研修体系への表記を見

送った。

『システム要件定義技法』コースについて

コース内容全体、名称

提案内容：ＤＯＡ構造化手法コースの内容を取込み、研修名を「要件定義技法」に変

更する。添付３－２参照。


提案内容：「要件定義」が「デザイン」に含められているが、これは「業務分析」に

含めたほうが良い。

提案理由：「要件定義」は、「業務分析」の一貫として行われると思われるため。

『コンサルティングメソドロジ』コースについて


提案内容：「コンサルティングに関する基礎的な知識を活用し、プロジェクトリーダ

として、効果的なコンサルティングプロセスを実践することができる。」

となっているが、プロジェクトマネージャにがどのようにコンサルプロセ

スを活用できるようになるかを記述（例示）すべき。



提案理由：コンサルティングプロセスとプロジェクトマネジメントとの関連が記載さ

れておらず、コンサルティングプロセスの必要性が理解しにくいと思われ

るため。


提案内容１：ＰＭＢＯＫの知識エリアを関連とする必要はない。かりにあるとした場合

も、（現行の）統合マネジメントのみではなく、他のプロセスも含める必

要がある。

提案理由１：コンサルティングプロセスとＰＭプロセスの関係は薄いと思われるため。

あえて関係をつけるとしても、スコープ（コンサル範囲の特定）、コスト

（追加コンサル時に追加費用）、スケジュール（ヒアリングスケジュール、

報告スケジュール）なども関係すると思われる。

提案内容２：「知的資産管理(ＫｎｏｗｌｅｄｇｅＭａｎａｇｅｍｅｎｔ)活用」の記述

は必要無い。

提案理由２：コンサルティングと「知的資産管理」の関係が理解しにくいため。

『プロジェクトマネジメントのリーダーシップ』コースについて


提案内容：「中規模以上または複雑なプロジェクト」という条件は不要。

提案理由：左記条件以外のプロジェクトでも、リーダーシップは必要であると思われ

るため。

『プロジェクトマネジメントのコミュニケーション』コースについて



提案理由：左記条件以外のプロジェクトでも、コミュニケーションは必要であると思

われるため。

『プロジェクトマネジメントのネゴシエーション』コースについて



提案理由：左記条件以外のプロジェクトでも、ネゴシエーションは必要であると思わ

れるため。

『コンプレックスプロジェクトマネジメント』コースについて



提案理由：新設の「プロジェクトマネジメント実践（技法応用編）」と「プロジェク

ト事例演習」で代替できるため。

『品質マネジメント』コースについて


提案内容：プロジェクトマネジメント実践（プロセス編）「と「プロジェクトマネジ

メント実践（技法基礎編）」に統合。添付３－２参照。


提案内容：「プロジェクト全工程における品質マネジメントを実施し、プロジェクト

責任者として、プロジェクトを成功裡に完了できる。」とあるが、「成功

裡に完了できる」は必要無い。

提案理由：研修を受けただけでは「成功裡に完了できる」ことを期待できないと思わ

れるため。




提案内容：「ソフトウェアエンジニアリング」のカテゴリ（Ｓ字カーブ、ゴンベルツ

曲線等）含めるべき。

提案理由：品質マネジメントのためには、統計等のソフト工学を理解すべきと思われ

るため。

『リスクマネジメント』コースについて


提案内容：「プロジェクトマネジメント実践（プロセス編）「と「プロジェクトマネ

ジメント実践（技法基礎編）」に統合。添付３－２参照。

【研修方法】


提案理由：講義が必要と思われるため。




提案内容：「プロジェクト全工程における様々なリスクマネジメントを実践し、プロ

ジェクト責任者として、プロジェクトを成功裡に完了できる。」とあるが、

「成功裡に完了できる」は必要無い。


れるため。

『ファイナンシャルマネジメント』コースについて


提案内容：コースの一部（コストｋ関連事項）を、「プロジェクトマネジメント実践

（プロセス編）「と「プロジェクトマネジメント実践（技法基礎編）」に

移す。添付資料３－２参照。


提案内容：「プロジェクトにおける適切なファイナンシャルマネジメントを実施し、

プロジェクト責任者として、プロジェクトを成功裡に実施できる。」とあ

るが、「成功裡に完了できる」は必要無い。


れるため。

『調達マネジメント』コースについて


提案内容：「プロジェクトマネジメント実践（プロセス編）「と「プロジェクトマネ

ジメント実践（技法基礎編）」に統合。添付３－２参照。


提案内容：「プロジェクトにおける適切な調達マネジメントを実施し、プロジェクト

責任者として、プロジェクトを成功裡に実施できる。」とあるが、「成功



れるため。


提案内容：９つの知識エリアのうち、調達Ｍの他に、スコープＭ、コストＭ、組織Ｍ、

コミュニケーションＭが記載してあるが、必要ないのではないか。仮に入

れるなら、９つ全てとすべき。

提案理由：元々、調達マネジメントコースであり、スコープＭ、コストＭ、組織Ｍ、

コミュニケーションＭを入れるのであれば、外注先の進捗管理（タイムＭ）、

外注先の倒産・撤退（リスクＭ）なども必要と思われる。



『プロジェクトマネジメントの契約管理』コースについて

提案内容：コースの一部を、新コース「関連法規とコンプライアンス」に移す。添付

資料３－２参照。

【研修方法】






提案内容：「プロジェクトにおける適切な契約マネジメントを実施し、プロジェクト

責任者として、プロジェクトを成功裡に実施できる。」とあるが、「成功



れるため。

『新技術動向』コースについて

【研修方法】

提案内容：ｅラーニングがあっても良い。

提案理由：他の動向コースはすべてｅラーニングがある




提案内容：「新技術に関する知識を活用し、プロジェクトメンバとして、開発、運

用、保守などのプロジェクトを実施することができる。」とあるが、「プ

ロジェクトメンバとして」は必要ない。

提案理由：各レベル（メンバ、マネージャ）でこのコースを受講することが想定され、

あえて「メンバとして」は必要無いと思われるため。


提案内容１：「－新技術動向」、「－新ＩＴ市場動向」が、「ＩＴソリューション

設計・開発管理」のカテゴリに含められているが、「テクノロジ」のカテ

ゴリとするべき。

提案理由１：「テクノロジ」のカテゴリが自然であると思われるため。

提案内容２：「ソフトウェアエンジニアリング」のカテゴリで何らかの記述が必要。

提案理由２：技術動向なので、ソフト工学としてのなんらかの記述も必要だと思われ

る。

『プロジェクトマネジメント新動向』コースについて

【研修方法】





『新ビジネス動向』コースについて


提案内容：「－新ＩＴ市場動向」が、「ＩＴソリューション設計・開発管理」のカ

テゴリに含められているが、「テクノロジ」のカテゴリとするか、新たな

カテゴリとするべき。

提案理由：「テクノロジ」のカテゴリがより自然であると思われるため。



『インダストリアプリケーション動向』コースについて


提案内容１：「－インダストリ知識」が、「ＩＴソリューション設計・開発管理」のカ

テゴリに含められているが、「テクノロジ」のカテゴリか、新たなカテゴ

リとするべき。

提案理由１：「テクノロジ」のカテゴリがより自然であると思われるため。

提案内容２：「ソフトウェアエンジニアリング」のカテゴリで何らかの記述が必要。

提案理由２：動向なので、ソフト工学に関するなんらかの記述も必要だと思われるため。

『コミュニティ活動』コースについて

指摘なし。

『プロジェクトマネジメント方法論（システム開発／アプリケーション開発／システムインテグレ

ーション）』コースについて


提案内容：関連コースを統合後、内容を変更して新コース「開発方法論」とする。

提案理由：各職種の方法論が、ほぼ同じ内容になっているので別々のコースである必

要もなく統合した方がよく、またコース名をV1.2と違えるために開発方

法論にした。


提案内容：「－ソフトウェアエンジニアリング」等が、「ＩＴソリューション設計・

開発管理」のカテゴリに含められているが、「ソフトウェアエンジニアリ

ング」のカテゴリが良い。

提案理由：「ソフトウェアエンジニアリング」のカテゴリが自然であると思われるた

め。

『DOA構造化手法』コースについて

提案内容：「要件定義技法」コースへ統合する。添付３－２参照。

『アウトソーシングプロジェクトマネジメントのためのシステム運用管理方法論』コースについて

【コース内容全体】




法論にした。

【研修方法】

提案内容：上級講座ではなく、基礎講座とするべき。

提案理由：他の方法論が基礎講座であるため。

備考：基礎講座、上級講座、特別講座に区分しない提案のため、意味を持たなく

なる提案。


提案内容：調達Ｍしか含まれていないが、９つの知識エリアすべてを含むのでは無い

か。そもそも、運用管理方法論は、ＰＭＢＯＫではなく、ＩＴＩＬのカテ

ゴリを適用すべき。

提案理由：アウトソーシングには開発＋運用という面があるため、より広範な知識エ

リアを含むと思われるため。また、運用管理では、ITILのサービスサポー

ト、サービスデリバリを参照することが適当と思われるため。



『アウトソーシングビジネスのプロジェクトマネジメント：アウトソーシングプロジェクトマネ

ジメント概説』コースについて



提案理由：「プロジェクトマネジメント基礎」、「プロジェクトマネジメント実践（プ

ロセス編）、（技法基礎編）、（技法応用編）」でカバーできると判断し

たため。

【研修方法】

提案内容：ｅラーニングでも良い。

提案理由：概説であるため、ｅラーニングでも良いのではないか。（ ○28『アウトソー

シングビジネスのプロジェクトマネジメント：アウトソーシングプロジ

ェクトマネジメントのための会計・経営管理概説』コース」はｅラーニン

グを含いいでいる）




ジメント実践』コースについて





たため。


提案内容：「ＰＭＰ」の記述部分は必要が無い。

提案理由：アウトソーシング以外の職種にはＰＭＰの記述が無く、また、ここに記載

されている必要性が感じられないため。

備考：コース削除提案が採用された場合は、意味を持たなくなる提案。


ジメントのための会計・経営管理概説』コースについて



提案理由：「フィナンシャル・マネジメント」と「経営管理（経営と情報）」によっ

てカバーできると判断したため。

○29 『プロジェクトマネジメント方法論（ネットワークサービス）』コースについて





たため。


提案内容：９つの知識エリアを対象とすべき。

提案理由：プロジェクトマネジメント方法論のコースであるため、９つの知識エリア

は含める必要があると思われるため。




『ネットワークプロジェクトマネジメント事例』コースについて



提案理由：「プロジェクト事例演習（計画編）、（実行・コントロール編）」でカバ

ーできると判断したため。

【研修方法】

提案内容：ｅラーニングではなく、講義とすべき。

提案理由：事例コースをｅラーニングのみでは教訓の深い部分を伝えることが難しい

と思われるため。








『ｅビジネスソリューション開発方法論』コースについて





法論にした。

『ｅビジネスソリューションプロジェクトマネジメント』コースについて





たため。

『プロジェクトマネジメント方法論（ソフトウェア製品開発方法論）』コースについて





法論にした。


提案内容：「ＩＰＤ」は「製品開発方法論」とすべき。

提案理由：「ＩＰＤ」は特定企業の方法論名でもあるため、一般名称とすべきと思わ

れるため。







『ソフトウェア開発プロジェクトマネジメント』コースについて






ロセス編）、（技法基礎編）、（技法応用編）」でカバーできると判断

したため。


提案内容：「ＩＰＤ」は「製品開発方法論」とすべき。

提案理由：「ＩＰＤ」は特定企業の方法論名でもあるため、一般名称とすべきと思わ

れるため。


３－３）個別改善提案（新規コース）

『テスト技法』コース

『構造化設計・構造化プログラミング技法』コース

『ITサービスマネジメント（ITSM)基礎』コース

『ITSM専門分野別技法』コース

『プロジェクトマネジメント実践（技法応用編）』コース

『プロジェクト事例演習（計画編）』コース

『プロジェクト事例演習（実行・コントロール編）』コース

『チーム編成と動機付け』コース

『業務知識』コース

『マーケティング』コース

『経営管理（経営と情報）』コース

『思考問題解決技法』コース

『メンタリング手法』コース

新規コースの概要説明は、添付資料３－２に記す。



４．今後の課題と提言

これまでの二年間のＷＧ活動で、ＩＴスキル標準および研修ロードマップに関する改善提案を一通り終えました。今

後のＷＧの活動については、ＰＭ委員会における討議を踏まえる必要がありますが、おおよそ以下の取り組みを考えてい

ます。

１）今後のＩＴスキル標準の改善領域や具体的関わり方について

■ＩＴスキル標準の新版に対する継続的改善提案

これまでの改善提案をインプットのひとつにして、新しいＩＴスキル標準が制定されます。当ＷＧで

はこれまでの改善提案の反映状況を確認して、必要であれば追加の改善や反映されていない箇所に関し

て再度の改善提案を出すなど、ＩＴスキル標準・研修ロードマップを我が国ＩＴのプロフェッショナル

育成のベースとして「使える」ものにするための活動を継続していきます。

■ＩＴスキル標準活用ガイドの作成

ＩＴスキル標準単体では説明不足だったり、解釈が曖昧な部分があるために達成度指標の項目を適切

に評価できない可能性があります。そもそもＩＴスキル標準は標準であり、解説文書ではありません。

そこで、ＩＴスキル標準ガイドとして解説書を作成したいと考えています。事例なども交えた実用的な

解説として達成度評価や熟達度評価の実務に役立つものにして、特に中小規模の企業や組織がそのまま

ＩＴスキル標準を用いたスキル評価や認定ができることを目指したいと思います。

■上流工程や発注側視点の考慮

本検討テーマは 2005 年度の検討課題でしたが、他の作業の影響で優先度を下げていました。これを

2006 年度も検討課題として再度取り上げ、具体的に検討することとします。特にＩＴアウトソーシン

グ及びソフトウェア製品開発についての企画段階のプロジェクトマネジメントを考えた時に、ＩＴスキ

ル標準をどう解釈もしくは改善すべきか、を検討していきます。

なお、顧客作成の RFP の拙劣さが多くのプロジェクトでの失敗原因のひとつとなっています。その主

因となっている顧客側（上流側）のプロジェクトマネジメントについての考察についても 2006 年度に

行います。

２）ＰＭコミュニティとしての取り組みの拡大

2006 年度も引き続き PM 委員会発信のＰＭコミュニティ活動を活性化していきます。

■研究会の発足

コミュニティ活動として、PM に関連する課題研究を行っていきたいと考えています。また、少しず

つですが、コミュニティへの参加者を増やしてコミュニティが継続する仕組みを検討して行きます。な

お、現時点で活動中の研究会は以下のものです。

① ＰＭＯ研究会

各社の事例研究を中心としてＰＭＯの具備する機能を体系化します。

② 笑力研究会

笑力（笑う力＋笑いを引き出す力）をプロジェクトが成功に向かう現場で如何に活用してチーム

の生産性を高めるかを研究します。

③ その他の研究テーマ



必要に応じて、委員・ＷＧメンバーの発案により積極的に研究会を立ち上げていきます。

■ 他のコミュニティとの連携

ＩＴスキル標準を中心として、他の専門分野など、横の連携やコミュニケーションを通じて、ＩＴス

キル標準の有効な改善が期待できると考えています。

２００５年度もＰＭ委員会やＷＧはＩＴスキル標準のＩＴ産業における有効性を更に高めるための一助に

微力ながらも役立てたのでは無いかと思います。今後は上記のような検討テーマやＰＭを育成するための

様々な活動に、文字通り「プロジェクトマネジメント分野のプロフェッショナルが集まるコミュニティ」と

して更に貢献できるような動きにして行ければと考えています。



添付資料


資料２－１改善提案サマリー

資料２－２ＩＴスキル標準達成度指標改善提言版（職種：プロジェクトマネジメント）

資料３－１研修コース変更に対する改善提案内容


資料３－３研修ロードマップ改善提案内容と理由




Ｃ．１プロフェッショナルコミュニティ

● プロフェッショナルコミュニティ設立趣旨

独立行政法人情報処理推進機構ＩＴスキル標準センターでは、ＩＴスキル標準の改版や、企業等での

活用事例の収集・分析、及びプロフェッショナルの後進育成に有益な情報発信等を行うことを目的とし

て、プロフェッショナル人材や、ＩＴスキル標準を活用した人事・教育訓練制度を先進的に実行してい

るＩＴ企業などの知見の収集、ＩＴスキル標準を基盤とした人材育成の支援事業を進めています。

この一環として、ビジネスの第一線で活躍しているハイレベルのスキルを持つ者同士が、社内や組織

の論理に捕らわれずに建設的に情報交換や議論が行えるような場を通じて、ＩＴスキル標準の改版、人

材育成のあり方等、次世代ＩＴサービスビジネスを担う後進人材のスキルアップに貢献するための諸活

動を行う「プロフェッショナルコミュニティ」を創設致しました。

● 活動内容

委員会は、プロフェッショナルコミュニティの目的を達成するために次の活動を行い、その成果を資

料等にまとめて情報を発信致します。

・後進人材育成のためのガイドライン作成

・ＩＴスキル標準／研修ロードマップの内容のレビュー・改善

・ハイレベルなＩＴ人材の育成要素に関する助言等

・その他目的を達成するために必要な活動など



Ｃ．２プロジェクトマネジメント委員会の設置

● 委員会の設置について

ＩＴスキル標準プロフェッショナルコミュニティでは、業界にても要望が高い、プロジェクト

マネジメントのハイレベルな人材育成を目的として「プロジェクトマネジメント委員会」を設置しま

した。

● プロジェクトマネジメント委員

既にプロジェクトマネジメントの分野において活躍されている団体がありますが、その中より、

・日本プロジェクトマネジメント協会（ＰＭＡＪ）（旧ＪＰＭＦ）

・ＰＭＩ東京支部（ＰＭＩＴ）

・プロジェクトマネジメント学会（ＳＰＭ）

に、ハイレベルな人材を保有されている企業をご紹介頂き、企業の代表を委員として平成１６年５

月にプロジェクトマネジメント委員会が発足しました。なお、平成１８年１月現在における本委員会

の委員（◎は主査，○は副主査）は次の通りです。

井沢澄雄日本電気株式会社

乾諭史日本アイ・ビー・エム研修サービス株式会社

岡田寿日本ユニカシステムズ株式会社

北野利光キヤノンシステムソリューションズ株式会社

向後忠明ＮＴＴリース株式会社

齋恒夫株式会社グランドユニット

澤田友宏株式会社日立製作所

土出克夫富士通株式会社

丹羽武志株式会社インテック

◎橋爪宗信株式会社ＮＴＴデータ

○濱久人松下電器産業株式会社

好川哲人エム・アンド・ティ・コンサルティング

（五十音順）

※齋恒夫： WG2 のみ



// 主な活動内容 //

日本 IBM へ入社後、主に、金融業・製造業・流通業のお客様

向けのアプリケーション開発SE、プロジェクトマネジャー、

SE マネジャーを担当。

その後、SE 本部において SE リソースに関する施策の立案・

企画を担当後、日本 IBM の SE 関連会社に出向。

日本 IBM への復帰後は、プロジェクトマネジメント・プロフ

ェッション・リーダーとして、日本 IBM におけるプロジェク

トマネジャー育成に関する諸施策の立案・企画・推進を担当。

2000 年 10 月から、日本 IBM 研修サービス株式会社に

おいて、プロジェクトマネジメントの必要性・重要性な

どの啓蒙活動や、PM 育成のコンサルタントおよび講師な

どを担当。

PMP、IT コーディネータ

プロジェクトマネジメント学会正会員、PMI および PMI

東京支部会員、JPMF 会員

日本アイ・ビー・エム研修サービス（株）ラーニングアドバイザー

乾諭史 Satoshi INUI


日本電気株式会社に入社後、主に官庁系、公共

系、一般産業系の情報システム開発プロジェクト

に参画し、SE、プロジェクトマネージャーを担当。その後、プロジェクトマネジメントに関する研修の企画・開発・講師を経て、エンタープライズ系、組込み系の双方のプロジェクトマネジメント関連活動を展開中。主な出版物「ソフトウェア開発のプロジェクトマネジメント入門」（1999/4、共訳、日刊工業新聞社）「オブジェクト指向とコンポーネントによるソフトウェア工学－UMLを使って－」（2000/9、共訳、ピアソン・エデュケーション）経済産業省組込みソフトウェア開発力強化推進委員会委員（プロジェクトマネジメント技術部会所属）

日本情報処理学会、プロジェクトマネジメント学

会正会員技術士（情報工学部門）、PMP、PMS、情報処理技術者（プロジェクトマネージャー、システムアナリスト、システム監査技術者、アプリケーションエンジニア、上級システムアドミニストレータ等）

井沢澄雄

日本電気（株）

ソフトウェアエンジニアリング本部

兼組込みソリューション事業推進本部

マネージャー

技術士


日本電気株式会社に入社後、主に官庁系、公共

系、一般産業系の情報システム開発プロジェクト

に参画し、SE、プロジェクトマネージャーを担当。その後、プロジェクトマネジメントに関する研修の企画・開発・講師を経て、エンタープライズ系、組込み系の双方のプロジェクトマネジメント関連活動を展開中。主な出版物「ソフトウェア開発のプロジェクトマネジメント入門」（1999/4、共訳、日刊工業新聞社）「オブジェクト指向とコンポーネントによるソフトウェア工学－UMLを使って－」（2000/9、共訳、ピアソン・エデュケーション）経済産業省組込みソフトウェア開発力強化推進委員会委員（プロジェクトマネジメント技術部会所属）

日本情報処理学会、プロジェクトマネジメント学

会正会員技術士（情報工学部門）、PMP、PMS、情報処理技術者（プロジェクトマネージャー、システムアナリスト、システム監査技術者、アプリケーションエンジニア、上級システムアドミニストレータ等）

井沢澄雄

日本電気（株）

ソフトウェアエンジニアリング本部

兼組込みソリューション事業推進本部

マネージャー

技術士




1967 年、日本ユニバック株式会社へ入社以来、商社、製造、

証券、都市銀行等、多数のプロジェクトにて SE 及びプロジ

ェクトマネジャーに従事。

1992 年以降、情報戦略コンサルティングの方法論開発、及

び製造、流通、物流、証券、電力、地域開発等の情報戦略コ

ンサルタントに従事。

2002 年、日本ユニシス株式会社を定年退職し、現在は、日

本ユニカシステムズ株式会社で、該社経営に直接係わるビジ

ネスの仕掛・仕組造りの技術顧問に従事。

学会ビジネスモデル学会員、経営情報学会員等。

日本ユニカシステムズ（株）技術顧問

岡田寿 Hisashi OKADA


入社以来生産管理系のシステムを中心に数多くの開発を経

験

SIプロジェクトの失敗を抑制する目的で2002 年に全社組織

のプロジェクト管理部が発足し従事

具体的な活動

・プロジェクトの評価、プロセス改善の推進

・ISO9001 の認証を受け維持/改善の推進

IT スキル標準を参考に社内 PM 認定制度の立上げに関与

2006 年 1 月に品質保証を強化する目的で品質保証部が発足

し従事

キヤノンシステムソリューションズ（株）開発統括本部

品質保証部部長

北野利光 Toshimitsu KITANO




1968 年：日揮株式会社入社

1988 年：NTT インターナショナル（株）移籍

JICA 調査団団長／トルコ中央銀行決済システム構築 PJ、

タイ中央銀行決済＆小切手システム構築PJにプロジェク

トマネジャーとして参加

1993 年：NTT インターナショナル香港支店（NTT 香港

事務所兼務）代表

1995 年：PJ 部次長兼品質保証部長（ISO 認証取得）1997

年：MGTI（NTT 投資案件で設立された SPC）取締役建

設・戦略企画長部長

1999 年：スリランカテレコム（株）

民営化 PJ での CAO（Chief Administrative Officer）

2002 年：NTT コミュニケーション（株）

ソリューション事業部企画部、及び IT ビジネス推進部

PM アドバイザー（PMO 設立及び PM 育成・資格認定制

度企画）、及び財務部 PM アドバイザー（次期経理シス

テム更改・構築 PJ）

2004 年：ＮＴＴリース

新ビジネス開発ＰＴ立ち上げ、運営

日本ＰＭ協会（ＰＭＡＪ）理事、国際Ｐ２Ｍ会員

向後忠明

ＮＴＴリース（株）ＰＭアドバイザー

Tadaaki KOUGO


1967 年：日本ユニシス株式会社にＳＥとして入社

生産管理パッケージの開発・客先適用、ＤＢ／ＤＣミドルウ

ェアの設計・開発・客先適用、

顧客のシステム受託開発作業等にＰＬ／ＰＭとして従事

1992 年：システム開発の標準化・規定類作成作業と普及活

動及びシステム監査業務の規定類の作成と適用に責任者とし

て従事、情報技術ビジネスプロセスの各種規定類の作成と普

及活動およびＰＭＯ活動に従事

2000 年：システム技術者のスキル認定作業に従事

2002 年：ＣＭＭＩ認定取得準備作業支援、ＰＭ指導、品質

管理、見積り関連の作業等に従事

2005 年：（株）グランドユニット社監査役

保有資格

情報処理技術者プロジェクトマネジャー

情報処理技術者システムアナリスト

齋恒夫

（株）グランドユニット社監査役

Tuneo Sai




1977 年、日立製作所に入社以来、SE として、銀行／生保／

損保／証券取引所といった金融機関の多数のプロジェクトに

参画。

現在は、金融分野の PMO として活動。

専門分野は、高性能／高信頼性システム構築。

プロジェクトマネジメント学会正会員

澤田友宏

（株）日立製作所情報・通信グループ

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

エンジニアリング部部長

Tomohiro SAWADA


主な活動領域

IT/SI プロジェクトのプロジェクトマネジメント関連

研修コース・教材開発、同支援、同研修講師／研修講師育成

支援

保有資格

PMP（PMI）

技術士（総合技術監理部門・情報工学部門）

IT コーディネータ

公認システム監査人（NPO・日本システム監査人協会）

所属団体

PMAJ（同、関西副代表）

日本技術士会

関西情報技術士会

日本システム監査人協会

ITC 近畿会

システム監査学会／情報処理学会

富士通（株）ビジネスマネジメント本部人材開発部

プロフェッショナル研修センター

土出克夫 Katsuo TSUCHIDE




1988 年：日本電信電話株式会社（NTT）入社。同年株式会

社 NTT データに分社。主に法人向け IT システムの設計・開

発に従事する。

1996 年：R&D 部門へ異動し、分散開発環境を研究。その後、

全社的な品質保証・審査（リスクマネジメント）／技術支援

組織の企画・組織化に携わる。当該組織で PM 資格制度を提

案し、全社的に PMP 取得や各種のPM 育成施策を推進する部

門（PM 推進室）の創設を担当。

2002 年：ビジネスインキュベーション部門の創設に関与し、

異動。全社における新規ビジネス創出、社内ベンチャー制度

の運営、海外VC ファンドへの投資を担当。

2003 年：SI コンピテンシー本部PMO へ異動し、全社 PMO

組織化を事務局として推進。個別ミッションとしては、PM 社

内資格認定制度運営（PM 育成）とPMO 訓練（特に品質管理）

を担当。

プロジェクトマネジメント学会理事（研究会担当）

PMP（PMI・PMIT 所属）

（株）ＮＴＴデータＳＩコンピテンシー本部

ＰＭＯＰＭ戦略担当部長

橋爪宗信 Munenobu HASHIZUME


1989 年株式会社インテックに入社

電力関連、ロジスティクス、経理、証券など、国内・国外で

SEならびにPMとして主にメインフレームを中心とした開発

および保守プロジェクトに参画しました。

現在は、全社プロセス改善推進担当として CMMI

（Capability Maturity Model Integration;能力成熟度モデ

ル統合）をベースにソフトウェア開発プロセスの改善活動に

従事しています。

国内・国外でプロセス改善に関するセミナー、研究発表を行

っています。

プロジェクトマネジメント学会正会員、

PMI／PMI 東京正会員

PMP、情報処理技術者プロジェクトマネージャ（株）インテック

技術・営業統括本部主事

丹羽武志 Takeshi NIWA




1979 年4 月、建設系の福山コンサルタント株式会社に入社。

都市計画、交通計画、道路情報システムなど、数多くのプロジ

ェクトに参画。

1989 年 10 月、松下電器産業株式会社に入社。システム開発

部門の PM として、テーマパークなどの AV システムや、官公

庁の通信システム、ITS、都市情報化などのプロジェクトを担

当。その後、営業企画部門などを経て、現在は、左記の部署に

て、経営、プロジェクトマネジメント、IT スキル標準関連の研

修を担当。

IT コーディネータ、プロジェクトマネジメントなど、各種研修

の講師も担当。

保有資格技術士（建設）、ITC インストラクタ、IT コーディネータ、PMP、

PMS、ISMS 審査員、公認システム監査人

所属団体 PMI、PMIT、PM 学会、日本情報処理学会、土木工学会、ITCA、システムアナリスト協会

濱久人

松下電器産業（株）人材開発カンパニー

コーポレート技術研修センター東京チームチームリーダ

Hisato HAMA


1982 年三菱重工業（株）入社、プラント計装業務経験のエレクト

ロニクス事業の立ち上げにかかわり、保有技術を活用した製品開発

プロジェクト数プロジェクトを担当。

1990 年（財）京都高度技術研究所入所、ソフトウエアエンジニア

リング研究室室長としてR&D マネジメントを行う。

1992 年エム・アンド・ティ・コンサルティングを設立。技術開

発型の事業の戦略策定から、製品開発プロジェクトマネジメントの

オペレーションまで幅広いコンサルティングを提供。

1998 年リーダー育成サービスを提供するエム・アンド・ティ・

ヒューマンクリエイツを設立。コンピテンシーマネジメントの導入

を行う。

2004 年プロジェクトマネジメントのプロフェッショナルサービ

スを行うプロジェクトマネジメントオフィスを設立。プロジェクト

マネジメントのコンサルティング、トレーニング事業の傍ら、Web

サービスを展開。メールマガジン「プロジェクトマネジャー養成マ

ガジン」にて15000 人に PM に対する独自の意見を発信する。

保有資格

技術士（情報工学）、ＭＢＡ（神戸大学）

所属団体

PMAJ、PMI、PMIT、PM 学会、IEEE、経営行動科学学会、

組織学会

（有）プロジェクトマネジメントオフィス代表

Tetsuto YOSHIKAWA

好川哲人

ITSS＆研修改善報告（２００５年度版）v0.9.doc


資料２－１ IT スキル標準改善提案サマリー

章●節カテゴリ改善提案提案№ 備考１）職種の説明につい

て職種の説明に関する定義の変更を下記のとおり提案。

【現状】　プロジェクトの立ち上げ、計画策定、遂行および管理を実施し、契約上の納入物にも責任を持つ。

【改善案】　プロジェクトの提案、立ち上げ、計画策定、遂行及び進捗管理を実施し、計画された納入物・サービス及びその品質（Ｑ）・コスト（Ｃ）・納期（Ｄ）に責任を持つ。

1


システム開発／アプリケーション開発／システムインテグレーションおよびeビジネスソリューションを、「システム開発」に統合するとともに、定義の変更を下記のとおり提案。【現状】　ITソリューションの設計、開発に係るプロジェクトマネジメントを行う。【改善案】　ＩＴシステムの提案・開発・保守に係わるプロジェクトマネジメントを行う（ＩＴシステムとして要求される機能を実現するためのソフトウェアを開発し、コンピュータ・ネットワーク環境及び付帯設備を構築する。インターネットテクノロジを使用した

2


「ｅビジネスソリューション」は削除することを提案。ただし、「システム開発」の定義に、インターネットテクノロジの活用を含む趣旨を盛り込ませる。

3

「ソフトウェア開発」の名称を、「ソフトウェア製品開発」に変更するとともに、定義の変更を下記のとおり提案。【現状】　ソフトウェア製品の設計、開発、改良及び保守に係るプロジェクトマネジメントを行う。【改善案】　不特定多数のユーザを対象としたソフトウェア製品の企画・設計、開発、改良及び保守に係るプロジェクトマネジメント

4

レベル7を新設することを提案。 5 ５）アウトソーシングに

ついて「アウトソーシング」の名称を、「ＩＴアウトソーシング」に変更するとともに、定義の変更を下記のとおり提案【現状】　情報システム環境の改善を通じた情報システムの効果的な運用に係るプロジェクトマネジメントを行う。管理対象として、アプリケーション開発、保守、システム運用、サポートデスク運用、業務運用などが含まれる。【改善案】　顧客の経営戦略を受けて、外部組織としてＩＴシステムの企画・構築・保守、システム運用、サポートデスク運用、業務運用に係るプロジェクトマネジメントを行う。

6

「システム開発」の定義にネットワーク環境や付帯設備の構築等を加えることを提案 7導入拠点数の変更に 8レベル7を新設することを提案。 9

■戦略的情報化企画局面での活動について

下記のとおり変更することを提案。 ●「プロジェクト基本計画の策定」を削除する ●管理統制に必要な計画として定義し「プロジェクト計画の策定」とし、下記の変更を併せて行う。

　→プロジェクトマネジメントの主たる活動局面とする　→タイミングはソリューション設計の局面に位置づける

10

■プロジェクト基本計画について

課題整理/分析局面での活動は、専門分野を2種類に大別し下記のとおり変更することを提案。 ●システム開発及びネットワークサービス

　　→特に活動は定義しない ●ＩＴアウトソーシング及びでソフトウェア製品開発

　　→課題の整理、分析を継続的に実施するので、この局面での活動を「情報化企画」とする　　→プロジェクトマネジメントの従たる活動局面とする

11

１-1）プロジェクト難易度と達成度指標の関係

達成度指標のうち、「サイズ」については「プロジェクト規模」とすることの検討を提案。12

レベル４の責任性においては「プロジェクトリーダ」という名称を削除し、レベル５以上と同じく、「プロジェクトの責任者」とすることを提案。

13

レベル５の複雑性の中で「システム要件の複雑性」を、「システム構築要件の複雑性」と修正することを提案。 14レベル３の責任性において、サイズについての規定を削除することを提案。 15レベル６における「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル５における「顧客の部長相当以上への満足感の提供」は、レベル５，６において共通に「顧客への満足感の提供」と表現することを提案。

16

レベル４の「プロジェクトリーダ」は「プロジェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを提案。 17契約金額についてはネットワークサービスではハードウェアの金額に左右されるため、サイズの決定要素とせず、導入作業拠点数によるものに置き換えることを提案。

18

レベル7を新設することを提案。－提案№８と同じレベル５から国際性を考慮することを提案。 19ソフトウェア製品開発においてもレベル７が必要との多数意見により追加を提案。－提案№５と同じレベル４の「プロジェクトリーダ」は「プロジェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを提案。 20レベル３は「ピーク時の要員数１０人未満のプロジェクト」というサイズの削除を提案。 21レベル６において「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル５において「顧客の部長相当以上への満足感の提供」は、レベル５，６において共通に「顧客への満足感の提供」と表現することを提案。

22

①プロジェクトマネジメントのスキル

「統合マネジメント」の部分に、“ＰＭにとって、契約に関する知識は重要である”ということを記述しておくことを提案。23

②パーソナルスキル職種共通スキル項目として、現在の項目に加え、下記項目の追加を提案。　　●分析力　　●行動力　　●倫理（社会的責任）

24

職種共通スキル項目「業務分析」のスキル熟達度を以下のように変更することを提案。【現状】　業界/技術動向の先見的見地に基づき複雑高度な業務要件/技術要件分析を行うことができる。【改善案】　専門家の意見に基づき、お客様の経営課題を理解し、最適な業務／技術要件を提案・判断できる。

25

職種共通スキル項目「コンサルティングメソドロジの活用」のスキル熟達度を以下のように変更することを提案。【現状】　最適なコンサルティングメソドロジの選択と適用、プロセスの定義と実践、成果物の定義と作成、コンサルティング技術の適用を行い、プロジェクトを成功裡に実施することができる。【改善案】　プロジェクト特性に応じたコンサルメソドロジーの選択と適用、プロセスの定義と実践、成果物の定義と作成、コンサルティング技術の適用を行い、プロジェクトを成功裡に実施することができる。

26

職種共通スキル項目「コンサルティングの実施」のスキル熟達度を削除することを提案。 27 ④スキルレベル各スキル領域におけるレベル（熟達度レベル）についての測定が立場（各レベルにおけるプロジェクトサイズ）を除いて

具体性に問題があるため、レベル毎の個別の熟達度に関する定義は止めて一本化し、各レベルは新たにスキルレベルを設定し、熟達度レベルに対応させることを提案。（２．５参照）

28

全般「スキル熟達度」のレベルをあらわす「スキルレベル」の概念を導入し、2段階で表現することで、知識項目ごとのレベルと「スキル熟達度」のレベルの関係を論理的に表現できる考え方を提案。

－提案№24と同じ

専門分野の変更（eビジネスソリューションのシステム開発への統合）に基づく知識項目の見直しを提案。 29統合マネジメントにて”契約は重要である”旨を記述することを提案。

30


①「システム開発」における議論

⑤「ソフトウェア製品開発」における議論

③職種共通的なテクノロジー及びメソロジーに関するスキル

２．４スキル領域

２．５スキル領域・熟達度・知識項目知識項目


③「ネットワークサービス」における議論

２．１ PM職種の説明と専門分野

２．２ IT投資の局面と活動領域そして職種の説明




資料２－２ＩＴスキル標準達成度指標改善提言版



資料３－１研修コース変更に対する改善提案内容既存のＰＭ研修体系の内、下記コースについて、コース名、あるいはコース内容を変更することを提言

する。

１）コース名の変更

・システム要件定義技法－－－－＞要件定義技法

理由：内容がシステム要件に限らず、業務要件を含めた内容になっているので、システム

要件を外し単に要件とした。

２）コース内容の変更

・プロジェクトマネジメント基礎・ファイナンシャルマネジメント

理由：他の関係コースとのバランスを考慮して内容を整理した結果、他の関係コースとの

整合性をとるために内容を変更した。

・要件定義技法

理由： Ver1.2 では独立したコースであるＤＯＡ構造化手法は、業務要件をまとめるのに

有効な技法であるので、要件定義技法に吸収した。また、当コースには、業務要件技

法としても有効であるＵＭＬについても学習する。

３）コース内容を分割後、内容を変更・追加して新コースとしたもの

・プロジェクトマネジメント実践－－＞プロジェクトマネジメント実践（プロセス編）と

プロジェクトマネジメント実践（技法基礎編）

理由：内容が豊富であるので、プロセス編と技法編に分けた。

・プロジェクトマネジメントの契約管理－＞プロジェクトマネジメントの契約管理と

関連法規とコンプライアンス（追加・新設）

理由：契約関係、法律関係を分割して、それぞれ独立したコースにし、内容を追加した。

４）コースを統合後、内容を変更して新コースとしたもの

① グループ A

理由：ほぼ同じ内容になっているので別々のコースである必要もなく統合した方がよく、

また、コース名を V1.2 と違えるために開発方法論にしたもの。

該当コース：

システム開発/インテグレーション方法論－－－－－－－－――－＞Ｍ４：開発方法論

・ｅビジネスソリューション開発方法論－－－－－－－－－－－－＞同上

・プロジェクトマネジメント方法論（ソフトウェア製品開発方法論）－＞同上

・プロジェクトマネジメント方法論（ネットワークサービス）－－－－＞同上



② グループ B

理由：プロジェクトマネジメント実践コースの主要な内容であり、別立てにしておくと内

容の重複が起こり非効率になるので、プロジェクトマネジメント実践コースに吸収合

併し、効率化と簡素化を図るもの。

該当コース：

・品質マネジメント－－－－－＞ＰＭ２：プロジェクトマネジメント実践（プロセス編）と

ＰＭ３：プロジェクトマネジメント実践（技法基礎編）

・リスクマネジメント－－－－－－－－－－－－－－－＞同上

・ファイナンシャルマネジメント－－－－－－－－－－＞同上

・調達マネジメント－－－－－－－－－－－－－－－－＞同上

③ グループ C

理由：プロジェクトマネジメントの研修コースを専門分野毎に分ける必要がなく、新設の

下記３つのコースで対応可能のため、吸収合併し、効率化と簡素化を図るもの。

該当コース：

・アウトソーシングプロジェクトマネジメント実践－－－－－＞同上、および

ＰＭ４：プロジェクトマネジメント技法演習

・e ビジネスソリューションプロジェクトマネジメント－－－－＞同上

・ソフトウェア開発プロジェクトマネジメント－－－－－－－＞同上

④ グループ D

理由：プロジェクトマネジメント基礎は IT のプロジェクトをマネジメントする上での基本

を学ぶコースであるので、IT アウトソーシングのプロジェクトマネジメントにも対応

可能のため、プロジェクトマネジメント基礎に吸収合併し、効率化と簡素化を図るも

の。

該当コース：

・アウトソーシングプロジェクトマネジメント概説

－－－－－－＞ＰＭ１：プロジェクトマネジメント基礎

⑤ グループ E

理由：会計知識や経営管理知識はハイレベルのＰＭには必要な知識であり、IT アウトソー

シングのＰＭだけのコースにする必要もなく、また、講義内容も会計と経営管理を別

立てにしてよりコース目的や内容を明確にしたもの。

該当コース：

・アウトソーシングプロジェクトマネジメントのための会計・経営管理概説

－－－－－－－＞ＰＭ１０：ファイナンシャル・マネジメントと

Ｂ５：経営管理（追加・新設）

⑥ グループ F

理由：新設の２つのコースでプロジェクトマネジメントの事例演習としては対応可能のた

め、吸収合併し、効率化と簡素化を図ったもの。

該当コース：

・ネットワークプロジェクトマネジメント事例



－－－－－－－＞ＰＭ８：プロジェクト事例演習（計画編）と

ＰＭ９：プロジェクト事例演習（実行・コントロール編）

５）Ver1.2 版（既存）のコースの中で受講レベルを変更したもの

・コンサルティングメソドロジ：レベル３－－－＞レベル４

理由：当コースを受講しても実践できるのは、リーダー・レベルであるので、 PM の場合

は、PM としての経験ができるのはレベル４からであるので、レベル３での受講では

早すぎる、また、当コースの受講後の効果を期待できるのはレベル４での受講とした。

・ファイナンシャルマネジメント：レベル４－－－＞レベル５

理由：当コースの内容から判断すると、ハイレベルのマネジメントには要求されるファイ

ナンシャルの知識であるので、それなりのレベルに達してからの受講が効果的である

ので、レベル５での受講とした。

６）削除したコース

・コンプレックスプロジェクトマネジメント

－－－－＞新設のＰＭ４：プロジェクトマネジメント実践（技法応用編）および

ＰＭ８とＰＭ９：プロジェクト事例演習で代替できるので削除した。

・プロジェクト管理ツールとプロセス－－－プロジェクト管理ツールを使いこなせること

は PM として必要であるが、特定ベンダーのツールの学習になるため、あえて当研

修体系への表記を見送った。




V1.2 で不足していて、PM としては必要と思われる下記コースを、新規に追加することを提言する。

１）メソドロジ

・Ｍ１：テスト技法（追加・新設）

コース概要：当コースは一般的な情報システムの品質を高めるために必要となる各種のテ

スト技法の知識を身に付けることを目指す。

・テスト計画の必要性とその内容、

・単体テスト、統合テスト（プログラム間、業務間、システム・業務間）、

・ネットワーク接続テスト、性能テスト、障害テスト、運用テスト、本番環境テス

ト、受入テスト等各種テストの役割とその機能、

・テスト方式（ブラックボックスとホワイトボックス・テスト）、

・テスト・カバレッジ（命令網羅性、分岐網羅性、条件網羅性、など）、

・テスト・ケースの決め方、

・テスト管理など

・Ｍ２：構造化設計・構造化プログラミング技法（追加・新設）

コース概要：当コースは、専門分野を問わず、ＰＭが情報システム開発プロジェクトに携

わる際に必要となる、複合化設計および構造化プログラミングに関する技法を学ぶ。

・Ｍ３：要件定義技法（内容変更・新設）

コース概要と変更点：当コースは、Ver1.2 版のシステム要件定義技法コースと Ver1.2

版の DOA 構造化手法コースを統合し、Ver1.2 版のシステム要件定義技法を要件

定義技法と名称変更したものである。

現モデル、新モデル、物理モデル、論理モデルを用いた業務分析・要件のアプロー

チとシステム要件の分析・まとめなどを学ぶ。

・Ｍ４：開発方法論（内容変更・新設）

コース概要と変更点： Ver1.2 版の下記コースから開発方法論を統合し、さらに、近の

開発方法論を盛り込んだ内容にしたのが当コースである。情報システムを開発する

ときの開発方法論に、ウォーターフォール法、プロトタイプ法、インクリメンタル

法、RAD 法、アジャイル法、OO による開発方法論など各種の方法論がある。当コ

ースでは、これらの方法論がどのようなもので、どのように利用すればよいかなど

について学習する。

なお、下記コースから開発方法論の除いた残りの内容は、該当の Ver1.2 版のコー



ス、あるいは新規のコースに吸収可能な内容です。

・システム開発/インテグレーション方法論

・ｅビジネスソリューション開発方法論

・プロジェクトマネジメント方法論（ソフトウェア製品開発方法論）

・プロジェクトマネジメント方法論（ネットワークサービス）

・Ｍ６：IT サービスマネジメント（ITSM）基礎（追加・新設）

コース概要：当コースは、専門分野を問わずプロジェクトマネジメント職種が情報システ

ムの運用管理においてどのようなことがなされなければならないかを理解し、情報

システム開発時から運用管理を視野にいれた開発ができることを目指しており、IT

サービスマネジメント全般について基礎知識を習得するコースである。

・Ｍ７：思考・問題解決技法（追加・新設）

コース概要：当コースでは、プロジェクト責任者がプロジェクト運営する際に遭遇するあ

らゆる問題に対しその解決策を考える上での基本になる各種の問題解決技法や思考

技法、意思決定技法について学習します。

・ブレーンストーミング法・KJ 法・ケプナー・トリゴー法

・ロジカルシンキング・クリティカルシンキングなど

・Ｍ８：ITSM 専門分野別技法（追加・新設）

コース概要：当コースは、専門分野を問わずプロジェクトマネジメント職種が IT サービ

スマネジメント（ITSM）基礎コースを修了後、ITSM の個々の技法について

更に詳細に学習するコースである。特に IT アウトソーシング分野のプロジェ

クトマネジメント職種の方は必須のコースである。

・サービスレベル管理・インシデント管理と問題管理

・構成管理・変更管理

・可用性管理と IT サービス継続性管理・キャパシティ管理

など

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

・ＰＭ１：プロジェクトマネジメント基礎（内容変更・新設）

コース概要と変更点：当コースは、プロジェクトマネジメント職種を目指す方に共通の必

須コースである。全てのプロジェクトマネジメント研修受講の前提要件となる。

Ver1.2 版のプロジェクトマネジメントの基礎コースは、主要な要件を国際的に認

められている普遍的なプロジェクトマネジメント知識体系の全知識領域について基

礎的な内容を網羅した内容になっているが、当コースでは、

特に IT のプロジェクトで重要になる Q（品質）、C（コスト）、T（タイム）を中

心にプロジェクトをどのようにマネジメントしていくとよいのかについて、その主



要な要件を国際的に認められている普遍的なプロジェクトマネジメント知識体系に

基づいて、プロジェクトの計画、実行と監視コントロールの各プロセスに沿って学

習する。

・ＰＭ２：プロジェクトマネジメント実践（プロセス編）（内容変更・新設）

コース概要と変更点： Ver1.2 版のプロジェクトマネジメント実践では、国際的に認めら

れている普遍的なプロジェクトマネジメント知識体系の９つの知識の全てのプロセ

スを、５つのプロセス群についての学習と演習と事例研究を採り入れたコースにな

っているが、当コースは、「プロジェクトマネジメント基礎」の後続コースとして

の位置づけで、国際的に認められている普遍的なプロジェクトマネジメント知識体

系で述べられている９つの知識エリアの全てのプロセスを、５つのプロセス群に沿

って、各々のプロセスで必要な入力・出力情報を中心に、演習を交えてプロジェク

トマネジメントの手順を学習し、理解します。

当コースには事例研究は採り入れていない。事例研究はプロジェクトマネジメント

技法演習として新規に独立したコースとして設定してある。

・ＰＭ３：プロジェクトマネジメント実践（技法基礎編）（内容変更・新設）

コース概要と変更点： Ver1.2 版のプロジェクトマネジメント実践では、国際的に認めら

れている普遍的なプロジェクトマネジメント知識体系の９つの知識の全てのプロセ

スを、５つのプロセス群についての学習と演習と事例研究を採り入れたコースにな

っているが、当コースは、「プロジェクトマネジメント実践（プロセス編）」の後

続コースとしての位置づけで、国際的に認められている普遍的なプロジェクトマネ

ジメント知識体系で述べられているの９つの知識の各プロセスで推奨されている技

法について、演習を交えて学習する。

当コースには事例研究は採り入れていない。事例研究はプロジェクトマネジメント

技法演習として新規に独立したコースとして設定してある。

・ＰＭ４：プロジェクトマネジメント技法演習（追加・新設）

コース概要：当コースは、「プロジェクトマネジメント実践（技法基礎編）」の後続コー

スとしての位置づけであり、特に主要な技法を演習を含めて更に詳細に学習する。

・ＷＢＳの作成と要素分解・クリティカル・パス法

・クリティカル・チェーン法・ＩＴプロジェクトの見積り手法

・ＰＥＲＴによる見積りの活用

・アーンド・バリュー・マネジメントとその活用

・品質保証と品質向上策・プロセス改善モデル

・リスク分析法：デシジョン・ツリー分析、モンテカルロ法など

・ＰＭ５：プロジェクトマネジメントの契約管理（内容変更・新設）

コース概要と変更点： Ver1.2 版のプロジェクトマネジメントの契約管理は、サービス契



約に関する知識、お客様との契約管理、取引先との契約管理について学習する。当

コースでは、旧 JEIDA 編、または、JISA 編のモデル契約を参考に、契約書とし

て必要な条項、その理由、また、どのような責務や制約があるのか、などを学習す

る。

・ＰＭ６：チーム編成と動機付け（追加・新設）

コース概要：当コースでは、プロジェクト責任者として、プロジェクトメンバのやる気を

喚起し、どうしたら効果的なチーム編成ができるかなどについて学びます。

・ハーマンモデル・行動科学論

・マグレガーの X 理論・Y 理論

・マズローの欲求５段階説・交流分析

・ストロークなど

・ＰＭ８：プロジェクト事例演習（計画編）（追加・新設）

コース概要：当コースでは、「プロジェクトマネジメント技法演習」の後続コースとして

の位置づけであり、また、「プロジェクトマネジメント実践」の各編で習得した計

画プロセス群の理論を活用して、事例研究のプロジェクトにおける「プロジェクト

マネジメント計画書」を策定することにより、プロジェクト計画力の補強と実践的

な能力へステップアップすることを目的としたチームによるワークショップ形式の

学習です。

・ＰＭ９：プロジェクト事例演習（実行・コントロール編）（追加・新設）

コース概要：当コースでは、「プロジェクトマネジメント技法演習」と「プロジェクト事

例演習（計画編）」の後続コースとしての位置づけであり、また、「プロジェクト

マネジメント実践」の各編で習得した計画や実行、監視コントロール・プロセス群

の理論および思考問題解決法で習得した手法などを活用して、事例研究のプロジェク

トにおける問題提起とその改善策や是正策を策定することにより、プロジェクトの

運営管理力の補強と実践的な能力へステップアップすることを目的としたチームによ

るワークショップ形式の学習です。

・ＰＭ１０：ファイナンシャルマネジメント（内容変更・新設）

コース概要と変更点：当コースは、Ver1.2 版におけるファイナンシャルマネジメント・

コースとアウトソーシングプロジェクトマネジメントのための会計・経営管理概説

コースの会計関連内容とを統合したものである。

当コースは、プロジェクト責任者としてプロジェクトを予算／資源／コストの観点

で成功裡に実施するために必要となる財務上の責任、各種財務用語、財務データの

導き方、PV（現在価値）／BCR（コストベネフィット比率）、投資対効果、など

について学び、プロジェクトの選択/評価、プロジェクトマネジメントへ財務データ

を活用するための知識と技法を習得する。



また、時価主義会計、連結会計、キャッシュフロー会計、年金会計、税効果会計、

研究開発費とソフトウェア会計などの企業会計と、キャッシュフロー経営、グルー

プ経営、ＢＰＲ( Business Process Reengineering )、ＡＢＣ／ＡＢＭ( Activity

Based Costing / Activity Based Management )、人材マネジメント、グループ

経営管理システムなどの経営管理手法についても学習する。

３）ビジネス/インダストリ

・Ｂ１：業務知識（追加・新設）

コース概要：当コースでは、各業界で代表的な業務とその用語を学習する。

・Ｂ３：マーケティング（追加・新設）

コース概要：当コースでは、新製品の開発を企画するために必要になるマーケティング戦

略や戦術の基本知識として、市場分析、製品分析、競合分析、事業成功要因分析な

どを学習する。

・Ｂ５：経営管理（経営と情報）（追加・新設）

コース概要：当コースでは、Ver1.2 版のアウトソーシングプロジェクトマネジントのた

めの会計・経営管理概説の経営管理関連内容を独立させ、経営戦略、ビジネスモデ

ル実現のための IT、情報システム、情報セキュリティなどについて学習し、経営戦

略をいかに情報戦略に結びつけ、この情報戦略を実現するために何をどうすべきか

について理解する。

・Ｂ６：関連法規とコンプライアンス（追加・新設）

コース概要：当コースでは、プロジェクトの責任者として、プロジェクトを計画・運営管

理する上で知っているべき法律などを学び、また、裁判事例を通じて法律遵守の重

要さを再認識する。

下記に例を示す。（順不同）

・労働基準法・人材派遣法・男女雇用機会均等法

・民法・商法・著作権法・PL 法

・下請代金支払遅延防止法・個人情報保護法

・VDT 作業のための労働衛生上の指針

・電気通信事業法・有線電気通信法

・不正競争防止法・ＳＯＸ法

・IT 関連の主な裁判事例と判決など



４）パーソナル

・Ｐ４：メンタリング手法（追加・新設）

コース概要：当コースでは、 PM 育成の指導者（メンター）にコミュニケーション・スキ

ルやパーソナルスキルの再確認をするために、次の内容を学習すると共に自社のメ

ンタリング制度の啓発、メンターとして効果を上げているメンターの体験報告など

の横展開を図る学習コースである。

・基本的なコミュニケーションや動機付けのコミュニケーション

・コーチング技術・カウンセリング技術

・ファシリテーション技術など



資料３－３研修ロードマップ改善提案内容と理由 № 改善提案提案の理由1 研修方法ワークショップは必要ないのではないか。基礎であり、座学のみでも良いと思われるため。2 受講対象者『受講対象者』に「運用管理経験者」があるが必

要ないのではないか。「システム設計」と「運用管理」では関連が薄いと思われるため。

3 受講前提『受講前提』も運用管理の経験は前提としなくてもよいのではないか

同上。

4 研修方法講義を含めてはどうか。システム構築に関しては講義なしのワークショップはやりにくいと思われるため。（講義をせず、プログラミング演習は難しいと思われる）

5 『コース概要』このコースで「進捗管理手法」は学習対象としなくてよいのでは無いか。

システム構築活動に専念し、管理的な学習はマネジメントを扱う他コースに任せて良いと思われ

6 『関連する知識』このコースで「タイムマネジメント」は学習対象としなくてよいのでは無いか。

システム構築活動に専念し、管理的な学習はマネジメントを扱う他コースに任せて良いと思われる。タイムマネジメントを対象とするなら、品質マネジメントも必要と思われるし、際限が無くなる7 研修方法ワークショップではなく、講義とすべきではない基礎であり、座学のみでも良いと思われるため。

8 本コースにはこの９つの知識エリアは不要ではないか。

ＰＭＢＯＫの９つの知識エリアのうち、統合Ｍ、タイムＭ、リスクＭの３つのみ関連することになっており、理解がしにくいため。それらを含めるなら、コストＭ、組織Ｍ、スコープＭの関連も考えられ、際限がなくなる。管理的な学習はマネジメントを扱う他コースに任せて良いと思われる。9 「業務分析」の記述を追記すべきではないか。運用しながら次の業務改善につなげることがあると思われるため。

10 研修方法講義が必要ではないか。講義が必要であると思われるため。11 『研修修了後のスキ

ル修得目標』「プロジェクトマネジメントに関する基礎的な知識を駆使し、プロジェクトメンバとして、プロジェクトを実行できる。」は、たとえば、「統一されたＰＭ用語で意思疎通ができる」といった修得目標とすべきではないか。

基礎コースでは、左記の表現は、実態に合わないと思われるため。

12 5-『プロジェクトマネジメント実践：　プロジェクトマネジメント実践』コースについて

『コース概要』『「プロジェクトマネジメント実践」コース群』という表現が出てくるが、どこかで定義すべきではないか。

『××群』という表現はどこにも定義されておらず、紛らわしいため。

13 研修方法ワークショップ（ツール実習）が必要ではないか。ツールのコースであり、演習が必要と思われる14 『コース概要』 №16と同じ №16と同じ15 『関連する知識』ＰＭＢＯＫの９つの知識エリアのうち、統合Ｍ、の

みを対象としているが、９つの全てのエリアを対象とすべきではないか。

全エリアに関するツールがありうると思われるため。

16 7-『システム要件定義技法』コースについて

『関連する知識』「要件定義」が「デザイン」に含められているが、これは「業務分析」に含めたほうが良いのではないか。

「要件定義」は、「業務分析」の一貫として行われると思われるため。

17 『研修修了後のスキル修得目標』

「コンサルティングに関する基礎的な知識を活用し、プロジェクトリーダとして、効果的なコンサルティングプロセスを実践することができる。」となっているが、プロジェクトマネージャにがどのようにコンサルプロセスを活用できるようになるかを記述（例示）すべきではないか。

コンサルティングプロセスとプロジェクトマネジメントとの関連が記載されておらず、コンサルティングプロセスの必要性が理解しにくいと思われるため。

18 ＰＭＢＯＫの知識エリアを関連とする必要はないのでは無いか。あるとした場合も、（現行の）統合マネジメントのみではなく、他のプロセスも含まれるのでは無いか。

コンサルティングプロセスとＰＭプロセスの関係は薄いと思われるため。あえて関係をつけるとしても、スコープ（コンサル範囲の特定）、コスト（追加コンサル時に追加費用）、スケジュール（ヒアリングスケジュール、報告スケジュール）なども関係すると思われる。19 「知的資産管理(ＫｎｏｗｌｅｄｇｅＭａｎａｇｅｍｅｎｔ)活

用」の記述は必要無いのではないか。コンサルティングと「知的資産管理」の関係が理解しにくいため。

20 9-『プロジェクトマネジメントのリーダーシップ』コースについて

『コース概要』「中規模以上または複雑なプロジェクト」という条件は不要ではないか。

左記条件以外のプロジェクトでも、リーダシップは必要であると思われるため。

21 10-『プロジェクトマネジメントのコミュニケーション』コースについ


左記条件以外のプロジェクトでも、コミュニケーションは必要であると思われるため。

22 11-『プロジェクトマネジメントのネゴシエーション』コースについ


左記条件以外のプロジェクトでも、ネゴシエーションは必要であると思われるため。

23 研修方法講義が必要ではないか。講義が必要と思われるため。24 『研修修了後のスキ

ル修得目標』「複雑度の高いプロジェクト環境において、プロジェクト責任者として、プロジェクト全工程におけるプロジェクトマネジメントを実践し、プロジェクトを成功裡に完了できる。」とあるが、「成功裡に完了できる」は必要無いのではないか。

研修を受けただけでは「成功裡に完了できる」ことを期待できないと思われるため。

25 『関連する知識』「－ソフトウェアエンジニアリング」が、「ＩＴソリューション設計・開発管理」のカテゴリに含められているが、「ソフトウェアエンジニアリング」のカテゴリに含めるべきではないか。

「ソフトウェアエンジニアリング」のカテゴリが自然であると思われるため。


「プロジェクト全工程における品質マネジメントを実施し、プロジェクト責任者として、プロジェクトを成功裡に完了できる。」とあるが、「成功裡に完了できる」は必要無いのではないか。

№28と同じ。

27 『関連する知識』「ソフトウェアエンジニアリング」のカテゴリ（Ｓ字カーブ、ゴンベルツ曲線等）含めるべきでは無い

品質マネジメントのためには、統計等のソフト工学を理解すべきと思われるため。

13-『品質マネジメント』コースについて

12-『コンプレックスプロジェクトマネジメント』コースについて

対象

8-『コンサルティングメソドロジ』コースについて

『関連する知識』

2-『システム構築』コースについて

3-『システム運用／保守』コースについて

4-『プロジェクトマネジメント基礎』コースについて


1-『システム設計の基礎』コースについて

6-『プロジェクトマネジメント実践：　プロジェクトマネジメントツールとプロセス』コースについて



№ 改善提案提案の理由28 研修方法講義が必要ではないか。講義が必要と思われるため。29 『研修修了後のスキ

ル修得目標』「プロジェクト全工程における様々なリスクマネジメントを実践し、プロジェクト責任者として、プロジェクトを成功裡に完了できる。」とあるが、「成功裡に完了できる」は必要無いのではないか。

№28と同じ。

30 15-『ファイナンシャルマネジメント』コースについて

『研修修了後のスキル修得目標』

「プロジェクトにおける適切なファイナンシャルマネジメントを実施し、プロジェクト責任者として、プロジェクトを成功裡に実施できる。」とあるが、「成功裡に完了できる」は必要無いのではない

№28と同じ。


「プロジェクトにおける適切な調達マネジメントを実施し、プロジェクト責任者として、プロジェクトを成功裡に実施できる。」とあるが、「成功裡に完了できる」は必要無いのではないか。

№28と同じ。

32 『関連する知識』９つの知識エリアのうち、調達Ｍの他に、スコープＭ、コストＭ、組織Ｍ、コミュニケーションＭが記載してあるが、必要ないのではないか。仮に入れるなら、９つ全てとすべきではないか。

元々、調達マネジメントコースであり、スコープＭ、コストＭ、組織Ｍ、コミュニケーションＭを入れるのであれば、外注先の進捗管理（タイムＭ）、外注先の倒産・撤退（リスクＭ）なども必要と思われる。33 研修方法講義が必要ではないか。講義が必要と思われるため。


「プロジェクトにおける適切な契約マネジメントを実施し、プロジェクト責任者として、プロジェクトを成功裡に実施できる。」とあるが、「成功裡に完了できる」は必要無いのではないか。

№28と同じ。

35 研修方法ｅラーニングがあっても良いのではないか。他の動向コースはすべてｅラーニングがある36 『研修修了後のスキ

ル修得目標』「最新技術に関する知識を活用し、プロジェクトメンバとして、開発、運用、保守などのプロジェクトを実施することができる。」とあるが、「プロジェクトメンバとして」は必要ないのではないか。

各レベル（メンバ、マネージャ）でこのコースを受講することが想定され、あえて「メンバとして」は必要無いと思われるため。

37 「－最新技術動向」、「－最新ＩＴ市場動向」が、「ＩＴソリューション設計・開発管理」のカテゴリに含められているが、「テクノロジ」のカテゴリではな

「テクノロジ」のカテゴリが自然であると思われるため。

38 「ソフトウェアエンジニアリング」のカテゴリで何らかの記述が必要ではないか。

技術動向なので、ソフト工学としてのなんらかの記述も必要だと思われる。

39 19-『プロジェクトマネジメント最新動向』コースについて

研修方法講義が必要ではないか。講義が必要と思われるため。

40 20-『最新ビジネス動向』コースについて

『関連する知識』「－最新ＩＴ市場動向」が、「ＩＴソリューション設計・開発管理」のカテゴリに含められているが、「テクノロジ」のカテゴリではないか。もしくは新たなカテゴリが必要ではないか。

「テクノロジ」のカテゴリがより自然であると思われるため。

41 「－インダストリ知識」が、「ＩＴソリューション設計・開発管理」のカテゴリに含められているが、「テクノロジ」のカテゴリではないか。もしくは新たなカテゴリが必要ではないか。

「テクノロジ」のカテゴリがより自然であると思われるため。

42 「ソフトウェアエンジニアリング」のカテゴリで何か記述する必要はないか。

動向なので、ソフト工学に関するなんらかの記述も必要だと思われるため。

43 22-『コミュニティ活動』コースについて

－指摘なし

44 23-『プロジェクトマネジメント方法論（システム開発／アプリケーション開発／システムインテグレーション）』コースについて

『関連する知識』「－ソフトウェアエンジニアリング」等が、「ＩＴソリューション設計・開発管理」のカテゴリに含められているが、「ソフトウェアエンジニアリング」のカテゴリで良いのではないか。

「ソフトウェアエンジニアリング」のカテゴリが自然であると思われるため。

45 24-『DOA構造化手法』コースについて

－指摘なし

46 研修方法上級講座ではなく、基礎講座ではないか。他の方法論が基礎講座であるため。47 『関連する知識』調達Ｍしか含まれていないが、９つの知識エリア

すべてを含むのでは無いか。そもそも、運用管理方法論は、ＰＭＢＯＫではなく、ＩＴＩＬのカテゴリを適用すべきではないか。

アウトソーシングには開発＋運用という面があるため、より広範な知識エリアを含むと思われるため。また、運用管理では、ITILのサービスサポート、サービスデリバリを参照することが適当と思

48 26-『アウトソーシングビジネスのプロジェクトマネジメント：　アウトソーシングプロジェクトマネジメント概説』コースについて

研修方法ｅラーニングでも良いのではないか。概説であるため、ｅラーニングでも良いのではないか。（28-『アウトソーシングビジネスのプロジェクトマネジメント：　アウトソーシングプロジェクトマネジメントのための会計・経営管理概説』コース」はｅラーニングを含いいでいる）

49 27-『アウトソーシングビジネスのプロジェクトマネジメント：　アウトソーシングプロジェクトマネジメント実践』コースについて

『コース概要』「ＰＭＰ」の記述は必要がないのでは無いか。アウトソーシング以外の職種にはＰＭＰの記述が無く、ここに記載されている必要性が感じられないため。

50 28-『アウトソーシングビジネスのプロジェクトマネジメント：　アウトソーシングプロジェクトマネジメントのための会計・経営管理概説』コースについて

－指摘なし



14-『リスクマネジメント』コースについて

16-『調達マネジメント』コースについて

25-『アウトソーシングプロジェクトマネジメントのためのシステム運用管理方法論』コースについて

17-『プロジェクトマネジメントの契約管理』コースについて

18-『最新技術動向』コースについて

21-『インダストリアプリケーション動向』コースについて

対象



№ 改善提案提案の理由51 29-『プロジェクトマネ

ジメント方法論（ネットワークサービス）』コースについて

『関連する知識』９つの知識エリアを対象とすべきではないか。プロジェクトマネジメント方法論のコースであるため、９つの知識エリアは含める必要があると思われるため。

52 研修方法ｅラーニングではなく、講義とすべきではないか。事例コースをｅラーニングのみでは教訓の深い部分を伝えることが難しいと思われるため。

53 『関連する知識』９つの知識エリアを対象とすべきではないか。 №55と同じ54 31-『ｅビジネスソ

リューション開発方法論』コースについて

－指摘なし

55 32-『ｅビジネスソリューションプロジェクトマネジメント』コース

－指摘なし

56 『コース概要』「ＩＰＤ」は「製品開発方法論」とすべきではないか。

「ＩＰＤ」は特定企業の方法論名でもあるため、一般名称とすべきと思われるため。

57 『関連する知識』９つの知識エリアを対象とすべきではないか。 №55と同じ58 34-『ソフトウェア開発

プロジェクトマネジメント』コースについて

『コース概要』「ＩＰＤ」は「製品開発方法論」とすべきではないか。

「ＩＰＤ」は特定企業の方法論名でもあるため、一般名称とすべきと思われるため。

30-『ネットワークプロジェクトマネジメント事例』コースについて

33-『プロジェクトマネジメント方法論（ソフトウェア製品開発方法

対象

itスキル標準&研修 改善報告書 -...

Documents

itスキル標準&研修改善報告書 -...