ケース3 : 事業会社の内製開発

ケースの設定

会社とPMの立ち位置

本ケースは、エンタメ領域の事業会社が自社で立ち上げる、店舗や展示会向けの映像と音楽の配信ソリューションです。この会社は動画の制作と配信を主力にBtoCとBtoBの両面でサービスを持ち、開発部はグループ全体の開発を担っています。PMが所属するのは社内に複数ある開発チームのうちの一つで、PM自身がそのチームのリーダーです。

あわせて上流のビジネス部門の一部も軽く兼任しているため、要求が出てくる側と受ける側の双方にPMが入る形になっています。本ケースでは要求の解釈に関する齟齬は起きず、開発をどう実行するかが論点になる、という前提です。

案件と期日

自社が抱える既存の動画資産を活用したBtoB向けのソリューションで、機材の貸し出しから営業と広報の体制まで、事業スキームはビジネス側でほぼ完成しています。残るのは開発だけ、というところから本ケースが始まります。期日は半年後の展示会で、これは動かせません。ビジネス側は間に合わなかった場合のダミー展示も並行で準備しており、展示会自体は成立する形が組まれていますが、開発部には、展示会で動かして見せるための試作版（プロトタイプ）の完成が期待されています。この期待にどこまで応えられるかが、本ケースの焦点になります。

プロダクトの構成

プロダクトは三つの要素で構成されます。動画などのメディアを配信に使えるようにする基盤、配信を運用するための管理画面、エンドユーザーが触れる配信アプリの三つです。

PMの依頼内容

PMへの依頼は、半年後の展示会というゴールに対して何をどこまで間に合わせるかを含めた見積もりを返すことです。スコープそのものがPMの判断対象で、どの形で着地させるかを設計するところから、PMの仕事になります。

事前準備フェーズ

本ケースの事前準備フェーズは、工程設計とチーム設計に重心が置かれます。要求定義はPMが上流のビジネス部門を兼任しているため事実上通過済みで、予算設計も社内工数と外注予算の枠が会社から示されているため、枠を読む必要はありません。ここでは、どちらも深追いしません。

事業の企画も、ビジネス側でほぼ済んでいます。大きな視点での企画の余地は小さい案件です。それでも、与えられた枠と固定された期日のなかで開発の構造をどう組むかには、工夫の余地が多くあります。本ケースでは、スコープの最低ラインの置き方、工程の組み方、外注の切り方、進行中の損切りに、PMの工夫が出ます。

工程設計

PMが工程設計の最初に見たのは、プロダクトの三要素がどう接続するかでした。

ケースの設定で挙げた三つの要素、動画配信の基盤、運用のための管理画面、エンドユーザーが触れる配信アプリは、一見すると、動画配信の基盤が先にできあがらない限り他の二つのタスクが動き出せない構造に見えます。実装の本体は基盤の側にあり、管理画面と配信アプリはその基盤を呼び出して使う関係になるためです。

しかしここで、動画配信のためのAPI、つまり「どんな入力に対してどんな出力を返すか」という連携の約束ごとだけは、基盤本体の実装に先んじて確定させられる、という性質があります。基盤の中身がまだ作られていなくても、APIの形さえ決まっていれば、管理画面と配信アプリの開発は、そのAPIを呼ぶ前提で並行して進められます。

APIさえ先行して固まれば、動画配信の基盤、管理画面、配信アプリは並列で開発できます。PM術では、管理上の複雑さが増すため不要な並列化は推奨しません。しかし本ケースでは、APIで境界を切ることで各要素が完全に別オブジェクトとして独立できるため、並列化に伴う複雑さへの懸念はほぼ消えます。

よってPMは、工程を「API設計フェーズ」→「実装フェーズ」の二段で組み、実装フェーズの中を三本の並列で構成する設計にしました。

工程の骨格

最初に来るAPI設計フェーズのOUTは、プロトタイプ範囲をカバーしつつ、本番への拡張の道筋を残したAPIスキーマの定義です。プロトタイプ専用といっても使い捨てのAPIという意味ではなく、プロトタイプ段階で必要になる範囲に絞りつつも、後の本番開発でそのまま育てていける形で設計しておく、ということです。

スキーマFIX以降の実装フェーズは、動画配信の基盤、管理画面、配信アプリが並列で走り、最後に三要素を統合してプロトタイプとして動かすかたちになります。ビジネス部門へのマイルストンは、APIスキーマFIX、各要素の単体動作確認、統合プロトタイプ完成、という単位で握ります。

