EC/CRMの自社サービス「prismatix」の開発チームのマネージャーになってからやったことl連発

おさらい

1月にprismatix開発プロジェクトマネージャーから開発チームのマネージャーになりました。

• prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO
• 開発チームのマネージャーになるまでにやったことm連発 | DevelopersIO

この記事では、マネージャーになってから取り組んできたことを、順不同で紹介します。

やったこと l 連発 (順不同)

1. 所信表明演説

• 年明けすぐにDevマネージャー就任のメッセージ表明
  • prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO の話を改めて

2. モブプログラミング講座実施

• チームの開発スピードが鈍化していると感じていた
  • また個人単位でのスキルのサイロ化も感じていた
    • これらの解決にモブプログラミングが効くのでは？という仮説を立てた
• 下記のモブプロ講座を行っていた 安井力(やっとむ)さん に依頼
  • チームで実践するモブプログラミング講座（2022年6月・9月） | CodeZine Academy
  • やっとむさんとは TDDBC 長岡 2019-02 を開いたときに、TAとして協力いただいた頃からのご縁
    • コミュニティ活動が仕事の役に立つという一つの事例にもなった
• 数名×2チームで講座を受講
  • メンバーの受け取り方はさまざま
    • とはいえ「型」を知ることはできた
• 参考資料
  • チームをつくるモブプログラミング / Mob Programming to build teams - Speaker Deck

3. モブプログラミングの導入

• モブプロ講座の後、1つのチームでモブプロ導入
  • 1日2時間+2時間くらい全員で集まるのを始めてみた
• このままの形では定着しなかった
  • 開発スピード鈍化とストレス増加が発生
    • 開発スピードについては織り込み済みだった
    • ストレス増加は想定以上に大きかった
• チームでふりかえってやり方を徐々に変えてみた
  • 探索的な作業で有効そうという意見がでた
    • 方針検討やレビューやログ調査など
  • チームで必要に応じて随時行う形になっていった

4. リリースに向けた開発プロセス改善

• 従来は1週ごとに「その日の状態そのまま」で、機械的にリリースしていた
  • 機能追加やりかけでも、セマンティックバージョニング でいう「パッチバージョン」アップしてリリースしていた
    • テストが途中の機能が含まれた状態になってしまっていた
• さらに顧客開発環境に週次で最新版をデプロイするプロセスになっていた
  • 結果、顧客開発環境にいきなり後方互換性を破壊するような機能がデプロイされることが稀に起きていた
• これを防ぐため、「マイルストーン」を定めてそこに到達したらリリースする流れにした
  • 生煮えの状態ではリリースせず、ちゃんと準備ができてから、次のリリースタイミングでリリースする
• 一緒に顧客開発環境への定期デプロイも停止
  • そもそも顧客が求めていることではなかった
    • そもそも開発中の機能を即座に使いたいという動機はない
      • 機能がちゃんと使える状態で提供される方が嬉しい

5. チーム稼働状況の可視化

• 前回の記事で書いたとおり、各チームの「前向きな活動」、「運用に必要な活動」、「非生産的な活動」、「刃を研ぐ活動」の稼働割合を収集し始めた
• その集めた稼働割合を元にグラフで状況を可視化した
• こんなことが見て取れそう
  • 全体的に「前向きな活動」を徐々に増やせてきている
    • チームの活動によって他の時間を減らせているのかも？
  • 「運用に必要な活動」には波があるが、特に「注文・決済」、「検索」チームでその割合が多め
    • チームへの問い合わせやアラート対応の割合が多いのかも？
  • 「非生産的な活動」は全体としては少ないが、発生すると稼働を多く持っていかれてしまう
    • チームとしての動きが止まらないような体制が必要かも？
• あくまで「かも？」までしかわからない
  • この先については個別にヒアリングしたりなどが必要
• とはいえ、チームの改善に向けての足がかりにできそう

6. フリーランスを対象とした増員

