GitHub のプロジェクトなどから学ぶ、サイドプロジェクト成功のパターン

ビジネス上のプロジェクトの成功法則やマネジメント方法は様々な形で語られています。一方で、主に余暇の時間で行われる技術的なサイドプロジェクト（ソフトウェア、ハードウェア含む）に成功パターンはあるのでしょうか。 最近では定量的なプロジェクトの分析を行うために GitHub のプロジェクトのデータを使おうとしている動きがあります。もちろん GitHub を使った研究はあくまでソーシャルコーディングのプロジェクトをスコープとするものですし、一部は因果関係というよりも相関関係でしかありませんが、知見として活用できる部分もあると思うので、GitHub の研究や私個人の経験を通して見てきたサイドプロジェクトの成功パターンをまとめてみたいと思います。 以下では大きく 3 つに分けて解説します。 チームアイデアとテーマプロセス 1. チーム最初に残念なお知らせです。どうやらプロジェクト内部の仕事の多くは少人

[kent-where-the-light-is]

“なので個人的にはエンジニアがトップに立つことを推奨しています。逆にエンジニアリングに興味のないアイデアマンがエンジニアを集めてチームを率いた場合、そういうチームは大抵喧嘩別れしているように思います。

[YassLab]

“長期に渡りそうなプロジェクトの場合、途中でも良いので公開してしまって、ユーザーの反応を見てみるというのもありかもしれません。とにかく継続的に社会にデプロイしてみてください。”

[ryuzee]

“なお議論や論争が発生した際に仲裁を行う優しい終身の独裁者（大抵はプロジェクト創設者）がいる場合も多いです。”

[paradisemaker]

素晴らしい論考

[efcl]

"成功しているプロジェクトには、他のプロジェクトのコアメンバーがこちらのプロジェクトのメンバーとして入っている傾向にある" 視点を逆転させると、そのプロジェクト(ライブラリやツール)を利用する際にチェックす

[minamishinji]

サイドプロジェクトに限らず重要な気がするなー。いい文章。

[yutaka_kinjyo]

“チームメンバーがチーム外部とのやり取り (exploration) の多いチームは優れている”