関西Ruby会議 08で出したプロポーザルがacceptされなかったので供養しておく

お焚き上げです。

Title

O(nm)畑でつかまえて ~Catcher in the Hell~

Abstract

日々のコーディングで、あなたは計算量を意識していますか？

多くの開発者は学校での学習や日々の業務で遭遇する課題を通して、その重要性を痛感した経験があるのではないでしょうか。

本発表では筆者が実際に遭遇した計算量が膨大になる可能性を秘めたファイルパース処理を題材に、いかにしてコードを改善し、効率的な処理を実現したかの実例を紹介します。

多重ループに陥りがちな処理を速度と可読性を両立させるための具体的なアプローチについて解説します。

また、複雑なパースと構造化処理を実装する上で開発のしやすさを向上させるためのテクニックもご紹介します。

より効率的でメンテナンスしやすいRubyコードを書くための一助となれば幸いです。

Details

本発表ではとあるアプリケーションで扱っていたファイル（具体的な形式は発表内で解説予定）のパース処理を題材に、計算量を意識することの重要性と具体的な改善方法を紹介します。

概要: 当初このファイルのパース処理は安易な実装を行うとネストが深く複雑なループ構造になり、O(nm)のような非常に大きな計算量を抱える可能性がありました。実際この実装ではファイルの複雑度が増すにつれて処理時間が著しく増大するという問題がありました。更にこの実装はとても複雑なループで構成されていて、メンテナンスに支障をきたしていました。

具体的な例: 発表内では多重ループによる非効率なパース処理のアンチパターンを具体的なコード例を交えて示します。これにより、計算量を意識しない実装がどのような問題を引き起こすかを明確に理解していただきます。

解決策と成果: この課題に対し筆者はアルゴリズムの見直しやデータ構造の工夫を行うことで、パース処理を相当なレベルで改善することができました。発表では採用した具体的な手法（例：適切なデータ構造の選択、ループの統合、 etc）とその効果を、実際のコードや簡単なベンチマーク結果を交えながら解説します。これにより具体的な改善イメージを持っていただけるでしょう。

開発のしやすさ: 効率的なパース処理の実装と並行してコードの可読性や保守性の維持も重要な課題でした。発表ではパース処理と構造化処理を分離するための設計原則や、開発のしやすさを向上させるための具体的なテクニック（例：オブジェクト指向設計、DSLの活用、etc）についても触れます。

対象者:

  • 計算量について普段意識していない方
  • 計算量を意識しているが、具体的な改善方法が分からず困っている方
  • 日常の業務で複雑なデータの処理やパースに携わっている開発者
  • コードのメンテナンス性向上に関心のあるエンジニア

Pitch

この「O(nm)畑でつかまえて ~Catcher in the Hell~」という発表は、関西Ruby会議08のテーマである「Rubyと作ろう」にまさに合致する内容だと思います。なぜなら、より効率的でメンテナンスしやすいRubyコードを書くにはRubyならではテクニックや背景が必要になるからです。特にテクニックの部分ではオブジェクト指向言語としてのメリットについて言及する予定です。

また現代のソフトウェア開発において、扱うデータ量は増大の一途を辿っており、計算量を意識したプログラミングは避けて通れません。しかし、その重要性は理解していても日々の業務の中で具体的な改善策を見出せずにいる開発者は少なくありません。本発表は、そうした課題に対し、実体験に基づいた具体的な改善事例を通して、効率的な処理がいかに問題を解決し、コードをより洗練されたものに変えるのかを示します。

特に、ファイルパース処理という多くの開発者が遭遇するであろう具体的なケースを取り上げることで、抽象的な計算量の議論に留まらず、明日からすぐに実践できる知識とテクニックを提供します。また、単に効率化するだけでなく、複雑になりがちなパース処理を開発しやすい構造にするための工夫も紹介することで、持続可能な開発の構築にも貢献します。

私自身、この発表で取り上げる課題に実際に直面し、試行錯誤の末に解決策を見出しました。その経験を通して得られた実践的な知見は、教科書的な知識だけでは得られない、血の通った学びを参加者に提供できると確信しています。また、計算量という一見難解なテーマを、具体的な事例で紐解くことで、より多くの参加者に興味を持ってもらい、活用して欲しいと思っています。

RubyKaigi 2025に参加しました

id:ryopeko (@ryopeko) です。

今回はRubyKaigi 2025の参加レポートです。

RubyKaigi 2025は4/15~4/18に愛媛県の松山で開催されました。

私は前日の4/15に現地入りしたため、4/15~4/18の間松山に滞在していました。

Day0 (4/15)

この日の午後は松山空港から北へ1時間ほど車で移動したところで、勤務先のタイミーで同じくRubyKaigiに参加するエンジニアとのオフサイトミーティングの予定でした。

ということで朝9時羽田発の飛行機に乗り現地へ向かうことになりました。

が、この日JRの朝の混雑が想定よりもひどく、羽田空港まで普段かかる時間の倍ほどかかるという事態になってしまいました。その結果保安検査終了時刻に間に合わず、搭乗予定の飛行機に乗れないという結果になりました...。

今まで夢の中で飛行機に乗り遅れるというのは何回かありましたが、ついに現実世界でもやらかしてしまいました...。

これが0回戦敗退...飛行機もまともに乗れないポンコツと化しました...。

しかしチェックインカウンターに乗り遅れた旨を伝えると、次の便に振り替えてもらえました。これがLCCだったら詰んでいたところでした。使っていて良かったFull service carrier...。

そしてなんとか松山空港に到着したわけですが、当然同僚たちはオフサイト会場に行ってしまっているわけで。

