術語の定義によっては若干変わるだろうけど(自分でも明日書いたら違うものになると思う)、だいたい上図のように ①XML基礎技術、②サービス指向技術、③ワークフロー技術という3つの技術が交わる領域の、さらに一部分をBPEL が占めるような配置になるんじゃないだろうか。
で、BPEL にはそれ自体に関するスキル以前に前提となるような技術要素あり、それぞれ①~③の領域に含まれていて、上図では特に依存性が強いものについて水色のハイライトで示した。
図中、重なった部分での①~③の各領域は均等の重みではなくて、私見では以下のようなバランスになる。
- XML 基礎技術 → 5
- サービス指向技術 → 3
- ワークフロー技術 → 2
さらに、実際のプロジェクトでは標準仕様を独自に拡張した何らかの製品を使うので、この一層も含めて、今度は縦に切った形で図式化すると以下のようになる。
以上のようなイメージが、BPEL スキルの内訳とその依存関係、また BPEL 周りの周辺技術について自然に思い浮かぶものだと思う。まあ主観に違いないけれど、XML、SOA、ワークフローを体系的に勉強した経験があれば、細部を除いて概ね意見が一致する自明な認識ではなかろうか。
ところが、現実のプロジェクトで各種の残念な事情が重なると、これと全く違うイメージが形成されて、マネージメント層から業務エンジニア層・プログラマ層までプロジェクトチーム全体で共有されてしまう事がある(あるいは共有されているかのように振舞うことを強いられる)。
まだ上手くまとまらないが、列挙するとこんな感じ。
- プロジェクトで採用された特定ベンダの BPEL 実装を、BPELの全てだと思い込んでいる。
- 最初に示した図と内外を逆に、「BPEL」という大きなカテゴリに XSLTなどの基礎 XML 技術や、SOA や WSDL などの Webサービス技術が包含されていると思い込んでいる。
- 特定ベンダの BPEL ツール使用経験を見て、XML基礎技術、サービス指向技術、ワークフロー技術のスキルレベルまでも満たされているものと思い込んでしまう。
このように、スキル要素の捉え方が大幅に間違っていると、プロジェクトの運営に当たって至る所で(教育、人員調達、情報共有、etc.)問題が生じる事は、リーダ/マネージャ経験者ならすぐ想像がつくと思う。
後日、今回の記事をベースにもうちょっと敷衍してみたい。
0 件のコメント:
コメントを投稿