大規模案件でうまく立ち回れません

質問

とあるベンダーで、市場シェアの高い製品の
サポートエンジニアを数年担当していました。

その製品の知識を買われ、とあるSIベンダーに転職しました。

案件は、プライムが多いため、
1部屋に100人以上が集まって作業をすることが多いです。

その100人が主に、10チームぐらいに分かれ（業務機能、基盤、PJ管理、など・・）、
上流からフェーズを進めています。
（プログラム海外開発が多く、主に設計がPJ管理がメインです）

悩みとしては、前職までは「製品のサポート」という受身の作業が多く、
またSIの経験が無かったことから、フェーズを進めるアイデアやノウハウが、
かなり不足していることです。

具体的には、設計はお客さんの誰を巻き込んで、どう進め合意を貰うか、
あとは結合テスト何をしてどう進めて、品質の判断はどうするか・・など、、
（開発の経験も少ないので、うまく言えずにすみません・・）

あとは、チーム間の会話や、発生している課題、PJの全体状況について
視野が狭く、話についていけず、チームから取り残されることもあります。

実は年齢のことで会社からはチームリーダのクラスを期待されてますが、
こんな状況ですので、立場がありません・・。

サポートで担当した製品の仕事も無く、正直転職は失敗したと思います。

しかし、このまま逃げるのも嫌なので、
できるだけ努力したいのですが、どう勉強して良いかわからず・・

尚、会社からはマネージャでなく、上記サブチームのリーダクラスの働きを
求められています。

PMPや情報試験など勉強することで、
PJで何をどう進めれば良いか、わかるようになるでしょうか？。

ご意見を頂ければ助かります。

回答No.3

shin_nosuk · ベストアンサー

こんばんは。
当方フリーのシステムエンジニアーです。

>あとは結合テスト何をしてどう進めて、品質の判断はどうするか・・など、、
>（開発の経験も少ないので、うまく言えずにすみません・・）

まずシステム開発の工程を知ること。
さしあたって「共通フレームの開発プロセス」の言葉と考え方を理解しましょう。ソフトウェア結合とシステム結合の違い、ソフトウェア適格性確認テストとシステム適格性確認テストの違い、またこれらの組み合わせの違いを考えたとき、ソフトウェア、ハードウェア、仕様（要件）をどう分けて、どう関連させる必要があるかがわかってきます。
テクニカルな側面については（プログラムはオフショアということですから、）システムで利用しているツール（言語やミドルウェアのたぐいのこと）について、把握しておきましょう。あるツールで、できることと、できないこと、あとは、簡単でもいいですから、具体的に、この仕様を実現するために、どんなことを書かなければならないか（設定をしなければならないか）を理解しておきましょう。

>具体的には、設計はお客さんの誰を巻き込んで、どう進め合意を貰うか、

工程の考え方を知れば、その現場での体制図を見渡して、業務要件の確認をもらう人、性能要件の確認をもらう人、ソフトウェア要件の確認をもらう人などが誰かわかってくると思います。

> PMPや情報試験など勉強することで、

PMBOK は理論ベースに経験が裏づけされることで真価が発揮されると思います。どちらかといえば、応用情報とか、テクニカルエンジニアの午後対策のほうが面白いと思います。（午後試験はケーススタディーが多いです。）

現場を管理するプロジェクトリーダーは、プログラマーを数年経験した、システムエンジニアーがさらに経験を積んだ人が多いです。質問を拝見してますと、ふつう30歳前後までに積む、これらの経験が不足されているのだと思います。プログラマーをいまからやり直すのは難しいと思うので、これまでに書いた、リーダーとして、知っていてしかるべきの、工程の考え方とシステムで使っているツールの把握、そして、業務知識（ようするに仕様）を知ることに注力されることがよいかと思います。

あともうひとつ。

あなたに裁量が与えられていて、現場のよい雰囲気を維持できている（悪い雰囲気でない）ならば、サブリーダーや主担当者を任命（体制上、公式なものでないにしても、そのように口頭で伝えてみる）してしまうというのがよいかもしれません。裁量がないにしても、分野別に特化したメンバーがいるはずですから、その人との信頼関係を築き、今、直面しているあらゆる問題のいくつかの対策を「頼れる人に聞く」というところにまず置きましょう。「ごめん、わからんから、ちょっと教えて。」というのもひとつの方法かもしれません。

こうやって自分なりに対策を考えて主体的にメンバーとの関わりを持つことで、

> 悩みとしては、前職までは「製品のサポート」という受身の作業が多く、

受身から脱却でき、そして、宴会の段取りをしているのとあまり変わりがないということに気がつくはずです。

がんばってください。

お礼

有難うございました。

悩んでいたポイントに対し、的確なアドバイスを頂き
深く感謝しております。

開発プロセス（工程の考え方）に関しては、本当に経験や勘所が無く、困っています。。

例えば結合テスト、総合テスト、システムテストなど案件毎にフェーズが
あるのですが、それぞれで具体的にどういったテストをするのか、、とか
周りに恥ずかしい質問ばかりして怒られてます。

