みなさん、こんにちは！ 2020年からkubellでPHPエンジニアをしているやまごし(@ymgn_ll)です。
あっという間に12月、師走さんも早く出番が来てほしいからってダッシュで急いで来すぎじゃないでしょうかね。
この記事はkubell Advent Calendar 2025 シリーズ2 の16日目です。
kubell - Qiita Advent Calendar 2025 - Qiita
さて、タイトルの「プロセスマスター」に聞き馴染みのない人もいるんじゃないでしょうか。
「スクラムマスターじゃないの？」という声も聞こえてくるようです。
それもそのはず、これは私たちのグループが独自に定義した、完全オリジナルの役割だからです。
なので既に知ってるほうが驚きですし、もしあなたが知ってるものがあっても、それとは完全に別物ですのでお気をつけください。
そんな独自の役割がなぜ生まれたのか、どういうことを1年してきたのかについての記録をここに残そうと思います。
この記事はこんな方におすすめです
- チーム統合や急拡大による「組織のカオス」に直面している方
- マネージャーだけではケアしきれない「チームとチームの繋ぎ目」をどう強くするか悩んでいる方
- スクラムマスターとは一味違う「プロセスマスター（PcM）」という役割に興味がある方
巨大な塊「サーバーサイド開発グループ」の誕生
時計の針を少し戻して、今年の1月（2025年1月）。
kubellのエンジニアリング組織に大きな変化がありました。
これまで別々に動いていた5つのサーバーサイド領域のチームを再構築して、
「サーバーサイド開発グループ（通称: SSG）」という一つの巨大な「塊」として生まれ変わることになったのです。
組織図上はA・B・Cの3つのグループに分かれていますが、これはあくまでマネジメント上の理由が大きく、実態としては「サーバーサイド領域のエンジニアが集まる20名以上の連合軍」です。
この組織変更の狙いとしては、将来的にチームごとに偏っていた業務負荷やナレッジを偏りない状態にすることで、A/B/C のどのチームでもサーバーサイド領域の運用保守や施策開発を実施できるようにし、
プロダクトを成長させつつシステムも堅牢に運用できるようにする組織に進化させることでした。
しかし、言うは易く行うは難し。
文化も、運用の「お作法」も、技術的なバックグラウンドも異なるチームがいきなり「今日からワンチームです」と言われても、すぐに足並みが揃うわけではありません。
発足したての1~2ヶ月は、正直に言って「カオス」でした。
「オンコール体制はどうする？」「どこまで共通化する？」「チケット管理もどうやる？」といった運用ルールの未整備に加え、以前のコンポーネント単位で分かれていたチーム時代の「知識のサイロ化（属人化）」による弊害も色濃く残っていました。
この巨大な変化の中で、エンジニアリングマネージャー（EM）だけで全ての歪みをカバーするのは物理的に不可能です。
そこで新設されたのが、前述した「プロセスマスター（以下、PcM）」という役割です。
プロセスマスターの誕生
「プロセスマスター」という名前は、我々は現状スクラムをやってはいないが、スクラムマスターのように(SSGを一つのチームとして)観測してチームのために動いてほしい、
というところから、チームの開発プロセスを改善していく役割、という事で当時の上長が名付けました。
「プロセスマスター」なんて大層な名前がついていますが、実態は「チーム間のボール拾い役」兼「便利屋」のような泥臭い役割です。 カッコいい必殺技があるわけではありません。
実際にプロセスをマスターできていたかというとわかりませんが、他と被らない名称ですし覚えやすく呼びやすかったので、結果的に良い命名だったんじゃないかなと思います。
ちなみにこのPcMは専任のロールではなく、あくまで開発業務と並行して活動する「兼任」の役割です。
そのため、日々の開発タスクもこなしながら、組織のための活動も行う。なかなかハードな役割でもあります。
このPcMという役割を作るとなった時、SSG内で公募が行われました。
私は2020年の入社以来（当時はChatwork株式会社）、幾度もチームを移り変わりながら組織の変遷を見てきました。
「チーム運営こそが開発の質とスピードを決める」と思っている私は、このカオスを前にして「自分にとって、そして組織にとってまたとない経験になる」と確信し、自らPcMに手を挙げました。
最終的に、PcMの体制は A・B・C それぞれのチームから1名ずつ代表を選出した「スリーマンセル（3人組）」でスタートすることになりました。
スリーマンセルと言うとカッコいい呼び名ですが、要は「1人だと心が折れるから3人で支え合う」というリスク分散の体制です。ちなみにこれは大正解でした。
カオスの正体と「3名ローテーション体制」の構築
PcMとして活動を開始して最初に着手したのは、目の前のタスクを片付けることではありません。
それは、「私たちは何のために存在するのか？」を定義することでした。
ただの「雑用係」になってしまっては、組織を変えることはできない。
そう考えた私たちは、まずEMがPcMに求めていることなどをヒアリングした後、3人で「インセプションデッキ」を作成し、徹底的に議論しました。
そこで導き出したPcMのミッションは、
「SSGが継続的にベネフィットを出せる組織にする」
というもの。
これを指針に、私たちは動き出しました。
実際、20名を超える大所帯では、EMだけではどうしてもケアしきれない「チーム間の繋ぎ目」が生まれてしまいます。
特に上半期は、複数チームの統合による混乱に加え複数のEOL対応が走り、新規開発どころではない「守り」のフェーズ。
カオスの中で各チームが余裕をなくし、視野が狭くなりがちな状況で、私たちPcMは以下の仕組みで組織を支えました。
カオスに抗うために取り組んだ5つの「仕組み」
1. 「PcMよもやま会」
毎週、PcMの3人だけで集まる時間を設けました。
ここは公式な報告の場ではなく、「うちのチーム、ちょっと空気が重いかも」「このプロセス、ABC間でうまくできないかな？」といった、チャットには残らない「生の情報」を共有する場です。
ここでキャッチした予兆を、即座に「EM×PcM定例」へエスカレーションする。この「情報のハブ」としての機能が、初期の混乱を最小限に抑える鍵となりました。
2. 「EM×PcM定例」による素早い連携
PcMよもやま会を行った翌日には、EMとPcMを交えた定例を開催するように設定しました。
「よもやま会」で出た話題や改善案を、熱が冷めないうちにEMへ連携する。このリードタイムの短さがポイントです。
これにより、現在SSG全体で起こっている懸念や問題点などをすぐに拾い上げ、スピーディーな改善につなげることができました。
3. SSG定例のファシリテーション
毎週開催しているSSG全体定例のファシリテーションはPcMが担い、3人でローテーション化しました。
PcMの誰かが休んでも、他のPcMが自然とカバーに入る。
この「属人化しない体制」自体が、発足時にSSGが目指そうとしていた姿のプロトタイプ（模範）でもありました。
4. 書籍をベースにした「チームサーベイ」
SSG結成時の目標である「サーバーサイド開発グループとしてワンチームになる」が達成できているかを計測するため、独自のサーベイを実施しました。
内容は書籍『あなたのチームは、機能してますか？』を参考に設計しました。
www.shoeisha.co.jp
工夫した点は、「自分の所属する(A/B/C)グループをチームとした場合」と「SSG全体をチームとした場合」の2つの視点で値を取るようにしたことです。
結果として、「SSG全体」と「自チーム」の数値がほぼ同じチームもあれば、「SSG全体」の数値が低く「自チーム」の数値だけが高い（内向きな）チームもあるなど、面白い傾向が見えてきました。
また、このサーベイ運用では「透明性」を最も重視しました。 回答は心理的安全性を保つために匿名とし、集計結果はクローズドにせず、毎月メンバー全員に展開しました。
PcMが分析するだけでなく、メンバー自身にも自分たちのチームステータスについて考えてもらう。
このサイクルを作れたことで、数値は私たちの体感とも一致し、今後の組織像（ToBe）を考える上で非常に重要なデータとなりました。
5. 「目安箱」の設置
実は当初、全員参加型の「オーバーオールレトロスペクティブ」を実施していたのですが、人数が多すぎたのかメンバーから発言が出ず、形骸化してしまいました。
そこで、「全員で話すのが難しいなら、声を上げられる場所だけでも作ろう」と切り替え、Googleフォームによる「目安箱」を設置しました。
この取り組みで大きな議論の場が作れなくても、小さな「困りごと」を非同期で吸い上げる口を用意したことで、こぼれ落ちる意見を拾えるようにしました。
現場の観察から生まれた「合宿」
様々な仕組みを回し始めた上半期の5月頃。 私たちPcMは、日々の活動の中である「危機感」を抱いていました。
SSG発足から4ヶ月が経ち、新入社員のジョインに加え、業務委託のパートナーさんを含めると相当数のメンバーが入れ替わっており、組織の顔ぶれは変わり続けていました。
社内のオフラインイベントなどで顔を合わせる機会は多少ありましたが、業務委託の方まではカバーしきれておらず、
全体として見ると「隣のチームの人の顔と名前が一致していない」「そもそも挨拶すらできていない」 という状況が散見されていたのです。
決して仲が悪いわけではないけれど、必要以上に連携を取ろうとしないし、どこか踏み込みづらい空気が漂っている。
「このままでは、組織図上は『SSG』という一つの『大きいチーム』だけど、実態は互いに無関心な『ただのグループ』になってしまうのではないか？」
「本当にみんなで目指したい方向についての認識は揃っているんだろうか？」
この課題感は、現場にいる私たちPcMが日々のメンバー同士のコミュニケーションを観察する中で「まとまりきらないもどかしさ」として感じ取った所から来たものでした。
そこで私たちは先手を打ち、6月末に地方のメンバーも会社のイベントで東京に集まるタイミングにあわせてSSG合宿（1day オフサイトミーティング）を開催することを決めました。
目的はシンプルに「チーム横断での関係構築」。
特に、普段のイベントではカバーしきれない業務委託メンバーも含めた「SSG全員」で膝を突き合わせて対話することに主眼を置きました。
「誰に聞けばいいか分からない」というタイムロスや、PRレビュー依頼時の心理的ハードルを下げるためには、最低限の「顔と名前の一致」が必要不可欠だと判断したからです。
その際、私が旗振り役となり、コンテンツを設計したり準備を行いました。
そうして迎えた合宿当日。業務委託メンバーも含め、ついにSSG全員がリアルで顔を合わせることができました。
発足から約半年を経てようやく「チームの垣根を超えた挨拶」が実現し、チャットや画面越しでは分からなかった互いの「人となり」を知る、本当に良いきっかけになったと思います。
合宿に参加したいち個人の感想としても、オンラインとリアルの印象のギャップを埋めることができたり、目指したい方向性について膝を突き合わせて話せたことで、その後のコミュニケーションが非常に取りやすくなったと実感しています。
「サブチーム化」と、突きつけられた現実
合宿で「顔が見える関係」の土台は作れました。 しかし、現実はそう甘くはありませんでした。
下半期に入ると、会社全体として複数のプロジェクトを同時進行させる必要があり、A・B・Cの各チームの中でさらに担当が分かれ、実質的に「サブチーム」のような小さな単位で動く体制へと移行したのです。
合宿で作った「横の繋がり」が育ちきる前に、業務的な「構造の分断」が来てしまった。 その影響は、仕組み④「チームのサーベイ」の結果として残酷なほど正直に現れました。
合宿後もスコアが劇的に改善（V字回復）することはなく、むしろ秋にかけて「信頼」や「結果への責任」といった項目で、チームごとにじわじわとした停滞が見え始めたのです。
正直、合宿をやった身としては「これだけやったのに、数値は上がらないのか……」という無力感を感じなかったと言えば嘘になります。
しかし、逆に言えば「合宿という大きなイベントもってしても、構造的な分断の影響は埋めきれない」という事実が明らかになったとも言えます。
もし数値を計測していなければ、「合宿やったし、みんな仲良くなったよね」という希望的観測で終わっていたかもしれません。
PcMとして「数値を測り続けていた」からこそ、私たちは「合宿は特効薬ではなかった」という現実を受け止め、次の一手を考え続けることができているのです。
実際に下半期には、この現実を踏まえてPcMとEM合同での合宿を複数回実施しました。
そこで「今のSSGの限界」と「次に向かうべき姿」について膝を突き合わせて議論し、そのアウトプットが来期の組織再設計の重要な検討材料にもなっています。
苦い現実から目を逸らさず、次の設計図を描くことに貢献できたのも、PcMという役割があったからこそだと思います。
おわりに：1年間の「実験」を経て
振り返れば、5つのチームがいきなり統合するという、会社としても前例のない巨大な組織変更でした。
正直なところ、カオスでした。 理想通りにいかないことばかりで、打った施策がすべてハマったわけでもありません。
しかし、この1年間を崩壊せずに走り切れたのは、間違いなく「PcM（プロセスマスター）」という役割が機能したからだと自負しています。
マネージャー（EM）は、評価やピープルマネジメント、事業との接続で手一杯になりがちです。
だからこそ、その「現場にいながらにして、チーム全体を俯瞰できる」PcMのような存在が大事なのだと思います。
- 現場の「生の声」を拾うセンサー機能
- 組織の「健康状態」を測るサーベイ機能
- チーム間を繋ぐハブ機能
これらを、A・B・Cそれぞれのチームの最前線にいるPcMが「スリーマンセル」で担う。
1人では心が折れていたかもしれないけれど、3人いたからこそ、ローテーションで支え合い、客観的な視点を保つことができました。
プロダクト開発をより良く進めていくために、組織の形や体制はこれからも変わり続けていくはずです。
その時、プロセスマスターという役割がそのままの形で継続となるかはわかりません。
それでも、この1年で「カオス」に向き合った経験がある限り、どんな変化が訪れてもそれを糧にし、私たちは乗り越えていけるでしょう。
形は変われど、この1年で私が得た「組織を俯瞰する視点」や「横断的に課題を解決する経験」は、エンジニアとしての大きな財産になりました。
カオスを恐れず、分断を繋ぎ、チームを1つにする。
そんな役割が、これからの開発組織にはもっと必要になってくるのかもしれませんね。
最後におしらせです。 kubell では、こういった「カオス」すらも楽しみながら、組織とサービスを成長させていける仲間を募集中です。
少しでも気になった方は、ぜひ下のリンクから話を聞きに来てください！
明日は25新卒の中川さん（@nkgw-dev）と料金プラングループのエンジニアリングマネージャーをされている久村さん（@hisamura333）の記事になります。お楽しみに！
