yigarashiのブログ

学んだことや考えていることを書きます

webextension-polyfill-tsの型定義の自動生成がバグっていたので直した

Fix type generation for WebExtensionManifest.commands by yigarashi-9 · Pull Request #66 · Lusito/webextension-polyfill-ts

珍しくOSS活動をしたので簡単に報告記事を書く。

問題

最近ブラウザ拡張をよく触っている。同僚がmanifest.jsonをTypeScriptから生成できる良い仕組みを整えてくれており、自分も元気に開発を進めたのだが、どうにも型が合わない。最初は型がついたおかげでミスが静的に検出されていいな〜と眺めていたのだけど、よくよく調べるとどうも型定義が間違っている。具体的にはmanifest.d.tsの以下の箇所。

        commands?: WebExtensionManifestCommandsType;
    interface WebExtensionManifestCommandsType {
        /**
         * Optional.
         */
        suggested_key?: WebExtensionManifestCommandsSuggestedKeyType;

        /**
         * Optional.
         */
        description?: string;
    }

MDNのドキュメントにあるように、commandsは任意のkeyでcommand名を指定しつつ、ショートカットキーの設定を与えることになっている。しかし型定義のほうは、commandsに直接ショートカットキーの設定を与える形になっていて誤っている。commandsはRecord<string, WebExtensionManifestCommandsType>といった型になっていると良さそうに見える。

解決

型定義を1行直したら解決と思いきやそうではない。MozillaはWebExtensions APIJSON SchemaライクなAPI Schemaで定義している。今回使っているwebextension-polyfill-tsは、そのAPI Schemaから型定義を自動生成している。今回の問題はその自動生成プロセスのバグによるものであった。

具体的には、API Schemaに対する前処理として、別ファイルでextendしているものをひとつにまとめ(上の例ではmanifest.d.tsの単位でまとめている)、その上で入れ子になっている定義を分割する(上の例だとWebExtensionManifestCommandsTypeのような分割)のだが、その過程でobjectが入れ子構造になっている情報が潰れてしまっていた。

再帰処理の感じから一般のケースとして直すのが難しそうに見えたので、コーナーケースとしてobjectの入れ子を補う処理を加えて修正とした。半信半疑で修正を加えて型定義を再生成したところ、見事に問題の箇所だけdiffができて直ったので自己肯定感がだいぶ高まった。

AWS ECSのログを無難に見られるようになるための覚え書き

自分が関わっているサービスが徐々にECSに移転している。CloudWatchログのコンソールやチームのドキュメントにあるawslogsコマンドをなんとなく使ってログを見ていたものの、不必要なログが混ざったりして困ることがあった。テクノロジー面のモチベーションが上がってきており、いい加減ちゃんと見られるようになろうということで、基礎概念やawslogsコマンドの使い方をザクっとまとめる。

基礎概念

  • ECS
    • タスク
      • タスク定義から生成される実行単位
      • 複数種類のコンテナをひとまとめにした実行単位を作れて、サイドカーのNginxをつけたりすることが多そう
    • サービス
      • 複数のタスクをデーモン化して動かすことをサポートする概念
      • タスク数を維持するためにスケジュールし直すといった機能もここについているっぽい
    • クラスター
      • Amazon ECS クラスターは、タスクまたはサービスの論理グループです。タスクとサービスは、クラスターに登録されているインフラストラクチャで実行されます

  • CloudWatch Logs

こんな感じなので、たとえばECSのサービスやクラスターごとにロググループがあり、そこにコンテナごとのログストリームがまとまっているといった構成が一般的になると思う。同僚がログストリームを階層的に整理する知見をまとめたりしていて参考になる。

ログの見方

CloudWatchログのコンソールで見る場合は、上の事柄が頭に入っていれば困ることはなさそう。ロググループ、ログストリームの順番で検索しつつ絞り込めるようなUIになっている。

CloudWatchログをCLIで見るためにawslogsというコマンドも作られている。ログを見たい場合は以下の形式になる。

$ awslogs get <log_group_name> <log_stream_name>

特にログストリーム名は正規表現による指定が可能なので、prefix-name/container-nameまでで絞り込んだりすれば、全てのタスクからログを集めてくるといった操作が簡単にできる。よく使いそうなオプションは以下。

  • -w watch
  • -G -S それぞれロググループ名とログストリーム名を表示から取り除く
  • -s -e ログを取得する期間の開始と終了を指定する
    • 絶対時間ではなく5mのような相対形式で指定できるのが手軽で良さそう
  • -f フィルターパターンによる絞り込み
    • JSONやtsvに対して高度なクエリを書くことができる

