ESM アジャイル事業部 開発者ブログ

永和システムマネジメント アジャイル事業部の開発者ブログです。

Rails / OSS パッチ会 2026年1月 (オンライン開催) のお知らせ

2026年1月の Rails / OSS パッチ会を 1月28日(水)に Discord でオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。

会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です。

discord.gg

先月リリースされた Ruby 4.0 や、4月に開催される RubyKaigi 2026 の話題などあるかもしれません。

これからパッチ会に参加してみたいという方、OSS 開発者間の会話に興味があるので聞いてみたいという方もお気軽にどうぞ。


永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

RailsTokyo #3 で永和システムマネジメントの maimu が発表します!

こんにちは!アジャイル事業部の maimu です。

2月19日に開催されるRailsTokyo #3 で「once-campfire のコードリーディングのすゝめ」というタイトルで発表をします。

https://railstokyo.connpass.com/event/378921/railstokyo.connpass.com

私はしんめ.rb というコミュニティを運営していて、現在は once-campfire のコードリーディングに取り組んでいます。

github.com

once-campfire は読めば読むほど学びが詰まっていて、Rails の良さや面白さを実感しています。コミュニティ内でじっくり時間をかけて読んでいるため、そこで得た知見を当日発表したいと考えています。

具体的には、

  • コードを読み進める際の準備
  • 読み進める際に一緒に目を通すとさらに面白くなる関連資料の紹介
  • 特徴的な実装箇所の紹介
  • 学びになった実装箇所の紹介

の構成を考えています。

ご都合が合う方は当日ぜひ会場でお会いできればと思います! よろしくお願いいたします。


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

自分のためにシーケンス図を書く

こんにちは!アジャイル事業部の maimu です。

私はアジャイル事業部でエンジニアとして働き始めて3年目になります。1年目と比べてできることが増えてきたと感じることもあれば、開発を進める上でなかなか成長を実感できない課題もいくつかある状況でした。

  • 機能開発をするにあたって自分が理解できている部分から先回りして手をつけてしまう
  • 最終的なゴールが曖昧な状態で実装を始めてしまう
  • 開発中に詰まった際に、具体的に分からない箇所を自分自身が把握できていない

などです。 これらの課題は1年目の頃からあったのですが、Ruby や Rails で開発をすることにある程度慣れてきた2年目からより強く実感するようになりました。当初は経験を積んでいけば自然と課題感も薄まるのではと思っていたのですが、どうやらそうではないということに2年目途中で気がつきました。

どうすればこの課題を解消していくことができるのか考えて、Ruby や Rails の基本を学び直してみたり、個人開発をやってみたり、良さそうに思ったことは色々試したのですが、課題は残ったままでした。

やはり時間がかかるものなのかーと思い始めていた矢先、手応えを感じた方法が「自分のためにシーケンス図を書く」でした。

分からないものは図も書けない

きっかけはプロジェクトの先輩から機能を開発する前にシーケンス図を書いてみようと言われたことでした。それまでの私はシーケンス図はドキュメントに添付されているのを見たりする程度で自分で一から書いたことはありませんでした。

マーメイド記法で初めて自分で書いたシーケンス図は関連するレイヤーが抜け落ちていて、処理の流れも曖昧になっていました。ですが、これが自分の中では小さな手応えを感じた瞬間でした。

「図に書き表せなかったことが自分が分かっていないこと」だと気がつくことができ、シーケンス図の中で流れの辻褄が合わない部分や必要なレイヤーを挙げられているかなどを整理していくことで、自分の頭の中で絡まり合っていた長年の課題感がほぐれていく感じがありました。

自分のために書く

以前の私はシーケンス図は完成している機能に対して説明用の記録として書くものと思っている節がありました。ですが、図を書くことに手応えを感じてからは、外部への記録用ではなく自分のために図を書く時間をとっています。

こちらは私の自作ブログ用に書いたシーケンス図の例です。

Rails と Active Storage が同じ粒度で並んでしまっている気になりはあるものの、まずは自分の頭の中にある流れを図で表すことを優先しています。より細かく書き加えたいことがある場合は該当箇所を新たに取り出して別の図を書いたりしています。 下の図は全体の流れを書いた後に、フロントエンドとRails、Active Storageの繋がりが曖昧だったため、新たに書き出した例です。

