アウトプットの出来が良いのはプロセスが良いからか
プロジェクトでチームの成果が思っていたよりよかったとき、それはチームで決めた開発プロセスがよかったからだろうか。
- チーム全員で同じゴールの方を向いて
- 同じ価値観で
- 価値を産むことだけに注力して
- メンバ個人を大事にして
- アウトプットを中心に改善方法を議論して
- モブやペアで勉強しあって
- チームの開発ルールを遵守して
- タスクの完了定義を守って
- ルールを守っていなかったら注意しあって
- 朝会は全員出席して
- バックログはチームで優先順位をつけて
- 見積もりは全員で前提と仕様を詰めて
- 週次でプランニングのミーティングをやって
- ふりかえりと学びを共有して
- 360度のフィードバックをして
- メンバのスキル、スキルレベルをオープンにして
- チームのOKRをメンバで作成して
- タスクは自分のOKRを意識して選んで
- お昼ご飯はみんなで食べて
これは、ベターなプロセス（プラクティス以下略）を選んだからできたことなのか。
それとも、プロセスどおりにやったから、得られた成果なのか。
（作業）プロセスは、チームのメンバのばらつきを一定の水準、それも下限値を揃えるために導入するものだ。それは作業のプロセスを導入することで、最低限のアウトプットを確保するために行う。
大規模のプロジェクトで開発作業標準を導入して、エンジニアに適用するのは、100人のプロジェクトなら、100人の最低限の成果を揃えたいからである。数人でも下限値を下回る品質のコードを書かれては、品質管理でのコントロールのコストがバカにならない。
少人数のチームでも立ち上げるときにはチームのルールとしてプロセスは合意して、守らないといけない。でも、それがチームとしての価値を生み出すものであれば自然と身につくし、ルール以上の価値を産む。
でも、プロセスが期待以上の価値を生んでいるわけではない。価値を作っているのは、メンバなのだから。