色々眺めて遊んでいたところ以下のようなエラーに遭遇することがあった。

The number of streams that match your pattern 'XXX' is 'NNN'. AWS API limits the number of streams you can filter by to 100.It might be helpful to you to not filter streams by any pattern and filter the output of awslogs.

どうやらロググループに紐づいているログストリームの数が多すぎてAPIの制限にひっかかっているということらしい。別の手段でフィルターせよと言われているが、フィルターパターンでコンテナを区別するのは難しそうだし、一旦ロググループの全てのログストリームを流してからgrepすると処理する量が多すぎて困ることもある。基本的にはログストリームのパターンマッチが効くようにロググループを設計しておくのが良さそうに見える。

まとめ

ECSとCloudWatchの基礎的なところを調査して、無難にログを見られるようになったと思う。最近はテクノロジー面のモチベーションが高まっているので、この調子で少しずつ解像度を上げていきたい。

はじめてのエンジニア1on1メンター

ピープルマネジメントの文脈でエンジニア同士のメンタリング制度を設置しているIT企業は多いと思います。自分が勤める会社も例に漏れず、1on1によるメンタリング制度があります。エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ でも整理したように、ピープルマネジメントの領域にも取り組んでいきたいと考えていたわけですが、9月ごろからメンティー2人を持つ機会に恵まれました。1on1やコーチングの経験はほとんどなく、同僚のキャリアに関わる責任の重さを思うと、なんらか知識や型を整えて臨むのが適切だろうと考えました。この記事では、はじめてのエンジニア1on1メンターをやっていくために学んだことや実践の様子をまとめてみようと思います。

座学編

スクラムマスターの文脈でコーチングは多少関わりがあるものの、やはり1on1によるメンタリングは初めての経験です。何はともあれ本を1冊読むことにしました。タイトル、目次、レビューなどの情報を参考にしつつ、良さそうだった実践!1on1ミーティング | 日経の本 日本経済新聞出版を購入しました。よくまとまっている本で、1on1の全体的な知識や、うまく腹落ちしていなかったコーチングの考え方を整理することができました。メンタリングはさまざまな流儀がありそうで、全てを鵜呑みにするのは注意というのを念頭に置きつつ、ひとまず以下に主要な学びをまとめてみます。本書では1on1のフェーズ別に様々なトピックが扱われているので、気になった方は読んでみることをお勧めします。新書サイズで手軽に読むことができます。

コーチングの考え方

1on1を通してメンティーの成長を加速させるには、内発的動機付けを促し「本気でそうしたい!」と思える情熱を引き出すことが重要で、それこそがコーチングであるとされています。メンティーの自問自答を支援し、メンティー自身が発見したメンティーにとって価値のある答えやアクション(もっとも筋が良いとは限らない)を大切にします。この部分を勘違いして、メンターが思う正解をメンティーに言わせるために誘導尋問をしてしまうと、たちまち1on1が窮屈になってしまいます。あくまで答えを見つけるのはメンティー本人で、メンターの役割は、そのために視野を広げる助けをしたり、話しやすい環境をセットすることです。これらは中長期的な経験学習のプロセスで、緊急性の高い問題の解決には向いていないということも補足されています。

確かに、自分自身が"ノっている"時を振り返ってみると、誰に言われるでもなく「次はこうしたらうまくいくのではないか」というアイディアがあり、それがうまくいくと信じられるような状態であったと感じます。メンティーをそういった状態に導き加速させる技術がコーチングだと整理すると、自分の振る舞いや問いかけも上手く組み立てられるように思います。

メンターの具体的な振る舞い

まずは自由に喋ってもらえる環境を作る必要があるので、信頼関係を構築し、心理的安全性を確保する必要があります。そのためには、プライベートや弱みといった人間的な側面を開示したり、徹底した傾聴の姿勢を示したり、存在承認を与えるような受け答えをするといったトピックが紹介されています。特に存在承認を与えるような受け答えは難しく、考え方を大きく変える必要があるように感じました。例えば、褒めたり否定したりといったメンターの価値基準でジャッジする言葉は避け、事実を肯定的に評価することで、メンターの顔色を気にせず振る舞えるようになるのだといいます。例えば目標値の80%までしか達成できなかったメンティーに対して、「達成できなかったのは残念だ」と声をかけるのは良くなく、「80%は達成できて、あと20%の伸び代がありますね」などと声をかけられるのが良いようです。

