プロダクトチームで強くなるためにEMPOWEREDの読書会をした話
こんにちは！atama plusの三井です。現在、atama＋プロダクトを開発しているチームでエンジニアをしています。
最近、私の所属するTerakoyaチームで「EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリーダーシップ」という本の読書会を開催しました。
参加者から「１人で読むよりも理解が深まった」、「チームビルディングとしても、日々の活動を新しい視点で捉え直す機会としても良かった」といった感想をいただけました。
また、atama plusは会社全体を通してアジャイルな文化が浸透しています。今回の読書会でもそういった側面が表れていたなと思ったので、どのように読書会を実施したのか記事を書いてみました。
この記事を通じて読書会が改善されていった様子や、またatama plusで働くチームのイメージも伝われば良いなと思っています。
なぜチームで「読書会をやろう！」となったのか
きっかけは、毎週行っているレトロの時間に、「チームのプロダクトディスカバリー力をもっと上げたい！」という意見が出たことです。
（プロダクトディスカバリーとは、問題解決におけるアイデアの妥当性を検証するために行う活動です。問題解決に繋がらないものを実装するリスクを回避するために行います。より詳しく知りたい方はLeanUXのディアルトラック・アジャイルの節が参考になるかもしれません。）
当時取り組んでいたOKRのテーマでプロダクトディスカバリーがなかなか思うように進まなかったという苦い経験をしました。「もっとチームで学びの機会を増やしていく必要があるのでは？」という話になり、その一環で読書会を始めました。最近はコンスタントに読書会を開催しています。
これまでの読書会では下記の本を取り上げました。
スクラムガイド
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける
LeanUX アジャイルなチームによるプロダクト開発
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR
今回、INSPIREDの続編ということでも注目度が高かった「EMPOWERED」の読書会を行ったので、そのときの様子についてご紹介します。
INSPIREDは「優れたプロダクトの生み出し方」が書かれている本です。プロダクトマネージャーのバイブルといわれてたりします。一方で、EMPOWEREDでは「良いプロダクト組織を作るための原理原則や手法」が書かれています。主にプロダクトリーダーを対象読者としています。
atama plusはフラットな組織で、各チームメンバーが自律した動きを求められていることから、この本から学べそうだと思い、「EMPOWERED」の読書会を開催しました。
読書会の設計と進め方を決める
普段の業務もある中、時間をつくって読書会を行うので、なるべく時間対効果の高くなる会を目指して準備をしました。
読書会の目的を設定する
最初に「何のために読んでるんだっけ？」と迷わないために、読書会の目的を設定しました。
本を読み終えてから目的を決めるわけではないので、ここは「エイヤ！」で決めました。本の概要が記載されているPart1を参考にしながら「良いプロダクトチームを作るためのエッセンスについて理解を深める」という目的設定をしました。
atama plusではスクラムマスターがチームの支援をしてくれるので、壁打ち相手になってもらいました。
対象範囲の章を絞る
時間帯効果の高い形でやりたいという気持ちがあったので、対象範囲を読書会の目的にあったPartに絞りました。
EMPOWEREDは全10章で構成されていて、今回対象範囲として選んだのは下記の章です。
■Part2 コーチング
■Part4 プロダクトビジョンと原則
■Part5 チームトポロジー
■Part6 プロダクト戦略
■Part7 チームの目標
■Part9 ビジネスコラボレーション
■Part10 インスパイアド、エンパワード、トランスフォームド
「Part1 一流のテクノロジー企業から学んだこと」の内容を参考にしつつ、目的に沿うような章をピックアップしました。「Part2 コーチング」の章は少し迷いましたが、本の中でもかなりのボリュームを占める章だったことから重要そうだと判断して対象範囲に含めました。
一方、下記の章は対象範囲から外しました。
■Part1 一流のテクノロジー企業から学んだこと
■Part3 人事
■Part8 ケーススタディ
外した理由は目的に沿っていなさそうだと思ったからです。また、「Part8 ケーススタディ」の章は、「他の章から学ぶことを優先したい」「負担にならないよう、読書会のボリュームを減らしたい」という判断から対象範囲から外すことにしました。
対象範囲を一度にまとめてしまうのは負荷が高そうだったので、２回に分けて１回あたり90分での開催としました。
（実は設計段階では上記のように対象範囲を絞ったのですが、読書会の中で面白そうという声も上がってきたことや、チームのスケジュールに余裕ができたことを踏まえて延長線でPart3、Part8についての読書会を開催しました。このあたりは、チーム状況などを踏まえて柔軟に対応しました。）
参加前にやってきてほしいことをアナウンスする
参加メンバーには当日までに対象範囲のPartを読んできてもらい、miroへの付箋だしをお願いしました。
付箋を出すときの観点は以下の通りです。
■チームでできていること
■チームでできていないこと
■新しく学んだこと
■わからなかったこと、疑問に思ったこと
■チームで実際にやってみたらいいかも・ワークショップにしたらいいかもと思ったこと
■つぶやき・感想
これらを付箋を出す時の取っ掛かりにしてもらいました。
当日の進め方
当日はzoomで通話しながらmiroを見て行いました。事前に出した付箋をもとに議論を行いました。全メンバー7人で下記のようなやり方で進めました。
■読書会の冒頭10分で他の人が出した付箋を各自眺めて議論したいものを考える
■１人が話したい付箋を選ぶ
■一つの付箋について10分を目安にみんなで話す
■話した内容は可能な限り緑色の付箋に書いていく
■上記のサイクルをローテーションで回していく
議論の目安時間（10分）を決めたことでリズムよくいろいろな付箋について話ができたと思います。議論が白熱するような付箋では、様子を見つつ10分以上かけることもありました。逆に「もう話し尽くしたかな」と判断したら、10分もかけずに次のローテーションへ回していきました。（このとき、カメラをオンにしてる人の表情も少し参考にしながら議論を切り上げるかどうかを判断しました）
当日は議論も盛り上がり、結果、たくさんの付箋メモが出来上がりました。
当日の様子
出てきた付箋の様子
当日議論した内容をPart番号と合わせて簡単にいくつか紹介します。
■Part2：チームの誰がどんなスキル（製品知識、プロセススキル、対人スキルなど）を身につけるのか戦略的に考えてみてもいいかもしれない。
■Part2：これまでの読書会はプロダクトづくりにフォーカスしたものが多かったけど、対人スキルとかファシリテーションとかにフォーカスした本を読んでみるのもいいかもしれない。
■Part2：度々ある意思決定のタイミングにチームでハッキリ「決断した！」という感覚持つのもなかなか難しいよね。意思決定するための情報が足りていない？情報が整理できていない？意思決定するにもいろいろなスキルが関係していそう。
■Part3：カルチャーフィットってあいまいな概念なのかな？そもそもカルチャーフィットを定義できるのだろうか？
■Part3：海外だと従業員を解雇しやすいから、本に書いてある「嫌なやつじゃない」というシンプルな採用基準にしても問題ないのかもしれない。
■Part4：プロダクトビジョンの共有とロードマップの共有の話。この辺があると顧客がatama＋を導入するかどうかの判断材料にもなりうるかもしれない。ロードマップじゃないけれど、会社の歴史年表みたいなものもあったら良いかも。例えば、過去に会社がビジョン・戦略に沿った判断をしてきたという説得材料にもなるし、オンボーディング観点でも会社が過去にこういう経緯でこう判断したというのが共有しやすくなりそう。
■Part5：プラットフォームチームとエクスペリエンスチームの分け方はしっくりくる。
■Part5：アーキテクチャがちゃんと出来てると共通部分が正しく共通化できるので、プラットフォームチームの肥大化が防げるかもしれない。プラットフォームチームの好ましい肥大化とそうでない肥大化がありそう。
■Part7：野心レベルを明確にするような動きは現状取れていないかもしれない。この辺明確になったら「それならこっちにフォーカスしたほうが良くない？」みたいなコミュニケーションも生まれるかもしれない。
■Part7：同じ問題に異なる野心レベルでアプローチする話はなるほどと思った。ルーフショット or ムーンショットの片方にベットするのではないのでリスク分散になるし、相互に獲得したインサイトを共有することで相乗効果も生まれそう。ただそもそもの問題設定を誤っていた時に、このやり方は逆にリスクが大きくなりそう。
■Part10：エンジニアだけど尻拭いだけやらされてるという感覚は全然ないね。ただ時々ソリューションがチケットに直接降りてきちゃったときは、やる作業がコーディングだけになってしまって価値が発揮できないと思うときはあるかも。
フィードバックを活用して読書会を改善していく
読書会の終わりには毎回slackで率直なフィードバックをもらい、第二回、第三回に向けて運用改善の参考にさせてもらいました。実際に貰ったフィードバックには下記のようなものがありました。
注：WAとはワーキングアグリーメントの略です
フィードバックをもとに以下のように読書会の進め方を改善していきました。
■読書会の冒頭に付箋を読む時間を取っていましたが、事前に読んできてもらうようにして議論時間をより多く確保できるようにしました。
■読んできた付箋のうち議論したいものは付箋のリンクをmiroのNoteに記入してもらうようにしました。読書会の中で付箋を探す手間が発生しなくなりました。
■議論の目安時間を10分→7分に見直し、より多くの付箋の内容について議論できました。
■全員で議論中のメモを残すことで、後で付箋を見返したときの情報量が増えるようにしました。
■読書会を読んで終わりにしないように、最終回ではラップアップの時間(30分）を取りました。ラップアップの時間を使って付箋の内容を見直し、具体的なアクションに繋げられないかを考えました。
読書会を進めていく毎に運用をスムーズにすることができました。全員で読書会をより良くしようという気持ちで進められていたのかなと思います。
ラップアップで具体的なアクションを考える
チームで読書会をするだけでも十分価値のあるものになりますが、読書会での話をもとに具体的なアクションを考えたいという声もあったので、最後にラップアップの時間を取りました。
各自で議論になった付箋の内容を振り返ってもらい、アクション案を考えてもらいました。
結果、コーチングのPartでの議論をもとに、「相互コーチングの機会を増やせないか？」ということで、「チーム内総当り1on1」をやってみようという具体的なアクションが決まりました。
読書会をもとにチームをより良くするための具体的なアクションが決まり、ワクワクしました。
ただ、正直ラップアップは最後にまとめて行うのではなく、各回やったほうが良かったという反省点もありました。第一回から第三回までで少し時間が空いてしまったので、もう少し議論した時の記憶がフレッシュな状態でアクションの立案ができたほうが良かったなと思っています。次回の読書会にむけてラップアップの仕方をもう少し工夫したいですね。
参加者の感想
簡単に参加したメンバーの感想を載せておきます。
■チームがより良くなるための議論が出来て楽しい。
■メンバーと議論することを前提にしているため一歩踏み込んで本を読み込めた。
■他のチームメンバーがどんなことを考え、どういうことに課題を感じるのかを知ることができ、とても良かった。
■他のメンバーの視点や考えも興味深いものが多かった
■読書会の設計が学びの多重構造となってて理解が深まった。
■入社から日が浅い自分にとっては議論を聞くことで弊社の現状について理解する機会にもなった。
■付箋という形でアウトプットが残ることで、後からでも思い出しやすくなる点もよかった。
■対象読者がプロダクトリーダーだったので、次は直接チームで使えるような知識・テクニックよりの本を読んでみたい。
■引き続き、チームで読書会していきたい。
まとめ
これまでチームで読書会をやってきて、以下のようなメリットを感じています。
■読書会の場で質問し合ったり感想を共有することで、一人で読むよりも深い理解を得られる。
■チームの共通言語ができる。１人で身につけた知識をチームに展開しようとする時にはコンテキストの説明も必要になりハードルが上がってしまうところがあるが、読書会をすればそのステップを飛ばせるので、より強いチームを作るのに一役買うと思う。
■シンプルに楽しい。楽しい時間をチームで共有できることは良い。
今後もチームが強くなっていくための取り組みの一環として読書会を続けていこうと思います。より効果的な学びが得られるような運用も心がけていきたいです。
最後まで読んでいただきありがとうございました。
少しでもatama plusのチームで働くイメージが伝わっていたら嬉しいです。
もしこの記事を読んで少しでも「atama plusっていいな、面白そう！」と思ってくれた方がいたら、会社の採用ページなども見てみてください。
現在、全職種採用強化中です！
この記事が気に入ったらサポートをしてみませんか？