Kyash SREチームの中村です。今回はKyash Advent Calendar 2023ということで、以前関わったプロジェクトでSREチームのリードを務めた際の体験を書かせていただこうと思います。
0. 発端
普段、Kyash社での私は構築や運用というタスクを粛々とこなしつつ平穏に暮らしているのですが、たまに特別なイベントが起こります。今回お話しするプロジェクト参画がそれでした。
本来こうなるはずはなかったのです。何しろそのプロジェクトのSREのリードは別の人がやる予定でした。自分はほぼ関わらないか、関わるとしてもお手伝い程度で、平和な日々を享受するはずでした。
しかし、そこは人の入れ替わりの多いこの業界のこと。その方が退職することになりました。その結果、私にお鉢が回ってきたのです。
このプロジェクトに関してはもっと上に全体を統括する方がいらっしゃいましたが、少なくともSREチーム関連の業務については私が責任もって回すことになりました。
1. 段取り
1.1 いつから始めたら良いのだろう？
状況
さっそく問題がありました。
おっとり刀でジョインしたので、プロジェクトの概要しかわからないのです。スケジュールも引かれていませんでした。
しかも空気が奇妙な感じで、聞く限りかなり危険な状態なのですが、なぜかのんびりしていて、余裕しゃくしゃくなのだろうかと思わせる雰囲気がありました。
選択
ここで私が取れる選択肢は大雑把に２つありました。
- どの程度まずいのかまずくないのかもわかっていない。このこと自体がまずい。最優先で取り掛かる
- まだヤバいと決まったわけではない。後回しにして、このプロジェクト以外にも仕事があるからそちらを優先する
どちらもそれなりに説得力がありました。
ですが今回選んだのは１です。即動くのが正しい証拠はなかったのですが、今のタスクで緊急性の低いものは全てペンディングにして、このプロジェクトへの対応を最優先にするようマネージャーに提案しました。ありがたいことにマネージャーはご理解くださいました。
実際はまだ猶予がある可能性も十分ありました。わざわざ様々な作業の優先順位を変えてもらっておいて、もしこれで余裕が残りまくったらかなり格好悪いことになります。
「この判断で良い」と思っていましたが、それはそれとして不安もありました。
結果
即着手して大正解で、終わってみるとプロジェクトのバッファは数日分しか残っていませんでした。概ね２ヶ月程度のプロジェクトであったにも関わらずです。この選択を迫られた時、すでにスケジュールはかなりギリギリだったわけです。
もし２を選んでいたらおそらく厳しい進行を強いられていたでしょう。
1.2 何をすればいいのだろう？
状況
さて着手したはいいのですが、さっそく次の課題にぶつかりました。何をすれば良いのかほとんど何もわかっていないのです。多分やらないといけないのであろう個別のタスクがいくつか見えているだけです。
選択
ここでまた私には２つの選択肢がありました。
- とりあえず今目の前にある作業をやる。地道にやっていればいつか終わる
- 作業は後回しにして全体把握を優先する
基本通り２を選びました。
幸い、残された資料や過去事例を読み込んでいくと、抽象的な業務内容はそこから類推できることがわかりました。そこで全体のタスクを抽象化していき、６項目にまとめました。
複雑なプロジェクトでも自分が見渡せるくらいの数になるまで作業を抽象化すれば全体を見渡すことができます。そうして大雑把にでも大体の作業内容を把握しました。その上で、次に細分化したタスクを見渡していきました。
結果
全体把握を優先して正解でした。先々を見渡したことで、
「このタスクは自分たちSREだけではできず、開発チームの助力が必須になる。早めに相談しておかねば」
あるいは
「このタスクはさらに部門をまたがるからお見合いエラーを起こしそう。早めに調整しておこう」
などなど、手を打つべきことがあると早期に気づくことができました。このことは後のスケジュール管理や調整上でとても有益でした。もし目の前のタスクしか見なかったらこうはいかなかったでしょう。
それだけでなく、大まかにでもGoalが見えたことで自分の中でも安心感が出てきました。
例え完璧にできなくとも、どのようなリソースが必要か、またプロジェクトを進めるうちに何が起こりそうなのか、事前に予測しておくのは大事なことと思います。
2. 推進
2.1 動いて風を知る
状況
さて上述のような経緯で、プロジェクトに着手しました。全体も大体見えました。しかしまだまだ全タスクを具体的に抑えたというには程遠い状態でした。
調べ、考えて、詰めなければなりません。ですが時間の余裕がどれだけあるのか不明です。チームメンバーにタスクを振らないとプロジェクトは進まないのももちろんです。
選択
ここでも二つ選択肢がありました。
- 計画とは完璧であるべき。納得いく計画ができるまで次のフェイズに行ってはならない。他のチームメンバーには待ってもらう
- 今の状況からすると走りながら考えざるを得ない。こちらの把握を待たずできるところは進めてもらう
プロジェクトマネジメントの教科書通りにやるなら１だと思います。ですが今回は２を選びました。
今回のプロジェクトは締め切りが厳格に決まっていました。あまりスマートではないのかもしれませんが、期日までに必要な成果物を提出できる可能性が高いのは２の方だと考えました。
結果
これはどちらが正解だったか悩ましいところですが、多分正解だったのだと思います。上述の通り、後で分かったことですが、このプロジェクトは長い手待ち時間を許容できるほど時間に余裕がなかったのです。計画ができるまでチームメンバーは待機、などと言っていたら時間が不足していたのではないでしょうか。
ただしいつも今回のようにすべきとは思いません。一番いいのは、計画を練ってから動いても問題ないだけの時間の余裕を用意することだと思います。
余談ながら、まずやってみるというこの進め方を、社内では「動いて風を知る」と言っています。
今回は動いたら「逆風だな！」と知ったわけなんですが。
2.2 進捗どうですか
状況
上記のようにドタバタしながらも、タスクをより具体的にしていき、またメンバーに順次割り振っていきました。 あとは粛々と進めながら、新たに出てきた課題に全力で当たるだけ・・・というところでまた課題が出てきます。
プロジェクトの進捗状況が良いのか悪いのかわからないのです。
選択
ここでも二つ選択肢がありました。
- 感覚を信じる
- 数字を使う
基本通り２を選びました。フィーリングでやると自分も曖昧な把握しかできませんし、周囲も状況がわかりません。
今回は進捗を表すKPIとしてタスク数を用い、そちらを毎日集計して毎日Slackで共有しました。グラフ化こそしませんでしたが、考え方はバーンダウンチャートを参考にしました。
ただし粒度の大小の差があったため、タスク数が厳密に進捗を表せるわけではありませんでした。そのため口頭ベースのコミュニケーションで補完することも心がけました。
結果
普通に数値化して良かったと思います。自分も進捗把握がやりやすくなりましたが、随時報告が上がってくるので安心できたと社内でも好評をいただきました。
規模感を数字で表すのは大事、と改めて実感しました。
3. 終盤
3.1 放り投げ OR 仕上げ
状況
そんなこんなで、実施が必須でないタスクをまとめてペンディングにする荒技も挟みつつ、プロジェクトは進みます。
そうこうするうちに一つの区切りがつきます。完了必須のタスクが全て完了ステータスとなったのです。
選択
ここでまた選択肢がありました。
- 「終わった終わった。チェックと仕上げがまだだけどもういいでしょ。忙しいんだから次行こう次」
- 「チェックと仕上げの工程を飛ばしちゃいかんでしょ」
なるべく生の声を届けたいということで包み隠さず書きます。１を選びたくなりました。
しかし実際は２を選びました。
「あたりまえだ」とお叱りが聞こえてきそうですし、実際そうなんですが、プロジェクト終盤になってくると心身ともに疲れが溜まっているもので、１の誘惑もかなり強かったです。
現実の業務においては、１を選んでしまう（選ばざるを得ない）プロジェクトが少なからずあるのではないでしょうか。
いやもちろんダメなんですけども。
結果
これも当たり前なのですが、２を選んで正解でした。やはり仕事のクオリティはチェックと仕上げで引き上げられるもので、見落としや理解の浅い部分を大いに埋めることができました。詳細は伏せますが、これは後のフェイズで大変自らを助けることになりました。
最終的にこのプロジェクトは悪くない着地ができたのですが、その要因の一つはこの仕上げができたことにあったと思っています。
終わりに
「基本が大事！」
これを改めて痛感しました。
その場その場でかなり様々なことを考えながら判断を重ねてきたつもりでしたが、改めて振り返ってみると、結局は当たり前の選択を当たり前に選んでいただけです。
プロジェクトマネジメントでは変に裏技など探さず、基本に忠実に、各プロセスを漏れなくきちんとやり切るのが大切、ということなのでしょう。面白みがなくてもレシピ通りに作っておけばマズメシにならないようなものかなと。
最後に付け加えますと、今回の趣旨とは違いますが、今回のプロジェクトをなんとか着地させられた最大の要因は社内のご理解ご協力に恵まれたからに他なりません。謙遜ではなくそうです。上で書いたような選択ができたのも、それを許してくれる環境あればこそでした。
当たり前のことを当たり前にさせてもらえることは、素晴らしいことです。
