こんにちは。株式会社クラスで、システム開発部を含む事業支援本部のゼネラルマネージャー（GM）を務めている鈴木です。

【プロフィール】
鈴木
フリーランスエンジニアとしてキャリアをスタートし、基幹システムの構築など大規模開発に従事。証券会社では機械学習フレームワークの構築や経済指標予測AIの開発を担当。2020年に業務委託で株式会社クラスへ参画し、2022年10月に正社員として入社すると同時に、システム開発本部のVPoEに就任。
2025年2月に発足した事業支援本部ではGMを務め、2026年3月からはシステム開発部・カスタマーサポート部・SCMオペレーション部の3部を管掌している。

以前、私がクラスのVPoEに就任したタイミングで「これから作っていく開発組織」について語ったインタビュー（※1）が公開されました。

※1 CLAS初のVPoE鈴木が目指す、これからの開発組織とは？|社員インタビュー

エンジニアが1年で3倍に増え、組織づくりがまさに始まったばかりの頃の話です。

VPoE就任から4年目を迎えたので、あのとき描いた組織像は、どこまで実現できたか振り返ってみました。

自分で書くと都合よくまとめてしまいそうなので、社内のメンバーにお願いして、
前回同様の形式で私にインタビューしてもらい、開発組織の現在の状況を紹介します。

あまり触れてほしくない話題にも鋭く突っ込んでもらったので、
実現したことも、うまくいかなかったことも、できるだけそのまま載せています。

あのとき、何を課題として挙げていたか

まず、以前のインタビューで私が課題として挙げていたことを振り返ります。
当時の言葉をそのまま並べると、次のようなものでした。

• 開発組織のパフォーマンスを見える化したい。
• エンジニアの評価が属人的で、客観的に評価できる体制が必要。
• ナレッジの共有や育成カリキュラムが、まだまだ整備しきれていない。
• チームリーダーの業務時間の大半がMTGに費やされている。

そして最終目標として掲げていたのが、「私が不要になる開発組織」でした。
この「4つの課題と、1つの最終目標」が、今回の答え合わせのテーマです。

25名から13名へ。それでもアウトカムは数倍になった

── 当時はエンジニアが1年で3倍に増えたと話していました。いまの人数はどうなっていますか。

鈴木：当時は25名でしたが、現在は13名です。数字だけ見ると縮小したように見えると思います。

状況としては、当時は業務委託のエンジニアが多く、25名のうち17名、7割近くを業務委託の方に頼っていました。急拡大の局面だったので、まずはエンジニアの手数を増やして開発量を確保する体制だったんです。

ただ、現在も社員エンジニアの数はほとんど変わっておらず、業務委託の方に担っていただいていた範囲を社員中心の体制に寄せた形です。

── 人数が減った背景には何があったのでしょうか。

鈴木：ここ数年で、エンジニアに求められる役割が大きく変わりました。以前はシステムの実装がメインでしたが、いまは事業領域にさらに踏み込んだ開発を求められています。

「事業を成長させるにはどういう戦略やサービスが必要で、そのためにどんな機能が必要か」、あるいは「この課題を解決するには業務プロセスをどう見直し、システムはどうあるべきか」。

そこをエンジニア自身が考えて、コードに落とし込む。一言でいうと、エンジニアリングの位置づけが目的から手段に変わりました。

機能を実装することが目的だった状態から、事業成長や課題解決のための手段のひとつになった、ということです。

── 「事業領域に踏み込む」とは、具体的にどんな動き方ですか。

鈴木：たとえば、開発チケットに書かれた内容をそのまま実装することはしません。開発依頼した人に「この開発によってどんな成果が期待されるか、どんな課題が解決されるか」などを丁寧にヒアリングし、目的や成果を明確にします。

業務アプリに機能を実装する場合は、実際に倉庫へ行って作業を体験します。リモートのやり取りだけでは現場の思いが全部は伝わらないので、自分でやってみて体感することを大事にしています。

法人向けの領域では、営業に同行して商談に同席することもあります。そのうえで、開発しないという判断も含めて手段を選ぶ。そこまでがエンジニアの仕事だと考えています。

