 |
第２１回（2004.05.13） プロジェクトロール |
ロールについて考える ◆ロールとは プロジェクトの中ではさまざまな作業があり、それを実行するために、異なるスキルが要求される。要件定義、業務分析アーキテクチャー設計、機能設計、プログラム設計、開発、テスト、運用、保守、マネジメントなどである。さらにこの中が細分化されることもあり、テストであれば、単体テスト、結合テスト、システムテスト、受け入れテストと細分化されることが多い。 プロジェクトの規模が大きい場合には、それぞれの作業に対して１人以上の要員を割り当て、その要員は他の作業には関与しないのが普通だ。しかし、プロジェクトの規模が小さい場合には、一人一人のメンバーが複数の作業を担当することも珍しくない。この場合には、一人のメンバーが複数のスキルを持たなくてはならない。 このような場合、要員と作業は分けて考えておかないと混乱する。例えば、計画では、Ａさんは機能設計だけの担当であったが、プログラム設計のスケジュール遅れにより、プログラム設計も担当するといったことがありうるからだ。 つまり、要員計画では、それぞれの要員にプロジェクトの中で一つ以上の役割を与える。この役割のことをロールという。 ロールはプロジェクトの中で極めて大切な役割を果たす。それは、開発方法論とプロジェクトマネジメントの接点となることだ。 要員の計画に限らない。例えば、コミュニケーションの計画、リスクの計画などを策定する際にも、ロールは基本単位となる。コミュニケーションの計画を例にとれば、ミーティングの召集は人ではなく、ロールで行われることが多い。 ◆ロールの例 基本的にロールというのはどのように設定してもかまわない。プロセスやプロジェクトのフェーズに応じて設定されることが多い。 では、プロジェクトでよく使われるロールにはどういったものがあるのだろうか？ガイドは以下の５つのロールは必ず設定することにしている。 プロジェクトマネージャー コンサルタント（ビジネスアナリスト） アーキテクト（技術リーダー） ディベロップメントエンジニア（プログラマ） システム管理者 の５つはまず、大方の企業で設定のあるロールだろう。ただし、ロールの名称は違うかもしれないので、それぞれ、どういうロールかをコメントをしておく。 プロジェクトマネージャーはプロジェクトの運営・管理をするためのロールである。プロジェクトチームの管理と指導に対する責任を持ち、スケジュールと作業分担を計画し、計画通りに進んでいることをレビューするロールである。 コンサルタント、あるいはビジネスアナリストは上流工程で、ユーザの抱える問題の分析をし、その問題解決方法をプロジェクトチームに与える役割をするロールである。 アーキテクトは技術リーダーとして、技術ソリューションを与え、ソリューションモジュールの論理的、物理的構造（アーキテクチャー、あるいはレイアウト）を開発するロールである。 ディペロップメントエンジニアはいわゆるプログラマである。 システム管理者はプロジェクトで利用するシステムやデータベース、ネットワークなどのインストールと維持管理を行うロールである。 これ以外に、共通的なロールとしては、最近ではセキュリティスペシャリストというロールが設定することが多い。プロジェクトのセキュリティポリシーを策定し、それを実現する責任を負うロールである。 これらのロールはガイドに限らず、多くの企業で似たような設定をしているケースが多い。いわば、ＩＴプロジェクトである限り、基本となるロールであろう。そして、その上で、 ・ソフトウエアプロセスの種類（例えば、ウォーターフローか、アジャイルか） ・アプリケーションの種類（例えば、基幹系か、Ｗｅｂ系か） ・適用技術の種類（例えば、ＤＢ系か、Ｗｅｂサービスか） などに応じて特別なロールを準備しているケースが多い。 特別なロールは、多くは企業により異なる。 ◆ロールとスキル さて、もう一度、基本的なロールに話を戻そう。上に述べたように企業により呼称の違いこそあれ、似たようなロールを使っているケースが多い。しかし、要員の調達を行おうとすると、意外と問題が起こる。問題は大きく分けると３つある。 最初は、同じ呼称のロールの意味するスキルの違いである。同じアーキテクトというロールをＡ社とＢ社で設定していた場合、そのロールが持つスキルが異なることがある。人材像としては似たようなイメージなのだが、微妙にスキルが異なる。この微妙な違いがプロジェクトでは致命傷になるケースがある。当然、できると思っていたことができないのだ。再度、調達すれば、その分、スケジュール的なロスになる。 二番目は、スキルのレベルの違いである。従来、スキルレベルの表現方法がなかった。せいぜい、経験年数や保有資格くらいしかなかったのだ。しかし、経験年数の場合、同じ経験年数でも人によりスキルは全然異なる。また、資格もストレートにスキルを反映するものではない（そういう資格もある。例えば、プロジェクトマネージャー系の資格でいえば、ＰＭＰはスキルを反映しているが、経済産業省のプロジェクトマネージャー資格はスキルと食い違うケースが多い）。 もう一つは、同じスキルなのだが、流儀が異なるというケースがある。その典型がプロジェクトマネージャーというロールである。プロジェクトマネージャーに関していえば、スキルの違いというのは少ない。プロジェクトをマネジメントするにはやらなくてはならないことは自明だからだ。ところが、やり方が違うケースは非常に多い。すると、メンバーと対立することになり、プロジェクトは汲々として進まないということになる。 当然、これらのロールにまつわる問題は避けられるべきである。まず、最初のスキルについては、ＩＴＳＳがその突破口になるだろう。ＩＴＳＳでは、職種の標準スキルというのを定義している（職種共通スキル）。さらに、職種の中に専門分野を設けており、専門分野ごとに標準スキルを定義している（専門分野固有スキル）。この枠組みを利用し、自社のロールを表現する。例えば、 当社のプロジェクトマネージャーというロールは、ＩＴＳＳプロジェクトマネジメントのシステムインテグレーションのスキルと、コンサルタントのパッケージ適用のスキルを持っていること という風に定義できる。さらに、この定義に、ＩＴＳＳのレベルを入れれば、レベルの問題も解消する。 残る問題は、流儀である。流儀の問題は技術標準、標準プロセスなどを採用するしかないだろう。ただし、必ず、標準があるかというとそうとは限らない。例えば、セールスやマーケティングの標準プロセスはこの先もなかなかできないだろう。この部分は本来、規定できるような性格のものではなく、むしろ、マネジメントの問題として異質なものを如何に活用していくかという観点で捉えるべきであろう。 |
|
| スポンサードリンク | |
| 読者からのコメント | |
■本稿に対するご意見，ご感想をお聞かせください．■ ■は必須入力です |
|
| このコンテンツは「プロジェクトマネージャー養成マガジン」としてメルマガで配信されています．メルマガの登録はこちらからできます． | |