はじめに
「進捗どうですか？」
この質問、開発者なら誰もが耳にタコができるほど聞いたことがあるでしょう。
本記事では、ソフトウェア開発現場での進捗管理の現実と、チームで試行錯誤できる改善策をお伝えします。
現場あるある：進捗管理の難しさ
1. 見積もりの難しさ
実際にありそうな会話：
PM：「このタスク、どのくらいで終わりそう？」
開発者：「うーん、3日くらいかな」
PM：「じゃあ4日で見積もっておこう」
1週間後...
PM：「あれ？まだ終わってないの？」
開発者：「すみません、想定外の問題が...」
教訓：未知の要素が多いタスクの見積もりは本当に難しい。
2. 「順調です」の落とし穴
朝会での会話：
リーダー：「進捗はどう？」
開発者：「はい、順調です」
（内心：あー、でもこの部分どうしよう...でも今は言いづらいな...）
結果：問題が大きくなってから発覚し、対応が後手に回る。
3. モチベーション維持の現実
ある日の開発者：
「今日はどうしてもコードが書けない...」
「このライブラリのドキュメントを読むふりをして、Qiitaをだらだら見てしまった...」
現実：誰しもモチベーションが上がらない日はある。それをどう乗り越えるかが重要。
実践してみたい：現実的な進捗管理アプローチ
1. 「ストーリーポイント」の導入
具体例：
タスクA: 3ポイント（1日程度）
タスクB: 8ポイント（3-4日程度、不確定要素あり）
期待される効果：時間ではなく、相対的な難易度で見積もることで、より現実的な計画が立てやすくなる。
2. 「確信度」を報告に含める
進捗報告の例：
「タスクAは80%完了。確信度は60%です。APIの仕様が曖昧な部分があるので、確認が必要かもしれません。」
期待される効果：早期に潜在的な問題を共有できるようになり、チームの対応が素早くなる。
3. 「今日はダメな日」の共有
チームでの約束事：
「今日はコードが書けない日」を宣言できる（月に1-2回まで）
実際の使用例：
「今日は集中できないので、ドキュメント整理と簡単なバグ修正に専念します。」
期待される効果：無理に生産性を装わなくて済み、精神的な負担が減る。翌日以降の生産性向上につながる可能性がある。
4. 「もくもく会」の導入
毎週水曜日の午後2時間を「もくもく会」として設定。
- 各自がその時間にやりたいことを宣言
- 集中して作業
- 終了後に簡単な成果報告
期待される効果：普段手が付けられない技術的負債の返済や、新技術の学習時間が確保できる。
5. 「リファクタリングスプリント」の実施
3-4スプリントに1回、1週間のリファクタリング期間を設ける。
実際の取り組み：
- 技術的負債の棚卸し
- チーム全体でのコードレビュー
- パフォーマンス改善
期待される効果：コードの品質が向上し、長期的な保守性が高まる。
まとめ：進捗管理の改善に向けて
完璧な進捗管理は存在しません。しかし、チームの現状に合わせて少しずつ改善を重ねることで、着実に成果を上げることができるはずです。
上記で紹介したアプローチは、一つのチームですべてを一度に導入するのは難しいかもしれません。しかし、以下のような段階的な導入を検討してみるのはいかがでしょうか：
- まずは「確信度」を報告に含める取り組みから始める
- チーム内で話し合い、最も必要性を感じるアプローチを1つ選んで試験的に導入する
- 1-2ヶ月ほど試行した後、効果を振り返り、継続するか別のアプローチを試すか決める
- 効果が見られたアプローチは正式に採用し、次のアプローチの試行に移る
このような段階的な改善プロセスを通じて、チームに最適な進捗管理の方法を見つけていくことができるでしょう。
理想的には、こうした取り組みを通じて：
- チーム内のコミュニケーションが活発になる
- 予期せぬ問題への対応力が向上する
- 個々のメンバーの成長スピードが上がる
といった効果が期待できます。
皆さんのチームでは、どのような進捗管理の課題や工夫がありますか？ また、この記事で紹介したアプローチの中で、試してみたいものはありますか？
開発現場の生産性向上と、開発者一人一人のウェルビーイング。この2つを両立させる進捗管理の形を、一緒に探っていけたら嬉しいです。