ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

勉強会参加メモ - Workers Tech Talks #1

https://workers-tech.connpass.com/event/287490/

GraphQL Server on Edge

speakerdeck.com

  • GraphQL server をコンテナでやるとして、初手 Cloudrun を選ぶとして、
  • cloudfrare workers という選択肢
  • 許容しなければならないこと
  • gcp 主体から cloudfrare 主体に書き換えることができた
  • (kysely, SQL builder. schema から型を生成する. DB migration のために prisma と合わせて使う)
  • メリット
    • デプロイが8分から1分
    • コールドスタート 5秒から200ミリ
    • コンピュータリソースあたりの単価は高め(起動時間が減ることで結果的にサーバ費用は1/10に減ったとのこと)
  • デメリット
    • nodejsが必要な場合は別途サービス作らないといけない
    • tcp はリクエスト処理しているときだけ接続可能
  • まとめ
    • API サーバとしては実用的な状況
    • cloud frareにロックインするが、メリットはある
  • ユースケースを見極めれば十分に使えるという事例だった

Gyazo の素朴な Workers

scrapbox.io

  • Gyazo のユーザは北米に多いので gcp us-central に origin
  • 素朴だけど明日から真似できる例として発表
  • 画像をキャプチャ、画像は png として url でアクセスできるが、
    • 再度アクセスすると上に gyazo と表示される
  • 解決したい課題
    • 画像直リンシェアされると gyazo.com に辿り着けない
  • Cloudfalre proxy を CDN として使う
    • 「人間が見てそう」なら画像バイナリの代わりに html を返す
  • 100行ぐらいの素朴な実装
  • cloudfrare worker proxy mode で使えるなら簡単に使える
  • 従来アーキテクチャでの nginx/lua で持っていた logic をなくせるのはメリットとして大きそうだった

Cloudflare Workers + R2で低コストで画像配信を移行した話

speakerdeck.com

  • Cloudfront + S3 に対するソリューションの1つとして Cloudfrare Workers + R2 ケースの紹介
  • r2
    • s3互換
    • s3に劣る部分はある、当てはまらない場合は検討できる
      • IAM/トークン単位でのアクセス制御できない
      • バケットのバージョニングできない
      • S3 Glacier のようなストレージクラス概念ない
  • 円安でのコスト増加への対策
  • これまでの構成
    • cloudfrontの後ろにnginx、basic auth、s3の構成だった
  • そもそもr2配信でworkers必要？
    • public buckets機能がでたのでシンプルな配信なら不要
  • workers を使うとpath mappingなど複雑な処理がedgeでできる
  • キャッシュは？
    • kv を検討したが、従量課金でコストかかる
    • cache api を使った
  • コストより柔軟な画像リサイズなどやりたいなら cloudfrare imagesを使うと良い
  • 移行の際はトラフィック料金がシビア
    • s3とr2はダブルライトした
  • 他スピード早くメモが追いつかず。移行のtipsがめっちゃ詰まってた
  • ペインを移行によって解決できていてすごい
    • コスト削減含め

Server Side JavaScript のためのバンドル最適化

speakerdeck.com

  • (前提破壊)制限が5MBから10MBになった
  • サーバサイドでバンドルするメリット
    • 起動高速化
    • CI
    • セキュリティ
  • デメリット
    • sourcemap で複雑化
  • v8 isolate で120MBのメモリを割り当ててスクリプトを実行
    • chrome のタブ1つに相当
  • パフォーマンスバジェットという考え方
    • バンドルサイズの上限をチームで合意しようね

gRPC Client on Cloudfrare Workers

speakerdeck.com

  • gRPC を cf-worker で動かす事例

まとめ

Cloudfrare Workers が何かもわからない状態で行ったので豊富な事例を聞いて活用方法はいろいろあることがわかった

勉強会参加メモ - 【有料プランユーザー様限定×オフライン】MagicPodユーザーLT会

