ツナワタリマイライフ

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

入社してから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 は所属組織でのロールとしての業務が多いなと。

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

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

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

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

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

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

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

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

正しいことを正しく言うのは難しい

人間の感情を配慮し尽くすのは難しい。確率を下げる努力はできても、完璧は無理だろう。

 

正しいことを誤って言ってしまうパターンは以下があるだろうか

- 関係性(信頼)の欠如: なんでお前に言われないといかんの？

- コンテキストの欠如: なんで今言うの？

- 期待値調整の欠如: お前何のためにここにいるの？

- 背景理解の欠如: 実はこういうことがあってですね

 

基本的にフィードバックが求められているときにすることであり、それ以外はしないにこしたことはない。求められてないアドバイスはクソバイスだからだ。

 

しかし、組織の生産性は噛み合わせが悪いと1つのことでも大きく劣化するし、最悪人が辞める。逆に言えば、たった1つのことで改善すると組織の生産性が大きく向上することもある。

 

ボトルネックの特定や、根本原因の見極め、問題の評価、という目線でいろんなことを見るようになった。それがマネジメントの仕事だとも思っていた。

 

それは正しいんだが、いかに正しいフィードバックでも届かなければ意味がないどころかマイナスの効果を引き起こしてしまう。

 

正しいフィードバックを見極める姿勢は続けつつ、次は"正しく届ける"ことを意識したい。

 

おそらく、目指すべきゴールはそんなフィードバックがなくてもチームや個人が自律的に課題を見つけられる世界なんだと思う。チームの中からの目線とチームの外からの目線のギャップをなるべく小さくしていきたい。

 

同じものを、同じように見るようにしていきたい。

SRE とプロダクト開発の EM を兼務して半年経った

3ヶ月前の振り返り

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

いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。

SRE

ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。

11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。

新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。

後半の Q4はリーダーが他のチームに留学したり、AWSのアカウント分割プロジェクトで手戻りが発生したりと不安定気味になったが、それについても留学時期を調整したり、リーダーが作戦変更を素早く意思決定し、段階的に変更を進めたり、開発チームとのインタラクションをコラボレーションモードに変更したりと素早く柔軟な軌道修正ができた点は良かった。

この期はアカウント分割プロジェクトを中心に、開発者との Relation を深く考えることができた期だと思う。これまでも開発者からフィードバックを得る、ということはテーマとして打ち出していたものの、具体的に依頼をいつどのようにしたら良いか、という点で学びが多かったし、その基本的な考え方も整理できた。

成果もかなり出ており、次の期でも引き続きやりたいトピックがたくさん出てきている。

次の期は僕が EM をやって4半期目である。(次の10月でちょうど2年)

僕が当時思い描いていたより遥かに遠いところにきていて、特にこの期はチームが格段に良くなった感覚がある。

僕がマネジメントとして成し遂げたことは数少ないが、意識していたことは、

  • メンバーがハイパフォーマンスを出せる環境

  • Teamとして不足している capability を獲得すること

  • Team としてそれを発見、実行できること

現状はこれが回りつつあり、少なくとも実務面ではマネージャ不要な状態にかなり近づいていると思う。(個人の成長支援として少なからずマネージャに残る役割はあると思っている)

チームがチームをセルフマネジメントしている状態、というのかな。

これには1人1人の技術力だけではなく、ソフトスキルも必要だし、何より同じ方向を向くことが大事で、これについてはビジョンミッションバリューを整理した前任マネージャの功績が大きい。僕はそのレールの上でさらにそこに向かうための改善サイクルを強化するための採用と目標設定を補助したに過ぎない。

引き続き"良い課題を発見する"ことを、SRE チームだけではなく、開発組織全体の技術戦略を通じて与えられるようにしていきたい。

Product Secriry Engineer については来期もう1人取りたい。頑張る。

プロダクト開発

B2Cプロダクトの WebDev のマネジメントをやりはじめた。まだ半年らしい。1年以上前からいる気がします、と言われることもある。よく分からないけど、半年も経てば慣れるもんである。

