【音声ライブ配信アプリの開発体制を整え、継続的にリリースできる状態へ】
WBSによる可視化と開発プロセスの整備で、経営と開発の期待値を揃えたアプリ開発支援

1. 本事例の背景（相談の入口）

本事例の対象となったのは、「好き」や共通の趣味をきっかけにユーザー同士がつながる、音声ライブ配信アプリの開発プロジェクトです。ラジオ的な音声配信に加え、投げ銭によるマネタイズ機能も備えたサービスとして、リリース直前のフェーズまで開発が進んでいました。

当時、開発はKSRで進めていたものの、開発全体をどのように進めるのか、どの機能をいつまでに作るのか、優先順位をどう決めるのかが曖昧な状態でした。クライアントにとっても、アプリ開発は初めての経験でしたので、ビジネスとして「こういう機能が必要」「これもあった方がよい」という要望は出てくるものの、それを開発要件として整理し、エンジニアに伝わる形へ落とし込むプロセスが十分に整っていませんでした。その結果、開発側からすると「結局、何をいつまでに作ればよいのか」が見えづらい状態になっていました。

一方で、バグや緊急対応が発生すれば、すぐに対応が求められます。新しい機能要望と緊急対応が混在し、開発チームとしては優先順位を判断しにくい状況でした。このような状態を整理し、リリースまで漕ぎ着けること。さらに、リリース後も継続的に改善できる体制へ変えていくことが、行川さんが本プロジェクトで担った役割でした。

2. 課題（開発が前に進みにくかった理由）

開発が前に進みにくかった背景には、機能要望が次々と出る一方で、優先順位やスケジュールが見えづらく、経営と開発の期待値にもズレが生じやすい状況がありました。新規アプリ開発で初めての挑戦だったこともあり、何をいつまでに決めればよいのか、判断のための共通言語が不足していたのです。

3. ゴール（何を"できる状態"にするか）

本プロジェクトのゴールは、アプリをリリースすることだけではありませんでした。もちろん、リリースまでなんとか到達すること自体は重要です。しかし、それだけでは一時的な解決に留まります。目指したのは、開発チームとして継続的にリリースを回せるような、以下の状態をつくることでした。

• 開発チームの役割と進め方が整理されている
• 要件を整理する人、質問・確認して開発要件に落とし込む人、実装する人の流れが見えている
• 何を・いつまでに・どこまで進めるのかを、関係者が同じ土俵で話せる
• 経営と開発の間で、期待値のズレが起きにくくなっている
• 緊急対応に振り回される状態から、計画的にリリースできる状態へ変わっている
• PdMがチームに加わり、継続的に要件を整理できる
• 継続的にリリースが回り、マネタイズできる状態まで持っていく

アプリ開発では、初回リリースはあくまでスタートです。リリース後も、ユーザーの反応を見ながら機能を改善し、新しい要望を整理し、次のリリースへつなげていく必要があります。だからこそ、今回のゴールは「一度出すこと」ではなく、リリースし続けられる開発体制を作ることでした。

4. 進め方（実行してきたこと）

4-1. まず、開発工程を"見えるもの"にする

最初に行ったのは、手を動かす前に、開発の進め方を見える形にすることでした。当時は、WBSのように開発の流れや期限を整理した資料がありませんでした。そのため、「この日にこの機能を出したい」という話が出ても、そのためにいつまでに要件が決まっている必要があるのか、いつデザインが必要なのか、フロントエンドとバックエンドの実装がどの順番で進むのかが見えづらい状態でした。

そこで行川さんは、まず開発工程を可視化しました。

• 要件を決める
• デザインを固める
• フロントエンドとバックエンドで実装する
• 最後につなぎ込みを行う
• リリースに向けて確認する

この流れを見える形にすることで、「このスケジュールで本当に間に合うのか」「どこを先に決めないといけないのか」が関係者に伝わるようになります。感覚で話していた開発スケジュールを、全員が見られる形にする。これが、プロジェクトを前に進める最初の一手でした。