話してもらえる環境を整備できたら、次はメンティーの自問自答を加速させる問いかけが重要になってきます。ひとりではたどり着けない考え方や視点にメンティーを導きます。本書ではそうしたテクニックも数多く紹介されていますが、特に印象に残ったのは目的論型のアプローチです。問題解決に慣れていると、ついつい「原因は?」「次のアクションは?」と考えてしまいがちですが、それらは原因論的なアプローチで、人のモチベーションを導く上では相性が悪いのだそうです。それよりも、「何があった?」「どうなってると嬉しい?」というように、現状の分析や目標の整理を前向きに行えるような問いかけが望ましいようです。確かに、自問自答を促して内発的な動機を高めたり、存在承認を与えたりといった方向性にも合致しており、納得できる考え方だと思いました。

実践編

ひとまず良さそうな本を読んだので早速実践です。

1on1で目指す状態

最初の1on1を迎えるにあたって、まずは1on1を通して目指す状態を自分の言葉で整理してみることにしました。何のためにやっているのか腹落ちしなければ、信頼関係を構築するのも困難でしょうし、1on1自体を改善していくのも難しいと考えたからです。上にまとめたコーチングの考え方や自分が"ノっている"状態を思い返して、以下を1on1で目指す状態として定めました。

(メンティー)さんが、自分や組織の将来、次のアクションに期待が持てて、生き生きと仕事に取り組めている。その結果、知識、経験を着実につけて成長できている。

もっとも重要だと考えているのは、参考書でも中心に据えられていた「生き生きと仕事に取り組めている」の部分です。具体的には、内発的動機付けに成功して、自己効力感があり、価値のあることに取り組んでいると信じられる状態だと考えます。よく言われる「月曜日が来るのが楽しみ」といった状態に近いです。そうした認識を一段階具体化して共有するために「自分や組織の将来、次のアクションに期待が持てて」という表現を加えました。そして、このようなポジティブなフィードバックループを構築すれば、方向性の調整といったサポートでメンティーは自ずと成長できるだろうと考え「その結果、知識、経験を着実につけて成長できている」としました。「成長」が最初に来るのではなく、「生き生きとした状態を作ることで気づかないうちに成長する」を目指すのがイチオシポイントです。

目指す状態に向けた戦術

上で述べたような状態に至るために、以下のように大きく分けて2つの戦術を設定しました。

  • 緊急度の高い障害物に対しては、高速に排除できるように動きます
    • 例: 心身の不調
      • 「いまいちやる気が出ない」も立派な不調
    • 例: 組織的な問題
      • やりたい仕事を任せてもらえない
  • 重要なテーマに対しては、じっくりと様々な視点を提供します
    • テーマ集
      • 最近うまくいった/うまくいかなかった仕事の分析
      • 次の評価でどうなると嬉しいか
      • 1年後/3年後/5年後どうなると嬉しいか
      • どんな知識、経験を積みたいか
      • どんなふうに働きたいか

まず、成長とか内発的動機付けだとか色々言っているものの、心身の不調や生活の事情でそれどころではない状態に陥ることはたくさんあるでしょう。そんな時に「1年後はどうなっていたいですか?」などと聞かれても勘弁してくれと思うばかりです。また、そういった障害物とコーチング技術の相性が悪いのも学んだ通りです。そこで「緊急度の高い障害物に対しては、高速に排除できるように動きます」として、目下の困り事をメンターがパワーでどうにかするコーナーを最初に置くことにしました。そうして足場を綺麗にしていくことで、少しずつ未来のことを考えやすい環境を作れたら良いと考えました。

そうしてメンティーが普通に元気に働いている状態になって初めて、1on1で目指す状態に向けて積極的に働きかけます。「重要なテーマに対しては、じっくりと様々な視点を提供します」として、目的論的なアプローチで現状〜近い未来について考えられそうなテーマを用意してみました。このコーナーでは、メンターはほとんどしゃべらないくらいのつもりで、メンティーが思考を深める助けをします。

実際にやってみて

