ケース2 : 開発系コンペ

ケースの設定

本ケースは、HR系SaaSの新規立ち上げの開発コンペです。発注元は総合コンサル系の事業会社で、自社事業として動画を主軸にした社内教育プロダクトを立ち上げる立場にあります。コンペには3〜5社が参加していますが、正確な競合数は明示されていません。

クライアントは発注元の事業会社、実質的な決裁者は事業部の部長です。PMが日常的にやり取りする相手は事業企画担当で、PMの前職での縁を通じて今回のコンペの窓口になっています。

PMが所属する制作会社は中堅のシステム・デザイン制作会社で、デザイン内製を強みとしています。本ケースのPMはプランナーを兼任する変則編成で、要求定義から企画の組み立てまで一人で踏み込みます。

PMはコンペの構図を、最初から次のように認識していました。担当者レベルでは大手SIerにほぼ内定している。コンペが必須化されているのは監査・ガバナンス対応のためで、自社は明らかに大穴・数合わせ枠です。窓口の担当者は前職での縁で自社を呼んでくれていますが、社内では本命に投票する立場にあるはずで、担当者を立てて社内を動かしてもらうという通常の姿勢では、大穴は永遠に勝てません。刺さるとすれば、窓口の上にいるはずの誰かに、ということになります。ただしその誰かが具体的に誰なのか、プレゼンの場に同席するか、そこで本当に刺さるかは、事前準備の段階では見通せません。

RFPの状態は次のとおりです。事業企画は固まっており、ターゲット・課題・価値提案・主要機能・画面構成方針・ローンチ時期まで仮決め済みです。動画配信を前提にした設計まで踏み込んで書かれており、提案範囲は技術スタック・開発方式・運用体制です。予算はPhase 1の金額が3000万円で固定提示、超過する場合は理由が必要です。ローンチ時期も固定で提示されています。

事前準備フェーズ

要求定義

ケース1では担当者へのヒアリングを通じて要求を掘る型を取りましたが、本ケースは違う型を取ります。コンペで自社が大穴という構造下では、書面質問や対面ヒアリングを使っても、相手は元々の企画を前提に話すだけになります。窓口担当者は事業企画の担当ではあっても、ビジネス的な核心部分の解像度はそれほど高くないのが通常で、深掘りしても表層の確認に終わります。よって本ケースの要求定義は、PMが自社内でRFPを読み込み、要求を再定義する作業として進みます。

RFPの読み込み

RFPには「動画を主軸にした社内教育」という方向性が書かれていました。新人のマナーや通常教育には動画が分かりやすい、という前提が置かれており、動画配信を前提にした設計まで仮決まっています。撮影・テロップ・前後のジングルといった、いわゆる動画教材の制作セットも所与の前提として書面に登場していました。

PMがここで引っかかったのは、「動画」という言葉が「mp4の動画ファイル」と固く結びついた状態で書かれていることでした。動画教材という発想に乗ること自体は分かるとして、その動画が必ず撮影・編集・配信のセットで作られなければならない、という前提までが思考停止で書面に乗っていました。

書面の権威に押されてこの前提を受け入れると、提案も書面の延長線上に収まります。技術スタック、開発方式、運用体制を、動画配信前提で組み立てるだけのものになります。それでは大手SIerと同じ土俵で戦うことになり、自社が勝てる余地はありません。

PMは引っかかりを流さず、もう一段奥に問いを置きました。RFPに書かれた達成目標は「動画教材を主軸とした社内教育プラットフォームを立ち上げ、新入社員のオンボーディングと社員教育を効率化する」というものです。ここで「効率化する」が結局何を指すのかを、PMは自分の言葉で置き直しました。突き詰めれば、「新入社員が定型業務などに早く慣れる仕組みを作り、教育そのものを会社の資産として蓄積していけるようにする」ということになります。

