最近増えている大規模開発や長期案件、イノベーション開発はいずれも、小規模プロジェクトの集合体だ。こうした案件では、従来とは違った「プログラムマネジメント」の実践が求められる。本特集では、PMが実践したい中核となるベネフィットマネジメントやガバナンスなど、七つの要点を専門家に解説してもらう。

 「プログラム」というと、多くの人はJavaやCOBOLなどで書かれたソースコードを思い浮かべるだろう。しかしプログラムとは、日常会話でもよく使う一般的な言葉だ。例えば運動会やコンサートのプログラム、テレビのプログラム(番組表)や学習プログラム、ダイエットプログラム、禁煙プログラムといった使い方がある(図1)。

図1●「プログラム」の意味
[画像のクリックで拡大表示]

 プログラムの語源をたどると「Pro-(前に、公に)+gram(書く)」である。つまり「前もって書かれ、公に示された手順や道筋」だ。またプログラムには「何かを成し遂げるために」「何かを変えるために」というニュアンスも含んでいる。

 コンピュータのプログラムは、ITエンジニアが意図する処理手順(命令語)を記したものだが、今回取り上げる「プログラム」は、対象が大きく組織の戦略や目標、ビジョンを達成する、つまりビジネスを成功させる道筋だ。例えば「ITへの投資対効果の最大化」を組織の目標として掲げ、各拠点で個別に運用しているネットワークを統合するケースを考えてみよう。これが一気にできる規模でなければ、最初に本社のネットワークを整備し、次に国内の拠点、それからグローバルに展開することを考える。この場合、ネットワーク統合を一つの大きなプロジェクトと考えるよりも、本社の統合プロジェクト、国内拠点の統合プロジェクト、北米の統合プロジェクトというように複数のプロジェクトを通して仕上げていくほうがやりやすくなる。このように関連する複数のプロジェクトを束ねたものが、今回テーマとするプログラムだ。

 大きなプログラムでは、プログラム自体が階層構造を持つ。先の例でITのプラットフォーム統合自体をプログラムとして捉えれば、その下にはネットワーク統合プログラムだけでなく、サーバーやデータセンターの統合、業務アプリケーションの統一、オフィスソフトやメールソフトの標準化などのプログラムを計画する必要がある。

注目浴びるプログラムマネジメント

 IT現場でも最近、このプログラムマネジメントが注目されてきた。背景にはプロジェクトマネジメント技術の成熟と、プログラムマネジメント分野での標準化の動きがある。

 プログラムはプロジェクトの上位概念だ。下位のプロジェクトをマネジメントする技術がしっかりしなければ、プログラムもマネジメントできない。PMBOK(Project Management Body Of Knowledge)に代表されるモダンPMが国内に広がって10年以上が経つ。その結果、知識レベルだけでなく、実践面からもプロジェクトマネジメントが成熟してきた。これが最近のプログラムマネジメントの普及・拡大を後押ししているのは間違いない。

 一方、プログラムマネジメントの国際化・標準化の動きも見逃せない。もちろんプロジェクトマネジメントに比べるとまだまだだが、主な標準として、米PMIの「プログラムマネジメント標準」、英AXELOSの「MSP(Managing Successful Programmes)」、日本プロジェクトマネジメント協会(PMAJ)の「P2M プログラム&プロジェクトマネジメント標準ガイドブック」などがある。またISOでは、プログラムマネジメントの国際規格化も進めている。

プログラムの3パターン

 ひと口にプログラムと言っても、大きく三つのパターンがある。すなわち(1)分割パターン、(2)段階的パターン、(3)イノベーションパターン―である(図2)。

図2●「プログラム」の三つのパターン
[画像のクリックで拡大表示]

 分割パターンは、大きなプロジェクトを細かく切った状態にしてプログラム的にマネジメントするケース。段階的パターンは、先に挙げたネットワーク統合のように、段階的に仕上げていくケースである。イノベーションパターンは、新事業や新製品・サービスを創出するケース。以下では、それぞれのパターンの特徴を見ていこう。

