メドピア開発者ブログ

■エンジニア紹介ページはこちら

speakerdeck.com speakerdeck.com speakerdeck.com speakerdeck.com speakerdeck.com

2023-08-02

potatotips主催させていただきました

iOSエンジニアの小林(@imk2o)です。メドピアでモバイルアプリのテックリーダーをしております。

さる2023年7月21日、弊社でpotatotips #83を主催させていただきました。以前にもオンラインで主催させていただいたことはあったのですが、オフラインを交えたハイブリッド開催は初めてでした！

弊社のモバイルアプリエンジニア総勢5名がLT登壇しましたので、その内容を紹介させていただきます。

発表内容には、実際の業務の中で生じた課題に対する取り組みもありますので、参考になれば幸いです。

ハイブリッド開催の所感

技術系イベントもオフライン開催が復活してきたこともあり、企画当初から社内を会場として実施したいという声があがっていました。ただ実際のところエンジニアだけで開催準備や当日の進行をするのは難しく、弊社HRチームに協力を仰ぎました。ここで多忙な中でも快諾いただいたのが、開催成功の一番の要因だったと思います。この場を借りて、あらためてHRチームには御礼申し上げます🙇‍♂️

また発表に関して、オンライン配信と会場での投影を同時に行うための機材準備についても色々工夫をしてもらいました。

会場発表者を含め、すべての参加者にZoomへ入ってもらう
発表者は投影したいスライドをZoomで画面共有する
ホスト用PCを会場のプロジェクターに接続し画面投影
音声は別のマイクで収録し、ホスト用PCと会場スピーカーに接続

とすることで発表者が機材への繋ぎ変えをすることなく、ハイブリッド配信を実現しました。事前リハーサルでMacと機材の相性問題が起きていたため、その解消と手順の簡略化をも実現したナイスソリューションですね！

LTの後に懇親会をさせていただきましたが、技術的な話から雑談まで色々なお話しをさせてもらい、とても楽しい時間を過ごせました。エンジニア同士だと、初対面でもすぐ会話できるのが不思議ですよね！対面でエンジニアの方々とコミュニケーションする機会となったのが、開催して一番よかった理由かなと思いました。

一方でオンライン参加いただいた方にはたくさんの拍手をいただいたものの、こちらのコミュニケーション不足でやや置き去りにしてしまったのかなと反省しております。振り返りをした上で、今後のイベント企画・開催に生かしていきたいと思います。

お知らせ: iOSDCスポンサーセッションに登壇します！

メドピアは今年も iOSDC Japan 2023に協賛しております。弊社iOSエンジニアの新井がスポンサーセッションに登壇しますのでよろしくお願いいたします！

是非読者になってください

メドピアでは一緒に働く仲間を募集しています。ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら

2023-07-28

「EM勉強会」をやってみたらすごく良かった話

メドピアでエンジニア／マネージャーをしている濱田 (@yut_h1979) です。

昨年末から半年以上かけて、「EM勉強会」(エンジニアリングマネジメント勉強会) と題した『エンジニアリングマネージャーのしごと』の輪読会を実施しました。これがとても良い取り組みになったので、その経緯や内容について共有しようと思います。

1. なぜやろうと思ったのか？
- メドピアの組織拡大に伴う課題感
- EM学習に最適な書籍との出会い
2 . 勉強会の始め方と進め方
3. 工夫点と留意点
4. やってみてどうだったか？
5. まとめ

1. なぜやろうと思ったのか？

メドピアの組織拡大に伴う課題感

ここ数年でのメドピアの組織拡大に伴い、「マネジメント人材の育成／拡充」が課題であると自分は感じていました。

一定以上の規模に成長した開発組織では、エンジニア個々人の技術力だけではなく事業部との協働なども含めた開発組織の総合力 (生産性) を上げられるような「マネジメント人材」も一定以上必要になってくる、そして現状ではここがボトルネックになっている、という課題感です。

EM学習に最適な書籍との出会い

そんな中、昨年の秋口に『エンジニアリングマネージャーのしごと』という書籍に出会いました。この書籍は下記の点が素晴らしく、学習に最適であると感じました。

これまで自分が学習・経験してきた「EM (エンジニアリングマネジメント) のノウハウ」が、網羅的・体系的に言語化されている
EMに関するトピックが、「心構え・姿勢」といった精神論ではなく「メソッド・テクニック・スキル」といった実践論的に書かれている
「他者とのコミュニケーション」「タスクの委譲」「プロジェクトマネジメント」など、マネジメント職でなくても役立つトピックが多く記載されている

さらに、メドピアでは「テックサポート」という学習・スキル向上のための制度があります。そこで「この書籍を使って勉強会をやると良いことが起こりそう！」と感じ、「EM勉強会」を提案・実施するに至りました。

2 . 勉強会の始め方と進め方

勉強会ニーズの把握

「EM勉強会をやると良いことが起こりそう！」と自分が感じていても、それが独りよがりだと意味がありません。そこで、自他部門のEMやメンバーに事前ヒアリングを行い、本勉強会のニーズを探りました。その結果、「おおー良さそう！」「いつからやるの？早くやりたい！」といった反応を頂けたので、「よし、イケる！」という感触を得ることができました。

Slackチャンネルの開設と導入