達成目標をこのレベルまで降ろすと、動画は必須の手段ではないことが見えてきます。動画は教材形式の一つにすぎず、「定型業務に早く慣れる」「教育を資産として蓄積する」という達成目標に対しては、他の手段の方が貢献しうる場面があります。少なくとも、動画配信システムを主軸に据える設計が必然である、という根拠は要求の側には存在していません。

PMはこの段階で、「動画は使ってもよいが、必須ではない」という判断にたどり着きました。代替手段の具体は、この時点ではまだ持っていません。それは受注前企画の段階で詰める話として、要求定義のレイヤーでは「達成目標の解像度を一段上げ、動画への固定を外す」ところで止めます。

予算設計

要求定義で達成目標の解像度が上がったところで、PMは予算設計に進みます。

提示予算は3000万円の固定です。PM術の手順どおり、まず利益を確保します。コンペで予算の枠が動かないこと、コンペ自体に提案コストがかかっていること、開発系プロジェクト固有の不確実性を考慮し、1000万円を粗利として確保しました。残りの2000万円が、企画と制作にあてられる枠です。

人日単価5万円で割って、使える総工数は400人日と算出されました。これが提案を組み立てる上での動かせない上限になります。

ここで一点、本ケースの予算設計の特徴を整理しておきます。ケース1では予算超過案を含めた松竹梅で提案を組みましたが、本ケースでは超過案は出しません。コンペで予算が固定提示されている場合、超過案は実質的に通らないというのが現実です。RFPに「超過する場合は理由が必要」と書かれていても、それは正規の手順を踏ませるための文言であって、コンペの審査では予算内に収めた提案が前提になります。超過案を組むコストを、本体予算内の提案を磨く方に振り向ける方が、合理的です。

ケース1のコラムで触れた予算超過案の考え方は、依頼ベースの案件で予算が動きうる場面では有効ですが、本ケースのように予算が固定されたコンペでは使いません。本ケースでは、お金は枠に収めて勝負を組み立てます。

受注前企画

要求定義で「動画は必須ではない」という判断が立ち、予算設計で総工数400人日の枠が固まったところで、PMは受注前企画に進みます。本ケースの受注前企画は、PMがプランナー兼任という編成上、PMが企画の中身まで踏み込んで組み立てます。

動画の代替を据える

PMが最初に詰めたのは、動画に代わる「プロダクトのキモ」です。RFPの達成目標を「定型業務に早く慣れる」「教育を資産として蓄積する」と置き直したことが、ここで効きました。

動画は流して終わるもので、見たあとに会社に残るのは視聴履歴だけです。それに対し、教育の資産化という達成目標を真ん中に置くと、別の機能の輪郭が見えてきます。具体的には、毎年の先輩のスキル習得パターンを保存し、次世代に継承していくカレンダー機能です。誰がどの時期に何を習得したか、どの順番で何に取り組んだかが年次で蓄積されていくことで、教育そのものが会社の資産として残ります。新入社員の側から見れば、この資産が「定型業務に早く慣れる」ためのガイドとして機能します。

動画は補助的な役割に降りる、という整理をしました。説明動画が必要な場面が残るとしても、それは先輩や社員が短いgif動画を撮れれば十分で、撮影・編集・配信の重い制作セットを動かす必要はありません。動画配信システムを主軸に据えるという仮決めは、ここで完全に外れました。

余剰工数の振り向け先

動画配信システム主軸の設計を外したことで、工数には大きな余剰が出ます。動画配信基盤の開発、配信運用の設計、関連する技術スタックの構築といった、RFPが暗黙に積んでいた工数が、まとまって浮く形になりました。

PMはこの余剰を、二つの方向に振り向けました。

