GitHub のプロジェクトなどから学ぶ、サイドプロジェクト成功のパターン
ビジネス上のプロジェクトの成功法則やマネジメント方法は様々な形で語られています。一方で、主に余暇の時間で行われる技術的なサイドプロジェクト（ソフトウェア、ハードウェア含む）に成功パターンはあるのでしょうか。
最近では定量的なプロジェクトの分析を行うために GitHub のプロジェクトのデータを使おうとしている動きがあります。もちろん GitHub を使った研究はあくまでソーシャルコーディングのプロジェクトをスコープとするものですし、一部は因果関係というよりも相関関係でしかありませんが、知見として活用できる部分もあると思うので、GitHub の研究や私個人の経験を通して見てきたサイドプロジェクトの成功パターンをまとめてみたいと思います。
以下では大きく 3 つに分けて解説します。
- チーム
- アイデアとテーマ
- プロセス
1. チーム
最初に残念なお知らせです。どうやらプロジェクト内部の仕事の多くは少人数で（場合によってはたった一人で）で行われているようです。その少人数の仕事は、ほかのコントリビュータ全員の仕事すべてを足し合わせた場合より多い傾向にあります。なので、チームをどう組もうとメンバーをどう増やそうと、きっと発案者となるコアメンバーたち自身が多くの仕事をしなければならないという前提でプロジェクトを始めるべきと言えそうです。
なので個人的にはエンジニアがトップに立つことを推奨しています。逆にエンジニアリングに興味のないアイデアマンがエンジニアを集めてチームを率いた場合、そういうチームは大抵喧嘩別れしているように思います。
一方、これは結果論かもしれませんが、プロジェクトに関わる人が多いチームほど成功しているそうです。ただし前述の仕事量の分布から推測するに、恐らく多くの参加者はあくまでサポート役として参加します。そしてサポート役としては多様な体験を持つ人が参加すると成功しやすいと言われているので、様々な人から支援をうまく得るのもプロジェクトの成功のためには重要と言えそうです。
成功しているプロジェクトは、そのチームサイズによって傾向が異なります。たとえばプロジェクトの参加人数が 10 人以下なら全員に仕事が分散しているときにプロジェクトは活発度が高く、30 人以上なら適度に分散しているときに活発度が高いようです。一方で 60 人を超えると個々人の活発度が下がるようなので注意して下さい。対策として、大きくなったときにはモジュール化して分担すると効果的のようです。
なお成功しているプロジェクトには、他のプロジェクトのコアメンバーがこちらのプロジェクトのメンバーとして入っている傾向にあるようなので、うまく他のプロジェクトのメンバーを巻き込んでみてください。あるいはこちらのコアメンバーに対して他のプロジェクトに積極的に関わることを推奨すると良いかもしれません。これは MIT の研究の、チームメンバーがチーム外部とのやり取り (exploration) の多いチームは優れている、という結果と相似なのかなと思います。
プロジェクトメンバーは音楽性の違いなどで増減することも多々あります。プロジェクトに 3 ヶ月以上残る貢献者は約半数であるものの、それ以降は 80% 程度の割合で残存することなどを鑑みると、プロジェクト参画の初期 3 ヶ月でどう深く関わってもらうかがポイントになりそうです。また減少するのは仕方がないので、メンバー数をある程度維持したければ常に新規貢献者を探す必要もあると思います。
なお私個人の経験則的には、熱意を持った人が少なくとも一人はいないと、サイドプロジェクトはほぼ確実に頓挫しているように見えます。個々人の熱意は時間の経過やライフステージの変化（卒業や結婚、出産等）などによって上下する傾向にあります。ただもし仮にリーダーは変わっても、その時に高い熱意を持つ人がいれば続いていくようです。なお議論や論争が発生した際に仲裁を行う優しい終身の独裁者（大抵はプロジェクト創設者）がいる場合も多いです。
最後に、技術的なコンピテンシーやパーソナリティよりも、意味があって役に立つチームメンバー間のつながりの強さが成功の鍵だと言われています。また基本的に知り合いとチームを組むほうが良いようで、既存の社会的なつながりがあるとプロジェクトの生産性が高いと言われています。初期にはそれほど生産性に大きな違いはないようですが、長期で見たときの生産性に既存の社会的つながりは有効とされています。
なので、やりたいことに対して技術的なスキルが十分ではなくても、仲の良い人たちと何かを始める、というのは理にかなっているのかもしれません。いずれにせよ、完璧なチームは存在しないので、技術やスキルはそのたびに勉強するか、周りの助けを乞えばいいのですから。
2. アイデアやテーマ
「困難な問題に取り組むほうが、スタートアップは簡単になる」と言われています。そうしたテーマを選んだほうが、会社の外の人からも多くの支援が得られるというのがその理由です。そして前述のとおり、支援はプロジェクトの成功に密接に関わっているようなので、困難な問題に取り組むべきというのはプロジェクトにも言えるのかもしれません。
実際に「技術的に面白い」「社会問題に取り組んでいる」など、周りの人が支援したくなるようなテーマやアイデアを選んでいるスタートアップは、他のスタートアップに比べると順調に進捗しているように見えます。そして外部からの支援を受ける能力は進捗を生む能力の良い指標だとも言われます。ぜひ周りを巻き込めるようなテーマを選んで下さい。
その一方で、初期は多くの人がそこそこ満足するよりも、少人数の人が愛してくれるようなものを作ったほうが良いという Y Combinaor の経験則があります。愛されているかどうかの一つのものさしは、口コミで自然に広まるかどうかです。人が欲しがるものを作る以前に大きく広げようとすると、サイドプロジェクトもスタートアップの死因の 70% を占めると言われる premature scaling と同様の事態に陥ります。気をつけて下さい。
注意して欲しいのは、多くの人がそこそこ満足するような人目を引くプロジェクトは成功しているようにも見える、という点です。たとえばそうしたプロジェクト（一部のメディアアートなど）は広告業界の人から声が掛かることも多々あり、一見ビジネスになるようにも見えます。
ただ広告商品は流行り廃りが激しいため長続きしない傾向にあります。むしろ目立つだけのプロジェクトは一年で旬が終わり、逆に注目された分引っ込みがつかなくなって…という悪循環があるのではないかとすら感じています。逆にきちんと落とし所を考えていたプロジェクトはうまく解散をしています。
ともかく、結局そのアイデアが成功するかどうかはタイミングが一番重要とも言われます。だから運良くタイミングよく始めるか、タイミングが来るまで粘り続けるかです。粘り強く続けられるだけの熱意を持てる、自分だけのテーマを見つけられるのが一番良いのではないでしょうか。
最初から特定の領域に情熱を持つのは珍しいことで、やり始めてから気づくことも多いという指摘もあります。そうした情熱を見つけるという文脈でも、イノベーションを起こすという文脈でも、ボラティリティに身を委ねていろいろティンカリングするしかないのかなと思います。
3. プロセス
プルリクエストへの対応の良いプロジェクトや、プロジェクト外部に開発のやり取りを可視化しているプロジェクトは人気度やソーシャル度が高くなるようです。ユーザーやコントリビュータときちんとコミュニケーションして、リクエストを受けることはプロジェクトの成功に役立つでしょう。
それだけではなく、プロセスやプロダクトのオープンさと参加者の満足度は正の相関があるようです。なので、「どういう貢献が今必要なのか」「どうやって貢献して欲しいのか」を明示的に書くことや、内部の意思決定プロセスやプロダクトの状況を透明化しておくことは、プロジェクトの内部的にも外部的にも重要なのではないかと思います。そのほか、外部の人がプロジェクト内部のメンバーにコミュニケーションするときのやり方をきちんと記述することなどが有効だと言われています。
また、内部の人たちにはきちんとフィードバックをするとモチベーションは高まります。プロジェクト参画初期はポジティブなフィードバック、最後のひと押しが必要なときは批判的なフィードバックがお勧めされています。
気をつけて欲しいのは 90% のプロジェクトはほんの僅かな期間の一時的なバーストだけでプロジェクトが終わっているところです。だから、思いついたら 2 週間程度で一気にやってしまうか、もしくは短期的なゴールとしてコンテストや展示会などに出る、などを短期の締め切りとして設定してしまうのが良いのではないでしょうか。実際、展示会の直前 1 ヶ月前から本腰を入れ始めて、でも手が動き始めるのは 2 週間前、というようなプロジェクトを多々みてきました。
逆にプロジェクトをしてきた人たちにインタビューをした結果、適切な目標や締め切りの設定が適宜できなかったプロジェクトは失敗する傾向にあるように感じています。長期に渡りそうなプロジェクトの場合、途中でも良いので公開してしまって、ユーザーの反応を見てみるというのもありかもしれません。とにかく継続的に社会にデプロイしてみてください。
なお、プロジェクトの初期にビジョンのコミュニケーションをしており、リーダーによって定められたゴールが明確なプロジェクトは成功する傾向にあるようです。実際、目標を SMART に設定したほうがモチベーションやパフォーマンスを維持できると言われています。そうした意味でも短期的なゴール設定をうまくしていくというのは意識したほうが良いかもしれません。
たとえば Face to Face のイベント (LeWeb) に参加した人たちの GitHub 上での交流が増すという結果もあります。イベントで発表する、なども一つの良い短期的なゴールとなるかもしれません。
その他の経験則も大事に
例えば古くは「伽藍とバザール」などでオープンソース開発の理論と実践や個人の体験からの法則が語られることがあり、こうした体験に基づく指針は参考になる成功パターンと言えそうです。以下に一部を抜粋します。
3. 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章）
7. はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
11. いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
12. 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
18. おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。（伽藍とバザール、山形浩生訳）
そのほか、たとえば最近では RethinkDB の共同創業者が OSS 開発で気をつけたこと（新しいコントリビュータ向けのガイドを書いたり、仕事を高く評価したり、アイデアを可視化するアートを使ったり、ドキュメントを整備したり）の記事が出ています。
もちろんこれらの他の OSS のプロジェクトでもこうした知見が溜まりつつあります。うまく先人の知恵を使って、是非サイドプロジェクトを成功させて下さい。
