大坪と申します。先日10/26に行われました楽天テクノロジーカンファレンスに参加しました。主たる目的はライトニングトークでiPadアプリ「へやくる！」について話すことだったのですが、いろいろ興味深い発表をいくつも聞くことができました。
本日はその中からまつもとひろゆき氏の講演について概要を紹介をしたいと思います。ちなみに本来基調講演は楽天の三木谷会長が行う予定だったのですが、「急遽」まつもと氏が講演することになったとのこと。そんな事情を話し、笑いをとるところから講演が始まりました。（個人的にはこの「急遽登板」は歓迎するところでしたが）
--------------
1990年に学校を卒業し働き始めた。そのころはエンタープライズソフトの開発をしていた。一つのシステムを３年かけ、ウォーターフォールで開発する時代だった。その時から「この開発方法は何かが間違っている」と思ったが何が間違っているかを説明できなかった。
その頃のソフトウェア開発は間違った前提に基づいていた。
・私たちは何を作ろうとしているかわかっている
・私たちは何が欲しいかわかっている
・状況は変化しない
しかしこれらの前提は馬鹿げている。実際台風がくるとか地震がくるとか誰が予測できるというのか。（注：このカンファレンス自体、台風が接近した場合には中止になりかねませんでした）
このように前提が間違っていたが、当時の企業はどういう戦略を選べたか？
一番目の方法はダチョウのように、頭を穴に突っ込み状況が好転するのを待つこと。
二番目の方法は保守的戦略。「過去から学ぶ」ことである。たとえば人間性は聖書の時代から変わっていないから多くの分野では過去から学ぶことができる。しかしIT業界ではそうはいかない。不思議の国のアリスで赤の女王が言った「同じ場所にいるためには、必死に走らなくちゃ」というのがIT業界にも当てはまる。
３番目の方法は「おとぎの世界に住む」こと。「間違った前提に基づいて進む」ことだが、これは「穴に頭を突っ込んだダチョウ」より悪い戦略だ。
２０年前、日本の会社はどのような戦略をとったか？多くの会社は３番目を選んだがこれは間違いだった。
今から考えて、唯一とるべき方法はTry and Error。この戦略を機能させる為には何度も挑戦できなくてはならない。
２０年前ソフトウェア開発にはものすごいコストがかかった。それ故Try and Errorは選択しにくかった。最優先は「失敗しないこと」であり、その戦略にプロセスが最適化した。その結果ユーザ満足度は犠牲にされた。
時代は変わり、ソフトウェア開発のコストは劇的に下がった。Network,ツール,プログラミング言語全てがよくなった。今はSocial Codingが可能。
２０年前は、とにかくソフトウェアを作る事がゴールだった。すごい金をかけてシステム構築すれば、それだけで差別化できた。しかし今のゴールは「すごいソフトウェア」を作る事。ただソフトウェアを持っているだけでは差別化できない。
ではどうやって「すごいソフトウェア」をつくれるか？
その方法はもちろんわからない。しかしまず無知を自覚する必要がある。ここで機能する唯一の戦略はTry and Errorだ。そして失敗したときのコストを最小化する必要がある。そのためにはOpen source Softwareを使うべきだ。巨人の肩にのって開発をすることで、コストを下げることができる。
コアコンピタンス以外のすべてをOpen Sourceにするべきだ。そしてオープンな開発コミュニティを作り、プロジェクトを最小化する。それによりプロジェクト「組織」を解体し、ソフトウェアが万人にとって開かれるようにすべきだ。
Rubyは元々個人的な興味から作り出した（ペットプロジェクトと言っていました）が、今や世界中で多くの人が使っている。このように将来を見通すことはできない。
唯一の方法は進み続けること。サメのように進み続けなければ死ぬ。Open source projectで偉大なソフトウェアを作るためには開発コミュニティが多くの人を引きつけなくてはならない。そしてできるだけ早く走り、何度も試し、失敗したら早めに撤退すること。
ソフトウェア開発に関する大きな図式を変換する必要がある。「失敗したら終わり」から"失敗もOK"にすべきだ。（もちろん大失敗をしないという条件下でだが）
--------
以上が講演内容。その後何件かQ&Aがありました。私が特に興味深いと思ったのは以下のやりとり
Q:"失敗もOK"という風に会社のカルチャーをかえられるか？多くの会社ではなかなかそうはいかないが。
A:基本的にはそんな会社は辞めるべきだと思う。多くの大きな日本のIT企業は歯車を求めている。従業員に敬意を払っていない。エンジニアの動機の一つは自由度があることであり、自由を得るためにはリーダーになる必要がある。だから歯車を求めているような会社は辞めるべきだ。
-------
特に最後の言葉は、「そういわれても..」とも思う反面、多くのエンジニアの心に響いたのではないでしょうか。
基本設計-詳細設計-コーディング-試験という整然としたウォーターフロープロセスの間に多くの書類が作られ、レビューが行われ,,という開発に携わった人は多いと思いますし、「何かが間違っている」と感じた人も多いと思います。その「何か」についてまつもと氏の意見を聞けたことは貴重な体験でした。
ちなみに昨年のテクノロジーカンファレンスでは、Design Thinkingというセッションでウォーターフォール型開発についてこんな話がありました。
ノードストロームではウォーターフォール式に開発段階でのチェックを厳格に行った。その結果、全てのinnovationが消えてしまった。ウォーターフォール式の開発がうまくいかない、ということは誰もが知っている。しかしいつまでもそれがなくならないことについて考える必要がある。つまりメリットがあるわけだ。ウォーターフローの利点は、個人にとって「安全」であること。うまく行かなかった時に、「自分じゃない誰か」を非難できる。ソフトウェアの開発が遅れたのは、仕様が出るのが遅れたからだ、とか、無茶苦茶な仕様がでてきたからだ、と非難できる。しかし製品を作るのには向いていない。
来年のテクノロジーカンファレンスではどんな話が聞けるか今から楽しみです。
