業務は整っているか

業務を仕組みにする前に、まず業務そのものを整えます。今のやり方をそのまま仕組みに写すのではなく、必要のない業務はやめ、減らせる手順は減らします。そのうえで、残った業務を、仕組みにできる程度まで明らかにします。

AIはプログラムを書けますが、その業務をどうするかを、自社に代わって決めることはできません。誰が、いつ、何を見て、何をし、何を決めているか。例外をどう扱っているか。今使っているExcelや帳票、手順書をAIに渡せば、読み取れることは多くあります。けれど、なぜその手順があるのか、何を残して何を変えるのか、例外のときにどうするのか、誰が判断するのかまでは、資料だけでは分からないことがあります。そこは、実際にその業務を担っている人が、明らかにする必要があります。受発注や見積もりのように複雑な業務ほど、作る作業のうち、この部分が大きく、重くなります。

この記事は、実務編の2つ目の問いを扱います。作る前に考える4つの問いの、二つ目です。「そもそも自分たちで作るべきか」で選んだ一つの業務を、仕組みにする前に整えるための問いを、順に並べます。要件定義や業務フロー図といった、システム開発の専門的な手法や書き方には立ち入りません。

そもそも、この業務は本当に必要か

最初の問いは、「どう作るか」ではなく「そもそも必要か」です。その業務は、今も本当に必要か。業務は必要でも、その中の手順まで必要か。誰も見なくなった帳票を作り続けているような、惰性で残っている業務や手順は、珍しくありません。仕組みにすると、その業務は形として固定されやすくなります。紙のときは現場の判断で省けた手順も、仕組みの中に必須の手順として入れれば、毎回通る道になります。だから、仕組みにする前に、必要のない業務はやめます。業務そのものは残るとしても、減らせる手順は減らしておきます。

勤怠管理なら、出退勤の記録そのものはやめられません。労働時間の把握や記録は会社に求められていて、法令やガイドライン上の要件があるからです。減らす前に迷えば、社会保険労務士などの専門家に確かめます。けれど、その周りには減らせる手順がついています。タイムカードの数字を紙の日報に写す、紙の日報をExcelに打ち直す、Excelの合計を電卓で検算する。今の手順をそのまま仕組みに写すと、この転記の画面まで作ることになります。この二重三重の転記や確認を先になくせば、作るものそのものが小さくなります。作るものが小さければ、作る量も確かめる量も減り、運用や管理の手間も減ります。直すときの範囲も小さく、不具合が入り込む余地も減ります。

誰が、いつ、何を見て、何をする・決めるか

残った業務を、流れとして言葉にします。基本編の「仕事を分解する」では、仕事をステップに区切り、各ステップを入力・作業・出力に分けました。「何を見て」が入力、「何をする」が作業と出力にあたります。社内システムでは、そこに「誰が」「いつ」を足します。そして、記録する・集計するといった作業と、承認する・対応を決めるといった判断を区別し、判断があるなら「何を決めるか」まではっきりさせます。誰が・いつ・何を見て・何をする・決めるか。仕組みは、この4つが決まっていないと作れません。

誰が	いつ	何を見て	何をする・決める
社員	その日のうちに	自分の出勤・退勤	時刻を記録する
上長	翌営業日まで	部下の記録	抜けや誤りを確かめ、承認する
担当者	締め日の翌日	全員分の記録	集計して、給与計算に渡す
経営者	月に一度	集計の結果	残業の多い人への対応を決める

書けない箇所があれば、そこはまだ言葉になっていない業務です。

例外はどう扱っているか

業務の本体より、例外のほうが仕組みを難しくします。ふだんの流れは誰でも言えますが、例外は担当者の頭の中にだけあることが多いからです。分かっている例外を言葉にしないまま、本番で使う仕組みにはできません。 作ってから見つかる例外は、そのたびに直す手間として、作った後に引き受け続ける負担に加わります。

勤怠管理の例外を挙げてみます。

• 打刻を忘れた。後から本人が申請し、上長が認める
• 直行・直帰で、会社の端末では打刻できない
• 日をまたぐ勤務。退勤が翌日の日付になる
• 半日の休暇や、時間単位の休暇
• 記録が間違っていた。後から直す必要がある

例外を言葉にすると、二つのことが決まります。一つは、その例外を仕組みで受け止めるか、人が処理するか。もう一つは、仕組みができたときに「この例外でも正しく動くか」を確かめる項目です。確かめ方は「直しながら、使い続けられるか」で扱います。

