私はオープンソースに関しては比較的初心者です。2016年初頭に、Go用の汎用オブジェクトプールであるgo-commons-poolというオープンソースプロジェクトをリリースしました。現在、このプロジェクトには200近くのスターが付けられています。起業に関しても、まだ初心者です。2015年初頭には、技術パートナーとしてスタートアップを立ち上げ、チームコミュニケーションとコラボレーションツールを開発しました。その1年間は、開発業務に加え、製品開発や運用業務も担当していました。起業とオープンソースには多くの共通点があると感じているので、いくつか知見を共有したいと思います。これまでの講演者の方々は主に実用的な情報を共有してくださっていましたが、私のプロジェクトは技術的には比較的シンプルなので、Timのアドバイスに従い、モチベーションを高める要素も加えていこうと思います！ :)

ビジネスを始めるにしても、オープンソースに取り組むにしても、最初に直面する疑問は「何をすべきか？」です。そして、そのアイデアはどこから得られるのでしょうか？ 基本的には2つのアプローチがあります。

1. 観察

周りの人々、自分の生活や仕事、そして皆の習慣を観察し、改善の余地や問題点を見つけましょう。例えば、私のプールのアイデアは、グループチャットで誰かが尋ねたことから生まれました。調べてみたところ、Go言語には汎用的で使いやすいオブジェクトプールがないことがわかりました。別の例としては、タクシーを拾うのが難しく、路上で何時間も待っても見つからない人が、Uberを使うようになったという話があります。複数のデバイス間でファイルを同期したいと思った人が、Dropboxを使うようになったという話もあります。仕事で同じ作業を何度も繰り返している人が、様々なフレームワークを使うようになったという話もあります。

2. 学ぶ

他の先進地域や分野を調査し、そこから学ぶべき教訓があるか、そして先進地域や分野の成果を後進地域や新しい分野に移植できるかどうかを検討すべきです。よく知られている「Copy To China」スタートアップモデルは、このアプローチの好例であり、先進地域の発展の軌跡を用いて後進地域の将来の動向を予測するものです。先日、高可用性グループでIndigoが行った、日本の経済社会の発展を用いて中国の動向を予測するプレゼンテーションも、同様の考え方に基づいています。私がこのプールを作成したのも、Javaコミュニティの分析に基づいています。Go言語は将来のサーバーサイド開発において重要な役割を果たすと考えており、コネクションプーリングなどの用途には堅牢なオブジェクトプールが不可欠になるでしょう。

何をするかを決めたら、次はそれをどのように実行するかです。このステップは起業とオープンソースでは大きく異なるように思えますが、共通点もあります。重要なのは、「プロジェクト」に必要なリソースを評価し、割り当てることです。リソースには、資金と時間が含まれます。最初のアイデアがあまりにも野心的で、実際のリソースと合致しない場合、スタートアップは失敗に終わるか、オープンソースプロジェクトはREADMEファイルだけのリポジトリになってしまう可能性があります。これは、プロジェクトの複雑さを評価し、リソースを効果的に管理する能力が試されることになります。

プロジェクトが完了したら、次のステップはユーザーベースにプロジェクトを周知することです。これは一般的に「推奨」と呼ばれています。PingCAPのHuang Dongxu氏が先ほどマーケティング手法とチャネルについて説明しました。このステップの核心は、ユーザーベースの関心が一般的にどこに集中しているかを理解し、最小限のコストでどのようにリーチするかを理解することです。オープンソースプロジェクトへのリーチは、様々なオープンソースコミュニティや技術コミュニティ、独自のソーシャルネットワーク、技術カンファレンスなど、様々な手段を通じて行われる可能性があります。

初期のユーザーアウトリーチは完了しました。ユーザーはプロジェクトの存在を認識し、中にはスターを付けた人もいるかもしれません。彼らは潜在的なユーザーです。また、サイトをフォークしたユーザーもおり、おそらくサイトを利用したり、二次開発を行うつもりでしょう。次のステップは、既存ユーザーを維持し、より多くのユーザーを獲得することです。これはこの段階で検討すべき事項であり、以下のような点が含まれますが、これらに限定されません。

1. ユーザーに使い方をわかりやすく説明するために、ドキュメントを改善しましょう。ユーザーの「***」に腹を立てないでください。

