ENTRY

歴史に残る
模範的な
ソフトウェア

つくろう

SmartHRの特長

古くて巨大、アナログな
行政手続きをハックする事業

社会保障制度は、私たちが安心して生活するために欠かせないすばらしい制度です。
一方で制度に係る手続きの中には大量の申請書類に何度も同じような内容を手書きし、ハンコを押して、お役所に持っていく、という処理が未だに広く行われています。
私たちはSmartHRの開発を通じ、このアナログな領域を改革し、人々がより生産的な働き方が実現できるようサポートすることによって社会に貢献していきます。

開発を通じて

対等な立場で仕様を磨く

非エンジニアのプロダクトマネージャー(人事労務の専門家)が企画を主導しており、エンジニアはプロダクトマネージャーをエンジニアリングで支えています。
営業やサポートで集まったユーザーの課題から企画が練られ、その企画案をプロダクトマネージャーとエンジニアが対等な立場で議論し、みなで仕様を磨き上げていきます。
「トップダウンで仕様が降りてきてそれを作るだけ」ということはほぼなく、仕様策定から関わりたい方にとっては、とても楽しめる環境です。

エンジニアのフロー状態を

集中できる開発フロー

開発はスクラムを取り入れており、基本的に週1回・約半日を使ったミーティングの中で工数見積もりや詳細な仕様設計まで行います。
その約半日の中で各タスクをエンジニア同士で議論し、着手可否を判断、各人の納得感のある状態にまで落とし込むことで、集中して開発をスタートできるようにしています。
コンテキストスイッチを可能な限り減らして課題に集中する時間を確保するために、必要なミーティングはまとめて開催しています。

開発を通じて
テクノロジースタック
SmartHR ではエッジの効いた最新の技術よりは、どちらかと言えばある程度枯れた保守性、運用性にフォーカスした技術選定を行う傾向が強いです。
開発
開発
開発支援
開発支援
AWSスタック
AWSスタック
サーバ監視
サーバ監視
  • フレームワーク: Ruby on Rails 5
  • フロントエンド: ES2015, Sass , webpack
  • リポジトリ: GitHub
  • 開発環境: Vagrant
  • AWSスタック: Elastic Beanstalk, RDS, ElastiCache, Route53, VPC
  • CI: CircleCI
  • サーバ監視: New Relic, Sentry, Mackerel
  • 情報共有: Qiita:Team
  • コミュニケーション: Slack
  • タスク管理: JIRA
investment01 社内ハッカソンの風景

積極的な技術への投資

基本に忠実である一方で、技術への投資は惜しまず、技術書籍の購入、勉強会やカンファレンスへの参加を奨励し、社内ハッカソンの実施も行っています。
RubyKaigiなどへの参加は業務扱いで、参加費・交通費・宿泊費などは会社が負担します。

investment01 investment01

OSSの公開で
コミュニティに還元

SmartHRは多くのOSSによって支えられています。
そして私たちもまた、開発の途中で生まれた再利用可能なモジュールをOSSとして公開しています。
OSSの公開やコントリビュートだけではなく、勉強会の開催、RubyKaigi 等へのイベントへのスポンサー活動を通じ、積極的にコミュニティへ還元しています。

kiji

大事にしている働き方

インタビュー

FAQ

  • 今後のプロダクトの方針は?

    SmartHR で人事労務の分野をより便利にしていくことを何よりも重視しています。新規プロダクトもいくつか立ち上げていますが、いずれも人事労務もしくはそれにほど近い分野における開発となっています。
    また、SmartHR にはユーザー企業さんの貴重なデータが蓄積されています。管理者さんだけでなく、従業員さんからのアクセスもあります。これらの資産を活用し、将来的には人事分野でのプラットフォームになることを目指しています。

  • 評価はどうやってるの?

    半期ごとにエンジニアチーム全員でチームミッションを考え、それを個人のミッションに落とし込んでいます。
    ミッションに対して取り組んだことのすり合わせは、エンジニアリーダーとの 1on1 で行っていて、それが評価に反映されていきます。
    1on1 は隔週で行われるため、評価の齟齬が起きにくい仕組みになっています。

  • 具体的な開発工程の流れは?

    各要望チケットに対して具体的な開発方針を決めるミーティングを週次で開催しています。ここには SmartHR の開発者が全員参加していて、大きめのタスクを分割して粒度を揃えたり、設計タスクを挟んだりと、担当する人の負担が分散されるよう調整を入れていきます。
    実装が済んだらまずは開発者間でコードレビューを行い、最後に開発者以外の QA 担当者でリリース判定をした上でリリースされます。

  • 他部署とのコニュニケーションは?

    社内の各部署から出た要望を整理するミーティングを週次で開催しています。ここには開発を含む各部署の担当者が参加していて、対応の可否や優先度を協議しています。
    ほとんどの機能はこういったお客さまの声を元に作られているため、開発担当者と起票者の間では多くのコミュニケーションが取られます。また、より良い解決策を探すために、開発者がサポートや営業メンバーと一緒にお客さまのもとに訪問し、ヒアリングをすることもあります。

  • 競合がでてきたらどうする?

    大前提として、競合が出てくることは市場拡大のためにとても良いことと捉えています。SmartHRはその中でマーケットリーダーであり続けるために以下の考えを持って取り組んでいます。

    ユーザの利便性を何より大事に

    ユーザの利便性が何よりも重要と考えています。そのため、ユーザ体験の向上が見込めるのであれば、近いジャンルの製品とも連携していきます。変に囲い込むことはせず、より良い体験を追求することに価値を感じています。

    選択と集中

    リソースの少ないスタートアップにおいて、選択と集中は重要です。既に世の中にあるものをつくるよりも、まだ解決されていないような伸びしろの大きな課題を見つけて解決していきます。

    大胆に攻める

    SmartHRはアポからの成約率が非常に高く、営業マンが訪問するとざっくり半数は導入決定していただけています。また、解約率が0.3%と非常に低い製品です。その為、スタートアップでありながら、テレビCMを打つなど、大胆に攻めることができています。

エントリー