SmartHRは2025年6月に「データ入力レス給与計算機能」を発表しました。

実はこの機能の発表直前、リアスマ編集部の耳に「この給与計算機能の開発チームが何やら面白い」という情報が入ってきていました。

リアスマで取り上げるかを検討するため何が面白いのかを聞いたところ……

• 技術統括本部（開発チーム）を飛び出し、CEO直下にて1人で開発を始めた

• SmartHRで広く採用されているスクラム開発を取り入れていない

• 明確な期限があるのにウォーターフォールも取り入れない自律駆動な開発

• 個人の目標設定は超シンプルな項目が1つだけ

という「いつものSmartHRとは随分違うな？」と感じる情報が舞い込んできました。

これはぜひ詳しく聞きたい！ということで取材をした結果、このチームの独自な手法や考え方は、メンバーの特性を踏まえ、既存のやり方に囚われずにベストなやり方を考えた結果だったことが分かりました。

さらに、これまで当たり前に行っていた「スクラム」や「目標設定」への問題提起ともいえる意見も多く飛び出しました。

果たして、この特異なチームはどのようにして生まれたのでしょうか。
そしてその特異なチームで1年間過ごして何を感じたのか、深堀りしていきます。

開発組織を離れてCEO直下で開発

ー さっそくですが、本来の開発組織である技術統括本部ではなく、CEO直下で開発することになった理由を教えて下さい

芹澤）僕がずっと給与計算領域のアツさについて語り続けていたら「そんなに言うならCEO直下で開発しても良いんじゃない？」となって、僕の直下でミニマムに始めることになったのがきっかけです。

あと、ちょうどたまたま暇してる5等級エンジニア（※）のパンチさん（※）がいたのでいい感じに始められるなと（笑）。そしてしばらくして2人目のエンジニアのrihoさんにも来てもらいました。

※ SmartHRの等級制度において5等級は「周囲の模範となり専門領域を牽引できる人」とされています
※ キックボクシングをしていることから佐藤さんは「パンチさん」と社内で広く呼ばれています

ー 開発のお二人はこれまでずっと所属していた開発組織を離れてCEO直下に異動されたわけですが、不安やとまどいはなかったのでしょうか？

パンチ）特になかったですね。serizawaさんがエンジニア時代からの仲なので不安はなかったです。

riho）私は不安はありましたよ（笑）。CEOはそれまでかなり遠い存在だったのですが、急に上司がCEOになるわけなので。

ー rihoさんの直の上司が芹澤さんなんですか？

riho）そうです。具体的な不安というよりかは、いきなり距離が近くなりすぎるので最初は戸惑いましたね。

芹澤）異動する前に一応面談しましたよね。でも実は以前2週間だけエンジニアとして一緒に働いたことがあって、発言の節々にロックンロールを感じていたので僕としてはこのチームには合いそうだなと。

riho）どこにロックンロールを感じたんだろう（笑）。

スクラムをやめた理由

ー さて、2人の在籍する給与計算チームがすごい勢いで給与計算機能を開発していくことになるわけですが、その勢いを後押しした理由の1つが「スクラムを取り入れなかったこと」だと聞いています。ここについて詳しく教えて下さい。
※追記：2025年6月時点で開発に関わる人員は10名です

パンチ）プロジェクトの性質的にスクラムは合わないと思ったのと、実はちょうどスクラムに疲れていたんです。

ー まず性質に合わないと思った理由はどのあたりでしょうか？

パンチ）SmartHRには給与計算の業務に詳しいドメインエキスパートとプロダクトデザイナーの2人がいました。その2人と芹澤さんが考える、最強の給与計算機能の仕様とモックが先にあって、まずそれを開発していこうという状況でした。

作るものがある程度明確なので、開発初期段階から細かく計画と実行を繰り返しながらつくっていく必要はないなと。だからスクラムは合わないと思いました。いや、でも疲れていたのが大きい（笑）。

ー なるほど。なぜスクラムに疲れていたんですか？

パンチ）スクラムでの開発を進めていると、スクラムの中で行われるイベント（※）が膨らみがちで、それが疲れるんですよね。
※スクラムを運用するうえで必要な各種ミーティングのこと

スクラムイベントだけじゃなく、スクラムのプロセスを改善するためのミーティングが生まれたり……。開発以外の時間が多くてここに疲れる人は僕以外にもいましたね。そしてこのやり方でやったらリリースが多分間に合わないなと。プロセスのための時間に多くをかけず、実際に価値を生むことに集中できる環境が自分にとっては理想です。

と言ってもリリース前のプロダクトなのと、少人数だったのでできた面もあるとは思っています。なのでスクラムを後から取り入れるなら良いのですが、少人数かつスピードを求めると今はスクラムではないなと。必要そうなら取り入れると思うんですけど……。その気配はまだ無いです（笑）。

