ご挨拶

こんにちは！インフラの奥村です！
タスク管理において色々課題合ったけど最終的に今はこうやって管理しているよってのを書きたいと思います。

チームの紹介

タイトルでは「SREチームを目指している」と書いていますが、実際は「SREっぽい事をするチームを目指している」状態です。

SREの解釈がそれぞれの組織や、インターネットで調べて出てくる記事とかで異なる事があるため、SREという言葉は極力使わないようにしています。

サービスの非機能系の改善を図る事でサービス・開発のアジリティを高めるのを目的として活動しております。
（システムの信頼性がよくなることもアジリティを高める要素だと考えております。）

特定のシステムを開発・運用しているチームに所属しているわけでは無く、横断的に複数のシステムに協力しています。
また、アジリティを上げる事を目的としておりますので、GitLab Serverの運用やSaaSの契約など、開発によるエンジニアリング以外も行っております。

ざっと以下の様な事を行っております。

システムのCI/CD導入・導入支援
Infrastructure as Code導入・導入支援
サービスの監視・モニタリング改善
サーバーのインベントリ情報のデータソース管理
GitLab Server運用
Tableau Server運用
各種SaaS契約

こんなのもやっています

blog.engineer.adways.net

タスク管理方法の移り変わり

2018年の10月頃に現在私が所属しているチームが発足しました。
発足後は野外会議してました。

blog.engineer.adways.net

その少し前の状況と現在の状況について簡単に紹介したいと思います。

チームメンバー（4人）
- チームリーダー（私）
- チーフ
- メンバー x 2

チーム発足前

チーム発足前に私が所属していたチームではカンバン形式でタスク管理をしておりました。
半年に1度に大きなプロジェクトを複数個立ち上げ、半年内で実施できそうな仕事を選択するという進め方でした。

ツールはJIRAを使っており、それぞれのチームメンバーがプロジェクトの子タスクを個人の感覚で分割してカンバンに登録しておりました。

当時私が所属している部署では、インフラの基盤の運用や、各種インフラの設定変更依頼のチケット対応なども行っていたので、立ち上げたプロジェクトは時間が無くてタスクを消化できないなどの課題がありました。

f:id:AdwaysEngineerBlog:20200130172236p:plain

チーム発足前タスク管理まとめ

ツール
- JIRA
カンバン方式
タスク共有
- 2週間に一回タスクの振り返り+チームへの共有を行う
- 朝会で軽く共有
課題
- タスクの粒度がバラバラ
  - タスクの課題や進捗が把握しづらい
- 共有しているがあまり理解できていない
  - フォローは発生しにくい
- etc

チーム発足最初期

時は流れ、現在のチームが発足されました。
新しいチームになったので今まで使っていたJIRAとはおさらばし、新しいタスク管理の方法を考える事になりました。
当初は「また新しくJIRAでカンバンを作成してタスク管理するかぁ」と考えていました。

ですが、新しくJIRAでタスク管理を始めるとなった時に、「タスクを確認するときにWebページを開かないといけない」という些細な課題が頭をよぎりました。

そして、当時私自身がミニDIYにはまっていたのも相まってホワイトボード + 色付きの付箋でのタスク管理を始めました。
物理でのタスク管理は、説明は難しいですが、何だか楽しい感じになりますね（物理の楽しさを適切に表現できる方法募集！）

物理でのタスク管理は良かったのですが、見切り発車でホワイトボードでのタスク管理を始めたので、完了したタスクの取り扱いを考えていませんでした。

ということで、完了したタスクの付箋の内容を1週間に1回Google Spread Sheetに転記するという作業を行う事になりました。

流石にこれを続ける気合は無く、2ヶ月のホワイボード管理を終え、結局JIRAでの管理に行きつきました。
JIRAでカスタムフィールドを作成し、欲しいタスクの情報を記録することができるのが良いですね。

また、チームが新しくなったことにより、私が所属するチームの業務内容も変わりました。基盤のメンテナンスなどがタスクからなくなったものの、GitLab Serverなどの運用系のタスクは残りました。

チーム発初期タスク管理まとめ

ツール
- JIRA
カンバン方式
タスク共有
- 2週間に一回タスクの振り返り+チームへの共有を行う
- 朝会で共有
課題
- タスクの粒度がバラバラ
  - タスクの課題や進捗が把握しづらい
- 共有しているがあまり理解できていない
  - フォローは発生しにくい
- 優先するべきタスクが個人の判断によって決められる
- etc

イテレート導入期

JIRAを使ったタスクに慣れてきたころ、いよいよ、タスク管理の課題解決に取り掛かる事にしました。

チームが発足してから約3ヶ月が経ち、他の開発チームと関わる事が増えたり、運用しているシステムの重要度が上がったりしてきました。
こういった変化により、個人でタスク管理する状況が増え、チームとしてのタスク管理が行いづらくなる可能性があります。

ちょうど私が、カイゼン・ジャーニー(1)やエンジニアリング組織論への招待(2)などの本を読んでいたこともあり、スクラム開発ライクにタスク管理をしてみようとなりました。

まず、現在の自分たちのチームの仕事の進め方や成果物の提供先などをスクラム19要素と照らし合わせてみました。
照らし合わせた結果、大きく以下のような課題が分かりました。

横断組織なので、統括して仮のプロダクトオーナーを決める事ができない
- 優先順位を決めるのが難しい
プロダクトが存在しないので、インクリメンタルな価値を検出するのが難しい

上記の課題もありますので、スプリントのイテレーティブな仕組みを導入し、1週間に一度タスクについて話し合うための時間を設けました。
結果的に

バックログ
リファインメント
スプリント
スプリント振り返り

