リード
AIや業務システムを導入するとき、最初につまずく原因は、必ずしもツールの性能不足ではありません。「案件とは何か」「完了とはどの状態か」「誰が判断するのか」——同じ会社の中でも、仕事の意味は人や部署によって少しずつ違っています。Neural Design Lab(NDL)代表の藏重彰三さんは、その違いをツール導入の前にほどく取り組みを「前捌き」と呼んでいます。この記事では、藏重さんから寄せていただいた文章とNDLの公開ページをもとに、「前捌き × AI・DX」という考え方を紹介します。
本文
人は暗黙に読み替えられる。でも仕組みはそのズレを引き継ぐ。
藏重さんは、AIやシステムの導入で最初に起きる問題として、仕事の意味のズレを挙げています。
同じ会社の中でも、「案件とは何を指すのか」「完了とはどの状態なのか」「誰が判断するのか」「例外が起きたらどうするのか」といった仕事の意味が、人や部署によって少しずつ違っていることがあります。
普段は、人がその違いを読み替えたり、声を掛け合ったりすることで仕事が回っています。しかし、その曖昧さを整理しないままAIやシステムに渡すと、判断のばらつきや例外処理まで仕組みに持ち込むことになります。
そこで、AIやDXの前に行うのが「前捌き」です。NDLのブログでは、前捌きを「システムやツールを導入する前に、業務の構造を整理・可視化し、言葉の意味、判断、例外、残すべき現場知をほどくこと」と一文で定義しています。
前捌きでは、いきなり業務を作り替えない
前捌きでまず整理するのは、次のようなことです。
- 今どのように仕事が回っているか
- どこに人の判断が入っているか
- 例外はどこで発生するか
- 人によって意味が違う言葉はないか
- 今のやり方の中に、残すべき知恵は何か
藏重さんが重視しているのは、現場のやり方を否定しないこと。長年使われてきたExcelや帳票、口頭での確認、担当者ごとの工夫には、その会社なりの理由があります。まずはその理由を読み解き、意味を揃える。そのうえで「ここは人が判断する」「ここはAIに任せられる」「ここはシステムで共有する」と役割を分けていきます。
NDLのブログでは、前捌きは「要件定義」や「ヒアリング」とは違う、「もっと泥臭い話」だと説明されています。現場に入り、誰が何を、どんな順番で、どんな判断をしながらやっているかを自分の目で確認し、「この業務、なぜ今この順番になっているのか」を読むことです。
All in Oneの前に、意味をひとつにする
最近は、見積・原価管理・案件管理・請求・顧客管理などを一つにまとめたサービスも増えています。便利な仕組みですが、複数の業務を一つにつなぐからこそ、それぞれの業務で使っている言葉や判断基準が揃っていることが重要になります。
たとえば「案件」「材料」「原価」「追加」「完了」という言葉が、営業・現場・事務で違う意味を持っていたら、システムに集約した瞬間にズレが表面化します。
前捌きは、AIやDXを入れるための準備というより、人と仕組みが同じ意味で仕事を扱える状態をつくることだと考えています。
「現場を読み解く役割」と「実装する役割」を分ける
AIやシステムを作る人が、その会社の業務を一からすべて読み解くのは大きな負担です。一方、現場側も、自分たちの仕事をそのまま要件として説明できるとは限りません。
藏重さんが示すのは、現場を読み解く役割と技術として実装する役割を分ける方法です。前捌きで業務の流れ・判断基準・例外・言葉の意味を整理し、その整理された状態を、AI開発、SaaS、RPA、業務システムなどにつなぐ。こうすると技術側は実装に集中しやすくなり、現場側も無理にシステムの言葉へ合わせる必要が減ります。
NDLの前捌きページ(The Maesabaki)は、まさにこの「つなぎ目」で困っている側に向けて書かれています。挙げられているのは、たとえばこんな状況です。
- 商談では好感触だったのに、要件整理で止まる
- 顧客ごとの例外が増え、見積が出せない
- 営業が聞いた内容と、開発が必要な情報が違う
- PoCまでは進むが、本番運用へ移れない
- 顧客の現場説明に、PMとエンジニアの時間が溶ける
ページでは「顧客側の混乱を、御社の実装コストにしません」として、顧客の業務を棚卸しし、例外・判断・役割・データを整理して、提案・設計・実装できる状態まで整えると説明されています。前捌きが整うと、営業が技術提案に集中できる、PMが顧客整理だけで消耗しない、エンジニアが曖昧な要望に振り回されない、見積精度が上がる、導入後の手戻りが減る、定着しない案件を減らせる——という変化が挙げられています。
現場の一例:ツールではなく、構造に問題があった
NDLのブログには、前捌きの考え方が表れた現場エピソードも紹介されています。ある大手企業のBPO案件で、特殊機材の手配業務を担うチームにミスが頻発し、VBAやRPAが次々と投入されていた現場です。インスペクターとして入った藏重さんの結論は、「ツールそのものに大きな問題はない。問題はツールの使い方と、それ以前の業務構造にある」というものでした。その後、メール連絡の削減と基幹システム改修へと舵が切られたと書かれています。
ブログはこう締めくくられています。
AIやRPAを壊れた構造の上に載せると、壊れた構造を高速化するだけです。
目指すのは「導入」ではなく「回ること」
AIやDXは、導入した時点ではまだ途中です。実際の仕事の中で使われ、困ったときに戻れる場所があり、現場の人が無理なく続けられて、初めて意味があります。だから前捌きでは、何を入れるかより、入れたあとに誰がどう使うかを先に考えます。
現場の知恵は残す。混乱だけをほどく。その状態をつくってから、必要な技術につなぐ。これが、Neural Design Labで行っている「前捌き」です。
Tesujiでの読み方:前捌きは「星と星のあいだ」に置く一手
Tesujiでは、人・AI・サービスを星として、その組み合わせを手筋として読んでいます。AI開発、SaaS、RPA、業務システムといった星は、それぞれ単体でも強力です。けれど、導入する現場の言葉や判断基準が揃っていなければ、どの星を持ってきても線はうまくつながりません。
藏重さんの前捌きは、そうした実装の星と、導入先の現場とのあいだに置く一手です。
- 前捌き × AI開発:判断・例外・言葉の意味を整理してから、AIに任せる範囲を決める
- 前捌き × SaaS/All in One型サービス:営業・現場・事務で言葉の意味を揃えてから集約する
- 前捌き × RPA・業務システム:ツールより先に業務の構造を切り、正しい場所に使う
AI・DX導入を進める企業や、それを支援する開発会社・SaaS事業者にとって、藏重さんは「次の一手」を一緒に考えられる星のひとつです。NDLでは初回60分の壁打ちを受け付けています。詳細は公式サイトをご確認ください。
NexAとNDLのご縁
NexAは、自社の営業ツール「BidDrive」の開発・情報収集の過程で、Web上からNDLを発見しました。そこから情報交換が始まり、今回、Tesujiでご紹介させていただくことになりました。
関連リンク
- Neural Design Lab:https://neuraldesignlab.jp
- 前捌き(The Maesabaki):https://neuraldesignlab.jp/maesabaki
- NDLブログ「地方DXで失敗する9割の共通点。『前捌き』という業務構造の切り方。」:https://neuraldesignlab.jp/blog/maesabaki-definition/
関連ノード:藏重彰三 / Neural Design Lab / 前捌き → AI開発・SaaS・RPA・業務システム
Tesuji