スクラム導入したいと相談を受けたので色々話してきた

別の会社に勤める知人から、会社にスクラムを導入したいという話をされた。

ひとりスクラム歴5年の経験談を、ビール飲みながら偉そうに語ってきたのでメモ。

自分のこれまでのスクラム

前職

ひとりで初めて周囲に説明。事業部門とエンジニアふたりを巻き込めて、生産性が目に見えて向上。手作業だったリリースも自動化、システムの一部をマイクロサービスとして切り出すなどの成果も。

ところが上司が変わり、ストーリーポイントを実時間に直せ、プロダクトオーナーの決定を無視、トレードオフスライダーは予算と時間は最小・品質とスコープは最大などと言い出したため、プロダクトオーナーが離職。

引き継げそうな人はいたが、上司とのやり取りを嫌い、引き継ぐ人がおらず自然消滅。

現職

Jiraを使っているけどタイトルにコミットログレベルの文言、説明やコメントなし、ついでにGitのコミットログは空白なのでマッピングもできない環境。

少なからぬお金を払っているのにナレッジベースとしての意味がないので、もうちょっとマシにできないかと、ここでもひとりスクラムを開始。

スクラムを何のためにやるのか

エンジニアと非エンジニアのコミュニケーションを密にし、情報の非対称性を減らし、意思決定を早くするためのものだと思う。生産性の向上は、それらの副次的な結果によるものと考えている。

スクラムアジャイルな開発のためのフレームワークだが、当然会社や部署によってカスタマイズする必要が出てくる。

動くものを作り、確認してもらい、早めに失敗し修正する、を実現できればいいので、そもそもスクラムありきで動くべきではない。

個人的には、新規開発に専念できる場合がスクラムには最も適していると思う。一方、すでに稼働しているシステムの、運用保守をやりながら機能追加も行う場合、スクラムよりもカンバン方式のほうが適していると思う。

スクラムの場合、スプリント内にこなせるタスクを最大化しようと考えてしまいがちになるため、運用保守をしながらだと、タスクの優先度よりこなしやすいタスクが優先される場合があった。

SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話 | リクルートテクノロジーズ メンバーズブログ がそのあたりのジレンマを書いている。

自分は今、Jira Softwareを使って、運用保守はタスクをカンバンボードで管理、開発はエピックやストーリーをスクラムボードで管理している。こればボードやタスクの種類を切り替えることで、どちらの作業を行っているのか分かりやすくするため。でないとスイッチングが面倒で...

また、スクラムだけでなく、アジャイルな開発をしたいのであれば、インセプションデッキは作っておきたい。10個のうち、「我々はなぜここにいるのか」、「やらないことリスト」、「トレードオフスライダー」は必ず、できれば「エレベーターピッチ」も作っておき、定期的に確認することで、チームの方向性が揃いやすくなる。

デイリースクラム

知人の会社では、リモートワーク可能なため、デイリースクラムを夕方行う予定とのこと。

デイリースクラムは当日やるべきことの表明が最も重要だと考えているので、開発メンバーが揃うできる限り早い時間で行ったほうがいいと思う。

それぞれ朝会・夕会として、今日やることの表明と、今日できたこと・できなかったことの共有で分けてしまってもいい。

慣れないうちは細かすぎる説明で発言が長くなったり、議論や相談を始めてしまいがち。スクラムマスターが発言時間を計測する、脱線したら指摘するなど、ファシリテーションは必要。

開発に直接関係のない問題が発生し、それで時間を取られるようなことがあれば、スクラムマスターが迅速に対応する。とはいえ会社員、なかなかきれいに解決できるわけではないので、場合によっては「頼まれごとで2時間休み」みたいに時間を取る。

また、難しいのは困っていることの表明。以下のページでは、5本指朝会として、表明をシンプルに行う方法を挙げている。

www.ogis-ri.co.jp

見積もり

知人の会社もJira Softwareを使っているので、作業はエピックとして追加したいとのことだが、いきなりストーリーとエピックを切り分けるのは難しい。

詳解 : JIRA の ユーザーストーリー を適切に分解する にあるように、とりあえずストーリーとして追加し、大きすぎると思ったらエピックにして細かいストーリーに分けていくのがいいと思う。

大きい小さいは見積もりポーカー(プランニングポーカー)で決めたい。最初のうちだけでも、エンジニア、デザイナー、営業、カスタマー、その他プロダクトオーナーやステークホルダーなど、集められるだけ集めるといい。非エンジニアの数字は参考扱いでもいいのでやってみると、それぞれ何をどう考えて見積もるのか、相互理解のきっかけになる。

また、開発者の間では、早い段階でチーム内の基準となる数字を合わせたい。

以下参考(前職でDataSpider使ってたんだけど、会社が変わったらいろいろあったようで...)。

appresso.hatenablog.com

プロダクトオーナーが決まらない

これまでの会社が悪いのかもしれないが、はっきりとひとりに決まったことがない。本に出てくるような、もろもろ取りまとめて意思決定できる人がいるなんてのは理想だと思う。

複数人いる前提で、スプリント計画ミーティングやスプリントレビューには、可能な限り全員に参加してもらう。

全員参加ができない場合や、意見が割れた場合に備えて、決定権を持つ人を決めておくといい。だいたい社内の地位で決まっちゃうが...

スプリント期間

2週間を予定しているとのことだが、計画してリリースしてスプリントレビューして振り返りまでやろうだと、慣れないうちは2週間では難しいと思う。

これらの期間として1週間のバッファは見ておくといい。余ったら次のスプリントでの計画を前倒しし、バックログ消化にまわすなど臨機応変に対応。

特に、テストやリリースの自動化などができていない場合は、学習や環境整備に余った時間を使い、早い段階で自動化を済ませたい。

総括

スクラムやろうではうまく行かない。目標を明確にすべき。インセプションデッキを作るといい。

特にエンジニア主導だと、スクラムというフレームワークを型通りにこなすことが目的になりがち。メンバー同士やステークホルダーとのコミュニケーションツールと考え、スクラムに限らず、アジャイル開発手法の取り入れられるところを取り入れ、会社や部署、チームに応じて取捨選択、ブラッシュアップしていく。

また、周囲に広めたり、上司に成果を報告するために、何事も測定して定量化することが重要。ベロシティ以外にも、バグ発生率、リリースまでの時間など、測って改善できる指標はいくらでもある。

いろいろ話したが、完璧にとは考えず、何はともあれやってみたほうがいい。やろうと考えて動いただけでも一歩前進している。

あと、きちんとスクラムマスターとかの勉強したり資格持ってたりする人からすると、何言ってるんだこいつって感じなんだろうな...