2. ユーザーからのフィードバックに応え、問題に対処する。スタートアップ製品の場合、カスタマーサービスシステムは不可欠です。

ユーザーベースが拡大するにつれて、コミュニティが形成され、ブランドが誕生します。これは私のような小規模なツールでは達成できないステップですが、PingCAPのTiDBや謝孟君のBeegoのようなフレームワークは、既に独自のコミュニティとブランドを確立しています。

このプロセスの要点をまとめると次のようになります。

1. アイデアがうまく抽象化されていませんでした。実際、あらゆるツールや製品は抽象化、つまりユーザーニーズの抽象化が重要です。例えば、典型的な例を挙げましょう。ユーザーに何が必要か尋ねると、彼らは間違いなく車ではなく、より速い馬と答えるでしょう。車はユーザーの移動手段に対するニーズを抽象化したものです。しかし、このような抽象化をどのように実現するのでしょうか？私はそれを3つのレベルにまとめました。

(1) DRY原則（Don't repeat yourself：同じことを繰り返さない）は、コードスタイルガイドラインで最もよく用いられ、コピー＆ペーストを避け、作業を抽象化することを示唆しています。しかし実際には、オブジェクト指向プログラミング、モジュール化、コード生成ツール、様々なフレームワークなど、言語の高度な機能はすべて、この問題に対処するように設計されています。言い換えれば、繰り返し作業が多いと感じたら、それを抽象化できるツールが存在するということです。

（2）車輪の再発明をしない。この原則は議論の余地があるように思えますが、議論の原因は「発明」と「創造」の違いを理解していないことにあると思います。車輪の再発明はしてはいけませんが、新しい車輪を作ったり、既存の車輪を改良したりすることはできます。この原則は、他人が既に行ったことを繰り返すのではなく、車輪だけを単独で再発明するのではなく、先人の仕事に基づいて改良を加えることを意味します。私は常に、車輪を発明した人は偉大であり、非常に困難な偉業だったと感じています。その歴史的意義は、火の発明に匹敵します。車輪が発明されて以来、人間が使用する道具と動物が使用する道具は根本的に異なるものになりました。

(3) 私たちは既に、自分自身の作業と他者の作業を繰り返さないという目標を実現しました。3つ目のレベルは「他者に自分の作業を繰り返させない」ことです。ツール、フレームワーク、抽象化をオープンソース製品やSaaSサービスとして共有することで、他者が既に行った作業を繰り返さなくて済むようになります。

2. 開発速度が遅い、競合他社が出現する、または機能が競合他社よりも弱い。

3. プロモーションがうまく行われないと、人々に知られず、結果的に新参者に追い抜かれてしまいます。

4. 結果として得られる製品は実用性に欠けています。例えば、Go言語でプールをシミュレートするのはチャネルを使えば十分であり、複雑なプールは必要ないと考える人もいます。同様に、中国にコピーされた多くのプロジェクトは、中国の環境に適していないことが判明しています。

5. オープンソース化後、メンテナンスを怠ると、熱意が失われ、ユーザーからのフィードバックに応えられなくなり、最終的にはユーザーを失うことになります。多くのゾンビオープンソースプロジェクトがこの罠に陥っています。

そのため、起業を目指すエンジニアは、オープンソースを起業のリハーサルとして捉え、まずはオープンソースから始めるのが良いと思います。構想から開発、そしてプロモーションまで、一連のプロセスを経験することで、起業プロセスの重要な側面を体感し、自身の強みと弱みを見極めることができます。彼らはエンジニアですから、開発期間をコントロールでき、ターゲットユーザーもエンジニアであり、解決すべき課題も馴染みのある分野、そしてリーチすべきコミュニティも馴染みのあるものです。こうした好条件にもかかわらず、それでも困難に直面するのであれば、未知の分野、未知のユーザー、未知のコミュニティに転向したら、どれほど困難になるか想像してみてください。

テクノロジー分野のプロフェッショナルにおける起業家精神について、もう一つ指摘しておきたいことがあります。王安石の詩の一節、「春の川の暖かさを真っ先に知るのは鴨だ」は素晴らしいと思います。私たち最前線でコードを書くエンジニアは、水の中の鴨のように、川の流れの変化を真っ先に感じ取ることができます。これは大きな強みです。昇進してコーディングをやめ、陸に上がってしまったら、川の変化を感じられなくなってしまうかもしれません。