「EM勉強会」の開始にあたり、まずは勉強会用のSlackチャンネルを作ることにしました。そして全エンジニアが入っているSlackチャンネルにて勉強会用Slackチャンネルの開設と「EM勉強会」の実施日時について案内し、興味あるメンバーに勉強会 and/or Slackチャンネルへの参加を促すようにしました。

読書ペースと進め方の決定

アジャイル開発でもプロジェクト推進でも、「結果の一部から全体を予測する」ことは肝心であると考えます。

そこで、勉強会の第一回では参加者と今後の進め方を相談しつつ、実際にみんなで「読書ペース」を計測しました。その結果、だいたい「15分で5ページ前後 ≒ 30分で10ページ前後」ということが分かったので、そこから次回以降の進行ペースと進め方を決定しました。

一回の範囲：10ページ前後
- 10数ページの章は1回で読み切る
- 15ページ超の章は2回に分ける
前半約30分：読書＆呟きタイム
- 黙々会的にその日の範囲を読み進める
- その中で気になった箇所や意見／感想などをSlackに適宜呟く
後半約30分：深掘り＆議論タイム
- Slackに呟かれた内容をピックアップし、みんなで深掘る

3. 工夫点と留意点

予習不要でハードルを下げる

『エンジニアリングマネージャーのしごと』は、300ページ超のボリュームを持つ書籍です。一回に10数ページの進行ペースだと、読み終えるのに「26回」、週一開催だと「約7ヶ月」という長丁場になることが分かりました。そこで、参加者が途中で脱落しないようにハードルを極力下げる配慮が必要と考え、事前の予習は不要としました。

内容をSlack上でオープンにする

勉強会はGoogle Meetで実施しましたが、前半30分の呟きと後半30分の深掘りや議論など、勉強会の内容はすべてSlackチャンネル上でオープンにしました。深掘りについてはSlackのスレッド返信で行うようにし、Google Meetのチャットコメントや口頭での意見も極力Slackに転記するようにしました。このようなやり方にした狙いは以下の通りです。

ワイワイ盛り上がっている感が出る
欠席者／未参加者も内容を簡単に追える
勉強会後の追加コメントも簡単に行える

「次回予告」で興味を惹く

先述の通り、本勉強会は「26回」、週一開催で「約7ヶ月」という長丁場になります。そこで、次回への期待を持たせて参加継続率を高める目的で、勉強会終了時に「次回予告」を行うようにしました。

「次回予告」のコンテンツは オライリー書籍ページの目次情報をコピペすれば良いので簡単でした。また、これには「次にどこまで読めば良いかを事前に把握できる」という効果もありました。

4. やってみてどうだったか？

興味ある人が想像以上に多かった

本勉強会を始めるまでは、事前にニーズ把握はしていたものの「果たしてどれくらいの人が参加してくれるだろうか…？」という懸念がありました。しかし蓋を開けてみれば、勉強会には常時10名前後が参加し、勉強会用のSlackチャンネルには30名以上が参加してくれました。勉強会を始めた時期 (2022年後半) のメドピアのエンジニア総数は約80名 なので、割合としてもかなり多くのメンバーが興味を持ってくれたということになります。

もしかしたら、勉強会の内容をSlack上でオープンにしていたことも良かったのかも知れません。実際、最初はSlackチャンネル参加だけしているメンバーから「自分も勉強会に参加したい！」というケースも一定数ありました。

様々な立場からの議論ができた

本勉強会には前職からマネジメント経験のあるメンバーやマネジメント未経験者など、多様なバックグラウンドを持つメンバーが参加しました。そのため、同じトピックでも興味のある部分が異なったり、マネジメントする側でなくマネジメントされる側ならではの意見が出たりなど、様々な立場からの議論ができました。

また、マネジメント経験者からは書籍の内容を補強するような参考情報も随時頂けたりしました。こういった体験は一人で本を読む場合では得られないと思うので、本勉強会は自分を含め参加者にとって非常に有意義な場になったと思います。

事業部メンバーからも反応を頂けた

さらに本勉強会は、エンジニアだけでなく事業部メンバーからも興味を持って頂けました。個人的にも本勉強会を通じて、『エンジニアリングマネージャーのしごと』の内容の一部 (というか半分くらい) は「職種を問わず通用するマネジメントの基礎になり得る」という実感を持ちました。そこで現在は、本書の内容をピックアップした「ビジネス職向けのマネジメント勉強会」を企画中で、近いうちに実施する予定でいます。

最後に、参加したメンバーからの全体感想を抜粋で紹介します。

『エンジニアリングマネージャーのしごと』、めちゃめちゃ良い本だなと思った
エンジニアリングマネージャーのいろんな観点を理解できて良かった
本の内容だけでなく、参加者の経験談とか感想とかも聞けたのが良かった
自分の欠席時も、Slackをあとでキャッチアップできて良かった
総じて、一人で本を読むのとは違った体験ができた

5. まとめ

以上、メドピアで実施した「EM勉強会」(エンジニアリングマネジメント勉強会) の取り組みについて共有しました。マネジメントは唯一解が存在しない難しい世界ですが、だからこそこういった勉強会を通じて様々な知見や学びを得るのは意義深いことであると考えます。

本エントリが、マネジメントや勉強会運営に際して何らかの参考になれば幸いです。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら

2023-06-26

RubyKaigi 2023をテーマにした社内LT会に参加しました

今年の4月に新卒で入社したエンジニアの冨家(@asahi05020934)です。
今回は、RubyKaigi 2023をテーマにした社内LT会に参加したので、それについてレポートします。

