EC/CRMの自社サービス「prismatix」開発チームのマネージャーになるまでにやったことm連発

prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO で書いたとおり、年明けにクラスチェンジするにあたり、前回の 開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO からこれまでにやってきたことを、またつらつらと書いていきます。

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

1. ミーティングの議事録作成担当を移譲

• 部署全体で行う勉強会的なもの(通称金曜会)のメモを私が作成していた
  • スライドのスクショ取って、箇条書きでメモを残す感じ
• SPoFになっていたので若手二人に移譲
  • メモの目的やポイント、スクショのとり方などをまとめた
    • スライドに 書いてない ことを箇条書きで書くこととか
      • 口頭で補足するタイプのスピーカーだとちょっと大変
  • それを元にやり方教えた
  • やらせてみたメモに自分で別取りしたメモを添えて「こんなかんじだともっといいよ」を伝える
    • 例）スクショ→ポイント箇条書きの順のほうが、スライドの中身を頭に入れてから読めるから読みやすいよ

2. ドキュメント改善タスク巻取り

• 認証・認可サービスのチームリーダーが、開発タスク以外に全体のドキュメント改善タスクも持っていた
• 認証・認可サービスはprismatixのキモの一つであり、常に多くの課題がある
• それに加えて全体ドキュメント改善もやるのはまず無理なのでひっぺがして巻き取った
  • ただ、その後チーム全体の優先順位によりドキュメント改善は後回しになっているので、そこはちょっと反省

3. 内製化支援チームのサポート範囲を再整理

• 7月にPjM担った当初から CX事業部 内製化支援チーム に相談に乗ってもらったりしていた
• 数ヶ月やってきたが、お互いが「何を期待していて何ができるのか」がわからなくなってきていた
• 一度関連メンバーをがっと集めて今後についてすり合わせをした
  • 「開発チームの状況を改善したい」に注力したい
  • それが得意なメンバーをアサインしていただくことになった

4. リフォームの匠チーム決起集会

• 主に改善作業やアーキテクトの役割を担う「リフォームの匠」チームはメンバーが各地に散らばっていた
  • 札幌、東京、千葉、長岡など
• チームの結束を高めるため、長岡に集結
  • コロナが落ち着いた時期にオフラインで集まることを組織自体も推奨していた
• オフラインで直接ヘビーな課題についてディスカッション
  • 仕事の後は旨い酒とともに懇親会を行い、チームの結束を高める

5. エンジニアの技術面接の見直し(継続中)

• これまでは「部署のメンバー全員」そろって応募者の技術面接をしていた
  • 結果、あんまり突っ込んだ技術面を見れていないケースがちらほらあった
• 技術面を見る面接を全体面接の前に入れようとしている
  • メンバーを絞って少人数で「クラス設計とコーディング」を見る、など課題は検討中
    • メンバーに協力してもらい、課題のお試しを実施して調整している
• 全体面接では「チームとの相性」を中心に見れるようになる効果を期待している

6. 他部署メンバーによるサポートの取り付け

• ある顧客環境でECSタスクで稼働するコンテナが異常動作する事象が発生
  • prismatixチームメンバーのスキル・知識では原因が検討もつかない状態になった
• 幸い弊社のAWS事業本部には、AWSに強いメンバーが多数在籍している
  • 部署をまたいでサポート稼働してもらえないか、事業本部長に直接お願い
    • 元々部署が違ってもフランクに聞ける関係性が弊社にはある
      • CLP「パートナーシップ」
• サポートを快諾していただき、おそらくの原因が判明
  • 解決に向けてAuto Scalingのパラメータの調整案も出してもらえた

7. Devチーム週報を導入

• これまで週次の進捗は各サブチームリーダー個々人順番に呼び出して、状況を聞き出すスタイルだった
  • 内容はリーダーによってバラバラだったり、チームでなくメンバー単位での報告だったり
• 結果、チームがどういう状況かいまいち見えなくなっていた
  • そのため、顧客フロント担当などから「いつまでに出来るのか？」という問いかけが頻繁に発生
