LAPRAS株式会社でSREをしているyktakaha4と申します🐧
弊社のSREチームで最近運用をはじめた見積もりやふりかえりの手法について書きたいと思います
大規模な立ち上がり済みの組織向けでなく、今ひとりで仕事をしている人が2人目のSREを迎え入れたときの一事例としてご覧ください
経緯
弊社は2016年に創業して以来、ソフトウェアエンジニアとして入社した社員がアプリケーションからクラウドまでプロダクト全体を開発・運用するというスタイルが取られていましたが、
エンジニア組織の拡大に伴い、2021年頃からプロダクトの信頼性や可用性の向上を責務とする専任のSREを立ててシステムの改善をおこなってきました
以下は、弊社で導入しているホラクラシーに基づいて定義された Site Reliabilityサークル のロールの一覧です
原則として、ロールは誰であっても自由に負うことができるので、主務としてこれらのロールを多く持っているエンジニアがSRE、プロダクト開発などのサークルやロールに多く関わっているエンジニアがSWEとして業務をおこなっているようなイメージです
Site Reliabilityサークルに含まれるロール
SREの実践パターンについてまとめられている以下のドキュメントに照らすと、主に 5.エコシステムを整備する や 7.プラットフォームを提供する をおこないながら、必要に応じて 2.外の人として、SREに関わるタスクや機能開発を引き受ける や 3.外の人として、SREに関わる助言を行う を実施しているといった感じでしょうか
実務についてはいくつか記事を書いていますので、よければお読みください
そうした背景の中で、2022年7月よりSREとしてnappaさんが入社したことにより業務を専任2名の体制で進められるようになったのですが、
ひとりでやっていたことを急に複数人でやろうとしたことで様々な問題が生じテコ入れが必要に感じたため、 複数人体制になって生じた組織課題を解決するためのチーム運用を決める というスコープで見積もりや振り返りを見直すプロジェクトを開始しました
課題の整理
nappaさんのオンボーディングが完了してからの数ヶ月中に課題に感じたことを振り返ってみます
作業中と未完了の増加
ひとりSREとして仕事をしていた時期から向こう3か月を描いた簡単なロードマップを作って何をするか・何をどの程度終わらせられたか評価していたのですが、
nappaさん入社後にやった最初の振り返りでは、 なんもしてない とか 残作業が残ってる のようなIssueが多くなってしまいました
2022年9月~12月のロードマップ
例えば、弊社ではインフラにKubernetes(EKS)を選定しており定期的なアップデートが必要なのですが、Issueの完了のためには既存環境の理解やDeprecatedやRemovedになるリソースの調査・修正、当日の作業手順書の作成といった様々なタスクをペース立てて消化していく必要がありますが、
詳細なタスクへの分解が個人の裁量に任されていたため、 何についてどのくらい終わっているか や いつまでに何を終えているべきか といった情報をチーム内で充分に共有できていない場面がありました
結果、作業の優先順位について各メンバー間で認識の齟齬が増えてしまい、着手できなかったり半端に作業して滞留してしまうIssueが増えてしまう…という状況が発生していました
割込み作業にペースを乱される
前節で未完了のIssueが増えてしまった理由を深堀すると 割込み作業への柔軟性の低さ も原因のひとつであったと思います
SREチームでは以下のような作業のトリアージポリシーを定義していたのですが、組織外から要求されたり持ち込まれるものについて、自分たちで計画したものよりも優先して対応する…というグランドルールを設けているため、結果として割込み作業が増えると自分たちの計画作業がそれだけ遅れます
- 第一に、SR組織外から持ち込まれる事業推進のために必要な開発施策について全面的に（作業請負するのでなく）協力する
- 第二に、時限性&反復性のある課題の中で放置するとサービス停止に追い込まれてしまうものについて、定形作業で解消できるようにする
- 第三に、セキュリティリスクに繋がりうる潜在課題を解消する
計画外の割込み作業の一例として、例えば以下のようなものがありました
いずれも対応を後回しにすべきではないですが、これらに優先して着手した結果、元々計画していた作業がどの程度遅れるか、またそれによって後続の対応にどのような影響が生じるか…といった検討が充分にできず、最終的には できそうなものをできるだけやる といった取り組み方をしてしまうケースが多かったです
- プロダクト開発チーム側でインフラの構築や改修の支援が必要なものが生じた
- オンコール対応の中で緊急性が高いものについてインフラや監視の観点で協力した
- 利用しているSaaSでセキュリティインシデントが発生し、急ぎ対応が必要となった
今後は、今割り込んできた作業が、計画している作業に対してどの程度のインパクトがあるか、着手前に一定のルールで評価して影響度を理解する運用が必要であると感じていました
知見が運用に蓄積しない
そうした状況の中で特定のプロジェクトを大きく失敗させてしまったり本番障害を発生させてしまうことがあれば、ポストモーテムなどの中でオペレーションに問題があったことを省みることができますが、
私もnappaさんもエンジニアとしてのキャリアがそこそこあるのも相まって、運用を後回しにして実務上の課題だけを場当たり的に解決してしまう部分が少なからずあるように感じていました
しかしながら、今後経験の浅い方や、業務委託等で働く方など異なるコンテキストのメンバーがチームに加わった時に、現状の仕事の仕方ではスケールや再現性を高めることは難しいのもわかっていたため、
指標を定量的に評価できるダッシュボードやワークフロー、定期的なイベントによって自分たちの行動を日々評価しながら改善していく運用を構築したいと考えていました
課題への対処
課題の整理ができたので、具体的な行動に移ります
巨人の肩の上に立つ
個人的に巨人の肩の上に立つという考え方が好きなので、既存の手法をベースにした上で合わない部分を手直しした運用を作りたいと思っていました
そこで、弊社でもプロダクト開発チームで採用しているアジャイル開発手法について、この機会に理解を深めてみることにしました
これは、直近でLAPRAS株式会社のエンジニアチームでRegional Scrum Gathering Tokyo 2023に参加する機会があったことも大きく影響しています
参加録を同僚のことねさんがまとめているのでよければご覧ください
今回、私がアジャイル開発手法をベースにしたいと考えた大きな理由は エンジニア組織内で共通言語を使って意思疎通できるようになりたい ことにありました
これは弊社に導入されているホラクラシーについて感じているメリットでもあるのですが、同じフレームワークを使って組織を運営していると、セールスやカスタマーサクセスといった異なる立場の人とも近いコンテキストで会話できるようになり、コミュニケーションや知見の共有が活性化されます
一例として、弊社にはスクラムマスター兼SWEのendoさんがいますが、なにか相談したいことがあった時にアジャイルをベースにした運用をおこなっていると状況の説明やプラクティスの輸入がしやすいものと思います
突き詰めていくと、どのフレームワークを採用しても最終的には何かしらの不満やカスタマイズが必要な部分が出てくるはずなので、それならば現状の組織でデファクトとなっているものをベースにするのが妥当だと考えました
リファレンスを決める
アジャイル開発手法をベースにする…と決めたので、情報をインプットしていきます
私は元々LAPRASにSWEとして入社しており、それ以前もWebアプリケーションエンジニアとしてキャリアを積んできてはいたのですが、アジャイルやスクラムについての基礎的な知識を持たないまま、現場最適化されたアジャイル風な何かを使って仕事をしてきてしまった…というコンプレックスがあったので、それを払拭するためにもいくつか本を読んでみることにしました
アジャイルな見積りと計画づくり
この本の良いところは、アジャイルな見積もりや計画手法について主眼をおいて、実践的なケースを題材に解説がなされているところです
私達が必要としていたのは適応型のアプローチでチームを運用するプラクティスであり、よりプロダクト開発に特化したスクラム開発手法ではなかったため、適切な粒度の書籍だったと思います
アジャイルレトロスペクティブズ
本を読んでいてふりかえりの手法についても知りたくなったので、以下の本を読みました
様々な手法がデザインパターンのような形式で紹介されており、リファレンスとしてちょうどよい本だと感じました
Clean Agile
また、実際にアジャイルでのチーム運用を進めていく過程で自分たちの方向性が誤っていないか心配になったため、以下の本も読みました
既存の手法やプラクティスに対して独自の現場最適化を加えるたびに、 これはアジャイルから遠ざかるような行動でないか と不安になっていましたが、この本ではアジャイルのプラクティスだけでなくその背景にある基本的な考え方について詳しく解説されているため、自信を持てるようになりました
メンバーとの対話
次に、チームメンバーとなるnappaさんと、前述した課題感と考えている解決方法について、私が書いた素案を見てもらってフィードバックを受けることを数回繰り返しました
アジャイルという語句は非常に広範な意味を持っているので、人それぞれが想起する具体的なイメージは大きく異なっている場合があります
実際にあったこととして、nappaさんは前職でスクラム開発をおこなっていたため、そうしたコンテキストからいくつか懸念を提示してくれたことがありました
そうした認識のずれを運用を開始する前に始めることが重要だと思います
見積もり考
フィードバック
次に、先ほど紹介したアジャイルな見積りと計画づくりの章末についていたまとめを輪読する会を日次で30分ほど開き、少しずつ読んでいきました
私は一度全体を読んでいましたが、複数人で読むと他者の着眼点を知れておもしろいのと、まとめの内容が過去の実体験を思い出す引き金となり、トピックについてケーススタディをおこなえる効果もありました
輪読会のルール
イテレーションの設計
インプットが一通りできたら、より具体的なプロセスについて考えていきました
現在の私たちは木曜日から始まる2週間を1イテレーションとしてイベントを設計しています
イテレーションの境目を金曜や月曜としなかったのは、来週に作業を持ち越しやすくなるため週明けにやることで迷わなくなるのと、金曜に予定を入れないことで疲れている時に早くあがれるようにするためです
また、私たちのチームでは、イテレーションでおこなうタスク選定に際して、アジャイルな見積りと計画づくりで紹介されていた コミットメント駆動 という考え方を取り入れました
コミットメント駆動では、過去のベロシティを元に確約できると思われるポイントをイテレーションに積む…というもので、後述する Planned のIssueを計画的に終わらせることを目指します
本の内容からカスタマイズした部分として、現在の私たちにはタスクの作業時間を詳細に見積るのはオーバースペックに感じられたため、Issueに対して割り振るストーリーポイントの決定と、タスクの簡単なToDoリスト作成に留めることとしました
アジャイルな見積もりと計画づくり p173より引用
各イベントについても簡単に説明します
色付けされているものは必ず開催するイベント、点線のものは適宜開催するイベントです
イテレーションでおこなうイベント
詳細を説明します
- イテレーションプランニング
- イテレーションに積むIssueの選定や重要度の決定、ストーリーポイントの見積もりをおこなう
- デイリースタンドアップ（DS）
- 毎朝10分間、所定のワークフローに基づいたメトリクス確認と予定の共有
- これはチーム内のもので、これに参加した後エンジニア組織全体のDSも別途おこなう
- 見積もり会
- 作業にあたって同期でのリファインメントが必要そうなタスクのために予約している時間
- インシデント対応や割込み作業などの緊急性の高いタスクがあったときに、進捗確認に用いる場合もある
- 他にも、DSで監視しているメトリクスに気になる点があったときに、フロー効率高く初動に着手できる
- 予定がないときは、輪読会やリリースノート読み会などの同期でのインプット時間に充てる時も
- インシデント対応や割込み作業などの緊急性の高いタスクがあったときに、進捗確認に用いる場合もある
- 個人タスクで忙しい場合などはバラす
- 作業にあたって同期でのリファインメントが必要そうなタスクのために予約している時間
- ペアプロ
- ペアプロ（グラミング）という名前だが、同期で作業したい内容を各自が好きに持ち込んでペア作業
- 新しく触る技術やサービスで、知識の平準化を測ったほうがよいもの
- 本番作業およびそのリハーサル
- 火曜は予定をあらかじめブロックしておき、他の日は必要に応じて任意開催とする
- ペアプロ（グラミング）という名前だが、同期で作業したい内容を各自が好きに持ち込んでペア作業
- イテレーションレトロスペクティブ
- イテレーションであった出来事をふりかえる
計測指標の設計
イテレーションの流れを決めた後に、課題の解決のためにどのような計測指標が必要か検討しました
Planned / Unplanned
第一に、私たちのチームの課題は 作業中と未完了のIssueの増加 にあったため、イテレーションを進める中でIssueが順調に処理されていることを定量的に確認したいと考えました
しかし、SREの仕事はアプリケーションエンジニアと比べて突発的な作業の比率が高く、一般的にも運用系の業務はスクラムとは組み合わせにくいと言われることも多いものと思います
これについては、タスクを Planned と Unplanned に大別し、それぞれのベロシティを別個に計測することとしました
前掲のドキュメントで解説されている固定アイテムという概念を参考にしています
https://codezine.jp/article/detail/16920?p=2 より引用
それぞれの区分について説明します
- Planned
- KubernetesやAWSアップデートの本番作業やその前提となるIssue、インフラ構築など、特定の納期や期日に対して計画的に作業したいタスクに設定
- イテレーションですべてのIssueがClosedになることを期待する
- イテレーション中に
PlannedのIssueを新規に増やす / 減らすのは禁止- 作業中に考慮漏れに気づいたり、タスクが詳細化された結果生じたIssueについてはOK
- イテレーション中に
- 確実に終わらせたいものにのみ設定し、ベロシティが下振れしても消化できそうな分量にする
- Unplanned
-
Planned以外のIssueに設定する - イテレーションですべてのIssueがCloseになることを期待しない
- Issueの増減は自由
- 次のイテレーションに作業の一部を持ち越してしまいそうな時は、終わった部分のみでCloseし別のIssueを立てて翌スプリントで対応
- 着手したものをそのままの形で持ち越すのは極力避ける
- 未着手のものを持ち越したり対応をやめるのは自由
-
イテレーションの開始時にどのIssueに Planned を設定するか重点的に話しあうことで、作業の重要度や遅延した場合の影響をチームとして強く意識できます
SR Strategy / Request / Incident
先ほど説明した Planned / Unplanned という区分とは別に、そのIssueがどのような経緯でイテレーションに持ち込まれたか識別できるようにもしました
それぞれの From 区分について説明します
- SR Strategy
- ホラクラシーにおいてSRサークルのロードマップ策定について責務を負う
SR Strategyロールが持ち込んだIssue- KubernetesやAWSのバージョンアップなど、時限性があって遅延すると本番影響のリスクが高いものをマークする
- 古くなったアーキテクチャのリプレースなど、SREチームとして計画して処理したいIssueに対してもマークする
- Qのロードマップの達成要件となるIssueに絞って選定することで、計画的な消化を目指す
- ホラクラシーにおいてSRサークルのロードマップ策定について責務を負う
- Request
- スクラムチームや情シスなど、SRチームの外部から要求されたタスクに関連するIssueをマークする
- 前述した対応ポリシーを意識した優先度付けができているか確認可能にする
- Incident
- 利用している外部SaaSのインシデント対応や緊急性の高いオンコール対応などの、不可抗力として高優先度で対処せざるを得なかったIssueをマークする
- 各イテレーションにおいてどの程度割込み作業が発生したか確認可能にする
Issueが持ち込まれた経緯を計測するのは、当初の課題だった 割込み作業にペースを乱される 状況について定量的な評価をおこないたかったからです
アプリケーション開発をおこなっているスクラムチームと比較して、SREチームは突発的な作業に対して柔軟に対処することが求められることが多いと思いますが、これをチームのIssue管理の外に置くのでなく、マーキングした上で同じカンバンの上で取り扱うことで、以下の効果が期待できます
- 突発作業が入ってきた場合でも、イテレーションとしては一定のベロシティをあげられているか計測できる
- 正しく価値提供に向き合えていれば、
Unplanned & IncidentのIssueの割合が増えてもベロシティの総量は大きく変わらないはず
- 正しく価値提供に向き合えていれば、
-
SR StrategyとしてマークされたIssueの消化度合いを見て、ロードマップ達成に寄与するIssueの消化度合いを計測できる
なお、スクラムにおけるプロダクトオーナーの役割をチームの方針決定者が兼任することについては、他社でも近い事例がありました
ツールの選定
イテレーションや計測指標の大まかな設計ができたので、最後に実装に用いるツールを決めます
弊社はフルリモートで業務をおこなっているため、ツールはすべてオンラインで利用可能なものを前提としました
エンジニア共通の運用として、課題は原則特定のGitHubリポジトリのIssueとして起票する運用となっていたこともあり、タスク管理についてはGitHub Projectsを用いることとしました
GitHub Projectsを用いると、カンバンやバーンダウンチャートといった分析に必要な可視化を低コストにおこなえます
また、リポジトリからのデータ取得についてもGitHub GraphQL APIを用いて簡単に実施できます
そのほか、ワークフローについてはSlack ワークフローを利用し、ロードマップやふりかえりなどの発散が必要な時はFigmaを用いることとしました
実装
最後に、設計した運用を実際に回してみた結果についてご紹介します
計画・見積もり
イテレーションは木曜日の午後にはじまります
イテレーションプランニング
イテレーションの最初に、以下のルールブックに基づいて45分程度でプランニングを実施します
SR Strategy およびSRE各自が本イテレーションで実施したいと考えるIssueを持ちより、過去イテレーションのベロシティも参考にしながらどのIssueに着手するかトリアージを実施します
具体的なプロセスとしては以下のようになります
- チェックイン
- インプット（~5min）
- ロードマップの確認・更新
- 前イテレーションのPlus / Deltaの確認
- 過去のイテレーションのベロシティの確認
- 発散（~30min）
- Issueの洗い出し（~10min）
- SR Strategyのリクエスト
- チームメンバー毎に「これをやりたい」を出す
- あがったIssueの議論すり合わせ（~20min）
- SR Strategyからのリクエスト詳細の説明
- 各メンバーのやりたいタスク説明
- このイテレーションでやるべきか
- どのIssueをPlanned / Unplannedに設定すべきか
- Issueの洗い出し（~10min）
- 収束（~5min）
- PlannedのIssueと、ポイントを確定する
- 今イテレーションに積んでいるPlannedのIssueが適切なサイズであること
- 過去のベロシティを参照
- チェックアウト
プランニングのアウトプットとして、GitHub Projectsで定義したイテレーションにIssueが紐づけられて、カンバンで確認できるようになります
GitHub Projectsを用いたカンバン
なお、Custom Fieldsとしては以下のような値を設定しています
GitHub IssueのCustom Fields
個人的に便利と思っているのがIterationフィールドです
私たちのチームでは2週間で1イテレーションとしていますが、GWや年末年始といった長期休暇が挟まるタイミングでは10営業日程度を確保できるよう3週間で1イテレーションに変更したい場合があり、そうした要望をいい感じに表現できます
ストーリーポイント
ストーリーポイントについては、フィボナッチ数列を用いる考え方をベースに、以下のような基準で設定しています
- 0ポイント
- Kuberneteアップデートなど、小さなIssueを多量に含む対応においてEpicとなるIssue
- 他チームに作業依頼していて、SREチームの作業着手をブロックしているIssue
- 1ポイント
- 単独のメンバーで対応可能で、非同期レビューでMergeする開発規模のIssue
- 2ポイント
- 単独のメンバーで対応可能だが、同期レビューや本番適用時などペア作業が必要そうなIssue
- 知見共有や新規構築など、開発からペアプロで対処したほうがよいIssue
- 3ポイント
- 対応内容が詳細化できておらず、これから調査が必要なIssue
- 詳細化の過程でIssueの分割を検討する
- Terraform、Kubernetes、アプリケーションの複数個所にわたって広範に修正が必要と思われるIssue
- 対応内容が詳細化できておらず、これから調査が必要なIssue
- それ以上
- Issueを分割してストーリーポイントを小さくすることを検討する
また、アジャイルな見積もりと計画づくりでも言及されていることですが、プロダクトの価値（≒ソースコードやインフラ設定の変更、運用手順書の更新）に直接的な変更を及ぼさないミーティングなどのイベントについてはストーリーポイントを設定しない、Issueを切らないこととしています
仮にそれらによって実務をする時間が取れなかった場合は、ベロシティの低下によって検知できるためです
タスクのアサイン
タスクのアサインについては、Planned / Unplanned の設定状態について明確にポリシーを分けています
- Plannedのタスク
- そのイテレーションで完了させることを目指すため、消化状況にあわせて積極的に分担やアサイン変更をおこなう
- 特にイテレーションの後半週で進捗が思わしくなかった場合
- そのイテレーションで完了させることを目指すため、消化状況にあわせて積極的に分担やアサイン変更をおこなう
- Unplannedのタスク
- 基本的にタスクを持ち込んだメンバーが担当する場合が多い
- 進捗が思わしくない場合は、無理に担当替えせず着手をあきらめて次のイテレーションに持ち越してもよい
ロードマップアイテムについては SR Strategy による進捗管理をおこないますが、それ以外のIssueの着手についてはメンバーの自主性やWillによって消化されることを期待します
イテレーションの完了時にPlannedのIssueがすべてCloseされており、かつ過去のイテレーションと同程度のベロシティを出すこと を目指しているとも言い換えられると思います
日々のイベント
プランニングが終わったら、2週間後の木曜日まで業務をしていきます
デイリースタンドアップ
デイリースタンドアップ（DS）は、週替わりで担当者を割り振るbotをGASで用意して司会を決定しています
（チームメンバーが2人しかいないため、代理の担当者をうまく表示できていませんが…）
Slackワークフローのイメージ
ワークフローでは、10分で以下のようなチェックをおこなっています
- あいさつ
- OKR確認・更新
- 週の初日のみチェック
- SRダッシュボードの確認
- 直近で改修した本番環境を監視するクエリなどをRedashやDatadogで定義してチェック
- SLOについてはエンジニア組織全体のDSで確認
- イテレーションの健全性の確認
- PlannedのIssueの消化状況は順調か？
- Issueが過去イテレーションと同程度のペースで消化できているか？
- 残Issueを今イテレーションで終えられそうか
- イテレーションの後半週のみチェック
- Issueになっていない作業の確認
- 今イテレーションで作業中に新しく増えたタスクがないか？
- トラブル対応などによってIssueを立てずに突発作業しているタスクがないか？
- 今日やろうと思っていることを一人ずつ宣言
- 非同期レビューやapprove済みの本番適用を忘れてないか確認
- リポジトリのPull requestsの画面をチェック
- 見積もり会（30min）の時間の使い方の決定
- トラブル対応やチーム外から持ち込まれたIssueなど、同期での対応方針決定や見積もりが必要な状況か確認
- それらがない場合は、輪読会などのインプット系の同期イベントを実施する
- Issueの消化に充てたい場合メンバーがいた場合はスキップ
- 特にイテレーションの後半週において
ペアプロ
弊社ではドキュメンテーションにesa.ioを利用しているので、ペアプロ履歴のドキュメントを用意し持ち込みたい作業を書いておきます
適宜休憩を取りながら午後いっぱいやる場合が多いです
ペアプロ履歴のイメージ
ふりかえり
イテレーションレトロスペクティブ（ふりかえり）は、Figmaに用意した専用のシート上でおこないます
ふりかえりボードのイメージ
必要なダッシュボードはGitHub ProjectsのInsightsで簡単に作成できるので便利です
以下のようなフローで、45min程度で実施します
- チェックイン
- 現状の把握 & ダッシュボードのスクショの取得（~10min）
- 今回のIterationの対応したIssueを見て、ステータスを正す
- Issue全体の消化推移はどうだったか
- Plannedがどのくらい完了したか
- 積み残しがどの程度あったか
- 今回～過去のベロシティ
- 今回のイテレーションで対応した全Issue
- タイムライン（~25min）
- 付箋を貼っていく（~10min）
- 貼った付箋を見ていく（~15min）
- Plus / Delta(5min)
- 付箋を貼っていく（3min）
- 貼った付箋を見ていく（2min）
- チェックアウト
ふりかえりの手法としては、アジャイルレトロスペクティブズに書いてあった以下のフレームワークをカスタマイズして利用しています
- タイムライン
- ベロシティやIssueのバーンダウンチャートに対して付箋を貼る
- Mad / Grad / Sad
- 付箋を貼る際に、その内容についてどのような感情を感じているか分類する
- 人によって同じ事象に対して異なる感情を持つことが可視されておもしろ
- Plus / Delta
- 次のイテレーションのインプットとなる継続or改善したい内容を宣言する
- ひとり最大1個程度に絞るようにしている
それぞれのプラクティスについては、以下のような事例がありました
ふりかえりについては、長く同じ手法を使っているとマンネリ化してくる部分もあるので、一定周期で別のものに変えていくことも検討しています
結果
3ヵ月程度上記の運用を回した結果、ベロシティは以下のようになりました
実際のベロシティ
感じられた効果としては、以下のようなものがありました
- 各イテレーションでどのような作業をどの程度完了させられたか可視化・蓄積できるようになった
-
PlannedのIssueに対して完了意識が高くなり、Inprogressのまま次イテレーションに持ち越すことがなくなった- ロードマップやOKRで定義している問題について確実に進捗を出せるようになった
- Issueの持ち越しが発生しそうな時にタスクの分割をおこなうようになり、どこまでが完了していて未完了の作業が何かわかりやすくなった
- 運用が明文化できたことで人の増減に強いチームになった
元々あった課題感については概ね改善することができてよかったです🐑
まだ運用を始めて日が浅く、これから運用に伴う問題やボトルネックとなる部分が出てくるはずなので、順次改善していきたいと思います
おわりに
アジャイルについては勝手な先入観から自分には縁遠いもののように思っていたのですが、今回Clean Agileに書かれていた一節を読み、一転して親しみを感じるようになりました
アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。できるだけ早く知りたいのは、そうすれば状況を マネジメント できるからだ。 これがマネージャーのやることだ。
（中略）
アジャイルはデータを生成する。 アジャイルは大量のデータを生成する。マネージャーはそれらのデータを使用して、プロジェクトの成果を可能な限り最高にする。
Robert C. Martin, 角 征典, 等『Clean Agile 基本に立ち戻れ』（アスキードワンゴ）Kindle版、2020年、位置No. 655。
組織運営も、プロダクトと同じようにデータを使ってマネジメントできるようになりたいと思います🦩
弊社ではSREを募集中ですので、興味を持っていただけた方はぜひどうぞ
カジュアル面談をご希望の方はこちら
Discussion