今回の社内LT会に参加する前

私は、新人研修としてRubyKaigi 2023に参加しました。
皆さんは、どのくらいセッションを理解できましたか？

私は、ほとんど理解できませんでした。
その原因の1つがセッションの内容を理解するために必要な知識が足りていないことだと思いました。
例えば、Power up your REPL life with typesを聞いたとき、
「そもそもこのセッションは何をしようとしているのか？」
ということや
「そもそも型を使うメリットは何なのか？」
ということがセッション中に引っかかって、全然頭に入ってきませんでした。

5月29日の社内LT会

しかし、先日、足りていない知識を少し補えた出来事がありました。
それは、RubyKaigi 2023をテーマにした社内LT会です。
弊社は、カンファレンス等で得た知見を定期的に勉強会や社内LT会で共有しています。
今回の社内LT会は、RubyKaigi 2023をテーマに参加したメンバーが有志で、セッションについて自分なりに調べたことや自作したものを発表しました。

社内LT会の要約

ReDoSの話RubyKaigi 2023レポート

この発表は、ReDoSの概要と対策方法に関する内容でした。

JITの講演を聞いてじっとしていられなくなったのでruby-jit-challengeやってみた

ruby-jit-challengeとは、JITコンパイラ作りを試せるチュートリアルのことです。
この発表は、実際にruby-jit-challengeを試してみたという内容でした。

iseq_compile_pattern_each Hacking Challenge

Findパターンは、Ruby3.0で追加されたパターンマッチ機能の一つです。この発表は、Findパターンを前方一致から後方一致に改造してみるという内容でした。

unloosen を使って Chrome Extension を作ってみた

unloosenとは、ruby.wasmによる Chrome Extension 開発に特化したフレームワークのことです。
この発表は、実際に、unloosenを使ってみてつまづいたところを共有するという内容でした。

型検査なしの型導入のすすめ　〜katakata_irbを添えて〜

この発表は、型の定義方法と型の活用方法に関する発表でした。詳しい内容は、Railsプロジェクトへの「頑張らない型導入」のすすめに記載しているので、ぜひ読んでみてください。

ruby mini_debuggerのコードを読んでみた

mini_debuggerとは、Stan Los(@_st0012)さんがBuild a mini Ruby debugger in under 300 linesで発表されたmini Ruby debuggerのことです。
この発表は、コード量が少ないので、mini_debuggerを読むことは意外と難しくなさそうという内容でした。

DIYインタプリタ

この発表は、インタプリタを作って、プログラミング言語が何をしているのか体験してみたという内容でした。

「演算子 "++"の実装、parse.yへの踏み込み」の講演を聞き、得たこと感じたこと

この発表は、Misaki Shioi(@coe401_)さんのImplementing "++" operator, stepping into parse.yのセッション内容を調べ直して、解説する内容でした。

発表を聞いた感想

これら8つのうち、個人的に印象に残った発表が、「型検査なしの型導入のすすめ　〜katakata_irbを添えて〜」でした。
この発表を聞いたことで、型を使うメリットの1つに、コーディング時の補完強化があることを知りました。
そして、改めてPower up your REPL life with typesを見返すと、「このセッションでは、型情報を使用してIRBの自動補完をより正確にしようとしている」ということをなんとなく掴むことができました。
LT会に参加する前は、型を使うメリットやPower up your REPL life with typesでやろうとしていることが全くわからなかったので、雰囲気を掴むことができて今回のLT会に参加して良かったです。

終わりに

今回参加して、LT会にはセッションの内容を理解するために必要な知識を補える可能性があることを知りました。これからも積極的に参加していきたいです。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら

2023-06-13

2ヶ月半で Nuxt サービスを 3.5 個つくった話

フロントエンド

フロントエンドエンジニアの小林和弘です。

去年の 4 月に「Web アプリを 3 つ使ったサービスを 3 ヶ月でつくりたい」という話が降ってきて、無茶を現実にした話をします。

新規サービス「やくばと」で Workspaces のモノレポを使って、医療機関画面、薬局画面、患者画面の 3 つの Nuxt を構築しました。

やくばととは

医療機関、薬局、患者さまの間でやり取りされる医療機関起点の薬局向け処方せん画像事前送信サービスです。処方せんに関する業務負荷を軽減すると共に、患者さまの大きな負担である医療機関、薬局での待ち時間を軽減するということを主な目的としたサービスです。

医療機関、薬局の DX を進め、患者さまの負荷軽減に貢献できる素晴らしいサービスになっています。

開発チームでは医療機関、薬局、患者さまに提供している Web 画面をそれぞれ医療機関システム、薬局システム、患者システムと呼んでいます。

モノレポとは

モノレポとは、ひとつのリポジトリ内で複数プロジェクトを管理するソフトウェアの開発手法を指します。

フロントエンドのモノレポツールでは Lerna が有名です。やくばとでは複雑なビルドフローを組む必要がなかったことと、開発当初は Lerna v4 のメンテナンスが止まっていたことから、技術選定の選択肢からは外していました（やくばと開発中に Nx 社が Lerna のメンテナンスを開始したため、現段階ではモノレポツールとして Lerna は選択肢に入ると思います）。

やくばとでは、yarn の Workspaces を利用してモノレポを実現しています。

「Nuxt サービス 3.5 個」の 0.5

記事のタイトルに書かれている 3.5 個の Nuxt とは何かを説明します。

