プロジェクト管理の方法：何を作るか分からないときの進め方

目次

• 曇った写真：waterfallとagileでは足りない理由
• 解像度を獲得できた合図：組織図が描ける
• 部署が先、人が後

  • 大企業の組織図をコピーしない
• 最小実行可能チーム
• 確実な領域か研究開発（R&D）か：お金の行き先を決めるラベル

  • ルール1：全部をR&Dにはできない
  • ルール2：それぞれでお金の使い方を変える
  • ルール3：1日あたりの試行回数を最大化する
• 縦切り（バーティカルスライス）と3つのバージョン

  • 各機能をカバーする5つの道
• ツールを買う前に計算する
• 消すはめになる図をスケールしない
• 準備ができる前に公開する
• ローンチは成功ではない
• 本当の資産：playbook（プレイブック）
• メソッドのまとめ
• 今週の演習
• 動画で見る

曇った写真：waterfallとagileでは足りない理由

自分のプロジェクトと、その対象となる市場の写真を想像してください。最初は曇っています。色の染みは見えるし、形は推測できるけれど、細部は判別できない。天然酵母のパン屋を開きたい。いいパンに余分にお金を払う人がいることは分かっている。でも、その人数も、買う時間帯も、本当の問題がオーブンなのか配達なのかも分からない。

この曇った写真がスタート地点で、これを飛ばす方法はありません。できるのは解像度を上げることだけで、解像度が上がる方法はひとつしかない。動くことです。対応した顧客、交渉した仕入先、公開したバージョンが、それまでなかったピクセルを返してくれます。

ここで、2つの古典的モデルが壊れます。

• Waterfall は、地図がすでに分かっている前提です。だからこそ PMBOKは起業家には部分的にしか役立たない のです。
• Agile は、イテレーションが必要だと認める分だけ誠実ですが、バックログがすでに定義済みだと前提しています。次の2週間で何をやるべきか分かっている、と。

テクノロジーもチャネルも、さらには顧客の行動までも四半期ごとに変わる環境では、どちらの前提も成り立ちません。必要なのは別のものです。完全な計画ではなく、チームと同じペースで詳細さを増していく、低解像度の計画です。

解像度を獲得できた合図：組織図が描ける

ここはほとんど誰も言わない部分で、このフレームワーク全体で一番役に立つところです。

必要な組織図を正確に描けるようになったら、解像度を獲得できています。タスクのリストではありません。roadmapでもない。組織図です。どの機能が存在し、各機能に何人入り、どれが内製で、どれをプロジェクト単位で外注し、どれを人ではなくテクノロジーで解決するのか。

それが描けないうちは、まだ曇ったままです。そして曇ったままなら、大量採用も大きな資金調達もすべきではありません。

問いの変化に注目してください。「製品はいつ完成しますか？」ではなく、**「これをちゃんとやるために、自分の組織はどんな形であるべきか、いつ分かるのか？」**になるのです。

部署が先、人が後

プロジェクトを分解するとき、人は「デザイナーが必要」「営業担当が必要」「community managerが必要」と考えがちです。それは順序の誤りです。

まず部署に分解します。そしてここに、すべてを変える定義があります。

部署とは問題。役割とは、学び取られた解決策。

コンテンツ制作会社を開くなら、「動画制作」は職種ではありません。解決すべき問題です。「顧客の獲得」は問題。「期日どおりの回収」は問題。役割はその後で来ます。問題を十分に理解して、どんなタイプの人間がそれを解くのか分かってからです。

これを混同すると、まだ理解していない問題のために立派な肩書きの人を採用し、4ヶ月後に問題は別のものだったと気づくことになります。

大企業の組織図をコピーしない

同じ業界の人と話すのは、いつでもいいことです。ただし大企業の構造はコピーしない。会社が成長すると、災害を防ぐことだけが仕事の人を組み込みます。承認、確認、調整、ふるい分け。千人の会社なら正当なことですが、8人のプロジェクトでは毒です。

初日からその構造をコピーすれば、チームのかなりの部分が生産ではなく監督に回ります。解像度は増えません。増えるのは会議です。

最小実行可能チーム

誰もが最小実行可能製品（MVP）について語ります。最小実行可能チームについて語る人は、ほとんどいません。

ルールはこうです。最初のバージョンでは深さではなく幅を探します。1部署1人。2人でも、チームでも、部下を従えた責任者でもなく。特定した問題ごとに1人。必要な7割しか満たしていなくても。

心もとなく聞こえますし、実際そうです。ただ、この最初の編成の目的は完成したプロジェクトを納めることではなく、穴がどこにあるかを見つけることです。薄い編成でサイクル全体を通ると、継ぎ目が見えてきます。

