マネージャーになって3年目の前半でやったことn連発

今期はプロダクトマネジメントにも挑戦を始めました。その一方で元々のプロジェクト、エンジニア、ピープルマネジメントも引き継ぎつつ実施しています。とあるマネージャーの日々の奮闘の記録として、連発形式でお届けします。

#プリズマティクス

#マネジメント

髙野将

2023.12.22

前回の「マネジメントロールになって2年目にやったことn連発 | DevelopersIO」から、この半年くらいでやったことを、また連発形式でご紹介しようと思います。

やったこと(順不同)

1. 開発チームメンバーの責務整理

今は開発チームをいくつかのサブチームにわけている
その影響もあり、知識のサイロ化が進むとともに、ベースラインが揃わなくなってきていた
ベースラインを揃えるための第一歩として、開発チームメンバーとしての責務を整理してチームに共有した

2. 開発基礎勉強会

整理した開発チームメンバーとしての責務を元に共通的なベースライン(基礎)部分を再整理
そのベースラインについて改めて学び直す勉強会を週次で開催
- 今後の新メンバー受け入れ時のオンボーディング資料の元ネタ作りも併せて実施

3. 業務ドメイン勉強会

開発を行う中でユーザーの気持ちがわかればすんなり話が進むのにと思うことが多々あった
- 何ができたら嬉しいのか
- どうできたら嬉しいのか
ユーザーの気持ちを知る一歩として、prismatixが扱う「EC/CRMという業務ドメイン」を学ぶことにした
- 単に「商品」や「価格」、「在庫」といっても、どういうことができないといけないのか
まずは最近ジョインしたメンバー1名とプリズマジャーナルの記事を一緒に読んでいった
- その後、実際の顧客側の要件がわかる資料などを一緒に読んでいった
- 今後他のメンバーが学べる資料を作ることにしている

4. Sentryに関する外部イベントに登壇

Findy社主催のSentry関連イベントに登壇打診があり、渡りに船と二つ返事で承諾
prismatixの開発・運用でSentryをどのように使ってきたか、これからどう使っていくかについてLTを実施
詳細は以下のイベントレポートを参照のこと
- 「Sentry本国のエンジニア登壇！Sentry 活用できてる？利用企業から学ぶエラー管理LT」に参加＆登壇しました #sentry_findy by @masaru_b_cl | DevelopersIO

5. Sentryのエラーアラート対応の開発チーム巻取り

これまでアプリケーションのエラーをSentryに連携していて、日々のアラートの処理は開発チーム以外に任せていた
- 結果的に「アプリケーションの問題」が開発チームから見えにくくなってしまっていた
エラーアラートの処理を開発チームが最初から処理することに変更した
- 主体的に処理することで「面倒さ」や「大変さ」がわかるように
今後は省力化に向けて進める
- 無駄なアラートの削減
- アラート確認頻度のレベル分け
- 対処しやすいエラー内容への修正

6. 「スプリントふりかえり」のふりかえりを実施

（あるサブチームが中心）

日頃スプリントごとに「ふりかえり」は実施していた
- 一人ずつYWT(やったこと、わかったこと、つぎにやること)を発表するスタイル
改善に向けたNextActionが「ルール」みたいなものになってしまい、いまいちアクションにならないという課題感があった
内製化支援「組織づくり支援サービス」 | クラスメソッド株式会社を実施している「内製化支援チーム」に相談して「ふりかえりのふりかえり」を実施してもらえることに
- ふだんやっているふりかえりを実際に見てもらう
- チームメンバーによる「ふりかえりのふりかえり」をファシリテーションしてもらう
  - いくつか「目的に応じたふりかえりのフレームワーク」を実際に体験した
  - チームリーダー、PjMがファシリテーション方法を学ぶこともできた
- 実際のチームでのふりかえりのやり方を目的に合わせて変えてみている
  - チームの動きを改善したいのが目的
  - 採用したのは「アトラシアンのふりかえり」
    - アジャイルでよく行われるふりかえりの手順 | アトラシアン | Atlassian
今後も場に応じた手法を使い分けられるようにPjM、リーダーで相談しながらやっていく
- 内製化支援チームへの相談もアドホックに実施予定

7. プロダクトの次期バージョン計画立案