◯分割パターン

 大きなプロジェクトは難易度が高くなるので、通常は経験豊富な上級のプロジェクトマネジャーが担当する。スコープが2倍なら難しさも2倍かと言えばそうではない。3倍にも4倍にもなる。だからこそ小さなスコープに分割すれば、大規模プロジェクトの成功率を高められるわけだ。

 ところが、スコープを小さく分割すると別の難しさが生じる。分割した各プロジェクトが複雑に絡み合うからだ。小さく分割してプロジェクトやシステムのインタフェースがかえって複雑になっては元も子もない。そこでプログラムの観点が必要となる。

 分割パターンを適用しやすいのは、企業統合などに伴うシステム統合だろう。事業や業務の単位にプロジェクトを分けて、両者の相対するシステムを統合するプログラムだ。

 あまり規模が大きくなくても、部署ごとに持つシステムを統合する場合には分割パターンが向く。例えば在庫不足や過剰在庫を抑止するためのサプライチェーンマネジメント(SCM)改革を行う場合、調達部門の仕入れ管理システム、物流部門の在庫管理システム、営業部門の販売管理システムのエンハンス(拡張)プロジェクトとして、それぞれ立ち上げるものだ。分割パターンはこうした細かく切ったプロジェクトを束ねるため、「マルチプロジェクト」とも呼ばれている。

◯段階的パターン

 段階的パターンは、時間軸に沿って順次プロジェクトを立ち上げ、段階的に仕上げていくプログラムだ。いくつかのフェーズに区切り、今年はここまで、来年はここまでやって3カ年計画で仕上げるといったケースである。

 図2の(2)に示したのは、運用効率の向上や情報共有の改善のために、社内に存在するサーバーをデータセンターに集約するプログラムだ。地域や事業、組織、業務ごとに順次展開する例が多い。分割パターンで挙げた小さなスコープと同様に、マイルストーンも小さくして成功率を高めるわけだ。

 ただし、各プロジェクトを立ち上げる順序、既に完了したプロジェクトの経験や教訓を引き継ぐためにリソース配分を考えなければならない。また、段階的パターンのプログラムは長期にわたる傾向がある。プログラム期間中に技術や経営状況など取り巻く環境が変わりやすく、これまでのプロジェクト以上に難しさがある。

◯イノベーションパターン

 プログラムの三つめが、イノベーションパターンだ。そもそもプロジェクトとは、定常組織では解決できない課題に対応するために立ち上げる。どういうプロジェクトを立ち上げるかは、より上位で意思決定し、この意思決定が予算化のプロセスの中で行われる。当然、プロジェクトで解決すべき課題が大きいものや難しいもの、今までの延長では解決できないものもある。このうちどう進めてよいのか漠然としているイノベーションを伴う新事業の創出、新商品・サービスの開発は、プログラムマネジメントが適している。実際、コードネームを付けて「○○計画」と表現する場合は、プログラムと解釈できる。

 新商品・サービスの開発では、商品企画、研究開発、マーケティング、商品開発、プロモーションなど、異なる部署間で有機的なつながりを持つプロジェクトが立ち上がる。しかも、あるプロジェクトの結果が他のプロジェクトに影響したり、世の中の変化に対応して進む方向を変えたりすることがある。この場合、経営とプロジェクトをつなぐ役割として、プログラムマネジャーを置くほうが関連するプロジェクトへのガバナンス、コントロール、さらには当事者では困難なプロジェクト打ち切りの判断が容易になる。

三つの「PM」の関係を理解する

 プログラムのイメージができたところで、三つの「PM」を押さえておこう。三つのPMとは、ポートフォリオマネジメント、プログラムマネジメント、プロジェクトマネジメント―の三つである(図3)。

図3●三つの「PM」の関係
[画像のクリックで拡大表示]

 プログラムとプロジェクトの関係は概ね理解できただろう。では、プログラムやプロジェクトと同じく標準化されているポートフォリオとはどういうものか。ポートフォリオは1962年、後にノーベル経済学賞を受賞するハリー・マーコビッツ氏によって提唱された理論。期待収益にリスクの考え方を取り入れ、株式市場などでの資産運用の理論として利用されてきた。その後、コンサルティング会社などが事業分野の選択と集中、プロダクトラインの選択の手法としてポートフォリオを使うようになった。

 株式投資や事業の選択と同様に、実施すべきプログラムやプロジェクトを選択するのがポートフォリオマネジメントである。この選択のための評価軸は、収益性、成長性、有益性、リスク、リソース配分など多様だが、まだ定着した手法には至っていない。

 ポートフォリオマネジメントの守備範囲は、どのプログラムやプロジェクトを実施するかを決めるまで。実際に実践して結果を出すのは、あくまでプログラムやプロジェクトである。プログラムを構成するプロジェクト同士は関連性を有するが、ポートフォリオで選択されるプログラムやプロジェクトは互いの関連性を求められない。

