「要員調達」でミスをしないためのポイント

はじめに

今回も、PMBOKや情報処理試験のプロジェクトマネージャー試験ではなかなか触れられることのない内容についてお話しします。テーマは「要員調達」です。

IT業界全体の
レベル低下を招いたきっかけ

まだ鮮明に記憶されている方も結構いらっしゃると思いますが、遡ること約13年前の2009年にIT業界は大変な状況に陥りました。アメリカの大手証券会社リーマン・ブラザーズの破綻により世界中の経済が一気に不況へと落ち込み、その影響でIT業界も「なかなか希望した仕事が見つからない…」そんな時期がありました。

この問題は「リーマン・ショック」と呼ばれていますが、このリーマン・ショックはIT業界に甚大な後遺症をもたらしました。リーマン・ショックは、その2年後に発生した東日本大震災の影響もあり、現場として景気の回復を感じたのは2012年頃でした。ちょうどその頃、IT人材調達に関わったプロジェクトマネージャー達から、同じような言葉を聞くことが急増しました。

• コミュニケーションの取れる人材がいない
• 使える人材がいない

言い方は色々ありますが、この2つの言葉がITの現場で急激に増えてきたのです。特に顕著に現れたのは「技術者募集要項」です。会社によって呼び方などに差はあると思いますが、これは社内や社外のパートナー企業などから技術者を募る際に、募集するプロジェクトの概要や勤務条件、技術者に求めることなどを纏めた書類です。これらの資料の「技術者に求めること」の記載に

• コミュニケーション能力のある人
• 自分で考え、動ける人

この言葉だけを見ると、優秀な技術者が居なくなってしまい、ITに関わらず仕事の基本を弁えていない人しか存在しないように思えてしまいます。では、なぜこのような普通に考えれば「明示しなくても良さそうな条件」が技術者募集要項に書かれるようになったのでしょうか。その理由はいくつかありますが、特にインパクトが大きかったのは次の通りだと思います。

リーマン・ショックがもたらした
度を越えたコスト削減

リーマン・ショック後、景気が減速する中で、日本だけでなく世界中の企業が投資を極端に抑制しました。特に、当時はまだ「DX」の言葉も誕生していない時代で、ITは各企業の事業の根幹とは見られておらず、あくまでも「事業の効率化などを補助するためのもの」という考えが主流だったので、投資の抑制は凄まじいものでした。

さらにはITへの投資だけでなく、既に稼働しているITシステムの保守業務にかけるコストも極限まで削る要求も行われました。それまで複数人で行っていた業務を1名に集約したり、ツールなどを内製して要員の手作業を減らしたりなど、当時の中堅層(現在の40代中盤～50代くらいまでの層)と呼ばれる世代を中心に涙ぐましい努力を重ねました。しかし、残酷なことに、そういった人材削減と効率化の餌食になったのは比較的人件費コストが高い中堅層でした。何とか少ない予算で、経験が少ない要員でもシステムを保守・開発できるように工夫した結果、自分達が不要とされてしまったのです。

会社から不要と言われ、転職先を探そうにも、どの企業も同じような状態です。その結果、当時の中堅層が大量にIT業界を去ってしまったのです。ところが、全ての業務がツール化やマニュアル化されていたわけではありません。要員調達や調達した要員に上手く仕事を遂行してもらうためのノウハウは置き去りにされていたのです。

その結果、技術者募集要項などを作って社内やパートナー企業から技術者を募ろうとしても、上手く人材を確保できなかったり、せっかく確保した人材に上手く業務を遂行してもらえなかったり、プロジェクト運営の一部が上手く行かない状況が頻発するようになったのです。この問題を改善しようとした際に、プロジェクトマネージャー目線では自分に問題があるわけではなく、あくまで募集する技術者側に問題があるように見えてしまい、「明示しなくても良さそうな条件」を技術者募集要項に記載するような事態になったのです。

