ユーザーに「何が欲しいの？」と聞くのは“リーダーの怠慢”　プロダクトづくりを成功に導く、真のリーダーのあるべき態度

「慈悲深き独裁者」でいることで得られたメリット

まつもとゆきひろ氏：一方で、プロダクトオーナーとしてよかったこともあって、私自身はRubyというプロダクトを作る組織、コミュニティの中で、絶対的な立ち位置があるわけです。「私が始めました」という感じなので（笑）。そうすると、私自身はBDFLなんですね。BDFLは、Benevolent Dictator For Lifeという言葉の略です。

これはPythonコミュニティから来た言葉なんですが、「慈悲深き終身の独裁者」という意味だそうです。私自身がRubyを始めた人なので、Rubyがこうなった、デザインそのものは良いも悪いも私に責任があるわけです。そうすると、Rubyというプロジェクトについて私がなにか決定をした時に、その権威に対してコミュニティの中に疑念がないんですね。

本当はあるんだけど（笑）、建て前上は「まつもとが決めたからね」と言うことができるんです。ソフトウェアプロダクトのプロダクトマネジメントって集団管理体制みたいになりやすいんです。実際に他のプログラミング言語（のコミュニティ）では、ある機能を入れるか入れないかについて委員会で投票によって決めるところもあるんですが、そういう場合、あまりうまくいかないことが多いんですよね。

「絶対にうまくいかない」とまでは言わないんですが、「船頭多くして船山に上る」ということわざがあります。やはりいろいろな人が集まって、いろいろな意見があった時に、投票などで中庸を選ぶと、凡庸になったり一貫性に欠けたりするんですね。独裁者は、少数、おそらくは1人の意思決定者によってプロダクトがリードされていることを意味すると思うんですね。

しかし、「慈悲深き独裁者」は、強権的ではありません。つまり人の話を聞かないで突っ走るのではなく、人の話を十分に聞いた上で合理的に判断する独裁者であるということです。オープンソースソフトウェアの場合、ソースコードも含めて全部公開されているので、あまり強権的な態度を取っていると「お前のやることが気に入らない」と言ってプロジェクトがフォーク、つまり分離しちゃうことがあるんですね。

同じプロジェクトが2つ、3つできることがあり得るんですよね。そうすると、ただでさえ少ないリソースが分散されてしまって、チームが崩壊する可能性があるわけです。そういうことを避けるためにも、少数の決定者によって一貫的な判断をするだけではなくて、人の話も聞いてコミュニティの分裂や崩壊が起きないようにする必要があるんですね。

リーダーやオーナーの重要な責務は「よい」を定義すること

「ベクトルを揃える」という言い方を私はよくするんですけども。その開発コミュニティに参加している全員が同じゴールに向かって進んでいる時にプロジェクトはうまくいく。

逆に、綱引きのように反対方向に引っ張り合ったりしているとどうなるか。綱引きって、結局ものすごく力をかけているわりには、力を打ち消しあってしまってほとんど動かないので、それと同じように対立によってみんなの持っているエネルギーが無駄に消費されるということが起きるんじゃないかなと思います。

プロダクトの創始者あるいはプロダクトの責任者ですね。代替わりすることもあり得るので、そういう人たちがリーダーシップを取って、意識の統一を徹底することが必要ではないかなと思います。もしみなさんが、ソフトウェア開発に携わったことがあるのであれば、ほとんどの開発メンバーは良いものを作りたい、良いソフトウェアを作りたい、良いプロダクトを作りたいと思っているんですね。

漫画の悪役みたいに、「俺はこのプロダクトを破滅させてやる」とか「妨害してやる」みたいなことを言う人はほとんどいないんですよ。もしかしたらいるかもしれないけど（笑）、ほとんどいないんですよね。ただ、問題なのは「よい」という言葉がものすごく曖昧なこと。「よい」は未定義なんですよね。そうすると、どういう性質を持ったプロダクトが良いプロダクトなのか、ということを明確にしていかないといけない。つまり、「よい」を定義することが必要で、それこそがリーダーなりオーナーなりの重要な責務であると思うんですね。

その重要な責務を果たす時に、非常に重要なツールがビジョンであると思います。ビジョンというのは、そのプロダクトのあるべき姿、あるいはそのプロダクトの成功した未来を予見するもの。

あるいは、こういう未来が来るためには、こういう「よい」を実現しないといけないという、メンバーを説得しないといけない説得力の根源なんですよね。そういうものを持っていると、そのプロダクトを作り上げることに成功すると言えるんじゃないかなと思います。

Rubyのビジョンは「PROGRAMMER'S BEST FRIEND」

Rubyのビジョンは何かというと、Rubyのホームページを見るとこういうことが書いてあるんですね。「PROGRAMMER'S BEST FRIEND」と書いてあるんですけども、これが、まずみなさんにご紹介したい、Rubyの場合のビジョンです。

Rubyを作り始めた1993年当時、プログラミング言語というのは、マシンパワーを最大限に使うことが望ましいと言われていたんですね。それこそがプログラミング言語の目的であると言われていました。

