この記事は HowTelevision Advent Calendar 2024 19日目の記事になります。
はじめに
こんにちは。外資就活ドットコムチームでエンジニアリングマネージャーをしております藤原です。
私は今年、グロース開発を行うチームのスクラムのマネジメントや、10名弱のチームで半年以上かかる規模のプロジェクトを遂行する技術負債解消チームのマネジメントを行なってきました。これらの経験の中で、(もちろん)ソフトウェア開発における計画の立案や実行には必ずしも順調に進まない場面がありました。特に、技術的な課題や組織の状況、要件の変化といった「不確実性」と向き合うことは避けられず、プロジェクトの成功に直結する重要な要素だと感じています。今回は、そうした「不確実性」にどのように対処してきたか、私の考えや取り組みについて共有したいと思います。
開発プロジェクトにおける不確実性とは？
不確実性とは、その言葉通り結果が明確に予測できない状況のことを指します。開発プロジェクトにおける不確実性では、以下のような事例が挙げられます。
技術的な不確実性
-
新技術の採用
未検証のフレームワークやライブラリを導入した際に、動作や互換性に問題が発生する。
-
実装時に発覚する想定外
見積もり段階では見落としていた挙動や、システム間の微妙な依存関係が実装中に明らかになる。
-
レガシーシステムとの統合
古いシステムとの連携で予期しない問題が発生する。
-
セキュリティ要件の対応
実装後に新たな脆弱性が判明し、緊急対応が必要になる。
-
テストカバレッジの不足
特定のシナリオが未テストで、本番環境で予期せぬバグが出る。
要件に関する不確実性
-
要件定義の曖昧さ
顧客やビジネス部門からの要求が漠然としており、開発が進むにつれて何度も変更が必要になる。
-
ユーザーのニーズの変化
プロジェクト途中で市場やターゲットユーザーの要望が変わり、要件の全面的な見直しが必要になる。
-
要件優先順位の変動
利害関係者間で要件の重要度に意見の相違が生じ、進行が遅れる。
-
想定外のユースケース
開発途中で、当初想定していなかった使用方法が判明する。
チーム・リソースに関する不確実性
-
メンバーの離脱
キーとなるメンバーが突然チームを離れることで、知識やスキルが失われる。
-
スキルの不足
特定の技術に対して、チーム内に十分なスキルを持った人材がいない。
-
リソースの競合
他プロジェクトとのリソース（時間や人材）争奪が発生し、開発速度が低下する。
-
オンボーディングの遅れ
新規メンバーの習熟が遅く、全体の生産性が一時的に低下する。
プロセスに関する不確実性
-
スケジュールの非現実性
過小見積もりに基づくスケジュールが設定され、開発が圧迫される。
-
不十分なレビュー体制
プロジェクト途中で重要な設計やコードの欠陥が見逃される。
-
変更管理の不足
要件やコードの変更が管理されず、プロジェクトが混乱する。
-
リスク管理の不備
潜在的なリスクが把握されず、問題発生時に適切な対応が取れない。
不確実性が影響する領域
不確実性は、ソフトウェア開発プロジェクトの多くの側面に影響を及ぼします。これにより、計画や成果がどのように変動するか予測しづらくなります。
1. スケジュール
計画時に想定していなかったタスクや遅延が発生することで、プロジェクト全体の納期が影響を受けます。特に不明瞭な要件やリソース不足が原因となることが多いです。
2. コスト
不確実性によって追加の作業や調査が必要になる場合、当初の予算を超過するリスクがあります。予算超過は、プロジェクトの中断や優先度の見直しを招く可能性もあります。
3. 品質
要件の変化やスケジュールの圧迫により、品質が妥協されることがあります。テスト不足や機能の不完全な実装が発生する可能性が高まります。
4. チームのモチベーション
長期化する不確実な状況や、頻繁な計画変更がメンバーのストレスを増加させます。これにより、士気が低下し、コミュニケーションや協力が不足する悪循環に陥るリスクがあります。
不確実性に対処するためのアプローチ
不確実性を完全に排除することは難しいですが、適切な計画と管理を通じて最小化することは可能です。特に私が意識して取り組んだ・上手くいったアプローチ方法をいくつか紹介します。
-
リスク対応シナリオの作成
見積もりのパターンを複数に分けて作成しました。
「楽観的」「現実的」「悲観的」の3つのシナリオを用意し、プロジェクトの進捗や外部要因に応じて柔軟に切り替えられるようにしました。たとえば、新しい技術を取り入れる際には、予期せぬ問題が発生する可能性を考慮して、バッファ期間を設けた悲観的シナリオも計画に含めました。
-
早期警告システムを導入する
進捗トラッキングをスプリント毎に行います。スプリント毎に目標から逆算したマイルストーン目標を設定し、ズレが生じた場合のアラート、対策を素早く行えるようにします。
-
スコープを区切る、小規模な実験を実施する
全体の見積もりを行う前に、スコープの決定と小規模な範囲で実装を進めてみて実績値が見えたタイミングで全体の見積もりを行います。
- スコープの明確化: プロジェクト開始時に、必要な要件を明確にし、合意を取ります。
- スコープの範囲を小さくする: 機能を細かく分け、段階的に進めることでリスクを分散することができます。
- スコープ変更の管理: 変更を記録し、その影響を全体スケジュールやコストに反映させます。
-
不確実性の高いものから着手する
プロジェクトの初期段階では、不確実性が高い部分から優先的に対応します。例えば、新しい技術の導入や未経験の要件に関連するタスクを早めに着手することで、プロジェクト全体のリスクを早期に軽減できます。これにより、後半のフェーズでの手戻りを防ぎ、効率的に進行できます。
-
ステークホルダーとの継続的なコミュニケーション
定期的なレビュー会議やレポートを通じて進捗状況を共有し、要件や優先順位の変更に迅速に対応できる環境を整えます。ステークホルダーからのフィードバックを活用し、不確実性の影響を最小限に抑えることが可能です。
-
チームの協力を促進・課題やリスクの共有
不確実性に対応するためには、マネージャーの動きだけではなくチーム全体の協力が不可欠です。定期的なミーティングを通じて、進捗や課題を共有し、メンバー間の意識を統一します。また、心理的安全性を確保することで、メンバーが自由に意見を出せる環境を作り、不確実性に対する多様な視点やアイデアを取り入れることができます。
おわりに
不確実性への対応は大きなプロジェクト単位に限らず、スプリントやタスク単位でも効果を発揮します。
不確実性による影響を最小限にとどめ、上手く対処していくことこそがエンジニアリングであり、人生であるかもしれません。
不確実性に強いチーム/個人をこれからも作っていきたいと思います。