一つ目は、管理者側の管理画面の追加です。RFPにはユーザー向けの画面構成しか書かれておらず、管理者側がプロダクトを運用するための管理画面は要求から完全に抜けていました。しかし、ユーザー向けだけではプロダクトは運用できません。管理者がコンテンツを登録・更新し、利用状況を把握し、組織変更に対応するための画面がなければ、ローンチ後の運用が必ず詰まります。PMはここを、UXまで作り込んだ管理画面として提案に組み込みました。これは要求の抜けを埋める追加であり、ローンチ後の運用が必ず楽になる機能です。

二つ目は、活用してもらうためのUX全般への作り込みです。日常で触れるプロダクトであるにもかかわらず、RFPはUXの最重要視を打ち出していませんでした。あわせて、スマホ対応も元のRFPには含まれていませんでした。社員が通勤時に見たい場面、見ながら定型業務を練習したい場面を考えれば、スマホ対応がない設計はそれだけで活用度を半分以下に落とします。PMはUXの作り込みとスマホ対応を、企画の柱として明示的に置きました。

自社の武器を活かす土俵に持ち込む

ここまでの組み立ては、達成目標から逆算して導いた結果ですが、同時に自社の強みを活かせる土俵に持ち込む狙いも入っています。両方が同時に効いた、という構造です。

自社のデザイン内製、PMがプランナー兼任で企画に深く入れる編成、これらは機能勝負・価格勝負の土俵では強みになりません。しかし、UXの作り込みと管理画面の使い勝手を企画の柱に据えた瞬間に、これらが直接的な武器に変わります。コンペで使える武器は何でも使う、というのが基本姿勢で、達成目標から導かれた結論と自社の強みを活かす狙いが一致した時点で、企画の方向は確定しました。

工程設計

受注前企画で「動画から別機能への組み替え」「管理画面の追加」「UXとスマホ対応の作り込み」が固まったことで、工程設計のIN/OUTは大きく組み替わります。

ここで効いてくるのが、PM術の「フラクタルなINとOUTの集合としてプロジェクトを設計する」という考え方です。要求定義レイヤーで「動画主軸」を外すという判断を一つ入れると、その下の工程設計レイヤーでは、各フェーズのIN/OUTが連鎖的に組み替わります。動画配信基盤の開発フェーズは消え、代わりにカレンダー機能の設計・実装フェーズが立ち上がります。動画コンテンツの配信運用設計は外れ、代わりに管理者UXの設計・実装が入ります。要求の抜けを埋めた管理画面は、その下にさらに細かいオブジェクトを抱えています。

これがオブジェクト指向プロジェクト設計の実例です。上位レイヤーで一つの判断が動くと、下位レイヤーのオブジェクトの構成そのものが変わります。動画前提の工程をそのまま削るのではなく、達成目標から再構成された企画に合わせて、工程のオブジェクトを組み直します。

具体の工数配分は、デザインとUX設計を厚めに、機能実装は標準的に、という形で組みました。総工数400人日のうち、企画・UX設計・デザインに重心を置き、開発フェーズは社内エンジニアチームで回せる範囲に収めます。詳細な配分は提案資料に落とし込みますが、ここでの本質は「IN/OUTの組み替えが工程の骨格そのものを変えた」という構造です。

チーム設計

工程設計の段階で各フェーズに当てる体制が固まりますが、本ケースのチーム設計はもう一段上から組み立てる必要があります。PM術のチーム設計は通常、見積もりと除外の判断という二軸で進めますが、本ケースのようなコンペでは、「他社との差分」という第三の軸も見ます。

内部の制約条件

PMは自社の編成上の制約を、最初から正確に把握していました。自社のエンジニアのレベルは標準で、高度な実装は得意ではありません。機能勝負では大手SIerに勝てず、価格勝負でも社員稼働である以上は効率が悪く、外注を入れれば粗利が一気に削られます。実装勝負はそもそも選べない、というのが内部の制約条件として最初に置かれていました。

一方で、デザイナーは標準的な水準にあり、企画次第で活きる余地があります。PMがプランナー兼任で企画に深く入れる編成も、企画とデザインを連動させる土俵では強みになります。