なぜならば、当時のコンピューターはだいぶ非力だったので、無駄に使っているとダメなんですね。マシンパワーを最大限に活用できる言語が非常にもてはやされた。だからプリミティブになりがちなんですよね。今でも使われているCとか、C++とか、そのあたりの流儀ですよね。

一方で、「もう1つのキャンプとして手軽に小規模な開発を行うんだったら、パフォーマンスはあまり関係ないよね」という人たちもいて、こういうのはスクリプト言語と言われていたんですね。

私はもともとプログラミング言語を作りたいと思っていたんですが、なにか特定の目的を解決するためにプログラミング言語を作りたいというよりも、プログラミング言語ならなんでもいいから作りたいと、とにかく思っていたんです。ただ、その時に、スクリプト言語の可能性に注目して、じゃあ自分が作るんだったらスクリプト言語を作ろうと思ったんですよ。

当時から、Awkとか、Perlとか、Pythonとか、そういうプログラミング言語はすでにあったので、後発で真っ向勝負をしてもなかなか勝ち目が薄いんですよね。最初はだいたい1人で作っているし。特に、プログラミング言語の性能とか、機能とか、そういうもので競争すると、だいたい勝てないんですよね。

開発リソースでも勝てていないし、こちとら、特定の目的を解決したいんじゃなくて、私が楽しかったから。「言語を作りたいから作りました」みたいな感じなので（笑）。そうすると、「いや、お前が好きな言語を作っても……。まぁ、勝手にやれば？」という感じで、他の人に自分の作った言語を使ってもらうとか、ファンになってもらうとか、そういうことに対する説得力がゼロなんですね。

どうせ作るなら良い言語を作りたい。どうせ作るならいろいろな人に使ってもらえるような言語を作りたいと思って、手軽な開発の部分にフォーカスしようと思ったんですね。それまであまり言語化されずにいたものを言語化したんです。

当時は、「手軽な開発にはスクリプト言語」という感じで言われていたのですが、これを「人間にフォーカスします」「使いやすさに集中します」「問題をわかりやすく再構築するためにオブジェクト指向プログラミングを導入します」「プログラミングそのものをプログラムできるメタプログラミング機能を充実させて、そのソフトウェアの記述力を上げます」「クラスライブラリを充実させて、他のツールと組み合わせなくても自分だけでいろいろ処理ができるようになります」「生産性と楽しさにフォーカスします」と言語化していくことによって、「スクリプト言語は、もともと人間のための言語である」という性質を言語化したんです。

その中で、楽しいプログラミングとか、PROGRAMMER'S BEST FRIENDとか、そういう言葉が生まれてきました。

これというのは、人間のためのプログラミング言語というビジョンを提示したということだと思うんですけども。これがある種の説得力を持っていたので、開発に楽しさを求めるコミュニティが生まれたんですね。

当時も、「仕事というのは楽しいもんじゃないんだ」みたいなことをよく言われていたんですけど（笑）。「いいじゃん、楽しくても」という感じではあったので、「仕事は楽しくてもいいんだ」「プログラミングの楽しい部分にフォーカスするんだ」ということに共感してくださった方がそれなりにいて、それがコミュニティの成長につながって、開発の増加につながって、そういう人たちが自分たちのためにRubyの機能を拡張したり、ライブラリを作ったり、ジェムとかを作ってくれることで機能が増加する。

あるいは性能が向上することによってRubyの実用性がますます向上して、ライブラリが増える、フレームワークが登場する、エンタープライズでも利用されるということが起きました。これによって「人間指向言語」、Human Oriented Programming Languageというビジョンが、「多少はうまくいった」と言ってもいいんじゃないかなと思います。

これが日本だけではなくて、海外でも共感を受けて広まったのが、Rubyが最初の成功を収めたきっかけになっていると思います。

「驚き最小の原則」をスローガンにしたらうまくいかなかった

私が提示したビジョンがいつもうまくいったわけではないんですね。うまくいかなかった例もあります。例えば、「驚き最小の原則」というものをRubyの開発当時は掲げていたんです。

これは「Principle of Least Astonishment」、POLAという略称なんですけれども。人間指向で人間が生産性を高めるためには、使っていてビックリすることがないほうがいいと考えたんですね。

人間の自然な期待に応える言語設計にする、あるいは新しい機能を付ける時に、「人間の驚きがより少ないようにデザインしましょう」というスローガンを掲げることによって、うまくいくんじゃないかと思ったんです。最初はそれでよかったんですが、長期的には、この「驚き最小の原則」はあまりうまくいかなかったんです。

なぜかというと、「驚き最小の原則」と言った時に、「誰にとっての驚きなのか」が未定義だったんですね。そうすると、人間の感性はだいたい共通していて……人間と言うとちょっと主語が大きいですが、Rubyが好きで、Rubyを気に入ってコミュニティに入ってきた人たちは似たような感性を持っているからこそRubyが好きになる。

なので、そういう人たちが驚かないデザインにすればいいやと個人的には思っていたんですが、そうしたら、Rubyに新しい機能を提案する人、あるいはRubyの機能を「こういうふうに直したほうがいい」と提案してくる人たちの中で、「自分がビックリしたから」と言うようになったんですね。