どこまで細かく書くかなどのルールは決めてなく、自分がもっと整理しておきたいと思う部分は状況に応じてどんどん書いています。また、書いたシーケンス図は手元に残しておいて、実装中に迷子になりそうになったら見直したり、新たに気づいたことを書き加えたり修正したりしながら使っています。

シーケンス図を書くようになって良かったこと

シーケンス図を書くようになって、最初に挙げた私の課題感に対してどうすればいいのか分からない状態からステップを踏みながら乗り越えていけそうな実感が持てるようになりました。

図を書くようになって良かったことはたくさんあります。

まず、処理の流れの全体を掴むことができるため、ゴールが曖昧だったり自分が分かっている部分から実装を始めて、流れの先回りをしてしまうということがなくなってきました。流れに沿って実装ができるとリズムに乗れているというか、実装の確認もやりやすくなっていると思います。

また、図を書くことで自分が分かっていない部分を認識する助けとなり、そこから必要なことを調べたりする手掛かりを得られるようになりました。自分一人では整理しきれない場合は、書き出した図をもとに先輩に相談して会話をすることもでき、コミュニケーションも取りやすくなったと実感しています。

まとめ

記事の最初に挙げた課題感はエンジニア歴2〜3年目ごろの方は一度は感じたことがあるのではないでしょうか? 課題に対するアプローチは人によって様々だと思いますが、私の場合は図を書くということが合っていたなと感じています。

こちらの記事が同じ課題感を抱えている方の参考になれば嬉しいです。


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

【入社エントリ】入社後3ヶ月の新人が感じた永和システムマネジメントの素敵なところ

はじめに

はじめまして。2025年10月に中途入社したham-capと申します。今回は、永和システムマネジメントに入社したばかりの私が、この3ヶ月間で感じたことについて書いていきます。

自己紹介

前職は大学の事務職員として、主に総務系の業務に従事していました。あるとき、職場内で業務効率化の機運が高まったことをきっかけにプログラミングに興味を持ち、フィヨルドブートキャンプというプログラミングスクールでの学習を経て、永和システムマネジメントに入社しました。

bootcamp.fjord.jp

入社後に感じた永和の素敵なところ

物事を良くしていこうという雰囲気がある

抽象的な表現になってしまいますが、常に物事を良くしていこうという雰囲気が社内に漂っているなと感じています。それは技術的な部分に限った話ではなく、事業部内の制度やイベントの企画、Slackチャンネルの細かい運用方法に至るまで、組織運営という面においても事業部内のメンバー間で活発に意見交換が行われています。些細なことであっても真剣に改善策を考え、それを実行する文化が根付いているのだと感じます。

コミュニケーションを大切にしている

私の所属するアジャイル事業部はメンバー全員がリモート勤務ということもあり、オンラインコミュニケーションにおける課題を解決するための取り組みが積極的に行われています。

例えば、2025年12月に開催された北陸Ruby会議01には、私も含めて10名以上のメンバーが参加したのですが、その前日にスケジュールを合わせてオフラインの社内イベントが開催されました。各自が業務を通じて感じている課題や事業部の今後の取り組みについて、業務内外におけるAI活用法についてなど、普段はなかなか深い議論を交わしにくいトピックについてじっくりと話し合う機会となり、オフラインで顔を合わせることのメリットを感じることができました。その時の詳しい様子は当ブログ内の以下の記事でご覧いただけますので、ご興味のある方は是非ご一読ください。

blog.agile.esm.co.jp

その他にも、上司やメンター(先輩社員)との1on1が定期的に実施されていたり、月に一度、オンライン上に全員で集まる「みんなの時間」という会を開催することで、最低でも月に一回は社内メンバー同士が話せる機会を設けるなど、コミュニケーションを非常に大切にしています。

ものづくりが好きな方が多い

永和は技術が好きな方が多く在籍されている会社というイメージを入社前から持っていました。もちろんそれも間違いではなく、技術に真摯に向き合っている方ばかりなのですが、個人的には「自分の手を動かして何かを作ることが好きな方が多い」と言った方が実態に近いかもしれないと思うようになりました。というのも、プレゼンツールを自作してイベントで登壇したり、エディタを自作したりする先輩社員を入社後3ヶ月という短期間のうちに立て続けに目の当たりにしたからです。普段の業務とは別に、自分の興味関心に従って何かを作り出している姿が本当に素敵だなと感じています。

blog.agile.esm.co.jp

今後の自分の目標について

