に行ってきました。

前置き

内容に沿った話は私の手には余るので（おい）、かろうじてメモが取れて印象に残ったこと、忘れないようにしたいことをつらつら記していきます。実際ぷーさにさんの話は面白くて密度も濃いので、私の処理能力ではちょっとうっかりすると咀嚼できずにただただ楽しく聞くだけになってしまってました・・・。なんとかしたい。

振り返りのテーマを絞る

自分が直接は関わってないんですが、予めキープしているミーティングの時間をよく踏み越えている（ようにはたから見えている）チームがあるんですけど、確かにいろんなことを一度にやろうとしている（ようにはたから見えている）と思いました。

少なくとも、今後この点を意識して関わる必要はありそうだと思いました。

型にこだわらない

プラクティスを実行するのが目的ではないとか、カンバンの型は現場の状況に応じて臨機応変に変更べきとか、そういうお話。あと、デジタルのツールでできること（できないこと）による制限によって、やりたいことをやらなくなるのは本末転倒であるとか。

分析する

問題が起こる傾向を雰囲気じゃなくて、統計をとって分析して対策を練る、と。そういえば私もマネージャーにそういうこと言われたばかりだった。

モード

コーディング中には気づけない観点が、コードレビューのときには気づくとか、テストケースを作成中には気づくとか。じゃあ漏れないようにするには、漏れないモードに予めなっておけばいいのではないか、というような話。だいたいテストケースを作成するモードでは抜け漏れをなくそうとするので、ようするに TDD なのでは、ということだったと思います。

これは実感としてよくわかりますね。テストケース考えてたらあれもないこれもないってなりますもんね。

全員で対処

いろんな文脈でこの話が出てきたように思いますが、私が一番気になったのは全員で設計する際に public のメソッド定義、シグニチャまで決めてしまうという話。たしかにそこまで全員で設計して合意が取れているなら、レビューでの手戻りも減るはず。

できることなら是が非でもやってみたい。やってみたい。

方針ややり方を変える（変えたい）ときは全体の振り返りで TRY として変える

これも全員で対処の文脈に入る話ですね。例えばリーダーが（単独で）頑張って上から変えてしまうのはよくないと。

まとめというかとても余談

途中から、私のカイゼンの心の師匠が言っていたこと（「結果的にスクラムになってる！なのがいいと思う！」）に似ているなー、と思いながら聞いていました。これが、カイゼンに向き合った人は結果として自然とそういう方向性を選ぶようになるのか、私がそういう考えに感化されているからそう思うだけなのかは、今の自分にはまだちょっとわからないのですが。