- スクラムで開発が楽しくなるみたいな話と、スクラムで開発がつらくなるみたいな話、両方ある気がする
- 多分両方とも正しいんじゃないか、と予想している
- プロジェクトマネジメント手法としてのみスクラムやアジャイルの知見を取り入れたとき、確実につらくなると思っている
- 開発プロセスの変遷モデル - shimobayashiパブリックでいうフェーズ2的な。現実世界には普通にあるケースだと思っている
- なぜなら、スクラムイベントは面倒な割に、それまで自由勝手にやれていたのが「透明性」が大事とか言われて隠せなくなるし、ベロシティがどうとか言われてこれまでのらりくらりとリスケを繰り返して避けていた労苦から逃げられなくなるから
- だから開発者から反発やモチベーションの低下を招いたりもする
- 別にこれまで誠実かつ成果もまっとうに出していた開発者からしても、別に手法はなんであれ成果は出すので、ただ面倒に感じたり、なんなら時間を奪われているように感じそう
- ので、元々プロジェクトマネジメントにコストを支払う文化が無ければ根付かないんだろうなあ、という気がする
- チームマネジメントやプロダクトマネジメント手法としてまで全体を取り入れたとき、楽しくなる可能性がありそうと思っている
- 開発プロセスの変遷モデル - shimobayashiパブリックでいうフェーズ3的な。本来スクラムとかってこっちのはずなんだけど、現実世界にどれくらいあるのかよく分かってない
- 「言われたものをつくる」から「チームとして一体になって、主体的にものづくりをする」になるはずなので、本来プロダクト開発に参加したかったタイプの開発者にとっては楽しめる状況になりそう。おそらく
- でも実際は、大体においてプロダクトマネジメントに課題感は持って無くて「正しくつくれば」成果は出ると思っているからいきなりフェーズ3に行くモチベーションは無くて、マネージャーからすると正しくつくれてないから成果が出てないんだ→プロジェクトマネジメントをしっかりしなきゃ！になるのでまずはフェーズ2に行きたがるフォースが生まれる(ややこしいけど、実際それが正しいケースも普通にあると思う)。けどフェーズ2は現場にとってモチベーションが無いのでうまくいかなくて、そのままうまくいかないフェーズ2のまま「正しくつくっているのに成果が出ないのはなぜだろう？」という問いに到達せずに滞留してしまうんだろうな、という気がしている
- まあなんにせよ課題より解決法が先立つことは基本的に無いと思うので、(課題を感じているなら)先ずはプロジェクトマネジメントにコストを支払う文化をつくりましょうだし、そのためにはマネージャーがきちんと課題を発信し続けて理想と現実のギャップを示し続けることが大事なのかな
