オフショア品質の本質｜「言われたまま作る」が起きる理由
仕様書に書かれていないことに気づける人がいるかどうかが、質を分けます。
オフショア開発で「品質が上がらない」という話は、 たいてい技術力の問題として語られます。 しかし実際に手を動かしているエンジニアの技術力は、国内と大きく変わりません。
それでも仕上がりに差が出るのは、 「言われた通りに作る」以外の動きが起きにくい構造があるからです。
良いものは「気づき」から生まれる
サービスの質を上げているのは、多くの場合、仕様書に書かれていない部分です。
- この文言だと初めて見た人には伝わらないのではないか
- この順番だと、実際の業務では逆のほうが自然ではないか
- ここでエラーになると、利用者は何をすればいいか分からない
- この画面、そもそも要るのか
これらは仕様書には書かれていません。 書き手が気づいていないから書かれていないのであって、 手を動かす人が違和感を持って初めて表に出ます。
国内で開発しているとき、この指摘は自然に出てきます。 作っている人が、そのサービスの利用者側の感覚を持っているからです。 日本のECサイトを日常的に使い、日本の商習慣を知っていれば、 「この確認画面は要らないのでは」と思えます。
その気づきが生まれにくい構造
ここからは筆者の見方ですが、 オフショアで品質が伸びない最大の理由は、 作り手がそのプロダクトに関心を持ちにくい構造にあると考えています。
| 要因 | 何が起きるか |
|---|---|
| 対象のサービスを日常的に使っていない | 使いにくさに気づく機会がない |
| 言語が違う | 文言の不自然さを判断できない |
| 商習慣・法規制を知らない | 業務としておかしい流れに気づけない |
| 誰が使うのか見えない | 利用者を想像しながら作れない |
| 指摘しても伝わりにくい | 言うだけ手間なので言わなくなる |
| 契約が「仕様通りに作ること」 | 仕様に従うのが正しい振る舞いになる |
これは能力の問題ではありません。 日本のエンジニアが、言葉の分からない国の、 使ったことのない業務システムを仕様書だけ渡されて作れば、 まったく同じことが起きます。
最後の行が特に効いています。 受託の契約では「仕様通りに作ること」が正しい仕事です。 仕様と違うものを提案して手戻りになれば、責任を問われるのは作った側です。 疑問を持たずに作るほうが、合理的な振る舞いになってしまいます。
結果として起きること
- 仕様書通りだが使いにくいものが出てくる
- 明らかな矛盾もそのまま実装される（指摘されない）
- 書き漏らした部分が抜け落ちる（補ってもらえない）
- 「動くが、誰も使わない」機能ができる
- 検収してから作り直しになる
2つめは実務で最も困ります。 仕様書に矛盾があっても、そのまま矛盾したものが納品されます。 国内なら「ここ、おかしくないですか」と確認が入る場面です。 この1往復が無いだけで、手戻りの量が変わります。
向く案件と、向かない案件
| 向いている | 難易度が高い |
|---|---|
| 仕様が確定した業務システムの実装 | 使われ方を見ながら育てるサービス |
| 既存システムの移植・作り替え | UIの細部が成果を左右するもの |
| テスト・検証 | 日本特有の商習慣が絡む業務 |
| 保守・運用 | 要件が固まっていない新規開発 |
| データ処理・バッチ | toC向けで文言の質が効くもの |
右側が悪いわけではなく、体制の作り方が変わるということです。 判断を伴う部分を発注側に残し、 実装を任せる形にすれば成立します。 丸ごと任せて良いものが出てくることを期待すると、うまくいきません。
品質を上げるためにやること
- 「なぜ作るのか」を最初に共有する（誰が、どんな場面で使うのか）
- 実物を触ってもらう（既存サービスがあるなら、まず使ってもらう）
- 疑問を出すことを歓迎する姿勢を明示する
- 指摘に対して理由を返す（採用しない場合も、なぜかを説明する）
- UIと文言の判断は発注側が持つ（任せきらない）
- 同じメンバーで続ける（毎回入れ替わると蓄積が残らない）
3つめと4つめが要です。 一度「言われた通りに作ってください」と返してしまうと、 そのチームからは二度と指摘が出てきません。 採用しない提案にも理由を返し続けることでしか、 指摘が出る関係は作れません。
6つめも軽視できません。 同じメンバーが続けば、そのサービスへの理解は少しずつ溜まります。 逆に案件ごとに人が入れ替わる体制では、 毎回ゼロから説明することになり、いつまでも「言われたまま作る」状態から出られません。 体制を選ぶときは、単価より継続性を見てください。
発注前に確認すること
- 担当メンバーは固定されるか（案件ごとの寄せ集めではないか）
- 過去の案件で、仕様への指摘を出した例があるか
- 日本語で議論できる人が何名いるか（1名だと属人化する）
- 対象の業界・業務の経験があるか
- 離職率と、抜けたときの引き継ぎ
2つめは具体例で聞いてください。 「提案もできます」と答える会社は多いので、 実際に仕様を覆した事例があるかを尋ねると、 体制の実態が見えます。
※ 本記事のうち「関心が持ちにくい構造」に関する部分は、 筆者の実務上の見方です。体制や案件によって状況は異なります。
よくある質問
オフショアの品質が低いのは技術力の問題ですか？
違います。技術力そのものは国内と大きく変わりません。問題は「言われた通りに作る」以外の動きが構造的に起きにくいことです。言葉が通じにくく、対象のサービスを日常的に使っていない環境では、仕様の違和感に気づいても言い出す理由が生まれません。
仕様書を細かく書けば解決しますか？
手戻りは減りますが、限界があります。仕様書に書ける範囲を超えた判断（この文言は分かりにくい、この導線は使いづらい）は、書き手が気づいていないから書かれていません。書かれていないことに気づける人がいるかどうかが本質です。
日本人のブリッジ人材を置けば解決しますか？
改善しますが、1名だと限界があります。ブリッジ人材は翻訳と調整で手一杯になりやすく、プロダクトの良し悪しまで見る余力が残りません。ブリッジではなく、発注側が判断を担う体制のほうが確実です。
どういう案件なら問題になりにくいですか？
仕様が確定していて、判断の余地が少ない案件です。基幹システムの移植、既存画面の作り替え、テストや保守などが該当します。逆に使われ方を見ながら育てるサービス開発は、最も難易度が高くなります。
掲載している金額は、一般的な発注で見かける水準をもとにした目安です。 実際の費用は要件・地域・体制によって変わります。必ず複数社から見積もりを取り、 「何が含まれていて、何が含まれていないか」を比べたうえでご判断ください。