移行というガテン・・・一夜あけて

幸いなことに、移行はうまくいったようだ。
本当に「うまくいった」を言えるのは、今月末の締め処理が終わったときだが、
データがきちんと入った、ということ自体、まずは成功と言えるだろう。


私のキャリアは、システム会社の開発者として始まった。
その当時、私から見た「コンサルタント」というのは、
・口だけ出す
・早く帰る
・丸投げする
・給料が高い
という、非常に魅力的な職業であった。
たとえば、移行の時には、自分で手は動かさず、的確な指示を出すわけでもなく、
単に開発者主体の「移行担当」に丸投げし、自分は家で寝ている、
というのが、「コンサルタント」という人々だった。
私は、そういう「おいしい仕事」をしたくて、転職を繰り返し、「コンサルタント」という肩書きを手に入れた、と言ってもいい。


しかし、その意味では、現在「コンサルタント」という肩書きがついた今、
当初の目的は、まったく達成されていないことに気がつく。
相変わらず、移行のときには、データ投入に付き合い、想定外のデータが発生すれば、その調査をしている。


しかし、それは必然である。


たとえば、移行のときに、「レガシーシステムのことはわからないから」という理由で、
そこのデータ抽出は、クライアント会社の情報システム部の人の仕事、
という「役割分担」を作ってしまうと、R/3のことを知らない人が作るデータを、受け身で受け取るだけになる。
すると、データだけを見てしまう。
そうすると、応用も汎用性もなにもなく、理屈に合わない「移行パターン」が増殖するわけだ。


本来データパターンとは業務パターンであり、このデータが、なんの業務で発生しているのか、
ということを把握し、To-Beの業務フローと突合せながら、どうするのかを考えるのがスジである。
ならば、この役割に最も適しているのは誰か？
業務を定義している「コンサルタント」である。
この認識なく、「コンサルタント」をしている人が非常に多いと感じる。
そして、その領域に踏み込もうとせず、単にぶつぶつ言っている移行担当、開発者も、同様に非常に多い。
これでは、スケジュールどおりのプロジェクト完結なんて、できるわけがない。


「役割分担」の災厄である。


「全員が役割分担に従って、仕事をきちんとすれば、プロジェクトはうまくいく」というのが、なぜ幻想なのか、は、また別の日に書くことにしよう。