「ヒーローを作らない会社」を、ベトナムで作っています。
こんにちは。Linnoedge（リノエッジ）の原田祥吾です。ホーチミンで日本企業向けのオフショアシステム開発会社を経営しています。
この記事は、「Linnoedgeってどんな会社なの？」という質問に、できるだけ正直に答えるために書きました。読んでほしいのは二種類の人です。一つは、うちで働くことを考えてくれている人。もう一つは、ベトナムに開発を任せることを検討していて、でも過去に一度うまくいかなかった経験があるか、周りからうまくいかなかった話を聞いている人です。
後者の方は、途中の「発注する側から見たLinnoedge」という見出しから読んでもらえれば、うちがどう仕事をしているかが一番早く分かると思います。
金融業界から始まって、気づいたらホーチミンにいた
キャリアの始まりは金融業界でした。そこからITコンサルティング業界に転身して、スタートアップ事業とシステム開発会社でマーケティングやプロジェクトマネージャー等やって、気づいたらベトナムでシステム開発会社を経営しています。
計画通りじゃないです。全然。
ただ、振り返ると一つだけ変わらなかったことがあって、それは「構造を設計するのが好き」ということでした。金融業界のときも、ITコンサルタントのときも、システム開発会社のときも、「この仕事、もっとうまく回る仕組みにできないかな」とずっと考えていた。
躊躇せずやってみる、ということを続けてきたら、その延長線上にLinnoedgeがあった。そんな感じです。
Linnoedgeが何をしている会社か
ホーチミンを拠点にして、日本企業のシステム開発をやっています。いわゆるオフショア開発です。
ラボ型の開発契約が中心で、クライアントの専任チームとして中長期で一緒に動く形が多い。病院向けシステムや業務基幹系など、止まったら困るシステムを扱うことが多いので、品質に対する緊張感は常にあります。
「オフショア＝安い」というイメージを持っている方もいると思いますが、僕らがやりたいのはそこじゃない。日本のIT人材不足が深刻になる中で、ベトナムの優秀なエンジニアと一緒に、品質を基盤にしたまま改善速度を上げていく。それがLinnoedgeの存在意義だと思っています。
あと、最近は海外進出のコンサルティングにも手を広げ始めています。オフショア開発で培った「国境をまたいで仕事を設計する力」は、結構いろんなところに応用が利く。
「仕組みで勝つ」という考え方
Linnoedgeの経営で一番大事にしていることを一言で言うと、「仕組みで勝つ」です。
オフショア開発って、距離がある。時差がある。言語も文化も違う。この環境で「あの人がいないと進まない」という状態を作ると、あっという間に崩壊します。
だから、属人化を徹底的に排除する。誰が何に責任を持つかを明確にする。判断の基準を全員が見えるところに置く。
逆に言えば、この制約がいい先生になっている。距離があるからこそ曖昧さを排除しないと何も進まない。その結果、「距離がなくても使える」くらい強い仕組みができる。
発注する側から見たLinnoedge
ここまでは会社の考え方の話でした。ここからは、実際に僕らに開発を任せるとどうなるのかを書きます。
相談に来る会社は、だいたい三つのどれか
一つ目は、社内の開発リソースが足りず、採用も間に合っていない会社です。日本国内でエンジニアを採ろうとしたけれど、想定した人数も期間も埋まらなかった。プロダクトの計画は動いているので、どこかで手を増やさないといけない。この相談が一番多いです。
二つ目は、過去にオフショアで一度失敗している会社です。安いと聞いて発注したものの、仕様の伝達で何往復もして、出てきたものが違って、結局作り直した。もうオフショアはやらないと決めていたけれど、コスト構造上もう一度考えざるを得なくなった、という状態です。
三つ目は、止まると業務が止まるシステムを抱えている会社です。病院向けのシステムや、業務の基幹にあたるシステム。新機能を足すこと以上に、今動いているものを壊さないことが重要な領域です。
どの相談も、根っこにあるのは同じ不安だと思っています。「発注したあと、中で何が起きているのか見えなくなるのが怖い」。
ラボ型契約が実際どう動くか
僕らの契約はラボ型が中心です。案件ごとに見積もって作って納めるのではなく、クライアント専任のチームを組んで、中長期でそのチームを使ってもらう形です。
具体的には、こう動きます。
チームの構成。 いま僕らが動かしているラボ型のチームは4つで、そこに25人（PM含む）が所属しています。一つのチームには、開発メンバーに加えてITD（プロジェクト推進の担当）が入ります。ITDは日本側との窓口であり、顧客と納期に責任を持ちます。開発チームは設計品質と技術戦略に責任を持ちます。この二つを対等な責任として定義しているのが、うちの体制の一番の特徴です。窓口担当がエンジニアの下請けになっていると仕様が伝わらないし、逆にエンジニアが窓口の言いなりになっていると品質が落ちる。どちらか一方が強い体制を、僕らは意図的に避けています。
週の流れ。 プロジェクトごとに週次で定例を行い、そこで進捗・課題・次週の計画を確認します。日々の進捗はログに残していて、どこにいてもいつでも見られる状態にしています。「今どうなっていますか」と聞かないと状況が分からない、という状態を作らないのが目標です。
決めごとの残し方。 打ち合わせで決まったことは、その場でログを出力して、タスクと担当者を明確にします。口頭で決まって誰の記憶にしか残っていない、という状態を許さない。これは日本とベトナムで時差と言語の壁がある以上、守らないと必ず事故になります。
チームの増減。 立ち上げは3名体制から始めて、3ヶ月ほど一緒に走って噛み合ってから広げるのを勧めています。最初から大人数で始めると、うまくいかなかったときに何が原因だったのか分からなくなるからです。3ヶ月というのは、仕様の渡し方とレビューの往復が定着するのにそれくらいかかる、という実感から置いている目安です。
「安いから」で受けたくない理由
オフショア＝コスト削減、というイメージは根強いです。実際、単価だけを比較すれば安くなります。僕らのラボ型契約は、エンジニア1名あたり月額40万円からです。
ただ、単価だけを理由に発注された仕事は、だいたいうまくいきません。安さが理由なら、より安いところが出てきた時点で乗り換える判断になる。乗り換えが前提の関係では、こちら側もドメイン知識を溜める投資ができないし、クライアントの業務を深く理解しないまま手だけを動かすことになります。それは結局、品質という形で発注側に返っていきます。
この考え方が正しかったかどうかは、続いた年数に出ると思っています。うちのラボ型契約の平均継続期間は1年半で、一番長いクライアントとは今6年目です。6年というのは、担当者が入れ替わり、システムの世代が変わってもなお一緒にやっている、ということです。単価の安さで選ばれた関係は、そこまで続きません。
僕らが取りたいのは、日本のIT人材不足という構造の中で、ベトナムの優秀なエンジニアと一緒に、品質を保ったまま改善速度を上げる、という位置です。単価が安くなるのはその副産物であって、目的ではありません。
オフショアが失敗するとき、だいたい原因は三つ
うちに相談に来る会社の話を聞いていると、過去の失敗の原因はかなり似ています。
一つ目は、仕様が言葉でしか渡っていないこと。 日本側が「よしなに」と伝え、ベトナム側が分かったと答え、出てきたものが違う。これは誰の能力の問題でもなくて、曖昧なまま進める運用を許した設計の問題です。うちが「誰が」「何を」「いつまでに」を毎回明確にするのは、この一点を潰すためです。
二つ目は、特定の一人に依存していること。 ブリッジ役の一人が全部を握っていて、その人が抜けた瞬間に何も進まなくなる。前の章で書いた「ヒーローを作らない」という方針は、社内の理想論ではなく、発注側のリスク管理の話でもあります。うちが評価するのは、徹夜で問題を解決した人よりも、次に同じ問題が起きたとき誰でも対応できるようにした人です。ドキュメントを書いた人、チェックリストを作った人、テンプレートを整備した人。発注する側から見れば、それは「担当者が変わっても同じ品質が出る」ということです。
三つ目は、品質の基準が共有されていないこと。 何をもって完成とするかが決まっていないまま作り始めると、レビューが個人の好みの応酬になります。完了の条件を先に文書にして合意してから作り、その文書をSSOT（唯一の正しい情報源）としてこまめに更新していく。遠回りに見えて、これが一番速い。
この三つは全部、距離があるから起きる問題ではなく、距離があると隠せなくなる問題です。だから僕は、オフショアの制約はいい先生だと思っています。曖昧さを排除しないと何も進まない環境で作った仕組みは、距離がないチームでもそのまま使えるくらい強くなる。
ヒーローを称えない、という選択
Linnoedgeでは、「ヒーローを称えるより、仕組みを作った人を評価する」という方針を取っています。
開発現場でよくある話で、誰かが徹夜で問題を解決して「あの人がいなかったら終わってた」みたいなことがある。それ自体は尊いことだけど、僕はそこに違和感を持っています。
誰かがヒーローにならなきゃいけない状態って、仕組みがまだ十分じゃなかったということだと思う。
だから、次にその問題が起きたときに誰でも対応できるようにした人の方を、僕は評価したい。ドキュメントを書いた人、チェックリストを作った人、テンプレートを整備した人。地味だけど、その人が作ったものは、その後ずっと組織を支えてくれる。
仕組みを作るというのは、次の人への贈り物を残すことだと思っています。
AI時代に、なぜ「構造」なのか
AIがコードを書ける時代になった。これは事実です。
でも、だからこそエンジニアの価値は「コードを書くこと」から「設計すること」に移っている。品質設計、アーキテクチャ設計、技術戦略。AIが速くなればなるほど、それを活かすための組織構造のほうが重要になる。
Linnoedgeでは、ITD（プロジェクト推進）とエンジニアリングを対等な責任として定義しています。どちらが上でも下でもない。ITDが顧客・納期に責任を持つように、開発チームは設計品質・技術戦略に責任を持つ。この二つが揃ったときに、チームは一番速く動ける。
AIは怖くない。構造が強いチームにとっては、むしろ追い風です。
発注を検討している方から「AIでどれくらい速くなるんですか」と聞かれることがあります。正直に言うと、コードを書く工程は確かに速くなりました。でも、プロジェクト全体の速度がそのまま同じ倍率で上がるかというと、そうはなっていません。
速くならないのは、仕様を決めるところと、出てきたものが正しいか確認するところです。むしろAIで生成量が増えた分、レビューと検証の負荷は上がっています。だから僕らは、AIで浮いた時間を値引きではなく、設計とレビューに振り直しています。
AIを使えば安くなります、と言うのは簡単です。でもそれをやると、品質を担保する工程を削ることになる。止まったら困るシステムを預かっている以上、そこは削れません。
リモートで、日本とベトナムをつなぐ
Linnoedgeはフルリモートのチームです。ベトナムと日本をまたいで仕事をしている。
リモートワークがうまくいかない原因の多くは、ルールがないことだと思っています。だから僕らは「Remote-First OS」と呼んでいるルールセットを作りました。
コアタイムを決める。3時間以内にレスポンスする。決まったことはログに書く。集中したいときはカレンダーをブロックする。期限までにコメントがなければ承認とみなす。
このルールは縛るためじゃなくて、全員が安心して自由に働けるための仕組みです。構造があるから、自由が生まれる。
こういう人と働きたい
正直に言うと、うちは大企業じゃない。知名度もまだまだだし、リソースも限られている。
でも、だからこそ面白いフェーズにいると思っています。組織の構造そのものを自分の手で設計できる。「こうした方がいい」と思ったことを、来週には実装できる。
こういう人と一緒に働けたら嬉しいです。
「自分がいないと回らない」を、かっこいいと思わない人。 自分がいなくても回る仕組みを作る方が価値があると思える人。それは諦めじゃなくて、設計だから。
曖昧なまま進むのが気持ち悪い人。 「なんとなく」で仕事を進めるのが嫌で、「誰が」「何を」「いつまでに」を明確にしたがる人。
距離があることを面白がれる人。 日本とベトナムの間で仕事をすることに不便はある。でもその制約を、「じゃあどう設計すればうまくいくか？」というパズルとして楽しめる人。
仕事は人を消耗させるものじゃない、と思っている人。 仕事がうまく回っているとき、人はエネルギーをもらえる。僕はそう信じてLinnoedgeを作っています。
最後に
Linnoedgeはまだ小さい会社です。でも、小さいからこそ、一人ひとりが作る仕組みがダイレクトに組織を変える。
僕らのカルチャーを一文にすると、こうなります。
「努力だけでは足りない。僕らが一緒に作る仕組みで、勝つ。」
話を聞いてみたい方へ
開発を任せることを検討している企業の方へ。 まだ発注を決めていない段階でも構いません。「今のこの状況でオフショアが合うのか」という相談が一番多く、合わないと思ったらそう言います。会社の詳しい情報はこちらにあります。 → https://linnoedge.com/?utm_source=wantedly&utm_medium=referral&utm_campaign=ceo-article
Linnoedgeで働くことを考えている方へ。 気軽に話を聞きに来てください。普段はフルリモートで動いているので全員が毎日そろうわけではないけれど、ホーチミンにオフィスはあります。面白い話はできると思います。
ホーチミンより。
原田祥吾 株式会社リノエッジ CEO
