上司との作業での問題点と対処方法
- 上司との開発作業で問題が発生しています。メインプログラムの設計仕様書が不明瞭で、上司の回答も曖昧です。また、コンフィグの作成やテストの際にも問題が生じます。このような場合、コミュニケーションを重視し、具体的な質問や仕様の共有を行うことが大切です。
- 問題点を解決するためには、上司との打ち合わせや共通の作業ルールの確立が必要です。また、仕様書や設計図の確認を徹底し、コンフィグの作成やテストの手順を明確化することも重要です。
- さらに、問題が続く場合は、上司や周囲のメンバーとのコミュニケーションを円滑に行い、解決策を共有することが求められます。また、自身のスキルや知識の向上にも努めることで、問題解決に貢献することができます。
- ベストアンサー
このような上司の場合、どのように対処しますか？
このような上司の場合、どのように対処しますか？ あるプロジェクトの開発で上司と私の二人で作業を行っています。 上司は、メインのプログラムを主に担当します。 私は、周辺のツール及び、メインプログラムで必要なコンフィグ作りを担当します。 しかし、作業を行うに当たり、かなり問題が出ています。 １．メインプログラムの設計仕様書がメモ書き程度の物で見ただけでは理解できない。 ２．上司に仕様を聞いても曖昧な言葉で「多分とか、機械を見ないととか、打ち合わせ必要とか」 言って質問に対して答えてくれない。 しまいには逆切れ。 そんなもん俺に聞くな！ と言う始末。 ３．そして、上司がプログラム完成、テストはしましたか？と聞いたらmakeは通ったから 大丈夫との事。 後は丸投げ。 ４．コンフィグを私が、作りテストを行うが正常に動作しない状態が発生。 それに対して質問すると、コンフィグが悪い。 標準の考え方でプログラムを作ったから大丈夫 と回答される。 ５．私としてメモ書きの仕様とプログラムを追っかけながら悩みに悩む状態。 時間を掛けていると、何でそんなにコンフィグで時間が掛かるのだ？と怒られる。 社内にいる人みんなに聞こえる声で叫ぶ。 ６．そして、一緒にテストを行いながら、デバックを行う。 その後、上司があ・・・と言う その後、ソフト修正。 ７．そんな感じで、一つづつ問題点を解決していくような状態です。 現場に行けば行ったで、テストを行ったが旨く動作せず。 １．旨くソフトが動かない。 ２．お偉いさんが集まってくる。 ３．上司が私に対して、ちゃんとテストをやったのか？と大声で叱咤する。 今すぐ確認しろ！ ４．そして、私がコンフィグを見直しで考えだす。 ５．時間が掛かっているのでお偉いさんが次第にどっへ行く。 ６．上司がコンフィグを見て、ソフトの修正を始める。 ７．ソフト入れ替え、と言った状態が続いております。 正直、辛い どうしたらいいかも分からない。 何か良い案がないでしょうか？ そのようなパターンを幾度も無く繰り返してます。 そして、今回もそれが来るのかと思うと憂鬱です。
- PGQA
- お礼率45% (14/31)
- その他（ビジネス・キャリア）
- 回答数3
- ありがとう数1
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
基本的に上司があてにならない場合、 かなりしんどいですが、事をスムーズ（穏便）に進めたいのであれば、 上司がやっていることを逐次チェックし、抜けがあるようであれば 指摘し、改善してもらうことになるかと思います。 （上司のやった作業を再チェックする為、自分の仕事＋上司の仕事で かなりしんどいと思いますが．．．。） 出来れば、その上司格にあたる人にも、内々に相談しておくと良いと思います。 文面から拝察すると、ＰＧレベルの上司の方かと思いますので、 その上司（例えばチームリーダ・ＰＭなど）の方が見えると思いますが。 状況が上層部にも伝わっていけば、何かしらの対策が打ってもらえるかも しれません。 現状を回りに伝える方法としてメールの活用も 有効と思います。 何かしら上司からの依頼に対する回答や、作業依頼を出したり、問題（リスク）を指摘したりする場合、 上司以外のメンバーにもＣＣで状況が分かるように（特に上司の上司に）回覧し、 責任の所在を明らかにしておくと、 理不尽な指摘や非難を受けた場合、反論することが出来る場合があります。 例えば、事前に自分がリスク指摘をしていた事実などの証拠として残すことが出来き 会議の席などで、反論する材料になります。 ひょっとすると、その上司も「いい加減なことをすると公衆の面前で恥をかかされる」事に 気づき、態度を改め慎重に作業するようになってくれるかもしれません。 私は良くこの手を使います。メールを印刷して部内会議で問題を公開し、 他メンバー・上長のいる前で回答をさせ、 責任の所在が上司にある事を回りに認知させました。 例１）リーダーが渡してきたメモを全員にコピー配布し、 「このプログラムの仕様ですが、メモ書き程度のものですので、製造に必要な情報が 不足しています。すみませんがもう少し詳細な指示を下さい。」 → 上司は本件に対し明確な回答を出さざるを得なくなるはずです。 例２）会議の場で上司に対し、○○のプログラムテストを行ったか確認する。 → 自分以外のメンバー（特に上長ＰＭなど）が聞いている。 公的な場で宣言した以上、上司は責任を持たなければならなくなるし、 後日、何か問題が発生しても上司の責任となるはずです（議事録があれば尚可）。 根本的な改善にはならないかも知れませんが、少なくとも 理不尽な指摘や非難を受ける回数は減らせると思います。
その他の回答 (2)
- K1301
- ベストアンサー率31% (16/51)
一番の問題は、あなたの上司が仕様書を正確に作れない（プログラムを理解してない？）事であると思われます。 社内の状況がよく分かりませんが、現状の問題点からの対策として以下のような案で解決できるでしょうか？ 素人考えですみませんが・・・ 案１・上司に仕様書をしっかり書かない事のリスクを説明の上、作業をお願いする。 案２・それらしい理由をつけて、別の人との作業をさせて欲しいと提案する。 案３・メインプログラムをあなたが作る。
- debukuro
- ベストアンサー率19% (3635/18948)
そういう環境で生き残った者が勝ちです 自分しか頼れるものはいないのです 幼稚園じゃありません 四面楚歌 耐えられない者は去れ そういう世界です
補足
そうですよね、私も耐えるしかないのかなーと 思っています、出来るだけ笑顔を絶やさず がんばってみようかと思います。
関連するQ&A
- 指示が180度変わる上司にどう対処すればいい？
上司の指示が無茶苦茶でひどいです ある資料を作っていて、ある部署のデータを例にしていたところ 上司「この事例、○○部にしろ」 オレ「え、いきなり資料の事例に出されたらその部署のヒトから、 なに勝手にサンプルにしてんだって言われますよ」 上司「例にするのは社内データで個人情報じゃないんだから 公開されても問題ない。○○部は折れの元いた部署だし 問題ない。修正しろ」 で時間かけて大幅修正後、翌日に資料の内部レビュー。 上司「なんで○○部を事例にしてるんだ？部門の許可取ったのか？」 オレ「え？（いや、あんたが昨日・・）」 上司「やり直せ。だいたいお前は普段から（以下詰めモード）」 こんな感じで、時には自分の意見を言いつつ上司の指示に従っては 後で180度逆のことを言われて、何度も同じ事を言わすなと怒られる。 自分のが仕事の理解が浅かったり、メモとってもメモ取りに必死で 覚えきれなくて理解漏れがあったりしてるせいで、メモに残してても 信用されない非があるのはわかってます。 だが、作業の遅れや、資料不備や手戻りを全部私のせいにされても困る わけで・・ 反論をその場でしたいが、上司が怒鳴ると萎縮してしまい反論できない。 オレはどうしたらいいのでしょうか？
- ベストアンサー
- 社会・職場
- 新米プログラマーです、アドバイス下さい！
ソフトハウスに入社して半年のプログラマーです。 ある専門分野のソフトを担当しています。そのソフトはドキュメントが メモ書き程度でほとんど無く前任者はすでに退職しています。 この状態で半年間やってきたのですが、ソフトの全体像がわかりません。この半年間は部分的な修正をしていたのでなんとかなったのですが この先どうしていいかわからなくなってしまいました。専門分野の担当者は私に不安を持っているようです。社内では私は仕様がわかっている 事になっていますが、実際ソースコードから仕様を把握する事は相当な時間がかかります。私としては、その担当者に仕様がわからないので、 教えて貰おうと考えていますが、社内ではそんな事をしたら相手を不安 にさせてしまうと考えているようです。小さい会社ですので、この担当 から降ろしてもらうと解雇されます。どうしたらいいでしょうか？ ベテランの方どうぞご教授願います！
- ベストアンサー
- SE・インフラ・Webエンジニア
- プログラムのテスト仕様書で使えるCMSについて
お世話になります。 今まではExcelでテスト仕様書を作成してテストを行っています。 ネット上でテスト仕様書の内容を追加、修正、削除ができるようなCMSを探していますが・・・ プログラムのテスト工程をやりとりできるような使い方ができるCMSはあるのでしょうか。 例えば下記のような表が作成出来て、みんなで更新ができるみたいな 番号 | テスト項目 | テスト結果 | ステータス | 担当者 | 備考 -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | -------------------------------------------------------------------------------- | | | | | 知識不足ですみませんがプログラム開発時で使えるCMSがあったら教えて下さい。 宜しくお願いします。
- 締切済み
- オープンソース
- 上司の指示に関して
上司の指示に関して質問があります。昨日上司より、夜勤中に休憩室の掃除をしろと指示を受けました。休憩室を掃除する時間もあり、する気もあったのですが、大きな荷物をどかした後だったので埃がけっこう目だってました。掃除機を使うにしても時間が時間なので使用できず。夜勤終了後に自主的に掃除をしていました。 ここからが質問です。掃除を夜勤後にしていたことに上司がマジ切れしました。一応理由を書いたメモを上司の目のつくところに貼っていましたが、見たか見てないのか？とにかく凄い剣幕で怒っていました。これは上司の命令を無視した僕が悪いのでしょうか？(上司とはフロアが違うため、やむを得ず口頭ではなく、メモにしました。) 言い方を変えれば、「上司の命令を無視し、自己判断で勝手な行動をした。事が事なら、会社に損害を与える！」ということになりかねませんが……今回の件はたかだか掃除機ですし…なんか釈然としません。 どちらが間違っているか？というよりも上司があそこまで切れた理由を知りたいです。第三者から見ていかがでしょうか？
- ベストアンサー
- 社会・職場
- 「テスト仕様書」の運用について ・どういう手法として知られているか
業務系のソフトウェアを開発・販売・保守している会社にいます。 今回、プログラム開発の過程に「テスト仕様書」というものが導入されることになりました。 通常、プログラマレベルでのプログラムの作成→担当SEもしくはその他の人がそれを検収の上ユーザに納入、という流れを取っています。 （ここにいう「作成」「納入」というのはシステム全体を納入するといったことではなく、例えば数十以上の実行ファイル等でできあがっているシステム全体のうち、実行ファイルを1コ追加する、といった単体レベルの話です。） 「テスト仕様書」の運用方法なのですが、 (1)通常の仕様書と同時に、あるいは少し遅れたタイミングでプログラマに渡す。 (2)稼働中のユーザと同じ動作環境のもとで、ごく限られた条件と、その条件によって出てくる予定の出力結果が提示してある。…帳票などでは範囲を広く指定すれば大量の出力結果が得られるわけですが、例えば「得意先は○○、商品は○○」の場合は「金額は○○円」と出てくる筈、というふうにごく一部だけが示してある。 (3)テスト結果をプログラム作成の終了と同時に、場合によっては途上で担当SEなどに早めに提出する。 …というものです。 趣旨としては、 (1)「テスト仕様書」の添付により、もともとの仕様書の不備を明らかにしやすくなり、かつ、プログラマの仕様の理解における勘違いを早めに正す。 殊に、誤解を招きやすい仕様の箇所に重点を置くと効果を発揮する。 (2)作成されたプログラムの本検収に取り掛かる前に一部でもテスト結果を早めに得ておくことで、検収やそれ以後の作業の迅速化を図る。（おもむろに取り掛かった本検収でプログラムの不備が初めて明らかになるより、ごく一部のテスト結果をちらっと見るだけでそれが間違いであることが分かればすぐに修正を依頼することができる。） (3)一部のテスト結果が正しければ全体も正しいという蓋然性が高まるので、プログラムの品質の向上に繋がる。 …というものです。 趣旨は良く分かりますし、特に「一部だけを早めに摘み食いする」という(2)の着眼点というのは面白いと思います。また、「得られるべき結果」を予測しておくための労力（言い換えれば「テスト仕様書」を作成するための時間)はかかりますが、あるべき出力結果を考えるというのはどのみち後でしなければならないことなので全体としての工数は変わらないという考えもあるようです。 …こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。 書店で立ち読みなどをして文献を探したのですが（笑）、該当すると思われるものはありませんでした。 手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。
- ベストアンサー
- SE・インフラ・Webエンジニア
- 議事録作成
最近、会議の議事録を担当することが多いです（月２～３回） この１年、メモ帳を持ち歩き手書きでメモし、会議後に１時間ほどかけて タイピングしてまとめていました。 ですが、この１時間を３０分くらいに短縮したいです。 そこで考えたのが、メモで書き取るのではなく、会議場にＡ４パソコンを持ち込んで 直接仕上げる方法です。 もちろん会議後、修正なり追記なりはするつもりです。 これを上司なり先輩に相談すると、「生意気」にうつるでしょうか。 それ以前にメモ帳で会議をメモし、会議後、まとめるほうがよいのでしょうか。
- 締切済み
- その他（ビジネス・キャリア）
- エンジニアをしています。
エンジニアをしています。 ある仕事（仕様書の作成）で、 上司のレビュー受け後に仕様書修正するという 修正作業の一部（6月中旬までに完了の必要がある修正作業の全体の約15～20％ まだ時間があるので6月に入ってからでも時間的に対応可能だった作業）を、 上司からの、修正作業の一部をまきとってくださるという言葉があり、甘えてしまった部分もあり、 先週末までのスケジュール（仕様書作成）が、遅延しておりませんでしたので、 先週は、6時30分～7時30分の間で、退社した日が2日ありました。 退社後に、下記のメールが来ました。 --- 現在私の方で修正をしていますが もともとは○○さんが手一杯であるであろうと思い こちらで修正する事としましたが ここ数日ですが、定時過ぎ、一時間超え位で帰っているようで 余裕があるのであれば、○○さんの方で修正してください。 私も時間に余裕があるわけではないので。 --- 現在の上司は、女性の方です。 残業時間は管理されていません。 また会社規模が小さいこともあり、勤怠管理もありません（タイムカードがありません）。 残業代は、年俸制のため現在のところ、まったく出ていません。 ・上司が巻き取ってくださるといってくださった言葉に対して、 自分で担当いたしますと回答すべきだったのでしょうか？ ・スケジュール通り業務が進んでいても、 やはり稼働日は、上司が退社されるまで確実に社内に残ることで、 業務に対する姿勢を見せた方がよいでしょうか？
- ベストアンサー
- SE・インフラ・Webエンジニア
- プログラマに渡すテスト結果に載せるべき項目を教えて下さい。
表題の通り、ソフトのテストをして結果をプログラマに渡したいのですが どんなフォーマットで渡せば良いのか、分かりません。 （私はプログラムは全く出来ません） どなたか、お力を貸して頂けませんか？ 詳細をお話すると、ソフトのテストを頼まれました。 動作確認をして、要修正箇所（エラー発生箇所）を表にして渡してくれ、というものです。 プログラマが超多忙のため、急遽できそうなことを手伝うことになり、 テストを頼まれた次第です。 テストをするソフトは、OS上で動作する業務システムです。 プログラム言語が何かは分かりません。 既に全体が完成していて、ユーザー使用のインターフェイスから、 実際の業務と同じ動作をし、不具合が出た箇所を表にして欲しいというものです。 プログラマに渡す一覧には、最低限何を記載する必要がありますか。 また、これも記載されていると親切、というものはありますか。 実際の現場で使用しているフォーマットのような物があれば、 参考程度にその項目を教えていただきたいのですが。 本来ならば、依頼してきたプログラマに聞くべきなのですが、急ぎの仕事なので そのプログラマと連絡がつくまで待っていると、テストが終わらなそうで困っています。 頼まれた時には「分かれば、どんなのでもいい」と言われたのですが 実際やり始めてみると、エラーが出たときエラー番号はメモした方が良いのか、 ダイアログの文面まで知らせるべきなのか、 エラーが出なかった箇所は表に載せなくていいのか、など疑問が出てきました。 以上よろしくお願いします。
- ベストアンサー
- その他（プログラミング・開発）
- 上司への報告が遅れます。どのタイミングで伝えたら？
コールセンターで業務をおこなっています。 今の時期はいちばん忙しく電話が鳴りっぱなしな状態です。 私の他に２人のコールセンターがいますが他の業務がありなかなか電話を取ってくれることがありません。 他の業務ももちろんですがメインはコールを取りながら（基本三回以内で）他業務に取り組みます。 言い訳になりますが私の取る回数が多いのでもちろん上司への報告が多くなります。 上司へ報告しなければならず何時何分に誰からどのようなクレームがあったかを書類に記入して報告しなければならないのですが時間が経っていると怒鳴られる状態です。 当たり前のことなのですが。。 忙しい状態のなかで口頭で伝えたいのですがメモで伝えてるのですがきちんと書類はわかりやすく記入しなければならず、そのぶんまた時間が経ってしまいます。 いざ課長へ報告しようと会議やミーティングで席をはずしてることも多く報告のタイミングがままならない状態です。 そういった時は同じ課の係長へ伝えるのですが基本、その課の課長へ伝えなければいけないとのことです。 私の要領が悪いのがいけないのですが。 こうして書き込みしていても自分が情けなくなります。 もう怒られると人格まで否定されてるようで辛いです。 よろしければアドバイスいただけたらと思います。 よろしくお願い致します。 アドバイスいただけたらと思います。 よろしくお願いいたします。
- ベストアンサー
- 社会・職場
- このような上司は普通ですか？
部下という観点から書きます。 上司（以下A）と僕は同じ課の同じ係の上司部下という関係です。 Aはあるお客さんから依頼があり、それを達成するためのプロジェクトを立てました。 そのプロジェクトは自分の会社内だけでは達成できないので別の会社とも連携で進めていく予定でした。 しかしその別の会社は出来ませんとの返事があったそうで、打ち切りとなり、お客さんの元へその旨を伝えました。 なんで出来ないのかと不思議に思ったAの部下（以下B。←僕ではないです）がその会社の担当者と話をすると「いや出来ますよ」と全く逆の返事でした。 そのことをBがAに話したところ「一回断ったしなぁ」と言い、放置しました。 しばらくして同じお客さんからやっぱりなんとかしてもらえないかと要望があり、Aが「あの会社と連携出来るってことだけど、お客さんに一回断ってるしなぁ。。。別の方法でいけるか聞いてみよう」ということで少し角度を変えて連携してもらえないか相談するとOKとのことでした。 それでAがその会社に協力依頼文のようなものを提出しにいくはずだったんですが、僕が代わりに持って行きました。 僕も内容をほとんど把握していない状態でしたが「持って行くだけだから。話はついてる。」とのことだったのでただ持っていきました。 するとその会社の担当者から「これだと全然駄目。別の書類で・・・ここはこうで・・・またこれがこうでこうなってるからこうしてくれ。関係ないけどあの件について・・・」と要望があり、わけがわからないながらもメモをして話を持ち帰りAに報告しました。 するとAは「口頭で話をしたときはこれでいいって言ったのに。しかも追加注文してくるなんて・・・」と若干我を失ってました。 加えて「一度どうしたらいいか詳しいBと相談してくれ。」とのことでした。（担当のAが相談すべきなんじゃ・・・？） 相談したところ、結論を言いにいくと「もうお前らに任すよ。」とのことでした。 そのあとAとAの部下（C）とが外出したのですが、そのときの会話でAが「もう俺無理。あの会社の担当者があーでこーで『悪い』。こんなん神経質な俺がやってたら駄目だ。もう○○（僕）がメインでBがサブとなってやってもらうよ」 と言ってたそうです。 これって丸投げな気がするのですが、上司ってこんなもんなんですか？ 僕も入社１年半で、まだまだ分からないことが多い中でのいきなりの担当者変更です。 文句も言えず、Bに相談しながらやってます。 一応B（割とベテラン）の意見としては「丸投げ。途中で担当者変わったら駄目だと思う。」とのことです。 Aは他にも「あれやれこれやれ」と雑用を命じ、一番辛かったのはAの弁当の残りの後処理をしろといわれたこともありました。 他には休日に急遽雑用仕事が入るときがあるのですが、僕に全部行けといいます。「俺らもやったんだから。お前もやらないと自分に部下ができたとき、同じこといえないぞ」ということでした。（Aの入社時期からすると絶対やってません） そうなんですか、といい結局僕が全部やってます。 このような上司は普通なんでしょうか？ これくらいなら「はいはい」と言ってるしかないんでしょうか。 もし僕が上司になったらこのようなことを部下には絶対しません。 職場で済ました顔でこのようなことを言ってくるのでイラッとしてしまいます・・・
- ベストアンサー
- 社会・職場
補足
ありがとうございます、参考になります。 ですが以前に何度か色々な案を言った事があります。 案１ 【結果】 回答Ａ：時間が無い、そんな暇は無い！ 回答Ｂ：この仕様書の何が分からないんだ、 分からんかったらソフト見ろ、ソフトが仕様書だ！ 案２：この時期に他の現場スケジュールがあるので無理なのですが・・・ 【結果】 回答Ａ：そんな物、他の人間に回せばいいだろ？ 回答Ｂ：このコンフィグが完成できるならその現場いけば？ 案３：メインプログラムを私が作る、完全に引き継ぐ 【結果】 その開発プログラムを覚えて、引き継いだ結果 その上司が作り上げた バグが数ヶ月ごとに発生する状況 処置をするが未だに新しいバグが 現れる、モグラたたき状態です。 そんなのが６アプリケーション分 不具合対応に追われる状態です。