つまり、「驚き最小の原則」をスローガンとして掲げているので、「私が驚いたから」というのが理由になるわけです。ただ人間というのは、自分のバックグラウンド、例えばRubyを使う前に使っていたプログラミング言語に固執しがちなんですね。例えばRubyの前にJavaを使ってきた人は、「Javaでできるあの機能がなんでRubyにないんだ」と思うわけです。

あるいはRubyの前にPythonを使っていた人、Perlを使っていた人たちは「自分たちの今まで使っていた言語にある機能がなんで（Rubyには）ないんだ」みたいなことを言うんですね。もちろん理由があって、（機能が）ないことが多いので、こちらが「こういう理由でそのアイデアは採用できません」と言っても、「いや、でも俺も驚いたんだから」と言って、議論が堂々巡りになってしまうことが多くなったんです。議論の妨げになる傾向にあったんですね。

それで「Principle of Least Astonishment」というスローガンはちょっと看板を下ろして、十分な情報を集めてトレードオフを考慮して、できるだけ説明可能な判断を責任者が行うようにしようと決めました。

「本当の問題は何か？」　ファクトを問うことでソリューションが生まれる

例えば私はRubyを作りましたが、Rubyを構成しているありとあらゆるジャンルの専門家ではあり得ないわけです。例えば、Rubyの中にはネットワークライブラリがあるわけですが、私はネットワークの専門家ではないです。あるいはRubyには、OSのシステムコールを呼び出す機能もたくさんありますが、私自身はOSの専門家というわけでもないんですよね。

どちらかというと言語の専門家、それも言語仕様の専門家だと思うので、判断する前に例えばOSの専門家、コミュニティの中にいるOSについて詳しい人、あるいはネットワークについて詳しい人に事前に「こういうふうなことを言っている人がいるんだけど、これってどう思う？」みたいに聞いて、情報を十分に集めるんですね。

その時のその人の感想、「びっくり！　自分が今まで使ったものと違う」とか、「僕はこれが好きだった」「嫌い」とか、そういうのではなくて、ファクトを集める必要があるんです。

ヘンリー・フォードが昔、言いました。「ユーザーに何が欲しいかを聞いたら『速い馬をくれ』と言う」と。つまり、ユーザーは自分が必要としているものを知らないんですよね。

なのでユーザーに「あなたは何が欲しいの？」とか「どんなソリューションが必要なの？」とは聞いてはいけないんですよね。それはリーダーの怠慢で、解決すべき問題は何かを聞かないといけないんです。

例えばヘンリー・フォードさんの場合、「あなたは何が欲しいの？」と聞いたら（ユーザーは）「速い馬」と答えるんだけど、「問題は何か」と言ったら「移動に時間がかかること」と答えられるんですね。

「馬よりも自動車のほうが本当は適したソリューションなんじゃないの？」とフォードさんも考えて、その真の問題を解決するために、大量生産によって比較的値段の安い車を大衆に対して提供するというソリューションを出したわけです。

つまり、ファクトを問う。本当の問題は何か？　ということを問うんですね。かつ、トレードオフがあるわけです。トレードオフが存在することは認めた上で、Aを選ぶかBを選ぶか。どちらを選ぶかを決めないといけないんですが、そうすると、こっちのメリットのほうが大きいからこっちを選ぼうとか、こっちのデメリットのほうが大きいからこっちは止めておこう、みたいなことが起きるわけです。

その優先順位は、リーダーが決めるべきことです。トレードオフに対して判断をする。あるいは優先順位を決定する。最終的にはその優先順位を決定することが良いプロダクトを作るということにつながるんだと思います。

真のリーダーのあるべき態度は、判断や優先順位を他の人任せにしないこと

あとは、できるだけ説明可能な判断をする。これは何かというと、機嫌や思いつきによって行動するリーダーにはメンバーはついて行きたくないんですよね。「今ちょっと機嫌が悪いから話しかけないようにしよう」みたいなリーダーは良くないですよね。

そうじゃなくてロジックによって「これこれこういう理由だから良い」あるいは「これこれこういう理由だからダメ」ということをタイミングや機嫌に左右されず言ってくれるのが理想です。そういうことを目指すべきだと思うんですね。

そうでないと、特にそのコミュニティの場合は分裂を招いてしまう。なので、そういう決定事項、優先順位の決定は責任者が行います。これは結果的に、集団管理体制というのは難しいよということを意味するんだと思うんですね。

判断がブレたり、一貫性が欠けたり、あるいは投票をする時に、投票をする人が自分の興味のあることであれば一生懸命考えて投票するんですが、自分が興味のない分野だと「どちらでもいいや」と言って安易な判断をしてしまいがちです。「自分には関係ないから」と思いながら投票しちゃうみたいなことが起きがちなんですよね。

そういうこともあるので、リーダーシップを考えると、「驚き最小の原則」みたいなビジョンはよくなかった。真のリーダーのあるべき態度というのは、その判断や優先順位を他の人任せにしないで自分でやらなくちゃいけないということを学びました。

（次回につづく）