## 前編はこちら
前編では「1. チーム」と「2. スプリントの内側」の話を書いた。後編は「3. スプリントの外側」と「まとめ」のお話。長くなったー！
## 3. スプリントの外側
お試しスプリントで小さく試してみたときとかは良い感じなんだけど、いざ実際にやり始めてみると「あれー。ここどうしたらいいんだろう？」って悩むことが結構あった*1。そういうのってスプリントの外側の話が多い。その中のひとつが「長いプロジェクト」。
## 3-1. 長いプロジェクト
絵の大きな円の部分。毎回リリースすることができないような長いプロジェクトの場合はフェーズの切り分け方を考える必要がある。
### フェーズの切り分け方
右側の付箋みたいなのじゃなくて、左側の網掛けみたいなので進める。最初の頃は、右側みたいに進めたこともあるけど、これだと開発やテストで得た発見や知識を元に設計を改善していくことが難しくてムダが多かったなと思う。短いウォーターフォールみたいな*2。
左側の網掛けの意味は、常にすべてのフェーズをやる、ということ。テストや実装からのフィードバックを得て設計をブラッシュアップしたり、実際に動くものを見て方向転換をしたりする。そのフェーズの山はだんだん設計→開発→テストに移っていく。ドキュメントでフェーズをつなぐことがないので、ドキュメントは最終的に揃っていれば良い。
ちなみに、チームの開発とは別で最後にQA(品質保証)と呼ばれるフェーズがある場合もあって、それはQAの専門チームが担当してくれる。開発チームとしては「QAチームにバグを見つけさせない」つもりで自分たちでテストをしておいて、QAチームには最後のチェックをしてもらう。バグが見つかった場合は、QAチーム様・・・ありがとうございます！の気持ち。
そんな風にすべてのフェーズをやるようになると、フェーズが明確に分かれていないことによってスプリントの終わりが曖昧になりやすい。そこで大切になってくるのが「スプリントの終わりを明確に定義する」ということ。つまり、スプリントゴール。
### スプリントゴール
スプリントゴールは、できるだけ「動くものをステージング環境で動かして、プロダクトオーナーチームに見てもらう」ようにする。動いているものを見てもらうことでフィードバックを得ることができる、というのと、そのゴールを達成できたかどうかが明確に分かる、というのが良い点。
ステージング環境が難しいときは開発用の環境で見せてもいいんだけど、できるだけ本番に近い環境で動かす方が良い。最後の最後で「環境の問題」という落とし穴にはまらないようにするために。
提供する機能は、ひとつずつ前から順番に完成させていくのではなく、ユーザーストーリーマッピングでMVPのスライスを作って、それを上から順番にやっていく方が好き。「作っていったら最後の最後で違和感が出てきた」みたいな状況を減らすことができる。
## 3-2. サービスの運用
僕らはサービス開発だけでなくサービス運用もやってる。サービス運用には、トラブル対応や問い合わせ対応、調査対応などの突発対応が含まれている。
開発だけでなく運用も担当していること自体は、悪くないなと思ってる。というのも、サービス運用のことを考えた開発をすることができるから。これは、実際にサービスの運用をしたことがないとなかなか実感することができない。
ただ、難しいのは、サービスの開発と運用ではサイクルが違うってところ。突発対応が多すぎると、開発のサイクルが乱されて、スプリントゴールの達成が難しくなる。
### 三角形が1次ハンドリング
三角形の3人が1次ハンドリングを担当する。プロダクトマネージャーがプロダクトよりのことを、プロジェクトマネージャーが組織よりのことを、テックリードが開発よりのことをハンドリングすることが多いかな。お互いに助け合いながら。この時点で、細々としたものはすぐに回答することができる。
そして「これは開発チームが動く方が良い」と判断されたら、開発チームの出番になる。
### 開発チームの出番
不思議なことに、突発対応は安定して突然やってくる。毎回スプリント内に、ある程度決まった割合で入ってくるのだ。
なので、ポイント見積もりや理想時間見積もりをしている場合は、その実績「前回のスプリントでどれだけのポイント（理想時間）を消化できたか」を使用することで、自然と突発対応の時間が考慮されたものになっている。
それを超えてしまって、プロジェクトの進捗に影響を与えそうなものに関しては、プロダクトオーナーチームに問いかけることになる。「この突発案件の対応をするのであれば、プロジェクトを遅らせるか、スコープを削ることになるが、どちらにするか？」ということを。
開発チームが黙って受け入れて、頑張ってスケジュールをリカバリーするのではなくて、そこはテーブルにのせて全員の問題として相談する。
## 3-3. 他部署とのやりとり
もう1つ開発のリズムと合わないのが他部署とのやりとり。これも三角形の3人がハンドリングする。
自分のところでは、開発チームは職能横断チームにはなっていなくて、社内の別の専門チームの助けを借りる必要がある。QAチーム、インフラチーム、セキュリティチームなど。なので、それらのチームとのやり取りが必要。
これも別に悪くはないと思ってる。開発チームが全てを見るには範囲が広すぎるし、そこを専門スキルを持った人たちが見てくれるのはとても助かるし安心する*3。
ただ、彼らも沢山のアプリケーションチームの相手をしているのもあって、やり取りには時間がかかる。そのチケットを開発チームのタスクとしてスプリントに入れてしまうとスプリントをまたいで残り続けるチケットになってしまって、チームの気が散ってしまう。
なので、これも三角形の3人がハンドリングして、ちょうどチームが必要とするタイミングでスプリントに結果を投げ込むことで開発をスムーズに進めるようにしている。
## 3-4. ディスカバリー
スプリントとは全く別の時間軸で、プロダクトオーナーチームによってディスカバリーが行われている。アイデアを元にキャンバスを描いたり、ペーパープロトタイプをしたり、ユーザーインタビューをしたり、モックを作ってみたり。そんなことをしながら頻繁に方向転換をして、作りたいものを探っていく。
このとき、プロダクトオーナーチームに含まれているテックリードも重要な役割を果たしている。何かを実験してみたい場合に、技術的にそれが難しいかどうか、どのような方法で実現できるのかどうか、その規模感、などがエンジニアにしか分からないから。
## 3-5. リファインメント
バックログリファインメントは、2つに分かれているなぁ。
### パート1: プロダクトオーナーとテックリードが頻繁に
パート1は、ディスカバリーをしながらプロダクトオーナーとテックリードの2人で行う。そうすることで、プロダクトオーナーがまだふわっと考えているような、開発チームを呼ぶにはまだ早い段階でも、テックリードと相談しながら進めることができる。この段階である程度のアイテムのサイズ感は共有していて、それを元にある程度アイテムを絞り込んでいる。
僕がテックリードしてたときは、プロダクトオーナーと毎日あーだこーだ言いながらFeature DefinitionをReadyにしていってたなぁ。
### パート2: テックリードと開発チームが1スプリントに1回くらい
ある程度方向が固まってきたらテックリードが開発チームを集めて、パート2を始める。プロダクトオーナーは居なくて大丈夫。テックリードはプロダクトオーナーとずっと話をしながらパート1をして認識が揃っているから。みんなからの質問にはテックリードが答えて、プランニングポーカーで見積もりをしていく。
### テックリードの現場感
ちなみに、テックリードはパート1のときでも「これは自分だけで判断するよりも、みんなの意見を今聞いた方が良さそうだな」と思ったときには、いつでも開発チームの力を借りることができる。
テックリードのスキルとしては、チームのみんなに相談しなくても、だいたいみんなの考えと合っているというような現場感が重要になってくる。これによって開発スピードは何倍も変わることになる。
## まとめ
### ふりかえり
ということで、ふりかえってみると、特に図の右側半分の「スプリントの外側」で悩むことが多かったんだよなー。それってどういうことなんだろうなー？と思ったので、その要素を抜き出してみたら、こんな感じ。
つまり、僕らが悩みながら探してきたのは
- 真ん中の「計画を持った開発のサイクル」と
- 上下にある「異なる周波数の様々なイベント」を
- 「どううまく組み合わせて開発を進めるか」
ということだったんだな。
難しいし面白いのは、これって外にはヒントはあっても答えはなくて、それは自分たちの現場で自分たちの仲間と試行錯誤しながら見つけていくしかないってこと。
### そんなことを考えてたときに
先月開催されたRSGT2019に参加した。特にこの3つのセッションが印象的だった。
この3組が挑戦してることってこういうことだった。
「どううまく壊して開発を進めるか」。その発想はなかった。・・・でも、考えてみると、それは良さそう。
### ということで僕も2つの実験を始めた
モブワーク。モブワーク自体というよりも、それによって計画のループを壊せないだろうか？と考え中。この1ヶ月で何回か挑戦してみたところ、良い感触ではあるので、もうしばらく実験してみたい。
学習セッション。プロジェクトのことを忘れて、今の自分達に役立ちそうなことを業務内の朝の1時間毎日学ぶ時間。これもかなり良い。・・・けど、今はプロジェクトに追われてあんまり取れてないから、時間とるー。
## 最後に
僕が具体的にやってることの紹介はここまで。で、もしかしたら「いいなー」って思ってくれてるかもしれないし、僕もそこで話を終わりにしておくとキレイかなと思うんだけど、ちゃんと伝えておきたいことがある。
ここまで色んなことを紹介してきたなかで、組織に根付いているのは、僕の勝手な感覚では「2割ぐらい」だと思う。これまで何チームかテックリードとしてリードしてきたし、今は色んなチームのサポートをしたりしてるんだけど、やっぱりその理由までを伝えきれてないとか、日々のプレッシャー、メンバーの入れ替え、マネージャーの方針の違い、などの色んなことが理由で、8割ぐらいはそこに留まらずに流れ落ちていってると感じる。
でも、それでいいかなと思ってる。進んでは戻って、伝えては失われて、そういうことの繰り返しで少しずつ変わっていけばいいかなと。
そもそも、2割も残ってるのってすごいよね。僕が1人であれこれやるよりも、組織としてこの2割の部分って、実感して、染み込んで、強い土台になってるってことで。この土台の上に、ひとつずつまた何かを積み上げていけるんだったら、それってすごいなって。
だから、今、もしあなたが何かを変えようとして、でも全然変えることができなかったり、ほとんど流れ落ちてしまったりして、心が折れそうになったり、悩んだりしてるんだとしたら、そこに残らなかったものじゃなくて、そこにほんの少しだとしても染み込んだものに目を向けると良いんじゃないかなって思う。
それと、このスクラムフェス大阪のようなイベントや、そういったコミュニティに参加すると、同じような気持ちを持った仲間と出会うことができるから良いと思う。
これで、僕のスクラムフェス大阪2019おしまいっ！最高のギャザリングでした！ありがとうございました！
