はじめに
この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/15の記事です。
こんにちは。バックエンドエンジニアの山下です。 普段は開発チームで、バックエンド開発を担当しています。
これまでいくつかのプロジェクトに関わってきて、最近はチーム内の開発で安定してアウトプットが出せるようになってきたな、と感じることが増えてきました。設計・実装やレビュー、テストも大きな問題はなく、スプリントごとのふりかえりで少しずつ改善できている実感もあります。
ただ、プロジェクト全体（他チームや外部ステークホルダーとの連携）で見ると、うまく進まない場面にもよく遭遇しました。開発チーム内は計画どおりに進んでいるのに、チーム外の関係者との調整や意思決定で時間がかかり、気付けばスケジュールに影響が出てしまう…そんなことが何度か続きました。
この記事では、そうした経験の中で、プロジェクト管理の観点でチームの外へ少し踏み出してみたことで気付いたことをまとめています。
開発チームは順調なのにプロジェクトが遅れる問題
開発チーム内での作業はうまくいっていた
プロジェクト全体としては遅れが出ている状況でも、チーム内の開発は安定していました。日々の作業で大きな混乱が起きるようなこともなく、「進め方が原因でプロジェクトが止まっている」という感覚はなかったです。
やるべきことも共有できていて、進捗もおおむね予定どおりでした。
しかし、チーム外との調整でスケジュールが崩れた
一方で、プロジェクト全体で見ると、開発チームの中だけでは気づきにくい課題も見えてきました。
askenでは扱うプロジェクトの種類が幅広く、関わるメンバーも開発チームだけとは限りません。 マーケ、栄養士、CS など、さまざまな職種が同じプロジェクトに関わることも珍しくありません。
そんなプロジェクトの中で、開発チームのタスクは順調に進んでいるはずなのに、リリース日がずれたり、追加の調整が必要になったり…そんな状況が何度か起きていました。振り返ってみると、開発チーム外の調整や関係者間の意思決定のタイミングなど、複数の要素が重なって影響していました。
開発チームの範囲では順調でも、プロジェクトでみると予定通りに進んでいない。そのギャップに、少しずつ違和感を覚えるようになっていきました。
失敗から学んだこと
前提が揃っていなかったプロジェクト
その違和感が明らかになったのは、あるプロジェクトでの失敗でした。
このプロジェクトでは、栄養学に関するある変更を目的としており、主要なステークホルダーとして栄養士さんが関わっていました。
ステークホルダーやPdMとも仕様をしっかり合意し、開発チームとしても実装やテストを予定通りに進めていました。しかし、リリース日の調整に入ったタイミングで、
「受入テストを挟み、その結果を見て仕様を微調整する前提だった」
という話が出てきました。その工程をスケジュールに含めて引き直すと、当初のリリース日から大きく後ろにずれることが判明しました。
何が問題だったのか
開発チームとステークホルダーの間では、次のような“前提の違い”があったことが分かりました。
- 開発チームの前提：最初に合意した仕様のままリリースできる
- ステークホルダーの前提：まずは動くものを見て、そこから仕様を仕上げていく
開発開始時点で「仕様はどの程度固めたものなのか」、「どの時点で仕様をFIXさせるのか」
という前提が最初から揃っていなかったことで、結果としてリリース時期を見直すことになりました。
開発チームの開発プロセスに問題があったわけではありません。
問題だったのは、「仕様をどの時点でどこまで固めるのか」という前提が、開発チームとステークホルダーの間で揃っていなかったことです。
その前提のズレがあったために、実装後の調整や仕様変更が入る可能性をスケジュールの中で十分に扱えていませんでした。
さらに、今回のプロジェクトでは栄養学に関わる変更のため、
「栄養士さんが栄養士の視点で変更後の仕様でプロダクトを動かした上で、微調整してリリースしたい」
という前提がステークホルダー側にありました。
その前提を踏まえれば、実装後に一定のフィードバックや仕様調整が入るのは自然な流れでした。
開発チームの「外」への越境が必要な理由
この失敗から得た一番大きな教訓は、開発チームの外の人々の動きを把握できていないとチーム内が順調でもプロジェクトはうまくいかない、ということでした。
開発チーム内では、
- スプリントの計画
- タスクの進捗
- レビューやテストの状況
といった情報が可視化されており、状況を把握しやすくなっています。
一方で、開発チームの外にいるステークホルダーや他職種のメンバーが、
- いつ意思決定をしているのか
- どんな前提で仕様を捉えているのか
- どのタイミングでフィードバックが来るのか
といった動きは、開発チームの中にいる限り見えにくいままでした。
この「見えている範囲の差」こそが、チーム内とプロジェクト全体の間でズレが生まれる原因でした。
開発チームの中だけを見ていると、どうしても「開発チームとしての進捗＝プロジェクトの進捗」だと思いがちです。しかし実際には、チーム外の判断や動きがプロジェクト全体の流れを大きく左右します。
だからこそ、チームの外側にある情報にアクセスし、理解しにいくことが欠かせないと感じています。
どう改善したか
開発チーム外を含めた前提と動きを見える化する
この気付きから自分が変えたのは「開発の進め方」そのものではなく、プロジェクト全体の前提や流れをどう見せるかでした。
開発チームの中だけで完結する情報ではなく、チーム外の動きや意図も含めて“同じ前提で進められる状態”をつくることを意識するようになりました。
そこでまず取り組んだのは、プロジェクトの目的と前提を関係者全員でそろえることです。
- リファインメントの場でステークホルダーやPdMと目的や前提をしっかりとすり合わせる
- PRDやメモに落として明文化し、関係者で共有できるようにする
- 変更が起きやすいポイントは初めからスケジュールに組み込んでおく
といったことを意識しました。
次に、プロジェクトが発足し動き出すタイミングで
「誰が」「どのタイミングで」「何をするのか」 を洗い出し、
プロジェクト全体のスケジュールとして整理し、関係者と合意・共通認識を作るようにしました。
こうしてお互いの動きや前提が可視化されると、
「開発チーム内の進捗は順調なのに、なぜスケジュールが読めないのか」
という状況が減っていきました。
開発チームの進捗管理にチーム外の動きも含めた全体のスケジュール管理を重ねることで、プロジェクトとしての見通しを持って進められるようになったと感じています。
まとめ
「開発チーム内の成功 ≠ プロジェクト全体の成功」
開発チーム内の進捗や品質が問題なくても、チームの外で動いている関係者の「前提」や「動き」が見えていないと、手戻りやスケジュールの遅延は避けられません。
チーム外の人を巻き込んで「誰が」「どのタイミングで」「何をするのか」を見える化することで、前提のズレがなくなり、やるべき作業が明確になります。明確になることで手戻りや確認待ちが減るので、リリースまでのスピードが上がります。
最高のチーム開発を追求することは、もちろん大切です。しかし、その力をプロジェクトの成功に直結させるためには、チームの境界線を意識的に乗り越え、プロジェクト全体の流れと前提を整えることが不可欠です。
採用について
askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！
https://hrmos.co/pages/asken/jobs
