2024/07/01よりVP of CTO Officeとなったよこちゃん（@jikun）です。 hacomonoでは開発組織全体の横断課題に取り組んでましたが、今後はより経営課題を意識して行きたいと思っています。 技術的負債解消のための専門チームを作ろう！ hacomonoでは、元々イネーブルメントチームがあり、バックエンドのスペシャリストのiwazerさん（@iwazer）とフロントエンドのスペシャリストのみゅーとん（@_mew_ton）の2名体制でした。 しかし二人とも日々多くの差し込み依頼に忙殺され、また開発チームが忙しすぎるなどイネーブルメントで何とかしていくことの限界を感じていました。 Rails や Vueのバージョンアップが進まない パフォーマンス改善すべき箇所が多い リファクタしたいがテストコードが不足している 自動テストの実行に時間がかかり過ぎる Platform En

はじめに こんにちは。hacomono UX部エンジニアのyasuです。 今年の3月からUX部とリアーキテクチャ&イネーブルメント部が連携し、フロントエンドの開発基盤を刷新するために発足した新プロジェクトにおいて「ドラッカー風エクササイズ」と呼ばれるチームビルディングを実施したので、実施に至るまでの背景や成果などをお伝えしたいと思います。 ドラッカー風エクササイズとは？ 自分の強みを活かすための方法や時間の有効活用など、経営学者のピーター・ドラッカーの思想や理論をベースに『アジャイルサムライ』の筆者が提唱したチームビルディングの手法の一つです。 次の4つの質問に回答する形で相互理解を深め、メンバー間の期待値を明らかにします。 自分は何が得意なのか？ 自分はどうやって貢献するつもりか？ 自分が大切に思う価値は何か？ チームメンバーは自分にどんな成果を期待していると思うか？ 各質問の意図などは

こんにちは、QA部SETチームのモーリーこと森島です。 現在QA部のメンバーはhacomono社員が8名、業務委託が11名、アルバイトが1名とかなりの大所帯です。 半年前には半分強の人数でしたが、多くの方と縁があり現在の規模になりました。 また、QA部内の体制にも変化がありました。 いままでは、１つのQAチームとして特定の機能範囲の担当はいたものの専任ではなかったため、QA部全員で色々な機能のテストを実施していました。 現在は、プロダクトチームごとの専任QA体制となりQA部内でもプロダクトチームと同じ数だけチームが存在しています。 そのチームはそれぞれに朝会やふりかえりなどを実施しており QA部全体でも朝会をして情報共有などを密におこない、QA部全体で品質のサポートができるようにしています。 以前はリソースに応じてその時々でコミュニケーションを取る人が変わっていましたが チームに分かれたこ

こんにちは！QAチームSETエンジニアのモーリーこと森島です。 この度hacomonoでは3月から「オンラインカウンセリング」支援制度が始まりました。 オンラインカウンセリングとは専門知識やスキルを持ったカウンセラーとの対話によって、相談者が抱える悩みや困りごとを解決できるよう導くプロセスです。 支援制度の導入の背景として、hacomonoの「ウェルネス産業を、新次元へ。」※1 というミッション達成のため、社員に長期的に挑戦してほしく、起こりうる不安要素に対して会社が少しでも支援して、安心して業務に取り組んで欲しいという思いと、掲げるミッションをメンバー自身の人生においても達成してほしいという思いから導入に至ったそうです。 なんとこの支援制度、社員は費用負担なしかつ利用上限なしでオンラインカウンセリングを受けることができます。※2 この支援制度ではcotree様のオンラインカウンセリングサ

こんにちは、hacomonoのプロダクト開発本部のたつ（X）です。 前回は「hacomonoの機能開発チームのたつです」と自己紹介したのですが、組織も大きくなりまして「部」なんて言葉を使うようになりました。 さて本日のお話は、2024年に入って「プロダクトエンジニア」という役割を社内で定義・言語化しましたのでそのお話をしたいと思います。 以前にもこじこじが「プロダクトエンジニア」について記事を書いてくれています。 本日はその第2弾としてhacomonoの「プロダクトエンジニア」の定義とその誕生の経緯についてお話したいと思います。 と言っても何も新しい役割を定義しましたという話ではなく、今までも社内で活躍してくれていた人の特徴を言語化・再定義したというお話です。 なぜ「プロダクトエンジニア」という言葉を定義したのか？ 理由は4つあります。 組織が大きくなるにつれて、プロダクト開発エンジニアの

