アウトプットの出来が良いのはプロセスが良いからか

プロジェクトでチームの成果が思っていたよりよかったとき、それはチームで決めた開発プロセスがよかったからだろうか。

  • チーム全員で同じゴールの方を向いて
  • 同じ価値観で
  • 価値を産むことだけに注力して
  • メンバ個人を大事にして
  • アウトプットを中心に改善方法を議論して
  • モブやペアで勉強しあって
  • チームの開発ルールを遵守して
  • タスクの完了定義を守って
  • ルールを守っていなかったら注意しあって
  • 朝会は全員出席して
  • バックログはチームで優先順位をつけて
  • 見積もりは全員で前提と仕様を詰めて
  • 週次でプランニングのミーティングをやって
  • ふりかえりと学びを共有して
  • 360度のフィードバックをして
  • メンバのスキル、スキルレベルをオープンにして
  • チームのOKRをメンバで作成して
  • タスクは自分のOKRを意識して選んで
  • お昼ご飯はみんなで食べて

これは、ベターなプロセス(プラクティス以下略)を選んだからできたことなのか。

それとも、プロセスどおりにやったから、得られた成果なのか。

 

(作業)プロセスは、チームのメンバのばらつきを一定の水準、それも下限値を揃えるために導入するものだ。それは作業のプロセスを導入することで、最低限のアウトプットを確保するために行う。

大規模のプロジェクトで開発作業標準を導入して、エンジニアに適用するのは、100人のプロジェクトなら、100人の最低限の成果を揃えたいからである。数人でも下限値を下回る品質のコードを書かれては、品質管理でのコントロールのコストがバカにならない。

 

少人数のチームでも立ち上げるときにはチームのルールとしてプロセスは合意して、守らないといけない。でも、それがチームとしての価値を生み出すものであれば自然と身につくし、ルール以上の価値を産む。

でも、プロセスが期待以上の価値を生んでいるわけではない。価値を作っているのは、メンバなのだから。