やくばとでは医療機関システム、薬局システム、患者システムをすべてひとつのリポジトリで管理しているわけではなく、患者システムと薬局システム、患者システムと既存サービスの 2 つのモノレポリポジトリで開発しています。

患者システムは、すでに存在していた既存サービスのリポジトリをモノレポ化してそこに組み込むという形をとっています。既存サービスのフォームコンポーネントなどのコードを、患者システムに流用するために大幅に書き換えています。0.5 はこの既存コードの変更部分を指しています。

ひとつの巨大なフォームコンポーネントを、入力項目ごとにコンポーネント化し、小分けにしたコンポーネントを共通利用するようにしています。作業としては単純ですが、ディレクトリ構造の変更を行っているため、リポジトリ内のほぼ全てのファイルが修正対象になっています。

患者システムは既存サービスのコードを使い回しているので QA テストの工数も大幅削減することができました。

モノレポの設定

モノレポの設定方法は非常に簡単です。

医療機関システムと薬局システムを管理しているモノレポを例に見ていきます。

package.json の設定

モノレポでは package.json をプロジェクトの複数箇所に設置する必要があります。

.
├── package.json
└── packages
    ├── medical
    │   └── package.json
    ├── pharmacy
    │   └── package.json
    └── ui
        └── package.json

まず、プロジェクトルートの package.json の workspaces プロパティにモノレポ対象になるディレクトリパスを指定します。workspaces プロパティには文字列の配列を定義しますが、ワイルドカード * も利用可能なのでやくばとでは下記のように指定しています。

{
  "workspaces": [
    "packages/*"
  ]
}

次に医療機関システム、薬局システム、共通 UI コンポーネントのための package.json を作成していきます。

{
  "name": "@yakubato/medical"
  "dependencies": {
    "@yakubato/ui": "*"
  }
}

{
  "name": "@yakubato/pharmacy"
  "dependencies": {
    "@yakubato/ui": "*"
  }
}

{
  "name": "@yakubato/ui"
}

各 pacakge.json の name プロパティに指定した文字列が package を呼び出すときのネームスペースに使われます。

たとえば、UI の Button コンポーネントを呼び出すとすると、

import Button from '@yakubato/ui/components/atoms/Button.vue'

といった形になります。

yarn workspace コマンド

yarn workspaces を使うと、node_modules のインストールコマンドが変化します。

プロジェクトルートの package.json に Nuxt を追加する場合は、 yarn　add nuxt -W といった形で -W オプションをつける必要があります（オプションをつけなかったらエラーログが流れるのですぐに気づけます）。

また、workspaces で指定したディレクトリ配下の package.json に node_modules を追加する場合は、別のコマンドが必要になります。

packages/ui に @storybook/vue を追加する場合は、プロジェクトルートのディレクトリで yarn workspace @yakubato/ui @storybook/vue -D を実行する必要があります。workspace コマンドの第 1 引数に追加したい package.json の name プロパティを指定して、第 2 引数に追加する node_modules を指定します。

モノレポの利点

モノレポの利点はいくつかありますが、やくばとプロジェクトでは下記のような恩恵を受けられました。

設定ファイルの共通化
node_modules のアップデートが楽
UI コンポーネントの共通利用

設定ファイルの共通化

個別のリポジトリで複数サービスを管理した場合、開発ツールの設定ファイルをそれぞれのリポジトリで管理する必要があります。

モノレポ管理をすると、ひとつのリポジトリで .eslintrc.js, .prettierrc, jest.config.js, stylelint.config.js 等々が一元管理できます。lint のルール変更も 1 ファイル変更するだけで各システムに変更が適応されます。

node_modules のアップデートが楽

node_modules のアップデートには dependabot や renovate といった、PR を自動作成してくれるボットがよく使われると思います。

モノレポ管理をすると、当然ですがリポジトリがひとつなのでこれらの PR 対応が一度で済むことになります。

また、今後発生するであろう Nuxt3 対応も一度で対応できるのも大きいです。

UI コンポーネントの共通利用

やくばとでモノレポを採用した一番の目的は UI コンポーネントの共通利用でした。

デザイナーさんに医療機関システムと薬局システムの UI デザインを共通化していただいた上で、汎用的な Button や Modal コンポーネントを一元管理することで開発工数を大幅に削減しました。

UI の開発工数を抑えるということであれば、UI ライブラリ（Vuetify, Chakra UI, Tailwind UI, etc）を使えばよいのでは？　という話なんですが、長期運用で UI ライブラリが負債化するリスクと作成するコンポーネントの数や UI・UX の品質担保を天秤に掛けて、独自 UI コンポーネントの開発という選択をとっています。

UI コンポーネントのみをパッケージ管理できているため、他のプロジェクトでも同じ UI を使いたいという話が出てきたときに、 npm や GitHub Packages でパッケージとして UI を提供できる状態にあるというのもモノレポ管理の良い点です。

各システムの簡略図

医療機関システムと薬局システムは 2 つの Nuxt と、共通の UI コンポーネント管理を行う Storybook のプロジェクトがひとつの GitHub リポジトリ内で管理されています。

CircleCI 上で 2 つの Nuxt を generate し、生成物を AWS の各 s3 にデプロイしています。CI 設定が共通化できるのもモノレポの利点です。

患者システムもほぼ同じ構成で、共通 UI コンポーネント管理に Storybook を使っていないくらいの違いしかありません。

