チーム開発でのメンバーとしての心得
新卒で現在の会社に入ってから2年チームメンバーとして働いてきて、自分がメンバーとして意識すべきことを独善的にまとめてみました。
気づいたことがあれば随時更新します。
まえがき
人にとっては「当たり前だろ!」みたいな内容なんでしょうが、疲弊してくると気付かずに自分本位の考え方をしてしまう自分への戒めと、体系的に整理するためのメモとして記事にしました。
記事の内容を当然だと感じる人はそのまま持続すれば良いと思いますし、あんまり考えたことなかったという人は参考にして頂ければ幸いです。
それでは、以下に意識すべきポイントとその解説・具体的な内容を記載していきます。
意識すべきポイント
- 単価の高い人に働かせない
- 自分が担当した仕事を忘れない
- 進捗が見える度に報告する
- 個人依存のリスクを最低限にしておく
単価の高い人に働かせない
解説
言葉の通りですが、ここで言う「単価の高い人」はチームリーダーやレビュアを想像してください。
組織的にはレビューなどを通してレビュア(単価の高い人)がメンバー(単価の安い人)をフォローする形になっていますが、
お金のことを考えるレビュアやリーダーがフォロー+本来の作業で長時間働く状況は良くない状況でしょう。
私の場合は、メンバーの仕事として降ってくる時には具体的な内容になっていることが多く、ただ作業するだけでは「実績を上げる」「業績を出す」ことが難しいと思っていました。
なので、今は単価の高い人からできるだけ仕事を剥ぎ取り負担を減らしてレベルの高い作業に集中してもらい、チーム全体として品質を上げることで効果を出そうと思っています。
具体的な内容
- 成果物のレビューをしてもらう前や一度してもらった後などに、レビュアが参考にしたドキュメント・知識や考慮すべきデータパターンを共有してもらう。
- 先に想定されるレビューの観点について品質を担保しておくことが大事。
- レビュアはそれが実現できていることの確認程度の負担で済むため、上記の想定から漏れたパターンがあるか気付く余力が生まれます。
- 環境の構築や、お便利なスクリプトを作成するなどしてリーダーの作業のフォローをする。
- 開発やテストで実際に触れているメンバーの方が細かい環境などの情報はリーダーよりも知っている場合があります。その優位性を生かして巻き取れる部分はフォローしてあげましょう。
自分が担当した仕事を忘れない
解説
どれだけ小さな改修でも、数ヶ月後に再度改修が入り「何でこうした?」となる場面が多々現れると思います。
基本はチケットに記載されているのが大原則ですが、
言葉や図で説明しきれないものもあるので起票したのが自分であれば経緯や関係者など含めて人に説明できる理解は当然ながら必要です。
私はこういう状況の時、改修内容がOK/NGよりも、その当時の状況から原因を突き止めて次に繋げていくことが大事だと思っています。
具体的な内容
- チケットに会話した内容を日付と関係者の名前を付けて記載する。
- 「いつ誰と話したか」で内容を思い出せることは多いです。
- チケットのコメントは他人に読み返されることを意識して状況を書く。
- 概要に書くレベルの内容ではなくともコメントに残すことでその時の状況や経緯が時間軸でわかります。
- 作業内容や打ち合わせした内容は別のメモとして残しておく。
- 自分が何を思って何をしたか日付とタイトルを付けて残すだけで思い出しやすくなります。
進捗が見える度に報告する
解説
基本の「キ」みたいなものですが、マネジメントが自分の進捗から工数を引き直すのも負担であることを意識しています。
色々な要因で進捗が早まる・遅れることは仕方ないですが、その場合に自分の工数をどこに割くか、どこで巻けるかまで提案するところまでがメンバーの範疇だと思います。
具体的な内容
- 自分の得意な領域・理解していない領域を把握し、タスクが後者の場合違うメンバーにスイッチしてもらう。
- あまり知らない領域に関してスイッチできるならすべきです。自分が他領域を学べると言うメリットはありますが、それは余裕があればの話で期日に間に合うのが最優先であることを忘れない。
個人依存のリスクを最低限にしておく
解説
どれだけ健康に気を遣っても体調を崩すリスクは常にあります。
「替えが利かない」とは聞こえが良いですが、メンバーレベルであれば上記のリスクを考えるとその状態は避けるべきです。
技術的なことはさておき、どんな作業をすれば良いのかくらいは明確に残しておく方が良いです。
具体的な内容
- 毎日チケットや仕様書の対応状況は小まめに更新しておく。行き当たりばったりで作業するのではなく、仕様書・そこまでちゃんと作成していなくともせめてToDoリストをまとめて「この先何をすれば良いか」を明確にしておく。
- 自分が倒れても引継いだ人が見て作業できる。
- まぁ倒れなくても準備してからやる方が普通に仕事早いと思いますが。
- 人が読んでわかるように少し意識することが重要です。
- 手順書作成の際などは簡単な動確を先にしたり、他人が読んで理解できる文章にする。図を入れるとか。
- 用意されたデータやファイルで上手くいかないと実施者が再度準備からしなければならない。それは避けるべき。
- 内容が属人化されていると最悪。「わからなければ○○に聞いて」とか。
あとがき
リーダーやマネジメントしている方にはまた違う観点からの意見が出たり、同じメンバーでも賛否あるのかもしれませんが自分の今の思想を今回言葉にしてみました。
他にもこんなこと意識してます、みたいな意見があるとありがたいです。
Author And Source
この問題について(チーム開発でのメンバーとしての心得), 我々は、より多くの情報をここで見つけました https://qiita.com/nogravityaoki/items/4449c669fc293a487283著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .