数ヶ月前、ウェブサイトの素晴らしいアイデアを思いつきました。そして、さらに「素晴らしすぎる」アイデアを思いつきました。ウェブサイトは作るけれど、作業はすべて外注してしまおうというのです。

優れたウェブサイトはすべてMVP、すなわちミニマム・バイアブル・プロダクト（実用最小限の製品）から始まります。アイデアを最もシンプルな形で示し、そもそも需要があるのかを検証するためのものです。TwitterがMVPを公開したときは、ラセットポテトの写真しかツイートできませんでした。Slackはピッグ・ラテン語にしか対応していない状態で華々しくローンチしたことで有名です。Netflixは今やインスタントストリーミングと同義になっていますが、最初のバージョンでは映画を選んでから数日間、リード・ヘイスティングス本人が自宅までやって来てあらすじを演じてくれるのを待たなければならなかったことを、もう忘れてしまっているかもしれません。

MVPを作るために、私はシンプルな計画を立てました。

1. 簡単な設計書をさっと書く。
2. 最もトレンディで最先端のウェブフレームワークで10年の経験を持つ、ロックスター級のフリーランス開発者を見つける。
3. 利益を最大化するために、そのフリーランスに時給4ドルを提示する。
4. あとはMVPが花開き、何百万人もの熱狂的なユーザーで賑わい、みんなが我先にお金を払いたがる大人気サイトへと成長していくのを見守る。

驚かれるかもしれませんが、この計画はうまくいきませんでした。今この文章を書いているのは、シリコンバレーにある2億ドルもする豪華な2ベッドルームアパートからではありません。Facebookによる法外な買収で見出しを飾ったわけでもありません。代わりに、中途半端な成果物を受け取り、なぜかフリーランスのフリーランスになってしまった状態で、変わり映えのしない1ベッドルームのアパートから書いています。

アイデア

私はケトジェニックダイエットを実践していて、いろいろなレシピを試すのが好きです。ネット上には優れたレシピがたくさんありますが、何十ものブログに分散しており、それぞれ構造がバラバラです。ケト系のブロガーがウェブ開発の経験を持っていることは稀なので、これらのブログは表示が遅く、使いにくいことが多くなっています。

私のアイデアは、ケトジェニックレシピのディレクトリサイト「KetoHub」でした。ウェブ上にあるレシピを集約して、一つの使いやすいウェブサイトにまとめるというものです。

フリーランスを探す

KetoHubの作業の大部分はウェブスクレイピングでした。レシピブログをクロールして関連データを抽出する作業です。これはUpworkやFiverrのようなフリーランス開発者向けサイトではよくある案件です。安い価格で誰かを見つけられるかもしれませんが、MVPを超えて機能を拡張しようとしたときに、コードがボロボロに崩れてしまう可能性もあります。

あ、待ってください。この仕事は友人のファーンガリーにぴったりではないでしょうか（彼女について書くにあたり、ふざけた仮名をつけることを条件に許可をもらっています）。彼女は最近仕事を辞めて旅に出ていましたが、数日後には戻ってきてフルタイムの仕事を探す予定でした。それまでの間なら、フリーランスとして時間が取れるはずです。以前一緒に働いたことがあるので、彼女が優秀な開発者であり、一緒に仕事がしやすいことも知っていました。

早速彼女に連絡を取ると、すぐに乗り気になってくれました。過去の仕事から、私のコードレビューが細かくて口うるさい厳格であることは彼女も知っていました。私の厳しい基準に応えるチャレンジを楽しみにしていると言ってくれました。

私はウェブサイトの構成要素を高い視点からまとめた設計書を書きました。バックエンドのスクレイピングはファーンガリーが担当し、私はレシピを表示するためのシンプルなウェブフロントエンドを作ることにしました。

なぜ公開できないのか

プロジェクトについて最初にファーンガリーと話したとき、彼女は締め切りはあるかと聞いてきました。「締め切りはありません。とにかく良いコードを書くことに集中してください」

