こんにちは！Crowd Agentのエンジニアが先週行われたRuby World Conference 2017に参加してきました。非常に魅力的なイベントだったので、トークの中から印象に残ったものをピックアップしてご紹介します。
1日目
エンジニアのbary822です。groovesには最近加入して、大阪からフルリモートで働いています。
今回はRWCの1日目で行われたトークの中から、私の印象に残った2つをピックアップしてご紹介します。
Keynote by Matz
Rubyユーザー数推移
Rubyをつくってから、ユーザー数がどのように推移していったのか。というお話でした。
1人(Matz本人)だけから、メーリングリストを公開すると、2,3週間で200人になったそうです。当時は新しいプログラミング言語にユーザーが定着しづらい状況だったらしいので、それを考えるとこの伸び率はMatzの予想を遥かに超えていたそうです。それだけRubyの魅力に気づいた人が当時から多かったことがわかりますね。
また、ML経由で開発に参加する人も徐々に増えてきたそうです。当時はオープンソースという概念も一般的ではなく、顔も知らない人が自分のプロダクトの開発に参加してくれるなど予想外の出来事だったとおっしゃっていました。
Ruby初の英語で書かれた本、Programming Ruby: A Pragmatic Programmer's Guideが発売されると、ユーザー数は10,000人規模まで急速に伸び始めたそう。Dave Thomasが共同執筆者であることから彼とRubyとのつながりはここから始まったのが推測できますね。Rubyは後のRailsの発明のおかげもあり、そこからさらに加速し、現在では全世界で1,000,000人以上のユーザーを持つプログラミング言語へと成長した、というのがRubyのユーザー数の推移を基にした歴史の話でした。
(OSS)コミュニティについて
コミュニティが生き残るには、変化が大きすぎても小さすぎてもダメだというお話です。
例えばソフトウェアで言えば、互換性を保ちつつも新しい機能やパフォーマンスの改善をし続けていく必要がありますよね。
これは個人的な意見なのですが、Rubyコミュニティはこの「互換性」というのものを単なるプログラムの互換性以上のものと捉えていると考えています。それはプログラマの互換性です。Rubyプログラマに「なぜRubyなのか」という質問をした時に必ずと言っていいほど返ってくるのは、「書いていて心地いいから」ということなんですよね。この心地よさこそがRubyの最大の特徴でもあることから、RubyプログラマがRubyらしくプログラムをかけることはある種の「互換性」なんじゃないかなと思います。
Rubyによるたのしいユーザー基盤再構築 by 諸橋 恭介さん
楽しく開発し続けるには
諸橋さんは現在Cookpadでユーザー情報をコアプラットフォームとして提供するための開発プロジェクトに参加していて、彼のチームで「楽しい」開発を実現するために行ったことをお話してくださいました。
具体的には、楽しい開発を考えるための3つのステップとして、
- コーディングするのが楽しい
- チームで開発するのが楽しい
- チームとチーム外の人とサービスリリースするのが楽しい
ということを挙げておられました。
コーディングするのが楽しい
Rubyはそもそも楽しくコードがかけるようにデザインされているのですが、しかし、そんなRubyを持ってしても、アプリケーションのコードが複雑になるにつれ、コーディングをするのが楽しくなくなってしまう、ということはありますよね。
複雑すぎてメンテンナンスが困難となったアプリケーションのメタファーとしてレガシーコードということがよく挙げられますが、我々はこのレガシーコードがお金を生むからこそ楽しくコーディングができる環境があることを認識しなくてはならない。なので、レガシーコードに真摯に向き合い、メンテナンス性を高める努力をすることで、これをまた楽しくコーディングできるようにしようと提案していました。
チームで開発するのが楽しい
ほとんどの開発プロジェクトに置いてはチームで開発することが前提となりますよね。
自分の考える「楽しい」の定義が他のメンバーのそれとは異なるので、チーム単位での「どうすれば楽しいか」という共通認識を持つことが最初のステップだそうです。そこからは振り返り、見積もり、計画づくりを軸としたイテレーションを回していき、どうすればより楽しい開発ができるチームになれるかを追求していくというプロセスがいいのだそう。
また、見える化はチームとしての「楽しい」を追求していく施策の効果的な施策の1つだそう。具体的には、バーダウンチャートでプロジェクトの進捗を見える化することで、プロジェクト完了をゴールとして、いま自分たちがどのステージにいるのかを明確にすることができたそうです。また、イテレーションの振り返りの中でtryとして上がった項目をいつでも意識できる場所に配置することも効果的だったようです。
チーム以外の人とサービスリリースするのが楽しい
チームが変われば「楽しい」の定義が変わる。「楽しい」の定義が変わればそれを基に発展してきたチーム文化も変わる。
自チーム以外のバックグラウンドが異なる人達と一緒に価値を届けることができるというのはそれだけで楽しさが味わえる一方で、その文化の違いから来る困難も多いそうです。その中でも私が一番なるほどと思ったのは、同じものを同じ名前で呼ぶことの重要さでした。
ある概念が抽象化されたものであればあるほど、チーム間でその認識にズレが発生する可能性が高くなる。そのため、それが具体的にどういうものを意味していて、何という名前で呼ばれるかを明確にしておくことは重要だそうです。
新しいメンバーがチームに入った時
これはトークの後で個人的に質問したことです。
新しいメンバーがチームに入った時に、その人が考える「楽しい」とチームが考える「楽しい」にギャップがあった場合にどうすればよいか？という質問に対して、
その人が考える「楽しい」を加味した上で、チームの「楽しい」を再定義する必要がある。変化が起こることは受け入れる。ただし、「楽しい」の定義が全く違うベクトルの人はチームに入れないようにするというのも選択肢として考えてよい。
という回答を頂きました。
自分の中ではチームの「楽しい」の定義はそのチームの文化になるものであり、変化させるべきではない。という考えを持っていたので、それを再定義し続けていくという意見は新鮮に感じました。チームの規模が大きくなるにしたがって、多様な考えを持った人が入ってくるということを考えれば、その方が持続可能なチームの発展が望めるのかもしれないと思いました。
2日目
エンジニアの@talkto_meです。二日目を担当します。
Ruby Is Nice so We Are Nice by 角谷 信太郎さん
メディアとしてのRuby
Matzの最近のセッションで、"Matz is nice so we are nice" という表現が "Ruby is nice so we are nice" に変わったことをきっかけとして、Rubyのナイスさがどのように育まれてきたのかという話がありました。 Rubyist（Rubyに対して単なるお客さん以上の気持ちを持っている人）が持ち寄った"いい感じ"の成果が、Rubyのナイスさを育てていると受け止めており、"いい感じ"の一例としては、RubyKaigi 2017 のMatzの基調講演でのmoduleの使われ方の変遷に表れていると感じたとのことでした。
「Rubyをキメると気持ちいい！」というMatzの言葉がありますが、Rubyは書き手にプログラミングの楽しさを感じさせる言語としてデザインされています。書き手の想いや楽しいという気持ちをコードを介して読み手に感じさせることのできるRubyのメディアとしての側面についても言及していました。 最近、弊社では月に一度Railsのコードの歴史を辿っていく勉強会をしているのですが、初期のActiveRecordで登場したmethod missingの大胆なメソッドの呼び出しやhas_finderに始まったnamed scopeのシンプルさは、キメた時の気持ちよさを読み手が感じられる実装だと感じました。
ポエムとしての仕事
以前よりもビジネスとしてのRubyの利用は増えている一方で、仕事を通して"楽しさ"を共感できる職場はそれほど増えてはいないと感じているとのことでした。 ビジネスとしてのソフトウェア開発は、インターネットの成長とともに自然と発展した"野生のソフトウェア"であるRubyとは異なり、人工的な環境であるため"いい感じ"を再現させる必要があると考え、Rubyと同じメディアとしてアジャイル/リーンを通して、仕事の送り手の"楽しい"を受け手の心に再現できないかとおっしゃっていました。
QAで角谷さんがさりげなく発した「うまくいかなくてもいいです、また別のやり方探しましょう」という一言が、アジャイル/リーンをメディアとした"いい感じ"を再現するために必要な考えなのではないかと感じました。
Rubyプログラマが育つ仕組み−Rubyでの受託開発を10年回してみて by 大場寧子さん
有志による新入社員研修改善プロジェクト
実務でのOJTベースの研修は、新入社員と受け入れ側の両方で非効率と感じるシチュエーションが見受けられていました。 株式会社万葉ではホラクラシーな組織形態を採用しており、担当者が自律的に判断する環境を整えているそうです。現状の問題を解消するために有志による改善プロジェクトが発足したとのことでした。 新しい研修では、習得してほしいスキルをベースに24のステップになっている擬似プロジェクトを採用しており、要件をあえて緩くすることで、状況をより現実に近づけ、自分で仕様を検討して決める判断力やコミュニケーション能力を養うことができます設計になっているとのことです。
研修を軸に社員同士のコミュニケーションが活発になる
研修を画一化すると、メンター以外の社員も自然とレビューに参加する動きが見られるようになったそうです。変化するベストプラクティスやコーディングパターンの議論も活発になり新入社員以外でも知見を得られる良い機会になったとのことでした。
初めての人がチームに新メンバー入る時、スキルに応じた仕事の選択や文化的な擦り合わせには多少なりとも時間がかかります。開発をスピードアップさせるために必要なコストですが、一時的にチームに不安な状態が生まれるため、事前に解消・軽減することができる研修方法には魅力を感じました。研修を繰り返すことで、レビューする側の社員の負担も軽減されていき、チームを超えた横断的なコミュニケーションを生み出している点も複数チームの交流を考えている企業にはもってこいだと思います。
研修期間完了は人により異なり、その分のコストが発生する一方で、新入社員の得手不得手の共有、文化のすり合わせが行われ、実案件へアサイン後はスムーズに活躍できるようになったそうです。プロジェクトで育ったメンバーがメンターとなり研修内容が改善していく流れもエンジニアが会社を育てていく良い文だと感じました。
なお、 https://github.com/everyleaf/el-training に擬似プロジェクトの成果が公開されています。弊社でもエンジニアの教育の機会にはぜひ参考にしたいと思いました。
エンジニア募集
株式会社groovesでは、エンジニアを採用しています。 私たちと働くことに興味ある方、気軽にご連絡ください。
