はじめに

先日、TECH PLAYで開催された若手エンジニアの失敗談LT大会に参加してきました！
本記事ではLTの補足として、開発の失敗原因の一つである 「計画づくり」 に関して深ぼります。

techplay.jp

発表資料

計画づくりとは

計画づくりとはその名の通り、「計画を立てる行為」です。
良い計画づくりをすることには以下の3つの効果があります。

プロジェクトに関する潜在リスクの発見
仕様の変更などの開発中の不確実性への対応
プロジェクトの実行可否の意思決定

結果として、良い計画づくりを行うとプロジェクトの成功確率は高まります。

悪い計画づくりによる失敗

当時の私の計画づくりはひどいものでした。
フィーチャーの仕様変更や追加がスケジュールに反映することができず、どんどん計画が価値のない物になっていきました。

スケジュールにバッファがない
→実装の遅れが後の作業に影響し、リスケが頻発 😭
見積もりが荒く、不確実性が高い
→期間内に終わらない量のタスクがそのまま積まれている 😇

これはなんとかせなば！ということで計画づくりを見直すことにしました。

f:id:y-zumi:20190714185950j:plain

計画づくりを改善するために何をしたのか

計画の改善のために、まず、不確実性を反映した計画を作り、そこからフィーチャーの費用対効果を検討し実装する機能を削ることにしました。

不確実性を反映した計画づくり

バッファを考慮した見積もりをするために、今まで理想日による見積もりだけだったのを、理想日とそれに1.5倍掛け合わせた最遅日の2つのスケジュールを立てました。
また、タスクの見積もりは時間ではなく、タスクの複雑さや規模をもとにポイントとして見積もりを行い、労力がかかりすぎないようにしました。

スクラムなどを使っている場合は、プロダクトバックログでスケジュールの変更容易性や、ストーリーポイントによる素早くてざっくりとした見積もりができるので計画づくりには適しているなと感じました。

費用対効果を考慮した実装範囲の再定義

スケジュールの見積もりが完了し、期間内にすべての機能が実装できないとことが明確になりました。そこで、開発する機能を減らすために「フィーチャーの価値」と「見積もった工数」をもとに実装の可否と優先順位を決めていきました。

フィーチャーの価値は「利益」、「獲得ユーザー数」、「課題の解決ができるか」などをもとに定義しました。フィーチャーの価値と前段階で見積もった工数を比較し、費用対効果の高いものを開発スコープ内に含めていくことにしました。
開発の優先順位については「最低限実装すべき機能」→「価値の高いフィーチャー」→「それ以外」という順で並べ替えていきました。

f:id:y-zumi:20190714202559j:plain

まとめ

以上のような不確実性を考慮した計画をもとに実装機能の取捨選択までを、プロジェクト期間中に継続的に行うことで、急な仕様の変更や追加にも対応できるような体制を作ることができました。まだ計画の運用も完璧とはいきませんが、基本的なところは抑えられているのではと思います。計画づくりは奥が深いですが、この経験により計画づくりについて考えなおす良い機会になりました！

今回は失敗LTということで、自分が参加していたプロジェクトの計画づくりに関する失敗を取り上げました。計画づくりはとても難しく、すぐにうまくできるようなものではないと思います。そのため、これからのプロジェクトでも失敗と学びを繰り返して、その気づきをブログ等で発信していけたらと思います！