PR：時代に取り残されないERPエンジニアになるには？

企業改革の手段としてERPが登場してから10年以上が経過した。この10年間で、企業の経営課題とITソリューションは大きく変化した。それに伴いERPの製品体系や技術、ERPエンジニアに求められる役割も変わってきた。時代に取り残されないERPエンジニアになるための方法を探る。

ERPブームから10年、市場はどう変化したか

　いまから10年以上前、構造不況に悩む日本企業の救世主となったITソリューションがある。それがERP（Enterprise Resource Planning）パッケージだ。ERPパッケージは、会計、販売、生産管理、人事と業務ごとに分かれていたシステムを統合し、共通のデータベースを持つことで、情報のリアルタイム共有や業務プロセスの効率化を図る画期的なシステムとして登場した。ERPパッケージに実装された業務プロセスに合わせ、自社の業務プロセスを見直すフィット・アンド・ギャップ分析も、業務改革手法の1つとしてさまざまな企業に採用された。この市場を切り開いたERPベンダの1つがSAPジャパンである。

アビームコンサルティングプリンシパルプロセス＆テクノロジー事業部 SCMセクターリーダー
公認会計士鈴木章夫氏

　SAPのERPパッケージ、「SAP R/3」（以下、R/3）が市場に浸透した背景について、アビームコンサルティングプリンシパルであり、プロセス＆テクノロジー事業部 SCMセクターリーダー鈴木章夫氏（公認会計士）は次のように語る。「そもそもERPパッケージは、業種を問わず、会計・販売・生産・人事という基幹業務システムを実装したもの。基幹業務の『ベストプラクティス』を実装しているという点において、SAPには30年以上にわたる実績がありました。そのため、極端な話、R/3の機能や管理項目を見れば、業務を知らないITエンジニアでもひと通りの流れをつかむことができたのです。この特徴は、最新版の『SAP ERP 6.0』になっても変わっていません。ITエンジニアが業務知識を得るには最適な入り口だと思います」（鈴木氏）

　しかし「SAP製品の機能を知っていれば、それでITエンジニア／ERPコンサルタントが務まるのか」といえば、そういうわけではない。1990年代半ばからSAPコンサルタントとして活躍してきた鈴木氏は、「2000年以降、企業がITに求める役割が変化し、それに呼応するようにSAPの製品も進化してきました。当然、ITエンジニアやSAPコンサルタントに求められるスキルも変化しています」と、ここ10年近くの市場動向を分析する。その実例を3つ挙げてみよう。

　第1に、業務改革のニーズの変化がある。10年前は、レガシーシステムからERPへ乗せ替えるだけである程度の業務改革およびITコスト削減を図れたが、2000年以降は企業ごとの明確な経営課題に基づいた業務改革に視点が移っている。具体的には、決算早期化プロセスの構築、シェアードサービス化、需給調整業務のサイクル短縮や週次対応、計画業務自体の集中化、購買の集約化といった取り組みがそれに当たる。

　第2はこれらと関連するが、最近では企業ガバナンスに対する意識がよりいっそう強くなっていることが挙げられる。業務プロセスの効率化に加え、内部統制対応や四半期報告の制度変更もその傾向にさらに拍車をかけ、グループ企業を含めた連結経営がよりいっそう重視されている。大企業グループの場合、本社とグループ各社にまとめてERPを導入するといった大型案件が増加しているという。

　そして第3に、ビジネススピードがますます速くなり、1つの企業グループの中でも、M＆Aや事業立ち上げ／売却といった変化が激しくなったことが指摘できる。また、顧客とのアクセスポイントをWebに広げて顧客を囲い込むといった取り組みや、ビジネスの変化に追い付ける柔軟なITインフラへのニーズが高まっているのだ。「ERPの導入＝業務改革と考えるのではなく、『業務改革のために、ITをどうすべきか』という視点が企業に育っています。ERPは、あくまで一手段ととらえるべきでしょう」と鈴木氏はいう。

