少人数で顧客課題から本番運用まで。RAYVENの開発体制とつくっているもの

こんにちは、株式会社RAYVEN採用担当です。

カジュアル面談で、フルスタック志向のエンジニアの方からよく聞かれる質問があります。

「入社後は、フロントエンドとバックエンドのどちらを担当するんですか?」

「AIエージェントの開発経験がなくても大丈夫ですか?」

「1〜3人のチームで、本当に品質は担保できるんですか?」

こうした質問に共通しているのは、技術や役割で線引きされた組織をご経験されてきた方が多い、ということだと感じています。
仕様書通りに実装する担当範囲は決まっているけれど、なぜそれを作るのか、その先で誰がどう使うのかが見えづらい。そんなモヤモヤを抱えて面談に来られる方が少なくありません。

RAYVENには、フロントエンドチーム、バックエンドチーム、インフラチームといった職能別の縦割り組織がありません。一人ひとりのエンジニアが、顧客との対話から設計、実装、デプロイ、本番運用まで、プロジェクトに必要な領域を横断して担当します。

なぜそうしているのか。
理由は単純で、RAYVENにとって技術は目的ではなく、顧客の課題を解くための手段だからです。この記事では、その考え方が実際の開発体制やチームの動き方にどう表れているかをご紹介します。次回の記事では、入社後どう成長していくか、そしてどんな人と働きたいかをお伝えします。

なぜ、職能で分けないのか

RAYVENの開発単位は、職種ではなくプロジェクトです。

1プロジェクトあたり1〜3人程度の少人数チームで、顧客の業務理解から本番運用までを一続きで進めます。同じメンバーがプロジェクトの背景と判断理由を共有し、実装と改善のサイクルを短く回すためです。

AI駆動開発では、チームの人数を増やせば、そのまま開発速度が上がるとは限りません。実装そのものよりも、仕様の受け渡しや情報共有、意思決定の調整がボトルネックになることがあります。そこでRAYVENでは、Claude CodeやCodexなどを日々の調査、実装、レビューへ組み込みながら、必要なメンバーがプロジェクト全体を理解できる規模を大切にしています。

これは単に少ない人数で多くの仕事をこなすための体制ではありません。顧客の課題を理解している人が、その判断を設計や実装、本番での改善までつなげるための体制です。フロントエンドだけ、バックエンドだけという担当分けにしてしまうと、なぜその実装が必要なのかという判断の背景が、担当が変わるたびに少しずつ失われていきます。

RAYVENが開発しているもの

RAYVENがつくっているのは、AIとの会話だけで終わるデモではありません。社内システムやSaaSと連携し、データを取得し、判断し、実際の業務を実行するAIエージェントを開発しています。

主な開発領域は次のとおりです。

• 企業の業務へ組み込むAIエージェント
• ChatGPTやClaude上で動作するMCP Apps
• AIに業務手順や判断能力を持たせるAgent Skills
• RAGを利用した社内データ・業務データとの連携
• AIエージェントの権限、通信、実行履歴を管理する「Tumiki」
• Web、デスクトップ、モバイル向けの業務アプリケーション
• AIエージェントを継続運用するための監視・インフラ基盤

現在の多くのプロジェクトでは、AIモデルそのものの研究開発よりも、既存のLLM、データ、業務システムを組み合わせ、顧客の現場で実際に使える状態へ落とし込むことを中心にしています。

モデルの性能だけでは、業務で動くAIエージェントにはなりません。

誰がどのデータへアクセスできるのか、どのツールを利用できるのか、失敗したときにどう止めるのか、どこで人間が承認するのか、実行結果をどう記録するのか。

こうした業務・権限・運用まで含めたオーケストレーションを設計することが、RAYVENのAI開発の中心です。

顧客の言葉を、動く仕組みに変える

RAYVENの開発は、完成した仕様書を受け取り、決められた画面を実装するところから始まるとは限りません。

「既存のサービスにAIを組み込みたい」「この業務をエージェントで効率化できないか」といった、まだ輪郭の曖昧な相談から始まることもあります。

そこでエンジニア自身が顧客との対話に入り、次のような点を整理します。