ここで幸運(?)にも同じく飛行機に乗り遅れていた同僚を捕まえて一緒にタクシーで現地に向かいました。

オフサイトではフルリモート環境で顔を合わせる機会が少ない同僚たちと様々なディスカッションや雑談をし、有意義な時間を過ごすことができました。

夕方からは隣接している海沿いでBBQをして会場であるブルワリーで作られたビールをたくさん摂取できてとても楽しかったです。

(海の様子と行列しいたけ)

Day1 (4/16)

RubyKaigi 2025本編の初日です。

この日は朝10時からKeynoteがありますが、受付などもあるため9時には宿泊先を出発、徒歩で向かいます。

30分ほどかかったかと思いますが、とても天気が良く、更に路面電車が走っている街並みがとても素敵であっという間に感じました。

(これは道中にあった建立されているIDE)

会場に到着後は受付を済ませ、名札を書いて、勤務先のタイミーブースでステッカーを受け取りました。

(会期中、かわいいを配るおじさんとして暗躍していました)

そうしている間にいよいよDay1 Keynoteの開始です。

ima1zumi「Ruby Taught Me About Encoding Under the Hood」

とてもわかりやすい説明とストーリーで思わず聞き入ってしまいました。

説明されていたものはどれもひとつひとつ、じっくりしっかり積み重ね理由を探って、問題点の本質を見極めていくことの大切さを語られていました。

普段からこのようにあろう、と心がけていてもなかなかできることではないものを、こんなにも積み上げてきたという事実がすごすぎるという感想でした。

それと途中で気がついたのですが、ima1zumiさんのトーク、フィラーがほとんど無くてスッと耳に入ってくる話術が素晴らしかったです。これはとても練習されたんだろうなあ。

内容には関係ないですがZWJ(Zero width joiner)というワードのカッコ良さ...。

ランチ

この日はスポンサーブースらへんで一緒に雑談していた chiastolite, repeatedly, makimoto と一緒に道後温泉方面へ早めのランチに出かけました。

宇和島鯛めし、美味しすぎてめちゃくちゃ満足度が高かった。

k0kubun「Deoptimization: How YJIT Speeds Up Ruby by Slowing Down」

めちゃくちゃエッジケースかと思うところでも問題を見つけて解決している様が異次元過ぎた... Shopify勢の発表はみんなそうだったのだが、ここ！という点について徹底的に掘り下げてベンチマークを取って改善の取り組みを行っていた。

(おまけ: 自分が書いたブログのスクショが出てきてびっくりした(YJIT関連は見られている))

spikeolaf「Ruby's Line Breaks」

文法とParserに関するセッション。

Parserに関しては昨今のブームとは裏腹にあまり手が伸びていなかったが(この思い込みは会期を通して覆されることになる(後述))、それとは別のところで印象が残ったセッション。

仮説、検証、考察のレベルが高すぎる。

spikeolafの思考プロセスを垣間見ることができて圧倒されてしまった。

tagomoris「State of Namespace」

Namespaceに関するセッション。個人的に今年の要注目セッション。

この1年で何度か進捗について話を聞く機会があったが、このBig featureに取り組み続けているの、偉業よな...。

最近一旦mergeされたようだが、rebaseしながら続けるのほんと地獄っぽそう...。 (この記事執筆時点でまだmergeされていないとのこと)

JITに関して詳しいことはわからないが、Namespaceが入ったあとのYJIT, ZJITの最適化はどうなっていくんだろう？こちらもまだまだ課題があるのかもしれないなと思いながら聞いていた。

 「TRICK 2025: Episode I」

もはやホラー。聞いてて背筋が凍るRubyコード...。

Official Party

松江城が見えるお堀の内側の公園でのパーティー。

特設会場でのパーティーで規模がすごかった。去年も屋外だったがこの人数が入る会場、もはや調達不能なのでは？

雨が降らなくてOrganizersの豪運を感じた。

この日はパーティーが終了したらすぐに帰路について早めに就寝。

集中してセッション聞いていたし歩き回ったのもあるけど、ここで調子に乗ってハシゴすると後々響くことを知っているのであった。

(楽しそうにしているタイムラインを眺めていて羨ましかった)

Day2 (4/17)

この日も早めに出発。

前日徒歩で結構かかることがわかっていたので路面電車で。

信号もあるし結構時間かかるかもなーと思っていたが10分ほどで着いてしまった。信号を観察しているとどうやら路面電車の通過に最適化されているようですごかった。

(右折車めちゃ大変そうだなというのがドライバー視点)

 KnuX「Performance Bugs and Low-level Ruby Observability APIs」

普段知ることのないレベルでのパフォーマンス問題の調査について。

TracePointを駆使して色んな調査ができるようになっているんだなー。自分が触っていたRubyに入りたての頃よりhookできるイベントがかなり増えていて学びだった。

osyoyu「Benchmark and profile every single change」

Sinatra likeな軽量フレームワークXinatraを作って極限まで速さを求める話。

現実世界においてrackより上のレイヤーで高速にリクエストを捌くにはほとんど時間が残されていないというのが印象的だった。

普段フレームワークレイヤーでやってくれていることはとても多彩だけど、そのほとんどを高速化していこうとするとトレードオフが半端ないな(目標値による)。

maximecb「ZJIT: Building a Next Generation Ruby JIT」

これからのRubyにはZJITという新しいJITが入るというお話。

method-based JITになるということだけどなんで有効なのか理解できなかった...。

JIT関連のトークだと途端に理解力下がるのはどうしようもなさそう(めちゃくちゃ専門的なので) 。

