仕様書どおりに作ったのに、うまくいかないことがある

仕様書どおりに納品され、検収も通ったのに、現場で使われないままになる案件は、珍しくありません。開発側に落ち度があったわけでもなく、発注側が手を抜いたわけでもない。それでも起きます。

仕様どおりなのに失敗する場面

いちばんよく見るのは、現場担当者向けの入力画面です。要件定義書に書かれたとおりに作られ、テストも通り、公開されます。半年後にログを見ると、月に数回しか開かれていない。担当者は、結局これまでのExcelを使い続けていました。

管理者向けのレポート機能も似た経過をたどります。画面は完成していて、数字も正しく出ます。ただ、実際に見られているのはCSVの書き出しボタンだけで、グラフも一覧も誰も開いていない、ということがあります。

どちらも、不具合が原因ではありません。仕様を満たしているかどうかという基準で見れば、問題なしと判定される状態です。

何が抜けていたのか

仕様書は「何を作るか」は細かく書きますが、「何が良くなれば成功なのか」は書かないことが多いと感じています。

そうなると、検収の基準は「書かれた機能が存在するか」になります。開発側は機能をそろえれば責任を果たしたことになり、発注側も受け取ってしまえば一区切りです。検収が通った時点で、双方の関心は次の案件に移ります。

半年後に使われていないと分かっても、契約上は誰の落ち度でもありません。仕様どおりに作られているからです。私たちが厄介だと感じているのは、この「誰の責任にもならない失敗」が、次の発注でもそのまま繰り返されやすいことです。原因が特定されないまま終わるので、学習が残りません。

さきほどの入力画面の例でいえば、要件定義の段階で「この画面で、今の作業の何が変わってほしいのか」を誰も聞いていなかった、というだけのことが多いです。

作る前に確認したい問い

発注前の打ち合わせで、次の4つを口頭で確認しておくと、後の食い違いがかなり減ります。契約書の書き方を変える必要はありません。

・第一に、この機能を実際に使うのは誰か。役職ではなく、その作業を毎日している人の顔が浮かぶかどうかです。

・第二に、その人は今その作業を何分でやっているか。正確な計測でなくても、体感で構いません。比較する相手がないまま作ると、良くなったかどうかを判断できなくなります。

・第三に、公開後にどの数字を見れば効果が分かるか。入力にかかる時間、差し戻しの件数、問い合わせの数など、すでに社内で見ている数字のほうが扱いやすいです。

・第四に、その数字は誰が測れる立場にいるか。開発側からは見えない数字を基準に置いてしまうと、確認そのものができません。

正直に申し添えますと、すべての案件でこの問いに答えが出るわけではありません。法令対応や社内規程の都合で「作ること自体が目的」という案件もあります。その場合は無理に数字を置かず、少なくとも「使う人が決まっているか」だけでも確認しておくことをおすすめします。使う人が未定のまま進む案件は、経験上かなりの確率で放置されます。

「完成」の決め方

検収の条件に、機能の有無だけでなく、公開したあとの実測をひとつ足しておく方法があります。たとえば「入力にかかる時間を、公開から30日後に実際に測って確認する」といった一文です。

ここで気をつけたい点があります。売上やコンバージョン率のように、開発以外の要因が大きく絡む数字を請負側の達成条件にすると、双方にとって扱いにくくなります。事業側の判断で状況が変われば数字も動くためです。最初は、開発側が制御できる範囲の数字から始めるほうが現実的だと考えています。入力にかかる時間、エラーの発生率、画面の応答速度あたりです。

そして、測ったうえで数字が動かなかったときにどうするかも、先に話しておくほうがよいと思います。追加で直すのか、そのまま運用して様子を見るのか。ここを決めずに測ると、結果が出たときに気まずくなるだけで終わります。

「機能がそろっているか」から「使われているか」へ。判断の基準をひとつ足すだけで、納品後の景色は変わります。

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