患者システムは、Storybook が導入されていない既存サービスをモノレポ化しています。すでに UI が構築されていてテスト済という状態だったので、Storybook の導入を行わないという選択をしています（そもそもスケジュールがタイトでインストールする余裕がなかった）。

まとめ

複数ドメインで Web 画面を管理する必要があるようなサービスの場合、UI コンポーネントを共通化してモノレポ開発すると、初期構築や運用コストが抑えられるといった話でした。

複数の Web 画面を利用しないサービスでも、汎用 UI コンポーネントを切り出しておくとパッケージとして切り離しやすくなるという利点があるので、軽い気持ちでモノレポ構成にしてみるのも面白いかもしれません。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら

2023-06-09

After RubyKaigi 2023 参加レポート

メドピア株式会社でバックエンドエンジニアをしている徳富(@yannKazu1)です。

先日、RubyKaigi 2023が開催されました。このイベントは、Ruby コミュニティの開発者が一堂に会し、最新のトピックや開発手法について議論する場として知られています。そのアフターイベントとして、株式会社ZOZO、ファインディ株式会社、そしてメドピア株式会社の3社によるLT・ディスカッション「After RubyKaigi 2023」を開催しました！

今回はそのイベントの様子を簡単にレポートします！

(イベント概要は https://zozotech-inc.connpass.com/event/281473 にて案内してます。)

After RubyKaigi 2023の概要

メドピア株式会社、株式会社ZOZO、ファインディ株式会社3社合同で行うRubyKaigiのAfterイベントです。昨年度はオンラインでの開催でしたが、今年度はメドピア株式会社オフィスでオフラインとオンラインのハイブリットで行われました。

前半、各社のエンジニアによるLTが行われ、後半に、各社のエンジニアのマネジメントを務める方からのパネルディスカッションがありました。

発表されたLT

「REPLとデバッガを取り巻く環境の変化 -Pry, IRB, そしてdebug.gem」　(メドピア株式会社古川健二 @frkawa_)
「ruby.wasm + unloosenでChrome拡張機能を作ってみた」　（株式会社ZOZO 近海斗さん @Ver3Alt）
「そうだ RubyKaigi、行こう。〜初めてのRubyKaigiの歩き方〜」　（ファインディ株式会社遠藤薫さん @aiandrox)
「Road to RubyKaigi Speaker」　（Speakers枠 Go Sueyoshiさん @sue445)
「After RubyKaigi 2023〜メドピア、ZOZO、Findy〜」　（Speakers枠 unasuke (Yusuke Nakamura)さん @yu_suke1994)

パネラー

平川弘通(メドピア) (@arihh)
諏訪智大(ZOZO)さん (@tsuwatch)
神谷健(ファインディ)さん (@k_m_y_)
Go Sueyoshiさん (@sue445)
unasuke (Yusuke Nakamura)さん (@yu_suke1994)

LTの様子

弊社からは古川にLT枠として登壇いただきました。古川は医師のクリニック開業支援サービス「CLINIC Support」のサーバーサイドを担当しています。

古川の発表ではタイトルにもある通り、デバッガを取り巻く環境の変化について説明がありました。

デバッグする際には現状だと、pry-byebugが主に使われるケースが多いです。しかしirbのデバッグ機能もかなり充実してきており、サードパーティーのデバッガーを使わなくても、十分デバッグができます。という説明があった後に、実際にデモンストレーションが行われました。

私自身、pry-byebugを使ってデバッグをしていた人間ですので、irbでのデバッグ機能の充実さにかなり驚いたのと同時に、irbを使ってデバッグする方が楽なのではと感じました。

パネルディスカッション

弊社からはVPoEの平川が参加しました。今年度のAfter RubyKaigiはオフライン開催ということもあり、お酒とピザが用意されており、乾杯のコールと共に和やかな雰囲気でパネルディスカッションがスタートしました。

RubyKaigiでスポンサーをしてみての簡易的なレポートや今回出展したブースの紹介などが行われました。

メドピアでは、今年度のブースでアルコールパッチテストを行いました。実は、2019年のRubyKaigiのブースでもアルコールパッチテストを行なっており、なぜ今年度もアルコールパッチテストを行なったかなどの経緯などが話されました。

また、RubyKaigiの話としては、世界中から多くの人が集まり、オフラインで様々な人と話せたのは非常に有益な時間だと感じたと話がありました。

懇親会

懇親会では、各参加者がドリンクを手に、様々な交流を行いました。特に興味深かったのは、登壇者への質問タイムでした。それは参加者が直接、疑問点や思索に対する答えを得る絶好の機会でした。

そして忘れてはならないのが、参加者が持参した「Rubyメソッドかるた」です。それは既知のメソッドと新たに学んだ知識をテストする楽しいゲームで、全員が大喜びで参加しました。

最後に

これらの素晴らしい思い出と共に、参加者一人ひとりが、この経験を自身のプログラミングスキルや視点に活かし、Rubyコミュニティ全体がさらに発展することを願っています。

次回のRubyKaigiでお会いできるのを心から楽しみにしています。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら

2023-05-30

Railsプロジェクトへの「頑張らない型導入」のすすめ

Ruby Rails RBS

こんにちは。サーバーサイドエンジニアの三村（@t_mimura）です。

主に保険薬局と患者さまを繋ぐ「かかりつけ薬局」化支援アプリ kakariのサーバーサイド開発（Ruby on Rails）を担当しています。