• 現在、誰がどのような手順で業務を行っているのか
• どこに時間や判断の負荷が集中しているのか
• AIへ任せてよい範囲と、人間が判断すべき範囲はどこか
• 利用できるデータと、アクセスを制限すべきデータは何か
• どのような状態になれば、業務上の価値が出たと言えるのか

実装するものを決める前に、そもそも何を解くべきかを顧客と一緒に定めます。その後、利用するLLM、RAG、MCP、外部サービスとの連携方法を設計し、ユーザーが触れる画面、バックエンド、データ連携、権限、ログまでを一つの仕組みとして実装します。

小さくつくり、実際の業務の中で育てる

AIエージェント開発では、最初から正解の仕様が決まっているとは限りません。まず小さなPoCをつくり、実際に試してもらいます。期待した精度が出なければ、参照するデータ、利用するツール、エージェントへ与えるスキルや指示を調整します。AIが対応できないケースがあれば、人へ引き継ぐ条件や画面の導線も見直します。

本番へ届けた後も、ログや利用状況から、想定した業務を遂行できているかを確認します。そこで見つかった課題を、次の設計や実装へ反映します。

RAYVENの開発は、納品して終わる仕事ではありません。顧客と一緒に、実際の業務で使える仕組みへ育てていく仕事です。

だからこそ、顧客との会話、PoC、実装、運用改善を同じプロジェクトの中でつなぐことが欠かせません。

「担当範囲が広い」は、「一人で全部抱える」ではない

フルサイクルといっても、全員が最初から同じ知識を持つ「何でも屋」になるという意味ではありません。UI設計が得意な人、バックエンドやデータ連携に強い人、デスクトップアプリの経験がある人、インフラやセキュリティに詳しい人など、それぞれの強みを出発点にします。

ただし、「自分の担当はここまで」と境界を固定せず、プロダクトを前へ進めるために必要であれば、自分の専門の外側にも踏み込みます。

分からない領域を一人で抱えることも前提にしていません。AIエージェント開発が初めてのメンバーは、経験のあるメンバーと同じプロジェクトへ入り、実際のタスクを通じて学びます。日々の質問や進捗はSlackなどで共有し、プロジェクトのミーティングやPR、CIを通じて認識と品質を確認します。

一人ひとりが自律的に動きながら、プロジェクトとして確認すべき点を残す。担当範囲は広く持ち、判断を孤立させない。

それがRAYVENの考えるフルサイクルな働き方です。

AIを使って速く進め、人が品質とリリースに責任を持つ

RAYVENでは、AIをコード補完として使うだけではありません。議事録、既存コード、仕様の調査、要件整理と設計案の比較、実装とテスト作成、一次的なコードレビュー、ドキュメント作成、ログや障害原因の分析、定型的な運用作業。こうした開発工程のさまざまな場面で、Claude CodeやCodexなどを利用しています。

エンジニアは、AIへ背景、制約、完了条件を渡し、出力された提案やコードを検証します。すべてのコードを手作業で入力することよりも、「何をつくるのか」「どこまでAIに任せるのか」「どう安全性を確認するのか」を設計することに時間を使います。

一方で、AIが生成したから正しいとは考えません。CIでは、プロジェクトに応じてフォーマット、型チェック、テスト、ビルドなどを自動で確認します。さらに、データ構造や権限など影響の大きい変更は人が確認し、ステージング環境で実際の操作や振る舞いを検証します。本番へ出してよいかという最終判断も人が行います。

顧客の要件を満たしているか、必要以上の権限を与えていないか、例外時に安全に止まるか、運用時に観測できるか。AIでは判断しきれない部分を人間が確認します。AIが開発速度を引き上げ、人が品質とリリースに責任を持つ。これがRAYVENのAI駆動開発です。

技術スタックは、プロジェクトを完成させるための道具

RAYVENでは、技術スタックを職種別の担当表としてではなく、顧客の課題を解決し、プロジェクトを完成させるための道具として捉えています。