スコープ設計

工程の骨格を組むのとあわせて、PMはスコープ側にも設計を入れました。

最大成果は、三つの要素が揃ったプロトタイプを展示会までに完成させることです。本ケースもこれを目標に組みますが、何も完成しない場合のリスクヘッジは、ビジネス側のダミー展示としてすでに用意されています。よってPMは、このプロジェクトでの最低ラインをどこに置くかを、自分で設計できる立場にあります。

PMはここで二つの軸を意識しました。一つは、展示会の見栄えに直結する部分は確保しておきたいというビジネス上の要求。もう一つは、本ケースの後ろに控えている本開発を考えると、使い捨て前提の作りで済ませたくないという長期目線です。

この二軸に沿って、絶対担保のラインを三つ置きました。本番に進化させられる動画のAPI仕様、展示会で実際に動画を流せる状態、配信アプリか管理画面のいずれかのUIデザインの三つです。UIデザインは展示会で見せられればよいので、動作する必要はありません。それ以外の要素は努力目標とし、間に合わなかった場合でも無駄にならない形で設計しておきます。

ケース1では、下振れへの備えを予算の側（計画的バッファ）に持ちましたが、本ケースは期日が固定でスコープが流動的なので、備えをスコープの側に持つことになります。

チーム設計

工程設計と並んで、チーム設計が本ケースのもう一つの主役です。論点は、各要素にどの形で人を当てるか、とくにアプリ部分について外注の引き方をどう設計するか、の二つに集中します。

内部の制約条件

編成にあたって、組織側から先に置かれた制約があります。

動画配信の基盤は、機密上の理由から社員が中心の編成にする必要があります。社員に業務委託や外注を混ぜる場合でも、機能チームのトップは社員が担う、というのが組織側からの条件です。

管理画面は機密上の制約が弱く、業務委託中心の編成でも問題なく組めます。

配信アプリは機密上の制約はありませんが、エンドユーザー向けのアプリのUX設計と実装は、自社の内製の得意ジャンルではありません。社内のリソースは動画関連に厚く、その先のアプリ側は手薄なため、外部の力を借りる方向で組むのが現実的だ、という判断になります。

アプリ部分の分割の引き方

アプリ部分の編成について、PMは二つの案を比較しました。

案Aは、UXだけを外注し、フロント実装は内製で進める案です。外注に依頼するのはUI デザインまでで、納品されたデザインを社内のメンバーが受け取って実装する流れになります。コストは抑えられ、期間も短く済みます。期待値を最大化する観点では、こちらが有利です。

案Bは、アプリを丸ごと外注する案です。UI デザインから実装までを一つの外注パッケージとして発注します。コスト、納期、品質の見通しのいずれも、案Aに劣ります。

数字の上では案Aを選ぶのが当然です。しかしPMはここで二点に注目しました。一つは、案Aが持つ後続作業への影響の連鎖性の高さ。もう一つは、案Aを選ぶことによる工程設計と進行管理の複雑化です。

案Bは、アプリを丸ごと一つの外注先にパッケージで任せる構造のため、外注先と他の作業との間が切り離された状態（疎結合）になります。仮に外注先で失敗が起きても、その影響はアプリの作業の内側に留まり、他の作業には波及しません。さらに、UI デザインだけは早期に納品される構造を、外注先との契約段階で組み込んでおきます。納品済みのデザインが手元にあれば、それと内製チームの動画資産を組み合わせることで、最低限の展示は担保できる、という構造です。

一方、案Aは外注のUX側と内製の実装側が結びついた構造（密結合）です。両者の境目ははっきりとは切り分けられず、デザインデータの渡し方や仕上げの粒度といった、解釈の余地を残したかたちで連結します。外注のUX納品が遅れれば内製の実装はそこで止まり、UXに方向性のずれがあれば内製の実装は手戻りに巻き込まれ、最悪の場合は後続の作業までドミノ式に押し倒される可能性があります。加えて、境目が曖昧なまま進めることになるため、工程設計の段階で依存関係を細かく詰める必要があり、進行中も常時の調整が発生します。設計と運用の両面で、見えづらいコストが上乗せされる組み方です。

PMはPM術のミニマックス思想に沿って、案Bを選びました。

セットアップフェーズ

