こんにちは、エンジニアリングオフィスのなかむら(@rh1011_)です。 このチームは以下に責任を持ち活動を行っています。 HRチーム、現場開発チームと密に連携しながらの採用活動（DevHR） 技術・組織カルチャー広報（DevRel） 社内エンゲージメント よろしければCTOの作成記事がありますのでご覧ください。 はじめに なぜ採用するのか hacomonoの魅力と、やるべきことの洗い出し ひたすら実施 ①テックブログ ②イベント企画、登壇 ③協力いただくエージェントとの信頼感の醸成 ④熱いスカウト ⑤候補者体験の向上 今後の課題 エンジニアリングオフィスとして おわりに 参考リンク 想定読者 スタートアップで採用に取り組んでいるエンジニア、エンジニアマネージャ、HR 話さないこと 採用マーケティングチャネル別の施策詳細 はじめに hacomonoはこの１年間でエンジニア、プロダクトデザイ

こんにちは、プラットフォームチーム所属のまこたすです。 昨今、様々な場で「モジュラーモノリスを導入した」という話を目にするようになってきました。弊社でも昨年からモジュラーモノリスの試験導入を進めており、社内でノウハウが徐々に溜まってきたため、今回 技術ブログ で なぜ導入したのかと知見の共有 をさせていただけたらと思います。 想定読者 モノリスなアプリケーションの分割を検討している Railsへのモジュラーモノリスの導入を検討している 話さないこと チーム体制がどうあるべきかという観点の話 以下アーキテクチャについての詳細 モノリスアーキテクチャ モジュラーアーキテクチャ 背景 今回「モジュラーモノリスを導入した」というタイトルですが、最初に検討・導入に至るまでの背景について触れたいと思います。 hacomonoという組織・サービスの成長 hacomonoというサービスはリリースから現在に

hacomonoでEMのよこちゃんです (@jikun) hacomonoは普段完全フルリモートで、開発チームは特に出社している人がほとんどいません。 オフィスが原宿にあるため、近場の人が気分転換に行ったりする程度です。 そうなると、やはり課題になるのがコミュニケーションです。 現在のところ開発チームでは半年に一度全員で集まろうと決めています。 今回は、2023/2/28に開発チーム総勢60名で原宿オフィスに集まって懇親目的の社内イベントを行ったので運営メンバーとして裏側をご紹介したいと思います。 開催した結果 控えめに言って大成功だったと思っています。 熱気と楽しさ溢れる会でした こちらの記事に写真など沢山ありますので是非ご覧ください。 note.com 頼りになりすぎる、運営メンバー/DevHRの方々/総務のまっきーさん/PRのともPさんに支えられ そして何より気の良すぎる開発メンバー

こんにちは、開発グループの和田（ニックネームはなつです）です。 普段は大阪からリモートで、hacomono のエンタープライズ領域（ = アドオン開発基盤周辺）を主に担当しております。 大手のお客様にシステム導入する際、Saas であっても個別の要件をいただくことは往々にしてあるかと思います。 hacomono ではプロダクトとしては対応しない場合でも、アドオンとして積極的に個別開発を行っており、その中でもよくある任意のページを組み込みたい、という要望を実現するためにとったアプローチを紹介できればと思います。 アプローチ 技術的な要件・前提条件 Vue2 / Nuxt2 ES6 クライアントサイドレンダリング 読み込み対象となるコンポーネントはビルド/デプロイ時点では不明であり、任意の URL が指定される 考えられるアプローチ CTO や Google 先生に助言をもらいつつ、マイクロフ

