こんにちは。SmartHR VPoE の森住（@t_morizumi）です。
これは SmartHR Advent Calendar 2022 の25日目のエントリーです。つまりクリスマス。
今年は何度かインタビューを受けて記事にしていただいたり、自分をコンテンツの一部としてテックブログを書いてもらったりしていたので気づかなかったのですが、なんと自分自身ではひとつもテックブログを書いていなかったんですよね。反省しております。
さて、年末になるとなんとなく過去の振り返りをしてみたくなるものですね。過去にも未来にも、人間からすると事実上無限に存在する時間という概念を、1年という単位で区切れるようにしたというのは人類の発明と言ってよいのではないでしょうか。スクラムもスプリントがあるからリズムができ、振り返りができるわけですね。
というわけで、過去の振り返りをやっていきます。が、2022年を振り返るわけではなく、僕が入社した2018年8月から今日までを振り返っていきます。意外と長期に渡る SmartHR 開発組織の変遷を書いた記事がなかったので、ここらでひとつ書いておいてもよいかなと思ったのが理由です。
先に注意事項を書いておくと、ここまで読んでいただいておわかりかと思いますが、わりとゆるめのコンテンツです。なぜなら年末に書いているから。僕の記憶や調査力に頼ってこの記事を書いているので、若干事実と異なる記述があるかもしれませんし、説明の便宜上色々と簡略化している部分も多いです（これは主に社内向けの注意書き）。SmartHR の組織はこんな感じで変わってきたんだな〜 とゆるくお楽しみいただければ幸いです。
また、振り返りテイストの記事ですが、最後に2023年という未来の組織についても軽く書いております。
2017年頃の開発組織
2018年8月から今日までを振り返る、と宣言しておいて早速違うことをやっているのですが、以下は僕が入社するより1年以上前の SmartHR の開発組織の組織図です。
すごくシンプルですね。プロダクトオーナーである、労務領域のドメインエキスパートの方とプロダクトエンジニアのみで SmartHR をゴリゴリ開発していた時代です。
アーキテクチャとしても Rails のモノリシックなアプリケーションがひとつあるだけで、こちらもまだまだシンプルな時代だったと言えるでしょう。
2018年8月〜 の開発組織
続いて、僕が入社した頃の組織図です。
大きな変化は、SmartHR 基本機能とオプション機能という概念が生まれていることです。
ビジネス的にはアップセル商材を作るという目的から生まれたものですが、開発の側面から見ると、新しい機能を SmartHR というモノリシックな Rails アプリケーションに追加するのではなく、べつのアプリケーションとして切り分けて実装しようという新しい試みでした。
ひとつのモノリシックなアプリケーションをひたすらに膨張させていくのではなく、別アプリに切り分けることで、
- チームの人数がいたずらに拡大し、コミュニケーションコストが増大するのを防げた
- ソースコードがいたずらに複雑化し、認知負荷が増大するのを防げた
というメリットがあったと思います。
アーキテクチャとしては、SmartHR 基本機能側に REST API のエンドポイントを設け、それを利用してオプション機能が動作する形に変化しています。ちょっと複雑になりましたね。
そして、この「SmartHR 基本機能側に REST API のエンドポイントを設け、それを利用してオプション機能が動作する」という構造ですが、これは後々のプラットフォーム化（サードパーティへの API 開放）を見据えたドッグフーディングとしての側面もありました。
2019年の開発組織
大きな変化は、プロダクトマネージャ / QA エンジニア / デザイナー といった新たな職能が追加された点です。
それにより、これまで仕様検討や品質保証、そしてデザインに至るまですべてをエンジニアが担当していた状態から、専門領域ごとに担当者が存在し、それぞれの専門性を活かして仕事をするようになりました。
すべてをエンジニアが担当していた状態に比べると、（当たり前ですが）各タスクにおける成果のクォリティが向上しました。エンジニア以外の職能ががっつり開発プロセスに入るのは SmartHR では初めてだったため、どのように協業するのかを模索するフェーズだったかなと思います。
組織の専門性が向上したというメリットを享受できた一方、専門家間のタスクの受渡コストが課題となってくるのですが、それはまた後のお話。この頃は専門家がいるってすげえ……！ という素朴な感動を覚えていた気がします。
アーキテクチャとしては大きな変化はないですね。オプション機能側のアプリケーションを増やすことで、SmartHR 本体機能側をいたずらに膨張させない、という方針がそのまま活きています。
2020年の開発組織
ここでの大きな変化は、
- SmartHR 基本機能の開発が LeSS（Large Scale Scrum）によるものとなったこと
- オプション機能が労務系と人材マネジメント系に大別されるようになったこと
のふたつです。
スクラム界隈ではしばしば Q.「スクラムはどのようにスケールさせればうまくいきますか？」 A.「スケールさせないことが最良の方法です」といった会話がなされます（個人の感想です）。SmartHR においてもそれほど積極的にスケールさせたかったわけではないのですが、しかしビジネスの要求が加速していく中でずっとワンチームスクラムを継続するというのは現実的に困難で、LeSS を採用してチームを増やす方向に舵を切りました。
オプション機能もチーム数が増えてきて、労務系と人材マネジメント系のふたつに大別されるようになってきました。祖業である労務領域から一歩踏み出して、人材マネジメント領域も事業の柱としていこう、という方針の表れです。ちなみに、今では労務系オプション機能より人材マネジメント系オプション機能の方が数が多くなっています。
ここでもアーキテクチャ上大きな変化はありませんが、技術的には、
- SmartHR 本体機能の API と繋がるアプリが増えてきたことによる変更の影響範囲の増大
- 多チーム化により SmartHR 本体機能のソースコードの全体像把握が難化
といった課題が出始めていたように思います。
2021年の開発組織
オプション機能の各チームを個別に図示しているととても一枚の画像に収まらなくなってしまったため、労務系 / 人材マネジメント系という大きな括りで表す形に変えました。括弧内の機能ごとにチームが存在すると思ってください。職能の構成は各チームで大差ないので、同じような構成のチームが横並びに存在しているイメージです。
ここでの大きな変化は、
- SmartHR 基本機能のチーム数が 2 -> 6 に増えていること
- オプション機能のプロダクトが 4 -> 6 に増えていること
- UXライターという新しい職種の追加
の三点です。
SmartHR 基本機能のチーム数、オプション機能のプロダクト数については順調にスケールしていっていますね。SmartHR 基本機能についてはひとつのプロダクト、ひとつのリポジトリに対して6チームで変更を加えている状況なので、相互の連携やリリースプランニングのコミュニケーションも一層密なものが求められるようになっています。
UXライターという新しい職種が追加されていますが、これはさまざまなテキスト・コンテンツを通してユーザがつまずくことなく業務を完遂できるよう SmartHR を進化させるために作られた職種です。例えばプロダクト上の文言やヘルプページなどのコンテンツに関わって、それらをユーザにわかりやすく伝えられるようにする、といったことに責任を持っています。
この頃になると、組織内に専門家が増えたことにより2019年のセクションに書いた「専門家間のタスクの受渡コスト」という問題がいよいよ顕在化してきていました。そこで SmartHR の開発組織では「最短距離を行こう」というスローガンを掲げて、主に以下の二点に取り組みました。
- 専門家間のタスク受渡により長大化したバリューストリームの最短化
- 職能横断的なスキルを身につけ、タスクのフロー効率を向上させる、クロスファンクショナル化の促進
上記を達成することで、仮説検証と軌道修正の速度を向上させることを狙ったスローガンですが、わりとうまくハマったのではないかなと思っています。現在では、プロダクトエンジニアがリリースノートを書いたり、品質保証の業務を行ったり、反対にQAエンジニアや UX ライターがプロダクトのコードにコミットしたり、といったことが当たり前に行われるようになってきています。
クロスファンクショナルな仕事の進め方については、以下の記事に詳しく書いてあります。
2022年の開発組織
そしてようやく2022年なのですが、今年の大きな変化は、
- SmartHR Plus（プラットフォーム事業）チームが組成されたこと
- 従業員データプラットフォームチームが組成されたこと
- プログレッシブデザイングループが誕生したこと
の三点でしょう。
まず、SmartHR Plus（プラットフォーム事業）についてですが、これは SmartHR をプラットフォームとしてサードパーティ製のアプリケーションを動かせるようにしようというもので、Apple における App Store、Salesforce における AppExchange の SmartHR 版です。チームの動きとしては、SmartHR をサードパーティにとって魅力的なプラットフォームにするために必要なことはなんでもやるという感じで、公開 API の改善やアプリストアの実装、サードパーティ向けのドキュメント整備やサンプルアプリの開発など、かなり幅広く動いています。
次に従業員データプラットフォームですが、これは SmartHR に溜まった従業員データを SmartHR 内部の別アプリケーションからより利用しやすくすることを目的に現在開発を進めているものです。現時点ではあまり詳しいことは書けないのですが、技術的にも結構おもしろいことをやっているので、詳しく書けるようになったらテックブログでご紹介したいと思います。（僕ではなく開発しているチームが書くであろうはずなのに勝手に「ご紹介したい」とか言っていますが、まあきっと書いてくれるでしょう）
最後にプログレッシブデザイングループですが、これは主にアクセシビリティ対応や多言語化対応を行うメンバーが集まったグループです。元々プロダクトデザイングループを中心にアクセシビリティ対応を進めていたのですが、それをさらに加速させることを意図して作られました。特定のプロダクトを対象として活動するわけではなく、SmartHR の組織全体に対して働きかけるような活動をしています。詳しくは VP of ProductDesign である ouji san の以下の記事をご覧ください。
また、組織図の上では見えない変化として、LeSS で開発している SmartHR 基本機能の開発チームがよりプロダクトへのオーナーシップを持ちやすいように、開発体制の変更が行われていました。SmartHR 本体機能のプロダクトオーナーをしている塚本さんが記事を書いているので、詳しくは以下をご覧ください。
組織の課題としては、SmartHR という会社全体の規模の拡大と、フルリモートワークの導入による組織内コミュニケーションの希薄化が挙げられます。従業員数で言うと、ここ2年で倍以上になっているんですよね。組織内に知らない人や知らないチームが増えてくるとなにが起こるかというと、自分が所属するチームに閉じこもりがちになります。気心知れた仲間と仕事をしている方が心理的にも負担が少ないですからね。これは個々人のマインドの問題とかではなく、人間が組織で行動する上でのある種の法則ではないかな思います。
とはいえ、ある種の法則だよねといって放置しているわけにはいきません。なぜなら、プロダクトは開発チームだけでは作れないからです。より正確に言うと、「顧客にとって価値あるプロダクトは開発チームだけでは作れない」でしょうか。顧客と直接接点のあるサポートチーム、カスタマーサクセス、セールス。そして顧客その人。そういった人たちからフィードバックを受けなくては、顧客にとって価値あるプロダクトは作れないんですね。開発チームだけに閉じてプロダクトを作っている状態は、目と耳を塞いでものづくりをしているようなものでしょう。（補足しておくと、年初の SmartHR 開発組織がそういう状態だったというわけではありません。が、まだまだ伸び代あるよね、という状態だったとは思います）
そこで、2022年の SmartHR の開発組織では「顧客の価値で語ろう」をスローガンに掲げました。これは平たく言うと、顧客にとっての価値という SmartHR 全社員の共通言語で語り合おうぜ、というものです。一見すると当たり前、かつ抽象度がかなり高いので、もう少し具体化するために今年の全社キックオフで以下のような問いを立てました。
- 製品を作ることに集中するのではなく、顧客の価値を作ることに集中していますか？
- 顧客が得られた成果、抱いている不満を知っていますか？
- 「カイゼン」の中心に顧客の価値を置いていますか？
上記を意識することで「最短距離を行こう」で高速化した仮説検証と軌道修正の質を向上させることを狙ったスローガンですが、これもわりとうまくハマったんじゃないかなと思っています。実際の行動としては、開発チームがセールスの商談に同席したり、カスタマーサクセスがどのようにユーザーをオンボーディングしているか教えてもらったり、スプリントレビューの場に多様なステークホルダーを招待するようになったり、顧客の声を直接聞く機会を増やしたり、といった風に表れていました。
2023年の開発組織予想図
そしていよいよ、未来の話です。ちなみにこの未来予想図、そんなに確度が高いわけではなく、森住が勝手にこんな感じかな〜 と妄想している面も多分にあります。
大きな変更点は黄色でハイライトして示しているのですが、箇条書きすると、
- 人材マネジメント系オプション機能がさらに増えます
- プロダクト基盤チームが組成されます
- なんらかの横串系プロダクトが開発されるでしょう
- なんらかのイネーブリングチームも組成されるんじゃないかなあ
こんな感じです。語尾で確度を察してください。
ひとつひとつ見ていくと、まず「人材マネジメント系オプション機能がさらに増えます」はそのままですね。引き続き投資を続けていきます。
次に、「プロダクト基盤チームが組成されます」についてですが、実は SmartHR っていわゆる基盤系のチームが存在しないんですよね。存在する開発チームのほとんどすべてが、特定のプロダクトひとつにコミットするフィーチャーチームなのです。変にコンポーネントチームを作ってバリューストリームを複雑化させない、という方針のもとにそのような体制を意図的に作ってきました。ですが、複数のプロダクトがコラボレーションすることで顧客にとっての価値が高まるといった場面も増えてきたため、ここらで基盤を整備してよりプロダクト間の連携をしやすくしよう、という背景があり、プロダクト基盤チームを組成することとしています。具体的になにをやるかはまだ決まっていないのですが、決まって動き始めたらきっとチームメンバーがブログを書いてくれることでしょう。
「なんらかの横串系プロダクトが開発されるでしょう」については、SmartHR のプロダクト数が増大してきたことと大いに関係しています。現時点で、SmartHR 本体機能 + オプション機能 + プラットフォーム事業で既に二桁のアプリケーションが提供されているんですよね。そうなると、アプリケーション間の体験の差異や、複数のアプリケーションに設定や情報が散らばるといったことが起こってきます。そういった、アプリケーションの数が増えてきて悪化しつつあるユーザー体験を改善するために、それらのアプリに一本横串を通すようなプロダクトの必要性が見えてきていて、2023年はそれも開発していくことになるかなあと思っています。
最後に「なんらかのイネーブリングチームも組成されるんじゃないかなあ」についてですが、これは各開発チームの認知負荷の増大が関係しています。SmartHR の開発チームは、2021年のセクションでもお伝えしたとおりクロスファンクショナルな働き方をしているため、やること・覚えることが比較的多いんですよね。また、各プロダクトの歴史も徐々に積み上がってきていて、ソースコードを脳のメモリに載せる負荷も上がってきています。そういった状況で、開発チームが自ら新しいことを学習し続けていると、どこかで開発チームのキャパシティを超えてしまいます。そういった事態を防ぐために、開発チームにとって調査や学習、実践の負荷が高い領域をイネーブリングしていくチームを組成する必要がありそうだなあと感じています。（ここで言うイネーブリングを超端的に説明すると、開発チームに対して容易に能力を獲得できる機会を作ったり、適切なツールやガイドを提供して実践の負荷を下げたり、といったものをイメージしています）
まとめ
こうしてこれまでの歴史を書き出してみると、毎年いろんな課題があり、そしてそれに応じて変化してきたんだなあということを実感しますね。何気に毎年ちゃんと成長して、ちゃんと新しい課題が出てくる組織というのは貴重なんじゃないかなと思っています。個人的にはすごくいい経験になっていますね。2023年も忙しい年になりそうです。
WE ARE HIRING!!! あなたの助けが必要です!!!
最後に声を大にして言いたいことがあるのですが、これまでの歴史や未来予想をご覧いただいてわかる通り、
- SmartHR というプロダクトは完成していてやることがない
- SmartHR の組織は完成していてやることがない
といったことはまったくありません！ たまにカジュアル面談などで上記のようなイメージがあった、というお話をうかがうのですが、全然そんなことないです！ やりたいことも、やらないといけないことも山盛りです！（特に後者…）
SmartHR ではエンジニアを絶賛募集中です！！！
少しでも興味を持っていただけたら、まずはカジュアルにお話ししましょう！！！！！