なんとか自分の言葉で目的と戦術を整理し、実際に1on1をスタートしました。メンティーは2人とも同じチームのメンバーなので、信頼関係はある程度構築されています。目的を伝え、コンテンツを順番にみていくという形で、今のところ無難に30分/隔週で1on1を行えていると思います。しかし、話題をうまく提供できないとか、メンティーの話を聞くので精一杯でコーチングの技術を適用できないとか、当たり前の難しさには直面しています。ここからは地道な積み重ねだと思うので、最初の学びを土台に、丁寧な準備や継続的な学習で1on1の質を向上していきたいと思います。

まとめ

この記事では、エンジニアリングマネージャーを目指す若者が、はじめてのエンジニア1on1メンターに臨む様子をまとめました。座学編では良さそうな本を1冊ピックアップし、コーチングの考え方や具体的な振る舞いのポイントを学びました。スクラムマスターとしての振る舞いにも応用できる知見が多く、読んでよかったと思います。実践編では、実際に1on1に臨む上で、1on1で目指す状態とそのための戦術を自分の言葉で整理しました。実際に開催できている1on1と目指す状態にはまだまだ大きなギャップがありますが、ピープルマネジメントの最初の一歩として足場を固めることができたと思います。これから10年20年とやっていく仕事になると思うので、焦らずやっていこうと思います。

エンジニアリングマネージャーを目指す若者の戦略

企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」(以降EM)と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。

EMについての理解

エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiitaがよくまとまっており、自分の周囲でもよく参照されています。主な戦場は以下の4つのマネジメント領域とされています。

こうした見地からチームが生み出す価値を大きくすることに責任を負います。その上で、専門職チームでテクノロジーとピープルの軸を中心にカバーするEMを「弱いEM」、ミッションチームで全ての軸をカバーするEMを「強いEM」と整理されています。この記事では、自分の環境も踏まえて「強いEM」を自分が目指すEM像として考えます。

それぞれのマネジメント領域についてはエンジニアリングマネージャーになる前に知りたかった考え方 - Qiitaの「マネジメントの4分野」が非常によくまとまっています。

テクノロジーマネジメントは一般にテックリードやアーキテクトと呼ばれる人がカバーする範囲と考えるとそれほどズレはないでしょう。サービスのアーキテクチャ、技術選択、開発手法、SREing、品質といった話題があります。後述するプロダクトマネジメントと重なる領域として、技術的負債のコントロールも重要な観点です。

プロジェクトマネジメントは締め切りに間に合わせるという視点になりがちですが、現代ではデリバリーマネジメントと言い換えた方が非プロジェクト型の開発体制のマネジメント(例えばスクラム運営)まで包含できて適切であるように思います。プロダクトオーナーが実現したいものを、適切な品質で、できるだけ早く、予測可能な形でリリースすることに注力する領域であると認識しています。

ピープルマネジメントはそのまま人のマネジメントで、チームマネジメントや、メンバーの育成・評価・採用がスコープになります。ここがEMの主務であるように語られることもありますが、Engineering Managerをエンジニアのマネージャーとするのはやめませんか? - Unknown Errorなどで述べられているように、EMはあくまでボトルネックに注力する役割で、ピープルマネジメントはツールのひとつであるという理解をするのが重要なようです。とはいえ、専門職チームにおける「弱いEM」として職務が設置された場合には実質的に主務になることが多いでしょうし、それが特段ネガティブなことだとは思いません。メンバーの成長を支援するのも面白い仕事だと思います。

プロダクトマネジメントは「何をつくるか」をマネジメントする領域ですが、4つの軸の中では最も取り扱いが難しい領域だと個人的には思います。プロダクトマネージャーないしプロダクトオーナーとしても振る舞えることが理想ですが、方法不確実性も目的不確実性も全部ひとりで乗りこなしてプロダクトをリードするのは、ごく一部のスーパースターだけが可能な離れ業と感じます。EMの現実的な関わり方としては、エンジニアリングマネージャのスキル習得 - Qiitaの「プロダクトマネジメント x エンジニアリング」が納得感があります。あくまでエンジニアとして、施策の実現可能性や費用対効果を明らかにすることで「何をつくるか」の判断を支援するという考え方です。

なぜEMを目指すのか

