デモでは軽いのに、締め日に遅い｜業務システムの動きを確かめる条件

入力した日報を一覧に出す。得意先から電話が来たら、注文を検索する。月末には一か月分を集計する。作りたい画面が動くと、仕事が楽になるイメージはつかみやすくなります。

ただ、数件の見本を一人で操作できたことと、日々の仕事がたまった状態で使えることは、別に確かめたい点です。最初は軽かった画面でも、記録が増えたり、同じ時間に利用する人が重なったりしたとき、待ち方が変わるかもしれません。

どの会社も大規模な試験が必要、という話ではありません。開発を頼むときに「速くしてください」で終えず、自社の仕事に照らして、何件を、何人で、どの操作まで確かめるかを決める。そのための考え方を整理します。

画面の見た目と、仕事を続けられる動きを分けて見る

デモで確認することには、入力項目が合っているか、必要な帳票を出せるか、担当者が操作を理解できるか、などがあります。この段階では、少ない見本で一件の流れを追う方が、間違いを見つけやすい場合もあります。

一方、本番に近い件数や使い方での確認は、それとは役割が違います。過去の記録も含めて検索したときに、結果が出るまで仕事を待てるか。夕方に入力が集中したとき、保存後の状態を担当者が確かめられるか。動く機能がそろったあとに、普段の量でも使い続けられるかを見ます。

社長は導入日や費用を先に押さえたい。現場は、電話を受けながら画面を待つ時間や、作業の最後に入力が重なる事情を知っています。どちらかの確認が甘いというより、見ている場面が違うんです。現場で混み合う時間を一つ持ち寄ると、打ち合わせが具体的になります。

速さは画面の作りだけで決まりません。端末や通信、同時に行う処理など、条件を分けて確認する必要があります。一度遅かっただけで原因を決めつけず、「誰が、どの端末で、何をしたときか」を残します。

注文十件の見本で、数年分の検索まで分かったことにしない

ここからの二つの例は、確認方法を説明するための仮定です。Ｂ．Ｉ．Ｙの顧客に起きた出来事や、実際のシステムの性能を紹介するものではありません。件数も説明用で、どこまで使えるかを示す保証ではありません。

例えば卸業の会社が、注文を検索して納品書を出す仕組みを検討しているとします。十件の見本なら、担当者が得意先を選び、対象の注文を見つける手順を確かめられます。ただ、その十件で、三年分の二万件を探す使い方まで確認できたとは言えません。

まず、今ある注文がどれくらいあり、一か月に何件増えるかを確かめます。そのうえで、普段は当月分を探すのか、返品の確認で前年の注文を開くこともあるのかを分けます。件数をただ増やすだけでなく、よく使う得意先に注文が偏る、商品名が似ている、といったデータの特徴も伝えます。

件数の数え方にも注意します。画面に二十行だけ出ていても、その裏で過去の全件を調べる作りなら、見えている行数だけでは条件を説明できません。また、一件の日報に写真が何枚もある仕事なら、記録の件数だけでなく、画像の枚数や大きさも相談材料です。「注文が二万件」「一覧には二十件」「一件に添付がある」を分けて伝えます。

確認するのは、一覧が開くところだけではありません。電話中に得意先を探し、注文を一件開き、納品書を出すところまでを一つの流れにします。検索が早くても、次の詳細画面や帳票作成で長く止まるなら、担当者の仕事はそこで待つことになるからです。

過去の注文を毎回すべて表示する必要がなければ、最初は未処理分を出し、必要に応じて期間を広げる方法も考えられます。ただし、見えなくなった注文を「消えた」と思わせない説明が要ります。件数を減らして速く見せるために、必要な記録へたどり着けなくしては、本末転倒です。

締め日の一斉操作は、普段の一人操作と分けて確かめる

別の仮定例です。建築業の会社で、現場からの日報入力と、事務所での月次集計を同じシステムで扱うとします。日中に一人が日報を登録する場面と、夕方に複数の現場が入力し、事務所も集計を始める場面では、使い方が異なります。

利用者が十二人だから、常に十二人が同時に操作する、と考える必要はありません。普段は三人ほどでも、締め日の何時に入力や集計が重なるか。社員数の合計より、同時に何をする可能性があるかを確認します。