中心はプログラムマネジャー

 それでは、プログラムマネジメントの具体的な内容に入ろう。まずは、プログラムの構成(組織)である。

 図4にプログラムを構成するメンバーを示した。プログラムマネジャーを中心に、プログラムチームメンバー、プログラムマネジメントオフィスのメンバー、傘下のプロジェクトのプロジェクトマネジャーやプロジェクトチームのメンバーから成る。

図4●プログラムの組織構成
[画像のクリックで拡大表示]

 まずプログラムマネジャー像を考えてみよう。プログラムは、分割パターンだと規模が大きく、段階的パターンだと長期にわたり、イノベーションパターンだと新規性が増す難しさがある。各プロジェクトをまとめるには、権限やコミュニケーション力、そして何にも増して意思決定力が必要だ。

 ユーザー側と違って、ベンダーに所属するITエンジニアにとっては、ビジネスの成功をプロデュースするプログラムマネジャーは想像しにくいかもしれない。だが、イノベーションパターンが増えてくると、ベンダー側にもその役割が必要となる。つまり、ベンダー社内で新商品・サービスを開発するプログラムマネジャーだ。

 次にプログラムチームのメンバー像を考えてみよう。プログラムマネジャーのサポートはプログラムマネジメントオフィスの役割であり、成果を出すのはプロジェクトだ。では、プログラムチームメンバーは何をするのか。

 ここでいうチームメンバーは、プログラムの成功に欠かせない核になる人たちだ。その役割は、パターンによって異なってくる。

 分割パターンのプログラムチームメンバーは、プログラムの初期段階から参加。プログラムマネジャーと一緒に計画を立て、プロジェクトが発足すると、プロジェクトの中心メンバーとして加わる。プロジェクトを発注する場合は、ユーザー側ならカウンターパーソンのような役割に就く場合が多い。

 段階的パターンでは、技術やノウハウを引き継いでいく人たちがチームメンバーとなる。例で挙げたデータセンターの集約プログラムの場合、東京センターへの集約が終わるとメンバーが解散して、大阪センターへの移行を新たなメンバーで進めるわけではない。中核になるプログラムチームメンバーが、引き続き大阪プロジェクトも担当する。こうした中核メンバーは、計画段階からアサインする必要がある。

 イノベーションパターンでは、新事業や新商品・サービス開発のコアとなる技術を持つ人がチームメンバーとなる。いわゆる「尖った人」となるケースが多い。プログラムマネジャーは、こうしたチームメンバーをどのように活用するかが腕の見せどころだ。

プログラムマネジメントの7大テーマ

 では、プログラムマネジメントの進め方について説明しよう。プログラムマネジメントの領域は、まだプロジェクトマネジメントのような統一的なガイドラインがあるわけではない。そこで以下では、筆者らの経験を基に、現在のプログラムマネジメントで実践したい7大テーマを取り上げる。

1 明確なビジョンを持つ

 プログラムを推進する上で最も大事なのは、明確なビジョンを持つことだ。このビジョンに基づいてプログラムを推進する。プログラムは長期にわたるため、プログラムを取り巻く市場環境が大きく変わりやすい。当然、それに伴って計画も大きく変動する。

 このとき軌道修正がうまくできるかどうかで、プログラムの成功確率が変わってくる。その鍵を握るのが、決してブレない明確なビジョンだ。

 ビジョンとともに、プログラムの立ち上げ段階で経営的な位置付けやミッションなども議論し、プログラムチームメンバーで共有しよう。大きな問題が起きた時や軌道修正が必要な時は、これなしに対応できない。