突然ですが！
この度kakariプロジェクトは「型導入」をしました！

皆さんのプロジェクトは「型導入」していますか？
「型導入」しているRailsプロジェクトはまだ少ないのではないでしょうか

なぜ型導入しないのか

型を導入すると何かしらが便利になることは分かっているのに何故やらないのでしょうか（煽り気味）

「型の恩恵」と「型を自分たちで書くコスト」の２点を比較していませんか？
RubyKaigi 2023開催前の私がまさしくそう考えていました。
本当にその２点を比較するべきなのかをここで再考してみましょう。

「型導入」とは何か

まず「型導入」とは何を指すのかを整理するために、「型定義」と「型活用」で分けて考えます。

「型定義」について

ここではRuby公式のRBSについて考えます。

Railsプロジェクトにおいての「型（RBS）定義」の方法は主に5種類あります。

ruby/gem_rbs_collectionや各Gemのリポジトリに定義されている型を取得
pocke/rbs_railsなどのツールによる型の自動生成
typeprofによる型の静的解析
rbs prototypeによる型のプロトタイプの自動生成
自分で型を書く

※ 各ツールの詳細はここでは割愛します。

他にもYARDからRBSを生成するツールなんかもあるようですが、現時点で主流なのは上記の5つだと思います。

ここで分かることは「自分で型を書く」以外にも型定義の方法があるという点です。

「型活用」について

次に「型活用」について考えます。

RBSは型が定義されたファイルでしかないため、それを何らかの形で活用しないと意味がありません。

現時点で私が観測できた型の活用方法は以下の3つです。

Steepを利用した型検査
コーディング時の補完強化
KatakataIrbによるirb補完強化

一つずつ深掘りしていきましょう。

Steepを利用した型検査

「型導入」という言葉を聞いて一番最初に思い浮かべるのはこれではないでしょうか。型検査による利点は知り尽くされているためここでは省略します。

Railsアプリケーションで型検査を意味あるレベルで運用するにはいくつかのハードルがあります。

まずは、Railsアプリケーションコードに対応する型を手動で定義する必要がある点です。
rbs prototypeを活用しプロトタイプな型の自動生成はできますが、「意味あるレベルの型検査」となると手動での型定義は避けられない現状です。当たり前ですがこの型定義は「型導入」初回の一度きりではなく、アプリケーションコードの変更の都度更新する必要があります。

「型定義・型検査はそもそもそういうものだから今更何を言っているのか」と厳しいご指摘もあるかと思います。

そこで二つ目のハードルとして、この手動での型定義作業をチームメンバーに強制する点が挙げられます。
一人プロジェクトならまだしも、我々はチームで一つのRailsプロジェクトを開発しているため独断で決めるわけにはいきませんね。
ただ作業を強制するだけでなく「型を定義し活用し続ける文化」を今まで型と無縁だったRubyエンジニアに浸透させるのは簡単な話ではないでしょう。

ちなみに、偉そうに語っている私は自分で型を書きたくありません。

つらつらと書きましたが、現時点でRailsプロジェクトで「Steepを利用した型検査」を運用するのはコストが高いと考える人は多いかと思います。

※ 「modelsなど特定のディレクトリのみ型検査対象にする」「型検査はするがCIには組み込まず、エラーも無視して良い体制にする」など折衷案はありますが、今回の話の本質ではないため割愛します。

コーディング時の補完強化

上述のSteepにはLSPを提供する機能があるため、これを補完強化に活用することができます。他にもRubyのLSPとして有名なsolargraphについてもRBSをサポートしていくと明言しています。

KatakataIrbによるirb補完強化

KatakataIrbとは型定義を活用することでirbの補完を強化するツールです。作者のtompngさんによる記事もここで紹介します。 qiita.com

Rubykaigi 2023でも紹介されましたね。 rubykaigi.org

本セッションを聞いたことにより「Steepを利用した型検査」以外の活用方法について意識が向くようになり、kakariプロジェクトの型導入と本ブログの執筆が始まりました。

まだまだRBSの活用方法は多くはありませんが、導入ハードルが高い「Steepを利用した型検査」以外にも活用方法があることが分かります。

また、「コーディング時の補完強化」と「KatakataIrbによるirb補完強化」に関しては、一部のクラス・メソッドの型が定義されているだけでその分恩恵を受けることができます。

つまり「型導入」とは

「型定義」と「型活用」を整理してみました。

「自分で型を書く」以外の「型定義」 + 「Steepを利用した型検査」以外の「型活用」 を採用する選択肢が見えてきました。

この形も立派な「型導入」だと提唱します。
今までの「型を自分で書きたくないから型導入しない」という考えから、「これならちょっとお試しで型導入してみようかな」という気持ちになった人もいるのではないでしょうか。

そんな方のためにちょっとお試しで型導入するための手順を以下に記します。
※ 本ブログ執筆（2023/05/29）時点の情報です。RBS周りは進化が早いため常に最新の情報を参照することをオススメします。

お試し型導入の流れ

ここでは実際にkakariプロジェクトに「型導入」した際の手順をベースに流れを記します。各作業の詳細については、それぞれの公式ドキュメントなどを参照してください。

0. KatakataIrbの導入

下準備としてKatakataIrbを導入します。

KatakataIrbは「型を活用する」と前述しましたが、型定義がなくともirb補完が強化されるため型に興味がない方にもオススメします。

