業務システムを作る前に、動くデモで要件を確かめる

業務システムを作るとき、要件は文書や打ち合わせで決めることが多いでしょう。ところが、完成した画面を触ってから「思っていたのと違う」と気づくことがあります。作った後の手直しは、時間も費用もかかります。

結論から言うと、本格的に作る前に、動くデモを触って要件を確かめることが有効です。文書では分からなかった食い違いに、早い段階で気づけます。

この記事では、デモで要件を確かめる進め方と、デモで分かること、分からないことを解説します。例は、このサイトで公開している業務のデモを作りながら、自分で触って気づいた点です。

文書だけでは気づきにくいこと

文書の要件は、機能の有無は確かめられますが、使ったときの感覚までは分かりません。次のような点は、画面を触って初めて気づくことが多くあります。

会議室の割り当てのデモでも、作りながら自分で触って気づいた点がいくつもありました。重みの入力欄は、実際に作ってから3つの案を比べる形に変えました。

気づいたこと	直した内容
会議の一覧が長く、下の図まで遠い	一覧を5件分の高さにして、中でスクロールできるようにした
使えない部屋の評価が、使える部屋より良く見えた	使えない部屋は評価を出さず、後ろに並べた
重みの数値を入力させても、どの値が良いか分からない	入力欄をやめ、方針の違う3つの案を並べて比べる形にした
案を切り替えると、表の幅が変わって見づらい	ボタンの幅をそろえ、表が動かないようにした

どれも、機能の一覧には現れない点です。文書で要件を決めて作り切っていたら、完成の後に手直しが必要になっていたかもしれません。

これらは作り手が触って気づいた点です。実際に業務をしている人が触れば、また別の点に気づくことがあります。

業務の流れを決め、架空のデータで小さく作り、関係者に触ってもらい、直して、本格的な開発に進む流れの図

最初から全部の機能を作らず、一番大事な業務の流れを1つ選びます。例えば請求なら、売上の取り込みから請求書の作成までです。

本物のデータを使うと、個人情報や取引先の情報の扱いに気を使います。業務の特徴を残した架空のデータで作れば、関係者に気軽に触ってもらえます。

入力ミスや例外も、わざとデータに入れておきます。例外の扱いは、文書では見落としやすい要件です。

デモは、作った人ではなく、実際に業務をしている人に触ってもらいます。説明しながら操作してもらうのではなく、まず自由に触ってもらうと、迷う場所が分かります。

触って分かったことは、デモを直すだけでなく、要件の文書にも書き戻します。本格的な開発では、その文書が基準になるからです。

デモは、使い勝手や業務の流れを確かめるのに向いていますが、次のことは確かめられません。

これらは、本格的な開発の設計で別に確かめます。デモがうまく動いたからといって、そのまま本番に使えるわけではない点に注意しましょう。

デモを作る仕組みがなくても、紙やスライドに画面の下書きを描くだけで、気づけることがあります。

説明に詰まったところが、要件があいまいなところです。

業務システムを作る前に、動くデモを触って要件を確かめると、文書では気づきにくい食い違いを早く見つけられます。流れを1つに絞り、架空のデータで小さく作り、実際に使う人に触ってもらいましょう。速さやセキュリティなど、デモで分からないことは別に確かめます。

このサイトの業務のデモは、ポートフォリオから試せます。題材は架空のサンプルで、ログイン不要です。要件を決める前の業務の整理は、業務改善はツール選びから始めないも参考にしてください。