本には書かれていない、アジャイル開発を成功させる重要なプロセス

 

刀を持ったサムライ

同時期に走ったある2つのプロジェクトの話。

プロジェクトの規模、メンバのスキルはほぼ同じ。これまでウォーターフォール開発しか経験がなく、アジャイル開発は初めて。新しいプロダクトを作るプロジェクトで、アジャイル開発をチャレンジしてみようと始まった。

プロジェクトの成否を測るのは難しいが、一方はプロダクトリリース前にプロジェクトが中止になり、もう一方はプロダクトをリリースした。その違いは何だったのか。


2つのプロジェクトに何が起こったのか

2つのプロジェクトはスクラムをベースにした。同じようにインセプションデッキを作成し、スプリントを分けて、プロダクトオーナー等の役割を決めて、デイリースタンドアップ、スプリントレトロスペクティブをした。

プロジェクトが進むに連れて、後に中止になったプロジェクトでは、機能の作り込みが膨らんだ。またアジャイルの名のもとに仕様変更が多数発生した。メンバーも疲弊した。

プロダクトをリリースしたプロジェクトでは、序盤にある作業をしていたので開発着手は遅れたが、機能の作り込みは膨らまず、仕様変更も抑えられ、メンバーと顧客の関係も良好のままリリースした。


初めてのアジャイル開発の成否を分けたもの

プロダクトをリリースしたプロジェクトが、序盤にやっていた作業はインセプションデッキの深化だった。

その業務とはどんなものか、何が課題なのか、どう解決するのか、その先にどんな未来がまっているのか、どんなステップでその未来を目指すのか。顧客と一緒になって、それらをビジョンとして1つのドキュメントにまとめた。

徹底的にWhy, What, How をまとめた資料だ。これがあると顧客もメンバも間違わない。この機能は必要か?のような議論になったときに、それは今のステップではないと誰もが納得して判断できた。

これに対して、後に中止になったプロジェクトでは、そういった判断が効かなかった。あったほうがいい(かもしれない)機能は実装され、顧客がこうしたほうがいいと言ったものは優先度を上げて対応された。


必要なものはビジョンだ

もちろん全く同じプロジェクトは存在しない。しかしこれは1つの事例だけではなかった。インセプションデッキを作らなかったり、形だけのインセプションデッキを作った他のプロジェクトも同様だった。

新しいものを作るときに、Why, What, How を作る側が知らないというのは驚くかもしれない。しかしこれは大きな組織ではありがちなのではないだろうか。

誰かが考えたアイデアが回り回って遠くの誰かが作る。その頃にはビジョンは見えなくなっていて、誰もそれがビジョンに沿っているか判断できず、作った後にこんなはずではなかったとなる。それを防ぐにはインセプションデッキだけでは不足している。

インセプションデッキに加えて、何が課題なのか、どう解決するのか、その先にどんな未来がまっているのか、どんなステップでその未来を目指すのか。そのビジョンこそが、アジャイル開発を成功させるために必要だと私は思う。


ビジョンの描き方は以下の投稿で紹介

各プロセス、考え方などアジャイル開発を知るための良書

コメント

このブログの人気の投稿

メールのURL(リンク)が途切れる問題に対応するアドイン(Outlook)

メールからRedmineのチケットを作成するアドイン(Outlook)

複数行テキストの「表示数を増やす」を自動で開くChrome拡張機能(SharePointモダンリスト)

Google Meetの参加リクエストを自動承諾するChrome拡張機能

もしもアフィリエイト かんたんリンク文字化け対策ツール(全角→半角記号変換)