この記事は コネヒト Advent Calendar 2021 18日目の記事です。
コネヒトでインフラエンジニアをしている @laugh_k です。今回は直近のコネヒトインフラチームの業務に部分的にスクラム開発のプラクティスを導入している取り組みを紹介します。
スクラム開発のプラクティス導入の背景
はじめに、なぜインフラエンジニアの業務で部分的なスクラム導入に至ったのかの背景を簡単に紹介します。
元々コネヒトのインフラエンジニアはこれまで基本的に一人、多くとも二人体制で過ごした時間が長く、課題の管理についても個人が把握している課題に取り組むという色が強かったように思えます。
私がコネヒトに入社した1年前からは GitHub Issue にチームの課題を集約する体制を作り、二人体制ではあるもののチームとしてインフラに関する課題を把握できる状況をつくることはできました。一方で日々の業務に取り組むスタイルとしては、初めの10カ月程度の期間は大規模なプロジェクトをメインタスクとして持ち、隙間時間で日々発生するインフラの課題に向き合う形で過ごしました。大きな課題に集中するべくこのスタイルで業務を進めていましたが、結果として日々発生するインフラの課題にほぼ手をつけられないという問題に発展しました。
これはチームのリソースや優先度の都合で仕方がないとみることもできます。ですが、「同じスタイルでの業務を続けると半期のうちに改善する問題が1,2個程度になってしまう」と危機感を覚えました。限られたリソースであっても、課題を解決に向けて少しでも進捗させられないかと考えた結果、「大きなプロジェクトを半期に持つ」のではなく「短い時間でできるところまで集中して取り組み、またタスクの持ち方を見直すループを回す」ほうが割り込み業務が発生しやすいインフラエンジニアの業務的にもよいという結論に至りました。
私の過去の経験上「短い時間でできるところまで集中して取り組み、またタスクの持ち方を見直すループを回す」スタイルにはスクラム開発のプラクティスが大いに生かせると考え、インフラエンジニア業務向けにスクラムを部分的に取り入れることに決めました。
どうやっているのか
ここで紹介するのは 2021-12-17 時点でのやり方です。スプリントごとにどんどん改修を加えていってる段階なので、来月にはやり方を変えていることもあるかもしれません。
インフラスプリントの開催
一般的なスクラム開発のスプリントにアレンジを加えた「インフラスプリント」を開催しています。
期間は約2週間程度とし、開始は木曜日で終了がその2週先の火曜日とします。スプリントの1回目の水曜日がリファインメントで、終了の次の日となる水曜日がレトロスペクティブと次回のプランニングという流れです。言葉だけだと少々わかりずらいので図で示すと以下のような流れです。水曜日にスクラムイベントが発生するようにしています。
スクラムイベントが水曜日となっている背景は、インフラスプリントを実践する以前から行っていた定例MTGがたまたま水曜日開催だったためで深い理由はありません。ただ、実際にやってみると水曜日にスクラムイベントがあると準備に余裕を持たせやすいこと、また次の日も営業日であることからイベントで話題に上がったTryに着手しやすく、バランスがよいと感じています。
GitHub Project(beta) の活用
基本的なインフラの課題・タスクの管理には GitHub Issue （以下、単に Issue）で行っています。その関係で今現在は GitHub Project(beta)を活用しています。
GitHub Project(beta)で用意しているステータスは以下の通り
| ステータス | 説明 |
|---|---|
| 未分類 | 原則 project に入れた Issue は最初は必ずこれにする。スプリント計画のタイミングで Backlog にするかスプリントTodoにするか決める |
| Backlog | 直近のスプリントではやらない（or やれない）Issue を積んでおく |
| ペンディング / 進行したもののとまってしまった | 途中まで進行していたものの、様々な要因で進行が止まってしまった Issue。プランニング or リファインメント時に Backlog に戻すか再びスプリントTodoに入れるかを判断する |
| スプリントTodo | 「このスプリントでやる！」という Issue 。今のところ明確な数の制限は行わず、状況を見て判断。プランニングの際にこのTodoを決める |
| 進行中 | 実際に手を動かして着手している最中の Issue。議論中となっているものもここに含む |
| 返答待ち / レビュー待ち / 確認中 | アサイニーは直接手を動かしていないが、別のだれか or 何かのアクション待ちの Issue/PR（PRのレビュー待ち、問い合わせた後の応答待ちなど） |
| 完了 / マージ済み | PRはマージしたらここでOK。Issueもクローズしたらここへ。他、開発チームから派生したIssueなどでインフラチームの対応として完了と判断したもの。 |
GitHub Project(beta) へのIssue/PRの追加ルールとしては以下の通りです。
- インフラ関連の課題は一つのリポジトリの Issue に集約。そのIssueは原則すべて追加
- ecschedule や terraform のコードを管理するリポジトリのPRも追加
- 他のリポジトリでもインフラとしての活動が入ったIssueも追加
- 最初のステータスは原則「未分類」。ただし、依頼やアラート対応などの急な割り込みの場合は「スプリント予定外」のラベルをつけて「進行中」にいきなり追加するのもあり。
また、ストーリーポイントのような見積もりは現時点では行わないことにしています。インフラ業務においては依頼やアラート起因で発生する割り込みでかつ、すぐに着手する必要があるIssueも多く、作業見積もりをしてから着手をするという流れはあまり現実的ではないという判断です。このあたりについてはチームの規模や、仕組み次第で今後変えていく可能性もあります。
スプリントイベントの進行
今のところインフラエンジニア二人体制でリファインメントは30分、レトロスペクティブ&プランニングでは1時間ほど水曜日に確保しています。二つのパターンでも基本的な進行は同じで、レトロスペクティブ&プランニングの回のみパート4があります。他の細かな違いは以下の通りです。
| イベントの種類 | 議論ポイント | Issueのアーカイブ |
|---|---|---|
| リファインメント | 残り半分の期間で今のタスクは終了させられそうか。終了させるにあたって何か懸念事項はないか。この時点で無理そうなものはないか。 | やらない |
| レトロスペクティブ&プランニング | 実際にどれくらいのタスクを消化できたか、タスクが残った場合は何が問題だったのかを振り返る | やる（完了数を数え、スクリーンショットをとっておく） |
アジェンダ・議事録については以前は Docbase を使って行っていましたが、最近は Notion 上で以下のテンプレートに沿って行っています。進行内容を実際のアジェンダ・議事録の一部とともに紹介します。
パート1: Issue / PR を確認
最初のパートではGitHub Project(beta)を眺め、前回のスクラムイベントからの間でどういった出来事があったのかを共有しながら、必要に応じて質疑応答・議論を行います。事前に書き出しておける内容は Memo ブロックにあらかじめ記載しておくようにします。
リファインメント回のときは、その時点で完了が難しくなったIssueを「ペンディング / 進行したもののとまってしまった」に移動するなどの調整も行います。レトロスペクティブ&プランニング回のときは「完了 / PRマージ済み」のIssueの内容を確認し、記録のためIssue/PR数を控えてスクリーンショットをとったあとにアーカイブをします。
また、GitHub Project(beta) のみの場合、直近動きのあった Issue を見逃す可能性もあることから、Issue を集約するリポジトリにおける Issue を「最近動きがあったIssue」として Recently update で sort した一覧も確認するようにしています。
パート2: 今週の出来事
方式としてはいわゆる KPT 方式なのですが、あえて「Keep」「Problem」「Try」とせず「よかったこと」「課題に感じたこと」「これやってみては？」という名称にしています。あまり深い意図は無いものの、実際に話しておきたい事をそのまま項目にしています。
パート3: ほか、話したい事
出来事の振り返りができたら次はインフラチームとして話しておきたいことがある場合に議論するパートです。このパートでは組織的な方針から、今週の出来事パートで出た話題の深堀り、「今やってるこのタスクぶっちゃけどうですか」のようなものまでさまざまです。
パート4:プランニング
レトロスペクティブ&プランニング回の時のみ行います。一通り振り返りの議論が終わったところで、次のスプリントの計画を立てます。やることとしては以下の通りです
- 「未分類」の Issue がある場合、「Backlog」にするか「スプリントTodo」にするかを決定
- 「進行中」「返答待ち / レビュー待ち / 確認中」の状況や期限などを話し合いながら「Backlog」から「スプリントTodo」に移動するIssueを決め、担当をアサイン
どのような効果が出ているのか
インフラスプリントはまだ3回目が終わった状況で、まだまだこれからな部分はあります。しかしながら、現時点でも定性的ではありますが改善していると感じられる部分はあります。
一つは常に巨大なプロジェクトを一人で抱え込まなくてもよくなったことにあります。プランニングの時点でそのスプリントで集中すべきことがチームで合意を取れたうえで決まるため、安心してスプリントToDoの内容に取り組めます。
また、やらないことに関する合意も取りやすくなりました。リファインメントのタイミングで「このIssueは割り込みのあの件があるので、来週まではやらないことにしましょう」といったコミュニケーションもよく発生しています。
スクラムイベントのフレームワークも良い形で機能してると感じることが多いです。単純な定例MTGと比べスクラムイベントのタイミングで「このスプリント、次のスプリントの終了 Issue を増やしに行く」という意識も強く働くようになり、中途半端な状態で宙に浮いてしまうIssueもかなりクローズさせられるようになったと思います。
おわりに
インフラエンジニアの業務にスクラム開発のプラクティスを部分的に導入している取り組みを紹介しました。この取り組みはまだまだ手探り段階で、まだまだ改善できる点も多いだろうと考えています。もしもこの記事で紹介している内容を見ていただき、「一緒にコネヒトのインフラチームで働いてみたい！」「こんなのもっとよくできるよ！」と思っていただける方がいましたら是非ご連絡ください。
