現代のビジネスにおいて、事業・サービスの拡大に伴うITシステムの規模も拡大を伴うもの。それは人を入れればよい、ツギハギでシステムを大きくすればよいというものではありません。

今回の記事では、国内最大のITエンジニア向け転職・就職・学習プラットフォーム、そして当媒体を運営する、paiza株式会社のVPoEとテックリードの対談をお届けします。

同社は、2012年に事業をスタート。この10年でサービスは拡大し、それに伴いシステムの規模も格段に大きくなりました。VPoEの渡嘉敷唯誠氏は、2020年10月に入社。入社時はエンジニアリングマネジャーとして、それまでエンジニア組織のリーダーとして役割を一手に引き受けていたテックリードの高村宏幸氏と改革に着手します。

ツギハギで大きくしてきたシステムは技術的負債を抱え、負荷に耐えきれなくなる寸前。また、エンジニア個人の成長に注力できておらず、組織体制を整える必要もありました。

事業優先で突き進みぶつかった組織の課題

――今回は、現VPoEである渡嘉敷さんの入社を起点にした、エンジニア組織の変化についてお伺いします。まずpaizaへ来る前の経歴について簡単に教えてください。

渡嘉敷唯誠氏（以下、「渡嘉敷」）：エンジニアとして最初のキャリアは、ソフトウェアハウスでの受託開発です。15年ほどして、BtoCのサービスに携わりたいと思い、株式会社カカクコムへ。そこで新規事業開発の部署に配属され、エンジニアリングマネジャーのポジションで6年務めました。新規事業系サービスのリリースとクローズを繰り返し、そろそろひとつのサービスに注力したいという思いから、前職の千株式会社に転職しました。マネジャーとして開発組織を整えるという役割がひと段落したあたりでpaizaに出会ったという経緯です。

――渡嘉敷さんが入社したころ、paizaのエンジニア組織はどのような状況でしたか？

高村宏幸氏（以下、「高村」）：わたしが前職のメーカー系SIerからpaizaに転職してきたのは2016年3月です。当時は、今よりもっとスタートアップ色が強く、目の前にあるサービス課題に対処すること、事業をどうにかして売上げを立てること、そして長い目で見て効果的な施策、とにかくやることがたくさんありました。

ただ、会社のフェーズ的に目の前の課題にフォーカスせざるを得なかった。そのため長距離走をする概念が乏しく、エンジニア組織にもあまり目を向けられていませんでした。エンジニアの退職率も高かったですね。

開発を進めていくにあたって、エンジニアとして「目の前にあるシステム的な課題をなんとかする」は必ずやるべきことですが、それだけでは駄目なんです。

――どうしてもサービス初期はコストの観点などから、長期の運用を見据えた施策は打ちづらい部分がありますよね。

高村：そのとおりです。そこでエンジニアLTV（Life Time Value、元は「顧客生涯価値」という意味）という言葉を使って、エンジニアに長くいてもらえるチームと組織をつくり、システムの健全化もしていきたいと考えました。

「システムと『人・チーム・組織』の両輪でしっかりやっていこう」と決めた方針自体は間違っていなかったと思っています。ただ、わたしの強みはシステム面にあったので、組織づくりをやってはみたものの正しいかどうかがよく分かりませんでした。

外部CTOの方にメンタリングしてもらいながら進めていた時期もありましたが、これから地に足をつけてやっていくためにも、組織の課題にじっくり向き合える人が社内に必要だと思いました。それから1年ほど採用活動を続けて、ようやく見つけたのが渡嘉敷さんでした。

採用を強化し、チーム制へ。システム健全化へ一歩前進

――ここからは、当時のエンジニア組織の課題と、渡嘉敷さんが入社されて変化や改善があった点について、具体的に伺えればと思います。

高村：課題は大きなものに絞ってもいくつかありました。まずはエンジニアの採用をわたしが片手間でやっている状況を改善したいと考えました。