(ちなみに自分が書いたブログのスクショ、会期中2度目の登場(やはり見られている...))

ランチ

この日はchiastolite, repeatedly, udzuraと炊き込みご飯のほうの鯛めし。

昨日とメンバーが似ているけど本当にたまたまフラフラしている人を捕まえたらこうなった。

炊き込みご飯もかなり美味しかった。

asonas「How to make the Groovebox」

音。

午後一のセッション。聞いていてめちゃ楽しいセッションだった。

実装の試行錯誤も良かったけど、相当泥臭い実装を地道にやっていたのが印象的だった。

sleepで同期制御しているとトラック増えまくってきた時に遅延しない？という質問をしたら「それはそう」という回答を得た。

それはそうなのだがAudio APIにクリックを制御するものがあってそれを使うと良いという話は勉強になった。

実際の商用Sequencerはもっと低レベルなところで制御されているんだろうな。

高いがちゃんとお金払う価値があるソフトウェアたちだ。

koic「RuboCop: Modularity and AST Insights」

構成力と密度がすごかった。

RuboCopで今までハックとされていた仕組みをオフィシャルでより良い方法として実現するための仕組みを行ったという話からスタート。

コツコツやり続けたのもすごいが、個人的な感想で一番すごいなと思ったのが、あーこういう仕組みだと良いとされるだろうな、というところに向かってひたすら進み続けたことだった。

更にその取り組みがModularityとつながり、Parserの革新と共にRuboCopのAPIを適切なものにしたやつとガチッとハマるという、取り組みとして完成度が高すぎるだろ。

koicさんは日本語でめっちゃ早口で話していたが、それでも時間がギリギリだった様子。

これは動画が出たらもう一度見返したいセッションのうちのひとつ。

tenderlove「Speeding up Class#new」

こちらもコツコツとひたすらに計測し改善し続けるという話。

object allocation を徹底的に潰していくという内容だったが、Class#new というメジャーな箇所を改善するにはここまでカリカリにやらないといけないのかー、まあそうだよなと思いながら聞いていた。

この取り組みがmergeされないにしても、Shopify勢のベンチマーク主体の取り組みはほんとお手本だな。

coe401_「Making TCPSocket.new "Happy"!」

ホスト名解決のアルゴリズムを入れたエピソードのお話。

RFCと既存実装のバランスを紐解いて実装していったという内容。

RubyKaigiで登場するコツコツ系のトーク(そうじゃないものは存在しないと思う)は本当に頭が下がる。

途中akrさんからの指摘で「実装がstateによりすぎてない？」というのがとても印象に残っている。こういう本質的な指摘をこの局面でバシッと出せるのカッコよすぎる...

Timee Drink up at RubyKaigi2025

会場を少し早めに出てこちらに備えていた。

参加者60人超でお店を貸し切ってタイミーのDrink upを開催。すごい。

1階と2階の座敷があって、自分が到着した頃には1階は埋まっていたので2階へ。

テーブルを見回すと海外ゲストが2人いるテーブルが空いていたのでそちらへ。

せっかくのRubyKaigiなので英語使う機会があるほうが良いに決まっているのだ。

そのテーブルには日本人でも英語話者が多かったのでEnglishテーブルが出来上がった。良き。

時間にして3時間ぐらいかな、英語でたくさんコミュニケーションできて良かった。#rubyfriendsもできたし、今度Kaigi on Railsにも参加するとのことなのでその時また会いましょうと約束。

時間中はたくさん出てくる料理を英語で説明する役もしていた。地場のものも多かったので単語が出てこなかったやつも多かったな。

途中でmoznionをつかまえて一緒に話してもらった(ありがとう)。色々盛り上げてもらえてさすがやなと思ったのでした。

Drink up終了後は帰路で野生のkatsyoshiに出会ったのでThe Tapで1杯だけビール飲んでこの日は終了。

Day3 (4/18)

朝同じような時間に起床して準備。

しかし準備は完了したものの体が重くてボーッとしていたらRuby Committers and the Worldを見逃す時間になってしまった...

早く寝ているとはいえさすがに疲労が蓄積してきたか？

jeremyevans0「Eliminating Unnecessary Implicit Allocations」

Aaronに続きallocationを徹底的に排除していくセッション。

こちらはメソッド呼び出しに関するallocation削減について。

メソッド呼び出しのたびにこれだけのallocationが発生しているんだな。

これはmergeされるんだろうか？

トークも聞きやすかったしスライドもわかりやすかったので後で見返す。

Eliminating Unnecessary Implicit Allocations

ko1「Toward Ractor local GC」

Ractorを使っている時にshareableなローカル変数をどうGCで扱うかという話を聞いた。

このあたりからだいぶヘロヘロで頭に入ってこなかったところが多いので後で見返す。

https://www.atdot.net/~ko1/activities/2025_rubykaigi2025.pdf

Matz Keynote

前夜のThe Tapで「こんだけAI流行っているのにAIに関するトークがひとつもないカンファレンス」と言われていた時に「いやーたぶんMatzが話しますよ」と予言していたのが的中。

3.5 or 4.0の話はめちゃ盛り上がっていたなーNamespace, ZJITなどあるし、まだまだRubyは盛り上がりそう。すごい。

Closing

飛行機の関係で聞かずに撤収。帰りも飛行機に乗り遅れるわけにはいかないのだ...

バスで空港まで移動したがとても快適だった。近いし。

帰宅

なんやかんやで帰宅したら24時前だった。無事帰ってきてえらい。

まとめ

