中小企業で必要になる「全社視点・現場視点・ROI」
前回の記事では、AI活用を段階で考えた。
検索や文章作成、専門業務の支援、小さな自動化、業務データとの連携、さらにAIへ仕事そのものを任せるところまで。
そこで最後に感じたのが、会社として次の段階へ進むには、AIを使える社員を増やすだけでは足りないということだった。
では、そういう人たちは、どう育つのだろう。
最近はこちらの方が次の課題だと感じている。
AIに詳しいだけでは足りない
生成AIの使い方そのものは、かなり身近になった。
ChatGPTやGeminiで文章を作る。
調べる。
要約する。
Excelについて相談する。
こうした使い方は、今後さらに一般化していくだろう。
ただし、会社の仕事を変えるとなると、必要なのは操作方法だけではない。
例えば、次のように考えます。
- 「このExcel入力は本当に人がやる必要があるのか」
- 「この承認は紙を回さず、スマートフォンからできないか」
- 「この数量計算の転記は自動化できないか」
- 「この図面作成の一部は機械処理へ任せられないか」
- 「この申請ルートはポータルから一元化できないか」
と考える。
必要なのは、今の実務を見て、別のやり方を考える力だと思う。
最初の一歩は、独学だけでは出にくい
AIが便利だと分かっていても、最初は何に使えるのか分からない。
ホームページは制作会社に頼むもの。
社内システムはベンダーに作ってもらうもの。
Excelは人が入力するもの。
承認は書類を回すもの。
業務ソフトは人が操作するもの。
そういう前提で仕事をしていれば、そこを変える発想自体が出にくい。
しかし今は、AIにコードを書かせながらホームページを改修することもできる。
VBA、GAS、Pythonで小さな業務ツールを作ることもできる。
社内ポータルを起点に、SSO、API、グループウェア、データベースをつなぎ、申請や承認を一元化することも考えられる。
一度こうした可能性を知ると、
「あれができるなら、これもできるのではないか」
と仕事の見え方が変わる。
だから最初の段階では、独学だけでなく、外部の知識や経験を借りることにも意味があるのだと思う。
ただし、全部作ってもらうという意味ではない。
自社の実務を題材に、
「ここはこう変えられる」
「ここまでは自分たちでできる」
「ここからは専門家へ頼んだ方がよい」
という境界を一緒に見つける。
その最初の数回が、その後の自走につながるのではないかと思う。
必要なのは「遠目」と「近目」
業務改善には、二つの視点が必要になる。
一つは、目の前の実務を見る視点です。
- 数量計算
- 図面作成
- Excel集計
- 帳票作成
- 申請・承認
- ファイル整理・転記
実際にその仕事をしている人だから分かる不便がある。
もう一つは、会社全体を見る視点である。
ある部署で作ったフォームが便利でも、似た仕組みが各部署に乱立すれば、後で管理が複雑になる。
それなら共通データベースにした方がよいかもしれない。
社内ポータルから使えるようにした方がよいかもしれない。
Google Workspaceなどの既存アカウントとSSOでつないだ方がよいかもしれない。
APIで既存システムと連携できるかもしれない。
目の前の作業を変える近目の視点と、会社全体を整える遠目の視点。両方が必要になる。
大きな会社ほど、遠目だけでは届かない
大企業には、DX推進室や情報システム部門、それに近い組織があることが多い。
そこでは、全社最適、標準化、セキュリティ、共通基盤、投資判断などを考える。
これは必要な役割である。
一方で、会社規模が大きくなるほど、各専門部署の細かな実務までは届きにくい。
設計者が毎日行っている数量計算のこの転記。
この図面のこの確認。
このExcelのこの手作業。
こうした細かな改善テーマは、現場を深く知っている人でないと気付きにくい。
逆に、現場だけで改善すると、局所最適になりやすい。
全社を見る人と、専門実務を見る人がつながることが重要になる。
一人のスーパー担当者を作る話ではない
当社のようなごく小規模な会社では、経営と技術実務の距離が近い。
そのため、会社全体の仕組み、現場の作業、投資判断まで、一人でかなり見渡せる。
しかし、会社規模が大きくなるとそうはいかない。
設計を知る人。
総務・経理を知る人。
社内ITを知る人。
ExcelやVBAが得意な人。
AIやプログラムに興味がある人。
それぞれが持っている情報は違う。
だから、一人の万能担当者を育てるよりも、複数人がある程度共通の知識を持ちながら、得意分野を補完し合う方が現実的なのかもしれない。
設計担当が、
「この数量計算を何とかできないか」
と問題を出す。
別の人が、
「Excelで処理できそうだ」
と考える。
さらに、
「他部署でも使うなら共通データにした方がよい」
という話になる。
必要ならAPIやデータベースまで考える。
現場の小さな改善と、会社全体の仕組みを行き来できる人たちがいる。その状態を作ることが重要になる。
そして、ROIの視点が必要になる
中小企業では、こうした役割を専任にできるとは限らない。
本業を持ちながら、改善活動を兼務することになる。
「できるかどうか」だけではなく、**「やる価値があるかどうか」**を見る必要がある。
毎月30分しかかからない作業を自動化するために、20時間かけてツールを作る。
それでは短期的には割に合わない。
一方で、
20人が毎日5分使っている作業なら、年間では大きな時間になる。
もちろん、時間だけではありません。
- ミス防止
- 属人化の軽減
- 品質向上
- 引き継ぎのしやすさ
こうした効果もある。
それでも、改善する時間そのものにもコストがある以上、
何を改善し、何を改善しないか
を選ぶ視点が必要になる。
特に兼務で進めるなら、この判断は重要だと思う。
教わることより、一緒に作ること
こういう人たちをどう育てるか。
一般的な研修だけでは、少し足りないのかもしれない。
AIの基本操作を学ぶことは必要である。
ただ、それだけでは、
「この仕事を変えられないか」
という発想までは育ちにくい。
困っている業務を一つ選ぶ
↓
どう変えられるか考える
↓
小さく作る → 使ってみる → 失敗する → 直す
↓
他の人にも使ってもらう
↓
必要なら会社全体の仕組みへ広げるこうした経験を積む。
その過程で、必要な技術を選びます。
- VBAが必要ならVBAを覚える
- GASが必要ならGASを使う
- Pythonが必要ならPythonを使う
- APIが必要なら、そのときに学ぶ
技術を全部覚えてから改善を始めるのではなく、
実務を改善するために必要な技術を学ぶ。
今はAIがあるので、この育ち方が以前より現実的になっている。
AIによって、内製できる範囲が変わった
以前なら、
「プログラムを書ける人がいない」
「システム会社へ頼むほどではない」
という理由で放置されていた小さな不便は多かったと思う。
今は、その一部を自分たちで解決できる。
だからといって、何でも内製すればよいわけではない。
重要な基幹システム。
高度なセキュリティ。
専門的なインフラ。
こうした部分は外部の専門家へ任せた方がよい場合もある。
ただ、自社で分かる範囲が広がれば、外部へ依頼するときにも、
「何を作ってほしいのか」
「何が正しい状態なのか」
「どこまで任せるのか」
を明確にできる。
内製と外注は反対ではない。
自社に判断できる人がいるからこそ、外部もうまく使える。
そういう関係になるのだと思う。
育てたいのは「AIの人」ではない
ここまで考えると、育てたい人材を「AI人材」と呼ぶことにも少し違和感がある。
AIは重要な道具である。
しかし目的はAIを使うことではない。
目の前の実務を理解し、会社全体とのつながりを考え、ROIを見ながら優先順位を付ける。必要な技術を選び、自分たちで試し、必要なら外部の力も借りる。
育てたいのは、会社の仕事そのものを少しずつ変えられる人たちである。
AIによって、そのための技術的なハードルは以前よりかなり下がった。
だから次に考えるべきなのは、
AIをどう導入するかだけではなく、
AIやデジタル技術を使って、会社全体と現場実務の両方を見ながら仕事を変えられる人たちを、どう育てるか。
なのかもしれない。
当社でもまだ試行錯誤の途中だが、AIを使うことの次には、“仕事を変えられる人をどう育てるか”という課題が見えてきた。同じような規模・業種の会社にとって、何かのヒントになればと思う。