実力不足でしょうか

質問

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

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

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

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

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

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

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

回答No.2

KnKn9898 · ベストアンサー

これはそもそもプロジェクトの進め方自体が間違っています。
カラムとあるので基本的にはデータベース系の開発だと思いますが、あれはウォーターフォール型の開発が一番しっくりくる案件で、まず基本仕様が決まって基本設計、詳細設計…と進んでいくもので途中で手戻りが発生するにしても毎回設計が変わるというのは前提の部分で決まっていない点が多すぎるか、根本的に何かが間違っていると考えるべきです。
しかも、
一番頭にくるのがPMやサブが食堂とか休憩室で雑談しながら、
一服しながら仕様変更の会話をしていることです。
というのは２、３人でXP的に開発しているのならともかく、多数のプロジェクトメンバーを抱える状態ではかなり危険です(仕様変更のアイディアを雑談でするのはいいけれど、すぐにその案件を全員に説明する必要はあるでしょう)。
推察するに、そのＰＭはあまり大きなプロジェクトの経験がないか、たまたま今までうまく行っていたか、あるいは(これが最悪ですが)炎上させても口がうまくて依頼者から追加の金を搾り取るようなテクを持っている悪徳ＰＭではないでしょうか？

お礼

こんばんは、アドバイス有難うございます。

カラムはテーブルの列のことです。※失礼しました
今回はデータウェアハウス系の開発になります。
※ウォーターフォール型の開発だと認識しています。

ご指摘のとおり前提の部分で決まっていない点が多かったか、もしくは
顧客の仕様変更要求を随時受けつけているのかもしれません。

でなければこの時期に追加要件がゾロゾロ出てその都度ER図が変更は
考えにくいのですが・・。

今回メンバー数も多いので「2,3人で雑談」は本当に厳しいです。。

回答No.5

noname#46712

・派遣されているのでしょうか？なのであれば、すぐ手を引くべきだと思います。
>なんかこのまま従っていてもPJTは炎上しそうな感じです。
もう出火しているような気が。。（＾＾；
最後は人海戦術ですよ。どうせね。そして引き伸ばし。結局、プロジェクトというのはメンバーひとりひとりが、誰が何をどの程度知っていて、どう使えばいいのか、どういえばどう動くのか、そして会社のやり方やお金の流れなども含めてあらゆることを知り尽くしていないと成功しないのですよ。つまり、普段からのチーム作りが必要なわけですよ。体をこわしてからでは遅いです。お大事に。。。

お礼

有難うございます。

「そういう人を巻き込んで設計はやりません。フットワークが重くなるので。」、とPMなどから思われているかもしれません。ただ現実問題で自分が
やっていける見通しがないので１月初めにPJTから抜けることになりました。

今回は教訓とし、また別なPJTで経験を積んで前向きにやっていきたいと思います。

回答No.4

dekopa-

#3氏に同意。

質問主は自分で「業務知識が少ない」と言っていますが、そういう人を巻き込んで設計はやりません。フットワークが重くなるので。

詳細設計レベルでころころ変わる、というのも、基本設計レベルで煮詰める作業が足りていないのか、そうでないのかが質問から見えませんね。
概念設計レベルでは変化せず、詳細設計レベルでERを頻繁にいじる事はあります。PMの進め方次第なのでそれを詳細設計でやるか、その前に詰めるかはプロジェクト次第ですが。

締め切りも、基本設計での成果がどれくらいあるのかも、詳細設計でどこまで作るのかも、そしてそれらにたいして貴方がどう関わっているのかも全然分からないので、「駄目なプロジェクト」「単に貴方がついて行けないだけ」それぞれ確率は半々です。

お礼

おはようございます、皆様アドバイス有難うございます。

自分としても「駄目なプロジェクト」と考えている訳でもなく
「単に(能力的に)ついて行けないだけ」の可能性もあると思ってます。

PGは多少経験はあるのでDAOとかフレームワークなど技術的な設定は
やってましたが今回のように詳細設計レベルでERが変わるケースは
正直初めてでした。また先述のとおり上流設計もあまり経験ありません。
またご指摘のように打ち合わせから外されているため、きっかけがつかめません・・。

とりあえず今後案件が進むにあたり、自分はPJTにどう接していくべきでしょうか？。
次の案件でも同じ鉄は踏まないようきっかけはつかみたいのですが。。

回答No.3

galluda

がると申します。

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

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

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

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

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

回答No.1

noname#96023

残念ながらPMの実力不足でしょう。
PMはいかなるメンバーであってもメンバーの手に余る仕事の進め方をしてはいけません。
懸案事項を解決する打ち合わせがあるなら、全体の意識が取れていないことを懸案として挙げてください。

お礼

こんばんは、アドバイス有難うございます。

懸念事項はそうですね、積極的に提言してみます。
正直この工程でテーブルの変更の繰り返しは本当に厳しいです。。