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

アジャイルの開発風景を想像してくださいと言われたら、皆さんはどのようなシーンを思い浮かべるでしょうか。

おそらくホワイトボードを囲みながら和気あいあいとディスカッションしているイメージがあると思います。自分達が製品を開発していくわけですから、互いに意見を出し合い、議論し合意していくことはアジャイルの象徴的な動きと言ってもよいかもしれません。

そのようなシーンも確かにあるのですが、プログラム開発の日常は、多くの時間をコーディングとテストに割くことになります。実際のプログラミングは一人で行う作業であり（ペアプログラミングやモブプログラミングもありますが）、黙々とパソコンと対峙して作業していく時間のほうが圧倒的に長いのです。

チームメンバーがある程度アジャイルに慣れてくると、議論を行うイベント（会議）も手際よくこなせるようになり、更に一人で作業する時間が増えていきます。
その段階で気を付けなければならないのは、開発者のコミュニケーション不足です。

当たり前の事と思われるかもしれませんが、慣れてきた時に新たな課題が生まれることはよくあることで、見落としがちなリスクがそこにあります。

開発者が自分の作業を把握し、ガリガリと開発を行っていくことは効率的に作業を行えている証（あかし）であり、素晴らしいことなのですが、その裏返しとして会話の量が減少します。

会話をしなくても作業ができることは一見問題ないように思えますが、孤独な開発作業は開発者の視野を狭めてしまい、都度都度チームメンバーに相談するよりも、自分で判断する傾向が増えていきます。各自が思い思いのプログラミングを始めると、仕様のズレや無駄なロジックが増えてしまい、結果的にバグの発生や手戻りの増加につながります。

このように開発者が各自の判断で開発してしまうことを「カウボーイコーディング」と言います。これはアジャイル開発がうまくいかない典型的な開発スタイルですので、当然避けなければなりません。
アジャイルプロジェクトはうまく進んでいるのに、できあがった製品がいまいちだなと思ったら、このような点も確認したほうがよいかもしれません。

それでは、カウボーイコーディングを避けるためにどうしたらよいでしょうか？
答えは簡単です。前述のとおりコミュニケーション不足がその発端である可能性が高いので、開発者同士の会話量を増やし、簡単な確認も気兼ねなくできる雰囲気を作り上げることです。例えば雑談をしてもよいでしょうし、お菓子などを置いてリラックスした雰囲気を作る事も効果的です。

緊張して静まり返ったフロアにキーボードを叩く音だけが聞こえてくる職場では、孤独な開発戦士が生まれやすいことをご認識ください。

アジャイル開発を行っていくうえで、もっとも気になる事の一つとしてリリース時期を守れるのか？という点が挙げられます。

要件が定まらないまま着手しますので、仮置きしたリリース時期を守れることを保証できるものはなく、なんとなく不安な気持ちを抱えている方も多くいらっしゃると思います。

社内的にもプロジェクト計画の説明をし、業務との兼ね合いからリリース時期を定める必要が出てきます。そのため、研究開発のような模索的プロジェクトを除き、多くのプロジェクトではリリース時期を定める必要があり、自由に変動させることができなくなります。
一方で開発が進むにつれて要件は増加し、開発ボリュームは膨らんでいきます。
当然、当初想定したリリース時期が近づいてくるほど、その時期を守ることが難しくなり、開発者の負荷が高くなっていきます。
結果的にリリース時期を無理に変更したり、開発者が疲弊したり、製品の品質が低下したりと様々な弊害が生まれ、失敗プロジェクトとして認知されかねません。
これがアジャイル開発失敗のロジックです。

”リリースを守ろうとしても守れない、だからアジャイルでは成果が出せない”はたして本当でしょうか？

実はこの状況が生まれる背景には、いくつかの原因が考えられます。

まず最初に注目すべき点は、計画段階で策定したリリース計画の精度です。
何を根拠にリリース時期を決定したのか？が重要です。
「業務都合でｘ月までに欲しい」や「感覚的に開発規模は3か月でできるだろう」といった事が根拠の場合は、そのリリースが守れないことを想定しておかなければなりません。
私の考えとしては、リリース時期を決めるためには、やはり開発ボリュームの見積を行うべきと考えています。その見積があれば、後々その見積と照らし合わせて差異を確認し、計画修正を行うことができるからです。

次に注目したい点は、バックログの精査です。
計画段階に見積を行うとしても、その精度はあまり高くないと思われます。
だからこそ、開発を進めるなかで常にボリューム変動を確認しつつ、バックログを精査する必要があります。
要件を詰め込んだだけのバックログはただの「やりたいことリスト」です。それを精査し、内容とボリュームに応じて実装を検討することが重要です。これをおろそかにするとリリースがあやうくなっていきます。

最後に注目したい点は、リリースの変更可能性を説明しておくということです。
アジャイルのメリットは開発途中でも要求の変更が行えることですが、要求が変われば見積も変わり、結果として当初想定とは乖離が生まれることは容易に想像できます。

しかしアジャイルを理解していない人はこのような認識がありませんので、社内でプロジェクト説明や進捗報告が行われた際に、資料に書かれたリリース時期を絶対視します。後々それは仮置きのスケジュールですと言っても恐らく理解を得ることは難しいでしょう。

そのような誤解を避けるために、計画段階や要件変更が発生した場合は、都度都度リリース計画を見直し、どの程度のブレ幅を想定しているか説明をおこなっておくべきです。
リリース時期を既成事実として定めてしまうから、アジャイルの柔軟性を活かすことができず、結果として詰め込み開発を行うツラいプロジェクトと化してしまいます。

業務の都合上、リリース時期をずらせないことはよくあることですが、一方で開発が間に合わなくなることもよくあることなのです。
この二つのジレンマに対して折り合いをつけていくことがリリース計画の本当の目的だと私は認識しています。

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