のようなものがある状態になりました！

これらの要素が存在する状態になることによって、タスクの把握が容易になったり、1週間で出来るタスクを選択することによってタスクの期限や進捗に対する認識がチーム内で強化されました。

上記のようなメリットがあったものの

優先順位を決めるのが難しい
タスクの粒度がバラバラ
運用による割込み

などの課題はまだ残ったままでした。

f:id:AdwaysEngineerBlog:20200130222143p:plain

参考にしていた書籍 1

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

作者:広木大地
出版社/メーカー: 技術評論社
発売日: 2018/02/22
メディア: 単行本（ソフトカバー）

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで

作者:市谷聡啓,新井剛
出版社/メーカー: 翔泳社
発売日: 2018/02/15
メディア: Kindle版

イテレートタスク管理まとめ

ツール
- JIRA
スプリント方式
タスク共有
- 1週間に一回スプリント振り返り
- 朝会で共有
課題
- 優先順位を決めるのが難しい
- タスクの粒度がバラバラ
- 運用による割込み
- etc

優先順位決めと運用担当の導入

イテレート導入期に存在した

優先順位を決めるのが難しい
運用による割込み

の二つの課題についてこの時期に暫定の対策を実施し、現在も継続しているのでそちらも紹介します。

優先順位を決めるのが難しい

複数のシステムやサービスと関わり様々な種類のタスクが存在します。また、統括して優先度を決めるプロダクトオーナー的な存在もチームの外には存在しません。

なので、現状は自分たちで優先度を決めています。

優先度を決めるために2ヶ月毎に目標を決めています。非機能の要素を細分化（例えば、障害反応速度やCI/CD自動化率など）し、その要素の中で注力する要素を決め、クオリティをどのように変化させるかを決めています。

注力する要素を決めるのは過去の2ヶ月でどんなことがあったかの振り返りをした結果から決めています。
本来は、非機能要件のクオリティを計測するような定量的な指標を設けて注力する要素を決めたいのですが、現状はそこまで出来ていません。
SLOや稼働率などを最終的には指標にしたいところです。

運用による割込み

こちらは、1スプリントごとに交代する運用担当を設けました。
運用担当は以下の仕事を率先して行います。

運用しているシステムのアラート対応
設定依頼対応
他チームからの相談対応

運用担当以外の人に相談があった場合は、運用担当にリダイレクトしています。
これにより、ある程度運用担当の人以外のメンバーはタスクに集中できるようになりました。

この問題を解決するには属人化を0%にする必要があるため、完全に解決したとは言えません。

見積もりする期

イテレート導入初期は、「このタスクの量なら1週間でいけそう」という感じの感覚で１スプリントで実施するタスクを決めていました。
これを行うと、明らかに終わらないタスク量のものを積んでしまい、次のスプリントに回すという状況が発生するという事が分かりました。

責任者の立場としては、正直「ん？なんで終わってないんだ？」と疑問になることはあります。
その疑問を無くすため、1週間に実施できるタスク量を適正な量にするためチームで見積もりを行う事にしました。

プランニングポーカー期

プランニングポーカーを実施、タスクの大きさを相対的にストーリーポイントをつけれることにより、タスク量の偏りや、一週間で完了できそうなタスク量の把握を行う事ができました。
ヴェロシティでポイントの調整を行えたので、残業が多くなったりするのも抑えれました。

また、メンバー間で何をしているかをより詳細に把握できるようになり、タスクに着手する前に、発生しそうな課題や不確実なポイントを洗い出せる事ができるようになりました。

月並みのメリットを享受し、めっちゃいい感じだわぁとか思ってました。
プランニングポーカーいいですね。

f:id:AdwaysEngineerBlog:20200130222747p:plain

また、個別のタスクにある不確実性を洗い出し、不確実な項目を大、小で分け、それぞれに係数を持たせ、、ポーカーで決まったストーリーポイントに乗算してタスクのバッファを決めていました。

f:id:AdwaysEngineerBlog:20200130223914p:plain タスクのバッファを合計し、チームのバッファとして持ち、スプリントを開始するようにしていました。

実時間見積もり期

プランニングポーカーを行い、プランニングポーカーいいわぁと思っていましたが、決められたポイントを通してどれぐらい時間が掛かるかを認識できるようになりました。。。ポイントによる相対見積もりだったはずが、実時間での見積もりになっていたんですね。

タスク分割（モブタスク分割）期

実時間見積もりになっていると気づいていましたが、特に手は打ちませんでした。
何故なら、具体的に決めれるに越したことはないんじゃないか？と考えたからです。

実時間見積もりをすることによって発生する問題は、考慮漏れなどにより、発生した突発タスクがスケジュールのズレを許容できない事だと考えています。
この問題は、ストーリーポイントによる相対見積もりでも発生するかと思われます。

また、タスクが持っている不確実性の係数付けもやめました。
不確実な事が発生するタスクは、1.5倍、もしくは1.2倍の時間内に終わる確率が低かったからです。

わざわざ計算しもてバッファあまり息してないね...となり思い切って稼働時間の10%(通常なら4時間)をバッファの時間として計算することにしました。

実時間見積もり
バッファの大きさの固定化

を行った私のチームがたどり着いたタスク管理の境地が「モブタスク分割会」です

モブタスク分割会

リファインメントで出てきた、優先度が高いタスクを15分から60分で終わるタスクにチームメンバー全員で分割するという方法です。現在は15分 = 1ポイントとして、何ポイント実施できるか計算して1スプリントに実施するタスクを選択しています。
（ストーリーポイントではないですね）例えば、「○○の自動復旧の仕組を作る」というタスクがあれば