今年は体調に気をつけたり、毎晩早寝することでかなりのセッションを聞くことができた。

そして勤務先のスポンサーブースはブースチームががっつり入ってくれていたのも忘れてはいけない。めちゃ感謝。

直近2年は色々忙しくてセッションを聞いたりランチに行ったりができていなかったが、久しぶりにRubyKaigiを堪能できた。

来年は函館とのことなので、せっかくだから移動も楽しみたいな。

おつかれさまでした。

RubyWorld Conference 2024に参加してきた

こんにちはバックエンドエンジニアの@ryopekoです。

これはTimee Advent Calendar 2024の17日目の記事です。

今回はRubyWorld Conference 2024およびRuby biz grand prix 2024の表彰式に参加してきたので、そのレポートをお届けします。

これら2つのイベントは12/4〜6にかけて島根県松江市で開催されました。

この期間はRuby Weekと題して複数のイベントが開催されていました。

私はこれらのイベントにTimeeに存在する「Kaigi Pass」と呼ばれるカンファレンス参加支援制度を用いて参加してきました。

Ruby biz grand prix 2024 表彰式

旅程のうちの初日である12/4にはRuby biz grand prix 2024の表彰式が開催されました。

この表彰式には応募された企業サービスの中から7社（7サービス）がファイナルノミネートとして表彰が行われました。

表彰式を通してそれぞれのサービスについて知る機会がありましたが、全てのノミニーは素晴らしい価値を社会に提供し続けているものばかりでした。

そして今年の大賞ですが、なんとTimeeが受賞しました！！！

https://corp.timee.co.jp/news/detail-3922/

会場には受賞者代表を含め3人のエンジニアが参加していましたが、大賞が発表された瞬間、会場だけでなく社内のSlackでも大盛り上がりとなっていました。

なお余談ですが、私自身は所属する企業が大賞を受賞するのは2度目となります！

ジンクスとして成立させてしまったので、今後は縁起物として扱ってもらいたいと思います。

表彰式のあとはレセプションがあったのですが、私は不参加でした。

なお受賞者代表として参加していた同僚はレセプションの時間中取材や名刺交換をひたすら行っていたと聞いています（同じ立場を経験したことがあるので、こうなるのは知っていました）。

RubyWorld Conference 2024

表彰式があった次の日から2日間、12/5〜6にかけて松江市のくにびきメッセを会場としてRubyWorld Conference 2024に参加してきました。

こちらもRuby Weekのイベントの一環として開催されていました。

2日間かけて様々な種類のトークを聞くことができてとても身になるイベントでした。

中でも1日目最後のセッションとなった関さんの「DICOMの文字集合をRubyで扱う話 - ISO/IEC 2022複数文字集合を読むぞ」が一番楽しめました。

内容はDICOMという医療用フォーマットの歴史とそれをパースするプログラムをRubyで書いたというものでした。

DICOMという規格を私は知らなかったのですが、歴史が積み重なって様々な表現を扱えるようになっている一方でとても複雑なものとなっていて、この説明を聞いているだけで胃が痛くなるようなものでした。

しかし発表者の関さんはパースするプログラムをとてもエレガントかつシンプルに実装されていてとても感動したのを覚えています。

実際の内容はアーカイブで見ることができます。

https://www.youtube.com/live/VOov1nyQTdw

一言ではとても言い表せないのですが、「パースをそうやるか！！！」というようなとてもカッコいいアプローチになっていました。

この発表を聞きながら自分も何か複雑な問題を解決しようとするときに、関さんが取ったアプローチの様に見方を変え、シンプルかつエレガントな問題解決ができるようになりたいなと思いました。

おまけ

会期中はたくさんのRubyistと交流することができました。

特にセッションのホールとは別の場所で内容が同時に中継されており、それを見ながら他のRubyistと様々な議論（ツッコミ？）ができたのはとても良かったです。

セッションをホールで真剣に聞くのもいいですが、リアルタイムでガヤガヤしながら見るのもこのカンファレンスの醍醐味だなあと思いました。

おまけのおまけ

松江市はとても良いところで、特に日本酒と食べ物が最高に美味しいのがとても魅力的です。

更に繁華街としては比較的コンパクトなのと、何度も参加している参加者が多いため、お店でバッタリ会うということもたくさんありました。

そこでも普段のエンジニアリングの話やRubyに関するたくさんの話をすることが出来てとても得るものがたくさんあった会期期間でした。

Shippio に入社していました

転職していました

6年半勤め続けていた前職を5月末に退職し、6月から Shippio という会社に入社しました。

Shippio | 貿易業務の可視化・効率化クラウドサービス

このたび8月末で無事試用期間が終わったためご報告です。

いつも通りなら入社した日に即、各所にご報告していたのですが、今回自分の中で大きなチャレンジ(後述)をしようと決めて入社したため、このタイミングでの報告になります。

今回の転職で重要視したこと

実は2021年は体調を大きく崩し、業務にうまくコミットできていなかったこともあり、自分の中で次のチャレンジの重要性が増していました。

体調は2022年の2月頃には軽快したのですが、自分が今後どういうことができるのか、どうやっていくのか、どうなっていくのか。たくさんのことを今回の転職活動の判断基準に選びました。

その中でも以下のことをより重要視しました。

  • 世の中にインパクトがあることを事業にしていること

  • 自分の仕事を通して何がどう世の中に影響しているかがわかりやすいこと

しかしこのことを重要視するとなかなか採用プロセスに進もうという会社に出会えませんでした。

今回転職活動をエージェントにサポートしてもらいながら案件を確認し、少しでも良いと思えた会社にはカジュアル面談をお願いするということを繰り返していました。

