スクラム開発で問題が起きたときの対応の仕方

https://twitter.com/shitai246_/statuses/372525878904766464

これずっと考えてる。

 

問題が起きたとき

今現在、僕らのチームはスクラムで開発を行ってますが、スクラムも銀の弾丸ではないので問題はまぁそれなりに起こるわけです。もちろん問題が起きたらすぐに対策を打つわけですが、

  1. 特定個人のせいにしない
  2. 見積もりのせいにしない
  3. プロセスは軽量を維持する

ということに気をつけることにしています。

 

特定個人のせいにしない

悪意を持って何かやらかしたのなら話は別ですが、当たり前の話として失敗したいと思って失敗する人はいません。

システム開発で何か問題が起きたときというのは、直接の原因になった人がいることが多いです。バグを埋め込んだり進捗が遅れたり、そういうトリガーになった人が必ずいるわけですね。ただそういうときに、その人の責任を追及してもあんまり良いことはないと思ってます。

バグや進捗遅れを個人の責任とした場合、極論すれば全て技術的な能力不足なわけです。ただ、エンジニアの世界は技術の流行り廃りが激しいため、誰しも常に勉強中の身であると言えます。勉強中の人に仕事を任せているわけですから、トラブルを未然に防ぐ仕組みが必要なわけです。

仕組みがないのはチームの問題なので、個人のせいにしても不毛です。もちろん仕組みを作るためになぜ問題が起きたかは当人にちゃんとヒアリングしますが、問題に対してはチームで取り組みます。

 

見積もりのせいにしない

見積もりのせいにされる場合もあります。見積もりが甘かったため進捗遅れを起こしたり、あるいは進捗を守るプレッシャーから品質が低下したり、などなど。

大前提として見積もりは単なる予測なので、外れることもあります。見積もりが原因だとするとバッファを詰むくらいしか対応策がなくなってしまいますが、いくらバッファを積んだところでパーキンソンの法則が発動するだけです。

見積もりは外れるものとして、見積もりが外れそうになった段階で計画が変更できなかったことを問題にするべきです。

 

プロセスは軽量を維持する

問題の対策を打つ際に、新たなプロセスを追加することは多いと思います。ただそのとき、全体のプロセスが増えすぎないこと、ひとつひとつのプロセスが重くなりすぎないことに注意するようにしています。

ウォーターフォールの呪いか何か知りませんが、問題が起きるとルールを増やしたがる人はどこにでもいます。放っておくと設計段階でレビューして実装コードをレビューしてテスト項目をレビューしてテスト結果をレビューして品質評価報告書を書いて…それなんてウォーターフォール?なんてことになるんじゃないかという気がしてくるくらいです。

必要なプロセスはちゃんと定義してルール化するべきだと思いますが、それを運用するのはチームです。重厚なプロセスはチームの負担になり、形骸化しやすくなります。また、チームには様々なスキルセットの人が混在しているため、一律に同じルールを当てはめることは熟練者の足枷になることも少なくありません。

ウォーターフォールが悪だとは思いませんが、数人のチームで重厚に厳密にウォーターフォールをやろうとするとコストパフォーマンスが割に合わないと思っています。アジャイルプラクティスなど先人達の知恵を拝借したり、ウォーターフォールのノウハウの一部を流用したりして軽量なプロセスを維持できるようにしています。

 

次のステップ

で、冒頭のツイートに戻って、こういうことをチームの誰もが出来るようになるにはどうしたらいいのか考えてたけど、記事書いてるうちに自分ひとりでも気をつけていられるなら問題ないやって気がしてきました。全員できればそれに越したことはないんだけどね。なんか贅沢な悩みだった気がする。

明日からもがんばろう。