セットアップフェーズは、型に沿って進めました。社員については組織内の調整、業務委託と外注については契約条件の確認で、各メンバーの稼働コミットをキックオフの前提として確保しています。コミュニケーション基盤は社内で運用しているチャネルとドキュメント保管場所を流用できる範囲に収まりました。キックオフでは、半年後の展示会というゴール、APIスキーマ最優先の工程の骨格、並列構造の各要素のIN/OUTを共有しています。とくにAPIスキーマがすべての並列フェーズの起点になるという構造は、メンバー全員にとって視界の前提になるため、ここで丁寧に説明しました。

実作業フェーズ

並列開発の進行

実作業フェーズは、プロトタイプ用APIスキーマの設計から始まりました。社員のチームが設計を進め、スキーマFIXの段階で各要素の担当者が同じテーブルでレビューを行い、自分の側のINとして使える定義になっているかを確認しました。

スキーマFIX以降、API化基盤の実装、管理画面の開発、配信アプリの外注作業が、それぞれ並列で動き始めます。PMの視界は各要素のINとOUTの境界に集中し、中身には踏み込まず、定義どおりのOUTが出てくるか、そのタイミングが工程設計どおりかを評価する動きです。

API化基盤は社員のチームが想定どおりのペースで進行し、管理画面の開発も業務委託中心の編成で順調に立ち上がりました。

想定通りの下振れと組み替え

進行中に顕在化したのは、配信アプリの外注先での作業遅延でした。

これはPMが事前にシミュレーション済みの事象です。アプリを丸ごと外注した時点で、外注先の遅延というリスクは計算に入っており、UI デザインだけは早期に納品される構造を契約段階で組み込んでありました。

外注先からの状況報告を受けたPMは、損切りの判断に入りました。アプリ実装が展示会に間に合う見通しが立たないため、その先の作業を外注先で進めることを止めます。

ここで、すでに納品されていたUI デザインが効きました。

PMはこのデザインの見た目だけを使い、動画を流すだけの簡易システム（実質はWebサイト）として組み直すことを決断します。本格的なアプリ実装は諦め、展示会で動かして見せる体裁だけは確保する、という判断です。

追加制作を社内のリソースで賄えるかを管理画面の開発チームに相談したところ、開発は順調に進んでおり追加しても大した実装にはならない、ということで快く引き受けてもらえました。

結果として、アプリ以外は、簡易動画システムも含めて予定通りに完成しました。

フィニッシングフェーズ

最終的には、展示会の当日に間に合ったのは、「動画配信システムのAPI基盤」「管理画面のプロトタイプ」「管理画面と連携して流れる動画」「アプリのUI/UXデザイン」の4点でした。

これは、想定の最大値ではなかったですが、最悪値は大幅に上回る成果でした。

当日の会場では、納品されたアプリのUIデザインを最大限活用したブースデザインとチラシで集客をし、管理画面による動画配信デモも行えました。

広報活動としては大きな成果が上がり、この結果は、リスクヘッジをしていたビジネスサイドの想定を上回っていたので、開発プロジェクトは成功となりました。

アプリが出来なかったのは残念でしたが、それでも後続の本格開発へ引き継げる様々な資産や知見は残ったので、PMとしても総合的には満足した案件でした。

事後処理フェーズ

展示会の終了をもって、本ケースのプロジェクトは閉じました。

ここから始まるのは、プロトタイプから本格開発への接続です。本番進化版のAPIが手元にあり、管理画面も運用可能な水準で揃っているので、本番のプロダクト開発に踏み出すための土台はすでに整っています。

「プロトタイプ専用のAPIを本番に進化させられる前提で設計する」という事前準備フェーズでの判断が、ここで効いてきました。最初の段階での設計判断が、後のフェーズで次のプロジェクトの起点として活きる。事前と事後がつながる、本ケースの構造です。

本ケースのまとめ

本ケースは、事業会社の内製開発で、PM術の組み立て方がどう機能するかを追いました。大きな視点での企画の余地が小さい案件でも、スコープ、工程、チーム、進行中の判断の各階層に、工夫の余地がありました。

工程設計でAPIの仕様を最優先に固めて並列開発を可能にし、スコープ設計で最悪ケースの担保ラインを先に決め、チーム設計でコストも納期も品質も劣る案をミニマックスの観点から選びました。実作業では、事前にシミュレーション済みの下振れが、組み込んだ構造のなかで吸収されました。

最大成果には届きませんでしたが、最悪値を大幅に上回る成果として着地しました。ミニマックスで組んでおくと、下振れが起きても、事前に用意した構造のなかで判断を下せます。本ケースは、その実例です。