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

優れたウェブサイトはすべてMVP、すなわちMinimum Viable Product（実用最小限の製品）から始まります。アイデアを最もシンプルな形で提示し、誰かが興味を持ってくれるかを試すものです。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から要素を削っても同じ目的が達成できるなら、そもそもそれは最小限ではなかったということです。

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

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

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

相手が別のフリーランスなら、これまでの作業にお礼を言って新しい開発者を探したところです。しかしファーンガリーは友人であるだけでなく、新しい仕事のストレスを抱えている最中でした。これ以上負担をかけたくなくて、もっと時間を確保してほしいとも、計画を大きく変えようとも言い出せませんでした。それでも、締め切りについて聞かれたときにあれほどゆるく構えていた自分を悔やみました。

彼女の作業の一部を自分が引き取ろうかとも考えました。でも、自分が仕事を依頼した相手に、やっぱり自分でやると言われたら嫌なはずです。設計書をもう一度見直してさらに削れないか検討しましたが、削れる部分は見つかりませんでした。そこで、彼女の時間的負担を私の方へ移すために、開発の進め方自体を調整できないか考え始めました。

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

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

誰が誰のフリーランスであれ、私はプロジェクトを早く終わらせたいと思っていました。削れる最大の時間的コストは、私のこだわりで有名なコードレビューでした。

レビューは二人にとって負担が大きいものでした。私はコードレビューにかなり力を入れていますし、ファーンガリーも私の指摘を反映させるのに時間がかかります。レビューの往復に数日から数週間も空けば、今どこまで進んだのかという文脈を思い出すだけでも時間を浪費していました。

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

これはおかしい

しかしファーンガリーは、私のこの clever な時間節約術をあまり喜びませんでした。厳しいレビューがあるからこそ技術的に成長できるのです。それがなければ、KetoHubはただの仕事でしかなく、仕事は本業で十分足りているということでした。

指摘を続けるべきか迷いました。指摘を省いても、フリーランスを雇うことで本当に時間が節約できているのか分かりませんでした。もしまた指摘を再開すれば、間違いなくマイナスになります。フリーランスに決して安くない時給を払いながら、自分でコードを書くよりも多くの時間を費やすことになるのです。

話し合った結果、ファーンガリーがKetoHubから離れるのが合理的だという結論になりました。最初のコンポーネントが完成したところで、ちょうど引き継ぎの良いタイミングでした。

自分で実装する

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

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

プロトタイプでは、トレードオフに関する細かな判断が無数に必要になります。レシピの10%にしか影響しないバグを直すために1時間かけるべきか。どのモジュールに自動テストを書くべきか。こうした答えを事前にフリーランス向けに仕様化することは不可能です。一人でやれば、直感に従ってすぐに決められます。

自分で作ることで、設計の弱点もはるかに直しやすくなりました。2人のチームでも、設計の欠陥は大きな摩擦を生みます。ファーンガリーが問題に気づいたら、私に確認し、私が設計書を更新し、彼女がそれを読み、作業の一部を捨て、ようやく新しい設計に沿って作り直す必要があります。一人でやれば、その全工程がほぼ一瞬で終わります。

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

教訓

いろいろと問題はありましたが、この過程から新しいウェブサイトの立ち上げやフリーランスとの仕事についていくつか大切なことを学びました。最大の教訓は、もしあなたが開発者なら、自分のMVPは自分で作るということです。

それでもフリーランスと仕事をするなら：

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

この記事はSamantha Masonが編集しました。

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