以下の記事が詳しいためこちらを参照ください。 www.timedia.co.jp

1. RBS Gem導入

ここからが「型導入」です。
まずはともかくRBS GemをRailsプロジェクトに導入します。

gem 'rbs', require: false

production環境では不要なためgroupの指定や require: false をお忘れなく。

2. RBS Collectionのセットアップ

次に以下のコマンドでGemの型定義をインストールします。

$ rbs collection init # https://github.com/ruby/gem_rbs_collection に登録されているgemの型定義を利用するための初期設定
$ rbs collection install # gem_rbs_collectionの型定義を取得

git ignore対象への追加を忘れずに

# .gitignore
/.gem_rbs_collection/

# 型検査を真面目に活用する場合は型定義のバージョンもGit管理下にするべき
# 現時点では型定義のバージョン管理するほど真面目に型を活用していない
rbs_collection.lock.yaml

今回kakariプロジェクトでは rbs_collection.lock.yaml をGit管理下にしない方針にしました。メンバー間で型のバージョンを揃える必要性は低く、それ以上に「型バージョン更新が無関係のコミットに混ざる」「型バージョン更新だけのPullRequest」が現状ノイズに感じられるためです。

DependabotでのGem更新PRで rbs_collection.lock.yaml も更新してくれる未来が来ると話が変わってきそうですね。

kakariプロジェクトの rbs_collection.yaml が以下です。
meta-tags の型定義が破損しているためスキップしています。 gem_rbs_collectionではなく各Gemのリポジトリに型が定義されているとこういう問題もあるようですね。

# Download sources
sources:
  - type: git
    name: ruby/gem_rbs_collection
    remote: https://github.com/ruby/gem_rbs_collection.git
    revision: main
    repo_dir: gems

# You can specify local directories as sources also.
# - type: local
#   path: path/to/your/local/repository

# A directory to install the downloaded RBSs
path: .gem_rbs_collection

gems:
  # Skip loading rbs gem's RBS.
  # It's unnecessary if you don't use rbs as a library.
  - name: rbs
    ignore: true

  # 型情報が破損しているためスキップする
  # https://github.com/kpumuk/meta-tags/issues/253
  - name: meta-tags
    ignore: true

ここまでの恩恵

ActiveSupportが提供しているメソッドの型定義がKatakataIrbの補完で活用される様子（Before）

Before

After

3. RBS Railsの導入

ここまでででも型の恩恵は得られていますが、更に便利にするためにRBS Railsを導入しましょう。

導入手順はシンプルなので公式READMEをご参照ください。

※ こちらのPRで対応されていますが、 bin/rails g rbs_rails:install で生成されたrake taskがproduction環境で読み込まれないように考慮する必要がある点にご注意ください。

rbs_rails:all タスクを実行することでsig/rbs_rails配下にActiveRecordが自動生成するメソッドの型情報が出力されます。
それにより以下のように補完が強化されます。

ActiveRecordが自動定義している「アカウントテーブルのemailカラムに関するメソッド」の型定義がKatakataIrbの補完で活用される様子

kakariプロジェクトでは現在sig配下をgit ignoreとしています。「型は自動生成のみ」に振り切っての型導入としているためバージョン管理は不要という判断です。
手動での型定義の運用方法が定まってきたらこの辺の設定は変更すると思います。

4. Steepの導入

一旦型定義についてはここまでとし、型活用に目を向けましょう。 Steepを導入することでコーディング時の型補完が強力になります。

Steep Gemの導入手順もシンプルなので公式READMEをご参照ください。

kakariプロジェクトでは「型検査はしない」と割り切ったためSteepfileは以下の形で利用しています。

D = Steep::Diagnostic
target :app do
  signature 'sig'

  check 'app'

  # 型検査はせずに補完強化用途でのみSteepを利用する
  configure_code_diagnostics do |hash|
    D::Ruby::ALL.each do |error|
      hash[error] = nil
    end
  end

  # https://github.com/soutaro/steep/pull/800 の対応がリリースされたら↓に書き換えること
  # configure_code_diagnostics(D::Ruby.silent)
end

Steepが提供しているLSPを活用する手順はご利用のテキストエディタによって変わります。以下は一例です。

VSCode GitHub - soutaro/steep-vscode: VSCode extension for Steep
Sublime Text Language Servers - LSP for Sublime Text
(Neo)Vim coc.nvim

また、RubyMineに関してはSteepのLSPを必要とせずに自前でRBSを参照して便利にしているようです。

NeoVimにcoc.nvimとSteep LSPを組み込んで補完が強化されている様子

5. 便利Rake Taskを定義

最後に仕上げで日々の運用上便利なRake Taskを定義します。と言っても、pockeさんがRubyKaigi 2023で発表していたRake Taskをありがたく流用させていただきました。
後述しますが、一部アレンジをしています。

return unless Rails.env.development?

require 'rbs_rails/rake_task'

