入社1ヶ月で組織変更を任されて中止した話

本エントリはカケハシ Advent Calendar 2023 Part 2の 25 日目の記事です。ぜひ Part1 と合わせて見て頂けたらと思います。

本日はMusubi AI在庫管理プロダクト開発チームでエンジニアリングマネージャーをしている僕が、開発ディレクターとして入社した当時に進めた組織変更への取り組みについて、現状の組織の状態も踏まえて振り返ってみようと思います。

組織変更の方針

入社した当時、Musubi AI在庫管理はフロントエンドチームとバックエンドチームに分かれて活動していました。同じプロダクトを開発しているにもかかわらず、それぞれのチームは別々に活動している状態で同じ開発テーマも異なる時期に開発していることもありました。それをフロントエンド、バックエンド混合のフィーチャーチーム化するというのが組織変更の方針でした。

組織変更の背景

実は組織変更の方向性は僕が入社する前、採用面接を受けている頃から方向性として決まっていて、むしろ入社した時点で完了していないことにビックリした覚えがあります。一方で組織変更をしていない僕が、組織変更直後の混乱した時期を逃して入社したところで、チームの役に立てるのか？と言う不安もあり少しだけホッとした記憶もあります。

また当時の開発プロセスに目を向けても、プロダクトマネージャーが管理する開発中の開発テーマの1つ1つは非常に大きい上に、その開発テーマをフロントエンドチームとバックエンドチームのやる事として2つに分けた状態をユーザーストーリーとして管理されており、実際に2週間スプリントでは終わらないようなユーザーストーリーばかりがバックログに並んでいました。そしてエンジニアが実際に開発するときには、それらユーザーストーリーがタスクに切り分けられ、新入社員の僕からはコンテキストとの接続がほとんど見えなくなっていたのです。

僕はフロントエンドチームとバックエンドチームもプロダクトマネージャーもデザイナーもロールに関係なく一緒に開発することができるようになったらきっと、もっと開発の可視性は上がるだろうと考えていました。これらの状況もあり入社して1か月も経たない中で、先輩エンジニアリングマネージャーに「もう大体方向性は決まっていて、実施するだけだから」と組織変更を任された時に違和感なく引き受ける事ができました。

実際にどう組織変更を進めたのか

改めて僕が組織変更に関わり出した時期を調べてみると2023年2月20日、そして2023年2月22日にはチームに展開する方向性を検討している記録が残っていました。この記録から入社してまだ20日程度で組織変更に手をつけていたことがわかります。

さらに特徴的なのは先輩エンジニアリングマネージャーはライフイベントのため次の週から休暇に入り進め方が決まった頃に戻ってくるという流れでした。その中で僕たちはどんどん進める必要があったのです。

1週間にわたるメンバーからの意見の聞き取り

2023年2月27日からは同僚の開発ディレクターと2人でメンバーとの2on1を実施し、組織変更に対するメンバーの意見などヒアリングを進めていきました。メンバーの皆さんは組織変更を前向きに捉えてくれており、チームとしても「やっていき」文化があるからみんなで進めていこうと言ってくれる方も多くいて、入社直後でありながらメンバーの言葉に励まされながら動けていた記憶があります。また、小さな問題点や不安についても素直に話していただき、具体的なプランを練るのに必要な情報も集まっていきました。

組織変更と同時にオフサイトイベントの準備

その裏では新しい組織での活動開始は2023年3月16日と決定し、新しい組織への目的を改めて明確にして円滑なチームビルディングに繋げるキックオフオフサイトイベントを2023年3月15日に企画していました。メンバー全員が入れる会議室は会社のオフィスにはないため、人事の方にお手伝いいただき外部の会議室を借りた上で実施するイベントです。

いかに順調なスタートが切れるようにするか？上司にあたるVPoEの湯前さんと同僚との3人で必死にコンテンツを練りながら楽しく進めていました。

ある日感じた大きな違和感