渡嘉敷：わたしが入ってすぐのpaizaのエンジニア組織は、スクラム開発はうまくいっているようにも見えましたが、チーム感がなく個人単位で成り立っていました。それは構造上、高村さんがリーダーとして上にいて、メンバー全員がその下にフラットに並び、しかも事業ごとに区切られていたからです。エンジニアの人数自体が少なかったので、事業制といっても担当のエンジニアは1人ずつという状況でした。

そのためまずはチーム化を見据えて採用を始めました。わたしのほうで採用を完全に巻き取って、高村さんにはサービス改善に集中してもらったのが最初に取り掛かったことだったと思います。

――エンジニアの経験者採用は難しいと言われますが、どのように進めていったのでしょうか？

渡嘉敷：採用サービスをいくつか利用してスカウトを打つなど地道にやりました。結果的にではありますが、入社の意向を固めてくれたのは「paiza転職」で応募してくださった方が多いですね。当然、paizaのサービスに登録してくれている方に、「エンジニアとしてpaizaを一緒につくりませんか」というメッセージが伝わりやすかったんだとは思います。

高村：TwitterのDMでコンタクトを取って入ってくれた人もいます。

渡嘉敷：そうして採用を進めていくのと同時に、高村さんが担っていた管理業務などを剥がし、役割を整理しました。入社後1年ほど要したと記憶しています。

――なるほど。ある程度採用が進んだあとのことも教えてください。

渡嘉敷：2021年9月に実施した、paiza全体の組織変更のタイミングでエンジニアをいくつかのチームに分けました。

そこから別の課題に取り掛かることになります。paizaは事業に対してのアプローチ、つまり機能開発や改善はよくできている一方で、技術的負債に関してなかなか根本的な解決ができていない状態でした。高村さんだけのころから「DX向上デー」（「Developer Experience（開発体験）向上のための負債解消に取り組む日」をpaizaではこう呼んでいます）を設けて取り組んではいたものの、人数も少なく、インパクトが出せていませんでした。

サービスの土台がしっかりしておらず、バランスの悪いところに機能を積み重ねていってしまうと、「システムをきれいにしたい」と思っても、まず上に乗っている部分をどかすという余計な作業が発生することもあります。

売上をn倍にする目標を掲げたとしたら、単純計算でトラフィックもn倍になります。paizaはむしろ2倍も耐えられるかどうか…この土台をきちんとしておかないと将来大変なことになると思ったんです。

――SREに着手したのがそのあたりなんですね。

渡嘉敷：そうですね。しかし、SREを担当できるエンジニアの採用は難しく、かと言って時間が過ぎるのをただ待ってもいられない状態でした。しかも専門性の高い領域なので既存のメンバーでの対応も難しい。そのため一時的に業務委託の方に入っていただき、高村さんと土台の立て直しを進めてもらいました。

高村：昨年の秋にSREエンジニアが入社して、社内に体制が整いました。

――全体的にエンジニアの人数も増えましたよね。

渡嘉敷：今いるメンバーは、paizaというサービスが好きで入ってくれた人が多いのも要因のひとつかとは思いますが、メンバーがモチベーションを保って仕事ができる環境づくりに取り組んできたつもりです。順調に規模が拡大できているのはうれしいですね。

課題解決は長期戦。試行錯誤でよりよい解決策へ

――さきほど役割を整理した話がありましたが、渡嘉敷さん入社後に高村さんの役割や実際の業務はどのように変わりましたか？

高村：渡嘉敷さんに採用をはじめとした組織づくりに関する大部分を任せたことで、わたしは自分のチームに集中しつつ、インフラ周りの課題に本腰を入れて取り組めるようになりました。

――渡嘉敷さんが最初に感じていた課題はある程度解消できましたか？

渡嘉敷：多くはまだ途中ですね。組織づくりは長期スパンでやっていくものですし、事業の状況やフェーズによって方針を変える必要も出てきます。

中でもエンジニアの目標評価制度は難しく、今でも模索中です。

