team-building-study-group.connpass.com
こちらのイベントに参加してきたので会の様子と感想を書いていきます。
会の概要
タイトル通り、ちいとぽことチームトポロジーを読んだ皆さんで感想戦をしていこうというイベントです。
会で話されていたこと
OST形式で、30分×2で2つのテーマについて感想戦をしていきました。
認知負荷とは？
認知負荷という単語が本では多種多様な場面で用いられており、これってどういう意味で使われているんだろう？という話をしていきました。意見としては以下のようなものが挙がっていました。
- プロジェクト型の認知負荷/プロダクト型認知負荷というのがありそう。
- 制限しない方が良い認知負荷があるのでは？普段全く仕事をしないチームから知識を仕入れることで、何か新しいやり方が生まれるなど
- 学習内容に伴う負荷/学習に関係ない余計な負荷/学習に役立つ適切な負荷の3つに分けて、それぞれの認知負荷をどう効果的に調整するかを考えると良さそう。学習内容に伴う負荷は、コンプリケイテッド・サブシステムチームが調整し、学習に関係ない余計な負荷はスクラムで言うスクラムマスターやプラットフォームチームが調整し、学習に役立つ適切な負荷はイネイブリングチームが調整する、というような形。
- 認知負荷という概念が作られたコンテキストが教育分野なので、これを組織に適用するのは難しそう。認知負荷という概念が現れた元々の論文を読んでも、認知負荷という概念を活用している場面が大分違うので、「認知負荷が高そうだから下げよう！」位のレベルで行動すると痛い目を見そう。
- 認知負荷が高いかを測るやり方が難しい(外から質問を投げてみてどれ位的確に答えが返ってくるか？で測るというのは、認知負荷以外の要素があまりにも影響しそうだった。)
チームAPIの活用
書籍内で紹介されていたチームAPIを上手く活用する方法は？という話を議論していきました。以下のような意見が挙がっていました。
- 過去に他のチームとやり取りした際、「定義されたフォーマットでチケットを挙げてください」と言われて、冷たいな...と感じたことがあったが、あれはまさにチームAPIを適切に定義できていた例だったのかもしれない。
- チーム間のドラッカー風エクササイズという感覚を持った。チームごとに何かしらの想いがあり、その思いにしたがってコミュニケーションを取ろうよ、コミュニケーションプロトコルを定義しようよという話。
- 結局はストリームアラインドチームが肝になっているので、ストリームアラインドチームを軸に考えると、適切なAPIが切れそう
- レポートライン別/話したいロール別にチームAPIを定義することで、余計な介入を減らすことができるのではないかと思った。
チェックアウト
チェックアウトとして、参加者でふりかえりをしていきました。以下のような感想が挙がっていました。
- もやもやするポイントが多い本だと再認識できた
- もやもやの共有ができてよかった
- まずは良いストリームアラインドチームを作ることが大切なんだと思った
- どの立場の実践書かが分からなかった。
- チームAPIを実践したい
- 認知不可の高まりを検知する方法をもう少し考えたい
- 4つのチームタイプのネーミングが複雑でもやる
- いつでもどこでも「まずは会話しましょう！」ではないんだな、と知れた
- 「プラットフォームチームの価値は、プロダクトチームに提供しているサービスの価値で測られる」という言葉が好き
- チームAPIの話で、コミュニケーションは密なもの/密ではないもの両方が必要ということが分かった
- 組織設計する上の人（事業部長とか）にも読んでもらいたい。。
会全体を通した感想
皆さんのもやもやが多めだった部分が挙げられ、それぞれについて共有できたのが良かったのかな、と感じました。(参加者からも、自分の想いと似たような想いを聴けて安心したという感想が多く挙がっていました)
個人的には、認知負荷の部分はまだまだ自分の理解が浅く、現場のコンテキストに合わせるためには、もう少し原著となっている論文を読み込んだり、学習科学の観点から深堀をしたいなーと思いました。
