こんにちはゲストさん。会員登録(無料)して質問・回答してみよう!

解決済みの質問

上司が部下に仕事を振ったら完全放置で困っています

34歳Web系のシステムエンジニアです。
上司がいわゆる職人タイプのエンジニアで
部下に仕事を投げたら後は放置する人間で困っています。


私の会社は自社サービスの開発・運営をやっています。
小規模な会社なので、インフラ専任のエンジニアは存在せず
プログラミングに加えてインフラのタスクも担当しています。
私は前職までで、インフラに携わったことはほとんど無く、
今の会社に来て初めて経験することも多いです。


私の上司から仕事を振られるときは、3ヶ月近くかかるような案件でも
「コレやっといて、よろしく!」と一言言われるのみで
事前のレクチャーや打ち合わせなどは一切ありません。

ググってもわからないような、会社やサービス特有のローカルな設定や
つまづきそうなところ、参考になる資料があったら、
事前に教えてくださいとお願いしても
「とりあえずやってみて、うまく行かないところがあったら
 すぐに何でも聞いて、適宜調整しよう」と言われ
事前に教えてもらえることはありません。


設計書(PJT概要/RFPやクラス図等)を作る文化もなく
チームの定期的なMTGもありません。
進捗が順調かどうかはコードを一通り書き終わって、
ソースレビューをお願いする段階になって
初めてわかると言った状況です。

例えるなら、設計無しドキュメント無しの
ウォーターフォールモデル型開発です。

さすがにこの現状はかなりマズイと思ったので、
自主的に設計しドキュメントに起こして、事前に確認してもらうようにしたり
また朝会を実施するようにお願いしたりして、実施されるようになりました。


わからないことは聞けば教えてはくれます。
ただ、タスク遂行にあたって困るのは
詰まったときに、何に詰まっているのかよくわからないこと
つまり、何がわからないのか、ということもわからないこと
タスクの取り組みの方針が合っていると確信していたが
実はあさっての方向を向いて、それに自分で気付くことができないこと
だと思います。ですので
「わからないことがあったら聞いて」だと不十分だと感じています。


私は、プログラミング経験はそこそこあるので
それで大きく困ることはないのですが
インフラ系タスクについては、経験も少なく
ミスをすると障害に直結するので困ることが多いです。

インフラ系のタスクも基本的に「これやっといて」と言われ放置です。
障害発生時の対応など、一応手順書はあるのですが
さすがに本番環境において、手順書を見ながら
いきなり一人でやるのは怖いので、レクチャーをお願いしても
「こんなの教えてもらって覚えるものじゃないんだよな」と言って
取り合ってもらえません。


また上司は、トラブルが起きると、担当者に対し
「もっとしっかり設計しろよな!」
「なにやってんだ!お前はサーバーオペレーション禁止だ!」のように
その担当者に全責任を負わせて、トラブル解決としています。
このような状況ですので、当然、チームとしてトラブルを防ごうという
取り組みは一切なく、似たようなトラブルが何度か起きている状態です。


上記のような状況ですので
インフラ系のタスクについては、独学でインフラの知識を身につけ
手順書を読み込んで、少しずつこなすしかありません。
ただ、タスクの割合から言って、プログラミングタスクの方がメインで
なかなかそういう時間も取れず、優先度も低くなりがちです。
また失敗を責められるということもあり、取り組むのを躊躇しがちだったところを
上司に「もっと積極性を出して取り組め」と言われました。

私が積極性を出していないのは事実ですが
こういった状況で、どうやって積極性を出せと言うのでしょうか

上司は以前に「できない人の気持ちがわからない」と言っていたので
何でこんな簡単なこともできないの?とりあえずやれば身につくでしょ?
というようなスタンスなのだと思います。
やれば身につくというのは、完全に同意できますが
ググってもわからないローカル設定を、教えてもらえなかったりするのは
どうすればええねん・・・という感じです。


次回の上司との面談時に、上記の話をする予定ですが
それに当たって皆さんにお願いしたいのは
この話は私の主観でお話をしてしまっているので
第三者の客観的な視点から見て
この問題の責任は(私も含めて)どこにあるか?ということを
お伺いしたいと考えています。

