「SmartHR使い物にならない問題」をどう解決したのか？　VPoEが語る、ピンチを乗り越える開発チームの作り方

面倒な労務管理の現状

芹澤雅人氏：あらためまして、私は芹澤雅人と申します。SmartHRという会社で「SmartHR」というサービスを作っております。前職で社会人になって以来、ずっとWebエンジニアとしてのキャリアを歩んでおります。

2015年のTechCrunch主催のスタートアップバトルで、SmartHRが優勝したピッチを見たことをきっかけにSmartHRにジョインしまして、エンジニアとして開発業務に携わっています。この1年ぐらいはVPoEとして開発チームのマネジメントもしております。

SmartHRというサービスについて、簡単にご説明させてください。SmartHRは人事労務の手続きを簡単にするクラウドソフトウェアです。

ちょっとお聞きしたいんですが、最近、転職や入社された方はこの中にどれぐらいいますか？　手を挙げていただけると助かります。

（会場挙手）

意外といますね。驚きました。ありがとうございます。その方々は記憶に新しいと思いますが、会社に入社するときにはいろいろな書類を書く必要があります。手で書いたりExcelのシートに記入したりすると思います。それってけっこう大変ですよね。

さて、入社する側のみなさんも大変ですが、それを処理する労務担当者側はもっと大変です。毎月のように入社してくる人が手で書いた書類を別のなにかに転記しています。

また、その情報に間違いがあったりすると、その従業員に直接聞きに行って情報を修正して、また書類を書き直すみたいなことを、毎月とてもアナログで面倒な業務を行っております。

その役所に提出する書類はとても種類が多く難解な書類の山となっております。本当に難しくて、これを書くために必要な知識を説明する書籍も大量に出版されています。

やっとの思いで書類を書き上げても、そこでおしまいではありません。それを役所に届けないと意味がありません。役所とひと言で言っても、書類の種類によって出すところがいろいろありまして、ハローワークとか労基署、あとは年金事務所といったところにそれぞれ出向かなければなりません。

さらに、入社のピークの時期では2時間ぐらい待たされることもざらにあり、労務担当者は憂鬱な時間を過ごしているのが現状です。

労務管理を効率化するSmartHR

そのような問題を解決するのがSmartHRです。SmartHRでは人事情報をWebで簡単に収集できます。さらにその収集した従業員の情報を使って、社会保険や雇用保険の書類を自動で生成できます。

さらにそのままe-Govという政府が公開しているシステムのAPIと連携しておりまして、役所に行かず、届け出をWeb上で完結することができます。副次的な効果として、役所に届ける最新の従業員のデータが揃っておりますので、従業員データベースとしての活用も行えます。

メリットは、労務担当者だけではなく、最近ではペーパーレス年末調整と謳っていますが、みなさんは年末になると年末調整で紙にすごく細かな字をいっぱい書くと思います。あれがはい・いいえの質問形式でスマホで答えるだけで完成する機能もありまして、こちらも好評を博しております。

ローンチから約2年半経っていますが、ご利用いただいている従業員数1名〜1万名規模、さまざまな業態の企業様に使っていただいております。

おかげさまで導入企業数は1万社を突破して、継続率も99.3パーセントをキープしております。

以上がSmartHRの簡単なご紹介でした。本日は開発のカンファレンスなので、「SmartHRを支える開発チームの作り方」ということで説明いたします。

ローンチに至るまでの開発環境

先ほどお話したとおりローンチから約2年半経っていますが、ローンチ時期から現在に至るまで、開発にまつわる環境がどのように変化してきたか、みなさんにご紹介したいと思います。

さっそくですが、ローンチにいたるまでに開発がどのような状況だったか紹介します。ローンチまでの間、SmartHRは3名のメンバーで作られていました。

こちらが社長の宮田です。

宮田は主にビジネスサイドを担当しておりました。営業活動を行う傍ら士業の方々やいろいろな各社にヒアリングを行い、プロダクトのコンセプトを固める作業をしていました。

ヒアリングの記録は今でも残っています。

ここにあるだけで88件記録残っていて、本人からは「ここに残っていないものを含めると200件以上ヒアリングに行った」ということをよく聞いております。

