SAPプロジェクトで、プログラマの弱点とコンサルタントの弱点は共通する！
「＠IT::Webサーバから始めよう」という記事に「プログラマの弱点（？）」というセクションが公開されていた。とても興味深いので引用しておこう。
ある程度の規模の開発プロジェクトでは、上流工程と下流工程、開発担当とサーバ担当、さらに開発担当のなかでもバックエンドのロジック担当とフロント周りの担当など、分業体制で進めていくのが一般的です。
ここまできっちりと分業されていない場合でも、コーディングはプログラマが行い、本番向けのサーバ構築などは詳しい人に任せてしまうといったことは多々あります。
こういった分業体制はもちろん理に適ったことなのですが、開発者が常にプログラマに徹してしまっていると、どうしてもサーバ知識が不足しがちになります。アプリケーションを動作させるために必要な最低限の環境を自分のPC上に整えたら、あとはひたすらコーディングの日々といったことの繰り返しになるので、なかなかサーバ知識が深まりません。
その結果、開発中やリリース後に問題が発生した場合に、アプリケーション本体以外に原因があっても特定できなかったり、特定できてもどう対処して良いか分からず対応に時間がかかってしまったりといったことにもなりがちです。
上記は、大規模な開発プロジェクトを対象に記述されているが、この内容は、ほとんど同様に「SAP導入プロジェクト」にも当てはまる。というより、「SAP導入プロジェクト」においては「分業」する分野が開発よりも増加する傾向がある。分業体制は、一見効率向上に貢献するような錯覚に陥るが、実際のところ、分業されていても結局は納品物は1つであるから、最終的には分業した内容を統合する必要があるのは、誰でも理解できる。
「SAP導入プロジェクト」における「分業」は、上記の開発プロジェクトにおける「分業」よりも実態は深刻である。まずは、「SAP導入」における目的を上流と称し、コンサルタントと呼ばれる人達が担当。一旦、目的が明確になると、ERPコンサルタントかSAPコンサルタントとか呼ばれる人達が登場して、SAPの設定を担当する。また、この人達は、SAPに関する内容は良く知っているが、アドオンといわれる拡張機能の開発は、コーディングや開発言語の難易度は知らない。最悪は、こうしたERPとかSAPコンサルタントは、開発を総称して「下流」と呼んだりして差別化する。
こんな分業体制で一つのプロジェクトが成功するのは奇跡に近いと私は感じているが。もっと、狭い領域でも良いから、「SAP導入プロジェクト」に関わるコンサルタントは、SAP導入目的の明確化、SAPの設定、簡易な開発といった分野を分業することなく実践できることが重要であり、そうしたコンサルタントの育成が我々のような管理者の使命だと信じている。
