この記事でわかること
-
フルスタックエンジニアで実現する「待ち時間ゼロ」の開発フロー
-
JavaScript統一のメリットとTypeScript移行へ踏み切る判断基準
-
法改正などの外部要因をアジャイルにプロダクトへ落とし込む手法
「専門性を高めるべきか、フルスタックを目指すべきか」。 多くのエンジニアが一度は直面するこの問いに対し、「全員がフルスタックであること」を明確な戦略として掲げる開発チームがあります。
日本最大級の奨学金プラットフォームと業務支援SaaSを内製開発する株式会社ガクシーです。 同社の開発チームは、少人数ながらフロントエンドからバックエンド、インフラに至るまで、メンバー全員が領域を横断して開発を担当しています。
複雑化しやすいSaaS開発において、なぜあえて「分業」を捨てたのか。その裏には、限られたリソースで最大の事業価値を生み出すための合理的な判断がありました。
今回は、開発責任者の中谷紀陽氏と、大手SIer出身のベテランエンジニア山根洋平氏に、現代のSaaS開発における「技術選定のリアル」と「強いチームの作り方」についてお話を伺いました。
株式会社ガクシー
「奨学金を変える。運命が変わる。社会が変わる。」をビジョンに掲げ、若者の可能性を広げる事業を展開。日本の学生の約半数が利用する奨学金の情報格差を解消するプラットフォーム「ガクシー」や、大学・自治体・財団向けに奨学金運営管理システム（SaaS）「ガクシーAgent」を提供し、アナログな業務フローのDXを推進している。
【HP】：https://gaxi.co.jp/
中谷 紀陽
株式会社ガクシー 開発責任者 28歳まで関西で古着屋の店長を務めた後、エンジニアへ転身。ワークスアプリケーションズ、GA technologiesにてエンジニアとしての経験を積み、ガクシーへ参画。現在は開発責任者として、技術選定から組織づくりまでを牽引する。
山根 洋平
株式会社ガクシー 開発チーム チームリーダー / エンジニア 新卒でリコーITソリューションズ株式会社に入社。約14年にわたりメーカー向けのソフトウェア開発等に従事した後、2022年に株式会社ネクストスケープに転職。プライムベンダーとして企業のDX支援や大規模システム開発に従事。2025年のガクシー入社後は、開発チームを牽引。メンバーのマネジメントや技術的な指導・推進役も担っている。
目次
奨学金SaaSという「社会インフラ」への挑戦
中谷さんは、異業種から未経験でエンジニアへ転身され、現在は開発責任者を務められているそうですね。
28歳までは全くの未経験でしたが、そこからエンジニアとしてのキャリアをスタートさせました。その後、ECパッケージの保守開発や不動産テック領域を経て、前任の創業者に誘われる形でガクシーの立ち上げ期から参画しました。
自分自身に「挑戦してキャリアを変えてきた」経験があるからこそ、若者の挑戦を支えるガクシーのミッションには強く共感しています。
山根さんは前職で約16年のキャリアを持つベテランですが、なぜガクシーを選ばれたのでしょうか。
前職では約16年間、メーカー向けのソフトウェア開発を行っていました。転職を考えた際、自分の技術が「社会課題の解決」に直結する手触り感を求めていたんです。
ガクシーは、奨学金という多くの人が関わる社会インフラを扱っており、それを少人数のチームでスピード感を持って開発している点に惹かれました。現在はプレイングマネージャーとして、手を動かしながらチームビルディングも行っています。
お二人が開発されているプロダクトについて、技術的な観点も含めて教えてください。
私たちが主に担当しているのは、学生・保護者向けのプラットフォーム「ガクシー」と、運営側（大学・自治体など）向けのSaaS「ガクシーAgent」です。 特に「ガクシーAgent」は、これまで紙やExcelで行われていた複雑な奨学金業務をクラウド化するものです。
掲載されている奨学金情報は約1.6万件にのぼり、それらの検索機能や、複雑な給付条件の計算ロジックなどを実装しています。
エンジニアとして開発する上で、特に技術的な難易度が高いのはどのあたりでしょうか？
修学支援制度における「授業料の減免」や「給付奨学金」に関する計算ロジックですね。奨学金は、単純に決まった額を支給するだけではありません。世帯年収や資産額に応じて「第I区分」から「第III区分」まで支援区分が細かく分かれており、それに基づいて授業料の減免額も変動します。
さらに厄介なのが、貸与型と給付型では年間の業務スケジュールも全く異なるという点です。それらが並走する複雑なワークフローを、システム上で矛盾なく制御しなければなりません。
なるほど、業務ドメイン自体の複雑さが桁違いなんですね。
ただ、私たちの技術がその複雑さを解消することで、学生にとっては「進学のチャンス」が広がり、運営側にとっては「業務効率化」が実現します。 運営の手間が減ることで、これまで「管理が大変だから」と二の足を踏んでいたような新たな奨学金の設立もしやすくなります。
まさに「自分たちの書いたコードが社会を変えている」という手触り感を、ダイレクトに感じられるプロダクトだと思います。
「全員フルスタック」×「JavaScript統一」。コンテキストスイッチを極限まで減らす開発戦略
現在の開発環境は、フロントエンドからバックエンドまでJavaScript（Node.js / Nuxt3）で統一されていると伺いました。この技術選定にはどのような意図があったのでしょうか？
最大の理由は、「コンテキストスイッチ（思考の切り替え）の最小化」と「開発スピードの最大化」です。 立ち上げ当初は圧倒的なスピード感が求められ、顧客の要望に対して「来週リリースします！」と即座に応えるような状況でした。
その際、フロントエンドとバックエンドで言語が分かれていると、どうしても頭の切り替えコストが発生します。 言語をJavaScriptに統一することで、思考を分断させず、一気通貫で機能を実装できるメリットを取りました。
あえて技術スタックを絞ることで、速度を出せる環境を作ったと。チーム編成も「全員がフルスタックエンジニア」という方針ですが、これも意図的なものでしょうか？
はい。エンジニアにはガクシーで終わるのではなく、市場価値の高い人材になってほしいという思いがあります。そのためにも、特定の領域だけでなくシステム全体を俯瞰できるフルスタックなスキルを身につけてほしいと考えています。
実際、入社時は「データベースを触ったことがない」というメンバーもいましたが、今ではDBのチューニングからフロントエンドの実装まで一人でこなせるようになっています。
山根さんは長年の経験から見て、この「全員フルスタック」体制のメリットをどう感じていますか？
「コミュニケーションコストの削減」と「全体最適の視点」を持てる点が大きなメリットです。 一般的な分業制の現場では、「この仕様を知っていれば、こんなDB設計にはしなかったのに」という手戻りが起きがちです。
しかしフルスタックであれば、「この機能要件なら、DB設計はこうして、APIはこう返して、フロントはこう描画するのが最適だ」と一人で完結して設計できます。 結果として、手戻りが減り、システムとしての整合性も保ちやすくなります。
システム全体を見渡せるフルスタック体制と、それを支える「JavaScript統一」という技術選定がうまく機能してきたわけですね。フェーズが進む中で、今後はTypeScriptへの移行も計画されているそうですが、これにはどういった背景があるのでしょうか？
JavaScriptは自由度が高い反面、規模が大きくなると「どんなデータが流れてくるか」がコード上で見えにくくなる課題があります。 チーム人数が増え、機能も複雑化してきた今のフェーズでは、TypeScriptによる「型」の導入が必要不可欠です。
データ構造を明確にし、変更による影響範囲を可視化することで、開発の安全性と生産性を一段上のレベルへ引き上げようとしています。
ドメイン知識を武器に、複雑な要件をアジャイルに実装する
奨学金や自治体の業務システムというと、法律や制度改正の影響を強く受けそうですが、どのように開発タスクに落とし込んでいるのでしょうか？
そこは一番気を使う部分ですね。特に奨学金の「減免額計算」などはお金に関わることなので、1円のズレも許されません。また、奨学金には年間スケジュールがあるものの、国の方針変更や制度改正は突然発表されることもあります。
そうした外部要因による突発的な変更には、どう対応しているのですか？
私たちは現場のお客様と非常に密な関係を築いているので、公的な要綱が決まる前の段階から「現場レベルでの実務相談」として情報をいただけることが多いんです。
実際に現場で運用可能な仕様に落とし込むため、早い段階で一次情報をキャッチアップし、「準備」を進めておいて、要件が最終確定した瞬間に実装を完了させるというアプローチをとっています。これはドメイン知識と顧客関係性があるからこそできる開発スタイルですね。
まさに顧客との信頼関係があるからこそできる開発ですね。 少人数チームだと、そうした突発的な対応と、通常の新機能開発のバランスを取るのが大変そうです。「誰か一人に負荷が集中する」といったことは起きないのでしょうか？
全員が忙しい状況ではありますが、フルスタック体制のおかげで「特定の人しか対応できない」という状況は避けられています。また、各領域に専任のメンバーがいないので「バックエンドの実装待ちでフロントエンドの手が空く」というようなボトルネックが発生しません。
緊急度が高いタスクが発生すれば、チーム全員でその領域にリソースを集中させることができます。誰か一人に負荷が偏るのではなく、チーム全体で柔軟にフォーメーションを変えて対応できるのが強みですね。
少人数ならではの機動力ですね。ただ一方で、奨学金という「お金」を扱う以上、ミスは許されないという厳しさもあると思います。 御社の行動指針には「行動ファースト」という言葉がありますが、スピードを重視しつつ、そうした品質はどう担保されているのでしょうか？
「行動ファースト」は、決して「品質を犠牲にしていいから早く出せ」という意味ではありません。「完璧な設計図ができるまで動かない」のではなく、「まずはプロトタイプを作って検証する」「自分から情報を取りに行く」という主体性を求めている言葉です。 早く動くことで、結果的に手戻りを防ぎ、品質を高めることができますから。
ただ、プロダクトのフェーズとしては明確に変化しています。これまではPMF（プロダクトマーケットフィット）を目指して「機能リリース」を最優先してきましたが、現在は社会インフラとしての責任も増しています。「スピード感」は維持しつつも、今は意識的に「安定性や品質」へ重心を移している段階ですね 。
「新規開発に全力」からの転換。CSチームとともにQAに挑む
ユーザー数や機能が増えるにつれて、いわゆる「技術的負債」への対応も課題になってくると思います。
正直にお話しすると、今年までは「新規機能開発に全力投球」という状態で、技術基盤の強化については優先度が下がっていた側面がありました。
こちらのグラフの通り、ガクシーAgentは2022年のリリースからわずか2年強で、導入数が23校から200団体以上に急増しています。 この急激なグロースに応えるために機能をひたすら追加してきた結果、どうしても歪みが生じてしまったんです。
このまま走り続けるのは、開発体制として持続可能ではありません。 そこで今年の秋頃、開発メンバー全員を集めて膝を突き合わせて議論し、来期からは開発工数の一定割合を「技術基盤強化」や「QA（品質保証）」に投資するという戦略的な意思決定を行いました 。
「作ること」と同じくらい「守ること」にリソースを割くと決めたわけですね。品質管理の面では、どのような新しい取り組みを始められているのでしょうか？
一つは、これまで開発者が兼務していたテスト工程を専門化するためのQA（品質保証）組織の立ち上げです。 もう一つは、CS（カスタマーサポート）チームとの連携強化です。これまではリリースの直前にCSチームに触ってもらっていたのですが、それだと修正の手戻りが大きすぎました。
「もう完成しました」というタイミングで指摘をもらっても、作り直すのはエンジニアも精神的につらいですし、工数もかかります。 そこで今は「シフトレフト」の考え方を取り入れようとしています。
開発の初期段階、プロトタイプや設計の段階からCSメンバーに入ってもらい、「お客様はこういう使い方をするから、このUIだと困る」といったフィードバックを早期にもらう。 作りきってから直すのではなく、「作る過程」に顧客視点を取り込むことで、手戻りを減らしながら品質を高めるフローへの変革を進めています。
CSチームとの連携で、手戻りを防ぐ仕組みができつつあるわけですね。 一方で、エンジニア同士の「コードの品質管理」についてはいかがでしょうか？ 山根さんが入社されてから、レビュー文化もかなり変わったと伺いました。
人数が増えると、「動けばいい」というコードでは運用が破綻します。 私がレビューで特にこだわっているのは、「書き手の意図」をコードに残すことです。変数名一つ、ループの処理一つとっても「なぜそう書いたのか」というメッセージが込められているべきです。
チーム全員がその基準でコードを書けるようになれば、言葉を交わさなくてもコードを見るだけで意思疎通ができる「非言語コミュニケーション」が成立するようになります。そこまで視座を揃えることが、少人数で開発生産性を最大化する鍵だと考えています。
正解のないアーキテクチャ構想と、組織を「ハック」する面白さ
最後に、今後のチームとプロダクトの展望について教えてください。プロダクトとしては、今後どのような技術的課題に挑戦していくことになるのでしょうか？
最大のテーマは「多様化するステークホルダーへの最適解」をどうシステムで実現するかです。 現在、大学だけでなく多くの自治体様への導入が進んでいますが、自治体特有の業務フローや要件は非常に複雑です。
これを既存のSaaSという「1つの巨大なシステム」の中ですべて吸収するのか、それとも機能ごとに分離してマイクロサービス化していくのか。
さらに、今後は単なる業務SaaSにとどまりません。資金を運用し、その運用益を奨学金として給付する「サステナブル奨学金」といったFinTech的なスキームへの対応や、「遺贈・寄付市場」とのデータ連携、さらにはインドやアジア圏への海外展開も見据えています。
こうした事業の広がりに耐えうる、拡張性の高いアーキテクチャをどう設計するか、正解のない問いに今挑んでいるところです。
組織づくりについてはいかがでしょうか？ これから入社される方にとっては、どのような環境だと言えますか？
今は組織自体も「アジャイルに開発している」状態です。スクラムの回し方一つとっても、「このやり方は合わなかったから変えよう」とメンバーから提案があればすぐに変えます。
完成された組織に入るのではなく、「自分たちで組織のルールを作っていく」「開発プロセスそのものをハックしていく」という経験ができるのは、今のタイミングでジョインする一番の面白さだと思います。
ありがとうございます。では最後に、これから一緒に働く未来の仲間へ向けて、メッセージをお願いします。
私はガクシーの開発組織を「伸びしろしかないチーム」だと思っています。 ボードメンバーも含めて、会社全体が開発チームに対して大きな期待を寄せてくれていますし、私自身も「このチームはもっと強くなれる」と日々ワクワクしています。 技術的な挑戦も、組織づくりも、すべては「より多くのお客様に価値を届ける」ためです。
奨学金という社会課題に対して、技術の力で本質的な解決策を提示できる。そんな手触り感のある開発に、熱量を持って取り組める方と一緒に働きたいですね。
編集後記：「生存戦略」としての開発スタンス
今回の取材を通じて、ガクシーの開発チームから学べることは、単なる技術選定の良し悪しではなく、「いかにエンジニアの認知負荷を下げ、バリューを最大化するか」という徹底した合理性です。
現場のエンジニアが取り入れられる視点として、まず挙げられるのが「認知負荷を考慮した技術スタックの活用」です。新しい技術を導入する際、それがチーム全体の「思考の切り替え」を増やしていないか、あえて絞ることで得られるスピードはないか。この視点は、リソースが限られたあらゆるプロジェクトで有効な武器になります。
次に「シフトレフトによる手戻りの防止」です。エンジニアの仕事は「コードを書くこと」だけではありません。設計段階で他職種を巻き込み、早い段階で違和感を潰しておくことが、結果として最も効率的に「動くプロダクト」を届ける近道であることを、同チームの実践は証明しています。
最後に「コードを通じた意思疎通」の重要性です。変数名一つ、処理一つに「なぜそうしたか」という意図を込める。こうした日々の細かな積み重ねが、チーム全体の視座を揃え、コミュニケーションコストを劇的に下げます。
技術の力で社会課題を解決するためには、こうした「開発プロセスそのものをハックする」姿勢こそが、エンジニアにとっての真の生存戦略になるのではないでしょうか。
ライター
