はじめに
Insanely Fastで有名なコミュニティで記事が上がっていたので翻訳・共有します。(許可いただきました。)
元記事: The road to senior dev
今回は同記事の後半、TeamWorkに関しての部分。
前記事: 【翻訳記事】中堅エンジニアになるには(プロジェクト編)
以下翻訳
チームワーク
質問を恐れないこと
キミの同僚や、テックリードから無知なやつだと思わるのが怖いというのは分かる。
だが、いいチームというのは「納期通りにリリースすること」が大好きで、遅れとその原因が大嫌いなものだ。
だからキミが何かの質問をし損ねて、結果としてプロジェクトが遅れればそれはもう大混乱になる。
それよりは些細なことでも質問して、それを乗り越えて学んでくれた方がよっぽどマシだ。
リリースを恐れないこと
新人の内は、「終わりました」と言うことほどのトラウマ体験もない。
だが覚えていてほしいのは、キミたちは「リリースする」という単純明快なことに対して給料を貰っているんだ。
「終わりました」を遅らせる言い訳を探すくらいなら、リリースして、出てくる問題に対応して、
失敗と成功から学んで、怖くなくなるまで改善を繰り返していくべきだ。
経験豊富なチームメイトにリスペクトを向けること
テックリードの判断に納得できないこともあるだろう。
それはいいが、「テックリードが間違っている」と怒り心頭になる前に、以下を試して欲しい。
- テックリードに対して、その判断の理由を尋ねること。
- その判断に際して描いているビジョンを理解すること。
恐らく、キミが想像もしていなかった制約がビジョンの中にあるだろう。
その判断が間違っているにせよ正しいにせよ、反対されたからといってすぐに癇癪を起こすよりは、
テックリードの意思決定のプロセスを理解することの方がよほど価値がある。
盲従と反抗のバランスを取り、そして自分のケツは自分で守ること
こんな逸話がある。
ビジネスアナリストとしてあるプロジェクトに参画した際、私の担当は、ビジネスロジックに則ってストアドプロシージャを実装することだった。顧客の受け入れテストは中国で実施されて、テックリードがそれに参加することとなっていた。
ユーザの試験環境へのリリースの一週間前に、テックリードは私に「ビジネスロジックが間違っている、このように修正してくれ」と告げてきた。彼の言ったことは全くの的外れで、敬意を込めてそれを伝えたが、跳ね除けられた。
私は「内容をメールで具体的に送信して下さい」とお願いし、後で見つけやすいようメールにフラグを付けた。また、必要な時にいつでも使えるよう、ストアドプロシージャのバックアップを行った。
一週間後、中国での受け入れテストはパスをせず、テックリードから電話がかかってきた。「なぜこんな風に書かれたのか、誰の指示なのか」 私はテックリードの指示であることを説明し、メールを転送した。30秒後、彼は元に戻すのにどの程度かかるかを尋ねた。「手元にバックアップがありますので、すぐにでも」
時には、キミが正しくて、テックリードが間違えることもあるだろう。
こういったケースでは、「具体的な説明をメール、ないしその他の後から見られる手段で明文化してもらう」のが良い。キミの考えている方法を返信しておいても良いかもしれない。
どんな問題が起きるにせよ、キミは守られていて、正しいやり方は別で保存されている。
必要ないことと思うかもしれないが、上司が部下を見捨ててしまうこともあるので、ここはスマートにやることをおすすめしたい。
メールを返すこと
特に理由がなければ、礼儀作法として「ありがとう」だけで十分だから返信しよう！
「確認しました」だけでもいい。全く返信しないのとは、天地ほどの差がある。
以上翻訳
「リリースするためにお金をもらっている」のは刺さるなぁ……。終わりました、完璧ですということは怖いけど、100点満点で遅れるよりは(というか一度リリースするだけでは絶対に100点にならないから)60点70点でもまずはリリースをする、動かしてみるのが大事なのかもしれない。