prismatixもサービス開始からだいぶ経ち、外部の変化含め色々と状況が変わってきた
- 今と未来に向けてさらに役に立つ「武器」を提供する次期バージョンを考えることに
次期バージョンのリリースに向けた計画立案を行った
- いわゆるプロダクトマネージャー(PdM)のようなお仕事
- 粗い計画案を作り、関係者にヒアリングしてすり合わせるのを何度も何度も繰り返した
これまで経験したこととは一段上のレイヤのことだったため、非常に苦労した
- 「達成したいゴール」が決まったところに対して、何をどんな順番でやればよいかというのはこれまで何度も経験があった
  - いわゆるPjMのようなお仕事
- 「ゴール」を決めるところから、そこに向けて「プロダクト」として何をどんな順番でやればよいかという経験は始めて
- 「粗い」計画案を作るのがすごく難しかった
  - どうしてもエンジニアのベースがあるので、深く考えようとする癖が自分にあることに気づいた
  - 深く考えずに、いわば「幅優先探索」のような考え方を何度も意識しながら行うようにした
やることとロードマップは決まった
- 今度はその一段下の「具体で何をやるか」「いつやるか」「どうやるか」を引き続き検討、議論、推進する

8. ほかチームとのコミュニケーションの型をつくる

運用チーム、顧客窓口チームとやり取りする際、気をつけるべきことをそれぞれのチームと会話して整理
それを元に、目的別に「型」を作った
- 何を期待しているか
- こちらが欲しい情報はなにか
- こちらが提供すべき情報はなにか
型をチームに共有し、使ってもらっている
- 今後型が活用されているかを随時確認予定

9. 一人あたりの開発スピードの可視化

これまで開発スピードはなんとなく体感に頼っていた
リリース単位で解決した「課題」の数を集計し、開発メンバーの数で割ることで、「一人あたりの開発スピード」をわかるようにした
- 2年前くらいからプロットすることで推移もわかるように
結果として、「1年前よりは加速しているが、今は停滞気味」ということが可視化された
- なぜ停滞しているかの原因調査と対応を今後行うことに

10. マネージャー向け組織開発研修受講

クラスメソッドという組織全体でピープルマネージャーを強化しようというプログラム
- 組織の規模が大きくなるに伴い、部門長とメンバーの中間層であるチー未マネージャー、リーダーの負担が多くなっているため
  - 板挟みになりやすいので「崖に落として登ってこい』スタイルだと育たない
全7回の動画講習を受講した後、部門をまたいてマネージャーを集めたグループでディスカッション
- 記憶に残ったところ
- 自分はできていると思うところ
- 自分、部門で試したいところ
研修そのものもそうだが、他部門のことを知れたことも良かった
- 何をやっているか
- どんな課題があるか
- 似た課題があればどうやって対処したか、またはしようとしているか

11. 目標設定/中間ふりかえり実施

昨年と同様に、人事評価基準、チームの組織目標(OKR)を関係者と協議の上決定
- 昨年のものをベースにしながら、現状をもとに新たな目標を設定
これを元に、チームメンバーの組織目標(OKR)、人事目標を設定した
- 個々人とチームの目標とすり合わせながら、任せたい役目なども調整
半期の終わりで中間ふりかえりを実施
- チームとしての状況を事実と感覚でまとめる
  - 残念ながら目標に対してはビハインドしている状況
- 現状を元に問題と課題の仮説を立てる
- 課題を解消するアクションの叩き台をつくり、今後チームと相談しながら実施していく

12. パフォーマンス問題の障害対応

顧客環境で突如特定マイクロサービスのレスポンスタイムが悪化する事象が発生
「何が起きているのか」を監視ツール(Datadog)とALBログを用いて実施
- ALBログから、ECSのタスクごとにリクエスト数、レスポンスデータサイズ、レスポンスタイムの平均、最大、p95を秒/分単位で集計
  - リクエスト数とレスポンスタイム悪化の時系列を確認
- Datadogでレスポンスタイム悪化の前後のCPU負荷状況、メモリ利用状況、GC発生状況のを時系列で整理
得られた情報から、障害発生までの「ストーリー」を描き、有識者とすり合わせた
- 時系列で何がきっかけとなったか、マイクロサービス内部で何が起きたかを整理することで、直接的な原因の説明がつくようにした
- 直接的な原因を元に、直近でどんな対応が取れるかを顧客窓口担当と共に協議の上決定した
- 顧客窓口担当から顧客に説明し、その後対応を実施するようにした