こんにちは。VP of Engineering の森住です。
今回は SmartHR VP リレー連載ということで筆を執っておりまして、僕の回では Alignment（調整）と Autonomy（自律）と Agility（機敏性）の3つの観点から SmartHR 開発組織のこれまでとこれからをお伝えしていきます。なぜ英語表記にしているかというと、A が3つ並んで見た目がおもしろいなと思ったからです。深い理由はありません。
組織
組織を構築する理由の一つは、時間・空間を超えて、一人の人間の努力では達成できないような目標を達成することである。分業・調整・統合の結果である組織のアウトプットが、時間を超えて何年、何十年にもわたって同じ品質を保ち、日本ばかりでなく海外でも同じ品質を保つ。時空を超えた調整・統合の手段があるが故に、組織はいつでもどこでも一定の質をもったアウトプットを生み出せるのである。
突然ですが、みんな大好き『組織デザイン（沼上幹）』より引用です。「時間・空間を超えて、一人の人間の努力では達成できないような目標を達成する」というところがよいですね。
当たり前ではありますが、一定以上の規模の SaaS 事業はどうがんばったって一人の人間だけでは実現できません。むしろ、ソフトウェアビジネスと聞いて想像するよりも遥かに多くの人手が必要です。テックブログを読む方には馴染み深いであろう開発組織をはじめとして、セールス / マーケティング / カスタマーサクセス / カスタマーサポートなどなど、多くの職種が介在して SmartHR というプロダクトはお客さまの手に渡り、利用されることとなります。
SmartHR の従業員数は2024年7月時点で1,000名を超えています。そのうちプロダクト開発に関わるのが270名ほどで、プロダクトエンジニアに絞ると150名ほどです。プロダクトエンジニアの人数は「思ったより少ないですね」と言われることが多いです（絶賛採用中です…！）
それだけの人数が関わる中で日々プロダクトを改善し、新機能をリリースし、フィードバックを受けてさらに改善し、というサイクルを高速で回していく必要があります。Agility（機敏性）ですね。
では、SmartHR の開発組織ではどのようにして Agility を確保してきたのでしょうか？
Autonomy（自律）
SmartHR のバリューには「自律駆動」というものがあります。説明文をコーポレートサイトから引用します。
SmartHRは「100の問題を100人で1問ずつ解く組織」を目指す。そのために、情報をオープンにし、フラットな状態をキープすることを約束する。ひとりひとりが指示を待つのではなく、みずから解くべき問題を見つけ出そう。そして、自分で判断し、主体的に行動を起こしていこう。
「100の問題を100人で1問ずつ解く組織」がポイントで、これは会社に山積する問題をマネジメントレイヤーなど一握りの人たちが解くのではなく、全員で並列に解いていこうということを意味しています。そのために、意思決定可能な状態（情報・権限・責任が揃った状態）を作ることに経営陣がコミットしますよ、という宣言でもあります。
SmartHR の開発組織はこれまでそれを実践し続けています。現在20近くプロダクトがありますが、それぞれのプロダクトを担当する開発チームが自ら投資優先度を決定し、開発プロセスを決定し、自律してお客さまの問題を解決できる状態にしています。チーム内で基本的に意思決定が完結することが Agility の確保につながっているのです。
チームが自律的に意思決定できるよう、アーキテクチャもまたチーム外の影響を極力排して開発できるよう設計されています。インフラは各プロダクトごとに Google Cloud のプロジェクト単位で分離されていますし、GitHub リポジトリもそれぞれに分かれています。インターフェイスとなるのは基本的に REST API（たまに GraphQL も） で、その境界面さえ壊さなければ内部がどのように振る舞っていても気にする必要がないようにしています。
そのため、上長になんらかの判断を求めることは言わば「例外処理」です。例外処理について、再び『組織デザイン（沼上幹）』より引用します。
優秀な管理者の例外処理能力がボトルネックなのだとすれば、前章のボトルネックに関する議論をメタファーとして思い浮かべることで、いくつかの具体的な手段が見えてくるはずである。これらの手段は基本的に三種類に分けられる。すなわち、（1）判断能力のある下位階層の構築、（2）管理者の例外処理能力の開発、（3）管理者の例外処理能力を補強する構造の構築の三つである。それぞれ簡単に解説しておこう。
（1）判断能力のある下位階層の構築——自律的作業集団・職場集団
上程される例外の数が多すぎる理由の一つは環境の不確実性が大きいことであり、もう一つは組織メンバーの熟練が不足していることである。それ故、組織メンバーの側の熟練が十分に蓄積されていれば上程される例外の数を減らすことが可能である。つまり適切な判断力を現場の集団にもたせれば、上司が判断しなければならない問題の数が減るのである。
このように、管理者の例外処理能力がボトルネックにならないための手段のひとつとして「判断能力のある下位階層の構築」という表現で自律的なチームづくりが挙げられています。
これまでの SmartHR 開発組織は、強引にまとめてしまうと「現場レベルの Autonomy を確保し、マネジメントレイヤーでの Alignment を極力減らすことで Agility を確保してきた」と表現することができます。
Alignment（調整）
では、今後もその方針で開発組織を運営し続ければ SmartHR は目指すゴールにたどり着けるのでしょうか？
答えは、半分 Yes で半分 No です。まずは、SmartHR の現在のフェーズである「スケールアップ企業」について CEO の芹澤さんの記事から引用します。
スケールアップ企業の特徴は「製品の市場テストが完了し、規模拡大を行う段階」で「組織・事業ともに急成長する」とされています。これはまさしく、スタートアップ企業にも大企業にもなれない僕たちにぴったりの段階であり、僕が目指したかった「SmartHRらしい大企業」に辿り着くためのヒントのように思いました。
スケールアップ企業のキーワードは「規模拡大」と「急成長」です。ポテンシャルの高い製品とそれを拡大する優れたメンバーが揃い、大きな組織で大きなことを成し遂げていけるようになるタイミングです。
スケールアップ企業のキーワードは「規模拡大」と「急成長」とあるように、SmartHR は引き続き急成長を続けており、プロダクトラインナップも拡大を続けています。以下は、シリーズEの資金調達の発表と合わせて行われた新プロダクト発表会の資料より抜粋したものです。
急成長とともにプロダクトラインナップも急拡大していくと、様々な課題が表出してきます。以下に例を挙げます。ほんの一部ですが。
- プロダクトに利用したい従業員データをどこ（どのプロダクトの DB）で持つべきか判断する基準がなく、チームに閉じた意思決定により部分最適化されたデータの持ち方になってしまう
- 権限など全プロダクト共通で持つ機能が各プロダクトごとに実装され、車輪の再発明が起きたりユーザー体験が断片化する
- 複数のプロダクトが連動することで初めてユーザーの業務課題を解決できるが、連動のための調整コストが大きい
このように、全体最適なアーキテクチャの構築をどう実現するかという技術寄りの課題以外にも、組織内のコミュニケーションの課題も多く出てきています。Alignment の重要性が増してきている、と言い換えることもできるでしょう。
表出してきているプロダクト横断的な課題は今の SmartHR にとって「例外処理」となるため現場もマネジメントレイヤーも対応コストが大きくなってしまいます。
これが半分 No と答えた理由で、明らかに今のステージから新しいステージに進むべきタイミングが来ています。では（極端な言い方ですが）、現場の Autonomy を捨ててマネジメントレイヤーでの Alignment を強化する以外に道はないのでしょうか？ そんなことはないだろうと、僕は考えています。
Agility（機敏性）
三度、『組織デザイン（沼上幹）』から引用します。
素人の時にはどれほど頭脳明晰な人間でも事前に予想していなかったことが発生するが、特定の専門領域で経験を積むにつれて多数の例外を処理した経験を蓄積し、予測可能な範囲が増えていく。だから、不確実性とは環境の側の特徴であると同時に、環境に対応しようとしている人間の側の特徴でもある。不確実性は人間の側の予測能力の問題でもあるので、それは組織学習を通じて時とともに変化していく。それ故、いまとなっては定型的な業務も、まだ不慣れだった創業期には不確実性の高い業務であった。逆に、将来的には定型的な業務になるはずのものも、現時点では不確実性が高い、ということも起こりうる。
（中略）
不確実性を下げるためには、熟練を積むこと、知識を蓄積することばかりでなく、競争相手や顧客よりも速く、より洗練された知識を身につけることが重要なのである。
今の SmartHR 開発組織はこれまでのやり方が通用しない、不確実性の高い領域に足を踏み入れています。その中で重要なのが Agility であり、Agility こそが SmartHR の競合優位性のひとつだと考えています。
Agility と聞くとプロダクト開発サイクルが速い、といった連想をされるかもしれませんが、SmartHR の強みは開発のみでなく学習の速さにあります。学習とは、実行し、結果を検査し、適応していく一連のサイクルです。環境の変化を察知し、機敏に適応していく組織能力こそが SmartHR の強みです。
「例外処理」が増えてきた中で、すでにいくつか実行・検査・適応のサイクルが回り始めています。例えば、全体最適なアーキテクチャを検討し、適用していくためのチームを組成しました。僕はそのチームの活動にオブザーバーとして参加していますが、（まだ組成から間もないながら）20を超えるプロダクトが連動していく環境下での Autonomy の新しいあり方が作られ始めているのを感じています。
「現場レベルの Autonomy を確保し、マネジメントレイヤーでの Alignment を極力減らすことで Agility を確保する」という方針で SmartHR は目指すゴールにたどり着けるのか？ という質問に半分 Yes と答えた理由は、機敏に適応していく組織能力こそが SmartHR の強みだと考えているからで、そして機敏な適応は現場レベルの Autonomy の確保なくして実現し得ないと考えているからです。
プロダクト開発は学習の連続です。技術、開発プロセス、顧客、市場、ドメイン、競合、etc… さまざまなものごとをインプットし、それをアウトプットした結果を検査し、また適応を続けていきます。検査と適応のループを回していくためにはチームが自ら「なにを、どのように作るのか」を決定できる必要があります。自分たちで実験手段を選べない環境では学習する意欲すら失われていくでしょう。それが Autonomy が不可欠な理由です。
不確実性が高まっている SmartHR の現状は例外処理が増え、学習負荷も高まっている状態です。ですが、僕たちは学習を経て新たな標準化や調整機構の設置、組織のリデザインを通して不確実性を削減し、マルチプロダクト開発を当たり前のことにしていくでしょう。
その過程で多くの課題に出会い、適応するために学び、そしてユーザーの深い課題を解決できることがスケールアップ企業で働くおもしろさであり醍醐味です。
WE ARE HIRING!
SmartHR ではエンジニアを絶賛募集中です！
歴史に残る模範的なソフトウェアを一緒につくりませんか？
少しでも興味を持っていただけたら、まずはカジュアルにお話ししましょう！！
SmartHR VPリレー連載の第4回は、VP of Brandingの 岡本さんの記事をお届け予定です。（記事はSmartHR のnoteにて公開予定です）
前回のVP連載記事はこちらからご覧ください。
