こんにちは。VP of Engineering の森住です
今回は、2022年1月に SmartHR の CEO に就任した芹澤さんが、なぜか最近になって SmartHR の開発チームにイチメンバーとして二週間ほど参加していたので、一体なにがあったのかとインタビューを敢行してまいりました
いつの間にか CEO をクビになっていたのでしょうか？ 気になりますね
それでは、今回のインタビューの登場人物をご紹介します
登場人物
SmartHR 代表取締役CEO 芹澤さん
2016年2月に SmartHR に入社。VPoE、CTO を経て2022年1月に CEO に就任。CEO 業に専念していたかと思いきや、いつの間にか SmartHR の開発チームにイチメンバーとして参加していた
芹澤メンバーを受け入れるチームのマネージャー 山本さん
2020年10月に SmartHR に入社。SmartHR 基本機能内の1つのスクラムチームでプレイングマネージャーを担当。真面目に機能開発をしていたらチームに CEO がきた
芹澤メンバーが開発を行うプロダクトのPO 塚本さん
2019年1月に SmartHR に PM として入社。2019年9月から基本機能の PO を担当。 芹澤さんが開発チームに入っていたとき、直接的な関わりはほぼなかったが、ひっそりと様子を見ていた
特に関係のないインタビュアー 森住
2018年8月に SmartHR にバックエンドエンジニアとして入社。プレイングマネージャー、マネージャーを経て2022年1月に VP of Engineering を拝命。今回の出来事にはそれほど関わっていないがなぜかインタビュアーとして指名された
なぜ CEO が SmartHR の開発チームにメンバーとして参加していたのか？
――さて、今回は芹澤さんが SmartHR の開発チームにイチメンバーとして参加していた、という出来事についておうかがいしていきます。そもそも、なんで開発チームにイチメンバーとして参加することになったんですか？
芹澤：僕や森住さん、あとはプロダクトサイドの VP 陣の SmartHR 基本機能（今回芹澤さんが開発に参加した、SmartHR 最古にして最大のプロダクト）の開発現場に対する解像度が低い気がして、そういう状態でちゃんと投資優先度を判断できているのか、現場の課題を理解できているのかといった疑問が出て、元々は僕と森住さんでいく予定だったんですよね。だけど森住さんが日和ってしまって
――スキップレベル 1on1 の実施時期と被っていたため、というのは一応言っておきますね
芹澤：まあ、現場理解というのが表向きの理由。裏向きの理由は、僕が久しぶりに開発したかった。半々くらいの理由です
――なるほど。最後にガッツリ SmartHR 基本機能のコード書いてたのっていつでしたっけ？
芹澤：2021年くらいだと思います。ガッツリというか、何かの案件でチームが組成されて、外部連携の機能追加とかで開発したのが最後。チームに入るのは3年半ぶりですね
――元々ずっと SmartHR 基本機能の開発をやってましたよね？
芹澤：そう、入社してからずっと。途中で文書配付アプリの立ち上げに半年くらい関わったけど記憶が薄くて……。SmartHR 基本機能の開発が丸三年ですね
―― 当時はどれくらいの規模だったんですか？
芹澤：エンジニアの数だけで言うと、3〜4人からスタートして、僕が離れるときはエンジニアは十何人くらいで、チームは当時3つくらいかな
山本：そんな時期があったんだ……。今だと基本機能を開発しているエンジニアは30人くらいで、芹澤さんが開発現場にいたときの倍くらいいますね。1チーム約5名で6チーム体制ですからね
――他職種も含めると5〜60名くらいの体制になってますね
芹澤：当時は他職種合わせても30名いくか行かないかくらいの規模でしたね。2020年末までは SmartHR 基本機能にいたけど、2021年は CTO になって SmartHR 基本機能からは離れていて、他のことをしてました。プラットフォーム事業の立ち上げや外部連携機能の開発とか
――で、2022年にはもう CEO になっていたと
芹澤：そうですね
突然 CEO がチームにやってくることに。そのとき現場は？
――芹澤さんから、「チームに参加してみたい」って言われて、どう思いました？
山本：めちゃくちゃびっくりした。コンテキストもわからなくて、「何するんだろう」って
――まあそうですよね。色々説明を受けてからはどうですか？
山本：ポジティブな気持ちと、ネガティブな気持ちがありましたね。ポジティブな面としては、元々開発者だった芹澤さんが入ってくれることで、模範的な動きを見せてくれるのかな、とか、SmartHR 基本機能のことをよく見てくれることで自分たちが気づいていない課題に気づかせてくれるかな、というワクワク。でも、芹澤さんがわざわざ見に来ないといけない状態になっているのかと不安になったのもあります。透明性が失われていたり、コミュニケーションに課題があるのかなって、邪推かもしれないけど
――SmartHR 基本機能のプロダクトオーナーとしては、どうでしたか？
塚本：最初聞いたときは、「芹澤さんなら言いそうだな〜」と思いました笑。面白そうだな、くらいの感覚で。もちろん目的はあってのことだと思いますけど、その前にこっそりアプリ開発をしていた話も聞いてたし、何か開発したいんだろうなというのは感じてました。実際に見てもらえるのは貴重な機会だし、嬉しいなという思いが強かったですね
山本：CEO と現場の目線は絶対違うから、違う視点でのフィードバックがもらえたらいいな、というのは思ってましたね
――実際にチームに芹澤さんが来ますという話をしたときは、どんなリアクションだったんですか？
山本：チームには朝会で共有したら、みんな「は？」っていうリアクションでしたね。「えっ」じゃなくて「は？」笑
――「は？ どういうことですか？」みたいな？
山本：そう。でもみんな楽しそうで、不安がっている人はいなくて。不安がってるの僕だけでしたね
――受け入れ時のオンボーディングはどうでしたか？ スムーズでした？
山本：開発環境を作ってもらうのと並行して、今開発していることのサマリは事前に情報共有していました。キャッチアップ早くて、「はえ〜〜〜」ってなりましたね
芹澤：昔やってたからね笑 でも、当時よりもオンボーディングがめちゃスムーズでしたね。あのプロセスは実際に新しく来た人にやってるやつですよね？
山本：そうですね
――最近の SmartHR 基本機能のオンボーディング、めちゃ充実してますよね
芹澤：してる。超びっくりした。あれなら入って即日で立ち上がれる。僕は合間合間でやってたからちょっとかかったけど、ギュッてしたら数時間くらいで終わるはず
浦島太郎と化した CEO が現場で見たものとは
――2020年末くらいの、芹澤さんがいた頃と比べて一番変わったところはどこですか？
芹澤：最初の印象としては、「思っていたほどは変わってないな」でしたね。大きな1週間の流れや、チームの働き方の流れは変わってない。でも、関わる職能・職種は増えてましたね。「こんなにいたんだ！？」ってびっくりした。関わり方も昔より濃くなってましたね
――一番変わったのは関わる人数と、関わる濃さ、と。ポジティブ / ネガティブで言うとどうでしたか？
芹澤：両方ですね。ポジティブな面としては、質が高いこと。機能要件の整理や文言整理、デザインなどなど。当時に比べて段違いのレベルでした。昔は、まあよくも悪くももっと牧歌的な感じで笑
――たしかに、昔は全部エンジニアだけでやってましたしね
芹澤：昔は事業フェイズ的にもアーリーで、Done is better than perfect の精神のもと、デリバリー重視だったよね。今は品質がめちゃくちゃ高くなってる。今回、たまたまリリース手前くらいのフェーズで入ったけど、「こんなにバグ少ないの！？」ってびっくりした
――昔と比較すると、だいぶその辺りの感覚は変わってますよね
芹澤：僕が開発していた頃だと、リリース前なんてバタバタでしたからね。バグ取り始めたら悲惨なことになるような。今は、リリースの予行演習会、避難訓練（問題が発生した場合の対応に関する訓練）までやっていて余裕がすごいなと思いました。インシデントが起きたときに誰がどう動くか、というのも確認してる
塚本：リリース前のバタバタは、今回芹澤さんが入ったチームだけじゃなく全チーム改善されてますね。今は「結合テストとかやっても大きなバグはないか念のため確認します」という感じで、やってみて「やっぱりないね」というレベル
――それって何が変わったんですかね？
山本：経験から学んできたんだと思いますね。リリースでバタバタして手戻りしたから、次のフィーチャー開発のときはリリース準備や避難訓練やるぞ、という風に改善されたり。各チームが色々踏んできて、その改善の結果として今があるんだと思います。サポートの方から共有してもらう問い合わせや、カスタマーサクセスの方にかけてきた苦労、「同じ思いをさせたくない」という思いから準備が入念になってきたのかなと
芹澤：もうひとつプロダクト品質についてすごいなと思ったのは、僕が入ったチームに関しては QA メンバーがいないのに、品質がめちゃ高いということ。QA メンバーが兼務としてすら入ってないのに、Pull Request の確認フローとか、昔は QA メンバーが担当していたことを、全エンジニアが自然にやってるんですよね。それは本当に感動した
――すごいですね
芹澤：僕、QA グループの立ち上げからずっと関わってるんですけど、当時の立ち上げメンバーが入社前から「品質保証を QA だけがやるんじゃなくて、組織として、誰でも無意識的にできるようにしたい」というようなことを言ってたんですよね。で、それが実現してるじゃんって。当時は本当に信じられなかったけど、今それができていて。時間はかかったけど、当時あの人たちが言っていた理想形ってこういうことなんだとすごく感動した
――QA からそういったスキルをプロダクトエンジニアに移譲していく上で工夫したところってなにかあるんですか？
山本：QA の人しか品質保証しないとなると、そこがブロッカーになっちゃうんですよね。だから必然的に分担しないといけなくて。当時チームにいた QA エンジニアの方がチームに落とし込んでくれて、最終的にチームから QA エンジニアが抜けようとなったときは、1ヶ月くらいメンターとして見守ってもらってました。そういった過程を経てスキルの移譲が進んだんですが、でも今の手法しか知らないので、もっといいプロセスや品質の捉え方について課題はあるかもしれないとは思っています
――しばらくして、QA の人にレビューしてもらうとまた新しい発見があるかもしれないですね。塚本さんからみて、各チーム内でのスキル移譲が昔に比べて進んだなと思うことはありますか？
塚本：他のチームでも QA がいない、というところは多いですね。ボトルネックにならないようみんなできるようになろうねという過程を経て、抜けても問題ないようにしようとなって。でも、他の職種は QA に比べると難易度が高いかもですね
――例えばどういった職種ですか？
塚本：例えば、デザイナーの場合はちょっとした画面上の UI 改善ならできるかもしれないけど新規のページを作るとなるとプロダクトエンジニアが業務をしながら作るのはハードルが高いんじゃないか、とかですかね
山本：クロスファンクショナルってタスクを肩代わりすることが目的というわけではないんですよね。議論だったり思考をするときに、別の職能の帽子をかぶってロールプレイングできるという側面があって。あの人ならなんて言うかな、どう考えるかな、という視点で、多様な視点をシームレスにプロダクト開発に持ち込めるのもクロスファンクショナルな働き方の利点なんですよね。お互いの職能を知っているからこそ、創発的なプロダクト開発ができるのかなと
――いい話。芹澤さんから見て、他によかった点はありましたか？
芹澤：めっちゃ仲良いなと思いましたね。チーム内のコミュニケーションがすごくいい。朝会やお茶会も盛り上がってるし
――お茶会ですか
芹澤：お茶会、すごく楽しかった。他愛もない話をするんだけどね
山本：メンバーのパーソナリティのおかげですかね。斜に構えてる人もいないし、フラットにコミュニケーション取れるチームだと思います。スクラムの振り返りとかでも相手の意見を否定せず、受け止めて、納得しなくてもいいけど理解はしようという気持ちがありますね
塚本：チームごとに色がありますよね。芹澤さんが今回入ったチームはほんわかしてる。対照的なところだと、スピード重視で突き進んでいるところもありますよね
山本：あ、うちのチームも今年に入ってからスピードというのは意識してるんですよね。昨年はかなり全体の合意形成を意識してました。納得感は置いておいて、短期的でもいいから成果を出し続けることに意識が高い他チームを見て、モチベーションや納得感も成果の上に成り立つものかなと感じるし、やり方としてそちらの方が妥当性があるのかなとも思って。でもバランスもあるので、様子を見ながらですね。芹澤さんからフィードバックをいただいたのもきっかけのひとつで、今回のフィーチャー開発も振り返ってみたらもっと小さくリリースできたと思うし、一回小さく出してみて反応を見ることでもっと質を高くできたかもしれない。それがアジャイルだよねって思うところはあります。小さく出してその後に改善のサイクルを回せるのが本当は一番いいと思っているので、振り返りで課題を出して考えてみています
CEO から見た現場の課題とは？
――色々よかった点が出ましたが、逆にここは改善点かもな〜 と思った部分はありました？
芹澤：品質の高さとか、丁寧なコミュニケーションの裏返しだと思うんですが、合意形成の動きが強い。何かあると「話しましょう」ってなりがちで。僕は開発者自身がコントロールしてやっていくのも醍醐味だと思ってるんですよね。あまりに合意形成に意識が向くと、面白くなさそうというか。予定外のことがあったときに、話し合って決めることが多かったけど、実際それで速度が遅くなっちゃうこともありましたね。ある程度事後報告でどうにかなるときもあるし、結果としてそれでよりよいものづくりに繋がることもあるんじゃないかな、と
――許可より謝罪の精神？
芹澤：そう、その精神に基づく動きは弱いと思う。許可を取りに行きがち
山本：チームのマネジメントを普段からしている立場からも、お互いに納得して仕事をしたいという気持ちは強いと思います。悪いことではないけど、合意形成のフローが細かくなっているのが妥当だったかを振り返って確かめることは少なくなっていたかもしれません。なんで合意形成をするのかといえば、お客様に価値を提供するためだから、振り返ってみると一人の意思決定者を立ててその人を中心に進めてもらうのもありでした。最近変わってきていて、全員参加で合意を取るようなことを減らして、興味のある人や必須の人だけ参加する形に変えていっています
芹澤：トピックごとに Slack のスレが立つの、すごくいいと思うけど、スレがめちゃ長くなることもある。正直、何個かミュートしました笑
――任せる動きが増えるといいんですかね
山本：そうですね。エンジニアも独立性は高いけど再現性は低いようなところとかは任せちゃった方がいいのかなとも思っています。知識の共有化という観点で考えると、そのときしかやらないようなことをみんなで学ぶ必要はないよなあ、とか。例えば、ここはフロントエンド一人に任せてしまおうという選択肢もあるんですよね。なんでもかんでもモブでやったりペアでやらなくてもいいよね、というのはありますね
――塚本さんはプロダクトオーナーとして、納得感の醸成と意思決定スピードのバランスについてどう考えているんですか？
塚本：そうですね……。今、SmartHR 基本機能の開発は6チームで行なっているけど、関心をある程度分離する形で6チームをふたつに分けて動いてるじゃないですか
――昨年の末頃にグループ分けをした、というやつですね
塚本：そう、それです。なので、私が全部決めているわけではないし、フィーチャーっていう単位で考えると、「グループ」単位で主導していて。関心ごとに分けたことで納得感を持ちやすくはなったのかな、と思います。6チームでひとまとまりだった頃は、なにから考えたらいいのかすごく難しかったし、人数を絞ったことで関心ごとや考える領域が限定されて納得感も持ちやすく、意思決定がしやすくなったのかなと
――今の SmartHR 基本機能開発チームの意思決定スピードはどうですか？
塚本：小さい単位の意思決定、各チーム内の意思決定はもっと早くできるんじゃないかと感じてはいますね。それは私が所属しているチームの、中から見える景色なんですが、今回芹澤さんが入ったチームと同様にプロダクトバックログのリファインメントとか全員がいる場ですごく細かな話をしていて進みづらくなっていたり、ひとつの懸念から話が止まらなくなったり。前に進めるための議論ではなくて、なにか気になったら場当たり的に議論してしまうことはあるかなと思います
――ファシリテーションの技術もあるんですかね
芹澤：今、6チームあるんですよね。6チーム集まって行う、LeSS（Large Scale Scrum）で言うオーバーオール系のミーティングは難しいと思います。これは僕が CTO をしていた時からの課題でした。大人数で話すとどうしても薄い内容になってしまう。難しいですよね
塚本：改善に向けて動いてはいるんですが……。難しいと思ってるポイントが、例えばオーバーオールレトロスペクティブって全体の振り返りをすべきなんですけど、なにを対象とするのかを明確化できていない。SmartHR 基本機能開発チームという内側の話をするのか、外も含むのか、目的が不明瞭なことがあって、うまく機能させられていない要因のひとつはそれかなと考えています。ちょうど今、その改善について EM と考えているところで、もうちょっと全体の会議の設定は見直していきたいですね。必要であれば新しいミーティングを設けるべきだし、目的を明文化するのは絶対に必要ですし。共通認識があってないようなものになっていたりしますからね
――芹澤さんは去年、経営会議のような全社の重要会議体を整理してましたよね？ その経験からアドバイスできることは何かあります？
芹澤：定例ミーティングは絶対定期的に見直した方がいいですね。クォーターごとに1回とか。始めたときはいいんだけど、時間が経つと状況も変わるし陳腐化するんですよね。あと目的整理は絶対にやった方がいいです
――プロダクトエンジニアの全体定例も最近1時間ギリギリになっちゃってるなあ
芹澤：「いつもの感じ」が出てくるとどうしてもぬるっとやっちゃうし、みんなこういうものだと思っちゃう。そのうち「最悪なにも得られなくてもいいか」とミーティング自体への期待値が下がってしまう。それって最初からそのミーティングを捨ててることになるから、ちゃんと見直していった方がいいですね
CEO を受け入れた現場側はどう感じたのか
――受け入れた側として感じたメリットとかってありましたか？
山本：SmartHR の7つのバリュー、たった2週間だったけど芹澤さんはすごく体現されていると思いましたね。Working Out Loud されていて、情報を開示されていて。Pull Request も時間がない中でもめっちゃわかりやすく書いてくれたなと思いました。今、カジュアル面談でわかりやすい例として使ってるくらいです笑。役職あるなし関係なくバリューを体現されてるというのは大事だし、芹澤さんに来てもらってチームにいる入社して間もない方にも明確に示すことができました
芹澤：え〜、うれしい
山本：あと、開発スピードや意思決定の早さとかも。開発の過程で出る悩みポイントも、解が出るまでがめちゃくちゃ早い。つまづいたからこうしてみた、違ったからこうした、が早くて。本当はチームとしてもっと早くできたり質を高めたりする余地があるのに、チームの中で一番早い人がそのチームの天井になってしまうことはよくあると思うんですよね。今回、チームに芹澤さんの早さを見せることができてよかった。ベースとするレベルが上がったように感じましたね
――早い方がカッコイイを体現されてたんですね。塚本さんはいかがでしたか？
塚本：フィードバックがありがたかったです。ずっと中にいると、よくないと思っていても正しく現状が掴めなくなる。それを新鮮な目で見てもらって改めて指摘してもらうことで、やっぱりよくないなと感じたし、改めて考えるきっかけにもなりました
――一番刺さったフィードバックはなんですか？
塚本：品質が過剰傾向になっていることですね。やはりそうかと思ったし、それに対してアクションを取れていなかったので
――逆に刺さらなかったフィードバックは？
塚本：刺さってないから覚えてない笑
――また芹澤さんがチームに入りたいと言ってきたら、受け入れたいですか？
山本：はい。僕のチームでも受け入れたいし、他のチームを見てもらうことでまた違う景色が見えるんじゃないかとも思うから、それも面白そうです
芹澤：やった。また歓迎会してもらえるじゃん
最後に
芹澤：小話なんだけど、この前の取締役会でチームに入って開発してきましたという話を共有したんですよ。正直、「何に時間使ってるんだ」って怒られるかと思ってたけど、逆に褒められて。CEO が自らそういう業務の場を見に行くこともいいし、「業務監査」というアクションもあるらしくて。べつの会社だと、役員が実際に自社サービスを使って一連のプロセスを体感する、というのもやっているらしい。めちゃくちゃいいアクションだよね
――芹澤さんが人事労務の担当者として SmartHR を触ってみる？
芹澤：やってみたい！ 現場の緊張感ってある程度のレイヤーになるとなくなっちゃうから。多分僕が人事労務の現場に行ってもなんの役にも立てないと思うけど……
――それでは最後に、久しぶりにイチエンジニアとして開発チームに入ってみてどうでしたか？
芹澤：楽しかった！ CEO 業務を完全に止めることができなくて中途半端になったのが悔やまれるけど。3つくらいチケットを担当したんですが、開発ってすごく楽しいなって思い出しましたね。忘れかけてた気持ち。課題を特定して、コーディングを通して解決していくのは今やってる仕事とは違う脳を使うんですよね。実際作った Pull Request がマージされたときが嬉しい、明確に達成感がある。マネジメントはそういうわかりやすい、短期間で結果が出るものってほぼないですしね。短期的にそれを経験できるのはアドレナリンが出るし、病みつきになっちゃう
――なるほど。アドレナリンに飲まれず、CEO 業もがんばってくださいね
芹澤：はい
――はい
We Are Hiring!
こんな感じで、開発現場に CEO がふらっとやって来たり来なかったりする SmartHR ですが、まだまだ一緒に SmartHR を作りあげていく仲間を募集中です！
これは毎回ブログの最後で声を大にして言うことに決めているのですが、
- SmartHR というプロダクトは完成していてやることがない
- SmartHR の組織は完成していてやることがない
といったことはまったくありません！ 安心してください！ 倒しがいのある課題だらけです！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