serizaswa）やっぱりスクラム嫌いだ（笑）。突然「スクラムキャンセル」なチームにアサインされたrihoさんはどう思ったんですか？

riho）それが私も結構疲れてたひとりなので…（笑）。スクラムを取り入れなかったことでお客様向けの活動が多くできるというのが純粋に嬉しかったです。

単純計算ですがスクラムで開発していた頃に比べて開発時間がほぼ2倍になりました。スクラムそのものが悪いわけではないのですが、これまでの運用ではイベントやその準備に時間がかかりすぎて開発に使える時間が限られていると感じていました。スクラムをいかに上手く回すかが目的になっていて、ユーザー価値にあまり繋がっていないなと思うこともありましたね。

芹澤）手段が目的化していたんですね。実際にrihoさんのGitHubの草（※）を見たら色が急に濃くなっていて、どこで給与計算を開発し始めたのかが一目で分かるんですよね。それくらい違う。
※GitHubにある活動量を可視化したカレンダーで、活動量が緑色の濃淡で表現されることから「草」と呼ばれている

パンチ）ちょっとスクラムに批判的なことを言ってしまったのですが、スクラムの原則である「透明性」「検査」「適応」は大事だと思っています。

この辺りはプロセスは違ってもみんなそういう認識でいました。というか今話をしながら思いましたが、スクラムが嫌いなのではなくて、イベントが多すぎたり必要以上のことをしているんじゃないか？というムダに対しての意見ですね。

スクラムではなくても小まめにドメインエキスパートやプロダクトデザイン側からフィードバックはもらっているし、一定の振り返りもしていて、でもそれらを型化せずに各人の自律駆動で開発しているスタイルでした。

スクラムという型で行うと、どうしてもイベントがあるからという理由で無理に小さいフィードバックを出すなど「場を保つためのムダ」が生まれたりもするので。

riho）イベントを毎週やってるとネタが切れるので、細かい文言の話とか、些細なことについて議論が生まれたりしますよね。「一語一句に手間ひまかける」という以前のバリュー（※）もあったので、細かいところこそ称賛されたりもするけど、時間をかけてみんなで議論するようなことじゃないこともあるなぁと思うことは正直ありました。
※2024年6月まで「一語一句に手間ひまかける」というバリュー（行動指針）がありました。現在のバリューはコチラ

その点、今の進め方にはスクラム的なイベントがないし、つくるものが明確なので毎日の朝会と週2回のリファインメント（※）くらいでした。でも同じ方向を向いていたのでリファもよくスキップになってましたね。
※リファインメント：「こういうものを作っていこう」という合意形成

芹澤）給与計算開発チームの誰かも「リファインメントに時間をかけるよりも、仕様の違いに気づいたらすぐに直せる今の体制の方が総工数が少ないんじゃないか」って言ってましたね。

これって「どこのムダを許すのか」ですよね。手直しのムダを許すのか。または会議のムダを許すのか。

ー なるほど。スクラムで時間をかけて会議を行い、手直しの時間を減らすよりも、開発時間を増やすことで手直しの時間を相対的に小さくするということですね。

芹澤）そうです。でもこれはローンチ前だからできる部分もあります。公開後は手直しがしづらい部分があるし、機能が複雑になればあまり手直し数が大きいと「手直しのムダ」が「会議のムダ」を上回るかもしれないので、今だからできるやり方がハマったんだと思います。

独自だけどベストな進め方

ー 改めてですが今回は明確な進め方の型はなく、つくってフィードバックをもらって直すを繰り返す……を型化せずに自律駆動でやっていく、というプロセスってことですよね。でもこれって締切があってミスが許されないプロダクトにしては怖くないですか？

芹澤）世の中的にはアンチパターンですよね。

どんなにつくるものが明確だとしても期限はあるのに明確な細かいマイルストーンも置いてないしウォーターフォールでもない。つくって、必要があれば直し、で積み上げていくスタイルなので、上手くいくとは限らない。

ー マイルストーンはどれくらいの粒度のものを置いていたんですか？

芹澤）大きなマイルストーンは3つだけ置いていましたね。「いついつまでに、この状態にする」という超シンプルな指標です。そこをめがけて各々が開発していくだけです。でもそれができるメンバーでした。

ー このプロセスでやってみて最終的にどうでしたか？

パンチ）かなり良かったですね。最終成果物はもしかしたらスクラムでも結果的に変わらなかったのかもしれないけど、ユーザー価値の創出と提供に集中できるのでメンタル的にマイナスのことが発生しない状態でいられるのは大きかったです。

