■第11回ホットセッション  
            「プロジェクトマネジメントの最新動向−プロジェクトマネジャの育成とＰＭＯ−」 ■

• ソフトウェア開発に於けるリスクマネジメントの方法と現場でのノウハウ
  　株式会社アスプコミュニケーションズ顧問、ＰＭ学会元総務委員長
  　　河合　清博氏
  
  株式会社アスプコミュニケーションズの河合清博氏により掲題について、現場での指導や実体験などをベースに講演を行った。 講演の骨子は2つに分かれており、一つは「リスクマネジメントの方法」と「プロジェクト管理　現場でのノウハウ」であった。 冒頭、ソフトウェア産業界における背景として、企業におけるリスク対策の一つとしてプライバシーマーク取得が個人情報保護法案施行に向けて活発となってきたことに触れられた。 次にリスク管理という言葉が脚光を浴びてきたのはPMBOK以降であるとし、そこからPMBOKの概要について説明をされた。 PMBOKの定義からリスクマネジメントの基本について触れた後、JISAのリスクマネジメント調査報告書を紹介。 ここではリスクの分類としては「経営リスク」、「情報サービスリスク」、「情報資産リスク」があるが 特に情報サービスリスクの考え方について説明された。 また、JISやISOの関連標準の規定を参照しながらプライバシーマークとISMSの違いを明らかにし、 リスクマネジメントの実施ポイントについて解説された。 続いて、開発現場における品質保証の経験から、品質保証体系の観点からのリスクマネジメントの 重要性について説明した。 現実的なプロジェクト管理の例として、SPC「ソフトウェア品質技術実践講座」からプロジェクト管理図を使用した、プロジェクトの局面ごとの管理図の見方や使い方を 紹介。 ここでは、管理図の活用ノウハウは、組織ごとに集め、現場にフィードバックしていくことで、 各組織に適したマネジメントが可能になることを強調された。
  そのためにも、マネジメントする立場の人間こそが、積極的に現場に出なければ 血の通ったマネジメントなど不可能であることを、品質保証部のトップとしての実体 験をベースに 話しをされた。最後に、プロジェクト管理における後進育成の重要性について説明され、講演を終えた。
  
  Q&A：
  Q:　配布された補助資料の出所は？
  A:　冒頭に紹介したJISAの調査報告書から抜粋したものである。
  
  