以前のプロジェクトマネージャーは
どうしていたのか

そもそも、技術者が思い描く「コミュニケーション能力のある人」「自分で考え、動ける人」を完璧に満たす人などいるのでしょうか。募集する側は「自分の意図通りに情報を連携できて、その情報も全てインプットせずとも何とかできる人が欲しい」と考えているのでしょうが、そんな人は滅多にいません。ましてや、募集するプロジェクトマネージャーによっても、その基準は異なるわけですから、あの短い文章だけで期待通りの人が見つかるなんて、偶然が重ならない限り滅多にないのです。リーマン・ショック前は上手く行っていたことが、リーマン・ショック後に上手く行かなくなる。そのポイントは何なのでしょうか。

答えは、第3回で解説した「のりしろ」の話に近くなりますが、「事前準備」と「丁寧なコミュニケーション」です。そして、それは技術者だけではなく、社内であれば要員調整の権限のある立場の人や、パートナー企業であれば要員調達の窓口となる営業担当などにも必要になるのです。

プロジェクトは、よほどのことがない限り、要員調達が必要になる数か月前から計画が動き出します。中～大規模なプロジェクトでは年単位で事前準備をすることもあります。そういった準備期間から、社内の要員調整権限がある人やパートナー企業の営業担当などと定期的にコミュニケーションを取り、「いつ位のタイミングで」「どれ位のプロジェクトで」「どんな技術を使うことになりそうで」「最大で何人位の要員を追加調達する必要があるか」などの情報を共有しておくのです。

また、スムーズに情報共有できる関係を作るために、飲み会やゴルフ、共通の趣味の場を利用することもあります。最近では「飲み会なんて何の役にも立たない」「ゴルフは仕事なんて言っているけど、結局会社のお金で遊びたいだけでしょ」などと否定する声が増加していますが、一緒に食事の時間を共有したり、1日一緒にいて苦楽を共にしたりすることで、お互いの距離は非常に縮まります。最近は特に肩身の狭い思いをしているタバコ仲間も同じようなものです。

現場での技術者とのコミュニケーションも同じです。プロジェクト計画を書き、設計ルールやコーディングルールを決めて手順まで整備しているのに、技術者が思った動きをしてくれない…とか、RACIチャートを提示しているのに「ここまで自分の役割だと思っていなかった」など言いわけをされる…など「PMBOKに従ってやるべきことをやっているのに技術者が付いて来てくれない」と嘆く声はよく耳にしますが、作成したドキュメントを使用して技術者とのコミュニケーションが取れていないことが非常に多く感じます。

例えば、設計書を作成する工程では、プロジェクト計画書にある体制図やRACIチャートを使って「誰が何をインプットに設計書を作り」「誰が何をインプットにレビューをし」「全部で何段階のレビューを経て完成するのか」や、プログラミングを行う工程では「コーディングルールに書かれている個別ルールが、実際のプログラムでは具体的にどういった実装箇所として現れるのか」など、計画段階や工程の前段階までに準備した情報を具体的にどのように、どのレベルで運用したいのかを技術者と意思統一しておかなければなりません。

ところが、「そんなことは、自分で資料を読んで理解しておくべき」「細かい話はプロジェクトマネージャーでなく、サブリーダークラスがすれば良い」などと考え、積極的に意思統一を行わないプロジェクトマネージャーが多いのです。生まれた時期も場所も、育った環境も経験も異なる人達が集まって遂行するのがプロジェクトです。「分かってくれて当たり前、知っていて当たり前」ではなく「知っているかも知れないけれど、分かっているかも知れないけれど、念のため認識合わせ、意識合わせをさせてください」というプロジェクトマネージャー側からのアプローチが重要になるのです。

おわりに

今回は要員調達でミスをしないためのポイントについて解説しました。次回は、仕事でもプライベートでもよく使われる「リスク」について、リスクとは何なのか、リスクとどのように付き合っていくものなのかを解説します。