今回のテーマは、「スクラム開発」について。

この度、機会があってアジャイル開発の一種である「スクラム開発」の手法を顧客のプロジェクトに適用してみましたので、それについて書いてみます。ちなみに教科書通りの適用ではなく、使えそうなところをつまみ食いした感じではありますが、それでもよかったと思います。下に経緯を書いてみたいと思いますが、具体的なお客様の内情を書くわけにはいかないのでフェイクを入れています。

１）きっかけ

ある業務アプリケーションにて、開発が頓挫しかかっているプロジェクトがありました。顧客担当者の強い要望でウォーターフォール型で開発を進めていたのですが、仕様が決まらないんです。お客様の方で仕様は出してくれないので、こちらで仕様を想定して提案して、という進め方をするのですが、お客様の方でちっともまとめてくださらないし、「これでいい」とも言ってくれないので仕様が詰まらない。「これでいかがですか？」と持っていても、後から後から「あ、そう言えば」という話が出てくる。顧客に依存した特定業務のアプリなので、こちらで検討するのも限界があり、プロジェクトは一進一退を繰り返してた。そんなフェーズで参加しました。

２）プロトタイプ

そもそも前任者からは「立て直してくれ」と頼まれた訳でもなく、当初数週間は、プロジェクトの支援はしつつも様子見だったんです。特定業務アプリなので仕様を理解するまでに時間もかかりますし、お客様との役割分担状況や「押したり引いたり」の感触もわからなかったこともあります。
一通り状況や仕様が理解できてきたところで、プロトタイプを作ってみて、それを見せてご意見をいただく、という形にすることにしました。
そうすることでシステム・イメージが具体化されるので、いただくご意見がやっと「仕様」と言ってもいいレベルになってきたのです。しかし、「見せて」ー＞「ご意見を賜って」ー＞「修正」が繰り返されるばかりになる懸念がありました。そうなると、毎回、改訂した設計書を出してレビューしてもらう必要がありますが、開発チームに多大な負担がかかるためにサイクルが長くなってしまい、次の話をする頃には「なんでこういう仕様にしたんだっけ？」「ここはこういう話でよかったんだっけ？」となってしまい、仕様が詰まらなくなってしまいます。そこで、「スクラム開発」を提案することにしました。

３）お客様に「スクラム開発」を提案する

お客様の幹部には率直に「このままでは開発が進まないので、アジャイルでやらせてほしい」と申し入れました。スクラム開発を認めていただくところに、最大の力を注ぎました。あまり細かいアジャイルやスクラムの説明はせずに、「仕様書は作らないこと」「プロダクト・バックログ」というリストで仕様を管理すること、「スプリント」という「期間ありき」の開発タームを設定し、そこでできることだけやること、を説明しました。スライドは２枚くらいだったかな。共通語を作りたかったので「プロダクト・バックログ」「スプリント」「スプリント・バックログ」など重要な単語だけを拾って、それだけやります、と、あえて偉い人にプレゼンして承認してもらいました。受け入れてくださったお客様の大英断で、スクラム開発が承認されました。

４）開発

実際の開発は教科書通りではなかったです。こちらは開発請負の立場でお客様はお客様なので、「あなたがプロダクト・オーナーです」と指名したところで期待した通り動いてもらえる訳ではないし、開発チームもロケーションがバラバラでデイリー・スクラムなんかできないからです。
とは言え、スクラム開発の用語を使ってコミュニケーションをする事で交通整理がしやすくなりましたね。

５）効果

それでも、開発仕様を「バックログ」をベースにお客様と「これはやります」「これはやりません」「これは次のスプリントで検討するのでとりあえずバックログに」と確認・交通整理できるので開発チームの負担がぐっと減りましたし、ドキュメントの作成負担も大きく減って開発に集中できるようになりました。通常のQ&Aと違ってバックログはそれ自身が「仕様」なので、お客様の方からも「ちゃんと練って」ご意見をいただけるようになったと思います。Q&Aだと懸念点だけ言われて、「後はそっちで考えて」という事が多かったのですが、そこが変わりました。それで、プロジェクトが前に進むようになり、やっとリリースできるように。なんとか年末に納品を終えました。ですから、「スクラム開発」を取り入れてよかったな、と思います。

付録）参考書

西村直人、他著「SCRUM BOOT CAMP THE BOOK」翔泳社、2013

ご相談ください

OSSPlazaへのお問い合わせは、お問合せはこちらへ。