必要なのがWeb画面なら画面をつくり、業務システムとの接続が必要ならAPIやMCPサーバーを実装し、利用環境がデスクトップならElectronやTauriを、モバイルならReact Nativeを選びます。担当するのは技術の一部分ではなく、ユーザーが実際に使える状態まで届けるために必要な範囲です。

具体的には、次のような技術を状況に応じて使い分けています。

アプリケーション開発では、TypeScriptを中心に、React、Next.js、Bun、Node.js、Hono、tRPC、Tailwind CSSなどを利用しています。
短期間でWebアプリケーションとAPIを立ち上げる場合、フロントエンドとバックエンドを同じ言語で扱いやすいTypeScriptは、少人数チームとの相性が良いと考えています。
一方で、すべてをTypeScriptに統一しているわけではありません。AI周辺の処理ではPythonを利用することもあり、処理性能、配布形態、既存システムとの連携など、プロジェクトの要件に応じてRustやGoも採用します。

開発対象もWebアプリケーションに限定されません。
React／Next.jsによるWebアプリケーションや管理画面、MCP AppsやAIエージェントとの対話インターフェース、業務システムや外部サービスと接続するAPI、Electron／Tauriを利用したデスクトップアプリケーション、React Nativeを利用したiOS／Android向けネイティブアプリケーション、Rust／Goを利用した高速処理、CLI、バックエンドサービス。これらすべてが選択肢に入ります。

AIエージェント・データ連携の領域では、Anthropic Claude、OpenAI GPT、Google GeminiなどのLLM APIと、Model Context Protocol、RAG、Function Calling、各種エージェントフレームワークを組み合わせます。
重要なのは、特定のフレームワークを使えることではありません。AIが何を判断するのか、どのツールを利用できるのか、どのデータへアクセスできるのか、失敗した場合にどう処理するのか、人間の承認をどこへ入れるのか、実行内容をどう記録し後から説明できるようにするのか。
こうしたエージェント全体のオーケストレーションを設計することが中心になります。

データ・インフラ・運用では、PostgreSQL、オブジェクトストレージ、Cloudflare、Docker、Kubernetes／k3s、GitHub Actions、Argo CDなどを利用し、監視やログ分析にはGrafanaやOpenObserveなどを活用します。アプリケーションを実装して終わりではなく、デプロイ後に何が起きているかを確認し、安全に改善できる状態まで整えます。

これだけ幅広い技術を並べると、「全部使いこなさないといけないのか」と思われるかもしれません。ですが、RAYVENが大切にしているのは、技術を網羅的に習得することではなく、「なぜその技術を選んだのか」を自分の言葉で説明できることです。
ある技術に精通していることよりも、目の前の顧客の課題に対して、今ある選択肢の中から最も適したものを選び取れるかどうかを重視しています。

技術課題にも現れる、RAYVENの価値観

RAYVENの技術課題では、単にコードが動くかだけを見ていません。AIエージェントやMCP Appsなどを題材に、「誰が、どの業務で、何に困っているのか」を考え、その課題を動く仕組みへ落とし込んでもらいます。

特に重視しているのは、次のような点です。

• 現実の業務課題を解決できるか
• 想定する利用者と利用場面が具体的か
• 要件を技術的な仕組みへ落とし込めているか
• なぜそのUI、モデル、データ接続方法を選んだのか
• 設計判断を自分の言葉で説明できるか
• 継続して運用・拡張できるか

高度な設計や新しい技術を使っていても、実際の利用者や業務シナリオが曖昧であれば、良いプロダクトとは考えません。
反対に、小さな構成でも、利用者の課題を正確に捉え、実務へ自然に組み込めるものは高く評価します。「何を使ったか」よりも、「なぜそれを使い、誰のどんな問題を解決したのか」。
ここが、RAYVENが選考を通じて一番見ているところです。

少し長くなりましたが、技術に対する考え方で重要だと考えている点を述べさせていただきました！

我々の考え方にご興味をお持ちいただいた方はぜひ、カジュアル面談で議論させてください。お待ちしております！

次回は、実際にご入社いただいた後にどのようにキャッチアップいただくのか。
我々の考えをお伝えする記事になる予定です。

おたのしみに！