――エンジニアの評価方法に悩んでいる企業は多いですよね。

渡嘉敷：エンジニアだけの評価基準であればもう少ししっくりくるものがつくれると思いますが、会社にいるのはエンジニアだけではないので、整合性をとるのが難しいですね。

また、エンジニア独自の評価というとスキル面になりますが、事業会社なので事業への貢献も評価に含めないといけません。

高村：paizaはまだ目先のやること・やりたいことが細かく変わっていくフェーズでもあるので、半年前に立てた目標をいざ振り返ろうとなってもズレることもあります。見直しや置き換えもしますが悩ましいですね。

米国のようにジョブディスクリプションがあって、そのポストに就いたら昇給という仕組みであればまた全然違うと思います。しかし、paizaは「成長」というキーワードも大切にしていますので、「事業に貢献しながらスキルをどう高め、成長したか」も評価したいんです。当然、自学自習で成長しましたでは物足りないわけです。バランスを取りながら評価制度に落とし込み、paizaがオピニオンリーダーとして何か示せたらという思いはあります。

渡嘉敷：評価制度はまだまだ改善の余地があります。「これだ！」という答えは出ないにしても、引き続きその課題とは向き合っていかなければならないと考えています。

――ある程度解決した、もしくは手応えを感じていることはありますか？

渡嘉敷：もちろんうまくいっている部分もあります。たとえば、エンジニアを少人数のチームに分けたことで物事が並列で進むようになりました。チーム間の連携は今後より強化していくつもりですが、各チームが主体性をもって開発を進められている手応えは感じています。

チーム化の最大の目的は、誰かが欠けてもタスクを進められることにあります。過去の組織体制だと、個人商店のような状態だったので一人欠けると止まってしまっていたんですね。

自社サービスといっても、機能リリースのタイミングは決められているので、その状態は事業的に大きなリスクになります。チームであれば最重要な部分は残してオプション的な部分は落とすか、フェーズを分けて実装するなど対策を講じられます。また、サービスのスケールを考えたときにもチーム化は必須でした。

高村：そのとおりですね。今は安心して開発に取り組める環境になりつつあると思います。

――技術的負債の返上については現在どうでしょうか？

渡嘉敷：月に2日間の「DX向上デー」を設け、その日は事業系のタスクは一旦置いて、技術的負債を返すことに集中します。

高村：DX向上デ―にしていても、ビジネスサイドから優先度の高い依頼が入り、そちらの対応に時間を割いてしまうことも考えられます。そのため振り返りをおこなって、おざなりにならないように気をつけています。

今ではメンバーから自発的に「来月は日付を固定してやってみたい」などトライが出てくるようになりました。

渡嘉敷：トライアンドエラーの思考が育っているのを感じられますよね。

個人と会社の未来を見据えて、リーダー経験の機会をつくり出す

――エンジニア組織をつくる上でのこだわりや、目指しているところはありますか？

高村：渡嘉敷さんに入ってもらう前から、「エンジニアが長くいてくれるだけでなく、長く成長し続けられる環境にしたい」という思いがありました。評価の話とも関連しますが、エンジニアが持っているスキルを生かして事業貢献をして、事業もエンジニアも成長できる組織であることが理想です。

そのためにやりたかったことのひとつが、リーダー育成の文化をつくること。メンバーをリーダーに任命するだけならわたしでもできますが、それでは本当の意味でリーダーを生み出したとは言えません。

渡嘉敷：さきほどエンジニアをチームに分けた話をしましたが、各チームにはリーダーがいて、タスクの取りまとめと他部署とのインタフェースの役割を果たしています。

ただ、メンバーはほぼ全員リーダー経験がないところからのスタートでした。そのため現時点では、リーダーの役割をそこまで強く求めてはいません。インタフェースの役割もリーダーに一点集中しすぎると他のメンバーが育ちませんし、ボトルネックにもなりやすいので、バランスをとるようコントロールはしています。今はリーダー候補を育成中と考えていただくと分かりやすいと思います。

