ウォーターフォール型プロジェクトでも取り入れられるアジャイルプラクティス
ウォーターフォール型プロジェクトしかやったことないくせに勉強だけはしているアジャイル耳年増です。現在参画しているプロジェクトである程度好き勝手にできる権限を貰ったのでアジャイルプラクティスを取り入れられないか実験しており、その中でうまくいったもの・イマイチ効果がなかったものがわかってきたので、シェアします。
なお、ウォーターフォールとアジャイルの「いいとこどり」をする気は全くなく、どうしたらウォーターフォールしか知らない人たちにアジャイルの価値観を植え付けるか、そのためのくさびとなるような活動は何か、ということを探るのが目的です。
効果があったもの
まずは、効果があったものを紹介します。
作業中/仕掛中のタスクの数を制限する
こちらはカンバンというプラクティスの中の1テクニックです。「人間の脳はマルチタスクができない」ことはよく指摘されていますが、研究するまでもなく、同時に10も20もタスクを抱えていたところで、その日に取り掛かれるのはせいぜい5つ程度でしょう（メールを返信する、というのまでタスクとして管理しているなら別ですが）。
カンバンは、各タスクの状態（未着手、作業中、完了など）を一目で見るためのボードです。
カンバンボードそのものについては、ウォーターフォールの現場ではExcel至上主義になっていることが多く、中々導入することが難しいです。
しかし、カンバンにおける重要なルールである、「チームが一度に作業中/仕掛中/Work in progressにできるタスクの数を制限する(WIP制限)」、というのは、どんなタスク管理手法を使っているプロジェクトでも導入でき、かつ強力なプラクティスです。
このルールを導入することで、マネジメント側は誰が今何をやっているかをよりはっきりと理解できますし、スタッフ側もあれもこれもやらなきゃ…というパニック状態から解放されます。実際、私のチームでも、これらのメリットを享受できています。
ちなみに、私のチームでは、タスクに優先度や締め切りを付けることを廃止しています。なぜなら、タスクは大抵締め切り = 優先度となり、さらに優先度は割り込みタスクによって次々と変化するため、ほぼ間違いなく形骸化するためです。その代わりに、
・今この瞬間にやってよいのは作業中になっているタスクだけ
・より優先度の高いタスクが発生した場合は、作業中のタスクを一つ未着手/保留に戻し、その優先度の高いタスクを作業中にする
というルールのみでタスクの優先度を管理するようにしています。
定期振り返り（レトロスペクティブ）
これまで私が参画したウォーターフォール型のプロジェクトでは、振り返りはプロジェクトの終わり（ウォーターフォールなので短くとも半年、数年がかりも珍しくない）に1度か、良くて数か月単位のフェーズの切れ目ごとでした。
一方、アジャイル開発では、1週間～1ヶ月単位のスプリントごとに振り返りを行い、どんなことをしたか、何がわかったか、どこがよかったか、どこが悪かったか、今後取り組むべきことは何か、といったことを話し合うのが一般的です。
私のプロジェクトでは、ウォーターフォールなのでスプリントという概念は存在していないのですが、2週間に一度振り返り会をセットしています。これにより、メンバから「こういう場がないとあえて言わないけど、こんなところが非効率だと感じているよ」という意見を集めることができ、それを解決するために動けています。具体的には、次のような課題が振り返りによって明らかになりました。
・プロジェクトフォルダが散らかっている
・他チームとの役割分担であいまいなところがある
・他チームとのコミュニケーションで問題がある
・クライアント側の時間が取れず思うように進められない
効果が薄かったもの
実践してみたものの、効果が薄かったものを紹介します。
ペアプログラミング/モブプログラミング
ペア、もしくはそれ以上の人数で同じ画面を見ながら開発を行う手法です。その場ですぐにフィードバックすることができるため、品質向上が見込めます。
しかし、ウォーターフォール型プロジェクトでは、ドキュメント作成やミーティングなど、開発以外のことをしている時間が多く、ペアプロ/モブプロに取り組めたときは効果があったのですが、時間を確保するのが難しく、思うような効果は得られていません。とはいえ、開発・テストフェーズでは効果を発揮するかもしれません。
インセプションデッキ
これがうまくいかなかった理由は別記事でまとめました。
難しさ
ウォーターフォール型プロジェクトにアジャイルのプラクティスを取り入れ、あわよくば完全アジャイルにしてしまおうとする上で難しいと感じた点は次の通りです。
価値観の違い
素早く失敗しながら前に進むアジャイルと、失敗しないように計画を立てるウォーターフォールでは、そもそもの価値観が大きく違います。そのため、価値観の共有が必要、もしくは価値観を理解して初めて効果を実感できるプラクティスは取り入れるのが難しそうです。
推進メンバは必然的にスクラムマスターと開発メンバの兼任になる
アジャイル（の中でもスクラム）では、複数の役割を兼任すると、どの役割として振舞っているのかが自分にもチームメンバにもわかりづらくなることから、バッドプラクティスだという意見が多いように感じます。
ウォーターフォール型プロジェクトにはスクラムマスターという役割が存在しないため、推進メンバは必然的ににスクラムマスターと開発メンバを兼任することになります。そのため、意識的に自分にもメンバにも今どちらの立場として振舞っているかを伝える必要があります。（が、中々難しいです）
優先度を下げられる
ウォーターフォール型プロジェクトでは、QCD、特に期限第一優先で動いているため、忙しく、多くのタスクの期限が迫っていると振り返りなどよりもタスクを優先しようとすることがあります。
そんな時は例のスクラムマスターになった気持ちで、「将来の10時間を節約するために、今皆の1時間を貰うんだ」と各プラクティスの重要性を説き、継続的に行われるようにしなければなりません。
おわりに
この記事で紹介したもの以外にも、様々なプラクティスがありますので、取り入れられるものから取り入れ、啓蒙し、あわよくば完全アジャイルにしていきましょう。
この記事が気に入ったらサポートをしてみませんか？