Drupalオフショア開発： 品質を「仕組み」で担保するベトナムチームの体制
あるお客様は、過去のオフショア開発で「仕様書を渡したのに違うものが上がってきた」経験から、発注に強い不安を持っていました。しかし原因を分解すると、それはエンジニアの能力ではなく、仕様の曖昧さを検出する工程が無かったことにありました。
オフショアの失敗は、多くの場合「人」ではなく「仕組み」の問題です。だからこそ、仕組みで解決できます。
本記事では、当社Drupalチームの体制・ワークフロー・品質保証プロセスを、運用しているそのまま公開します。
Drupalオフショアで、何が成否を分けるのか
まず、うまくいかない構造を整理します。原因はほぼ4つに集約されます。
– 仕様書の曖昧さを洗い出す工程が無い → 推測で実装し、手戻り2〜3週間
– 質問のエスカレーション経路が未定義 → 質問が来ないまま進み、完成後に全面修正
– テスト観点が担当者の主観 → テストは通るのに本番で壊れる
– 設計・レビュー基準が属人化→ 担当交代で品質が落ちる
いずれも優秀な人材の採用では解決しません。工程で解決する問題です。
そしてDrupalは、実は分散開発と相性の良いCMSです。「設定で組み立てる」割合が大きく、その設定はConfiguration Managementでコード同様にバージョン管理・環境間同期できます。「環境が違うから動かない」が起きにくい構造です。
品質を担保する4つの仕組み
① 設計書・テスト観点の標準化 — フォーマットとテスト観点リストを社内標準として定義しています。担当者が替わっても成果物の粒度が揃い、属人化を防ぎます。
② 独立した品質保証部門によるレビュー — 開発チームとは別の品質保証部門が、原因分析・不具合チェックを独立した立場でレビューします。開発者が自分のコードをレビューする構造を避けています。
③ Drupal特有のチェック項目— 一般的なWeb開発の観点に加え、Drupal固有の確認を工程に持っています。コアハック（コア直接改変）の有無、フック／プラグインによる正しい拡張、権限設定の妥当性、キャッシュタグの設定漏れ、そして使用モジュールがセキュリティアドバイザリ対象か。最後の項目は特に重要で、対象外モジュールは脆弱性が見つかっても公式対応がありません。当社は採用前に必ず確認します。
④ 設定のバージョン管理による環境差の排除 — DrupalのConfiguration Managementで、コンテンツタイプ・フィールド・ビュー等の設定をYAMLとして書き出し、Gitで管理します。「本番で誰かが手動で設定を変えた」を検出でき、日本側とベトナム側の環境差もなくなります。
注意すべきリスク
オフショアを検討する際、正直にお伝えすべき点です。
– 時差の小ささは前提条件であって、品質保証そのものではありません。日本・ベトナムの時差は2時間ですが、仕組みが無ければ近くても失敗します。
– 「自動テストがある」の中身を確認すべきです。カバー範囲が主要導線に限られるのか、網羅的なのかで意味が変わります。ツール名だけでは判断できません。
– 属人化はオフショア特有ではなく、標準化で防ぐしかありません。「優秀な担当者がいる」は、その人が抜けたときのリスクと表裏です。
– コアハックは数年後に効いてきます。納品時は動いていても、コアを直接改変していると以後アップデートが当てられません。発注時点で禁止事項として握るべき項目です。
日本市場の動向
日本国内では、開発リソース不足を背景にオフショア活用が広がっています。
– 品質保証の現場では自動化の不足が課題として繰り返し指摘され、専門人材の不足も深刻です
– ベトナムは日本との時差が2時間で営業時間がほぼ重なり、「質問と回答がその日のうちに1周する」点で他の遠隔地より有利です
– Drupalのように設定をコード管理できる基盤は、分散開発の環境差リスクを構造的に下げます
TTVの実際のDrupal開発体制
当社のDrupalチームは、日本市場向け・非日本市場向けの複数プロジェクトを並行して担当する専任組織です。
対応実績のある領域は、ECサイト、コーポレートサイト、ヘルスケア、ホスピタリティ管理システムなど多岐にわたり、これまで10サイト以上の構築・保守運用を担当してきました。バージョンアップは最新のDrupal 11まで対応しています。
役割ごとの担当内容
各役割が「何に責任を持つか」を明確に分けています。これが属人化を防ぎ、担当交代時の品質維持につながります。
| 役割 | 担当内容 |
| PM | 要件整理、スケジュール管理、日本側との窓口 |
| BrSE | 仕様の翻訳・橋渡し、曖昧点の事前洗い出し |
| Drupal開発 | モジュール選定・カスタム実装、コアハック回避の設計 |
| QA | 独立した立場での不具合レビュー、Drupal特有チェック項目の実施 |
| R&D | 技術レビュー、難易度の高い実装の検証、モジュールの内 |
チーム全体を横断して、R&Dエンジニアが技術レビューに入ります。これにより、プロジェクトが違っても技術判断がばらつきません。このエンジニアは実務で必要になった機能を20のContribモジュールとしてDrupalコミュニティに公開しており（[drupal.org/u/zipme_hkt](https://www.drupal.org/u/zipme_hkt)）、代表例に Context Breadcrumb（コンテキストに応じた動的なパンくず定義）、Node Preview Context（プレビュー画面でのノードコンテキスト条件の不具合を解消）があります。「使う側」ではなく「作る側」の知見があるため、要件に対して既存モジュールで足りるのか、拡張が必要なのかの判断が早い段階で下せます。
進め方のポイント
役割分担は、実際の工程で次のように機能します。
– BrSEが仕様の曖昧さを事前に洗い出す— 実装に入る前に「解釈が分かれる箇所」を日本側へ確認し、推測での実装による手戻りを防ぎます
– 独立したQAが本番前にコアハックの有無を検出する — 開発チームとは別の目で、以後のアップデートを妨げる実装が混入していないかを確認します
– 開発段階からコアハックを回避する設計 — QAで見つけて直すのではなく、そもそも作り込まない方針を開発側が持ちます
成果
こうした体制により、大きな手戻りなくリリースし、以降の保守運用も継続してご依頼いただく案件につながっています。品質を仕組みで担保することが、単発の納品ではなく長期的なお取引に返ってくる、という考え方です。
まとめ
テーマは「能力ではなく、仕組みで担保する」です。
– オフショアの失敗原因は、エンジニアの能力ではなく工程設計の不在です。
– 当社は標準化・独立QA・Drupal特有チェック・設定のバージョン管理の4つの仕組みで品質を担保します。
– 日本・ベトナムの時差は2時間。質問と回答が当日中に1周します。
– Drupalは設定をコード管理できるため、分散開発と構造的に相性が良いCMSです。
Drupalのオフショア開発・ラボ型開発のご相談を承っております。体制と工程のご説明のみ、実際の設計書サンプルの提示のみでも対応可能です。
Drupalのオフショア開発にご関心のおありの方は、お気軽にお問い合わせください。
出典
– transcosmos technology Vietnam サービス
