会議では全員がうなずいていたのに、翌日になると実装の方向が違っていることがあります。 ベトナムの開発チームと働き始めたころ、私はこれを英語力の問題だと思っていました。
ただ、同じ言語で働くチームでも、確認を省いた要件はずれます。 オフショア開発では、そのずれが早く見えるだけでした。
会議で話した内容を、相手が実行できる約束へ変えるために、私は次の三つを確認しています。
決まったことを一枚に残す#
会議の議事録を長く残しても、次に着手する人が判断を見つけられなければ意味がありません。 会議の直後に、背景、決定、未決事項を短く書きます。
- 背景：なぜ今この変更が必要なのか。
- 決定：誰が何を、どの条件で進めるのか。
- 未決事項：止まったときに、誰へ何を確認するのか。
「画面を修正する」とだけ書くと、文言、挙動、対象ユーザーのどれを変えるのかが残りません。 決定を読んだ人が、会議に参加していなくても次の作業を選べるかを基準にします。
相手の言葉で次の作業を確認する#
「分かりました」と返ってきた時点では、理解の深さは分かりません。 その場で説明を繰り返すより、担当者に次の作業と懸念点を自分の言葉で書いてもらうほうが、認識ずれを見つけやすくなります。
私は「次に何を作る予定ですか」「判断に必要な情報は足りていますか」と聞くようにしています。 答えが違えば、相手の理解不足と決めつける必要はありません。 話した側が、判断材料を渡し切れていなかったことも多いからです。
この確認を会議中に行うと、後から成果物を戻すより小さな修正で済みます。
完了条件を先に見せる#
作業の依頼には、始める条件だけでなく、終える条件も必要です。 たとえば「ログイン画面を作る」なら、画面を表示できれば終わりなのか、エラー表示や確認メールまで必要なのかで、実装範囲が変わります。
私は、確認するときに次の三点を置きます。
- 何が表示または実行できれば完了か。
- どのケースでは失敗として扱うか。
- 誰が、どの環境で確認するか。
仕様を厚くするためではありません。 実装者が作業中に勝手な判断をしなくて済むようにするためです。
オフショア開発の良さは、言葉が違うことそのものではありません。 前提が共有されていないときに、その不足を見過ごしにくいことです。
会議を終えたあと、決定を一枚に残し、担当者の次の作業を聞き、完了条件を並べる。 この三つを続けると、「伝えたつもり」のまま進む作業を減らせます。 AI時代にオフショアで働く日本人として考えていることは、オフショアで働く日本人が、AI時代に生き残るにはにも書いています。