高村：まだ道半ばではあるものの、リーダーになれる人材を育成できつつある実感はわいています。今は少人数のチームリーダーですが、ゆくゆくはもっと大きなチームや、エンジニア組織でリーダーを務められるような人も出てくるのではないでしょうか。

それと関連して、以前は個人で取り組んでいたDX向上デーを、現在は事業系タスクのチームとは別に「○○委員会」という名称にしてチームで取り組んでいます。普段の業務ではチーム内のメンバーとだけ関わることが多いので、他チームとの情報交換も兼ねて。この委員会では、事業系タスクのチームとは別の人にリーダーを担ってもらっています。

――皆さんあまりリーダーになることに抵抗はないですか？

高村：期の終わりにアンケートを取っていて、「前期にやったので今期はいいです」と言う人はいても、大半はやってみてもいいと言ってくれますね。

前職のSIerではリーダーを経験するとなると、最初からプロジェクトのサブリーダーなど責任の重い役割になりがちでした。それではちょっと試してみるといった体験が難しい。そのことが頭にあったので、事業のタスクから離れたところで、気軽にリーダー経験が積める文化をつくっているところです。

――苦手意識がある方もいるとは思うのですが、案外きっかけがなかっただけで、やってみると「向いているかも？」と気づくこともできるかもしれないですよね。

高村：リーダー候補を育成している目的はもうひとつありまして、組織のスケールには実務未経験の方や新卒学生も含めた採用が欠かせません。これまでも何名か採用し、育てましたが、現状はわたしがつきっきりにならざるを得ない。その状況を変えて、受け入れ体制を整えるためにもリーダーを生み出すことは不可欠です。

渡嘉敷：長期的な取り組みにはなりますが、paiza自身がIT人材を輩出する企業でありたいですね。

paizaの全成長を支え、役割を担うために

――最後に、エンジニア組織の将来像についてお聞かせください。

高村：paizaはエンジニア向けのサービスを提供しているので、社内はもちろん、他のエンジニアから見ても「paizaのエンジニアって生き生きしてるな。輝いてるな」と思ってもらえる組織にしていきたいです。

渡嘉敷：エンジニア組織は、事業とエンジニアがともに成長していける環境であることが一番大切だと思っています。

高村さんも言っていたとおり、paizaはエンジニアのためのサービスを運営しています。前職までは、自社の事業と自分が見ているチームのエンジニアが成長することが大切でした。ただ、paizaに来てからはうちのサービスを使ってくださるエンジニアの成長にもフォーカスしたいと考えるようになりました。

エンジニアにとって転職というのは成長のひとつの手段です。事業を伸ばすのはもちろんですが、自分たちも含めたエンジニアに向けて、サービスを通してよりよい機会の提供をしていきたいと思います。実現が難しい部分もありますが、手を止めずに取り組み続けます。

――サービスをつくる側ではありますが、paizaを利用してくださっているユーザーと同じく、エンジニアでもありますもんね。

渡嘉敷：そうですね。そしてpaizaでエンジニア採用をおこなっている企業に対しても同様です。エンジニア採用がうまくいくかどうかは、企業の事業成長に直結するはずです。

高村：paizaが掲げるミッションは、「IT人材や企業がともに成長しあえる場をつくり、世界により多くの可能性を生み出す」です。それを自らも体現できる組織でなければ、他者・他社の成長を支える役割はできません。

――改めてミッションに立ち返ってみると、結構責任重大ですよね。

高村：その通りです。自分たちがもしそれを体現できていないのであれば、そこに課題があるんだと思います。

渡嘉敷：自社の事業とエンジニアの成長はもちろんですが、paizaのサービスを利用するエンジニア、そして企業も含めてみんなが成長できるサービスと組織を目指していきます。

――paizaのエンジニアチームの挑戦はまだまだ続きますね！　ありがとうございました。