SIGで『チームを止める』ことが成長するチームに繋がる

いくつかのプロジェクトで経験知的にやったことの中で我ながら良いなと思ったのが、兎に角、チームを止めるアクティビティを計画の中に折り込み、実践するということだ。

最終形としてのパターンは、毎週末の金曜日の午後に時間枠を設定し、例え、ほとんどのメンバがデータセンタ作業などで不在になったとしても残ったメンバが2人以上いれば続けるようにしていた。生憎、データセンタ作業は予備時間を含め、作業で一杯になるし、プロジェクトルームと同じ環境が揃っていないため、翌営業日に別の時間枠を取っておく。

立ち止まらせる

チームを立ち止まらせるとはどういうことか。それは上述してしまったが、週次で枠を取り、KPTをやってもらい、チームメンバ一人ひとりの実績、できなかったことを俯瞰してもらう。

これを『立ち止まらせる』と表現している。

放っておくと、チームの進捗が前倒しで進捗していても先の作業を割り振って欲しい、その作業を着手します、と言い始める。

一見、良さそうなのだが、一概に良いとは言えない。なぜなら、作業がその期日に設定しているのは作業の依存関係や外部との決め事と絡み合っているから、というケースもあるためだ。ただ、これは指して理由の大きなポーションとはならない。

立ち止まり、自分たちのチームが行った実績が計画どおりにやれたとしても、何かしら、とても些細なプロセスの不具合を人系でカバーしてしまっていることがままあるからだ。人系、つまりエンジニア個々の経験知でプロセスのバグをカバーしてしまうとカバーしたエンジニア個人のノウハウになってしまうし、複数いるエンジニアがそれぞれの経験知でカバーするので対応がバラバラになり、結果が変わることだってありえる。

プロジェクトマネージャでもスクラムマスタでも、作業プロセスの不具合は直させ、快適に作業をしてもらえる環境を維持しなければならない。

立ち止まることが成長に繋がる

上述したが、SIプロジェクトでは兎に角、何かしら作業をし続けることで進捗することを良しとする風潮がある。

これは実はそうしたプロジェクトのプロジェクトマネジメントがなされていないということを意味していることに気づかなければならならい。

プロジェクトマネジメントが機能していれば、無闇に進捗させる意味はない。計画どおりに進め、マイルストーンに複数のタスクが揃い、局面毎に成果物が要求される品質を確保していれば良いのだ。

繰り返すが、作業をし続けることを求めるプロジェクトマネージャがいたら、それは無能なプロジェクトマネージャの疑いがある。ただ、リスクを予見している場合もあるのでなぜかを聞くことを進めたい。

話を戻して、計画どおりに進め、枠を取り、チームを止めることで過去を俯瞰し、不具合があれば作業プロセスや手順書、ワークパッケージの順番の変更候補などをあげられるようになると格段にチームの作業効率が上がる。

当たり前である。チームのメンバ自身が行う作業のプロシージャをメンバ自身がやりやすいように直すからである。

メンバが些細な気づきをフィードバックする
　↓
プロセスが改善される
　↓
効率が上がる
　↓
元に戻る

こうした体験がチームの成長を育むのである。

どうして立ち止まらせるようにしたのかというと、作業プロセスデザインの中で作業プロセスは成果物だけを作る手順にせず、品質管理のプロセスを組み込まなければ、工程毎に品質を確保することができず、品質不良のリスクを次工程に付け回してしまうことから、作業品質を明示的に、それも週次のサイクルで埋め込んでおけば良いと気づいたからである。

SIG(Stop, Improve, Grow＝立ち止まり、改善、成長)とでも名付けようか。