trident-qa.connpass.com

普通に会社名義で出たので会社ブログを書けという話だが、個人の学びとして他の人の発表で感じたことメモしておきたいので書く。

MagicPodでFlutterアプリをテストする

Flutter から遠い生活をしているので特に思ったことはないが、サポートできる Platform を増やすことは E2E Test SaaS ベンダーとしては重要だが、Flutter という Native から1段階 wrap しているものをサポートするのはかなり苦労があるんだなーと思った。

MagicPodで始める がんばらない回帰試験の自動化

speakerdeck.com

  • 自動化の導入コストは当然かかる
  • MagicPod のベストプラクティスは知らなかった
  • 実際に経験してみて自動化が難しいものとそうでないものを切り分けられたのは良い学びだと思う
  • kintone 普通に metrics を食わせて表示できるんだーってのがびっくり
    • 後の自分の発表言うことないな、ってなっちゃった
  • issue ちゃんと書いているの大事

『スタディサプリ 中学講座』における E2E Test の運用と計測による改善

所属チームのこれまでの軌跡が話されてよかった 合わせてブログ書きたい 「開発チームが自ら自動テストを書き、メンテしている。QA はサポート」というのはもっとアピールしたい。 質疑でも補足したけど tatto さんの丁寧なサポートと品質リードへのファシリテーション、そういった役割を踏まえて組織したマネジメントが合わさって成し遂げられていることだと思う

自分の資料はこっち

speakerdeck.com

github.com

「計測されていると、改善したくなる」が一番言いたかったことかもしれない。

あと Web だからか、E2E が15分ってめっちゃ短いほうなのね、ってわかったw

そういえば Duration seconds 的なのも　API で取れると嬉しいと言う話をして issue を書いてもらった。

github.com

みてねの安定リリースを支えるMagicPod活用状況

speakerdeck.com

  • QA からはじめて開発チームに認知が広がったのはいい話
  • 共有ステップを使いこなすのすごいと思うけど、副作用もあると思った
    • 共有ステップの管理とその周知はどうやっているのだろう
    • QA チームが少人数だとコミュニケーションでうまくやれるのかもしれない

高い開発生産性を実現するために取り組んだMagicPodの利活用

speakerdeck.com

  • 実行方法の整理は見事で、特にデプロイ前と定期実行でテストケースを分けている点は見習える点があるなと思った
  • Jimbo さんと懇親会でも話したけど、デプロイ前はマジで重大障害につながるクリティカルなところだけにすることで、開発速度を止めない
    • 逆にそれ以外定期実行の「最悪3時間」で気づけるものはデプロイブロックしない、というのは言うは易しというか、うまく問題起こさずにできているのはすごいと思う
    • CI で PR マージ前実行でも5分ならまぁ我慢できるなと思う

自動テストを社内へ浸透させた話

speakerdeck.com

  • 手動テストと自動テストをどう棲み分けるのか、そのガイドなり考え方なりを発信するのは大事だと思う
    • 100% は無理
  • 特にレコチョクさんの扱うような音楽再生みたいな、メディアが関わるものは難しいですよね

まとめ

懇親会も楽しかったです。ありがとうございました。 発表させて、といって当日までつなげてくれたコミュニティマネージャの田上さん、懇親会で会話させていただいた伊藤 CEO 他みなさんありがとうございました。

引き続きよろしくお願いします。何かあったら Issue 書きます。

勉強会参加メモ - 開発生産性 Conference

dev-productivity-con.findy-code.io

From Metrics to Mastery: Improving Performance with DORA and the SPACE Framework

  • SPACE フレームワークはかなり有益だと思った
  • あらゆる metrics・評価指標自体の評価ができるメタフレームワーク
  • DORA のページがある DORA | DevOps Research and Assessment
  • SPACE Framework
    • S: Satisfaction and well-being
    • P: Performance
    • A: Activity
    • C: Communication and collaboration
    • E: Effectivity and flow
  • 多面的に評価できるので、トレードオフを考えられるので良い
  • 特に flow に入れるかどうかは satisfaction にも影響を与えると思う
  • 計測方法はヒアリングしかないなーと思うのでここをうまくやりたい

