スタートアップの開発チーム:どの種類に頼み、どう選ぶか

何を作るのかを知らずに、あなたのスタートアップに合う会社を正直に名指しできる人はいない。選択を決めるのは二つのことだ:プロダクトのどれだけが難しいエンジニアリングに依存しているか、そしていまどの段階にいるか。普通のウェブやモバイルのプロダクトなら、たいていは小さなプロダクトスタジオか、シニアのフリーランス二人で足りる。あなたが技術者でないなら、そこに経験のある技術アドバイザーを自分の側に加える。なかには、何か難しいものが動いて初めて成り立つプロダクトもある。たとえばトレーディングプラットフォームや、ユーザーが待っているあいだに判断を下すモデルだ。そうしたプロダクトには、その種のシステムをすでに本番で動かしている会社を探す。

スタートアップが頼める開発チームには、どんな種類があるか

スタートアップが頼めるチームには六つの種類がある。時間単価より大事なのは、ほかの二つのことだ:誰が仕事を計画するのか、そして仕事が止まったとき、プロダクトについての知識がどこに残るのか。

フリーランスとは、直接契約する一人のエンジニアで、時間単位かタスク単位で支払う。フリーランスが向いているのは、プロトタイプや、ランディングページや管理画面のような、範囲のはっきりした単発の仕事だ。管理は自分で行う。そして一人が去れば、その人がプロダクトについて知っていたことも一緒に去る。

受託開発会社やプロダクトスタジオは、デザインも含めて最初のバージョン全体を作る。支払いはたいてい固定価格か月額だ。良いスタジオは、あなたのものと似たプロダクトを数多く世に出していて、会員登録や決済のようなよくある部分をよく知っている。弱いのは、プロダクトの難しい部分が珍しい種類のものである場合だ。プロジェクトを売り込む人たちが、実際に作る人たちでもあるのかを尋ねること。

専門特化したエンジニアリング企業は、難しいシステムの狭い領域を扱う。たとえばトレーディングプラットフォームや、1秒に満たない時間で応答しなければならない広告オークションだ。そうしたシステムが本番で動いているところを見せられる。支払いはスタジオや専任チームと同じで、プロジェクト単位か月単位だ。普通のアプリには向かない。使いもしない専門性に金を払うことになるからで、この種の良い会社なら自分からそう言う。

専任チームとは、外部の会社のエンジニアのグループで、あなたのプロダクトだけに取り組み、月額で支払われる。固定価格で頼むには計画が変わりすぎる段階に合う。何を次にやるかを、あなたの側の誰かが毎週決めなければならない。

社内のエンジニアはあなたの従業員なので、プロダクトの知識は会社の中に残る。それが最も効いてくるのは、プロダクトが事業そのものになってからだ。計画がはっきりしていてもいなくても、コストは毎月かかり続ける。

フラクショナル CTO とは、週に1日か2日といった形で、パートタイムであなたのために働く経験豊富なエンジニアリングのリーダーである。要件書を書き、候補者と面談し、仕事をレビューし、何かがうまくいっていないときは早めに知らせる。コードを書くのは、あなたが雇ったチームだ。あなたが技術者でないなら、どのチームを選ぶにしてもフラクショナル CTO を一人組み合わせる。そして最初に、推薦する会社から手数料を受け取っていないかを尋ねること。

自分のスタートアップに合うのは、どの種類のチームか

プロダクトのどれだけが難しいエンジニアリングに依存しているか。1分間、遅くなったり間違ったりしたら何が起きるかを問うてみる。ユーザーが待たされて文句を言うだけなら、エンジニアリングは普通のもので、優れたジェネラリストのチームが作れる。その1分が、間違った価格での約定や、取りこぼした広告オークションという形で損失になるなら、その種のシステムを作ったことのある人が必要だ。

いまどの段階にいて、手元の資金はすでにいくらあるのか。ラウンドで資金を調達していれば、月額で払うチームを抱える約束ができる。資金調達の前は、人々がそのプロダクトを欲しがっていることの証明にお金を使い、エンジニアリングは小さく保つ。