かなりの案件数に目を通したと思いますが、幸い現職に出会うことができ、更には入社することができました。

何が決め手だったか、何をチャレンジするのか

  • スタートアップということもあり無限にやることがある

  • 事業と目的が明確

  • 事業のための情報収集と整理の頻度と速さが抜群

  • 整理した情報を元に UI/UX が良い形で実現されている

  • プロダクト開発における公用語が英語(non Japanese なメンバーがたくさんいます)

UI/UX については意思決定のプロセスやプロダクトの開発の上手さがモロに出る領域だと思っていたので特に重要視したポイントでした。

最後に大きなこととして英語を使う環境にチャンレンジできるというものがあります。

自分は正直英語は全く得意では無くコンプレックスだったのですが、今回自分のステップに合う形でのチャレンジができそう、ということもあり大きな決断をすることにしました。

英語に関しては @yoshiori が自分の周りで大きなチャレンジをしつつ頑張っているのを見ていたので、直接相談したりもしました。ヨシオリさんには今回の決断を大きく後押ししてくれたと思っているので、とても感謝しています。

最後に採用情報

Shippio ではあらゆるポジションで仲間を募集しています！

もし気になる方は気軽にお声がけください！！！！

recruit.shippio.io

ActiveRecord を使っていて NoMethodError: undefined method `new' for BigDecimal:Class と言われたら

ActiveRecord でクエリを実行した結果 BigDecimal 型のインスタンスを組み立てるようなものが含まれている場合、使っている Ruby のバージョンや他ライブラリのバージョン次第でこのようなエラーが出ます。

NoMethodError: undefined method `new' for BigDecimal:Class

先日詳細知らされていない状態でこのエラーを渡されたのでとりあえず調べてみると以下の Qiita の記事がトップに出てきました。

qiita.com

結論から言うとこの記事に書いてある対処方法は端的に言ってよろしくないのでやめましょう。

そもそもこのエラーが出る問題の原因として BigDecimal の扱いが、とあるバージョンから変わっているからです。 バージョンによる BigDecimal の取扱方の違いは README.md にちゃんと書いてあります。

github.com

前述の Qiita の記事の何が良くないかって、古いバージョンに固定して対処していることなんですよね。 しかもこうしろと書いてある。

gem 'bigdecimal', '1.3.5'

次に BigDecimal の README.md に書いてある説明を引用します。

version characteristics Supported ruby version range
3.0.0 You can use BigDecimal with Ractor on Ruby 3.0 2.5 ..
2.0.x You cannot use BigDecimal.new and do subclassing 2.4 ..
1.4.x BigDecimal.new and subclassing always prints warning. 2.3 .. 2.6
1.3.5 You can use BigDecimal.new and subclassing without warning .. 2.5

1.3.5 は確かに BigDecimal.new が使えるので一見大丈夫そうに見えるんですが、これサポートされる Ruby バージョンが 2.5 までなんですよね。

2.5、EOL date: 2021-03-31 なんですよ...。

じゃあどうするのがいいかと言うと、この Qiita の記事にはどこでどんな形でエラーが発生しているかが明記されていないので、自分が調べた限りの想像ですが。

(そもそもちゃんとエラーの詳細を記事に書きましょうよ...)

mysql2 のバージョンが古いのが原因です。

github.com

もしこのエラーが発生して、手元の mysql2 のバージョンが < 0.5.0 ならこれを疑いましょう。 rails new すると mysql2 のバージョンが固定された Gemfile が生成されるからバージョン上げるの放置してて Ruby のバージョン上げたら踏んだパターンなのではないですかね。

この記事執筆時点で 2.5 の EOL が目前なので、これ踏む人増えそうなので書き残しておきます。

DeNAを退職します

このエントリーについて

10/30をもって最終出社となり、DeNAを退職することになりましたのでそのご報告です。
現職において社内外の皆様には大変お世話になりました。
本来ならばお一人お一人に直接ご挨拶させていただきたいのですが、諸々の制約のためこのような形を取ってしまうことをお許し下さい。

DeNAで働くということ

DeNAには4年半勤めていたことになりますが、入社当初を振り返ってみると技術的にもマインド的にもまだまだな段階で採用してもらえたことはとても幸運でした。
しかも当時は大物エンジニアが続々と入社している状況で、そんなすごい人達と一緒に働くことを楽しみにしていた反面、ちゃんと会社に貢献できるのかどうかとても不安でした。

DeNAという会社は誰にでも自分のMaxより目一杯ジャンプしてやっと届くか届かないかというところにハードルを置くのがとてもうまい会社で、なおかつ周りのハイスペックなエンジニア達に囲まれ、常に自分の立ち位置を認識できるような環境の中でした。
そんな中入社以降無力感を感じることもあれば成長していることを実感できる充実した日々を過ごすことができました。

その過程で技術力はもちろん、様々なアイディアが色んな場所から無限に湧いてくるような中、更に猛烈なスピードで事業が展開されていくという環境で一致団結していくために必要なコミュニケーション力(個人的には大人力と呼んでいるやつ)も高めることができました。(大人力は今も全然足りていないので引き続き頑張るぞい)

DeNAに入社する際に考えていた自分がこうありたいというエンジニア像を遥かに超え、それまで苦手だったり無関心だった技術領域に踏み込んでいくことができたのは今となってはかけがえのない財産になっています。
今後のキャリアに大きく影響するような経験をさせてもらった会社、DeNAで働く全ての人達に感謝します。ありがとうございました。

