- ベストアンサー
設計・開発業務のマネジメントとは何か?
設計・開発業務のマネジメントとは何か?という漠然とした疑問を持っています。 まだ私はマネージメントされる側なので、あまり気にすることはないのですが。 新しい仕事が期初に発生すると、計画を立てるのですが担当者が立てて、それをチームリーダーに見せますが特に何もいわれません。 週に一度、業務を担当者からチームリーダー、チームリーダーから部課長に報告しますが、チームリーダーは部下の書いた報告書をコピペして部課長の前で読んでいるだけだそうです。部課長は「突っ込んでみても、わからないとしかいわないから、君のところに来たんだけど」と担当者の私のところに来ます。 チームリーダーからは、残業の申請をしてくれというようなことしか言われたことはありません。チームの人の割り当てなども、先輩がしております。 しかしながら、チームリーダーの週イチ業務報告には「マネージメント を行った」と書いてあります。 このチームリーダーは何を持ってマネージメントしたといっているのでしょうか?そんなこんなで、私も部課長と直接やり取りをするようになったので、余計わからなくなってしまいました。 まわりからも「お宅のチームリーダー何やっているの?」と聞かれて答えに窮しています。困ったときも、先輩や部課長に相談し(チームリーダーに相談しろといわず話を聞いてくれる)10年前は新製品を1つ量産化までこぎつけたらしいのですが、それ以降何をやっていた人なのかはあまり知られていないようです。 よろしくお願いいたします。
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
まずマネジメント全体として考えます。 1.目標設定 大きな目的とか目標は与えられることが多いです、それを部下の業務分掌に適合して噛み砕くことが大事です。そのときに背景・目的・上位の目標の説明も必要です。 2.日程管理 3.業務の評価・指導 区切りごとの評価の良し悪しを判断し、不足している場合ならそれに対して指導が必要です。また、このなかで、コミュニケーションギャップも発見できることが多いです。このときマネージャに十分な技術力があれば、マネジメントから一歩踏み込んでよい仕事ができるでしょう。 4.まとめ 少なくとも業務終了後、あるいは途中でまとめていき、必要に応じて関連部署、上司にに報告を行います。 こういうふうに考えると管理職以外、一番下の職層でも自分自身のマネジメントが必要になってきますね。私はそれに気がつくのが相当遅くて苦労しました。 今回の質問 >設計・開発業務のマネジメントとは何か? は目標設定・納期は明確ですね、それ以外のところではリソース管理とか、他部署との関係とかいろいろ仕事あります。 さて、質問者様の文章を拝見すると本当の質問はこういうことを聞いているのではなくて、うちのリーダーマネジメントしているの?ということだとおもいます。していないというのが回答でしょう。 しかし、これでリーダーの資質があるかどうかは別問題です。
その他の回答 (1)
- nb18dl
- ベストアンサー率14% (1/7)
技術職向けのマネジメントの本でも読んでみては? チームリーダーぐらいだと、マネジメントすきるが殆ど無い人 (本人のパフォーマンスは高いが、チームの管理が出来ない人)はいると思います。 質問者様が、勤続何年で、どのぐらい今の上司と付き合っているか分かりませんが、一年ぐらい一緒に仕事をして駄目だなと思う上司は、 大抵は駄目上司ですね。 そういう場合は、上司のやり切れていない部分の仕事をさり気なくこなしていくと、上司(部課長服含む)から一目置かれ 一般的な社員より、早く出世する人が多いような気がします。
お礼
ありがとうございます。 ある程度の年齢になると、どの会社でも管理職的な扱いになるのですが、私の勤め先では「マネジメントに軸足を持つか」に進むか「そのまま技術的な業務をしてスペシャリストになるか」選べると思います。当然、技術的なほうに残って開発を進めていけば、日程に追われるだとか、新しい技術を若手と張り合って手につけなければならないので、安易に「マネジメント系」にいく人が多いです。
お礼
ありがとうございます。 私の会社では、チームリーダーといいながら残業手当なしで、マネジメントと実開発業務を兼務して、結局「名ばかり管理職」になっておりみな苦労しております。しかし、昔からの「管理職」が頭にある人は1日中パソコンに張り付いているだけに見えてしまうのです。 どちらがよいのかは、一概に言えませんが、最適な結果が出るように部課長と連携して仕事をしたいです。