こんにちは、2015年新卒エンジニアのnewuniverseことチュウです！現在はレシピ動画を見ながら料理を学べる料理サプリのサーバーサイドを担当しています。入社前にはエンジニア向けメディアPostdの運営をしていました。

今回は初出張ということで、2015年11月10日・11日に開催されたRubyWorld Conference 2015 に参加してきました。そのご報告を兼ねて、Rubyを触り始めて5ヶ月目の者として感想を書いていきます。

初出張

RubyWorld Conferenceとは？

『RubyWorld Conference』はRubyの利用事例や技術動向や開発者教育の情報を発信する場として、今年で7回目になる大会です。開催後に気づいたのですが、名称が『Ruby World』ではなく『RubyWorld』となっており、国際会議という意味合いよりもRubyの世界、つまりRubyのエコシステムにフォーカスした会議と言えます。

しかも今回は協賛企業にカンファレンス初の海外企業(現地法人除く)も加わっており、国際化も進んでいるようです。今回弊社リクルートマーケティングパートナーズも協賛しております！

スケジュール概要は以下で、Matz氏の基調講演について紹介していきます。

• 1日目: Matz氏によるKeynote speech + mruby関連 + 小規模企業におけるRubyの利用事例など
• 2日目: Linda氏によるKeynote speech + 「Ruby Prize 2015」表彰式 + 教育・経営・翻訳システムの事例など

Second System Syndorome

Matz氏による1日目のKeynoteスピーチです。タイトルのセカンド・システム・シンドローム(以下SSS)とは、1975年に刊行されたソフトウェア工学の古典「人月の神話」で提唱された現象です。

セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。

Matz氏は「Design is blueprint」つまりシステムを作るということは設計していることに他ならないと主張していました。

最初に作るシステムというのは、自分の能力を把握しきれていないので、慎重に作られます。

二度目に作られるシステムは一度目で叶えられなかった機能などを加えようと、詰め込みがちになり、結局失敗作が生まれやすくなります。

セカンドシステムを作ろうとするアーキテクトやエンジニアには

• 最初のシステムが汚いから、作り直したいという欲望
• 設計し直すことでもっとパフォーマンスが良くなるだろうという妄想
• 上記の欲望・妄想による作り直しに対する正当化

のような共通の心理が働いて、自制が効きにくくなります。

皆さんも一度作ったクソよろしくないコードやシステムをリファクタリングや再設計した挙句、既存のシステムで動かなくなった経験はあるかと思います。

一般的なソフトウェアと比較してこのような傾向は、プログラミング言語開発で更に顕著に現れます。

Matz氏は実際にSSSに直面したプログラミング言語たちを引き合いに、今後Rubyのアップデートに向けてSSSが発生しないよう努めることを断言していました。

Case1: Perl 5 vs Perl 6

Perl 6のリリースには15年以上を費やしたそうです。調べてみるとforの書き方からHashなど基礎的な部分からして色々変化があるようです。Perl 5と6はもはや違う系統の言語で、Perl 5系の次のバージョンアップをPerl 7としようと揶揄する人もいるようです。

Case2: Python2 vs Python 3

それからPython 3は2009年にリリースされていますが、2014年の統計では、Python 3のWeb採用率はPyhton 2.x系に比べると微々たるものです。
Python 3では良くないとされる古い関数の削除、互換性のない変更を許容したりして、Python 3は失敗作と感じている人もいるようです。

Case3: Ruby 1.8 vs 1.9

互換性の問題について実はRubyも例外ではありません。Ruby 1.8から1.9のアップデートにより多言語化（M17N）対応され、マルチバイト文字列の扱いに互換性がなくなりました。その結果、両バージョンのサポートをするにはプロダクトの方で対応することが必須でした。ただしRubyについては、1.8から1.9へのアップデートするメリットを明確に提示しました。

では、どうSSSを克服するか？

いくつかのプログラミング言語の例を見ていると、セカンドシステムは作ったが利用者が移行してくれないという問題が発生しているようです。

互換性に大きな原因があるようです。互換性について対処するデメリットと移行して新たな機能を使えるメリットの両天秤で、メリット＞デメリットでなければ利用者は移行しようとは思わないでしょう。

設計図をリニューアルする場合、自分の幻想を押し付けるよりも、どんな実質的な利益をユーザーに与えられるかという観点から進めていくのがベターだと感じました。

Matz氏からの提言をまとめると以下のようになります。

• 全部捨てることはやめる
• 劇的変化は認めない
• 一つずつ改善
• 互換性を維持

当たり前に聞こえるかもしれませんが、だからこそ逆に日頃それほど注意していないのかもしれないですね。

料理サプリにおける実践

料理サプリのサーバーサイドはRuby on Railsで作られています。歴史的経緯もありRailにちゃんと乗っていない箇所が多々あります。

ただ大規模にリファクタリングする機会もありません。

ここではリファクタリングもセカンドシステムを作る沿線上のものと考えると、SSSに陥らないように料理サプリのエンハンス開発で実践していることをリストアップしていきます。

• 既存のテストコードは極力触れず、新しいテストは既存テストから極力切り離して書く
• rubocop導入によるコーディング規約強制遵守
• ダメな既存コードを再利用しなくていい場合、極力再利用しない

すごくシンプルで自明かもしれませんが、Matz氏のアドバイスには沿っている気がします。

Ruby 3.0に向けて

今大会で一番の興奮したのはMatz氏によるRuby 3.0に関する言及ではないでしょうか！

Matz氏はRubyはOSSなのでアップデートに関するリリース時期などは確約はしないとは言いましたが、気になるメジャー機能をまとめると以下になります。

• マルチコア対応でConcurrencyを実現（現在Actorモデル含め３つのモデルを比較検証中）
• データスケーラビリティ
• コードスケーラビリティ(型推論)

Concurrencyについては関数型言語でかつ並行処理を扱えるErlangがHotですが、書き方がRuby風のElixirもじわじわ来ているようです。並行処理を扱えるRubyはどういったものになるか気になります。

Swiftなど今やモダン言語では標準装備となっている型推論が導入されれば、より安定したプログラムが書けそうです。

Web以外の領域へ

Matz氏は今後Rubyのテーマとして人と機械の協働を挙げています。どういった協働かは詳細はありませんでしたが、今大会では組み込み系mrubyの講演が多数あったり、Ruby Prize 2015がデータ可視化ライブラリとフレームワーク開発により科学技術計算分野に貢献した西田さんに表彰されたりと、これらが『人と機械の協働』を指しているようです。

今後Rubyの活用がWeb以外の多くの領域へ広まることを目指していることは疑いようもありません。

Ruby 3.0を気長に待つか、Elixirを始めてみるか悩みます。