例えば、入力する人が保存し、事務所が当月分をまとめて出力する場面を、開発側と確かめる候補にします。そのとき保存した日報が一覧に反映されるか、集計はどの時点の記録を対象にするか、処理の途中で結果をもう一度取りに行けるかも整理します。待ち時間だけを縮めて、数字が確かめられなくなってはいけません。

集計がすぐ終わらない場合、開始したことと、完了したことを区別して知らせる方法もあります。担当者がその間に別の仕事をできるなら、待ち続ける画面から離れられる方が運用に合うかもしれません。ただし、完了をどこで知るか、失敗したら誰が確認するかまで含めて検討します。

こうした確認は、実運用中の環境に無断で大量の処理をかける話ではありません。使う環境や試す量、他の仕事への影響を開発側と決め、顧客名などを含まない見本を使えるかも相談します。

すべてを一秒で、より「この仕事はどこまで待てるか」

電話中に必要な注文を探す操作と、翌朝までに使う月次資料の作成では、待ち時間の意味が違います。前者は相手を待たせ、後者は実行後に別の作業へ移れるかもしれません。全画面に同じ速さを求めるより、止まると困る仕事から優先します。

「速い」という言葉だけでは、発注側と開発側で受け取り方がずれます。どの操作を始めてから、何が表示されるまでを見るか。どれくらいの件数と同時利用を想定するか。その条件で、仕事として待てる時間を一緒に決めます。何秒ならどの業種でも正解、という共通の数字は置きません。

確認は一回の結果だけで終えず、条件をそろえて何度か試します。最初に開くときだけ遅いのか、特定の得意先や古い期間で起きるのか、締め日の操作が重なったときか。結果と条件を並べることで、追加の調査をどこに向けるか考えられます。

表示が出始めた時点と、仕事に使える結果がそろった時点も区別します。例えば集計の枠だけすぐ見えても、数字や帳票をまだ取り出せないなら、作業は終わっていません。試す人が違っても同じところを見られるように、「注文の詳細を開けるまで」「集計を確認して出力できるまで」と終点を言葉にします。

改善には、画面の出し方を変える、集計の実行時間を分ける、処理の組み立てや利用環境を見直すなど、複数の方法があります。どれが合うかは調査が必要です。機器を買えば必ず直る、作り直せば必ず速くなる、と先に決めないことが大切です。

予算を配分するときは、頻度と、止まった先の影響を並べます。一日に何度も使う検索、月に一度でも出荷や請求を止める処理は優先する候補です。反対に、時間を決めて実行し、ほかの仕事を続けられる作業なら、表示方法や運用を変える方が合う場合もあります。速さへの希望を全部一度に積まず、困る場面から確認する順番を決めます。

既製サービスを選ぶ場合も、自社の件数や利用人数で試せる範囲、契約上の上限、困ったときの相談先を確認できます。個別開発なら、確認する条件と結果の扱いを発注内容に残します。想定を超えるデータ増加や新しい処理が必要になった場合の見直しは、範囲と費用を別途相談するものとして整理します。

今日できるのは、待たされる仕事を一つ選ぶこと

いま使っているExcelやソフトで、止まると困る操作を一つ選んでください。操作の名前、扱う件数、利用が重なる時間、そのあと誰が何に使うかを短くメモします。「月末に重い」より、「夕方に各現場の日報が入り、事務所で当月分を出すときに待つ」の方が、確かめる場面が伝わります。

まだ新しい仕組みがないなら、今月の件数と、残しておきたい過去の期間だけでも構いません。社長が全操作の時間を測る必要はありません。日々入力する人と、結果を使う人から一つずつ場面を集め、開発側へ渡す出発点にします。

Ｂ．Ｉ．Ｙの育てるシステム開発では、紙やExcelで回している仕事を整理し、必要な部分を作り、導入時の説明や運用中の相談まで支援範囲を確認して進めます。動きの確認や運用後の改善をどこまで行うかも、案件ごとに合意します。開発から直接相談でき、顧問契約を先に結ぶ必要はありません。

埼玉県川口市の株式会社Ｂ．Ｉ．Ｙへは、公式LINEで「月末の集計で待つ時間が長い。今の件数で使える仕組みを相談したい」と一言送ってください。待っている画面の名前と、記録のおおよその量が分かれば、相談の手がかりになります。