　こうした市場変化を受け、これからのSAPエンジニアには、どのようなスキルや知識が求められるのだろうか。

業務が分からないSAPエンジニアは淘汰（とうた）される？

　次世代のSAPエンジニアに言及する前に、まず現在のSAPエンジニアに求められている技術スキルについて見ていこう。

　最初に、R/3の構成を大まかに説明する。R/3は、「ABAP」という言語で記述された業務プログラム群と、それを“システム設定する”ことで業務プロセスを実現する機能、プログラムを呼び出すAPI群「BAPI」、それに運用管理ツール「BASIS」で構成されていた。実際の導入に当たっては、ユーザー企業の業務をヒアリングし、R/3側の機能との調整をしていくフィット・アンド・ギャップ分析を得意とするコンサルタントが多かった。中には経営課題からブレイクダウンし分析した結果、「必要なところにR/3を適用する」というスタイルで導入を指導するケースもあったが、SAPの技術や機能に明るいエンジニアがコンサルタントを兼任するケースも見られた。

　技術的に見れば、現在も根幹は変わっていない。だが製品自体、徐々にオープン化／標準技術対応が進み、技術の間口はずっと広がっている。その背景にあるのは、「柔軟性の高いIT」へのユーザーニーズだ。SAP ERP 6.0は、SOAを実現するインフラ製品「SAP NetWeaver」のJavaやWebサービスへの対応、オープンソースの開発ツールを採用したことなどにより、“業務パッケージ”ではなく、“企業ITの基盤”として進化している。

　「SAPのエンジニアとして、システム設定、ABAP、BAPI、BASISに関する技術知識の有無が市場価値につながることは、現在においても同じです。技術の進化により柔軟性の高いシステムが可能になったため、製品もよりオープン化の方向に対応していますが、完全に180度違った技術に置き換わったわけではありません。向上心さえあれば、古くからのSAPエンジニアもその技術進化を追うことは容易なはず。もちろんSAP固有の技術知識は、現在も非常に付加価値が高いですし、それは今後も変わらないでしょう」と鈴木氏はいう。

　ただし、製品技術はユーザー企業のニーズを反映して進化している。「特に2000年以降、真の業務改革に目覚めた企業が増えたため、“その課題を解決する”ことがSAP導入の必須条件になっています。現在、技術のベースが固まっており、さらにその上を目指すのであれば、業務改革分野の知識を身に付けることは必須です。これが次世代のSAPエンジニアの付加価値になります。もっといえば、業務の話ができないエンジニアは、淘汰されていくかもしれません」と鈴木氏は次世代のERPエンジニアに必要なスキルを指摘する。

次世代SAPエンジニアが付加価値を上げるために

　現在は、よりシビアな業務課題に対応するため、SAPエンジニアにも深い業務知識や課題分析能力が求められている。つまりエンジニアというよりも、コンサルタントとしての役割が大きくなっているわけだ。「SAPエンジニアが自らの付加価値を上げるには、技術スキルのほか、業務に対する知識も持たなければならない」と鈴木氏は断言する。なぜなら、市場の視点が「ERPを導入すること」から、「業務改革のために、ITを戦略的に使うこと」にすでに大きく変化しているからだ。

　アビームコンサルティングでは、SAPコンサルタントの付加価値を上げるべく、「基本的には、技術・業務共にチームで担えるような人材育成をしています」（鈴木氏）という。ただ、ある程度以上の経験を積むと、仕事の幅を広げるために業務系に注力するという傾向もあるようだ。「文系出身で業務系から来た方はすんなりコンサルティングに入りやすいのですが、一方でIT系の知識習得に苦労します。しかし必死に技術を習得してそこは乗り越えてほしいですね。IT系出身の方は技術に強く、プロジェクトマネジメントなどの実務にも才能を発揮する場合がありますが、業務系が苦手な人もいる。どちらも、それぞれの専門性を生かして活躍できる場面をチームで作るように努力しています。もちろん個々人が“のりしろ”を意識して補完し合う関係が必須です」と鈴木氏は語る。

