『チームのルールですよね』『変えて良いよ』

これはあるプロジェクトチームを立て直したとき、朝会でカンバンを前にメンバ全員に言ったこと。

カンバンの列、基本形としては、ToDo | Doing | Done　の3つの列でタスク管理をするものをプロジェクトの成果物や段取りからカンバンを導入したタイミングで、カンバンの列をそれらに合わせて列を増やした。そのカンバンを説明しながら、カンバンの列どおりにやらないと、つまり列を飛ばしたらそのタスクは元に戻すルールにするからと伝えた。

• カンバンの列はチーム全員が守るプロセス
• プロセスを守らないと元に戻す

このプロセス（カンバンの列の順に進めること）を守っている限り、メンバのアウトプットについての失敗りは全部自分が責任を持つ。守らなかった場合、一切エンジニアを守らないよ、と。

メンバでもチームのルールを守らないメンバが出てきて、それを指導することを感けると他のメンバも悪い行いを真似をするようになる。

そうするとチームはdisciplineを失ってしまう。立て直そうとしているチームはダークサイトに落ちてしまう。

一方、ルールは机上で組み立てた仕組みである。テストをしていない。裏付けとして直前の作業を観察していてこれでいけそうだと踏んでいるが、なにぶん実践していない。

だから、チームのプロセスだと決めたルールにも間違いがあるかもしれない。もし間違いがあればそれを修正しないと無駄なことをメンバにやらせることになる。これも立て直すチームにやらせたいことではない。

であるから、チームにはこう言ったことも合わせて伝えた。

『今からこのカンバンはチーム、みんなのプロセスだ。だから、プロセスを分けたいとかいくつかの列を1つに統合するとかしたければ、チームで合意すれば変えて構わない。というか変えて欲しい』

こう伝えるとほぼ全員が驚く。

ルールは守るものだ。

ルールを守るように言ったではないか。

どうして変えて良いのか。 

実践テストをやっていないし、実務者としてルールを実行するのはメンバのエンジニアなのである。

目の前の現場でやらなければ意味がない。

カンバンのプロセスで使いにくい箇所があったらいちいちプロマネに相談をする必要があるだろうか。目的に対する成果を得られることが変わらないなら、プロセスは簡略化した方が断然マシである。

数ヶ月後、カンバンのプロセスは少し詳細に分けられていていた。

自分たちの成果を出しやすく、間違えないようにしていた。

ルールはプロマネの手から離れてチームのものになっていた。

SIMPLE RULES 「仕事が速い人」はここまでシンプルに考える (単行本)