パズル提供能力ドリブンな人材流動化
少し前にアップされた、itproの梅田ーまつもと対談の第二弾の中に、非常に印象に残るやりとりがありました。少し長くなりますが、引用します。
梅田 それをやってやろう，と思うときのモチベーションというのは何なんでしょう。そこに山があるから登るという感じ？
まつもと 新聞を開けたらそこにクロスワードパズルがあったというのと同じですね。
梅田 パズルなんだ！
まつもと 新聞に載ってるクロスワードパズルですから，やってもやらなくてもいいわけですよ。でもやれば，ある一定時間，知的な満足感が得られるわけじゃないですか。
それと同じことがオープンソース・プログラマにもあって，メーリングリストを読んでると問題が書いてあるわけですよね。で，「お，これ，きっと直せる」と思って，ソースコードを読んで10分か15分やってみると直せる。
梅田 そうすると使命感ではないわけですね。
まつもと 使命感ではないですね。楽しんでるんです。
梅田 そうなんだ。これをこのまま放置しているとユーザーが困る，というのではなくて。
まつもと そういう，大あわてで直さなくちゃいけない時もありますけど。
梅田 そういうときは使命感がある。
まつもと 僕は少なくともありますけど，僕のまわりの多くの人はあまりないんじゃないかな。
梅田 そこに面白い問題が，パズルがあるから。
まつもと オープンソース・コミュニティというのは世界中が結託して，自分のためにパズルの問題をどんどん考えてくれているという世界観があり得るわけですよ，オープンソース・プログラマにとっては。
枠組みから作るのはたいへんなんですけど，Rubyの場合はもう枠組みがあるから。Rubyコミュニティに参加しているひとたちにとっては，コミュニティというのは，ひとつの巨大なパズル製造機械であるわけです。
梅田 そうなんだ！
まつもと 簡単なものもあるし，難しいものもある。どんどん降ってくるわけです。それを，「これ，俺やれそう」って。先着一名しか解答できないというのはあるんですけど。
極端に言えば、オープンソース・プログラマは、「自分にとってちょうどいい難易度のパズルの問題を得る」という極めて利己的な動機で参加しているだけだという話。
プログラマがオープンソース・プロジェクトに参加する動機の利己的な部分を、これまで見た中で一番うまく説明しているものだと思いました。
まつもとさんは、この後で、こんな言い方もしています。
僕はたまにオープンソースはサメだ，みたいな話をするんです。マグロでもいいんですが，つまり泳ぎ続けてないと呼吸できずに死んでしまう。動かないと停滞しちゃうんですよ。変化がないと新しい問題が生まれないから。
tDiary開発者のただただしさんも、tDiaryプロジェクトのミッションは「プロジェクトを25年間存続させること」だとして、日々の開発のこんな悩みを書いています。
かといって、最小限の変更以外を凍結してしまうと、プロジェクトを維持するだけの開発者が確保できなくなってしまう。われわれ開発者は、変化がなくては生きていけない種族なのだ。プロジェクトを継続するためには、日々変化していかなくてはならない。(中略)ミッション遂行のためには、両者のバランスを取りながらおそるおそる進むしかないわけで、実際の開発よりもこっちの方がよっぽど難しいと感じている今日このごろ。
確かに成功したオープンソース・プロジェクトは、「変化のマネジメント」がうまく行っていたという気がします。
変化が急激過ぎると、発生する問題が大きくなり過ぎてそれに取り組む開発者がいなくなってしまうし、ゆるやか過ぎると、パズルとしてはつまらない問題ばかりになってしまい、やはり開発者は去ってしまいます。
開発者の能力や使える時間はバラついていますが、その正規分布のカーブに合わせてちょうどよく難し過ぎずやさし過ぎず大き過ぎず小さ過ぎない問題を、開発者の人数にちょうどいいくらいの数だけ、問題を作り続けなくてはいけない。
この難題をクリアしたプロジェクトが、成功したプロジェクトになるわけです。
というか、LinuxやApacheは、ソフトウエアの構造が「課題提供能力」を高める方向に最適化されていると言えるかもしれません。
このような「課題提供能力」は、オープンソース・プロジェクトに限定された話ではなく、プログラマが関わる全てのプロジェクトにおいて、実は最もクリティカルな問題かもしれないと思いました。
マイクロソフトのヤフー買収断念も、マイクロソフトの「課題提供能力」が欠落していたことが最も重要な要因だったという見方もできます。
ヤフーに在籍しているプログラマは、買収の前後で、ヤフーの「課題提供能力」がどう変化するかに注目しています。ペイが上がっても会社の「課題提供能力」が落ちるなら、つまり、仕事の中でのチャレンジがつまらないものになっていくなら、いてもしょうがないということ。
これはトップクラスの超優秀な人に適用されることではありません。プログラマのキャリアとは、過去に自分が取り組んできた課題の歴史です。だから、適切な難易度の課題に取り組めるかどうかは、ミドルクラスの普通のプログラマにとっても重要なことです。
「課題提供能力」は、会社のミッションそのものが魅力的であかどうかいう点と、それを個々の社員の為に適切なサイズにブレークダウンしていく組織全体の能力、それを回転させて継続していくマネジメントの力等に依存します。
この総合力として、グーグル ＞ ヤフー ＞ マイクロソフト と見るプログラマが多かったことが、買収劇の結末(株式の論理では強行できる所まではこぎつけたが、人材流出を懸念して断念)につながったのではないでしょうか。
こう考えると、たださんの悩みは、多くの企業経営の中にこれから表れてくる課題の先取りと言えるのではないかと思います。
つまり、現状のサービス内容に満足しているユーザを多く獲得している状態で、安定指向でそれを継続することで開発者が去るリスクと、チャレンジをして一時的にサービス低下をまねきユーザが去るリスク、その二つのリスクを両方見ながらバランスの良い決断をしなければならないということです。