ですので、ヒアリングがすごく得意なんです。200件行っているのでかなりのノウハウがたまっております。そのヒアリングテクニックは、宮田のみならず営業メンバーにも受け継がれています。今でも新規機能を開発する際は、そのノウハウを用いていろいろなユーザー様にヒアリングを行っています。

こちらがプロダクトサイドです。

副社長の内藤ともう1名のエンジニアで進めておりました。私たちの開発は初期段階からスクラムを導入しておりまして、リーンで爆速な開発を進めておりました。スクラムは先ほどのデンソーさんの説明でもありましたが、プランニングポーカーを使って相対的なポイントで見積もりを出すということを昔からやっていました。

よくスクラムで言われますが、プランニングで工数を出すことによって、1週間でスプリントを回しています。これによって1回のスプリントで行えるタスクの量がだんだんわかってきます。そのタスクが継続可能な状態になると、開発者がうれしいのみならず、ビジネスサイドにもメリットがあります。

ビジネスサイドのメリットとしては、開発のロードマップの精度が上がってきます。なので、この機能を作ろうと思ったときに、だいたい何クオーター後にできるかとか、そういったことがお互いに正確に知れることがとてもいいなと思っています。

開発者サイド的には過重労働などを避けることができ、ホワイトな労働環境が保てるというメリットがあります。その2つは本当にいいなと思っておりまして、いまだに毎週スクラムポーカーを用いて見積もりを行っています。

そんなヒアリングとスクラムのテクニックを駆使してSmartHRは作られていました。2015年の11月にローンチし、その結果、TechCrunch Tokyoのスタートアップバトルで見事優勝を勝ち取りまして、プロダクト・組織がともに成長の道を歩むことになりました。

SmartHR使い物にならない問題

とまぁ、ここで終わればスタートアップのめでたい美談というか、きれいな話なんですが、きっとみなさんが聞きたいのはこんなことじゃなくてもっとドロドロした話なんじゃないかなと思います。ですので、ここからドロドロゾーンに突入していこうと思います。

（会場笑）

というわけで、プロダクトの黎明期になります。スタートアップバトルで優勝しましたので、プロダクトを成長させるため、エンジニアのみならずほかのメンバーも増員して、とりあえず人が増えました。私もこの時期にジョインしまして、ほどなくしてスクラムマスターを引き継いでおります。

さっそく、ピンチを迎えました。僕が入社して3ヶ月目か4ヶ月目ぐらいの時期に、こんな問題が起きました。「SmartHRぜんぜん使い物にならないですね」みたいな感じです。

どういうことかというと、プロダクトオーナーに副島という者が入社した時にこんな記事が投稿されました。「いまのSmartHRの残念なところ」と。

率直に言うと「まったくこれは労務の現場では使えません」ということがつらつらと書かれていて、私たち開発者は「やばい」と。「なんでこんなことになってしまったんだ。ヒアリングとはなんだったのか？」という感じで、心臓がざわざわするような経験をしました。

なにが起きていたかというと、決してヒアリングが間違っていたわけではありませんでした。ヒアリングをしていたときの想定ユーザーは10名規模のスタートアップのITの先進的な企業様でした。

ただ、ローンチから4ヶ月ぐらい経つと、だんだんとユーザーが100名規模の企業になってきたんです。10名と100名でなにが違うのかあんまりわからないと思いますが、実はすごく大きな違いがあります。

10名規模の企業では社長が片手間で労務をやっていることが多いです。誰かが入社したときに社長が書類を作って出すみたいな感じです。しかも、毎月定期的に入るわけではなく、不定期に入ってくるので、月次のルーチンワークという感じではありません。

ですが、100名規模の企業になると、毎月数名程度の入退社が発生するようになっていきます。そうなると、労務担当者という専門の人がつくようになり、その人が月次のルーチンワークで処理し始めます。

この2つはフローが違いまして、私たちがヒアリングして作ってきたフローでは、100名規模の労務担当者が使うものにはまったく歯が立たないというか、別ものでした。その結果、実世界に即していないプロダクトになっていました。なので、この乖離を埋めるために抜本的な修正を加えることになりました。

企画フローを見直す

