スクラムはじめました！～実践編～

本記事は「2014年2月」に投稿したブログ記事を再編集したものです。

いよいよ実践編に入ります。

前回までは、スクラムをどうやって導入していったかを書きました。
ここからは、実際にやってみて感じたことを表現していきます。
※やはり、本やネットに書かれていることを読んだだけでは吸収できないことが多いですね

～実践編(1) ～

やってみて

実際にスクラムを実践してみて感じたことは、「スクラム＝現場が良くなる」ではないということです。

スクラムは、チームが抱えている問題を明らかにすることが大きな目的であるため、どんなにスクラムを定義通りに実践したとしても、それによりメンバーの振る舞いが変わらなければ、いつまでも現場は良くならない。ということを実践して経験として得たことがチームにとっての大きな成果となりました。

「スクラムをきっかけにして、メンバーの振る舞いが変わる」

という方が正しいですね。

どんなところが良かったか

スコープの明確化

スプリントというタイムボックスで区切ることで、やるべきことに集中できることが良いです。

これまでは、緊急度や重要度に関わらずたくさんの要件を並行で対応していくことが多く、今やらなくても良いことに時間をとられていたことがわかりました。

メンバー間の対話

スクラムをはじめてから、確実にメンバー間の対話が増えました。

作業に入る前のゴールを共有すること、解決策をメンバー間で相談しあうこと、リリース前のクロスチェックで確認すべき点を知識として伝授することなどが増えています。

一方通行の【指示】ではこうはなりませんね。

メンバーが考える

問題点＆改善点が明らかになることで、メンバーそれぞれがどうやって問題を解決したら良いか、どうやって改善できるか、を考えることが増えました。

メンバーから出た改善策は次のスプリントからすぐにやってみてさらに改善点を見つけるサイクルが生まれています。
先に進んでいる感がありますね。

まだまだ細かな発見もたくさんありましたが、ここでは代表的なものをピックアップして書いてみました。

～実践編(2) ～

うまくいかないこと、改善が必要なこと

予定と実績

予定と実績は必ずといってよいほど差がでます。
作業へ入る前に十分な情報収集をして見積もったとしてもやってみてわかることや、想定と違うことは多々あります。

ここで注力したことは、予定（見積り）を正確にしていくことよりも、実績としてどのような問題が発生し、どうやって解決したか、そして、想定外の問題が発生したときにどうやって早く軌道修正をするか、という点です。

見積りが適当で良いというわけではなく、予定はあくまでも予定であり、状況が変わればやることも変わってくるので、できるだけ早く問題点等を共有し、正しい方向へ向かうための活動をしていこうという改善がメンバー全員で導き出した（この段階での）答えです。

活動にかける時間

スクラムでは、計画を立てる時間やふりかえりに費やす時間がこれまでよりも多くなることで、手を動かす時間が少なくなるため、活動に費やす時間を最適化する必要があります。

ただし、時間を短くすることが良いことではなく、活動に時間をかけることで、メンバー全員での情報共有ができ、ゴールへの意識を一致させることができるため、手を動かす時間を短縮（認識の相違により生まれる作業のムダを排除）することができます。
⇒計測はしておらず感覚的なものですが。。。

活動にかける時間は要件の複雑度やメンバーの習熟度などによって変わるため、繰り返し状況に合わせてメンバー全員で最適化していきたいですね。

スクラムの基礎知識

スクラムをはじめるにあたり、スクラムの知識が無いメンバーもいる中ではじめたため、用語や方向性、進め方など、正しくスクラムを実施できているか不安な点もありました。

スクラムを十分に勉強した上ではじめることでも良いですが、今回は、実際に進めながら知識を増やしていく方向ですので、例えば、１週間に１つまたは２つ程度の用語を変えていき、（ [ 要件一覧 ] という呼び名を [ プロダクトバックログ ] と呼び変える等）かつ、以下のような、スクラムの定義を簡単にまとめたものを用意して常に見えるところに置いておくという仕掛けをしました。

以下はスクラムの概要を簡単に表現したもの。