うちはホーチミンで、日本企業向けの開発会社をやっています。ベトナム人やインド人のエンジニアと一緒に、日本語もベトナム語も英語も飛び交う、非同期で動く多国籍チームです。
そういう環境で何年もやってきて一番痛感しているのが、「問題を早く言えるチームかどうか」で、最終的な品質がまるっきり変わる、ということなんですよね。これは感覚じゃなくて、実際に目の前で何度も見てきたことです。
だからうちでは、失敗した人を責めない、を割と本気でやっています。といっても品質にこだわらないわけじゃなくて、むしろ逆で。失敗が見える状態になっていないと、そもそも直せない。だからまず見えるようにする、を先に置いている、というだけの話です。
今日は、その「うちが企業文化として大切にしていること」を、そのまま書いてみようと思います。
失敗は許す。隠蔽は、許さない。
バグは出ます。仕様の認識違いも起きる。見積もり工数がずれることも多々あります。これはゼロにならないんですよね。プロが作っても、ベテランが設計しても、それでも出るときは出る。
じゃあ大事なのは何かというと、問題が出たとき、どれだけ早く共有できるかどうかです。
白状すると、僕も「問題が出たら、まず誰のミスなのか」をはっきりさせることが目的になりがち。でも多国籍チームで何年かやってみて、これは逆効果なんですよね。原因を人に紐づけると、次から人は黙る。黙られると、サブマリンバグになってしまい、見えないものは誰も直せない。
問題を見つけた人が「報告すると詰められる」と感じると、何が起きるか。報告が遅れる。遅れるだけじゃなくて、そのうち報告しなくなる。リモートで、言語も違う環境だと、この沈黙は特に速く広がるんですよね。現状の事実が見えないのは致命的です。
だからうちでは、振り返りの場から「誰が悪かったか」を意図的に外すようにしています。見るのは「何が起きて、次どう再発防止するか」だけ。これは優しさじゃなくて、直すための実務的なアクションです。誰かを責めた瞬間に、直すのに必要な情報が出てこなくなるのはさけたいのです。
バグ（問題）を見つけた人を褒める。ただし、問題を隠したまま進めることは、信頼を壊す。この2つをセットで企業文化として進化させることが、うちでは基本になっています。
具体的な話をすると、もう14年くらい前なんですけど、東京のビジネスショーで使うiPadのアンケートアプリを作ったことがあって。ブースに来た人に、その場で15問くらい答えてもらう、というシンプルなものでした。
これが、最後の3問だけ回答が記録されない、というバグを抱えていたんです。前半の質問はちゃんと取れているのに、その最後の3問だけ、保存されていなかった。しかもそれが分かったのが、ショー本番の2日前でした。あれは痺れましたね。
その瞬間に頭をよぎるのは、正直「テストはちゃんとやり切れていたのか」と「お客さんにどう説明すればいいんだ」です。隠したいというより、説明する自分がしんどい。でも、言わない選択肢はないんですよね。黙って当日を迎えて、現場でデータが欠けているほうが、はるかに信頼を壊す。
このとき体で覚えたのは、バグそのものより「いつ、どう言うか」のほうが信頼に効く、ということでした。問題が起きること自体は避けられない。でも、起きたと分かった瞬間に隠さず出せるかどうかで、その後の関係が決まる。あの2日前に「言う」と決めたことは、今でも自分の中の基準になっています。
仕事は、見える場所で進める。
これが、実は一番難しいんですよね。透明性って、どこまで何をオープンにするかが曖昧で。
僕が大事にしたいのは「全部公開しろ」じゃなくて、必要な人が、必要な情報に、必要なタイミングで届く状態、という意味です。
これ、国内の同じオフィスにいるチームなら、そこまで意識しなくても回るんですよ。隣の席で聞けるし、顔色も見える。「分かった？」が本当に分かっているか、その場でだいたい察しがつく。でも時差があって、言語が違って、非同期で動くと、その「なんとなく伝わる」が一切効かなくなる。「分かりました」がどれくらい分かっているのか、画面の向こうが見えないんです。
だからうちは、記録に倒しています。意識の高さとか性善説の話じゃなくて、口頭が物理的に成立しないから書くしかない、というだけの話なんですよね。正直、きれいな仕組みを目指しているというより、そうしないと普通に事故る、という後ろ向きな動機のほうが大きい。先に書いてしまえば、少なくとも「言った・言わない」で信頼をすり減らすことはなくなる。
ヒーローより、直せるチームをつくる。
属人化って、どう減らすか。うちの答えは「2回以上やる作業は手順化して、誰でもできる形に書き起こす」なんですけど——これ、昔の僕はむしろ逆だったんです。「あの人がいれば大丈夫」という状態、実はこれが一番好きでした。優秀なエースエンジニアに全部任せておけば、確かに速いし、品質も出る。だから昔は、強い人を見つけてそのひとがやりやすい環境をつくることが「いいマネジメント」だと思っていました。今でもそれは、ひとつの成功する仕組みだとも思っています。
でも、考えが変わったのは、その「あの人」が休んだり抜けたりするたびに、チームが一瞬で止まるのを何度か経験してからです。一人しか分からないコード、一人しか対応できない顧客、一人しか判断できない仕様。エースに寄りかかっているときは楽で強みに見えるんですけど、抜けた瞬間にそれが全部リスクになるんですよね。
だからうちでは「2回以上やる作業は手順化する」を半分ルールにしています。同じことを繰り返すなら、誰でもできる形に書き起こす。書いてレビューして直す。地味なんですけど、これを続けると「あの人しかできない」が一個ずつ減っていくんですよね。
AIの時代になって、この考え方はさらに重要になったと思っていて。個人が速くなることはできる。Claude CodeやCursorを使えば、一人のエンジニアの生産性は確かに上がった。でも「チームで誰がやっても同じ品質が出る」ことは、ツールを配るだけでは手に入らないんです。これは別の記事で詳しく書いたんですけど、配れるのは仕組みだけ、という話と同じです。
ヒーロー1人に頼るより、みんなで直せるチームにしておくほうが、あの「エースが抜けて一瞬で止まる」場面が来ないんですよね。地味だし派手さもないんですけど、僕はそっちのほうが、安心して人に任せられます。
小さく作り、早く学ぶ。
「小さく作って、早く見せる」これ自体はもう新しい話じゃないですよね。ただ、僕たちがオフショア開発でここに強くこだわるのには、距離のあるチームならではの理由があって。
時差と言語が挟まると、仕様の読み違いが何日も表に出てこないんです。「分かりました」と返ってきても、実際に上がってきたものを見るまで、認識がずれていたことに気づけない。だから、完成度を上げにいく前に「方向が合っているか」を先に確かめにいきます。
特にAIを使った機能開発や、ユーザーの行動が読みにくいtoC系のシステムは、仕様を固める前に動かしてみる方が、最終的な完成度が上がることが多い。僕たちが今作っているAIを活用した業務システムでも、この感覚は毎回ある。
だから今は、小さく作って早く見せるプロジェクト進行に倒しています。分厚い仕様書で手戻りを増やすより、こっちの方が結局シンプルにスムーズに仕上がるんですよね。
「後から大きく直す」のと、「早く小さく直す」のでは、工数も認識齟齬も、顧客満足も変わってくる。常駐でなく、時差があって、言語が違う場合は特に、後工程への持ち越しがコストになる。だからこそ、早く見せる文化が効いてくるんです。
AIにも、同じ文化を当てはめる。
最後にAIの話を。ここ最近、AIの使い方が「質問したら答える」から「自分で手を動かす」に変わってきましたよね。コードを書く、調べる、ドラフトを作る、チケットを起票する。指示を待つツールというより、タスクを渡すと勝手に進めていくエージェントに近くなってきている。うちのチームでも、もう日常的にそういう使い方をしています。
そうなると、論点が一個ずれるんです。少し前までは「AIの答えは間違っているかもしれないから、人が後ろでチェックしよう」で済んでいました。でもエージェントが実際に手を動かす量が増えてくると、全部を人が後ろから見張る、では追いつかない。チェックする人がボトルネックになって、結局スピードも落ちるし、見落としも増える。
じゃあどうするか。うちは、AIを「新しく入ったチームメンバー」と同じように設計することにしています。ただ、人間の新メンバーと一個だけ決定的に違うことがあって。人間には研修期間があるじゃないですか。最初は小さい仕事から渡して、やり取りを重ねながら、お互いに信頼を積み上げていく。でもAIエージェントには、その積み上げの時間がないんですよね。入った初日から、フルスピードで手を動かしてくる。
だから、人間なら「時間をかけて作る信頼」にあたる部分を、最初の設計のほうで先に用意しておくことになる。どこまで任せるか、何を後から戻せる範囲に収めておくか。それを、渡す前に決めておく。新しいメンバーを信頼していくのと、やっていることは結局同じなんですよ。違うのは、信頼を積む時間がない分、その代わりを設計のほうで先に渡しておく、というところだけ。
「技術的には作れます」だけで突っ込む案件は、正直うちではやりたくない。誰のためになるのか、間違えたとき誰がどう気づいて戻せるのか。そこを最初に決めておく方が、後から「そういうつもりじゃなかった」になるより、お互いずっと楽なんです。発注側から「堅いな」と言われることもあるんですけど、ここは譲らないようにしています。
信頼を設計する、という考え方
まとめると——うちが企業文化として大切にしていることは、失敗しないことじゃないです。失敗は避けられないという前提に立って、起きたときに早く見える状態をつくる、というほうに振っている、という話です。
バグは直せます。認識違いも直せる。設計ミスも、見つければ改善できます。でも、隠された問題だけは直せない。14年前のあのアンケートアプリも、2日前に「言う」と決めたから直せた。黙って当日を迎えていたら、ブースでデータが欠けたまま、それに気づけもしなかったはずです。
オフショア開発って、「安くできる」で選ばれることが多いんですよね。でも、長く一緒にやっていける会社かどうかを決めるのは、価格より先に、こういう文化の部分だと思っています。安さだけなら、もっと安いところはいくらでもあるので。
もし「うちの開発チームと文化が合うかどうか」を確かめたい方は、下のボタンから30分の壁打ちを使ってもらえれば。技術の話より先に、どういう仕事の仕方をしているかを聞いてもらうのが一番早いと思っています。
「合うかどうか」を、まず話してみませんか
価格や技術スタックより先に、どういう仕事の仕方をしているか——問題が出たときどう動くか、何を記録に残すか。御社の状況を聞きながら、文化が噛み合うかを一緒に確かめます。営業というより、壁打ちのつもりで来てもらえれば。
30分の壁打ちを予約する →よくある質問
Linnoedgeはどんな企業文化を持っていますか？
透明性・文書化・チームで品質を守る姿勢を重視しています。バグや問題を報告した人を守りつつ、隠蔽は許さない方針です。リモート・多国籍チームで働くため、チケット・議事録・意思決定ログを「信頼のインフラ」として運用しています。詳しくは本記事をご覧ください。
オフショア開発で失敗しないために、一番重要なことは何ですか？
「問題が隠れない環境をつくること」です。時差・言語・文化の壁がある分散チームでは、問題が出たとき報告が遅れると取り返しがつかなくなります。Linnoedgeでは「早く小さく共有する」文化を開発プロセスの中に組み込んでいます。オフショア開発サービスの詳細はこちら。
AIを使った開発を依頼するとき、何から相談すればいいですか？
「技術的に作れるかどうか」より先に、「誰のためになるか・間違えたとき誰がどう気づいて戻せるか」を一緒に整理することから始めます。まずは30分の壁打ちで現状をお聞かせください。
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。