• 週次報告の内容を「週報」としてテンプレート化し、報告すべき内容を揃えた
  • チームとして取り組んでいるタスクおよび完了予定時期
  • 顧客フロントからの問い合わせがあればその状況
  • 障害があればその状況
• 週次ミーティング前には開発チームの状況がまとまった状況にできた
  • 結果、サブチームリーダーと周辺ステークホルダーが 一緒に集まって ミーティングできるようになった
    • 状況報告は書面で済ませ、調整事項などに注力できるようになった

8. チーム稼働状況の収集(継続中)

• 各サブチームの進捗が思ったよりなかった場合、なんで進まなかったのか問い詰めるような形になりがちだった
  • 問い合わせやアラート調査、障害対応などの時間が見えなかった
• 週報の中で、各チームの稼働状況について、大まかに割合を収集し始めた
  • 稼働の分類は 可視化 - プロダクト開発チームの「開発テーマ」を考える | DevelopersIO にあるやり方をベースに次のようにした
    • 前向きな稼働
    • 運用に必要な稼働
    • 非生産的な稼働
    • 刃を研ぐ稼働
      • 前述のエントリにないもの
      • 勉強会、ブログ執筆など、今後のチームのちからを高める活動はここに分類する
• 進捗がいまいちのときでも、「前向きな稼働」が少ないことが原因であればすぐわかるように
  • 「前向きな稼働」の割合がそれほど少なくなっていなければ、他に原因があるということになる
• 今後継続して大まかな傾向を把握した上で、徐々に前向きな稼働、刃を研ぐ稼働に使える時間を増やしていく
  • 運用に必要な稼働、非生産的な稼働を少なくするために「障害」となっているものは何かを見つけたい

9. 地方在住エンジニア向け会社説明会に登壇

• クラスメソッドの会社説明会〜地方在住エンジニアに贈るオンライン上京という選択〜 に登壇
• 「地方在住エンジニアでもバリバリやっていけているよ！」というメッセージを主に発信
  • 前職のSIer時代から変わったこと、変わらなかったこと
  • どういった活動が今の自分に役立っているか、など
• 社内外にprismatix事業部および自分の存在をアピールできた
  • クラスメソッドは多くの部署があり、どこも優秀な人材が欲しい
  • 他部署との連携などがやりやすく

10. 自分が思う理想の開発チームの形をチームに共有

• prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO に書いた「目指す形」をチーム内に向けて発信

自由自在なチーム
(思ったとおりに 安心して使えるプロダクトを 開発・保守できるチーム)

• 理想の形に向かうために必要だと思っていることも伝えた
  • 仕事に取り組む姿勢
  • 仕事の進め方、など
• このあたりは別途ブログエントリにしたい

11. Meetyでカジュアル面談作成

• Meety | カジュアル面談プラットフォーム にて、カジュアル面談を作成
  • フルリモートでマイクロサービス開発チームのPjMってどんな感じ？
• 今後の採用に向けてprismatixチームの内情を気軽に知ってもらえるための入り口を作った
  • とはいえ実際のカジュアル面談にはつながっていないので、今後も継続して発信する

12. 四半期ごとの個人面談である「JD」を主導

• クラスメソッドでは四半期ごとにメンバーとマネージャーが面談する「JD (Job Description、職務記述)」というイベントがある
  • メンバーひとりひとりが四半期で何に取り組みどのような成果を出すことを目指すかを文書でまとめ、マネージャーと期待値のすり合わせやコーチング的なことを実施する
    • 一般的な 職務記述書 とは意味合いが異なるため、私は括弧付きの「JD」と呼んでいる
• 部署ごとにやり方が違っているが、例えば次のエントリなどが参考になる
  • リモートワーク 在宅勤務 テレワークを成功させる鍵を考えてみた | DevelopersIO
  • 自走できる即戦力という夢物語。従業員の活躍には組織の支援が必要。組織社会化について | DevelopersIO
