はじめに
私は関西でSAPエンジニアをしています。
関西という狭い業界で動いていると多方面から様々なプロジェクトのお話を聞くことができます。
私は4年ほど関西でSAPプロジェクトにかかわっていますが、燃えるプロジェクトは燃えるべくして燃えていると感じます。某グ〇コの話なので最近盛り上がりが出てきているので忘れないうちに感じたことをメモします。
SAPプロジェクトについて
SAPのプロジェクトのほとんどがウォーターフォール型で行われており各フェーズの完了をもって次のフェーズの作業を行うといったプロジェクトです。最近のPMBOKではアジャイル開発が推奨され始めたりしていますがSAPの現場はアジャイルになることはしばらくなさそうです。
新規の導入であれ、バージョン改修の作業であれ、裏ですでにお客様が所持しているシステムが動いています。そのため、経営陣の思惑と実際の現場の思惑がずれていることはよくある話です。
SAPプロジェクトのいいところ
すでに多くの企業が導入してくださっているのでお客様もどんなシステムが入るのかイメージついてる、つきやすい状態です。ERPのパッケージ商品なのでコンサルや開発陣も基本的にはお客様の業務をパッケージに合わせる方向で動きます。そのため、コンサルや開発側も無茶苦茶な要求はそう発生せず（はず...）あとは納期がどうなるか、お客様特有の箇所をどうするかだけに注力できます。
ところが...
私が関わったプロジェクトも、聞いたプロジェクトもあまり前述した状況にはなっていないことに気づきました。なぜそのような状況になっていないのか、聞いた橋と実体験をベースにまとめます。
経営陣と現場の意識の差
まずここが一番の課題かと思います。基本的に、新たなシステムになるということで、お客様側の経営陣はよくなることを信じて導入してくださります。
ところが、現場の方は経営陣の思惑とは別に慣れ親しんだシステムで行いたい、新しくなってもできること、やることは変わらないことを望んでいます。特にここの意識の差が顕著であればあるほど、本番稼働後に大きな影響が出ているかと思います。
コンサルタント側の実力不足
経営陣と現場の意識の差なんてなくそうとするのは難しい話でそれにいかに減らせるのかがコンサルの腕前かと私は考えています。とくにPMをされる方や各モジュールの指揮をとられる方がここに意識をされていると、プロジェクトの立て直しが上手く、お客さんとの関係も良好であったと記憶しています。
ただ、最近よく聞くプロジェクトの話やいわゆる燃えているプロジェクトではコンサルやPMの方とお客様の関係が悪かった印象です。
必ずどちらからも不満が発生したまま、プロジェクトが進んでいました。
開発者とPM、コンサルの認識齟齬
特に多いのがプログラムの開発を外注している、海外に委託している場合です。
設計書の内容と違うものができる、設計書が不十分なため問題に気付かないまま作成する等々、多くの問が発生しています。私が関わったプロジェクトの中でうまくいっていたプロジェクトは、設計書が不十分なものなどありましたが、自社と関係社だけで開発を行うなど、外注をしていない印象でした。
現場はどうすべきなのか
正直、私はまだまだPMやコンサルではなく、プロジェクトの意思決定にかかわる機会は少ないです。それでも、プロジェクトがまずい状態は嫌でも肌感覚で分かってしまいます。
よく聞く話は、まずくなりすぎないうちに別のプロジェクトに移るということです。
私はそれも悪い選択ではないと思いますがまずほかにやれることはないか、私が行った行動をまとめます。
①自らお客さんと話せる立場に上げてもらう
正直これが一番多いです。開発する側もお客さんも第一にいいものを作りたいことは一緒の認識です。
そのため、開発が行き詰っている、要求が難題化しているときほど直接お客さんと話せる機会をいただいています。
②コンサルの方と綿密に計画を練る
お客さんの要望が原因でプロジェクトが遅延している場合はまずはコンサルの方と綿密に話をすり合わせました。当然、コンサルやPMの方もどうすべきか計画を練られているので、その計画の助けになるべく開発者の状況、要望を伝えてました。
さいごに
あくまで私が感じた内容のメモですので、すべての現場の状況がこれに当てはまるとは思いませんがいずれもコミュニケーションエラーで問題が発生しているかと思います。
私自身もこれからさらに上流部分で仕事するにはこれらの問題にぶつかるかと思います。
その際に、開発者時代に書いたこのメモを思い出せるようにするとともにどう動くのが最適なのかの一助になればと思います。