プロダクトに手を加えるのもそうですが、まずは企画のフローから見直すことになりました。1つ目が「利用ユーザーの声を聞きましょう」ということです。

当たり前ですが、ローンチ前というのは利用ユーザーがいないので、実ユーザーにヒアリングはできません。ただ4ヶ月経つと、幸いにして利用ユーザーが増えてきていましたので、具体的な要望や使いにくい点が彼らに対するヒアリングによってあらわになりました。

私たちが作っているのはSaaSサービスなので、個別のカスタマイズは基本的にはしない方針で作っております。いろいろ会社の方から要望がたくさん来ますが、それを全部作っていたらとんでもないプロダクトになってしまうので、「10社から要望が来たら実装しようね」というルールを敷いて運用していました。

もう1つ、先ほど紹介した副島が主導して機能を設計するというところです。今まではエンジニアが主導で機能を考えていましたが、副島は他社で10年以上の労務担当者の実務経験がありますので、その知見に基づく現場で使える機能設計をやることになりました。

現在でもこの2つのフローは引き継がれておりまして、とても役に立っております。その結果、なんとかピンチを乗り越えまして、数百名規模のユーザーでも使えるプロダクトになりました。めでたしという感じですね。

不安な心を支える名著

すこし脱線しますが、このフェーズでお世話になっていた本を紹介したいと思います。読んだ方も多いと思いますが、『キャズム』という本があります。

これはマーケティング理論の1つです。プロダクトは初期の段階ではマーケットにフィットするかどうかぜんぜんわかりません。そのため、とても毎日不安な日々を過ごしております。本当にSmartHRというプロダクトが今後スケールして1,000名規模とか1万名規模のユーザーに使っていただけるのか不安で不安でしょうがないです。

『キャズム』はスタートアップのプロダクトがある谷を超えて世界的に有名になるターニングポイントを決めて乗り越えましょう、みたいな本なんですが、これを読んで理論武装することでかなり心が安らぎました。

難しい本ですが、全社的に勉強会をやっておりまして、この中に出てくる「期待プロダクト」とか「拡張プロダクト」といった用語はほぼ全員が会議で使うようになるぐらい浸透しています。

なので、今後なにか新しいプロダクトを作ったり、「ちょっと会社作ろうかな」みたいな方がいましたら、ぜひこちらを読むことをおすすめいたします。

システム基盤限界問題が発生

次は、チーム開発の黎明期になります。人数が増えてくると、チーム開発の体が余裕をなしてきます。約1年半前、エンジニアは10名ぐらいに増えてきました。このタイミングで私はVPoEを拝命いたしまして、隔週でメンバーとの1on1を始めております。

そして、このフェーズでまたしてもピンチを迎えます。「SmartHRのシステム基盤限界問題」ですね。さっきと似ていますが、やっとの思いで100名規模の企業を攻略したと思ったら、気がついたら1,000名規模の非IT企業のユーザー様に使っていただけていました。

本当にうれしい悲鳴ではありますが、何千人の従業員に対して一括な操作をするような要望が、このタイミングですごく増えました。当初は想定していなかった負荷が加わってサーバの輻輳が頻発しました。

また、非IT企業ではユーザーの層が多彩でした。例えば、SmartHRはスマートフォンを持っている前提で作っていましたが、「スマートフォンを持っていない」という場合もあり、UI/UX的な限界も迎えました。またしても、これらの乖離を埋めるために抜本的な修正が必要になりました。

さらにこれに加えて、組織が大きくなってくるとプロダクトへの要望も多様化してきます。エンジニアチーム、サポートチーム、営業チーム、マーケチームと、各チームがより専門的なことに取り組むようになり、細分化されていきました。すると、各チームから要望がこんな感じで上がってくるようになりました。これを開発チームが処理しないといけないという状況でした。

するとどうなるかというと、開発初期からTrello（注：タスク管理ツール）を使っていたんですが、Trelloはこうしたことに耐えられずに崩壊してしまいました。

Trelloを使ったことある方はわかると思いますが、古いカードは黄ばむんですよね。画面がどんどん黄ばんでいく恐怖みたいのものがありまして。

（会場笑）

