ID:18008さん

開発プロセスの運営とチーム改善（会議のファシリテーション、要件定義、プロジェクトの進捗管理、スクラムの運営とふりかえりの改善）

開発チームの意見を取りまとめ、リリース期日の厳守と製品品質の担保を意識しつつ、デリバリーのペースを安定させ、チームの改善サイクルが継続的に回る状態をつくること。

当初は純粋にWebフロントエンドエンジニアとして参画したが、要件定義が十分でなかったり会議の進行が円滑でなかったりする状況を目にし、会議のファシリテーションや要件定義を担ううちに、自然とプロジェクトの進捗管理も担うようになった。開発チームの意見を取りまとめ、リリース期日の厳守と製品品質の担保を意識して開発を進めた。 スタートアップの成長期には、エンジニアが2名から6名へと増える中でスクラムを導入した。人数が増えるにつれて知識が個人に偏り、進捗や課題が見えにくくなっていたため、ベロシティ計測とタスクの可視化を取り入れ、サイロ化していた知識や停滞を表面化させることでデリバリーのペースを安定させた。 別のプロダクト開発では、1週間スプリントの6名チームで、ふりかえりが1回あたり実質1トピックしか扱えず、改善が回りきらないという課題があった。そこでふりかえりに「並行作業」（複数トピックを同時並行で洗い出し・議論・整理する）パターンを導入し、1回で扱えるトピック数を2件以上へ倍増させた。あわせて議論内容の記録に追跡性を持たせ、チーム改善の推移を継続的に振り返れる状態にした。この取り組みはエンジニアリングブログでも外部に発信している。 いずれの場面でも、直接の指揮権を持たない立場から、ファシリテーションと仕組み化によってチームが自律的に改善を続けられるようにすることを重視した。