協栄産業株式会社
協栄産業株式会社は、「半導体・FA事業」と「システム開発事業」を中核に、エレクトロニクス分野を幅広く支える企業です。半導体・電子デバイスや産業機器などの販売に加え、ソフトウェアや組込みシステム、IC設計などの開発も手掛けています。商社機能と技術開発力を活かし、自動車、産業、情報通信、建設、物流など幅広い分野で、顧客のものづくりや製品開発、業務課題の解決を支援しています。
同社では、業務改善を進める中で、「公式のマニュアルと呼べるものがほとんど存在していない」という課題を抱えていました。
担当者個人のメモや、引き継ぎのたびに追記されたExcel、システム導入時の説明に使われたPowerPointなどが、それぞれマニュアルとして扱われていたといいます。
ManualForceの導入後、作成されたマニュアルは約200件にまで増加。さらに、ManualForceの利用申請の約7割を、一度利用した社員からの再申請が占めています。
ManualForceの導入によって、社内のマニュアル作成や業務改善はどのように変わったのでしょうか。
経営企画部で業務改善を担当する山﨑もとみ様と、システム開発事業部で基幹システム関連のマニュアル整備を推進される冨久田眞弓様に、導入前の課題やManualForceを選んだ理由、導入後の変化について伺いました。
社内業務の断捨離や効率化、電子化を推進
インタビュアー：まず、現在のご担当業務について教えてください。
山﨑様：
経営企画部にて、社内における業務の断捨離や効率化、業務手順のシンプル化・電子化を進めています。
また、それらに必要なツールの調査・検証・提案を通じた業務改善活動も行っています。
インタビュアー：そうした業務改善は、普段どのような体制で進めているのでしょうか。
山﨑様：
経営企画部内で業務改善を担当しているのは、私を含めて2名です。
一方で、実際に社内業務を改善する際には、さまざまな部署と連携する必要があります。そのため、現場や統括部門などの関係部署のメンバーと合わせて、10名前後の単位で活動することが多くあります。
また、システム導入については、情報システム部のメンバーとも定期的に情報共有を行っています。
「公式のマニュアル」と呼べるものがほとんど存在していなかった
インタビュアー：業務改善活動を進める中で、ManualForceを導入する前には、どのような課題を感じていましたか。
山﨑様：
「公式のマニュアル、つまり手順書と呼べるものがほとんど存在していなかったこと」です。
そもそも、社内で「マニュアル」の定義もバラバラでした。
担当者個人のメモや、代々の担当者が引き継ぎのたびに追記を重ねたExcel、導入時の説明に使われたPowerPointなどが、それぞれ「マニュアル」として扱われている状況でした。
個人のメモレベルでは、どれだけ重要な情報であっても、次の担当者に引き継がれることはまれです。
これまでにも、業務の棚卸しから見える化、マニュアル作成までを期の目標に設定したり、プロジェクトとして実施したりしたことはありました。
しかし、プロジェクトが終了すると更新されなくなり、気づけば形骸化したマニュアルになる、というところまでが、残念ながらセットになっていました。
これが部署ごとに繰り返されていたため、マニュアルのフォーマットも、作成に使用するツールも統一されていない状態が続いていました。
公式のルールや手順が確立されていない中では、業務移管や担当者交代の際にトラブルが起きやすい構造になっていました。
インタビュアー：マニュアルが統一されず、更新も続かない状態によって、実際の業務にはどのような影響が出ていたのでしょうか。
山﨑様：
例えば、トラブルが発生して原因を調べると、上長でさえ把握していなかった手順が存在していた、ということが起きます。
「なぜその作業が存在するのか」「いつから行われているのか」が、誰にも分からない状態だったこともありました。
マニュアルが整備されていない業務でも、作業そのものは経験や慣習によって、問題なく回せてしまうことが少なくありません。
その一方で、「本当にこのやり方が最適なのか」といった、業務の背景や目的を考える機会が少なくなりがちです。
結果として、非効率な手順や不要な作業が含まれていても、それを改善すべき対象だと認識できず、長年続いているやり方をそのまま踏襲する状態になっていました。
特に、歴史の長い業務ほど、その傾向が強いように感じます。
インタビュアー：一方で、マニュアルさえあれば解決する、というわけでもなかったのでしょうか。
山﨑様：
マニュアルが存在していたとしても、別の問題をはらんでいる場合があります。
いわゆる「マクロあるある」と同じです。
以前、マクロが得意な社員が開発したものに対して、後任の別の担当者が追加や修正を重ねていく。その結果、歴代の開発者の癖を多く含んだ、読解が困難なコードが業務の根幹を担っている、という状況が生まれます。
これと同じことが、マニュアルにもよく起きます。
誰も全体を把握できていない「継ぎはぎの知識体系」の中では、業務を改善するどころか、現状を正確に把握することすら容易ではありませんでした。
改善提案に入る前の「現状把握」に多大な時間がかかる
インタビュアー：そうした状況の中で、業務改善を進めるうえで特に大きな負担になっていたのは、どのような部分でしょうか。
山﨑様：
業務課題についてヒアリングをすると、自部署の業務であっても、実際の作業者にしか分からない手順やルール、これまでの経緯が次々と出てきます。
さらに、同じ業務であっても、各拠点を細かく見ていくと、現場ごとの独自ルールやひと手間、工夫が存在していました。
マニュアルが存在していても、内容が古くて使えなかったり、実際の作業内容が簡略化されていたり、一部の手順が省略されていたりすることもあります。
そのため、実際の改善提案に入る以前の「現状把握」だけに、多大な時間を要していました。
さらに、「その手順は会社の公式ルールに則ったものなのか」「ほかの部門にも同じような作業や課題が存在しないか」を確認する必要があります。
改善課題を多数抱えているにもかかわらず、どの課題も「現状把握」の段階からなかなか抜け出せない。
優先順位を決めて取りかかりたいのに、そこまで進めない。なかなか改善に着手できないことに、日常的にもどかしさを感じていました。
インタビュアー：では、当時はそうした業務の実態を、どのように把握していたのでしょうか。
山﨑様：
ひたすら地道なヒアリングと確認作業に頼るしかありませんでした。
担当者やその上長、その業務に詳しい関連部署の方などから複数回話を聞き、実際の作業を見せてもらいながら内容を把握します。
そのうえで、把握した内容が会社として正しいものなのかを、さらに確認するという工程を、すべての課題に対して繰り返していました。
ヒアリング時のメモやスクリーンショットは手元に残ります。
しかし、それらは体系化されたマニュアルではないため、結局は改善担当者にひもづいた属人的な情報にとどまっていました。
インタビュアー：そこまで丁寧にヒアリングを重ねても、なかなか根本的な解決にはつながらなかったのでしょうか。
山﨑様：
大きく3つの理由があったと思います。
1つ目は、改善担当側がヒアリングで情報を集めても、属人的な記録にとどまり、マニュアルにはならなかったことです。
ヒアリング相手となる担当者が異動や退職をするたびに、またゼロから業務を把握し直すことになります。同じ苦労が繰り返される構造から抜け出せませんでした。
2つ目は、現場に「マニュアルを作るほどの作業でもない」という心理的なハードルが根強くあったことです。
細かな作業ほど後回しにされやすく、ほかに大きな課題があると優先順位が下がります。
「課題だとは思うが、今ではなくていい」という結論になることが多くありました。
3つ目は、現場に正常性バイアスが働きやすいことです。
問題がまだ起きていないうちは、「現状で回っている」と感じてしまいます。そのため、マニュアルを整備する必要性が実感されにくく、動き出しが鈍くなりがちでした。
一度トラブルが起きて初めて、その怖さが理解されるという状態でした。
改善プロジェクトのタイミングでManualForceを提案
インタビュアー：そうした中で、ManualForceの導入はどのように進んでいったのでしょうか。
山﨑様：
特に大きな不安はありませんでした。
導入のタイミングが良かったことが大きかったと思います。
ちょうど営業アシスタント業務の改善プロジェクトが動いており、業務の洗い出し、各拠点のルール確認、マニュアル化という流れの中で、ManualForceを提案できました。
もともと改善意識の高いプロジェクトメンバーに、最初の一歩を踏み出してもらえたことが、スムーズな立ち上がりにつながりました。
インタビュアー：スムーズに導入を進められた背景には、ほかにどのような要因がありましたか。
山﨑様：
安心して導入できた背景には、ManualForce側の丁寧なサポートもありました。
十分なトライアル期間を設けていただいたことで、現場のメンバーが実際に触れ、使用感を確かめることができました。
また、導入時にはプロジェクトメンバー向けの説明会を開催していただき、使い方に関する疑問をその場で解消できました。
これも、安心して導入に踏み切れた理由の一つです。
シンプルさと使いやすさがManualForce導入の決め手に
インタビュアー：実際にトライアルで使ってみて、最終的にManualForceを選んだ決め手は何だったのでしょうか。
山﨑様：
主に3つのポイントが決め手になりました。
1つ目は、機能が多すぎないことです。
多機能なツールでは、「作り込みたい人」と「そうでない人」との間で、完成するマニュアルの品質にばらつきが生まれます。
作成に時間をかけて作り込む人がいる一方で、最低限の内容しか作らない人もいます。同じツールを使っているにもかかわらず、出来栄えがまったく異なるという状態になります。
こだわって作られたマニュアルは、更新する際にも同じ熱量が必要です。その熱量が続かなければ、いずれ放置されてしまいます。
ManualForceはシンプルな設計で、作り込む余地がそもそも多くありません。
だからこそ、誰が作っても作成にかける時間に大きな差が生まれず、品質も一定に保たれます。「マニュアルを作ること」が目的化せず、業務の記録という本来の目的に集中できる点を高く評価しました。
2つ目は、UIがシンプルで、直感的に使えることです。
社内には、ITが得意ではない社員も多くいます。kintoneやTeams、AIツールなど、新しいツールが次々と増える中で、現場からは「また新しいツールなのか」「どんどんツールが増えて利用方法を覚えきれない」といった声も聞いていました。
そのため、活用を始める際の心理的なハードルが低く、継続して使い続けてもらえるシンプルさや分かりやすさを重視しました。
3つ目は、作業をしながら自然にマニュアルが完成することです。
これまでは、通常の業務とは別に「マニュアルを作る時間」を確保しなければなりませんでした。しかし、日常業務の中でその時間を作ることは難しく、それがマニュアルが作成・更新されない最大の原因でした。
ManualForceであれば、対象業務を開始するときに「録画」を押し、作業が終わったら「録画終了」を押すだけで、ほぼマニュアルが完成します。
「まず録画だけすればいい」という取りかかりやすさが、現場にも好評です。
作成されたマニュアルは約200件に
インタビュアー：導入後、実際にマニュアル整備はどのように進んでいったのでしょうか。
冨久田様：
営業アシスタントの業務改善、マニュアル作成プロジェクトはひと段落しました。
現在は、基幹システムのマニュアル作成プロジェクトが新たに立ち上がっており、マニュアルの数は着実に増え続けています。現時点では、約200件のマニュアルが作成されています。
この基幹システムは、数年後に別のシステムへ移行することが決まっています。
「移行するのに、今になってなぜマニュアルを作るのか」と思われるかもしれません。
しかし、システムを移行する際には、「現行システムでどのような手順で、何をどのように処理していたのか」という業務手順の情報が不可欠です。
ManualForceで作成したマニュアルは、現行の手順確認や見直しだけでなく、移行前の業務整理や移行作業においても、担当者の負担軽減に役立っています。
利用申請の約7割が、一度利用した社員からの再申請
インタビュアー：マニュアルの数が増えるだけでなく、社員の意識や行動にも変化は感じていますか。
山﨑様：
現在は申請制でユーザーライセンスを貸し出しています。
一度ManualForceを使ったことのある方からの再申請率が非常に高く、これまでの利用申請の約7割がリピーターです。
使いやすさや見やすさ、共有しやすさを体験した方は、別の業務に取り組む際にも、自然と「この業務はManualForceで録っておこう」と思い出してくれています。
「マニュアルを作る」という発想が、じわじわと社内に浸透してきているのを感じています。
インタビュアー：そうした利用の広がりによって、マニュアルの作り方や社内での活用にはどのような変化が生まれていますか。
山﨑様：
ツールが統一されたことで、誰が作成しても、一定の見やすさと統一感のあるマニュアルが自然と出来上がるようになりました。
これは、かつてメモやExcel、Word、PowerPointがバラバラに乱立していた状態から見ると、大きな前進で、業務の属人化解消に向けた確かな一歩となっています。
また、ManualForceの良さを実感した社員が、口コミのような形で、別の社員にこのツールを勧めてくれているという話も耳にします。
今後も利用拡大に向けた取り組みを行い、さらなる効率化に向けて活動していきたいと思っています。
