パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

同僚の雑な仕事に対応するには」記事へのコメント

  • 原因を取り除けばいい。

    彼が忙しいんなら彼の負担を減らすべきだ。
    少なくともバグリポートや機能リクエストが無視されることはなくなるだろう。
    それでも改善しないのであれば、そのときは正面から話し合う必要がある。

    負担を減らしても仕事の質が上がらないということはあると思う。
    雑な仕事で生じている問題はあなた自身の時間を削られることであるから、
    別にリファクタリングを専門に引き受ける人材を用意すればいい。

    #といっても人は用意できないことも往々にしてあるので、上司に相談じゃないかな?

    • by Anonymous Coward on 2013年05月04日 19時05分 (#2375299)

      ですね、そこまでわかってるなら適切なスケジューリングができないマネージャーに対応するには、とでもすべき。
      もしかすると予算配分ができない役員に対応するには、とかキャパを考えないで受注する営業にryとか派生する可能性もあるけど。

      親コメント
      • by Anonymous Coward

        マネージャや営業は問題があると認識してない可能性が大ですね。
        雑なのは内部設計とか資料の類いだけみたいだし、2人チームとしてのアウトプットを見ればちゃんと整理できてるんだから品質の問題も出にくいだろうし。
        問題があるとすれば、実は2人チームじゃなくて質問者の本業が他にあるとか、チームが変わったときに他の人ではフォローできないくらい先輩の作成物が酷いとか、外部影響のあるバグレポートまで無視されてるとか、そういう場合ですかね。

        で、まずするべきことは、、組織にとってどういう問題があるかを整理することでしょう。
        上に書いたような問題がない場合、もしかしたら、質問者がドキュメント整備をしてるいまの状態が組織にとってベストなのかもしれないんだし。
        それでやっぱり問題があるなら、そういう問題があることを管理者に認識させるのが第二段階。

        • by Anonymous Coward on 2013年05月05日 14時27分 (#2375563)

          マネージャ「雑だけどちゃんと動くコードをどんどん書ける奴と、細かいところまで気を回して修正できる奴。最高の組み合わせだと思うなぁ」

          親コメント
        • by Anonymous Coward

          マネージャや営業から「そうすることで、利益が出るんですか?」
          と言われちゃうような環境なのでしょうね。

        • by Anonymous Coward

          正しいスケジューリングをしてない開発が問題なんじゃないの?
          そもそも「品質」に対するコミットなくスケジューリングしてる時点でアウトでしょ。
          開発ができるってんなら営業は信じるしかないだろうし。

          …と言う見方もできるよね。

          脊髄反射的に自分と違う世界に責任を押し付ける発想は、
          視野が狭い人間の最大の特徴で最大の欠点だと思うんだ。

          #開発と営業を経験してると分かってくるよ。
          #この手の問題に関しては「どっちも悪い」ってことがね…。

      • by Anonymous Coward

        綺麗なコード・綺麗なドキュメントを前提としたスケジューリングが正しいとは限りませんからねぇ。
        例えば、ドキュメントを犠牲にしてでも、より早くリリースしてシェアを取ることを重視しているのかもしれません。

        • by Anonymous Coward on 2013年05月05日 10時25分 (#2375497)

          「正しい」の意味により違ってきます。

          小さなiPhoneアプリ等ではコードを見れば一目瞭然なので奇麗さが大事だとは思いません。コードが会社のメインの資産になるようなものであれば話が別ですが、その場合でもシェア獲得して早期利益を目指し廃れる前に事業や会社を清算する/売り抜けるのは戦略の一つでしょう。開発者だと短期的に事業を成功させ、開発停滞する前にその成果をもとに条件の良い所に転職するという方法はありです。

          綺麗なコードやドキュメントは後々の機能拡張や保守が目的なので長期視点だとまずいでしょう。運が良ければ腐ったコードとドキュメントを元に開発を続けることができるかもしれないですが博打みたいなものです。アジャイルどうのこうのは大規模開発だとまともにできる人が少ないので期待しない方がいいでしょう。

          「奇麗」の意味も人によって変わってきます。

          人によってはコードと1対1レベルの仕様書があって初めて奇麗なドキュメントがあると思うかもしれませんが、他の人にとってその仕様書は意味のないゴミにしか見えないでしょう。

          親コメント
      • by Anonymous Coward

        スーパーマネジメントができるマネジャーならば別ですが、この世の中、そんな権限は与えられていない、与えられた材料だけでミッションを達成することを命じられた、みなしマネージャーが多いですからね。
        要するにマネジメントをするのが仕事ではなく、責任を取らされるだけの存在です。

        人が足りなくても人員を増やしてもらえない。
        スケジュールを十分にとりたくても顧客がそれを許さない。
        時間外作業を重ねると上からも下からも批判される。
        しょうがないのでマネージャー自身が過酷な残業を引き受けて過労死する。

        マックやユニクロの店長も同じようなもんですね。

        問題の同僚とやらも、そういう状態なんじゃないのかな。

      • by Anonymous Coward

        こういうストーリーでは脊髄反射で「マネジャーガー」というコメントが涌くけど、
        何もかもエライ人にやってもらおうという姿勢は問題があるとは思わんかね?

犯人はmoriwaka -- Anonymous Coward

処理中...