• ＩＴプロジェクトのプロジェクトマネージャーに必要な能力と育成方法
  日本ＩＢＭ　理事　神庭　弘年氏
  
  １．プロジェクトマネジメントについて
  
  一般的技術者＝ＰＭが知っていれば良い、ということではない！！全員が知っていることが重要。 ＳＥには、義理＋根性を指導するより、スマートなＰＭ像を示す事。そのベースとなるのが「モダンプロジェクトマネジメント」（現代的プロジェクトマネジメント）で、アメリカで１９９３〜１９９６　政府調達の法整備に合わせて定められ、日本では１９９８年ＰＭＩ活動を開始した（ＰＭＩ−Ｔｏｋｙｏ、ＳＰＭ、ＪＰＭＦ）。 アメリカでは、物をやる前に細かく決めることから始め、１９９６年のＣｌｉｎｇｅｒ　Ｃｏｈｅｎ　Ａｃｔや、１９９２年のＤＡＵ（Ｄｅｆｅｎｃｅ　Ａｃｑｕｉｓｉｔｉｏｎ　Ｕｎｉｖｅｒｓｉｔｙ）設立などの、透明度の高い仕組みを作っている。そのため、日本の様なあいまいな運用は無い。
  ２．ＩＢＭのプロジェクトマネジメント
  
  ＰＭＢＯＫは常識的なことしか定めていないし、全世界で共通している。ＩＢＭではＰＭＰをパスしないと、ＰＭとして認定されない。又それにより、全世界共通言語として話が通じる。 米国の場合、ＥＶＭが必須で、良い悪いは関係なく、全員が使うことが当たり前になっている。
  ３．日本のプロジェクトマネジメント
  
  ＳＷＥＣ：ソフトウェアエンジニアリングセンター ＩＴＳＳ：ＩＴスキルスタンダード 日本のＩＴに関する調達改革（制度の透明化）が進められているが、世界的に見ると、遅れている。 カナダでは、政府がＰＭコンピテンシー制度を定めており、韓国なども進めている。 中国では、駅のキオスクにＰＭの本が並んでいるくらい、急激に成長しようとしている。
  ２．プロジェクトとは
  
  　有期性、独自性が特徴で、そのために「リスクだらけ」となる。 プロジェクトマネジメントとは「品質」「期間（納期）」「予算（コスト）」を失敗無しで、しかも最短距離を最適な技術で、最速で実現するために実施する。
  ★プロジェクトマネジメントのとらえ方★
  
  プログラムマネジメント　　　　＝プロジェクトの集合体、定常事業としての管理的要素
  マルチプロジェクトマネジメント＝共通的な要素を含むプロジェクトの集合体のマネジメント
  プロジェクトマネジメント　　　＝有期性、独自性
  ＰＭＯの活動として、プログラムマネジメント的領域と、マルチプロジェクトマネメントの領域と、プロジェクトマネジメント（現場の）支援がある。
  ３．プロジェクトの成功と失敗
  
  成功プロジェクトの率は、
  　日本＝２６．７％
  　米国＝２３％（プロジェクトが中止となった割合）
  トラブルプロジェクトでは、メンバーは精神的、肉体的に疲労困憊してしまう。しかし、ＩＴプロジェクトの多くは、労働集約的な作業で、仕様が確定しない、コストが確定しない、アートの要素が強い等、プロジェクトマネージャーの個人の力量に依存している。 結局は、人の問題なのか？スキルよりも、達成感、やる気、情熱に依存している。 規模が大きくなると、検証（テスト工数＝欠陥除去）が著しく増える。すなわち開発規模が大きくなると、プロジェクトの規模（工数）は比例以上に大きくなる。すなわち、小さく分割する技術が生死を分ける。 様々な見積モデルの比較
  ＤＯＴＹ　　＝１９８０年代　　　　　　　　　　〜　１０ＫＬＯＣ
  ＣＯＣＯＭＯ＝１９９０年代　　　　１０ＫＬＯＣ〜１００ＫＬＯＫ
  ＰＵＴＮＡＭ＝１９９０年代後半　１００ＫＬＯＣ〜
  
  ４．ソフトウェア技術者の成長のメンタルモデル
  
  個人の力量に依存する度合いが増加し、成長の鍵は、個人に姿勢に掛かる（プライドを棄てる、自分の力量に正直に、問題解決策は複数ある、スキルが重用）。用件定義では、聞く、読む、理解する、書く能力が必要で、最も大切な「理解する能力」とは、抽象化能力＝「モデリング能力」の獲得が必要。 又、プロジェクトの中では、無駄な人を排除する、役割が明確でない人は不要とする必要があり、ＰＭとは管理職（ラインマネジャー）ではなく、技術職として考えている。そして組織的にＰＭ力を高める取り組みが必要で、ＩＢＭではＰＭＰ合格を必須としている。
  コンピテンシーモデルとして（Ｍａｌｅｒ　１９９７）以下の事を行っている。
  ・ｅ−Ｌｅａｒｎｉｎｇ
  ・モチベーション、動機、価値観
  ・メンタリング＝支援、個人の秘密日記帳（公開情報共有）
  ・ＰＭはメンターとなりＰＭの相談を受ける
  ・（人事評価には使わない）
  ナレッジマネジメントは、過去の知識の横流し再利用、世界中の経験が参照できるという効果がある。
  
  ５．企業全体へのＰＭ浸透（エンタープライズプロジェクトマネジメント）
  
  　ＩＴを離れて、企業そのものがマトリクス型に変わっている。
  　　　　　設計開発　試作　部品手配　品質管理　．．．
  　製品ａ　　ｘ部　　ａ部　　ｎ社　　　ｑ部　　．．．
  　製品ｂ　　ｙ部　　ａ部　　ｈ社　　　ｒ部　　．．．
  ＩＢＭ憲章：プロジェクトマネジメントをＩＢＭの中核となるコンピテンスとする
  ＣＭＭＩを受ける理由として、会社のプロセスを評価しないと、マトリクス型に適用できない。
  １つ毎に、オーダーに応じて製造する＝一品製造、から、市場の動きにすばやく対応＝振る舞いを変えようとしているオンデマンドマトリクスに変化する必要がある。
  ＥＡがターゲットと考えていて、モデリングができないと何もできないため、全員が理解する必要がある。
  
  ６．日本のプロジェクトマネージャーに必要な知識と動向
  
  グローバル化、ＩＴパッケージを組み合わせる、標準化、ビジネスモデルの構築の知識が必要。
  例えば、ＩＣタグについて、アメリカでは盗難防止、日本ではトレーサビリティとして注目しているが、アメリカでは、まずプランニング（企画、使い道）を考える。システムそのものより業務の中身を知ることが重要。
  
  ７．プロマネコミュニティ
  
  社内で、プロマネ同士のコミュニケーションの場を作って、メールでの情報交換、悩み相談などを行うと共に、社外に対しても様々なＰＭ団体に参加するようにしている。
  
  
