年末ポエム
年末ポエムといいつつ年始になってしまったけど。
休みの中で思ったことをめも。
副題は「チームで仕事をするときのフレームワークとしてのスクラム」
IT業界で１０年以上様々な人と仕事してきたけど、ほとんどの人はチームで仕事をすることが苦手だと思うからはじまった話。
小学生の頃、教室の掃除をみんなでするとき。
なんとなく各自バラバラとホウキを取ったり机を移動したりする中、なにしたらよいかわからずポツンとしている子がいる。掃除を終わらせるという目的に対して自分のやることを見つけて実施するという子がいる。
ちょっと成長して中学とか高校の文化祭でも同じ。ペンキ塗ったりしてる人がいるなか、自分はなにしたらいいかわからないからリーダーっぽい人に聞いて仕事もらう。
こんなわかりやすい短期のゴールに対してさえ自分のやるべきことを見つけられない人がいるのに、いきなりチームでこれ開発してねみたいなの渡されてもたぶんできない。
ITの仕事は複雑なので、仲良くとかコミュニケーション取りながらとか、そういうのではとても対処できない。
そんな時、ゴールを明らかにしたり、みんなの目線を揃えたり、進捗を見えるようにするフレームワークがスクラムだと思う。
スクラムやってみようかで普通にできる人にとってはミーティングが増えるだけというのはその通りだと思う。開発とビジネスが当たり前に会話して、やるべきことが共通認識できれいれば十分かも。
スクラムはよく開発スピードをアップさせるみたいな紹介がされているけど、そうじゃないと思う。
チーム開発できない人たちでチーム開発できるようにするのが最初の一歩なので、スクラムやって良し悪しを判断する項目が「開発早くなった？」とかだと期待値は満たせないと思う。
確認すべきは「チーム開発できた？」であり、スクラムはチーム開発できてスクラム通り進めていれば結果的に開発が早くなるようにできている。
ビジネスの強い現場だと「チームが仲良し作業するためにコストかけるのかよ」と言われるだろうけど、なんの気持ちも入れずに作業したアウトプットで満足できるなら不要だと思う。
だけどほとんどのプロダクトはそれなりに複雑だし開発過程の「こうしたほうがいいかも」の小さい積み重ねに支えられてるはず。これはチームが仲良し作業していないと生まれない。
土に種植えて水あげてれば美味しい野菜取れる？
最終の消費者がそう思っているのはいいけど、作ってる側なんだったらハウスに入れて暖かくしてはじめて美味しくなるとか、そのあたりも理解しといてほしいよね。
この人の言っている「アジャイルじゃないとスクラムはつらいよ」というのはそういうことだと思う。
アジャイルに完全同意できない人がひとりでもいるとスクラムは成り立たない。
Discussion