こんにちは、リノエッジ代表の原田祥吾＠ベトナムです。
「オフショア開発 失敗」で検索して、対策をまとめた記事を何本か読んでいる途中だとしたら、たぶんもう気づいていると思うんですよね。書いてあることが、どこもだいたい同じだということに。
今日は、その対策リストが間違っている、という話はしません。逆です。あのリストは、たぶんもう正しい。それでも失敗が減っていないので、問題は別のところにあるんじゃないか、という話をします。
結論から言っちゃうと、差がつくのは対策の中身ではなく、それが続いているかどうかを誰かが見ているところです。地味な結論ですみません。でも、うちが毎週やっていることを書き出すと、そこに行き着きます。
オフショア開発の失敗対策として、何が言われているか
よく挙がる対策は、だいたい4つに収まります。週に1回、決まった曜日に定例をやる。決まったことは議事録にして、担当者とネクストアクションまで書く。決まったことは、関係者がいつでもオンラインで見られる場所に置く。そして完了の条件を先に文書にして合意し、SSOT（正となる1つの置き場）として最低でも週2回は更新する。
この4つは、僕にとって特に新しいことではありません。システム会社として当たり前だし、リモートワークをする会社としても当たり前のことだと思っています。定例は、クライアントと制作側のギャップをなくすためにやる。それ以上でも以下でもない。これで助かった人は毎週出ていると思っていますし、そもそもこれがなければプロジェクトは回っていかない。
これはうちの発明でもないですし、たぶん御社の中にも、同じことを言っている人がすでにいると思います。
対策が出尽くしても、予定どおり終わる割合は下がっている
ここで1つ、公開データを見てもらいたいです。日本情報システム・ユーザー協会（JUAS）が経済産業省の監修で毎年出している「企業IT動向調査」の2025年版（2024年度調査・回答981社）に、システム開発の工期遵守状況の推移が載っています。
2024年度に「予定どおり完了」したプロジェクトの割合は、100人月未満で31.0%、500人月以上だと11.0%。資料の見出しには、こう書かれています。「10年間（15〜24年度）の推移では、すべてのプロジェクト規模で『予定どおり完了』の割合が低下傾向にあり、２４年度においても改善の兆候は見られない」
この数字はオフショアに限った話ではありません。国内も含めたシステム開発全体のものです。ただ、週次定例も議事録も国内外で共通の対策なので、「知らないから失敗しているのか」を見るにはこの分母で足ります。
この数字が何を意味するか、1つだけ書いておきます。週次定例も、議事録も、タスク管理ツールも、この10年で新しく発明されたものは1つもありません。それでも「予定どおり完了」は下がり続けている。だとすると、対策を知らないことが原因だとは、少し考えにくいんですよね。10年あれば、知識としては十分に行き渡っているはずなので。
じゃあ、何が難しいのか
ここからが、今日いちばん言いたいところです。
議事録も作ります。タスクも作ります。全部作れます。難しいのは、それをチェックすることのほうなんです。どのレベルで達成しているのか。ここは、ごまかそうと思えばごまかせてしまう。
たとえば議事録は、書いてあること自体は本当でも、決まらなかったことが書かれていないことがあります。タスクは、期限を先に延ばせば未達にはなりません。完了条件も、曖昧なまま合意しておけば、どうとでも読める。忙しければ、自然にこうなります。だから最後は、ある程度カルチャーとして自己責任の領域になり、どのレベルでやるかは人による部分がどうしても出てくる。
特に入ったばかりのメンバーには、このレベル感がいちばん伝わりにくいです。でもこれは相手の問題というより、僕が「できている」の線をどこに引いているかを、言葉にしないまま期待していたという話なんですよね。だから最初の数ヶ月は、その線がどこにあるのかを言葉にするところから始めることになります。
簡単に言うと、ちゃんと見てる、ということ
やれた時は、やれたねと言う。やれてない時は、やれてないよねと言う。フィードバックをする。書いてしまうとこれだけです。地味なんですが、すごく大事なことだと思っています。
仕組みのほうは、正直コピーできます。定例の枠をカレンダーに置くのも、議事録のテンプレートを配るのも、1日あれば終わる。でも「先週やれてなかったことを、今週その場で本人に言う」は、毎週やらないと成立しません。しかも、言われた側が納得していないと次の週に効きません。ここだけは、テンプレートを配っても増えないんですよね。
見る人が要るなら、人が増えたら回らないのでは
この話をすると、だいたいここを突かれます。全部を見ている人が要るなら、それは属人的で、人数が増えた瞬間に破綻するんじゃないですか、と。もっともだと思います。
いまは、見る人を増やすほうで持たせています。僕が全部を見るのは無理なので、リーダーが自分のチームの達成レベルを見て、僕はリーダーの見方のほうを見る。継承して、どんどんリーダーになってもらう。人数が増えても回るかは、これから試されるところです。
ひとつ自分でも引っかかっているのは、「ちゃんと見てフィードバックする」が、個別に人の時間を使う行為だということです。僕はダメな人を放っておけない癖があって、それは経営者の悪癖だと自分では思っている。なので線引きを1つだけ決めています。個別に救うのではなく、見方のほうを渡して継承する。そこを外れたら、それは僕の悪癖のほうです。
ただ、基準は放っておけば薄まります。一代目は僕の基準を直接知っていますが、二代目が受け取るのは一代目の解釈のほうなので。伝言ゲームと同じで、悪気なく少しずつ削れていく。
それを防ぐためにやっているのが、書くことと、全体定例で扱うことです。うちの会社はこういうふうにやっているんですよ、というのをブログや文書にする。それを全体定例ミーティングで扱って、ポイントポイントで底上げを図る。リーダーもそこでより理解できる。二代目、三代目には理解しきれない部分もあるかもしれませんが、そこはリーダーがフォローしていく。それで足りているのかは、まだ分かりません。
たとえば6月に「バグは直せる。隠すことは、信頼を壊す。」というブログを書きました。僕の中では「正直でいろ」という話です。これについては、全体定例とは別に、プロジェクトマネージャーたちと4人でミーティングで話しました。プロジェクトマネージャーとして、お客さんに正直でいること。それから、ボスに正直でいること。
話してみると、正直でいることは、思っていたより難しいものでした。できるふりをする、失敗を言わずにおく、というのは、本人に嘘をついている自覚がないまま出てしまうことがあるからです。
それでも、できるふりや失敗を隠すのはカッコ悪いことで、ボスはそれを許さないんだ、ということは感じてくれたと思います。簡単には変わらないんですが、トレーニングを積んで、徐々に良くなってきた、という感じです。基準を配るというのは、そういう地味な作業のことなんですよね。
白状すると、これは僕自身にも効いています。僕もお客さんの前でいい格好をしたくなる時はあるんですよね。でも、みんなにそう言っている以上、僕がお客さんに嘘をつくことは絶対にできない。この副次的な効果は、かなり大きいと思っています。
スキルの問題ではない、と言いたいわけではない
さっきのJUASの資料は、工期や品質が悪化している背景について、こうも書いています。「システム開発の難易度が上昇するなか、それに対応できる人材を確保することが困難になっており、QCDの悪化に影響を及ぼしている」
つまり、技術力や人材確保は今もはっきり効いている要因だということです。運用さえ回っていれば誰でも同じ、という話にはならない。そこを飛ばして「大事なのは仕組みです」と言うのは、雑だと思います。
そのうえで、あえて僕が1つだけ選ぶなら、やっぱり見てフィードバックするほうです。理由は単純で、スキルの差は見えるからなんですよね。面談でも、コードでも、経歴でも、ある程度は見える。見えているものは対策も打てます。一方で「今週の達成レベルが先週より少し下がっている」は、誰かが見ていなければ、誰にも見えないまま過ぎていく。厄介なのは、たいてい見えないほうだと思っています。見えないほうに時間を使うしかない、というのが今の結論です。
発注する側は、どこを見ればいいか
いまオフショアの発注先を選んでいる立場なら、確認する場所が少し変わってくると思います。「週次定例をやっていますか」「議事録は出ますか」は、たぶん全社がやりますと答えます。ここで差はつきません。
代わりに、こう聞いてみるのがいいと思います。「先週やれていなかったことは、今週の定例で誰が、どう扱いましたか」。これで見分けがつくと断言はできません。ただ、定例や議事録の有無と違って、この質問は答え方に運用のクセが出ます。一般論しか返ってこないなら、そこから先を聞いてみる価値はあると思います。
もう1つ現実的な手は、最初に1〜2ヶ月だけ小さく発注して、定例の中身を見てから広げること。うちが失敗の原因を「相性」や「国」のせいにするのをやめた経緯は別の記事に書きましたし、毎週の定例で実際に何が起きているかという話はシステム会社は何を売る会社なのかにまとめてあります。うちのラボ型・受託の体制そのものはベトナムオフショア開発のサービスページにまとめてある。
対策リストは正しい。差はその後にある
というわけで、対策リストは正しいし、うちも同じことをやっています。そこは差にならない。差になるのは、その当たり前が来週も再来週も続いていて、どのレベルで達成できているかを誰かが見ている、という部分のほうかなと思っています。
うちがやっているのも、やれた／やれてないをその場で言う、それだけです。派手なことは何もしていません。ただ、これを毎週続けるのがやっと、というのが実際のところです。
よくある質問
オフショア開発の失敗を防ぐには、まず何から始めればいいですか?
週次定例・議事録と担当者の明確化・オンラインでの共有・完了条件の事前合意の4つが基本です。ただ、この4つはたいていの会社がすでに置いています。最初の一歩としては、先週やれていなかったことを今週の定例でその場で扱ってみるのがいいと思います。仕組みを足すより、いまある仕組みが続いているかを見るほうが先です。
発注先の候補が本当に運用を回せているか、契約前に見分けられますか?
「先週やれていなかったことは、今週の定例で誰が、どう扱いましたか」と聞いてみるのがいいと思います。定例や議事録の有無は、どこでも「やっています」と答えるので差が出ない。でもこの質問には具体的な場面が要ります。一般論で返ってくるか、実際の1件が出てくるかで、かなり見えてきます。もう1つの手は、最初に1〜2ヶ月だけ小さく発注して、定例の中身を見てから広げること。
オフショア開発が失敗するのは、技術力の差が原因ではないのですか?
技術力も要因です。JUAS『企業IT動向調査2025』も、開発の難易度が上がるなかで対応できる人材の確保が難しくなり、QCDの悪化に影響していると書いています。そのうえで1つ選ぶなら、僕は達成レベルを見てフィードバックするほうを選びます。スキルの差は面談やコードである程度見えますが、今週の達成レベルが少し下がっていることは、誰かが見ていないと誰にも見えないからです。
「その運用、続いていますか」を一緒に見ます
オフショアの発注先を選んでいる途中でも、いま動いている開発に引っかかりがある途中でも、この記事の続きを「御社の場合はどうか」という角度で話します。次の定例で確認する項目くらいは持ち帰ってもらえると思います。ちなみに、これはうちへの発注の入口でもあります（笑）。切り離して使ってもらってかまいません。
30分の壁打ちを予約する → お問い合わせフォームへ →
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。