参加してました。体調がアレだったので流しながら見てたりしてたので特に自分の中に残った部分だけ。
続きを読む
今のチームでスクラムを始める時、多少時間はかかってもプランニングはやりきりましょうということをメンバーに対して話していて、合意も得ていた。
しかしPO(=事業部長)が無駄なMTGやってませんかと言ったことで一部のメンバーが過敏に反応して時間内に収めることを優先しようという動きを始めてしまった。
既存の考え方はなかなか変わらない。
MTG時間=無駄な時間という一般的に正しいと強く信仰されている言葉と、事業部長という立ち位置の人の発言というのがかなり大きかったのだと思う。
一応、この状態でもうまくいくならいいかと見守っていたものの、やはりプランニングが形骸化し始めている*1軌道修正をはかりたいところ。
POに対して「開発チームのプロセスに口出ししてはならない」というのが言われていますが、こういうことだったんだなーと初めて理解できました。
ある意味経験を得られてよかった(笑)
*1:各タスクやる人が見積もりしてねとか
2月から関わっていたプロジェクトが無事に終了した。
タイトルでは予定通りと言っているが、実際には自社開発サービスのリプレースなので何かあったらリリース延期とかは出来る状態。
とはいえ、当初目標と定めていた6月末リリースを無事に終えられたので予定通りと言ってもいいと思う。
ある程度スキルと経験の揃った人がきちんと予定通りに終わらせるためにどうすればいいか考えて動いた結果、というのが正直なところ。
あとは社内システムなので融通を効かせられるのも大きい。
実際に納期延ばしてとかこれやめにしてとかは言ってないけどいざとなったら相談できるのと、無理な仕様が来ても難しいと言える関係は安心感がある。
自分としては「React,TypeScript,Next.jsわかるよね?」ということで招聘されたので無事に役目を果たせてホッとしているところ。
*1:今は出社は任意だが2人は家の事情等で出社を選択していたらしい
1週間のスプリントで毎週1時間ずつレトロスペクティブとプランニングをやっている。
スクラム1ヶ月ほどやってみてメンバーはそこそこいい感じの手応えを感じていたっぽいところ、上司からこの取組についてフィードバックがあり「メンバーのやりやすいようにやってくれて構わない」と言ってくれつつも遠回しにMTGを削って効率化しろという指摘をされた。
自分としてはまたいつものかと思いつつも「予定としてのMTG時間だけ削ってもその分だけ見えないところに分散するだけですよ」みたいなことを言って一応この時間の確保は続けさせてもらうよう話をしていた。
しかしその週のレトロスペクティブで時間を減らそうという話が出てしまった。
その週、レビューが爆発してリリース出来ないタスクが発生していて今後どうするという話をしていて当事者たちは「プランニングで厚目に見たい」という意見だったが他の人は「時間が増えてしまうので関係者だけでやればいいのでは」という意見だった。
まるで自分たちは関係者じゃないみたいな物言いでショックだった。同じチームなのに。
それとMTG時間を減らすことが目的になっていたのと、何よりそうなった原因が上司からの命令だったというのが情けない。
始めるときに1時間って長いって言われがちだけど〜みたいな話をして納得してもらったはずなのになー。まぁ1ヶ月経てば忘れるか。。。
ちなみに、自分は毎回1時間全部使い切れとは思ってない。
早く終われて作業にかかれるならそれに越したことはない。
ただ、現実問題が起こっている状況でコミュニケーションを削るのはありえないというのが自分の考え。
試してみればよかったのだろうか。
MTG30分削れば儲かるのか?を率直に聞いてみればよかったのだろうか。
ここまで書いてみて、実はMTG時間短縮云々じゃなくてメンバーに対して疑念が出来てしまったところがしんどいのかなと思った。
ここまでやってきたときに協力的っぽい感じがしたのは自分に関係があるところだったからなのか、目に見えやすかったからなのか等々考え始めてしまってしんどい。
混乱期に突入したのかなと思えばまぁ前進してる感じはするのでいいけど、このままだと形骸化して崩壊しそうなのでなにか手を考える。
すぐに悪くなるものへの対策はしやすいけど長期間に渡って効いてくるものは納得してもらうのがなかなか難しいね。
とりあえずモヤモヤを溜め込んでしまったのでここで吐き出しておく。
期の変わり目でそこそこ大きめの人事異動が発生している。
人員配置の最適化といえば聞こえはいいけど個人的な感想だけ言えば、半年かけて作ってきたチームや文化がリセットされてたまったもんじゃないと思う。
一般的にチームが機能し始めるようになるには3ヶ月〜半年程度かかると言われている。
んで、自分が今期面倒を見てきたチームも半年経ち今は技術的な相談くらいしか面倒を見ていない。要するに自律的なチームになれている。
しかし今回の異動で6人チームから3人が異動になったのとチームの事業的な役割も変わった。
新しい人が入ってきたわけじゃないというのは若干マシだけどまたここが機能するようになるまでの数ヶ月、模索の期間が続くはず(形成期、混乱期)
ちなみに自分は今回の異動とは別にひとあし先に異動になっている。
自分の異動の話を打診されたときは、既にチームは機能していたしこのような大きめの人事異動の話は全く出ていなかったので安心して承けたつもりだったんだけど…。*1
とはいえこれはあくまで会社全体のうちの一部署一組織しか見てない自分の感想なので、全社レベルの視点で見ると正しいのかもしれない。今の自分にはわからないけど。
そういえば評価面談をしたとき、現場レベルでのマネジメントは問題ないからもう一段上の視点(?)でのマネジメントを学んでほしいというようなことを言われた気がする。
これはいわゆる「経営者視点を持て」というアレだと思ってるので避けたいんだけど、それとは別に上が何を考えているのかは知っておいたほうがいいのかもしれない。
けどこれって社内政治とかそういうのに繋がりそうという気もしている。
求められていることをもう少し明確にしたほうがいいかもしれない。
その中から汎用的なものを探すという道筋が良さそう。
*1:あと、入社当時に上長になるはずだった人のところに行けるということで喜んで承けた
2020年も終わりですね。
部署が変わってからの仕事上の役割を決めるときになぜかスクラムマスターという名前の役割を与えられていた。
これには理由があって、
これらのことを上司が配慮してくれたことによる(と理解している)
とはいえ実際にそういう役割だと認識してくれたのは上司2人だけだったけどw
自分としては手を動かして成果物を作る以外の活動をする大義名分を得たと解釈して思う存分やらせてもらいました。
具体的なことは過去記事に書いてますが、いろいろ失敗しつつも経験や考えをもとに試したことが奏功したことは自分にとって大きな経験だったと思います。
来年やることはこれを自分のスキル・知識として明確化することですね。
これをやらないと今回の経験がただのラッキーパンチで終わったり自分がボトルネックになる可能性があるからです。
あと、問題・課題はきちんと捉えられているのに解消するための表現が下手くそという指摘もされてるので…。もう少し伝える力を身に着けなければ。
激動の2020年お疲れさまでした。
大変だった。
その一部始終と分かったこと思ったことを残しておく。
先に書いておくとアップデートできたからと言ってwebpacker理解できたわけではない。
ただwebpackerを扱うときどのあたりを触ったりどのあたりの記述が関係してるのかのあたりはつけられるようになったし、開発サーバー立ち上げるときに流れるログにもちゃんと意味があってそれがヒントになることがわかるようにはなった。
おもに見るべきは webpacker.yml と config/environment.js
environment.jsがbabel他のloaderの設定になっている。
詳しいことは公式に書いてある。
主にはchunkのやり方が変わったこととerbに埋め込むタグ(javascript_packs_with_chunks_tag)を使うこと、画像などはmediaパスになったこと、webpacker.ymlに extract_css: true を書くこと、が主な対応だった。
webpacker立ち上げるとログにjsやcssのパスが大量に表示されるところがあるけどあれが javascript_packs_with_chunks_tag で読ませるべきパスと実際のファイルの対応になっている。
あれがおかしければ読み込めないし、欲しい形のパスになっていないならenvironment.js内のloaderの設定を見直す、という感じで対応した。
それにしても、webpackerのググラビリティ低すぎ(勝手にwebpackとして検索される)
webpack自体もだいぶ辛いけどwebpackerはwrapされてるのもあって更に辛い。
世に脱webpacker記事が沢山あるのもうなずける。
そんな感じで四苦八苦しつつもなんとかアップデート自体は完了した(3系→5系)
…と思ったらそのプロダクトがサ終することが決まった。
この展開、前にも見た気が…。呪われているんだろうか*1
*1:一応別のプロダクトにそのまま応用できるわけだから完全に無駄になったわけではない