叡智の三猿

〜森羅万象を情報セキュリティで捉える

当サイトは、アフィリエイト広告を使用しています。

スペシャリストとジェネラリスト

長くITエンジニアをやっていると、いくつもの開発プロジェクトに関わってきます。それを正確にカウントしたわけでは無いのですが、大小含めて、20あまりのプロジェクトに関わってきたと思います。

自分が関わってリリースしたシステムには我が子のような愛着があります。システムの稼働後、トラブルが相次ぎ、改修に改修を重ねたシステムもありますが、そんな悪童のようなシステムを含め、愛おしかったりします。

わたしはシステムの要件定義段階から本番移行後もプロジェクトに関わるケースが多かったことから、愛着がより強いんだと思います。

開発プロジェクトのイメージ(ウォーターフォールモデル)

ITエンジニアというと専門職のイメージが強いと思いますが、実際はスペシャリストとジェネラリストとが混在しています。

スぺシャリストは、特定分野の知見が高く、その分野の資格や技術を持つ人です。マルチな分野での知見を持つエンジニアをフルスタッフエンジニアと呼んだりしてます。若きエンジニアで、「フルスタッフエンジニアを目指したい」という願望を持っている人も多いと思います。

ジェネラリストは、広範囲に渡る知識や経験を持つ人です。開発プロジェクトや運用業務の全体を見渡し、適切なリソース配分ができることが重要です。プロジェクトのなかで、コミュニケーションを重視し、システムの利用者と開発者のギャップを埋める役割を果たします。

下図はERP(Enterprise Resources Planning)の導入プロジェクトをイメージした体制図の例です。このなかで計画系、実行系、分析系、インフラ系にアサインされるエンジニアは、それぞれの分野でのスぺシャリストといえるでしょう。一方、プロジェクトマネジャーやPMO(Project Management Office)は、全体を客観的に見る役割ですので、ジェネラリストといえます。ちなみに、PMOはプロジェクトマネジメント業務の支援を行いながら、プロジェクトで発生する各種調整や管理業務をそつなくこなすことが求められます。

ERP導入プロジェクト体制の例

プロジェクト活動のなかで、スペシャリストとジェネラリストの関心は異なります。両者は価値基準が違うともいえます。

スペシャリストは、自分の専門分野で新しい技術が採用され、それを自分で作ることが出来ればより情熱的になります。反面、レガシーな技術が使われ、仕事をしても自分の能力の向上にあまり役に立たないと判断したら、やる気を失う可能性もあります。さらにそのような仕事での工数が増したら、なおさらです。

プロジェクト活動を進めるなかで、メンバーの入れ替えはよくあるのですが、その背景にはやる気を失ったエンジニアがプロジェクトからの離脱を訴えることもよくあります。特に外部(SESや人材派遣)から調達したエンジニアは、期間契約単位(3ヵ月が多いです)で動くので、期間を終えたら離脱を止めるのも難しいのが実態です。

プロジェクトマネジャーに象徴されるジェネラリストのあたまのなかは、新しい技術の重要性は理解しつつも、それより重視するのは、プロジェクトを計画通りに進めて、利用者に納期通りに届けることです。単に届ければいいという訳ではありません。プロジェクトの予算内におさめることも重要です。そのためには、プロジェクト活動の中で、遅延につながる要因を徹底的に排除して優先順位を決めます。もし、やる気を失ったエンジニアがいれば、即座に人材の入れ替えを決断します。

一般的にプロジェクトの開発規模が増すと、生産性は低下します。それによって開発工数が加速度的に増えます(下図)。規模の大きなシステムは個々のプログラムの関係性が複雑化し、他システムとの連携も発生します。そのなかでインタフェース開発の調整業務に工数を取られます。それによって、プロジェクトマネジメントが重視されます。プロジェクトマネジャーやPMOは、コスパ第一のプロジェクト運営に思考が向かっていくのです。

開発規模と開発工数の関係