Yehuda Katzという生き方とインディーWeb

https://frontsidethepodcast.simplecast.fm/16

1 comment | 1 point | by WazanovaNews 3年弱前 edited


Jshiike 3年弱前 edited | ▲upvoteする | link

昨日のエントリーでも名前のでてきたYehuda Katzですが、Rails / Ember.js / jQuery / W3C Technical Architecture Group (TAG) / TC39-ECMAScriptなどで活躍し、今回はRustのコアチームに参加することが発表されてます。Tom Dale曰く「インターネットの半分くらい書いてる感じだから。[1] 」という勢いがあります。Yehudaの仕事振りやプロジェクト運営における考えは、オープンソースという視点での発言ですが、企業におけるプロジェクトの進め方や今後の働き方のスタイルがどう変わるか、変わるべきかという観点からも、示唆に富むものだと思います。

まず。彼がメジャーなプロジェクトを渡り歩いてきた経緯について、

最初に掲げたコミットメントの成果をだし、舞台から時間をかけてゆっくりと引いていくスタイル。TAGには数年前に参加し、今年はやめておこうと決めたのは、TAGの構成とミッションを変革したいというオリジナルのゴールをほぼ達成したから。この後は他のメンバでトーチを運んでいける。Railsについても、すでに日々の意思決定からは長い間離れていたが、同じような理由で今年引退した。

このやり方をうまくいかせるための唯一の秘訣を挙げるとしたら、積極的に委譲すること。どういう意味かと言うと、「もう人に任せても大丈夫だな。」と思う前から委譲をはじめること。自分が達成したいことを全て成し遂げるための唯一の方法は、ビジョンを掲げて、最初の実装の作業をやり、ビジョンを共有でき助けてくれる人々をなるべく早く見つけること。これまでいくつかのプロジェクトを手がけることができた大きな理由は、物事というのは人が思ってるよりももっとつながっているから。Ember.jsのようなプロジェクトの全体像は、Ember.jsの開発の日々の作業と、関連するテクノロジー全体における啓蒙活動の両方が必要になってくる。

Rustに関わることになったのも、うちのサービスであるSkylightにとって、低いオーバーヘッドでクラッシュしないエージェントをつくるに最適なソリューションであったから。特定のテクノロジーにかなり初期から関わると、自分はかなり時間を投資して取り組むたちで、「自分なら埋めることができる。」という穴を探そうとするんだ。

これまでのプロジェクトは盛り上がってるから選んできたわけではない。TAGとTC39のケースは、盛り上がりに欠けた組織をミッションで活性化できるのではないかというチャンスを見つけたから。…ほとんどの時間をもっと効果的に多くの人が参加してくれるようにするためのビジョンづくりに費やした。...

Ember.jsとHandlebarsでは、エコシステムにおいて欠けているものに気付いたので自分のツールとして開発した。どちらも…未来のビジョンを共有できる仲間のリクルーティングに相当な時間をかけた。もし、次から次へと盛り上がっているプロジェクトに順に移っていくつもりだったら、MustacheとかAngularJSに参加してたと思う。

Webもしくは自分が関わっているプロダクトに関連する未来が良くなるようにという将来像を描こうとしているつもり。そして、自分のビジョンの一部を共有できている既存のプロジェクトか、もしくは新しいものをつくりあげるというアプローチ。たくさんの異なるプロジェクトに関わってきたのは、大きな絵を描くと色んなテクノロジーの改善につながるという事実があるからなんだ。[2]

次に彼が提唱するインディーWeb / インディーオープンソースソフトウェアという考え方について、

Railsで忙しい頃にDHHから「ところで今はどんなアプリつくってるの?」と聞かれて、「こんなにRailsで忙しいのだからそんな暇はないよ。何を言ってるんだ。」と、しばらく頭にきたけど、やがて彼が正しいことに気づいた。実際にアプリをつくったりメンテしてないと、痛みがどこにあるかという現場感覚が鈍るので、エンジニアとして自分がやってること(オープンソースでフレームワークの開発)がよくわからなくなるんだ。そこから、ビジョンを共有できる緩やかなつながりで、(現場感覚のある)多様なメンバが集まれば成功するプロジェクトができるという考えに至ったんだ。例えば、Ember.jsにしても、Grouponに勤務するメンバは、社内の他のプロジェクトと比較してEmberに何が欠けているのか教えてくれるし、モバイルの開発をしているメンバからは、モバイル視点でEmberに対するフィードバックをもらえる。[3]

コアチームを分散化すること。考えられる限りの役割全てを分散化すること。ドキュメントを担当する人、イベントを担当する人、エバンジェリストの役割をする人、ユーザコミュニティのサポートをする人などは、その分野でトップのスキルのあるメンバをチームの中からアサインし、権限をもって仕事してもらうこと。他のオープンソースのプロジェクトでよく見るのは、イベントの担当者はコアチームを上長としてレポートするかたちになっているスタイル。その担当者はイベントの専門家であるのに自分で最終決定できずに、コアチームがyes / no を決めている。コアチームにイベント運営のスキルはないのに。そこでイベントの担当はコアチームに対して説明するのに疲れてストレスが溜まる。

自ら意思決定できる立場の人たちを分散化すること。これが、企業が運営する(そして過度の干渉だと物議をかもすことが起きうる)オープンソースのプロジェクトの話に関連するのだが。ちなみに、企業がオープンソースのプロジェクトを運営することはできるが、Rustの事例のように、最初はMozillaで始まったプロジェクトだが、それから彼らは社外に主要メンバを広げるために相当な努力をしてきた。

分散化してきた多様なメンバがいると、多様な考えを持つようになるので、「一気に全部書き直す」ということは難しくなる。やり直しを大喜びする人たちがいる一方で、「俺たちのアプリがどうなってしまうんだ。」と反対する人たちもでてくる。ドキュメント担当は「全部マニュアル一式揃えなおすの?」と文句を言い、エバンジェリストの人は「ユーザコミュニティが反対して大騒ぎになってる。」とくる。となると、分散化するプロジェクトにしっくりくるのは、短いサイクルでリリースを繰り返し、段階的に開発する手法となる。ユーザにとっても、6週間ごとのリリースサイクルだと、都度それほど大きな変更をしなくて済む。段階的にやると聞くとあまり大きな開発ができないように思う人もいるようだが、人間の細胞が毎日少しづつ入れ替わって、全身が一定期間に新しく生まれ変わっていることと同じ(で、大きな目標も達成できる。)。それで開発コミュニティ全体をうまくスムーズに動かすことができる。(併せてビジョンを示すことも大切。)

大きなプロジェクトを成功させるには、多くのメンバが同じような問題に出くわしているのなら、「皆で共感/共有できるソリューションはどのようなものか」と追い求めるのが本筋で、「別のフロアで働いている権威ある天才に何事もお伺いをたてなくてはいけない。」というのは間違ってると思う。[4]

[1] http://shoptalkshow.com/episodes/147-tom-dale/

[2] https://news.ycombinator.com/item?id=8742953

[3] https://www.youtube.com/watch?v=YqXU4o24Hkg

[4] https://frontsidethepodcast.simplecast.fm/16


2014 Topアクセスランキング


Back