そして、忘れもしない2023年3月3日の金曜日。仕事を終えた僕は、僕の中に小さくはない違和感を覚えていることに気が付きます。メンバーのほとんどから「やっていき」など前向きな意見がもらえて安心して進めているのに、なぜ僕の中に違和感があるのか分からず困惑しました。

土日もその違和感が頭から離れず、なんとなくメンバーとの会話を振り返りなんから考えていると、1つの矛盾のような共通点が思い浮かんだのです。

それは開発プロセス変更に対して疑問が多かったことです。フロントエンドとバックエンドのメンバーがそれぞれ小さなフィーチャーチームなるような組織変更をした後も、今まで個別に活動していたメンバーがより一緒に1つのものごとに取り組めるよう、開発の可視性を上げるプロセス改善しないと円滑な開発が進められない部分ありました。よりアジャイルに開発を進めるためにフロントエンドとバックエンドのメンバーもデザイナーもプロダクトマネージャーも同期的に進めるプロセスを導入する必要があると考えていたのですが、メンバーとの会話の中で僕自身がプロセス変更に難しさを感じていたのです。

上司への相談と中止の決定

2023年3月6日月曜日、僕は上司であるVPoEの湯前さんに対し相談をしました。違和感がある中このまま進めて良いものか正直悩んでいると。そこで上司からは「現場を見ている笹尾さん（僕）が危ないと感じたらやめるべきだ」と言ってもらえたんです。そして僕は翌日の火曜日に正式に中止を決定します。

やばい。オフサイトはどうする?

しかしここで問題が発覚します。オフサイトイベントは1週間後、キャンセルするにもお金がかかります。急遽、イベントの方向性を練り直し、コンテンツを作り直すことになりました。

そこでオフサイトイベントは組織変更から切り離し、僕たちにとって良いチームの形として「個々人が弱さを見せられる事は組織としての強さの表れである」という方向性を明確にした上で、メンバーの不安に隠れたチームの課題を洗い出すワークなどチームの改善につながるコンテンツを用意し無事実施できました。

改めてなぜ組織変更を中止したのか？

僕の中でチームの体制を大きく変えると言うことは、不可逆な変化だと考えています。医療に例えると外科手術的な変化。不可逆な変化は絶対に避けるべき言うわけではありませんが、より良い方に向かうと確証が持てる時に使うべき手段だと考えています。

一方で、プロセスの変更は小さく進めることで高い可逆性を維持して変化する事が可能です。外から大きな変化を加えるのではなく、内面から少しずつ良くしていく。内科医の指導に従い食生活を改善し、必要なら薬を飲んで、少しずつ体調が良くなるような活動です。やめてしまえばすぐに元に戻ってしまうような手段だとしても、何かを良くしていくことはできます。

組織システムをより良いものにするには、その両方を適切に組み合わせる事が必要です。

仮に外科的手術が必要だったり外科的手術が内科的な方法より効果が高いとしても、それに耐えられる状況を作る事が優先だし、外科的手術後に発生する内科的アプローチに対する合意が必要になります。

現場から発せられた不安

当初から現場のメンバーは組織変更のことを「組織変更」ではなく「チーム分割」と呼んでおり、フロントエンドチームとバックエンドチームが分割されてしまう危機感があることがわかっていました。その上で、今の2週間スプリントに対して1週間スプリントにしていく方針などに不安が大きいことも意見としていただきます。また、プロダクトマネージャーが管理するバックログはJIRAなのに、エンジニアはGitHub Projectsを使っている中で、どちらかに情報を寄せる事にも強い抵抗感がある事がわかりました。

これらの不安が残っている間に、いきなり大きな組織変更するのはチームとして外科的手術に耐えられない可能性を考える必要があります。そもそも、それらチームが抱える不安の背景を僕がほとんど理解できていないまま組織変更を進める事自体がチームへの裏切りのようにも感じました。

それからのチームの方向性

一度組織変更を諦めたとしても逆コンウェイ的な課題もあり、半年程度でチームをストリームアラインドな編成に変更することを念頭に入れて進める事は変わりません。しかし直近の進め方として組織変更を行わない可逆性の高い方法で進める事にしました。

