採番という名の秩序、あるいは組織の記憶について
深夜のオフィスで、私はまた同じ問いに突き当たっていた。
「DXって、結局なんなんだろう」
コーヒーカップの底に溶け残った砂糖を眺めながら、私は考える。デジタルトランスフォーメーション。変革。革新。言葉だけが宙を舞い、現場では今日もExcelが粛々と更新されている。
DXの文脈で語られる「課題」の多くは、実は課題の皮を被った症状だ。本当の病巣はもっと深いところにある。そしてその病巣を探り当てることなしに、どんな高価なシステムを導入しても、組織は変わらない。私はそれを、ある「採番」の話から学んだ。
システムは「使わせる」ものではなく、「使わざるを得なくする」もの
よくある失敗がある。
新しいシステムを導入したとき、管理職が社員にこう告げる。「これからはこのシステムを使うように」と。そして半年後、システムのログを見ると閑古鳥が鳴いている。みんなExcelに戻っている。「定着しない」と嘆く声が聞こえてくる。
だが待ってほしい。そもそも「使うように」という言葉の時点で、もう負けているのだ。
仕組みづくりとは、ユーザーにシステムの利用を強要することではない。システムを利用しないと、業務が回らなくすることだ。
たとえば見積書。見積番号を、システムを経由しないと採番できないようにする。紙に手書きで「見積No.」と書こうとした瞬間、それは番号のない見積書になる。顧客に出せない。承認が通らない。川下の管理部門が受け付けない。そういう構造を作って初めて、システムは組織に根付く。
これは強制ではない。設計だ。水は低いところへ流れる。人も、楽な方へ、自然な方へ流れる。その流れを、システムへと向けてやる。それがDXにおける本質的な仕組みづくりではないかと、私は思っている。
採番ルールという名の、組織の歴史書
さて、「採番」という話を掘り下げよう。
案件管理における管理番号には、脈々と続く採番ルールがある。これを軽く見てはいけない。管理番号は、川下での管理に必須の情報だ。受注管理、会計、アフターサービス、クレーム対応──すべての業務が、この番号を「共通言語」として動いている。
そしてその採番ルールたるや、実に複雑怪奇だ。
金額によって頭文字が変わる。数百万円未満ならば「S」、一千万円以上ならば「L」、億単位ならば「E」──といった具合に、受注規模でプレフィックスが分岐する。さらに会計年度を先頭に付けるのだが、これがまた曲者で、暦の4月始まりとは限らない。ある企業では3月決算だが、システム上の切り替えは2月末日の業務終了後。この微妙なタイミングのズレを、採番ロジックは正確に知っていなければならない。さらに部署によっても頭文字が異なる。東日本営業部は「E」、西日本営業部は「W」、海外営業部は「G」（グローバルの頭文字）──。
この複雑な体系は、一見すると「レガシーの悪弊」に見えるかもしれない。だが違う。これは組織が長年をかけて積み上げた知恵の結晶だ。どの案件がどの規模で、どの年度に、どの部署で生まれたのか。管理番号の文字列を一目見るだけで、ベテランの担当者はその案件の素性を読み取れる。それはある意味で、組織の記憶そのものだ。
DXの波に乗って「新システムに移行します、管理番号も新方式にします」などと言おうものなら、現場は凍りつく。川下のすべての部門が、新旧二つの体系を並走させなければならなくなるからだ。
だからこそ、過去の案件管理台帳も取り込んで、業務の連続性を担保することが重要になる。システムの移行は、データの移行でもある。過去の何千件、何万件という案件記録が、きちんと新システムに引き継がれて初めて、組織は安心してシステムを信頼できるようになる。
dbSheetが解くもの
こうした複雑な採番ロジックを、どう実装するか。
「IT部門に依頼する」という選択肢は、今の時代ますます非現実的になっている。どこの企業もIT人材は不足し、依頼の行列は伸びるばかりだ。外部のSIerに頼めば、要件定義から始まって半年後に納品、変更があればまた数ヶ月──そのスピードでは、現場の業務は待ってくれない。
dbSheetが秀逸なのは、こうした現場固有の複雑なロジックを、Excelの関数とタスク機能の組み合わせで実装できる点にある。
会計年度の判定ならIF関数とDATE関数を組み合わせる。部署コードによる分岐はVLOOKUPで対応する。採番の連番管理はデータベースのタスクで制御する。Excelを日常的に使ってきた担当者であれば、この「関数で考える」という思考回路はすでに備わっている。あとは、その関数をデータベースとつなぐ方法を学ぶだけだ。
そして運用後のメンテナンスも容易だ。「来期から、新設の中部営業部の頭文字は『C』にしてほしい」という変更要求が飛んできたとき、dbSheetなら現場の担当者が対応できる。SIerへの追加発注も、IT部門への依頼チケットも必要ない。
過去台帳の取り込みについても、ExcelデータをそのままインポートしてDBに格納できるdbSheetの特性は、ここで大きな力を発揮する。現場で使われてきた管理帳票の形を壊すことなく、データだけをシステムの中に移し替える。ユーザーは慣れ親しんだ画面で、過去のデータも新しいデータも、同じように扱える。
DX、AI、そして次のキーワードは「DIY」
IT業界はキーワードをめまぐるしく更新し続ける。
DXが叫ばれ、次いでAIが来た。生成AIが業務を変える、コパイロットが人間を補佐する──確かにそれは本当のことだし、無視すべきでもない。
だが私が注目しているのは、その次に来るキーワードだ。それはDIY──ユーザー部門によるシステムの内製化、ではないかと思っている。
考えてみれば当然の流れだ。DXによってデジタル化が進み、AIによってその高度化が進む。そのとき、現場に最も近い「ユーザー部門」自身が、自分たちの業務に合ったシステムを自分たちで作れるようになる。IT部門や外部ベンダーへの依存から脱却し、業務の変化にリアルタイムで対応できるシステムを、自らの手で育てていく。
これは夢物語ではない。dbSheetのようなローコードツールが、この流れを現実のものにしつつある。Excelを使えるメンバーが、プログラマーでなくとも、自分たちの業務システムを作り、改善し、維持できる。情報システム部門は「作る人」から「支える人」へ、役割をシフトしていく。
採番ルールという、外からは些細に見えてしかし内側では重大な業務ロジックを、現場の人間が自分でシステムに落とし込める。それが、本当の意味でのDXではないだろうか。
窓の外が少しずつ白んできた。
「DXって、結局なんなんだろう」という問いへの答えは、まだ完全には出ていない。おそらく一夜では出ない問いだ。
ただ一つ、確かなことがある。それは、DXが成功する組織は例外なく、「仕組み」を作っているということだ。ユーザーの善意や努力に頼るのではなく、使わざるを得ない流れを設計する。過去の記憶を引き継ぎながら、未来に向けて更新し続ける。そしてその設計を、現場の人間が自らの手でできるようにする。
採番という小さな話が、DXの本質を照らし出す。
あなたの組織にも、そんな「採番」が眠っているはずだ。
皆さん本日もお疲れ様でした！
おやすみなさい（挙手）