CX事業本部の1年目を組織の観点で振り返ってみる

2020.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CX事業本部の阿部です。創立記念日なので、ふりかえり的な記事を書いてみたいと思います。

CX事業本部設立から1年が経ちました

お客様のプロダクトに関わり、ビジネスの成功を支援することをミッションとして部門統合して立ち上がったCX事業本部ですが2020年7月から2年目に突入しました。 この1年は、四部門統合という組織規模の急拡大に伴う各種課題を洗い出しながら対応し、足場を作った期間だったと思います。

1年目のふりかえり

このふりかえりはCX事業本部の1年目の組織の形の変遷を振り返っていきたいと思います。

フラットな組織の困難さ

2019年4月〜6月の準備期間に新しい体制のマネジメント中心に議論を行い、CX事業本部をスタートさせました。

当初はチーム制を導入しておらず、固定化された組織ではなく各案件が緩い繋がりとして配置し、横軸に職種での繋がりを持つフラットな形を目指しています。 Spotifyモデルに見られるマトリクス型の組織です。 その中で、各案件にはなるべく多くの権限を委譲し、案件リーダーの判断で多くのことができる形を理想としています。

これは、100人規模でメンバーがいる中で階層化やサイロ化を避けながら、ビジネスや組織の課題にスピード感を持って柔軟に対応することを想定したものです。 私はこの段階では、横軸の中のエンジニアロールの整備に携わっていました。

私たちもこの体制に絶対の自信があったわけではなく、あくまで理想的な形とその仮説に基づいてのスタートでした。

ただ、これについては制度面でハマるやり方が見出せなかったことと、我々自身がコミュニケーションパスの爆発的な増加に対応しきれなかったため、発足後半年の間に以下のような課題が出てきます。

  • 各案件で技術スタックが大きく異なることもあり、横軸で共通した活動を強く推進する動機が見出せなかった
  • コミュニケーションパスが爆発的に増えた結果、逆にフラットな場での発言が難しくなってしまった
  • 関係する案件でのコミュニケーションは密にされていたが、固定化されている組織でないことでクローズドなコミュニティになってしまった

もちろん、この中で様々な実験を行いましたが、どれも決めてにかけていた時期です。

このままでは、CX事業本部が出すことのできる価値が案件の価値の総和になってしまい、部門統合の意義自体が見出せなくなってしまうため、ここで方向転換を行います。

チーム制の導入

この時点で、私の役割はいわゆるマネージャ像からはだいぶ離れてきています。

リモートマネージャを1年やった振り返りと新しい肩書きについて

以前書いたエントリですが、これをより洗練させていった感じです。

案件やチームのマネジメントを役割の主体とするのではなく、CX事業本部がビジョンやミッションにしたがって理想とする動き方ができるように様々な制度や仕組みの設計や実装、メンテナンスをすることに主な役割が移っています。

さて、様々な課題が出たCX事業本部の上半期を踏まえて、下半期では事業ターゲットに基づいたチーム制を導入しました。 それぞれ課題に対して、以下のような解決を測ったものです。

  • 技術スタックは事業ターゲットごとに似通った形になりやすく、チーム内での技術情報のやりとりはむしろ活発にできる
  • チームごとにマネージャをたててハブになることで、コミュニケーションパスの数が個人から見て多くなりすぎない状態を維持できる
  • 組織図上にもチームが明確にあることでパスが明示され、コミュニティがブラックボックスになりづらい

現在では、ビジネスとデザインを含めた11のチームに分かれて活動しています。 各チームのマネージャは予算や採用、アサインについての権限をもち、事業ターゲットの中で直面する課題に柔軟に対応できることを目指しました。 チーム制を導入して半年ほど経ちますが、チーム内でのコミュニケーションについては少なからず改善されたものと思います。

ただし、これについては各チームがサイロ化するリスクを内包しています。この点については今後の課題になると思います。

採用、評価プロセスの整備

これらの組織の形についての活動とは別に、採用や評価プロセスの整備も同時に行っていました。 以前に書いた二次面接の流れは、その中で整備してきたものについて発信したものです。

CX事業本部のエンジニア採用について

採用に着手したのは、私自身のサーバーレス開発部マネージャの経験を経て、マネージャがメンバーとオンサイトで仕事をしない状況というのは今後増えていくという前提で、以下のようなことに対応していく必要があると考えているからです。

  • 統治と監視によるマネジメントではなく、ビジョンや文化に基づいたマネジメントが必要
  • ビジョンや文化に基づいたマネジメントにおいては、メンバーを信頼し、アウトプットを評価する必要がある
  • 信頼して仕事を任せるために、セルフマネジメントができることをメンバーの要件とする

これらをCX事業本部全体の方針として出しつつ、各チームで細かい要件(スキルがフィットするか、チームの雰囲気にフィットするか)にも対応できるようにプロセスを整備しました。 まだまだ改善の余地はありますが、ひとまず昨年度中に制度をスタートして、実施経験を積むことはできました。

次に評価プロセスについてですが、以下の2点について整備しています。

  • 各職種ごとの評価基準の整備
  • プロセスの明文化と透明化

特にエンジニアの評価基準についてですが、文化面とアウトプットを重視したものになります。文化面はCLPを下敷きにしています。

なぜ文化面のような曖昧にも取られかねないものを評価基準として重視したかというと、私たちが大事にしている価値観こそが私たちが今の価値を出せている基盤になっているという仮説に立っているからです。 そして、文化が価値に繋がっているのであれば、それを体現してアウトプットを出している人は高い評価を得るべきだという考えがあります。

これも先日一回目の施行を終えたばかりで、改善すべきポイントもいくつか見えてきました。 評価自体は年一回になってしまうため、今年度の終わりに次の改善をすることになりますが、より良いものを目指していきたいと思います。

個人として

クラスメソッドという会社において、エンジニアリングで顧客に価値を提供することに携わらない仕事というのは面白さがあるものも、所々自信が揺らぐ局面がありました。 私の人件費は完全に間接費ですし。

しかも、チームのマネージャという形ではなく、間接的に関わっていくちょっと形容し難いロールということもあり、仕事のスタイル自体を見直す必要を感じながらの1年となっています。 試行錯誤で制度自体が行ったり来たりする部分もありましたが、個人としては新しいロールの形を模索する良いチャレンジができました。 自分が言い出した部分もありますが、このチャレンジとロールを許容してくれた部門長に感謝します。

2年目に向けて

組織的にはチャレンジが続きます。 今期取り組むことは大きく以下です。

  • チーム間のコラボレーションの促進
  • 新卒の部門配属準備
  • 採用/評価のプロセス改善
  • 各種マネジメント業務の自動化

1年目で出てきた課題に対して、より良い形に持っていくようにさらに改善するフェーズかな、と思っています。