HERPの開発組織では、オープンでフラットな文化が根付いています。一方で、プロダクトが成長し、開発規模も大きくなるとフラットな議論だけでは解決できない課題も出てきました。そこで2024年4月から、「エンジニアリング組織」を立ち上げ、そのリーダーとしてtaketo957（たけと）が就任しました。なぜ開発組織にリーダーを置くのか。現在どんな課題に向き合っているのか。taketo957とHERP代表の庄田が語り合いました。

（聞き手：宮﨑章太（まざっち） HERP ソフトウェアエンジニア）

決める“人”も“スキル”も不足していた

——エンジニアリング組織とはどんな組織でしょうか。

taketo957：エンジニアリング組織は、プロダクト開発や事業活動とは別に、技術的な活動を横串で行うチームです。事業活動を推進していくうえで、技術的な要素を考慮した意思決定を行い、課題があれば特定して解決のために動きます。

以前から草の根的な活動を行っていましたが、満を持して組織化したのが2024年4月。そのタイミングで、私がリーダーとして就任することになりました。

——エンジニアリング組織の発足には、どんな背景や課題がありましたか。

taketo957：事業が拡大するにつれて、技術的負債などの解決しなければいけない課題が積みあがっていましたが、解決のための意思決定をできるエンジニアがいなかったんです。私を含めて議論はできるのですが、前に進まない。その結果、開発スピードが遅くなるという課題がありました。

庄田：エンジニアのメンバーたちもその問題には気づいていて、私も1on1で聞いていました。組織課題解決担当のメンバーが発言してなんとか引っ張りながら、物事を進めていた様子でした。そうしたメンバーからは「課題を叫ぶことに労力を割いていて、エンジニアとしての仕事が進まない」という相談も受けていたんです。

創業時は私も意思決定に関与していましたが、開発組織が大きくなるにつれて一任するようになっていた。それでも何とか進んでいたので任せっぱなしになっていましたが、「いよいよ何とかしないとまずい」とテコ入れを始めたのが、2023年後半ごろでした。

最初は、専門のチームを作って、そこに権威を与えることで、意思決定を進められるように図りました。

taketo957：僕を含む3名のチームに意思決定を任されました。1人ではなく3人にしたのは、それぞれの技術的な強みを生かして全体最適な意思決定をする狙いがあったからです。しかし、3人の合議にも時間がかかってしまった。

庄田：また、当時は意思決定する「スキル」も足りていなかったと思っていて。はじめは物事を決める人を設定すれば、意思決定が進むと予想してチームを作ったわけです。

でも、ビジネススキルとしての「決めきる力」が足りず、思ったより課題解決が進まなかった。僕も開発組織のメンバー一人ひとりの決める力を培う支援をするということはやってこなかったので、当たり前ですよね。

そこで、一人のリーダーを置いて「決めるスキル」を身につけてもらうことで、意思決定のできる組織を目指そうと考えました。エンジニアリング組織を立ち上げて、そのリーダーをtaketo957に任せたのはそういった経緯です。

——taketo957さんが適任だと思ったんですね。

庄田：リーダーには人としての成熟度も必要だと思っていて。周りの人がついていきたいと思えて、僕も安心して任せられる誰かがいたら、と思っていました。長年開発組織に責任者を置いていないのは、そういった人柄とスキルを備えた人材と出会えるまで無理に置く必要はないと思っていたからなんです。

でも、待っていては組織が前に進まないし、新規事業を進める上で横串の技術課題の重要度がこれまで以上に高まっていました。そこで、素質を持った人を抜擢して成長支援をする方がいいなと考えたときに、taketo957が手を挙げてくれたというわけです。

taketo957はエンジニアメンバーからの信頼もあって、モチベーションも安定しているので適任だと思いましたね。もちろん、技術的な知見と経験の豊富さも、安心して任せられるポイントです。

——taketo957はなんでリーダーをやってみようと思えたの？

taketo957：自分のエンジニアとしてのキャリアを長い目で見た時に、もっとビジネス領域に関わっていきたいと思っていたんです。組織の課題に向き合うことで、事業に貢献する役割だと思い、やってみたいと思いました。

——とはいえ、いきなり一人で意思決定の責任を負うのはプレッシャーでは？

taketo957：いわゆるパラシュート人事なので、難しいことばかりでした。前職まででCTO経験があるわけでもない自分が、リーダーとしての役割を全うできるのか。皆の納得感を醸成しながら同じ方向に導いていけるのか――といった不安がありました。

