オフショア開発チームと円滑に連携するには？

プロジェクトには複数の部門が関わることがありますが、それぞれの役割は同じではありません。質問を取りまとめる人が業務フローを確定できるとは限らず、予算を承認する人が個々の機能を確認するとも限りません。

例えば、購買申請の承認システムを開発するケースを考えてみましょう。これは説明のための仮定です。購買部門は申請の受け付け方を把握し、経理部門は予算上の条件を確認し、管理者は決裁金額の基準を判断します。すべての質問を一人に集めても、その担当者が誰に確認すべきか分からなければ、開発チームは回答を待つか、仮の判断で作業を進めることになります。

そこで、どの内容を誰が担当するかを双方で決めておきます。発注側では、業務内容を説明する人、変更を承認する人、成果物を確認する人を明確にします。開発側にも、進捗を取りまとめ、作業が止まっている理由を説明し、適切な相手に質問をつなぐ担当者が必要です。

複雑な体制をつくる必要はありません。小規模なプロジェクトなら、一人が複数の役割を兼ねることもあります。その場合も、本人が判断できる範囲と、ほかの人への確認が必要になる範囲は共有しておきましょう。

担当者に加えて、連絡を取りやすい時間帯、早めの回答が必要な場合の連絡方法、不在時の代理担当も決めておくと安心です。時差や祝日の違いがある場合は、相手の回答を思いがけず待つことのないよう、計画に織り込んでおきます。

ある要件が会議で話題に上がり、チャットで補足され、試作版を確認した後に変更されることがあります。結論がそれぞれのやり取りに散らばったままでは、作業する人がどの内容をもとに進めればよいか分からなくなります。

要件と関連する決定事項は、プロジェクト管理ツールや共有ドキュメントなど、一か所で確認できるようにしましょう。項目ごとに、議論の経緯、合意済みの内容、未解決の質問をたどれる状態にしておきます。

先ほどの購買システムでも、「承認機能を追加する」だけでは、さまざまな解釈ができます。誰が申請し、誰が承認するのか。却下されたらどうなるのか。申請者は内容を修正して再申請できるのか。こうした場面に沿って話せば、発注側は自分で技術的な仕様書を書かなくても、普段の業務をもとに要件を説明できます。

話し合いの後は結論を記録し、関係者が確認できるようにします。まだ決まっていない点は、合意済みの内容と混ぜず、「確認待ち」と分かる形で残します。その後に変更があった場合は、実際に参照しているドキュメントも更新する必要があります。

複数の言語を使うプロジェクトでは、役割やステータスの意味もそろえておきましょう。例えば「承認済み」は、上司の承認を指すのか、それとも経理による予算確認まで含むのか。業務上の意味が異なれば、言葉を正確に訳すだけでは、意図どおりの処理にはつながりません。

要件分析とは？開発の方向性を定める最初のステップ

「80％完了」という報告を受けると安心するかもしれません。しかし、それだけでは、どこまで試せるのか、次のマイルストーンに向けて何が障害になっているのかは分かりません。進捗を判断するには、作業がどの段階にあり、何を確認・テストできるのかを把握する必要があります。

例えば、購買申請を送信する機能の実装が終わっていても、ユーザー権限ごとのテストはまだかもしれません。それは、購買部門が試せる状態とは異なります。各ステータスの意味と、次の段階に進む条件を双方でそろえておきましょう。

報告の内容が曖昧なときは、次のように確認できます。

進捗報告	確認したいこと
「実装完了」	どこまでテストが済んでいるか。発注側はいつ確認・試用できるか。
「確認待ち」	何を決める必要があるか。誰が回答するか。待っている間、どの作業に影響があるか。
「確認可能」	どのバージョンをどこで確認するか。何を期待する結果として確認すればよいか。
「指摘対応済み」	何を修正したか。問題があった場面を誰が再確認するか。

すべてのプロジェクトで、同じステータスを使う必要はありません。大切なのは、報告を読んだときに、完了したこと、残っていること、協力が必要なことを、双方が同じように理解できることです。

文書での報告に加え、計画に合わせて成果物を確認する機会も設けましょう。承認機能なら、画面を一つずつ見るだけでなく、「社員が申請する」「管理者が却下する」「社員が修正して再申請する」という一連の流れを確認します。

この方法なら、業務を理解している人が、システムに実際の仕事の流れが反映されているかを確かめられます。合わない点があった場合も、「画面がイメージと違う」という曖昧な指摘ではなく、同じ利用場面をもとに話し合えます。

ただし、デモが問題なく進んだからといって、必要なテストや受入確認がすべて済んだわけではありません。機能の準備ができたら、プロジェクトで決めた範囲と基準に沿って、利用者が確認する機会を設けます。

受入テスト（UAT）で企業が確認すべきこと

成果物を確認した後は、具体的に伝えるほど、開発チームも修正すべき点を理解しやすくなります。「承認まわりが使いにくい」ではなく、「管理者が申請を却下しても、申請者には理由が表示されないため、何を直せばよいか分からない」と伝えてみましょう。

これなら、どの場面で何が起き、利用者が何に困っているのかが分かります。必要に応じて画面の画像や操作手順を添えますが、数行で伝わるのであれば、無理に長く書く必要はありません。

フィードバックをまとめる際は、合意した内容と異なる点と、試して初めて出てきた新しい要望を分けておきましょう。両者では対応の進め方が異なる場合があります。新しい提案は、計画に入れる前に影響を確認する必要があり、会議中の一言をそのまま承認済みの作業として扱わないようにします。

開発途中で要件が変わったときの対応方法

成果物への指摘だけでなく、回答待ちで作業が止まっている質問にも目を向けましょう。「お客様の確認待ち」とだけ書くより、何を決める必要があり、誰が回答し、遅れるとどの作業に影響するのかを明記した方が、対応を判断しやすくなります。発注側も時間がかかる場合はその旨を伝えることで、開発チームが作業順序の調整を検討できます。

解釈が分かれる内容や、チャットでやり取りしても結論が出ない内容は、資料を追加するより、必要な人を集めて短く話し合う方がよい場合もあります。話し合いの後は、決定事項と担当者を記録し、参加していない人も作業を続けられるようにします。

オフショア開発を円滑に進めるには、双方の関わりが欠かせません。役割を明確にし、情報を更新し、実際の業務に沿って成果物を確認することで、発注側は技術的な作業に直接関わらなくても、進捗を把握し、必要な判断を行いやすくなります。

これから海外の開発チームと協業する場合は、要件の共有、成果物の確認、変更への対応をどのように進めるか、話し合うことから始めてみてください。日々の作業に入る前に、開発パートナーと確認しておきたいポイントです。

Fenixにプロジェクトについて相談する