• 開発チームへの負荷が高い状況をなんとかするため、余力を作る必要がある
• そのためにある程度長期的にコミットしてもらう前提でフリーランスを募集
  • もちろん社員の採用も並行で進める
• 負荷が高い注文・決済チーム、比較的期限が近い要望がたくさんある保守開発チームをターゲットに増員
  • ただ、いきなり増やすとそれはそれで負荷になるので少しずつ

7. Pull Requestテンプレートの小さな改善

• 元々Pull Request(PR)のテンプレートをそれなりに作り込んでいた
• そのうち下記の変更を行った
  • リリースノート
    • PRの変更をフロント開発者向けに説明するためのリリースノートを書くところ
    • そこに開発ドキュメントへのリンクを記載するための項目を追加
      • 変更がどの機能に影響しているのかすぐに分かるようにするため
  • デプロイ担当者への依頼事項
    • Kibanチーム(運用作業を行うチーム)向けの注意事項を書くところ
    • 特定のスクリプトを使うケースで、そのファイル名を明記するように
      • 運用作業の中で、毎回PRの内容から使うファイルを推測していたのをやめるため

8. 開発エンジニアの増員に向けてES部との連携強化

• クラスメソッドでは人事をES(エンプロイーサクセス)部が担当している
  • 参考: クラスメソッドの人事が採用時に重要視しているポイント | DevelopersIO
• 開発エンジニアの採用を強化したいとまずは意思を連携
  • その後、どんな動きができるか、できそうかを相談
• 結果、募集枠を増やしたり、採用プラットフォームを通じたスカウト活動につなげたりしている

9. チーム体制変更

• リフォームの匠 チームのメンバーから何人かが、新規プロダクト開発の活動にピボットした
• 同時に Kibanチームからも SRE を作る流れがあった
• この流れを合わせて一部チームを再編した
  • Kibanチームマネージャーとも頻繁に意見交換を行った
• 再編されたチーム
  • SREチーム
    • DevOpsを体現するスペシャリスト
      • 将来的にはDevチームとKibanチームを統合するための媒体とする
    • メンバー構成
      • Kibanチーム内から3名
      • リフォームの匠チームから1名
  • イネーブリングチーム
    • 品質や開発力を高めるためのファシリテーター
      • 書籍「チームトポロジー」の「4つのチームタイプ」から命名
    • メンバー構成
      • 匠チームから2名
• 部内にも「チームトポロジー」を引き合いに出しつつ、体制変更の狙いを説明
  • 参考: 【書籍レビュー】Team Topologies | DevelopersIO

10. 募集ポジション追加

• 元は「サーバーサイドエンジニア（JavaによるAPIプラットフォーム開発）」だけ募集していた
• 開発チームの現状を元に必要と考えた募集ポジションを追加した
  • プロジェクトマネージャー（自社サービス開発チームのプロジェクトマネジメント）
    • 私がプロジェクトマネジメント、ピープルマネジメント兼任しているのがボトルネックにならないようにしたい
  • エキスパートエンジニア（JavaによるAPI開発チームのテックリード / アーキテクト候補）
    • 未来に向けて強く開発をリードする力がほしい
  • 認証・認可・ユーザー管理基盤開発エンジニア
    • 認証・認可サービスをより体制強化していきたい

11. ファシリテーション塾を実施

• 前述のイネーブリングチームはファシリテーションスキルが不可欠
  • チームメンバーとはコラボレーションではなくファシリテーションでコミュニケーションするのが基本のため
• メンバーのファシリテーション力を高めたかった
• 内製化支援グループ の gaoryu さんにファシリテーション塾を依頼
  • 私とイネーブリングチームメンバーが参加