具体的には大きすぎるユーザーストーリーを一緒に小さくしながら価値を明確にするとともに、プロダクマネージャーとデザイナー、エンジニアがリリースまでの流れとコストについて一緒に考える時間を増やす流れを作りました。

チームの編成も自然に変化

2023年8月頃には機能開発など個別の意思決定を早くするための手段として、フロントエンドチームとバックエンドチームそれぞれに4人以内のレーンを構成する事ができました。それら個別のレーンを2023年9月に1つ、2023年10月に1つフロントエンド、バックエンド合同のレーンとして結合させていき、2023年11月にはそれぞれのレーンにプロダクトマネージャーもデザイナーも合流してもらえるようになりました。

当初予定の3月比べて11月まで9か月ほど組織変更に時間をかけることになりましたが、フロントエンドチームやバックエンドチームの存在も残したまま、マトリックスな組織構成としてストリームアラインドなチーム編成に変化しています。

メンバーが自ら進めていく流れに

2023年9月からは同僚の開発ディレクターの提案がチームに受け入れられバックログはJIRAに統一することができ、今ではメンバー自らが使い方を考えてより良いバックログのあり方を考えてくれるようになっています。そして開発ディレクターやエンジニアリングマネージャーがチームの方針を出すだけでなく、メンバー自らよりアジャイルな状態を目指した提案が上がるようなり、2023年10月からは1週間スプリントも導入される事になりました。

当時から振り返って

エンジニアリングマネージャーが組織システムを考える時に大切にすべき考え方のいくつかがより明確になったと感じています。

まず、1つ目は勇気ある撤退の必要性。
僕たちエンジニアリングマネージャーはチームがより良い開発ができるように、より良い組織システムを作りつつ、メンバーと一緒に考えメンバーと一緒に歩むことが求められます。その目的を叶えることができないのであれば、一度決めたことでも自ら撤回する必要がある。正直、上司の「現場を見ている笹尾さん（僕）が危ないと感じたらやめるべきだ」というコメントがあっても、僕自身は最後まで撤回すべきか悩んだことは確かです。でも今は、撤回してよかった。チームの力を信じてよかったと心から感じることができています。

そして上記よりさらに大切な事は、大きな改善より、本当に些細な改善を小さな期間でたくさん積み重ねる事。
僕が入社して10か月ほどの期間の中で、Musubi AI在庫管理プロダクト開発チームには入社当時には信じられないくらいの大きな変化が起きています。それらのほとんどは現場のメンバーが起こした小さな改善の積み重ねです。逆にこの10か月間で僕ができた事は方針・方向性を出して小さな改善をお願いしている事がほとんどです。 1つ1つ小さな変化でも、とにかく短い時間でたくさん試していけば、大きな時間軸の中で大きな改善をいくつか繰り返すより大きな変化を生み出せると言う考え方はMusubi AI在庫管理プロダクト開発チームにとっても必要な考え方だと改めて実感しました。

もしあの時、無理に組織変更をしていたら

もしあの時、僕が違和感に気づかなかったり違和感を無視して組織変更をしていたら、どうなっていたのでしょうか？

実は僕が組織変更を諦めた直後に知った事実があります。Musubi AI在庫管理プロダクト開発チームには過去にもエンジニアリングマネージャー主導で似たような、よりアジャイルな開発組織になるための取り組みを実施したものの、現場とエンジニアリングマネージャーの間にあるギャップが埋まらないまま、お互いに苦しさだけが残ってしまった経験があったのです。僕はその苦しみを抱えたメンバーに寄り添うことなく「やっていき」と応援してくれるメンバーに甘えてものごとを進めていたにすぎなかったのです。

おそらく組織変更を進める事はできたとしても、開発プロセスの小さな改善を積み重ねる余裕が現場のメンバーから奪われてしまい、より良い変化を継続的に生み出す事はできなかったのではないでしょうか？少なくとも現在の開発体験や開発ロードマップへの貢献は得られなかったと思います。