技術的には WebFrontend を触るようになって0から React を触れたのが良かった。楽しい。実際に軽微な改善、ドッグフーディングで見つけた改善はプロダクションに出した。

Native Team と関わるようになったのも新しい経験だった。どうしても SRE と Native は直接的な関連がなかった。お近づきの印に Jetpack compose の置き換えのリファクタもやらせてもらって、(最後はペアプロでおんぶに抱っこだったがw) 無事1コンポーネント本番に出せた。

インフラや監視面でも(それをしにきたわけではないとはいえ、持ってるスキルセットとして)身近に聞ける人ができた面でも貢献できたと思う。が、それを組織の capability として強化する、みたいなことはできなかった。

3Q でやっていた領域はビジネスの方針転換により縮小することになり、この組織変更には痛みが伴うものとなった。ビジネスの方針変更に対して開発組織はそれに合わせて変更する、それによる痛みは少なからずある、というのは理屈ではわかるが、我々人間、感情の生き物であり、そこはもっとうまくやれたところはあったと思う。(結果としてあの時あの時点では最良の選択をしたと思うが、もっと早く手をつけて回避できなかったのか、ということをたくさん考えた)

PLG チーム

Q4 からは体制変更に伴い、PLG - Product Led Growth チームが立ち上がり、そのチームの担当マネージャーに立候補した。チーム立ち上げのプロポーザル自体は別の EM が行い、まんま引き継いだ感じ。

Growth Enginering, プロダクトをプロダクトによって改善し、仮説検証をデータを元に繰り返していくチームだ。今は Android, Web 開発者が1人ずつと、PM が1人、EM が僕の4人の小さいチームだが、立ち上げは順調で既にいくつかの変更をだし、A/Bテストを行っている。

"事実に基づいて意思決定する" Fact based decision making は信頼性領域における SLI/SLO であり、それを事業指標とプロダクト指標で行うこととなんら変わりはない。分析基盤の構築をしながら、高速にサイクルを回して事業指標を改善していくことは僕が最もやりたかったことだった。次の半年はいよいよ成果を出す期である。楽しみだ。

マネジメントの課題

課題は明確である。

  • PM とのコミュニケーション、期待値調整、情報流通

  • 各チームが自立的に改善を繰り返すための組織設計、およびリーダーの育成やアサイン

1つ目については年明けからかなり状況は良くなっており、PM のマネジメントメンバーとの会話はかなり増えた。

みんな優秀でちゃんと話を聞いてくれる、話せばわかる人たちなのがありがたい。じゃあ話せばいいじゃん。話そう。それだけなのである。でもそれだけのことで結構うまくいかなくなるもんである。

2つ目は具体的に現在予定されてる新規プロダクトのリリース後の組織体制の検討がアウトプットになる。この意思決定については早めからありうる未来を考え、メンバーにフィードバックをもらいながら設計し、その設計意図や意思決定については ADR のように残したいと考えている。

3つ目として、技術戦略がある。(システム的な技術課題の解消、組織の技術力向上、ビジネス戦略を見越したシステムならアーキテクチャなど) が、ひとまず次の半年については大玉のリリースおよびチームの再構築によるチームビルディングと安定化が目先大事なので、それが落ち着いてきたら考えたい。

技術戦略

直前で言ったのとは別に、スタディサプリ小中高全体の技術戦略グループがある。このグループもなんと2年だそうだ。よく続いている。尊い。

兼務メンバーで成り立つこのグループは派手さはないものの、地味に成果を出しつつあり、組織としては成熟しつつある。

技術課題を吸い上げて、評価して、計画を立てる。

ただそれだけのことを、1人のリードアーキテクトではなく、ボトムアップでグループで行えるようになっている。これはなかなか凄いことなんじゃないかと思っている。

長年やりたかったシステムアーキテクチャに対するサブグループも立ち上がった。時間はかかったが、着実に良い未来につながる取り組みができていると思う。

自分が担当している DevOps WG も自分たちの様々なことについて、アセスメントを実行してフィードバックを得る、それ自体のサイクルが回っている。

