 |
|
【PMO昨今】 イデオ・アクト株式会社
代表取締役 葉山博昭、PMP：10月号 PMAJ研修第二部会の話題からずれますが、筆者が現在行っている「PMO」のコンサルティグを通して得られた「PMO」のIT業界での最近の情況を私的な思いも含めて書いてみました。 「PMO」という言葉自体はあっという間に市民権を得てしまったようです、8、9年前からプロジェクト・オフィスと呼ばれ、EPM(Enterprise Project Management)でもプロジェクト・オフィスがキーと言われても、なかなか普及しなかったことから比べると隔世の感があります。 ところがIT業界の悪いところで3文字言葉を大手企業が話題にすると野火のごとくに業界全般に広がるが、数年すると熱が冷めてしまう。「PMO」も先端企業では既に4、5年の試行錯誤でようやくこの1、2年で効果出てきた企業もあるが、現状ではまだまだその緒に就いた段階の企業も多く、先端企業では「PMO」は当たり前のことでことさら「PMO」を話題にすることもなくなって来ているが、それを真似る企業では「PMO」という話題が少なくなって来たことから、効果が無いと早合点してしまう傾向もある。このように先端企業では改革を常に行えるが、そうでない企業では改革を行おうとしては次ぎの話題に心を奪われ改革が中途端になる傾向があり、「PMO」もやはりその例に倣おうとしているように見える。大手のシステム開発企業ではいまさらPMBOKが必要かなどと議論する必要のないほどPMBOKをプロジェクト・マネジメントの共通基盤としているが、未だにPMBOKは効果があるかないかなどと議論している企業もあり、プロジェクト・マネジメントに対する認識、実務能力は企業により格差はより拡大しつつあるように思えます。未だに開発標準、QMS、プロジェクト・マネジメントの関係を認識出来ていない企は多く、本来企業経営の問題であることを「PMO」を設置すれば全てが解決すると思いこみ「PMO」を設置する企業も多いようです。このような企業ではプロジェクト・マネジメントと「PMO」とが結びつかず、プロジェクト・マネジメントを強力に推し進めるための推進機関がPMOであると言う認識が無い場合もあります。このような企業では「PMO」といっても何を目的するものなのか不明で、効果が出る出ない以前に何も機能しない例も数々あるようです。 1．なぜ「PMO」を設立するのか？ 「PMO」を設立するシステム開発を行う企業の殆どはトラブルの続出に頭を痛め、トラブルを無くしたいとの一心から「PMO」という言葉に飛びつく企業が多いように思われる、しかし、成功していると思われる企業の「PMO」でも様々な試行錯誤の結果軌道に乗るのに4、5年を要しており、単に「PMO」という組織を作っただけでは直ぐには機能しないが、一年位で効果が出ないと止めてしまう例もあります。 「PMO」設立の失敗の原点
システム開発を行う企業にはそれぞれの企業文化があり、システム開発のトラブルといってもその原因はかなり様相が異なる。システム開発を行う企業でも一例ですが下記のような特性があります。
自己の企業の強い点、弱い点はその企業の長年の蓄積の結果で企業文化ともなっており、トラブルを分析することはその企業の文化を見極めることに繋がります。「PMO」にその企業の弱点の多くを補強することを求めるのは、企業文化を変えることを求めるのと同じようになり、無理な面があります。「PMO」がプロジェクト・マネジメントを通してシステム開発の理想像を描き、企業文化の改善までを担ってしまい社内の歴史ある部門の反発を受けうまく機能しない「PMO」もあります。 トラブルの分析を行うことにより「PMO」は危険な分野を認識出来、リスク管理を行うことが出来ますが、分析を行わないとリスク管理の焦点がぼけてしまいます。例として、方式設計ではトラブルを発生させたことが無い企業ではリスク識別の項目には方式面は必要ないか、より高いレベルのリルク識別を行うという具体的な「PMO」の活動となって表れます。企業によっては性能に関しては元受会社の責任とし受託条件から外し、リスクを移転しているケースもあり、そのような企業ではリスク識別に方式に関する項目は設ける必要が無いといったことが例となります。 3．「PMO」の目的、範囲を定めているか？ 「PMO」は経営者が求めるような魔法の杖ではありません、企業文化を変えるほどに力があり全社を挙げて歓迎され、企業が真に改革を行う旗振りになるものと全社を挙げて認識されているなら強力な「PMO」の発足は可能でしょう。トラブルを解消したいというのは本音でしょうが、それが企業文化まで変えることになると認識出来るソフトウェア開発企業の経営者は少ないようです。単に受託したシステム開発のプロジェクトが赤字ならないよう末端の事業活動が円滑になることを「PMO」に期待している企業が多く、「PMO」設立が企業文化まで影響する経営の重要事項と理解している経営者は少ないように思われます。 そこで、「PMO」を設立する場合はその企業の文化とにらみ合わせ、なにが可能かを見極め、出来るだけ「PMO」の理想に近い現実的な目的を設定する必要があります、あまり高い目標を置いても社内で浮き上がってしまい何も出来ない可能性があります。それでも従来プロジェクトに直接影響する組織がなかった状態からすると大きな変化となるので、決してボトムアップで出来るほど小さな影響しかない組織ではないので、企業経営ップの強力なトップダウンでの実施が必要です。成功している「PMO」の多くはソフトウェア開発自身に造詣がある(システム設計、プログラミング経験)経営トップの主導により出来た「PMO」のようです。「PMO」はシステム開発の方式設計、開発技術(開発標準)、生産技術、品質管理というようなソフトウェア開発の個々の技術は「PMO」外の専門部署で行っていることを前提とし、「PMO」はリスク管理を目的とすると他の部門とのヒッチが少なく、また組織的に独立していれば、他部門のプロジェクトへの影響を「PMO」が評価出来ることにもなります。同一の組織内にあると評価しにくく、別組織にあったほうが外部から評価を受けることで、個々の技術の発展を促すこともできます。 「PMO」の目的の一例 「PMO」以外の他の部門がより良いもの作るという、だれでも理解出来ることを目的にしていて、それがプロジェクトを成功させるのに大きな要因であり、プロジェクトを成功させるのに又別の組織が必要なのかよく理解出来ない場合があります。リスク管理が重要というのは誰にでも直感的に理解出来るので、リスク管理の必要性を押すことは他の既存組織との差別化が行え、設立の抵抗感、設立後の抵抗を抑えるのに極めて有効です。 ここで1．なぜ「PMO」を設立するのか？
4．既存組織との関係は整備されていますか？ 既に「PMO」が出来る前に品質保証部門、教育部門、経営企画部門、監査部門、技術部門、標準化部門がある企業は多く、新参者の「PMO」がこれらの既存組織と経営者の後押しなく戦うのは既存組織の自衛との戦いでもあり「PMO」が受け入れられない原因にもなります。既存の組織にはそれぞれ専門家も多く、真正面から組織編制を迫ることは社内的政治力学との戦いになり、発足に時間もかかれば、発足後の抵抗も大きく「PMO」の機能する時間が遅れることになります。 「PMO」の設立ではその目的によっては既存組織自体が評価の対象となるので、「PMO」が機能する制度の整理、組織の整理が不可欠であり、その整備の状況により「PMO」が出来る範囲は影響を受けます。古い大規模な企業では社内の制度が複雑であり、問題が発生した場合のトップへのエスカレーション方法が定まっており、新参物の「PMO」にその機会が与えられない場合があります。「PMO」は時により現場プロジェクトの進行を停止したり、受託を差し止めたりすることがありますので、トップへ短時間で独自にエスカレーションできる道を制度化する必要があります。またプロジェクトの状況の判定は「PMO」だけが出来ることも制度的に認知されている必要があります。その為には他部門主催の会議に出席し意見を述べるのではなく、「PMO」が主催する会議体を持ちその決定は経営トップの判断となるように制度化しておく必要があります。 5．「PMO」の人材はいますか？ 実は「PMO」の設立で最も難しいのは「PMO」でプロジェクトの状態を分析把握し、問題点を指摘し、改善を指導できる人材の確保です。(筆者は「PMO」には事務的作業も多く、分析、評価、指摘、指導を行う人員をASSESSORと呼び事務局員とは区別しています)企業内の「PMO」と言っても企業により求められる範囲が異なるが、エンドユーザーに近いソフトウェア開発会社ほど多面的な技術を求められる、その一部を専門分野毎に得意な企業に分割し発注することになるが発注元はハードウェアからソフトウェア開発までの全体俯瞰し詳細にモニタリングを行える技術力が必要で、そのような企業の「PMO」ではエンドユーザーの業務分析から本番稼動までの全工程の実務経験のある人材を揃えた「PMO」でないと全工程を評価することは出来ない。システム開発を行っている大手企業では全工程の実務経験のある人材が存在すると思われがちだが決して多くはなく、ある工程に関しては実務経験者が全くいない場合もある、全工程の実務経のあるプロジェクト・マネジャーも極端に少ないのが現実です。従って「PMO」が必要とする人材はよりすくなくなる。例えばプログラムが読める人材が「PMO」にいるといことも極めて少ない、なぜそこまで要求するかというと、最終成果物に問題がある場合、プログラミング経験がないと評価は出来ず、原因も対策も十分出来ないこととなるからです。「PMO」の設立ではトップダウンにて行うの良いとは言っても、ソフトウェア開発の最終成果物がプログラムであることを認識していない経営者が多く存在し、何か問題があった場合プログラミングとは何か、システム設計とはなにかを理解していないと、真の原因と適切な対応が出来ているのか理解できず、「原因はなんであれ何とかしろ」というとが現実に発生し、根本原因の究明、対応策が無い対処療法でトラブルが再発し経営問題となりTVでの弁明を見ているとお詫びにも何にもなっていないことは良く目にします。このようなことは経営者が自社の最終成果物がプログラムであることを理解していなからではないかとこと思ってしまいます。このようなことが起きない「PMO」を作るには優秀な人材の配置が必須であることを理解するには、経営者がシステム開発自身を深く理解している必要があることがお分かりいただけると思います。 「PMO」の人材ではなくプロジェクトの問題ですが、プロジェクト・マネジャーがシステム開発の実務経験、プログラミングの実務経験がないとスケジュールを作成する最、プログラミングの知識のある技術者の言うことを無評価に受け入れざるをえず、スケジュールの基本的部分は個々の技術者の直感に頼り、個人の良識だけを頼りにする時間帯の存在を許すことになる。その集合はやがて全体としてフィージビリテイのあるスケジューングを作成出来ないという結果を発生させてしまう。PMにシステム開発の実務経験がないと個々技術者の力量を評価出来ない、評価出来なければ個々の技術者は自己のスケジュールをいい加減に報告しても発見されないこと知っている、そのためスケジュールに緩急をつける必要のある場合、プロジェト・マネジャー指示に従わないという現象が発生し、そのようなプロジェクトでは常に遅れ勝ちとなってしまう。このようなことの無いようプロジェクトにおいてプロジェクト・マネジャーはプロジェクトガバナンス力を持っている必要がある。「PMO」はこのようなPMを支援、指導することになるので、PMより以上の経験を持たなければならず、現場はこのような重要な人員は希少性があり本部機構に供出しない傾向にある、第二戦級の人材で「PMO」を構成しても実際に機能しないこととなる。「PMO」は一時的に現場の力が削がれる位の人物を当てないと指導を受ける現場も受け入れない。このようなダイナミックな人材配置を可能にするのは会社経営者(社長)が音頭を取らないと可能とならないのはいずれの企業でも同じようです。「PMO」が成功している企業の多くは社長自らが先頭に立っている企業であり、中間の役付き役員が音頭を取っても社内の派閥、抵抗勢力により本来の機能を発揮しない例が多い。 6．ようやく「PMO」が設置できましたが？ 目的、人材、他部門との調整、制度改革も出来「PMO」が機能する環境は出来ました、それでも上手くいかない場合があります。 ここで、 1．なぜ「PMO」を設立するのか？
トラブルが多いから「PMO」を設置したのですから、当然「PMO」が出来た時はトラブルの真最中であるプロジェクトが複数存在しています。また「PMO」には優秀な人材を揃えてあります。トラブルによっては企業の屋台骨を揺るがすものもあるでしょう、となると「PMO」に誰々をレスキュウに出せという神の声が降ってきます、大事な人材がまたプロジェクトに取られてしまいます、トラブルは多いのですから次々に発生しては人材が取られてしまいます。このようにして折角作った「PMO」が機能しなくなる例が非常に多くあります。レスキュウは「PMO」の範囲外とし少数精鋭にし、一人抜いても「PMO」が成り立たないようにする必要があります。また神の声が降ってこないようにするにも「PMO」の長が社長であれば矛盾した声は降らなくなります。社長がどこまで我慢できるか、今の火事を消すのか、火事を起こさないようにするのか選択を迫れば、自らが「PMO」の推進者であれば予防を選ぶのは確かでしょう。「PMO」設立後一年はプロジェクトに人材をレスキュウで出さない我慢が大切です。 7．最後に「PMO」に「PMBOK」は必要ですか？ という奇妙な質問をたまに受けますが、何をプロジェクト・マネジメントの共通用語にして「PMO」を行うのですか？その企業ローカルな言葉で十分ならいいのですが、複数の企業と人材からなるプロジェクトでプロジェクト・マネジメントの用語を「PMBOK」が無くて話すのは時間を要して無駄ではありませんか？有効かどうかはそのプロジェクトによりことなりますが、話を早くするには有効ではありませんか？と質問には答えております。 「研修第二部会」は一人でも多くプロジェクト・マネジャー、「PMO」の人材を確保するためにも、より多くのPMP産むお手伝いをしております。 |
 |