また、以前はRubyコミュニティでしか活動していなかった自分ですが、そのままだと決してクロスしないような多くのコミュニティ、優秀な社内外のエンジニアの皆様と交流する機会も増え、多くのものを頂きました。
本当にありがとうございました。

DeNAという会社の魅力

DeNAは永久ベンチャーという言葉を標榜しているわけですが、この2年ほどは以前にも増して社内にいてもびっくりするほどベンチャースピリットに溢れる企業になっています。
様々な事業を行っているということもあるのですが、その裏にはたくさんの失敗や成功があり、それをこれから生まれてくる新しい事業に有機的に繋げることができる企業です。
失敗したらタダでは起きないなんて言葉は生易しい。
その文化を更に加速させ、チャレンジしている企業です。

それは各事業に携わっている人を見ると明らかで、個々の事業が起業したての会社のようにエネルギーに溢れ、人が情熱を持って事業にフルコミットしている稀有な状況があります。
その中で、新卒で入ったメンバー、中途で入ったメンバーがお互いを補うように能力を発揮し、かつ成長し、組織としてのアウトプットを最大化している状態は驚異的でした。
恐らくこんな会社はそうそう無いんじゃないかと思います。
いつどのタイミングでjoinしてもエキサイティングな会社というのが最大の魅力なのではないでしょうか。

じゃあなんで辞めるの？

DeNAという会社はどこを見ても超一流なエンジニアがいる環境です。
それは協力して仕事するという上ではこの上ない経験なのですが、見方を変えると自分の弱点を他のエンジニアがカバーしてくれるということになります。
ただ弱点というのは成長するチャンスでもあり、自分に足りないところを見極められるというメリットもあり、今後のキャリアを考える過程であえて弱点になるようなことを求められるような環境に身を置きたいと思うようになりました。
理由はこれだけではなく、もっともっとたくさんあるのですが、今回色んなタイミングが重なり退職することを選択しました。

次のお話

ありがたいことに次はもう決まっていて、間髪入れずに11月から新しい環境で仕事をすることになっています。
ryopeko先生の次回作にご期待ください。

改めてお礼

この4年半の間、接していただいた全ての方にお礼申し上げます。
これからも変わらぬお付き合いをしていただけると幸いです。

以下謎の余白と謎のリスト

www.amazon.co.jp

Developers Summit 2014 で新卒エンジニア研修についてお話してきました #devsumi

2014/02/13 (木) に開催された Developers Summit (通称デブサミ) 2014 1日目で「新卒エンジニア研修でできることすべきこと」と題してお話してきました。

これはその記録です。

f:id:ryopeko:20140213223854j:plain

(わいふが名札書いてくれました)

はじめに

今回わざわざお時間を割いてお話を聞きにきてくださった方々、デブサミスタッフのみなさま、本当にありがとうございました。

今回のセッションは以下のような内容で話してきました。

一口に新卒エンジニア研修と言っても単に詰め込んで終わり、というのではあまりに勿体無いということを実際のDeNAでの新卒エンジニア研修の事例を紹介しつつお話します。エンジニアに継続的な成長を促すことや自立性を持たせることはとても大変なことです。しかし新卒エンジニア研修ではこの様なエンジニアの素地とも言える部分を育むにはうってつけの場です。
本講演ではDeNAが試行錯誤を繰り返し発展してきた大人数に対する新卒エンジニア研修をご紹介しますが、DeNAの研修は人数によらない研修内容となっているため、来年度の研修からすぐにでも使える内容となるはずです。

とても嬉しいことに私のセッションは満席というだけでなく、当日は立ち見の方もいらしていたという状態でした（感謝）。

このエントリーの最後にスライドを載せておきますのでおおまかな内容はそちらでもご覧いただけます。

このエントリーでは主にセッション後、色んな方から質問を受けたことの一部でセッション内でお伝えできなかったことを、多少補足する形で進めていきます。

質問と伝え忘れたこと

人に物事を教える時に教える側が優れたエンジニアでない場合はどうするべきですか？

これ実はものすごく重要なことです。そのくせ伝え忘れました、すいません。

これは教えられる側からすれば実はすごく瑣末な問題だと思っていて、なぜなら教えられる側は適切な答えやインプットを貰えれば良くて、それを得られる相手であれば誰でもいい訳です。この理屈は裏表が逆で正しく言い換えると、表立ってはスーパーなエンジニアに教えてもらいたいと言いつつも、それは適切な答えを得られるという裏付けがスーパーなエンジニアにはあるということだけだと思います。誰か、もしくは自分がスーパーだと思うラベルがついている人から教わればハズレな答えを掴ませられる確率が低いというものです。

であれば適切な答えを与えてあげればよくて、仮に現在自分で答えを持っていなかったとしても、「君のその考えはとても重要で是非とるべきアプローチなんだけど、今自分は適切な答えを持っていないんだ」と正直に伝えた上で、「ちょっと調べて答えを用意するから君も君なりに答えを導き出してみて」と言って自分は後ほどきちんと調べればいいだけです。そうして後日答え合わせをすると。

なんか一見頼りないことに思えますが、セッション中でもお話したとおり我々の知識技術領域は無限の幅と深さを持っているので、この様なシチュエーションは日々の業務では日常茶飯事だとも言えます。つまり日頃仕事をする上で大事なことを2人でロールプレイするという絶好のシチュエーションです。ここで下手に取り繕うと速攻で新卒氏にバレます。取り繕うというのにもそれなりの知識や経験が必要なんです。正直になるということが信頼関係の構築にも繋がります（でもちゃんと行動しないとダメですよ、行動しないでこういうことばかり言う人はただの無能です）。