── 人数が減って、開発は回るのでしょうか。

鈴木：むしろアウトカムは数倍になっています。理由はいくつかあります。

ひとつは、エンジニア個人の成長と、開発環境の基盤整備によって生産性そのものが上がったこと。もうひとつは、使われない機能や効果の薄い開発を徹底的に排除するようになり、開発工数が減ったことです。

メンバーの業務理解が深まって、要件や仕様の解像度が上がったことも効いています。何をつくらなくて良いかが早い段階で判断できるようになりました。

「少数精鋭」と言うとありきたりですが、私の感覚では、贅肉が削ぎ落とされたという表現が近いです。無駄な開発や会議がなくなり、自律的に成果を上げて目的へ最速でたどり着く、筋肉質な組織に生まれ変わりました。

AIの性能も飛躍的に向上しましたので、開発にも積極的に取り入れています。そのおかげでエンジニアがコードを書く比重は下がり、その分、より本質的な課題に向き合えるようになりました。

VPoE就任時の4つの課題は、どこまで終わったか

── 1つめの「パフォーマンスの見える化」はどうなりましたか。

鈴木：週次と月次でFour Keysのスコアを集計し、チームごとのパフォーマンスやコンディションを測れるようになりました。

また、開発タスクやエピック単位の詳細な状況などはAIに分析レポートを作成させ、Four Keysでは見きれない領域を補っています。当時は感覚で把握していた部分が、いまはグラフで可視化できるようになっています。

── 2つめの「評価の属人性」については。

鈴木：エンジニアの評価には、技術スキルシートを導入し、エンジニア全員のスキルを見える化しました。入社して間もないエンジニア、特にジュニア層には役立っていると思います。クラスの技術水準を理解し、目標とする成長の指標にできるからです。

一方で、長く在籍しているエンジニアはスキルシートを卒業した状態になっています。求める役割が、技術よりも事業へのコミットに寄ってきたためです。

技術の物差しは用意できたので、これからは事業への貢献をどう見るかが評価の中心になります。

ただその点に関しては、全社共通の人事制度や評価基準が大幅にアップデートされ、個人の成果がしっかり組織や事業計画に連動する仕組みになりましたので、当時の課題は解決されました。

── 3つめの「ナレッジ共有と育成」はいかがですか。

鈴木：育成は、エンジニア個人のスキルとキャリアプランに応じて、柔軟にサポートする方針をとっています。全員に同じカリキュラムを流すのではなく、一人ずつ状況に応じて決めています。

ナレッジ共有の中心は、全エンジニアが集まるコードレビュー会です。ここでコードの品質を担保し、エンジニアのスキルの底上げを図るほか、新しい技術の導入説明もここで行います。

各チームの状況を共有する場も設けました。自分以外のチームがどんな開発に取り組んでいるのか、お互いに分かるようにしています。

── 毎週金曜のスキルアップMTGは続いていますか。当時は「続けられていること自体がエンジニア文化が高まってきた証拠」と話していました。

鈴木：正直に申し上げると、現在は定例をやめて、スポットでの開催になっています。あのあと1年以上は定期的に続けられたものの、発表する人の負担が大きく、マンネリ化も感じてきたのが理由です。

代わりに、社外から技術支援でサポートいただいている方の主導で「読書勉強会」という輪読会を毎週開催してもらっています。

読書勉強会といっても、ただ書籍を読むだけの会ではなく、その内容に対してそれぞれが意見や疑問をぶつけ合います。

学んだことを実際のプロダクトコードにどう適用できるかまで話すので、生きた技術が身につく場になっています。

── 4つめの「リーダーのMTG過多」については。

鈴木：形骸化しているMTGはどんどんなくす方針で、かなりスリム化されました。議事録をAIに作成させるなど、AI活用も負担の軽減に貢献してくれています。

会議を減らすことは、開発を減らすことと同じ発想です。目的から逆算して、自分が毎回参加しなくて良い会議は必要に応じてスポットで参加するように変えました。

「私が不要になる開発組織」は、達成された