• どこで全部が詰まるか、
• どの機能が2人分の仕事をしていたか、
• どの問題が実際は些細だったか、
• そしてどれが本当のボトルネックだったか。

これがあれば、想像していた場所ではなく、役に立つ場所に深さを足せます。

確実な領域か研究開発（R&D）か：お金の行き先を決めるラベル

フレームワーク全体のなかで、今週すぐ使えるのがこのツールです。部署のリストを取り出して、それぞれに2つのラベルのどちらかを貼ります。

**確実な領域。**方法を知っています。世界一であるという意味ではなく、やり方を正確に知っていて、誰かに説明できるという意味です。ここではスケールはお金の問題です。人を増やし、道具を増やせば、成果も増えます。予測可能です。

**研究開発（R&D）。**方法を知りません。時間が足りないのではなく、チームのだれもまだ解き方を知らないのです。ここではお金ではなく実験で拡大します。そして創業者自身の直接的な注意が必要で、委譲はできません。

	確実な領域	研究開発（R&D）
方法を知っているか？	知っている。教えられる	いいえ、チームのだれもまだ知らない
スケールの方法	お金で：人員か道具を増やす	実験で
1ユニットあたりの支出	高い：リターンは予測可能	低く軽い：賭けである
チームと道具	買って投資する	借りて試す
担当者	委譲できる	創業者が必要

ルール1：全部をR&Dにはできない

本当にイノベーションする1〜2の部署を選び、他はすべて確実な領域にします。プロジェクト全体がR&Dラベルなら、6ヶ月のプロジェクトではなく4年のプロジェクトです。しかも、たぶんその前に資金が尽きます。

そして、どこでイノベーションするかはよく選んでください。クリエイティブな部分がすでに得意なら、そこにR&Dは要りません。そこは支えにして、エネルギーは自分が支配できていない領域に注ぎます。

ルール2：それぞれでお金の使い方を変える

1ユニットあたり、すでにできることには多くを、できないことには少なく使います。確実な領域に置いた1ドルは1ユニットの成果を返す。R&Dに置いた1ドルは、外れるかもしれない賭けです。R&Dの役割は安く、軽く保ちます。

必要だと分かっているサービスにはいい値段を払い、役に立つか分からない実験には安い報酬のパイロットしか出さない、あの顧客と同じ論理です。同じことは自分自身の賭けのポートフォリオにも当てはまります。それを極端まで押し進めたのがバーベル戦略90/10です。

ルール3：1日あたりの試行回数を最大化する

R&Dでは、速さは働いた時間ではなく試行で測ります。3ヶ月かけて解くはずだったことを、20回のテストで5日で解くのです。

サイクルを短縮するものであれば、事前に時間を投資する価値があります。レンダリングを待つのではなく結果をライブで見ること。2週間後にフィードバックをもらうのではなく、決定権のある人に、作っている最中から見てもらうこと。

縦切り（バーティカルスライス）と3つのバージョン

何を作っているのか分からないとき、最悪の戦略は全部を中途半端に作ることです。最良のものは縦切りです。プロジェクトの小さなひとまとまりを取り、最初から最後まで、深さすべて込みで完成させるのです。

オンライン講座の最初の10章を中途半端に作るのではなく、1章を完全に作ります。動画、演習、サポート、決済、フォローまで。この切片が学習の単位です。

そして、およそ3回繰り返します。

1. **1周目。**最小実行可能チームで作るので、出来はそこそこです。それでも公開し、フィードバックを集め、本当に難しい問題がどれだったかを突き止めます。
2. **2周目。**もう同じ理由では失敗しません。別の理由で失敗し、その別の理由が新しい情報です。
3. **3周目。**もう製品を発見しているのではなく、組織図を調整しています。

3周の本当の目的はこれです。完璧な製品に到達することではなく、機能の完全な地図に到達すること。どの機能が必要で、どれが内製で、どれが契約で、どれには市場のだれもやり方を知っている人がいないのか、を知ることです。

各機能をカバーする5つの道

各機能について、結局は5つの道から選ぶことになります。そして選択が明白になるのは、解像度を獲得してからです。

1. **内製する。**すでにチームにいる人で。
2. 正社員を採用する。
3. テクノロジーに置き換える。
4. 一時的に外注する。
5. 外部メンターをつけて社内で育成する。

最後の道が一番遅く、必要な人材が市場に単純に存在しないときの、唯一の選択肢になることもあります。

ツールを買う前に計算する

テクノロジーに投資すべき正しいタイミングがあります。「買えるようになったとき」ではありません。計算が求めるときです。

手順はシンプルです。

1. 1人が何か1ユニットを生産するのにかかる時間を測る。
2. 完成に必要なユニット数をかける。
3. 期限で割る。手作業を続けた場合に何人必要かが出ます。
4. その年間コストと、それを自動化するツールのコストを比較する。