どうぞよろしくお願い致します。

投稿日時 - 2015-10-04 10:59:21

QNo.9058423

すぐに回答ほしいです

質問者が選んだベストアンサー

上司の方には技術力はあるんでしょうが、マネジメント能力が不足しているんでしょうね。
小規模な環境だと、マネジメントする立場の人も手を動かして開発をしなければいけなくなるので、どうしても開発に傾注してしまうとマネジメントが疎かになってしまいます。
また、上司の方の技術力が高く、一人で何でもこなせてしまう場合陥りやすい問題ですね。

一番の原因は環境です。
マネージャーにマネジメントに集中できる環境が用意されていないから、マネジメント能力が育たないんです。
会社としてもっとマネジメント業務を主体に仕事をするよう仕向けていかなければ変わらないでしょうが、小規模な所だとマネジメントだけに人を裂く余裕が無いのでなかなか変わらないかもしれません。
会社としてどこまで危機感を持つか次第ですし、仕事量が増えて規模が大きくなり人員が増えていくとちゃんとマネジメントしないと仕事が回らなくなり、結果としてキッチリ管理するようになって行くでしょう。

どこでも小規模なところは似たようなモノだと思います。
そういった環境について行けず辞めてく人は多くいますし、そういった環境に馴染んでしまって一人で何でもこなせるけど後輩を育てられない人になっていく人もいます。

投稿日時 - 2015-10-04 11:23:17

お礼

ご回答ありがとうございます。
状況を的確に捉えて頂いていて助かります。

実は私の上司は会社の創業メンバーの一人なんです。
上司の半年前までの口癖は

「俺は今までマネジメントなんてしてこなかったからできない。
 マネジメントするために会社作ったわけじゃないんだよな
 (だからマネジメントはしない)」

でした。ただ、それだとどうしてもカオスな状態になってきたので
朝会が誕生したという経緯があります。

私は過去に、

「上司さんのエンジニア系タスクは全部私がやりますから
 マネジメントの力を注いで頂けませんか?」

とお願いしたこともあります。返答は

「マネジメントするために会社作ったわけじゃないんだよな」

でした。要するに上司はマネジメントじゃなく手を動かしたいんですね。
ですので、今後もマネジメントを中心に据えることは無いと思われます。

マネジメントに不慣れだから協力して欲しい、ということなら
喜んで協力させてもらいます。
でも、不慣れだからしない、だとどうすることもできないです。

不慣れでチームマネジメントが行き届いていなのは仕方がないです。
そこを責めるつもりはありません。ただそれなら、
トラブルが起きたときに、なぜそのトラブルが起きたのか真の原因を究明して、
人に責任を押し付けるようなやり方だけは止めて頂きたいのです。
そうしないと、チームが崩壊してしまうからで、実際に崩壊しています。

第三者から客観的な意見を頂きありがとうございました。
この内容を元に上司との面談に臨みたいと思います。

投稿日時 - 2015-10-04 12:44:47

ANo.1

このQ&Aは役に立ちましたか?

1人が「このQ&Aが役に立った」と投票しています

回答(3)

ANo.3

 プログラミングに加えてインフラのタスクも担当の仕事をしているのですか。

教えてくれないのは当たり前です。上司は正しい。

上司のやり方が、最高ではない、だから、あなたなりのやり方でやれば、上司よりもいいものができるかもしれない。

上司は、謙虚なのです。

みんな、自分なりの工夫で結果を出してきた。

タスクは、データのファイルがあり、

それを使って、計算、判断をする手順をプログラミングして、

成果をだす。

手順を計画するのです。それには、タスクの内容を、マニュアル化できる知識が必要です。

タスクの内容を、マニュアル化できる努力が大事です。

また、それには、個性がでます。

上司の個性でないものを、見ようとしているのです。

単純労働よりも良いよ。

投稿日時 - 2015-10-05 23:12:00

お礼

お礼が遅くなってすみません。
ご回答ありがとうございます。新しい切り口ですね。

インフラの定常タスクについては、既に手順(マニュアル)があります。
マニュアルを改善するには、まず、マニュアル通りにこなせるようになる
ことが必要だと思うのですが、いかがでしょうか?