── 前回のインタビューで「最終目標は私が不要になる開発組織です。」と話されていましたが、現在どうなりましたか。

鈴木：現在の開発組織においては、私はほとんど不要になったと感じているので、当初の役割は終えたと思っています。

開発プロセスは最適化され、業務を通じて成長できる育成体制も整いました。チームリーダーを中心に各チームが自律的に動いてもいるので、私が細かく指示やサポートをする必要はなくなりました。

── 当時は「そのころにはVPoEは不要になっているはずなので、私は違う役回りになっていると思います。」とも話していました。

鈴木：あのときは「私が不要になったら（＝役割を終えたら）自分からクラスを去るべきだろうな」と考えていましたが、実際は違いました。

2025年2月に、カスタマーサポート部とシステム開発部を統括する事業支援本部が発足し、まずそのGMを任されました。

2026年3月にはSCMオペレーション部も管轄に入り、いまは3つの部を見ています。この役回りになっているとは、当時は想像できませんでした。

── 開発組織との関わり方は、どう変わりましたか。

鈴木：私自身の業務領域が広がって、事業部など各部署との連携も強化されましたので、開発組織との関わり方は、「開発組織内部からの関わり」から、「全社からの統括的な関わり」にシフトしてきています。

組織ごとの課題を把握し、それぞれの強みを活かしてシナジー効果を生むことで、より大きな成果につなげる。開発組織だけでは解けない課題を、部門横断で解決に導くことが、いまの役割です。

今も変わらず残っている関わりとしては、各開発チームやエンジニア個人の目標達成をサポートすることと、エンジニアが働きやすい環境を整えることです。

これらも会社と事業の成長につながるので、とても大事な役割だと思っています。

それでも、まだ発展途上です

── いま残っている課題を挙げてください。

鈴木：1つめは、エンジニア採用です。技術力が高く経験も豊富な方でも、主体性や課題解決力がないとクラスで成果を出すのは難しいため、なかなか採用が進んでいない状況です。

カルチャーフィットを大切にしていますが、そこは一定期間一緒に働いてみないと分からない部分もあり、面接だけでは見極められません。

入社前の期待値と入社後のギャップが大きいと、会社にとっても入社された方にとっても不幸です。そのため、期待値ギャップはできるだけ事前に解消するようにしています。

この記事で現在の状況を率直にお話しさせていただいているのも、同じ理由からです。

2つめは、3つの部を横断した業務プロセスの改革です。システム開発、カスタマーサポート、SCMオペレーションをつないで全社の業務を変えていく余地は、まだ大きく残っています。

現場に蓄積された知見と、システムに溜まったデータを組み合わせれば、事業部への提案にもつなげられます。エンジニアにとっては、腕の振るいどころが山ほどあるという意味でもあります。

3つめは、サクセッションプラン（後継者育成）が進められていないことです。

これは、1つめのエンジニア採用にも関わってくるのですが、採用が進んでいないので、優秀なエンジニアに次のポジションを用意できていないことも要因のひとつです。

私の業務が属人化していて引継ぎが難しいことも事実なので、早急に改善しないといけないと感じています。

── どんな方と一緒に働きたいですか。

鈴木：前回のインタビューでは「主体的に動ける人」と答えましたが、それはいまも変わりません。ただ、その意味はより具体的になっています。

• 目的から逆算して、つくらない判断も含めて最適な手段を選べる人。
• 自ら現場に踏み込んでいき、要件を取りに行ける人。
• 自分で課題を見つけ、より本質的な問いに再定義し、周りを巻き込んで大きな改革を推進していける人。

そんな方と一緒に働きたいと思っています。

理想とする組織はまだ完成していません。ですが、だからこそ自分の判断で決め、提案して変えていける余地があります。

クラスのエンジニア組織に興味を持っていただけた方は、30分だけ話しませんか

前回のインタビュー記事は、採用担当の言葉で「開発組織を作っていくちょうどスタートラインにいる」と締められていました。

いまはそのスタートラインを越えて、次の課題が見えている状態だと思っています。少しでも興味を持っていただけたら、まずはカジュアル面談でお話しできればうれしいです。