目下の目標は、先輩方の背中を見ながら業務に取り組み、お客様に価値を提供できるようになることです。加えて、上記のような永和の素敵な部分に触れたことで、技術以外のソフトスキルのレベルアップも図りつつ、一人の開発者として自分の作りたいものをきちんと形にしていけるようになりたいという思いも強くなってきました。全てを一度に叶えるのは難しいですが、自分は非常に恵まれた環境でお仕事をさせていただけているなと感じているので、それを無駄にすることなく着実に成長していきたいと思います。

今後ともよろしくお願いいたします!


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

北陸Ruby会議01で登壇しました&個人的な話

こんにちは、平田です。

普段はマネージャとして、事業部運営に関するいろいろを担当しています。

この記事は、ESM Advent Calendar 2025 最終日の記事です。

少し前になりますが、北陸Ruby会議01で「Ruby受託事業マネジメントの10年」というタイトルで登壇しました。

speakerdeck.com

当日の話だけでしか伝えなかった部分も多いので、スライドを読んでもあまり伝わらないこともあるとは思いますが、三行でまとめると、

  • Ruby、Railsがビジネスで使われるようになってきた歴史と一緒に歩んできたよ
  • 受託開発という文脈で起こる様々な出来事に対処してきたことの紹介
  • 今後、コミュニティの外でも力を発揮していきたいという意思表明

です。 スライドではさらっとしか触れていませんが、RubyKaigiのRubyスポンサーを眺めることで歴史を思い出すことができるというアイデアはちょっとウケていたようなので、長く業界にいらっしゃる方は試してみてください! 現地では、ESMのことを知ってくれている方がほとんどで、温かい雰囲気の中お話させていただいて、大変ありがたかったです。

最後にこの登壇で伝えきれなかった個人的な話を書きたいと思います。 内部を知っている人がよく見たら気がつくと思うのですが、ここで発表したことの多くは僕がオリジナルでアイデアを出したものではありません。周囲の人たちの意見を聞いて、それを実行したり、お手伝いしたものが多いです。僕個人が「こうであるべき」というこだわりを持ってリーダーシップを発揮するタイプの人間ではなく、調整型の人間だからというのが理由です。 組織のマネージャとしてそれで良いのかということはすごく悩みが多かったのですが、10年以上続けていく中で、最近ではこれが自分のスタイルなんだという割り切りができるようになってきたと感じています。

そもそも、要件定義担当だった時代から、人と話をすることが大好きでした。「人はそもそも善良である」というTOCの原則がすごく好きで、ただの愚痴や不満のように悪く見えるものであっても、それはその人の本心から出ているものなので、何かしらの制約を表現していると捉えるようにしています。(そして、それは解決可能であると信じる)

上司や同僚には恵まれていますが、お客様やコミュニティの皆さんからもいろいろなインスピレーションを得ています。最近、アジャイルコミュニティにはご無沙汰していますが、来年はもう少し復活しようかなと考えています。

2026年もよろしくお願いします!


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。 こんなマネージャの話を聞いてみたいというだけの方も、カジュアル面談フォームからお申し込みください!

agile.esm.co.jp

北陸Ruby会議01に参加しました

はじめに

こんにちは、@wai-doi です。

2025年12月6日(土)に金沢で開催された『北陸Ruby会議01』に参加してきました。

regional.rubykaigi.org

福井県に本社を置く永和システムマネジメントはイベントスポンサーとして協賛しており、アジャイル事業部からは3名の登壇者を含めて11名のメンバーが参加しました。

blog.agile.esm.co.jp

会場

会場は石川県立図書館で行われました。テレビなどでこの場所は知ってはいましたが初めて訪れることができました。オープニングセッションの1時間くらい前に到着して館内を見て回りましたが、ドームのように広くて圧巻でした。座れる場所が至る所にあり、過ごしやすそうで、近くにあれば通ってみたいなと思いました。

石川県立図書館

セッション

スポンサーセッションでは弊社も @fugakkbn から、社内でやっているコミュニケーションを取るための取り組みを紹介しました。弊社を知っている方を聞いたときに、参加されたかたほぼ弊社をご存知だったので嬉しく思いました。

@fugakkbn のスポンサーセッションの様子

オープニングキーノートは日本Rubyの会の高橋会長の「日本Rubyの会の構造と実行とあと何か」でした。日本Rubyの会の成り立ちなど貴重な話を聞けました。中でもRubyは他の言語より人口が少ないので、特定分野で強みを持つことで存在感が出せる、という話が印象的でした。自分もRuby製の何かで強みを持てるようになりたいと思いました。