現状では、案件に参画しつつ、知識として色々勉強するしかないですね・・。

また各フェーズのTODOもそうですが、案件がいまどこまで進んで、何が課題かも
体制図などからキーマンに確認しつつ、気持ちを切らさず当事者感覚で望みたいと思います。

あと「分野別に特化したメンバーがいるはずですから、その人との信頼関係を築く」、
これは私に欠けていた点だったと思います。

交流を持つことで、双方の情報の流れが良くなり、「案件がいまどこまで進んで」という
状態は回避できるかもしれませんね。

頂いたアドバイスを元に、多人数の中に埋もれないよう、頑張りたいと思います。

回答No.2

kztk

こんばんは。
大変な状況だとお察しします。

質問者様には、
　・システム開発そのもの
　・プロジェクトマネジメント
両方の知識、経験が不足しているものと思います。

前者に関しては、システム開発に関する一般的な解説がしてある本を
一冊読破してください。
大規模プロジェクトとのことなので、ウォーターフォール型開発の
各工程でどのような作業をするかイメージをつかめばＯＫです。

後者に関しては、知識先行ではなかなか難しいと思います。
実際にプロジェクトを経験しないと、書かれていることが腑に落ちない
と思うのです。
教科書は一冊手元に置くとして、まずはご自分が参画されている
プロジェクトの状況を把握してみてください。

・プロジェクトのスコープ(≒フェーズ毎の納品物)
・全体スケジュール
・工程毎のマイルストーン
・体制(顧客、自社、協力会社)
・役割(だれがどの作業をやるのか)
　　：
等々。

それが分かったら、直近のマイルストーン(例えば結合テストの開始)の
前提となる作業には何があるか、それらは順調かどうか。
まずいならいつまでにどう対応しないと更にまずいのか。
そのためにはいつまでに何を始めないといけないのか。
・・・を考えてください。それが直近でチーム間で議論すべき優先課題
です。
最優先の課題にきちんと取り組んでいれば、とりあえず「立場がない」
という状況もなくなってくると思います。あとはそこからの派生で関連
する課題の把握を頑張るしかないと思います。

「このまま逃げるのも嫌」との心意気で、是非頑張ってください。

お礼

有難うございました。

具体的なアドバイスを頂き、大変感謝しております。

会社は思ってないのですが、私自身はやはり

・システム開発そのもの
・プロジェクトマネジメント

両方の知識、経験が不足しているのは間違いないと思います。
（会社は年齢を理由に、一方的に経験者扱いで参ってます・・）

システム開発に関する書籍は、読んで先ずは知識をインプットしたいと思います。

あと現在のPJでのことですが、人とチームが多すぎて
今進捗はどうで、どこが止まっているかなど情報が入らずに出遅れてしまい、
立場が無くなることがありました。

これは「役割(だれがどの作業をやるのか)」を体制図から確認し、
自分から情報を仕入れに行けるなどの姿勢をとってみたいと思います。

回答No.1

lv4u

>>その製品の知識を買われ、とあるSIベンダーに転職しました。

ということですが、

>>実は年齢のことで会社からはチームリーダのクラスを期待されてますが、

と、実際には管理者としての能力も期待されているってことですよね。その製品の仕事も無いのなら、会社は貴方を騙したってことですよね？

また、給料はその地位に見合ったものとして契約したのでしょうか？それであれば、入社前にリーダと期待されていることを知っていたってことですが、そうじゃあないですね？であれば、リーダクラスの仕事を拒否して、年齢は上だけど、単なるメンバーとしての仕事だけをやるという選択もあると思います。

ちなみに、どんなにやり手でも転職して環境が変わると、チーム間の会話や課題にはすぐについていけず、取り残されることは、ありがちなことだと思います。

>>PMPや情報試験など勉強することで、
PJで何をどう進めれば良いか、わかるようになるでしょうか？。

一般論はそれらを勉強すれば理解できる気がします。が、実際の現場では、なかなか難しい気がします。
失敗をしながら、時間をかけて１つずつチームリーダに必要なことをマスターしていくしかないのでは？

ちなみに、私も「今のリーダが別のチームに移るから、かわりにリーダとしての働きを期待する」なんて言われたことありました。でも、それに応じて給与が増える可能性はほとんど無いですから、そういう働き方はしていません。

お礼

有難うございます。

＞＞会社は貴方を騙したってことですよね？

本心を言えば、私もそう思います。
管理などの条件での入社はしていません。

管理をやれ、と上司から言われるものの、色々とうまくいかず、
次第に上司との関係も悪くなり、欝に近い状態になったこともありました。

辞めてやり直したいのですが、この不況ですし
短期間での転職は本意ではありません。

そうならば、今の大規模案件から学ぶ点を探すしかないと思ってます。
ご指摘のように失敗をしながら、時間をかけて１つずつ学ぶしかありませんね・・。

とはいえ、今から要件定義から基本設計、総合テストなど
一連のフェーズで、得意領域を探すのは大変で途方に暮れています。。