2 ベネフィットを追求する

 プロジェクトマネジメントは「プロフィット」を追求するが、プログラムマネジメントは「ベネフィット」を追求しなければならない。プロフィットは、金銭的、あるいは即物的な利益を指す。誰にとっても分かりやすいものである。

 これに対してベネフィットは、便益や価値と訳される。例えば「(会員)特典」のような使われ方をする。この場合、金銭的な利益だけでなく、コミュニティーに参加できたり、優先的に予約ができたり、特別な記念品をもらえたりする、といった有形・無形の価値を含む。

 ベンダーの多くは、プロジェクトマネジメントに熱心である。ベンダーの場合、ユーザーからプロジェクトを受注して開発を進める。ベンダーにとってプロジェクト成功の指標は、QCD(品質・コスト・納期)と顧客満足度となる。だが、プロジェクトは独自性が強いのでリスクが伴う。要求仕様が曖昧で、個人の能力や人間関係の影響、既存システムの制約など、さまざまなリスクがコスト増大、納期遅延、品質低下の要因となる。納期遅延や品質低下は、もちろんコスト増大につながる。不採算プロジェクトを防止し、適正なプロフィットを確保するには、プロジェクトマネジメントの手法を活用しなければならない。

 これに対してプログラムマネジメントの視点では、モノを作る過程だけでなく、プロジェクトやプログラムを通じて作り出されたモノがビジネスの役に立つかどうかが評価の対象となる。利益率など財務指標の改善はもちろんだが、市場の拡大や競争力強化、ビジネスプロセスの改善、運用改善などを達成しなければならない。直接金銭的な価値に結びつくものばかりではないのでベネフィットと呼ばれるのだ。

3 多くのステークホルダーを巻き込む

 ステークホルダーとは、利害関係者のこと。プロジェクトやプログラムを成功に導くために、関係する人や組織を洗い出して期待や影響を分析し、より良い関係を築き上げるのが、ステークホルダーマネジメントである。

 図5に示したのは、プログラムにかかわるステークホルダーの例だ。先に説明したプログラムマネジャーやプログラムチームメンバー、プログラムマネジメントオフィス、傘下のプロジェクトマネジャーやプロジェクトチームメンバーもステークホルダーとなる。

図5●多岐にわたるステークホルダー
[画像のクリックで拡大表示]

 ユーザー企業の社内のステークホルダーを見てみると、経営者や経営幹部などのスポンサーの役割を果たす人、分割パターンや段階的パターンでは複数部署にわたる利用部門もある。イノベーションパターンの場合はマトリクス組織から代表者を出すケースが多いので、それぞれの所属先の部門がステークホルダーになる。財務部門や調達部門、他にも関連部門が加わる。

 ユーザー企業の社外の顧客や取引先、関連会社もステークホルダーになる。また、プロジェクトを発注している場合は、発注先のベンダー内のプロジェクトオーナーやプロジェクトマネジメントオフィス、営業部門といった関連部門もステークホルダーだ。

 もっとも、ステークホルダーマネジメントはプロジェクトマネジメントの知識領域にもある。やることはプロジェクトでもプログラムでも変わりはない。ただしプロジェクトに比べてステークホルダーの数と種類が圧倒的に増えるのが、プログラムである。ステークホルダーごとにプログラムへの期待やニーズ、影響力などがそれぞれ異なるので、良好な関係を保つ方策をそれぞれ考える必要がある。

 例えば、発注側のプロジェクトマネジャーの期待は利用者に有益なシステムを提供し、経営幹部から高い評価を得ることかもしれない。一方で発注先ベンダーのプロジェクトマネジャーの期待は、ベンダー側で目標とする利益を確保することと、プログラムマネジャーから高い評価を得ることかもしれない。同じプログラム傘下のプロジェクトマネジャーでも、期待やニーズが異なることが分かるだろう。

 プログラムは期間が長期にわたるので、市場や環境の変化だけでなく、M&Aや組織の変更、人事異動の影響なども考えなければならない。組織のミッションが変われば期待やニーズが変わる。人が変われば考え方も変わる。

 影響力のあるステークホルダーにプログラムへの興味を持ち続けてもらうために、ステークホルダーにとって即効性のあるプロジェクトを継続的に実施したり、完了したプロジェクトの効果を定量的に評価して次のプロジェクトやステークホルダーの説明につなげたりするのもプログラムでは重要だ。

4 ガバナンスを利かせる

 プログラムは、明確な一つのビジョンの下に進められる。では、どうやってプログラム傘下のプロジェクトにガバナンスを利かせ、モニタリング、コントロールすればよいのか。これに有効な仕掛けが「フェーズゲート」である(図6)。