組織をスケールさせるためのFour Keysとチームトポロジー

speakerdeck.com

  • 適切な摂理面の探索、どうすればいいんでしょうねぇ
    • バリューチェーンでわけても上流下流が密に影響する場合そこで分けられないのはそうだと思う
    • 戦略的にモノリスにしているのは賢いと思う
  • ダブルループ学習を推奨するのは良さそう
    • 結局やって学んでいくしかない

なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜

speakerdeck.com

  • 発表が上手だった
  • 資料もわかりやすい、参考にしたい
    • 伝えたいことが1スライドで明確
    • 文字だけでなくアイコンは図を使っている
  • 0から最終的にオーナーシップを渡せるまでの旅路が描かれていた、これからやる人は参考にできそう
  • 各メトリクスはつながっているの、そうなんですよね

The Metrics Key: Connecting Product, System, Team

speakerdeck.com

  • 1番聞けてよかったセッション
  • DMM さんは組織規模的にも先を行っているので参考にしている
  • 基本の基本で「計測」かなりちゃんとしていおる印象、ここまでできてないなぁと反省
    • 工数、予算、品質の観点で調査していてすごい
  • "「不確実性が高い」という言葉を計画、計測、学習を適切に行なっていない言い訳にしない” 肝に銘じます
    • 可観測性と再現性を作る、100回言いたい
  • Metrics の整理が素晴らしかった
    • 事業、プロダクト、システム、チーム
    • 事業、システム、組織、という整理を自分でしていたが、プロダクト軸と、それぞれの指標例が載っていてありがた
  • 有効稼働率を計測しているのは驚いた、できる気がしない。..
    • 勤怠管理ツールと接続するとは。..

これからのソフトウェア開発 "GitHub x AI" による生産性革命

copillot X は相当便利だなーと思った 早く使いたい。

行政府の開発生産性向上のアプローチと、目指す未来

各自治体で分かれている中で　DX を進めていくのは並大抵のことではない、尊敬の念です。

大規模言語モデル時代の開発生産性

資料だけ見ました。素晴らしかった。

speakerdeck.com

  • 開発生産性の3つのレベルと組織の関係 p19 がわかりやすい
    • 開発部の目標、事業の目標はわけて考えないといけない
  • p24 もわかりやすい
    • Engineering Manager, Product Manager, Sales/Maketing Manager の役割がよくわかる
    • GP = Gross Productivity
  • p34 定性目標、定量目標、「健全化指標」という整理もよかった
  • AI 時代に関連すると、AI エージェントが何をし、人間が何をやるのかを理解して取り組む必要がある
    • 実際にツールを書いて検証していてすごい

まとめ

所属会社でもこの領域に取り組んでいるため良質なインプットを得られてよかった。 自分の取り組みを省みて、今後の方向性を考えたい。

勉強会参加メモ -【PLAID×NewsPicks共同開催】ABテストの理論と実践〜成果にコミットするプロダクト開発〜

uzabase-tech.connpass.com

参加した。ちょうど今年の2月からプロダクトエンハンスを A/B テストを活用するチームを立ち上げたばかりで関心の高いトピックだった。

中身も非常に学びが多く、開催してくれて本当に感謝。

動画も残っていて感謝。

www.youtube.com

ABテストのための統計的検定理論(序論)

統計的検定理論について理解が浅いままやっている（所属組織については専門のデータアナリストについてもらっている）ので、その入り口として非常にありがたかった。紹介された本も買ったのでこれから読む予定。

A/Bテスト実践ガイド　真のデータドリブンへ至る信用できる実験とは (アスキードワンゴ)

A/Bテスト実践ガイド　真のデータドリブンへ至る信用できる実験とは (アスキードワンゴ)

