- ベストアンサー
上司が部下に仕事を振ったら完全放置で困っています
- 上司が部下に仕事を振るだけで後は放置する状況に困っています。部下はインフラ専任ではないため、インフラのタスクも担当していますが、レクチャーや打ち合わせはなく、困難な部分も自力で解決する必要があります。
- 設計書や定期的なMTGがなく、進捗状況もソースレビューまでわからない状況です。このため、自主的に設計しドキュメントにまとめたり、朝会の実施をお願いするようにしました。
- 部下はプログラミングにはそれなりの経験がありますが、インフラに関しては不慣れでミスをすると直接的な障害につながるため、困ることが多いです。上司はトラブルが起きた場合、部下に全責任を負わせており、チームとしてのトラブル防止の取り組みはありません。部下には「もっと積極性を出せ」と言われていますが、この状況で積極性を出すのは難しいです。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
上司の方には技術力はあるんでしょうが、マネジメント能力が不足しているんでしょうね。 小規模な環境だと、マネジメントする立場の人も手を動かして開発をしなければいけなくなるので、どうしても開発に傾注してしまうとマネジメントが疎かになってしまいます。 また、上司の方の技術力が高く、一人で何でもこなせてしまう場合陥りやすい問題ですね。 一番の原因は環境です。 マネージャーにマネジメントに集中できる環境が用意されていないから、マネジメント能力が育たないんです。 会社としてもっとマネジメント業務を主体に仕事をするよう仕向けていかなければ変わらないでしょうが、小規模な所だとマネジメントだけに人を裂く余裕が無いのでなかなか変わらないかもしれません。 会社としてどこまで危機感を持つか次第ですし、仕事量が増えて規模が大きくなり人員が増えていくとちゃんとマネジメントしないと仕事が回らなくなり、結果としてキッチリ管理するようになって行くでしょう。 どこでも小規模なところは似たようなモノだと思います。 そういった環境について行けず辞めてく人は多くいますし、そういった環境に馴染んでしまって一人で何でもこなせるけど後輩を育てられない人になっていく人もいます。
その他の回答 (2)
- Broner
- ベストアンサー率23% (129/554)
プログラミングに加えてインフラのタスクも担当の仕事をしているのですか。 教えてくれないのは当たり前です。上司は正しい。 上司のやり方が、最高ではない、だから、あなたなりのやり方でやれば、上司よりもいいものができるかもしれない。 上司は、謙虚なのです。 みんな、自分なりの工夫で結果を出してきた。 タスクは、データのファイルがあり、 それを使って、計算、判断をする手順をプログラミングして、 成果をだす。 手順を計画するのです。それには、タスクの内容を、マニュアル化できる知識が必要です。 タスクの内容を、マニュアル化できる努力が大事です。 また、それには、個性がでます。 上司の個性でないものを、見ようとしているのです。 単純労働よりも良いよ。
お礼
お礼が遅くなってすみません。 ご回答ありがとうございます。新しい切り口ですね。 インフラの定常タスクについては、既に手順(マニュアル)があります。 マニュアルを改善するには、まず、マニュアル通りにこなせるようになる ことが必要だと思うのですが、いかがでしょうか? またマニュアルがあるからと言って、「これやっといて、よろしく!」と 言うだけで放置するのは、正しいやり方ですか? プログラミングについては、 自社内で独自フレームワークを利用していますが ドキュメントがあまりなく、どうプログラミングするのが、 おおよそセオリー通りなのか、というのも不明確なままです。 まずはそこの定義から始めないといけないと思うのですが、いかがですか?
質問すれば答えてくれるというのはあなたの職場は正常な状態です。質問にクイズが返ってくる職場なら問題なのです。一方、机に座って「さあ教えてください」という生徒は学校に戻るならいいですが職場での存在意味はどうなんでしょう。仕事の方向性に不安があるなら、現在の自分の方向を説明する資料を作りこれでいいですかと確認することです。世話してほしい、レールを作ってほしいという気持ちは分かりますがこれでは労働者の品質として外国人研修生との競争になってしまいます。我々には仕事ができる義務もミスゼロの義務もありませんがホウレンソウという義務があります。ホウレンソウが出来ない者はブラック労働者であり要りません。席が隣でもメールで質問すればエビデンスになるし口頭で質問するなら自分で記録を残すことです。結果の確認を求める時も、結果だけを提出してチェックお願いしますでは、上司は一から作業者の労働の跡をたどる必要があります。こんなのでは世話がやけることこの上ない。自分が確認したチェックシートを出して、これは自分で見ましたが確認の仕方はこれでいいですか、他に見るところがありますか、というようでなければ使いにくいということになります。
お礼
ご回答ありがとうございます。 あなたがエンジニアの方かわかりかねますし 質問文も長いので見落としてらっしゃるのかも しれませんが・・・ > さすがにこの現状はかなりマズイと思ったので、 > 自主的に設計しドキュメントに起こして、事前に確認してもらうようにしたり > また朝会を実施するようにお願いしたりして、実施されるようになりました。 > ただ、タスク遂行にあたって困るのは > 詰まったときに、何に詰まっているのかよくわからないこと > つまり、何がわからないのか、ということもわからないこと > タスクの取り組みの方針が合っていると確信していたが > 実はあさっての方向を向いて、それに自分で気付くことができないこと > だと思います。ですので > 「わからないことがあったら聞いて」だと不十分だと感じています。 です。 例えば、コードレビュー時に、今までの成果を全て確認してもらうのは 大変だろうということもあって、自主的にクラス図を作って 見てもらうことにしました。 どういった意図で、どういうクラスが作られているのかを 事前に把握してもらえれば、コードレビューも楽になると考えたからです。 クラス図を見てもらってOKが出て、それを元にそれ通りに実装しても コードレビューになって、クラス構成がおかしいと言われることがあります。 実際にコードを見てみて違和感を感じるのは仕方のないことですが これはウォーターフォール型開発における「手戻り」にあたり 絶対にやっちゃいけないこととされています。 これ以上、細かく上司に確認を取るとなると 毎日毎時間のように上司にホウレンソウをしなければならなくなります。 (上司は自分で手を動かしたく、自分の時間を確保したいから 今の方針を取っているわけで、細かいホウレンソウは望んでいないと思われます) ですので、事前に打ち合わせがしたいんですね。 どのポイントで詰まってしまいそうなのか だから、どのポイントを見て欲しいのか どういう頻度でホウレンソウをしたら、お互いに取って心地良い状態なのか こういうことを事前に打ち合わせしたいです。 また、さらに別の例だと、ミドルウェアの設定ファイルは デフォルトのパスにデフォルトのファイル名で置いてあるなら ググればそのパスを発見して、それを読んで理解することができます。 ただし、デフォルトから変更されているのであれば どんな大ベテランでも、それを見つけることはほぼ不可能です。 ファイル名すらわからないわけですから。 なので、これは事前にどうしても教えてもらう必要があります。 ただ、こういうことすらも難色を示されているので どうしたらよいですか?という質問です。
お礼
ご回答ありがとうございます。 状況を的確に捉えて頂いていて助かります。 実は私の上司は会社の創業メンバーの一人なんです。 上司の半年前までの口癖は 「俺は今までマネジメントなんてしてこなかったからできない。 マネジメントするために会社作ったわけじゃないんだよな (だからマネジメントはしない)」 でした。ただ、それだとどうしてもカオスな状態になってきたので 朝会が誕生したという経緯があります。 私は過去に、 「上司さんのエンジニア系タスクは全部私がやりますから マネジメントの力を注いで頂けませんか?」 とお願いしたこともあります。返答は 「マネジメントするために会社作ったわけじゃないんだよな」 でした。要するに上司はマネジメントじゃなく手を動かしたいんですね。 ですので、今後もマネジメントを中心に据えることは無いと思われます。 マネジメントに不慣れだから協力して欲しい、ということなら 喜んで協力させてもらいます。 でも、不慣れだからしない、だとどうすることもできないです。 不慣れでチームマネジメントが行き届いていなのは仕方がないです。 そこを責めるつもりはありません。ただそれなら、 トラブルが起きたときに、なぜそのトラブルが起きたのか真の原因を究明して、 人に責任を押し付けるようなやり方だけは止めて頂きたいのです。 そうしないと、チームが崩壊してしまうからで、実際に崩壊しています。 第三者から客観的な意見を頂きありがとうございました。 この内容を元に上司との面談に臨みたいと思います。