他社の制約の読み

PMは要求定義の段階で「動画は必須ではない」と判断していますが、それと同じタイミングで、他社の動きも読んでいました。RFPに積まれた動画配信システムの過剰要求（速度などの不要な要件が並んでいた、おそらく癒着SIerが設計に関わったと思われる重い仕様）は、本命の大手SIerにとっても工数を吸う要因になります。動画配信基盤の開発に体力を取られると、デザインとUXまで手が回らない可能性が高い。

これは大穴側から見ると、競合の制約として読める情報です。本命の大手SIerは、RFPの仮決めに乗る限り、動画配信基盤に工数を取られざるを得ません。デザインとUXに振り向けられる工数は限定的になります。

勝てる土俵を選び、その土俵に合わせて編成する

自社の制約と他社の制約を並べると、勝てる土俵は自動的に決まります。実装勝負は選べない、価格勝負も選べない、しかし企画とデザインの土俵では、競合がそこに体力を割けない構造的理由がある。よって、勝てる土俵は「企画＋デザイン＋UX」です。

土俵が決まれば、編成はそこに合わせて組みます。PM（プランナー兼任）1名、PL 1名、デザイナー2名を厚めに配置、エンジニアは社内のチーム体制でPL経由で機能ごとに管理。デザイナー2名という配置は、UXの作り込みと管理画面のUX設計の両方を抱える企画の重さに対する答えです。エンジニアをPL経由で管理する形にしたのは、PMが企画とデザインの作り込みに集中できる体制を作るためです。

見積もりと除外の二軸については、いずれも社内の慣れたメンバープールから当てているため、過去の実績がそのまま見積もりになり、除外の必要もありませんでした。これは通常の手順どおりです。

提案とプレゼン

事前準備フェーズで組み立てたものは、提案資料として形にし、プレゼンの場で出して初めて受注に至ります。本ケースの提案資料は、PMがプランナー兼任で企画から書き起こし、デザイナー2名と連動して、ビジュアルのモックも作り込んだ状態で提出しました。

要求とは違う提案を出すため、書面だけでは伝わりにくい部分が多くあります。動画ではなくカレンダー機能をプロダクトのキモにする、管理画面のUXまで作り込む、スマホ対応で日常的な使い方を組み立てる、といった方向性は、文字情報だけだと「RFPに書いてないことを言っている」としか受け取られません。PMはここを、ビジュアルのモックで視覚的に補完しました。プランナー兼任で企画の意図を握っていることが、デザインの方向と細かくすり合う形で効いてきます。

プレゼン本番

プレゼン本番で、PMはオープニングに「教育動画は誰も見ない」という、文字だけのスライドを置きました。RFPの大前提を真っ向から否定する一文を、最初に出す構成です。

スライドが出た瞬間に、会場の空気が真っ二つに割れました。窓口の担当者は明らかに困惑し、その隣にいた事業部の部長は「おっ」という反応を見せました。担当者の困惑は予想していたものでしたが、部長の反応はPMにとって、提案が刺さる余地を持っている合図になりました。

オープニングのあと、PMはRFPの企画の問題点を順に指摘していきました。

説明動画は誰も最後まで見ない、特に若い人は見ない。全動画一律のロゴ・イントロ・タイトルは、見るたびに無意味なノイズが繰り返されるだけで、教材としては逆効果になる。動画というフォーマットは、ぶつ切りの知見を分かりやすく見せる点では有効でも、教育で本当に重要なタイミングや順番を組み立てる手段としては弱い。スマホで見れない想定は、そもそも日常で触れるプロダクトの設計として成立していない、通勤時に見たい人もいれば、定型業務を練習しながら参照したい人もいる。日常で触れるものなのに、UXを最重要視しないのはおかしい。