ビジネス変化に対応するため、SAPエンジニアに必要なこと

SAPジャパンビジネスプロセスプラットフォーム本部 BPPソリューション部
シニアソリューションアーキテクト原弘美氏

　目覚ましいビジネススピードの変化にシステムが柔軟に対応するため、SAPジャパンは4年前からERPの概念を再定義しています。ひと言でいえば、日々の技術進化、ビジネス課題の変化を取り入れることが可能なSOAのプラットフォームです。

　ERPがR/3と呼ばれていた時代には、ユーザー企業が抱えるビジネス課題に対し、SAPが提供するアプリケーション機能を豊富にしてゆき、これを活用いただくという方向性で対応してきました。しかしながらこの方法では、新しいビジネス要件への対応を大規模バージョンアップの段階まで待つ必要があったり、個別に機能追加を実施して対応することとなり、必ずしもビジネスの変化に即応することが、難しかったのです。

　これらを解決するため、SAPが打ち出したのは「エンタープライズSOA」でした。エンタープライズSOAが一般的なSOAと異なる点は、「業務システムで35年の実績を持つSAPが、経営視点でSOAを実現するために提供する実装済みのSOAプラットフォーム」であることです。これを実現しているのが、最新版の「SAP ERP 6.0」です。従来と同様の高機能な基幹業務モジュールに加えて、定義が難しいサービスの粒度を業務視点で定義し、再利用可能な状態で提供している「エンタープライズサービス」が用意されています。このサービスを自由に組み合わせ、ニーズに合わせて柔軟に機能拡張ができます。さらなるスピードが求められる場合、また、サービスの組み合わせ方が分からない場合は、あらかじめ決められたビジネスシナリオに基づいた「エンタープライズ・サービス・バンドル」を利用できます。

　このようにして従来の基幹業務モジュールのくくりにとらわれず、SAPが製品として提供するサービスと、個別開発のサービスを組み合わせ、新たなモジュールの概念を構築することができます。必要な部分を限定してインストール／バージョンアップできるエンハンスメントパッケージや、Flashを用いたリッチなユーザーインターフェイスの実現といった面でも進化しています。

　この状況を受け、SAPエンジニアの役割定義が変わり、活躍範囲が広がってきています。例えばシステム全体を設計するアーキテクトは、エンタープライズSOAプラットフォームを活用するという観点から設計、開発をとらえることが望まれます。これによりサービス化に対応したERP 6.0の可能性を最大限活用することができるようになります。

　この領域では例えば、これまでSAPから距離を置いていたスクラッチ開発がメインのエンジニアにとって、参入・活躍の機会が広がったといえます。またアプリケーション設計担当者を中心に行うフィット・アンド・ギャップ分析も、要件のモデル化を経て、それを実現するエンタープライズサービスを取捨選択する方式を視野に入れる必要が出てきます。この際、認識されたギャップを吸収する方法も、エンタープライズサービスの拡張、エンタープライズサービスの新規開発などのオプションから最も効果的な方法を選択できるようになることが望ましいといえます。さらに「サービスの消費」をシステム利用者の観点からとらえ、表現力豊かなRIAなどの技術を活用して設計、構築していくユーザビリティ特化型のエンジニアも生まれてきています。最新型ERPの力を最大限に引き出していくために、新しい役割をこなすことのできるエンジニアが、いま、求められています。

　さらに大きな変化といえば、「どうしたら経営課題を迅速に解決できるか」を提案する上流コンサルタントが、これまで以上に必要とされる点でしょう。ユーザーニーズを満たすために開発者が努力していた時代から、「実現できて当たり前」の世界に変わりつつある中、付加価値をより高めるには「その課題をいかに解決するか」という革新的な提案が求められます。