Edited at

スクラムの堂々とコミットできないメリット

ここ最近のプロジェクトはスクラムをベースに行っている。

そこで、社内の抵抗勢力や、普通になぜいいのか疑問に思ってる人たちに、コミットはできないんだけども、ほとんどの場合、起こり得る伝えたいメリットがあるので説明したい。

ありきたりながら以下の2つが思い当たる。


  • チームメンバーの成長

  • 別次元の開発スピードの向上

チームメンバーの成長は、機能やシステムのレイヤーではっきりとした担当者を決めない、開発した全てに対してメンバー全員が責任を持つ、という2点で達成する。

開発スピードの向上は、レトロスペクティブなどにより、短い(覚えてる)期間内でPDCAが回ることで、着々と開発の無駄が発見され、改善されることによるものだと思う。

なぜ今までに語り尽くされたことをわざわざここを書いたかと言うと、別に開発手法の変化ごときで変わる事などさして多くない、仕様変更がなければ今まで通りの開発でいいじゃんってなる人たちに伝えたい事だからだ。

確かに開発フェーズの変更という考え方の話なら仰る通り、変化に対応できる反応が良くなるだけで、仕様変更が起きないならむしろ遅くなる場合もあるし、新しい取り組みを行うメリットは少ないと思う。

ただ実際には変化に対応するために、クロスファンクショナルや、整ったドキュメントよりコミニュケーションを重視するなど、働き方に関わる変化が必要となる。これがプラクティスとして議論され改善されてきている事で従来の手法では達成できない違いが出てくるのである。

そんなことは今までの方法でもやれるし、やるべきことだ、やっていると言う反論がこの後よくくる。

そりゃそうだと思う。

ただ従来のウォーターフォールなどの方法は、開発メンバーの変化等に対応することを前提としたものであるため、少なくともここで書いた内容はなかなか実践しづらく、どこかでごまかしが発生しているはずである。

この2つの効果が恒久的に出続けるとしたら?

従来の手法だけでやっていると最終成果物の完成度や、顧客満足度に影響しないのだろうか?

短絡的に絶対コミットできる内容だけ追いかけると、達成しえない世界があるのではないだろうか?