現在、ＩＴ業界でホットなポジションといえば、「ＩＴアーキテクト」です。 技術の専門家として、基本的にはプロジェクト設計～納品までに携わります。
この「ＩＴアーキテクト」は企業によって役割が異なるようです。
- 「ＩＴアーキテクト」の部門が独立していて、受注の段階からの参加する
- 「ＩＴアーキテクト」の部門が独立しているが、受注後にＰＪのサポートのように関わる
- 運用チームに属しており、運用前提でＰＪに参加する
最近では、コンサルティングファームでも、ＩＴアーキテクトの求人が活発になっております。国内系の大手システムインテグレターでも、「基盤チーム」といった部門を設立し対応しているようです。
更には、大手のパッケージベンダーでも、ＩＴアーキテクトの部門を設立し、色んなお客様への導入に対応しています。
では、なぜ「ＩＴアーキテクト」が注目され始めたのでしょうか？
それは、ＩＴ企業のお客様であるユーザー企業（事業会社）に原因が求められます。これまで、事業部ごとにシステムを導入し、つぎはぎでシステムを構築していました（もちろん、ＩＴ企業もそれを支援していました。）
その後、「システムを統合し、情報を一元管理する」というコンセプトが中心になり、ＥＲＰパッケージ等が出現しました。
そういった中、これまで無計画にシステム構築してきた「ツケ」が回ってきたのです。システムを統合しようとして、稼動しないといったトラブルが続出したのです。
そこで登場したのが、アプリケーションはもとより、システム基盤にも詳しいエンジニアの存在でした。これまで、表に出るというより、バックでサポートするイメージが強かったのですが、積極的にお客様の前に出るようになったのです。
更にユーザー企業には「業界の再編」という波が襲い、「吸収・合併」が盛んになりました。
企業が統合されれば、当然、システムも統合します。そして、上記のようなトラブルが更に続出していきます。このような流れの中で、ＩＴ企業としては、システムの統合などのノウハウを自社内に蓄える必要性が出てきたのです。
そこで生まれてきたのが、「ＩＴアーキテクト」というポジションなのです。
まだまだ、システムの統合のニーズはあります。
ますます、「ＩＴアーキテクト」のポジションは注目されるでしょう。
＜大外一気＞