アジャイルコーチが見た開発現場~はじめてのアジャイルでつまづく12のポイント~【後編】

マーケットの速い動きと変わりやすいニーズに対応するためにアジャイル開発は大変有効な手段ですが、一方で本を読んだだけではうまくいかない事も多く、実際のプロジェクトではどうしたらよいかという質問も多くいただきます。

そこで私がアジャイルコーチとして様々なプロジェクトに参画してきた経験から、はじめてアジャイル開発に取り組む企業が陥りがちなポイントについてご紹介し、どのように対処すればよいか解説を行っていきます。

今まではプロジェクト立ち上げ時とプロジェクト開始時に陥りがちなポイントを説明しましたが、今回はプロジェクト遂行時に起こりやすい課題とその解決策を解説します。

連載記事:
はじめてのアジャイルでつまづく12のポイント~【前編】
はじめてのアジャイルでつまづく12のポイント~【中編】

1.プロジェクト遂行時:うまくいっているのにプロジェクトの進捗を説明できない

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

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

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

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

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

アジャイルコーチ

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

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

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

アジャイルコーチ

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

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

2.プロジェクト遂行時:うまくいっていないのでプロジェクトの進捗を説明できない

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

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

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

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

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

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

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

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

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

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

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

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

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

3.まとめ

今まで三回にわたって、アジャイル開発のプロジェクト立ち上げ時、プロジェクト開始時、プロジェクト遂行時、それぞれの段階で陥りがちな6ポイントについて説明しました。これからアジャイル開発に取り組むプロダクトオーナー、スクラムマスター、マネージャーの皆様に少しでもご参考になれば幸いです。

おすすめ記事