Amazon

サンプルサイズの決め方 (統計ライブラリー)

サンプルサイズの決め方 (統計ライブラリー)

Amazon

新装改訂版 現代数理統計学

新装改訂版 現代数理統計学

Amazon

最初に紹介されていたスライドはこれ。

blog.recruit.co.jp

  • ABテストとは
    • ABテストとは分析の一種である
    • 「分けて、比較する」が分析
  • AB テストの前提条件
    • どちらに割り振られるかはランダム
    • 片方に割り振られたらもう片方には割り振られない
    • 2つの群で同時に実施される
    • ABC テスト
      • うっ
  • AB テストの結果の見方
    • 量ではなく CVR をみていく
    • 棒グラフで出してもあまり意味がない、スケールを変えればどうとでも見れるので
    • 何をもって近い、遠いかを判断するには「統計的仮設検定」が必要になる
    • 「CVR の発生確率」を分布していく、重複が離れていくと有意と言える
  • 注意点
    • サンプルサイズを大きくすると、確率分布が尖る（幅が小さくなる）
    • サンプルサイズを大きくすると、小さな差でも有意になってくる
  • 統計的仮設検定の手順
    • ABの差が棄却域が有意水準より離れていれば棄却できる、と考える
    • 差があるといえる確率を検出力という

時間があったら話すことを聞きたかった！続編に期待。

120回分のABテスト結果を分析して見つけたアンチパターン/成果が出たパターン

約2年で120回、すごい。

  • 失敗事例から学ぶ
    • いつまでも終わらないABテスト
      • Android ではじめて、あとで iOS で適用すればいいのでは？ー>サンプル数が足りないのでいつまでも終わらない
      • わかる...
      • サンプル母数が少ないと改善サイクルが遅くなる
      • 人数が多いプラットフォームで先にやるべき
    • 差分が少ないテスト
      • これ難しいですね。差分が大きすぎるとどの要素が効いたかわからないという問題はありそう
      • あまりに些細すぎると、効果は出ないというのはありそう
  • 成功事例
    • 施策のタイミングを考える
      • ユーザが感情が動くタイミングでやる 　 * インストール直後の初期画面 -> プレミアムを訴求する
        • サブスク開始後に通知許諾を促す
        • 良さそう
    • 判断に必要な情報を整理して伝える
      • めちゃくちゃ大事。..
      • 結局いくらお得なのかを整理する、やりたい
      • 解約画面で訴求するのいい例だと思った
        • もしやめて、また入ると高くなるよ、ということを通知 　 * 値段だけじゃなくても解約防止のための情報を伝えるのは大事
  • サービスの種類や特性によって違う、それはそう
    • これが難しいし実験あるのみというところだなと思った
    • 実験サイクルを回し、学習量を増やすことが一番大事だと思った

Notionを軸にABテストを効率化する

Notion, 仕事では使っていないんだけど、データベースになるのでテンプレート + 結果の分析に役立つなーと思いました

A/B テスト自体のテンプレートは GitHub Issue Template を使っているけど、分析はそのまま使えないので確かになーと思った。

A/B テスト自体の分析ができるほど施策ができてないなーというところはぐぬぬとなりつつ、いずれ必要になるので考えておきたい。

AB テストの if 文の残留はタスクマネジメント上しっかり Issue 化しているので忘れずにできているなと思った。

ただ全体的に自動化の余地はあるので、Zapier 使うとか知見共有するよとかそういうのは真似していきたい。

質疑応答

  • KPI の分解についてはかなりできてないなと思った
    • 実際売上に近い、課金率を目標に取っている
    • 課金率を KPI ツリーに分解し、より近いところを目標していくことで高速にサイクルを回せるようになると思った

まとめ

  • A/B テストテーマの勉強会、めちゃくちゃありがたかった、またやりたい
  • 自分たちも発信できるようにしないとなーと思った、ブログ書こう。。。

