Comments
Description
Transcript
IT スキル標準 改善提案 報告書 - IPA 独立行政法人 情報処理推進機構
ＩＴスキル標準 プロフェッショナルコミュニティ プロジェクトマネジメント委員会 ２００４年度版 IT スキル標準 改善提案 報告書 1 Ⓒ2005 IPA All Rights Reserved 本報告書の位置づけ IT スキル標準は経済産業省より２００２年１２月に公開されました。スキル標準は策定段階から IT 市場 の急激な進展や刻々と変化する IT サービスビジネスのあり方・価値に対して、継続的な見直しを前提に内容 や活用の充実を進めていくことが必要だとされていました。そこで、IT スキル標準の運営機関として、独立 行政法人 情報処理推進機構（当時の情報処理振興事業協会）内に「IT スキル標準センター」が設置（２０ ０３年７月）され、IT スキル標準の普及啓蒙活動とともに、以下の改訂および活用促進に関る諸活動を行っ てきました。 ①研修ロードマップ（６職種）の策定[バージョン１．１]（２００３年７月） ②IT スキル標準の改訂[バージョン１．１]（２００３年７月） ③研修ロードマップ全職種の策定及び改訂[バージョン１．２]（２００４年８月） さらなる改善のために、IT スキル標準センターでは上述の改訂検討に加えて実際に IT スキル標準を活用し ている方の声を探るための市場調査活動や、実ビジネスのハイレベルプロフェッショナルによって IT スキル 標準のレビューやプロフェッショナルのあり方を示すプロフェッショナルコミュニティの創設を併行して 行ってきました。 本報告書は IPA が主催したプロフェッショナルコミュニティの各委員会（IT アーキテクト、プロジェクトマ ネジメント、アプリケーションスペシャリスト）のうち、プロジェクトマネジメント委員会が２００４年度 の活動としてまとめた IT スキル標準の改善提案を報告書として公表するものです。 今後、IPA において本報告書と他の委員会の報告書に基づき改善仕様と計画を検討し、利用者の意見などを 取りまとめながら作業を進め、IT スキル標準ｖｅｒ.２.０をはじめとした今後の公表につなげていく予定で す。 独立行政法人 情報処理推進機構（IPA） IT スキル標準センター 2 Ⓒ2005 IPA All Rights Reserved CONTENTS はじめに・・・・３ １．改善提案における前提条件・・・・５ １．１ プロジェクトマネジメントの役割と範囲・・・・５ １．２ プロジェクトマネジメントの能力と定義・・・・６ １．３ プロジェクトマネジメントレベルの概念・・・・６ ２．改善検討と提言 ２．１ ＰＭ職種の説明と専門分野・・・・７ １）職種の説明について・・・・８ ２）システム開発/アプリケーション開発/システムインテグレーションについて・・・・９ ３）e-ビジネスソリューションについて・・・・１０ ４）ソフトウェア開発について・・・・１１ ５）アウトソーシングについて・・・・１２ ６）ネットワークサービスについて・・・・１３ ２．２ ＩＴ投資の局面と活動領域、職種の説明・・・・１５ ２．３ 達成度指標・・・・１８ ２．４ スキル領域・・・・２６ ２．５ スキル領域・熟達度・知識項目・・・・３０ ２．６ 改善提案サマリー・・・・３６ ３．今後の課題と提言・・・・３７ 3 Ⓒ2005 IPA All Rights Reserved はじめに 独立行政法人情報処理推進機構（IPA）ＩＴスキル標準センターでは、第一線で活躍しているハイレ ベルなスキルを持つ者同士が、社内や組織の論理にとらわれず建設的に情報交換や議論が行えるような 場において、ＩＴスキル標準の改訂、人材育成のあり方等、次世代ＩＴサービス・ビジネスを担う後進 人材のスキルアップに貢献するための諸活動を行う目的で「ＩＴスキル標準プロフェショナルコミュニ ティ」を創設しました。 そして２００４年７月にＩＴアーキテクト委員会に続きプロジェクトマネジャーのプロフェショナ ルコミュニティである「プロジェクトマネジメント委員会（略称：ＰＭ委員会」が活動を開始しました。 さらに、ＰＭ委員会の下に２種類の WG グループ （WG1：IT スキル標準＆研修改善ＷＧ 、WG2： ＰＭ育成ガイド作成ＷＧ）を立ち上げ、下記に示されるメンバーにて下記目的及び内容を討議するため 会議を開催し、「ＩＴスキル標準と研修ロードマップ」のプロジェクトマネジメント部分を対象に検討 及び確認しました。 ・WG 名称 ：IT スキル標準＆研修改善点ＷＧ（WG1） ・ＷＧ１グループメンバー ：平成１６年６月現在におけるメンバー及び所属 （○はリーダ）は次の通りです。 ○ 井沢 澄雄 日本電気株式会社 小川 健司 日本アイ・ビー・エム株式会社 向後 忠明 ＮＴＴコミュニケーションズ株式会社 澤田 友宏 株式会社日立製作所 土出 克夫 富士通株式会社 丹羽 武志 株式会社インテック 橋爪 宗信 株式会社ＮＴＴデータ 4 Ⓒ2005 IPA All Rights Reserved // 本報告書の目的 // 本報告書はＰＭ委員会の 2004 年度活動の活動を通して、下記に示す目的にてＩＴスキル標準と研 修ロードマップのプロジェクトマネジメント部分を第一線で活躍しているプロジェクトマネジメン ト・プロフェショナルの視点からその改善点を提言したものです。 なお、研修ロードマップについては今年度の結果を踏まえて次年度にてその詳細検討を行うことにし ました。 ＜今回の改善提言対象＞ プロジェクトマネジメントの職種の概要及び専門分野 ＩＴ投資の局面と活動領域 プロジェクトマネジメントのスキル領域 プロジェクトマネジメントの達成度指標 プロジェクトマネジメントのスキル領域・熟達度・知識項目 // 作業内容 // 下記内容の検討及び確認作業を上記の各提言対象に対して行いました。 プロジェクトマネジメントの専門分野のチェックとレベル確認 職種の説明の確認 達成度指標の各指標の精査（責任制・複雑性・サイズ・タスク特性） スキル領域の確認（スキル項目の過不足チェック） スキル熟達度・知識項目の確認 プロジェクトマネジメント対象範囲の拡大に関する提案 5 Ⓒ2005 IPA All Rights Reserved １． 改善提案における前提条件 ＩＴスキル標準と研修ロードマップの改善点を提言するにあたり、その前提条件としてプロジェクト マネジメントの下記に関する項目について議論し、メンバーの合意及びＰＭ委員会での了承を得ながら、 その改善提案を行ないました。 １．１ プロジェクトマネジメントの役割と範囲 １）役割と範囲 プロジェクトマネジメントの役割と範囲が企業によって異なっています。この部分を整理しなが ら、明確化することにしました。 ■役割 プロジェクトマネジメントは下記に示す目標の管理であり、そのため下記に示す役割範囲内にお ける目標と仕事の内容の整理が必要との考えから検討を行いました。 ■範囲 プロジェクトマネジメントの役割範囲については委託側と受託側の関係があり、その業務内容も異な ってきます。本報告書は図 1.1−１に示す受託側から見たマネジメントについて検討を行いました。 （ただし、将来はその上流側であるエンタープライズマネジメント（委託側）の部分も含めて検討し ます） ２）対象機能の整理 プロジェクトマネジメントの役割と範囲の中でＰＭに求められる必要なマネジメントスキル及 び特性要件を以下の前提での整理 ・ 目標マネジメント（スコープ、スケジュール、品質、コスト、統合マネジメント） ・ 支援マネジメント（組織マネジメント、コミュニケーションマネジメント、リスクマネジメン ト、調達マネジメント） 委託側事業化検討 フェーズ 委託側技術検討・ 設計・調達フェーズ 受託側提案フェーズ プロジェクト 最終フェーズ プロジェクト実行フェーズ ェ プ ロ ジ ︵ 労 働 力 投 入 度 契 約 ク ト 計 画 検 収 ︶ 関 連 要 員 ・委託側プロジェクト チーム編成 ・情報化企画 （委託側） ・事業化妥当性検討 ・委託側設計 ・技術要件と 委託側PJ計画 ・調達要求書作成 （RFP） ：受託側負荷曲線 ：委託側負荷曲線 ・受託側プレゼン テーション ・引合書の発行 ・提案活動（含む 情報化企画： 受託側） ・評価（委託側） ・技術 ・契約交渉 ・契約内容の確認 ・基本設計 （スコープ/契約条件 ・調達 /技術要件の確認） ・詳細設計 ・プロジェクト作業 ・製造/プログラム の明確化（WBS） /各種試験 ・スケジュール/予算 ・搬送 の確定 ・据付／導入. ・プロジェクトチーム ・各種試験/検査 の編成とスタッフの 配置 ・性能試験 ・検収 ・試運転 図1.1−１ 委託者側/受託者側のプロジェクトマネジメント範囲 6 Ⓒ2005 IPA All Rights Reserved １．２ プロジェクトマネジメント能力の定義 プロジェクトマネジャーの能力を定義するにはその背景にある組織を考慮する必要があります。しか し、結果としてＩＴスキル標準がダブルスタンダード化するので組織の規模は考慮せず、あくまでも個 人の能力を議論の対象としました。例えば大規模なＩＴ企業であれば、ＰＭＯ（プロジェクトマネジメ ントオフィス）といった、プロジェクトマネジャーを組織的に支援する仕組みや潤沢な要員リソースを 用いて、長期にわたる大規模プロジェクトを着実に遂行することが前提となるかも知れません。また、 中小規模のＩＴ企業ではひとりのプロジェクトマネジャーが短期間で多くのプロジェクトを効率よく 推進する能力が前提となるかも知れません。それらの前提毎にＩＴスキル標準を見直す意見も出ました が、複数の標準を維持することは好ましくないと判断しました。 そのため、プロジェクトの規模や複雑性等のパラメータを複合させて、企業規模や対象プロジェクト の性質に関係なくプロジェクトマネジャーの能力定義ができるような仕組みを考慮しながら検討しま した。 １．３ プロジェクトマネジメントレベルの概念 プロジェクトマネジメントのレベル概念は以下の通りですが、レベル 7 のあり方も含めそれぞれの 違いが明確になるように検討を進めました。 ・レベル１、２：レベル設定を行わない（設置しない） ・レベル３ ：エントリーレベル（プロジェクトメンバ：ＰＭ見習いとし、この時点ではプロジ ェクトサイズについての考慮は不要とします。そして、ＰＭは実質的にレベル ４からという前提としました） ・レベル４ ：ミドルレベル ・レベル５、６：ハイレベル ・レベル７ ：スーパーハイレベル なお、プロジェクトサイズがレベル決定の主な決め手となっているのでそれ以外の要素についての定 義付けも検討しました。 また、ＰＭ委員会の２００５年度以降の活動結果により,さらに改善の提案を行い、ＩＴスキル標準 及び研修ロードマップへ反映していく予定です。 7 Ⓒ2005 IPA All Rights Reserved ２． 改善検討と提案 本章はすでに発表されているＩＴスキル標準と研修ロードマップのＰＭ部分における記述について具体 的改善点を WG 内にて討論を行い、その具体的改善点を示したものです。 なお、2.1 節はＰＭ職種の説明と専門分野について改善提案を行い、2.2 節以降では、2.1 節にての改 善提案項目を前提として検討を行いました。 ２．１ ＰＭ職種の説明と専門分野 現在のＩＴスキル標準の専門分野の分類方法および名称に関しては、違和感を覚えるとの意見が多い ため、本 WG では、まずプロジェクトマネジャーに求められる能力という観点から、専門分野の分類 という概念に関し、妥当性の議論を行いました。 基本的にプロジェクトマネジャーに求められる能力は、プロジェクトのタイプに係らず共通要素が多 いため、専門分野を設けるのは妥当ではないとの議論がありました。しかし、ＩＴ企業のサービス形態 として、システムインテグレーション、ネットワークサービス、アウトソーシング、ソフトウェア開発 という分類が存在することからも、専門分野をプロジェクトマネジャーの実務形態としての「ジョブカ テゴリー」という概念でとらえるならば、妥当であるという結論に至りました。また、専門分野という 枠組みは、育成面の観点からも有効に機能することが本 WG で合意を得ました。 例えばアウトソーシングのプロジェクトマネジャーの達成度指標はレベル 6 以上となっていますが、 これは当該分野を担当できるプロジェクトマネジャーが、それまでに他の専門分野を経験することを前 提としたキャリアパスを期待されているからです。 以上の基盤となる議論を踏まえ、現状のプロジェクトマネジャー職種の説明および、専門分野として 規定されている５項目を討議テーマとし、各論ベースで改善点の討議を行いました。 下記に、テーマ毎の討議内容および改善提案を記載します。 １）職種の説明について ２）システム開発／アプリケーション開発／システムインテグレーションについて ３）ｅビジネスソリューションについて ４）ソフトウェア開発について ５）アウトソーシングについて ６）ネットワークサービスについて 8 Ⓒ2005 IPA All Rights Reserved １）職種の説明について 【討議内容】 職種の説明に関し、ＩＴスキル標準では「プロジェクトの立ち上げ、計画策定、遂行及び進捗管理を 実施し、契約上の納入物にも責任を持つ」と定義されています。しかしながらプロジェクトマネジメン トは、顧客だけではなく、社内ユーザも対象とするケースも多いので、契約上という記述を削除すべき ではないか、またプロジェクトマネジメントの重要な責務である品質、コスト、納期の遵守に関してさ らに強調すべきではないか、という点について討議を行いました。 【改善提案】 職種の説明に関する定義として、下記の通り提案いたします。 ●現状 プロジェクトの立ち上げ、計画策定、遂行および管理を実施し、契約上の納入物にも責任を持つ。 ●改善案 プロジェクトの提案、立ち上げ、計画策定、遂行及び進捗管理を実施し、計画された納入物・サー ビス及びその品質（Ｑ）・コスト（Ｃ）・納期（Ｄ）に責任を持つ。 9 Ⓒ2005 IPA All Rights Reserved ２）システム開発／アプリケーション開発／システムインテグレーションについて 【討議内容】 システム開発／アプリケーション開発／システムインテグレーションの表記を統一することができ ないか？ これらの用語は、利用者により、使われ方が統一されていないため、現在は併記されています。定義 を厳密に行うのであれば、個々を独立させることも可能ですが、むしろ統一的な定義を行うことにより、 ひとつにまとめた方が利用者にとってわかりやすいと思われます。当該専門分野の場合、システムエン ジニアリングとソフトウェアエンジニアリングを包含するものとして捉え、「システム開発」と呼称す ることが適当であると思われます。内容については、システムインテグレーションの観点から、対象職 務フェーズを提案から保守までとすること、インフラ構築を含めること、ならびにｅビジネスソリュー ションの観点から、採用技術に関する事項を盛り込み、包括的な記述としてはどうか等々の意見があり ました。 【改善提案】 システム開発／アプリケーション開発／システムインテグレーションおよび e ビジネスソリューシ ョンは、「システム開発」に統合されるものとしました。また、コンピュータ・ネットワーク環境及び 付帯設備の構築を含むものとします。名称を「システム開発」と改称し、定義の改訂を下記の通り提案 いたします。 ● 現状 ＩＴソリューションの設計、開発に係るプロジェクトマネジメントを行う。 ● 改善案 ＩＴシステムの提案・開発・保守に係わるプロジェクトマネジメントを行う（ＩＴシステムとして要 求される機能を実現するためのソフトウェアを開発し、コンピュータ・ネットワーク環境及び付帯設 備を構築する。インターネットテクノロジを使用したものも含む）。 10 Ⓒ2005 IPA All Rights Reserved ３）ｅビジネスソリューションについて 【討議内容】 ｅビジネスソリューションは、固有技術のひとつである Web 技術を駆使したシステム開発との意味 合いが強いので、専門分野「システム開発」に含めてもよいのではないか？ ｅビジネス の定義は、インターネットテクノロジやＷｅｂ技術を活用したビジネス形態であるが、 すでに一般的なシステム開発においても、同技術が活用されることが多くなってきています。また、ビ ジネスソリューションの観点から、通常コンサルタントが実施する事業検討フェーズを除くならば、シ ステム開発と大差はありません。よって、ｅビジネスと一般的なビジネスシステム開発を分ける必要性 はないと思われます。 【改善提案】 ｅビジネスソリューションは、専門分野「システム開発」に含まれるものと定義し、専門分野から削 除することを提案いたします。ただし、「システム開発」の定義にインターネットテクノロジの活用を 含む趣旨を盛り込むものとします。（システム開発／アプリケーション開発／システムインテグレーシ ョンの項参照） 11 Ⓒ2005 IPA All Rights Reserved ４）ソフトウェア開発について 【討議内容】 ① ソフトウェア開発という名称は、システム開発との相違がわかりづらいのではないか？ システム開発は、ある特定のユーザ向けの開発であるのに対し、ソフトウェア開発は不特定多数の ユーザを対象としたものを意図しています。例えば、市販製品を作るのが、ソフトウェア開発であり、 その市販製品を用いて特定顧客向けのカスタマイズなどを行うのがシステム開発であると理解して よいと考えます。したがって、現在の名称を「ソフトウェア製品開発」と改訂すれば、この相違が比 較的明確になるものと思われます。 ② ソフトウェア開発に組込系ソフトを考慮すべきではないか？ 当該専門分野のソフトウェアはそれ自体が最終製品をイメージしており、何らかの製品に組み込ま れる「組込系ソフト」とは異なります。組込系は別委員会で検討されているため、本 WG の検討対 象外とします。 ③ ソフトウェア開発にレベル７がないが、検討すべきではないか？ 近年のソフトウェア製品開発は大規模、複雑かつ短納期なものであることから、システム開発と並 び、レベル７が定義されてしかるべきです。 【改善提案】 ソフトウェア開発は、ソフトウェア製品の開発を意味するので、それを識別しやすくするために、名 称を「ソフトウェア製品開発」と改称し、定義の改訂を下記の通り提案いたします。また、当該専門分 野におけるプロジェクトマネジャーの高レベル能力の必要性を勘案し、新たにレベル７を新設すること を提案します。 ● 現状 ソフトウェア製品の設計、開発、改良及び保守に係るプロジェクトマネジメントを行う。 ● 改善案 不特定多数のユーザを対象としたソフトウェア製品の企画・設計、開発、改良及び保守に係るプロジ ェクトマネジメントを行う。 12 Ⓒ2005 IPA All Rights Reserved ５）アウトソーシングについて 【討議内容】 ① アウトソーシングという名称は、広範な印象を与えるため、プロジェクトマネジャーの職務範囲が 特定しづらいのではないか？ ＩＴスキル標準におけるアウトソーシングは、単に運用のアウトソーシングや、開発のアウトソー シングではなく、長期にわたる事業検討から運用フェーズまでのライフサイクルに対応する広範囲な ものを意図しています。そのため、そのような名称と、定義に改訂することが好ましいと思われます。 ② アウトソーシングに運用フェーズを含めると、ＩＴＩＬの領域を加味する必要があるのではない か？ 現状のＩＴスキル標準には、ＩＴＩＬは加味されていませんが、アウトソーシングのプロジェクト マネジャーはＩＴＩＬ等を理解した上で、マネジメントすべきです。ただし、ＩＴスキル標準にＩＴ ＩＬや他のメソドロジーを安易に取り込むと、それらの改訂時の対応が煩雑となり、好ましいとはい えません。 ③ アウトソーシングでは、育成面を考慮し、下位のレベルから定義してはどうか？ アウトソーシングのプロジェクトマネジャーは、顧客の経営戦略を受け、ＩＴシステムの企画から 運用までを含むフルアウトソーシングを職務範囲としているため、要求されるレベルは必然的に高い ものです。このため、プロジェクトマネジャーの他の専門分野でキャリアを積んだ後、当該専門分野 へ移行するキャリアパスを提示すれば、現在のレベル付けは妥当であると言えます。 【改善提案】 プロジェクトマネジャーの専門分野としてのアウトソーシングは 10 年スパンで考えると、運用を含 めたＩＴシステムのフルアウトソーシングを意味するものとなります。よって専門分野名称を「ＩＴア ウトソーシング」と改称し、定義の改訂を下記の通り提案いたします。 ● 現状 情報システム環境の改善を通じた情報システムの効果的な運用に係るプロジェクトマネジメントを 行う。管理対象として、アプリケーション開発、保守、システム運用、サポートデスク運用、業務運用 などが含まれる。 ● 改善案 顧客の経営戦略を受けて、外部組織としてＩＴシステムの企画・構築・保守、システム運用、サポー トデスク運用、業務運用に係るプロジェクトマネジメントを行う。 13 Ⓒ2005 IPA All Rights Reserved ６）ネットワークサービスについて 【討議内容】 ① ネットワークサービスにもレベル７の定義が必要なのではないか？ 過去の電気通信技術であれば、レベル７に相当する技術者もいましたが、現在は既存の設備を用い てシステムを構築することがほとんどであるため、現状通りのレベル設定でよいと思われます。しか し、検証が必要であるという結論になりました。 そこで、ネットワークの専門家に参画いただき、再度議論を行った結果、レベル７追加の必要性の 議論を行いました。 ② システム開発では、ネットワーク環境や付帯設備の構築等も含まれるので、当該分野を削除し、シ ステム開発に統合したほうがよいのではないか？ システム開発にはソフトウェアの開発が伴うので、ネットワークサービスをシステム開発に含める と、やや違和感があります。例えば、ネットワーク系の企業のプロジェクトマネジャーはシステム開 発を行っているわけではなく、あくまでもネットワークの構築を専門としているため、当該職種を独 立した専門分野として定義していることは妥当です。ただし、システムインテグレーションでは当該 作業も含まれるため、「システム開発」の定義にネットワーク環境や付帯設備の構築等を加えればよ いと考えられます。 ③ カスタマーサービスのファシリティマネジメントとの相違が明確でない ネットワークサービスが存在する一方で、インフラ構築サービスがあれば、ファシリティマネジメ ントとの相違も一層明確になるものと思われます。しかし、今回は「システム開発」「ＩＴアウトソ ーシング」「ネットワークサービス」「ソフトウェア製品開発」の４専門分野で検討を進めることと し、インフラ構築については、専門分野として含めません。 【改善提案】 ネットワークサービスについても新技術を用いた構築など、難易度の高いサービスも存在します。ま た、管理する要員数がピーク時で 500 人以上、もしくは導入作業拠点数が 1000 拠点以上といった 大規模プロジェクトや国際的なプロジェクトにおいてはマネジメントの難易度も高く、レベル７の定義 も必要だと考えられます。 14 Ⓒ2005 IPA All Rights Reserved 以上１）から６）までの改善提言をまとめると図 2.1−１のようになります。 プロジェクトマネジメントの職種の概要 職種 プロジェクトマネジメント 職種の説明 ネ ッ ー ク サ シ ン グ ビ ス ソ フ ト ウ プロジェクトの提案、立ち上げ、計画策定、遂行及び進捗 管理を実施し、計画された納入物・サービス及びその品質 （Q)・コスト（C）・納期（D）に責任を持つ ア 製 品 開 発 −戦略的情報化企画 ・情報化企画（ITアウトソーシング／ソフトウェア製品開 発の場合） ・プロジェクト計画の策定 −開発 ・プロジェクトの管理／統制 −運用、保守 ・プロジェクトの管理／統制 ェ ト ワ ー I T ア ウ ト ソ ー 専門分野 シ ス テ ム 開 発 当該職種は、以下の専門分野に区分される レベル７ レベル６ レベル５ レベル４ レベル３ レベル２ ●システム開発 ＩＴシステムの提案・開発・保守に係るプロジェクトマネ ジメントを行う。（ＩＴシステムとして要求される機能を 実現するためのソフトウェアを開発し、コンピュータネッ トワーク環境及び付帯施設を構築する。インターネットテ クノロジを使用したものを含む。） ●ＩＴアウトソーシング 顧客の経営戦略を受けて、外部組織としてＩＴシステムの 企画・構築・保守・システム運用、サポートデスク運用、 業務運用に係るプロジェクトマネジメントを行う。 ●ネットワークサービス データ(LAN/WAN)、画像、映像等の通信環境の設計、導 入及び管理に係るプロジェクトマネジメントを行う ●ソフトウェア開発 不特定多数のユーザを対象としたソフトウェア製品の企 画・設計、開発、改良及び保守に係るプロジェクトマネジ メントを行う レベル１ 図2.1−１ 職種の概要と専門分野の改善案まとめ 15 Ⓒ2005 IPA All Rights Reserved ２．２ ＩＴ投資の局面と活動領域、職種の説明 １）討議内容 プロジェクトマネジメントにおけるＩＴスキル標準で定義された各局面とその活動領域に関して 議論をしました。 ■戦略的情報化企画局面での活動について 「表 2.２-1ＩＴ投資の局面と活動領域の関係」を時間軸で捉えるとプロジェクトマネジメントの 重要な活動は、ソリューション設計から始まります。従って特に課題整理/分析局面に関して下記の 議論をしました。 ●システム開発、ネットワークサービスのこの局面での活動の有無 ●ＩＴアウトソーシング、ソフトウェア製品開発では、プロジェクトの計画を策定するのでは無く 製品開発やフルアウトソーシングの活動の延長線上で製品や戦略の情報化企画をする局面では 無いか ■プロジェクト基本計画について プロジェクト基本計画は、プロジェクト計画の一部であり表現として不正確ではないかとの問題提 起が有り検討しました。またプロジェクト計画は、全てのプロジェクトで管理統制に入る前に策定が 必要です。そのタイミングについて課題整理/分析局面ではなくソリューション設計での活動とすべ きでないかを議論しました。 さらに計画の変更/策定は、戦略的情報化企画、開発、運用のいずれの局面でも実施されるべき活 動ですので全ての局面に記述することも検討しました。しかしながらプロジェクトマネジメントの主 たる活動を考慮すると、計画の策定は戦略的情報化企画局面での重要な活動です。従ってこの局面だ けにおける記述の妥当性について議論をしました。また計画の策定は、プロジェクトマネジメントの 主要な活動にも関わらず「プロジェクト基本計画の作成」がプロジェクトマネジメントの従たる活動 になっているのはおかしいとの指摘があり、主たる活動に変更することを決定しました。 ■戦略的情報化企画の名称について ＩＴアウトソーシング以外では、当局面の「戦略的」という言葉は不適切であり、プロジェクトマ ネジメントの観点から変更すべきとの問題提起がありました。しかしながら、この名称はＩＴアーキ テクトやコンサルタントの職務範疇として適切かつ必要であるのでそのまま残す事で合意しました。 さらに、これらの職種がプロジェクトマネジメントの前段階としてプロジェクトに参加していれば 問題は無いのですが、現実的には参加していないケースが多々あります。その場合は、プロジェクト マネジメントが当活動を兼務することになり、「戦略的に情報化を考える必要がある」との意味合い で変更する必要はないと結論しました。 ■経営戦略策定局面について ＩＴアウトソーシングやソフトウェア製品開発では企画以前の経営戦略策定の段階からプロジェ クトマネジメントが入っている必要が有ります。しかし、この局面でのプロジェクトマネジメント共 通の活動として意見を集約するには今後さらに検討を重ねる必要があります。 16 Ⓒ2005 IPA All Rights Reserved 表２．２−１ ＩＴ投資の局面と活動領域の関係 ＩＴ投資の局面と活動領域の関係 ＩＴ投資の局面 と活動領域 経営戦略策定 戦略的情報化企画 経営目標／ ビジョン策定 ビジネス 戦略策定 課題 整理／分析 （ビジネス/ＩＴ） セールス 目標/ビジョン の確認 ビジネス 戦略の確認 ビジネス課題 ｿﾘｭｰｼｮﾝ提案 コンサルタント 目標/ビジョン の提言 ビジネス戦略 策定の助言 ソリューション 策定のための 助言 ソリューション の設計 ＩＴ アーキテクト ソリューション の枠組み策定 プロジェクト マネジメント プロジェクト基 本計画の策定 職種 IT スペシャリスト アプリケーション スペシャリスト ソリューション 設計 (構造/ﾊﾟﾀｰﾝ) 開発 運用・保守 コンポネント 設計 (ｼｽﾃﾑ/業務） ソリューション 構築 （開発/実装） ソリューション アーキテク チャーの設計 コンポネントの 設計 ソリューション の構築 プロジェクトの 管理/統制 プロジェクトの 管理/統制 システム構築 計画の策定 ｱﾌﾟﾘｹｰｼｮﾝ 開発計画の策 定 カスタマ サービス オペレーション ソリューション 運用 （ｼｽﾃﾑ/業務） ソリューション 保守 （ｼｽﾃﾑ/業務） プロジェクトの 管理/統制 プロジェクトの 管理/統制 プロジェクトの 管理/統制 システム・コン ポネントの 設計 システムの 導入構築 システムの 運用 システムの 保守 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の設計 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の開発 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の運用 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の保守 導入計画 の策定 ハードウェア ソフトウェア の導入 ハードウェア ソフトウェア の保守 ハードウェア ソフトウェア の保守 運用計画/ システムの 運用と管理 システムの 運用と管理 運用管理 の策定 主たる活動局面 従たる活動局面 17 Ⓒ2005 IPA All Rights Reserved ２）改善提言 ① 現在のＩＴスキル標準で示されている活動領域の「プロジェクト基本計画の策定」は、プロジェク トマネジメントの観点からは不正確です。そのために下記の通り変更することを提言します。 ■ 「プロジェクト基本計画の策定」を削除する ■ 管理統制に必要な計画として定義し「プロジェクト計画の策定」と変更する ■ プロジェクトマネジメントの主たる活動局面とする ■ タイミングはソリューション設計の局面に位置づける ② 課題整理/分析局面での活動は、 専門分野を 2 種類に大別し下記の通り変更することを提言します。 ■ システム開発及びネットワークサービス 特に活動は定義しない ■ ＩＴアウトソーシング及びでソフトウェア製品開発 ・課題の整理、分析を継続的に実施しますので、この局面での活動を「情報化企画」とする ・プロジェクトマネジメントの従たる活動局面とする （参照：「表２．２−２ ＩＴ投資の局面と活動領域の関係の新提案」） 表２．２−２ ＩＴ投資の局面と活動領域の関係の新提言 ＩＴ投資の局面と活動領域の関係 ＩＴ投資の局面 と活動領域 経営戦略策定 戦略的情報化企画 経営目標／ ビジョン策定 ビジネス 戦略策定 課題 整理／分析 （ビジネス/ＩＴ） セールス 目標/ビジョン の確認 ビジネス 戦略の確認 ビジネス課題 ｿﾘｭｰｼｮﾝ提案 コンサルタント 目標/ビジョン の提言 ビジネス戦略 策定の助言 ソリューション 策定のための 助言 ソリューション の設計 ソリューション の枠組み策定 プロジェクト なし 基 本計画の策定 職種 ＩＴ アーキテクト プロジェクト マネジメント IT スペシャリスト システム開発/ ネットワークサービス 情報化企画 ＩＴアウトソーシング/ ソフトウェア製品開発 アプリケーション スペシャリスト ソリューション 設計 (構造/ﾊﾟﾀｰﾝ) 開発 運用・保守 コンポネント 設計 (ｼｽﾃﾑ/業務） ソリューション 構築 （開発/実装） ソリューション アーキテク チャーの設計 コンポネントの 設計 ソリューション の構築 プロジェクトの プロジェクト 管理/統制 計画の策定 プロジェクトの 管理/統制 システム構築 計画の策定 ｱﾌﾟﾘｹｰｼｮﾝ 開発計画の策 定 カスタマ サービス オペレーション ソリューション 運用 （ｼｽﾃﾑ/業務） ソリューション 保守 （ｼｽﾃﾑ/業務） プロジェクトの 管理/統制 プロジェクトの 管理/統制 プロジェクトの 管理/統制 システム・コン ポネントの 設計 システムの 導入構築 システムの 運用 システムの 保守 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の設計 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の開発 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の運用 ｱﾌﾟﾘｹｰｼｮﾝ ｺﾝﾎﾟﾈﾝﾄ の保守 導入計画 の策定 ハードウェア ソフトウェア の導入 ハードウェア ソフトウェア の保守 ハードウェア ソフトウェア の保守 運用計画/ システムの 運用と管理 システムの 運用と管理 運用管理 の策定 主たる活動局面 従たる活動局面 18 Ⓒ2005 IPA All Rights Reserved ２．３ 達成度指標 「達成度指標」はスキルを客観的に観察する指標として、各専門分野のレベルごとに要求される経験 と実績を定義したものです。具体的には各「実務能力」レベルのプロフェッショナルとして認められる ために必要かつ当該レベルのプロジェクトを成功裏に完了した経験と実績の要件として定義していま す。指標の切り口には「タスク特性」・「サイズ」・「複雑性」・「責任性」の４つを取上げています。 当 WG ではこれらの達成度指標について、まず４つの切り口を議論し、次いで専門分野別のレベル ごとにその内容を検討し、現実との乖離があるもの、感覚的に合わないものについて改善案を提示する ことにしました。 主な検討・討議内容、及び個々の改善提案について、以下に記述します。 １）討議内容 1-1）プロジェクト難易度と達成度指標の関係 プロジェクトマネジメントを成功裏に完遂するには プロジェクトの難易度が大きく作用する との共通認識から、難易度に影響を与える要因を挙げ、ＩＴスキル標準の達成度指標との比較検討 を行ないました。表-2.３.1 にその対応を示します。 表-2.３.1 プロジェクトの難易度に影響を与える要因と達成度指標 難易度に影響を与える要因 ＩＴスキル標準の達成度指標 ① プロジェクトを取り巻く環境条件 ① 責任性 ② プロジェクトそのものに含まれる各種条件 ② プロジェクトの複雑性 ③ 企業のポリシー、トップの指示、 ③ プロジェクトのサイズ ビジネスの目的 ④ ④ タスク特性 企業の対応能力 上記の要因をさらに分解し、達成度指標との関係性を検討しましたが、結果はＩＴスキル標準に 示される達成度指標がこれらの一般的に考えられる難易度の要因とは大きな齟齬がないことが検 証されました。 ただし、達成度指標の中で「サイズ」については「プロジェクト規模」としてはどうかとの意見 がありましたので、ご検討ください。 1-2）達成度指標についての議論 4 つの達成度指標については精査が必要との提起がされました。たとえば、複雑性については、 ・プロジェクト経験は「回数」ではなく、「経験年数」を考慮する必要はないか？ ・プロジェクト体制に関して、「顧客特性」を考慮する必要はないか？ ・プロジェクト立上げ時点での「要求仕様明確度」や「要求仕様明確可能性」を評価指標にでき ないか？ といった問題提起でした。 19 Ⓒ2005 IPA All Rights Reserved これらの提起を含め、各専門分野・レベルごとに達成度指標の各項目を精査し、改善提案として盛 り込むことにしました。 以下、個別に議論・検討した項目について、議論のポイントと改善提案を示します。 なお、提案した達成度指標項目については、最後にまとめて一覧化しましたので、ご確認ください。 1-3）各専門分野・レベルごとの議論 ①「システム開発」における議論 ● 責任性 ・レベル４では「プロジェクトリーダ」、またレベル３では「プロジェクトメンバ」と記述さ れていますが、これでは 本当のＰＭはレベル５から と解釈できる、との指摘がありまし た。 ・レベル４の責任性においては「プロジェクトリーダ」という名称を削除し、レベル５以上と 同じく、「プロジェクトの責任者」とすることを議論しました。 ● 複雑性 ・回数の規定に対して、 過去３年間などの期限を設けてはどうか との意見が出ましたが、 プロジェクトによっては長期のもの、短期のものがあり、一律に規定するのは無理がある との多数意見がありました。 ・レベル５の複雑性の中で「システム要件の複雑性」と表記されていますが、意味をより明確 にするために「システム構築要件の複雑性」と修正することを議論しました。 ● サイズ ・レベル３の責任性において、「プロジェクトメンバとしての経験・実績を有する」と規定する なら、サイズにおける「ピーク時の要員数１０人未満のプロジェクト」という規定は意味がな い、との指摘がありました。サイズについてはこの規定を削除することを議論しました。 ・ 複数のプロジェクトの合計金額でレベルを評価してもよいのでは との意見がだされました が、 １千万円規模のプロジェクトを複数こなしても、１０億円の仕事ができるとはいえない との意見がだされました。 ● タスク特性 ・レベル６における「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル５に おける「顧客の部長相当以上への満足感の提供」はお客さまによって対応者が異なるため（中 堅・中小企業では社長の場合もある）、レベル５，６において共通に「顧客への満足感の提供」 と表現することを議論しました。 ②「ＩＴアウトソーシング」における議論 ・名称を「ＩＴアウトソーシング」に変更されています。 ・４つの指標について精査しましたが、現行で特に問題となる指摘はありませんでした。 20 Ⓒ2005 IPA All Rights Reserved ③「ネットワークサービス」における議論 ■ 責任性 ・レベル４で「プロジェクトリーダ」と記述されていますが、システム開発同様、レベル４にお いても「プロジェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを 議論しました。 ■複雑性 ・ネットワークサービスにはグローバル案件も数多く存在するため、レベル 5 以上の複雑性 の用件として「国際的なプロジェクト」の追加を議論しました。 ■サイズ ・拠点数でサイズを定義することに対して、曖昧さをさけるため 全国規模・地域（領域）で 分ける、あるいはメーカ間の調整有無、プロトコルの難易度などを考慮した定義が望ましい のではないか との意見がありましたが、検討メンバーにネットワークに強いものがいない ため結論は保留となりました。別途、ネットワークに詳しい方を招聘し、レベル７の必要性 や他の指標を含めて検討することにしました。 これを受けて、専門家に参加いただき、再度検討会を開きました。ネットワークサービスにお いては、お客様の拠点特性により、小規模拠点を 1 万拠点以上実施するケース（例：コンビニエ ンスストアなど）や、高信頼性を考慮した大中規模拠点を数百拠点実施するケース（例：金融業 など）など、拠点数のみでサイズを定義することは困難であると考えられます。よって、拠点数 もしくは要員数のいずれかの要素をみたすことによりサイズの定義を行うことが望ましいのでは ないかとの意見がありました。 また、拠点の定義についても議論がなされ、無線系、有線系、そしてその内容について議論が なされました。基本的にはそれぞれの拠点は無線であれば基地局、有線であれば例えばコンビニ のようにある程度規模の導入作業を伴う拠点ではないかとの議論がされました。 契約金額についてはネットワークサービスではハードウェアの金額に左右されるため、サイズ の決定要素とはしないことを議論しました。 ④「ｅビジネスソリューション」における議論 ・ 本分野は「システム開発」に含まれるとのＷＧでの合意から検討の対象外となりました。 ⑤「ソフトウェア製品開発」における議論 ・ 現行の「ソフトウェア開発」は「システム開発」と紛らわしいため、「ソフトウェア製品 開発」と名称変更となりました。 ・ レベル７の追加 ソフトウェア製品開発においてもレベル７が必要との多数意見により追加を提案します。 レベル７における達成度指標は、システム開発にほぼ準じた内容と思われますが細部について は、後述の一覧表をご確認ください。 21 Ⓒ2005 IPA All Rights Reserved ● 責任性 ・ レベル４で「プロジェクトリーダ」と記述されていますが、レベル４においても「プロジ ェクトの責任者」とし、「プロジェクトリーダ」という名称を削除することを提案します。 ● サイズ ・ レベル３はプロジェクトメンバとしての経験・実績であることから、「ピーク時の要員数 １０人未満のプロジェクト」というサイズは無意味であり、削除することを提案します。 ● タスク特性 ・ レベル６において「顧客の事業部長相当または部長相当以上への満足感の提供」、レベル ５において「顧客の部長相当以上への満足感の提供」と記されていますが、お客さまによっ て対応者が異なるため（中堅・中小企業では社長の場合もある）、レベル５，６共通に「顧 客への満足感の提供」と表現することを提案します。 ２）改善提案 上述した専門分野別、レベルごとの達成度指標について、改善提案した項目を一覧表の形で示 します。 専門分野 システム開発 達成度指標 レベル６ ■タスク特性 プロジェクト終了時、顧客への満足度、プロジェクトメンバ への達成感の提供 レベル５ ■複雑性 システム構築要件の複雑性（・・・） ■タスク特性 プロジェクト終了時、顧客への満足感、プロジェクトメンバ への達成感の提供 レベル４ ■責任性 下記複雑性、・・・において、プロジェクト責任者 として、プロジェクトを実施した経験と実績を有 する（「プロジェクトリーダ」の表記を削除） レベル３ ■サイズ −以下の規模に相当するプロジェクト成功の経験と 実績を有する □ピーク時の要員数 10 人未満のプロジェクト [削除、サイズは不問] 専門分野 ＩＴアウト 達成度指標 特になし ソーシング 22 Ⓒ2005 IPA All Rights Reserved 専門分野 達成度指標 ネットワーク レベル７ サービス （追加） ■責任性 下記複雑性、サイズに相当するプロジェクト全体に対する責 任を持ち、プロジェクト責任者として、プロジェクトを遂行 した経験と実績を有する ■複雑性 以下の幾つかに相当する複雑度のプロジェクトに関する複 数回のプロジェクトマネジメントの経験と実績を有する ・システム要件の複雑性(パフォーマンス要件、セキュリ ティ要件、技術要件、稼働運用要件) ・ネットワーク要件の複雑性（パフォーマンス要件、セキュ リティ要件、技術的要件、稼動運用要件） ・複雑なアプリケーション要件 ・プロジェクト体制（サブコントラクト、複雑な協業関係、 複数の関係部門） ・複雑な契約条件、完了条件 ・国際的なプロジェクト ■サイズ 以下のいずれかの規模に相当するプロジェクト成功の経 験と実績を有する ・管理する要員数がピーク時 500 人以上、または導入作業 拠点数が 1000 拠点以上 ■タスク特性 以下のタスク特性を踏まえたプロジェクト遂行及びプロ フェッショナル活動の経験と実績を有する ・上記サイズ、複雑性のプロジェクトに対するプロジェクト 対象の熟知、最適解の選択、プロジェクト終了までの責任 ・上記サイズ、複雑性のプロジェクトに対する期待される資 源と期間内でのプロジェクト遂行とプロジェクト管理 ・プロジェクト終了時、顧客の経営層への満足感、プロジェ クトメンバへの達成感の提供 ・後進育成、学会等外部団体のコミュニティ活動、論文執筆、 講演活動、ビジネス特許取得等のプロフェッショナルとし ての顕著な貢献と実績 23 Ⓒ2005 IPA All Rights Reserved 専門分野 ネットワーク 達成度指標 レベル６ ■複雑性 サービス ■国際的なプロジェクト （続き） ■サイズ 以下のいずれかの規模に相当するプロジェクト成功の経験 と実績を有する ・管理する要員数がピーク時 50 人以上 500 人未満、また は導入作業拠点数が 300 拠点以上 レベル５ ■複雑性 ・国際的なプロジェクト ■サイズ 以下のいずれかの規模に相当するプロジェクト成功の経 験と実績を有する ・管理する要員数がピーク時 10 人以上 50 人未満、または 導入作業拠点数が 100 拠点以上 300 拠点未満 レベル４ ■サイズ 以下のいずれかの規模に相当するプロジェクト成功の経験 と実績を有する ・管理する要員数がピーク時 10 人未満、または導入作業拠 点数が 100 拠点未満 専門分野 ｅビジネス 達成度指標 (専門分野から削除、システム開発に吸収) ソリューション 24 Ⓒ2005 IPA All Rights Reserved 専門分野 達成度指標 ソフトウェア レベル７ （システム開発のレベル７に準拠） 製品開発 （追加） ■責任性 下記複雑性、サイズに相当するプロジェクト全体に対する責 任を持ち、プロジェクト責任者として、プロジェクトを遂行 した経験と実績を有する。 ■複雑性 以下の幾つかに相当する複雑度のプロジェクトに関する複 数回のプロジェクトマネジメントの経験と実績を有する ・システム要件の複雑性(パフォーマンス要件、セキュリテ ィ要件、技術要件、稼働運用要件、技術の成熟度、障害対 策、運用、保守を考慮した設計、開発サイクル) ・システムデザインの複雑性（マルチプラットフォーム、高 可用性） ・プロジェクト体制（サブコントラクト、複雑な協業関係、 複数の関係部門） ・複雑な契約条件、完了条件 ■サイズ 以下の規模に相当するプロジェクト成功の経験と実績を有 する ・管理する要員数がピーク時 500 人以上 ■タスク特性 以下のタスク特性を踏まえたプロジェクト遂行及びプロフ ェッショナル活動の経験と実績を有する ・上記サイズ、複雑性のプロジェクトに対するプロジェク ト対象の熟知、最適解の選択、プロジェクト終了までの 責任 ・上記サイズ、複雑性のプロジェクトに対する期待される 資源と期間内でのプロジェクト遂行とプロジェクト管理 ・プロジェクト終了時、顧客の経営層への満足感、プロジ ェクトメンバへの達成感の提供 ・後進育成、学会等外部団体のコミュニティ活動、論文執 筆、講演活動、ビジネス特許取得等のプロフェッショナ ルとしての顕著な貢献と実績 レベル６ ■タスク特性 プロジェクト終了時、顧客への満足感、プロジェクトメンバ への達成感の提供 25 Ⓒ2005 IPA All Rights Reserved 専門分野 ソフトウェア 達成度指標 レベル５ ■タスク特性 製品開発 プロジェクト終了時、顧客への満足感、プロジェ （続き） クトメンバへの達成感の提供 レベル４ ■責任性 下記複雑性、・・・において、プロジェクト責任者 として、プロジェクトを実施した経験と実績を有す る（「プロジェクトリーダ」の表記を削除） レベル３ ■サイズ −以下の規模に相当するプロジェクト成功の経験と 実績を有する □ピーク時の要員数 10 人未満のプロジェクト [削除、サイズは不問] 26 Ⓒ2005 IPA All Rights Reserved ２．４ スキル領域 「スキル領域」は、技術者に求められる実務能力をスキル項目として定義したもので、職種共通スキ ル項目とシステム開発・ＩＴアウトソーシング等４つの専門分野固有スキル項目から構成されています。 当ＷＧでは、主に職種共通スキル項目についてその内容を検討し改善案を提言しました。 以下、主な検討・討議内容、及び個々の改善提案について記述します。 １）討議内容 職種共通スキルは下記に示すように４つの領域に分解されます。 ■プロジェクトマネジメントのスキル ■パーソナルスキル ■ビジネスマネジメントに関する知識／スキル ■職種共通的なテクノロジーおよびメソドロジーに関するスキル ① プロジェクトマネジメントのスキル ＰＭＢＯＫ2000に示されるプロジェクトマネジメントに関する以下に示す９つの知識エリ アに対応して、現行ＩＴスキル標準は定義されています。 統合マネジメント プロジェクト計画策定、実施、変更管理 スコープマネジメント プロジェクト立ち上げ、スコープ計画と定義、納入物検収、スコープ管理 タイムマネジメント 作業定義、順序設定、所要時間見積、スケジュール作成と管理 コストマネジメント 資源計画、コスト積算、予算設定、コスト管理 品質マネジメント 品質計画、品質保証、品質管理 人的資源マネジメント プロジェクト組織計画、要員調達、チーム育成 コミュニケーションマネジメント コミュニケーション計画、情報配布、進捗報告、プロジェクト完了手続 リスクマネジメント リスク特定と定量化、対応策策定、リスク管理 調達マネジメント 調達計画、協力会社選択､引合計画、引合、発注先選定、契約管理、 契約完了処理 27 Ⓒ2005 IPA All Rights Reserved 「契約マネジメント」の追加の必要性について討議を行いました。その結果、各委員からは以下 に示すような多くの意見がありました。 ・ ＰＭＢＯＫでは、契約以降がＰＭの役割として定義されているが、ＰＭにとっては、顧客（プロジ ェクトの発注者）との契約も重要な意味を持つものであり、ＰＭも契約について充分な知識を持っ ておかなくてはなりません。 ・ プロジェクトの立場には、調達する側（発注側）と調達される側（受注側）という２つの立場があ ります。ＰＭＢＯＫでは、 調達するための契約 については述べられていますが、それでは、契 約としては一方的です。 ・ ＩＴスキル標準では、「調達マネジメント」の中の「契約交渉」という項目で、契約について触れ ています。 ・ ＰＭには、契約を締結した後に、その契約を精査し、理解する能力が必要だという意味で、契約は プロジェクトの範囲内であると言えます。 ・ 受託側の立場で契約について議論すると、プロジェクトの範囲外を扱うことになってしまうので、 契約については、別のアウトプットで扱った方が良いです。 ・ ＰＭにとって、契約に関する知識は必要不可欠なものであるが、ＰＭガイドライン等の別のアウト プットで、その重要性を強調してはどうかと言う意見がありました。 ・ 「調達」と「契約」は、「調達・契約マネジメント」として一つにまとめ、その中で契約の重要性 を強調してはどうかと言う意見もありました。 ・ 契約は、プロジェクトのマネジメントすべてに関わるものであると言えるので、「スコープマネジ メント」等の各マネジメント項目の中で、契約を強調することもできるし、それらをまとめて「契 約マネジメント」として取り出してはどうかという意見もありました。 ＰＭBOK では、委託側としての契約マネジメントを調達マネジメントとして定義をしています。 しかし、受託側のプロジェクトに焦点を当てて考えてみると、発注を受ける立場としての契約マネ ジメントも存在しているので、結果として、契約についての記述が、欠落しているとの意見の一致 を見ました。 ②パーソナルマネジメントについてのスキル ＰＭの活動様式としての人間力（ヒューマンスキル）及び倫理について討議を行ないました。 ③ビジネスマネジメントに関する知識/スキル 知的資産管理（Knowledge Management）活用 知的資産の管理と活用 をＩＴスキル標準で代表例として提示されています。これについて十分性を検討しました。 その結果、追加で例示すべき内容がないことが検証されました。 28 Ⓒ2005 IPA All Rights Reserved ２）改善提案 ①プロジェクトマネジメントのスキル 「統合マネジメント」の部分に、 ＰＭにとって、契約に関する知識は重要である ということを記述 しておくことを提言します。 ②パーソナルスキル 職種共通スキル項目として、現在のＩＴスキル標準では、下記の通りプロジェクト関係者とのプ ロジェクト目標の共有について視点を当てられています。 リーダーシップ プロジェクト目標設定､チーム形成、アクティビティ展開と推進、動機付け コミュニケーション 意思疎通、プレゼンテーション、各種文書の作成、会議運営 ネゴシエーション スコープ、コスト、スケジュール、契約条文と条件、及びリソースに関する交渉等 上記の項目に加え、その他の重要な要素として、下記項目の追加を提言します。 分析力 行動力 倫理（社会的責任） ③職種共通的なテクノロジー及びメソロジーに関するスキル 「業務分析」については、「専門家の意見に基づき、お客様の経営課題を理解し、適切な業務／ 技術要件を提案・判断できる」との趣旨を盛り込みました。 「コンサルティングの実施」に関しては、コンサルティング技術の適用を行うとすべきではない でしょうか（プロジェクトマネジャーとしては、コンサルの手法があるということお客様やプロジ ェクト内のメンバーに伝え、実際に手法を実施する場合はコンサル等専門家を使って業務を行うの が責務である）。その表現の見直しをしました。達成度指標レベルについては、スキルレベルで展 開することにした。具体的修正案を表2.4−1に示します。 表 2.4−1 職種共通スキル項目 業務分析 プロジェクトマネジメントのスキル熟達度修正案 スキル熟達度 業界/技術動向の先見的見地に基づき複雑高度な業務要件/ 技術要件分析を行うことができる。 →専門家の意見に基づき、お客様の経営課題を理解し、最適 な業務／技術要件を提案・判断できる。 29 Ⓒ2005 IPA All Rights Reserved 最適なコンサルティングメソドロジの選択と適用、プロセス の定義と実践、成果物の定義と作成、コンサルティング技術 の適用を行い、プロジェクトを成功裡に実施することができ コンサルティングメ る。 →プロジェクト特性に応じたコンサルメソドロジーの選択 ソドロジの活用 と適用、プロセスの定義と実践、成果物の定義と作成、コン サルティング技術の適用を行い、プロジェクトを成功裡に実 施することができる。 コンサルティングメソドロジ、モデル、コンサルティング技 コンサルティングの 術を活用し、プロジェクトを成功裡に実施することができ る。 実施 →(削除) ④スキルレベル 各スキル領域におけるレベル（熟達度レベル）についての測定が、立場（各レベルにおけるプロジェクトサ イズ）を除いて具体性が十分ではありません。そのため、スキル熟達度のレベルごとにせず、一本化し、各 レベルは新たにスキルレベルを設定し、熟達度レベルに対応させることでＷＧでは提案しました。 30 Ⓒ2005 IPA All Rights Reserved ２．５ スキル領域・熟達度・知識項目 「スキル領域」は技術者に求められる実務能力をスキル項目として定義したもので、職種ごとに共通の スキル項目と専門分野固有のスキル項目から構成されます。それぞれのスキル項目に対して、どのレベル にあるかを表現するのが「スキル熟達度」です。スキル熟達度はすべて「∼することができる」という基 準によってスキルの有無を問うもので、当該レベルに達していることの裏づけとなる要素として捉えられ ます。つまり、ある職種のレベル５に該当する技術者ならば、「このスキル項目についてこれだけのこと を行えるはずだ」というガイドラインを示すのが、スキル熟達度の意義です。 また各スキル項目にはそのスキルを身につけるための前提となる知識を「知識項目」として明記し、ス キルに対応した知識習得の指針として活用できるようになっています。 １）討議内容 「スキル熟達度」は、利用する側の視点で見ると、自らの「スキル熟達度」が、社会一般的なレベル からみると、どのレベルにあり、どのスキル項目のどの知識項目が不足しているかを把握し、スキルア ップのために活用するという捉え方ができます。育成者の視点からも、対象となる人材に対して、同様 の捉え方ができることが活用の視点から重要になります。 これに対し、現状の「スキル熟達度」は、以下のような点がわかりにくいとの指摘がありました。 レベルの違いをサイズ＋責任で表現しているが、達成度指標のレベルとの違いがわかりにくい。 知識項目とスキル熟達度のレベルとの関係が示されておらず、どの知識項目をどのようなレベルに すれば、スキル熟達度が向上するのかがわかりくい。 レベル区分が達成度指標と同様に 7 区分設定されているが、スキルのレベルを 7 つに区分できる だろうか。 「スキル熟達度」は、複数の知識項目に対応するスキルのレベルの組み合わせで表現されるはずだ が、そのレベルや組み合わせは、組織のニーズや個人の経験の違いによって個人ごとに異なると考 えられる。キャリアアップの視点からは、その違いに配慮できるような構成になっていることが望 ましい。 知識項目には、職種共通のものやいくつかの職種で共通に活用できるものもある。それらの知識項 目については、同様の視点で評価できる形が好ましい。 以上の指摘に対応するために、以下のような改善を提案しました。 31 Ⓒ2005 IPA All Rights Reserved ２）改善提案 「スキル熟達度」のレベルをあらわす「スキルレベル」の概念を導入し、2 段階で表現すること で、知識項目ごとのレベルと「スキル熟達度」のレベルの関係を論理的に表現できる考え方を提言 します。 「スキル熟達度」のレベルを「熟達度レベル」、「スキルレベル」の 2 段階で考えます。 「熟達度レベル」とは、対応するレベルのプロジェクトを実践するスキルを保有していることを 表す指標で、スキルに対応します。たとえば熟達度レベル４であれば、達成度指標レベル 4 の規 模や複雑性などを有するプロジェクトのプロジェクトマネジメントを行える可能性があるという ことです。「達成度指標レベル」は、実際に行って成功裏に終了した実績を示しますが、「熟達 度レベル」は行える可能性を示していると考えられます。 「スキルレベル」とは、スキル熟達度を構成する要素（スキル項目と呼ぶ。またこのスキル項目 を大括りにしたものを、スキル領域と呼ぶ）ごとにレベル 0 からレベル 5 までを設定します。た だし、そのレベル表現は、個々のスキル項目ごとに設定するのではなく、すべての項目に共通の 表現を用いることとします（表 2.5.２参照）。 「スキル項目」ごとの「熟達度レベル」は「スキルレベル」を用いて、その総合スキルレベルに よって決定します（表 2.5.３参照）。ただし、この評価点はあくまで一般的な例示と考えてくだ さい。組織によっては、海外でのプロジェクトで世情に不安があり、リスクがとても大きいため にリスクマネジメントに対するスキルが重視される場合もあります。そのような場合は、例示し ているスキルレベルを変える必要があります。 トータルの「熟達度レベル」は、「スキル領域」ごとの総合スキルレベルを総合判定したものと して、表現されます。 「熟達度レベル」によって、要求される「スキル領域」の割合は異なっていると考えられます。 たとえば、熟達レベル３では、テクノロジー及びメソドロジースキルのような現場でのスキルが より重視され、ビジネスマネジメントスキルはまだあまり重視されないといえます(図 2.5―１参 照)。レベルごとの「スキル領域」の割合については、組織によって異なる場合があります。 また、個人ごとに強いスキルが異なる場合があります。たとえば、表 2.5―１のような 3 名の方 の熟達度レベルをどのように考えるかを見てみましょう。Ａ氏は、すべてのカテゴリーのスキル レベルが、熟達度レベル評価で 4 を上回っています。したがって、熟達度レベル 4 であると考え られます。Ｂ氏は、パーソナルスキルとビジネスマネジメント･スキルの総合スキルレベルによる 熟達度レベル評価が 4 に達していません。しかし、テクノロジーメソドロジースキル、インダス トリー・適用業務スキルでは４を超えています。このような場合は、まずプロジェクトマネジメ ントスキルを優先してこの部分が４を超えていますので、熟達度レベル 4 の可能性があると考え ます。ただし、パーソナルスキルとビジネスマネジメントスキルに不安があることを認識する必 要があります。プロジェクトマネジャーの上司やメンターが適切な支援をする必要があります。 一方、Ｃ氏の場合は、プロジェクトマネジメントスキルの総合スキルレベルが、熟達度レベル 4 に達成していませんので、熟達度レベルは 3 と考えます。 32 Ⓒ2005 IPA All Rights Reserved 表 2.5―１ 熟達度 レベル 熟達度レベルの例示 各カテゴリーにおける総合スキルレベル（）内が対応する熟達度レベル プロジェク パーソナル･ テクノロジ インダスト トマネジメ マネジメン ーメソドロ リー･適用 ント ト ジー 業務 ビジネスマ ネジメント Ａ氏 ４ ３．５（４） ３．０（４） ３．０（４） ３．０（４） ２．０（４） Ｂ氏 ４ ３．５（４） ２．０（３） ３．０（４） ３．０（４） １．２（３） Ｃ氏 ３ ２．５（３） ３．０（４） ３．０（４） ３．０（４） ２．０（４） ｢熟達度レベル｣を上記のように表現する形になりますので、「スキル熟達度」はレベル表現をせ ず、スキル項目の説明を記述することになります(表 2.5.４参照)。 ここで示しました｢スキルレベル｣、｢熟達度レベル｣は、レベルアップのための仕組みとして活用 することを前提にしています。論理的にレベル判定ができるからと、この仕組みを個人の評価に 用いることは必ずしもよい結果を生まないと考えています。ＩＴ技術者の育成に活用されること を切に望みます。 表 2.5―2 スキルレベル スキル スキルレベルの レベル 定義 具体的な説明例 0 知らない 1 知っている 研修などで勉強をして、知識として知っている 2 説明できる 知識中心だが、人に説明できる。指導を受けなが ら実践したこともある 3 活用できる、実 そのスキル・カテゴリーについて、殆ど経験してお 践できる り、自力で実践できる 4 実践し、指導で そのスキル・カテゴリーについて、深い理解と数多 きる くの経験を持ち、後進の指導ができる 5 リードやコンサ そのスキル・カテゴリーについて、業界の第一人者 ルテーションが で、業界をリードできる できる − 33 Ⓒ2005 IPA All Rights Reserved 表2.5―3(1) プロジェクトマネジメント･カテゴリーにおけるスキルレベル(例) 熟達度レベル 知 識 分 野 プ ロ セ ス 分 野 1 2 3 4 統合マネジメント 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 総合ポイント 総合スキル・レベル 5 6 7 すべての項目で スキルレベル３ 以上で、スキル レベル４が４個 以上、スキルレ ベル５が２個以 上のこと すべての項目で スキルレベル４ 以上で、スキル レベル５が７個 以上のこと すべての項目で スキルレベル４ 以上で、スキル レベル５が７個 以上のこと すべての項目が すべての項目が スキルレベル５ スキルレベル５ のこと のこと 表2.5―3(2) パーソナルスキル、インダストリー／適用業務スキル、 ビジネスマネジメントスキルカテゴリーにおけるスキルレベル(例) 熟達度レベル ー パ ソ ナ ル ス キ ル 1 2 3 4 5 リーダシップ 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 総合ポイント 総合スキル・レベル インダストリー／適用業務スキル ビ ジ ネ ス ス マ キ ネ ル ジ メ ン ト 0.2 0.7 1.3 2.2 6 7 すべての項目で スキルレベル３ 以上で、スキル レベル４が２個 以上、スキルレ ベル５が２個以 上のこと すべての項目で スキルレベル４ 以上で、スキル レベル５が５個 以上のこと 18 24 29 3 4 4.8 2 2 すべての項目が スキルレベル３ 以上で、スキル レベル４以上が ２個以上のこと すべての項目が スキルレベル３ 以上で、スキル レベル４以上が ３個以上、スキ ルレベル５が２ 個以上のこと 0 2 3 3 3 情報化と経営 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 2.5 3.3 4.2 0.5 1.5 34 Ⓒ2005 IPA All Rights Reserved 表2.5―3 (3 ) テクノロジー／メソドロジースキルカテゴリーにおけるスキルレベル(例) 専門分野：シス テム開発 熟達度レベル 業務・システム要件分析 システム／ネットワーク／障害対策設計 テ ク セキュリティ設計 ノ 運用設計 ロ ジ 情報技術（ＩＴ）、ネットワーク技術 ー メ ソ ド ロ ジ 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 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 ス ソフトウェアエンジニアリング キ／ コンサルティングメソドロジーの活用 ル 総合ポイント 総合スキル・レベル 専門分野：ＩＴアウトソーシング 熟達度レベル 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 1 2 3 4 4 3 3 ス ソフトウェアエンジニアリング キ／ コンサルティングメソドロジーの活用 ル 1 2 2 2 3 3 3 0 0 1 2 3 2 2 ナレッジマネジメントの活用 0 0 1 2 3 3 2 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 2 3 4 4 3 3 0 1 2 3 3 2 2 ナレッジマネジメントの活用 0 1 2 3 3 3 2 総合ポイント 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 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 12 19 26 28 25 23 0.8 1.5 2.4 3.3 3.5 3.1 2.9 テ ク ネットワークシステム資源管理 ノ 障害対策・セキュリティ対策 ロ ジ ネットワーク運用設計・運用管理 ー メ ソ ド ロ ジ ー 専門分野：ソフトウェア製品開発 熟達度レベル テ ク システム／ネットワーク／障害対策設計 ノ セキュリティ設計 ロ ジ 情報技術（ＩＴ）、ネットワーク技術 ー メ ソ ド ロ ジ ー 総合ポイント 総合スキル・レベル 35 Ⓒ2005 IPA All Rights Reserved 図 2.5−1 熟達度レベル別スキル量の推移(イメージ図) 高 ７ 熟達度レベル プロジェクト マネジメント ビジネス マネジ メント パーソナル マネジメント ６ 2.5 −4 ５ テクノ ロジー／ インダス メソドロジー トリー／ 適用業務 ４ ス キ ル ３ 項 ２ 低 表 １ 目 PMにはこのレベルはない の 説 明 少ない スキルカ テゴリー スキル量 スキル項目 統合Ｍ 多い 説 明 プロジェクト計画策定、計画実施、変更管理を行い、プロジェクトを成功裡に遂行 することができる スコープＭ プロジェクトスコープを適切に計画、定義、管理し、プロジェクトを成功裡に遂行す ることができる タイムＭ 作業定義、順序設定、所要時間見積もり、スケジュール作成、管理全般を実施 し、プロジェクトを成功裡に遂行することができる プロジェクトマネジメント コストＭ 資源計画、コスト積算、予算設定、コスト管理を実施し、プロジェクトを成功裡に 遂行することができる 品質Ｍ 品質計画、品質保証、品質管理を実施し、プロジェクトを成功裡に遂行すること ができる 人的資源 M プロジェクト組織計画、要員調達、チーム育成を実施し、プロジェクトを成功裡に 遂行することができる コミュニケー コミュニケーション計画、情報配布、進捗報告、プロジェクト完了手続を実施し、プ ションＭ ロジェクトを成功裡に遂行することができる リスクＭ リスク特定、定量化、対応策策定、リスク管理を実施し、プロジェクトを成功裡に 遂行することができる 調達Ｍ 調達計画、引合計画等調達に関する業務の管理を実施し、プロジェクトを成功裡 に遂行することができる 36 Ⓒ2005 IPA All Rights Reserved ３． 今後の課題と提言 当ＷＧの今後の課題として、やり残した検討テーマやコミュニティとして今後勧めていきたい事項 を以下に示します。これらはＰＭ委員会全体として進め方を議論した上で次年度活動テーマとして取り 組む予定です。現時点では未承認の内容も含まれている前提で参照して下さい。 １） 今後のＩＴスキル標準の改善領域や具体的関わり方について ■今期の改善提案をベースとした研修ロードマップの見直し ■上流工程や発注側視点の考慮 ＷＧ１のスコープは今回の前提で述べている筈ですが、提案や企画段階などの上流工程はとりあ えず外しました。これをどうするか、受託側で無く発注側の立場も含めてプロジェクトプロジェク トマネジメントを考えた時にＩＴスキル標準をどう解釈もしくは改善すべきか、を今後検討してい きます。 ■更なる深堀り 今回の改善提案の検証が必要。具体的には専門分野毎のＰＭへのヒアリングを実施して、改善提 案の有効性をテストしたいと考えています。特に、熟達度レベルと今回新たに設定されたスキルレ ベルの検証とその評価方法についての十分な議論が必要だと認識しています。 ■ＩＴスキル標準改訂に対する協力 ＩＴスキル標準改訂時の意見照会やレビュー等、単なる改善提案だけで無く具体的な改訂ミッシ ョンにもプロフェッショナル・コミュニティとして関与できる仕掛けとなるべきだと我々は考えて います。 2）コミュニティとしての新規の取り組み ■各社のＰＭの達成度・熟達度の比較 これは実行可能かどうか判りませんが、研究テーマとしてＩＴスキル標準を共通ものさしとして、 各社の認定ＰＭがどのレベルかを調査し、ＩＴスキル標準の存在意義を具体的に検証したいという 意見が委員からも出ています。 ■研究会の発足 上記の再掲にもなりますが、ＰＭ委員の中から研究テーマを出し合って、まさにコミュニティと しての研究を行っていきたいと考えています。そのためにコミュニティの継続性を担保する仕組み を検討して行きます。 ■ 他のコミュニティとの連携 ＩＴスキル標準が扱っている領域以外でもスキル標準を制定しようという動きもあります。我々 ＰＭ委員会としてはこれらのスキル標準の横の連携やコミュニケーションを通じて、ＩＴスキル標 準への有効な改善が期待できると考えています。 いずれにしても、今回のＰＭ委員会やＷＧはＩＴスキル標準のＩＴ産業における有効性を更に高める ための一助に微力ながらも役立てたのでは無いかと思います。今後は上記のような検討テーマやＰＭを 育成するための様々な活動に、文字通り「プロジェクトマネジメント分野のプロフェッショナルが集ま るコミュニティ」としてもっと貢献できるような動きにして行ければと考えています。 37 Ⓒ2005 IPA All Rights Reserved プロジェクトマネジメント ITスキル標準改善提案報告書 2005 年７月２９日 初版第 1 刷 著作・監修 ＩＴスキル標準 プロフェッショナルコミュニティ プロジェクトマネジメント委員会 発行者 独立行政法人 情報処理推進機構（ＩＰＡ） IT スキル標準センター 〒113-6591 東京都文京区本駒込 2-28-8 文京グリーンコート センターオフィス 16 階 TEL：036-5978-7544／FAX：03-5978-7516 [email protected] Ⓒ2005 IPA All Rights Reserved ――本書の無断複製・転載を禁じます―― 38 Ⓒ2005 IPA All Rights Reserved