本記事の概要
プロジェクトが進行する中で、「特定のタスクが停滞し、後続の開発ラインが手空きになる」「後半になって予期せぬ課題が発覚し、リカバリ不能になる」といったトラブルは頻繁に発生します。
こうしたボトルネックの根本原因は、WBSが「単なる作業の羅列」になっており、リスクや依存関係を反映した順番になっていないことにあります。
今回は、1人目のエンジニア/PMとして、プロジェクトの停滞を回避するために私が実践してきたことを下記項目に分けて記載しています。
- タスクの見通し（既知・未知）度合いによる優先度判断
- 後続への影響度による優先度判断
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
不確実性と依存関係の放置
タスクが遅延・停滞する原因として単に作業量が多いことだけでなく、「実装方法が未確定（ブラックボックス）なタスク」や「外部影響を受けるタスク」が後回しにされていることがありました。
これは冒頭に記載したようにWBSに優先度が反映されていないことによる結果でもあるのですが、一方でタスクの進め方は任せていたので担当者のWBS構築基準に不確実性や依存関係が欠けていたことの表れでもありました。
後半になってからブラックボックス部分で不具合や課題が検出された場合、手戻りの影響はプロジェクト全体に及びます。見通しが悪かったタスクだからこそ、不具合なども想定以上に検出されるもので、その解消に時間がかかり他の対応も遅れてしまう、このリスク構造こそが、チーム全体の進捗を阻む最大のボトルネックとなっていました。
不確実性の解消
「既知の技術か否か」はリスク判断で非常に重要な要素となります。
既知の技術で実装できるタスクは後からでもリソース調整が可能ですが、技術的に未知な領域は課題検出時のリカバリが困難です。そのため、ブラックボックスなタスクほど優先的に前倒しで消化・検証する計画に変更しました。
見通しの悪い技術、その技術を使って実装すべきコア機能、この情報を整理して検証する期間を設けました。もちろん当初のタスクはその分遅れますが、不確実性を放置するよりはスムーズになるはず、という見立てです。
遅れた分は私も実装に加わることや、全体スケジュールから後ろ倒しにしても影響の小さいタスクをリスケジュールするなどして調整を行いました。
後続タスク影響の判断
後続のチームや外部システムに影響を与えるインターフェース（通信仕様等）のタスクを最優先に位置付け、後続の開発ラインがストップしない環境を整えました。
一番影響の大きい部分であり、可能な限り当初のスケジュール通りにタスクを消化するように意識した内容でもあります。
後続タスクで必須となる機能や、期待されている実装内容などをすり合わせてタスクを細分化し後続タスクに影響しない最小プログラムとして提供することで対応しました。
振り返り
成果
不確実性の高いタスクを早期に消化したことで、プロジェクト後半にリスクをため込まずに進められたと思います。
不確定要素が排除されたことで後半の予測可能性が劇的に向上し、タスクの粒度も小さく切り分けたことで、タスクを柔軟に再割り当てができるようになりました。
また、メンバー自身もタスクの対応順序を改めて振り返るいいきっかけになったと感じました。
振り返り
- WBSというツールの意味を改めて考えさせられた
- 検証の工数を個別に設けるか実装工程の中で並行できるかの判断基準を設けるべきであった
- ベロシティの平準化に寄与する要素の扱いは開発を円滑に進めるうえで重要と再認識した