BPEL 要員の集め方

前のポストで BPEL スキルについてあれこれ考えて、こんな図を描いてみた。
これをベースに要員調達について、特にどんなスキル・キーワードを条件として用いるべきか考えてみる。ポイントは以下のようになる。

• 上図、また前ポストで示したように、BPEL技術は階層を成したXML技術構造のやや上層に位置し、XML×SOA×ワークフローが交叉する複合的な技術でもある。この特性をどう扱うか。
• そもそもBPEL 技術者は絶対数が少ないが、これにどう対処するか。

■ 駄目な集め方
多分、こんな感じだと上手くいかない。

必須スキル：○○社BPEL製品

調達担当者は、「○○社BPEL製品経験者」ならば、当該製品のノウハウはもちろん BPEL標準仕様からXML・SOAの基盤技術まで一通りマスターしているだろうと考えて、下図のようなスキル分布を期待する。（調達担当者が要素技術について多少なりと理解しているという想定。やや楽観的だが。）
ところが現実の応募してくる人のスキル分布は、こんなふうになる。

畢竟、ただただ言われるままに、IDE上のグラフィカルなエディタを何十時間かいじってきただけの経験だと、どこまでが現場のローカルルールで、どこからがツールの仕様で、どの辺りが標準仕様なのか全く未分化なままだし、それを自覚することもないから、応用というものが全くきかない。XMLソースを普通に読み書きするだけの事を、異様に恐れたりするレベルの人。

で、普通なら正味のスキルを面談時に精査して、合格レベルに満たないなら次の応募者に期待という事になるが、そもそも BPEL技術者の絶対数が少ない上に、さらに「△△社」で絞っているものだから、「選ぶ」なんて贅沢な余裕が生じる程、応募者は来てくれない。

こんな応募条件を出すくらいだから調達者側のレベルからして推して知るべしで、面談で正しくスキルチェックができるほどの技量もない。従って、結局は職務経歴書に記載の「△△社BPEL製品」という記号の有無だけで採用が決まり、面談は形式的な挨拶程度ということになりがち。

■ マシな集め方
改善するとこうなる

必須のスキル
　・XMLスキル（XSLT、XPath、XML Schema）
　・SOA、Webサービス
望ましいスキル
　・BPEL (○○社製品ならば尚可)
　・その他ワークフロー技術

とりあえず、応募者がいないと比較も選別もできないから、思い切って該当者の少ない BPEL経験は必須から外してしまう。それに替えて XML／Webサービスのスキルを必須とし、高スキル技術者を募る。XML／Webサービス技術者も中～高レベルのとなるとそう多くはないが、それでも同等レベルの BPEL技術者よりは、はるかに流通している。

下図のような技術者を期待して待ち、首尾良けば、複数の候補者からベストな数名を採用してチームに組み入れる事になる。
もちろん BPEL 標準および△△社のツール／プラットフォームについての学習工数が発生する事にはなるが、基礎スキルが充実していれば採用者側が心配するほどには時間も労力も掛からない。

また上述の駄目な例として挙げたような特定ベンダーの条件を外すことで、下図のような技術者にも門戸を開くことになる。

このタイプの BPEL 技術者なら、作業開始の要点とローカルルールについて簡単にレクチャーし、座席を適切に配置しておけば、業務要件の把握していく作業のついでに自然と習得できてしまう。

むしろ、XML 良く知ってる人が BPEL や 特定ツールを習得するための工数について、募集側が過度に多く見積もっている場合、プロセスを BPEL で書くという作業を募集側自身が良く理解していない可能性がある。

つまるところ「XMLで定義・公開され、XMLをやり取りするサービスを、XMLで記述したプロセスで動かす。」という事に尽きるわけで、必要なスキルがどんなものなのか簡単に分かりそうなものだが、実際の現場はそうじゃなかったりする。

■ 応募者側からの見方
ここまで募集する側の視点で書いたけど、逆に応募する側、BPEL技術者の視点から言うと、「BPEL経験」だとか「○○社BPEL製品」なんて必須指定がある案件は、募集側の見識を疑ってかかる事もできる。

特に、そういった選択肢を過度に狭め得る条件を必須にしておきながら、そのくせ「急募」だったり「稼働時間高」なんて場合は、プロジェクト自体も採用側の思考も、とっくに破綻していると考えてまず間違いない。

まあ不景気だし、金に困っている場合などは、タコ部屋かマグロ漁船に飛び込む気持ちで、敢えて短期間やってみるって選択もありかもしらんが。