アジャイル・スクラム開発を経験して考えたこと・感じたこと

はじめに

この記事はスクラム開発の解説ではなく、私がスクラム開発チームやっていたときの備忘録です。
こんなんだったなぁとか大変だったなぁみたいなことを書きたいと思います。
内容も私の経験を元に書いているので、それはスクラムじゃないみたいなこともあるかもしれません。 一応スクラムマスターの元でやっていたので、そこまでズレてないとは思いますが。

プロダクトバックログ

スクラム開発を始めるにあたってまずやることは、製品で実現したいことを一覧で書きだすことです。 実現したいことはストーリーと呼ばれたりします。
具体例としては、ユーザーがブログにコメントできる、みたいな感じです。
プロダクトバックログは優先度順に機能が並んでおり、上から順番にやれば優先度が高いものから消化されていきます。
……ただこの優先度って綺麗に決まるものではなく、大抵ステークホルダー(営業さんだったりCSさんだったり)の方はこれも必須、あれも必須みたいな感じになります。
使う側・売る側からしたらそれはそうですよね。
また人によって優先度のイメージも違うので、ちゃんと管理しないと大抵カオスになります。
さらに、時間が立っていくとメンテが追いつかず、この機能はこっちにもあっちにも書いてあるみたいなこともよくありました。

ここらへんの取りまとめ等はPO(プロダクトオーナー)さんの責務ですが、エンジニア組織と各部署の要望を円滑にまとめる必要があるので、かなり大変ですね。

プロダクトバックログからタスクを作成

色々な事情が反映されたプロダクトバックログから、スプリントでやるタスクを決めます。
タスク化は、例えばブログの機能で、下書き機能をやるとして
フロントエンドは下書きボタンを追加するタスクと~…
バックエンドは下書きフラグを追加するタスクと~…
みたいな感じでやっていました。
タスクの見積もりはストーリーポイントを使います。
これは時間ではなく、このタスクが1ポイントならこのタスクは3倍くらい掛かりそうだから3ポイントみたいに決めていました。
時間で見積もった方が分かりやすくない?みたいな話はどこの現場でも起きました。
プランニングポーカーといって、カードでストーリーポイントを出すやり方もあります。 口頭でもカードでもどちらでも良いと思いますが、カードの方が雰囲気は出るかもしれません。

なお、タスク化とそれを消化する責務は開発チームメンバーにあります。
なので、この設計書通りにやっておいてという感じではなく
プロダクトバックログにある要望から、適切に設計及び開発する必要があるので、難易度が高いと言われています。
下書き機能の例でいうと、ちゃんとメンバーが下書き機能を満たすタスクを全て作成する必要があります。

デイリースクラム

毎日決まった時間に会議を行います。朝会みたいなものでした。
そこで進捗や困っていることを話し合います。
困っていることや悩んでいることを解決できる場でもあるので、リモートワークだと特に有用かもしれません。

スプリントの振り返り

スプリントは1週間から2週間で、それを回していきます。
スプリントの終わりには、良かったこと(継続したいこと)や悪かったことを挙げて、振り返りをしてチームを改善します。
スプリントを回すごとにどんどん良かったことが増えて、悪いことは改善されていく仕組みです。
実際は色々と新しい問題が起きたりしますが、振り返り自体はとても良いことだと思います。

また、機能のレビューも行います。これはプロダクトに関係する部署の方にもレビューしてもらいます。
それによって、時には機能の改善をおこなって、より良いプロダクトに柔軟にしていく感じです。

スクラム開発を関係部署に理解してもらえない問題

スクラム開発はエンジニア組織で完結するものではなく、プロダクト単位の開発手法なので 営業さんやCSさんなどにも参加していただきます。

そのため関係部署の理解が必須です。
ただ、エンジニアでも中々最初はイメージがつかないのに、エンジニア組織はスクラム開発でやるから~ みたいな話をしても、うまく伝わりませんよね。
スクラム開発をやることで、関係部署の方々にもしっかりメリットを伝えて分かって頂かないと 良いから要求通りに作っといて、みたいな話にもなりかねません。
これはエンジニア組織側からちゃんと最初にお伝えしたほうが良いなと思います。
なお私達はちゃんと伝えられてなかったので、理解が得られず瓦解寸前になりました。

振り返ってみて

スクラム開発で大変かつ重要な点は、2点あると考えました。
一つは、エンジニア組織とプロダクトの関係組織をうまく調整して、適切なプロダクトバックログを作ることだと思います。 それに気づいてからは、営業の方と雑談しながら機能について話したりして、ズレや軋轢がないように動きました。

もう一つは、自走してタスク化~開発ができるエンジニア組織を作ることです。
その両輪がうまく組み合わないと、中々難しいなぁと思います。