こんにちは、hacomonoの機能開発チームのたつです。 hacomonoでは機能開発チームのマネージメントや開発全体のこぼれ球を拾ったり、開発者体験を向上していくために施策を実施したり、プロダクト開発をしていたりといろいろしています。 今回は弊社CTOのまこさんが以前に発信した「チームの成長・カルチャーにコミットするエンジニアリングオフィスチーム立ち上げの話」の具体策として『開発チーム星取表』をみんなで作成しましたので、その紹介をしていきたいと思います！ して、開発チーム星取表とは？🤔 「星取表」だけでググりますと、相撲の星取表が一面を占めますので、「星取表 開発」と調べてみますと、各社さん星取表を作成しているのがわかります。 画像からも拾えるように、端的に言うと「メンバー各自のスキルマップ」です。 今回はその背景を兼ねて、どのようなツールで、どのように作っていったのかをご説明しようと

hacomonoで開発チームに所属しております、塩濱です。（社内では、はまちゃんと呼ばれております。@hcmn_hama） 最近はQAエンジニアとしてQAチームの全体管理〜自動化までをメインに動いています。 （絶賛一緒に自動化に取り組んでいただける方を募集中です！） 本記事は22年の年末（12月）でエンジニア→QAエンジニアに軸を置き換え動き始めてから1年が経過したので、その際に振り返ってみた内容となります。 1年前と変えたこと、変わったこと チーム構成 21年の12月、プロダクトの開発からQAエンジニアとして軸を置き換え、正社員のQAエンジニアが私1人、業務委託で参画していただいているQAエンジニアは3名で、チーム発足時は4名のチームでした。 それが現在は、正社員のQAエンジニアが私含めて3名、業務委託で参画していただいている方は全部で8名で、総勢11名のチームとなりました。 （11名全

hacomono スクール開発チームに所属するせっちゃん(森山)です。 各社でスクラムイベントを採用されていると思います。 弊チームでも採用しているのですが、運用する上で少しカスタマイズしているのでイベント毎に紹介し、参考いただければと思います。 要約 デイリースクラムは喋るコンテンツを増やした プランニングは2ptを使わない レトロスペクティブはブレスト形式も良さそう 実施しているイベントと概要 0. 前提 各イベントは下記時間で運用しています。 スプリントの期間は2週間 デイリースクラムは毎日30分 リファインメント、プランニングは毎週1時間 スプリントレビューは都度実施 レトロスペクティブは1スプリント中に1時間 1. デイリースクラム 弊チームでは毎朝に実施しているので、朝会とも呼んでいます。 毎朝各自のタスク進捗をチーム内で共有しつつ、見積もったポイントとのブレを確認しています。

プロダクト開発チームのまっつん(@pagu_o28)です。 hacomonoではお客様からの問い合わせや社内問い合わせはサポートチームが受けて回答する体制になっています。 基本的にサポートチーム側で解決できるものの、中には解決が難しい問い合わせも来たりします。 そういった場合に開発チーム側にエスカレーションする、というような運用になっています。 今回は開発チームの調査、回答までのリードタイムを測定する仕組みを作ってみたのでその話をしようと思います。 開発チームへのエスカレーションチケットの管理方法 Jira を使って管理しています。サポートチームが開発にエスカレーションが必要と判断したら調査用の Jira プロジェクトにチケットを切り、開発チームが調査に着手し、サポートチームへ回答する、という流れで運用・管理しています。 Jira の自動化を設定する なにかをトリガーに自動でなにかをする、

hacomono CTOのまこ(@macococo)です 今年最後のテックブログでは、2022年の hacomono の開発組織を振り返りたいと思います。 ちなみに昨年の振り返りはこちら。 開発組織の変化 2021年末の段階では、正社員が15名ほどの組織でした。当時の課題は、私自身が開発も担当しており、CTO という役割以上に開発チームのリーダーとして開発の中心に居たことと、私自身が開発に多くの時間を割けられずにボトルネックになってしまっていたことでした。2022年からはチームを分け、3月のB調達を経て採用が強化されたことで、チームもメンバーも大きく成長する年になりました。 (コードを書ける時間が減ったのは悲しいですが。。) 非常にありがたいことに、今年も多数の優秀かつバリュー体現の高いメンバーにJoinいただき、プロダクト組織全体で48名と約3倍の組織に成長しました。業務委託・アルバイト

