【読書メモ】あなたのチームは、機能してますか？
こんちは、じぬです。
いつもタイトルを 書評 にしてたけど評するってほどじゃないなって気付いたので 読書メモ にした。
読んでみて非常に良かった本だったため、いつも通り感想をまとめていく。
あなたのチームは、機能してますか？ | パトリック・レンシオーニ, 伊豆原弓 | 実践経営・リーダーシップ | Kindleストア | Amazon
良かったフレーズ
- p.68 信頼を気付く唯一の方法は、完全無欠でありたいという気持ちを克服すること
- p.92 政治的とは、自分がどう考えるかではなく相手にどう反応して欲しいかで言葉や行動を選ぶこと
- p.102 合意しなくても責任を果たせ
- p.140 個人の問題よりチームの結果を優先させること。あなたたちの第一のチームはこのチームなの
- p.151 追求しないことは信頼ではない。信頼とは、追求されたときに相手が真剣に考えているんだと理解できること
- p.151 とにかく追求することが大事、絶対に遠慮してはダメ
- p.186 幹部会議の時に9人もいるため実のある円滑な議論ができなくなってきた
- p.192 健全な衝突が無いと、メンバーは真に意見を出せず決定に対して責任感を持てない
- p.192 責任を持てなければ、チームのためにならない行動をとったメンバーに対して毅然と接することができない（説明責任の回避）
- p.197 信頼関係とは弱みを見せられること。弱みとは、能力不足、対人関係の欠点、ミス、助けを求めること
- p.198 信頼があれば、やるべき仕事にエネルギーを集中できる
- p.205 時間がかかるからと衝突をさける事があるが、それは次回の会議で再発するのがオチである
- p.208 時にリーダーは衝突を掘り起こす役割を担う必要がある
- p.209 衝突に対してメンバーから不快感が出ている場合は、それでもこれは必要なことだときちんと伝える。これが必要で生産的な活動だという自信に繋がる
- p.209 衝突に特化したツールとしてトーマス・キルマン衝突モデルがある
- p.209 衝突は自然な解決に任せることが重要だが、リーダーから見るとそれは失敗のようにも感じるためかなり難しいことでもある
- p.211 完全な合意を目指す必要は無く、きちんとそれぞれの意見が考慮されたことが伝われば十分である
- p.211 決定が正しいと確信できるまで待つという姿勢は、無気力さや自信のなさをチームに伝えてしまう
- p.214 最悪の敵はあいまいさである。期日などを明確に決めることで仕事への責任感が生まれる
- p.215 リーダーは決定が間違っていても動じないこと。グループで議論を促し、チームで決めたスケジュールの徹底を求めることが必要
- p.225 リーダーは誰よりも結果を重視して行動することが必要。そうしないとメンバーが同じように行動をとることはない
感想
ストーリー仕立てなのでサクッと読みやすかった。
ここ最近は改めて自分が何をすべきか考えることが多く、この本では特にリーダーとしてのふるまいに関する記述で気づきが多かった。 特に次に挙げる点は自分を改める良い気づきだったと思う。
結果にこだわる姿勢
前回の記事で書いたとおりチームを円滑に回すことにはこだわってきたつもりだったが、その分結果を追求できていたかというとイマイチな点があったかもしれない。別に不必要に厳しくする必要は無いが、メンバーそれぞれの成果や進捗に対して自分（リーダー）や他のメンバーが納得できるレベルまで突き詰める姿勢は改めて意識したい。
自分の成果ではなくチームの成果
正直な話、自分は割と自分自身の成果にこだわっているタイプだと思う。仕事である以上より良い評価を得たいと考えている。 ただそれが常にチームの成果と一致していたかというと自信が無い。 基本的にイコールではあるはずだが、結果論ではなく意識してチームの成果とは何か？を考え、それを目指した行動を選んでいく必要がある。 そうでないと、メンバーに対して同じ動きを期待することが難しくなってしまう。
弱みを見せる意識
これは普通にやっていたつもりだったが、最近仕事でもっとメンバーに任せちゃっていいのでは？という指摘を受けた。 言われてみると、最後は自分で解決しなければ、導かなければ、という意識はあった気がする。 勿論そういう姿勢も必要だが、メンバー自身が突破することを信じて（逆に言えば自分ではできないということを認めて）仕事を進める、というのがまだ足りていないのかもしれない。
2022年度のふり返り
こんにちは、新婚のじぬです。 期も変わったので、去年の入社から何をやってきたかふり返ろうと思います。
チーム組成
去年の入社時に前任のマネージャーから引き継ぎ、エンジニアチームの組成を担当しました。 基本的に自走できるメンバーばかりでしたが、新規メンバーも複数いるタイミングだったので、上手く連携できる環境作りを心がけました。 やったことは、一言で言えば雑談する機会作りです。 フルリモートの環境では何気ない情報共有の機会が少なくなってしまうため、なるべく気軽に話ができるよう定例ミーティングを設置しました。 ミーティングは多すぎると効率が下がるので難しいですが、リモート環境ではやや冗長な頻度で行うべきというのが所感です（議題がなければ早めに解散することもあります）。 今のところ、1時間ずつ週3回ほど定例ミーティングがあります。
参考にした記事⇒「帰りの会」というリモート雑談の形 - maru source
初期は会話を促したり必要性を認識してもらうために自分でファシリテーターをやりましたが、ある程度軌道に乗ったあとは交代制にしました。 チームメンバーの参加しているという当事者意識を高めることが目的でしたが、それ以外の利点として、自分がいなくてもミーティングが実施されるという事実が精神的な負担を軽減してくれました。
これ以外にもバックログの棚卸しや、普段はそこまで詰められていない議題を集める月1の定例など、いろいろな角度からコミュニケーションが発生するよう意識しました。
課題の収集・検討フロー
元々プロダクトを使い込んでいるメンバーも多く、改善アイデアが Slack 等で挙がることがちょくちょくあります。 それらを放置するのはプロダクトとしても勿体ないし、放置が続くと提案してくれるメンバーのモチベーションも下がってしまいます。 そこでマネージャーメンバーの定例アジェンダとして、それらを拾い上げることを徹底しました（そもそもこの定例設置も担当していました）。 議論が落ち着いたものについては全体に周知をするなど、意見を挙げてくれたことが無駄だと思われないようにしました。
チーム間の情報共有機会を設置
メンバーが増えたことで並行開発ラインが増え、情報のキャッチアップが難しくなっていきました。 チャットを注意深く追えば拾うことはできますが、全員がすべてのチャットを追うのは効率的とは言えませんし、そもそも全体把握に対するモチベーションもメンバーごとに異なります。 そこで開発チームを横断して情報を拾えるように、任意参加の確認会を設置しました。 このミーティングに参加していれば、ある程度の概要までは拾えるようにしています。 その上で詳細まで把握したいメンバーは、仕様書やチャットを追ってもらっています。
コミュニケーションのハブ
主にチャット上のコミュニケーションで細かい混乱が起きた際はいち早く反応することを意識しています。 例えばスケジュール決めなど、特定の主導者がいない部分は意識して関わっています。 目的の一つは開発メンバーが目の前の課題に集中できるようにすることで全体のパフォーマンスを向上すること、もう一つは自身がコミュニケーションハブになることでプロダクトに関する課題をより深く理解することです。 特にマネージャーは、実績の積み上げによるメンバーからの信頼構築が大事だと思いますので、そういう目的でもややこしい部分は積極的に関与・解決できるようにしています。
ピープルマネジメント
1on1 などメンバーのフォローを行いました。 月並みですが、なるべくメンバーの意見や意思を引き出すように傾聴を心がけています。 自分はいつも Google Document で会話ログを共有しており、きちんと意図をくみ取れているかを示すようにしています。 副次的な効果として、取り組んだことふり返りがしやすく、メンバーが評価ふり返りを行う際の参考になっているようです。
プロジェクトマネジメント
いくつかの取り組みでプロジェクトマネージャーを担当しました。 Slack コミュニケーションで完結するのが1番スマートとは思いましたが、キャッチアップの負担を考えて定例ミーティングを行っています。 開発が軌道に乗ると細かいすり合わせも多いので、直接のコミュニケーション自体は必須かなとは思っています。 なるべくスムーズになるよう、バックログ整理や議事録まとめなどを行っています。
まだできていないこと
ベロシティや 4 keys など、チーム状態を定量化することはまだできていません。 ちょうど今はメンバーが増える中で新しい組織を模索しており、それと合わせて長期的にチーム改善を継続できるような指標も定義していく必要があります。
また、昨年度はいくつか定期ミーティングを設置しましたが、それらが本当に適量かは測り続ける必要があると思います。 作業時間が減り過ぎていないか、メンバーのモチベーション低下に繋がっていないか、という点は定性・定量それぞれの観点で把握するべきです。 現状ではヒアリングなどを行っていますが、チャットコミュニケーションの量など定量的な指標計測も今後の課題だと思います。
コミュニケーション創出やプロジェクトマネジメント、ピープルマネジメントなど、まだまだ言語化できるほどノウハウを得られていないというのは今後の課題です。 いろいろとアクションは起こせたつもりですが、ふり返りや、成果に再現性を持たせるための知見獲得は次の目標です。
【書評】新１分間マネジャー
読んだ。良かったので感想。
Amazon.co.jp: 新１分間マネジャー eBook : ケン・ブランチャード, スペンサー・ジョンソン, 金井 壽宏, 田辺 希久子: 本
雑感
マネージャーとしてメンバーとコミュニケーションする際に意識するべき事が具体的に挙げられていた。 1on1 をやる時など、細かいところで真似してみようと思える点が多々あった。
気に入ったフレーズ
第2章
- 何を目標とするか、優れたパフォーマンスとは何か、を自身もチームも理解している状態を作ることが優れたマネージャーには必要
- マネージャーがやるべきなのは「正しいやり方をしているところ」を見つけること
- メンバーが称賛を自ら勝ち取ったと思いそれが自信になる、それが重要
- マネージャーはミスを指摘したあと時間をおく、この時間でメンバーは自分のミスやその影響についてきちんと思考することになる
- 1分間修正はなるべく早く行う
第3章
- 目標と現状が一致しているかを考える
- 称賛には根拠と、心からのものであるかが重要
- 最初は、メンバーが「概ね正しい」ということを受け入れる
- 最初は1分間称賛をするべき対象がないか常に注意しておく
- 目的は自信をつけさせること、だから1分間修正の後半では必ず褒めることが重要
- 最初に厳しく、後半にやさしく、という順番
第4章
- 自分をさらけ出し、どんなマネージャーであるかをきちんと伝えること、自分も間違えることがある人間であること、それらをまず認めること
【書評】エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
会社で議論を進めていく上で、「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」を改めて目を通そうということになった。 もちろん書籍は知っていたが、恥ずかしながらきっちり読み切ったことがなかった。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon
気になったフレーズ
Chapter 1
- 曖昧さを減らし、具体性や明確さを増やしていくことがエンジニアリング（が成すべき事）
- 本質的に分からないのは未来と他人
- どんなに自分が正解だと思ってもそれは本人の認識においての話であり、他人（の認識）においては正解とは限らない
- 自分や他人がどんなときに論理的でなくなるのかを知っておく、それが論理的思考の盲点を知るという考え方
- 怒りを知るとは、自分にとって大事なもの、自分を構成するもの、その延長にあるもの、を知ること
- 怒りとは悲しみであり、その感情を伝えることが大事であり、正当性だけで相手を変えることはできない
- 相手の感情（やる気など）といったコントロールできないものを制御するのではなく、仕事に対する行動を観察してよりよい行動に変わるよう導くべき
Chapter 2
- 人は無意識に思考の範囲を狭めてしまう、それはその閉じた世界が心地よいから
- 悩むとは何をすべきか分からないこと。これを明確にすれば考えるフェーズに進める。ここに導くのがメンターの仕事
- 相手に共感し、相手の思考を可視化し、相手の盲点を探索する。そうして相手の思考に余力を作るのがメンターの仕事
- メンターは意図的に自己開示を行い、フィードバックを受けやすい状態を作る必要がある
Chapter 4
- ベロシティの悪いチームを外から改善しようとするのは間違い、当人たちが問題に気づくようにメンタリングするべき
- 分からないものをどうやって分かるべきか、分かったら何ができるのか、それらを自発的にできるようになるのが自己組織化された状態
Chapter 5
- 権限が明示的でない状態は最も不自由な状態
- 技術的負債は新たな機能があるときに現状との差分として始めて存在する概念
- 技術的負債という考えは、エンジニアチームと経営者のコミュニケーション齟齬を表現する必要性から生まれた
- 例えばエンジニアチームが社内 SIer のように振る舞うのは一見合理的にも見えるが、本来内製化で避けられるコミュニケーションコストを再度抱えることになってしまう
- ビジネスが進行すると専門チームを作り知の深化に向かいがちだが、これはイノベーションを起こす力が弱まるリスクがある
感想
いくつかマネジメントの本を読んでいれば知っている概念はあるが、それらを理論づけてまとめてくれている。 特に Chapter 1、2 の理論寄りの章は気になる記述が多く良かったと思う。
以前読んだときに読みにくかった記憶があったが、ある程度の理論や実践を経たいま読み直せたのはちょうど良かったと思う。 業務としてはチームと組織それぞれの観点を持ちながらビルディングを行うフェーズと認識しており、その観点では Chapter 3 のアジャイルや Chapter 5 の権限委譲の観点がとっかかりになるのでは、と感じた。
【書評】ゼロから学べる！ ファシリテーション超技術
最近ミーティングを仕切ることがちょっと増えたので1冊読んでみた。
本格的な議論に慣れてない、あるいはそこまで顔なじみでないメンバーとのミーティング向けかなという印象で、自分にぴったりという本ではなかった。 ただ要所要所で参考にしたい記述があった。
ゼロから学べる！ ファシリテーション超技術 | 園部浩司 | ビジネス・経済 | Kindleストア | Amazon
なるほど、となったところ
- アジェンダはあらかじめ考えておく、どういう流れでどういう時間配分をするかを決めておく
- まず現状の不満、次にあるべき姿を洗い出す。その差に注目すれば課題が見えてくる
- アウトプットはそこに対する問いで決まる、それを考え導くのがファシリテーターの責任
- KJ 法では7〜10くらいのカテゴリ分けが望ましく、そうならない場合は整理の基準を見直す（議題が複雑すぎる、とかではなくやり方次第で解決できる）
- 課題の整理と課題の議論は時間を分ける
分かっているつもりだけど自戒
- 仮に積極性が薄いなら、会議に自然と参加しやすい仕組みを作る（みんなで付箋を出す、とか）
- 納得感を作るには意見を聞いてもらえたと思ってもらうことが大事
- 聞いてもらえる、という信頼感が大事
【書評】チームトポロジー: 価値あるソフトウェアをすばやく届ける適応型組織設計
最近はチームビルディング周りに興味津々なのと、タイムラインでよく見かけることもあって読んだ。
気づきメモ
- 認知負荷：人が把握できる量には限界がある→チームの守備範囲が広がりすぎると認知負荷が上がりパフォーマンスが落ちてしまう
- 全員が全チャットを見る、全ミーティングに出る、みたいなことが起きているなら組織設計に問題がある
- 組織の関係を考慮せずにツールを統一する、ということがあってはならない 管理や評価の都合で組織再編を
- 繰り返すのは悪手→業務を通して必要なコミュニケーションに基づいて組織は設計されるべき
- 新メンバーがこれまでのやり方や視点との違いを受け入れるには感情的な負担がある（これはタックマンモデルの混乱期のこと
適切な境界
- 3種類の認知負荷がある、1. 2. を早期に解消することで 3. にフォーカスできるように整えていく
- 課題内在性負荷：本質的な負荷（実装における課題など
- 課題外在性負荷：環境の負荷（デプロイ方法など
- 学習関連負荷：学習する上での負荷
- 認知負荷を抑制するためにチームが扱うシステムをや範囲を小さくする（分割と分担）
- 事例：あえてリードを無くし、チーム全体で判断させることでモチベーション向上が起きる
- Spotify モデルにおけるギルドのようなコミュニケーションが自然発生しやすい環境があることで、本来のチームにおけるコミュニケーションの練習が行われる
チームの分類
| チーム | 概要 | 詳細 |
|---|---|---|
| ストリームアラインドチーム | エンドツーエンドで開発を行う | プロダクトや機能単位ではなく、ストリーム全体に沿うというあり方が必要になってきている |
| イネイブリングチーム | 特定ドメインのスペシャリストチーム | ストリームアラインドチームが直面する課題解決を補佐する |
| コンプリケイテッド・サブシステムチーム | 保守が必要な特定パーツやシステムのスペシャリストチーム | ストリームアラインドチームの認知負荷を下げるために特定ドメインの開発に責任を持つ |
| プラットフォームチーム | 下位の内部サービスを提供する | 例えばサーバインスタンスの構築やセキュリティなどを管轄するサービスを提供する |
- 同一のチーム内で設計から開発、テスト、デプロイ、運用ができるべきである
- イネイブリングチームは能力向上が目的であり、短期の密接なコラボレーションを前提とする
- 技術視点のみで分割すると、透明性が下がりコミュニケーションが遅くなりリスクがある
チーム間インタラクションの分類
| インタラクション | 概要 |
|---|---|
| コラボレーション | 他チームと密に連携する |
| X-as-a-Service | 依存を最小限にして何かの機能を利用する |
| ファシリテーター | 特定課題を解決するための支援や補佐 |
- インタラクションをあらかじめ形式化することで、チーム間で期待されるインターフェースを明確にできる
- コラボレーションは認知負荷が高くコミュニケーションが大量になる、その代わり素早く課題を解決する上で大きな推進力を得られる
- 約束理論：強制ではなく、セマンティックバージョニングの各数値が示すような約束事によって成り立つ関係性
- チームやインタラクションは固定すべきでない、自分たちの今の目的は何か？期待される速度は？を常に考えチームに反映する必要がある
- 特定のワークフローは特定の個人に割り当てられがちだが、分かっているのは誰かを軸に計画を設計すると作業フロー全体に悪影響がある
- 理想を言えばチームから見た外部依存を減らしたい、たとえば QA チームを作るとそこがサイロ化し、すべてのチームが QA チームを待たなければいけない状況になりがち
感想
ストリームアラインドチームという形で責任範囲を一気通貫させつつ、認知負荷を下げるというのが最初よく分からなかった。 おそらく、その分だけドメインを限定する（ストリームアラインドチームとしての責務定義）、技術領域を分割する（コンプリケイテッド・サブシステムチームへの委譲）ことを意識すべし、ということだと理解した。
インタラクションを命名するという考えは初めてだったが、それによりチーム同士の期待値（インターフェース）を明確にするというのは腑に落ちた。 現職でチームビルディングを考える際も、最低限相互に何を期待するか、どんな情報を同期するのか、という点を重視しながら検討を行っているため、ここに繋がるものを感じた。
QA チームの例は前職でも非常に感じたことだが、一方で各チームにアサインするほどメンバーがいないというのもあり、兼任する分いかに負荷を下げられるかという点が課題ではないかなと感じた。
転職するのでお仕事を振り返る
本日が現職最終日なので雑に振り返りをしておく。
株式会社ドリコムではちょうど5年半働かせてもらった。 細かいものを除けば3チームほど所属し、ソーシャルゲームのクライアント、Unity SDK の開発、などの業務を担当した。
自分は前の会社を1ヶ月ほどで辞めた過去があり、ここでは絶対にちゃんと実績を残すぞという背水の陣みたいな想いがあった。
技術スタック
ざっと思い出すのはこのあたり。 歴史あるアプリが多かったので多少古いフレームワークもあった。 Ruby は学生時代から使っているので自分用のスクリプトはだいたいそれで書いた。 めんどくさい手作業を避けたくて Electron によるツール開発などもやったりした。（知人にドヤったらめっちゃ便利ツールに拡張された）
ソーシャルゲームのクライアント
元々ゲームを希望していたのでアサインされた。 壮絶な既存コードではあったが、1個1個読み解いた。 同時押しするとフリーズする、など代々伝わるバグの原因究明などもやった。 複雑すぎてもう直せないと言われていたコードにも修正を入れた。 既存とルールの異なる新バトルの開発、なども仕切った。
この頃はスキルアップのための試行錯誤も多かった。 見積もり精度を上げるために徹底して作業を時間計測をしたり、手戻りを起こさないよう実装をとにかく後回しにして事前調査をやったり、世にある設計を勉強したり。 このあたりの経験は今も生きている。と思う。
開発はスクラムではない何かで管理されていたが、今考えれば大人数の割にはきれいにまわせていたと思う。 チームの IP 愛も高く良いチームだった。 途中からはクライアントリードも任され、自分なりには上手いことやっていたと思っていた。 が、今思えば、もっと「チーム」に対していい影響を与える動きを期待されていたんだろうなと気づいた。
Unity SDK の開発
少人数の新規開発チームだったので、それまでのゲーム運営とはだいぶ体感が異なっていた。 プロダクトのためになるなら割と何をやっても許される文化があり、やるべきことは自分で見つけることが期待されていた。 めちゃくちゃ自発的に動いていたし、結果として趣味の勉強と業務が混ざり土日もずっと何かをやっていた記憶がある。 正直自分には縁が無いと思っていた社外登壇や技術書の執筆もこの時期に行った。
途中からは多少チームが大きくなったことで、以前から興味のあったマネジメントも本格的にやり出した。 いろいろ考えて設計した開発フローがだいたいスクラムと一緒だと気づき、既存フレームワークの力を感じた。 メンバーのことやチームのことを考えながら自分で手を動かす大変さを知り、プレイングマネージャーだった上司たちの凄さも思い知った。 マネジメントが性に合っているとは感じるが、手を動かさなくなるのは思ったよりやりづらかったので、少なくとも直近は隙あらばコードを書くという姿勢を続けたいと思う。
次の話
IRIAM (イリアム) | あなたらしいキャラで、おしゃべりしよう！
次は「キャラクターによるライブ配信アプリ」でお仕事させていただくことになっている。 以前の同僚がここや同業他社にいるのを複数観測しており、非ゲームなもののだいぶ地続きなのを感じる。
業務は Unity とマネジメントという自分が興味ある二つをやれるので非常にありがたい。 と言いながらも、マネジメントやってくれぇ！圧を非常に感じているので、まずはそっちで成果を出し、そこを起点にしてより面白い業務につなげていきたいと思う。
