しゅん

2025年8月から、データ基盤側のBIユニットでエンジニアリングマネージャーとして、BIアプリケーション開発チームとデータエンジニアリングチームの2チームを見ています。目標設定・評価・1on1、採用、ユニット間の連携、開発フローの整備、障害対応を担当しています。その前は分析用BIの開発チームのリーダーとして、自分も開発しながら仕様検討やスクラム、進捗管理をしていました。

一番の責務は、2つのチームが隣のチームとの受け渡しも含めて、機能リリースを最後まで届けられる状態にすることです。 私が見ている領域には、外部サービスとの連携機能のように、要件は自分たちが書き、実装は隣のチームが担当する仕事があります。こうした案件でも、誰が期日を持っているのかがはっきりしていて、特定の人の手が空くのを待たずに進められる状態をつくる必要がありました。 あわせて、マネージャーとして次のことにも責任を持っています。 ・メンバーが、自分に何を期待されているかを分かったうえで働けるようにする（1on1, 目標設定, 評価） ・必要な人を採用できるようにする（予算の確保, 募集要項の策定, 採用面接） ・障害が起きたら直し、同じことを繰り返さないようにする（障害の再発防止策の策定と実施） ・特定の人しか分からない仕事を減らしていく（属人化の解消）

まず考えたのは、チームの中よりも、チームとチームの境目に手を入れる必要があるということでした。それぞれのチームの中では仕事が回っていても、受け渡しのところで誰がボールを持っているのかが曖昧だと、案件はそこで止まります。そのため、工程ごとに誰が主担当なのか、期日を誰が持つのかをはっきりさせることを軸に置きました。 もう一つ大事にしたのは、今の分担を誰かのせいにしないことです。おかしく見える分担にも、たいていはその時点では正しかった理由があります。それが状況の変化に追いつかなくなっているだけなら、問うべきは「誰が悪いか」ではなく「今の状況で、この分担はまだ合っているか」だと考えました。だから、変える前にまず、なぜ今の形になったのかを知るところから始めています。 この考え方で実際に取り組んだのが、外部サービスとの連携機能の受け渡しです。要件は私たちが書き、実装は隣のチームが担当していました。要件を渡しては差し戻される往復が多く、そのやりとりは両チームの間に立てる少数の人に頼っていました。その人が忙しいと、案件ごと止まってしまいます。遅れていることは誰もが分かっているのに、期日を持っている人がいない状態でした。そこへ、間に合わなければ解約につながる案件が控えていたので、フローそのものに手を入れることにしました。 私はこの分担を決めた当事者ではなく、今の形になってから引き継いだ立場です。そこで背景から調べました。この連携機能は、もともと私たちが調査から実装まで通しで持っていた仕事でした。それが隣のプロダクトの機能として扱われるようになり、実装だけが隣のチームに移ります。要件整理と設計は「データの出口を知っている側がやったほうが精度が出る」という理由でこちらに残り、この領域にはPdMを置かないという判断もされていました。どちらも当時としては筋の通った判断です。案件が月に1件くらいのうちはそれで回っていましたが、常に数件が並行するようになって、往復の多さが目立つようになっていました。 そのうえで、最初は「実装を持っているチームが、事前調査から実装まで通しで持つべきだ」と正面から提案しましたが、通りませんでした。要件を決める役割がこちらに残ったままでは、作業の分担だけ変えても元に戻ってしまいますし、現場が気にしていたのは目の前の案件をどう回すかでした。 それからは、口で「分担を見直したい」と言うのをやめました。代わりに、工程ごとに誰が主担当かを書いた1枚の責務境界図を作り、会議に持っていくようにしました。図があると、「この工程はうちじゃない」「ここはこう分けたい」と、具体的な修正の話がしやすくなります。 責務境界図では、事前調査・要件定義・設計・実装・取り込んだあとの加工と集計の5つに分け直しました。特に、要件を決めるための材料(外部システムのAPI仕様やデータ）を集めるのはエンジニア、何を作るかを意思決定するのはPdM、と分けて書くようにしています。 逆に、「開発の優先順位を誰が決めるか」という行は最初は入れていましたが、あえて削りました。事業側の判断が必要で、その場のメンバーでは決めきれないからです。決められないことを残しておくと、それだけで全体の合意が先送りになると考えました。 合意を取る順番も意識しました。いきなり全体会議にかけるのではなく、まず両チームの意思決定者に個別に見てもらいました。次に現場のキーマンに見てもらって図の間違いを直し、全体会議は決まったことを全員で共有する場にしました。 図を見せて回る中で、「人手が空いていない」「引き継ぎが終わっていない」という声もありました。人手の話は図の議論と混ぜると前に進まなくなるので、現場で判断して上に相談するルートで別に詰めることにしました。引き継ぎの話は、知見が私たちの側に偏っている問題として、図とは別の課題に切り出しています。 この経験から、正しいことを言うだけでは組織は動かないと学びました。みんなで手を入れられる材料をテーブルに置くことが大事だと考えています。