そこで、信頼関係を築くための努力をかなりがんばりました。エンジニアのメンバーたちとの対話を大事にして、「こういう方向に進もうと思っている」と伝えることで、実際にメンバーに動いてもらうときにもスムーズにできているのかなと思います。

さらに、「チームとしての意思をまとめにいく」こと自体もチャレンジングで、不安もありました。

——意志決定のスキルはどのように習得していったのですか？

taketo957：実は、「自分に事業側の判断ができるのか？」という不安は今もあります。適切な意思決定をするためには事業・戦略の理解も大切で、その点はまだまだ学習が不足しているので、経営陣を中心にコミュニケーション機会を作って、キャッチアップしています。

ただ、庄田さんからひたすら言われていたのは「決め方を決めることが大事」という話。そして「課題の特定」が重要であるという話も、僕に刺さりました。

庄田：僕が社会人2年目のころに言われた「課題が特定された瞬間に仕事は終わっている」という話ですね。現場レベルでの課題で、誰も目にしたことのないものはほとんどないはず。つまり解くべき課題が分かれば、やるべき仕事は終わったも同然というわけです。

taketo957：なので、エンジニアリング組織の活動は、課題の特定にかなり力を入れています。その上で、周囲のメンバーと目線を合わせる。そうすることで納得感を持ってもらい、課題解決に向けて円滑に動いてもらえると感じています。

課題マップで特定した3つの課題

——課題の特定に注力する中で、具体的にはどういった課題を見つけましたか？

taketo957：まずは「課題マップ」を作りました。エンジニアのメンバー皆で集まり、それぞれが感じている課題を出し合って重要度を特定する営みです。課題同士の依存関係も洗い出して「ここを動かせば、一番効率よく問題が解決していくだろう」といった仮説も立てて、解決に向けて動き出しました。

その中で浮き彫りになったのが、3つの課題です。

一つは、エンジニアリングリソースの配分の課題。短期的な事業成果や、直近の技術課題の解決に偏っていることが問題でした。特に技術的負債への対応には組織として対応ができておらず、開発速度の低下や障害発生率の高まりなどに影響がでていました。

二つ目に、技術選定の課題。黎明期からマイナー技術を特に振り返ることもなく採用し続けていることによって、採用やエンジニアのチーム異動などにもネガティブな影響がうまれていました。採用や育成において魅力を訴求できないことや、開発者自身の採用技術に対する納得感が薄いために技術的な知見が蓄積されにくく、メンバーの学習が進まないことにもつながっており、さまざまな問題の根幹ともいえる課題でした。

三つ目に、マルチプロダクトにおけるデータやアセットの持ち方について。これは明確な課題というよりは、「現状のやり方は最適ではないのでは」という仮説がありました。

——それぞれどのように解決を進めてきたのでしょうか？

taketo957：リソース配分の問題に対しては、「ICU」と名付けた取り組みを行っています。これは「集中治療室」のように開発者が集まって機能開発以外の重要な課題解決に月数時間を充てるというものです。

会社として「非機能要件の改善や技術的負債の解決にリソースを投下します」と宣言して、その配分でやる方法もあり得たのですが、何割かのリソースを割いて少しずつ進めるのでは時間がかかり、解決に至るまでにうまく行きづらいという負の成功体験が溜まっている状況でした。まずは、重要な課題解決に集中的に時間とリソースを投下して、そこに対する手応えを開発者自身が実際に感じてもらって成功体験を得てから、各開発チームにリソースを充てよう、という目論見で進めてきました。

実際にICUを繰り返し実施することで、開発者が機能開発以外の改善に手応えを感じるようになり、プロダクトスコープで上述の課題マップが生成されたりし、最近では機能開発チームの目標に技術的負債の返却が盛り込まれるというような変化が組織におきました。

技術選定については今も課題に向き合っている最中ですが、新しい技術に関しては選び方の原則を定めました。また、これまでの技術選定を振り返ることで、次の技術選定に生かそうと、現在取り組んでいます。まず、技術に振り回される時間を減らすことと、開発者自身が決めることを原則としました。その上で各チームでの振り返りや意思決定の記録や選定基準への反映を繰り返していき、バラバラだった方針を緩やかに揃えていくことを目論んでいます。僕たちは黎明期からHaskellを開発言語に採用していることから、社内に関数型プログラミングに精通した方が多いのですが、その個性が反映されつつも上述の問題が解決されるような選定に落ち着いていけると面白いですね。

また、三つ目のデータやアセットについてはHR Platformという専門組織を立ち上げることで、その課題に向き合っています。