大学でコンピューターサイエンスを学び、Webアプリケーションエンジニアとして採用された自分が、なぜキャリアのこんなに早い段階でEMを目指すのか。ステレオタイプなソフトウェアエンジニアの感覚からすると珍しく映るかもしれません。しかし、この2年半で自分が強みを発揮したり喜びを感じた場面を思い返すと、やはりEMという職務はとても魅力的です。

テクノロジー面は言うまでもないでしょう。新しい技術を使う楽しさ、難しい要件を綺麗に実装する喜び、過去の実装にしっぺ返しをくらって試行錯誤をする楽しさ、様々な良さがあります。デリバリーマネジメントでは、締め切りの厳しい大規模開発におけるプロジェクト管理や、現チームでのスクラム運営のリードなど、多くの人と関わり成果を挙げる面白さを知りました。ピープルマネジメントでは、インターンでメンターをした人が入社し活躍した時の喜び、ふりかえり改善コーチとして他のチームを良い方向へ導けたときの達成感など、他の仕事とは違う独特の喜びがあることを知りました。プロダクトマネジメントでは、データ基盤を整備することによってチームの価値判断が改善する様子を目の当たりにし、ユーザーに届く価値が直接的に向上するやりがいを知りました。

こうした体験を通して、テクノロジーだけでなく、ソフトウェア開発で直面するあらゆる問題が面白いという印象を持ちました。またテックスキルと非テックスキルの狭間になぜか自分がうまく立ち回れる領域が広がっているという感触も得つつあります。EMという職務は今のそうした自分の志向によくフィットすると感じます。EMは、時には自ら手を動かし、時には人の手を借り、チームが4つのマネジメント領域をカバーできるようにリードします。ある意味では、ソフトウェア開発におけるあらゆる問題を「解決してよい」立場であるとも考えられます。多くの人と関わり成果を挙げてもらえるように支援し、多様な問題にアタックできる、非常に充実した職務だと思います。

EMを目指す戦略

「EMを目指す」と言った時、ふたつの側面があるように思います。ひとつは会社にEMというポジションがあってそれに指名されることを目指す。もうひとつは、自他ともにEMと認められる知識・経験・スキルを身につけることを目指すというものです。前者は環境要因もあり、ある意味では後者の結果に過ぎないので、あまり重要視しません。大事なのは後者であると考えます。以下では、EMに足る能力を身につけるための自分なりの戦略をまとめてみます。

まずは4軸の中での大きな方針を決める必要があります。時間も元気も有限なので、全部の軸を完璧にというわけにはいきません。いちアプリケーションエンジニアからのスタートであること、EMが特に方法不確実性の領域に責任を負うことを踏まえて、以下のように優先度をつけて取り組もうと考えています。

テクノロジーマネジメントではいわゆるテックリード級の実力を目指します。サービスのテクノロジー面を任せられる実装力と経験、脳内インデックスの豊かさが求められると考えています。基盤への投資を計画したり技術的負債について正しく説明するために欠かせない能力です。プロダクトマネジメントを高いレベルで行うためにも必要です。またピープルマネジメントを行う上でも、多様なエンジニアの育成を良い形で行ったり、エンジニアからの信頼を得るのに高い技術力はポジティブに働くはずです。仕事で色々なタスクを取りに行って場数を踏む、社内勉強会などを通してトレンドを見極めながら索引を広げていくといった地道な活動を続けて少しずつレベルアップしようと思います。チャンスがあればテックリードをやりたいという意思を各所にばら撒いて成長のチャンスを呼び込む努力が必要かもしれません。

デリバリーマネジメントでは、締め切りのある状況を健全に保つプロジェクト管理と、非プロジェクト型のイテレーティブな開発の管理のふたつを中心に置いてスキルアップを目指しています。このふたつがわかっていれば大抵の状況には対処できるはずです。教科書的な知識のインプットと、それを現実の状況に適用する経験をバランスよく積んでいきたいものです。この領域は床に落ちて転がっているボールが多く、腹を決めてボールを拾いにいくだけで経験値を稼ぎ放題なので、自分の元気と相談しながら頑張ろうと思います。

ピープルマネジメントは現段階では優先度が下がります。なぜならまだ評価や育成、採用の責任を負っていないためです(決してピープルマネジメントをナメているわけではありません)。今のところは、メンタリングやコーチングの機会があれば積極的に手を挙げる、ピープルマネジメントもやっていきたいと主張する、自分がコーチングされる時に相手がどういうワザを使っているか意識する、といった行動を少しずつ起こしています。将来的に採用にも関わることを考えると、テクノロジーやデリバリーの軸で人脈を広げ界隈でのプレゼンスを向上させることもある種のピープルマネジメントと言えるかもしれません。