• これまでに3回開催
  • ファシリテーションとは？
    • 目的に対してチームを「促進」する行為がファシリテーション
      • 目的に向かうためのゴールを設定して、そちらに向かわせる
      • ふるまいで人を動かす
      • 促進させるための「デザイン」を行う
    • 変化型ファシリテーション: 人の系に対する高速フィードバック制御
      1. 見る
      2. フィードバックを受ける
      3. 感情として感じる ※ここが大事
      4. 感情を切り離して ふるまいを考える
      5. ふるまう
      6. チームが変化する
      7. 最初に戻って繰り返す
  • 場の設計
    • 登場人物と関係性を見る
      • その上で期待をチームに共有して歩み始め、目標に向けて働きかける
  • 提案と相談の違い
    • 物事を依頼すると「提案して欲しい」という意思表明になる
      • 提案されたらレビューすることになる
        • 批評家として見てしまう
    • 物事を相談すると「共に作ろう」という意思表明になる
      • 出てきたものを方向修正しながら一緒に作り上げる活動ができる
        • 「味方」としての関係性になる
    • 「形式知」ができたら、以後「依頼」の形にすれば良い

12. 定期的な 1on1

• 大体2週に1度の定期的な1on1を実施
• メンバーの感じていること、状況等を掘り下げて会話
  • プロジェクト進行に関すること以外も
• 私に対する「話しやすさ」を上げる効果も期待

13. 採用タスク引き継ぎ

• 前のDevマネージャーの塩谷 が担当していた採用関係の知見を引き継ぎ
• 説明ドキュメントを作ってもらい共有
  • 募集
  • 書類審査
  • 面接とオファー
  • 会社説明会、など
• エンジニアリング統括室の田部井(てぃーびー)との相談も
  • 最近の「相場感」を教えてもらう
  • 「採用」という活動の流れを改めて教えてもらう

14. 会社説明会登壇

• 採用活動引き継ぎの一貫として、クラスメソッドが開催している中途向け会社説明会に登壇
  • 1,2,3,4月の4回
• 塩谷が使っていた資料を参考にはしつつ、現状に合わせて毎回内容をアップデートしながら実施

15. オープンポジション発表会登壇

• クラスメソッドには「越境チャレンジ」という部署をまたいで新たなポジションにチャレンジできる制度がある
  • DevelopersLT 越境チャレンジスペシャル | DevelopersIO
• そのための「オープンポジション発表会」にてprismatixとして登壇
  • 会社説明会で登壇している内容をベースに社内向けの味付けをして

16. 「一体感」の深堀り

• クラスメソッドが全社で行っている 従業員エンゲージメントセンサスサーベイ の結果が出た
  • prismatix事業部として、決して悪い数字ではないが、「一体感」に関する期待との乖離が全社平均よりあることが分かった
• 「一体感」を向上するために、まずは個々のメンバーが考える「一体感」を知る必要がある
  • 参考: 従業員エンゲージメントサーベイの結果は具体的な問題を抽象化したもの。どう扱えばよいか？ | DevelopersIO
• 1on1でそれぞれのメンバーが考える「一体感」とは何か会話した
  • 予想通り色んな軸での「一体感」が出てきたので、それを取りまとめている最中

17. 大規模リリース実施

• 半期から四半期ごとに実施している「利用推奨バージョン」のリリース作業を行った
  • LTS扱いにすることで、開発・運用負荷を下げる目的のもの
• リリースに向けた性能試験を実施し、前回の大規模リリースとの比較を実施
  • 差が出た部分について深堀り
• 性能試験を行う中で出てきた課題を取りまとめ
  • 次回の大規模リリースに向けて取り組む計画中

18. 他部署のスクラムマスターとの交流

• CX事業本部には案件毎に多くのスクラムマスターが活動している
  • そして、スクラムマスターが週次で集まって雑談する会があった
• prismatix事業部はスクラムこそ行っていないがアジャイル開発を行っている
• アジャイル開発の知見や相談などを期待してスクラムマスター雑談会に参加するようにした
  • 結構お悩み相談室みたいなことも起きていて面白い

19. 勤怠管理

• クラスメソッドでは勤怠管理システムの KING OF TIME(KoT) を利用している
• 定期的な勤怠の「締め」や勤怠に関する相談などの対応を実施

20. 入場時の作業環境構築ドキュメント刷新