• まだ資金を調達しておらず、プロダクトも普通のものなら、クリックできるプロトタイプを作るか、フリーランスを一人雇い、自分の時間は顧客と過ごすことに使う。
• ラウンドで資金を調達し、普通のプロダクトの最初のバージョンが必要なら、プロダクトスタジオかシニアのフリーランス二人に頼み、フラクショナル CTO に仕事を確認してもらう。
• ラウンドで資金を調達し、プロダクトの中核が難しいエンジニアリングなら、専門特化したエンジニアリング企業に頼み、自分の側には技術リードを置く。社員として雇っても、フラクショナルで入ってもらってもよい。
• 最初のバージョンが稼働していて、ユーザーがお金を払っているなら、自社のエンジニアを雇い始める。最初はリードからだ。自社の人員が外部チームなしでプロダクトを運営できるようになるまで、外部チームは残しておく。
• エンジニアリングそのものが売り物なら、最初のバージョンを外部の会社が作るとしても、はじめから自社のチームを計画に入れておく。

プロダクトの難しい部分がトレーディングプラットフォームや AI システムなら、次の記事がさらに踏み込んでいる:

自分のスタートアップには、どこがおすすめか

この問いに一社の名前で答えれば、それは当て推量になる。本稿は会社のランキングもしない。本稿が勧められるのは、前の節で見たチームの種類と、その種類を、自分で確かめた三つの名前に変える方法である。

連絡する価値のある候補は、いくつかの場所から見つかる:

• 自分のものに似たプロダクトをすでに稼働させている創業者を探す。誰が作ったのか、そして同じ人たちにまた頼むかどうかを尋ねる。
• 投資家に、ほかの投資先がどのチームを使い、どうだったかを尋ねる。
• 自分で確かめられる仕事を探す:開いて使えるプロダクト、そしてチームのエンジニアの名前が入ったコードや記事。
• レビューサイトを読むなら、書き手の名前と案件名が書かれたレビューだけを見る。そうすれば書き手に連絡できる。

次に1ページを書く:プロダクトが何を、誰のためにするのか、初日に必ず動かなければならない一つのこと、すでにあるもの、期限、そしてあなたの側で誰が決めるのか。同じ1ページを三つの候補に送る。候補からの質問は、提案と同じくらい多くを教えてくれる:似たものを作ったことのあるチームは、技術の話をする前に、あなたのユーザーとリスクについて尋ねる。

自分は技術者ではない。開発チームをどう見極めればよいか

2006年、Y Combinator の創業者の一人である Paul Graham は、1990年代の EC スタートアップの大半を潰したのは質の低いプログラマーだったと書いた。彼の説明では、そうしたスタートアップの創業者たちは、良いプログラマーと悪いプログラマーを見分けられなかった。自分がプログラマーでない場合に良いプログラマーをどう選ぶかについて、彼はこう書いている:「答えはないと思う。」

とはいえ、チームを見極めるのにコードを読める必要はない。まずは動くソフトウェアから始める。これは目に見える。2001年のアジャイル宣言の背後にある原則の一つには、こうある:「動くソフトウェアこそが進捗の最も重要な尺度である。」アジャイルに仕事をしていると言う会社なら、その一文どおりにやらせ、毎週クリックできるものを求める。

自分では見えないものについては、見える人にお金を払う。あなたが報酬を払い、その会社とつながりのないフラクショナル CTO か独立したエンジニアなら、月に一度コードを読み、気がかりな点を平易な言葉で伝えてくれる。

契約の前に、開発チームをどう確かめるか

技術の知識がなくてもできる確認が四つある。

まずは顧客から。プロダクトがすでに稼働していて、この2年以内にその会社と仕事をした顧客を二社紹介してもらい、自分で電話をかける。尋ねるのは次のことだ:

• その会社の誰が、そちらのプロダクトを担当したか。その人たちはいまも在籍しているか
• プロジェクトの途中で何がうまくいかず、会社はそれにどう対処したか
• 動くソフトウェアをどれくらいの頻度で見られたか
• 次のバージョンも同じチームに頼むか

次に、誰があなたのプロダクトを作るのかを確かめる。一人ひとりの名前と役割、そして週のうちどれだけをあなたの案件に割くのかを尋ねる。営業の打ち合わせに出てきた人の中に、コードを書く人がいるのかも尋ねる。契約の前にリードエンジニアに会い、名前は提案書だけでなく契約書に書き込む。

有償のトライアルを頼む。二つの候補に、同じ小さな実際の仕事を、通常の単価で支払って任せる。受け入れ基準は着手前に書面で合意しておく。期間は1〜2週間で足りる。どちらのチームを選んでも成果物はあなたのものになり、何か月もの仕事を約束する前に、それぞれがどう質問し、どう問題を報告するのかが見える。

契約の前に、毎週のデモを取り決める。2週目からは、自分で開けるリンクで、毎週動くソフトウェアを見られるべきだ。スライドや、パーセントで示す進捗報告は数に入らない。クリックできるものが何もないまま1か月が過ぎたら、次の請求書を支払う前に手を止め、理由を尋ねる。