たとえば、1人が動画を編集するのに2時間かかり、600本の動画が必要で、期限が3ヶ月（1人あたり約480時間）なら、これだけに専念する人員が2.5人必要になります。人数が馬鹿げた数字になったとき、答えは出ています。しかも、パートナーや投資家の前でそれを守る数字の根拠まで手に入ります。

この計算には、2つのルールが伴います。

• **R&Dのあいだは借りて、確実な領域になったら買う。**二度と使わないかもしれない機材に資本を固定しない。ただし、部署がラベルを変えたらすぐ投資する。そこではもう賭けていません。スケールしているのです。
• どの見積もりにも30%のバッファを足す。そして、どの補完的な役割が主力を加速するか自問する。生産を倍にする最安の方法が、高価な専門家をもう1人雇うことではなく、その人の土台を整える誰かを置くことであることもあります。

消すはめになる図をスケールしない

最後に、すべてのなかで一番高くつく間違いにたどり着きます。戦略の間違いではなく、順序の間違いです。

3周を終えて組織図がはっきりしたら、それがスケールのタイミングです。お金を入れ、採用し、道具を買う。それより前はだめです。

理由は、組織図の描き直しには低解像度への逆戻りが要ること、そして大きなチームは描き直せないことです。5人なら、ピボットは午後1回の会話で済みます。40人なら、約束した人を解雇し、チームがすでに染み込ませた働き方と衝突することです。組織は抵抗します。それが当然です。

だからこそ、順序がこれほど大事なのです。まず形を見つけ、その後に燃料を注ぐ。形を知る前に大きなラウンドを調達すれば、買うのは速さではなく、一発で当てなければならないという義務です。

そして、計画にほぼ入らないカレンダーの細部があります。必要な人を見つけ、口説き、引き継ぎ期間を終えるまでに、3〜4ヶ月かかります。採用計画は、その1四半期分、前倒しで回しておく必要があります。

準備ができる前に公開する

このメソッド全体が、ひとつのものにかかっています。本物のフィードバックを受け取ることです。そして本物のフィードバックは、仕事を見せなければ届きません。これは Steve Blankのcustomer development や1週間でアイデアを検証するの背後にあるのと同じ考えです。

中間バージョンの公開は、3つのものを同時にもたらします。

• **形。**あらゆる批判が、解像度のピクセル1つ分になるから。
• **人材。**見たこともないアイデアのために安定した仕事をやめる人はいませんが、中途半端でもすでに存在するものには、多くの人が参加するから。
• **メンター。**本物の経験がある人は、本気だと確認できなければ時間を割いてくれないから。

不完全な仕事を見せることは、評判のリスクではありません。足りないピースを手に入れるための仕組みです。

ローンチは成功ではない

プロジェクトは、ローンチしたから成功なのではありません。誰の心にも残らないものが、毎日ローンチされています。満足する前に、どの信号を見るかを定めてください。

• **本当に好かれているか。**試した人の重要な部分、たとえば半数が気に入ること。
• **払う意思があるか。**何パーセントが払うと言うか。その数字は常に膨らんでいると知ったうえで、探すべきは割合であって数字ではない。
• **市場はあるか。**自分のやっていることに、本当にどれだけの人がいるのか。

本当の資産：playbook（プレイブック）

サイクル全体を回し終えたとき、持ち去るのはプロジェクトより価値のあるものです。playbookです。

そして、やり方を書き留めた文書のことではありません。文書は読まれますが、学ばれない。マニュアルを読んで動画編集を習得した人はいません。playbookとは、発見した組織図、構築した協力者とメンターのネットワーク、そしていまチームの頭のなかに生きている判断力のことです。

それが資産です。プロジェクトは、それを生み出した言い訳にすぎません。

メソッドのまとめ

1. 曇った写真から始まることを受け入れ、解像度を上げるのは動きだけだと認める。
2. プロジェクトを、人ではなく部署（問題）に分解する。
3. 最小実行可能チームを組む。1部署1人。
4. 各部署に確実な領域かR&Dかのラベルを貼り、R&Dは最大2つまでにする。
5. 完全な縦切りを1つ作り、およそ3回繰り返す。
6. 計算が求めたときに道具へ投資する。それより前ではない。
7. 正確な組織図が描けたときだけスケールする。

今週の演習

いまプロジェクトの真ん中にいるなら、これをやってください。人のリストではなく部署のリストを書き、それぞれに確実な領域かR&Dかのラベルを貼ります。

R&Dが3つ以上あったら、そこに期限の問題があります。

動画で見る

解説を動画で見たい方は、こちらで手法の全体をご覧いただけます（スペイン語）。

YouTubeで見る