4-2. WBSで、希望納期と現実の工程を接続する

次に、WBSを使ってタスクと期限を整理していきました。WBSを作ることで、「いつまでに何が必要か」が可視化されます。たとえば、リリース日から逆算すると、要件を決める期限、デザインを固める期限、実装に入る期限、結合確認を行う期限が見えてきます。これにより、「この機能をこの日に出したい」という要望が、現実的な開発工程として成立するのかを判断できるようになります。それまで曖昧だったスケジュールが可視化されると、議論の仕方も変わります。「やる／やらない」だけではなく、「今やるのか」「次のリリースに回すのか」「この期限なら何を削る必要があるのか」といった会話ができるようになります。WBSは単なる管理表としてではなく、希望納期と開発の現実を接続し、関係者が同じ前提で話すための共通言語として機能しました。

4-3. 要望をそのまま流さず、開発要件に変換する流れを作る

開発の型を整えるうえでは、役割の流れも重要でした。本プロジェクトでは、以下の流れをチーム全体で共有していきました。

• 要件を整理する人
• それを質問・確認し、開発要件に落とし込む人
• 実際に実装する人

この流れが曖昧なままだと、要望がそのまま開発チームへ流れ込み、エンジニアが都度判断しなければならなくなります。一方で、要件整理の流れができると、「これは何を実現したい要望なのか」「開発要件としてはどう表現すべきか」「いつのリリースに入れるべきか」を整理してから実装に進められます。これにより、開発チームは目の前のタスクに集中しやすくなります。また、ビジネス側も「どこまで決めれば開発に進められるのか」を理解しやすくなります。機能要望をそのまま受け渡すのではなく、開発が進められる形へ翻訳する。この流れを作ったことが、チームの動きやすさにつながっていきました。

4-4. 「できる／できない」ではなく、判断できる材料を出す

プロセスを可視化したからといって、すぐにすべてがスムーズに進むわけではありません。事業側には事業側の事情があり、開発側には開発側の現実があります。行川さんは、その間に入り、粘り強くコミュニケーションを重ねていきました。「この機能を出すには、先にここを決める必要があります」、「このスケジュールだと、ここがボトルネックになります」、「今すぐ入れるべきものと、次回以降に回せるものを分けましょう」。

このように、感情的な対立になりやすい場面でも、開発工程や判断材料を見える形にして、会話の土台を作っていきました。特に重要だったのは、単に「できない」と伝えるのではなく、なぜ難しいのか、どこを調整すれば実現できるのかを示すことです。見えないものを見えるようにすることで、経営と開発の期待値のズレが少しずつ解消されていきました。

4-5. PdMが必要だと分かる状態まで、プロセスを定着させる

リリースに向けて体制を整える中で、プロジェクトにはPdMの必要性も見えてきました。最初は、要望が広がりやすく、開発要件として整理される前に議論が進んでしまう状態でした。しかし、WBSを作り、要件整理の流れを整え、リリースに向けたプロセスを回していく中で、「継続的に要件を整理し、優先順位を判断する人が必要だ」という認識が生まれていきました。その結果、先方側の担当者がPdMとしてチームに加わり、要件がNotionなどに整理されるようになっていきました。これは単に人が増えたということではありません。開発を継続的に回すために必要な役割が明確になり、チームの中に定着していったということです。一度リリースして終わりではなく、その後も改善を続けるための体制が整い始めました。

4-6. 緊急対応に追われる開発から、リリースを回せる開発へ変える

開発の型が整い、WBSで進捗が見えるようになると、緊急対応に追われる状態は徐々に減っていきました。それまでは、要望や不具合対応が都度発生し、開発チームがその場その場で対応する場面が多くありました。しかし、何をいつ出すのかが整理され、次のリリースに向けた判断ができるようになると、チームとして計画的に動きやすくなります。結果として、1〜2ヶ月に一度のリリースができる体制が整っていきました。さらに、マネタイズできる形まで持っていけたことも、大きな成果につながっています。"火消し"に追われる状態から、リリースを計画的に回す状態へ。開発の進め方を整えたことで、チームは継続的にプロダクトを育てられる状態へ近づいていきました。