入社してから5年

前回 https://blog.chaspy.me/entry/2022/12/24/120000

約半年ごとに書いている勤続(？)エントリー。ついに丸5年となった。

節目ということもあり、5年を振り返ってみる。

5年間を振り返る

1年目

2018/06-2019/05

とにかくパフォーマンスが出なかった。出なかった、というか、低かった、というのが正しい。求められる期待値と現在のギャップを正しく認知できず、間違った方向にがむしゃらで、パニックゾーンだった。

今でもたまに思い出す。辛い時期だった。

半年経ったころから Microservices Readiness な仕組みつくりをはじめたり、deis からの Platform 移行にともなう Kubernetes の勉強会や、起きる変更を文章にしたり、特別講習と呼ばれる live サービスのインフラを担当したりと、少しずつ自分ができることが増えてきた。

同時にオンボーディングカルチャーを WebDev と一緒になって醸成した。

ブログ筋があったおかげで、わかることもわからないことも文章にするスキルがこの時自分を助けてくれた。

SRE Lounge のコミュニティに顔を出したり、同僚と勉強会に行ったりの時間が癒しだった。

2年目

2019/06-2020/05

自分でできることも増えてきた。ユーザも増え、パフォーマンスの問題を顕在化してきた。MongoDB のスケールアップのための負荷試験をやったり、Kubernetes 上で HPA を導入したりしていたかな。

あとは SLO をやっていくんだ、と宣言して、最初は1人でコツコツと、それから開発チームと一緒に少しずつ。現れる技術的問題をクリアしながら"文化を作る"体験をしたのは自分にとって稀有な経験だった。

この時の体験は最善だったとは思わない。もうやらないし、もうやれないな、とも思う。しかし組織としての仕組みがない中で個人が1つのことを成し遂げることができる土壌そのものの尊さを感じたのを覚えている。

英語を真剣にやっていたのもこの時期だと思う。悔しい思いをたくさんした。嬉しい思いもたくさんした。現地に行って会話したこと、それがリモートであれ普段の仕事のしやすさにつながること、今、時代柄見直されていることだが、オフラインコミュケーションの重要さを実感した。

1番ハードに働いていたと思うし、でも夢中だった時期だと思う。

3年目

2020/06-2021/05

Lead Engineer というタイトルがついた。チームが前に進むためにできることを考えた。とにかく考え尽くした。

言語の壁もあった。チームメンバーの価値観の違いもある。SRE チームの担当範囲の広さもある。難しかったが、この頃からメンバー全員と1on1をはじめて、課題解決に時間を割いた。

同時に IC として技術力の壁を1つ超えられたのもこの時期かこのちょっと前だったように思う。"技術力が課題"という言葉に、これ以上の解像度を持っていなかった。

しかしとにかくコードを書くことをミッションにしたり、"わからなさ"をわかることができた、この認知の変化によって自分が技術的に成し遂げられることが格段に変化した。

https://blog.chaspy.me/entry/2021/05/08/120000

Platform に関する大きな変更にもチャレンジした。company wide に影響する migration をサポートをもらいながら主体的に成し遂げられたのは自信につながった。

この頃から"エンジニアリングでビジネスに貢献したい"という気持ちが強くなってきていた。

4年目

2021/06-2022/05

この頃はマネジメントの割合が増えてきていた。もちろん OSS を書くなどコードを書く機会は増やしつつ、いかに組織の課題を fact をもとに解くのか、計測するのか。SRE は何を目指すべきなのかを考えていた。

そして10月からは EM になった。

この頃は組織全体の技術戦略にも関わることになり、視座が一段上がったように思う。そのことが SRE としての活動の幅を広げるにも役立った。

5年目

2022/06-2023/05

SRE だけでなく web チームのマネージャーも兼任することになり、マネジメントとしての難易度を一段上げた。

