 |
|
プロジェクト・マネジャーはSEを兼務出来ない 葉山 博昭：8月号
システム開発業界ではプロジェクト・マネジャーがSEを兼務すると危険であると一般的にも言われるようになってきたが、筆者が行っているPMOの設立、運営のコンサル ティングを通して、実際にはまだ存在する例があった。又プロジェクト・マネジャーがSEを兼ねてはいけないということからくるシステム開発のプロジェクト・マネジャーの持つべき資質に対する誤解がある例にも遭遇した。 今回複数のプロジェクトでの体験を複合してプロジェクト・マネジャーがSEを兼務する危険性と、プロジェクト・マネジャーに求められる資質に関する私見を纏めたが、特定プロジェクトでの出来事を指しているものではありません。 【プロジェクト・マネジャーがSEを兼務して失敗した例】 『具体的には基本設計が遅れるという事態が発生してしまった』 (対応)
『原因』 『原因1：プロジェクト・マネジメントに当たる人員がSEとしての作業に忙殺されプロジェクト・マネジメントが出来なかった』 筆者はトラブルの発生したプロジェクトの上位のプログラム・チームの一員でもあり、PMOでの経験もあり、プロジェクトを冷静に見てトラブルの予兆からプロジェクト・マネメントの不具合を指摘出来るつもりであった。しかしトラブルの発生したプロジェクトでは、筆者のプログラムへの参入目的が成果物の品質向上であり、プログラムの下位のプロジェクトのマネジメトに直接携われない限定的立場であったためトラブルの防止に貢献出来なかった。立場上、要件定義書、基本設計書の内容の業務レベルのかなり深いSE的な評価作業に追われた。 またプロジェクト・マネジャーも(旧来のプロジェクト・リーダーに近いが)業務面の把握というSE作業に徹夜の連続で忙殺され、全体アーキテクチャー、プロジェクト・マネジャーとしての視点でプロジェクトを見ることが出来なかった。問題点を早く分かっていた人物もいたが、プロジェクト・マネジャーは徹夜の連続でアドバイスを受け入れられる状態ではなく、アドバイスを躊躇しているうちに、是正の指摘を上層部にエスカレーションを行うことが遅れてしまった。かなり状態が悪くなってからプログラム・マネジャーの上司に複数のルートからエスカレーションが行われ、対応を行った結果納期遅れにつながる最悪の事態は免れた。 時間的余裕が極度に不足するとSE的業務に忙殺され、PMとしての知識をもっていても生かすことが出来ないことを自ら体験することとなった。 『原因2：プロジェクト内部者だけでは対応が遅れる』 このプロジェクトでは開発側のPMOは存在せずプロジェクト、プログラム外の冷静な評価を受けることが出来ず、又エスカレーションルートが通常のラインのみで問題点の本質的把握、対応に遅れを生じた。 『原因3：アーキテクチャー設計能力の不足』 前述のプロジェクトだけの例ではないが、最近のシステム開発では業務内容が高度で複雑化しており、また顧客のレベルもPCの扱いに慣れており要望が高度且つ緻密で開発側が振り回される。もちろん顧客に振り回されないように顧客を導くのもプロジェクト・マネジャーの重要な役割だが、開発側に何らかの弱点を持っていると流れに抗するのも難しい。またWeb系ソフトでの開発技術の教育、指導がなされておらず、アーキテクチャーを設計出来ないまま個別機能を設計してしまう例は多い。特に制御系の開発経験の無いアプリケーション(ビジネスソフト系)・システムのみを開発してきた技術者にはアーキテクチャーを設計するという感覚が乏しく、画面と画面遷移まで決めると設計は終わりとする傾向があり、トラブル発生の原因ともなった。 『原因3：プロジェクト・マネジャーの資質に偏りがあった』 トラブルの発生したプロジェクトのプロジェクト・マネジャー固有の問題と思われるが、業務の設計に時間を取られたことは、技術、人員調達面に対する関心が薄くそのバランスを取るのがプロジェクト・マネジャーの重要な役割との認識が薄かったこともあり、トラブルを大きくした原因ともなった。 【システム開発プロジェクトのプロジェクト・マネジャーの資質】 『プロジェクト・マネジャーに求められる重要な資質』 プロジェクト・マネジャーは業務、技術には深入りせずプロジェクト・マネジメント事項のみを行うというプロジェクト・マネジャーに時々遭遇するが、筆者の経験からするとシステム開発のプロジェクト・マネジメントを行うには業務、技術に関してかなり高いレベルの知識が必要と思われる。プロジェクト・マネジャー一人で全ての分野のリーダーシップを取ることは現実としては難しいので、専門的スタッフをプロジェクト内に配置するか、バックヤードから支援の約束を取り付けることが現実的だろうと思われる。 システム開発のプロジェクト・マネジャーには知っていなければならない業務知識と技術知識のレベルがある、どのレベルまで分かるかはそのプロジェクト・マネジャーの能力に依存してしまうが、プロジェクト・メンバーのプロジェクト・マネジャーに対する視線で、業務、技術、人間的に信頼されているかプロジェクト・マネジャー自ら気がつくものである、気がつかないようなプロジェクト・マネジャーは業務、技術に興味を持たないプロジェクト・マネジャーと同様にプロジェクト・マネジャー失格である。 対象業務・技術に耐えるプロジェクト・メンバーの選択はプロジェクト・マネジャーが責任を持って行うことで誰に譲ることも出来ない。たまに上司に人員の選択を委ねてしまうプロジェクト・マネジャーがいるが、業務、技術の特性を知り、どのような技術者でないとシステムが完成しないかはプロジェクト・マネジャー自身が最も良く理解しているはずで、上司に人選を委ねるなどという他人事のように物事を捉えていてはプロジェクトの成功はおぼつかない。 【PMOとしてプロジェクト・マネジャーに求める資質】 プロジェクト・マネジャーはSEを兼務しないほうが良いということから、プロジェクト・マネジャーが備えているべき資質に誤解出を生じていると思われることによく遭遇する。筆者はシステム開発におけるプロジェクトの外にあるPMOとして、プロジェクト・マネジャーに対して、開発するシステムの顧客の業務の理解度、システムを実現する技術的方策の理解度、人員の調達度合いの三点を特に重要な評価点としてきた。 顧客の業務の理解度とは、開発するシステムの対象とする業務知識、例えば同じ金融関係でも証券、銀行、生損保なのか、その中で証券であれば株債投(株式、債券、投信の略だが、こういう略語で業務の会話を行うところが業務知識面の難しいところなのだが？)のいずれなのか、その中でも注文、約定、証券管理、信用取引、先物取引、財務・・・なのか？等業務知識は止めどもなく深く、それら業務知識が顧客側と噛み合っているのかが非常に重要になる。PMOではプロジェクトの指導的立場にいる技術者、特にプロジェクト・マネジャー自身がこれら業務の専門知識を有しているのか、顧客との交渉能力に影響するので、重要な評価点としている。 システムを実現する技術的方策に関しては、近年WEB関係のシステムを構築するソフトウェアはサンマイクロ社のVM系JAVA、マイクロソフト社のASP.NET等のように移り変わりが激しい、又種々の開発ツールの出現、顧客の画面インターフェースへの細かな注文により、業務内容と技術知識の統合は極めて複雑なものになっており、業務内容と言語、開発ツール、DB、クライント、サーバー、既存システムとの接続、外部との接続、運用性に影響するアーキテクチャーの設計がより重要になっている。プロジェクト・マネジャー自身が技術的知識をもってプロジェクト・メンバーとコミュニケーションを取ることができているのかも重要な評価点としている。 人員の調達度合いに関しては、システムが完成するかどうかは未だ技術者個々の持っている能力に圧倒的に依存してしまっているので、対象プロジェクトに相応しい人材を確保できているのか、プロジェクト・マネジャーに人材調達能力があるか、出身母体の企業への影響力があるか、協力企業に対する調達能力があるか、人材調達にプロジェクト・マネジャーの上司(機能部門の上級管理職)が協力的であるのかという点をPMOとして評価することとし、プロジェクト・マネジャーに調達能力が不足している場合は、PMOがステークホルダー間の橋渡しを行うことも考慮している。 PMOでは顧客業務の理解度とシステムを実現する技術的方策に対する知識のバランス、又専門的知識を有した技術者の確保が出来ているかを総合的に評価することとしている。 【最後に】
|
 |