また、自分がスーパーじゃないという実感があったとしても自分ネックで新卒氏彼らの天井を自分に合わせる必要はなく、時には自分自身が理想とするエンジニアを演じ、伝えるべきことを伝えるというがとても重要だと思います（acts as 自分がすごいと思っているエンジニア業）。

教える側が理想とするエンジニア像に達していないのであれば、その理想を新卒氏と一緒に指を指して目指せばいいのです。

どうやってレビューでの言動からやばそうなことを察知するのか

これも明示できていませんでした。

この質問は ask the speaker コーナーが終わった後に休憩室をふらふらしていて @igaiga555 さんと まつもとさん、ささださん とお話していたときに出た質問です。

これは色んなパターンがあるのですが、一つ言葉にしやすいものとしては「問題に対する解決案への論理がショートカットされているパターン」です。

例えば問題から結論には5ステップぐらいの論理展開が必要な問題があったとして、その説明が 1 → 2 → 5 と途中が飛んでいる場合です。

この原因もいくつかあって

  • そもそも理解していなくてなんとなく正しい結論にたどり着いている
  • 答えだけを周囲（同期や google 先生など）から得ている

どっちも良くないわけですが、この状態にあるかどうかを見極めるには飛んでいる中間を2分探索して質問を投げていくのが良いです。

そうすれば適切な理解の上結論に至っているかどうかがかなりの精度、かつ省エネで判定できます。

 

これらの質問はごく一部ですが、特に伝えておきたかったものとして補足させていただきました。

最後に

実はこれから書くことはデブサミのオーガナイザーである岩切さんにはお伝えしたのですが、ものすごく縁というものを感じたので感謝の意味も込めて書き留めておきます。

 

自分にとってデブサミは数年前に初参加したときに今までの自分の世界をひっくり返し、学ぶことの重要性と楽しさを教えてくれた、いわば今の自分の基礎を成すものです。

そんなデブサミでいつかセッションを持って、デブサミの窓を通して誰かにとって新しい価値を伝えることでデブサミに恩返しをしたいというのは大きな目標のひとつでした。

それが今回、岩切さんがオーガナイザーとしての最後のデブサミで、しかも自分が新卒にものを教え伝え、学ぶことという内容のセッションを持って目標を達したこと。

これものすごく出来過ぎて帰りの電車の中で気がついた時に思わず吹き出してしまいました。

なのでこの気持ちはしっかり書き留めておこうと思った次第です。

 

おまけ

今日のセッションで使ったスライドと、普段スライドを作る前に作成するアウトラインを残しておきます。

どなたかの参考になれば幸いです。

アウトライン

実際のスライドと内容とは多少ズレていますが伝えたいことはほぼ満たしています。

