前回の「EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発」から、早1年半が経とうとしています。
途中「EC／CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから」で取り組みかけていたことなどはご紹介しましたが、その内容を含め、何をやってきたかの紹介を、また連発形式でご紹介しようと思います。
やったこと(順不同)
1. 仲間集め
- より多くの価値提供に向けて仲間を増やしたかった
- 採用強化に向けていろいろやった
- 詳細は別途ブログ化予定
- リード獲得のために色々
- 部署紹介ブログエントリ作ったり
- DevIOに登壇したり
- 部署の取り組みを紹介したり
- スカウト文面見直し
- カジュアル面談実施
- 面接課題見直し
- オファー資料見直し
- 結果的に
- 採用枠の充足できた
- オファーからの受諾率100%達成
- 採用枠の充足できた
2. 人事評価基準作成
- クラスメソッド全体で人事評価基準を作ることになった
- これに伴い、開発エンジニアを次のロールで評価する基準を整備した
- 技術を突き詰める「エキスパート」
- 例）エンジニア→テックリード→アーキテクト
- 価値提供を突き詰める「スペシャリスト」
- 例）エンジニア→タスクリーダー→チームリーダー→プロジェクトマネージャー
- 技術を突き詰める「エキスパート」
- 段階ごとに求められる行動や能力の一例を明文化
- 評価される側が目指すキャリアをイメージできるように
- 評価する側によるブレが起きないように
- どんな基準を設定したかなどは別途ブログ化予定
3. 組織目標作成
- 前述クラスメソッド全体で組織目標を作ることになった
- 前述の通り評価制度全体の見直しの中で実施
- 組織目標の枠組みとしては OKR を使用する
- 部門のOKRをマネジメントメンバーと詰めながら作成した
- その後、開発チームのOKRをチームメンバーと相談しながら作成した
- さらにサブチーム単位のOKR作成の支援を行った
- どんなOKRを設定したかなどは別途ブログ化予定
4. 個人目標設定支援
- 上記のように人事評価基準と組織目標を作成した
- これの実現に向けて「チームメンバー個人」としての目標設定を支援した
- 組織目標実現に向けて個人が目指すことを設定
- そのために必要な行動・能力を人事評価に照らし合わせて設定
- 支援は主に個々人と1on1を繰り返し行って実施した
- 目指したいところ、そのためにまずどんな状態を目指すのかなどを問いかけを軸に引き出す
- 引き出したものをどう端的に表現したらよいか意見を交換した
5. ドキュメントツール移行
- クラスメソッド全体で使っていたドキュメントツールをConfluenceから移行することになった
- Confluenceに溜まっている各種ドキュメントを仕分けした
- 破棄するもの
- 参照できるように残すもの
- 継続的にメンテナンスを続けるもの
- 継続的にメンテナンスを続けるものについて、別ツールに移行した
- データベース的に使っているものはkintoneに
- ログイン情報などは安全に管理できる1Passwordなどに
- 部内にしぼりたいものはesaに
- 全社的に意味のあるものはNotionに
6. 「雑に相談しよう！」の部内働きかけ
- クラスメソッドが定期的に行っていた 組織サーベイ の結果「一体感」が弱みと出た
- この部分についてメンバーへのヒアリングを実施し「本当に問題であるのか」意見を集約
- ヒアリングの結果「関係性」の改善に向けてテコ入れが必要そうであるという「仮説」を設定
- 「一緒に問題解決する」という空気づくりのために「相談」してみませんか？と問いかけてみた
- 「作業指示」から始めると「提案」が返ってくる
- 「提案」されたら批判的に「レビュー」してしまう
- 「相談」から始めて「一緒に取り組む」空気を作りたい
7. 「相談」をどうやってするかの紹介
- 上記「相談しよう」の問いかけを受けて、そもそも相談ってどうやるものなのかを部内に紹介
- 「雑に相談しよう」がメッセージ
- 早い段階で
- 時間を掛けすぎず
- 一発で答えに辿り着こうとしない
- その上で礼節は大事にねも添えて
- 「雑」は「無礼」とは違う
- また「言葉にする大事さ」も
- 思いは言葉にしなければ伝わらない
- どんなに難しくてもこれしかない
- だから練習しよう
- 伝わったかどうかは相互に確認しよう
- 相談は「決める」のは相談者側
- オーナーシップを投げ出さない
- 相談される側も気をつけよう
8. 「雑に相談」するためのチームビルディング実施
- 上記「雑に相談しよう」の問いかけを受けて職能横断グループを作りワークショップを開催
- 「雑に相談」するために必要な要素について数人にグループで上げてディスカッションしてもらった
- ワークショップの設計では CXの長南さん にもお手伝いいただいた
- 詳しくは別途個別エントリで紹介する予定
9. 復職支援
- 育児休業していた くにきち | DevelopersIO が復職することになった
- 休職前と今とではだいぶ状況が変わっていた
- 休職時とはマネージャーが変わっている
- チーム体制が変わっている
- ルールが変わっている
- 復職前に何度か面談を実施し、復職後の双方の期待をすり合わせた
- 何をやりたいのか
- 何ができるのか
- 何をやってほしいのか
- 何が不安なのか
- etc...
- 面談の内容を踏まえ復職後の体制を整えた
- 所属サブチームの検討
- やりたいことができるサブチームへ配属するため
- 復職オンボーディングの手配
- 変わった状況のキャッチアップのため
- PCの手配
- ちょうど入れ替え時期に差し掛かっていたため
- etc...
- 所属サブチームの検討
- 復職後は毎日短時間の1on1を実施
- なにをやっているか
- 日々の困りごとはないか
- なにか手伝えることはないか
- etc...
- ご本人からの見え方は次のブログエントリを参照のこと
10. DevelopersIO 2022 ライブ登壇
- クラスメソッド主催のイベント DevelopersIO 2022 に「組織開発」枠でライブ登壇した
- 詳しくは
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-42252
- CVE-2021-43980
- いずれも即座に影響が無いことを確認
- その上で公式情報を元にライブラリのバージョンアップを含む修正を実施
- 対象は最新版及びサポート中のバージョン(パッチリリース)
- これらの対応を受けて脆弱性の対応記録を判断経緯含めて残すようにした
- CVE名など脆弱性を一意に特定するID
- 影響有無
- ありなら影響範囲
- 対応の要否
- 緊急対応の要否
- 即座に修正してパッチバージョンを提供しないといけないものかどうか
- 緊急対応の要否
- 対応結果
15. アカウント名変更手順文書化
- 人生イベントなどがきっかけで名字が変わることがある
- 名字をアカウント名に使っていたとき、どのように変更を進めればよいか手順がなかった
- ただ、その時々で使っているSaaSなどは変わるため、「何をきっかけとして」「誰がどういった事を行うか」について明文化して部内に展開した
16. 認証認可チーム新メンバー受け入れに向けた資料提供
- 新たに認証認可チームに 中島義道 | DevelopersIO を迎えることになった
- ジョイン後にすぐに業務に入れるよう、各種情報を事前に渡すことにした
- NDA締結して資料提供することに
- ただし、そのためのフローが曖昧だった
- 部門長に確認しながら手順化した
17. 部署マネジメントミーティング議事録を部内公開
- 週次で部内各チームマネージャーが集まって状況共有や方針議論のミーティングをしていた
- メンバーから見ると「何を話しているかわからない」状態だった
- 各チーム状況や議題について部のメンバーが誰でも見れるよう議事録として公開した
18. 炎上しそうな機能追加案件にむけて緊急体制構築
- 最初の見積より大幅にコストがかかる案件が発覚
- 「今」の再整理と今後に向けてメンバーを緊急でサポートにアサイン
- CEOにも共有し事業とのバランス含めて合意をつける
19. プロジェクトマネジメント業務の委譲
- 自分が「ピープルマネジメント」と「プロジェクトマネジメント」の両方を持っていた
- prismatixおよび自分の成長のため「ピープルマネジメント」および「開発チームの成長支援」に集中的に力を割きたい
- そのため「プロジェクトマネジメント」を専任するメンバーである 八代醍弘一 | DevelopersIO の採用を行った
- 本当にありがとうございます！助かりました！
- プロジェクトマネジメントでやっていた役割を徐々に徐々に移していった
- 週次報告のまとめ
- リリース作業のとりまとめ
- チームミーティングのとりまとめ
- 全サブチーム間の調停
- 顧客窓口、インフラ運用チームとの調停
- ….
- 結果的に自分がEM(エンジニアリングマネジメント)業務に集中できるようになってきた
20. 次年度に向けての体制づくり
- 2022年度で目指していたことと実際にできたことをくらべる
- 2023年度で何を目指すか、どう目指すのかを部門長と相談しながら作成
- 次の組織目標であるOKRを作成した
- チームの統廃合、メンバーのチーム異動などを各所と調整して進めた
- 部署として新たなプロダクトも力を入れていくため、重心を少し移動するイメージ
21, 22, 23, …
他にも日々の球拾いや内部向けすぎてここでは書けないことなどたくさんやっていました。
まとめ
立場がPjMからマネージャーに変わり、チームのタスクコントロールとは別に、ピープルマネジメントという新たな役割が増え、相当バタバタとした1年半でした。
幸い優秀なメンバーを採用や異動を通じて迎えることができ、元々もっていた役割を渡しつつ、誰に何をやってもらえるといいのかな？という全体を考えて体制を組んでいくという動きを経験できたのは、非常に良かったです。
今年度は昨年度よりさらにハードになりますが、また色々と試して経験しながら、自らもどんどん成長できればと思っています。
4
