認定スクラムマスターになった。

普段の仕事でスクラム開発したり、カンバン管理したりと断片的には取り入れていたが、体系的に学んだのは今回が初めて。本やウェブサイトの解説を読んだだけでは分からないことがたくさんあって視野が広がった。

Agile Business Institudeの研修を受けた。製品開発チームのために、とサポートしてくれたtsumugにはとても感謝している。私なりの気付きや過去の知見との関連をまとめてみる。

スクラムに関連する技術

スクラムを進めるために必要な技術がいくつかある。実践されている方もいると思うけど、特に重要なものとしてテストオートメーション、継続インテグレーション、継続デリバリを挙げたい。

スクラムではユーザーストーリーを実現するために小さな単位で作業をするのだけど、検証不可能な作業はおおよそ「完了」させることが出来ないので、ストーリーを「実現」することが出来ない。

個人的に取り入れている開発スタイルとしてはTDD (=Test Driven Development / テスト駆動開発)で、開発完了の定義にテストを含めるという意味合いでスクラムと相性が良い。昔ちょっとだけ流行ったXP (eXtreme Programming) も、チームでプロダクトを前進させるというスクラムと相性が良さそうだった。

10年くらい前に出ているいくつかの取り組みは、スクラムに適用すると上手くいくのではないかと思う。

スクラムとは

プロダクトの前進に対してチーム全体で取り組んでいくためのチーム作り、開発スタイルを定義したフレームワークである、と理解した。

Joe Justiceという方が講師となって解説してくれたのだけど、随所にリラックス、ハッピー、ファンという言葉が出てくる。Joe-sensei自身、いきなりウィッグをかぶって登場するしネタ感ある。

リラックス、ハッピー、ファンに仕事をするためというわけではないが、スクラムではいくつかのイベントを定義している。スプリントプランニングやスプリントレビューといったイベントがそれに当たるが、随所で状況確認を挟み、良いことがあったらお祝いをするということをフレームワークに取り込んでいる。ファシリテータ（スクラムマスター）はこうしたイベントを取り仕切る必要があるが、フレームワークとして定義されているのでやりやすい。

開発プロセスは様々な手法があるが、プロダクトを前進させるための集中、困難に立ち向かう勇気、課題を共有するopennessなど、作業者の感情を大切にするものはあまり見かけなかったように思う。そういった意味で、Joe-senseiがリラックス、ハッピー、ファンを大事にするということはかなり衝撃を受けた。楽しく作業することでプロダクトが前進する、という揺るぎない信念を感じた。

ちなみに、スクラムを取り入れることとプロジェクトの成功は無関係である。そもそもプロジェクトの成功とは何なのかという話なのだが、予算超過したり納期をオーバーしたら失敗である。しかし、スクラムを取り入れることで「成功の確率を上げる」ことは出来るということだった。こればかりは実践してみないと分からないのだが、失敗を避けるためのルールがフレームワークに取り込まれている点は前向きに受け取れた。

チームとロール

スクラムチームは、プロダクトオーナー1名、スクラムマスター1名、開発チーム複数名で構成され、おおよそ3〜9名程度が良いとされている。開発チームの人数はデザインや職能の違いで上下することがあるが、（製品における）フルスタックエンジニアやDevOpsの実践をすることで小さく保つことが出来る。

プロダクトオーナーはビジョンを持ち、顧客の要求を取りまとめて「ユーザーストーリー」としてプロダクトバックログアイテムを作る。ユーザーストーリーは、誰が何を実現したいのか、それは何故かをまとめる。これが本質的な製品の価値につながっていく。

ストーリーについて複雑度や具体的な作業を検討し、進めていくのはチーム全体で行う。スクラムマスターが進行を取り仕切る。

一般的な会社のロールに置き換えると、プロダクトオーナーは小さな製品開発会社のCEO、スクラムマスターはCOOに相当する、とされている。

イベント

スクラムチームは1回の開発サイクルを「スプリント」と呼んでいる。

スプリントプランニングでは、プロダクトバックログアイテムをより元にスプリントバックログを作成する。実装仕様の検討、デザイン、API開発、フロントエンド実装、検証などである。1つの項目は1日程度で終わる作業量が望ましい。作業量が大きくなると不確定要素が増える。

スプリント中にストーリー、タスクを消化していきデイリースクラムで共有する。ブロッカーや困っていることがあったらチーム全体で助けること。

スプリントの終わりにスプリントレビューを実施して、スプリントバックログを消化することが出来たか、プロダクトが前進したか（インクリメント）を判断する。達成できたらお祝いする。スプリントレトロスペクティブで振り返りを実施して、スプリントが完了する。

スクラムのフレームワークに設定されたイベントをこなしていくことで、確実に製品が前進するし、開発チームは達成感が得られて、リラックス・ハッピー・ファンを実現することが出来る。

成果物

スプリントの終わりには、インクリメント、プロダクトバックログアイテム (PBI)、スプリントバックログが成果物として得られる。

インクリメントは、チームの完了の定義に沿う利用可能な成果物。実際には大きなユーザーストーリーの一部であることが多い。例えば、あるサービスを利用したときの領収書を発行する際の「画面表示処理」などが該当する。

プロダクトの開発中に発見した新しい課題や改善案は、PBIやスプリントバックログに登録しておく。

スクラムを支えるツールとプロセス

メインとなるウェブアプリケーションの開発業務では、フレームワーク（Django Test / Rspec）を使ってテストを書き、CircleCIで継続インテグレーションしている。チームで合意しているルールとして、常にテストカバレッジは90%以上、テストの無いPull Requestは無条件でrejectして良いルールにしている（レビューしない）。また、静的解析には Sider, CodeClimate を使っている。

circleci.com

sider.review

codeclimate.com

全力でアクセル踏むためには最低限これくらい必要、と思っている。

tsumugとスクラム

私はハードウェアスタートアップのtsumugを手伝っている。Twitterでサービスの紹介をしているので見たことのある人もいると思う。

tsumugでは今年の春くらいからスクラムを導入し始め、9月の認定スクラムマスター講習を受けてから一気に加速した。

組織全体のプロセスを急激に切り替えたので一部のメンバーには短期的にストレスがあったと思うが、今では良い感じに回っているように見えるし、結果として良い方向に振れたと思う。経営層を含めてスクラムに舵を切れたのは本当にラッキーだった（抵抗勢力がいると必要性を議論したり、感情的に対立したりして大変な事態が予想される）。

私自身がスクラムマスターとなって、今は1週間単位で忙しくスプリントを回している。分かったことがいくつかあったので思いつくものを書いてみる。