アジャイル開発を採用するにあたりテーラリングすることで、組織、プロジェクトの特性に合わせた柔軟化が図られプロジェクトの成功率を上げることが可能です。
PMBOK(Project Management Body of Knowledge)においてもテーラリングの重要性が強調されており、以下のようにステップを踏んだ適用が推奨されています。
- プロジェクトの特性を理解する:
プロジェクトの規模、複雑さ、リスク、ステークホルダーのニーズなどを評価します。 - 適用するプロセスを選択する:
プロジェクトの特性に基づいて、どのプロジェクトマネジメントプロセスを適用するかを決定します。 - プロセスの調整:
選択したプロセスをプロジェクトのニーズに合わせて調整します。 - 実行と監視:
調整されたプロセスを実行し、プロジェクトの進行状況を監視します。 - 継続的な改善:
プロジェクトの進行に応じて、プロセスの効果を評価し、必要に応じてさらに調整を行います。
ただここで、組織特性、プロジェクトの特性という言葉に甘えすぎると、アジャイル開発の採用が効果を出さないので、アジャイルの基本原則[1]を損なわないように注意が必要です。
損なってしまった失敗例をいくつか挙げます。
-
スプリント期間の過度な延長
- フィードバックタイミングが遅延することで変化への対応が遅れる原因となった
- 対話機会が減少することでモチベーションの低下を招いた
-
プロダクトオーナー、スクラムマスターの役割の不鮮明化
- 責任の所在が不明確になることで意思決定が遅れ、チームの方向性が定まらなかった
- ステークホルダーとの連携が十分に行われなかったため成果物が期待と大きく外れた
-
スクラムイベントやデイリーの省略
- 対話機会の減少により問題の早期発見ができず解決遅れを発生させた
では、テーラリングをしない方が良いのか?と言えばそうではありません。
冒頭にも述べた通り、テーラリングすることで組織、プロジェクトの特性に合わせた柔軟化が図られプロジェクトの成功率を上げることに繋がります。
もし、テーラリングしたアジャイル開発を採用し開発を推進しようとされているあるいは既に推進されている方がいらっしゃいましたら原則を損ねていないか、今一度確認されることをお勧めします。
皆様のプロジェクトの成功を願っています!
アジャイルソフトウェア宣言
・ プロセスやツールよりも個人と対話を
・ 包括的なドキュメントよりも動くソフトウェアを
・ 契約交渉よりも顧客との協調を
・ 計画に従うことよりも変化への対応を
引用:https://agilemanifesto.org/iso/ja/manifesto.html ↩︎