(いつもこの状態を作ってからスライドを書き起こしています)

  • タイトル
  • 自己紹介
  • 新卒研修って何でしたっけ？
  • 世にある新卒研修のイメージ
    • 必要なことはこれとあれとそれとこれと…
      • はわわ
    • よし、終わり！突撃ー
      • 各所「むりむりむりｍばたり」
      • メンターの力量に依存してぎりぎりなんとかもしれないがジリ貧
  • 弊社の場合もこれと似たようなことが起きたり起きる要素が揃ってる
    • 今年度の新卒の特徴
      • 未経験者 >>> 経験者
      • 大人数 (今年度70名弱)
    • 教えることたくさん
      • もうほんと無限にある
      • だけど教えるのムズすぎ時間無さすぎ人いない
      • 無理
    • やれる範囲でやりましょう
      • 全然やれていない
      • やる前から投げてる
    • 現場のニーズの変化
      • サーバーサイドだけやってればいいとかいう時代じゃない
      • あれもこれもそれも
      • 成長してくれない！
  • まずは新卒にまつわる問題点を整理、解決策を考えてみた
    • 技術レベルが求める水準に達していない
      • いいから引き上げる
      • 今まで棚上げしていたことをちゃんと教える
      • ここでちゃんと教えないと新卒が現場出て死ぬ
        • むしろこの辺身につけていないで現場に来られるとおれが死ぬ
        • 教え方工夫して理解できるようになるまで諦めないで教える
        • その結果自分が死ぬとしても教えなかったら結局死ぬんだからいいから教える
        • 教えきれなかったとしてもその失敗は来年に生きるはず
    • 研修でやってきた知識が現場で生きない
      • 局所的な知識や技術じゃなくて汎用的なものをちゃんと教えましょう
        • 技術や知識や問題領域は幅広な上に深くて流動的、しかもロールがある
        • なのに局所的なことを教えるのは研修じゃない、研修担当のギャンブルだ
      • 基本の基をしっかり
      • 現場固有の事象を取り扱わない
        • 現場ではやむを得ずこうなってますとかBKは絶対ダメ
        • むしろ理想を刷り込む
          • レガシーに浸る前に理想を刷り込む
    • 現場で教える時間も暇もない
      • 教えなくても勝手に学んでいけるような人材を育てましょう
      • 問題を正しく捉え、立ち向かえる力を養う
      • 目先の技術力より観察眼、応用力を養う
    • 知識や技術は水準、汎用性、応用力で評価される
  • 問題点と解決策を考えたらこれって新卒だけじゃなくて会社全体の課題なんですね、ということに気がついた
    • 誰のための研修なんですか？
      • ✕新卒のため
      • ◯みんなのため
    • 個別の事情に対応すればいい？
      • 無理、変化しまくりだから
      • 既存社員も停滞されてると困る
  • 以上を踏まえて弊社での研修の流れ
    • フェーズは4段階
      • 簡単な座学
      • サービス企画
      • 設計（画面とかDBのおおまかなもの
      • 実装
    • 各フェーズではレビューがある
      • レビューは1時間
      • 各フェーズ大体 5〜7回ぐらい
      • 各フェーズでstep1, step2と分かれている
        • step2ほど詳細に踏み込んだレビューになる
      • 新卒と研修講師の1対1
        • 70名超の個別指導 (小学校1学年の3クラス分!!!)
    • 講師陣
      • 現場のエンジニア3名
        • 今回の研修のために一時的に現場を離れて100％コミット
      • 外部研修講師数名
    • 卒業時期
      • 早抜け方式
        • 早い人は2ヶ月ぐらい
        • 遅い人だと半年 (9月末で全員卒業
    • 研修のゴール
      • 正しく問題へ立ち向かえる
      • 継続的に主体性を持って成長できる
      • 変化に強い人材
  • 研修の進捗と成長度合い
    • 研修が進んでいくと個人の差が徐々に出てくる
      • 経験者未経験者問わず
      • 経験者であろうとも伸び率や未知の領域との向き合い方など
    • 早めに気がつく
      • 成長を促すために打てる手はなんでも打つべき
      • 教え方を工夫しないといけないなら教え方を返る
      • 強みを更に伸ばして弱点を克服させてあげるスタイル
    • どうやって気がつくの？
      • 計測計測ー
      • 想像するよりまずは計測
        • ウェッブサービスと同じやー
      • 各フェーズ各stepにかかっている日数を記録
        • 大体パターンが出てくる
        • 進捗する人が増えてくると精度が高まる
        • 高まるころにはもう手遅れ
      • そこで技術テストをやってみた
        • Perlの筆記テスト
          • PC無し、本無し
          • 簡単なループからオブジェクト指向をしっかり使ったコードの読み取り
          • 脳内コンパイル力
            • あー障害対応のときに必要になるやつだ
          • 基本的な知識がちゃんと身についてるか
          • アーカイブに素早く辿り着くためのスキルも必要なんだけどここでは置き
      • 新卒との会話
        • フラッと研修部屋に遊びにいってどうでもいい話をする
        • レビュー時のふとした発言を記録
          • これ結構ばかにならなくて普段どういう考えをしているかが読み取れる
            • こういう発言しちゃうようなのってもしかして着実性無いのでは？とか
          • この前こういう短絡的な発言してきたけど今回はすごい論理的に組み立ててきたり説明するためのツールも工夫してきた
            • すげえめっちょ成長しとるテンションあがる
    • 気がついたらどうするの？
      • 褒められるところはたくさん褒めてあげる
      • 良くないところは改善を促す
        • 促すことにより成長や進捗を加速させる
      • 改善は最初は自力で
      • 改善してこないようなら手助けしてあげる => フォローアップ
  • フォローアップ
    • 今年度最大の発明
    • フォローアップとは
      • 毎日 or 隔日で講師との 30 分間の 1 on 1
      • プログラミングのハマりどころ解決
      • 問題解決手法のトレーニング
      • 議論のトレーニング
      • 成長促進のための徹底した振り返り
      • etc…
    • 大事なこと
      • 良い所を伸ばして良くないところを改善する
      • ひとりひとり丁寧に
      • 一筋縄ではいかないのでひたすら工夫
      • 改善したらフォローアップは卒業
      • 最終的に自信をつけさせる
    • フォローアップビフォアアフター
      • ビフォアー
        • 暗闇の中ゴールの場所もわからないのに目隠し耳栓している状態
          • 何がわからないかがわからない
          • 何がわかったかわからない
          • 何のために自分が今やっていることをやっているのかがわからない
        • 敵の強さがわかんない
          • Lvわからないのにバラモスと戦っている
          • 倒せるかどうかもわからない
            • 死んで気がつく
      • アフター
        • 本質を見抜く力
        • 自分のたどってきた道のりを正しく把握している
        • 間違った道に入ったことを検知できる
        • ゴールまでの距離
        • 敵の強さがわかる
        • 敵を分断して戦える規模にしてから戦える
    • 効果
      • フォローアップを受けた人のほとんどが急激に成長
      • 時間と人員が許すなら全員にやっても良かった
      • ただ自分の弱い面と向き合い続けるってすごくしんどい
        • 結局は本人の意志に頼るところ
        • 無理強い良くない
  • 今年度研修の総括
    • 現場アンケートより
      • 主体性向上
      • 基礎的な技術力向上
      • git, github ネイティブ
        • 去年すごく苦労した
      • 切り込み力
        • 問題へ立ち向かい切り開いていくエピソード多数
    • 所感
      • アンケート通り
      • サービスを作る楽しさをもっと教えたかった
        • もっと自分で考えに考え抜いたものを形にすることもやってもよかった
        • レビューコストが爆発するという問題点がある
        • 研修とは別のアプローチが必要か
      • 自身の力を伸ばすことを優先して新卒同士で相談、協力させることができなかった
        • 実は何もできるようになりませんでした、というのを避けたかった
  • まとめ
    • 組織のニーズも大事だが、変化の激しい組織のニーズに応えるのは大変
      • 応えると2年後には陳腐化してる恐れがある
    • 基本的な技術力向上はとても役に立っている
    • 新しい技術も本質的な知識が備わっているので吸収が早い
    • 人にフォーカスすることにより人材の柔軟性を高めたら組織にフィットしやすくなった
    • 組織の型にはめて人材を育成するより変化に強い
    • 特に弊社のような事業領域が広く変化が激しいところには有効
スライド