スタートアップが初日から所有しておくべきものは何か

プロダクトの土台になるものはすべて自社の名義で登録し、外部のチームには自社の人員よりも狭いアクセス権を与える。

• コードは自社のアカウント、たとえば自分で作った GitHub の Organization に置く。GitHub のドキュメントによれば、Organization のオーナーは「あなたの Organization に対する完全な管理アクセス権を持つ」。そして、このロールは限定すべきだが、「2人を下回ってはならない」とされている。このロールは自社の二人に与える。
• クラウドのアカウントは、会社のメールアドレスで開設する。Amazon Web Services では、アカウントの作成に使ったメールアドレスとパスワードで、「アカウント内のすべての AWS サービスとリソースへの完全なアクセス権」を持つアイデンティティにサインインする。そのアドレスは自社のものであるべきだ。
• iPhone アプリがあるなら、Apple のデベロッパプログラムには会社として登録する。登録した人がアカウント保有者（Account Holder）になる。Apple の言葉では、「あなたの組織を代表して法的な契約に同意する」ことと、「アカウントの銀行情報の変更を承認する」ことが必要な人物である。
• ドメイン名、会社のメール、アナリティクスと決済事業者のアカウントも、同じルールに従う。

契約では、コードとプロダクトを書面で自社に譲渡させる。会社が自前の再利用可能なコンポーネントの権利を手元に残すなら、その一覧を名前まで求め、関係を解消したあとも使い続けられるライセンスを求める。契約の詳細は、上でリンクした専任チームについての記事が扱っている。

開発チームに頼むときの危険信号は何か

• 後回しにできるものは何かを誰も尋ねないうちに、一度の通話だけでプロダクト全体の固定価格が出てくる。
• 会社が、コードやあなたのアカウントのどれかを自社の名義で持とうとする。
• 電話できる顧客が一人もおらず、あるのはスクリーンショットとロゴだけ。
• 有償のトライアルは断るのに、何かが動くのを見る前から多額の前払い金を求める。
• クリックできるものが何もないまま1か月が過ぎ、進捗はパーセントで届く。
• どの機能もどの期限も、何が最も大事かという質問が一つもないまま受け入れられる。
• プロダクトはライセンスのもとでその会社独自のプラットフォーム上で動く形になっているのに、離れたら何が起きるのかを誰も説明しない。

amBrain はどこに位置づけられるか

上で挙げた六つの種類のチームのうち、amBrain は専門特化したエンジニアリング企業にあたる。トレーディング、FinTech、AdTech のリアルタイムシステムを構築し、立て直す。AI プロジェクトは業種を問わず引き受ける。AI 以外では、これらの分野の外の仕事は引き受けない。あなたのスタートアップが、AI を中核に持たない普通のウェブやモバイルのプロダクトなら、プロダクトスタジオかシニアのフリーランスのほうが合っている。

amBrain は2019年からソフトウェアを作っている。働き方は一文に収まる:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権の条件も一文だ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」どの会社に対してもそうするように、署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。

あなたのスタートアップがこれらの分野のどれかにあるなら、amBrain は、あなたの1ページの要件書を受け取る三つの候補の一つになれる。

よくある質問

• 開発チームではなく、技術系の共同創業者が必要か。それは投資家次第であり、何を売るか次第だ。Y Combinator の FAQ は、技術者でない創業者にこう答えている:「創業チームが、プロダクトを誰かに外注するのではなく、自分たちで作るスキルを持っていることが重要だ。ほとんどの事業では、それはたいてい、技術系の共同創業者が必要だということを意味する。」そう考える投資家から資金を調達するつもりなら、たとえ最初のバージョンを外部のチームが作るとしても、いまからその人物を探し始める。
• 固定価格で払うべきか、月額で払うべきか。固定価格が合うのは、紙の上で完全に記述できる小さな最初のバージョンだ。ユーザーから学ぶにつれて計画が変わっていくなら、毎週デモのある月額のチームのほうが、手綱を握りやすい。どちらの場合も、作業を始める前に、それぞれの部分について「完了」とは何を意味するのかを書き出しておく。
• あとからチームを替えられるか。替えられる。ただし、コードとアカウントがすでに自社のもので、書面の手順からプロダクトをビルドできる場合だ。必要になる前に試しておく:チームの外のエンジニアに頼み、ドキュメントだけを使って、まっさらなマシンにプロダクトをセットアップしてもらう。