• これまでは開発チームのマネージャーである塩谷が主導していた
  • 年明けから私がマネージャーになるため、その役割を引き継いだ

13. 障害・脆弱性対応の指揮 (数回)

• 先日発生した Log4Shell など、各種脆弱性や顧客環境で影響が大きい障害が発生した際、その指揮を取った
  • Log4shellにprismatixがチームとしてどう立ち回ったか | DevelopersIO
• 今後は対応プロセスを ITIL などを参考にブラッシュアップし、チームに根付かせる活動が必要

14. 開発チームへの依頼窓口を集約

• これまで顧客フロントからの問い合わせや、アラートによるログ調査などの依頼が、Slackの様々なチャンネルにバラけていた
  • 顧客フロント対応専用チャンネル、運用専用チャンネル、開発サブチーム専用チャンネル、など
• 元々あった、開発チーム以外も含んだチーム横断で「開発」に関する内容を扱うチャンネルに、依頼窓口を集約した
  • 関連チームメンバーが全員入っているチャンネルなので、パス回しが楽になった
    • 調査の中で運用チームに訪ねたいことがあれば、そのままチャンネル内でメンションするだけで良い
• 依頼する際の宛先は各サブチームのSlackユーザーグループにした
  • 全てに私が入り、依頼があったことをもれなく捕捉できるようになった

15. 360度評価の実施

• クラスメソッド全体で360度評価を実施
  • 評価者としてチームメンバー、別チームマネージャーを評価
  • 被評価者として他チームマネージャー、事業部長、他部署などから評価を受ける
• 評価結果については年明けにチームメンバーにフィードバック予定

16. 社内情報共有プラットフォーム移行の下準備

• 現在クラスメソッドでは社内情報の共有に Atlassian の Confluence を利用している
  • 歴史が積み重なることで目的の情報にたどり着きにくい状況になってきていた
• 全社プロジェクトとして他のプラットフォームも含んだ移行の検討が始まった
  • いわゆる「式年遷宮」みたいなもの
• 今Confluenceにある情報で移行対象とすべき情報の取捨選択が必要になった
  • 担当者からの確認依頼が各マネジメント向けに来ていたが、誰もボールを拾えていない様子だったので動いた
• prismatix事業部が利用していたワークスペースの文書について一覧化
  • 開発チームが必要なものにマーク
    • メンバーにも要否判断を依頼
  • 他チームのものっぽい文書についてもそのようにマークして確認依頼を投げた
• 担当者に移行対象となる文書のリストを引き渡すことができた

17. 褒めそやされた

• 社内コミュニケーションを盛り上げる活動「褒めそやすっ！」について | DevelopersIO で紹介されたやつ
• 褒めそやされる側で参加した
  • 自分のやっていることを改めて見直す機会にしたかった
  • prismatix事業部でやっていることを全社的に認識してもらうための手段になると思った
  • マネジメント業による日々の心のダメージを癒やしたかった
    • 組織の課題は「重い」ものが多いので、心の力がかなり必要でどうしても疲弊しがち
• 今後は褒める側で参加予定

18. RDS for MySQLのバージョンアップ影響調査のハンドリング

• 古め(数年前)のすでにサポート期間を過ぎているバージョンのprismatixを利用している顧客環境のRDS for MySQLについてバージョンアップが必要になった
  • ある日を過ぎると自動でアップデートされてしまう
• バージョンアップによる影響が無いこと を事前に確認しなければならなくなった
  • 前述のように古いバージョンではあるが、万が一何かしらの影響があったとしても顧客のシステムを止めるわけにはいかない
• 古いバージョンのため、単にデプロイして確認ということが困難になっていた
  • 古いバージョンが動くAWS環境を維持していなかった
• CIによるインテグレーションテストを変更して動作を担保することにした
  • 元々はH2DBを用いていたが、これをMySQLを相手に実施するように変更

19. 緊急連絡先となる社用携帯番号を確保

• 休み中に顧客環境でなにかあったときなどは、Slackで連絡をもらっていた
  • 通知をミュートすることが出来るので、ベストエフォートでの反応になりがちだった
