アジャイル開発プロジェクトでリソースを超えるタスクをコントロールする
概要
アジャイル開発でプロジェクト開始後にタスクがコストと時間を超えて追加されていくとバランスがとれずに問題となることがある。具体的にはスケジュールが遅れたり、スケジュールに納めるために開発速度を優先し品質を落とすことで不具合が発生する等がある。これはプロジェクト開始後にタスクが増えているものの、当初予定していたコストと時間を超えるタスクをうまく減らす事ができていないことに起因して発生することが多い。コストと時間を超えるタスクを減らすにしても単純にタスクを追加する際に、必要か不必要かをコントロールすることが難しいこともタスクを減らすことが困難な理由の一つとなる。
そのため、タスクに優先順位をつけて、優先順位が低い物に関して対応しない決定をしていくような仕組みが必要となる。ここではタスクの優先順位を使って、増えたタスクを減らすための方法について説明する。
前提条件
どのようにコントロールするかの説明の前に前提条件を確認しておきたい。本ページの記載は以下の前提条件のもと記載されている。もし前提条件が異なる場合においては適宜読み替えてほしい。
・システム開発会社で受注を受けての開発を行いユーザーに提供する
・ソフトウェア開発に関するプロジェクトに関して記載している
・アジャイル開発でプロジェクトを進める
・アジャイル開発に慣れていないクライアント、エンジニアが多い
・要件整理は完了しており、要件定義、および開発フェーズでのプロジェクト
必要な要素
アジャイル開発で要望が追加される中、期限内に納めるにはいくつか必要な要素がある。実際にタスクを管理する前に必要な情報を以下に記載する。
タスク一覧
作成する機能、および機能以外も含めてプロジェクトを完遂するためのタスクを一覧化したもの。アジャイル開発だとバックログという形で定義することが多い。
アジャイル開発では決まっていないことも多い中でスケジュールの調整をしていく必要があるため、アバウトでも漏れていても良いので今わかっているすべてのタスクを記載する。
タスクの内容については何を実現すれば良いかを記載するようにする。
タスク毎の見積り
アジャイルでは仕様が明確に決まっていない事が多いため正確な見積はできない。そのためおおよその開発規模での見積を実施しておく。スクラムだとストーリーポイントという規模で見積をすることが多い。ある特定の開発規模の見積を基準として、それと比較しての開発規模を見積る。
数値についてはフィボナッチ数列（0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34）を使う事が多い。正確に要件が決まっていない状態での見積となるため正確な見積を出すというよりもスピード重視で見積を決めていく。複数人で開発する場合においてはプランニングポーカーなどで決める方法もある。
タスク完了の実績
見積が見積となるため、特定の期間（1週間とか2週間）毎にどれぐらいのタスク量がこなせるかを記録する。
その記録を元に、特定の期間でどの程度の見積のタスクをこなせるかを確認する。その結果で今後も同様の見積のタスクが完了していく事を想定してスケジューリングを行う。
期限
タスクを完了させるための期限を設定する。期限をどこにもっていくかはプロジェクトによって異なる。実際のリリースまでのことを示していることもあれば、開発後、結合テストまでを完了したことを示すこともある。いずれにしても管理されているタスクの範囲を完了とさせたい期限を設定する形となる。
タスク毎の優先順位
アジャイル開発では、開発中に追加のタスクがでてくることを許容する。通常追加のタスクが多くなるため、期間内にすべてのタスクを完了にできない。そのため、優先順位を設定し、その順番で作ることによって期間内に最大限の効果をもつ開発を行うようにする。
実際の実践方法
必要な要素を作成する過程も含め、実際にタスクを管理する流れを以下に記載する。
タスク一覧の作成
まずはタスク一覧を作成する。タスクに関しては機能を実現するためのタスクや、技術検証などのタスク等、実際にエンジニアが動く物に関してはタスク化しておく。
注意点としては、今確定で見えてるものだけをタスク化すると、期限までに必要なタスクが網羅できないことが良くある。不確定でも何かしら対応が必要であればタスク化しておく。
タスク毎の見積り
タスクの見積を見積で行う。
おおよそ大きくても2日程度で終わるタスクが大半になるように設定するのが進捗管理上良い。これは2日連続でタスクが進んでいない場合、何かしら課題画ある場合が多く、その課題をいち早く検知し対応していくためとなる。
タスクの優先順位の決定
ビジネス上最低限の機能を最低限実現するものを優先する。
UIに関しては最低限のルールを最初に決めておくのが良い。もし最初にUIを作り込むとそのほかの機能を実現する際にでもUIを作り込む必要がでてくることで全体的に修正に時間がかかってしまう場合が多い。そのためあまりプロジェクト序盤では作り込まないほうがよい。
期限の設定
基本的にはプロジェクト開始の時点で期限が決まっている事が多い。そのためそれに合わせるのが基本となる。
全体のスケジュールを元にブレイクダウンし、マイルストーンを設定した方が良い場合も多い。
スクラムでは、スプリント毎にリリース可能であることが求められるが、受注しての開発の場合は難しいことが多いため、各イテレーションでは単体テスト、結合テストまでを実施することとし、最後に総合テスト、システムテストの期間を設けることもある。その場合は結合テスト完了までをマイルストーンとしてそれまでに必要なタスクを完了させるなどの調整を行う場合がある。
タスク完了の実績
１週間や2週間のイテレーションを設定し、その間にどの程度のタスクが完了したかを計測する。完了したタスクの開発見積を合計すれば、一週間でどの程度進められるかが計算できる。その内容を元に今後のスケジュールを立てる。
期限までのリソースとタスクの見積りを比較する
実績を踏まえると期限までにどの程度のタスク見積が対応できるかがわかる。その上で残りのタスクの見積合計を比較する。比較した結果、残タスクの見積合計のほうが、残リソースを超えるようであれば優先順位の低いものは対応不要とする。もしまだリソースがある場合においては、開発していくなかで追加されるタスクや、クライアントからの要望を追加していく事が可能となる。
いずれにせよこの比較をして進捗状況を常に確認しながら進めていく事が必要となる。プロジェクトの最初期についてはすべての要素がそろわないため、実現しにくいが、開始後 1, 2週間後にはできるようにしていく。
もしこの比較をプロジェクトの後半にすることになった場合は、その段階でタスクがリソースを大幅に超えていた場合にリカバリー対策がとれない事が多い。そのため早めに見積もりが出来る状態を作るのがよい。
TIPS
本件を実施する上で、うまくタスク管理できないような場合がいくつか考えられる。その点について以下に記載しておく。
プロジェクトの早めに必要な情報をまとめる
プロジェクト開始後1, 2週間程度では、仮にでも情報をすべてそろえられるようにしておきたい。早めにやらなければ、リスクは後回しとなり、期限内に必要な機能がすべて対応できないと行ったことが起きうる。
プロジェクトのなるべく早めにタスク量をオーバーさせてスケジュールを行う
追加要望も含めタスクの洗い出しを行い、早め期日までに全てのタスクが終わらないという見積もりをだす状況を作ると優先順位をつけやすい。これはユーザー含めたメンバーが優先順位を考える機会となる。
アジャイル開発になれていないメンバーは最初は取捨選択できないので、取捨選択せざるを得ない状況を早めに作り優先順位の付け方を学びながらプロジェクトを進める。
エンジニアは課題を課題として認識していない場合がある
本件とは直接関係するものではないが、タスク管理をする上での課題は解決していくことが前提となる。課題については各自がプロジェクトメンバーに共有していくことになるが、プロジェクトの各メンバーへの役割と期待値がはっきりしていないと課題があったとしても課題と思わず、解決をせずに進めてしまう事も多い。そのため、このタスク管理でいつまでにやらないと行けない等の期待値を明確化することで、それが実現できない可能性がある物すべてを課題として共有するように促すと良い。
エンジニアは期限がないと作りこむ傾向がある
本件の対応で概算の見積は出せるが、それをメンバーに周知し、期日までに予定されているタスク量を完遂するよう促す必要がある。それをしない場合は各メンバーがただ単に開発を行い機能ではなくUIを作り込んだりして、全体スケジュールが遅れるといったことがある。そのため、タスクの優先順位順に実施すること、またなるべく一つ一つを完了させるようにしていく。
機能毎に一つ一つ作りこむ傾向がある
最終的に成果物ができれば良いということ、またそれを効率よく作ろうというエンジニアの心理から、効率良く開発するために一つ一つの機能を順番に作り込んでいくということが良く発生する。アジャイル開発の場合、プロジェクト序盤からフィードバックを得ることからタスクが追加されていくこと、また価値を提供する事に集中することから最小限の機能の実現をまずは優先していく必要がある。
そのため、各機能毎に必要なタスクから対応していくようにしたい。
指摘があるとそこから優先的に対応する傾向がある
指摘が発生した場合に、修正内容がわかりやすい、また時間もかからず簡単に対応できることも多いことから、指摘をすぐに修正しようとしがちになることがある。そしてその指摘内容を選定せずに修正すると、本来であれば価値を提供することに直接影響しない優先順位が低いタスクを先に対応することとなる場合がある。アジャイル開発ではリソースを超えるタスクが発生するため、プロジェクトの終盤に指摘事項の修正より重要なタスクが結局できないということになる。
これを避けるために、指摘内容についてはタスク一覧にいったん記載した後、優先順位を決めて対応することを徹底するのが良い。
フィードバックがUIの指摘ばかりになりがち
アジャイル開発はプロジェクト序盤からクライアントにアプリケーションのデモを見せるといったことを行う。デモの見せ方にもよるが、内部の機能について詳しくないクライアントも多いため、UIに関しての指摘に偏りがちになる。UIの修正についてはわかりやすいものの、プロジェクト序盤においては実際の機能のほうが重要となることが多い。
そのため、プロジェクト序盤のUIの指摘事項については、タスク優先順位を適切に設定してから対応すると良い。UIの基礎的な内容や、おおまかなデザインなどの統一などは序盤に行った方が良いが、各個別の選択項目の最適化や、ユーザーが使いやすくするための修正などはプロジェクト中盤から、終盤にかけての対応としたい。
工数オーバーしたところはできないことを前提に管理する
アジャイル開発においては要望を途中で追加していくことになるため、通常タスクの量がリソースを超える事となる。そのため、理論上でも実際でも対応しないタスクを選ぶ必要がある。エンジニアはよく最終成果物を最大限にすることを価値として考えている事が多いため、無理してでもタスクをこなすことに集中してしまい、結果として品質を犠牲にしたりといったことがある。
そういった場合については、優先順位の低いタスクは実現できないことを説明し、もし必要であればタスクの優先順位をあげる等の対応を行う。いずれにせよすべてのタスクは実現できないため、優先順位が低いタスクについては対応できないこととする。エンジニアに関しては、最終的なビジネスにどのような価値を提供していくかを丁寧に説明し、成果物を作ることだけが価値ではないことを理解してもらう。
早めにリリースをして見えないタスクを洗い出す
アジャイル開発では、最初に要件定義などをしてタスクを洗い出す行程がないため、途中で必要なタスクが増えていく傾向にある。プロジェクト終盤においてタスクが増えるとリソースが少ない事もあり、タスクの優先順位の調整が難しくなる。また、そういった要件定義を行うフェーズはアジャイル開発では行わない。
そのため、早めに実際にリリースをするなりして、なるべく本番に近い状況を作り増えるタスクについては、早めに増やしていくのが良い。
プロジェクトの成功基準が成果物となりがち
プロジェクトの成功基準は成果物ではなく、期待値を超えられるかどうか。期待値のコントロールが必要。全部作ろうとして品質を低下することが良くあるが、そこはここで紹介した方法でタスク管理を行い、タスクを調整することで品質を維持できるようにしたい。
この記事が気に入ったらサポートをしてみませんか？