各チームから満遍なく参加してもらっているのはマネージャである自分の唯一の功績である。その多様性により、何気なく持ち込んだら一瞬で課題が解決する、といった良い成果が出ている。このグループの取り組みが SRE チームにも良い影響を与えられており、自分がいて良かったことの1つだと思う。

SRE(2)

BtoB 領域のインフラを何とかしれくれと言われて何とかしにいった。と言っても片手間なので、状況を把握しにいって、方向性を決めて、細々発生するタスクを誰でもできるように標準化したり、意思決定したりする程度。

ちょっとはマシにはなった。

Terraform applyをlocal実行するのドキドキ新鮮だった。

学んだこと

  • 任せた方がいい、だけど丸投げはしない

それはそうなんだけど、でもやっぱり任せた方が結果的には良くなる。でも任せ方は大事で、丁寧に期待値合わせをして任せて、それを最初は結構頻度高く目線合わせとかで会話するとうまく行く。

それはそうということなんだが、やっぱりそうなんだなという感じである。なので、これは続けていきたい。

  • 自分にできないことを自覚し、他者を信頼して、他者を頼る

一時期足りてなかった時期があった。他者を信頼するというのが大事で、今でもちょっと苦手かもしれない。でもうまくいかない時って自分に原因があるので、そういう時はちゃんと内省するってことはできてるので続けたい。

次の半年

  • SRE: チームでチームをマネジメントできるようにする

  • プロダクト開発:

    • 大玉のリリース

    • リリース後の組織設計

    • PM とのコミュニケーション改善

VPoE は席空いてるけど能力が追いつくか余力ができないとできないかもしれない、わからない。

とりあえずこの半年はチャレンジしました。お疲れ様でした自分。

mikefarah/yq 便利

github.com

便利。やや癖ある。

2種類あるらしい。ややこしい。

github.com

本記事では前者のほうの使い方メモしておく。

副業で kubernetes manifest をあれこれオラオラするみたいなときに利用した。

でいろいろ記事を書こうと思ったが example は動く形で GitHub に置いておくかとなり

github.com

こちらを書いて満足した。

一括処理をするときに、同じパターンを複数のサービスに展開する時などは環境変数から入れることが多いと思うのでこれを知っておくと便利。

kustomize のリファクタリングとかよくやると思うのでこれまた便利。

最近こういう学んだことメモやってなかったので GitHub に書いていくスタイルでやっていきたい。

new Slack platform でやりたいネタ集

ここ最近 new Slack platform (この呼び方が正しいかは知らない) でいろいろ作って遊んでいる。

api.slack.com

使い心地や特徴、基本的な使い方は日本語記事でもたくさん出ているのでそちらに譲るとして、これまでやってきた今年含め冬休みに実装したいアイデアを記録しておく。

hanakintro

完全に身内のホビーアプリで、決められた問いかけに対して決められた文言を返すのみ。

github.com

いまオススメの店をサジェストする機能があるが、これをユーザが登録できるようにしたい。現状は conf ファイル的なところに静的に書かれているが、非エンジニアにプルリクを送れというのも無理だと思うので。

これは slack の DB と、Link trigger でできそうである。

api.slack.com

特定のリンクを貼って、ワークフロー的な入力画面を出してオススメの店をユーザが登録すると、DB に登録されるようにできそうである。link trigger 自体は使ったことないので本当かはわからん。

抽象化すると、アイデアやネタをユーザが登録し、botがなんらかのアルゴリズムで返却するということができる。これは今回のような趣味の知見共有もだし、業務のトラブルシューティングだったりオンボーディング支援だったりと、集合知の収集と活用というパターンで幅広く使えると考える。

thanks bot

プロトタイプまで作ったが実用化するのは断念した。

github.com

@thanks @mention message と投稿すると、メンションされた人がこれまで感謝された回数を返信する bot である。

結果は DB に保存して、その総数を返信するところまではできた。DB を使ってみたくてやってみた案件。

実用化できない理由は以下。今回は event trigger (今回だと app_mentioned trigger )であるが、

  1. 他の bot へのメンションでも反応してしまう

  2. channel_id を trigger で指定する必要があり、app が動くチャンネルが制限される

いずれも Slack DevRel の瀬良さんからワークアラウンドを紹介いただいたが、

