スクラムやってても突発的な期限付きのお仕事って振ってきますよね。

ども、ひぐちぇです(゜д゜)ﾉ

スクラムでは、「期限を指定せずに、チームの見積もりに任せて仕事を進め、それに合わせてスコープやスケジュールを調整する」というものですが、納品したものが実際使われる場面（本番など）で問題起こったりすると、他チームの業務にも影響あるため、そうも言ってられません。

だいぶ前に我々の納品したあるツールが、今週あるお客様の環境で動かしてみて、上手く動かないということがありました。原因は、そのあるお客様の環境に限り、元々の想定と違った箇所があった事です。
実は、そういった状況を想定したツール修正を行うPBIも立ててはいたのですが、「急ぎではない」「そういうお客様は今のところ見当たらない」という理由で後回しになっていました。（もしかして、こういうの『あるある』なんですかねぇ(;´Д｀)）

POからも、今取り掛かっているPBIよりも優先度高くでお願いしますと指示され、
今週中に対応しざるを得なくなりました。

幸いだったのが、ちょうど同時に取り掛かれる仕事がなかった事もあり、他開発メンバーのサポートに回ってるメンバーが１人居たというタイミングでした。
いやぁ、稼働率１００％を目指してなかったのが良かったのかもです。

※稼働率と効率については、↓の過去記事より。
junhiguchi.hatenablog.jp

まず、そのメンバーに、ツールの中を見てもらい、修正の見積もりを立てもらいPBI化してもらいました。
私は、他チームと連携して、どういった理由で、いつまで修正が必要か？また、最悪リスケが可能なのかを調査。

今週中に修正して貰えれば、問題（今後の影響）はないとのこと。
そして、見積もりでは、その間に終われそうとの回答でした。
ここで注意しないといけないのは、「見積もりはコミットメント（約束）ではない事」です。ある前提に立っての見積もりなので、それが覆って場合には、当初の見積もり通りには行きません。その場合には、ごめんなさいしないといけなくなるのです。何かの本で見ましたが、「『見積もり』はあくまでも『そのくらいで終わる可能性が高い』という事を意味しているだけ」という事です。それを念頭において、話を進めました。

今回は、無事に期限通りにツール改修が済み、再度納品する事ができました。
（来週、本番環境で実際に利用する予定なので、まだ気は抜けないですが、、）

終わった後、ツール改修して頂いた開発メンバーからの感想に笑いましたｗｗ

「いやぁ、なんか久しぶりに仕事したーって感覚でしたよｗ」

とのこと(笑)

普段の仕事で、「余裕がある」という状態が良かったのだと思います。
常にいっぱいいっぱいだったならこうはならなかったでしょうね。

余談ですが、
中国の秦の始皇帝時代、秦軍が楚に攻め入った際に楚軍に大敗した後に、逆に楚軍から攻め入られてしまい、秦は滅亡の危機になりました。その際、既に引退していた王翦を秦王自らが説得して再度将軍になってもらい、楚軍の侵攻を防いでもらったという出来事があったのですが、その際のことです。