適材適所なサービス選定！現場と情報システム部の双方の視点から見る業務改善！

私の業務改善シリーズでは、トヨクモやkintone界隈の方1人1人が「どのように業務をしているのか」「どのような業務改善を実施したのか」をご紹介していきます。
私の業務改善シリーズ一覧はこちら！

今回は、株式会社ラスコの情報システム部や設計部門で勤務され、kintoneエバンジェリストでもある中島さんに、kintoneとの出会い、kintoneやトヨクモ製品を用いた業務改善事例についてお話しいただきました！

株式会社ラスコは、1964年創業の埼玉県にある会社で、半導体製造装置を支える空調・液調製品を製造しています。

自己紹介・kintoneに出会ったきっかけ

ーこれまでのご経歴や、どのような業務をされてきたか教えてください。

2003年に新卒で、現在も勤めている株式会社ラスコに電気設計のエンジニアとして入社しました。20年ほど設計担当をしていく中で、活動のステージがマネジメントの領域に変わっていくと、社内の情報がまとまっていないと感じるようになりました。

情報をエクセルで作っても一度作って終わりで再利用ができなかったり、マクロなどで内製化も進めていましたが、色々な人に使ってもらうとそのマクロが壊れてそのメンテナンスで手がいっぱいいっぱいになって立ち行かなくなったりと、課題が対応できるものが何かないかと探していたところkintoneに辿り着きました。

kintoneを使っている内に、情報システム部門への異動や、kintoneエバンジェリストの就任も重なり、当初は課題解決の手段として使っていましたが、使っている内に楽しくなってきて、現在に至ります。
（中島氏）

ーエンジニアとして、プログラムでコード書かれてきたと思いますが、kintoneのようなノーコードツールにどのような印象を持たれましたか？

最初はカスタマイズなしで使っていました。データが壊れない安心感や編集履歴が残ることで、データに疑問があった際、いつ誰が更新したか分かります。データを遡ったときに、確認したい情報が自動的に記録されているところががkintoneの良い点だと感じています。（中島氏）

kintoneと連携サービスを活用した業務改善事例

中島さんにkintoneやトヨクモ製品を用いて、実際に行われた業務改善について伺いました！

【基幹システムへの連携】入力ミスによる手戻りを軽減！月80時間の工数削減を実現！

株式会社ラスコでは、各部でまとめた日報データを毎月基幹システムに連携していましたが、連携時にうまく取り込めないなど問題が発生していました。

元々は紙で管理していた日報データを、エクセル管理にしてマクロを組み、作業の簡略化をしていました。しかし、エクセルには手入力していたので、基幹システムのコードとあっているかの確認は目視で行っていました。

マクロで自動で基幹システムに流し込むデータは出るのですが、実際にデータを流し込む際に基幹システムに登録されていない作業コードなどが出てきて手戻りが多々発生していました。それを連携する手段も思い付いてはいましたが、より業務が複雑になってしまい、データベースを誰が更新するのかという新たな課題が生まれます。

誰もがエクセルファイルを自由に編集していたので、マクロ処理がたびたび破綻してしまうことも悩みで「日報が壊れました」という連絡もしょっちゅう受けていました。良かれと思ってマクロを組んだものの、管理する側の地獄が始まってしまい、どうにかしないといけないと思っていたところ、kintoneに辿り着きました。（中島氏）

ー日報の管理は主に情報システム部門の方が確認されていたのですか？

大元の基幹システムの管理は、情報システム部門が行っていましたが、基幹システムにどう入力するかは各部署任せになっていました。製造現場は端末が近くにないので紙でまとめていたり、設計部門はパソコンの前で仕事しているので、データとして使える形でまとめていたり、各部門で対応はまちまちでした。

最終的に基幹システムに決まった形でデータが入っていれば良いという、割と自由な運用になっていました。（中島氏）

ーkintoneを導入してどのように変わりましたか？

基幹システムのデータを定期的に抽出して、kintoneに入れてルックアップで入力するようにしているので、入力ミスはほぼなくなりました。kintone導入前は、作業や案件ごとのコードが無機質なコードになっており、入力ミスをしても気づきにくいことも課題でした。

そこで、いくつか連結したコードにして、案件名で検索しても引っ張って来れるようなキーにしつつ、基幹システムに連携するものはあくまでも従来のコードのみになるよう、情報の検索性が高くなるよう工夫しました。（中島氏）

ーkintoneを導入する前は、どのくらい時間がかかっていましたか？

導入前と比較して、個々人の日報への記載時間、入力間違いによる手戻り、担当者の打ち込み作業(2日/月毎)などを試算すると、設計部門の目に見える部分だけで月80時間の削減ができました。

合わせて部署で受けている案件の完了チェックが年間150件ほどありました。導入前は全く確認できていなかったものが、日報の記録と照らし合わせれば96%完了チェックができる体制が出来ました。

