この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
DevelopersIO 2022 技術で心を揺さぶる3日間 | クラスメソッド株式会社 が、昨日おかげさまで大盛況のうちに終わりました。
私も「Day3 Aトラック 14:50-15:35」のセッションで、ライブ登壇を行いました。
このエントリでは、その登壇内容について紹介し、ざっくりとふりかえってみます。
動画
資料
導入部
何を話すか
今日話すことは「新米マネージャーに降り掛かった困難と苦闘の物語」です。
一年前にプロジェクトマネージャーに、更には年明けから開発チームのマネージャーにロールチェンジするに当たり、直面した課題にどう立ち向かってきたのか、赤裸々にお伝えします。
ちなみに、この一年でやってきたことを並べると、お見せできる範囲のことだけでもこんなにたくさんありました。
今回は時間も限られているので、これらのうちのごく一部について、整理してご紹介します。
prismatixの紹介
prismatix(プリズマティクス)は「EC/CRM(Customer Relationship Management)」に特化したプラットフォームで、クラスメソッドがB2Bの自社サービスとして展開しています。我々は「エンゲージメントコマース」と銘打ち、伴走型のコンサルティングサービスとともにビジネスとして提供しています。
prismatixが解決しようとしている課題について説明します。
従来は、EC/CRMといったシステムを作ろうとした場合、フルスクラッチやパッケージを導入して、店舗、ECサイトといった単位で構築する必要がありました。このとき、新たにスマホアプリを追加したいとなったら、また新たなパッケージを使うことになり、結果として同じようなロジックが何箇所にもばらついた状態になってしまいました。また、それぞれのシステム間でデータ連携しようとすると、たすき掛けのように複雑なデータ連携が必要でした。
その問題に対して、我々prismatixは間に「データとロジックを保持するプラットフォーム」を置くことで解決しようとしています。prismatixでは店舗、ECサイト、スマホアプリそれぞれから、同じデータ、ロジックにREST APIを通じてアクセスが可能になります。また、周辺システムへのデータ連携も、prismatixからAPIを通じてデータを取得すれば良いので、構成をシンプルにできます。
また、EC/CRMに必要な「認証・認可」「商品管理」、「注文管理」、「ポイント管理」といったそれぞれの機能を「マイクロサービス」として開発、提供しているため、必要なサービスだけ利用すると言ったことも可能です。
このプラットフォームでやりたいことは、「事業者に向けた 武器屋」です。
受託開発のようなオーダーメイドでは、ビジネスとしてのスケールがどうしてもしにくい部分があります。
そこで、prismatixでは「すぐ使える武器」を提供することで、同じ問題・課題を抱えた複数の事業者に幅広く価値を提供でき、ビジネスとしてスケールさせるのが目標です。
詳しくは次のブログエントリを参照してください。
クラスメソッドのビジネスモデル転換のストーリー ～ 鍛冶屋から武器屋へ ～ | DevelopersIO
前日譚
プロジェクトマネージャーへのロールチェンジのきっかけ
それでは、まずプロジェクトマネージャーへのロールチェンジをすることになったのかについて説明します。
それは今から1年と少し前、2021年1月くらいだったかと思います。
当時、私は「注文」管理機能を中心に扱う「注文チーム」のリーダーでした。
そこにある日、ボスである石島から「ちょっと話したいことあるんだけど」みたいに声をかけられまして、そこで「開発チームまとめて面倒見る人欲しいんだけど、やらない？」と持ち出されました。
私としては、もともとやりたいことの一つでもあったので「やります」と二つ返事でOKしました。
当時のチーム状況
なぜこういう話になったのか、当時のチームの状況から説明します。
まず、prismatixの事業自体は色々なお客様に採用・支援させていただき、ビジネスを始めて4年目くらいで徐々に売上が伸びてきていました。
こちらの支援・導入事例を見ていただきたいのですが、どこかで一度は目にしたことがあるような事業者様への支援・導入をさせていただいていました。
ただその一方で、歴史的な経緯やコロナ禍による影響によって、組織の力が少しずつ弱まっている、といったことが起きていました。
これは技術的、コミュニケーション両面で起きていまして、具体的には次のようなことがありました。
- 機能追加に 以前より時間がかかる ようになってきた
- チームが細分化及び サイロ化 して流動性が低い
- (リモートワーク中心になったこともあり) 誰が何をやっているのか わかりにくくなってきた
- 気軽に話をするのに ためらう雰囲気 がある
こういった問題を解消するために、私に白羽の矢が立ったことになります。
敵は非常に強大です。
髙野に声がかかった理由
ただ、そもそもなぜ私だったのでしょうか？
それは、もともと私が持っていた プロダクトの把握状況や目指すキャリア からと聞いています。
ボスからの話のところでも簡単に紹介したとおり、私は「注文チーム」のリーダーでした。「注文」機能というのはECの中核的な機能であり、注文サービスだけでなく、認証認可、商品、ポイント、在庫、会員、決済など、他の多くのサービスと連携する必要があります。そのため、prismatixの全体像を比較的把握できている状態でした。
また、私はプログラムコードそのものにはあまり興味がなく、それより人を含んだ系―つまりはシステム―を作りたいと思っていました。ITシステムだけではなく、人とサービスをなめらかにつないで流れるような仕組みを作りたいと常々思っていました。
こういった話を2018年のジョイン前、転職活動をしているときにすでにボスに話していて、それを覚えていてもらったようです。
第１部 準備編（4月〜6月）
それでは、いよいよ準備に入っていきます。
自分の仕事を剥がす
当時の私は前述の通り「注文チーム」のリーダーでした。そこからプロジェクトマネージャーにロールチェンジするにあたって、自分がやっていた仕事をチームメンバーに渡していかなければなりません。
渡せるようにするため、まずは自分から剥がす必要があります。そのために、まずはやっていたことを洗い出してみました。それがこちらです。
！！！！！
めっちゃ多い！！！
とはいえ仕方ないので、すぐに向き直って順番に剥がし始めました。
その際、どのように渡していくかですが、属人性が高いものから優先順位をつけてトリアージしながら進めました。
- 赤: 字分の頭の中にしか無いもの
- 自分がいなくなったら動かなくなってしまう
- 複数のサービスが同連携しているか、のようなドメイン知識など
- 明文化 してメンバーに渡せる状態にするのを最優先で実施
- 自分がいなくなったら動かなくなってしまう
- 黃: やり方はあるが自分しかできていなかったこと
- 複雑な手順を理解しないといけない
- 障害時のログ調査の進め方など
- 一緒にやって 徐々にメンバーにもできるようになってもらう
- 複雑な手順を理解しないといけない
- 緑: 手順書通りにやればできること
- やることが明文化されていてシンプルだが渡していなかったもの
- リリースノートの書き方など
- 手順書を元にやり方をレクチャーしてやってもらう
- やることが明文化されていてシンプルだが渡していなかったもの
- 黒: 自分がやらなくても良いこと
- リーダーでなくてもやれること
- 機能の詳細設計やコーディングなど
- 「やりません」と宣言してメンバーのタスクにする
- リーダーでなくてもやれること
達成したいことを考える
仕事を剥がしてきて少し余裕ができたら、次は プロジェクトマネージャーとして何を達成したいか について考えました。
そのためにまずは自分が何をやりたいのか、改めて考えてみたところ、すでに述べたような Devチームを中心として系が回るようにする ことを目指そうと思いました。
このためにDevチームは、 自由自在 であることを目指していくことにしました。
この自由自在というのは「思ったとおりに 安心して使えるプロダクトを 開発・保守できる」能力を持ったチームを作りたい、という意味です。
この「思ったとおり」については、開発チームだけの視点ではなく、周辺ステークホルダーにとっても「思ったとおり」になることを目指します。
この内容については、次のブログにまとめてありますので、ぜひご覧ください。
EC/CRMの自社サービス「prismatix」開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO
障害となっていること
「自由自在であること」を目指すことにしましたが、今度はそのための障害となっていることを次に考えました。
その時に出した仮説が「Devチームと周辺ステークホルダーとの 期待値 が一致していないのではないか？」でした。
prismatix事業部には「prismatixという事業を行うため、ほぼ一つの会社に必要な機能が揃っています。そして、それらをを専門とする職能を持ったチームがDevチーム以外にも数多くあります。
EC / CRMプラットフォーム prismatix を支える組織の構成とは？ | DevelopersIO
我々Devチームもこれらのチームと協力して仕事を行いますが、そのやり取りの中で期待値のずれがあると、非常に大きな摩擦となってしまいます。
具体的に起きていたこととしては、次のようなことがありました。
- 「prismatixを使った開発」を行うフロント開発者が、ユーザードキュメントからやりたいことを簡単に見つけられない
- 中長期の開発スケジュールがあいまいで、欲しい機能がいつごろ使えるようになるかがわかりにくい
- 「リリースしました」といったときでも、必要なテストやドキュメントが足らずに、メンバーによって「完了」とみなす条件にブレがある
こういった事が今後起こりにくくなるように、活動していこうということで……
よし、なんとかしよう！
といったところで、「第１部 準備編」は終わりです。
第２部 PjM編（7月～12月)
続いて、プロジェクトマネージャーになってからの話をしていきます。
当時のチーム状況
まず、当時のチーム編成について簡単に説明します。
当時は機能領域ごとに、2,3名からなるサブチームが全部で5つありました。これらのサブチームはそれぞれでタスクの進め方が異なっていました。そのため、状況を把握するために、私の前のプロジェクトマネージャーが週次でサブチームリーダーを呼び出して話を聞き出す、といったことをしていました。ただ、その際サブチームおよびリーダーによって報告する粒度はバラバラでした。
また、各サブチームのタスクへは、それぞれサブチームに様々な顧客の要望が直接入ってくる状況でした。このとき、複数の顧客から「優先度高」のような形で依頼されることもしばしばあり、どの顧客を優先するかといった明確な尺度は有りませんでした。また、直接チームに要望が入っていくことから、それぞれのサブチームにどのくらいの要望が集まっているか、といったこともすぐにわからない状態でした。
その結果、チーム全体としての状況がわかりにくくなってしまっていました。
- 今何をやっているのか
- どこまで進んでいていつ終わるのか
- 今後何をするつもりなのか
- どんな問題を抱えているのか
問題集め
こういったチーム状況を受け、次は何が問題でそうなっているのかを考えたいと思いました。このとき 真の問題 を見つけるために、まずは目の前の問題を集めることにしました。
問題集めは、次の手段で行いました。
- Devチーム内外のメンバーと1on1で直接聞き出す
- 「なんかうまくいっていない」と思うことをスプレッドシートに書いてもらう
そうして集めた問題を書き出してみたところ、こんな感じでめっちゃたくさん出てきました。
正直「どうすんのこれ……」という気分にはなったのですが、そう言っていても進みません。
ですので、できることから対処をはじめました。そのために最初にやったのは 見通しを良くすること です。
問題解決の正攻法は「問題の依存関係を整理して 根っこの問題 を見つけ、そこから対象する」といったものです。しかし、当時はプロジェクトマネージャーになってから間もないこともあり、自分の処理能力が追いついておらず、いわゆる「パニック期」になってしまっていました。
ですので、パニック期を脱出するためにも、 足元の問題 を解消して、余裕を作ることに集中しました。
そのために行ったことのいくつかを順に説明します。
チーム再編成
まず、チームの再編成を行いました。小分けにされていたいくつかのサブチームのうち、関わりの深いチームを統廃合することで、 マネジメントコストの低下 や コミュニケーションの活性化 を狙っていました。
再編成後はこちらの4チームになりました。
- 認証・認可
- 独立性および専門性が高いので統廃合せずそのまま
- リフォームの匠
- prismatixを始めて数年で溜まった技術的負債の返済とアーキテクト、QA(品質保証)の機能を統合
- 注文・決済
- 新たな決済手段の追加などでともに取り組むことが多い注文と決済のチームを統合
- 検索・保守
- 積極的な機能追加ではなく改善が中心の保守フェーズに入ったサービス担当チームを統合
プロダクトバックログ(PBL)導入
こうして統廃合した4チームに向けて、今度はプロダクトオーナー(PO)の起案でプロダクトバックログ(PBL)を導入しました。一番の狙いは「機能追加・改善要望の優先順位の明確化と共通認識作成」です。
まず、これまで各チームに直接依頼していた要望を、プロダクトバックログアイテム(PBI)として起票して一箇所に集約します。このとき、その要望の 顧客への価値 を明確にしてもらいます。
こうして集まったPBIについて、価値と状況を元に チーム全体の優先順位 をつけます。これはPOだけではなく、Devチームや顧客担当のCS(Customer Support:カスタマーサポート)チームのマネージャーも一緒に合議で決めます。
また、要望が一箇所にまとまっていることで、その要望の処理スピードで 開発スループット がわかるようになります。常にPBIの数が増え続けるようであれば、「開発力がビジネスでやりたいことに対して足りない」、ということがわかるようになるのです。
PBL導入後のタスクは、このように進めていきたいと考えていました。
まず、すでに述べたように要望を一箇所に集めて優先順位をつけます。そして、各職能別サブチームでは、優先順位を基本としつつも、すぐに対処できるかどうか、といった工数の観点も加味して、次に取り組むPBIを自律的に取捨選択します。
そして、PBIの数が増え続けていればスループットが足りていないという判断ができるようになります。これは全体でもそうですが、職能別サブチームごとの判断もしやすくなります。開発力が足りないのであれば、チーム力強化や採用といった次の手を打つ際の裏付けに使えるようになります。
情報動機タイミングの増加
続いて、情報動機タイミングの増加に向けて、チームの状況をこまめに把握・共有する場を用意しました。
- Dev各サブチームのデイリーミーティング
- 日次で各自がやっていることや課題の共有が目的
- アジャイルプロセスのスクラムでは「デイリースクラム」と呼ばれるもの
- これまでは行っていないチームがほとんどだった
- サブチームの人数が少なかったこともある
- 日次で各自がやっていることや課題の共有が目的
- インフラ担当の Kiban チームとのウィークリーミーティング
- 開発・運用をまたいだ課題や情報の共有・相談が目的
- 部署全体に向けた週次のプロダクト報告会
- Dev各サブチームだけでなく運用、顧客担当、営業、コンサルなどの各チーム間の状況共有が目的
周辺チームとのインターフェースを整備
また、周辺チームとのインターフェースを整備しました。チーム間のやり取りについて 型化 を進め、コミュニケーションコストを低減させる目的があります。
具体的には、関連するチームと相談しながら、次のようなインターフェースについて整備しました。
- アラート対応フロー
- 顧客環境でのアラートをクローズするまでのプロセスを明確化する目的
- アラートの起点からだれが仕分け、調査、対応するかを整理
- チームをまたいだエスカレーションをどこでどう行うかについても統一したフローにまとめた
- リリースノート
- prismatix利用者や顧客担当チームに向けて必要な情報をもれなく伝達する目的
- そのリリースで何を変更したか、どのような影響があるのか、それに対して何をすれば良いのかを明記するようにガイドラインやレビュー観点を整理した
- デプロイ資料
- 運用担当に向けてインフラについての変更点を伝達する目的
- AWSリソースやデータスキーマ、システム構成の変更および影響、リスクについて明記するようにガイドラインやテンプレートを整備
- Dev週報
- 機能領域別サブチームの状況を把握・共有する目的
- 元はサブチームごとにバラバラだった報告内容について、統一したガイドライン、テンプレートを作成した
- 要望に対して必要なタスク
- その進捗状況
- 完了見込み
- その他チームとしての活動など
チームの稼働状況可視化
また、チームの稼働状況の可視化も行いました。
これまではチームの状況がわからず、進捗が出ていないときに「なんで進まなかったのか」を問い詰めるような形になってしまっていました。それは、突発的な障害や顧客問い合わせに対処していたからだとしても、そのことを把握できていなかったためでした。
この問題をなんとかするため、チームとして何に時間を使っているかの稼働状況を、大まかでも把握するため、収集・可視化を行いました。これにより、チームの負荷状況がわかりやすくなります。
この施策のネタ元は CX事業本部Consulting部の杉井さん に、prismatix事業部の開発チームをサポートしている中で伺いました。
可視化 - プロダクト開発チームの「開発テーマ」を考える | DevelopersIO
我々は杉井さんから教えてもらった「前向きな稼働(機能追加やプロダクト改善など)」、「運用に必要な稼働(定例ミーティングやログ調査、問い合わせ対応など)」、「後ろ向きな稼働(障害対応やその再発防止に向けた作業など)」に加えて、「刃を研ぐ稼働」、つまりは個人の成長やプロダクトの発展に向けた学習などの活動に関する時間も収集することにしました。
その収集結果をまとめて可視化したのがこちらのグラフです。一番上が「前向きな稼働」の割合です。可視化しただけではありますが、段々とその割合が大きくなってきており、「前向きな稼働」に使える時間が少しずつ増えてきている、といったことが見て取れます。
これらが何だったのか
これらの施策が何だったのかな〜と今振り返ると、
自分とチームの認知負荷低減 をしていたのかなと思っています。
この「認知負荷」については、 チームトポロジー (マシュー・スケルトン、マニュエル・パイス(著)、原田騎郎、永瀬美穂(翻訳)、吉羽龍太郎(監訳)、2021年、日本能率協会マネジメントセンター) という書籍に書いてあります。人が処理できる情報の量には限りがあるが、それはチームの場合も同じで、チーム全員の認知容量の合計を超えることはできない、といったことが説明されています。
この制限を無視し続けるとどうなるかというと、チームがデリバリーのボトルネックになってしまい、遅延や品質低下だけでなく、チームメンバーのモチベーション低下にもつながってしまいます。
当時のチームではまさに認知負荷がオーバーした状態だったのを感じて、各種の施策をやったのだなと、ふりかえって気が付きました。
そして次のステージへ
こうして色々やった結果、
少し見通しが良くなり、チームの状況が以前よりは把握できるようになってきました。
こうしてプロジェクトマネージャーとして活動していて、年の瀬も迫ったある日に、
今度は当時のDevチームマネージャーやっていた塩谷(かっぱ)さん(@kwappa)に呼ばれまして、「もうほぼマネージャーみたいなことしてるし、年明けからマネージャーよろしく」と言われました。
私としても、あらゆることを使ってなんとかしていたのがもうプロジェクトマネージャーの範囲に収まっていないことを自覚していたので、もう「やります」と返事をしました。
そんなこんなで、プロジェクトマネージャーとしての戦いを終え、舞台は次のステージに移ります。
といったところで、第２部プロジェクトマネージャー編は終わりで、次のDevマネージャー編に進みます。
第３部 DevMgr 編（1月～現在、そしてこれから）
いよいよDevマネージャー編として、1月から現在、そしてこれからについて話をしていきます。
チームの状況がかなり把握できてきたので、いよいよ本丸の問題へと取り組んでいます。中でも次の3つについて、主に取り組んでいます。
- 組織のコミュニケーション
- チームの力
- エンジニアリングマネジメント
チームトポロジーとの出会い
そんな中で出会った書籍が、先程も紹介した「チームトポロジー」です。
詳しく内容を知りたい方は、実際の書籍を手にとってもらうのが一番良いですが、監訳者である @ryuzee さんの「30分で分かった気になるチームトポロジー | Ryuzee.com」というスライドや、この資料を使った講演の YouTube動画 やその文字起こしの下記ページを見てもらうと、大雑把につかめると思います。
Team Topologies Study 1部 30分で分かった気になるチームトポロジー | エンジニアの生き様をウォッチするメディア
簡単に言うと、「逆コンウェイ戦略」を用いて「チームファースト」で「チームに仕事が流れ込むようにする」、そして「認知不可に合うように責任範囲を制限する」といった方法で、チームのパフォーマンスを上げようという考え方です。
また、価値提供のために4つのチームタイプを使い分け、メインとなるチームの負荷が下がるようにほかのチームがサポートしようだとか、チーム間のインタラクションを「コラボレーション」、「X as a Service」、「ファシリテーション」の形で行いましょうといったことが書かれています。
これを見て、マネージャーになって少し拠り所ができ、なんだかやれるような気になることができました。
では、具体的な内容に入っていきましょう。
組織のコミュニケーション
まずは「組織のコミュニケーション」です。
こちらについては「一体感 を持って価値提供にチームで取り組む」といったことをやりたいと思っています。
そのために、今以上になめらかに情報が流れるようにして、Devチームとその他の職能別チームの間で 摩擦を減らす ことを意識しています。
また、メンバーそれぞれが個人で頑張るのではなく、チームによる問題解決を目指しています。これまでは「依頼→提案」ベースのインタラクションが多かったのですが、これだと依頼した方は提案されたものをどうしても批判的に見てしまいます。そうではなく、雑に相談してともに答えを探索する、といったやり方にしていきたいです。
そして、これらを実現するために、高い心理的安全性を持った状態に持っていきたいです。kwappaさんいわく「カジュアルにやばいことが言える」間柄になれるよう、色々やっています．
以上を踏まえて、今のprismatixの価値提供の流れについてどうなっていて、今後どうしていきたいかを話していきます。
今のprismatixでは、顧客の要望を顧客窓口担当のCSチームが受け取り、開発担当のDevチームが開発し、リリースしたらインフラ・運用担当のKibanチームに連携して顧客に提供する、といった形で行っています。そして、各チームがお互いをプラットフォームのように利用している状況です。
そのため、チーム間はいわゆる「X as a Service」のインタラクションモードを使い、ドキュメントや作業チケットなどの「チームのAPI」に頼ったやり取りを行います。
このAPIがお互いに使いやすいものであればよいのですが、 貧弱なAPI でありそこだけでやり取りを行うことで、問題が発生します。具体的には、顧客への価値提供がすんなりいかなくなったり、アラート対応に時間がかかったり、といったことです。
そこで、ここからどのような形に持っていくべきか、理想の価値提供の流れを元にチーム構成を考えてみたところ、まずはCSチームと DevOpsチーム の2つにしてはどうかと考えました。
DevOpsチームは、「チームトポロジー」で言うところの ストリームアラインドチーム になり、単一のチームで価値提供に必要な開発と運用を行います。このようにすることで、CSチームは単一のDevOpsチームとだけやり取りを行えば良くなります。
DevOpsストリームアラインドチームに向けて
「ストリームアラインドチーム」が何かについては、書籍から引用します。
「価値のある単一の仕事のストリームに沿って働くチーム」であり、「チームには権限が移譲」されています。また、「ほかのチームへの引き継ぎが必要ない」形を目指しており、価値提供を担う中心のチームです。
とはいえ、今のDevとKibanが分かれたチーム構成から、一足飛びにこの形にはできませんので、段階的に変化させていく予定です。そのため、まずは DevとKibanの橋渡しとなるSREチーム をKibanチームのマネージャーとも連携しながら新設しました。
このSREチームは頻繁にDev/Kibanチームとコラボレーションすることで、徐々にDev/Kibanの間の垣根を低くし、一つのチームとして統合させる役割を持っています。
将来的にはSREチームの活動によって、1,2年後くらいにはDevとKibanが統合して、ひよっこのDevOpsチームにしていきたいと考えています。ただ、まだまだ「ひよっこ」ですので、SREチームは引き続き伴走しながらサポートを続けていきます。
そして、最終的に―おそらく早くても2,3年後くらい―にはSREチームもDevOpsチームとして統合され、真のDevOpsチームとして独り立ちできればと思っています。この活動の中で、CSチームとの間のAPIも洗練させ、スムーズな情報のやり取りができることも目指したいです。
チームの力
次に、チームの力についてです。
こちらについては 事業でやりたいことができる 力をつけていきたいです。
そのためには、価値提供の量、スピード両面の向上により、価値提供を素早くたくさんできるようになることや、使いやすいプロダクトにするために本番からのフィードバックをプロダクトに反映し改善できること、また安心して使える品質を目指し、機能面/非機能面両方で高い品質を維持できるようにしていく必要があります。
そのためには開発チームの各サブチームの力を向上させる必要があります。ですので、開発力向上のファシリテーターとなる イネイブリングチーム を新設しました。イネイブリングチームはコラボレーションもしますが、メインとなる活動はチームの力向上のファシリテーション―促進させる活動―です。
イネイブリングチーム
この「イネイブリングチーム」という名前も、チームトポロジーで紹介されているチームタイプの一つで、
"ストリームアラインドチームが、使えるソフトウェアをタイムリーかつ持続可能に届けられうように支援"
するミッションを持っています。
具体的にはストリームアラインドチームの自律性を高めるために、自らが学び、その内容をファシリテーションでチームにインストールしていくといった活動を行います。
我々のイネイブリングチームの活動は、現在のところ 品質・スキル向上活動 に主軸をおいています。
例えば、モブプログラミングを導入し、チームのフロー効率向上や「チームで取り組む」空気づくりをしたり、保守性の向上のため、変更容易性の高いテストやプロダクトコードの書き方をチームと一緒に作ったり、いわゆる「シフトレフト」のため要件定義など早い段階からチームが品質に向き合うようにする活動を行ったりしています。
モブプロ導入については、ブログエントリにもまとめているので、ぜひご覧ください。
チームにモブプログラミングを導入してみた | DevelopersIO
エンジニアリングマネジメント
最後に、エンジニアリングマネジメントの領域についてお話します。
この分野については 楽しく働けて成長できる 環境を作るのを目的としています。
そのためにも、組織とメンバーの目的の方向性を一致させ、組織の目的がメンバーの目的をサポートできるような活動を行おうとしています。
また、健康な組織に向けて、一部のメンバーに負荷が集中することなく、着実に成果を出せる体制やアサイン計画をたてるよう頭を悩ませています。
最後に、評価および査定についても、組織とメンバーの双方が合意し納得できるよう、評価基準を明確にする活動もしています。こちらについては、クラスメソッド全社でも取り組みを始めています。
この領域については主に私の活動が中心になるので、 1on1 と 採用 を頑張っています。
1on1
まず、1on1については 傾聴 することで、メンバーから情報を引き出すように気をつけています。人となりや志向の把握、そこから目指すキャリアに向けた目標設定、心身の健康状態の把握、そしてマネージャーである私へのフィードバックを、 問い掛け により引き出すようにしています。
このやり方については、下記の書籍なども参考にしています。
- 問いかけの作法 (安斎勇樹(著)、2021年、ディスカヴァー・トゥエンティワン)
- エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド (Camille Fournier(著)、及川卓也(まえがき)、武舎広幸・武舎るみ(翻訳)、2019年、オライリージャパン)
採用
続きまして採用についてです。
こちらは純粋に 仲間を増やしたい という気持でやっております。
そのために、「prismatix」というプロダクト、組織をエンジニアに知ってもらうための認知向上活動や、各種人材データベースを使ったスカウト活動、また採用に向けた面接の整備や採用に至った後のオンボーディング設計など、「採用」という領域で必要なことを徐々に拡充、強化してる最中です。
この活動については、エンジニアリング統括室の 田部井(てぃーびー) さんが書いた、 ITエンジニア採用入門 を参考にしたり、直接田部井さんに相談したりしながら行っています。
以上大きく3つの活動を紹介しましたが、とはいえこれらについてはまだまだ途上です。
よって、実現に向けて目下奮闘中です、ということで、第3部Devマネージャー編を締めようと思います。
まとめ
それではまとめです。
この1年は 良いチームを目指して 試行錯誤しながら全方位に向けて本当に色々やってみたなと感じています。今回紹介できたのはほんの一部で、小さなものから大きなものまであらゆることをやってきました。
その中では、一つ課題を解決するとどんどん次の課題が見つかるというようなことがよくありました。ただ、それは 前に向かって進んでいる証拠 でもありますので、ポジティブに捉えて進んでこれました。
そのように取り組めたのは、もちろんチームが良くなることが嬉しいということもありますが、自分のキャリアにとってもプラスになるという面は否めません。最近は色んな所で強い組織を作郎としている話をよく聞きます。そういった経験を積むことで、自分の市場価値と高めることができるロールを経験できていると思っています。
最後になりましたが、
もし、「prismatix」というプロダクト、組織に興味を持ってもっと知りたいということであれば、組織のことがわかるようなブログエントリを用意していますので、そちらをご覧いただければと思います。
prismatix(プリズマティクス)事業部のことがよくわかるWebページやブログエントリ、YouTube動画 n選 | DevelopersIO
また、もっと詳しく話を聞いてみたいなどあれば、カジュアル面談プラットフォームの Meety でカジュアル面談を公開していますので、そちらからお気軽に申込ください。
フルリモートでマイクロサービス開発チームのマネージャーってどんな感じ？ - クラスメソッド株式会社の中の人のカジュアル面談 - Meety
そして、大事なことですが、prismatixの事業とともに成長できる仲間を絶賛大募集中です。
募集しているポジションについては、「プリズマティクス株式会社」の採用ページで公開しております。こちらのポジションは、いずれもクラスメソッドの社員としての採用ページへリンクされています。ぜひ、お気軽に応募いただければと思います。
以上、prismatix事業部 Devチームマネージャーの髙野がお送りしました！
Q&A
Q. 期待値調整する際、どこに気をつけてどうやっているか？
A. 問いかけをベースに対話を通じて相手から引き出す
- まずはとことん聴く
- 「何を求めていたのでしたっけ？」を問いかける
- 返ってきたもので曖昧なところがあったら、それを明確にする質問を重ねる
- 問いかけをベース に相手から引き出す
- 引き出したものは箇条書きなどで明文化
- ニュアンスに違いがないかなどをお互い合意できるまですり合わせる
- 議事録を画面共有しながら 一緒に合意をつくる のもよくやる
- 問題 vs 私達の構図になりやすい
- お互い同じものを見ながら違う視点で意見を出しやすい
Q. 施策がチームにあっている、あっていないの判断(撤退判断)はどうしていたか？
A. 施策に期待した効果が出ていなければ撤退
- 施策を始める前に自分なりに こうなるはず を考えている
- 思ったとおりにならなければ撤退する
- とはいえ KPI を元に定量的に判断といったことはできていない
- 現時点では 自分の肌感覚に頼ってしまっている
- 今回は紹介していないが、 やったけど上手く行かなかった施策 はたくさんある
- 例) Devチームリーダーを週次で集めて報告会を実施
- その場でチーム感の調整などが行われることを期待していた
- 実際はただ順番待ちして自分の分を話すだけになってしまった
- 状況把握の場と調整の場は分けたほうが良いという学びになった
- 例) Devチームリーダーを週次で集めて報告会を実施
参考資料
登壇にあたって参考にしたエントリ、URLなどを紹介します。
- prismatixについて
- Devチームマネジメント
- prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO
- prismatix開発のプロジェクトマネージャーから開発チームのマネージャーにクラスチェンジする話 | DevelopersIO
- 開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
- 開発チームのマネージャーになるまでにやったことm連発 | DevelopersIO
- prismatixの開発チームのマネージャーになってからやったことl連発 | DevelopersIO
- チームにモブプログラミングを導入してみた | DevelopersIO
- Log4shellにprismatixがチームとしてどう立ち回ったか | DevelopersIO
- 採用
- 書籍
4