@taiju による「Ruby DSLでMinecraftを改造できるようにする」は印象的でした。マインクラフト上で作成されたスライドで発表し、最後に北陸Ruby会議01のロゴをクラフトするデモは見ていてとても楽しかったです。他にはないマインクラフトを存分に活用したパフォーマンスのようなトークでした。

@taiju のトークの様子

@m_pixyによる「Ruby受託事業 マネジメントの10年 永和システムマネジメント」のトークがありました。アジャイル事業部の変遷を発表されていて、Rubyコミュニティの関わりで成り立ってきているのだなと思いました。勤務先が全RubyKaigiで唯一毎回スポンサーをしている企業だということを歴史を感じました。

@m_pixy のトークの様子

LTでは@koicによる「STYLE」のLTトークがありました。Rubyで書き手によって好みが異なる代表的なものを挙げられていて、たしかに人によって別れる書き方だなあと思いました。最後に紹介されていたPreset機能がRuboCopに追加されれば、RuboCopを簡単に導入したいがデフォルトのルールは厳しいと思ってた人が助かりそうだなと思いました。

@koic のトークの様子

懇親会

夜は懇親会に参加しまして、金沢の美味しいご飯を食べました。 LTで「Rubyで楽して タスクを書きたい!」を発表された ahogappa さんと席が隣だったので、LTの内容と現状のRake タスクの課題感などお聞きしたりできたのがありがたかったです。ありがとうございました。

まとめ

今回は北陸Ruby会議01 に参加してきました。私は初めて地域Ruby会議に参加しましたが、内容が技術寄りでないトークもあることで、RubyKaigiなどのカンファレンスでは得られない知見を得ることができたのが良かったです。

スタッフのみなさん、初開催ということで準備など大変なところあったと思いますが、お疲れ様でした。ありがとうございました。

前日には金沢で社内イベントも開催したので、こちらの記事もご覧ください。

blog.agile.esm.co.jp


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

Mui(無為)—— Ruby製VimライクTUIエディタ

この記事はESM Advent Calendar 2025の1日目の記事です。

はじめに

こんにちは、S.H.です。

普段はVimを使ってお仕事をしていたのですが、使っていく中で「Vimの設定を書くこと」に課題を感じていました。 そうした中で「書きなれたRubyで設定を書けるエディタがあると良いのでは?」と考え、Mui(無為)という名前のVimライクな自作エディタを作り始めました。

この記事では、その自作エディタを作るまでの経緯や機能の紹介をします。

過去のエディタ変遷

元々はCを勉強していたため、Visual Studioを使っていました。 その後、UIなどが近いVSCodeをエディタとして使い始めましたが、使いにくさを感じる場面が出てきました。

僕はGUIよりもターミナル上でGitのコマンドを実行することが多く、その方がスムーズにブランチの切り替えなどができるため、VSCodeは僕の開発スタイルにはマッチしていませんでした。

また、VSCodeではCRubyのソースコードのインデントが崩れることも多く、その点でも扱いにくさを感じていました。

そうした中で、ターミナル内でのコマンド操作もしやすく、CRubyのインデントも崩れないVimを使うと良いのではと考え、Vimにコンバートしました。

Vimに移行してからはかなり快適になった一方で、使い続ける中でいくつか課題を感じるようになりました。

Vimを使い続けて感じた課題

基本的に、Vimでコードを書くこと自体には満足していましたが、設定ファイルを書くことには難しさを感じていました。

最初のころはvim scriptで設定を書いていましたが、あるタイミングで導入したプラグインがVim9 Scriptにしか対応しておらず、利用するにあたって設定ファイルをVim9 Scriptに置き換える必要がありました。 そのときは大きなトラブルなく移行できたものの、その後に追加しようとしたプラグインの中にはVim9 Scriptに対応していないものもあり、どうしたものかと悩む場面も出てきました。

また、プラグインを使ってリポジトリ単位でVimのキーマップを定義し、テストやリンターの実行をNormalモードからできるようにしていましたが、そのリポジトリごとの設定はvim scriptで書く必要がありました。

そのため、Vim9 Scriptとvim scriptの二つのスクリプトで設定を書く必要があり、この点も課題だと感じていました。

Ruby製エディタという前例:Textbringer

