ID:84686さん

自分を含む4名のチームが担当する開発PJと保守・運用の進行、およびメンバーへのタスク配分です。 正式な役職ではありませんがチームリーダーとして、以下を担当しました。 - 全体スケジュールの把握とメンバーの不明点の解消 - 上長・PdMOを交えた中長期のタスク割り振り - Issueとマイルストーン管理（Notionでの運用、およびGitHub Projects移行後の整理・クローズ）

- 各メンバーが着手しているプロジェクトと保守・運用を含めた全体スケジュールを、常に把握できている状態にすること - メンバーがタスクを進める上での不明点を解消し、手が止まらない状態を保つこと - 中長期のタスクの割り振りを上長・PdMOと合意した上で決め、メンバーが次に取り組む内容を見通せる状態にすること - 管理ツール上でタスクが整理され、Issueの状況が実態と合っている状態を保つこと - 上長に対して、進捗を不確定要素の少ない形で連携できる状態にすること

# 課題 ### Issue管理が機能せず、支援の判断が後手に回っていた Issue は Notion で管理していましたが、できることが多く、メンバーが機能を活かしきれていない状態でした。 Issue を閉じるタイミングも、作成方法や運用方法も担当者ごとにばらつき、管理としてほとんど機能していませんでした。 その結果、各プロジェクトが「いつ・どこまで終わるのか」をチームとして把握できず、中長期のタスク配分やメンバーへヘルプに入る判断が後手になり、メンバーへの負荷や、上長への進捗連携における不確定要素につながっていました。 # 取り組み ## GitHub Projects への移行を提案し、チームで合意 ### 原因 運用ルール自体は過去に定めていましたが、Git との連携は実現可能なものの運用コストが大きく、Issue の更新が手作業に依存していました。 また Notion はチーム内でドキュメント管理ツールとして定着しており、Issue 管理としての運用が根付いていませんでした。 原因は個人の運用ではなく、Issue の更新が開発の流れから外れた部分にある点にあると考え、正社員メンバーで実施している業務改善MTGで GitHub Projects への移行を提案しました。 ### 選定理由 - Issue が GitHub 上にあることで、Notion との連携コードを保守する必要がなくなり、GitHub Actions を含めた構成をシンプルにできる - 1年ほど前まで同ツールで Issue を管理しており、当時の運用ルールを一部踏襲すれば、Issue の移行やメンバーのキャッチアップを含めた移行コストを抑えられる なお Notion は廃止せず、ドキュメント管理としての責務に絞って継続利用しています。 # 並行して行っていたこと 仕組みが整うまでの間は、自分が各メンバーの着手状況と保守・運用を含めた全体スケジュールを把握し、不明点をその場で解消することで進行が止まらない状態を維持しました。 中長期のタスクの割り振りは自分の判断だけで決めず、上長・PdMO を交えて決定し、優先度の認識をそろえた上でメンバーに提示するようにしました。 移行後は Issue の整理とクローズを担当し、着手中・完了の状況が実態と一致する状態を優先して運用しています。 移行から日が浅く定量的な効果はこれからですが、Issue を元にマイルストーンで管理することで「いつ・どこまで終わるのか」を以前より可視化することができています。 また、メンバーから Issue のクローズ運用に関する提案が上がるなど、チーム内で運用を改善する動きが出てきています。