sankakuichi's blog

働き盛り!日々感じたことを書きます♪

コンサルタントとエンジニア - トップダウンとボトムアップの考え方の違い -②

コンサルタントとエンジニアの考え方の違いは、納期の考え方だけでなく
システム開発そのものにも大きく影響する。

エンジニアはシステム開発に必要な要件をベースに顧客から求められる要件を擦り合わせるように要件定義を行うが、
コンサルタントシステム開発に必要な要件なんてお構いなしに要件定義を行う。
コンサルタントは基本的に顧客の顔色しか気にしないのだ。
エンジニアが無理だ、もっと開発のこと考えた要件定義をするように要求しても
それは自分たちの仕事ではないとばかりにまるで無視する。
※言いすぎてる感はありますが。笑。極端に言えばこういう態度であるということです。




そして、コンサルタント出した要件定義成果物をインプットに設計が始まるが
システム開発に必要な要件のほとんどが抜けており、設計者がほとんどの機能を想像で考えることになる。
設計者が要件定義をしている人間と同じ会社の人間ならまだしも、昨今では海外のベンダーや地方のベンダーを使うものだから
コミュニケーションが取りにくく設計者が独自に考えざるをえないのだ。

いい要件定義成果物には、設計者にある程度の設計の自由度を残しつつも、肝となる仕様や機能に関しては
きっちりと誰にでも分かる形で制限事項として明記してあるものだが、そんな成果物はあまり見たことがない。
素人が要件定義を行っているも同然の成果物がほとんどである。

<スポンサーリンク>

はじめての上流工程をやり抜くための本~システム化企画から要件定義、基本設計まで (エンジニア道場)

はじめての上流工程をやり抜くための本~システム化企画から要件定義、基本設計まで (エンジニア道場)



そんな要件定義成果物を作るコンサルタントは、おそらく要件定義の成果物が
何のために使われるのか理解しておらず
顧客の要求をうまく取りまとめたものにしか考えていない。
システムの知識などないのだからそうならざるを得ないのだろうが…

ここまで来るとコンサルタントははっきりいてもいなくてもいいのではと考えざるをえなくなる。
業務のことは顧客の方が詳しいに決まっている。
コンサルタントが知っているのは一般的にはこうであるというレベルのもので、顧客のことは顧客が一番詳しいに決まっている。

少なくとも私がこれまで経験してきたプロジェクトでは残念ながらそんなコンサルタントばかりであった。
そして、さらに残念なことに彼らはそれを認めようとはしないのだ。
知ってるフリをすることは、私にはとても苦痛を伴うのだが、彼らは、プライドの高さがそうさせるのか
平気で知ってるフリを装う。そして立場が悪くなると、屁理屈にも似たロジックで窮地を脱する。

そんなコンサルタントの中で育った人には、もはや本当に必要なものが何なのか分かることはない。
就職したときは優秀だ、外資に入れた、コンサルタントになれたと鼻高々なのだが、
(その全てが自己満足ということを気が付かない)
すぐに実際の仕事は泥臭くかつろくに仕事ができていないことに気が付く。
しかし、自分では何もできないので、それを他人のせいにすることでしか仕事を進めることができない。
実に残念だ。

<スポンサーリンク>

申し訳ない、御社をつぶしたのは私です。

申し訳ない、御社をつぶしたのは私です。



私は、なぜこんなことになっているのか最近まで不思議に思っていたが
昨今はIT業界そのものに問題があるように考えるようになった。