5. 成果

本事例の成果は、音声ライブ配信アプリの開発体制を整え、リリース後も継続的に改善できる状態を作ったことです。当初は、機能要望が次々と出る一方で、優先順位やスケジュールが見えづらく、経営と開発の期待値にもズレが生じやすい状態でした。そこに対して、WBSによる可視化、役割の整理、リリースまでの流れの設計を行うことで、関係者が同じ土俵で話せるようになっていきました。開発チームとしても、何をいつまでに進めるべきかが見えやすくなり、緊急対応に追われる状態から、計画的にリリースを回せる状態へ変化しました。その後、先方側にPdMが加わり、要件がNotionなどで整理されるようになったことで、継続的な開発体制も強化されています。結果として、1〜2ヶ月に一度リリースできる体制が整い、マネタイズできる形まで持っていくことができました。単にアプリを出すだけではなく、事業として運用し、改善を続けられる開発の土台を作れたことが、本支援の大きな成果です。

6. インタビュイーのワンポイントアドバイス

行川さんが支援に入る際に意識しているのは、プロジェクトが止まっている原因を、スキルや技術だけで判断しないことです。プロジェクトに関わる人たちは、多くの場合、同じゴールに向かっているはずです。それでもうまく進まないときには、人・モノ・お金・情報のどこかで不安や納得感の不足が生まれています。たとえば、追加投資の判断ができない背景には、「本当にうまくいくのか分からない」という不安があるかもしれません。エンジニアが思うように動いていないように見える背景には、要件が曖昧で、何を作ればよいか判断できない状況があるかもしれません。だからこそ、行川さんは利害関係や感情の動きを見るようにしていると語ります。誰かの能力不足として片づけるのではなく、なぜその人が動けないのか、何が見えれば意思決定できるのかを捉える。その視点が、今回のように経営と開発の期待値を揃える支援にもつながっています。

初めて外部支援者を活用する発注者に向けては、以下の3つを事前に整理しておくとよいとされています。

• 自社の課題をできるだけ明確に言語化しておくこと
• それをいつまでに、どのように解決したいか、ざっくりしたイメージを持っておくこと
• 自社にどの程度の知見があるのかを把握しておくこと

外部支援者は、すべてを代わりに決める存在ではありません。課題や期待値、知見レベルが共有されているほど、支援者はより正確に入り込み、必要な支援を提供しやすくなります。

7. 最後に（総括）

アプリ開発において、機能を作ること自体はゴールの一部でしかありません。本当に重要なのは、何を作るべきかを判断し、必要な順番で開発し、リリース後も改善を続けられる状態を作ることです。今回の支援では、音声ライブ配信アプリのリリース直前フェーズにおいて、開発の進め方そのものを整えることが重要なテーマでした。機能要望が広がる中で、WBSを使って開発工程を可視化し、優先順位と期限を同じ土俵に乗せる。要件を整理する人、確認する人、実装する人の流れを作る。さらに、PdMが加わることで、継続的に要件を整理できる体制へと変えていく。それは、単なる進行管理ではありません。経営と開発が同じ前提で会話できるようにし、チームが迷わず動ける状態を作るための支援でした。

スタートアップの開発現場では、スピードが重視されるからこそ、型やプロセスが後回しになることがあります。しかし、型がないまま進むと、かえって認識のズレや手戻りが増え、リリースの速度も落ちてしまいます。今回の事例が示しているのは、開発を速く進めるためには、まず「何を・いつまでに・どの順番で進めるのか」を揃える必要があるということです。

WBSで工程を可視化し、要件を開発できる形に変換し、経営と開発が同じ判断材料を見られる状態を作る。そうした土台があるからこそ、チームはその場その場の火消しから抜け出し、継続的にリリースを回せるようになります。リリース直前の混乱を、プロダクトを育て続けるための開発体制へ変えていく。そこに、行川さんが本プロジェクトで発揮した支援の価値が表れていました。