1 についてはまだフィルターしたり、あるいは本家が治るのを待ってもいいのだが

2 はユーザが登録チャネルを増やすのを link trigger でやる、というのをイチイチやるのは面倒である。いつでもどこでも thanks したい。そのため見送った。

ワークスペースグローバルな event trigger が許容されるといいが、まぁベータだしチャネル制限はするよなというのはわかる。内部構造はわからんがグローバルだといろいろ負荷は大きそうだし。

問い合わせ記録bot

自分のチームはチームへのメンションに特定のリアクションをつけ、reacji で特定のチャンネルに流して、それを daily meeting でおさらいして共有したり、新規で反応できてないものへの対応策を決めたらするという営みがある。

ただしこれでは統計量の収集をしたり、中長期での分析をするのに一手間必要になってくる。

そこで該当チャンネルへの message posted event を使い、spreadsheet に追加する bot を実装したい。

spreadsheet じゃなくても DB 保存でもいいのはいいんだが結果のメンバー共有は楽にしたいので。

emoji_changed event でもいいんだが、前述のチャンネル制限の問題がある。こちらは自分のチームはの問い合わせが起きるチャンネルはある程度限定されるものの、どこで発生するかはわからない。

api.slack.com

そのため現状の reacji 運用を続け、流されるチャンネルでのみ動くようにする。

気になりとしては reaji がついたメッセージだけをフィルターできるかどうかぐらいである。(スレッドに回答サマリーをメンバーが登録している)

message post のデータでフィルターできなくとも、まぁ最悪 emoji ついてるかどうかをファンクション側でフィルターすればいいからなんとかなるかなと思っている。

これは抽象化すると、特定のチャンネルのメッセージを分析可能にする(シートに転送する)という処理になる。native に会話されてるチャンネルでやってもいいかもしれないし、今回のように reacji を活用すれば特定のコンテキストを人間が収集し、それを分析できるようになる。これも活用可能性は広いアイデアだと考える。

display name 変えたら戻す君

所属会社での slack workspace では slack display name と github id と google エイリアスを一致させるという規約がある。yaml でグループが一元管理され、それが CI で同期される。

そのため display name を変えると CI が落ちる。

display name なんて user preference な値をキーにするなよというのはごもっともであるが、これによって ID の強制ができるので、ID のみでコミュニケーションができる。

現状の慣習だと休み予定などのステータスを display name で表現する組織が多いように思う。組織も大きくなってきており、周知だけでなんとかするのも難しくなってきた。

実装だが、残念ながら profile change 相当の event trigger はこの platform でサポートされていない。しかし意地でもマネージド環境で動かしたい。そのため、schedule trigger で定期的に動かしつつ、直近プロフィールを変えたユーザがなんかを api でとってくるか、display name がリポジトリにある yaml 定義と異なるユーザを見つけてきて、強制的に修正しつつ DM で通知する、という機構を作るのかなと思っている。

本当はプロフィール変更イベントをキャッチして戻すというふうにできればより簡単にできるだろう。ただ現状の影響が大きいので実装してしまおうと思う。

このパターンはある静的なパターン(yamlなど)との一貫性を矯正するということになる。が、event 稼働でなくスケジュールというところがラグがあってイケてないよなぁ。プロフィールになんらかの規約を持たせたくて、さらにそれを強制化したいみたいなユースケースがあれば同じパターンとして適用できるかもしれない。

まとめ

今後もアイデア集めと実装を進めたい。slack new platform も deno も typescript も開発体験が良くて気に入っている。

これまでの経験から以下がまなびかな

  • event trigger はチャンネル特定に絞るパターンに使うほうがよい

  • DB は bot のみがアクセスする前提で考えたほうがいい。保存されたデータをより広く使わせたい場合は別の場所に保存したほうが良い

わかっていないこととしては、

  • チームで開発する方法。各自 dev 用トリガーを作って貰えばそれでいいか

  - それはそうと dev trigger は使ったら削除しないと登録しっぱなしだと反応してエラー通知が来てうざいことに気づいた

というわけで happy coding!

その後は会社のブログで書くかも。