はじめに
はじめまして。2025年10月にキャディ株式会社へ入社した、エンジニアリングマネージャー（EM）の蟹澤です。
先日、リードアーキテクトの小森（@littleforest12）が、設計フェーズにおける不確実性への向き合い方を綴った記事（https://caddi.tech/2025/12/16/112311）を公開しました。本記事は、同じプロジェクトをプロジェクトマネージャー（PM）として担当した私からの、アンサーソングです。
本プロジェクトは、今後すべてのチームが依存する、キャディの根幹にズブズブと手を入れるような基幹機能開発です。わずかな設計ミスが将来の全社の開発速度を左右しかねない、失敗の許されない横断プロジェクトです。「幅広くキャディを理解する機会として」という意図でのアサインでしたが、当時の私はドメイン知識ゼロ、入社2週間目。正直に言えば「ヒリヒリする打席がきたなあ」と興奮していました。
同時に、冷静に状況を見ると、これは気をつけないとすぐ燃える、火種の多いプロジェクトでもありました。もちろん私もPMとして盛大にプロジェクトに火を噴かせてしまった経験があります。なんなら、新参者の私自身が簡単に火種になり得ます。
そう認識したとき、自分の役割が見えてきました。チームが自律的に動ける環境を作り、自分がボトルネックにならない、それがゴールへの最短ルートだと。
結果として、プロジェクトはリリースに向けて（自分でも驚くほど）順調に進んでいます。メンバーに恵まれた部分が大きいのは前提ですが、振り返ると、以下がポイントだったと思います。
- アーキテクチャに引いた、責任境界という名の線
- 2度の設計見直しと、引き返す勇気
- 仕様的負債をただの「妥協」にしない
- 「構造を創り、自律を生み出す」がマネージャーの価値
完全な答えを持っているわけではありませんが、同じような状況に置かれた方の、何かヒントになれば嬉しいです。
新参者だった当時の私が「気合と根性の進捗管理」ではなく、「構造の力」でチームを最高速で自律駆動させた、その舞台裏を共有します。
アーキテクチャに引いた「責任境界」という名の線
まず必要だったのは、スケジュールの調整などではなく、アーキテクチャに納得のいく明確な線を引くことでした。
アーキテクトの小森を中心にアーキテクチャの初期検討から進みました。要求の変更も折り込んで複雑度が高まったり、それを整理したりを繰り返します。 合わせてデータモデルも検討していきます。その際、あるメンバーに「DDD的な観点で境界線を引いてみてほしい」と伝えました。
アーキテクチャはオーナーの異なる複数のコンポーネントの連携であり、そこに新しいデータモデルを投入します。自明なところもありますが、当然複雑度は高くなり、極端に言えば全員が全方位を心配して無限に依存関係を確認し続けるような感じで、議論が発散しがちでした。
データモデルに引かれた一本の線により考えが局所化し、アーキテクチャにも境界線が表現され、意識の集中は高まり議論が整然と進むようになりました。誰のボールか分からない領域はゼロです。
ここで引かれた線こそ、各チームが持つ「責任境界」です。キャディの組織設計は逆コンウェイ戦略に則っており、コンポーネントとチームとが対になっています。つまりアーキテクチャに線を引くことは、チームの絶対的な安全地帯を定義することです。「他チームの不備の影響が大きいんじゃ？」「グレーゾーンでポテンヒットになるんじゃ？」という横断プロジェクト特有の漠然とした不安を、アーキテクチャという構造で解消することができました。
「自分のコンポーネントのことだけ考えていれば大丈夫」 この高い集中を正しく産み出す環境が、チームを最高速で自律駆動させると確信しました。
二度の設計見直しと、引き返す勇気
自信のあるアーキテクチャができ、チームのキックオフを開催しました。アーキテクチャについてCTOとも合意が取れました。設計の詳細化を進めていきます。 そんな中、PdMから「価値提供においてやはり最低限必要だ」と、一度はスコープアウトした要件の見直し議論がおこりました。納期を意識する時点での変更は「火種」です。正直言って避けたい気持ちMAXでしたが、議論により「納期リスクはあるが、中途半端なものを出すことになる」と合理性を理解し、取り込む決断をしました。実現に向けて詳細を詰める中でデータモデルに修正を加え、より実効性の高いアーキテクチャへとブラッシュアップさせました。 「これならいける」と納得し、改めてステークホルダーとの対話に臨みます。
「この修正だと、近い将来の拡張性の毀損や、UXの低下に繋がらないか？」
目の前の仕様に没頭しすぎて生まれた盲点を、正確に射抜くCTOの指摘でした。 「せっかく詳細まで詰めたのに」「納期はどうなる」ピリッとした緊張が走ります。
PMとしては、納期を盾に設計を死守する動きも考えました。しかし、指摘された構造の歪みが将来の現場を疲弊させる。ここで引き返さないと後悔する、という直感に従いました。
盲点になっていた箇所を修正し、影響範囲を洗って全体的な整合が保たれていることを確認。UXレベルでも変更があるためその議論を経て設計修正は完了。CTOとの再レビューでもOKが出て、やっと開発実装に着手する準備が整いました。
こう書くと簡単そうですが、データモデルに手が入っているため、恐ろしく気を遣う工程です。小森さんごめん。
仕様的負債をただの「妥協」にしない
ここまで初期設計で当初想定よりも期間を使ってしまい、さらに最後に修正を再度重ねたことで、開発期間は削られた状況でした。 「気合いで間に合わせようぜ！」と無邪気に鼓舞して嫌な顔をされるのは最後の手段にして、納期調整も今回は難しいため、スコープ調整を行います。 要件を一覧化し、要求レベルを評価し、MUSTでなく高難度高リスクな実装項目を一つずつPdMと議論し「後から構造を変えず差し込めるか」等を基準にスコープアウトを決断します。
これ自体は特別変わった風景ではないと思います。（主に心の）痛みや苦い思い出になっていくやつです。
しかし私たちは、スコープアウトした項目をあとから誰も探さないドキュメントに残して終わることを良しとせず、「仕様的負債」であると再定義しました。ここには初期段階でMVPを検討した時に外された要求も含めています。技術的負債であれ仕様的負債であれ、負債は計画的に返済したい。妥協した項目を「いつかやる」の霧の中に消すのではなく、チームが意識し続けられる構造に置いておく。それが、今回私たちが大切にしたことでした。
具体的には、全ての負債項目に対して、内容はもちろん、想定される負の影響度合いや解消すべき時期を評価しリストにします。そのリストをPdMや開発メンバーと認識合わせを行い、その上でオフィシャルな開発項目候補としてPdMの管理下としました。バックログの奥底に沈めて終わりではなく、実際に開発検討が進められています。
「構造を創り、自律を生み出す」がマネージャーの価値
構造を整理し、負債の扱いを明確にする。これによりチームは高い集中を得られるはず。
いけると信じていましたが、「開発が進めば仕様調整・納期調整・リスク管理・それらを議論し判断するための会議でカレンダーが埋まるかもな」と言う覚悟も持っていました。一応。念の為。
しかし、デイリーミーティングでの新規リスク報告では、適切な対策案がついてくる。前スプリントでのスケジュール懸念は、リカバリプランに則って次スプリントで見通しがつく。仕様調整や議論は担当同士で完結する。テストが始まっても品質が高い。自分たちの裁量を超える判断はちゃんと相談がくる。チームが自信を持って息づいており、開発が健全に進み続けています。 プロジェクトはもう終盤ですが、安定的な状況にも誰かが気を抜く事もなく、むしろ「今しておけることをやり切っておきたい」といったムードです。
PMとして超人力で奔走する必要などなく、チームがどんどんと自律駆動を続ける。
もしかすると傍目には「あのPM何もしないな」な状態に見えるかもしれません。「ボトルネックになってはならない」という狙い通りであり、最高の褒め言葉です。ありがとう。 磨き上げた境界線に守られたチームが、自分たちの出すべき価値に集中し向き合えている「高密度の自律」を、このチームが出した成果が証明しています。
チームをこの状態に導けたことは、PMとしてもEMとしても強烈な手応えを感じられる体験でした。そして、「これを実現できるキャディ」でのこれからに、ますますワクワクしています。
最後に
キャディに入社早々、こんなにエキサイティングな打席に立つことができました。そして今はまた別のシビれる打席に立ち向かっています。
「構造で高度な自律を引き出す」という挑戦、そしてそれを実現できるメンバー、組織設計、技術戦略がキャディにはあります。
気合と根性ではないマネジメントを手放し、その熱量をもっと本質的な価値に向けたい欲張りなPM/EMのみなさま。キャディではそんな仲間を募集しています！興味を持っていただけた方は、ぜひ採用サイトをご覧ください。カジュアル面談もお待ちしています！
キャディ 採用サイト https://careers.caddi.com
カジュアル面談 https://open.talentio.com/r/1/c/caddi-jp-recruit/pages/78398?_fsi=2IcRhEF0
