Odai「エンジニア立ち居振舞い」
への回答
過去に一度ブログに書いたネタだが、エンジニアが見る場所に書くほうが誰かの為になるかもしれないので忘れる前に転載しておく。不適切だと思ったら消すかも
転載元
以下転載
うまく整理できるかわからないが面白そうなので、思いつくままに書きなぐってこっそり差し込んでおく。 チーム構成によってメンバーへの接し方を変えるのがよいという当たり前の話になりそう。ときどきできてないこともある。
チーム構成が固くて分担できる場合
自分がマネージャーになる場合は、適宜タスク整理、チームのガイドライン整備、PRのレビュー、忙しそうなメンバーのサポートをする。 チームだからできることというのも多いので、うまくメンバーの能力にレバレッジをかけていく。
例えばドキュメンテーションの経験が長い人からはその話をちゃんと聞いて、現状とすり合わせてよさそうな方法を一緒に考える。 技術習得に熱心なメンバーがいる場合は、自分がやりたいのをこらえて「こういうのが主流みたいなんだけど着手できてないんだよねー」「このへん読むとなんかよさそうなんだよねー」みたいな感じでヒントを出しておくと自分よりもいい感じで調べて整理してくれたりすることがある。 自分にフロントエンド経験が全くなかったときは、より豊富なメンバーに完全にお任せしていた。
ただしいずれにしても、各メンバーの裁量でどうにもならないところは自分が引き受ける。 要件ヒアリング、外注先対応、他チームとの調整（ミーティングアサイン含む）、SlackやQiitaやConfluenceなどチームにあったコミュニケーションツールの選定、スクラム・リリースフローの調整、アクセス権限整理、リソースのコスト管理、メンバーの手に負えない技術調査、他社の事例調査などがこれにあたる。
メンバーの強化したい領域も推移していくし、のっぴきならない事情で自分が引き継がないといけない場合もあるので、分担は暫定と考えて、折を見て各メンバーから話は聞いておく。 他人がやってくれるからと上流に行き過ぎて手が動かなくなるとチームの価値発揮・自分のエンジニアキャリア双方危うくなることがあるので、それは避けるようにする。同様に、自分のやったこともちゃんとどこかに残す。再現性重要。あとチームの冗長化重要（とくに自分が休暇とって動けなかったりするとき）。
エンジニアメンバー（あるいはエンジニアの理解者）が少ない場合
チームに自分が入った時点でドキュメントがない場合はひとまず要件・業務フロー・全体の構成・シーケンスあたりをざっと書いて整理するところから始める。 その後は、何やってるか外から見てわからない感じにならないことが意外と重要かも。 「よく知らないけどこれくらいでできるんじゃないの」と言われたら、「あーまたわかってないな」と言いたくなるのを我慢して、後で潰すことも考えてとりあえず設計して実装して何かしらの目に見える進捗を見せる。 プロトタイプと割り切って、書いたコードにあまり思い入れないようにする。 少し落ち着いた時にコツコツリファクタしたりインフラの置き換えをやるというように、緩急つける。 もし可能であれば、スタックは自分が使いやすいもの、あるいは将来新しい人が入ってきてもググれば分かるくらいのよく使われるものにしておく。
その他
いつかのRebuild.fmで「自分が技術的にはやりがいがないと思う仕事ほど、逆に感謝されたりする」という話があったような気がする。 自分の興味と周りの要望のバランスはどうしてもとらざるを得ない。 とはいえ、こういう理由からエンジニアはふとしたきっかけで虚しくなったり孤独になりやすいような気がする。 ということで、自分が何をやってるのかわかるようにすることは、チームだけでなく自分のためにもなる。 一緒に盛り上がれるエンジニアが周りにいない場合は、他の環境のエンジニアとランチするだけでも結構救われたりする（隣の庭の芝生は青くみえることも時々あるけど）ので、そういうのを避けないで参加するとよいと思う。