こんにちは！ 株式会社hacomonoの Engineering Office でアシスタントをしているみーこです。 ふだんは事務まわりの業務やこのテックブログの運営サポートなどをしています。 hacomonoはフルリモート企業。エンジニアも開発以外の部署も、ほぼ全員がフルリモートで働いています。 そこでふと、 hacomonoのエンジニア達はいったいどんな環境で仕事をしてるんだろう？🤔 と気になったので調べてみることにしました。 エンジニアにとってPCはもとよりキーボードやモニター、デスクは商売道具。 料理人にとっての包丁、野球選手にとってのバットやグローブのようなもの。 きっとこだわりのある人は多いはず…！ SRE部 いわちゃん (岩本) さっそくエンジニアらしいキーボードが登場 最初に登場するのはSRE部いわちゃんのデスク。手前が仕事用、奥がゲーム用だそうです。 せっかくなので本人

こんにちは！SETチームの塩濱です。 hacomonoではニックネーム文化なのではまちゃんと呼ばれております。 今回はhacomonoで活用しているmablのリリースされた機能を使ってみたシリーズ（今回が初めて😌）を書いてみようかと思います。 早速ですが今回使ってみた新機能は「Postmanからのインポート」です。 mablの記事も貼り付けておきますので気になる方はこちらもどうぞ。 https://help.mabl.com/hc/ja/articles/19078193969940-Postmanからのインポート なぜこちらの機能を紹介するかというと、hacomonoのmablの活用方法上、神機能だったのです。 順を追って説明します。 mablでの環境設定について hacomonoではmablの実行用環境が最大で7環境あります。 基本的にメインで使用しているのは、2環境となりますが こ

運用保守部のよこちゃん (@jikun) です。 最近、平日に長めのお休みを頂いて息子の小学校卒業記念として家族でUSJに行ってきました。 アトラクションの待ち時間についついSlack見てしまいましたが、みなさんが温かくサポートして仕事を進めてくれており本当に休みやすい環境に感謝しました！ 最終日は、USJ近くのホテルからあべのハルカス、道頓堀あたりを5時間ほどブラブラ探索しながら伊丹空港へ移動しましたが、この写真のようにお土産含めて家族全員分の荷物を1人で持つスタイルで頑張りました。 日々の運用保守業務で鍛えているパワー💪　をプライベートでも存分に発揮してまいりました。 Metadata lockとの闘い 2024/03 ver hacomonoはプロダクトが急成長していますと言って既に2-3年経っている気がしますが、 今も継続して急成長中です！ コードが増えるのはもちろんDBのテーブ

こんにちは、QA部SETチームのモーリーこと森島です！ SETチームではペアプロミング・モブプログラミングを週に２〜３回実施しており、イテレーション内に目標が確実に達成できるように取り組んでいます。 今回はその取り組みの事例とそれによりどんな効果を得られているかを紹介しようと思います。 はじめに（対象となる読者） SETではイテレーションの目標となるトピックに紐づくタスクをペアやモブで作業しています。 一般的にペア・モブプログラミングというと複数人でコーディングをする作業を指すと思います。 SETチームでは一般的なコーディングをすることもありますが、大半はコーディング以外の作業が多い状況です。 そのため今回は記事のタイトルの通りモブプログラミングの手法を活用した内容になりますので、一般的なモブプログラミングに対するプラクティスを期待されていた方はご注意ください。 一方で、コーディング以外の

こんにちは、hacomono QA部SETチームのモーリーこと森島です。 SETチームでは現在E2Eテスト自動化に積極的に取り組んでおり、その中でもmablで作成・実行する自動テスト作成を最も活用しております。 hacomonoでどのようにmablを活用しているかイマの状況をお伝えしたいと思います。 mabl運用状況 実行頻度 参考：１月の合計実行数 QA部では主に２週間に１度の定期リリースタイミングに合わせて、リグレッションテストを実施しています。 このリグレッションテストの位置づけは、機能テストが完了したあとリリース前にこれだけはインシデントが起きたら困るという部分に対して全体的に実施している最後の確認です。 リグレッションテストには手動テスト・自動テストがあり、自動テストはmablで実行しています。 自動テストの実行はイマはSETチームが担当しており、手動テストはQA部の各プロダクト