• 社用の携帯電話番号を確保して、緊急連絡先としてチームメンバーに共有した
  • クラスメソッドでは モバイルチョイス "050" を利用して簡単に社用携帯番号を払い出す事ができる

20. Sentryアラート対応プロセス改善

• Sentryアラートのトリアージを担当している部署からのエスカレーションが開発チームに届いていないケースが発生した
  • エスカレーション手順が曖昧だったため、エスカレーションされたことに気づいていなかった
    • Sentry Issueの担当者を開発チームにしただけで終わっていたため、確実に情報が届いていなかった
• Sentryアラートのエスカレーション手順を明確化した
  • SentryのIssueの担当を変えるだけでなく、Slackで担当チーム宛にメンションするようアラート対応手順書に明記し、トリアージ担当チームに共有
    • 個々のアラート別の対応マニュアルを開発チームは用意しているが、そちらではなく共有の手順書に記載

21. 新規入場メンバー受け入れ準備

• 年明けに新メンバーを開発チームで受け入れる予定がある
• そのために誰をメンターとするか、どういう手順を踏んで受け入れるか、などを各所と相談して詰めた
• 今後のメンバー入場に向けて、プロセスをまとめて受け入れコストを減らしていきたい

22. 年末年始の体制組み

• 年末年始の休業期間も顧客のサービスは動き続ける
  • もし何か起きた場合は、開発チームも調査などを行う必要がある
• 休業前にエスカレーションルートを整備してチームに共有した
  • そのための社用携帯電話番号でもあった

23. 新規案件で必要となる機能追加タスクの認識すり合わせ

• 年明け移行に受注した案件で必要となるであろうprismatixの機能追加がいくつかある
• 案件担当やPOとともに「何をして何をしないか」「何を優先するか」について認識すり合わせを実施した

24、25、26、… (たくさん)

• 引き続き球拾いたくさん
• 年明けの施策に向けての仕込みなども

その他継続中の活動

• 注文・決済チーム開発サポート
  • タスクブレークダウンとクリティカルパスを元にした優先順位付けをチームにインストール中
  • チームとしてパフォーマンスをより出せるようにまだまだ色々サポートは必要
  • 7月くらいを目処に完全に抜けられるように色々やっていく
• 開発環境不要リソース整理
  • 大体倒せたがECRイメージの大掃除が残っている
    • 使っていないものを削除する
• リリースプロセス改善
  • 理想のリリースに向けた開発チームとしての動きがまとまってきた
  • 年明けに何度か試走してブラッシュアップ
  • その後は改善し続ける
• ログ基盤改善
  • 匠チームに幾度となくPoC作成と検証を実施してもらった
    • fluentdのようなログ集約用のサイドカーを用意する形
  • 結果、今のログ量を捌くのが難しいことが判明
    • AWSリソースを相当潤沢にすればいけないこともないが料金に跳ね返ってくる
  • ログ量をへらすこともやりつつ、方針を見直し中
• 足回り改善
  • ECSで稼働するコンテナのベースイメージをAmazon Correttoに変更
    • コンテナイメージの脆弱性に素早く対応できるようになった

今後に向けて

まずは prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO の「開発チームの直近の課題」に取り組んでいきます。

その上で、まだまだ目の前の小さい課題を倒している状態から抜けられていないようにも感じています。よりチームとしてパフォーマンスを出せるよう、俯瞰した視点で考える時間も捻出していかなければならないので、自分の時間の使い方も見直しが必要ですね。

最後に

このエントリは下記の2つと合わせて、年末の三本締めでした。(都元ダイスケ が生前毎年のようにやっていましたね)

• Log4shellにprismatixがチームとしてどう立ち回ったか | DevelopersIO
• prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO

本年もクラスメソッド並びにprismatixをありがとうございました。来年も引き続き皆さんに愛される組織、プロダクトを目指して活動してまいります。

来年も良き年となることをお祈りしております！