同僚の雑な仕事に対応するには 64
ストーリー by headless
対応 部門より
対応 部門より
本家/.「Ask Slashdot: How To Handle a Colleague's Sloppy Work? 」より
私は会社の先輩と新製品の仕事をしている。率直に言うと、彼の仕事は雑だ。実際に動作して処理は完了するのだが、エレガントさからはかけ離れており、大量の小さなミス(ささいなミスと考える人もいるだろう)があちこちにある。5～6ページで作成すべき図が1ページに詰め込まれており、命名規則には一貫性がまったくない。機能には影響しないものの、矢印が間違った方向を示していることもある。原因としては彼が忙しすぎるためで、それでも何とかすべてを完成させようとしているからだ。このような状況にどうやって対処するのがよいだろう。私はかなりの時間をリファクタリングに費やしているが、彼が何らかの手を加えるたびにやり直さなくてはならない。さらに自分がやらなくてはならない仕事もある。バグリポートや機能リクエストなどを送っているが、無視されている。彼と一緒に仕事をしなくてはならないので、雰囲気を悪くしたくない。私は細かいことにこだわりすぎなのだろうか。それとも、こういった内部的な品質は気に掛ける価値のあることだろうか。
原因がわかっているなら (スコア:5, すばらしい洞察)
原因を取り除けばいい。
彼が忙しいんなら彼の負担を減らすべきだ。
少なくともバグリポートや機能リクエストが無視されることはなくなるだろう。
それでも改善しないのであれば、そのときは正面から話し合う必要がある。
負担を減らしても仕事の質が上がらないということはあると思う。
雑な仕事で生じている問題はあなた自身の時間を削られることであるから、
別にリファクタリングを専門に引き受ける人材を用意すればいい。
#といっても人は用意できないことも往々にしてあるので、上司に相談じゃないかな？
Re:原因がわかっているなら (スコア:4, おもしろおかしい)
一行目を読んだ瞬間にうっかり粛清的な展開を予測してしまった。連休だというのにココロが荒んでるな…
Re: (スコア:0)
ですね、そこまでわかってるなら適切なスケジューリングができないマネージャーに対応するには、とでもすべき。
もしかすると予算配分ができない役員に対応するには、とかキャパを考えないで受注する営業にryとか派生する可能性もあるけど。
Re: (スコア:0)
マネージャや営業は問題があると認識してない可能性が大ですね。
雑なのは内部設計とか資料の類いだけみたいだし、2人チームとしてのアウトプットを見ればちゃんと整理できてるんだから品質の問題も出にくいだろうし。
問題があるとすれば、実は2人チームじゃなくて質問者の本業が他にあるとか、チームが変わったときに他の人ではフォローできないくらい先輩の作成物が酷いとか、外部影響のあるバグレポートまで無視されてるとか、そういう場合ですかね。
で、まずするべきことは、、組織にとってどういう問題があるかを整理することでしょう。
上に書いたような問題がない場合、もしかしたら、質問者がドキュメント整備をしてるいまの状態が組織にとってベストなのかもしれないんだし。
それでやっぱり問題があるなら、そういう問題があることを管理者に認識させるのが第二段階。
Re:原因がわかっているなら (スコア:2, すばらしい洞察)
マネージャ「雑だけどちゃんと動くコードをどんどん書ける奴と、細かいところまで気を回して修正できる奴。最高の組み合わせだと思うなぁ」
Re: (スコア:0)
マネージャや営業から「そうすることで、利益が出るんですか？」
と言われちゃうような環境なのでしょうね。
Re: (スコア:0)
正しいスケジューリングをしてない開発が問題なんじゃないの？
そもそも「品質」に対するコミットなくスケジューリングしてる時点でアウトでしょ。
開発ができるってんなら営業は信じるしかないだろうし。
…と言う見方もできるよね。
脊髄反射的に自分と違う世界に責任を押し付ける発想は、
視野が狭い人間の最大の特徴で最大の欠点だと思うんだ。
＃開発と営業を経験してると分かってくるよ。
＃この手の問題に関しては「どっちも悪い」ってことがね…。
Re: (スコア:0)
綺麗なコード・綺麗なドキュメントを前提としたスケジューリングが正しいとは限りませんからねぇ。
例えば、ドキュメントを犠牲にしてでも、より早くリリースしてシェアを取ることを重視しているのかもしれません。
Re:原因がわかっているなら (スコア:1)
「正しい」の意味により違ってきます。
小さなiPhoneアプリ等ではコードを見れば一目瞭然なので奇麗さが大事だとは思いません。コードが会社のメインの資産になるようなものであれば話が別ですが、その場合でもシェア獲得して早期利益を目指し廃れる前に事業や会社を清算する/売り抜けるのは戦略の一つでしょう。開発者だと短期的に事業を成功させ、開発停滞する前にその成果をもとに条件の良い所に転職するという方法はありです。
綺麗なコードやドキュメントは後々の機能拡張や保守が目的なので長期視点だとまずいでしょう。運が良ければ腐ったコードとドキュメントを元に開発を続けることができるかもしれないですが博打みたいなものです。アジャイルどうのこうのは大規模開発だとまともにできる人が少ないので期待しない方がいいでしょう。
「奇麗」の意味も人によって変わってきます。
人によってはコードと１対１レベルの仕様書があって初めて奇麗なドキュメントがあると思うかもしれませんが、他の人にとってその仕様書は意味のないゴミにしか見えないでしょう。
趣味のプログラミングなら自宅で無報酬でやろう (スコア:5, おもしろおかしい)
Re: (スコア:0)
おもおかがついてるけど、
先輩氏は本当にこんなふうに思ってるんじゃね
Re: (スコア:0)
または"会社の先輩"が書いているのかもしれませんね。
Re: (スコア:0)
日本の会社でプログラマやっていましたが、多少雑でも成果物が動作し仕事が速い方が上司から高く評価されていました。
雑だとされている先輩のほうが上司から高く評価されている気がします。
Re: (スコア:0)
そりゃ、仕事は修行でも芸術でもないですからね。
日本に限らず、どこでもそういう評価になるでしょう。
Re: (スコア:0)
私のところでもそうでした。
後でコードの汚さが問題になり別の人が長い時間を掛けて書き直しさせられていました。
人の尻拭いなんてしたくないから俺なら会社辞めるだろうな。
Re: (スコア:0)
「同僚の雑な仕事に困っています」と言う質問だと叩かれるかも？と思い立場を変えて質問しました。
私の行動が容認されてホっとしています。
・・・
はたして質問者は本当に後輩なのだろうか。
気にしない (スコア:4, すばらしい洞察)
雑なドキュメントやコードで具体的な支障が発生してしているのならば指摘すべきだとおもいますが、そうでないのなら自分の場合は相手の仕事は気にせずに、自分の仕事をやります。
本来ならプロジェクト側でドキュメントやコードの品質について規定があるべき(もしくは、品質について判定を下す人がいるべき)ですが、それが無いということは内部の品質については気にしていないプロジェクトなのでしょう。
Re: (スコア:0)
だよなぁ。
規定が無いならどうしても良いってことだし、レビューで問題になるでしょ。
自分はどうなんだろうか (スコア:3)
ときどき、こんな(上から目線に見える)のがあるけど、どうなんだろうか
やり方がちがうだけで結果は同じかもしれないよね
仕事は速くて雑が良い (スコア:3)
役割分担をすればよい。 (スコア:2)
彼に、まず書かせ、それのダメ出しと改善に集中すればよい。
時間がなくて雑だというのなら、平行して課題を確実にひろいあげてリストしてやるだけで
完璧なチームが作れる。
っていうかむしろ、それが質問者が最初から期待されている仕事なんじゃないのか？
彼は先輩。 (スコア:1)
先輩ってだけで自分が上司なのかもしれないが、自分でリファクタリングなんてしてないで、すぐに上司に相談すべきだ。
Re:彼は先輩。 (スコア:4, 興味深い)
同感です．
人の管理は，上司の仕事．こういう時こそ，いわゆるホウレンソウを徹底すべきだと思います．
”雑な同僚”だけでなく，自分だけで解決しようとしてる質問者にも問題がありそうです．チームワーク悪すぎです．
もしくは質問者は本当はそんなに困ってなくて，単に /. で愚痴りたいだけなのかも知れません．
Re: (スコア:0)
本家の話だし、他人の仕事は他人の仕事ってことで上司に投げてスルーするのが向こうの文化だと思ってたけど、違うんだろうか。
Re: (スコア:0)
アメリカだと（会社によって違うとは思いますが）現場の事は現場でって感じだから上司に投げたところで、
当事者同士でなんとかしろよ、って感じになるんじゃないんだろうか。
そういう状況だからこそのトピックなわけで。
Re: (スコア:0)
マネジメントは現場の仕事じゃないです。
なので、上司に投げるのが正しい。
現場で何とかしろってのは日本式。
Re: (スコア:0)
企業文化とか上司の人柄によるので一概に言えないんですが、こちらでは業務上の問題を上司に投げる（エスカレーションする）のは結構重たい事なんですよ。
なので、不満を溜める一方で、上司にエスカレーションするほどでもない問題とも考えているのじゃ無いですかね。
しょっちゅう上司とコミュニケーション取っていれば、そういった些細な事でも「個人的な相談」レベルで済むんでしょうけどね。
Re:彼は先輩。 (スコア:1)
「こちら」って、本家の人？
the.ACount
Re: (スコア:0)
アメリカで働いているので、こちらと書きました。
本家の方は殆ど見てないです。
Re: (スコア:0)
つうか、ドキュメントとかコードのレビューしないの？
してるならレビュイーでなくレビュワーを叩いた方がいいんじゃねーの？
ほんとに雑なのかな？ (スコア:0)
忙しすぎるって事は、優秀ゆえに大量の仕事を抱えてるんじゃないの？
タイミングが一番大事って言う仕事もよくある話。
枝葉末節にちょこちょこ口出しして、自分のほうが優秀だと
思い込もうとしてるんじゃないかと思っちゃうな。
全体の構成とかクラスの設計とかならともかく、命名規則ばかり
こだわる人だとちょっとwannabe臭がするなぁ。
Re: (スコア:0)
リスクの高い仕事が集中してる可能性もあるなと
実際の所妻帯者が取れないリスクの高い部分を独り者が背負うケースはあると思うよ
別に難易度の問題ではなく、評価が低くリスクが高い仕事が集中する可能性はある
優秀なプログラマなのでは？ (スコア:0)
>率直に言うと、彼の仕事は雑だ。実際に動作して処理は完了するのだが、
>エレガントさからはかけ離れており、大量の小さなミス(ささいなミスと考える人もいるだろう)が
>あちこちにある。
木を見て森を見ず、ということわざもあるが、時間がないのに
破綻せずに仕事をこなしているように思える。
エレガントさを追求しないのも、動いてナンボ、
命名規則が一貫していないのは、ロジックとは
無関係だからと、割り切っているからでは？
コミュニケーションの問題？ (スコア:0)
> 私はかなりの時間をリファクタリングに費やしているが、彼が何らかの手を加えるたびにやり直さなくてはならない。
同じコードベースを弄っているにしては、コミュニケーションが間接的な雰囲気があります。
これは、手を加えることを知る手段がなかったのか、あるいは、知ろうとしなかったのか。
拠点が異なる場合は、間接的なコミュニケーションしか選択肢がない場合もあるものの、
そもそも綿密なコミュニケーションなしで同時進行でリファクタリングというのは、非効率ではないだろうか？
やるべきはリファクタリングではなく、機能リクエストや直すべきバグを取捨選択し、
一旦”手を加えられる”モジュールをFIXするのが先なのではと思います。
質問者に問題があるように思える (スコア:0)
質問者は本来業務をしているのだろうか？
それが原因で先輩に負荷が集中しているような気もする。
Re: (スコア:0)
私は会社の後輩と新製品の仕事をしている。率直に言うと、彼の仕事は独善的だ。実際に動作して処理は完了するのだが、コードはエレガントを通り過ぎて断片化されきっており、大量の小さなライブラリ(美しい機能分割と考える人もいるだろう)をあちこちたらい回しされた後に、やっと本当の処理に辿りついたらしいことが分かる。
1クラスで実装すべき機能を5～6レイヤーのクラス群に分けているが、それでクライアントからの変更要求をうまく吸収できた試しがない。抽象化のために設けたAPIが仕様レベルで誤っていたが、全く使われなかったので機能には影響しなかったということもあった。
こういう感じだったりしてね。
雑な怠け者。これはプロジェクトマネージャーに向いている。 (スコア:0)
雑な働き者。これは処刑するしかない。
同僚に仕事が雑だと言われた。どうしたらいい? (スコア:0)
というストーリーを対抗して立てる。
# ちゃんと関連ストーリーに入っていて編集者珍しくGJ
Re:同僚に仕事が雑だと言われた。どうしたらいい? (スコア:1)
実は質問者が雑な仕事をしている本人というオチはなかろうか?
# 嫌いなママ友についての相談でそんなのがあった気がする・・・
これですか？ (スコア:1)
ねとらぼ [itmedia.co.jp]で話題になってました。
/*
その書き込み主は、いやみな成金趣味だよなぁ。
*/
蹴落とす (スコア:0)
そんな奴は邪魔。
仕事で失敗はしたくないので率先して蹴落としますよ。
Re: (スコア:0)
誰が誰を？
Re: (スコア:0)
ネタで煽ってるんだろうけど、時々いるよね、こういう風に自分のことしか考えてないヤツ。
チームで作業している意味ないじゃん。
「雑」の種類について (スコア:0)
コーディングがエレガントじゃないだのは、「雑」でもいい。
ぶっちゃけコードなんて動けばいいんだ。
設計書だの図面が「間違ってる」のは指摘して訂正しろ。ソレは「雑」でなく間違いだから。
「雑」という批判はいろいろな意味で間違い。
Re: (スコア:0)
基準のとり方でいかようにでもなるからね
人間関係にこれさえあれば万全なんて答えないから
とりあえずコメントは盛り上がるわな
Re: (スコア:0)
前半に関して。
その手の「雑」だから忙しいんじゃないの？
Re: (スコア:0)
仕様を満たしていて雑なコードは問題ない。
コーディング規約があるのにそれを満たしてないのは「雑」でなく「間違い」。
それは指令通り開発してないだけだから。
エレガントで、その部署の他の人のコードとスタイルが違うコーディングは趣味の世界でやってればいい。
Re: (スコア:0)
バグレポートを送っても対応できてないんですよ。いいの?
Re: (スコア:0)
別ACより。
元コメの所ではfixするかどうかは別の人の役割なんだと思います。
たぶん元コメの立場は雑用PGで、指令を出す人が他にいてその人が管理を行ってるんだと思います。
全てを完璧に行うのは非効率なのでモジュール化などちゃんとした人が行っていて混乱を局所的する仕組み、体制ができていれば
元コメのような雑用PGが何も考えずがりがりコーディングしていくというのは合理的でしょう。
Re: (スコア:0)
おっと、fixするかどうかの判断は、です。