• 日本のプロジェクトマネジャに必要な知識と動向
  　コーポレイト・インテリジェンス株式会社　代表取締役
  　　武富　為嗣氏
  
  １．ＩＴプロジェクトの動き
  
  ９０年代、クライアントサーバ、ＥＲＰパッケージの登場で情報システムにかかわる人の役割やプロジェクトの進め方が変わってきた。ＥＲＰの導入によりプログラムの開発からパッケージのパラメータ設定へと 単にプログラムの作り方を知っているのではなく、業務含めてシステムをどう作りあげるかの視点、意識が必要となってきた。同時に、新しい組織概念（ＡＳＰ、アウトソーシング、シェアードサービス）の導入、 グルーバルな企業活動、PLM（プロダクトサイクルマネージメント）、電子商取引等の情報システムを取り巻く環境が変わってきた。 シェアードサービスが進んだ形がオフショアリングになる。 ソフトウェア業界も中国、インド等のオフショアリングによりここ数年で仕事は出てゆかないがオフショア価格が国内に入ってくる可能性が高い。いわゆるユニクロ現象が起きる。 こういう状況では一からシステム構築するのでなくパッケージを組合せたシステム開発するケースが増加する。電子商取引ではシステム構築よりビジネスモデルをどう造るかが重要 ＩＴ技術だけでなくビジネス、業務に精通する必要がある。
  ２．プロジェクトマネージメントとは
  
  期間が決まっていて、定常状態で動いているものに変化を起させ、次の状態に変わるまでの期間を マネージするのがプロジェクトマネージメントである。オーナー側から観たプロジェクトマネージメントは、今の業務を、ＩＴを使って変えること。ＩＴを投入して、当初目的が達成されたらプロジェクトは終息となる。 オーナー側は自分達で開発できないものをSier、ソフトハウスに発注する。自ずから受注側とオーナー側のプロジェクトマネージメントは視点、範囲が異なってくる。 プロジェクトマネージャはシステムそのものより業務の中身に関与するところでプロジェクトを理解することが重要である。しかし、ＩＴプロジェクトでは、プロジェクトマネージャ自体が存在しなかったり、コーディネータ的役割だったり、プロジェクトマネージメント自体をマネージャ自体が理解してないケースがある。そして社内も動かせない。プロジェクトマネージャがやるべきことがきちんと実施されてないのが ＩＴプロジェクトの実態である。（例えば、進捗管理、変更管理等）多くのプロジェクトで失敗する原因として仕様がうまく固めきれないことが多い。最近では、業務の繋がりを重視し、ＡｓＩＳ　ＴｏＢｅを明確にする。業務を図面に落とせるか。これがうまくゆかないと仕様は固められない。 開発フェーズ毎（初期、中期、終盤）に潜在的なリスクはある。プロマネがうまく機能しないと多くの問題はテストの段階で噴出し、予算と納期をオーバーしてしまう。そこまでは何もしなくてもプロジェクトは進んでしまう。会社がプロジェクトをサポートする仕組み、体制ができているか否かで、ＰＭの力が発揮できるか違いが出る。プロマネは知識経験だけでなく適性（リーダシップの発揮）が重要である。 プラント分野では、入社数年間で適性に応じてプロマネと専門家に分ける。プロマネに向く人はフットワークがあり、交渉力を持つ。技術的な細かい中身が分からなくても首を突っ込んでゆける能力が必要。 ＩＴ分野ではIT技術を知っていれば誰でもプロジェクトマネージャにしてしまう。 ある程度以上の開発規模になると適性の弱いプロマネだとプロジェクトが失敗する可能性が高くなる。 プロマネはＩＴ特定技術知識の専門家でもなくても勤まる。管理知識とリーダシップ（キャラクタ）がプロジェクトマネージャには重要である。
  ３．ＰＭＯとは
  
  ある程度の規模を超えるプロジェクトであるとプロマネが全てのことに精通しているわけでない。 その為、プロマネを支えるスタッフが必要である。 プロマネとプロマネを支えるスタッフを合わせてＰＭＯと呼ぶ。 ＰＭＯは２種類あり、プロジェクト内で造る（開発と別に進捗状況やドキュメント整理具合を管理する）オペレーショナルなＰＭＯとプログラムＰＭＯ（プロジェクト本部、組織、プロジェクトセンタ）がある。 一般的には前者の例が多いが、進んだ企業では後者の取り組みを始めている。 ＰＭＯの機能（ＰＭとスタッフの役割）は次のフェーズに進むかのジャッジ、リスクマネージメント（プロマネが難しいのは経験がないとリスクが見えない）、スケジュールコントローラ等である。 ９０年代の後半からこういうことに関心がもたれるようになった。その背景は、プロジェクトの失敗が多発、クライアントサーバの台頭、インターネットが進んでビジネスモデルまで考慮する必要が出てきた。
  ４．プロジェクトマネージメントの進化
  
  プロジェクトマネージメントは発達の過程で三世代に分けられる。
  ・第１世代
  　ＱＣＤスケジュールのトレードオフを管理する。
  　リスクを管理。予見し、失敗時の次善策を立案する。
  ・第２世代
  　プロジェクトの投資収益性、戦略性を管理する。
  ・第３世代
  　ビジネスモデルまで管理する。
  
  ＰＭ自体が特定技術専門家である必要はない。専門家を取り込んでマネージしてゆけばよい。 マルチプロジェクトとプロジェクトという概念がある。マルチプロジェクトは無関係なプロジェクトが複数走っている形態である。プログラムは、いくつかのプロジェクトが一つのミッションのもとで走っている形態である。
  