図6●「フェーズゲート」でガバナンスを利かせる
[画像のクリックで拡大表示]

 フェーズゲートは、プログラムやプロジェクトをいくつかのフェーズに分け、次フェーズに移るときにゲートを設ける手法だ。各ゲートの条件を満たしているかどうかをレビューし、明示的に意思決定する。

 フェーズゲートは単にフェーズとフェーズの間にあるゲートと考えるのではなく、ゲートに至るまでのプロセスも重視している。各ゲートでは、プログラムの立場からプロジェクトの「ゴー」「ノーゴー」の判定を下す。目的はビジョンやミッションからの逸脱防止やリスク軽減、経営的な利益最大化である。「ノーゴー」というとプロジェクトの打ち切りをイメージするかもしれないがそうではない。ノーゴーは、ゴーを否定しているだけなので「指摘された懸念事項や問題点があるうちは先に進まない。解決してから進みなさい」という意味だ。プロジェクトが混乱しているときにいったん止めてでも立て直させる場合は「ストップ」、本当に打ち切る場合は「ターミネート」を使う。

 特にイノベーションパターンの場合は、研究開発プロジェクトの打ち切りや、競合相手など外部環境変化に伴い大きな方向転換を迫られるかもしれない。プロジェクト側は当然、続けたいと思っているので、実際に打ち切るとなると強い抵抗がある。あらかじめフェーズゲートを設定しておけば、こうした場合でも適切に意思決定できるようになる。

 プログラムのフェーズゲートは通常、2階層になる。一つは経営やポートフォリオの立場からプログラムをモニタリング、コントロールする階層、もう一つはプログラムの立場からプロジェクトをモニタリング、コントロールする階層だ。前者は期や年度の切り替わり、あるいは予算時期や重要なプロジェクトの開始/終了時期など、プログラムの節目に開催する。満たしているかどうかの意思決定は「マネジメントデシジョンボード」や「ガバナンスボード」と呼ばれる委員会で行うケースが多い。

 一方の後者のフェーズゲートは、プログラム内のプロジェクトの計画完了や設計完了などの時期に開催する。こちらの意思決定者は、プログラムマネジャーだ。問題があればマネジメントデシジョンボードなどにエスカレーションする。どちらのフェーズゲートでも事前に権限や責任など、意思決定の仕組みを明確にしておこう。

5 プラスのリスクに対処する

 リスク要因を洗い出し、影響度などを分析して優先順位を付け、リスクへの対応策を検討する。このリスクマネジメントのやり方自体は、プロジェクトマネジメントと変わりはない。変わるのは、ベネフィットに影響を与えるリスク要因が対象になる点だ。経済的な指標だけでなく、市場の拡大や競争力強化、ビジネスプロセスの改善など、ビジネスの役に立つかどうかがリスク対象となる。

 具体的には、競合相手の出方や景気変動、研究開発がうまくいかないといったことがリスク要因となる。特にイノベーションパターンの場合は、プログラム外のリスクが増え、自分たちでは全くコントロールできないケースがある。それでもさまざまなリスクを洗い出し、対応策を考えるのがプログラムのリスクマネジメントだ。

 半面、悪いことばかりがリスクではない。リスクとは振れ幅のこと。マイナスのリスクは押さえる一方、プラスのリスクを活かしていくのが基本だ。

 もちろん、プラスのリスクを最初から期待して計画を作ることはない。だが、振れ幅が大きいイノベーションパターンでは、追い風が吹くケースなどプラスのリスクのシナリオを描いて備えておくことも求められる。

6 残資金に目を向ける

 プロジェクトマネジメントの場合、ユーザー側であれば予算金額、ベンダー側であれば受注金額をベースラインとしてコストマネジメントすればよかった。しかしプログラムの場合、プログラムを継続するための予算化や資金調達を自らやる必要がある。それがフィナンシャルマネジメントだ。

 ITプロジェクトの場合、ファンドを募るようなケースはまれで、利用部門が予算化するケースが多い。しかし大規模なプログラムでは潤沢な資金が不可欠だ。プログラムマネジャーは、各プロジェクトの見積もりと資金繰りに目を向けて、資金がショートしないように残資金の管理をしっかりマネジメントしなければならない。当然、プログラムマネジャーにはフィナンスに関する知識やスキルが必要だ。

7 支援体制を作る

 先にも述べたように、プログラムマネジメントの円滑な活動を考えると、プログラムマネジャーが一人でこなせる量ではない。これをサポートするのがプログラムマネジメントオフィスだ。プログラムマネジメントオフィスの活動は、図7に示すように多岐にわたる。もちろん活動の最終責任はプログラムマネジャーだが、大規模なプログラムになればプログラムマネジメントオフィスの役割は大きくなる。

