こんにちは、趣味でコーポレートエンジニアをやっていますyamashuです。 タイトルの通りかなり昔の話になるのですが、勤怠打刻の課題解決についてそういえば社外へ向かってアウトプットしていなかったなと思い、この度したためている次第です。 社外と接点が多い営業の社員が弊社での打刻の方法をたまたまお話したりして、その話を聞いた会社様から「話を聞かせてほしい」とヒアリングをいただくことも最近まで何度かありました。 そのため、もしかしたら同じ悩みに直面している方がいらっしゃるかもしれないので、1つの解決策としてやったことを書いておこうと思います。 課題 🤔 勤怠管理SaaS（弊社だとAKASHI）を使っているが、打刻（出勤、退勤）しても本人以外にはその結果が見えない、わからない。 そのため、コミュニケーションツールのSlackでも「出勤したよ〜」となにかしらの報告がチームメンバーに対して必要となる

SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre

SmartHRでは開発にRuby on Railsを広く採用しています。 今日は負債解消のために、開発しているサービスでRailsのモデル名をすべて変更した話を紹介します。 既存のモデル構造のつらみ 私達が開発しているサービスでは、モデルの親子構造が分かりやすいということで、モデルをネストした構造にしていました。 例えば、 User に紐づくプロフィール画像 User::ProfileImage は、 app/models/user/profile_image.rb に配置する具合です。 パッと見の構造が分かりやすいのですが、時が経つにつれて次のようなつらさが顕在化してきました。 Railsの規約(推奨ルールのようなもの)に則っていないので、関連定義が冗長になる テーブル名が長くなる。 外部キーや関連名が長くなる。 関連名と外部キー名が一致せず、カラムを呼び出したいときにDB定義を見ないと

こんにちは、プロダクトデザイングループの@kgsiです。 SmartHRでは、書き方の誤りを検知・修正してくれるtextlintというOSS（オープンソースソフトウェア）をプロダクト開発に導入しています。textlint導入の背景については、既に公開済みの関連記事を参照してください。 shanaiho.smarthr.co.jp 今回は、textlintとその開発者を支援するために、GitHub Sponsorsを通してOSSスポンサーになったことを公式に報告します。 寄付をした背景 現状、SmartHRではtextlintと独自のルールを含むプリセット（textlint-rule-preset-smarthr）を作成し、主にプロダクトのCI環境や、ドキュメントの校正に利用しています。 また、オープン社内報や登壇で「textlintのルールプリセットを作って、プロダクト開発で利用している」

こんにちは！CTO の芹澤です。 前回投稿した「エンジニア採用が再びピンチ！ 窮地を脱すべく改善施策の企画会議をしました」という記事ですが、おかげさまで多くの反響をいただけました。 みなさまから寄せられた意見は一部 saiyo-tasukete プロジェクトにも反映させておりますので、引き続きこちらも楽しみにお待ちいただければと思います。 さて、この投稿はそんな saiyo-tasukete プロジェクトに起票された「CTO からの大切なお知らせ」というチケットを元に書いています。 荘厳なチケットタイトルではありますが、お伝えすることは採用目標の具体的な内訳とその根拠についてです。 「採用がピンチです！」とだけお伝えしても、「どれくらい採用するつもりなのか？」とか「退職が相次いでいるのか？」といった点をクリアにしないと、安心してご応募いただくことは難しいかと思います。 なので、今回はその辺

俺だ、kinoppydだ。今日はお前にSmartHRで働くということはどんな感じなのかを伝えに来た。 このエントリは、なにか悪い力によって書かれました。 ただしいエントリは下のリンクを参照して下さい。 tech.smarthr.jp SmartHRという会社 社会の役に立つものを作っている。そういう認識をしておけばだいたい間違っていない。 紙、好きか？　俺は好きだ。紙の質感は指に心地良いし、何より紙にはだいたい有益な情報が書いてある。俺は情報も好きだ。 だがしかし、それが年末調整や入社手続きなどの書類になると、話は別だ。俺は途端に紙が大嫌いになる。 何故か。必要ないからだ。必要ないだろ？　今の時代、政府だっていーがぶとか、でじたるとらんすふぉーめーしょんとかいうやつで、紙じゃなくても手続きできるようになってるんだ。 ペーパーレス。最高じゃないか。俺は紙が好きではあるが、紙を右から左に送った

SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。