「本プロジェクトには（業務部門の）エース級人材の投入をお願いします」――
システム開発プロジェクトの提案書におなじみのフレーズだ。この言葉の裏には、発注者である事業会社側（以下「顧客」と表す）とITベンダー（以下「ベンダー」と表す）、双方にとってのわなが見え隠れする。
控えめに言っても要注意なフレーズだ。では、どこをどう注意すればよいのか。今回はこの問題をひもといていく。
そもそも現場は「エース級」人材を手放したがらない
よほど業務の改革や改善に意欲的な組織は別として、現場である業務部門は自部門の「エース級」人材をシステム開発プロジェクトにアサインしたがらない。
例えば営業活動をITシステムに乗せ換える（あるいは既にIT化された営業システムを刷新する）プロジェクトがあるとしよう。この場合、営業部門が業務部門になる。果たして営業部門は、前線でバリバリと数字を出しているエース級の担当者をシステム開発プロジェクトに放出したいと思うだろうか？
営業部長の多くは「困る」「勘弁してくれ」と答えるであろう。
こうしてエース級ではない人材がアサインされる。いや、別にエース級でなくても構わない。業務を正しく理解し（あるいは理解しようと努力し）、コミュニケーション能力や調整能力にたけ、上長や現場のメンバーと合意形成しながら物事を進められる人であれば大丈夫だろう。しかしながら、そのような人材もまたなかなかアサインされない。結果、業務を分かっていない、コミュニケーション能力も調整能力もいまいちな人のもとにプロジェクトを進めることになる。
まれに現場がエース級人材を渋々アサインしてくれるケースもある。ただし多くの場合、「部分参画なら」のような条件が付く。
部分参画。この条件もなかなかくせ者である。「週2日以内」「1日2時間以内」など定義してマネジメントできればまだよい。しかし、いざプロジェクトが始まってみると……
- ・現場の忙しさへの対処が優先され、エース級人材がプロジェクトミーティングに出席してくれない／ドタキャンが相次ぐ
- ・部分参画だったはずが、いつのまにかフルタイムでプロジェクトに拘束される。業務部門との関係がギクシャクする
こうしてプロジェクトは頓挫する。あるいは「見切り発車」でプロジェクトが進んでしまい、後になって火を噴く。
エース級人材の過信は危険！
幸先よくエース級人材がアサインされたとしよう。しかし手放しで喜んではいられない。エース級人材への過信は禁物である。以下、筆者が実際にシステム開発プロジェクトの現場で経験したエース級人材のわなを紹介する。
（1）自分の仕事やプロセスを言語化するのが苦手
エース級の人材が、必ずしも仕事や業務プロセスを説明することにたけているとは限らない。業務のプロである一方、「属人化のプロ」でもあるケースが少なくない。トップセールスの営業担当者であれば、「野生の勘」や「過去の経験値」「本人の感覚」など、属人的な知識やスキルで勝ってきたという具合だ。
プロスポーツの世界のスーパープレーヤーを想像してみると分かりやすい。彼ら／彼女らは、自分たちの勝ちパターンを言語化できているとは限らない。自分が成果を上げることと、その成功法則を他人に説明することでは全く別のスキルが要求される。
エース級人材は言語化が苦手。このくらいに考えておいたほうがよいかもしれない。
「それから」「そういえば」「言われてみればこのパターンも」――このように、次から次に（あるいは後になって）新たな業務プロセスやイレギュラーなパターンを聞かされることもある。自分の頭の中で、プロセスを俯瞰（ふかん）および体系化できていないのだ。