リクルートグループ入りしたこともあり、交流も増えた。大企業での泳ぎ方みたいなのはわりと適応能力があったみたいでなんとかなっている。

マネジメントをうまくやればやるほど、自分個人の成果が見えづらくなる、マネージャーあるあるだが、そういったことはあまり気にせず、自分の成長できる環境を自分で作っていけたと思う。

このときやりたかった Web 技術そのものを仕事でやることは残念ながらほとんどできていない。まぁ、複数グループ兼任してたらマネジメントだけで終わるのはそれはそうよね。

そのことが今後足枷になるのかはわからない。ただ、評価する立場としては技術との距離はこれ以上離れてはならないと思うので、1軍のコードは書かないまでも、2軍3軍のコードを書く、副業で書くなどして食らいつきたいし、自分自身も技術を楽しみたい。

今後

10月で SRE のマネージャーをやって2年である。2年で引退するつもりだったが、Web のマネージャーもはじめたため寿命が伸びた。

今自分が1番面白いと思うのは"Engineering Management"だ。これは文字通りであり、マネージャーという仕事が面白いとか、人と話すのが楽しいとかという側面ではなく、どのように技術をビジネスに活かすのか、ここにより直接的に関与できる立場にある。

変わらず国内と海外の両方のビジネスを支えていきたい。

国内については SRE と開発チーム両方見れる立場として、技術戦略をよりうまくなる、3年後5年後のサプリの未来を作ることに貢献したいし、それを主体的に行う Engineering Manager や Lead/Senior Engineer をサポートしたい。

海外についてはインフラ面でビジネスが継続できるようコストや開発生産性でサポートしていきたい。

外部コーチングを受けることで自分の強みはある程度わかってきた。広く見て、仕組みを作って、ひとりひとりの成長をサポートして、重要な課題について、レバレッジポイントを見つけて介入したい。そういうことを、もうしばらく今の組織でやる。

それ以外の個人的な興味だと、プロダクトエンハンスをA/Bテストをやって仮説検証をやるチームの検証サイクルを爆速にしたいと思っており、これを成し遂げるには超えるべき壁がたくさんあるので、自分が貢献できるポイントも多いと感じている。やっていきたい。

次の10月で Engineering Manager 3年目になる。引き続きよろしくお願いします。飲みに行きましょう。

エンジニアリングマネージャーの成果

なんかタイトルを一般化すればするほどブクマがつくことがわかった。これも十分一般的だが。

エンジニアリングマネージャーのしごと本には確かマネージャーの成果について、

  • マネージャーのアウトプット = 自分のチームのアウトプット + 影響を与えた他のチームのアウトプット

とかかれている。

さて、これについての自己評価、あるいは他者評価の難しさについて。

2つに分けて考える。

  1. 自分のチームのアウトプット
  2. 影響を与えた他のチームのアウトプット

まず、1から考える。マネージャーは目標に対する資源分配最適化の役割であるとする。チームのコミュニケーションがうまくいってないものを対話によってうまくいくようにしたり、個人の目標設定を変えたり、役割を変えたり、大小いろいろある。

その場合、ここで書かれてないことであるが、

  • 1-1 マネージャーが存在しなかった場合のチームの成果
  • 1-2 マネージャーがいたことで想定できる最大のチームの成果

現実はこの両者の間にチームのパフォーマンスが落ち着くと思われる。しかし、その期におけるチームの成果が想定通りか想定外かを計測することは難しい。よって評価も難しい。

しかし、例えば営業数値とか、製造の利益とかで出せるチームもあるだろう。内製開発チームにおいてそれはなんだろう。あるいは横断(プラットフォームチーム)だとなおさらなんだろう。

測ろうとすればするほどそれはハックできるわけで、なおさらマネージャーの評価、ないしチームの評価は難しい。

しかし、ただ1つ揺るがない評価は価値提供相手の定性評価である。SRE チームであれば開発チーム、開発チームであればプロダクトマネージャーからフィードバックをもらい、それもなるべく頻度高くもらうことで軌道修正できるようにしたい。

