12
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

スプリントレビューが組織の在り方をガラッと変える

Posted at

はじめに

なんちゃってアジャイル・スクラムを始めてはや1年。

「スプリントレビューって意味あんの?」
「事前に打ち合わせした通りのものを作ってるのに、その確認なんて時間の無駄じゃね?」
「ステークホルダーも忙しいし…」

こんなことを考えていた時期が僕にもありました…。が、つい先日チームで初めてスプリントレビューを行ってみて、直接的にも間接的にもかなり大きな収穫があったと確信しました。特筆したいのは、直接的に得られるもの以上に、スプリントレビューは組織の在り方を大きく変えるポテンシャルを秘めたイベント・考え方だということが実感できたことです。

そこで、僕らが経験したスプリントレビューの良さをなるべく具体的に共有したいと思います。

前提

僕らのチームは6人で、ベテランエンジニアが2人と若手4人のスクラムチームでやっています。今やっているのは「顧客に送るDM(ダイレクトメール)をシステム化することで、業務を楽に、ミスなく行えるようにしようプロジェクト」です。関係者は以下。

ぼくら:開発者
セールス・マーケター:ユーザー/ステークホルダー
物流会社:ユーザー/ステークホルダー

プロジェクトの開始前に行ったこと

いわゆる上流工程を、ベテランエンジニア2人+僕の3人で行いました。

ユーザー(セールスメンバー)へのヒアリング

そもそもどんな課題意識があるのか、具体的に業務のどこが煩雑になっていたり、ミスがおきやすくなっているのかを聞き、プロジェクトの目的を明確にしていきました。

基本設計とUI設計

ヒアリングの途中からすでに基本設計に着手。基本設計がざっくり決まったらUI設計に着手。

分科会(インセプションデッキ作りに近いイベント)

XDのプロトタイプをもとに、ユーザーに「こういうものを作ります」と説明。主に不足している要件を出したり、仕様の確認をしたりして、開発スタートできる状態に。

この時点でユーザー側とはある程度「これでいけそうだな」という認識のすり合わせというか、コミュニケーションはできている状態でした。なので、これまでのやり方であれば後はもうリリースまでコミュニケーションはほとんど取らず、いきなり本番お披露目という形。

このやり方を取っていたときも、実はそこまで問題があるわけではありませんでした。仕様で困った時はユーザー(社内のセールスメンバー)に聞きに行くし、ユースケースもある程度把握していたので、本番リリース時に「そもそも使われない」とか「機能が足りてない」とかいう課題はなく、最低限のクオリティは担保できていたように思います。

一方、アジャイル・スクラムの進め方には課題感がありました。というのも、スプリントゴールがほぼ機能していなかったからです。

例えば、「box(クラウドストレージサービス)にファイルをアップロードできる」みたいなスプリントゴールを立てていたのですが、、、

仮にそれを達成したとして、自分たちの自己満以外に何も得られるものがなかったんです。

「スプリントゴール達成しましたね。で?」みたいな虚無感…。

形だけはアジャイル・スクラムっぽく進めてはいるものの、スプリントゴールを立てる目的がないまま開発を進行していくのは、強烈な違和感になっていました。

スプリントレビューで得られた直接的な利益

実際に触ってみてわかるフィードバックを得られる

分科会でも「こんなUIになります」と見せてフィードバックをもらっていましたが、やはりユーザーが実際に触ってみることで出てくるフィードバックの質は全然違います

「「はがき」って一口に言っても、官製はがきとか大判はがきとかあるから、「はがき」だけじゃ「どのはがき?」ってなるかもね」
「宛名の印字方法って固定? 変えられるようにできない?」
「はがきの表面に何を印刷するのか、初心者だとちょっと分かりづらいから説明があると嬉しい」

などなど、、、

よりよいプロダクトを作るにあたって、具体的なフィードバックはかなり有り難かったです。

実はすごく価値がある機能を発見できる

作っている僕らからするとなんでもないような機能が、実はユーザーにとってすごく価値のある機能だったりします。今回はこんな感想がありました。

ユーザー「送り先のセグメントができるんですか?」
僕「はい、できるようにしてますよ」
ユーザー「おお…マジすか!!!それはめっちゃありがたい!!!」

実はこれまで、手動でDMを送るにあたって詳細な送り先のセグメント化ができなかったんですが、「まあセグメントできた方がいいだろうな」くらいの軽い感覚でセグメント化できるようにしていたところ、革命が起こったレベルで喜んでもらえました。

士気が上がる

スプリントレビューの終わりに、何名かから「リリースが楽しみ!早くリリースしてほしい!」という声をもらいました。やっぱりモノづくりをやる人間として、期待されているということを直接ユーザーから聞けるのはモチベーションにつながりますし、より速くより高い品質のプロダクトをリリースしようと自然と思うことができますよね。

スプリントレビューで得られた間接的な利益

スプリントゴールに意味が生まれる

開発のすべてがユーザー中心になり、コミットメントする場があることで責任感が生まれ、よりゴールに対して納得し、集中することができるようになりました。

期待値のマネジメントができる

プロジェクトにはスコープがあります。「僕らが最初に提供するもの」と「ユーザーが求めているもの」を近づけることで、出来上がるものへの納得感がスプリントレビュー内で形成されていきます。

(強制的に)顧客と向き合える

上流工程を担当した3人以外のチームメンバーも、実際に顧客と接することでより強く顧客と向き合い、アウトプットではなくアウトカムを意識することができたと思います。

実際にお客さんを目の前にしてソフトウェアをデモするだけで、チームは自分たちの果たすべき成果責任に対してもっと自覚的になれる。なぜなら、デモをするとまず、自分たちのソフトウェアに期待している人が実在することに気づくはずだからだ。利用者は実際の人間で、解決すべき課題は現実のものだ。お客さんは君のソフトウェアを使ってそれをなんとかしたいと思ってる。こうしたことを実感できることの効果は大きい。

『アジャイルサムライ』より

さらに言えば、スプリントレビューによってチームはより外部志向になっていきます。「お客さんは何に困っているのか?」「自分たちはどうすればそれを解決する手段を提供できるのか?」をスプリントごとに意識することで、ただのエンジニアではなく、技術を用いて課題解決を行うビジネスマンとして成長していけそうな気がしています。

顧客との信頼関係ができる

なんのコミュニケーションもなしにいきなり機能をリリースすると、ユーザーはやっぱり最初不安に思うものです。

「ほんとにちゃんとできてる?」
「使っても問題起きないかな?」

など、特にミスが起きてはならない領域に関わる機能だとなおさら不安です。ですが、事前に触ってもらったり、スプリントレビュー内で細かな疑問点を解消していくコミュニケーションの中で信頼関係が構築されていきます

スプリントレビューに参加してもらったユーザーは、実際に本番リリースした際も安心してその機能を使うことができ、最初のユーザー体験が大きく向上することになるでしょう。そうすると、さらに開発に協力的になってくれたり、フィードバックを送ってくれたり、デベロッパーとユーザーが協力し合いながら開発を行っていく組織に変わっていく。まだスプリントレビューはやり始めたばかりですが、近い将来そんな組織に変わっていくんじゃないかと。

終わりに

  • より速く、より価値あるものを届けるユーザー中心の組織に変わる力学
  • 開発者とユーザーが協力してプロダクトを作り上げていく信頼関係

これらが、僕の感じたスプリントレビューで特に得られた効果です。もちろん、現場によって状況は様々ですが、アジャイルを取り入れている組織であればぜひ行ってほしいと思えるだけの成果がありました。

以上、ご参考になれば幸いです。

12
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?