- ベストアンサー
新人プログラマが休業｜Aさんとの付き合い方をアドバイスしてください
- 入社2年目の新人プログラマが、先輩プログラマAさんとの付き合いに困っています。Aさんはプライドが高く、他人を見下す傾向があります。あるプロジェクトでAさんがバグを起こしたのにも関わらず、新人のBくんにデバッグを頼んで自分は知らん顔をしています。チームリーダはバグを検出したがAさんの行動には気付いていません。新人プログラマはどのようにAさんとの付き合い方を考えれば良いでしょうか。
- 新人プログラマのBくんが休業しています。新人プログラマ自身は自分の実装に忙しく、Bくんをフォローすることができませんでした。Bくんが休業した理由にはAさんからの無理難題が関係しているかもしれません。総務やリーダがBくんの対応をしてくれていますが、新人プログラマ自身は自分のせいでBくんが休業したのではないかと感じています。どのように対処すれば良いでしょうか。
- 新人プログラマが先輩プログラマAさんとの付き合い方に悩んでいます。Aさんはプライドが高く、他人を見下す態度があります。あるプロジェクトでAさんがバグを起こしたにも関わらず、Aさんは自分の責任を逃れるために新人のBくんにデバッグを頼んでいます。チームリーダはバグを検出したがAさんの行動には気付いておらず、新人プログラマはどのようにAさんと上手に付き合っていけば良いのか悩んでいます。
- その他（プログラミング・開発）
- 回答数6
- ありがとう数6
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
>繰り返される仕様変更＆仕様矛盾点の解決に時間が掛かり、設計・コーディング・テストの時間が取れなかったのです・・・。 >チームメンバは私を含めて若手が多く、大変なプロジェクトでした。 ま、時々耳にする典型的な失敗例ですね。 全体のスケジュールだけが強固に決まっているが、肝心な構想、概要設計、要件の洗い出しが不十分で 作業すればするほど不備や不足が明らかになり、方針が二転三転最悪の場合、誰も全体を把握し切れていない・・・・ そうなると、各自の役割分担などあっても無いようなモノで、よっぽど骨のあるリーダーがケツをまくって、広げた風呂敷を畳まない限りまともなモノにならない。 最後の最後は、人海戦術(使えるだけの若者を掻き集めて力ずく)で辻褄を合わせる。 >そうですね、リーダに報告を上げていたんでしょうか？そこは分かりません。 逐次1対1で無くとも報告はしないと、更に混乱に拍車が・・・・ ん～。そうなるとＡさんが悪いのかＢ君が駄目なのかという問題ではなく。 そういう状況に追い込んだ、プロジェクトのトップの責任が大きい。 結論としては、駄目なら駄目を白旗を早めに上げる。自分で抱え込んで自分を追い込んでしまったら自分が損という感じだろうか？
その他の回答 (5)
最終的にはプロジェクト反省会で、Aさんのバグ分析をしておくべきでしょう。単体テスト、Aさん環境でのマージテストで不具合がなく、テストチームの検証対象レビジョンによって一度合格後、当該コードの修正が行われていないか、ヒープやスタックを大量消費するコードでないか、コードレビューも重要です。また、バグ管理システムでのBさんへの再アサイン理由記録を確認したり、再アサイン時は一旦開発リーダーの了承を得るといった見直しも必要に見えます。 すぐに役立つものではないですが、誉田直子著『ソフトウェア品質会計』日科技連刊行、2010年のような好著がありますから参考になるのではと思います。
お礼
お礼が遅くなり、申し訳ございません。 （Okwaveのトラブルで投稿できませんでした） 回答ありがとうございました。
職場の事情もあるでしょうが、バグ管理システムを使ってテストチームは担当開発者にバグ修正をアサインするのが普通です。 ついで、納期終盤であれば、バグ修正分のコードレビューを実施して、同種原因バグも網羅的に調べて必要な修正を施しているか、副作用は生じないかなど点検します。 一応Aさん担当のバグ数が多すぎてBさんにも分担させた、あるいはBさん担当分のモジュールやクラス、メソッド利用のバグと判明していれば別ですが、普通はバグの温床Aさんに上級者をペアにして修正指導するか、Aさんをプロジェクトの補助に配置転換します。 バージョン管理システム利用の場合、Bさんがマージ後のコンパイル、一連のテスト不十分でチェックインしたせいでAさんのコードの正常動作を妨害した可能性もあります。 リセットされることを考えるとメモリーまわりのエラー（スタックやヒープの大量消費）、キャストエラー、データ型選択エラー、初期値設定ミス、メモリーリーク、オーバーフロー、アンダーフロー、例外処理エラー、オーバーライドなどが候補なので、必ずしもAさん担当範囲でのバグと限らないかもしれません。
お礼
回答ありがとうございます。 履歴管理、構成管理をしていましたが、退行テストや類似バグの確認まで手が回らないような状況でした。 また、Aさん作成分を無効化した場合は、不具合動作が起きなかったため、Aさん担当分と推測しました。
- thunder-bird
- ベストアンサー率26% (304/1143)
リーダーがデバッグに掛かり切りになっていたらチームが機能しなくなります。 それが何故か分かりますか？ 分からないのなら、まだ青いです。
お礼
回答ありがとうございます。 リーダが具体的に何をしていたのかは分かりませんが、忙しいようでした。 リーダーに仕事が集中していたのかもしれません。
- trajaa
- ベストアンサー率22% (2662/11921)
>チームリーダは忙しく、バグを検出したことを知っていますがAさんの行動まで見えていません。 ま、別に行動を一々監視する必要は無いけど、バグが上がれば要因解析から対策検討、対策の結果確認、影響範囲の有無調査など一連の処理が必要でそのポイントポイントは、直接リーダーが聞き取りするか報告書の形で上げられる。 納入前って事は結構工程が進んでからの事ではないか？ 工程が後段になればなるほど、発生したバグに対する担当割りや対応の進捗状況把握は、詳細にする必要があり、それはリーダーの役割である。 周囲の配慮も当然必要であるが、そもそもの体制として問題があったのでは無かったか？ 誰か個人の責任というよりも、リーダーが雑務に忙殺された体制の問題ではないか？ Ｂ君も、無理を言われたからって来なくなっちゃうのもどうか？ 困っているなら、リーダーなり(リーダーが不甲斐ないのなら)上位の役職者に一言言えなかったのか？
お礼
回答ありがとうございます。 そうですね、リーダに報告を上げていたんでしょうか？そこは分かりません。 繰り返される仕様変更＆仕様矛盾点の解決に時間が掛かり、設計・コーディング・テストの時間が取れなかったのです・・・。 チームメンバは私を含めて若手が多く、大変なプロジェクトでした。
仕事を頼んだら休んじゃった ほっとけばいい
お礼
回答ありがとうございます。 たしかに話を聞けばそう思われるのは分かりますが、Bくんが頑張っていたのも知っているので、なかなか・・・。
お礼
回答ありがとうございます。 ＞作業すればするほど不備や不足が明らかになり、方針が二転三転最悪の場合、誰も全体を把握し切れていない・・・・ まさにその状況でした。