はじめに
こんにちは。初めまして。まるべいじ（malvageee）と申します！
今回は、チーム内で機能開発の進捗が追いづらくなり、動きにくさが生まれていた状況を改善するために導入した「プロジェクトオーナー制度」について紹介します。
私が率いている開発チームでは、複数の機能開発が同時に走っており、プロジェクトの透明性が低下するという問題を抱えていました。
結果として、誰がどこまで進めているのかがわかりにくく、チーム全体が自律的に動きづらい状態になってしまいました。
そこで改善策として導入したのが、この プロジェクトオーナー制度 です。
取り入れてみたところ、チームの動きが大きく変わり、想像以上にポジティブな効果がありました。
この記事では、その背景から導入内容、実際にどんな変化が起きたのかまでをまとめて共有します。
チームの状況
私がリードしているチームは5名のエンジニアで構成されており、
1つのチームで複数のプロジェクト（スクラムでいうエピック規模の機能開発）を同時に進めていました。
当時は、プロジェクトごとに明確な担当者を置いているわけではなく、
優先度順に最初に着手した人が「なんとなくそのプロジェクトを一番知っている」という状態でした。
この状況では、
「誰が何をどこまで進めているのか」が全体から見えづらく、
結果として進捗の透明性が欠け、メンバーが動きにくくなる問題が起きていました。
チーム内で上がっていた声と見えてきた課題
私たちは2週間（1 Sprint）ごとに振り返りを実施しており、
その中で次のような声が上がるようになりました。
- 「依存関係が複雑だと、どのタスクを取ればいいか判断が難しい」
- 「USと紐づくタスクを一覧で見たい。『このタスク切ってあったっけ？』がよく起きる」
- 「依存関係を追いつつ別タスクにdeep diveすると頭がこんがらがる」
- 「依存関係を考慮し別タスクに着手したら準備が間に合っておらず待ちになることがある」
1. 依存関係の可視化不足
- 依存関係が複雑なストーリーは着手しづらい
- ストーリー全体の進行が追いきれず、次に取るタスクを判断しにくい
2. タスク全体の把握が難しい
- ユーザーストーリーに紐づくタスク一覧が見えない
- 「このタスクあったっけ？」と確認が発生
- 階層（プロジェクト全体 > ユーザーストーリー > 作業タスク）を跨いで探す必要があり、全体像がつかみにくい
3. タスク着手時の準備不足
- 依存関係の都合で優先度が少し低いものに着手すると、準備不足で着手できないタスクが生まれる
4. オーナーシップの曖昧さ
- ストーリー単位での責任者が不在で、把握できている人が少ない
こうした課題が重なることで、
プロジェクトがふわっと進んでしまい、チームが迷子になってしまうことがありました。
解決のために導入した「オーナー制度」とは
これらの課題を解消するために、私たちは プロジェクトごとにオーナーを設定する仕組み を導入しました。
オーナーが担う主な役割は次の通りです。
プロジェクト開始前の ユーザーストーリーの整理と計画作成
- ユーザーストーリーの整理・分割・依存関係の洗い出し
- 必要に応じてタスク化し、進め方を検討
- 依存が複雑な場合は、オーナーが一任してタスクまで洗い出す
依存関係の可視化
- ユーザーストーリーとタスクをFigJamで図解
- 着手順・詰まりポイントが一目でわかる状態にする
プログレスバーで進捗を見える化
- 明確なルールとして決めてはいないが、最初のオーナーが導入してくれたことで定着
- ゴールまでの距離が視覚的に把握できる
整理方法はオーナーの裁量で自由
- 方針だけ共有し、フォーマットは固めすぎない
- ただ、最初に整理してくれた方のフォーマットがわかりやすかったため、それが自然とチーム標準に
週2回ほど夕会で状況共有
- 担当外のメンバーでも状況が理解しやすくなる
- プロジェクトに対する発言、サポートが出やすい環境に
導入後に起きた変化（効果）
オーナー制度を導入してから、チームには次のような変化が生まれました。
1. チーム全体がプロジェクトに主体的に関与するようになった
担当外だから分からない、という状態が減り、誰でも新しいプロジェクトに入りやすくなりました。
2. 進行状況が明確になり、モチベーションが向上
ゴールと現在地が明確になることで、あとどれくらいで終わるのかが可視化され、自然とスピード感が上がりました。
精神的にも「終わりが見える」ことはチームの安心感につながります。
3. リーダーの管理負荷が大きく軽減
リーダーである私自身の把握すべき情報量が減り、状況を正しく把握するまでの時間コストが大幅に軽くなりました。
ただし、リーダーの役割がなくなるわけではありません。
プロジェクトの雲行きが怪しくなった時には、即座にサポートして軌道修正することが必要です。
オーナー制度はあくまで“視界をクリアにする仕組み”であり、放任するものではありません。
4. プロジェクトオーナー経験が蓄積され、チームの底力が上がった
一人称でプロジェクトを整理し、説明し、判断する経験は、タスク消化側では得られない学びがあります。
この経験がチーム内で循環することで、プロジェクト推進力そのものが底上げされていきました。
実際にやってみて感じたポイント
チームリーダーとして痛感したのは、
「チームが自律的に動けるための仕組みを整えること」 がいかに重要かということです。
情報把握や先回りに時間が取られすぎると実装時間が取れず、
逆に実装に寄りすぎると全体の把握が曖昧になり、チームの成長と生産性が下がってしまいます。
オーナー制度は、このバランスを取るための大きな助けになりました。
さいごに
振り返りで課題を出し、改善案を一緒に考えてくれたチームメンバーには本当に感謝しています。
オーナー制度はまだ発展途上ですが、今後も続けつつブラッシュアップしていく予定です。
もしあなたのチームでも、「情報整理がうまくいかずプロジェクトが迷子になりがち」 という課題があるのであれば、ぜひ一度試してみてください。
小さな取り組みですが、チームの動き方が驚くほど変わるきっかけになります。
Discussion