システム開発に今こそPMOの活用を

昨今、ITエンジニアの能力・モチベーション低下に関する記事を見かけることが多い。例えば、日経コンピュータの『働く意識調査』では、「リーダー役としての活躍が期待される30代後半の士気がもっとも低い」（35～39歳の“やりがいを感じていない”という回答が30.4%で第一位）という結果が出ている（2006.12.25号）。これらは、ミドル層の弱体化を意味しており、実に由々しき事態である。

例えば今年度末で勤続10年となる人（32、3歳頃）は、1997年4月に入社している。1997年といえば、マイクロソフトがウィンドウズ95を発売し、ビジネスはもとより家庭においてもインターネットの利用が急速に普及してきた時期である。その後、オープン系システムはクライアント・サーバ系システムからウェブ系システムへ、また開発言語もC言語からJavaへと主流が交代していった。

このようなインターネットの普及や技術の進歩は、ミドル層の弱体化に大きく関わっている。ひとつは「構築期間の短期化による影響」である。クライアント・サーバ系システムまでの時代は、システムの直接的な利用者は企業・団体内の職員が大半であり、システム構築期間も1年を超すものも珍しくはなかった。しかし、その後のウェブ系システムの発展により、直接的な利用者はその企業・団体の顧客にまで広がっていった。企業・団体は顧客を自社のサイトにつなぎとめるために、常にシステムの操作性向上・機能強化等を継続的に行うようになり、その結果、案件毎のシステム構築期間が短期化していった。

もうひとつは「主要技術の短命化による影響」である。1980年代に至るメインフレーム全盛時代は、OS、開発言語、TPモニター、DBMS等のシステム基盤はほぼ固定的であり、新規プロジェクトといってもシステム基盤が大幅に変わるものは少なく、アプリケーション開発の大型案件というケースが多かった。したがってITエンジニアは、案件毎に固定的な環境で繰返し構築を経験することができた。しかも経験年数の経過とともに、小さな案件から大きな案件・重要な案件へと段階的に、である。よって、この時代を経て育ったリーダーは経験豊かで勘所が働くため、若手が失敗しそうな際には事前にチェックを促したり、失敗した場合でも自らリカバリーがきくことから、若手にチャレンジの機会を多く与えることができた。ところがオープン系システムの時代に入ると、技術革新のスピードが早くなり、数年間で大幅な機能向上を伴うバージョンアップが行われ、時には主要技術や製品までもが交代してしまう。極端な場合には、同じOS・開発言語・技術・製品での構築が、二度とないケースも見られるようになった。その結果、新技術・新製品によるプロジェクトを確実に、しかも短期間で成功させるには、若手に“失敗させる”ことは許されなくなってしまった。

さらに新技術・新製品によるプロジェクトでは、性能、バックアップ・リカバリー、認証・セキュリティ、監視・自動運用等のいわゆる非機能要件を新たに考えなければならない。ところが若手を指導する立場にある先輩エンジニアの中には、世代的に固定的システム基盤の上でアプリケーション開発を担当してきた人が多く、自身が非機能要件の定義・設計・開発経験が少ないために、若手が充分な指導を受けていない可能性が高い。その結果、WBS（Work Breakdown Structure：プロジェクト全体を細かい作業に分割した構成図）もシステム基盤や非機能要件に関する部分については充分分解できないこととなる。必然的に、製品を供給しているメーカー系ベンダーに頼りすぎることとなり、プロジェクト・マネージメントに問題が生じる可能性がある。

つまりミドル層はそれ以前の世代と比較すると、システム構築環境が激変し、また求められる知識や役割が増えたことから、充分な教育・訓練・経験を積みづらい環境に身を置いてきたと言えよう。プロジェクトを成功させ、その自信がモチベーション向上にもつながるよう、今後を担うミドル層への教育・支援が、今以上に求められている時期はない。

ただし、ミドル層が体得すべき知識・ノウハウを座学で習得するには限界があり、適切なサポートが不可欠である。まず考えられるのは、学ぶ機会を増やすことである。例えば、プロジェクト終了時のプロジェクト総括会やシステム障害対応完了時にトラブルの現象・原因・対処・再発防止策等の解説会を公開方式で開催する等して、関係者の感覚が“熱い”うちの体験談を聞き、擬似体験する。また現在若手の人には新入社員へのOJTを担当させる。これにより自分の知識・経験が棚卸され、得意・不得意分野や曖昧にしてきた知識を認識することで、自らが学ぶべきことが明確になる。特に新入社員の質問に答えられないと先輩の“メンツ”にかかわるので効果的である。

しかしながら、これだけでは充分とはいえない。プロジェクト・マネージメントや非機能要件の設計の方法論・ノウハウの伝授は一朝一夕に行えるものではない。そこで、PMO（Project Management Office）の活用を提案したい。PMOとは、「プロジェクトチーム」とは別の、当該プロジェクトが円滑に遂行されることを支援する専門部門である。PMOは個々のプロジェクトのモニタリングや監査を行い、会議体等で改善勧告や助言を行うことでプロジェクト・マネージャの支援を行う。この活動を通して、プロジェクト終了後には解散してしまうプロジェクトチームからノウハウを吸い上げ、プロジェクト・マネージメント手法・品質管理の体系化・標準化を行うことで、全社的なプロジェクト・マネージメントの能力・品質向上に寄与する。こうした役割の性格上、PMOは経営層が直轄する組織としている企業・団体が多い。

ここで重要なことは、PMOがプロジェクトの「外」から監査・牽制的立場で支援するのではなく、プロジェクト期間中、そのプロジェクトの「内」に深く関わる、つまりプロジェクト・マネージャ支援グループとして、システム稼動まで参画する、ということである。PMOはその役割上、ベテラン社員で構成されることが多い。技術的にはメインフレーム経験世代かもしれないが、システム基盤・非機能要件の設計に携わった者も多い。OSや開発言語こそ違うものの、チェック・ポイントには類似性がある。このようなPMOの存在は、若手のプロジェクト・マネージャにとっては心強いだろう。PMOがプロジェクトに参画し、支援グループとして活動することで、若いプロジェクト・マネージャのOJTを行うのである。

技術変化が急であるがゆえに、システム構築環境の変化もまた急である。それゆえ求められる人材の育成手法もまた、必然的に変化してこよう。これに柔軟に対応するしくみを整備できるかが、今後のITベンダーの競争力を大きく左右するであろう。