※初日レポートはRubyWorld Conference2016 初日レポートをご参照下さい
morimorihogeです。
というわけで、二日目のレポートです。会場や雰囲気については初日レポートの方に記載してありますので、そちらをご参照下さい。
前回と同じく、発表のチョイスは僕の独断と偏見です。
Social Coding
基調講演として、GitHub.Inc から堀江さん（@dice）とEdward Thomsonさん。事例紹介として日本経済新聞社から梅崎さん（@bungoume）のお話でした。
特にEdwardさんの話が面白く、Microsoftにどのようにしてオープンソースな文化（社内でオープンソースにすることをInner Sourceと呼んでいました）が浸透していったかの話は興味深かったです。
この辺のまとめは既にid:soplanaさんがruby world conference 2016 2日目のSocial Codingに関する話のメモという記事でまとめてくれているので、そちらが詳しいです。
「最近のMSはきれいなジャイアンみたいだ」といった意見が一部であるとかないとかありますが、そうした舞台裏を垣間見られた発表でした。
梅崎さんの発表は日経新聞社で外注主体だった自社のメディアを内製していった＆している最中の話で、古くて大きな会社でも内製化できるんだぜ、といった話として良い事例だと思いました。
外注や外部開発部隊との協力開発でも、外部が開発したものを社員でレビューする流れで進め、いわゆるWork in Progressパターンにより開発を進められているとのことでした（参考: Work in ProgressパターンによるPull Requestを利用した開発フロー）。
僕はかれこれ10年以上Web関連の受託開発に携わっていますが、数年前にRailsに利用技術を切り替えてからは特に Railsは内製開発と最も相性が良い と思うようになって久しいです。
そのうち記事を書こうと思うのですが、開発速度が必要な部分は全外注でやってしまうとどうしても契約なり手続き上のコストがかかってしまい、思った速度が出ないのが良くある話として見受けられます。
顧客との直接の入り口周りやフレキシブルな方向転換が必要になるような事業では、自社でリスクを取って一部でも内製化する（または開発の舵取りを自社で持つ）ことが一つの成功要因になっているのではないでしょうか。
・・・と言ってしまうと僕らの様な受託開発屋の仕事が無くなるように思いますが、基幹系システムとのデータ連係や技術的に難しい所のある大量のデータ捌きなど、内製化よりはシステム開発経験豊富な外注先に任せた方がうまくいきそうな部分も引き続き残ると思います。早さよりも正確性や保守性が要求される分野はありますし。
以下、会場で頂いたoctocatのMonalisaちゃん（由来はこの辺からどうぞ： GitHubのキャラクターの足がタコなのは「サンゴ」を食べたからだった！ 正式名称は「Octocat」ではなく「Monalisa」）
Rubyによるアジャイルとデブオプスを実現するチームづくり——みんなのウェディングの経験から
高井さんによる、クックパッドからみんなのウェディングに出向して色々な開発環境にまつわるあれこれを開拓していったといった話でした。
みんなのウェディングの開発当初は2007年で、まだGitはあれどGithubはなかった時代です。そうした時代やDeNAからスピンアウトしたみんなのウェディングの背景諸々含めた選択肢としては、当時はMobaSifや実績のあったSubversionの利用など、それほど悪い選択肢ではなかったのだと思います（多分その頃はソシャゲ界隈がイケイケだったし、とにかく速度とチャレンジの数重視！みたいな風土もあったのでは）。
ただ、事業として成功してユーザが集まり、継続的改善を要求されるようになってくると「触るのが恐い」という状態が負の遺産となって足を引っ張ってくるというのは他の業界でもあるあるだと思います。
このあたりのスピード感と継続的改善のための足場固めのバランス感覚というのは難しい所で、最初からスーパーなエンジニアリングチームを揃えられるなら、最初から持続的改善を詰める仕組みや自動化を構築して進められるのですが、予算や人材諸々の都合でリソースは常に有限です。
足場固めや技術的負債の返済というのは大事ですが、足場を固めてるうちに乗っかっている事業ごと水没してしまっては元も子も無いので、事業のステージやリソース状況、チームの構成に応じてその時その時の最適解というのを見つけていかないといけないんじゃないかなあと思いました。
ゼロから稼げるエンジニアになる3つのステップ
株式会社Dive into Code代表の野呂さんによる発表でした。
今流行の社会人向けプログラミングスクールをやられていて、未経験者向けにきちんと構造を理解してもらう（腹落ちさせる）教え方に力を入れているのが特徴的で、良いなあと思わされました。
弊社でも新人向けを含めてWeb開発者向けの勉強会的な講座を実施しているのですが、この「腹落ちさせる」という言葉にはしっくりくるものがありました。
職業開発者をやっていると「AをするにはBをすれば良い」という辞書的な情報ってググれば見つかるし、その場の目的は達せられるのでついそのまま先に進んでしまいがちなのですが、これだと問題の数だけの辞書を用意するなり引く必要があって、かなり非効率的なんですよね。
「内部構造や設計がこうなっているからAをするにはBをすれば良い」まできっちり腹落ちした上で技術を使っていると、辞書的な問題解決だけでなく「BができるからCもできるはずだろう」といった新しい選択肢や解を思いつくことにも繋がるので、ぜひ新しくエンジニアを目指す方には全体の動きを腹落ちした上で技術を使う様にしてもらえるといいなあ、と思います。
ちなみに、Dive into CodeさんはRails開発の講座テキストをDIVERというサイトで公開されているので、学生や転職を検討していてRailsで本気でサービスを作ってみたい！という方は見てみると良いのではないかと思います。
以下、公式サイトから転載です。
Bring Ruby into Campus
最後の発表は台湾5xRubyの高見龍（@eddiekao）さんによる台湾の大学教育にRubyを普及させに行くという話でした。
台湾ではRubyの求人がとても少ないらしく（PHP/Javaの1/20くらい）、それもあってか学生の人気も低いという中で、台湾でのRubyイベントを主催したり大学での授業を実施したりと精力的な活動をされていました。
日本においてWeb開発の分野にRubyが素早く浸透していったのは、Railsが一部のアーリーアダプターにウケたことでRailsを使ったスタートアップが割合早い段階で出始めたことや、Ruby自体が日本で生まれたことから 日本語の正確な情報 が豊富であったこと、ちょうどRailsが成長しているタイミングでクックパッドの様な有名大規模Railsサービスが世の中に知られるようになったことなど色々な要因があると思います。
日本は今の所ある程度大きな市場規模があるため、国内の技術動向を見ていれば直近数年飯が食える程度には技術を選んでいけますが、市場規模が小さい国では自分で事業を興すのでもない限り、あまり好き勝手に技術を選ぶのはリスクになるところはありそうです（自分で事業を興すにしても、エンジニアの補充面でリスクを負う）。
このあたりは「顔を見て仕事をしたい」という人が多い日本ではむしろ日本人有利かな、と思いますが、世界的にはリモートワークな方向に向かっている風潮もあるので、日本人としてどこまで日本domesticな経済に身を委ねていて大丈夫なのかというのは気にしておく必要がありそうです。
Ruby Prize (一日目の発表)
初日のレポートで書きそびれてしまいましたが、今年のRuby Prizeは山口一生さん（@rhe__）でした。
ruby/opensslのGem化をはじめ、対応する人がいなかったRubyのOpenSSL対応周りの放置チケットのクローズや最新OpenSSLへの追随などを行われたとのことで、今日のRubistは足を向けて眠れない程にお世話になっているのではないでしょうか。
※約23,000行のレガシコードを整理したり、Heartbleed後にOpenSSLの30万/70万行のコードが更新されたことに対する対応など、さらっとお話されてましたが尋常じゃないと思いました（汗
こうした「誰もが動いて当たり前だと思って使っている」ライブラリに対する貢献というのはこういった機会がないと表に出てきづらいので、RubyPrizeというのはRubyコミュニティとして良い仕組みだなあと思いました。
まとめ
そんなわけで一通り記憶に残った発表レポートでした。
最終的な会議の入場者数は初日481人、二日目367人、述べ848人とのことです。毎年少しずつ人数は増えていますね。
技術情報だけ集めたいという人にはあまり向かないカンファレンスかもしれませんが、Rubyコミュニティの輪や前向きな流れに触れることができるので、来年も何かしら都合をつけて参加したいと思います。
毎年運営されている開催実行委員会、開催協力されている島根県・松江市の皆さまありがとうございました。また来年もよろしくお願いします :)