• パネルディスカッション
  
  パネラー
  　神庭弘年氏（日本ＩＢＭ）
  　武富為嗣氏（コーポレイト・インテリジェンス）
  　島田さつき氏（富士通）
  　北嶋義弘氏（S-Open副会長）【司会】
  
  講演進行の関係で、各講演後に質問時間が取れなかった為、質問を会場から募った。
  
  Ｑ１ 　武富さんの資料に関して
  　第３世代のプロジェクトマネージメントはオペレーショナル部分で留まるか経営、戦略まで入り込むのか？
  Ａ１
  　線引きによるがプロジェクトマネージメントで求められる役割が経営層まで入ると思う。
  　組織によってプロジェクトマネージメントと経営を分けて考える事になる。
  　Ｐ２Ｍでは、カルロスゴーンの日産改革をプロジェクトとして捉えている。
  
  Ｑ２
  　神庭さんの講演の中で
  　プロマネは技術職であって管理職と違う（技術を知っている必要がある）との内容がありました。
  　現場で、技術だけを持っている人がプロマネをやると管理面で失敗するケースを見るが
  　その考え方の背景をうかがいたい。
  Ａ２
  　プロマネはＷＢＳ、見積、工程の作成等のプロマネ業務はできなければならない。
  　最近のＩＴプロジェクトはＩＴにまつわるリスクが大きい。
  　ＩＴ素養の乏しいプロマネが間違えて失敗するケースが多い。
  　技術者をそのままプロマネに据える事とは違う。
  
  Ｑ３
  　マルチプロジェクトマネージメント（ＭＰＭ）、プログラムマネージメント（ＰＧＭ）の切り口の違い？
  Ａ３
  ◆神庭氏
  　ＭＰＭは、互いに競合・関係する複数のプロジェクト
  　ＰＧＭは、基本的にはマルチだが時間軸が長い。ビジネスマネージメントに近い側面を持つ。
  　（期間を限定しないスコープでビジネスを追求する）
  ◆武富氏
  　例えばＮＡＳＡが月にロケットを打ち上げることは人類を月に送るミッションで
  　それをプログラムと見ている。
  　月に人を送るにはロケットを打ち上げる、宇宙飛行士をトレーニングする、ロケット運行管理等の
  　複数のプロジェクトが走る。
  　全体として１つミッションのもとに走った。そういうものをプログラムと呼ぶ。
  　通常、別々のミッションでプロジェクトが動く。そういうものをマルチプロジェクトと呼ぶ。
  ◆島田氏
  　ＰＧＭはビジネスドメインまで含めて考えるものと理解している。
  　個々のプロジェクトリスクをどこまで広げて考えるかによる。
  　プロジェクトにより責任範囲が違う。
  　ＰＧＭはビジネスまで含めた形でアプローチするもの
  　ＭＰＭはプロジェクトのタイプを総合してエンタープライズにプロジェクトの優先度を測る。
  
  一通り、会場とのやり取りをした後、パネリストの共通する意見として プロジェクトマネージャに基礎的な管理の知識、訓練が欠如している指摘が出る。 例えば、WBSの落とし方やクリティカルパスの押さえ方、見積方法がプロジェクトマネージャにできてない。PMOのような流行の言葉で議論するだけでなく、もう少しこつこつ地道に管理プロセスを改善する努力をするべきと。
  最後に司会の北嶋氏からスタッフとプロジェクトの協力関係をＰＭＯという名前だけでなく、うまく造って行く議論を続ける事が重要と結論付けがなされて終了。