kintone導入前は、テキストコミュニケーションでやり取りするといったスタイルも確立できていなかったため、システムに登録された内容に誤りがあるときは担当者に直接確認をする必要がありました。担当者が休みや出張で不在の時は、ただ時間が経過していくばかりでストレスになっていました。

「担当者に直接ミスの内容を確認→担当者が修正対応」これにかなりの時間を要していたことが大きな課題でした。（中島氏）

ー当時、設計部の打ち込み作業の担当者は何人くらいいましたか？

打ち込み自体は設計部の事務担当の方が1人でやっていました。

打ち込み業務は別部門でもだいたい同じ形で運用されています。

但し、設計部の日報アプリはパソコンに慣れている人が多く機能的に複雑になっていたため、『最終的に基幹システムに取り込めれば良い』というスタンスにあわせて、他部門向け日報アプリはシンプルに入力する形に再構築し、あえて部門別に日報アプリを運用しています。（中島氏）

ー日報登録は、何名くらいの方がされているのですか？

日報登録自体はほぼ全部署での人が行っているので約300名です。その中でkintoneライセンスを持つのは約80名ですね。4部門で使用しており、その中の1部門はFormBridge（フォームブリッジ）とkViewer（ケイビューワー）で、日報の登録・閲覧をしています。

先日こっそりのぞいてみたら、FormBridge、kViewerで運用している部門は、いつの間にか入力している人数が増えてましたね。アカウントを増やさなくても入力ができることを、導入時に説明したのを思い出してくれたみたいです。こういうことがあると嬉しいですよね。（中島氏）

【お弁当注文】注文の集計から、業者への共有まで自動化

お弁当を注文する際、エクセルで注文内容をまとめて送っていましたが、複数のエクセルを連携して使う仕様になっており、扱いが複雑化していました。

エクセルの作りが複雑で、各部門が従業員の名簿を持っていて、人が増えるたびに連携している複数ファイルの内容を変更する必要がありました。

そのため、人が一人増えるだけで複数のエクセルを編集する必要があったのです。その変更作業に何らかの不備があるとファイルが破損してしまったり、増えた人のお弁当を発注できなかったりといったトラブルも発生していました。

エクセルを簡略化しようかという話もありましたが、個人での申込も、部署単位での申込も対応できるということで、FormBridgeとkViewerの導入を決めました。（中島氏）

ーFormBridgeとkViewerの導入を決めたのは、お弁当注文がきっかけですか？

会社として導入するkintoneのライセンス数を考えた時、全社員がkintoneを頻繁に使うわけではないため、FormBridgeとkViewerを導入すれば問題ないと考えました。

また、日報連携でkintoneのアカウントを増やすか、FormBridgeとkViewerを入れるかという話になり、当時は現在よりkintoneのアカウントも少なかったので、まずはFormBridgeとkViewerでやってみようとなりました。その流れで、お弁当注文もFormBridgeとkViewerを活用して行ってみようという結論に至ったのです。（中島氏）

お弁当注文システムの運用については、以下の記事でも解説しています。

関連記事

【3人のkintoneエバンジェリストが語る】トヨクモ製品の魅力と活用方法

トヨクモが主催する「トヨクモ kintone フェス　2023」は、デジタル化して効率的に業務改善する珠玉のアイデアを学び・広める、2日間のオンラインイベントです。2023年のテーマは、「やれるっ、できるっ、キントーン！」で、よりトヨクモ製[…]

ー導入前後で、変化はありましたか？

注文した人のお弁当が届いていなかった時、FormBridgeとkViewerの導入前は注文担当である管理部門の人の責任となっていました。これではやや理不尽ですよね。

導入後は、誰が注文を失念していたのかが分かるようになりました。責任の所在が不明確で何でも管理部門の不手際とみなされてしまうことがなくなったのは良かったですね。

また、お弁当業者への注文数をkViewerで共有できるのが、業者の方からの評判が良かったです。導入前は、電話での伝言リレーで配達担当者に伝わっていたので、数量や場所の配達ミスも多かったです。

kViewerがあれば、途中の注文状況もビューを通して確認できるため、見込みでお弁当を積んでおいて、お弁当の注文を締め切った頃にはすぐ出発できるようになりました。

最終確認で電話はしていますが、数量のやりとりは、kViewerで共有できているため不要になりました。また、配送担当者にもkViewerのURLを共有して活用されているとのことで、拠点ごとの発送ミスもなくなりました。（中島氏）

ー他社にもkintoneと連携できるサービスがありますが、FormBridge・kViewerを選んだ決め手はありますか？

他社のサービスは、フォームが使われた回数やユーザー数などで従量課金になっていたので金額が見えづらく、その点トヨクモ製品は、kintone1ドメインにつき1環境のため、料金が変わらない点が社内での稟議が上げやすく安心でした。

また導入の際に、トヨクモの担当者に電話いただいたり、こちらからも電話で問い合わせた際にサポート体制がとても良かったのも一因です。（中島氏）

【電子帳簿保存法改正対応】kintoneにはこだわらず、体験を落とさない工夫

電子帳簿保存法改正に伴うシステム導入時の経験を話していただきました。