これらを順に指摘したうえで、動画を主軸から外した代わりに、カレンダー機能を中心に教育を資産化する企画、ユーザーと管理者の両側を作り込んだ運用設計、UXとスマホ対応を企画の柱に据えた構成、を順に出しました。各論点には、デザイナー2名で作り込んだモックが添えられており、要求と違う部分が視覚的に伝わる構成になっています。

担当者の困惑は最後まで残りましたが、部長の反応は最初から最後まで一貫して前のめりでした。指摘を出すたびに、部長から「それは確かにそうだ」という温度のうなずきが返り、企画の中身に踏み込んだ質問もいくつか出ました。全体としては、手応えのある熱めの空間で進みました。

結果

プレゼンの結果、コンペは自社が受注しました。担当者ベースでは本命だった大手SIerを飛び越えて、大穴の自社が選ばれた形です。

部長の反応が決定打になったことは、後日の経緯からも見て取れました。担当者の困惑は最後まで解けないままでしたが、部長の側で「この提案でいく」という意思決定が下りた、というのが実際の流れでした。

刺さる余地を残して組んだ提案が、本番で実際に刺さった、という結果です。狙って部長に刺したわけではなく、攻めた提案を組んだ結果として、部長というポジションにいる人物がプレゼンに同席し、そこで刺さった、という偶然性を含んだ構造です。事前にPMにできたのは、刺さる余地を残して組むところまでで、本番でその余地が機能するかは構造的に確率の問題でした。

受注後について

本ケースは事前準備フェーズに焦点を当てたケースのため、受注後の実作業フェーズ以降は扱いません。実作業フェーズで起きる事象、特にこの規模の開発系プロジェクトでの工程進行と異常検知の様相は、別のケースで扱います。

本ケースのまとめ

本ケースを通じて、事前準備フェーズの手順がコンペにも適用可能であること、ミニマックスの本当の意味、真の決裁者の見定め方、が現場の判断としてどう機能するかを追いました。

要求定義のレイヤーでは、書面化されたRFPに対してももやもやセンサーが働くことを確認しました。動画主軸という仮決めが達成目標に対して過剰だ、という引っかかりを流さずに、達成目標を「教育の資産化」まで降ろすことで、動画への固定が外れました。これはケース1で担当者の発言の奥に中期方針を見たのと同じ動きを、書面に対して適用した応用編です。

要求定義の判断が工程設計のIN/OUTに連鎖的に波及したことは、フラクタルなINとOUTの集合としてプロジェクトを設計するというPM術の考え方の実例です。動画から別機能への組み替え、管理画面の追加、UXとスマホ対応の作り込みは、要求定義レイヤーの一つの判断が下位レイヤーのオブジェクトを再構成した結果でした。

チーム設計では、自社の制約と他社の制約の双方を見て、勝てる土俵を選び、その土俵に合わせて編成を組むという、コンペ固有の組み立て方を取りました。実装勝負は選べない、しかし企画とデザインの土俵では競合に体力的余地がない、という構造の読みが、デザイナー2名を厚めに配置する編成判断を支えました。

プレゼンでは、担当者を立てる通常の姿勢を反転させ、窓口を飛び越えて上に刺さる余地を残す形で提案を組みました。コンペで大穴の場合、担当者は社内の安全策として本命に投票する立場にあるため、担当者を立てる戦略では勝てません。ただし、上に刺さるかどうかは構造的に偶然性を含みます。狙って刺せるものではなく、刺さる余地を残して組む、ということが正確な書き方です。

そして、攻めた提案を組むという判断そのものが、PM術のミニマックスの応用として正しい判断であったことを、コラムで言語化しました。「ダメならいいや」は心情ではなく、最大損失の見積もりの問題です。無難な提案の最悪ケースのほうが、攻めた提案の最悪ケースより損失が大きい、という構造を理解していれば、攻めることは合理的な選択になります。

型はあくまでテーラーするための素材であり、状況に応じてPMが姿勢を変える、というPM術の基本姿勢が、本ケースを通して具体的に確認できます。