ツールを導入しても現場に使われず、結局元の方法に戻ってしまう、というのはよくある悩みです。ツール全般に共通する「なぜ使われなくなるのか」という考え方は、ツールを入れても使わなくなるのはなぜ？現場に定着する仕組みの作り方で解説しています。本記事では、それを踏まえたうえで、受託開発する業務アプリ特有の進め方に絞って、社内定着のポイントを解説します。
開発プロセス自体に、社内定着のための仕組みが含まれている
業務アプリ開発とは？で触れた「ご利用支援」の通り、Seldishの業務アプリ開発では、導入後の保守・改修から社内への定着支援まで継続的にサポートし、使いながら育てていくことができます。汎用のSaaSツールと異なり、受託開発の業務アプリは開発プロセス自体の中に、定着につながる仕組みを組み込みやすいという特徴があります。
テストツールの段階から現場を巻き込む
最速3営業日の業務アプリ開発、テストツール先行プロセスの仕組みで紹介した通り、Seldishの業務アプリ開発では受注前にテストツールを確認できます。この段階で、実際に使う現場の担当者にも触ってもらっておくと、本開発が完了した時点で「初めて見る画面」ではなく、すでに操作の流れを知っている状態で導入できます。
また、業務アプリ開発で失敗しないための要件定義の進め方で触れた通り、要件定義の段階から現場の担当者に関わってもらうことも、導入後の定着につながります。自分たちの意見が反映されたツールだと感じられることが、使い続ける動機にもなります。経営者・管理者もこの段階に同席し、現場の意見と業務全体の方針を踏まえて判断することが、後の定着を左右します。
旧来の方法をいつまで使うか、運用ルールとして明文化する
業務アプリへのデータ移行、Excel管理から失敗なく切り替えるにはでは、データそのものの移行範囲や表記の揺れについて触れました。データ移行が完了した後も、「いつから業務アプリだけに切り替えるか」をルールとして明文化しておかないと、Excelや紙の旧来の方法が、部署や担当者によって残り続け、結局二重管理になってしまうことがあります。
切り替え日を決める場合は、その日以降は旧来の方法での更新を止めると周知し、何か問題が起きた場合の相談先も決めておくと、現場が安心して切り替えに踏み出せます。たとえば「来月1日以降は受注管理アプリのみで管理し、Excelファイルは参照用として残すが更新は行わない」といった形で、具体的な日付と運用範囲をセットで決めておくと、部署をまたいだ周知もしやすくなります。
ご利用支援を使った改善サイクルの回し方
業務アプリは、導入した時点で完成というわけではありません。Seldishの「ご利用支援」は、保守・改修・機能追加を通じて使いながら育てていく仕組みです。
たとえば受注管理アプリを導入した場合、「入力項目の並び順が使いにくい」「この項目はもっと目立たせたい」といった声が現場から出ることがあります。こうした小さな要望をご利用支援の中で一つずつ反映していくことで、「言えば直してもらえる」という安心感が生まれ、現場が積極的に使い続けるきっかけになります。改善要望をどこに伝えるかという窓口を、導入時に決めておくとスムーズです。
よくある質問
テストツールの段階で現場の意見を聞くと、開発期間は延びませんか？
テストツールの確認自体は受注前の工程なので、テストツール先行プロセスの仕組みで触れた「受注から納品まで最短3営業日」という期間には影響しません。むしろこの段階で現場の意見を反映しておくことで、受注後の仕様変更を減らせます。
ご利用支援は、導入後どれくらいの期間続きますか？
保守・改修・機能追加、社内への定着支援まで継続的にサポートしています。導入後も使いながら改善を重ねていけます。
社内に複数の部署がある場合、定着のさせ方は変わりますか？
部署ごとに業務の進め方が異なる場合は、それぞれの実情に合わせた導入の進め方を検討します。一律に進めるより、部署ごとの巻き込み方を工夫したほうがスムーズです。
経営者が要件定義やテストツールの確認に、毎回同席する必要がありますか？
必須ではありません。ただし、現場の意見と業務全体の方針をすり合わせる判断が必要になる場面では、経営者・管理者が一度は同席し、方向性を確認しておくと、後から方針がずれて手戻りになることを防げます。
まとめ
業務アプリを社内に定着させるには、テストツールや要件定義の段階から現場を巻き込み、旧来の方法をいつまで使うかを運用ルールとして明文化し、導入後はご利用支援を使った改善サイクルを回すことが基本になります。ツール全般の定着の考え方は現場に定着する仕組みの作り方も参考にしながら、業務アプリケーション開発に関するお悩み事などがあれば、まずはお気軽にSeldishにご相談ください。
