GENZITSU
commented
1 year ago エンジニアのためのマネジメントキャリアパス ~5章 チームの管理 ~
エンジニアのためのマネジメントキャリアパスを読んだので要点をまとめていく
エンジニアリングリードの職務
- チームの生産性を下げる要因を見つけそれを解消する
- 最も取り組むべき価値あるプロジェクトを見極め、そこにチームの力点を移動させる
- チームに必要な人員を確認し、人員確保のための計画立案および募集を行う
- チームメンバーに期待する能力や言動、成果を明確に伝え、こまめにFBを行う
- 製品ロードマップのスケジューリングおよび主要なリスクを把握する
- 技術的負債を察知し、解消にかかる費用対効果を経営陣に提示する
- 以上のことをこなしつつ、小規模な技術的な成果を上げる
管理者にとって最も大切なこと
- チームの人々の後押しをする
- 最高の技術力を持っている必要はない
ITスキルの維持
- 技術的な意思決定を主導する責任があるためITスキルはできるだけ維持する必要がある
- バグ修正や小さな機能追加を行うことで、技術的負債に対する感度を高める
- 何か新規実装する際に最適なルートを判断できるレベルまで各システムコンポーネントの理解を高めておく
機能不全に陥ったチームのでバック
- デリバリにこぎつけられない場合
- メンバーへの催促を厳格に行う
- ただし、本当にするべき時と控えるべき時のバランスを取る
- 自ら袖捲りをしてチームにハッパをかける
- 遅れている部分を担当しているエンジニアに現況を理解してもらう
- ツールやプロセスに問題がないか検討する
- 気軽にプロダクトのリリースができるような体制を組むと良い
- メンバーへの催促を厳格に行う
- 厄介な部下への対応
- 人間関係のゴタゴタは勇気を持って早めに対処する
- 必要ならば自分の上司に協力を仰ぐ
- 問題行動は見つけた時にすぐ諫める方が良い
- メンバーを異動させるという方法もありうる
- 人間関係のゴタゴタは勇気を持って早めに対処する
- 過労による士気の低下
- 職務時間の2割をシステムの持続可能性を維持するために割り当てる
- 外せない納期を控えた過労チームへの対処
- チームのチアリーダーとなる
- とにかくチームを支える
- 夕飯のピザを頼む
- 残業に最後まで付き合う
- なぜこうなってしまったかを分析し次回に活かす
- 機能はできるだけ絞る
- 現実的でない納期は延長する
- チームのチアリーダーとなる
- 協働に関する問題
- 他チームとの協働がうまくいってない場合、まず改善の意欲をこちらから見せる
- 他チームの責任者と定期に連絡を取る
- 自チームのメンバーからFBをもらう
- ただし自チームを前にして他チームを公然と批判するのはNG
- 自チーム内での協働がうまくいっていない場合
- チームで息抜きをする機会を設ける
- ランチ会やプレミアムフライデーなどを活用する
- チームで息抜きをする機会を設ける
- 他チームとの協働がうまくいってない場合、まず改善の意欲をこちらから見せる
同僚が自分の部下になってしまった場合
- 気まずい状況であることを認識して注意深く行動する
- チームの各メンバーの成功のため全面的な支援をする姿勢を見せる
- 自分の持っていた職責を他のメンバーに委譲する
- 大人な対応に徹する
チームの盾となる
- 外界のいざこざを何でもかんでもシャットアウトすべきではない
- チームの面々に成功のカギとなる目標を理解させ焦点を絞らせる
- 時折チームに持ち込むことで、プロジェクトのコンテキスト理解を向上させる
- プロジェクトのコンテキストを適切に理解させることはメンバーのモチベーション向上につながる
- チーム外のよからぬ情報をシャットアウトしないようにする
- 遅かれ早かれメンバーには伝わるので、要らぬ不信感を生んでしまう
- そのような情報は明快かつ冷静に伝えることで安心させる
- チームメンバーの親になったわけでないことを肝に銘ずる
- メンバーを敬意をもって接するべき大人である
チームの意思決定を主導するコツ
- 管理者に与えられた権限は最終的な意思決定を下すものではなく、意思決定を主導することである
- 「データ重視」の文化を構築する
- 顧客に対する共感を高める
- 顧客を深く理解することで、コンテキストや何に注力すべきかを把握できる
- 将来を見据える
- 将来の見通しや可能性を常に模索する
- 最新の技術トレンドを把握する
- 定期的な振り返りを実施する
チーム内の対立をコントロールするコツ
- コンセンサスや投票に頼らない
- メンバーによってスキルや知識も異なるのでろくなことにならない
- 管理者が決定に対する責任から逃げてはいけない
- 意思決定から個人的な要素を排除する
- 意思決定の際の評価項目や、プロセスを規定しておく
- 爆発寸前の問題に見て見ぬフリをしない
- 日頃からメンバーに目をかけ、問題に早めに対処する
- 本当に対処すべき問題に焦点を絞る
- 今後も続く問題か、チームの生産性を下げている問題かを見極める
- 他チームに責任転嫁してはいけない
- 優しさよりも親切を心がける
- 対立を避けたい恐怖心を勇気をもって克服する
- 自分の言動を定期的に振り返る
チームの結束を見出す人の対処
- 管理者はチームの心理的安全性向上を目指すべきである
- そのためには個々のメンバーを一人の人間として理解するように努め、親近感を持って接す流ようにするべきである
- 心理的安全性を下げる人たち
- ブリリアントジャーク
- 技術的には優秀だが、自己中心的で、辛辣な物言いや同僚にたいするいびりなどがひどい傾向がある
- この手の人は初めから雇ってはいけない
- メンバーに対して好ましくない言動をしたらすぐに冷静に公然と拒否する
- ただし、自分に向けたものであれば1対1で話し合うべきである
- 秘密主義者
- 自身の進捗をマネージャーらに隠し事をするような人
- 情報隠しの上側にはなんらかの恐怖心が隠れている
- なんらかの原因がないか探ってみる
- レビューが辛辣であったり、チーム全体の心理的安全性が低い場合も考えられる
- なんらかの原因がないか探ってみる
- 他のメンバーが真似する前に、早めに対処する
- ブリリアントジャーク
- 無礼者
- 管理者やメンバーに敬意を払おうとしない人たち
- まずは本当にこのチームで働きたいのかどうかを確認する
- 働きたいのであれば、敬意を持って対応するように指導する
- そうでないなら、異動や退社の方法を模索する
管理者が担当するべきプロジェクト管理
- 管理者は四半期や半期の計画を立てる際に、自分のチームがプロジェクトをこなせるか、作業量はどれほどかといった見積もりを求められる
- 即席の見積もりと具体的な計画の両方を求められる
- 管理者は見積もりの応じてプロジェクトを選択と決定をする必要がある
- プロジェクト管理に関する経験則
- 日頃からチームの面々が作業の分割や大モカな見積もりを立てるアジャイル手法を取り入れる
- ただし管理者は週単位の管理ではなく月単位の管理にタイムスケールを移すこと
- エンジニア一人が一定レベルの生産性が見込める週は1四半期あたり10週ほどしかない
- システムの持続可能性維持に2割の時間を割く
- 2割の時間で抜本的な回収はできないが、旧システム由来の生産性低下を避けられる
- 万が一の時にこの2割の時間を割り当て可能になる
- 本当にやるべきことに範囲を狭める
- 必要であれば上にも下にも「ノー」を言う
- 即席の見積もりに関しては倍増ルールを
- ちょっとしたタスクであれば自分が見込んだ時間の倍を提示する
- 2週間以上かかりそうなものは、数字を出すものの、妥当性を確認するための時間を求める
- タスクを厳選した上でチームメンバーに見積もりを依頼する
- ただし管理者は週単位の管理ではなく月単位の管理にタイムスケールを移すこと
コメント
まだピンとくることが少ないが、今後のためにメモ
アクティブラーニングの手法を活用した物体認識における効率的なアノテーションツールの開発
隣接ピクセルに含まれるクラス種類数と予測ラベルのエントロピーを用いた不確実性指標RIPUを元にしたアクティブラーニングをアノテーションツールとして実装した事例の紹介
RIPUの計算方法
RIPUとはTowards Fewer Annotations: Active Learning via Region Impurity and Prediction Uncertainty for Domain Adaptive Semantic Segmentation というCVPR2022で提案された指標で以下のように計算できる
RIPUを元に部分的にアノテーションしたデータによる学習結果
画像全体の5%程度のアノテーションで全体をアノテーションするのと同等程度の精度を得ている
アノテーションツールへの組み込み
事前学習モデル or これまでアノテーションした結果を元に、予測ラベルを生成し、RIPUが一定以下の部分は事前にモデルがアノテーションし、不確実性が高いところだけ人によるアノテーションを依頼する
組み込みの結果
数十枚程度ではあまり効果がみられないが、1000枚ほどやるとかなりやるようになる。
コメント
アノテーションコストが特に高いセグメンテーションモデルに対するアクティブラーニングの手法を知れてよかった。 ざっくりとした実装例があるのも助かる。
出典