オフショア開発が失敗するのは、たいてい仕様書のところから

オフショア開発がうまくいかなかった話を聞くと、コードの品質より前に、仕様の受け取り方が食い違っていることが多いです。

よくある失敗の場面

たとえば、こんな場面です。これは説明のための例で、特定の案件の話ではありません。

発注側は、仕様書に「一覧画面に検索機能をつける」と書きました。開発側は、キーワードで絞り込める検索を作って納品しました。ところが発注側が思い描いていたのは、日付や担当者でも絞り込める検索でした。

どちらも、仕様書どおりです。だから、あとから話し合っても、どちらが悪いとは言いにくくなります。

なぜ食い違いが起きるのか

仕様書は、書いた人の頭の中にある前提を、すべては運べません。「検索」という一語にも、人によって思い浮かべる機能が違います。

日本の会社の中でも、部署が変われば同じ言葉の意味がずれることがあります。これは国の違いだけの話ではありません。ただ、言語や時差が加わると、食い違いに気づくのが遅くなりやすいと思います。

書面に残すもの

仕様書に加えて、次の3つを書面に残します。

・決めたこと(何を作るか) ・決めていないこと(あえて保留にした点) ・作らないこと(今回の範囲に入れないもの)

とくに、決めていないことと、作らないことは、書かれないまま進みがちです。ここが空白だと、それぞれが自分に都合のよい解釈で埋めてしまいます。

先ほどの例なら、「検索はキーワードのみ。日付や担当者での絞り込みは、今回は作らない」と1行書いておくだけです。それだけで、食い違いは作り始める前に見つかります。

最初の1週間でやること

作り始める前の1週間で、次のことをやっておくと、食い違いを早めに見つけられます。

業務で使う言葉の意味を、1行ずつそろえます。「検索」「ユーザー」「完了」のような、当たり前に見える言葉ほど書き出します。

質問の窓口と、最終的に判断する人を決めます。

小さな画面をひとつ先に作ってもらい、思っていたものとの差を確かめます。

「作らないこと」を書き出して、双方で確認します。

仕様書は大事です。ただ、それだけで全部を伝えるのは難しい、という話です。

開発を頼むか迷っている段階の方は、記事内で紹介しているサービスのページも見てみてください。