どこまでをこの仕組みが担い、どこからは人がやるか

流れと例外が言葉になったら、仕組みと人の境界を引きます。先ほどの表の「何をする・決める」の列を見ると、時刻の記録や定型的な集計は仕組みに、承認や対応の判断は人に、と分けられます。基本編の「プログラム・AI・人に振り分ける」と同じで、手順の決まった定型の部分を仕組みに任せ、判断と責任を人に残します。

工程	担うのは
出退勤の時刻を記録する	仕組み
打刻忘れの申請を受け付ける	仕組み
申請を認めるかを決める	人（上長）
月の労働時間を集計する	仕組み
集計の結果を確かめる	人（担当者）
給与計算に渡す形で出力する	仕組み

境界を先に引いておくと、AIに頼むときの指示が具体的になります。「勤怠管理を作って」ではなく、「記録と集計と出力をする仕組みを作って。申請を認める判断は人がするので、承認の欄を用意して」と頼めます。

今のやり方の何を変えず、何を変えるか

紙やExcelで回ってきた業務の手順には、業務上の理由があって残っているものと、昔からそうしてきたというだけのものが混ざっています。要らない業務や手順は、最初の「本当に必要か」の問いで減らしました。残った手順について、何を維持し、何を変えるかを、意識して決めます。締め日、承認の順番、集計の単位のように、理由があって残っているものは、仕組みにするからというだけで変えません。仕組みの都合で変えると、現場が混乱します。逆に、業務として変える理由があるなら、この機会に変えて構いません。

勤怠管理なら、締め日と承認の流れは維持します。給与計算の日程や、誰が確かめて責任を持つかと結びついているからです。変えるのは、記録の方法（紙やタイムカードから、仕組みへの直接の入力へ）と、集計の方法（手作業から自動へ）です。維持するものと変えるものが決まっていれば、AIに「締め日と承認の流れは今のままで、記録と集計のやり方を変えたい」と伝えられます。

作らないと決めたものは何か

最後に、作らないものを決めます。作るものの一覧より、作らないものの一覧のほうが、仕組みを小さく保ちます。作り始めると、「ついでにこれも」が必ず出てくるからです。

勤怠管理なら、たとえばこう決めます。給与の計算はしない（給与ソフトに渡すところまで）。シフトの作成はしない。有給休暇の残日数の管理はしない（休暇を取った記録は残すが、残りの日数は数えない）。作らないと決めたものは、後から必要になれば、そのとき別に考えます。

作ると決めたものも、一度に全部を作る必要はありません。必要なものから順に作り、実際に使いながら足していきます。最初から大きく作るほど、使ってみて違ったときに直す範囲も大きくなります。

つまずきやすいところ

• AIに業務を決めさせようとする。 「勤怠管理の仕組みを作って」と頼めば、AIは一般的な勤怠管理を組み立てるか、こちらの事情を尋ね返してきます。どちらにしても、自社の締め日も、承認の順番も、例外も知りません。決めるのは自社で、AIには決めたことを渡します。
• 例外を後回しにする。 普通のケースが動くと完成に見えますが、例外は担当者の頭の中にだけあることが多く、本番でぶつかって初めて見つかります。全部を仕組みに入れる必要はありませんが、分かっている例外は先に言葉にしておきます。
• 整える作業を重く考える。 専門的な手法や、きれいな業務フロー図を作る必要はありません。誰が・いつ・何を見て・何をする・決めるかを、箇条書きや表で書き出すところから始められます。複雑な業務では量が増え、流れを図にしたほうが見やすいこともありますが、やることは変わりません。書き出したものは、そのままAIに渡す材料になります。

まとめ

仕組みにする前に、業務そのものを整えます。必要のない業務はやめ、減らせる手順は減らし、残った業務を「誰が・いつ・何を見て・何をする・決めるか」で言葉にし、例外を書き出し、仕組みと人の境界を引き、維持するものと変えるものを決め、作らないものを決めます。作るものにも順番をつけ、必要なものから小さく作ります。ここまで整理できれば、AIに何を作ってほしいのかも、ずっと具体的に伝えられます。

次は、その業務が扱うデータの話です。同じ情報が複数にあるときどれを正とするか、何を記録するかは「そのデータは何で、どれを正とするか」で扱います。