こんにちは、QA部SETチームのモーリーです。 hacomonoに入社して3月で5ヶ月目になります。 hacomonoではドキュメントツールとしてNotionを利用しています。 今回はhacomonoのNotionの使い方でいくつか課題を感じていたので 解決のために実行したことをシェアしようと思います。 記事の本題に進む前に、Notionで扱っている種類について触れておきます。 下記のように情報を分類したときに、今回はフロー情報にフォーカスして課題に取り組みました。 ストック情報 あとから何度も更新がされて活用する「蓄積される情報」です。 例：仕様書、マニュアル、等 フロー情報 その場限りで更新がされない「流れる情報」です。 例：議事録、メモ、等 hacomonoで感じたNotionの課題 hacomonoに入社して過ごしてみたところ、以下のような課題を感じていました。 階層化が進んでいて

どうもみゅーとんです. 小ネタです. 弊社は GitHub の hacomono-lib という organization にて, OSS を公開しているのですが, なんとなく作っているロジックがちゃんとメモリ解放されているかが気になったので, そのテストを書く方法を探りました. 概要 3 行でまとめ Node.js 実行時のオプションにて, ガベージコレクションを任意実行させる関数を有効化できる メモリ解放されているかどうかは WeakRef を利用すると確認できる Node.js 実行時のオプションを使って Vitest を実行できる ここで話題にしないこと メモリ管理 / ガベージコレクタについて Vitest などのテスト導入について 背景 冒頭に記載したとおりですが, OSS を作っていてメモリがちゃんと開放されているかどうかが気になった次第です. ライブラリのロジック内で, 複

どうもみゅーとんです. 最近パフォーマンス周りで問題をおこしかけてしまったので, パフォーマンスの劣化を抑制する方法を調べてみました. 概要 3 行でまとめ public repository であれば, CodSpeed を無料で利用できる main ブランチでのパフォーマンスを計測しておき, Pull Request で劣化したら警告してくれる CodSpeed から, 内部処理を詳細に追うことができる 前提知識 vitest でパフォーマンステストを行う構成ができていることが条件になります. 導入方法についてはこの記事を確認してください. techblog.hacomono.jp CodSpeed とは docs.codspeed.io なんて読むんでしょうか・・？私はコードスピードと呼んでいますが, コッドスピードのほうが正しそう・・？ GitHub Actions で実行した P

こんにちは。 開発本部 フィーチャー部 会計・決済グループでエンジニアをやっている ぺい です。 みなさん、PullRequest 作っていますか？ 本記事では、私が普段 PullRequest を作る中で、レビュアーにとってレビューしやすく読みやすくするために意識しているコミットの積み方の工夫についてお話しします。 ※ 私の主観が多く入っている点について、予めご了承ください。 前提 以下を、本記事の前提条件とします。 GitHub を利用している PullRequest は最終的に Squash and Merge でマージ先のブランチに取り込まれる 実装者の開発ストーリーを追体験できるようなコミットを積み重ねる 例として、Ruby on Rails を使って新しく API を追加するケースを考えてみます。User モデルがあるとして User を新規作成する API を実装する、としま

どうもみゅーとんです. 小ネタです. hacomonoは GitHub の hacomono-lib という organization にて, OSS を公開しているのですが, なんとなく作っているロジックが多重ループになっていて計算量が多そうだ, と思い, そのパフォーマンス計測を行うことにしました. 概要 3 行でまとめ Vitest には標準でベンチマークテストを行う仕組みがある ただし experimental (v1.2.x 時点) ベンチマークテストには tinybench を利用している ここで話題にしないこと 計算量の概念 パフォーマンス改善のためのコーディング 背景 インシデント未遂を引き起こしてしまいました. hacomono-lib で公開している OSS の json-origami にて, パッチバージョンアップとして, たった１行変更するだけのバグ修正を行いまし

