https://messagepassing.github.io/018-deadline/02-kzys/
昔にチームにいたシニアなエンジニアが「顧客は社内の締切なんて知る由もないが、可用性や速度についてはわかる。社内の締切のために品質を妥協するべきではない。」といったことを言っていて、私がそれを信じているから、というのもある。締切も品質もチーム全体で守るものだけど、締切をずらすことのまずさはマネージャーが、品質を妥協することのまずさ、例えば「この変更がどのくらいハックか」はエンジニアがよりよくわかっているはずで、私は締切と品質だったらまずは品質のほうを守りたいなあと思っている。
https://messagepassing.github.io/018-deadline/03-karino2/
リリースする過程でいろいろタフな諦めを行っていく事で製品というのは完成するものだ、 と思っていて（これは今でも思っている）、だから締切が無いといつまでも完成しないんじゃないか、とも思っていた。 でも最近は、やり方をいろいろ工夫すれば締切が無くてもリリースは出来ると思うようになった。
仕事の効率の為には適度なプレッシャーがある方が良いと思うけれど、 それで失われる物を昔より重視するようになった気がする。 「楽しく働けてそこそこの成果」くらいでバランスを取る方が、 長期的には良いプログラマが集まってきて良いんじゃないかなぁ。
https://messagepassing.github.io/018-deadline/04-shinh/
こううわーと背伸びして機能実装などをした後に、ちょっと時間を取って足もとを固める、みたいなの、シャクトリムシぽいなって思ってるのだけど、このスタイルは結構いろんなところで使える働き方なんじゃないかな、とか思っている。
bookmark 2021-06-30