ID:85588さん

介護支援SaaSを開発する部の運営と、スクラム開発のプロセスです。部の人員は自分を含めて 2 名で、実装の大半を外部の開発パートナーに委ねる体制です。開発部マネージャーとして部の目標設計と進捗管理、パートナーの選定と契約条件の整理を担い、スクラムマスターとしてスプリントの運営、マイルストーン管理、ベロシティの可視化を行っています。

事業側が決めた期日に対して、何がどこまで出せるかを常に答えられる状態にすることが責務でした。見積もりの精度ではなく、ずれたときに早く分かり、何を落とすかを判断できる状態を作ることです。 あわせて、特定の人しか触れない領域を作らないこと、プロセスが形だけ残って中身が空になるのを防ぐことも範囲に含めていました。

入った時点で、スプリントは回っていましたが、終わってみないと何が出せるか分からない状態でした。原因は見積もりの甘さではなく、進捗が個人の頭の中にしかないことだと考えました。 まず Linear でブランチとステータスを自動で同期させ、作業の状態がコードと紐づいて見えるようにしました。手で更新する運用だと必ず止まるため、更新しなくても実態が反映される形にしています。そのうえでマイルストーンごとの残ポイントとベロシティを出し、期日に対して足りているかを毎スプリント確認できるようにしました。 次に問題になったのは、リリースの単位が大きく、できたものが長く手元に残ることでした。トランクベース開発と自動マージを導入して、小さく出し続ける形に変えています。あわせて AI コードレビューを CI に組み込みましたが、導入直後は誤検知が多くノイズになったため、棄却のフローと基準を決めて運用に乗せました。仕組みを入れるだけでは定着せず、外す判断をどう残すかまで決める必要がありました。 属人化については、保守性に課題のあった既存実装を v2 として作り直す判断と合わせて扱いました。読める構造に直さないと、担当を分散させてもレビューが回らないためです。稼働中のサービスを止められないので段階的に切り替え、破壊的なスキーマ変更には expand / contract の手順を定めて、途中で壊れない形にしました。 プロセスの形骸化を防ぐために意識しているのは、ルールを足す前に「どこがやりづらいか」をメンバーから直接聞くことです。会議体や規約を増やすと一時的に整って見えますが、守る理由が共有されていないものは必ず空洞化します。小さく変えて、効かなければ戻す形を取っています。

広告配信プロダクトの開発チームです。最大で 10 名の規模で、スクラムマスターとエンジニアリングマネージャーを兼任し、1年2か月にわたってスプリントの進行とプロセス改善、メンバーの育成・1on1・評価のフィードバックを担当しました。社内向け管理サービスと ToB / ToC 向けの配信サービスを扱うチームです。

新しく入った人がすぐ動けて、既存のメンバーが止まらずに出し続けられる状態を作ることが責務でした。チームの人数が増える局面だったため、個人の頑張りで回している部分を仕組みに移すことが求められていました。 評価については、期末にまとめて判断するのではなく、本人が何に詰まっていて何ができるようになったかを継続的に把握できる状態にすることを範囲としていました。

EM として人を見る側を担当して、一番効いたのは評価のための面談ではなく、普段から「いま何に詰まっているか」を聞く場を持つことでした。期末にだけ話すと、そこまでの数か月を思い出せる範囲でしか扱えません。1on1 で出てきた詰まりをその場で小さく外していくほうが、本人の成果にも、こちらの評価の精度にも効きました。 問題になったのは、オンボーディングのたびに既存メンバーの手が止まることでした。口頭で教える形だと、教える側の負荷が人数に比例して増えます。ドキュメントと開発フローを整え、コード規約とレビュー体制をルール化して、聞かなくても進められる範囲を広げました。 技術面では、既存のフロントエンドを段階的に刷新しながら機能追加も続ける必要がありました。止めて作り直す余地がなかったため、リプレイスの単位を小さく切り、運用を続けながら置き換える形を取りました。認証や設定管理など一部のバックエンドも自分で実装しています。 プロセスを整えるときに気をつけていたのは、規約を増やしすぎないことです。レビューで指摘が多くなると、指摘する側もされる側も消耗します。機械で判定できるものは lint とフォーマッタに寄せて、人のレビューは設計の判断に使えるようにしました。