これは私が一緒にサイドプロジェクトをする開発者にはいつも言っていることです。月曜日に急ごしらえのコードを受け取るより、木曜日に高品質なコードを受け取る方が良いと思っています。ファーンガリーの担当分は30〜50時間で実装できると見積もっていました。1週間もあれば終わるでしょう。見積もりが外れていたり、彼女が週40時間以下しか働かなかったとしても、2〜3週間もあれば十分なはずでした。

当時、私は本業が忙しい時期でした。フロントエンドを作る時間を確保できるまで、何ヶ月もかかるかもしれません。どう考えてもボトルネックは私の方でした。

設計書を書き終えた後、もしファーンガリーがスクレイピングのコードを納品しても、それが何ヶ月も引き出しの中で眠るだけになったら拍子抜けだなと思いました。そこで数日間夜なべして、基本的なフロントエンドを組み上げました。手作業でスクレイピングしたサンプルレシピが表示されるものです。ファーンガリーの作業が終わり次第、本番のレシピデータを組み込んですぐに公開できる状態になりました。

そのあたりから、私は不安になり始めました。

ウェブ部分の完成には1週間かかりましたが、ファーンガリーからはまだ一行もコードが届いていませんでした。彼女は何をしているのでしょうか。

フロントエンドを作る前は、プロジェクトはストレスとは無縁でした。しかしダミーデータで動くサイトができてしまうと、生き物を檻に閉じ込めているような気分になりました。日が経つごとに、私のコードは古びて陳腐化していきます。早くKetoHubを世界に公開して、マーク・ザッカーバーグが個人情報収集用のスーパーヨットでシャンパンに招待してくれる段階まで一気に進みたいだけでした。

限られた稼働時間での作業

ファーンガリーから最初のコードレビューが届いたのは、2週目の終わりでした。最初のバックエンドコンポーネントの部分的な実装でした。彼女は週平均15時間ほど作業していましたが、翌週の月曜日からはフルタイムの仕事が始まるとのことでした。それ以降は稼働時間がさらに減ることは確実でした。

設計書を見直して、削れる部分がないか確認しました。当初の設計では、バックエンドがレシピデータをウェブサイトのデータストアにプログラムから直接アップロードすることになっていました。ローカルファイルシステムにデータを書き出すだけにすれば、ファーンガリーの作業を減らせます。あとは既存のコマンドラインツールを使って、私がそのデータをサイトにアップロードすれば良いのです。

まあ、時間が限られているのは良いことかもしれません。MVPから要素を削っても同じ目的を達成できるのなら、それはそもそも最もミニマルな形ではなかったということです。

あと数週間で終わらせられるだろうと楽観的に考えていました。

フリーランスのフリーランスになる

残念ながら、仕事が始まったことでファーンガリーの稼働時間は私の予想以上に減ってしまいました。翌月、彼女がKetoHubに充てられた時間は週平均5時間未満でした。このペースでは、完成まで数ヶ月かかってしまいます。

相手が別のフリーランスだったら、これまでの作業に感謝して新しい開発者を探していたでしょう。しかしファーンガリーは友人であり、しかも新しい仕事のストレスを抱えている最中でした。もっと時間を取ってほしいとせっついたり、プロジェクト計画を大きく変えたりして、彼女の負担を増やしたくありませんでした。それでも、締め切りについて聞かれたときにあんなに甘い対応をしてしまった自分を悔やみました。

彼女の仕事の一部を自分に振り替えることも考えました。いや、自分が雇われた仕事を依頼主が勝手にやってしまったら、私だって良い気はしないでしょう。設計書を再び見直して、さらにシンプルにできないか考えましたが、もう削れるものは見つかりませんでした。そこで、開発プロセスを調整して、彼女にかかっている時間的コストを自分側に移せないかと考え始めました。

ちょっと待ってください。一体何が起きているのでしょうか。KetoHubを外注したのは自分の時間を節約するためだったのに、今は自分の時間よりもファーンガリーの時間を最適化するためにプロジェクトを作り直しています。どうして自分が、自分のフリーランスのフリーランスになってしまったのでしょうか。

コードレビューを簡略化する

