こんにちは！freeeでエンジニアをしているideと申します。入社以来、freeeの中でも金融機関様との協業PJを主に担当するチームに在籍しておりました。

この度別のチームへ異動になったのですが、この機に2年間チームでスクラムを実践して得た以下の気づきを書いていきたいと思います。

• スクラムの実践によるメリット
• スクラム運営の細かいコツ

個別のチーム事情を多分に含んでおりますが、スクラムの原則から大きく外れてはいないつもりです。チームの事情に合わせて守破離をしていくこと自体もまたスクラムの理念かなと思うので、事情は違えど一つの参考にしていただければ嬉しいです！

前提

前提としてチームの実態をお伝えすると、こんな感じです。

• 金融機関様とのPJは最小1, 最大3並列
• エンジニアは5~7人(時期によって変動)
• スプリントの単位は1週間。デイリースクラムに加え、バックログリファインメント、スプリントレビュー、レトロスペクティブをそれぞれ週1回実施
• チケット管理はJIRA、ナレッジ管理はConfluence

スクラムの遵守によるメリット

先に書いた通り、私のチームは金融機関様との協業PJを(それも複数の案件を同時多重的に)担当しておりました。こういったPJはスケジュールが外部要因によってある程度決まっており、スモールリリースなども調整が難しいため、一見スクラムには向かないのでは？と思われるかもしれません。

が、実際にスクラムガイドに照らしてみると、スクラムの3本柱がPJの性質とマッチしているなと感じる部分があり、チームでこの3本柱を常に意識していました。詳細は原典に譲りますが、スクラムの3本柱というのは「透明性」「検査」「適応」の3つです。以下、私のチームでの実践例を交えて説明していきます。

透明性

創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。スクラムにおける重要な意思決定は、3つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。

うちのチームはPJが並列しており、かつそれぞれが長期に渡るという特性上、特に属人化が起きやすい状態にありました。
結果として、仕様について特定のメンバーしか把握していないことによって意思疎通のスピードが落ちたり、先方に提示する情報に対するレビューの質が落ち、誤った情報を示してしまったりすることもありました。
スケジュールの遅延や誤情報の提示のような属人化によるリスクを社内だけで吸収できないので、通常のプロダクト開発よりもこの透明性の担保がより重要だと痛感しました。

先方とのMTGに出るエンジニアの数を増やしたり、チケットやConfluenceを通して情報を公開したりして透明性を高め、現在はPJの担当者が特定のメンバーに集中することを回避しています。極論、PJの担当者がスプリント単位で互いに入れ替わることも可能なぐらいの風通しを意識していました。

検査

スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。

スプリントのゴールとPJの進捗状況を常にバックログ上に示し、こまめに認識合わせをとっています。バックログとチケットを見れば「今何を最優先でやっているのか？そのアウトプットはどんなものになるのか？」が誰にでもわかる状態を徹底し、複数のPJが並列していても手戻りや遅延のリスクを減らすことができました。

実際の運用として徹底していたのは、以下のあたりでした。

• スクラムイベントでPjMとチケットの優先度を都度確認して、誤りがあればすぐ修正する
• エンジニア以外にもバックログを常に公開し、bizメンバーにもチケットの作成や並び替えを適宜行ってもらう

適応

プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。 関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。

特に外部とPJを進める都合上、変数が多く、先方からの作業依頼や仕様変更による再設計が少なくない頻度で発生します。
レトロスペクティブやスプリントレビューといった振り返り・FBの機会が毎週必ず存在することで、頻繁に変化するPJの状況に素早く対応することができました。

メンバーのリソースやPJの逼迫度に応じて、スクラムの運用自体を適宜変えていくこともしばしばでした。(例えば作業時間確保のためにスポットで2週間スプリントに変える、など)

スクラム運用のコツ

目的と優先順位を常に明確にすべし

