本日は、製造業出身でエンジニア経験を持ち、業務の整理からシステム構築まで手がけている中小企業診断士の大谷さんに、小さな製造業がデジタル化を進める上でのポイントを伺います。大谷さん、よろしくお願いいたします。
よろしくお願いいたします。
なぜ、中小製造業のデジタル化は進まないのか
さっそくですが、製造業の生産プロセスのデジタル化が必要だという話は以前からあります。しかし、実際に取り組めている中小企業はまだ少ない印象です。その理由はどこにあるのでしょうか。
中小企業は大企業に比べて、お金もない、専門の人材もいない、ITに詳しい人がいない。いわゆる社内のリソースが乏しいという問題はよく言われます。ただ、私はそれが本質的な原因ではないと考えています。
では、何が本質的な原因なのでしょうか。
「自社の業務のどこに問題があり、何をどう変えればいいか」を整理できる人が社内にいないことです。大企業には、専任のIT担当者がいて、自社の業務を分析し、要件を整理して、ベンダーに「これを作ってほしい」と具体的に伝えることができます。しかし、従業員30名以下の製造業にはその役割を担える人がいません。
ソフトウェアベンダーに相談すると何が起きるか
ベンダーに相談すれば、そこは手伝ってもらえるのではないですか。
ベンダーにとって、受注できるか分からない段階で業務分析から要件定義まで行うのは大きな負荷です。結果として、小規模な案件は後回しにされやすい。経営者としては「やりたいけど、誰に相談すればいいか分からない」という状態になります。
実際にベンダーと話が進んだケースでも、うまくいかないことがあるのでしょうか。
よくあるのは、ベンダーからパッケージソフトの機能説明を聞いて「うちの業務に合いそうだ」と思って導入したものの、実際に使い始めると合わない部分が出てくるパターンです。パッケージソフトには標準機能がありますが、どの会社にもぴったり合うわけではありません。カスタマイズすれば合わせられますが、費用が跳ね上がります。
カスタマイズが難しいとなると、どうなるのですか。
業務の方をパッケージに合わせようとします。「運用でカバー」という言い方をするのですが、これは結局、現場の努力に頼るということです。今までのやり方を変えなければならないので、現場からは「なぜわざわざやり方を変えるのか」と反発が出ます。これがシステムが定着しない大きな要因の一つです。
お金をかけてシステムを入れたのに、使われないまま元のやり方に戻ってしまう。
はい。そのリスクが一番大きいと感じています。あるお客さまの話ですが、ベンダーから「生産管理ができるソフトウェアです」と提案されて導入したところ、実際には生産管理の機能はオプション扱いで、基本機能の事務管理のみの導入だった、ということがありました。
それはかなり極端な例ですね。
極端な例ではありますが、根っこにある問題は同じです。自社がやりたいことと、ベンダーが提供する機能が本当に合っているかを、整理しないまま導入してしまう。ベンダーの仕事は、お客さまの要求事項を満たすソフトウェアを実現することです。「その要求事項が本当に正しいかどうか」を整理するところまでは、ベンダーの役割ではありません。
ベンダーに相談すると、そのベンダーのソフトを前提に話が進んでしまう。
そうです。たとえば「自社に最適な会計ソフトは何ですか」と聞かれたら、どのベンダーも自社の会計ソフトが最適だと言うでしょう。そうでなければ、何を提案すればいいか困ってしまいますから。
確かに、ベンダーの立場からすれば当然ですよね。
ですから、ベンダーに相談する前に、「そもそも何がしたいのか」を整理しておく必要があります。たとえば「会計ソフトが欲しい」とおっしゃる方がいますが、会計ソフトは日々の経理処理――いわゆる財務会計を効率化するためのものです。
「製品別の原価を把握したい」「予算と実績を比較したい」というニーズであれば、それは管理会計の領域ですよね。
はい。管理会計は、原価管理や予算管理を通じて経営判断の材料を作るもので、会計ソフトとは目的が違います。「会計ソフトを入れたい」ではなく、「どういう経緯でそう思ったのか」から整理しないと、自社に合った手段は選べないのです。
システムの刷新でも同じことが言えますか。
はい。「生産管理システムが古くなったから刷新したい」というご相談もよくいただきます。老朽化は確かに一つの理由です。ただ、昔の機能をそのまま新しいシステムに移植して、それでいいのか。業務プロセス自体がこの10年で変わっているのに、システムだけ新しくしても、投資に見合った効果は出にくい。背景をきちんと整理してから手段を選ばないと、費用対効果が合わないのです。
コンサルタントに相談すると何が起きるか
では、業務の整理を専門にしているコンサルタントに頼めばいいのでしょうか。
経営コンサルタントやITコーディネータは、ヒアリングで課題を整理し、解決策の一つとしてシステム導入を提案するところまではできます。ただ、それはあくまで机上の話です。「その仕組みが本当に現場で使えるか」は、実際に試してみないと分かりません。
コンサルタントの提案内容を、ベンダーに渡して検証してもらうことはできないのですか。
ベンダーからすれば、デモを見せるのが精いっぱいです。評価のためにツールを貸し出したとしても、ユーザーは操作方法に慣れていませんから、「使いづらい」という評価になってしまう。それは製品の良し悪しではなく、単に慣れの問題です。結局、導入してみないと自社の業務に合うかどうかは分からない、という状態になってしまいます。
つまり、業務を整理する人と、仕組みを作って試す人が別々だと、どうしても隙間ができてしまう。
そうです。だからこそ、業務を整理して「何が本当に必要か」を明確にしたうえで、実際に動く仕組みを小さく作って現場で試す。この2つをつなげてやれることが重要だと考えています。
デジタル化には段階がある
ここまで「デジタル化が進まない理由」を伺ってきましたが、そもそも「デジタル化」と一口に言っても、いろいろなレベルがありますよね。
はい。実はデジタル化には3つの段階があります。IPA（独立行政法人 情報処理推進機構）の指標でも示されていますが、デジタイゼーション、デジタライゼーション、デジタルトランスフォーメーション（DX）の3つです。
それぞれどう違うのでしょうか。
まずデジタイゼーションは、アナログをデジタルに置き換えるだけの段階です。紙の書類をPDFにする、FAXをメールに変える、手書きの日報をExcelに入力する。紙がデジタルになっただけで、やっていること自体は変わっていません。
確かに、PDFにしたからといって業務が楽になるわけではないですよね。むしろ、扱いづらくなることもありそうです。
そうです。個別の業務を部分的にデジタルに置き換えているだけで、いわば部分的な改善にとどまります。次のデジタライゼーションは、業務プロセスそのものを見直して、全体の流れを効率化する段階です。
たとえばどういうことですか。
受注情報をExcelに入力して、それを別のExcelに転記して、さらに別のシステムに入力して……と途切れ途切れだった業務を、ひとつながりの仕組みでスムーズに流れるようにする。個別ではなく、業務全体を見て改善するイメージです。
部分的な改善と、全体を見た改善。その違いですね。
はい。そして3つ目のデジタルトランスフォーメーション、いわゆるDXは、ビジネスモデルそのものを変革する段階です。正直なところ、中小企業にはかなりハードルが高い。ただ、デジタライゼーションで集めたデータをもとに経営判断ができる状態を作ること。これが中小企業にとっての現実的なDXの入り口だと考えています。
効率化した先に、データを使った経営判断がある、ということですね。
はい。ただ、前提として押さえておきたいのは、業務を効率化しただけだと、従業員は楽になるかもしれませんが、それで止まるということです。コストが下がるわけではありません。従業員を解雇して人件費を削るわけにはいきません。人手不足の時代ですから。効率化で生まれた時間をどう使うかが大事なんです。
時間の使い方ですか。
はい。やり方は2つあります。1つは自動化。繰り返しの作業を仕組みに置き換えて、人の手を空ける。もう1つは標準化。特定の人にしかできなかった業務を、手順として整理して誰でもできるようにする。この2つで、人を増やさなくても対応できる幅が広がります。
そのうえで、データを経営判断に使う段階に進むわけですね。
はい。たとえば、設備稼働率のデータが見えるようになれば、「この設備は稼働率が低いから設備管理を見直そう」「設備ごとに稼働率が違うなら作業手順を標準化してみよう」「この製品は赤字だから価格を見直そう」といった判断ができるようになります。データに基づいて経営判断ができる状態を作ること。これが中小製造業にとっての現実的なゴールだと考えています。
大谷さんが特に注力している領域はありますか。
原価計算と予実管理です。中小製造業の多くは、見積もりは出していますし、日報も書いています。ただ、日報が経営判断に使われているかというと、ほとんどの場合、ただの作業記録で止まっている。紙で管理しているので、書いた後に誰も見直さないんです。
記録はしているのに、経営には活かされていない。
はい。その製品を作るのに実際いくらかかったか――実績原価を把握している会社はほとんどありません。見積もり時の予定原価と実績原価を突き合わせて、差を把握する。これを予実管理と言いますが、ここができていないと、そもそも利益が出ているのかどうかすら分かりません。
予実管理ができると、何が変わるのですか。
「この製品は利益が出ている」「この製品は製造原価に対して価格が合っていない」といった判断ができるようになります。仕事を断るという話ではなく、製造原価を正しく把握した上で、きちんと利益が出る価格で受注する。それができるようになることが、経営判断の第一歩です。
実際原価を把握するために、どのような仕組みを使うのですか。
そこでIoT――モノのインターネットと呼ばれる技術の出番です。簡単に言うと、設備にセンサーを取り付けて、データを自動で集めて、インターネット経由でクラウド（外部のサーバー）に送る仕組みです。センサーで稼働データを自動的に取得し、ダッシュボード――Webブラウザ上でデータをグラフや一覧で見られる画面です――で集計・可視化すれば、記録が自動化されるだけでなく、そのデータがリアルタイムに経営判断に使える状態になります。
ただ、中小製造業の現場には古い機械が多いですよね。IoTに対応できるのですか。
最近の機械では、標準でデータ取得の機能を搭載しているものもあります。ただ、一つの工程のデータだけ取れても、経営判断には使えません。受注から出荷までの流れの中で、どの工程にどれだけ時間がかかっているかを横断的に見る必要があります。
古い機械はどうするのですか。
当社では、古い機械にも後付けでセンサーを取り付けて、そのデータをダッシュボードで見える化する仕組みを作っています。機械自体を改造する必要はありません。新しい機械も古い機械も、同じダッシュボード上でまとめて見える状態にできます。
ただし、見える化するだけでは不十分ですよね。
その通りです。大事なのは、業務プロセスを整理した上で、「どのデータを取れば経営判断に使えるか」を明確にしてから仕組みを作ることです。当社では、そのためのセンサーデバイスの開発とダッシュボードの作成を、試作・検証――いわゆるPoC（Proof of Concept：概念実証）として行っています。本格導入の前に、小さく作って現場で試すということです。
大谷さんのサービスは、先ほどの3段階でいうとどこに位置づけられますか。
当社が担当するのは、デジタライゼーションとDXの入り口です。業務プロセス全体を見直して、必要な部分をデジタル化し、つながった仕組みにする。そのうえで、集めたデータを経営判断に使える状態まで作り上げる。「紙をPDFにしました」で終わらせるのではなく、経営者がデータを見て判断できる状態を目指します。
そのためには、まず業務の流れを整理するところから始める必要がある。
はい。ツールを入れる前に、どこに無駄があるか、どこが途切れているかを見える形にする。そこから始めないと、部分的にデジタルにしただけで終わってしまいます。
まず、業務の流れを一緒に整理する
では、「業務を整理する」というのは、具体的にはどのようなことをされるのですか。
最初にやるのは、経営者のビジョンの確認です。今後5年、10年で、この会社をどういう方向に成長させたいのか。その中で業務がどうあるべきか。ここを最初に押さえておかないと、目先の効率化だけで終わってしまいます。
経営の方向性を先に確認するわけですね。
はい。そのうえで、現状の業務プロセスの棚卸しに入ります。各部署の担当者や管理者の方に、どういう業務をしているか、どういうプロセスを経ているかをヒアリングしていきます。
ヒアリングではどのようなことを確認するのですか。
まず帳票を用意していただきます。この帳票はどういうときに使うのか。インプットは何で、アウトプットは何か。Excelで管理しているのか、アプリで管理しているのか、それとも紙なのか。そもそもこの伝票の目的は何なのか。そういったことを一つずつ確認していきます。
かなり細かく見ていくのですね。
はい。工程ごとに、人の流れ、業務の流れ、帳票の流れを追いかけて、図に起こして見える形にしていきます。いわゆる業務プロセスの棚卸しですが、これは私が一方的に進めるのではなく、現場の担当者や管理者の方と一緒にやるものです。現場の方が一番業務を知っていますから。
棚卸しの中で、どんな発見があるものですか。
よくあるのは、「同じ情報を3カ所に入力していた」「この帳票は10年前に作ったけど、今は誰も見ていない」「この承認フローは形骸化していた」といった発見です。日々の業務に追われていると気づかないことが、図にして俯瞰すると一目で分かるようになります。
現状を把握した後は、どう進めるのですか。
大事なのは「あるべき姿」を描くことです。現状の業務プロセスをそのまま仕組みにしても意味がありません。どこが無駄で、どこに問題があるのかを経営者と一緒に話し合った上で、あるべき姿を設計します。
現状を整理して初めて、理想とのギャップが見えるわけですね。
はい。そのギャップを埋めるために、何を・どの順番で変えるかをロードマップにまとめます。業務フロー図、課題の一覧と優先順位、改善後の業務フロー、改善ロードマップ。これが揃えば、「何が問題で、何を変えるべきか」が目に見える形で分かります。
仕組みを作って、現場で試す
業務を整理して、あるべき姿を設計した。ただ、先ほどのお話では「机上の整理だけでは不十分」ということでした。
はい。業務プロセスを机上で設計したとしても、「本当にそれで現場が回るか」は別の問題です。実際の業務はさまざまな作業が複雑に絡み合っていますから、設計図の上ではきれいに流れていても、現場ではそうはいかないことが多い。
たとえば、どんなことが起きるのですか。
「この工程の後にデータを入力する」と設計しても、実際には作業者の手が離せないタイミングだったりします。「この帳票を廃止してシステムに一本化する」と決めても、取引先とのやり取りで紙が必要だったりする。机上では想定しきれないことが現場にはたくさんあります。
だから、実際に仕組みを作って試す必要がある。
そうです。設計した業務プロセスが本当に現場で成り立つかどうかを、実際に動く仕組みで検証します。センサーを設備に取り付けてデータがきちんと取れるか。ダッシュボードで業務の流れが回るか。現場の方が無理なく使えるか。こうしたことは、やってみないと分かりません。
その仕組みは大谷さんご自身が作るのですか。
はい。センサーのハードウェアからダッシュボードのソフトウェアまで、自社で設計・構築しています。御社の業務に合わせてゼロから作るので、「パッケージソフトが合わない」という問題が起きません。
課題を整理する人と、仕組みを作る人が同じだと何が違うのでしょうか。
情報の受け渡しで起きるズレがなくなります。通常、課題整理はコンサルタント、システム構築はベンダーと、別々の専門家が担当します。間に人が入るたびに認識のずれが生じますし、時間もコストもかかる。当社ではヒアリングで問題点を把握した人間がそのまま仕組みを作るので、速く、ズレがありません。
ヒアリングの中で「ここを測れば数字が見えるようになる」と分かったら、すぐにセンサーを作って設置できるということですか。
そうです。「設備の稼働率を知りたい」という話になれば、電力センサーを設計して設備に取り付ける。「製品ごとの作業時間を記録したい」となれば、バーコードで作業開始・完了を記録する仕組みを作る。業務を整理する中で見えてきた「ここを測るべきだ」というポイントに対して、すぐに動けます。
いきなり大きな投資をしない
業務を整理して、仕組みも作れる。ただ、それでもいきなり大きな投資に踏み切るのは勇気がいりますよね。
はい。中小企業にとっては結構な投資になりますから、効果が分からないまま導入するのはリスクが大きい。そこのハードルを下げることが肝だと考えています。
ハードルを下げる、というのは。
まず小さく試して、デジタル化の効果を実感してもらうことです。ただし、ここで大事なのは、過度な期待を持たないことでもあります。「デジタル化すればすべてが解決する」というわけではありません。
デジタル化にも限界がある、と。
はい。実際に試してみると、「ここはデジタル化で効果が出る」「ここは手作業のままのほうがいい」という線引きが見えてきます。たとえば、設備の稼働データを自動で取る仕組みは非常に効果がありますが、目視検査や顧客との細かいやり取りは、デジタル化してもあまり楽にならないこともあります。その現実を理解した上で、どこにお金をかけるべきか判断できること。これが試作・検証の本当の価値です。
事例：設備の稼働状況を見える化した
具体的な事例を教えていただけますか。
ある切削加工の工場のお話をします。従業員10名ほどの会社で、マシニングセンターを複数台お持ちでした。経営者のお悩みは、「受注は増えているのに、利益が伸びない」ということでした。
利益が伸びない原因は何だったのですか。
見積もりに使う設備の時間単価（マシンアワーレート）が数年前のまま更新されていなかったんです。材料費や人件費は上がっているのに、レートが古いまま。しかし、「設備が実際にどれだけ動いているか」を計測していないので、正しいレートを出しようがない状態でした。
まずは業務の整理から始めたのですか。
はい。受注から出荷までの業務フローを経営者と一緒に整理しました。その中で、見積もりの精度を上げるには設備ごとの実稼働時間を把握することが最優先だ、ということが明確になりました。ただ、作業者に「設備が動いた時間を記録してください」とお願いすると現場の負担が増えてしまいます。
そこでセンサーを使ったわけですね。
はい。マシニングセンターに電力センサーを取り付けました。消費電力の変化から、設備が動いているのか止まっているのかを自動で検知する仕組みです。現場のやり方を変える必要はありません。センサーを設備の電源ケーブルに取り付けるだけです。
現場の方には何もお願いしなかった。
はい。翌日からダッシュボード上に設備ごとの稼働状態がリアルタイムに表示されます。日次・週次・月次の稼働率も自動で集計されます。
経営者の反応はいかがでしたか。
画面を見て、最初に出た言葉が「思っていたより止まっている時間が長い」でした。感覚ではフル稼働だと思っていた設備が、実際には段取り替えや材料待ちで1日の3割以上止まっていた。この数字が見えたことで、レートの再計算ができるようになりました。
感覚と実態のずれが数字で見えたわけですね。
はい。「なんとなく高い気がする」「安い気がする」ではなく、実際の稼働データに基づいた根拠のある数字です。値上げ交渉の場でも、「うちの設備の実稼働率はこれだけで、1時間あたりのコストはこの金額です」と説明できるようになりました。現在は、この稼働データと作業実績を組み合わせて、製品別の実績原価を把握する仕組みの構築に取り組んでいます。
事例：Excelの見積計算書をダッシュボードにした
もう一つ、別の事例も伺えますか。
ある金属加工業のお客さまの話をします。従業員15名で、多品種少量生産のため受注のたびに都度見積もりを作成されていました。見積もりはExcelの計算書で行っていたのですが、2つの問題を抱えていました。
どのような問題ですか。
1つは属人化です。材料費、加工時間、間接費の配賦まで、何年もかけて経営者が作り込んだ計算書で、シートは何十行にもわたります。よくできた計算書でしたが、経営者以外に誰も触れない。計算式の意味が分からない、数字を変えたら別のセルが壊れそうで怖い。結果として、見積もりのたびに経営者自身が計算書を開いて数字を入れるしかない。
もう1つの問題は。
見積もりと実績の突き合わせをしていないことです。予定原価は計算しているが、その製品に実際どれだけの時間がかかったかは記録していない。蓋を開けてみれば赤字だった、という製品が少なくないのですが、どの製品がどれだけ赤字なのか、具体的には分からない状態でした。
経営者としては何を求めていたのですか。
「どの製品で利益が出ていて、どの製品が赤字なのか。それが分かれば、受注の判断が変わる」とおっしゃっていました。要望は明確でした。
どのように対応されたのですか。
まず業務フローを整理するのと並行して、Excelのロジックを一行ずつ紐解きました。「この計算式は何を意味しているか」を経営者と一つずつ確認し、実態とずれている箇所を洗い出しました。材料費の算出方法、加工時間の見積もり根拠、間接費の配賦方法。さらにヒューマンアワーレートやマシンアワーレートも、現在の人件費・設備費・間接費を反映した数字に再計算しました。
Excelのロジック自体を見直したわけですね。
はい。そのうえで、整理した原価計算のロジックを、Webブラウザ上で操作できるダッシュボードとして再構築しました。製品ごとの予定原価が一覧で見える。材料費・労務費・間接費の内訳がグラフで表示される。Excelの計算式では頭の中でイメージするしかなかったものが、画面として目の前に見えるようになりました。
経営者の反応はいかがでしたか。
デモをお見せしたとき、「ぜひこのまま導入したい」とおっしゃいました。計算書の中身は同じなのに、画面として見えるだけで「これが欲しかった」と。計画書や提案書だけでは、経営者はなかなか意思決定できません。実際に動くものを見せて、「これでいけそうだ」と感じてもらうことが、次のステップへの大きなきっかけになります。
この2つの事例に共通しているのは、いきなり大きなシステムを入れるのではなく、まず一つの課題に絞って小さく試しているという点ですね。
はい。小さく試すことで、「ここはデジタル化で効果がある」「ここはそうでもない」という現実が見えてきます。効果が確認できた部分だけ広げていけばいい。いきなり全社導入して、合わなかったらやり直し、というリスクを取る必要がないんです。
ベンダーに「提案してほしい」と依頼できる状態を作る
検証で効果が確認できた後は、どうなるのでしょうか。
当社のゴールは、ベンダーに「こういう業務プロセスで仕事をしたいから、それに見合った機能を提案してほしい」と具体的に依頼できる状態を作ることです。これを提案依頼書（RFP：Request for Proposal）と呼びます。
提案依頼書というのは、あまり聞き慣れない言葉かもしれません。具体的にはどのようなものですか。
簡単に言うと、「うちの業務はこういう流れで、ここに課題がある。こういう仕組みが欲しいので、提案してください」という依頼書です。構成としては、自社のビジョンや事業内容、現状の問題点と解決したい課題、そして業務プロセスを記載して、まず自社の状況をベンダーに理解してもらうことがメインです。そのうえで、あるべき姿として「こういう機能が欲しい」というのを具体的に示します。
それを受け取ったベンダーはどう動くのですか。
ベンダーは提案依頼書の内容を見て、自社のソフトウェアで実現可能なのか、カスタマイズが必要なのか、あるいはできないのかを判断します。そのうえで、「うちならこういう構成で実現できます」「開発期間はこのくらいです」「費用はこの範囲です」という提案を返してきます。
複数のベンダーに渡す、というのがポイントですか。
はい。同じ提案依頼書を複数のベンダーに渡して、提案をもらう。いわゆるコンペです。各社の提案を比較して、機能、費用、開発期間、サポート体制などを総合的に判断し、御社に最も合うベンダーを選ぶことができます。
冒頭のお話にあった「ベンダーに相談するとそのベンダーのソフトを売られる」という問題とは、まったく逆の構図ですね。
そうです。提案依頼書がない状態でベンダーに相談すると、ベンダーは自社の製品を前提に話を進めます。それは当然のことです。しかし提案依頼書があれば、立場が逆転します。御社が「こういうものが欲しい」と要件を提示し、ベンダーが「うちならこう実現できます」と提案する。御社が主導権を持って選べるわけです。
提案依頼書があれば安心、というわけでもないのですか。
注意すべき点はあります。パッケージソフトの導入は、数千万円を超える投資になることも珍しくありません。提案依頼書で要件を明確にしても、「ここは標準機能で対応できます」と言われた部分が、蓋を開けてみるとカスタマイズが必要だった、ということは起こりえます。「運用でカバー」と言われた部分が、本当に現場で実現可能かどうかも、慎重に見極める必要があります。
導入後に想定外のコストが発生するリスクですね。
はい。そのリスクを事前に潰すために、試作・検証が重要になります。「こんな業務の流れにしたい」「こんなデータが欲しい」というのを、実際に動く仕組みとして先に作って試してある。これがあれば、事業者さんがやりたかったことと、ベンダーが提案できることのギャップを、導入前に具体的に確認できます。
試作・検証の結果があることで、提案依頼書の説得力も変わってくる。
その通りです。実際に動く仕組みを作って現場で試した経験がありますから、「この機能が必要です」「この業務はこういう流れで動かしたいです」と具体的に書けます。動いている仕組みがあるので、「こういうものが欲しい」という見本としてベンダーに見せることもできます。
ベンダー側にとってもメリットがありそうですね。
はい。ベンダーも「こういうものを作ればいいんだな」と明確に分かるので、見積もりの精度が上がります。要件が曖昧なまま進めるよりも、お互いにとって良い結果になります。「導入したけど使われなかった」というリスクも大幅に減ります。
検証で作った仕組み自体は、その後どうなるのですか。
進め方は3つあります。1つ目は、検証で作った仕組みをそのまま本運用に広げていく方法。2つ目は、提案依頼書をもとにパッケージソフトの導入に踏み出す方法。3つ目は、その両方を組み合わせる方法です。たとえば、一部の業務は当社が作った仕組みをそのまま使い、基幹の部分はパッケージソフトを導入する、ということもできます。
製品ありきではなく、あくまで業務が起点になっている。
はい。「このシステムを入れましょう」ではなく、まず業務を整理して「何が必要か」を明確にする。その上で手段を選ぶ。この順番が大事です。御社が納得した上で判断できる状態を作ること。それが当社の役割です。
対象範囲に応じた進め方
業務を整理した結果、その先の進め方はどのように決まるのですか。
対象範囲の大きさによって変わります。たとえば、ある製品の原価計算を見える化したいという場合は、対象範囲が比較的狭いので、アプリを開発して現場で試します。そのアプリが業務にフィットすれば、対象範囲を広げていく。一方、基幹システムの入れ替えのように規模が大きい場合は、先ほどお話しした提案依頼書の作成をベースにしつつ、一部の業務についてはPoCとしてアプリを開発し、実際に動くものを使って要件を具体化します。
アプリを開発する目的は、担当者の作業を楽にすることですか。
それだけではありません。もちろん現場の負荷軽減にはなりますが、本当の目的は経営判断ができる状態を作ることです。たとえば原価計算のアプリであれば、担当者の入力作業が楽になるだけでなく、経営者がダッシュボードで製品別の利益をリアルタイムに把握し、価格設定や受注の判断に活かせるようになる。現場の効率化と経営の意思決定、この両方がつながって初めて意味があります。
自分たちで改善を続けられる組織へ
最後に、大谷さんが目指している姿を教えてください。
当社が目指しているのは、単にシステムを導入することではありません。その先にある、御社自身が業務の仕組みを改善し続けられる組織をつくることです。
アプリを試して効果が確認できたら、対象範囲を広げていくというお話がありました。その先はどうなるのですか。
アプリの開発や改善を、御社自身でできるように教育を行います。パッケージソフトを導入しても、標準機能で足りない部分は必ず出てきます。業務も日々変わります。そのたびに外部に頼むのではなく、自分たちでちょっとしたアプリやツールを作って補えるようになると、改善のサイクルが社内で回り始めます。
ただ、アプリを作ると言っても、プログラミングの知識がない方には難しいのではないですか。
教育では、生成AIを活用したアプリ開発を実際に行います。座学ではなく、御社の業務に必要なアプリを、生成AIを使って一緒に作るところから始めます。プログラミングの知識がなくても、やりたいことを言葉で伝えれば、アプリの原型を作ることができます。
実際に手を動かして覚えるわけですね。
はい。ただ、作って終わりではなく、それをチームで共有できる形にすることが大事です。個人の便利ツールで終わらせず、チームの業務として定着させる。そこまで含めて支援しています。
ITリテラシーが上がると、何が変わりますか。
当社がいなくても、事業者さん自身で改善のサイクルを回せるようになります。「もっとこうしたい」と思ったときに、自分たちで形にできる。多くのベンダーは導入後の保守で継続的な収益を得るモデルですが、当社のアプローチはそれとは違います。外部に依存し続けるのではなく、社内に改善の力を育てていく。当社の支援は、御社が自立するための最初の一歩だと考えています。
まずは無料相談から
今日のお話を聞いて、「まさにうちの状況だ」と感じた方もいらっしゃるのではないでしょうか。
「何から始めればいいか分からない」という状態は、決して珍しいことではありません。むしろ、そう感じているということは、課題に気づいているということです。あとは、それを整理する相手がいるかどうかだけの違いだと思います。
大谷さんに相談したい場合は、どうすればよいのでしょうか。
まずは無料でご相談に乗りますので、お気軽にご連絡ください。「デジタル化が必要だと思っているが、何から手をつければいいか分からない」という段階で構いません。お困りごとをお聞きした上で、一緒に整理するところから始めましょう。
本日はお話をお聞かせいただき、ありがとうございました。
こちらこそ、ありがとうございました。