その上で事業を継続できる、投資がもらえる数値も共有して、同じ方向を向けるようにしたい。

難しいねーなんで難しいんだろって話を考えたかったんだけど目標設定が難しいorできてないからだねということがわかったので解決してしまった…。

2 についても同じ方法でフィードバックをもらうべきだろう。

所属組織では360フィードバックという、メンバー同士でフィードバックを送る営みがある。(評価には使わない)

それと同様に、チーム単位のピアフィードバックもすべきだと思うし、これはマネージャーの評価に使ってもいいと思う。

1人のトップマネジメント(VPoE)が各チーム個別あるいはマネージャーの評価ができないならば、評価できる仕組みを作るのがVPoEの仕事なんじゃないの、と思う。

多分、こういう営みそのものがマネージャーのマネジメント業務の理解を深めたり、マネージャのキャリアを作るのに役立つんだと思う。

余談ながら、最近個人でプロのコーチングを受けている。 自分の want to を特定する上で過去のエピソードや好きなワードなど出して深掘りするワークをしたのだが、その中で自分の好きなことに、「少しの労力で大きな成果が出ること」が好き、気持ち良い、という発見があった。

これはソフトウェアの世界でいう UNIX 哲学 Use software leverage to your advantage であるし、組織マネジメントにも同様の要素はあると感じている。

これだけ続いているということは、ソフトウェアの世界、マネジメントの世界、どちらも向いてるのだろうな、と思いつつ、Hazy Double IPA 作って自宅でタップで注いで飲みたいな、とも思う。

リーダーとマネージャの違い

最近見たいくつかのツイートが自分の考えとちょっとズレがあったので考えてみる。

見つけられなかったのだけど、

マネジメントは欠けている要素を増やす、リーダーは目標を決めてチームを前に進める、やることを減らす、なので本来真逆である、みたいなやつ。

こういうのもか。

僕はこれまで以下のような整理をしてきました。（これは最近できたチームでのリーダーとの期待値合わせに利用しました）

  • Manager:
    • 担当メンバーの評価、目標（ミッション）設定
    • 担当メンバーの健康・労働時間管理
    • チームの半年単位での目標設定、戦略策定（採用を含む）
    • チームの結果責任
  • Leader:
    • チームを前に進めるためにリードする
    • チームが前に進めない要素を取り除く
    • 内容例
      • 0->1 のチームビルディング
      • チームが意思決定することをサポートする
        • 決め方を決めるように推進する、観点や選択肢を提示する、問いかけによって気づきを与える、など
      • ステークホルダーとの折衝
      • 開発部内の他のチームとのやりとり

思えば、僕が認識している Manager は所属組織でのロールとしての業務が多いなと。

ここに書いてないが、確かに「チームに不足している要素を（人材育成なり、他のチームに協力依頼するなりして）持ってくる」という動きはしている。

資源配分という意味では「チームの戦略策定や目標設定」もそうだろう。

そしてリーダーがやることを減らす、という意味としては「前に進めない要素を取り除く」にマッチしていそうだ。

そう思うとあんまりズレはなかった気もするが

チームビジョンを策定し、それに向かってメンバーを鼓舞する

これは結構両方に混じるところだなぁと思った。「どこへ向かうのか」はマネージャがやると自分は思っている。「向かう先に対してメンバーを鼓舞する」はリーダーの役割で良いのだけれど。

向かう先を決める能力がチームに備わっていれば、マネージャは欠けている資源を調達する、のみになるかもしれないが、実際は組織の階層構造だとか評価制度などが絡んでこれはパッキリ分けられないのだと思う。同じ権限を持ったマネージャとリーダーがチームにいて、そういう役割分担をすると良さそうだと思った。

開発組織でのマネージャ同士の役割分担がこんなふうにできると便利かもな。リーダー的マネージャとマネージャ的マネージャ。