社長と現場でほしいシステムが違うとき｜通常と例外の2件で仕様の抜けを探す

「会社の数字をまとめて見たい」。社長がそう考えてシステムの相談を始めても、毎日入力する人の困りごとは「作業途中で担当が交代したとき、どこまで済んだか分からない」かもしれません。どちらかが間違っているわけではありません。社長は仕事全体の判断に使う情報を見て、現場は一件を終わらせる手順と例外を見ています。

ここを確かめずに画面を決めると、集計はできても入力が二度手間になったり、入力しやすくなっても社長が知りたい数字を取り出せなかったりします。必要なのは会議の回数を増やすことではなく、同じ仕事の「普通に終わった一件」と「途中で判断が要った一件」を一緒に追うことです。

社長の希望と、現場の手順は違う種類の情報

社長には、何を改善したいのかを聞きます。例えば当日の出荷件数を見たいのか、翌朝に残る作業を知りたいのか。同じ「倉庫の仕事を見えるようにする」でも、目的によって必要な記録と画面は変わります。投資の優先順位や、最終的に誰が判断するかも経営側の仕事です。

一方で、現場の担当者には、今ある帳票がどの順番で動くかを聞きます。作業を始める人は何を最初に記録するか。途中で止めた仕事をどこへ残すか。交代した人は何を見て続きを始めるか。担当者は一日の中で「通常の一件」だけを扱っているわけではありません。

確認する相手を社長か現場かの二択にしないことも大切です。金額や納期を承認する人、帳票を確定する人、次の工程でその数字を使う人が別なら、その人たちの判断も要ります。作業を知っている人に会社としての決裁まで背負わせず、社長の希望だけで現場の手順を決めない。その境目を見えるようにします。

普通の一件だけでは、画面の足りないところが見えない

以下は説明のための仮定例です。Ｂ．Ｉ．Ｙの顧客で起きた出来事ではありません。

倉庫の会社で、紙の出荷指示を見ながら荷物をそろえ、途中で担当者が交代するとします。通常の一件なら、指示を受けた人が品物をそろえ、確認を終えて出荷へ渡すまでを追えます。社長はその日の完了件数を知りたいかもしれません。ここだけを見ると、作業済みの印を画面に付ければ足りそうです。

次に、途中で作業が止まり、次の担当者へ渡した一件を選びます。止めた理由は出荷指示に残ったか、それとも口頭だけだったか。次の担当者は、その一件を「未着手」と「作業中」のどちらとして受け取ったか。出荷してよいと判断した人は誰か。社長、最初の担当者、引き継いだ担当者に、同じ一件を別々の立場から確かめます。

経営側には、何をどの時点で「今日の完了」に数えたいかを聞きます。現場には、止まった仕事をどこに置き、どんな情報があれば安全に再開できるかを聞きます。出荷の確認者には、何を見て確定するかを聞きます。その答えによって、作業中・確認待ち・完了を分けるだけで足りるのか、引き継ぎの理由や確認履歴も必要かが変わります。現場の工夫を単なる入力ミスとして扱わず、その順番になった理由を聞くことが重要です。

二つ目の例では「次に使う人」まで聞く

建築業で、現場の写真を事務所へ送り、報告用の資料にまとめる仕事を仮に考えます。社長は現場ごとの進み具合を知りたい。現場担当者は作業の合間に写真を撮って送る。事務担当者は、どの写真がどの工事のどの工程か分からないと、報告書をまとめられません。

通常の一件なら、工事名と撮影日を付けて送れば済むかもしれません。例外として、同じ日に複数の作業があり、写真だけでは場所が分からない一件を見ます。そのとき誰に確認を戻すか、報告書に載せる写真を誰が確定するか。事務所が勝手に推測して分類する仕組みにはできません。現場で入力する項目を増やしすぎれば、今度は提出が負担になります。社長が見たい一覧、現場が無理なく残せる情報、事務所が確認できる根拠の三つを照らし合わせます。

この例で必要なのは、すべての写真を高度に自動判定することとは限りません。工事名を選ぶ欄、未確認の写真を戻す経路、報告書に使う前の確認者だけで足りるかもしれません。逆に、複数の帳票へ毎回同じ情報を書いているなら、連携を考える余地があります。欲しい機能を先に並べるより、次に使う人がどこで止まるかを見た方が、作る範囲を絞れます。

聞く時期を三つに分けると、話が大きくなりすぎない

最初の相談時には、社長が目的と優先順位を伝え、担当者が普段使う帳票を見せます。担当者全員を最初から集める必要はありません。一つの仕事を実際に始める人、最後に確認する人、例外を判断する人が分かれば、まず必要な相手を選べます。個人名や取引先情報を隠した見本でも、項目と流れは確認できます。二件は仕様を確定する材料ではなく、聞くべき論点を見つける入口です。他にも頻繁に起きる例外や、影響が大きい例外がないかを責任者に確かめてから範囲を決めます。

次は、画面案や試作品が見えたときです。説明を聞くだけで「使えそう」と決めず、先ほどの普通の一件と例外の一件をその画面で再現します。どこに中断や確認待ちの理由を残すか、次の担当者に見えるか、最後の帳票まで情報が渡るか。ここで分かった不足は、必要な機能なのか、運用のルールで足りるのかを分けて考えます。追加する機能は範囲と費用も確かめます。

使い始める前には、操作を教わる人と、困ったときの確認先を決めます。現場で見つかった使いにくさをどう集め、どの範囲をいつ直すかも、開発側と確認します。「育てる」開発でも、改修を無制限に含めるという意味ではありません。業務上の優先順位と契約の範囲を見ながら、必要な改善を相談することになります。

今日できるのは、記録を二件だけ選ぶこと

最近終わった同じ仕事から、普通に完了した一件と、途中で変更や確認が入った一件を選んでみてください。紙、Excel、電話メモや写真を並べ、「最初に記録した人」「途中で引き継いだ人」「最終的に確定した人」「次にその情報を使った人」を書き出します。顧客名や金額を外した写しで構いません。

その二件に沿って社長と担当者に聞けば、「進み具合を見えるようにしたい」「提出を楽にしたい」という抽象的な希望が、どの記録と判断をつなぐべきかという話に変わります。既存のExcelや市販ソフトで足りる部分と、会社の仕事に合わせて作る部分を分ける材料にもなります。

Ｂ．Ｉ．Ｙは埼玉県川口市を拠点に、帳票と仕事の流れを確かめ、必要な部分を作って導入時の説明や運用中の改善まで相談できる育てるシステム開発を行っています。開発の相談に顧問契約は必要ありません。社長と現場で見えている困りごとが違うなら、公式LINEへ「社長と現場で、困っている作業が違う」と一言送ってください。二件の記録を手がかりに、どこから確認するか考えられます。