namespace :rbs do
  task setup: %i[clean collection rbs_rails:all]
  # prototype+subtractを活用したいところだが、自前の型定義が必要になるため保留中
  # task setup: %i[clean collection prototype rbs_rails:all subtract]

  task :clean do
    sh 'rm', '-rf', 'sig/rbs_rails/'
    sh 'rm', '-rf', 'sig/prototype/'
    sh 'rm', '-rf', '.gem_rbs_collection/'
  end

  task :collection do
    # lockファイルに定義されているバージョンに従わず最新の方情報を取得したいためinstallではなくupdateを利用している
    sh 'rbs', 'collection', 'update'
  end

  task :prototype do
    sh 'rbs', 'prototype', 'rb', '--out-dir=sig/prototype', '--base-dir=.', 'app'
  end

  task :subtract do
    sh 'rbs', 'subtract', '--write', 'sig/prototype', 'sig/rbs_rails'

    prototype_path = Rails.root.join('sig/prototype')
    rbs_rails_path = Rails.root.join('sig/rbs_rails')
    subtrahends = Rails.root.glob('sig/*')
                       .reject { |path| path == prototype_path || path == rbs_rails_path }
                       .map { |path| "--subtrahend=#{path}" }
    sh 'rbs', 'subtract', '--write', 'sig/prototype', 'sig/rbs_rails', *subtrahends
  end

  task :validate do
    sh 'rbs', '-Isig', 'validate', '--silent'
  end
end

RbsRails::RakeTask.new do |task|
  # If you want to avoid generating RBS for some classes, comment in it.
  # default: nil
  #
  # task.ignore_model_if = -> (klass) { klass == MyClass }

  # If you want to change the rake task namespace, comment in it.
  # default: :rbs_rails
  # task.name = :cool_rbs_rails

  # If you want to change where RBS Rails writes RBSs into, comment in it.
  # default: Rails.root / 'sig/rbs_rails'
  # task.signature_root_dir = Rails.root / 'my_sig/rbs_rails'
end

kakariプロジェクトは現在ここまで対応しています。いかがでしょうか、立派に「型導入」しているように見えます?が一つも自分で型を書いていません。

すごい勢いでRBS周りのエコシステムが便利になってきているおかげで、自分で型を書かずとも型の恩恵を受けることができるようになっています。ありがたい！

また、本導入方法のアピールポイントとして「型に興味がある人は型を活用でき、型に興味がない人にデメリットがない状態」となっていることが挙げられます。このレベルの型導入であれば負債になりませんし方針転換も容易です。

「型導入をしない理由」を考えるまでもなく「とりあえず型導入してみる」と気軽に試せるのではないでしょうか。

今後の展望

ここまで自慢げに型導入について解説しましたが、正直なところまだまだ入り口段階だと思っています。

型に対するチームの成熟度に沿って以下の取り組みについて継続してチャレンジしていきたいと考えています。

「rbs prototype( + subtract)」を活用して、独自クラス・メソッドの型のプロトタイプを自動生成

rbs prototypeにより、クラスやメソッドのI/F（引数情報なども含め）が定義されている型のプロトタイプを生成することで、上述の補完が更に便利になることが予想できます。

当初はここまで対応しようと考えていましたが、prototypeで生成した型が不十分でSteepでエラーが発生し今回は見送りました。実際のところこのエラー自体は一つ一つ解消すれば良いだけの話なのですが、「クラスやメソッド更新の都度rbs prototypeとsubtractを実行し、エラーが発生した場合は対処する」というフローを現段階のチームに組み込むのはハードルが高く感じられました。

僕自身RBS周りはまだ未熟なので過剰にビビっているだけかもしれませんが、今回は「意味のある形で、尚且つ普段の開発速度が低下することなく型を導入する」を目標にしていたため今回は見送ったという経緯です。

typeprofの活用

typeprofを活用するとrbs prototypeより詳細な型情報が自動生成されるため更なる型補完強化が望めます。

解析速度について現状（v1）は課題がありますが、v2で大きく改善されるとRubyKaigi 2023で発表されましね。とても楽しみです！

正直のところまだほとんど触れられていないため、Railsプロジェクトでの解析精度がどの程度か不明な状況です。型の目的を「型検査」ではなく「補完強化」に振り切っている現状は精度が完璧である必要はないため十分に実用段階かもしれません。

積極的に活用していこうと思います！

Gemの型定義追加を含むOSS貢献

ここまではひたすらRBS周辺OSSの恩恵を頂いているだけなので、私たちもRBS周辺の成長に貢献していくべきです。 gem_rbs_collectionの型定義更新やRBS,Steepなどのツール群への貢献は然り、 RBS Railsのような型自動生成ツールの開発にも興味があるのでチャンレンジしていきたいところです。（ActiveHash の型定義なんかもうまいこと自動生成したいですよね。）

また、今回のRBS導入とブログ執筆の最中にRBSの些細な不具合を見つけたのでIssue起票しました。

このような不具合だけでなくRBS導入のハードルを下げるための提案なども積極的にしていきたいと思っています。
まだまだRBS周辺は貢献できる余地が多く敷居が低い領域なので「OSS貢献」の文化をチームに浸透させる良い機会として精進していきます！

まとめ

以上、型導入の敷居を下げるための記事でした。

「型定義なし」と「型検査バリバリ組み込んでいる」の間の選択について理解し、「ちょっと弊プロジェクトにも型導入してみようかな」と思えてくれたら幸いです。

「小さく型導入してみて、チームが型に馴染んできたらもう一歩踏み込んでいく」

そんな形で型を徐々に浸透していけると良いのではないでしょうか。

参考記事

本ブログを執筆する際に多くの記事を参考にさせていただきました。紹介しきれませんが一部列挙します。

是非読者になってください！

メドピアでは一緒に働く仲間を募集しています。
ご応募をお待ちしております！

■募集ポジションはこちら

■エンジニア紹介ページはこちら