プロダクトマネジメントはさらに優先度が下がります。基本的には、テクノロジーマネジメントの方面から攻めて、施策の実現性・費用対効果を高いレベルで説明できるようになることが勝手にプロダクトマネジメントにつながると考えています。また、具体的な企画立案や仮説検証のプロセスはプロダクトマネージャーと分業が可能と考えています。とはいえ、プロダクトマネジメントから一歩距離を置いているのは単に自分の興味が薄いことが一因としてあり、違う意見の人もいるだろうし自分も将来的に意見が変わる可能性があると思います。現状は、データ駆動な仮説検証といった現代的なプロダクト開発の作法をつまみ食いする程度で、他の領域に力を入れようとしています。

こうして優先度をつけて取り組むにしても、究極的には全部やっていくぞ!ということなので、とにかく器用貧乏に陥ることは避けなければいけません。マネジメントができる程度の深さと広さでバランスよく育っていく必要があります。簡単な道ではありませんが、常に目の前の課題を楽しみながら、元気に暮らしていければと思っています。

おわりに

この記事では、まず現時点でのエンジニアリングマネージャーという職務に関する理解をまとめました。その上で、なぜ自分がその職務に魅力を感じるかを説明しました。これらのパートを通して、EMという職務の内容や魅力が少しでも伝わればと思います。さらに、それを踏まえてどうやってEMに足る能力をつけようとしているかを整理しました。似たような境遇にいる人の参考になれば嬉しいです。

チームが大きくなったらふりかえりをどうしたらよいのか

どうしたら良いんでしょうね。大きくなったら、というのは15〜20人くらいを想定しています。絶賛困っているので論点を整理するために考えていることを書き出してみます。

何に困っているか

  • 素朴に1グループで会話すると発話できる人が減る
  • 話題のスコープが多様すぎる
    • ある話題に関係ない人が常に一定数いる状態になる
    • 特定の話題を継続的にトラックすることが難しくなる

ざっくりとはこんな感じです。だったらチームを分けたら良いじゃんとなるわけですが一筋縄ではいきません。

  • 適当にグループ分けをするとトピックに詳しい人が揃わず会話が浅くなる
    • 発話人数は増えるのでアクティビティとしての価値は増加する
  • 適切な分け方を模索すると職能横断なフィーチャー?チームの軸と職種の軸があり困る
    • 職能横断なチームで分けるとデザイナーが分かれる必要があって職種のふりかえりができないといったことが起こる
    • 両方やったら良いと言い出すとチーム内にふりかえり会が片手に収まらないくらいに乱立する

問題を整理する

上で述べた問題は以下の2点に整理できるように思います。

ひとつはどんな課題を解決したいかということです。具体的には、改善したいのがチーム全体のプロダクト作りなのか、もっと小さいチームのプロセスなのか、職種ごとの課題なのかといったことです。チーム内に意味のある部分集合が増えるほど、取り扱いたい問題の種類も増えるので難しくなります。

もうひとつはどうやって課題を解決したいかということです。

  • 一部のリーダーが話してとにかく最短距離の解を得る v.s. チームの問題解決能力を高める
  • 単発で障害物を取り除き続ける v.s. 改善の様子をトラックして成長する

このような軸があるように思います。

じゃあどうするか

まずひとつめのポイントについては、チームの規模に比例して部分集合が増えるのはどうしようもないので、優先度をつけて必要なだけやるしかない気がしてきています。話題が増えているのにひとつの会でどうにかしようというのはどう考えても無理筋です。

ふたつめの話題については、ひとつの会で全てを得ようとしないのが良さそうです。ひとつめのポイントに対するアプローチから自然に大小いくつかのふりかえり会が生まれるはずなので、それぞれで別の解決方針を採用することができます。特に小さいチームでは、自己組織化をし問題を継続トラックするのが容易です。逆に大きなチームはリーダーが集まってくるので、最短距離で上がってきた課題を解決し続けるのが向いていそうです(よく考えたらリーダーだけでふりかえりをやったら良いのでは?)。

まとめ

書いていたら少し考えがまとまって、それらしい次の手を思いつくことができました。大きいチームのふりかえり設計に関する知見があればぜひ教えてください。