【メモ】チーム・ジャーニー本読み会第10話
著者による本読み会に参加した際のメモです。毎度素朴な疑問やコメントにに応えていただき感謝です。
コメント
リモートワークになってから、より他のチームとの交流がなくなったことで、今回の情報流通設計の重要性を把握できました。
出会う・お知らせをしあえる仕組みを意図的に作ることが重要とコメントをいただきました。
私の現場では他プロダクト開発チームとの会話は出社している時であってもほとんどない。
コーヒーサーバー付近での立ち話くらいでしょうか。
そんな出会わない複数の異なるプロダクトのチームが出会うための仕組みとして多段式朝会を導入している。
書籍で紹介されている情報の構造設計と似ているので紹介。
プロダクト開発チームの困りごとを情シスにまで吸い上げる仕組み。必要に応じて他部署にも情報が伝播されるようになっている。
こんなイメージ。
真価はリモートワークになってから
プロダクト開発チームはスクラム開発をしているため、朝会=デイリースクラム。情シスは他の開発プロセスです。平日は毎日実施。
デイリースクラムで出た困りごと（社内基盤の不具合・トラブルなど）を上に流すことでいち早く問題解決すること、サイロ化を緩和するために各チーム間で情報が混ざり合う状況を意図的に作り出すことが当初の目的だったように記憶。
2019年頃から運用開始してしばらく経つが、当初はこれが何のメリットがあるのだろうか？と疑問がある状態で参加していました。私は毎日参加する会議が増えるので負荷が上がるためです。時折、何かと理由を付けて出席しない方もいたりと主催の意義が浸透していなかったように思う。
4月7日に事態は急転しました。緊急事態宣言。全社員強制リモートワーク。
リモートワーク中は普段コンタクトをとらない人とは分断が急速に進む。会話する機会がゼロになり会話を始めるハードルが格段に上がる。
この仕組みがあったおかげで他のチームの現場の困っている事に耳を傾け、手を差し伸べることができた。自分たちのチームの困っていることを共有することで何らかの解決策や指針がその場で出ることもある。
重要性を肌で感じていたが、本読み会でも再認識できた。
リーダー会は意思決定機関ではない
書籍にも紹介されていたが、現職でも当初は意思決定機関にはしないというコンセプトで始まった。
プロダクト開発の意思決定は各チームに委ねられている。
その他の困りごとについては、意思決定機関になっているような気がする。
情報の粒度
書籍では情報の粒度設計が重要と語られている。
現場のリーダー会では自然と大きな枠組みでの報告が大きくなる。
しかし、困っている事はより具体的に報告していることが多い。バグの報告はかなり詳細なログの添付や再現方法が報告されることも。
もう少し粒度が荒くてもいいかも？
課題の可視化
書籍ではカンバンによる可視化がなされている。現場のリーダー会ではカンバンは利用していない。
「あれはどうなった？」発言が時折発生する。
まだまだ改善の余地はありそうだ。
この記事が気に入ったらサポートをしてみませんか？