いつまで経っても消化されない。増える一方で「どうするんだ？」みたいな感じでした。あと、昔のカードもどこにあるのかわかりません。その結果見事に崩壊しまして、タスクの優先順位付けについて、いよいよ本腰を入れなければならないフェーズに入りました。

会社にとって一番大切なことを定義する

月並みではありますが、Jiraを導入しました。

Atlassianの製品は比較的好みが分かれると思いますが、僕はJiraを導入してよかったなと思っています。

まず、要望をバックログに各チームが起票します。その起票してもらったバックログを1週間に1回整理する会を開き、各チームのリーダーが集まってみんなで話し合い、やるかどうか、やるならどんな優先度でどのスプリントでやるかをその場で判断していきます。

Jiraのいいところは、将来のスプリントの計画まで立てられるところです。なので、3週間後にやろうとか、そうした判断がしやすいのがとても気に入っています。

結果として、対応時期が不明な要望チケットが放置されなくなり、バックログは常にクリーンな状態に保たれています。あと、むこう1、2ヶ月ぐらいのスプリントの計画がわかりますので、開発者の精神的な安定もある感じです。

もう1つ、こちらも重要だと思います。プロダクト指針の全社共有をしました。

私たちの会社では、初期から半年に1回、全社員で合宿をし会社のビジョンを決めています。このぐらいのフェーズから「今のSmartHRにとって一番大切なことはなにか？」ということをみんなで話し合って決めるという取り組みを始めました。

大切なことを最優先で各チームが動くんです。この時は「1,000名規模の会社で使ってもらうことが一番大事だよね」という判断をしました。なので、開発タスクに関しても、それから逸れるようなものは、強い気持ちでやらないという判断が言えるようになりました。

これは全社で共有されている指針なので、開発チームが「これはやりません」と気楽に言えるというか、変な責任を負うことなく言えるのがとてもよかったかと思います。その結果、なんとかこのピンチを乗り越えて、1万名規模のユーザーでも使えるようになりました。

問題は誰が解決すべきか？

またしても脱線コラムなんですが、この時期すごくお世話になっていた本が1冊あります。

この本（『ライト、ついてますか』）を知っている方はどれぐらいいますか？

（会場挙手）

少しいらっしゃいますね、ありがとうございます。これは社会学的な本なんですが、なぜかプロダクト開発に携わる人の間でも人気です。僕も知り合いに教えてもらって読んで、確かにおもしろくて。

どんな本かというと、問題の本質を見極めるということ、そしてそれを誰が解決すべきなのか決める力、探し出す力を教えてくれます。

どういうことかというと、組織が大きくなってくると、それに応じて問題の数もすぐ増えてきます。人数が少ないときは、出た問題を片っ端から「手の空いてる人がやればいいじゃん？」という感じでしたが、人数が多いとそうは言ってられません。やはりある問題に対して、それを解決すべき適切な人がいるし、逆に言ってしまえば不適切な人がいます。

一番やってはいけないのは不適切な人をアサインして中途半端な問題解決になってしまうことです。これは、スタートアップにとっては痛手なんですね。

なので、一度冷静になって、誰がやるべきなのかを考えるときっかけになったのがこの本です。すごく助けられたと思っております。ライトに読める本なので、もしよかったら読んでみてください。

成長期に入り、スクラムが崩壊

次は最後のフェーズ、チーム開発の成長期です。これは去年の暮れに撮った写真です。おかげさまで3人で始めた会社がこんなにメンバーが入ってきました。

このフェーズで迎えたピンチは2つあります。そのうちの1つ、スクラムがついに崩壊しました。先ほどのデンソーさんの話にもありましたがScrum Guideというものがあります。それによると、だいたいスクラムの最大許容人数は9人なんです。

ピザの例がありましたが、それを超えてしまうと崩壊します。

SmartHRのスクラムは、なぜ崩壊したか？　1個目は、タスクが専門化してきました。だんだん難しいタスクが増えてくると、暗黙的にアサインし始めるようになってしまいます。「このタスクはあの人がやってくれるだろう」という認識をみんなが持ち始める。ただ、口に出しては言いません。