図7●プログラムマネジメントオフィスの活動
[画像のクリックで拡大表示]

 プログラムマネジメントオフィスはどんな役割を果たすのか。一つは各プロジェクトとのコミュニケーションだ。プログラム全体の状況を把握し、適切な意思決定をするには、各プロジェクトからの情報収集が必須である。傘下のプロジェクトを含めた週次/月次の定例会議、進捗/懸案事項のレポーティングなど、コミュニケーション方法を決めて、着実にプログラム運営につなげなければならない。

 二つめは、影響力を持つステークホルダーへのレポート作成である。経営者や経営幹部など、プログラムに影響力を持つステークホルダーへのレポーティングは重要だ。報告自体は月次やマイルストーンごとにプログラムマネジャーが行うが、プログラム全体の状況を報告する資料は、プログラムマネジメントオフィスがまとめたい。

 三つめは、フェーズゲートの運営である。プログラムは長期にわたるケースが多いので、フェーズゲートを形骸化させない仕組みが必要である。これをプログラムマネジメントオフィスが担い、経営幹部など出席者のアサインや会議室/日程確保などを行う。

 このほかプロラムマネジメントオフィスは、各プロジェクト横断のITアーキテクチャーの検討や、各種手法・ツールの標準化・推進も担う。各プロジェクトのナレッジや教訓の吸い上げ、横展開もカバーしたい。プログラム参加メンバーの人材育成も担う必要がある。プログラムのITインフラを整備する役割も果たすケースが多い。

成熟度はまだまだ低い

 ここまで七つのテーマに分けて実践したい要点を挙げてきたが、プログラムマネジメントの成熟度はまだまだ低い。具体的な知識エリアも曖昧なので本記事では特に意識したいポイントについて取り上げた。今後は各企業の現場で実践を繰り返し、成熟度を高めることが重要だろう。そして業界を挙げたガイドラインの統一も望まれるところだろう。

 図8に示したのは、冒頭で紹介したプロジェクトやプログラムマネジメント関連の国際化・標準化動向だ。ISOの国際標準化は現在、審議中である。内容は公開されていないが、早ければ2017年頃に制定される。

図8●プログラムマネジメントの国際化・標準化動向
[画像のクリックで拡大表示]

 米PMIのプログラムマネジメント標準は、2008年にリリースされた。記述内容は第3版(2013年)で一定の水準に達した印象である。

 英AXELOS社のMSPは、英国内閣府が英国政府のIT調達向けに開発したもの。既に欧米でも広く使われるガイドラインになっている。

 最後の日本プロジェクトマネジメント協会のP2Mプログラム&プロジェクトマネジメント標準ガイドブックは第3版で大幅に改訂された。

 今後、ガイドラインの発展がさらに進めば、実際のプログラムマネジメントでより参考になるはずだ。

初田 賢司(はつだ けんじ)
日立製作所 ICT事業統括本部 プリンシパル
初田 賢司(はつだ けんじ) 1980年、日立製作所入社。製造業のSEを経てソフトウエア生産技術の開発に従事。現在はPMO(Project Management Office)に所属し、プロジェクトマネジメント分野のエンジニアリング化に取り組む。プロジェクトマネジメント学会副会長。著書に「本当に使える見積もり技術」(日経BP社)「システム開発のためのWBSの作り方」(日経BP社)がある。
桑原 恵治(くわはら よしはる)
日立製作所 ICT事業統括本部 プロジェクトマネジメント統括推進本部 IT人財マネジメントセンタ 技師
桑原 恵治(くわはら よしはる) 2002年、日立製作所入社。流通業のSEを経験後、PMO(Project Management Office)に所属し、プロジェクトマネジメントの支援技術の開発、プロジェクトマネジメント制度の制定、および展開に従事。現在は、日立ITプロフェッショナル認定制度(社内の人材認定制度)の推進に携わり、新職種の検討や認定者の活用に取り組む。
武田 昭(たけだ あきら)
日立製作所 ICT事業統括本部 プロジェクトマネジメント統括推進本部 IT人財マネジメントセンタ 担当部長
武田 昭(たけだ あきら) 1977年、日立製作所入社。流通業のSEを経て生産性向上技術のプロジェクト適用推進に従事。現在は、日立ITプロフェッショナル認定制度(社内の人材認定制度)の取り纏めとともに、上級プロジェクトマネージャの育成を担当。プロジェクトマネジメント学会標準化検討委員会委員。共著に「やってみよう!!プログラムマネジメント」(プロジェクトマネジメント学会)がある。
出典:日経SYSTEMS 2016年10月号 pp.48-55
記事は執筆時の情報に基づいており、現在では異なる場合があります。