リーダーは何をやっておくべきか？
ふじしろメンバーポジションでリーダーを見ていて感じたこと。
事前にやれると良さそうなこと
・参画するメンバーのレベル感把握
リーダーポジションが最初にやったほうが良さそうなこと
・業務範囲の明確な説明（期待する業務範囲、サポートできること/できないこと）
・委譲する権限レベルのすり合わせ（デリゲーションポーカー）：メンバーとリーダーのスキルレベルのバランスに応じて決める必要がるため。
開発中に意識したほうが良さそうなこと
・メンバーの開発時間を確保する
・無駄な会議を減らす
・ロードマップを管理してメンバーが迷わないようにする
・ロードマップ通りに開発を進めることに集中できるようにする
・タスクの優先度付け
・レビュー最優先とか
・ルール（仕組み）策定
・レビュアーの自動アサイン設定
・git hub projectの設定
相談とか
・メンバーが迷ったら決断する
・後からでも修正する
・短くてもいいので1on1をする
ふじしろ今の自分の結論は、「メンバーが実装に集中できる環境を作る」のがリーダーのメインタスク。
そのために何ができるか、ということを考える必要がありそう
・責任範囲/業務範を明確にする
・これは自分の仕事か、リーダーの仕事か、わからないと判断コストがかかる
・ゴールを明確に示す
・最終的にどういう状態がゴールなのかわからないと、このままでいいのか、他にもやるべきことがあるのではとメンバーが不安になる
・タスクの優先度を判断する
・
ふじしろ個人的アンチパターン
・ゴールを明確にしない
・何度も繰り返しゴールを伝える必要がある。しないとメンバーが各自で優先度ややるべきことをを判断できない。
・現状を明確にしない
・ゴールに対する現在地を伝えないとメンバーが路頭に迷う。
・こちらもゴール同様にやらないとメンバーが自発的に動けない
・また、現在地がわからないと今が踏ん張りどきなのか、まだ余裕があるのかわからなくなるため、余裕があるのに長時間稼働してしまったり、逆に踏ん張りどころなのにすぐに帰ってしまったりする。
・それらはリーダーに跳ね返り、リーダーからメンバーにまた跳ね返る
・メンバーの作業環境を整えない
・ここで言う作業環境は、「メンバーが各自のタスクのみに集中できる環境」のこと
・不要なMTGを減らす
・ロードマップを整理する
・レビューのルールを決める
・開発の共通基盤を整える
・などなど
・メンバーに任せるけどヘルスチェックしない
・メンバーは大丈夫と思って進めていたことが後々のチェックでひっくり返ると双方に大きなダメージが入る
・仕組みではなくメンバー各個人のパワーに重きを置く
・特定の人にタスクが集中する。また、その人が捌ききれなくなったときにスケジュールが崩壊し始める
・状況改善をメンバー任せにする
・メンバーに任せたうえで進捗が遅延しているなら介入が必要。既に内部で解決できなくなっていることは「頑張りましょう」では解決できない。
・リーダー本人がタスク持ちすぎる
・これまで書いたすべてのことができなくなる。
・メンバーは迷い、各自が考えるベストな選択肢をとるが、リーダーの認識と齟齬があれば無駄な努力になる。
・ヘルスチェックがされないので状況の悪化に気付けない
・リーダーでも解決できない問題が育っていた場合、上のポジションの人への相談が遅れる
ふじしろ良さげな記事