またマニュアルがあるからと言って、「これやっといて、よろしく!」と
言うだけで放置するのは、正しいやり方ですか?

プログラミングについては、
自社内で独自フレームワークを利用していますが
ドキュメントがあまりなく、どうプログラミングするのが、
おおよそセオリー通りなのか、というのも不明確なままです。
まずはそこの定義から始めないといけないと思うのですが、いかがですか?

投稿日時 - 2015-10-25 02:24:17

ANo.2

 質問すれば答えてくれるというのはあなたの職場は正常な状態です。質問にクイズが返ってくる職場なら問題なのです。一方、机に座って「さあ教えてください」という生徒は学校に戻るならいいですが職場での存在意味はどうなんでしょう。仕事の方向性に不安があるなら、現在の自分の方向を説明する資料を作りこれでいいですかと確認することです。世話してほしい、レールを作ってほしいという気持ちは分かりますがこれでは労働者の品質として外国人研修生との競争になってしまいます。我々には仕事ができる義務もミスゼロの義務もありませんがホウレンソウという義務があります。ホウレンソウが出来ない者はブラック労働者であり要りません。席が隣でもメールで質問すればエビデンスになるし口頭で質問するなら自分で記録を残すことです。結果の確認を求める時も、結果だけを提出してチェックお願いしますでは、上司は一から作業者の労働の跡をたどる必要があります。こんなのでは世話がやけることこの上ない。自分が確認したチェックシートを出して、これは自分で見ましたが確認の仕方はこれでいいですか、他に見るところがありますか、というようでなければ使いにくいということになります。

投稿日時 - 2015-10-04 11:23:36

お礼

ご回答ありがとうございます。
あなたがエンジニアの方かわかりかねますし
質問文も長いので見落としてらっしゃるのかも
しれませんが・・・

> さすがにこの現状はかなりマズイと思ったので、
> 自主的に設計しドキュメントに起こして、事前に確認してもらうようにしたり
> また朝会を実施するようにお願いしたりして、実施されるようになりました。

> ただ、タスク遂行にあたって困るのは
> 詰まったときに、何に詰まっているのかよくわからないこと
> つまり、何がわからないのか、ということもわからないこと
> タスクの取り組みの方針が合っていると確信していたが
> 実はあさっての方向を向いて、それに自分で気付くことができないこと
> だと思います。ですので
> 「わからないことがあったら聞いて」だと不十分だと感じています。

です。

例えば、コードレビュー時に、今までの成果を全て確認してもらうのは
大変だろうということもあって、自主的にクラス図を作って
見てもらうことにしました。
どういった意図で、どういうクラスが作られているのかを
事前に把握してもらえれば、コードレビューも楽になると考えたからです。

クラス図を見てもらってOKが出て、それを元にそれ通りに実装しても
コードレビューになって、クラス構成がおかしいと言われることがあります。
実際にコードを見てみて違和感を感じるのは仕方のないことですが
これはウォーターフォール型開発における「手戻り」にあたり
絶対にやっちゃいけないこととされています。

これ以上、細かく上司に確認を取るとなると
毎日毎時間のように上司にホウレンソウをしなければならなくなります。
(上司は自分で手を動かしたく、自分の時間を確保したいから
 今の方針を取っているわけで、細かいホウレンソウは望んでいないと思われます)

ですので、事前に打ち合わせがしたいんですね。
どのポイントで詰まってしまいそうなのか
だから、どのポイントを見て欲しいのか
どういう頻度でホウレンソウをしたら、お互いに取って心地良い状態なのか
こういうことを事前に打ち合わせしたいです。

また、さらに別の例だと、ミドルウェアの設定ファイルは
デフォルトのパスにデフォルトのファイル名で置いてあるなら
ググればそのパスを発見して、それを読んで理解することができます。
ただし、デフォルトから変更されているのであれば
どんな大ベテランでも、それを見つけることはほぼ不可能です。
ファイル名すらわからないわけですから。
なので、これは事前にどうしても教えてもらう必要があります。

ただ、こういうことすらも難色を示されているので
どうしたらよいですか?という質問です。

投稿日時 - 2015-10-04 12:26:00

あなたにオススメの質問