Contact us now
03-6416-4760

第2回:プロジェクトマネージャのためのAgile入門(成功の為の12ポイント:前編)

(INSIGHT NOW!への寄稿記事と同様の内容です)

連載第1回目には、Agile開発の本質を解説しました。

第2回目の今回は、Agile開発プロジェクトの成功の為のポイントについて、自身の経験則に基づき解説していきます。

私が実際にAgileプロジェクトを管理する中で導出した、成功のためのポイント全12点のうち、前編である今回は6点について解説していきます。

 

まずは、“体制”に関するポイントを3点示します。

 

ポイント①:設計者と開発者は同一の前提!

Agileの前提として、設計書などのドキュメントは作成しません。

これは、設計者と開発者が同一人物であるという前提に立っているからです。

しかし、実際プロジェクトのチーミングを行う際、このようなスキルセットの要員を必要数確保できるとは限りません。

設計者といては優秀だけど、プログラムはいまいち。プログラマーとしては優秀だけど、クライアントとコミユニケーションをとって設計をするのはちょっと。

という偏った要員の方が多いのが実情です。

その際には、設計者と開発者が分かれざるを得ませんが、そうすると両者間でのコミユニケーションが発生し、

設計書などのドキュメント作成が必要になるという点に注意が必要です。

そして、このような状況は、Agile導入の効果を損なう可能性がありますので注意が必要です。

 

ポイント②:設計リーダーを設置!

開発チームに高いレベルの要員を揃えられるのであれば不要ですが、大抵の場合にはレベルのばらつきがあるでしょう。

この様な際には、開発チームの中に熟練の設計リーダーを配置する事が有効です。

この設計リーダーはスクラムマスターなどの調整役とは違い、実際に設計の全体像を把握し、全体最適の観点からチームメンバーに助言する役割を担います。

これにより、品質のばらつきを是正でき、結果的に無駄な工数の削減につながる効果が期待できます。

ポイント③:意思決定できるクライアントを!

Agile開発では、日々タスクの優先度を考慮して調整を行います。

当然、優先度の高いタスクから実施していくことになりますが、調整するクライアントの

意思決定がブレたり、必要以上の時間を意思決定に要しているのでは満足いく効果を得ることは困難でしょう。

“プロダクトオーナー”と呼ばれるクライアント側にも高い意識とのスキルが求められるのです。

具体的なプロダクトオーナーの役割を示します。

  • 明確な優先順位付けを恐れず行う(同位はNG)
  • 明確な方向性を示し続ける
  • チームの一員として振る舞う
  • 開発チームと交渉を行う

続いて、“プロジェクト計画”に関するポイントを3点示します。

 

それに先立ち、Scrum(Agile手法の代表的な一つ)の進め方イメージ図を示しておきます。

こちらの図を見ながら読み進めてください。

<Agile(Scrum)の進め方イメージ図>

 

ポイント④:イテレーション*は、3~4週間が最適!

一般的にイテレーションの期間は、2~4週間といわれていますが、私の経験上、2週間ではちょっと慌ただしいです。

3週間~4週間に設定するのが望ましいでしょう。

当然、これに合わせて、開発単位の規模を調整するのがポイントです。

これによって、管理負荷が過剰に大きくなる事を防ぐ効果が期待できます。

*:Agile開発で用いられる短い期間で反復する開発期間単位の事

 

ポイント⑤:先送りタスクをこなす余裕を持つ!

イテレーションを進めていく中で、優先順位によりタスクの先送りが必要な状況が頻繁に発生します。

この先送りされたタスクをイテレーション中にこなすための時間・リソースに関する余裕(バッファ)を、

プロジェクト計画上持たせておく事が重要です。

(個々のタスクにバッファを持たせるのではなく、バッファを明確に切り出しておく事がポイントです)

これはAgileに限った話ではなく、通常のウォーターフォール型のプロジェクトにおいても、

熟練のプロジェクトマネージャは自然と行っていることだと思います。

 

ポイント⑥:計画時の作業見積りを細くしすぎない!

タスクの見積もりを行う際に、時間を細かく切りすぎない方が良いでしょう。

短くても半日ぐらいの単位で見積もるのが望ましいでしょう。

(1~2時間の見積もりは管理負荷を必要以上に高める要素になりますので、極力避けた方がよいでしょう。)

イテレーション計画をタスクに落とし込む際に工夫が必要です。

イテレーションのゴールを設定し、それを実現するために必要な機能単位の実装内容をストーリーとして定義します。

そのストーリーを実現するために必要なタスクを定義していきます。

この様に、具体化できる単位までトップダウンで落とし込むことで、タスクの粒度を調整していけばよいのです。

 

今回は、「Agile開発成功の為の12ポイント:前編」として、私自身の経験則からの“体制”および“プロジェクト計画”に関する

気付きを6点お伝えしました。

 

次回は、後編として“マインドセット”および“その他”のポイントを6点お伝えします。