システムの受託開発というと、案件ごとに既存のフレームワークを組み合わせて作る仕事、というイメージを持つ人が多いかもしれません。ですが、東京とハノイの二拠点・25人で開発をしているOpen Reach Tech(以下、ORT)は、少し勝手が違います。
バックエンドの「renchan」、フロントエンドの「furo」。ORTは、開発の土台となるフレームワークそのものを自社で作っています。しかもそこで終わらず、認証やデータベース接続、外部API連携といった、どのプロジェクトでも必ず出てくる処理を50本以上のモジュールに切り出し、案件ごとに組み合わせて使い回せるようにしてきました。
さらに近年は、AIにコードを書かせる時代に合わせて、AIの開発プロセスそのものを型にはめる「HoraKit」という仕組みまで自作しています。既製のAIコーディングツールを使うだけでなく、それをどう使うかというワークフローの部分から自分たちで設計する。受託開発会社としては、かなり珍しい部類に入ると思います。
「なぜ、そこまで自分たちで作り込むのか」を会社のビジョンとともに、CEO/代表取締役の山本次郎さんに聞いてみました。
目次
Webの受託開発から国家プロジェクトの造船ロボットまで——ORTが手がける仕事はこれだ！
ーー まずは、Open Reach Techが今どんなことをやっている会社なのか、具体的なところから教えてください。
メインはシステムの受託開発です。Webアプリケーションと業務システムが中心ですね。最近だと、Salesforceのような既製のSaaSを使っていた会社から、うちで作るCRMに丸ごと置き換える、という案件が増えています。ライセンス費用が高くつくのと、自社の業務に合わせて柔軟に変えられない、というのが理由として多いです。 また、海外の案件もあったりしました。アメリカの分散型取引所から助成金を出してもらって、その取引所で開催するトレーディングコンペ、取引の成績を競う大会ですね、そのシステムを作りました。時価総額でいうと100億円規模の取引所です。 あとは、日本が国として動かしている造船ロボット（フィジカルAI）のプロジェクトにも入っています。受託開発の会社としては、やっている幅は結構広いほうだと思います。
ーー 会社の規模を教えてください。
拠点は東京とハノイの2つで、メンバーは25人です。そのうち8割の20人がハノイですね。ベトナムには子会社を作って、現地で直接雇っています。外注ではなく、自分たちの社員です。社員全体の8割くらいがエンジニアです。 開発に使うフレームワークも自分たちで作っています。バックエンドのrenchanとフロントエンドのfuroという二つで、そこから切り出した独自のnpmモジュールが50本以上あります。一度作ったものを使い回せるので、品質も開発速度も上がる。中小のベンダーで自社のモジュールを持っている会社は、あまりないと思います。
renchan：https://github.com/openreachtech/renchan-core
furo：https://github.com/openreachtech/furo-core
ーー 国の造船プロジェクトというのは、どういうものなんでしょう。
国土交通省と、国の研究機関である海上技術安全研究所が動かしている、AI造船ロボット(フィジカルAI)の開発です。溶接や塗装、鋼板の曲げ加工みたいに、これまで熟練の技能者がやっていた工程をロボットにやらせる、という話ですね。 うちが担当しているのは、そのロボットに動きを学習させるシミュレーションの部分です。 プロジェクト自体の規模でいうと、予算が125億円級で、開発したロボットは日本とアメリカの造船所に1,000体以上の導入が予定されています。
ーー 造船、ですか。Webの受託開発をやっている会社が、なぜ船なのですか？
もともと4足歩行ロボットのシミュレーション環境を、自社の研究開発として作っていたんです。NVIDIAのIsaac Simというツールを使って、仮想空間の中でロボットに歩き方を学習させる。その積み重ねを見てもらって、声がかかったという流れですね。 今はそれを造船所でやっています。造船所そのものをデジタルツイン、要はバーチャル空間にそっくり再現して、その中で学習させたモデルを、実機のロボットに移していく。
↓造船ロボット(Physical AI)に興味がある方はぜひこちらの記事も読んでみてください！
/assets/images/23968541/original/5c1ae87d-0408-4b58-a1f7-887946a7c598?1781079204&w=1440)
Web開発での6年間の積み上げが、フィジカルAI国家プロジェクトへーーAI時代に求められる本当のエンジニアの姿とは【前編】 | Open Reach Tech株式会社
高品質＆スピード＆リーズナブル、全てを満たす「妥協なき価値提供」
ーー Open Reach Techのビジョンを教えてください。
「テクノロジーの力で妥協なき価値提供を」です。価格、品質、速度、顧客対応。この全部で満足してもらえるものを出す、ということですね。
ーー 上記の資料を見ると、それぞれ80%以上を出す、というような理解で合っていますか？
80%ではなく全て100%を目指しています。 具体的にそれをどう実現するのかは後ほどさせていただくのですが、抽象的に言わせていただくと、高品質＆スピード＆リーズナブルを全て満たす「妥協なき価値提供」をしていく、というイメージです。
システム開発は「体感5割失敗」——業界の構造的な欠陥に気づいた瞬間
ーー なぜ、全て100%を目指そうと思ったんですか。
いろんな会社に発注したり、一緒に仕事をしたりする中で、エンジニアが意外とちゃんとやっていない、ということがよく分かったんです。 システム開発のプロジェクトって、失敗が多いんですよ。体感、うまくいっているプロジェクトは1割くらいで、5割以上は失敗しているんじゃないかと思っています。残りの4割以下は、その中間ぐらいかと。 実際の統計を持っているわけではないので、あくまで感覚ですが。だからみんなSaaSを使うわけです。スクラッチで作ると、大体失敗する。
ーー なぜ、そんなに失敗するんでしょう。
理由はいろいろあります。コミュニケーションがうまくいかない。技術力が単純に低い。ユーザーが実際に利用するところをイメージできていない。思ったよりコストがかかる。 市場感覚として、実際にシステム開発をそれなりの数やっている人なら分かると思うんですが、少なく見積もっても半分以上は絶対に失敗しています。それは構造としておかしいと思ったんです。
ーー 構造としておかしい、というのは。
エンジニアは、自分の仕事（納品したコード）に対して、あまり責任を持っていない人が少なからずいると思っています。コードを書いて納品すればいい、と思っている人です。これが属人化につなり、プロジェクトの成功が担当者に左右されてしまうんですね。 技術力はもちろん前提として必要です。ただそのうえで、お客様が期待する通りのものを作る。そのためには、1個1個、全ての工程に対してちゃんとできないといけない。
ーー この業界の課題はどこにあると思いますか？
開発のやり方の標準を持っていない会社が多いことだと思います。ほとんどの会社が結局、運がいいとプロジェクトがうまくいって、運が悪いと失敗する。そういう状況になってしまっている。 同じシステムでも、エンジニアのAさんとBさんが実装すると、アウトプットが全然違うものになる。 だったら、もうちょっとまともなものを提供できる仕組みをちゃんと作って、それをこの業界全体に広げて行こう、っていう思いでやっています。
ACP-LLPフォーラムに参加し、ORT社のAIソリューションについて紹介をしている山本次郎さん
誰が担当しても同じ品質に。ORTが5年かけて作った"標準化"の中身
ーー では、その100%をどうやって実現するのか。いま取り組んでいることを教えてください。
主に2つあります：
- 開発のやり方に標準を持つということ
- ベトナムの若手エンジニアを直接雇うということ
1つ目｜開発のやり方に、標準を持つ
標準化の仕組みを、それこそ5年ぐらいずっと作ってきました。
具体的には、自分たちで開発の「型」そのものをツール化してきました。バックエンドのrenchan、フロントエンドのfuroという二つの自社フレームワークがベースにあって、そこから切り出した独自のnpmモジュールが50本以上あります。認証やAPI設計、データのやり取りみたいな、どのプロジェクトでも必ず出てくる部分を毎回ゼロから書くんじゃなくて、この共通モジュールを組み合わせて作る。だから、誰が担当しても品質と速度のブレが小さくなるんです。
造船のプロジェクト（フィジカルAI）では、シミュレーション基盤やGPUサーバーまで自前で持っていて、AI開発に必要な計算環境そのものも標準化の対象にしています。中小の受託開発会社で、ここまで自社ツールを揃えているところは、あまりないと思います。
あとは、最近、AIを使った開発に関してはHoraKitというツールも作っています。Claude CodeみたいなAIコーディングツール自体は世の中にたくさんありますが、それをどう使うか、どういうワークフローで実装させるかというところは、結局それぞれの会社や個人がバラバラにやっているのが実態だと思うんです。HoraKitは、そこに「この手順でやる」という業務フローと規約をスキルの形で定義していて、AIがその流れに沿って必ず動くようにする仕組みです。同じシステムなら、誰が触っても、AIが作っても、毎回同じアウトプットに着地する。それを担保するためのツールですね。
50本のモジュールが生む、"誰が書いても同じ品質"という土台
"ーー まずは、独自モジュールについて詳しく教えてください"
土台になっているのは二つのフレームワーク（renchanとfuro）です。
renchanはバックエンド側で、Node.jsで作っています。GraphQLにもRESTにも対応していて、認証、データベースとのやり取り、外部APIとの連携みたいな、どのプロジェクトをやっても必ず出てくる定型的な処理を、あらかじめ土台として用意しています。案件ごとに一からこの辺りを設計・実装し直す必要がない、というイメージですね。
furoはその対になるフロントエンド側です。Nuxt・Vueで画面を作るときに、同じように毎回発生する定型的な処理を共通化しています。
さらに、renchanとfuroの中身も、機能ごとに細かく分けてnpmパッケージとして切り出しています。データベース接続の部分、テストのための部分、外部APIクライアントの部分、というふうに、必要なものだけを選んで組み合わせられるようにしているんです。
こうしておくと、プロジェクトが始まるたびにフレームワークをゼロから選定したり組み立てたりする手間がなくなります。誰が担当しても同じ土台の上でスタートできるので、品質と速度が安定するんです。
AIに"型"を強制する。HoraKitが解決するコーディングのバラつき問題
ーーAIを使った開発に関連するHoraKitについても気になります。
HoraKit自体は、Claude Codeみたいな、すでにある既存のAIコーディングツールをうまく使うためのツール、というイメージです。AIを使って開発をする時の流れ、ワークフローを管理する仕組みですね。 具体的には、二つのコマンドで動きます。/hora-specというコマンドで、AIが質問しながら仕様書を対話的に作っていく。ここはまだ人間がちゃんと見て判断しないといけない工程です。次に/horaというコマンドで、その仕様書をもとに実装を自律的に進めていく。仕様を決める側と実装する側を分けているのがポイントです。
ーー 使うと、何が変わるんですか。
HoraKitにスキルは僕らが用意しているものがあって、それに合わせて実装を毎回同じようにやってくれるんです。同じシステムであれば、同じアウトプットに毎回着地する。これがすごく重要なポイントで。それを担保するための規約をスキル化していて、それをAIが使いながら実装してくれるように作っています。 もう少し具体的に言うと、1つの機能が完成するまでに「18の関所」「4つのゲート」という多段階の検収プロセスを通します。機能ごとにセキュリティ監査も組み込んでいますし、都度すべてのテストを流す設計にしているので、1万本規模のテストがあっても対応できます。そうすると、AIによる速さを維持しながら、保守性・安全性を保つことができるんです。
ーー スキルのようなものを定義して使っている人は、もう結構いると思いますが。
それをどこにどう配置して、どういうワークフローでやるか、というのは、会社で決まっていないことが多いと思います。それぞれが個人でやっているケースが多い。そこに対して「この形でやるといいですよ」というのを定義してあげる。 業務の大枠を定義してあげて、AIがその流れに沿って必ず動くような仕組みを作る、というイメージですね。もちろん、具体的な実装やテストのノウハウは会社ごとに多少変わりますし、使っているプログラミング言語でも少し変わます。そのため、大枠の業務フローを強制して、さらに個別のより細かいSKILLも必要に応じて使える形にしています。
ーー 自社のやり方に合わせて、規約そのものを作り直すこともできると。その場合、規約を作るのはAIですか、人ですか。
AIも作ることはできます。でも、やっぱり最初は、その会社で一番技術的な内容を決めている、コントロールしている人——リードエンジニアやCTOのような人が作るのが一番いいと思います。原則、そのほうがいい。 その人が全体に共通するルールをどんどん作っていって、ただルールとして作るだけでなく、開発全体のプロセスの中でどう運用していくかを決めないといけない。そこら辺をHoraKitがカバーしている、というイメージです。 既存のプロダクトに後から導入することもできます。今あるリポジトリの履歴やブランチ、コードは一切変えずに、外側からHoraKit用のディレクトリで囲むような形で追加していく。だから、今動いているプロジェクトを壊す心配をせずに導入できます。
ーー 逆に、導入するデメリットはありますか。
デメリットはあまりないと思っています。ただ、確認やテストのプロセスを強制する仕組みになっているので、少し時間はかかります。何も制約を与えずにAIに実装させた時と比較すると、実装速度は遅くなるでしょうね。 ただそれは、本来必要なコストを払っている、という感覚が正しいと思っているので、そういう意味だとデメリットはないと思っています。目安としては、ブログやポータルサイトのような小さい開発だと2-3日、比較的大きめの業務システムでも2週間程度で形になる。制約を設けている分、一般的なAIコーディングと比べても遅いわけではなく、むしろ5倍くらいのスピード感は出ています。 プロトタイプやモックのような、検証だけできればいい、とりあえず欲しい、という時には向いていません。ちゃんと長期的に運用していくシステムを作るという前提で、しかもそれをAIでやりたいのであれば、必ず使ったほうがいいと思います。
HoraKitについてさらに詳しく知りたい人は、こちらの ORT 社公式のブログも参考にしてみてください！
本当の意味での自動開発を実現するためのAI開発フレームワーク『Hora Kit』をOSSにしました
2つ目｜外注ではなく直接雇用。ベトナムの若手エンジニアと組む
ーー 拠点は東京とハノイの2つで、メンバーは25人。うち20人がハノイで、全体の8割がエンジニアだと伺いました。なぜベトナムだったんですか。
まず最初は、偶然の繋がりがあって面白そうだな、というのが半分です。あとは、実際にベトナム人と仕事をした時に、クオリティが日本人と全然変わらなかった。むしろ、日本人の変な人よりベトナム人の若い子のほうが、やる気もあるし優秀だと思うくらいでした。日本人に頼む場合、当時4〜5倍、今でも3倍ぐらいの給料を払わないといけない。その意味が感じられなかったんです。
"ーー ただ、安く早く作りたいだけなら、現地の開発会社に外注するという手もありますよね。なぜ、わざわざ法人を作って直接雇うことにしたんですか。"
海外の外部会社を使うと、社内のルールを適用できないんです。そうすると、品質が依頼先の下請け会社以上にならない。 それだと単なる営業会社、仕事を投げるだけの会社になってしまう。自分たちの価値は低いなと思ったので、もうちょっとちゃんと仕組み全体を作っていくには内製したい、と。それで法人を作って直接雇用しようという話になりました。直接雇用すると、今度は現地でマネジメントやコミュニケーションが必要になる、という流れですね。
ーー ベトナムで雇用を始めた時、苦労したこととかありましたか？
結構うまくいかないという話を聞くが、個人的にはすごいやりやすい。ベトナム人は結構真面目で、文化も日本と似ていて相性がいいと思う。年上をリスペクトする文化があり、日本と近い。ただ言語の問題があり、ベトナム語が中心で英語ができる人が少ない(日本でも英語ができる日本人がそんなに多くないのと同様)。エンジニアのうち7割ぐらいは英語ができず、3割ぐらいの人がある程度できる印象。採用は英語ができる人を中心にしているので若干採用のパイが狭まるが、それでも日本より全然やりやすい(若い人がめちゃくちゃ多い)。とても苦労したというほどではないが、少し苦労したかな、というところです。
自社の標準を、業界のデファクトへ。ORTが描く次の展開
ーー ここまでの2つは、どれも社内の標準化の仕組みを作るという話でしたが、これを業界全体に行き渡らせようとしてるのですか？
ようやく社外に公開できそうな状態になってきたので、それを広げていきたいと今は思っています。社外の開発者も使える仕組みを作っていこうと。 それを広げていって、業界の開発者（最近だと、エンジニアではない人でもだんだん使えるようになっていくと思います）が、自分たちの作った仕組みやツールを使っている、という状況を作りたい。
ーー なぜ、そこまでやるんでしょう。
特に今、AIを使ってみんな開発していると思うんですが、ほとんどちゃんと使えていないと思っています。そこをちゃんと使えるようにしていきたいんです。 今の開発って、どれもこれも大体似たような、大体同じような開発なのに、みんないろんなやり方でやっていて、うまくいったりいかなかったりしている。そういうことがないように、自分たちが作ってきた標準化の仕組みをいろんな開発に適用していく。それが今後やりたいことです。
ーー 会社のページには、もっと直接的な言葉で書かれていますね。「単なる優良な開発会社にとどまるつもりはありません。ソフトウェア開発業界における新たなデファクトスタンダードを創り上げる」と。仕組みを配るだけでなく、一緒に作りに入ることも考えているんですか。
僕ら自身もスキルを作ってきた歴史やノウハウがあるので、自社の開発フローが安定しない会社に対して、僕らが介入して一緒に作る。そういう、開発会社・開発チーム向けのコンサルティングも会社としてやっていきたいと思っています。
話を聞いて見えてきたのは、「全部で100%を目指す」という言葉を、精神論ではなく仕組みの話として語っていたことでした。renchan・furoという自社フレームワークと、AIコーディングを型にはめるHoraKit。属人化を許さないための標準化を積み重ねてきた先に、山本さんは今、その仕組みを社外にも広げようとしているのです。
