RubyWorld Conference2013まつもとゆきひろさん基調講演メモ

2013/11/21

初めて参加しているRubyWorld Conference 2013での、Ruby創始者Matzことまつもとゆきひろ氏の基調講演『Aiming the Moving Target』が技術者にとどまらずいろんなひとに聞いてもらいたいような内容だったのでメモを放流。
体裁はあとで整え…るかもしれないし整えないかもしれない。

以下、聞きかじりメモ。

大学卒業後、2000人規模の大手システム会社に就職、エンタープライズ向けの大規模開発を手がける。
ウォーターフォール型の開発で初めから終わりまで3年くらいかかっていた。
→ここに疑問を抱く「なにか間違っている気がするが、なにが間違っているのか説明できない」

0.1 なにが間違っていたのか？
0.2 ここに対する対処法としてどのようなものがあるか？
0.3 わたしたちができることは
0.4 最も重要なのは「前に進み続けること」

1 今日からできること：「失敗」を「ナイストライ」と言い換えること。

なにが間違っていたのか？

なにを作っているか把握していると思っていた

実際にはソフトウェアが一体なんなのかを十分に理解していない
物理的法則に制限されないのでどんどん複雑な構造になっていくのでドキュメントでは十分に説明しきれなくなっている
Software is not soft

なにを作りたいか把握していると思っていた

作ったソフトウェアを上司に見せると「なんかイメージと違う」と言われる
上司・顧客はバカなの？
想像力には限界がある
自分の作ったソフトウェアがビジネスを成功に導く確証はない
なにを作るべきかわからない
結局自分もバカなんじゃないの？

状況は変化しないと思っていた

変化は速いし未来はわからないし、予測はだいたい外れる
「自分がなにも知らないこと」を認めるべきだったのに、プロの技術者として知ったかぶりをした

ここに対する対処法としてどのようなものがあるか？

保守的戦略
- 過去から学ぶ
- 良い戦略だが状況が変化しないことが前提
- IT業界では成立しない
- 「あなたがもし同じ所にとどまりたかったら全力で走らないといけない、進みたかったらもっと速く走らないといけない」（不思議の国のアリス・赤の女王の言葉）
ダチョウアルゴリズム
- 悪い状況から抜け出すためにただひたすら待ってやり過ごすということ
- 変化した状況が変わらなかったらその状況の中で進み続けるしかない、最悪のパターン

20年前、ウォーターフォール型開発では絶対に失敗ができない「満足度はさておき、とにかくなにか作りましょう」というのが唯一の方法だと思いたかった。
しかしこの方法では現在ではもう差別化できない。
とはいえ、現在でも「すごいソフトウェアの開発方法はわからない」。
予測は外れるし、無知の知は認めるべき。

昔に比べてソフトウェア開発コストは低くなっている。
インターネットを通じたコラボレーションが実現している。（エコシステムの実現、ソーシャルコーディング）
→「巨人の肩の上に乗る」ことで自分の実力以上の成果を達成できる

新しい対処法の提案

試行錯誤をする
- ローコストであれば速く開発し、何度も挑戦することができる→これがソフトウェア開発の成功の秘訣
- ソフトウェア開発のコストを最小化する（ここでRuby）
- 動く標的（＝「作るべき」「すごい」ソフトウェア）を狙うことができるようになった
- 個人が世界を変えることができる世の中になった

果たしてこれで成功するのか？そんなのはわからない。
でも少なくとも、成功確率を上げることはできる。

わたしたちができることは

熱心にコードを書かない、コードを書かないために熱心に働く
- 書けば書くほどソフトウェアは複雑化するし、失敗したときのダメージが大きい
- 巨人の肩の上に乗る（できる人の力を借りる）
競争力維持に必要な物以外すべてをOSSにする。
- 相互作用で提供者側も利用者側もハッピーになる
オープンコミュニティをつくる
- 成功したオープンソース・ソフトウェアにはかならずよいコミュニティがある
- OSSであってもなくてもコミュニティはよい効果を与えるのでは
プロジェクトを最小化し、「組織」を解体すること
- 「人員予算管理とかどうするの？」という声が聞かれるかもしれないが、この変化によってソフトウェア開発がうまくいくかもしれないし、うまくいくよう挑戦できる環境になるかもしれない
- 「変えること」を恐れない