誰が誰のフリーランスなのかはともかく、私はとにかくプロジェクトを、そしてできるだけ早く完成させたいと思っていました。削れる最大の時間的コストは、悪名高い私の細かすぎるコードレビューでした。

レビューは二人にとってコストが高いものでした。私はコードレビューに多大な労力を注いでいますし、ファーンガリーも私の指摘を反映させるのに時間がかかります。レビューのラウンド間に数日から数週間の遅延があれば、どこまで進んだかの文脈を思い出すだけでも時間を浪費してしまっていました。

時間を節約するために、ファーンガリーへの指摘をやめることにしました。彼女から次のチェンジリストがレビューのために届くと、私はそれをそのままマージし、自分の基準に合うように少しだけ手を加えました。すると、あっという間に最初のバックエンドコンポーネントが完成しました。残りはあと二つです！

割に合わない

ファーンガリーは、私のこの妙案ともいえる時短テクニックにあまり乗り気ではありませんでした。厳しいレビューは彼女にとって技術的な成長の機会でした。それがなければ、KetoHubはただの作業であり、彼女は本業だけで十分仕事を抱えていたのです。

指摘を再開すべきか迷いました。指摘を省いていたときでさえ、フリーランスを使うことで本当にトータルで時間を節約できているのかどうか分かりませんでした。もしまた指摘を書き始めたら、時間的には確実にマイナスになります。フリーランスに決して安くない時給を払いながら、自分でコードを書くよりも多くの時間を費やすことになるのです。

二人で話し合い、ファーンガリーがKetoHubに関わり続けるのはもはや理にかなっていないという結論に至りました。最初のコンポーネントが完成したところで、彼女がプロジェクトから離れるには良いタイミングでした。

自分で実装する

ファーンガリーとの仕事を終えた翌週の土曜の夜、私は彼女が残したところから作業を引き継ぎ、MVPが公開できるまでやり切ると決めました。午前2時までに、最初のバージョンが完成しました。見た目があまりに素っ気なくて恥ずかしかったのですが、とにかく完成したのです。

すぐに気づきました。最初から一人でやるべきだったのです。

プロトタイプでは、トレードオフに関する小さな決断が無数に必要になります。レシピの10%にしか影響しないバグを修正するために、さらに1時間を費やすべきでしょうか。どのモジュールに自動テストを書くべきでしょうか。こうした問いの答えを事前にフリーランスに指示しておくことなど不可能です。一人で作業すれば、直感に従って決めれば良いのです。

自分で作ることで、設計の弱点を修正するのもずっと簡単になりました。たった二人のチームでさえ、設計の欠陥は大きな摩擦コストを生みます。ファーンガリーが問題を見つけたときは、私に確認し、私が設計書を更新し、彼女がそれを読み、一部の作業を捨て、ようやく新しい設計に沿って再実装しなければなりませんでした。一人でやれば、その全プロセスがほぼ一瞬で済みます。

最後に、バックエンドを外注することで、ビジネスの核となる部分を自分自身から見えなくしていました。自分で手を汚してウェブスクレイピングをやってみると、将来のKetoHubで活用できるレシピデータのアイデアが次々と浮かび、サイトの設計上の制約についても理解が深まりました。

教訓

問題はあったものの、このプロセスは新しいウェブサイトを作ることやフリーランスと働くことについて重要な教訓を教えてくれました。最大の教訓は、もしあなたが開発者なら、自分のMVPは自分で作るべきだということです。

それでもフリーランスと働くことを選ぶなら：

• 目標の完了時期について話し合う。
  • 厳格な締め切りを設定する必要はありませんが、事前にお互いの想定が同じくらいの範囲にあるか確認しておきましょう。
• 週あたりの稼働時間を合意する。
  • フリーランスには他のクライアントや優先事項があるかもしれません。あなたのプロジェクトにどれだけ時間を割けるのかを確認しておきましょう。

この記事はSamantha Masonによって編集されました。

ケトジェニックダイエットをしていて新しいレシピを探しているなら、この記事でずっと語ってきたウェブサイトKetoHubをぜひチェックしてみてください。