仕様書がなくても、オフショア開発は頼めます その前に「仕様だけ」を決める期間を

仕様書がない状態でも、オフショア開発の相談はできます。ただ、作り始める前に、仕様だけを決める期間を別に取っておくと、あとの食い違いを減らせます。

仕様書がないまま見積もりを取ると

「仕様書はまだないのですが、見積もりをお願いできますか」。この問い合わせは、実際によくあります。

見積もりは出せます。ただ、その金額は「こういうものだろう」という前提の上に立っています。前提が違っていたとわかるのは、たいてい作り始めてからです。

私たちの経験では、仕様の抜けは最初、抜けに見えません。誰かが「このケースはどうなりますか」と聞くまで、できあがった資料に見えるからです。聞かれなかった部分は、作る側が常識的に見える動きを推測で選びます。だれも警告を出さないので、ずれは静かに積み上がります。

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

・権限が「管理者と一般」の2つとしか書かれていない。実際には経理だけが見られる画面がある ・今あるデータを新しいシステムに移すのに、そのデータの状態が書かれていない。きれいな状態だと仮定して作られる ・エラーのときの画面や、データが1件もないときの表示が決まっていない ・「現行システムと同じ」の一文。双方がそれぞれ別の意味で読んでいる

最後の一文は、とくに見つけにくいものです。書いた方にとっては説明の省略で、読んだ方にとっては指示に見えます。

仕様だけを先に決める期間を、別枠で取る

そこで私たちは、開発の見積もりを出す前に、仕様だけを決める期間を別に取る進め方をしています。「仕様確定フェーズ」と呼んでいますが、やることは名前ほど難しくありません。

期間は1〜2週間、大きな案件では2〜4週間です。この期間の費用は固定で、始める前にお伝えします。終わったときに、次の5つをお渡しします。

1. 要件をまとめた文書

2. すべての画面の簡単な設計図（ワイヤーフレーム）

3. データの設計

4. システム全体の構成

5. 開発の段階の固定見積もり

大事なのは、ここで止めてもよいことです。5つの資料を受け取って、別の会社に開発を頼むという選び方もできます。止める自由があるから、このフェーズの結果を、発注する側が落ち着いて判断できます。

何もないとき、すでにあるとき

状況は2つに分かれます。

何もない場合は、業務の流れを伺いながら、画面を一緒に描いていきます。足りない決定は、画面を描く段階で表に出ることが多いです。ボタンが何をするのか決まっていなければ、ボタンは描けないからです。

すでにシステムがある場合は、動いているものをこちらで調べます。古い資料に書かれていることではなく、実際に何をしているかを、コードの読み取りと運用の方への聞き取りで把握します。

どちらの場合も、事前の資料は要りません。実際の業務の流れをわかっている方が、打ち合わせに加わってくだされば進められます。

この進め方が向かない場合

小さな案件には、このフェーズは要りません。画面を1つ直す、帳票を1つ足すといった作業なら、短い打ち合わせと見積もりで足ります。

数日のうちに大人数で開発を始めたい場合も、向きません。フェーズの分だけ開始が遅れます。業務の流れをわかっている方が社内にまだいない場合は、その方を見つけるところが先です。

仕様を確定しても、要件は後から変わります。変わること自体は普通のことです。変更が出たときに、書面の手順を通すようにしておく、という話はまた別の機会に書きます。

次に誰かに頼むとき

相手がどこの国の、どの会社でも使える質問を3つ書いておきます。

・見積もりの前に、どんな文書を作ってもらえますか。そこで止めた場合、その文書は手元に残りますか ・この見積もりは、どの文書にもとづいていますか ・業務の例外は、どなたが、どんな方法で確かめますか

答えが曖昧な部分に、あとで揉めるもとがあります。

このブログでは、オフショア開発とベトナムのことを続けて書いています。続きを読みたい方は、フォローしていただけるとうれしいです。