最近ポケモンメザスタにハマっている、プロダクト開発チームのまっつん(@pagu_o28)です。 プロダクトの品質向上のために、コードカバレッジもテストコード自体の質も高い状態にしていきたいです。 hacomono のバックエンドは Ruby on Rails で、テストフレームワークは rspec です。今回はバックエンド側のコードカバレッジの測定について書きます。 1. カバレッジレポートを確認できる状態にする まずは現状の確認をしました。 simplecov を導入済みでしたが、何故かちゃんと計測できていない状態でした。 なぜ計測できていないのかを調査するところからはじめました。 SimpleCovのREADME を確認してみる よく読んでみると、下記の記述はアプリケーションのコードを require する前に呼んでおくこと！と書いてありました。 require 'simplecov'

こんにちは、hacomono のCTOのまこ(@macococo)です。 今年の7月から、開発組織のカルチャーに対して横断的にコミットする Engineering Office というチームを立ち上げました。3ヶ月ほど経過していくつか成果が出てきたので、この記事で紹介したいと思います。 Engineering Office とは？ 改めて Engineering Office とは、チームの成長・カルチャー・エンゲージメントにコミットするチームと定義しています。スタートアップによくある、プロダクトの PMF 達成のためにゴリゴリ機能開発をすすめるフェーズから、組織がスケールしていく中で、ただモノを作るだけでなくカルチャー醸成にもコミットしていくフェーズに切り替えていくために立ち上げたチームです。 まだこのチームに対して専任が付けられる体制ではないため、日頃から組織カルチャーに興味がありそう

フロントエンドのテックリードのみゅーとん(@_mew_ton)です。 弊社では新しいプロジェクトを立ち上げの際に、Nuxt3を採用しています。 このプロジェクトでは、APIコール部分の実装について、以下のようなルールを設けています。 ブラウザからは、 Nuxt3 の ServerRoutes (BFFサーバ) へアクセスする BFFサーバから、APIサーバへアクセスし必要な情報を取得する BFFサーバにて、ブラウザで表示するためのデータ構造に変換する (不要な情報を削ぎ落とす) このプロジェクトでE2Eテストを導入するためBFFサーバのモックを準備しました。 今回は、Nuxt3 の ServerRoutes 機能を利用してモックサーバを作る方法を紹介します！ TL;DR Nuxt3 は API の実装に server/api 配下にソースを配置する Nuxt3 が利用しているサーバエンジン

フロントエンドのテックリードのみゅーとん(@_mew_ton)です。 弊社では新しいプロジェクトを立ち上げの際に、Nuxt3を採用することにしました。 また、従来までのプロジェクトの反省点として、 Atomic Design を考慮して実装することにしました。 ただ、Atomic Design について調査していくと、Atomic Design の考え方をそのままディレクトリに落とし込んでいくのはどうやら悪手のようで、Google サジェストからも、いくつか失敗のケースが散見されました。 そこで、Nuxt3 のディレクトリ構成にマッチするような Atomic Design の構成を考えてみたので紹介します。 Atomic Design とは Atomic Design とは、パーツ単位でUIデザインを設計する手法です。 Atomic Design 自体は 5年以上前から提唱されている設計方

こんにちは、hacomono の工藤です。最近買って半年の車を擦ってしまい凹んでます。 少し間が空いてしまいましたが、2/17-18に実施された Developers Summit 2022 にスポンサー枠で弊社岩貞と共に登壇してきましたので、そのレポートを書きたいと思います。今年はデブサミ20周年ということで、その節目に初めて参加することができて嬉しく思っています。 event.shoeisha.jp セッションでお伝えしたかったこと タイトルは「フィットネスの未来を変える！顧客と伴走するバーティカルSaaSのプロダクト戦略の話」です。 このセッションで色々とお話させていただきましたが、一番伝えたかったことは "バーティカル SaaS の開発は面白い" です。 バーティカル SaaS の開発には顧客・業界理解が必要で、一般的にも開発難易度は高いと言われます。逆に言えばチャレンジしがいがあ