HERPは現在、「企業と求職者のマッチング力を支援し双方の意思決定を滑らかにする」ために、もともとあった『HERP Hire』に加えて『HERP Careers』や『ジョブミル』 『HERP Trust』といった新規のサービスを提供し始めています。これらの複数プロダクトでシナジーを生むためにはどのようなデータをどう共有すると良いのか、例えば求職者情報・求人情報・企業情報としてどのような情報をどのようなスキーマで持つと良いマッチングを生み出せるのか、といったことを検討するために、各プロダクトに知見を提供してもらっています。

（HERPの複数プロダクトの事業戦略についてはこちらもご覧ください！）

——エンジニアリング組織のリーダーとして、どんなところに楽しさややりがいを感じていますか？

taketo957：組織という複雑なシステムに向き合うのは、対象がコンピュータから人に変わっても、エンジニアとして純粋に楽しいですね。また、メンバーに真剣に向き合っていると、相手も真剣に答えてくれる。たとえそれが違う意見でも、そういうコミュニケーションができるのは面白いです。自分一人ではできなかったことが、できるようになりつつある感覚があります。

エンジニアリング組織のこれから

——エンジニアリング組織は、今後どんな課題に向き合っていきますか？

taketo957：引き続き、自分を含めたリーダーたちで意志決定できるスキルを高めていきます。これまではフラットに議論することだけが重視されていて、それが習慣になっていました。これからは議論の先に結論を出せる文化に変えていく必要があると考えています。そのためには、リーダー間で「決めることが仕事」という意識を共有しなければなりません。この意識の醸成は、まだまだこれからかなと思っています。

また、開発組織では心理的安全性を引き上げる必要もある。というのも、メンバーそれぞれが感じている課題を1on1では言ってくれるものの、全体の会議の場では発言されないことが多いんです。皆が思ったことをその場で言い、解決に向けてすぐに動ける組織を目指して、コミュニケーションを改善していきたいですね。

さらに、具体的に対策を決めなければいけないものとして、運用工数削減の課題もあります。事業戦略に寄り添う最適な技術構成を明確にすることも重要な課題です。

このように、解決するべき課題がまだまだあります。

——庄田さんとしては、エンジニアリング組織にどんなことを期待しますか？

庄田：HERPはプロダクトを開発・提供する企業として、開発領域に対する投資も大きい。開発に関する重要な意志決定が当たり前に適切になされる状態になることが、経営上必要不可欠なんです。

特に、開発に対するリソースだけでなく、採用やリファクタリングなどにもどう工数を分配していくのかは難しい問題です。どうしてもビジネスサイドだけでは新機能をできるだけ早く開発することを優先したくなってしまう。エンジニアリング組織は、開発の視点から技術的な問題や予算も考慮したうえで「何にどれだけ投資するか」を意志決定できる組織を目指したいですね。

その際に、人依存ではなく、組織としての考え方に従って意思決定ができることが理想です。これまでの課題解決は、課題感を抱いた誰かがScrapboxに意見を述べて、そこから会話が生まれて取り組みが始まる、という個人起点のものが多く、最終的な結論に至るプロセスにおいても個人の考え方を統合して答えを導き出す形になっていた。そうではなくて、組織としての価値観や判断基準を全員が理解して、ある意味それに沿って誰もが同じ意思決定にたどり着けるようにしていく努力が必要だと思います。同時に、上記の決め方を決めることでスムーズに意思決定していけるケーパビリティを会社として持てるようになりたいです。

——最後に、HERPの開発組織ではどんな人と働きたいですか？

taketo957：さまざまな意味で人と向き合うエンジニア組織にしたいと思っているので、「人と向き合える人」と働きたいですね。これには3つの意味を込めています。

一つはHERPが採用ドメインの事業であることと通じています。「採用によって新しい人が加わることで組織が変わる」ということに共感できる人であってほしいです。

また、僕は人生に熱意がある人が好きで。周りの人や組織人としての自分だけでなく、「自分自身という人」も大事にしてほしい。自分がどうしたいのか考えることが、技術者視点での意見にもつながると思うからです。

三つ目は、今後HERPの開発組織が強化していきたい点なのですが、「人と一緒に物事を動かすことができる人」に来てほしいです。課題を見つけたり解決することは得意でも、組織として目の前の人とどう進めるかを考えるのは、まだ苦手なのがわれわれの組織です。他者に寄り添って、組織としての動き方を考えられるという意味でも、「人と向き合える人」が加わってくれたらうれしいです。

HERPの開発組織では、ともに働いてくれるメンバーを募集中です。ご興味のある方は、下記フォームよりお申し込みください！