結果として、タスクの偏りや他人任せにしたことによる残タスクの増加が顕著になり、ビジネスサイドから「これはいつやってくれるの？」という指摘が増えてきました。

もう1つは、先ほどもあったように、スプリントプランニングの時間が増えてしまって、十数人分のタスクを一気に見積もるのはすごく時間がかかるようになりました。また、自分に関係ないタスクが増えてくるので、関係ないタスクをみんなで話している間はストレスな時間になります。そういった感じで、「このままじゃスクラムやばいね」という感じになりました。

解決策は、一般的な方法ですがチームを分割しました。ちょうどよく雇用契約締結機能というアドオンプロダクトの開発が本格始動したので、そのタイミングでチームを分割しました。コンウェイの法則というものがありますが、やはりプロダクト単位でチームを分けるとすごくうまくいくというのが実感です。

もう1つはちょっとスクラムのカスタマイズです。Scrum Guideを見るとガチガチにルールが決まっています。本来タスクの担当者はプランニング中にアサインしないほうがいいとよく言われております。

ただ、現状としてすでに属人化してしまっているので、いっそのこと潔くアサインしてみると、逆に担当が明確になることで、今まで「どうせあの人がやるんでしょ」と言ってチャレンジできなかった人たちがチャレンジしやすくなる環境が生まれました。また、強制的に全タスクの担当を割り振るので、お残しタスクもなくなりました。

なので、スクラムのルールからは外れつつありますが、なんとか機能しております。

開発上の課題の多くは社会学的なものである

もう1つのピンチが、チームの課題がすごい多様化してきたなと思います。『ピープルウエア』という有名な本の冒頭にこんな文章があります。「実際のところ、ソフトウェア開発上の問題の多くは、技術的なものより社会学的なものが多い」という一文です。

私は社会学部出身なので、この本ではこの一節がとても印象に残っているのですが、本当にそうだなと思うことが増えています。

技術的な課題や個々人のタスク調整でいろいろな問題を解決してきましたが、人数が増えてくるとそう言ってられません。評価制度や福利厚生、労働環境など、そういったところまで問題が発生してきています。

そこで、ずっと続けてた1on1をひとつ工夫してみました。

メンバーと僕で認識している問題を共有してベクトルを合わせる。そしてその問題に対して本来どうあるべきなのかを議論します。

その具体的な解決に向けた期待値を2人で話すことでフレーミングされるというか、期待はずれの結果にならなくなってきているので、そうした個々人が持つ不満はすごく減ったと思います。あとはエンジニア定例を始めました。

実はチーム発足から2年半ぐらい、エンジニア全員で集まって話すということをほぼやっていなくて、チーム内の課題を話すミーティングは一切ありませんでした。

やってみると意外とチームビルド的な話になることが多く、各メンバーが民主的かつ自律的に理想のチームを作り上げていく風潮が生まれて、これはすごくよかったです。

一度みんなでブレストをしまして、「なにをやりたいか？」「どんなチームがかっこいいと思うか？　働きたいか？」をみんなで出し合ったらすごくたくさんアイデアが出てきて、今はそれを1つずつ実現に向けた話をしています。

SmartHRのこれから

それでは、これからの話を話します。SmartHRって傍から見ると完成しているんじゃないかと思われるんですが、まだまだそんなことはありません。僕たちが今できていることは氷山の一角にすぎないんです。

人事労務領域はもっといっぱいありまして、それらを最大限に効率化すべく、これからもテクノロジーと創意工夫でハックし続ける必要があります。

組織も50人ぐらいになってくると「成熟しているんじゃないですか？」と言われますが、本当にそんなことはありません。

今言ったような問題と、ここでは言えないような問題が本当に毎日のように起きております。それらを解決すべく、制度や仕組みを整備しているフェーズになっております。

弊社は、文化として遊び心を大切にしています。そんな遊び心のある会社という姿を保ったままスケールさせていこうと日々奮闘しております。

というわけで駆け足になってしまいましたが、積極的に採用活動をしておりますので、この話を聞いて興味を持った方がいましたら、懇親会などでお声がけいただければと思います。

では以上になります。ご清聴ありがとうございました。

（会場拍手）

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

ピープルウエア 第3版

ライト、ついてますか―問題発見の人間学