スプリントプランニングでは必ずスプリントゴールの設定から始めています。ゴールを最初に定めるのも、バックログの優先度をbizメンバー交えて細かに調整しているのも、スプリントの中でどこにリソースを注ぐか迷わないようにするためです。

ここの目線を揃えておかないと、誰が何をやるかが完全に各々の判断に委ねられてしまい、優先度にそぐわない作業や、パスボールが発生することがしばしばでした。

逆にここの認識を丁寧に揃えておくと、「今週はこの作業がゴールだからサポートしよう」「自分の作業は終わっていないが優先度的にこちらのヘルプに入ろう」みたいな判断が誰の指示もなくできます。
とにかく個人で迷う必要のない状況を作り出すことが、チーム全体のパフォーマンスを最大化する上で有効だと感じています。

定例MTG(スクラムイベント)ではメリハリを意識すべし

スクラムは定例が多いので、この質をどれだけ上げられるか(下げずにいられるか)が鍵です。

定例に当てている時間が長い分、質が低いと辛いです。
(これってあんまり意味ないな……)と参加モチベがどんどん下がってしまい、やってるけどあんまり誰も聞いてない、みたいな定例になりがちです。

こうならないために、私は本質的でない時間を減らすことを意識していました。
早いのが正義というわけではないですが、議論が十分に尽くされてやることが終わったなら、全然巻いて終わったっていいと思います。

以下具体的な行動です。

ファシリ(司会)のとき

今何をしようとしているとか、誰にボールが行っているとか、とにかくガンガン発話して、何もない時間を減らすと効果的です。

特にスクラムは外部のMTGと違って、リスペクトは必要ですが礼式は不要なので、例えば以下のような仕草は不要だと思います。

• この方針で良さそうなんだけどいいですかね……？(長めの沈黙)

  => 良さそうなので進めます！何かあれば言ってください

• チケットを編集するごとに大丈夫でしょうか？と確認

  => (基本的に大丈夫でなければその人が声を上げるという原則のもと、不要)

基本的に間違っていたら誰かが訂正すればいいので確認は不要で、やってまえ精神でいきましょう。

ファシリでないとき

メンバーとしても、振られなくても発言する、食い気味にリアクションするなどして、ファシリが不安に感じる時間をなくしてください。

基本的に間違っていたら誰かが訂正すればいい

この原則のもと、異論があれば必ず発言することが必要です。
議事録も誰とは言わず手が空いてたら取って、議事を取るために会議が停止する時間をなくしましょう。

チームのモチベーションを管理すべし

バックログはプロダクトの未来なので、バックログの綺麗さは関わる人のモチベーションに直結すると思っています。

例えば、いざプランニングだと思ってバックログを開いたら、優先度のわからない差し込みやら定型作業的なチケットがたくさん積まれていたら、プランニングも時間がかかりますし、開発が進んでいる気がしなくてげんなりしませんか？

私は自分のモチベーションのためにも、プランニングの前に以下のようなアクションをとってバックログを整理していました。

• 細かい作業や問い合わせ系のチケットを、さらっと片付けてしまう

• バックログを眺めて、定期的に古いチケットを掃除する

• 差し込みがあったら要件と優先度を整理して、適切な位置に動かす

チーム全体としてOKRに関わるチケットをたくさん触れる方が嬉しいですし、プランニングもスムーズに進むので、前述した定例の短縮にも繋がってハッピーです。

結び

2年間でのスクラム運用で得たノウハウでした！
スクラムの旨みってどういう部分なの？みたいなところに、体験ベースで自分なりの答えを出せた2年だったかなと思います。
実践に基づいたスクラムの話をもっともっと目にしたいので、まずは自分の取り組みを書いてみました。一例として参考になれば幸いです。

私自身も、異動後でもできるだけこれらのノウハウを再現性を持って実践できるよう、チームの状況を見て最適なやり方を模索していきます！

フォローして更新通知を受け取ろう