実力不足でしょうか

質問

来年納品の開発PJTに現在入ってます。
しかしPJT自体に前向きにやれない、というかついて行けなくなりました。

工程は「詳細設計」に入っていますがテーブルの変更(カラムの増減)が連日相次ぎ、
仕様の辻褄が合いません。
画面の仕様も同じく毎度変わります。

一番頭にくるのがPMやサブが食堂とか休憩室で雑談しながら、
一服しながら仕様変更の会話をしていることです。

その内容はPJTでアナウンスされず一部のその面子だけが把握し先に
進めている状態です。
例えばカラムの増減についてもその変更理由が
説明されずER図だけが変わっているようなイメージです。
ドキュメント全体の整合性も怪しいです。

私の方に開発の経験や業務知識が少ないこともあります。
しかしこんなやり方って一般的なのでしょうか？。
それとも自分はPJTで割っていく何かが不足していますでしょうか・・。

なんかこのまま従っていてもPJTは炎上しそうな感じです。

情報が少なく恐縮ですがご意見お願いします。

回答No.3

galluda

がると申します。

基本的には「プロジェクトメンバー全員で」ってのがもちろんよいのですが。
現実問題として。
スキルの低い子とか動きの鈍い子が多い場合、とりあえず「真っ当に出来る連中でとっとと仕切って」ってケースは決して少なくないです。
正直。全員で打ち合わせをしても「烏合の衆」の集まりではただの時間の浪費ですし。

仕様変更については「どこにいってもよくあること」です。
無論、仕様変更はないに越した事はないのですが。実際問題として「仕様変更がない」プロジェクトなど見たこともないですし。
その場合に求められるのは「仕様変更に強い作り」になります。もちろんDBも画面も含めて(別に。DB系の開発だからウォータフォールとは限らないというかそんな事してたら失注してしまいます)。
例えば。DAOとかきちんと把握されていれば、詳細設計フェーズ程度でのDBのカラム変更くらいは楽に吸収できるはずですし。

厳しい発言をしてしまえば。
PMやサブの方が「こいつは使える」リストに、ご自身を入れられてないのだろうと思います。
だから、ローカルな打ち合わせにも入れてもらえず…なのだろうと。

理想とかきれいな流れとかが理解できないではないのですが。
現実としてのラインと、その上にご自身が乗れるだけのスキルがあるかないか。ないのであれば「どうやってそのスキルを身につけるのか」というのをきちんと正面から捉えられてみるとよろしいかと思います。

かなり厳しい内容になり恐縮ですが。