そういう意味ではこのプロセスにプラスの要素はあまりないのかもしれません。でもプラスよりもマイナスを排除できることに大きな意味があったと思います。

芹澤）今回やってみて、チームごとにコンディションはぜんぜん違うので、プロセスもフラットに検討しないといけないと改めて感じました。

チームに誰がいるのか、どんな人なのか、何を考えているのか、どんなプロダクトなのか、ビジネス的なインパクトはどうなのか、スケジュールはどうか。

これらを踏まえてちゃんと検討してから適材適所の開発手法を考えるべきなんだなと。

スクラムと育成

パンチ）本題から少し逸れますが、当社のスクラムで育成観点の課題が出ることも多く見てきました。

スクラムをちゃんと回そうとすると、手戻りを減らすためのすり合わせがどんどん増えていく傾向があって。自分の経験上「こういうふうにコードを書くよね」まですり合わせるチームも多いので、新人やジュニアのエンジニアは言われた通りや計画した通りのコードを書くことが多くなる傾向があります。なので成長しづらいんじゃないかと。

芹澤）それ、スクラムに初めて出会った時めっちゃ思いましたね。「これで育つのかな？」と。さらにそのすり合わされたコーディングをモブプロ（※）でやったりするとなおさら。
※複数のエンジニアが協力してコードを書くこと

パンチ）自分で責任を持って意思決定して、失敗を重ねることで成長しますからね。

芹澤）成長には自分で設計するというのが大事ですよね。スクラムみたいにみんなで責任を持ち合って、みんなで考えるやり方にもメリットはあるけど、責任やリスクも薄まるから個人の成長でいうとおそらく鈍化しやすい。

ー ほぼ全ての開発組織で採用されているスクラムの問題点をひたすら明らかにする記事になってますけど大丈夫ですか？

芹澤）結構ヤバいかも……（笑）。でも実際に成長を考えて、rihoさんをこのチームにアサインした面も大きくて、スクラムキャンセルなチームで1年過ごしてみてどうでしたか？

riho）多分これまでで一番成長できた1年でしたね。

芹澤）ここ太字にしてください（笑）。パンチさんはrihoさんの成長を感じました？

パンチ）僕はこのチーム以前のrihoさんがどうだったかは分からないのですが、他のメンバーへのフィードバックなどを見ていると「すごいなぁ」と「そうだよなぁ」と思うことは多々あって学びがあるレベルになっているのは間違いないですね。

給与計算の本

ー つくるべきプロダクトが明確だったという点に加えて、皆さんが「給与計算の本」を読んでドメイン知識をつけていたというのも特徴だと聞いていますが、どうでしたか？

パンチ）給与計算の概念は理解できたので「よしやっていくぞ」という気持ちになった。……くらいですかね。

riho）そうですね。

芹澤）テンション低い（笑）。僕はこれ読んで「給与計算機能つくろう！」ってなったんですよ。なんとなく下手に開発しない方が良いと思ってたけど「これ、つくれるじゃん」と。めっちゃテンションあがりましたね。

パンチ）へぇ。

芹澤）……この本を読んで盛り上がってたのは僕だけだった様です。ただ、エンジニアがこういう業務の入門書を読むと、データ構造や画面設計をイメージしながら理解を進められるので非常にオススメですね。

映える目標設定問題

ー 開発体制については一通りお聞きできたと思います。次に目標設定も独自だったと聞いています。

芹澤）僕、エンジニアの目標設定には課題意識がありまして。そもそも「エンジニアの目標設定は激ムズ」だと思っているんですよ。自分がエンジニアの頃からずっと思っていて。何を持って個人の成果とするかとか、良し悪しをどう測るかとか、不確実性が高い状況で半年後のあるべき姿をどう定義するか、とか。不明瞭なことが多すぎるし、その目標があることでヤル気が漲るんだっけ？と。

今回、給与計算開発チームを自分が見ることになり、久々にエンジニアの目標設定をすることになったので、2人に目標設定についてどう考えているのかヒアリングしたんですよ。そしたら2人とも僕と似た考えだったんです。パンチさんに限っては「目標設定はなくてもいいですよ」って感じでしたからね。

パンチ）目標設定であれこれ悩むよりも、まずは今やるべき開発に集中したいという思いでした。

ー でもさすがに目標設定なしではないですよね？最終的にどんな目標になったんですか？

芹澤）さっき言った「この日までにこれを開発する」というマイルストーンを3つ置いただけですね。それだけ。それを押すのか巻くのかで評価が変わるというシンプルな設計。