• エンジニアが入場する際に参考にする環境構築ドキュメントが散在していた
  • Confluenceとesaのようにドキュメントツール自体の分散
  • Dev/Kibanなどチーム別の分散
  • 同一チームでも新旧の手順が混ざっている
• Kibanチームと相談しエンジニア向け作業環境構築文書を刷新
  • 共通手順を統一
  • チーム別個別手順を分割
    • IDEなどDevチームだけが使うツールはこちらに
  • インストール対象者を明記
  • 関連手順ドキュメントへの導線を整理

21. Devチーム向けITSMツール利用手順レビュー

• 業務改善チーム が進めるITSMツールのDevチーム向け利用手順ができた
• Devチームに説明するにあたって気になる部分についてフィードバック
  • ツールの目的や利用ケースなど
• その利用手順を元に、後日Devチーム向けに説明をして利用開始してもらっている
  • 顧客からの問い合わせのエスカレーションを受ける
  • 顧客本番環境について調査依頼をする

22. 組織紹介ブログエントリ作成

• 採用コンテンツとしてprismatix事業部についてより知ってもらう公開ドキュメントが必要と感じた
• 手っ取り早い方法としてブログエントリとして作成した
  • EC / CRMプラットフォーム prismatix を支える組織の構成とは？ | DevelopersIO
  • prismatix(プリズマティクス)事業部のことがよくわかるWebページやブログエントリn選 | DevelopersIO
• 全社で「Entrance Book」を作る取り組みが動いているので、そちらに合流する元ネタとしても使う予定
  • 参考: ポテンシャライトから生まれた「Entrance book(エントランスブック)」 17選 +番外編 【2021/9/17更新】｜ポテンシャライト｜note

23. 全社新卒研修に参加

• 2022/4入社の新卒研修をエンジニアリング統括室が取りまとめていた
  • 前職で新卒研修を行っていた こともあり、興味があったので自ら巻き込まれて積極的フィードバック
• また「ソフトウェアテスト」のコースについてprismatix事業部が担当することになった
  • 「開発プロセス」および「チーム開発」コースを行うCX事業本部のメンバーと担当範囲のすり合わせを実施
  • その後コース設計を行う
  • この後5月に実際に実施する予定

24. リリース予定カレンダー作成

• リリースに向けた開発プロセス改善 の中で、1スプリントを2週間に変更した
• リリース日が毎週でなくなり、わかりにくくなった
• それを解決するため、Googleカレンダーとして「リリース予定カレンダー」を作成して部署に共有した

25. Spring4Shell対応

• 3月末から4月頭にかけて世間を賑わせた、Springフレームワークのゼロデイ脆弱性「Spring4Shell」に対応した
• 影響範囲の調査
  • cve-2022-22965 Spring4Shell の影響調査 | DevelopersIO
  • 結果的に即座に影響があるものではなかった
• 脆弱性対応
  • 即座に影響はないとはいえ、対応しておいたほうが良いものではある
  • Springプロジェクトの公式情報 に従い、プロダクトに修正を実施
    • メインライン
    • 過去のリリースバージョンのパッチバージョンアップ

26. 採用一次面接

• 応募者に対して一次面接として部署説明とカルチャーマッチ判断
  • もし採用できた後に配属したいチームリーダーなどのメンバーと一緒に実施
• 面接官をお願いしたメンバーと事前にすり合わせ
  • 何を期待しているか
  • どのポイントを見るか
  • 書類で気になったポイントはどこか
• すり合わせた内容を元に面接を実施

27、28、29、……

その他プロジェクト管理や顧客環境で発生したアラート対応についての調整など、いつもの仕事はたくさんやっていました。

まとめ

Devチームのマネージャーになり、当初想定していた通りピープルマネジメントに関する1on1や採用関係の取り組みがやはり多かったですね。とはいえ、チームや開発マネジメントもあまり減ったわけではないので、かなり忙しく動いていた印象です。

ただ、おかげで採用やチームに関する資料やドキュメントなどもだんだんと整ってきたので、少しずつ視点を上げてもっと先を見据えた活動を今後やっていけたらと思います。