マネジメントロールになって2年目にやったことn連発

#プリズマティクス

#マネジメント

髙野将

2023.09.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

前回の「EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発」から、早1年半が経とうとしています。

途中「EC／CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから」で取り組みかけていたことなどはご紹介しましたが、その内容を含め、何をやってきたかの紹介を、また連発形式でご紹介しようと思います。

やったこと(順不同)

1. 仲間集め

より多くの価値提供に向けて仲間を増やしたかった
採用強化に向けていろいろやった
- 詳細は別途ブログ化予定
- リード獲得のために色々
  - 部署紹介ブログエントリ作ったり
  - DevIOに登壇したり
  - 部署の取り組みを紹介したり
- スカウト文面見直し
- カジュアル面談実施
- 面接課題見直し
- オファー資料見直し
結果的に
- 採用枠の充足できた
  - オファーからの受諾率100%達成

2. 人事評価基準作成

クラスメソッド全体で人事評価基準を作ることになった
- クラスメソッドの評価制度を改定した話 | DevelopersIO
これに伴い、開発エンジニアを次のロールで評価する基準を整備した
- 技術を突き詰める「エキスパート」
  - 例）エンジニア→テックリード→アーキテクト
- 価値提供を突き詰める「スペシャリスト」
  - 例）エンジニア→タスクリーダー→チームリーダー→プロジェクトマネージャー
段階ごとに求められる行動や能力の一例を明文化
- 評価される側が目指すキャリアをイメージできるように
- 評価する側によるブレが起きないように
どんな基準を設定したかなどは別途ブログ化予定

3. 組織目標作成

前述クラスメソッド全体で組織目標を作ることになった
- 前述の通り評価制度全体の見直しの中で実施
- 組織目標の枠組みとしては OKR を使用する
部門のOKRをマネジメントメンバーと詰めながら作成した
その後、開発チームのOKRをチームメンバーと相談しながら作成した
さらにサブチーム単位のOKR作成の支援を行った
どんなOKRを設定したかなどは別途ブログ化予定

4. 個人目標設定支援

上記のように人事評価基準と組織目標を作成した
これの実現に向けて「チームメンバー個人」としての目標設定を支援した
- 組織目標実現に向けて個人が目指すことを設定
- そのために必要な行動・能力を人事評価に照らし合わせて設定
支援は主に個々人と1on1を繰り返し行って実施した
- 目指したいところ、そのためにまずどんな状態を目指すのかなどを問いかけを軸に引き出す
- 引き出したものをどう端的に表現したらよいか意見を交換した

5. ドキュメントツール移行

クラスメソッド全体で使っていたドキュメントツールをConfluenceから移行することになった
- ネクストモード社Noitonセミナーに登壇し「ConfluenceからNotionへの全社移行事例」について発表しました。 | DevelopersIO
Confluenceに溜まっている各種ドキュメントを仕分けした
- 破棄するもの
- 参照できるように残すもの
- 継続的にメンテナンスを続けるもの
継続的にメンテナンスを続けるものについて、別ツールに移行した
- データベース的に使っているものはkintoneに
- ログイン情報などは安全に管理できる1Passwordなどに
- 部内にしぼりたいものはesaに
- 全社的に意味のあるものはNotionに

6. 「雑に相談しよう！」の部内働きかけ

クラスメソッドが定期的に行っていた組織サーベイの結果「一体感」が弱みと出た
- この部分についてメンバーへのヒアリングを実施し「本当に問題であるのか」意見を集約
  - 組織課題の解決シリーズ – 問題が存在しているか見極める | DevelopersIO
ヒアリングの結果「関係性」の改善に向けてテコ入れが必要そうであるという「仮説」を設定
「一緒に問題解決する」という空気づくりのために「相談」してみませんか？と問いかけてみた
- 「作業指示」から始めると「提案」が返ってくる
- 「提案」されたら批判的に「レビュー」してしまう
- 「相談」から始めて「一緒に取り組む」空気を作りたい

7. 「相談」をどうやってするかの紹介

上記「相談しよう」の問いかけを受けて、そもそも相談ってどうやるものなのかを部内に紹介
「雑に相談しよう」がメッセージ
- 早い段階で
- 時間を掛けすぎず
- 一発で答えに辿り着こうとしない
その上で礼節は大事にねも添えて
- 「雑」は「無礼」とは違う
また「言葉にする大事さ」も
- 思いは言葉にしなければ伝わらない
- どんなに難しくてもこれしかない
  - だから練習しよう
- 伝わったかどうかは相互に確認しよう
相談は「決める」のは相談者側
- オーナーシップを投げ出さない
- 相談される側も気をつけよう

8. 「雑に相談」するためのチームビルディング実施

上記「雑に相談しよう」の問いかけを受けて職能横断グループを作りワークショップを開催
- 「雑に相談」するために必要な要素について数人にグループで上げてディスカッションしてもらった
ワークショップの設計では CXの長南さんにもお手伝いいただいた
詳しくは別途個別エントリで紹介する予定

9. 復職支援

育児休業していたくにきち | DevelopersIO が復職することになった
休職前と今とではだいぶ状況が変わっていた
- 休職時とはマネージャーが変わっている
- チーム体制が変わっている
- ルールが変わっている
復職前に何度か面談を実施し、復職後の双方の期待をすり合わせた
- 何をやりたいのか
- 何ができるのか
- 何をやってほしいのか
- 何が不安なのか
- etc...
面談の内容を踏まえ復職後の体制を整えた
- 所属サブチームの検討
  - やりたいことができるサブチームへ配属するため