事業会社はソフトウェア開発で使われる「QCD（※）」のD（= Delivery）がクライアントワークではないので流動的になりがちです。でも遅れて良いわけじゃない。特に今回のプロジェクトでは、事業戦略上素早いDeliveryが求められていました。だから、シンプルにDeliveryに重きを置くのには意味があるしシンプルかつムダがなくて良い目標だと思っています。
※「Quality（品質）」「Cost（コスト）」「Delivery（納期）」

riho）シンプル故にそれがすべてなので、私は評価を意識して期の後半はめっちゃ焦ってました（笑）。

パンチ）私は焦ってる周囲を見て初めて焦りました。

芹澤）パンチさんは本当に評価に興味がないですよね。そういえばエンジニア陣は目標設定に結構な時間かけてますよね？

パンチ）ですね。目標設定に時間をかけすぎているケースだと、期初に始めた目標設定がなかなか定まらず、2ヵ月くらいかかって中間評価の目前になっていたり。関係者のレビューが複数入ったりして長引いたりするんですよ。でも現在は改善が進んでいるみたいです。

芹澤）2ヵ月はヤバい。

パンチ）開発自体の評価がムズいので「映える目標」を入れることももありました。「どこどこチームと連携」とか「新たにhogeを導入」みたいな評価しやすいアクション。そして、期末評価の直前になって目標設定を終えるために慌てて「映える目標」をねじ込んだりするみたいな。

riho）ユーザー価値には直接つながらないけど評価の分かりやすさのために「プロセス改善」とかを評価に入れがちですよね。それがユーザー価値につながれば良いのですが「評価のためのアクション」は結構ある印象です。

ー 芹澤さん、スクラムだけじゃなく評価にも相当課題がありそうですが。

芹澤）そこそこ大きな課題かもしれない（笑）。

ー 給与計算開発チームで上手くいった「いつまでにどこまで開発する」みたいなシンプルな指標をエンジニアの目標設定にはできないんですか？

パンチ）測れますね。ただ今の評価制度だと期初に目標設定をしないといけないので、そうなると結構ムズいんです。当社のようなスケールアップ企業において、向こう半年間の開発計画を定めるのはとても勇気がいるので。

芹澤）マネジメント側も明確に評価できる「映える目標」を入れたくなる気持ちは分かるのですが、それをなくす勇気がマネジメント側にあればシンプルに活動だけにフォーカスした目標設定は可能だと思ってます。勇気次第です。

あと、その期日を目標にする場合、そこに対する納得感の醸成もとても大切です。このプロジェクトにおいては、なぜここまでにDeliveryしたいのかという事業上の想いや、ユーザーに届けたい価値についてはできるだけ共有するようにしていました。

riho）いちエンジニアとしても目標設定に時間をかけなくなったことはかなりポジティブでしたし、期日を守れば自分の評価につながるというシンプルな目標なので分かりやすくて良かったです。ムダなアクションもしなくて良いし、ちゃんと分かりやすく評価されるのでかなり燃えましたね。

「データ入力レス給与計算機能」の思わぬ反響

ー スクラムと評価に対する「提言」が一通り出たところで……。最後に、給与計算機能を発表して、かなりのメディアやSNSでの言及がありましたね。反響を見てどう感じたのかを教えて下さい。

パンチ）反響を見て「すごいことしたのかもな」と。同時に「リリースしちゃった。やべぇ、バグ出したらやばいな」と。お金に直接絡むシステムなので特にバグが許されない領域ならではの不安は生まれましたね。

riho）分かります。リリース前までは軽い気持ちでマージしたり、テーブルふっとばしたりしても良かったけど今は戦々恐々としていますね（※）。こんなに反響があるとは……。

※リリース前に社内の品質保証チームや関係者による然るべき品質チェックのプロセスを経てリリースされています

芹澤）僕も想像以上の反響でしたね。これは嬉しいことですが背筋が伸びました。

ー 改めてリリース、そして大きな反響、おめでとうございます。そしてスクラムや育成、目標設定に対する色んな想いまでありがとうございました。

お話を聞いていると、これまでのやり方に固執せずに「自分たちならどうやるか」をフラットに考えて、実行に移し、良い形で着地するという理想的なチームだったように感じました。

どうしてもすでに社内で流通している「SmartHRらしいやり方」でやろうとしがちな中、この記事は「当たり前」に一石を投じる記事になるかもしれません。

また、SmartHRには「ためらう時こそ口にしよう」や「まずやってみる人がカッコイイ」というバリューがあるので、給与計算チームだけではなく、色んな人や組織から前例に囚われない意見ややり方が普段からもっと飛び交っていても良いのかもしれないとも思いました。

私たちリアスマ編集部としても色々考えてみるきっかけになりそうです。皆さま、ありがとうございました！

久しぶりに給与計算の本を読んで初心にかえる3人

編集／@arakin
写真／@arakin