2023年8月22日にリリースしたSmartHRの最新プロダクト「スキル管理」。
実は、リリース時チームメンバーの3分の1、数にて4名がSmartHR入社半年以内のメンバーであり、しかもそのうち3名は配属時期が6〜7月とリリースの直前！
今回は、そんなスキル管理の「入社半年〜ズ」に集まってもらい、リリース後の心境や、SmartHRについて感じていることについて語ってもらいました。
また、先日実施されたイベント「0→1をスクラムでやってみた -スキル管理機能の作り方- - connpass」では、新規プロダクトリリースに至る苦労や知見が、リリース時スクラムチームメンバーから選ばれた6名によって披露されたので、ぜひ資料をチェックしてみてください。
higashi173大学卒業後、第三者検証の会社にQAエンジニアとして入社。1年ほど在籍したのち、ポテンシャル採用のQAエンジニアとして2023年3月にSmartHR入社。同年7月、スキル管理開発チームに参加。 趣味はゲーム、Youtube、たまに行く旅行。
eto大学卒業後、第三者検証の会社に新卒入社。5年ほどの在籍ののち、ECスタートアップに最初のQA担当者として入社し、QA体制づくりを担当。テスト自動化の取り組みを始め、AppiumとPythonを使ったアプリ自動化などを行なう。 2023年4月にSmartHR入社。同月、スキル管理開発チームに参加。 趣味はキックボクシング、猫と昼寝。
theo大学卒業後に未経験で小規模SIerに入社し、JavaとSQLを習得するも開発にはほぼ関われず。中規模SIerに転職し、開発案件を渡り歩く中でRubyと運命の出会いを果たす。Rubyで自社開発の仕事がしたく、メーカーに転職。 2023年6月にプロダクトエンジニアとしてSmartHR入社。同月、スキル管理開発チームに配属。 趣味はマンガ(少年マンガ多め)とゲーム(任天堂ハード専門)。
chanMisa大手SIerにソフトウェアエンジニアとして新卒入社し、フロントエンド開発や、Ruby(Rails)での表示・操作関連のバックエンド開発を担当。異動で海外子会社のマネジメント業務担当になるも、のちにエンジニア復帰。出向先で動画系やオンライン会議系サービスのフロントエンドを経験。 2023年7月にプロダクトエンジニアとしてSmartHR入社。同月、スキル管理開発チームに配属。 趣味はちょっとした飲み物と一緒に生ハムを食べること、美味しいノンアル（ワイン、ビールなど）を探すこと、期間限定のビールを試すこと。
入社直後&リリース直前を乗り切れた理由
—— スキル管理のリリース日が8月22日だったわけですが、theoさんは6月にチームジョイン、chanMisaさんとhigashiさんは7月ジョインと、まさに「直前」でした。
theoジョインした時は超ビビっていました。チームの雰囲気がピリピリしてたらどうしようとか、こんなタイミングで入って足手まといにならないのかな、という不安がありました。 チームの雰囲気については実際には全然そんなことはなく、とてもなごやかなチームだったので、すごく安心したのを憶えていますね。
チームの足をひっぱってリリース遅らせちゃったらどうしよう、という不安については、コードを書いているうちに解消しました。Rubyはもともと大好きで、Ruby on Railsには習熟していたので、であればなんとかなるかな、とも思っていたんですが、いくつかコードを書いてそれが動くまでいくのを何回か繰り返すことで、とりあえず足はひっぱってなさそう、と思えました。
chanMisa私は、リリース直前だからどう、という意味でのプレッシャーは全然意識していませんでしたね。もちろん、ジョインしてちゃんと貢献できるかな、というのは考えていましたが。
theo本当ですか、すごい(笑)。chanMisaさん、ReactもNext.jsも仕事で使うのははじめてだったんでしたっけ。
chanMisa個人的に勉強してはいましたが、productionのコードを触るのははじめてでしたね。ただ、すでにあるコードが読みやすくて、すぐになんとなく「つかめた」ので、これはいけるな、大丈夫だなって思いました。
オンボーディング向けの開発チケットを用意してもらえたのは、ありがたかったですね。バックログのたくさんのチケットの中で迷子になると困ってしまうし、簡単なチケットを仕様を見ながら実装できるのは良かったです。
（注： スキル管理のリリース直前は、リソース効率重視で、エンジニアがそれぞれチケットを取って単独で実装することが多かった。リリース後の現在は、モブプログラミングに移行中。）
とはいえ、そこまで手取り足取りという感じのオンボーディングではないんですよね。
theoそれはエンジニアを信頼しているということなのかなと思います。なんとか頑張れるでしょ、というのが前提にある。実際、なんとかなりましたし。
それでいて、わからないことは聞きづらいという空気ではなく、逆に質問はとてもしやすい環境でしたね。いつでも聞いてね、と言ってもらえてたというのもありますし、Slackではテキストのやりとりはもちろん、ハドル（ビデオチャットルーム）に常に誰かしら常駐しているからいつでも質問しにいける。スクラムイベントをはじめ同期的なコミュニケーションも多いので、どこかしらで聞けるという安心感があります。
higashi173私はポテンシャル採用という形で採用していただいた背景があり、3月に入社してからずっと特定の所属チームというのはなくて、QAグループ内で勉強したりとか、いくつかのチームを短期間ずつ体験したりなどしていました。
はじめての所属チームとして7月からスキル管理にジョインしましたが、4月に先んじてジョインしてたetoさんにQAのOJT（On-the-Job Training）をしてもらう、という名目ではありました。だから、「リリース直前の、チームがそんな大変なときに、そこでOJTって、いいんですか!?」という気持ちは、とてもありましたね。だって、OJTって時間を使ってもらう前提じゃないですか。
etoさんには毎日1on1のミーティングをしてもらい、色々な取り組みを一緒にやっていこう、と言ってくださったりしたので、とても安心感がありました。
そもそもプロダクトのリリースを経験できるのって、なかなかないですよね。しかも、先輩QAエンジニアから教えてもらいながらリリースを間近で見られたのは、とても良い経験だったなと思っています。
theo私から見ていると、higashiさんはガンガン仕事してくれていたと思いますけどね。バグもたくさん報告してくれましたし。OJTで来てる、みたいな印象は全然なかったですけどね。
etoええ、higashiさんはもともと非常に「つよつよ」なQAエンジニアなので、私も指導的なことはほぼやっていない……はずです。それよりは、QAが2人で倍の馬力になって、リリースまでの作業を協力してやる、という感覚でしたね。
コミュニケーションはすべてを解決する!!
—— 入社したばかりの慣れない時期に、初配属のチームはリリースに向けて追い込み中、しかもフルリモートという大変な状況を乗り切れたのには、コミュニケーションの多さが寄与していそうですね。
theoSmartHRの特長として、総じてコミュニケーションはすごく多いですよね。プロダクトエンジニアはフルリモートですが、1人で働いているという感覚が薄くて、いつもにぎやかにやっている、みたいな。
chanMisaそれはとても思います。前職から比べて、モブプログラミングなど、同期的に作業することがかなり多くなりました。
etoそれでいうと、プロダクトエンジニアと、QAなどの職種が、モブでいっしょに、同期的に作業するというのは、これまで経験したことがありませんでしたね。
chanMisaあと、Slackでワーキングアウトラウド（作業している内容をリアルタイムで投稿していくこと）していると、「これよくわからん・・・」って書きこむと、誰かがサッと教えてくれるので、それに助けられたと思ってます。あと、ほとんどのSlackチャンネルはフルオープンなので、なにかわからないことがあったら、とりあえずSlackで検索すると、他チームの事例が見つかったりする。このオープンさがすごくいいなと思います。
eto困った、ってSlackで書くと、メンションつけてなくても誰かしらが返信してくれたり、誰かにメンションつけてても他の人から返信あったり、とにかく情報を見て拾ってくれるのがすごく良いな、と思いました。
higashi173SlackのDMは基本使わない、っていうのが最初とてもびっくりしました。オープンなチャンネルの流速がすごくて、入社日に東京オフィスに来た帰りの新幹線でずっとSlackを見てましたね……。社内ドキュメントも大量にあるし、自分から情報を取りにいけば、たいていのものはある、という感じですよね。
etoそうした環境のおかげで、私自身の気持ちもポジティブに変化してきました。前職だと私は1人QAで、職種が違うのでエンジニアにも質問しづらいなと感じていたんですが、今はもう、誰にだって質問していいし、相談してもいいんだなっていう気持ちになれています。
敬意があると頑張れる
—— SmartHRは基本的に開発体制としてスクラムを採用していますが、リリース時だけは例外なことが多くて、リリース時からスクラムという「スキル管理」チームは珍しいケースだそうですね。皆さんはこれまでどういった開発体制を経験してきましたか。
theoウォーターフォールとスクラムです。
chanMisa私もウォーターフォールとスクラムです。
eto私も同じく。
higashi173私はウォーターフォールのみで、スクラムははじめてです。
etoSmartHRでとてもいいなと思ったのは、スクラム講座の存在ですね。エンジニアはほぼみんな受けてると思うんですが、そこでスクラムならではの共通の価値観を持てるようになるのが、実はすごく大事だなと。
higashi173エンジニアだけじゃなくて、ビジネスサイドの人も参加できるんですよね。私が参加したときも受講していました。
theoSmartHRに入ってびっくりしたのは、スクラムをはじめプロダクトの開発に対して全社的に理解がある、みんなそれが当たり前、という文化だったところですね。
chanMisaたしかにそれは思いますね。前職でのスクラムだと、プロダクトオーナーが忙しくて「要件を出すだけの人」になりやすく、チーム内で試行錯誤しながら頑張っていたものの、うまくいかない部分も多かったんですが、SmartHRはちゃんとスクラムが回せてる感じがします。ビジネスサイドの側にも、「機能のリリース時期が決まっていないことへの許容度」みたいなのがありますよね。
theoチャットサポートやカスタマーサクセスも、そのあたりを理解した上で、お客様からの問い合わせに返信して、その上でプロダクト側にフィードバックしてくれて。で、プロダクトのオーナーもそれを見て優先度とかの判断をしっかりして、と、全社的なサイクルがしっかり回っているのをすごく感じます。
「テック定例」という、エンジニアの全体定例のような場がありますが、その冒頭が「チャットサポートからの共有」コーナーというのも象徴的だと思います。エンジニア側としても、チャットサポートやカスタマーサクセスが持つ情報をキャッチアップしていこうという姿勢があります。
おたがいの仕事に敬意があるんですよね。みんながプロダクトを良くしようとしているのがわかる。入社してからの私自身の変化としても、そういう空気に引っ張られて、自分も頑張ろうという気持ちなれました。
eto仕事への敬意というのは本当に大事だと思います。私は以前、QAエンジニアはプロダクトエンジニアに比べて肩身が狭いなと感じることが多かったです。でも、そういう感覚ってプロダクトの品質担保の阻害につながるんじゃないかなって。SmartHRを選んだ理由は、どの職種もイーブンな関係性だと感じたからですね。
higashi173プロダクトもそうだし、チームを良くしていこうという意識も強いですね。私も今回はじめてチームに所属して、自分がどう動いたら良くなるのかという意識が働くようになりましたし、ちゃんと考えていきたいという気持ちになりました。
chanMisaやっていこう、と思ったときに、頑張るための支援もあるのが良いと思っています。上司などとの1on1ミーティングでは、自分の目標に対しての進捗を確認したり、やりたいことをやれるように一緒に考えてもらえたりしますし、自走できるようにサポートしてくれるメンバーも多いので、成長の実感があります。
etoいい話だ……！
——みなさん、ありがとうございました。「スキル管理」の今後の開発にも期待しています！
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
プロダクトエンジニア、QAエンジニア、プロダクトデザイナー、UXライター、そしてもちろんビジネスサイドも一丸となって、歴史に残るプロダクトを作っていきましょう！
少しでも興味を持っていただけたら、カジュアル面談でぜひざっくばらんにお話を！