そういった課題を感じる中で、「Rubyで設定が書けるVimライクなエディタがあればいいのでは?」と考えるようになりました。 RubyでDSLとして設定を書く手法は、さまざまなgemでも使われていますし、設定を書く体験としても案外相性が良いのではないかと思いました。

そこで参考にしたのが、Textbringerです。TextbringerはRuby製のエディタとして長く開発されており、 実装にあたって参考になる情報があるのではないかと考え、コードを読み始めました。

github.com

実装を軽く読んでみたところ、依存関係としてcursesを使い、ターミナル上でのキー入力や画面描画を扱っていることがわかりました。 そのため、最低限cursesを経由してキー入力や描画を扱えれば、RubyでもTUIエディタが実装できそうだという感触を得ました。

VimライクTUIエディタ「Mui(無為)」

そうして今、僕が作っているのが Mui(無為)という名前の VimライクなTUIエディタです。 名前の由来は老荘思想における「無為自然」で、設定や操作を強く意識することなく、コードを書く人が自然体でコードに向き合えるエディタでありたいと考えています。

自作エディタの画面。画面中央を起点に左右にバッファがそれぞれ表示されており、そのバッファの中にRubyのコードがシンタックスハイライトされて表示されている

github.com

:e でファイルをバッファとして開くといった基本的なコマンドから、タブやシンタックスハイライトなど、コードを書くうえで最低限あると便利な機能を一通り実装しています。

実装前の仕様検討にはChatGPTを使い、実装はClaude Codeに任せつつ、テストが書きにくくなっている部分については僕が書き直す、といった形で開発を進めています。

また、設定ファイルはRuby DSLとして、以下のように自然な形で書けます。

# カラースキームの設定
Mui.set :colorscheme, "mui"

# シンタックスハイライトの有効化
Mui.set :syntax, true

# インデント設定
Mui.set :shiftwidth, 2
Mui.set :expandtab, true
Mui.set :tabstop, 8

# Gitプラグイン、バージョンを指定することもできる
Mui.use "mui-git", "0.2.0"

# fzfプラグイン
Mui.use "mui-fzf"

# LSPプラグイン
Mui.use "mui-lsp", "0.2.0"

Mui.lsp do
  # LSPプラグインでは Ruby LSP などのLSPをデフォルトでサポートしている
  # デフォルトでサポートしているものに関しては use :ruby_lsp で利用できる
  use :ruby_lsp
end

# ファイルの保存のキーマップ
Mui.keymap :normal, "<Leader>w" do |ctx|
  ctx.editor.execute_command("w")
end

# バッファを閉じるキーマップ
Mui.keymap :normal, "<Leader>q" do |ctx|
  ctx.editor.execute_command("q")
end

また、TUIエディタは内部状態が複雑になりやすいため、E2Eテストを追加し、実際の操作に近い形で動作を検証しています。 例えば、以下のようにファイルの編集から保存までが正しく行えるかをテストしています。

  def test_basic_file_editing
    # Scenario: Open existing file -> Edit -> Save
    Tempfile.create(["test", ".txt"]) do |f|
      f.write("Hello\nWorld")
      f.flush

      runner = ScriptRunner.new(f.path)

      runner
        .type("j")         # Move to line 2
        .assert_cursor(1, 0)
        .type("llll")      # Move toward end of line (4 times)
        .type("a")         # Append mode
        .type("!")         # Add "!"
        .type("<Esc>")     # Normal mode
        .assert_mode(Mui::Mode::NORMAL)
        .assert_line(1, "World!")
        .type(":w<Enter>") # Save
        .assert_message_contains("written")
        .assert_modified(false)

      # Verify file was actually saved
      assert_equal "Hello\nWorld!\n", File.read(f.path)
    end
  end

このE2Eテストのおかげで、新機能の追加や既存コードのリファクタリング時にも、リグレッションが起きていないことを確認しながら開発を進められています。

おわりに

現在は、お仕事やOSSのパッチを書く際には基本的にMui(無為)を使っており、たまにバグを踏むことはあるものの、大きな不満なく、楽しくコードを書けています。

今後は、見つけたバグの修正や、より便利に使えるプラグインの開発などを進めていければと思っています。

興味を持った方は、ぜひ使ってみてもらえると嬉しいです。


永和システムマネジメントでは、Rubyやアジャイルソフトウェア開発、そして自作エディタの開発を通じて、コミュニティとともに成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp