アジャイルコーチが見た開発現場～初めてのアジャイルでつまづく12のポイント～【プロジェクト遂行時①】

「開発も順調のようだから来月のリリースは予定通りできますね」
「このペースで進めば3か月後のリリースも可能ですよね」
プロジェクトが進んである程度進捗が見えてくると、今後の見通しが気になります。
関係者もリリースを待ち望んでいますから、そんな声が聞こえて来たりします。
アジャイルプロジェクトに携わっている方は、どのように回答するでしょうか？

”はい、大丈夫です”と答える方もいれば、”もう少しバックログが明確にならないとなんとも・・・”と慎重に答える方もいるかもしれません。
特に問題があるわけでもないのに、プロジェクトの進捗を明確に答えられない場合があるのは、なぜでしょうか？

アジャイル開発における見通しは、不明確な未来を明確にすることと同じです。
つまり、”これまで順調”であったことは”今後も順調”ということを約束してくれないのです。そのため、不明確な未来に不安を感じ、進捗をはっきりと示すことができなくなります。
これはアジャイル的な取り組みにおいて、当たり前のように発生することで何の根拠もなく進捗を約束するよりは誠実に現状を理解しているとも言えます。

このような状況で進捗をどのように説明すべきでしょうか？
イテレーティブな開発を行っているため、これまで作り上げてきた成果は明確に説明することができます。残りの開発対象もどのようなものがあるかある程度は説明することができるでしょう。
ただし、残りの開発対象で明確になっているものと、明確になっていないものがある場合、少し冷静に分析したほうがよさそうです。

明確な開発対象は単に残ポイントで開発ボリュームを説明できます。ベロシティを加味すれば、およそどのくらい時間が必要かも説明が可能です。
しかし不明確な開発対象は、ラフなポイントしかつけられませんので、ここにブレ幅が生まれてきます。

具体的な数字で考えてみましょう。
例えば残りのストーリーポイントが５０ptあるとして、そのうち３０ptは明確だが、２０ptは不明確なものとします。

この場合、見通しを考える上で必要なことは不明確な２０ptがどの程度ブレるのか？ということです。もちろん、わからないから不明確なのであって、内容によりブレる程度も様々だと思います。そのためブレ幅を確定させることは厳密にはできないのですが、ひとつのアイディアをご紹介します。

不明確とはいえある程度内容を把握し一旦のポイントを置けているのであれば、そのポイントを前後にぶらしてみます。
上記の２０ptの内訳が、８pt、８pt、２pt、２ptだとしたら、それぞれのフィボナッチ数列の前後を考えます。小さくなる場合は５pt、５pt、１pt、１pt＝１２pt、大きくなる場合は１３pt、１３pt、３pt、３pt=３２ptです。つまり前後８~１２pt程度のブレが想定されます。

全体としては、残り５０ptを基準に４２pt～６２ptとブレ幅を仮定できそうです。これに応じて、必要な期間も算定することができます。約１０pt程度ならなんとかなると安心できるかもしれませんね。
※今回は説明のために数字を小さくしていますので、実際にはもっと大きな幅になるかもしれません。

このような試算が皆さんのプロジェクトにフィットするかどうかお約束できるものではありませんが、不明確を不明確のままにせず、可能な範囲で明確にしていくことで、より具体的に未来を見通せるのではないかということが私のお伝えしたかったことになります。

プロジェクトの進捗が思わしくない場合、その説明は難しいものです。

まず状況説明として現状と課題を明確にしなければなりません。そのうえで、今後どのようにしてリカバリーを行うかという予定の提示も必要になります。
アジャイルに限らずシステム開発では思わぬ事態によって計画通り進まないことはあり得ることですが、とはいえ、そのままで良いかというと改善しなければ周囲の理解を得ることができません。

アジャイル経験が少ない場合は、なおさら現状把握や改善についてのノウハウが少なく、対応に苦慮することもあると思います。具体的な解決策の検討は、有識者やアジャイルコーチ、技術者に頼ってほしいのですが、本章では、課題の捉え方と進捗把握の仕方について概念的な説明をしておきたいと思います。

本題に入る前に、アジャイルは今後どうなるかわからないから成り行きで行動すると思っている方がおられますが、プロジェクトである以上、目指すゴールがあり、そこに向けた計画や予定がないということはあり得ないと私は考えます。従って、その計画と実際の差異が生まれるということも当然起こり得ます。アジャイルだからどうなるかわからないと考えるのではなく、アジャイルだからこそ柔軟に改善できると考えることが肝要です。

さて、プロジェクトがうまくいっていない場合、その課題を浮き彫りにする必要があります。アジャイルでは開発者が自律的に行動しますので、詳細はわからないと思うかもしれませんが、多くの場合、バックログをどのように対応したか、どの程度の時間を要したかデータが残っていますので、後から分析することは可能です。また、日々の作業を見ていれば、なんとなく課題の所在を特定できることも多いと思います。

アジャイルプロジェクトが遅延する理由にはどのようなものがあるでしょうか？
特殊な要因を除けば、以下のように大別できると思います。

・開発者のスキルが足りず、調査・検討・見直しなどに多くの時間が使われている
・アジャイルの理解が足りず、コミュニケーションや連携ができず非効率が生まれている
・要件の追加や変更が多発し、そもそも見積と実態があっていない

これら以外にも、メンバーの離脱や製品不具合など一般的な課題もあるのですが、当記事ではアジャイル特有の事象にフォーカスして解説を行います。

開発者のスキル不足は、初期のアジャイルプロジェクトで起こりがちな事です。ウォーターフォール型と違い、設計～開発～テストと全てをこなす多能工である必要がありますし、アジャイルプロジェクトは技術や仕様などチャレンジングなものであることが多いためです。起こりがちとはいえ、解決策は明確です。不足しているスキルを補うため、教育を行ったりチーム外から技術サポートの援助を受けるといったことが挙げられます。

続いてアジャイルの理解不足により非効率が生まれるというのは、失敗プロジェクトで多く聞かれる話です。アジャイルのプラクティスは、それぞれ意味があり理論を持っていますので形骸的にこなしたり、意図を無視したテーラリングを行うとその効果を享受できません。これについても外部の有識者や経験者からのアドバイスをもらうのが最も効果的と思います。

最後に要件のブレにより見積と実態にブレが生じている場合ですが、まずやるべきことが明確に整理できているかどうか確認することが重要です。バックログに目的とゴールが明記されているか？開発者は自分が行うべきことをタスクで説明できるか、といった感じです。バックログは丁寧に書かないと意図していることがうまく伝えられませんので、プロダクトオーナーの方は細心の注意を払わねばなりません。対策としては、ユーザー部門との調整を円滑化、プロダクトオーナーのスキル補填、リリースプランの見直しなどが考えられます。

課題認識と対策を決めることができればスケジュールを作ることができます。課題によってどの程度の改善が得られるかわからない場合もありますが、そのような取り組みもアジャイルにイテレーティブに取り組めばよいと思います。

これら課題の把握と対策の評価はスクラムマスターが大きな役割を占めます。開発者やプロダクトオーナーを支え、ステークホルダーや外部の支援を巻き込んで、よりよいチームを実現していただきたいと願っています。

今回はアジャイルプロジェクトの進捗報告に関する注意ポイントを説明しました。次回は、プロジェクト遂行時によくある他の課題とその改善策を紹介いたします。