電子帳簿保存法改正で業務を見直すと、「紙を受け取り、エクセルでまとめて、それをまた紙に印刷して提出」という、紙とエクセルの往復作業が多いことが分かりました。

また、まとめたエクセルも月ごとに1シートになっていてデータとして使いづらく、苦労している割にベストな運用とは言えない状況でした。そのため、法改正と一緒に新しいシステムを入れることを決めました。

kintoneも候補の一つとしてはありましたが、法改正への対応はハードルが高いのではと判断し、法改正があった時にもシステムが対応してくれるだろうということで、電子帳簿保存法に対応しているクラウドサービスを入れました。

kintoneも全く使っていないわけではなく、従来方式からの切り替える際の取引先や担当者の管理や進捗管理はkintoneで行っています。

また、krewSheetも使っています。クラウドサービスにデータが入っていますが、手形支払いなど業務フロー上対応できないところがあったので、一旦kintoneに連携・集計した上で後の工程に進むようにしています。（中島氏）

ー法律に関するところは外部サービスで対応したというところですね。

kintoneを使うことが目的ではなく、社内の業務改善が目的ですから、それが大事ですよね！

kintoneを無理やり使って、kintoneでの業務品質が落ちてしまうことも避けるべきと感じました。

電子帳簿保存法改正への対応を情報システム部だけで行うにはマンパワーが不足していました。しっかりと対応できたのは現場の人の力を借りられたのが大きかったです。（中島氏）

ー生産性向上にも効果はありましたか？

経理関係の資料やデータは会計管理ソフトに集約されてはいたものの、全て経理部門の管理下にあったので、他部門の人が情報閲覧するのはややハードルの高さがありました。

クラウドサービス上に各種データや操作の履歴が一元化して残っていて、従来の煩わしさはなくなりました。以前は、部署ごとの支出がブラックボックス化していて、どこの部署でいくら使っているか見えなくなっていました。

最終的には、会計ソフトで計上していましたが、急遽予算枠をとって支払った際など部門ごとに計上していない金額もありましたが、導入後は自部門で自由に確認できるようになり、予算に対してより自覚的になりました。

導入して1年経ちましたが、見えてない予算があったことに気付きました。（中島氏）

【Microsoft 365】システム導入は適材適所に

メールシステムが、社内のローカル環境でオンプレミスで動いているシステムを利用していました。メールの容量上限が1人200MBしかなかったり、社外からアクセスする際の、セキュリティ対策が大変であったり、IEしか対応していなかったりと、様々な点で限界を迎えていたため、Microsoft 365に切り替えました。

また、プリインストール版のOfficeが入ったパソコンを購入することが多かったため、パソコンとライセンスが1対1になっていました。

パソコンが壊れて、再インストールが必要な時の対応が煩雑などの問題があり、これを機にMicrosoft 365に契約を切り替えることで、ライセンス管理・メールアドレス管理が一元管理できるようになりました。（中島氏）

ーMicrosoft 365に切り替えることで何か変化はありましたか？

インストールベースではなくライセンスベースの管理になった部分と、Officeのバージョン違いによるサポートの手間がなくなったのは大きく改善した点です。ただ、考えていたよりもOutlookやTeamsのバージョンアップで挙動が変わるので、困ったときにはWeb版を利用するよう案内しています。

Microsoft 365を導入したら、kintoneではなくて、Microsoft 365に統一できるのではという声も出てきました。技術的にはできなくはないとは思いますが、使う側のITリテラシーの飛躍的な向上や、それ以外にも超えるハードルが多岐にわたるため、実現するのはかなり難しいのではないかと思っています。

kintoneもそうですが、無理に機能を全部使うのではなく、会社の状況に合わせて使うことが業務改善では大切だと感じています。（中島氏）

今後の展望

先日2023年10月に情報システム部門から、再度設計部門に異動になりました。設計部門に戻るとkintoneに触れなくなるかと思っていましたが、部門内での課題を解決してほしいという相談が、情報システム部門の時よりも、設計部門に戻った後の方が来るようになりました。

今の上司が、部署をまたいだ情報のやりとりや、基幹システム連携前の情報が残っていないことに課題を感じていて、それらをkintoneでフォローできるようにしたいなど、現場ならではの課題が出てきています。（中島氏）

「設計部門と、情報システム部門両方を渡ってきたからこそ得られた知識を業務改善に活かしていきたいです。情報システム部だけだと見えてこない現場のことや、設計部門だけだと見えない他の部門のことが分かって、できることの幅が広がったと思うので、今後も仕事が楽しみです。」と中島氏は締めてくれました。

中島　俊一（なかじま としかず）氏

2003年10月 株式会社ラスコに電気設計のエンジニアとして新卒入社
設計部門や情報システム部門で勤務され、社内の業務改善に尽力
また、サイボウズ公認 kintone エバンジェリストとしても、各所で精力的に発信活動を行っている

X：https://twitter.com/nakaji32
note：https://note.com/nkj_t/