- 復職オンボーディングの手配
  - 変わった状況のキャッチアップのため
- PCの手配
  - ちょうど入れ替え時期に差し掛かっていたため
- etc...
復職後は毎日短時間の1on1を実施
- なにをやっているか
- 日々の困りごとはないか
- なにか手伝えることはないか
- etc...
ご本人からの見え方は次のブログエントリを参照のこと
- 育休から復帰しました（ごあいさつと振り返り） | DevelopersIO

10. DevelopersIO 2022 ライブ登壇

クラスメソッド主催のイベント DevelopersIO 2022 に「組織開発」枠でライブ登壇した
詳しくは
- EC／CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから #devio2022 by @masaru_b_cl | DevelopersIO

11. Amazon Aurora for MySQL EoL対応

主に利用しているAuroraのバージョンがEOLになる
- そのため新バージョンで問題ないか動作を確認しないといけない
- 特にMySQL 5.7互換バージョンは2024年には使えなくなるため、MySQL 8.0互換バージョンでの動作検証も必須
SREチームと協力し、特定バージョンのMySQLやAuroraでの検証ができる体制を整えた
- 見つかった問題に対処するためのコード修正も実施

12. 部門異動対応

他部門のAWSコンサルエンジニアから開発ロールに戻りたいとのことで打診を受ける
数回の面談で双方の期待のすり合わせを実施
- 何を期待しているのか
- なにをやりたいのか
- どんなことをしてほしいのか
双方の意向が一致したため部門異動を行うこととなった
部門異動に伴う諸々を実施
- 異動元部門長への働きかけ
- 自部門長への働きかけ
- 入場手続きの手配
- 異動オリエンテーションの手配
- 異動オンボーディングの準備
- 配属サブチームの検討および既存メンバーからのヒアリング
異動オンボーディングの実施

13. 無駄なCIコスト削減

現状無意味になっているCIビルドを停止しコストを削減する
- アクティブでないサービス
- 古いバージョンのサービス
毎日実行していたCIを平日のみ実行する
- 週末はコード変更が起きないため

14. 脆弱性調査および対応旗振り

下記の3つについて影響調査を実施
- CVE-2022-22965 (Spring4Shell)
  - CVE-2022-22965 | Security | VMware Tanzu
- CVE-2022-42252
  - JVNVU#93003913: Apache Tomcatにおける無効なHTTPヘッダの取り扱いに関する問題
- CVE-2021-43980
  - JVNVU#98868043: Apache TomcatにHttp11Processorインスタンスにおける競合状態による情報漏えいの脆弱性
いずれも即座に影響が無いことを確認
その上で公式情報を元にライブラリのバージョンアップを含む修正を実施
- 対象は最新版及びサポート中のバージョン(パッチリリース)
これらの対応を受けて脆弱性の対応記録を判断経緯含めて残すようにした
- CVE名など脆弱性を一意に特定するID
- 影響有無
  - ありなら影響範囲
- 対応の要否
  - 緊急対応の要否
    - 即座に修正してパッチバージョンを提供しないといけないものかどうか
- 対応結果

15. アカウント名変更手順文書化

人生イベントなどがきっかけで名字が変わることがある
名字をアカウント名に使っていたとき、どのように変更を進めればよいか手順がなかった
ただ、その時々で使っているSaaSなどは変わるため、「何をきっかけとして」「誰がどういった事を行うか」について明文化して部内に展開した

16. 認証認可チーム新メンバー受け入れに向けた資料提供

新たに認証認可チームに中島義道 | DevelopersIO を迎えることになった
ジョイン後にすぐに業務に入れるよう、各種情報を事前に渡すことにした
- NDA締結して資料提供することに
ただし、そのためのフローが曖昧だった
- 部門長に確認しながら手順化した

17. 部署マネジメントミーティング議事録を部内公開

週次で部内各チームマネージャーが集まって状況共有や方針議論のミーティングをしていた
メンバーから見ると「何を話しているかわからない」状態だった
各チーム状況や議題について部のメンバーが誰でも見れるよう議事録として公開した

18. 炎上しそうな機能追加案件にむけて緊急体制構築

最初の見積より大幅にコストがかかる案件が発覚
「今」の再整理と今後に向けてメンバーを緊急でサポートにアサイン
CEOにも共有し事業とのバランス含めて合意をつける

19. プロジェクトマネジメント業務の委譲

自分が「ピープルマネジメント」と「プロジェクトマネジメント」の両方を持っていた
prismatixおよび自分の成長のため「ピープルマネジメント」および「開発チームの成長支援」に集中的に力を割きたい
そのため「プロジェクトマネジメント」を専任するメンバーである八代醍弘一 | DevelopersIO の採用を行った
- 本当にありがとうございます！助かりました！
プロジェクトマネジメントでやっていた役割を徐々に徐々に移していった
- 週次報告のまとめ
- リリース作業のとりまとめ
- チームミーティングのとりまとめ
- 全サブチーム間の調停
- 顧客窓口、インフラ運用チームとの調停
- ….
結果的に自分がEM(エンジニアリングマネジメント)業務に集中できるようになってきた