はじめまして！hacomono インターン生の、インフラとウマと馬が大好きなかわにーと申します。お馬さんかわいい。 2022年6月に入社してから2年弱経ち、このタイミングでやってきたことの整理として振り返り記事を書いています。 hacomono のインターンに興味を持っていただける方の参考となれば幸いです。 （※編集部注：2024年1月現在、hacomono開発チームのインターンは募集停止しております。再開次第、hacomonoプロダクト公式Xなどでお知らせいたします！） hacomono に応募したきっかけ 大学に入学してから今まで、気の赴くままに趣味として低レイヤやインフラ技術を学んでいました。何か役に立つようなプロダクトを作るわけでもなく、ただ自分の好奇心に従って。 しかし、大学院修士1年の頃、早期選考、インターン….、就活早期化の波が押し寄せます。 趣味ばかりで実務経験のない私は、

あけおめ一発目です. フロントエンドテックリードやってるみゅーとんです. 年末年始はひたすら Unity と Blender で遊んでました. 弊プロジェクトのフロントエンドではもともと vue-i18n を導入しており, 後に多言語対応をサポートできるようにしていました. これを, サポートできるように見直そうとしたところだったのですが, 課題が多く見つかり, 書き直すことになりました. その際に見通しのよい書き方に直せたので, これを共有します. TL;DR 文言を引き当てるキーには, 表示する文言を設定すること なるべく 1文まとめて文言を作ること コーディング時に, そこに何が書いてあるかわかりやすくなった 前提 vue-i18n, nuxt-i18n の使い方は解説しません. 同様の仕組みであれば真似できる話です. 背景 元々以下のように単語ごとに翻訳し, 文字列結合するようなロ

こちらの記事はhacomono Advent Calendar 2023の25日目の記事です hacomono CTOのまこ(@macococo)です。 子供へのサンタ業を済ませてこの記事を書いています。今年のプレゼントは「マイニンテンドーストア」で買える「えらべるプレゼントセット」にしました。よく考えたらサンタ = ニンテンドーアカウントを持ってるとある人物と気付かれるかもしれませんが触れずに押し通そうと思います。 さて、今年最後のテックブログとして、2023年の hacomono のプロダクト組織を振り返りたいと思います。ちなみに昨年の振り返りはこちらです。 組織の成長 hacomono のプロダクト組織の社員数は2022年末で49名ほど、当時は下の組織図で説明していました。プロダクト開発を行っている4チーム + IoT チームと、それを支えたり協業する各チームという構成です。 現在は

はじめに こんにちは、hacomono SETチームのモーリーです。 こちらはmabl Advent Calendar 2023 20日目の記事です。 hacomonoではリグレッションテストをmablで自動化しており、mablのテスト数は200にも届きそうな状態です。この記事では、新しくhacomono SETチームに参画した私が、mablでリグレッションテストの自動化に取り組む過程で助かったmablの運用ガイドラインについてご紹介します。 hacomonoのmabl関連資料の紹介 hacomonoでは下記のmabl資料を用意しており、新しいメンバーは資料を読み進めながらキャッチアップと実際にテストを作成するようにしています。 mabl運用ガイドライン 1. 自動テスト作成環境の構築方法 開発環境の構築方法 自動テスト用初期データのインポート方法 ローカル実行のやり方 2. 運用ガイドラ

こちらの記事はhacomono Advent Calendar 2023の14日目の記事です はじめに 開発本部 フィーチャーグループのこじこじ です。 プロダクトエンジニアという職種を聞いたことがあるでしょうか？ 先日、Product Engineer Night というプロダクト志向を持つエンジニアのミートアップイベントの第一回に参加してきました。 自分にとって単にフルスタックエンジニアとかという言葉では、微妙にしっくり来なかった部分がきれいにハマった感覚があり、思った事を書いてみます。 プロダクトエンジニアとは Product Engineer Nightを主催してくださった株式会社アセンドのCTO、丹羽さんの記事 がとても良くまとめられててわかりやすいです。(こちらを読めば正直この記事は読まなくてもいいくらい…) 同じ事を書いても仕方がないので、詳細は省きますが、簡単に言うと「プロ