1000万円級の開発で決めた「やらないことリスト」

重要ポイント

• 案件: オンライン英会話サイト／トレード分析サイトなど
• 規模: 1000万円級
• 良かった工夫: 「やらないことリスト」を発注側・開発側で先に合意
• 失敗から得た教訓: 性能・障害対応の条件を数値で文書化する

Q. 「やらないことリスト」とは何ですか？

A. 要件定義書とは別に、「今回のスコープにはこれは含めない」と最初に文書にして、発注側と開発側で合意しておくものです。開発の途中で出てくる「ついでにこれも」という追加要望によって範囲がなし崩しに膨らむのを防げました。追加要望自体は悪いことではなく、それを別契約とするか今回の範囲に含めるかを、その都度きちんと判断できる状態を作ることが目的です。

Q. なぜ、このリストが有効だったのですか？

A. 発注側は、契約時には気づかなかった要望をあとから思いつくものです。それ自体は自然なことですが、境界線がないと「言えばやってもらえる」という空気になり、スケジュールと予算がなし崩しに膨らみます。あらかじめ境界を明文化しておくことで、追加要望は「追加の相談」として扱えるようになり、双方が納得しやすくなります。

Q. 逆に、うまくいかなかった経験はありますか？

A. 初期の案件で、想定アクセス数や障害が起きたときにどこまで対応するか(いわゆるSLA)を曖昧にしたまま契約してしまったことがあります。システムが稼働してから、「そんな話は聞いていなかった」という食い違いが表面化しました。口頭でのやり取りに頼っていたのが原因でした。

Q. その経験から、今はどう変えていますか？

A. 要件定義の段階で「やること」だけでなく「やらないこと」を明文化すること、そして性能や障害対応の条件は必ず数値で契約書・仕様書に落とし込むことを徹底しています。「だいたい早く動く」「なるべく早く直す」のような曖昧な言葉は、契約書には残さないようにしています。

Q. 技術が分からない発注側にとって、これはどんな意味がありますか？

A. 技術の知識がなくても、数字であれば確認できます。「同時アクセス何人まで想定するか」「障害発生から復旧まで何時間を目標にするか」を数字で書いてもらうだけで、あとからのトラブルをかなり防げます。

Q. 「やらないことリスト」は、どんな案件にも使える考え方ですか？

A. 使えると思います。規模の大小にかかわらず、発注側と開発側の期待値がずれる原因の多くは、範囲の曖昧さにあります。小規模な案件であっても、最初に数行でよいので「やらないこと」を書き出しておくだけで、認識のずれをかなり防げます。